Hacker News Reader

Comment by jblow | Hacker News Reader

"...calcify and ossify data structures and types..."

What are you even talking about? This sounds like an assertion from someone who doesn't use statically-typed languages and is just guessing.

To change a data structure in a statically-typed language, you change the declaration then fix any compile errors. It is easy in most cases.

In a dynamically-typed system, data structures actually get way more ossified, because when you change a structure you don't really know what might be broken or when you are really done making the code correct again... Therefore programmers avoid this.

View on HN

I feel we're getting into strawman assertion territory here.

I've worked with statically typed and dynamically typed languages, and the fact is that there's some overhead involved in static typing. You pay that overhead upfront in order to hopefully prevent some bugs (and possibly get a performance boost) later on.

If you haven't tried both, you probably won't notice the mental overhead.

I've also found that this difference sometimes result in people approaching things differently, with static typing leaning itself more to specifying things upfront compared to jumping straight into the code with dynamic typing.

Sometimes this surely means things end up being clearer with static typing, but I've also seen the reverse happen, more often than you'd think, because some kinds of code have a lot of messy little details - with a dynamic language like Python you can model, or perhaps rather avoid modeling, those little local details by just stuffing things onto something you're already passing along, while the static typer would have to think harder about how to fit them in without polluting the overall data structures.

When you're rewriting things a couple of times as your understanding of the problem evolves, it can certainly help to be able to not worry too much about those details.

Oh, I've tried both all right!

There is more mental overhead in dynamically-typed languages, actually .. it's just less visible because it's implicit! It's the overhead of having to "keep all the type information in your head", which dynamic type proponents sometimes seem to be saying is a good thing.

It's not good because it is a tax on everything you do! Whereas in a statically-typed language, sure, you have to do the little extra overhead of putting the types in the program text, but this is quite freeing in the long term, because you can then drop the burden of having to think about what type something needs to be, in most cases.

(It also serves as documentation / literate programming.)

My approach to programming tends to involve rewriting things several times, or heavily modifying them, and as someone who has been programming for 34 years, in a lot of different situations, I find that static typechecking is by far a superior framework when refactoring or rewriting code. It is not even close.

I'm firmly on the static typing side of the fence. But I think you're ignoring what others are saying about where dynamic typing shines: Where you don't know what you're doing to the point that you don't know what the proper types look like. You can try things faster in a dynamic language in that situation, because you can sweep the "don't know what the types look like" part under the rug, and experiment with algorithms, and let that experimentation show you what the types ought to be. In some situations, that can be faster/easier/better than trying, from first principles and analysis, to determine what the types must be.

I think the difference is that I (and, I suspect, you) spend little of our time in that mode, and much more in the mode where static types can save your behind. (Nothing like working on a million-line code base in its second decade to make you value static types.)

Sometimes you know what the types look like but not in detail. For instance, you know you need a structure with several named properties, but you don't commit to a type for some of them. You can have a fairly deep idea about the object model: what kinds of classes there are and how they connect, yet be loose about some of the lower level details.

You have types in the dynamic realm. Only, you're not restricted to executing nothing but consistently typed programs.

No, this is how I program all the time. Usually when I start typing I have only a rough idea of what I want to do.

But in practice this is not a problem. So what if I don't know exactly what type a particular thing will be in the end -- I know generally if it is a number, or an array/list, or a hash/index... that is all I need to know. I use one of those basic types. If I need to change it later I change it later, and the fact that I am in a statically-typed language is great for changes like this because it helps me make them with high confidence.

This is why I don't believe that anyone who makes this argument in favor of dynamic languages really has that much experience in static languages. The actual outcome in real life is the opposite of what is described.

You still have to keep type information in your head when working with static programs. Compiling isn't all that you do with programs.

Not every expression in a program is rife with explicitly visible type. Not even in a language with declarations for all storage locations. Type inference seeks to minimize that, because it's considered clutter.

However, the completely clutter-free static program looks much like a dynamic one! If I look at some snippet of OCaml or what have you, for all I know it could be dynamic.

The difference is that it's constrained in invisible ways. (If it is already correct in its current form) it cannot be changed in certain ways and still be accepted for execution.

That doesn't mean a thing to me when I'm just looking at it trying to understand it. I have to figure out what the types are, and connect all the pieces in my head.

In a statically-typed language with reasonable tools you can right-click on an expression and see what type it is. This whole thing you're describing is a non-issue.

> To change a data structure in a statically-typed language, you change the declaration then fix any compile errors. It is easy in most cases.

Right. This can become an overhead in a rapidly evolving design because every small type change has implications across the codebase. With dynamic typing, you only need to fix the code paths you are currently interested in and development is very focussed in a way - you don't have to shuffle all parts of the code through your mental caches. This way you can iterate over a few revisions to the types without having to 'fix everything' each time. Finally when you're happy, you go ahead and fix the other dependent code. Admittedly, dynamic languages may not help you find the code that needs fixing. This problem is somewhat mitigated by tests.

> you change the declaration then fix any compile errors.

In all 3123 places in the code base; good luck.

This sounds like ... an assertion from someone who doesn't do actual software engineering.

Back at you!

> you don't really know what might be broken

Because you don't have a regression test suite, a test plan, and four developers to one QA person.

> Therefore programmers avoid this.

Programmers bravely avoid nothing. Historically, programmers have gotten themselves into every imaginable mess with every type of language.

Reply on news.ycombinator.com