Hacker News Reader

Comment by tikotus | Hacker News Reader

A bit tangential, but I believe dynamic vs static typing works the same. I switch quite often between them, and when ever I've had a longer break from dynamic typing, coming back to it feels quite heavy. "How did I ever do this?" It feels so heavy.

But a few hours (or days) in, I forget what the problem was. A part of my brain wakes up. I start thinking about what I'm passing around, I start recognizing the types from the context and names...

It's just a different way of thinking.

I recognized the same feeling after vibe coding for too long and taking back the steering wheel. I decided I'd never let go again.

View on HN

In dynamically typed programs, you can if you allow it, let the types happen to you. In a statically typed program, you are forced to think about them from the beginning. That same abstract concept is at play with vibe coding, but instead the code now happens to you.

My best LLM written code is where I did a prototype of the overall structure of the program and fed that structure along with the spec and the goal. It is kind of the cognitive bitter lesson, the more you think the better the outcome. Always bet on thinking.

I've used a dynamically typed language extensively. I don't think they are suited for anything but small scripts.

Refactoring is a nightmare, as as types don't exist, the compiler can't help you if you try to access a property that doesn't exist.

I think generally people have realised this, and there are attempts to retrofit types onto dynamically typed languages.

It bugs me that there are two kinds of languages. Parameters and variables could be typed optionally in a dynamic language; either error in the compiler or at runtime; otherwise you just haven’t made any type errors while you coded and the code is fine either way.

This is what gradual typing (such as TypeScript, or the use of Python annotations for type-checking) accomplishes. The issue is that it basically always is bolted on after the fact. I have faith that we aren't at the end of PL history, and won't be surprised if the next generation of languages integrate gradual typing more thoughtfully.

The problem with these two languages is that the runtime type system is completely different (and much weaker) than the compile time one; so that the only way to be safe is to statically type the whole program.

CL has a pretty anemic type system, but at least it does gradual without having to resort to this.

JavaScript caught on because it was the best casual language. They've been trying to weigh it down ever since with their endless workgroup functionality and build processes. If we get a next generation casual language, it'll have to come from some individual who wants it to happen.

No, JavaScript caught on because at the time it was the only game in town for writing web front-ends, and then people wanted it to run on the server side so that they could share code and training between front end and back end.

It's not enough to just be first. It would have been replaced by now if it wasn't fit for purpose. Otherwise we might as well not bother to critique anything.

To "realize" that it would have to be true. The longer I've stuck with untyped Python the more I've preferred it, and the more I've seen people tie themselves in knots trying to make the annotations do impossible (or at least difficult) things. (It also takes away bandwidth for metaprogramming with the annotations.)

A needlessly confrontational view. Some people do use dynamic typing as a way to stumble around until it works (e.g. most scientists) but some others simply don't want the noise associated with a static type system accurate enough to really say what you want; especially during prototyping/interactive use. Which is why gradual typing exists, really.

Same reason my views about GC evolved from "it's for people lacking rigour" to "that's true, but there's a second benefit: no interleaving of memory handling and business logic to hurt clarity".

Reply on news.ycombinator.com