Re:Writing that changed how I think about programming languages
by coldtea on Wednesday May 14, 2025 @10:47AM
(#43985197)
>We've come a long way, and examples have made clear that this dichotomy is a false one.
I wouldn't be so sure. Even Javascript, when is added types in the form of Typescript, looks more like the convoluted Windows API example and less like the TCL example.
>Let's talk about syntax. His exact Tcl code as presented could be parsed and compiled by a language that does static type analysis. It's not, because he's running it in an interpreter that only checks types at runtime. But the point is that whether code is compiled or interpreted is an implementation detail that has very little to do with the syntax.
Pedantically true. You can of course compile anything, including BASIC and TCL, or intepret C++ if you wished so.
But to really take advantage of compilation, languages tend to add types and other annotations or semantic constructs (like Haskell does). And so compiled languages tend to a certain syntax/semantics, and interpreted languages to another.
>And types: he claims that 'typeless' languages allow for faster development because of fewer restrictions. This is, ofc, nonsense. The amount of restrictions you have is a function of your problem, not your language. If it feels like dynamic typing is letting you develop faster, that's because you're putting off encountering those restrictions til later.
So it's not "nonsense", but rather a tradeoff, just like Ousterhout puts it.
For many, it is much faster to "putting off encountering those restrictions til later", as that's a large part of exploring the problem space.
See, while "the amount of restrictions you have is a function of your problem", you don't always know your exact problem, its boundaries, and the form you'll use to solve it, until you've experimented and played with early prototype solutions and changed them, etc. While doing so, having to tackle hard restrictions based on assumptions that can and will change or be discarded, slows you down.
>It's better to guarantee we encounter all type errors before the program even runs.
Only if it doesn't entail other issues, like it making our exploratory programming to end up with a design for our program slower and more tedious.
I wouldn't be so sure. Even Javascript, when is added types in the form of Typescript, looks more like the convoluted Windows API example and less like the TCL example.
>Let's talk about syntax. His exact Tcl code as presented could be parsed and compiled by a language that does static type analysis. It's not, because he's running it in an interpreter that only checks types at runtime. But the point is that whether code is compiled or interpreted is an implementation detail that has very little to do with the syntax.
Pedantically true. You can of course compile anything, including BASIC and TCL, or intepret C++ if you wished so.
But to really take advantage of compilation, languages tend to add types and other annotations or semantic constructs (like Haskell does). And so compiled languages tend to a certain syntax/semantics, and interpreted languages to another.
>And types: he claims that 'typeless' languages allow for faster development because of fewer restrictions. This is, ofc, nonsense. The amount of restrictions you have is a function of your problem, not your language. If it feels like dynamic typing is letting you develop faster, that's because you're putting off encountering those restrictions til later.
So it's not "nonsense", but rather a tradeoff, just like Ousterhout puts it.
For many, it is much faster to "putting off encountering those restrictions til later", as that's a large part of exploring the problem space.
See, while "the amount of restrictions you have is a function of your problem", you don't always know your exact problem, its boundaries, and the form you'll use to solve it, until you've experimented and played with early prototype solutions and changed them, etc. While doing so, having to tackle hard restrictions based on assumptions that can and will change or be discarded, slows you down.
>It's better to guarantee we encounter all type errors before the program even runs.
Only if it doesn't entail other issues, like it making our exploratory programming to end up with a design for our program slower and more tedious.