I don’t have an issue with it, if they want to do what I am too lazy to do, more power to them.

It’s beautiful, I love it.

You need to offer an incentive (ie: discount on new vape if you recycle) and then, from my experience, most people will recycle.

Such restrictions seem to purposefully target poor people, and I have rather strong ethical objections to them (something about making a problem invisible and hoping it'll go away - or starve out), but the effect goes beyond that. Getting $20 back on a $200 product would be a different story, but here, it's more like $2 on $20, or $0.2 on $2; most people aren't going to bother with that (and understandably so: it's not worth the logistics overhead). So at best, all this does is redirect money stream from poor people to recycling companies. More typically, it just makes people recycle less.

Here in NY as a cannabis user, one of the brands available that offers vapes (Fernway) offers a recycling program at dispensaries. I get 10% back off my next vape/cart if I return the old one to the recycling dropbox. My dispensary also keeps how many I've returned on file if I return extras, so I keep a 'balance' of disposables returned for the discounts.

I won't speculate about whether the plastic on the board is recyclable, or ecological to recycle. I don't know. This is what I'm asking.

The fundamental problem with "recycling" is precisely the fact that we just hand it off and don't ask questions about where it ends up, all while feeling great about ourselves afterwards. Bestbuy and Staples are offering accountability laundering so that you don't have to feel bad and in exchange are more likely to become a customer. The 3rd parties working for them do the same thing, but they usually want cash for it.

This sentiment is the case because very often that's where recycling ultimately ends, we just pay someone to move it far away from us so we don't have to see it when it happens.

Until 2018, when they finally stopped accepting it, one of the US largest exports to China was cardboard boxes sent over for "recycling". We burned tons of bunker fuel shipping back the boxes Chinese goods arrived in. The net environmental impact would likely have been less had we just kept the boxes at home.

It's strange to me how often people prefer a widely acknowledged lie than to simply admit the truth.

I always recycle though because the recycle bin in my city is larger than my trash bin, and I don't have enough room in my trash bin sometimes.

Metals, especially aluminum, get widely recycled because it actually makes financial sense.

Plastics, well, you are probably better off burning them for electricity.

I wouldn’t really call that recycling.

But yes, not proper recycling.

Edit: I'm actually curious l, i don't know how recycling supposed to work for electronics and how it can be a scam.

https://www.youtube.com/watch?v=PJnJ8mK3Q3g

(The above is not so much about processors, but about plastics. As long as we are still burning any fossil fuels at all, we are probably better off holding off on recycling and instead burning the plastic for electricity to use ever so slightly less new fossil fuels for power, and instead use the virgin fossil fuels to make new plastics.

Especially considering the extra logistics and quality degradation that recycling entails.

Directly re-using plastic bottles a few times might still be worth it, though.)

The World has limited resources, we don't have a spare.

Do you need it spelling out more clearly?

Also, if you go for measures like mass processed, the weight of microchips, pcbs, parts is only a tiny fraction of what has to be processed and build in the supply chain.

Agreed that it is smarter to use oil for plastics then to burn it directly.

My argument is that as long as we are still burning oil and gas, we might as well burn old plastic instead of new oil and gas.

If/when we stop burning oil and gas, then we can think more seriously about recycling plastic.

It's a fascinating topic. There's even more problems than the ones you bring up, but engineers are also pretty smart.

The world has effectively infinite resources, getting more is usually just a matter of figuring out better extraction techniques or using better energy.

For example at 1% energy growth per year it would only take around 9-10k years before to reach an annual consumption equal to all the energy in the Milky Way galaxy. By "all the energy" I don't just mean consuming all the solar energy from all the stars, and using all the fissionable material in reactors, and fusing everything that can fuse, and burning all the burnable stuff. No, I mean also using all the gravitational potential energy in the galaxy, and somehow turning everything that has mass into energy according to E=mc^2.

From there at 1% annual growth it is only another 2-3k years to using all the energy in the whole observable universe annually.

Population at 1% growth also gets out of hand surprisingly quickly. If we don't get FTL travel then in about 12k years we run out space. That's because in 12k years with no FTL we can only expand into a spherical region of space 12k lightyears in radius. At 1% annual growth from the current population in 12k years the volume of humans would be more than fits in the sphere--and that's assuming we can pack humans so there is no wasted space.

We actually have population growth under 1% now, down to around 0.85%, but that only gets us another 2-3k years.

We are very far from that.

Sure, like effectively infinite atmospheric carbon sink, effectively infinite Helium, effectively infinite fresh water, effectively infinite trees ... we've treated these things as true, because the World is big and population of humans wasn't so big we've got away with that for a time, now those presumptions are coming to bite us, hard.

Yes, we can work our way out of some holes, maybe all of them. But we have to make things sustainable first, then spend those resources. We're not wizards, deus ex machina only reliably happens in movies.

A little Malthusian.

Directly reusing plastic bottles that were not meant to be is bad for your health though, isn't it?

If you just opened it and drank the drink in it, there's probably no harm in filling it soon after and using it a few times like that. Using that same disposable bottle for a few months is probably not a good idea.

The problem here is the item lasts 'long enough' that they can't, a single battery, unless it were very large would drain charge first.

But that brings in the second issue of the device not being refillable, which may be the bigger sin.

Especially since both the waste created in the process of making the device and the e-waste created with it's disposal are somebody else's problem!

When computers become disposable, their programmers soon become disposable as well. Maybe, you shouldn't love it.

Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits. The wire doesn’t care about monads or integers or characters or strings or functors, just 1’s and 0’s, and ultimately I feel like imposing a type system can often get in the way more than it helps. There’s so much weirdness and uncertainty associated with stuff going over the wire, and pretty types often don’t really capture that.

I haven’t tried Gleam yet, and I will give it a go, and it’s entirely possible it will change my opinion on this, so I am willing to have my mind changed.

So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.

Types naively used can fall apart pretty easily. Suppose you have some data being sent in three chunks. Suppose you get chunk 1 and chunk 3 but chunk 2 arrives corrupted for whatever reason. What do you do? Do you reject the entire object since it doesn’t conform to the type spec? Maybe you do, maybe you don’t, or maybe you structure the type around it to handle that.

But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing.

There are more elaborate type systems that do encode these things better like session types, and I should clarify that I don’t think that those get in the way. I just think that stuff like the C type system or HM type systems stop being useful, because these type systems don’t have the best way to encode the non-determinism of distributed stuff.

You can of course ameliorate this somewhat with higher level protocols like HTTP, and once you get to that level types do map pretty well and you should use them. I just have mixed feelings for low-level network stuff.

Of course it’s different. You have a type that accurately reflects your domain/data model. Doing that helps to ensure you know to implement the necessary runtime checks, correctly. It can also help you avoid implementing a lot of superfluous runtime checks for conditions you don’t expect to handle (and to treat those conditions as invariant violations instead).

For things that are invariants, that’s also trivial to check against with `if(!isValid(obj)) throw Error`.

The type is a way to communicate (to the compiler, to other devs, to future you) that those are the expected invariants.

The check for invariants is trivial as you say. The value of types is in expressing what those invariants are in the first place.

I like HM type systems a lot. I’ve given talks on type systems, I was working on trying to extend type systems to deal with these particular problems in grad school. This isn’t meant to a statements on types entirely. I am arguing that most systems don’t encode for a lot of uncertainty that you find when going over the network.

For ensuring bits don't get lost, you use protocols like TCP. For ensuring they don't silently flip on you, you use ECC.

Complaining that static types don't guard you against lost packets and bit flips is missing the point.

Again, it’s not that I have an issue with static types “not protecting you”, I am saying that you have to encode for this uncertainty regardless of the language you use. The way you typically encode for that uncertainty is to use an algebraic data type like Maybe or Optional. Checking against a Maybe for every field ends up being the same checks you would be doing with a dynamic language.

I don’t really feel the need to list out my full resume, but I do think it is very likely that I understand type systems better than you do.

Gleam is still new to me, but my experience writing parsers in Haskell and handling error cases succinctly through functors was such a pleasant departure from my experiences in languages that lack typeclasses, higher-kinded types, and the abstractions they allow.

The program flowed happily through my Eithers until it encountered an error, at which point that was raised with a nice summary.

Part of that was GHC extensions though they could easily be translated into boilerplate, and that only had to be done once per class.

Gleam will likely never live to that level of programmer joy; what excites me is that it’s trying to bring some of it to BEAM.

It’s more than likely your knowledge of type systems far exceeds mine—I’m frankly not the theory type. My love for them comes from having written code both ways, in C, Python, Lisp, and Haskell. Haskell’s types were such a boon, and it’s not the HM inference at all.

Sure thing. Unless dev forgets to do (some of) these checks, or some code downstream changes and upstream checks become gibberish or insufficient.

IMO the right approach is just to parse everything into a known type at the point of ingress, and from there you can just deal with your language's native data structures.

Once you add distribution you have to encode for the fact that the network is terrible.

You absolutely can parse at ingress, but then there are issues with that. If the data you got is 3/4 good, but one field is corrupted, do you reject everything? Sometimes, but often Probably not, network calls are too expensive, so you encode that into the type with a Maybe. But of course any field could be corrupt so you have to encode lots of fields as Maybes. Suddenly you have reinvented dynamic typing but it’s LARPing as a static type system.

I get what your saying, but can't you have the same issue if instead you have 3 local threads that you need to get the objects from, one can throw an exception and you only receive 2, same problem

When you have to deal with large amounts of uncertainty, static types often reduce to a bunch of optionals, forcing you to null check every field. This is what you end up having to do with dynamic typing as well.

I don’t think types buy you much in cases with extreme uncertainty, and I think they create noise as a result.

It’s a potentially similar issue with threads as well, especially if you’re not sharing data between them, which has similar issues as a distributed app.

A difference is that it’s much cheaper to do retries within a single process compared to doing it over a network, so if something gets borked locally then a retry is (comparatively) free.

On one end, you write / generate / assume a deserialisator that checks whether incoming data satisfies all required invariants, eg all fields are present. On the other end, you specify a type that has all the required fields in required format.

If deserialisation fails to satisfy type requirements, it produces an error which you can handle by eg falling back to a different type, rejecting operation or re-requesting data.

If deserialisation doesn't fail – hooray, now you don't have to worry about uncertainty.

The important thing here is that uncertainty is contained in a very specific place. It's an uncertainty barrier, if you wish: before it there's raw data, after it it's either an error or valid data.

If you don't have a strict barrier like that – every place in the program has to deal with uncertainty.

So it's not necessarily about dynamic / static. It's about being able to set barriers that narrow down uncertainty, and growing number of assumptions. The good thing about ergonomic typing system is that it allows you to offload these assumptions from your mind by encoding them in the types and let compiler worry about it.

It's basically automatization of assumptions book keeping.

What the hell is really the alternative here? Do you just pretend your process can accept any kind of data, and just never do anything with it??

If you need an integer and you get a string, you just don't work. This has nothing to do with types. There's no solution here, it's just no thank you, error, panic, 500.

Actually Gleam somewhat shares this view, it doesn't pretend that you can do typesafe distributed message passing (and it doesn't fall into the decades-running trap of trying to solve this). Distributed computing in Gleam would involve handling dynamic messages the same way handling any other response from outside the system is done.

This is a bit more boilerplate-y but imo it's preferable to the other two options of pretending its type safe or not existing.

I might give it a look this weekend.

the dynamic messages have to have static properties to be relevant for the receiving program, the properties are known upfront, and there's no "decades-running trap of trying to solve this".

I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something. The fact that, even given a very popular alternative in that list, or super tightly integrated RPC like sending terms between BEAMs, basic questions like “should optionality/absence be encoded differently than unset default values?” and “how should we encode forward compatibility?” have so may different and unsatisfactory answers says something.

Not as an appeal to authority or a blanket endorsement, but I think Fowler put it best: https://martinfowler.com/articles/distributed-objects-micros...

It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.

> It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.

ASN.1 wasn't in the same problem space with CORBA/DCOM, both CORBA and DCOM/OLE were heavily invested in a general-purpose non-domain-specific object model representation that would suppot arbitrary embeddings within an open-ended range of software. I suspect this is the unsolvable problem indeed, but I also believe that's not what you meant with your comment either, since all the known large-scale BEAM deployments (the comment I originally replied to implied BEAM deployments) operate within bounded domain spaces such as telecom and messaging, where distributed properties of the systems are known upfront: there are existing formats, protocols of exchange, and the finite number of valid interactions between entities/actors of the network, the embeddings are either non-existent or limited to a finite set of media such as static images, videos, maps, contacts etc. All of these can be encoded by a compile-time specification that gets published for all parties upfront.

> basic questions like “should optionality/absence be encoded differently than unset default values?”

However you like, any monoid would work here. I would argue that [a] and [] always win over (Option a) and especially over (Option [a]).

> and “how should we encode forward compatibility?”

If you'd like to learn if there's a spec-driven typed way of achieving that, you can start your research from this sample implementation atop json: https://github.com/typeable/schematic?tab=readme-ov-file#mig...

The "its only bits" thing makes no sense in the world of types. In the end its machine code, that humans never (in practice) write or read.

Within a single computer that’s easy because a single computer is generally well behaved and you’re not going to lose data and so yeah your type assumptions hold.

When you add distribution you cannot make as many assumptions, and as such you encode that into the type with a bunch of optionals. Once you have gotten everything into optionals, you’re effectively doing the same checks you’d be doing with a dynamic language everywhere anyway.

I feel like at that point, the types stop buying you very much, and your code doesn’t end up looking or acting significantly different than the equivalent dynamic code, and at that point I feel like the types are just noise.

I like HM type systems, I have written many applications in Haskell and Rust and F#, so it’s not like I think type systems are bad in general or anything. I just don’t think HM type systems encode this kind of uncertainty nicely.

You absolutely can make all assumptions relevant to the handling/dispatching logic expressed at type-level.

> and as such you encode that into the type with a bunch of optionals.

Not necessarily, it can be `Alternative f` of non-optional compound types that define the further actions downstream.

> Once you have gotten everything into optionals, you’re effectively doing the same checks you’d be doing with a dynamic language everywhere anyway.

Not true, your business logic can be dispatched based on a single pattern comparison of the result of the `Alternative f`.

This reminded me of that.

[1] https://www.thecinemasnob.com/crossovers/brad-and-pheloustro...

Generative AI, as we know it, has only existed ~5-6 years, and it has improved substantially, and is likely to keep improving.

Yes, people have probably been deploying it in spots where it's not quite ready but it's myopic to act like it's "not going all that well" when it's pretty clear that it actually is going pretty well, just that we need to work out the kinks. New technology is always buggy for awhile, and eventually it becomes boring.

Every 2/3 months we're hearing there's a new model that just blows the last one out of the water for coding. Meanwhile, here I am with Opus and Sonnet for $20/mo and it's regularly failing at basic tasks, antigravity getting stuck in loops and burning credits. We're talking "copy basic examples and don't hallucinate APIs" here, not deep complicated system design topics.

It can one shot a web frontend, just like v0 could in 2023. But that's still about all I've seen it work on.

We all know LLMs get stuck. We know they hallucinate. We know they get things wrong. We know they get stuck in loops.

There are two types of people: The first group learns to work within these limits and adapt to using them where they’re helpful while writing the code when they’re not.

The second group gets frustrated every time it doesn’t one-shot their prompt and declares it all a big farce. Meanwhile the rest of us are out here having fun with these tools, however limited they are.

> The whole discourse around LLMs is so utterly exhausting. If I say I don't like them for almost any reason, I'm a luddite. If I complain about their shortcomings, I'm just using it wrong. If I try and use it the "right" way and it still gets extremely basic things wrong, then my expectations are too high.

As I’ve said, I use LLMs, and I use tools that are assisted by LLMs. They help. But they don’t work anywhere near as reliably as people talk about them working. And that hasn’t changed in the 18 months since I first promoted v0 to make me a website.

Using LLMs has made it fun for me to make software again.

Overconfident and over-positive shallow posts just hurt the overall discussion. Also some layer of arrogance - a typical 'if you struggle to get any significant value out of this new toy you must be doing something horribly wrong, look at us all being 100x productive!' which is never ever followed by some detailed explanation of their stack and other details.

Clearly the tools have serious issues since most users struggle to get any sustained reliable added value, and everybody keeps hoping things will improve later due to it being able to write lengthy prose on various topics or fill our government documents.

Yeah, kids these days just include stdio.h and start printing stuff, no understanding of register allocation or hardware addressing modes. 20 years from now nobody will know how to write an operating system.

Also some layer of arrogance

As compared to "if you claim AI is useful for you, you're either delusional or a shill"? The difference is that the pro-AI side can accept that any specific case it may not work well, while detractors have to make the increasingly untenable argument that it's never useful.

If you hired a human, it will cost you thousands a week. Humans will also fail at basic tasks, get stuck in useless loops, and you still have to pay them for all that time.

For that matter, even if I'm not hiring anyone, I will still get stuck on projects and burn through the finite number of hours I have on this planet trying to figure stuff out and being wrong for a lot of it.

It's not perfect yet, but these coding models, in my mind, have gotten pretty good if you're specific about the requirements, and even if it misfires fairly often, they can still be useful, even if they're not perfect.

I've made this analogy before, but to me they're like really eager-to-please interns; not necessarily perfect, and there's even a fairly high risk you'll have to redo a lot of their work, but they can still be useful.

> salesman can convince executives that it does

I tend to think that reality will temper this trend as the results develop. Replacing 10 engineers with one engineer using Cursor will result in a vast velocity hit. Replacing 5 engineers with 5 "agents" assigned to autonomously implement features will result in a mess eventually. (With current technology -- I have no idea what even 2027 AI will do). At that point those unemployed engineers will find their phones ringing off the hook to come and clean up the mess.

Not that unlike what happens in many situations where they fire teams and offshore the whole thing to a team of average developers 180 degrees of longitude away who don't have any domain knowledge of the business or connections to the stakeholders. The pendulum swings back in the other direction.

Maybe I shouldn't have used the word "replaced", as I don't really think it's actually going to "replace" people long term. I think it's likely to just lead to higher output as these get better and better .

[1] https://en.wikipedia.org/wiki/Jevons_paradox

[2] https://en.wikipedia.org/wiki/Gustafson%27s_law

Anecdotally I’ve seen no difference in model changes in the last year, but going from LLM to Claude code (where we told the LLMs they can use tools on our machines) was a game changer. The improvement there was the agent loop and the support for tools.

In 2023 I asked v0.dev to one shot me a website for a business I was working on and it did it in about 3 minutes. I feel like we’re still stuck there with the models.

Now it's reversed. More often than not its method is better than mine (e.g. leveraging a better function/library than I would have).

In general, it's writing idiomatic mode much more often. It's been many months since I had to correct it and tell it to be idiomatic.

There were definitely languages where it worked better (JS), but if I told people here I had to spend a lot of time tweaking after it, at least half of them assumed I was being really anal about spacing or variable names, which was simply not the case.

It’s still the case for cheaper models (GPT-mini remains a waste of my timetime), but there’s mid level models like Minimax M2 that can produce working code and stuff like Sonnet can produce usable code.

I’m not sure the delta is enough for me that I’d pay for these tools on my own though…

Of course, sample size of one, so if you haven't gotten those results then fair enough, but I've at least observed it getting a lot better.

It is a helper, a partner, it is still not ready go the last mile

If you hired a staff engineer to sit next to me, and I just had him/her write 100% of the code and never tried to understand it, that would be an unwise decision on my part and I'd have little room to complain about the times he made mistakes.

> The whole discourse around LLMs is so utterly exhausting. If I say I don't like them for almost any reason, I'm a luddite. If I complain about their shortcomings, I'm just using it wrong. If I try and use it the "right" way and it still gets extremely basic things wrong, then my expectations are too high.

I’m perfectly happy to write code, to use these tools. I do use them, and sometimes they work (well). Other times they have catastrophic failures. But apparently it’s my failure for not understanding the tool or expecting too much of the tool, while others are screaming from the rooftops about how this new model changes everything (which happens every 3 months at this point)

That experience gave me a deep appreciation for how incredible LLMs are and the amazing software they can power—but it also completely demystified them. So by all means, let’s use them. But let’s also understand there are no miracles here. Go back to Shannon’s papers from the ’60s, and you'll understand that what seems to you like "emerging behaviors" are quite explainable from an information theory background. Learn how these models are built. Keep up with the latests research papers. If you do, you’ll recognize their limitations before those limitations catch you by surprise.

There is no silver bullet. And if you think you’ve found one, you’re in for a world of pain. Worse still, you’ll never realize the full potential of these tools, because you won’t understand their constraints, their limits, or their pitfalls.

See my previous comment (quoted below).

> If I complain about their shortcomings, I'm just using it wrong. If I try and use it the "right" way and it still gets extremely basic things wrong, then my expectations are too high.

Regarding "there are no miracles here"

Here are a few comments from this thread alone,

- https://news.ycombinator.com/item?id=46609559 - https://news.ycombinator.com/item?id=46610260 - https://news.ycombinator.com/item?id=46609800 - https://news.ycombinator.com/item?id=46611708

Here's a few from some older threads: - https://news.ycombinator.com/item?id=46519851 - https://news.ycombinator.com/item?id=46485304

There is a very vocal group who are telling us that there _is_ a silver bullet.

If your metric is an LLM that can copy/paste without alterations, and never hallucinate APIs, then yeah, you'll always be disappointed with them.

The rest of us learn how to be productive with them despite these problems.

I struggle to take comments like this seriously - yes, it is very reasonable to expect these magical tools to copy and paste something without alterations. How on earth is that an unreasonable ask?

The whole discourse around LLMs is so utterly exhausting. If I say I don't like them for almost any reason, I'm a luddite. If I complain about their shortcomings, I'm just using it wrong. If I try and use it the "right" way and it still gets extremely basic things wrong, then my expectations are too high.

What, precisely, are they good for?

I agree that there's definitely some overhype to them right now. At least for the stuff I've done they have gotten considerably better though, to a point where the code it generates is often usable, if sub-optimal.

For example, about three years ago, I was trying to get ChatGPT to write me a C program to do a fairly basic ZeroMQ program. It generated something that looked correct, but it would crash pretty much immediately, because it kept trying to use a pointer after free.

I tried the same thing again with Codex about a week ago, and it worked out of the box, and I was even able to get it to do more stuff.

The gist is this: Programmers view computers as deterministic. They can't tolerate a tool that behaves differently from run to run. They have a very binary view of the world: If it can't satisfy this "basic" requirement, it's crap.

Programmers have made their career (and possibly life) being experts at solving problems that greatly benefit from determinism. A problem that doesn't - well either that needs to be solved by sophisticated machine learning, or by a human. They're trained on essentially ignoring those problems - it's not their expertise.

And so they get really thrown off when people use computers in a nondeterministic way to solve a deterministic problem.

For everyone else, the world, and its solutions, are mostly non-deterministic. When they solve a problem, or when they pay people to solve a problem, the guarantees are much lower. They don't expect perfection every time.

When a normal human asks a programmer to make a change, they understand that communication is lossy, and even if it isn't, programmers make mistakes.

Using a tool like an LLM is like any other tool. Or like asking any other human to do something.

For programmers, it's a cardinal sin if the tool is unpredictable. So they dismiss it. For everyone else, it's just another tool. They embrace it.

[1] This, of course, is changing as they become better at coding.

Then there are the cases where I just cannot get it do what I ask. Ask Gemini to remove the background of an image and you get a JPEG with a backed in checkerboard background, even when you tell it to produce an RGBA PNG. Again, I don't have any use for that.

But it does know a lot of things, and sometimes it informs me of solutions I was not aware of. The code isn't great, but if I were non-technical (or not very good), this would be fantastic and better than I could do.

I use LLMs, I code with a mix of antigravity and Claude code depending on the task, but I feel like I’m living in a different reality when the code I get out of these tools _regularly just doesn’t work, at all_. And to the parents point, I’m doing something wrong for noticing that?

> And to the parents point, I’m doing something wrong for noticing that?

There's nothing wrong pointing out your experience. What the OP was implying was he expects them to be able to copy/paste reliably almost 100% of the time, and not hallucinate. I was merely pointing out that he'll never get that with LLMs, and that their inability to do so isn't a barrier to getting productive use out of them.

> he'll never get that with LLMs, and that their inability to do so isn't a barrier to getting productive use out of them.

This is _exactly_ what the comment thread we're in said - and I agree with him. > The whole discourse around LLMs is so utterly exhausting. If I say I don't like them for almost any reason, I'm a luddite. If I complain about their shortcomings, I'm just using it wrong. If I try and use it the "right" way and it still gets extremely basic things wrong, then my expectations are too high.

> If it were terrible, you wouldn't use them, right? Isn't the fact that you continue to use AI coding tools a sign that you find them a net positive? Or is it being imposed on you?

You're putting words in my mouth here - I'm not saying that they're terrible, I'm saying they're way, way, way overhyped, their abilities are overblown, (look at this post and the replies of people saying they're writing 90% of code with claude and using AI tools to review it), but when we challenge that, we're wrong.

Ah, no. This is wildly off the mark, but I think a lot of people don't understand what SWEs actually do.

We don't get paid to write code. We get paid to solve problems. We're knowledge workers like lawyers or doctors or other engineers, meaning we're the ones making the judgement calls and making the technical decisions.

In my current job, I tell my boss what I'm going to be working on, not the other way around. That's not always true, but it's mostly true for most SWEs.

The flip side of that is I'm also held responsible. If I write ass code and deploy it to prod, it's my ass that's gonna get paged for it. If I take prod down and cause a major incident, the blame comes to me. It's not hard to come up with scenarios where your bad choices end up costing the company enormous sums of money. Millions of dollars for large companies. Fines.

So no, it has nothing to do with non-determinism lol. We deal with that all the time. (Machine learning is decades old, after all.)

It's evaluating things, weighing the benefits against the risks and failure modes, and making a judgement call that it's ass.

scamming people

I haven't heard that at all. I hear about models that come out and are a bit better. And other people saying they suck.

>Meanwhile, here I am with Opus and Sonnet for $20/mo and it's regularly failing at basic tasks, antigravity getting stuck in loops and burning credits.

Is it bringing you any value? I find it speeds things up a LOT.

Gemini now often produces output that looks significantly better than what I could produce manually, and I'm an expert for web, although my expertise is more in tooling and package management.

I'm suspecting that once these models hit 'good enough' for ~90% of users and use cases, the providers started optimizing for cost instead of quality, but still benchmark and advertise for quality.

Probably less than that, practically speaking. ChatGPT's initial release date was November 2022. It's closer to 3 years, in terms of any significant amount of people using them.

I think the big problem is that the pace of improvement was UNBELIEVABLE for about 4 years, and it appears to have plateaued to almost nothing.

ChatGPT has barely improved in, what, 6 months or so.

They are driving costs down incredibly, which is not nothing.

But, here's the thing, they're not cutting costs because they have to. Google has deep enough pockets.

They're cutting costs because - at least with the current known paradigm - the cost is not worth it to make material improvements.

So unless there's a paradigm shift, we're not seeing MASSIVE improvements in output like we did in the previous years.

You could see costs go down to 1/100th over 3 years, seriously.

But they need to make money, so it's possible non of that will be passed on.

I have no idea what this is called, but it feels like a lot of people assume that progress will continue at a linear pace for forever for things, when I think that generally progress is closer to a "staircase" shape. A new invention or discovery will lead to a lot of really cool new inventions and discoveries in a very short period of time, eventually people will exhaust the low-to-middle-hanging fruit, and progress kind of levels out.

I suspect it will be the same way with AI; I don't now if we've reached the top of our current plateau, but if not I think we're getting fairly close.

I'll interpret it as meaning 1800s to 1900s to 2000s. I'd argue that we haven't yet seen the same step change as 1800s to 1900s this century because we're only just beginning the ramp up on the new technology that will drive progress this century similar to how in 1926 they were still ramping up on the use of electricity and internal combustion engines.

Let's take electricity as the primary example though since it's the one you mentioned and it's probably more similar to our current situation with AI. The similarities include the need for central generating stations to supply raw power to end users as well as the need for products designed to make use of that power and provide some utility to the consumer. Efficiency of generation is also a primary concern for both as it's a major cost driver. Both of those required significant investment and effort to solve in the early days of electrification.

We're now solving similar problems with AI, instead of power plants we're building datacenters, instead of lightbulbs and washing machines we're developing chat bot integrations and agents, instead of improving dynamos we're improving GPUs and TPUs. I fully expect we'll follow a similar curve for deployment as we find new uses, improve existing ones and integrate this new power source into an increasing number of domains.

We do have one major advantage though, we've already built The Grid for distribution which saves a massive amount of effort.

This article is a good read on the permeation of electricity through the economy

https://www.construction-physics.com/p/the-birth-of-the-grid

We may be in a similar step-jump period now, where over the next 10-15 years we'll see some pretty big advancements in robotics due to AI, and then all of the low hanging fruit will be picked until there some other MAJOR breakthrough

Alphabet / Google doesn’t have that issue. OAI and other money losing firms do.

I'm not trying to be pedantic, but how did you arrive at 'keep improving' as a conclusion? Nobody is really sure how this stuff actually works. That's why AI safety was such a big deal a few years ago.

I will acknowledge that I don't have any evidence of this claim, so maybe the word "likely" was unwise, as that suggests probability. Feel free to replace "is "likely to" with "it feels like it will".

I made a joke once after the first time I watched one of those Apple announcement shows in 2018, where I said "it's kind of sad, because there won't be any problems for us to solve because the iPhone XS Max is going to solve all of them".

The US economy is pretty much a big vibes-based Ponzi scheme now, so I don't think we can single-out AI, I think we have to blame the fact that the CEOs running these things face no negative consequences for lying or embellishing and they do get rewarded for it because it will often bump the stock price.

Is Tesla really worth more than every other car company combined in any kind of objective sense? I don't think so, I think people really like it when Elon lies to them about stuff that will come out "next year", and they feel no need to punish him economically.

I'd rather characterize it as extremes of Greater Fool Theory.

https://en.wikipedia.org/wiki/Greater_fool_theory

The technology is neat, the people selling it are ghouls.

I know it's good tech for some stuff, just not for everything. It's the same with previous bubbles. VR is really great for some things but we were never going to work with a headset on 8 hours a day. Bitcoin is pretty cool but we were never going to do our shopping list on Blockchain. I'm just so sick of hypes.

But I do think it's good tech, just like I enjoy VR daily I do have my local LLM servers (I'm pretty anti cloud so I avoid it unless I really need the power)

It's not really about the societal impacts for me, at least not yet, it's just not good enough for that yet. I do worry about that longer-term but not with the current generation of AI. At my work we've done extensive benchmarking (especially among enthusiastic early adopters) and while it can save a couple hours a week we're nowhere near the point where it can displace FTEs.

It's a business, but it won't be the thing the first movers thought it was.

It's certainly easier once they're dead. I can't speak for everyone, but part of the issue is that we don't want to financially support anyone who is doing bad stuff, so once they're dead I don't have to worry about funding them.

Hyperbolic example; suppose David Duke wrote a fantasy novel. Let's even assume that this fantasy novel had nothing to do with race or politics and was purely just about elves and gnomes and shit. Let's also assume that the novel is "good" by any objective measure you're like to use.

I would still not want to buy it, because I would be afraid that my money is going to something I don't agree with. David Duke is a known racist, neo-Nazi, and former leader of the KKK, and if I were to give him cash then it's likely that some percentage of this will end up towards a cause that I think is very actively harmful.

Now, if you go too deep with this, then of course you can't ever consume anything; virtually every piece of media involves multiple people, often dozens or even hundreds, many of which are perfectly fine people and some of which are assholes, so unless you want to go live in a Unabomber shack then everything devolves into my favorite Sonic quote [1].

So you draw a line somewhere, and I think people more or less have drawn the line at "authorship".

[1] https://www.reddit.com/media?url=https%3A%2F%2Fexternal-prev...

Dilbert came out a bit before I was born, so from my perspective it always existed. Even before I had ever had any kind of office job, I was reading the Dilbert comics and watching the cartoon series, and had even read The Dilbert Principle.

It was upsetting that he ended up with such horrible viewpoints later in his life, and they aren’t really forgivable, but as you stated it’s sort of like a relative you grew up with dying.

I really hate my grandmother, because she has repeatedly said very racist stuff to my wife, so I haven’t talked to her in since 2018, and the only communication that I have had with her was a series of increasingly nasty emails we exchanged after she called my mother a “terrible parent” because my sister is gay, where I eventually told her that she “will die sad and alone with her only friend being Fox News”.

It is likely that I will never say anything to her ever again; she is in her 90s now, and not in the greatest health from my understanding. When she kicks the bucket in a few years, I think I am going to have similar conflicts.

Despite me hating her now, it’s not like all my memories with her were bad. There are plenty of happy memories too, and I am glad to have those, but it doesn’t automatically forgive the horrible shit she has said to my wife and mother and sister.

I have thought about reaching out, but I cannot apologize for anything I said because I am not sorry for anything I said, and I do not apologize for things unless I actually regret them.

Dunno, relationships and psychology are complex and I can’t pretend to say I understand a damn thing about how my brain works.

To learn FUSE, however, I started just making everything into filesystems that I could mount. I wrote a FUSE driver for Cassandra, I wrote a FUSE driver for CouchDB, I wrote a FUSE driver for a thing that just wrote JSON files with Base64 encoding.

None of these performed very well and I'm sort of embarrassed at how terrible the code is hence why I haven't published them (and they were also just learning projects), but I did find FUSE to be extremely fun and easy to write against. I encourage everyone to play with it.

FUSE makes me think that the Plan 9 people were on to something. Filesystems actually can be a really nice abstraction; sort of surreal that I could make an application so accessible that I could seriously have it directly linked with Vim or something.

I feel like building a FUSE driver would be a pretty interesting way to provide a "library" for a service I write. I have no idea how I'd pitch this to a boss to pay me to do it, but pretending that I could, I could see it being pretty interesting to do a message broker or something that worked entirely by "writing a file to a folder". That way you could easily use that broker from basically anything that has file IO, even something like bash.

I always have a dozen projects going on concurrently, so maybe I should add that one to the queue.

I built the original version in Python for a job years ago. But the version above is almost entirely vibe-coded in Rust in a lazy afternoon for fun.

However, I disagree that the filesystem is the right abstraction in general. It works for git, because git is essentially structured like a filesystem already.

More generally, filesystems are roughly equivalent to hierarchical databases, or at most graph databases. And while you can make that work, many collections of data are actually better organised and accessed by other means. See https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf for an particularly interesting and useful model that has found widespread application and success.

Also, looks like my message queue idea has already been done: https://github.com/pehrs/kafkafs

No new ideas under the sun I suppose.

If you don't do your homework, it's definitely a crapshoot with hardware compatibility, and of course that sucks if you're telling people that they should "switch to Linux" on their existing hardware, since they might have a bad experience.

That said, it is weird that people seem to have total amnesia for the rough edges of Windows, and I'm not convinced that Windows has fewer rough edges than Linux. I've grown a pretty strong hatred for Windows Update, and the System Restore and Automatic Repair tools that never work. Oh, and I really think that NTFS is showing its age now and wish that Microsoft would either restart effort on ReFS or port over ZFS to run on root.

[1] Before you give me shit for this, if anything breaks I agreed to be the one to fix it, and I find that generally I can solve these kinds of problems by just using tmate and logging into their command line which AFAIK doesn't have a direct easy analog in Windows.