Holy shit you’re right, I’m an idiot. Thanks for helping me shift my perspective.

If you didn’t have an agenda/preconceived idea you wanted proven, you’d understand that a single study has never been used by any credible scientist to say anything is proven, ever.

Only people who don’t understand how data works will say a single study from a single university proves anything, let alone anything about a model trained on billions of parameters across a field as broad as “programming”.

I could feed GPT “programming” tasks that I know it would fail on 100% of the time. I also could feed it “programming” tasks I know it would succeed on 100% of the time. If you think LLMs have nothing to offer programmers, you have no idea how to use them. I’ve been successfully using GPT4T for months now, and it’s been very good. It’s better in static environments where it can be fed compiler errors to fix itself continually (if you ever look at more than a headline about GPT performance you’d know there’s a substantial difference between zero-shot and 3-shot performance).

Bugs exist, but code heavily written by LLMs has not been proven to be any more or less buggy than code heavily written by junior devs. Our internal metrics have them within any reasonable margin of error (senior+GPT recently beating out senior+junior, but it’s been flipping back and forth), and senior+GPT tickets get done much faster. The downside is GPT doesn’t become a senior, where a junior does with years of training, though 2 years ago LLMs were at a 5th grade coding level on average, and going from 5th grade to surpassing college level and matching junior output is a massive feat, even if some luddites like yourself refuse to accept it.

In my line of work (programming) they absolutely do not have a 52% failure rate by any reasonable definition of the word “failure”. More than 9/10 times they’ll produce code at at least a junior level. It won’t be the best code, sometimes it’ll have trivial mistakes in it, but junior developers do the same thing.

The main issue is confidence, it’s essentially like having a junior developer that is way overconfident for 1/1000th of the cost. This is extremely manageable, and June 2024 is not the end all be all of LLMs. Even if LLMs only got worse, and this is the literal peak, it will still reshape entire industries. Junior developers cannot find a job, and with the massive reduction in junior devs we’ll see a massive reaction in senior devs down the line.

In the short term the same quality work will be done with far, far fewer programmers required. In 10-20 years time if we get literally no progress in the field of LLMs or other model architectures then yeah it’s going to be fucked. If there is advancement to the degree of replacing senior developers, then humans won’t be required anyway, and we’re still fucked (assuming we still live in a capitalist society). In a proper society less work would actually be a positive for humanity, but under capitalism less work is an existential threat to our existence.

I support creatives with direct donations. When you buy Netflix, you’re supporting extraordinarily wealthy capitalists.

If you actually care about supporting creatives, end all your subscriptions, pirate all your media, and give 100% of your previous subscription costs directly to the creatives you want to support.

Most people aren’t practicing teachers, so it makes sense that not all explanations are the best. Trying to get an intuitional understanding of passing by reference or passing by value in imperative languages is arguably more important than understanding how map works, and yet I’d argue it’s also harder to do.

If you understand map (not just lists, but futures, IOs, Options, Maybes, etc.) then you understand Functors. Yes there are laws, but mathematical laws here are just encoding our intuition. Something like Iterator in Java may not have laws, but you would expect that calling .next() doesn’t modify an SQL database, though it wouldn’t be a technically invalid implementation if it did. The same is not true for Functors. If you map over a List and the act of mapping each int to its double modified a database then you wouldn’t have a lawful functor. But that should make sense intuitionally without knowing the laws.

People in OO land are more happy to say they “understand” something if they generally get what the abstraction is going for. Do you know all the methods for Iterator/Iterable in Java? Even if you didn’t, you’d likely say you get the “point” of an Iterable. The bar for understanding things in the FP community is usually higher than just understanding the point of something.

This doesn’t mean FP is more complicated. Actually it kind of means it’s simpler, because it’s not unreasonable for people to totally understand what Functors are for all languages that implement them. The same is not true of Iterable/Iterator. There’s no way you’d have more than just an intuition about what Iterable is in a language you don’t know. I don’t program in Agda or Idris, but I know Functor in those languages are the same as Functor in Scala and Haskell. Same with Monad, Monoids, etc.

Haskell/Scala. Huge fan of pure functional programming. Here’s another comment I wrote about some FP-related things

I think the dislike for Functors/Monads/Monoids etc. is super overrated. I’m not a mathematician, but christ these are beautiful abstractions coming from a background in Java and OO programming.

Functor instances are defined by one function. Once you learn the one main thing that Functors do (mapping), you’ll understand them no matter the language. Monoids have 2, Monads have 2, etc. Yes all there are functions built in terms of the functions required in the typeclass definitions (or several typeclasses), but they don’t need to be known to effectively use the abstractions.

I was able to easily transfer most of my Haskell knowledge to Scala at my last job in the typelevel ecosystem because of HKTs like Functors, Monads, monad comprehensions, Monoids, etc. I was the go-to guy for FP-related questions despite most of my background being in Haskell and not Scala.

Using an Iterable in Java will be different than an Iterable in any other language in at least some respects. Yes they will represent the same abstract idea, but you can’t just 1:1 transfer knowledge between different Iterable implementations.

I’ve programmed professionally in Java, Kotlin, Scala, Ruby, Python, JS/TS, and many more in hobbyist settings, and the cleanest transition was Haskell -> Scala (omitting language transitions on the same runtime, so Java -> Kotlin or JS -> TS).