Hacker News Reader

Comment by mordocai | Hacker News Reader

The author's stated reasons for why dynamic languages are used may be valid (I use them because the type of job I like to get usually does) but there are real advantages to them.

It is much easier to quickly prototype or experiment in a dynamic language. Note that I am thinking versus a language like Scala or Haskell where types are a integral part of the language. This applies less to languages like Java. You don't have to stop and figure out your types for every function and then go back and change them every time you figure out there is a better way to represent the data.

That being said, I get their 'Dynamic Languages really just have one type' argument. I understand what they are saying. Doesn't mean we can't still use the term dynamic to describe such languages. Words mean whatever we(as a group) want them to mean.

View on HN

"It is much easier to quickly prototype or experiment in a dynamic language."

I disagree. I can say what I mean with types, and if I didn't mean what I said, refactoring is a breeze.

"You don't have to stop and figure out your types for every function and then go back and change them every time you figure out there is a better way to represent the data."

You don't have to do this in languages like Haskell either. Type inference will help you most of the time when figuring out a function's type, and you don't have to use the type system as it was intended at first. You can have a prototype with Strings and Lists, the compiler won't be able to help you much though.

While Haskel has quite a few tools to help assuage issues like this, I can't help but think that niche tools do not define the genre. When I hear "statically typed", I don't think of Haskel, I think of C, C++, Go, Java, and Rust.

All of these languages offer tools to handle similar duck typing via interfaces or traits or polymorphism, but they are far from simple to use.

When Haskel gains a mindshare outside of its current niche, or the type inference becomes more broadly implemented in languages used across our industry, then let's talk about how it makes statically typed languages better and easier to use than "unityped" languages.

> I can say what I mean with types

This is one of those things that is perhaps true in theory, but often falls short in practice. Static type systems tend to require (more or less frequent) additional incantations, but may not be sufficiently-express, even with those incantations, to express the desired intent.

(Or, the required complexity of the incantations may be a greater cognitive workload than actually writing the functional code.)

> You don't have to do this in languages like Haskell either.

Most static languages -- particularly, the ones with the strongest standard libraries and ecosystems that are likely to support whatever it is you are doing -- aren't like Haskell.

> You don't have to stop and figure out your types for every function and then go back and change them every time you figure out there is a better way to represent the data.

Hmm, if you change your data representation from an array to a dict, say, don't you anyway need to go back and change code in every function that accesses this data?

Frequently the answer is no, you don't need to change every function. If you're iterating through values, are obtaining the lookup value outside the function, or just passing it along, no changes are necessary.

Compared with your average statically typed language, you do have to update the function signature and everything that calls it.

Now then, admittedly, Haskel is not your average statically typed language - but then again it's very rare to actually run up against Haskel in production code.

> iterating through values

I don't think you can iterate thought the values in an array and in a dict in e.g. python with the exactly same syntax.

> just passing it along

In languages with global type inference (e.g. OCaml) you would not have written the type in the code in the first place, so changing the type of an argument that you just pass through, would not require any changes in the code.

But yes, in Haskell people are in the habit of writing the type signatures, even though the compiler does not require them, so in this case edits are needed.

> I don't think you can iterate thought the values in an array and in a dict in e.g. python with the exactly same syntax.

That depends on what you mean by "values". The default iterator over dictionaries in python iterates over the keys, so if you use the exact same syntax as iterating over members of a list you iterate over the keys of a dictionary, not what are usually called the values (there is a separate iterate for that, and for key/value pairs). But, yes, dicts and lists are iterable via the same syntax since they both support Pythons iteration protocol.

I think the author of the article is unreasonably upset about dynamic languages. It is, ironically, restrictive to only use the most static of languages. Dynamic languages are fun to!

10,000 lines of bubblegum and chicken wire is not fun. At all.

I never said you should be building 10,000 line apps in python, nor passed any value judgment. All I was implying is that sometimes it is just fun to use different sorts of languages.

I can't imagine how you are deriving an emotional state from that post.

Type inference in static languages eliminate 90% of the advantages of dynamic languages including being easier to quickly prototype or experiment.

Reply on news.ycombinator.com