It's not just about skill. It's about maintainability, ease of refactor, and modeling invariants in your code in a way that they can be checked by the machine (the compiler) without every single developer having to maintain them in their head.
Clojure even knows this is an issue and many people use `spec` to sort of retrofit static typing.
Dynamic typing was, is and always will be a mistake. There is nothing you can do with dynamic typing that you cannot do with a sufficiently powerful static type system - and it doesn't have to be something absurd like Haskell's. You basically just need structural typing and type inference and some type-level programming constructs.
The worst part about Clojure is the community. Rich Hickey has cult-like status and the only thing clojurians can do is parrot his inane commentary.
I too agree that "until you get better" isn't a good take. To err is human, and even the most experienced developers make mistakes.
That said, you don't get static typing for free. As with many things it's a trade-off: you catch some errors at compile time in exchange for working within the confines of the type system. The ultimate hope is that the time you spend fiddling with types is going to be less than the time you spend debugging type errors.
> There is nothing you can do with dynamic typing that you cannot do with a sufficiently powerful static type system - and it doesn't have to be something absurd like Haskell's. You basically just need structural typing and type inference and some type-level programming constructs.
Haskell doesn't have a complex type system for no reason; it's necessary to encompass everything it wishes to do, and even then it's not as flexible as a dynamically typed language.
For instance, how would you statically type Clojure's `assoc` function? It's not at all trivial if you want to retain the type information of the keys and values.
The problem with your counter-argument is that it hinges on a false premise: That you need or even want a function like `assoc` which is polymorphic over everything. It's an extremely overloaded function which does a lot of things at once, and in many circles and arguably in general within the realm of software design, this is considered a smell.
In practice, what you want is something that allows you to do this safely for the concrete type you're working with. If you want an abstraction that covers all of it, there are ways to achieve this in a type-safe manner, such as traits/type classes. Even in clojure, you're not working with everything at once all the time. You are working with a record, or a vector, or whatever. The fact that you can use one function for all of them is mostly just needless cleverness. In Clojure, you have to keep the type of the data you are working with in your head at all times, because even though `assoc` "just works" for many cases, that's not true in all cases. It will happily insert an integer key into a record without issue, which may or may not be waht you want. But you can also try to insert an atom key into a vector, which then crashes loudly. This is clearly an asymmetry in the abstraction.
Moreover, pointing out that Haskell cannot do what you'd want to do in this case doesn't make a lot of sense. I mentioned Haskell precisely because its type system is extremely powerful and complicated to understand for a lot of people, but still doesn't achieve the kind of flexibility we are looking for - it lacks row polymorphism.
To answer your actual question: Typing a function like that for the individual cases is bordering on trivial in a language such as typescript. For the record case, you don't even need it, because in practice, you get the correct type inference for free by just spreading one object into another.
I don't see an asymmetry in the abstraction. Both vectors and maps are associative structures - you can assign a key to a value - the only difference is that vectors have a more constrained keyspace (i.e. ordered, consecutive integers starting from zero).
But that wasn't really my point. Even if we limit `assoc` solely to maps it would still be difficult to type effectively.
For instance, suppose we have some code like:
(let [m* (assoc m :number 3)]
(:number m*))
We can see that the return type of this expression is obviously an integer, but what is the type of m*? How do we type m* such that (:number m*) can be inferred to be an integer by the compiler?
Most statically typed languages sidestep this problem: instead of using an open data structure like a map, a closed structure like a record or class is used instead, and these structures must be explicitly typed by the user.
The problem with this approach is that now every record is specific and bespoke. You lose access to all the general-purpose functions that operate on generic data structures, and as records and classes are closed, you also lose the ability to extend them.
This is the ultimate problem with static type systems: you're trading capability for safety. If you're programming within a static type system, there are options that are simply not available or feasible to use.
> I don't see an asymmetry in the abstraction. Both vectors and maps are associative structures - you can assign a key to a value - the only difference is that vectors have a more constrained keyspace (i.e. ordered, consecutive integers starting from zero).
The asymmetry lies in the fact that it's an overloaded function that's supposed to do the right things every time, but in some cases, it does what is arguably the wrong thing, silently, and in others, it refuses to do the wrong thing and fails loudly. It's better that it fails loudly, of course, but the point is that the ergonomics of the abstraction is lessened because you can't just assume it will work. You effectively have to keep the types of all the things involved in your head and/or trace them to ensure that you don't run into a crash.
> We can see that the return type of this expression is obviously an integer, but what is the type of m? How do we type m such that (:number m*) can be inferred to be an integer by the compiler?
> This is the ultimate problem with static type systems: you're trading capability for safety. If you're programming within a static type system, there are options that are simply not available or feasible to use.
This is just not true. It's true for some certain specific static type systems, but not true in general, and that brings me back to my original thesis: You just need a sufficiently capable type system with the right properties - structural/row polymorphism, ish, plus type inference. And also my Haskell point: it doesn't have to be an incredibly complicated type system that is beyond mortal ken. TypeScript is already doing this and it's arguably one of the most used programming languages on earth.
> You effectively have to keep the types of all the things involved in your head and/or trace them to ensure that you don't run into a crash.
You make this sound difficult, but in practice type errors are rare in Clojure and generally caught in the REPL or by tests, since the moment you go down a branch with a type error an exception is thrown.
Contrast this to errors caused via mutable state, which are usually far harder to track down, because the failure condition is more specific.
> This is trivial in TypeScript.
In the example you give you're omitting assoc entirely, which defeats the point. I'm using assoc as a minimal example, but the same principle applies to more complex functions, so replacing assoc with the equivalent expression doesn't tell us whether or not we can effectively type a function that deals with maps.
So lets try doing this properly. At minimum we need something like this:
type Assoc<M extends object, K extends string, V> =
Omit<M, K> & Record<K, V>;
function assoc<M extends object, K extends string, V>(
m: M, k: K, v: V): Assoc<M, K, V> {
return { ...m, [k]: v } as Assoc<M, K, V>;
}
(Note that we need to perform an explicit cast in order to inform TypeScript of the type of the key.)
However, this produces some rather messy types consisting of nested Assocs. In order to get back to something a human can read, we can use an additional Simplify type to force the type system to reduce it back down into an typed object:
type Simplify<T> = {[K in keyof T]: T[K]} & {};
type Assoc<M extends object, K extends string, V> =
Simplify<Omit<M, K> & Record<K, V>>;
function assoc<M extends object, K extends string, V>(
m: M, k: K, v: V): Assoc<M, K, V> {
return { ...m, [k]: v } as Assoc<M, K, V>;
}
(The empty `& {}` intersection forces normalization, providing a cleaner reported type.)
We're still not done, though, as if we want the same type checking that a class has, we need to ensure that a key cannot be overwritten with a value of a differing type. So we'll type the value argument as well to ensure it matches the type of an existing value within the map:
type Simplify<T> = {[K in keyof T]: T[K]} & {};
type Assoc<M extends object, K extends string, V> =
Simplify<M & Record<K, V>>;
type AssocValue<M extends object, K extends string, V> =
K extends keyof M ? (V extends M[K] ? V : never) : V;
function assoc<M extends object, K extends string, V>(
m: M, k: K, v: AssocValue<M, K, V>): Assoc<M, K, V> {
return { ...m, [k]: v } as Assoc<M, K, V>;
}
So this is possible to type in TypeScript (to its credit), but is it "trivial"? And is this type signature significantly less complex than one might find in Haskell?
It's not about "knowing" anything. It's about admitting that humans are fallible meat computers that can't hold invariants in their head across thousands or millions of lines of code and possibly an exponential number of interactions. It's using the technology we are capable of building to help us because it's the obvious thing to do. The notion of dynamic typing as an attractive programming model hinges entirely on the hypothesis that it lets you somehow express things that you need or want to be able to express that static typing prevents you from doing, and that is demonstrably false. The `assoc` example above is a perfect example.
The problem with these concepts is a) they are completely opaque to the common chud programmer and b) they are just not available to people in languages that anyone actually uses. There are a bunch of effect libraries in Haskell, even special efforts to make them work better in GHC, but it's nearly all wasted effort because it's just academic circlejerk.
Effect brings these capabilities to the masses by implementing them in the most popular programming language on the planet. Obviously, there is quite a learning curve -- it is essentially a programming language unto its own inside another programming language -- but it's doable. I've onboarded juniors with close to 0 FP experience into an Effect codebase. The guardrails help a lot. The language server which helps with best practices, the type errors themselves help quite a lot.
Arguably the best way to do Effect would be a separate programming language, but that would just give us the problems Haskell has: nobody would use since there would be no ecosystem, and there will be no ecosystem since nobody would use it.
Global state is bad because it makes it hard to reason about your system. The global state can affect any part of it, or, focusing on the inverse which is probably better applied to global styles, any part of your system can depend on the global state.
It's also weird to say "global styles are not mutable" - you're right, they're (generally) not mutable, at runtime. But they are mutable in the sense that your developers (you, or your colleagues, or someone in 3 years maintaining your code) can mutate them, and if large parts of your system are implicitly dependent on the CSS cascading properly and so on, then those changes can have unintended consequences.
Of course, that can also apply to tailwind, to some extent. A developer can change a class (custom or otherwise) or the configuration - but at least it is very clear what is being changed and what parts will be affected (just grep).
With CSS unintended consequences are always problems of scoping things better. If I give semantically meaningful CSS classes to my semantic HTML and scope my rules to apply to their intended place in the pages, then unintended consequences don't happen. If I roll like: "Oh, I want this list to look differently, lets make a global scope ul/ol style!" then I am asking for trouble later on. When I write a CSS rule, I should always be thinking about the scope and whether my rules are truly something universally applicable to that scope.
The problem with this dev's approach is not AI, it's their use of it. They didn't ensure that the architecture made sense. They didn't look at the code and get a "feel" for it. They didn't do the whole build stuff, step back, refactor, rinse and repeat dance. The need for that hasn't gone away; if anything, it's even more important now. Because you can spit out code 100x faster than you could before, your tech debt compounds 100x faster. The earlier you refactor, the less work it is.
I usually give the agent a solid idea of what I want, often down to the API interfaces. Then every now and then, I'll go through the code and ensure that everything makes sense, and that I'm not just spitting out code that works, but building a codebase that scales.
As much as I also enjoyed the actual coding part, a lot of it is just .. boring plumbing. I enjoy solving the problems - designing the solutions, the algorithms, choosing the right tech, coming up with nice abstractions.
When doing agentic development, you need to be in control, at least for now. Every frontier model will still do incredibly stupid stuff, and if you let it cook unchallenged, you'll have a codebase that doesn't scale. Claude will happily keep piling turds upon your tower of turds, but at some point, even an LLM will have a hard time working in it.
When you are at the wheel, the engineering hasn't changed. You're still solving all the same problems, but you can iterate a lot faster. Code is now ~free, and the cost of having a bad idea is now much cheaper, because you can quite literally speak the solution out loud and fix it in a few minutes.
I have tons of experience with python, possibly more actual work experience than any other language, and I do think the indentation is a bit of a problem. Obviously not a huge one, but still something I wished they had done differently. Because I like to have a robust format-on-save wired into my editor, and you just cannot quite have that when indentation is meaningful.
I must admit that I’ve tried python in my early days and indentation was the main reason why I just didn’t pursue the language further. It felt just brittle and hard to read.
Of course if I had be forced I would have probably managed to master it but I had the freedom to use whatever I wanted as programming language and python was just not an attractive option.(despite being seduced by its “zen” and all that. Felt like form over function design.
The “build”/run/deploy system was the other major issue. All the python versions, virtual env etc seemed like a mess. A compiled language is so much better(I.e Go, Rust etc) IMHO.
Yes, I remember having a problem with python indentation. For some reason tabs and spaces were causing my code to fail to run!!
This was when I was first learning programming and didn't know anything. Once I understood the syntax of the language it hasn't been a problem ever since.
Its like being upset that your yaml doesn't work because you have mixed spaces and tabs.
It's not just about skill. It's about maintainability, ease of refactor, and modeling invariants in your code in a way that they can be checked by the machine (the compiler) without every single developer having to maintain them in their head.
Clojure even knows this is an issue and many people use `spec` to sort of retrofit static typing.
Dynamic typing was, is and always will be a mistake. There is nothing you can do with dynamic typing that you cannot do with a sufficiently powerful static type system - and it doesn't have to be something absurd like Haskell's. You basically just need structural typing and type inference and some type-level programming constructs.
The worst part about Clojure is the community. Rich Hickey has cult-like status and the only thing clojurians can do is parrot his inane commentary.
reply