mightybyte

2 ay öncediscuss

Haskell gives you quite a powerful set of tools for constraining and reasoning about your program's behavior. For instance, its ability to define pure functions and control side effects is a very powerful tool for preventing certain classes of bugs. Dereferencing invalid pointer locations and out of bounds array lookups are large classes of bugs in mainstream languages that Haskell basically eliminates entirely. It's not at all the same thing as what you get from the type systems in languages like Java, C++, etc. You really have to try it to appreciate it.

mightybyte

2 ay öncediscuss

How much code do you think is necessary for LLMs to be good enough?

mightybyte

4 ay öncediscuss

One plausible future I can see from here is that we see a shift in our relationship to code in high-level languages that is similar to what happened with code written in assembly language back when the first high level languages were introduced. Before them, software engineers operated in assembly language. They cared about the structure of assembly code. This happened before I started my professional software career, but I can imagine that a lot of the same things we are hearing from developers today were heard back then. Concern about devs producing code they didn't understand, the generated assembly not being meant to be understood by others, etc etc.

Now, however, we know how that played out in the case of assembly language. The fact of the matter is that only a very tiny fraction of software engineers give the structure of the compiled assembly code even passing thought. Our ability to generate assembly code is so great that we don't care about the end result. We only care about its properties...i.e. that it runs efficiently enough and does what we want. I could easily see the AI software development revolution ending up the same way. Does it really matter if the code generated by AI agents is DRY and has good design if we can easily recreate it from scratch in a matter of minutes/hours? As much as I love the craft and process of creating a beautiful codebase, I think we have to seriously consider and plan for a future where that approach is dramatically less efficient than other AI-enabled approaches.

mightybyte

5 ay öncediscuss

Hmmm, I used OpenCode for awhile and didn't have this experience. I felt like OpenCode was the better experience.

mightybyte

5 ay öncediscuss

I have been unable to use OpenCode with my Claude Max subscription. It worked for awhile, but then it seems like Anthropic started blocking it.

mightybyte

5 ay öncediscuss

The thing that annoys me most of all is they block me from using OpenCode with my Claude Max plan. I find the OpenCode UI to be meaningfully better than Claude Code's, so this is really annoying.

mightybyte

6 ay öncediscuss

This is why I think (at least given the current state of AI code generators) that senior engineers will benefit more from AI than less experienced engineers. I don't know exactly what the chart of experience (on the x-axis) and amount of productivity gain from AI (on the y-axis) will look like, but I'm pretty sure it will be roughly (given suitable error bars around the input) a monotonically increasing function.

mightybyte

6 ay öncediscuss

Sounds like this should live in Wikipedia somewhere on https://en.wikipedia.org/wiki/Ellipse...or maybe a related but more CS focused related page.

mightybyte

6 ay öncediscuss

No, this is not at all a given. There could be switching costs that cause people to stay on a product that is actually worse. Users also simply might be unaware of alternatives or that they are better. It's not hard to imagine any number of other reasons why in our imperfect world there is not perfectly elastic competition.

mightybyte

6 ay öncediscuss

It also could happen because tech companies have optimized their products to maximize the amount of time that people spend on them, often in ways that directly result in a worse user experience (by showing ads instead of the most relevant search results, for example).

mightybyte

6 ay öncediscuss

The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. I'm not aware of any broadly accepted consensus definition. Sometimes people want to use this category to talk about purity and control of side effects and use the term "functional programming" to refer to that. I would advocate the more targeted term "pure functional programming" for that definition. But in general I try to avoid the term altogether, and instead talk about specific language features / capabilities.

mightybyte

6 ay öncediscuss

Was just talking with someone the other day who used to write Haskell professionally but is now using Python. He said that in his experience when there are bugs the "blast radius" is much larger in a dynamic language like Python than in a static language like Haskell. That has been my experience as well.

Something I haven't seen talked about, though, is how powerful the type system is for constraining LLMs when using them to generate code. I was recently trying to get LLMs to generate code for a pretty vague and complex task in Haskell. I wasn't having much luck until I defined a very clear set of types and organized them into a very clear and constrained interface that I asked the LLM to code to. Then the results were much better!

Sure, you can use these same techniques in less strongly typed languages like Rust, and you can probably also use a similar approach in dynamically typed languages, but Haskell's pure functions allow you to create much stronger guard rails constraining what kinds of code the LLM can write.

mightybyte

7 ay öncediscuss

He's also won the International Obfuscated C Code Contest 3 times.

https://www.ioccc.org/authors.html#Fabrice_Bellard

mightybyte

10 ay öncediscuss

One of my favorite pieces on this topic is this talk "Stop Treading Water: Learning to Learn":

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

mightybyte

5 yıl öncediscuss

The author wrote follow-up book called The Dichotomy of Leadership specifically to address the problem of people taking EO too far in one direction. But like my sibling comment mentions, I don't think you should blame the Gallagher problem on EO without clear evidence connecting the two. And even if you do, the follow-up book is there to clarify.

mightybyte

5 yıl öncediscuss

> I prefer using the word 'control' over fault, because fault has so many negative connotations.

Excellent point. I completely agree. I'll have to keep that in mind in the future.

mightybyte

5 yıl öncediscuss

Well said. The book Extreme Ownership has a slightly different take of what I think is basically the same idea. It opened my eyes to a new way of thinking about people above you in the organizational hierarchy and advocated taking ownership up the chain as well as down. Instead of asking yourself "why isn't my boss listening to me?", you should ask yourself how you are failing to communicate to your boss. Obviously things aren't entirely your fault all the time, but changing your ownership mentality is a tremendously empowering idea--especially when it goes in the opposite direction of traditionally perceived power vectors.

comments