Writing that changed how I think about programming languages

I opine that typeless languages are best for short programs, because one can understand 100% of the program. Typed languages are a way to manage the complexity of a larger program.

For a related example, the BASIC programming language is great for programs that fit in 24 lines (which is how many lines a glass tty displayed).

Static typing lets you build very large rigid structures where types ensure constraints. However, these constraints get in the way of moving quickly. If you change a signature of a function, you have to first change every piece of code that calls the function. You then have to compile, restart your program, rebuild the whole rigid structure, and confirm the change works as expected. This whole process can take many minutes. The claim is that catching these errors at compile time results in more reliable code.

Dynamic typing has no such constraints to help you catch errors at compile time. Dynamic typing allows you to build organic structures that more fluidly change. If you change a function signature, you don't have to change every piece of code that calls the function. You can change the function and test it in a running application without restarting the application. Doing this takes seconds. Dynamic typing allows you to iterate 100x faster. Being able to rapidly iterate often means better tested code and more reliable code.

Both are valuable. Dynamic typing is valuable during development when you need to iterate rapidly and build a prototype when requirements are often changing. Static typing is valuable when code need is more mature, changing less frequently, and code needs to be put in production.

Ideally you have both. More mature parts of the program are statically typed and more fluid parts of the program are dynamically typed.

> It's better to guarantee we encounter all type errors before the program even runs.

This is only valid if you either are writing mission-critical software, or have infinite time.

Your argument doesn’t consider the case that you have a deadline and need to ship, so optimising for productivity, rather than asymptotic typing perfection, is paramount. There is a reason even performance-critical environments, where scripting languages are not very well suited, somehow still lean on them for productivity.

Case in point, game dev (Unreal Engine with its blueprint system, Godot with GDScript, the myriad of game engines in C++ paired with Lua.) Of course in a vacuum game devs would like to write ideal data structures with strong typing so that the game doesn’t crash, but their goal is to ship a game within the decade, so limit the strong typing to performance critical engine and can focus on building and iterating on the core product without consulting type theory books.

The point of Mr. Ousterhout’s argument is that there are only two choices: either we invent the panacea, the mythical productive strong-typed language that gives 100% safety yet enables experimentation, optional typing and compiles to C++ speed native code, or we accept that this is an impossible pipe dream, and we need to use the correct tool for the problem. Again, obvious on the surface, but still a contentious point to this day.

> Ousterhout's view was colored by his limited experience

Wow… If he has limited experience, I better go doing something else…

What I've never understood about this argument is this:

How often are you passing around data that you don't fully understand?

Also, people use types and then end up reaching for reflection to perform pattern matching on types at which point you've just moved the typing from the user level to a type system. Not much gained imo.

But some languages DO have less restrictions. There's a lot less I have to worry about with Python than the quagmire of Java. You may say I'm putting something off (and maybe I am), but that is perfectly reasonable in a lot of scripting use cases.

> 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.

Unless you're implementing something that's already known, you're effectively carving out your problem when you're in the process of writing code. There are more unknowns than there are knowns. A strongly typed language forces you to focus on satisfying the types before you can do anything, at a point where you don't exactly yet know what you want to do. The right time to cast your data rigidly into types is gradually when your data structures settle in their own place one by one; in other words when you're pretty sure things won't change too easily anymore. This allows writing code that works first and then, depending on your needs, gets next correct and then fast, or next fast and then correct. You use the weakly typed or "typeless" style as a prototyping tool that generates snippets of solid code that you can then typefy and write down for good.

Languages introduce restrictions of their own all the time. In Java I can't have a function that works on any type of number, I have to specify the type. In Haskell I can. In Haskell I can't put random stuff in a list, in Java I can as long as they are all objects.

Those language restrictions slow down your development as you have to design and code around them. People see the extra design\code as a good trade off because it improves safety, but it slows you down if you are just messing around.

>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.

Click the comment timestamp and use the favourite link to add it to your favourites, accessible from your profile page.

Click the time (next to the author) to go to a page for the comment, where you will be able to favorite it.

You say that, but if there's one thing I wish more mid-level engineers understood better about good code it's the distinction between simple and easy.

Oh cool, thank you so much!!