Comment by eldavido | Hacker News Reader

Comment by eldavido | Hacker News Reader

Slightly meta, but: has anyone else noticed how much love languages with very strong type disciplines have been getting on HN recently? Scala, Haskell, Clojure, Go, Rust jump out.

Maybe language designers/toolmakers are getting better at bringing the benefits of stronger typing (superior editor support, faster execution times, less need for unit testing) without as much baggage: highly ceremonial code, complex compiler setup/tooling, etc? I suspect editor/compiler-level type inference, where you can do things like "val x = NewVal()" vs. "NewVal x = new NewVal()" might have something to do with it.

As someone who's swung back and forth across this divide, I get the sense that modern static language development is much less of a pain in the ass than it was 10yrs ago.

I'm less interested in static vs. dynamic than I am in why the community seems to be floating in this direction recently, when the past 5-7 years has been all about RoR, Django, and even Perl.

I do not consider Go to have a strong type system. It's static though.

Strong typing allows you to do a lot and it also solves the problem we fallible humans bring to the table. Humans are pretty good at being creative but extremely terrible with details, remembering things, and keeping track of "hairballs".

Strong type systems solve pretty much all of that.

Now, with some of Haskell's newest features (like Type Holes) it's starting to make dynamic languages look more like children's toys because you get all the power and safety of a type system with the same "do what you want, it will (usually) tell you what you're intending to put there".

Dynamic programming came from a need for rapid iteration of a program because that's how humans work, we "start" then iterate till we have a more complex and functioning program. The problem with that model though, is that the burden of correctness is on us in the end.

Programming in Python is like leaving your dishes pile up in the sink for a week, then spending two hours doing dishes on Sunday.

Programming in Haskell is like taking your dish to your cleaning robot that will wash it, dry it, and put it away for you. All you have to do is know what you want to use the plate for and return to where the robot can get it.

> Programming in Haskell is like taking your dish to your cleaning robot that will wash it, dry it, and put it away for you. All you have to do is know what you want to use the plate for and return to where the robot can get it.

With the occasional smash coming from the kitchen when you find out the robot has been trying to hold all of your plates at once instead of putting them away because you haven't gone to get one out of the cupboard yet ;)

A stack of type t things blowing up because of lazyness... How appropriate ; )

It's now "typed holes", which really is a much better description anyway.

Programming in dynamic types is not easier because you can jump around the type system more dextrously. Programming in dynamic types is easier because you (mostly) can forget that types even exist. That leads to lesser cognitive load, and that always makes a thinking job easier.

That of course makes it more dangerous too, but it's a trade-off.

Even in a dynamically typed language you can't just ignore the types. You still have to make assumptions about what methods and functions can operate on a value; the compiler just doesn't know what assumptions you are making.

I get the feeling that many programmers have been bitten by weak typing too many times and have come to appreciate the benefits of stronger typing.

If you want to apply defensive programming, which is always a good idea, you usually encounter this pattern: "I'm expecting an Int. Is this an Int? No, this is a string. But if I converted it, would the result be an Int? No? OK, then we have a problem, what should I do about it?". Some languages even have automatic type coercion, in which the final result depends entirely on what the language decides, and varies across languages. It's a mess.

Languages like Haskell or the ML family, with their type systems and type inferences, simply won't compile if you say you are expecting an Int and some other part of the program sends anything else. Maybe it's more work for the programmer upfront, but it reduces future headaches, and it's not difficult once you get the hang of it. Many times you don't even have to state the types explicitly, the compiler just knows. Thanks Hindley-Millner!

Static typing != Strong typing. Once you've grokked Haskell it's hard to consider mere static type systems to be type systems at all. Languages like Java, Go, etc. may as well just be dynamically typed for all their type systems do for you vs Haskell's.

I think that revelation may be one of the things driving this new interest in type systems and comparisons of them. Haskell has really opened some eyes and people are wondering how others compare, and are on the lookout for new languages like Rust doing interesting things with strong typing.

Dynamic typing without the metaprogramming, plus tacked-on parametric typing in the form of templates or generics or whatever they call it. Or better yet: no parametric typing whatsoever and no way of making strongly-typed abstract data structures. Or duck typing, which is exactly that.

Yup, no strong typing anywhere.

Plenty of killer bugs are smashed in compile time by the most simple compiler checks.

The weirdest thing with the new breed of strongly typed language, in my opinion, is that they naturally accept sum types, which are completely alien from an OOP point of view. I mean, the magnificiently useful case switch feature you have in most of those new languages translates very awkwardly in, say, Java by using a isinstanceof then some kind of cast, which I gather is Considered Harmful because it breaks encapsulation and type safety, yet case switches are a natural consequence of sum types, and are completely safe, in the context of a type system that have sum types.

Switching on "type" also happens to be a thing I see a lot in what one would traditionally consider bad code, for example, treating a scalar and an array differently in PHP, or having functions that can deal with many different shapes and kinds of JSON blobs in JavaScript. There also have been a lot of hype around the idea of eliminating null references by using Maybe types, which in the end are just a degenerate case of a sum type.

My pet theory is that the ability to keep doing this in a safe and formalized manner is what makes the new breed of statically typed PLs so cool.

In the 90's Java/C/C++ land, one needed to implement lists and dicts and such by hand. Then came dynamic Perl/Python/Ruby where all these handy data types like list comprehensions, map, foreach were part of the language. I guess we mistook easy operations on a rich set of default data types as a property of dynamic languages?

Now we have Scala, Haskell, OCaml, Rust that have all these handy tools by default, but also strong typing, and type inference on top of that.

(Well OCaml and Haskell we had already some time ago, but they were not popular then.)

You could assume it is something inherent, or you could just connect the dots and realize that it's the silver-bullet fad of the decade, just like OOP and various other things before that.

Silver-bullet fads tend to have a grain of truth that gets carried on into the next fad. Loops are still with us (structured programming), we still write polymorphic code (OOP), we still like less verbose type systems (dynamic languages), etc.

No, it's just a second take at removing the "ceremony":

v. 1: let's remove the ceremony along with strong static typing advantages and just hack-fix everything with unit tests.

v. 2: let's remove just the ceremony.

Reply on news.ycombinator.com