Hot take: Static typing is often touted as the end all be all, and all you need to do is "parse, don't validate" at the edge of your program and everything is fine and dandy.
In practice, I find that staunch static typing proponents are often middle or junior engineeers that want to work with an idealised version of programming in their heads. In reality what you are looking for is "openness" and "consistency", because no amount of static typing will save you from poorly defined or optimised-too-early types that encode business logic constraints into programmatic types.
This is also why in practice alot of customer input ends up being passed as "strings" or have a raw copy + parsed copy, because business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program.
> no amount of static typing will save you from poorly defined or optimised-too-early types that encode business logic constraints into programmatic types.
That's not a fault of type systems, though.
> because business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program
That's a problem with overly-tight coupling, poor design, and poor planning, not type systems
> In practice, I find that staunch static typing proponents are often middle or junior engineeers
I find people become enthusiastic about it around intermediate stages in their career, and they sometimes embrace it in ways that can be a bit rigid and over-zealous, but again it isn't a problem with type systems
> overly-tight coupling, poor design, and poor planning
yeah imagine if you could foresee the future five years in advance. People overestimate their ability to use type systems correctly, as shown in your reply here.
> I find that staunch static typing proponents are often middle or junior engineeers
I wouldn't go this far as it depends on when the individual is at that phase of their career. The software world bounces between hype cycles for rigorous static typing and full on dynamic typing. Both options are painful.
I think what's more often the case is that engineers start off by experiencing one of these poles and then after getting burned by it they run to the other pole and become zealous. But at some point most engineers will come to realize that both options have their flaws and find their way to some middle ground between the two, and start to tune out the hype cycles.
This is such a tired take. The burden of using static types is incredibly minimal and makes it drastically simpler to redesign your program around changing business requirements while maintaining confidence in program behavior.
People keep saying this and yet in the decades of my career the industry bounces between being fully dynamic and fully typed according to the affordability of senior engineers. What you are saying are covered by tests, not types.
how does this square with very senior people putting in a lot of effort to bolt fairly good type systems onto Python and JavaScript?
> business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program.
I just don't understand how this is the case. Fields or methods or whatever are either there, or they are not. Type systems just expose that information. If you need to change the types later on, then change the types.
Example: Kotlin allows you to say "this field will never be null", and it also allows you to say "this field will either be null or not null". Java only allows the latter. If you want the latter in Kotlin, you can still just do that, and now you're able to communicate that (or the other option) to all of your callers.
Typed Python allows you to say "yeah this function returns Any, good luck!" and at least your callers know that. It also allows you to say "this function always returns a str".
"good type systems" in Python and Javascript has a escape hatch via dicts/objects, and are frankly, not "good" compared to FP via haskell etc, but it is realistic, reliable, open and consistent, which is exactly my point!
You could spend more time understanding Pydantic before you make this comment however.
python, js, ruby, clojure, erlang etc are created by senior engineers who are fully aware that haskell etc exists, so have you considered that people you claim are "senior" aren't senior enough?
> static types are not about “classifying the world” or pinning down the structure of every value in a system. The reality is that static type systems allow specifying exactly how much a component needs to know about the structure of its inputs, and conversely, how much it doesn’t.
The most useful thing juniors can do now is use AI to rapidly get up to the speed with the new skill floor. Learn like crazy. Self learning is empowered by AI.
AI has a lot of potential as a personal, always on teaching assistant.
It's also an 'skip intro' button for the friction that comes with learning.
You're getting a bug? just ask the thing rather than spending time figuring it out. You don't know how to start a project from scratch? ask for scaffolding. Your first boss asks for a ticket? Better not to screw up, hand it to the machine just to be safe.
If those temptations are avoided you can progress, but I'm not sure that lots of people will succeed. Furthermore, will people be afforded that space to be slow, when their colleagues are going at 5x?
Modern life offers little hope. We're all using uber eats to avoid the friction of cooking, tinder to avoid the awkwardness of a club, and so on. Frictionless tends to win.
Why not just let the product manager use some no-code tool?
I think software engineers are having an identity disconnect from their roles as engineers vs coders. Engineering is about solving problems via tools and knowledge through constraints. An engineer is not diminished by having other engineers or better tooling as assistants. If you are having problems understanding your role in the problem, frankly you need to review your skillset and adjust.
You are correct in the abstract, but concretely I contest how useful LLMs are for producing software. I don't doubt their usefulness in prototyping or, say, writing web apps, but I truly do not think they are revolutionary for me, or for software development as a whole.
I hate that he is right. It speaks deeply about how broken the incentives are for humanity and labour and why AI will ultimately destroy jobs, because AI won't need to deal with all the sacred rituals around politics and control and human management. For each stupidity that we worship just to "preserve company culture", we step into the inevitable doom like having a Google principal engineer worship Opus on X like it's the first time they went to prom and saw someone hot.
It is sickening and it is something we have internalized and we will have destroyed ourselves before we settle on the new culture of requesting excellence and clarity beyond the engineers who have to deal with this mess.
IMO context poisoning is only fatal when you can't see what's going on (eg black box memory systems like ChatGPT memory). The memory system used in the OP is fully white box - you can see every raw LLM request (and see exactly how the memory influenced the final prompt payload).
the core problem is that language/library authors need to provide some way to bridge between different execution contexts, like containing these different contexts (sync / async) under FSMs and then providing some sort of communication channel between both.
This would generally just discourage open software in general. Rebble is a non-profit and should not pretend to "own" any software or content. Eric didn't do things the polite way, but either way there's nothing to discuss here. Claiming that someone can steal something that is open source implies that they own said open source code / content. that's not how any of this works.
Reselling open source content is always going to be bad taste.
In practice, I find that staunch static typing proponents are often middle or junior engineeers that want to work with an idealised version of programming in their heads. In reality what you are looking for is "openness" and "consistency", because no amount of static typing will save you from poorly defined or optimised-too-early types that encode business logic constraints into programmatic types.
This is also why in practice alot of customer input ends up being passed as "strings" or have a raw copy + parsed copy, because business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program.
reply