Hacker News Reader

Comment by fnord77 | Hacker News Reader

> Programs should be easy to express.

in my experience, languages that make it easy to express small programs tend to be counterproductive for large systems with many modules, many people working on the system and the desire for fine-grained control.

View on HN

Sounds like you perhaps have experience of dynamically-typed languages? Haskell is statically typed, compiled, has a scalable multi-threaded runtime, a very good FFI; and was designed around the notion that large programs should be built by composing small programs.

Globalized type inferrence is still a problem when you want to build large programs. You change the implementation of one function and 20 functions further there is a problem and you need to figure out all the interactions on the path between. Rust strikes a great compromise here IMO.

Sort of sounds like the interfaces/components/boundaries/separation of concerns in your modules isn't up to scratch. This is more of an org issue around management as opposed to the language unless you think rust has a set of fetaurs that help with this

I think that these days the Haskell best practices recommend adding a type annotation to all toplevel declarations, to help keep error messages manageable.

I tend to prefer eager ML languages vs Haskell. Some lazy abstractions are a bit leaky. Performance might degrade and it's really hard to debug.

Laziness is nice, but not by default perhaps.

It's not difficult to enforce strictness in Haskell in the places where it matters.

I neither want to deny or confirm this but if love to see a more in depth analysis of the idea.

Why? Is it because of the "fine grained control" part? Because it breaks the neat abstraction?

Expressiveness is too powerful. I have to understand what the author was thinking. What you typically want is composition. With composition, you have to understand what the author is doing.

Painting with acrylics vs Lego.

fair point, expressiveness shifts idioms toward "single man private jokes"

A point I just realize the value.

But you could just have expressiveness through composition then?

It's basically the same reason Go was created: not many advanced features, lack of abstraction power, leading to highly predictable codebases so that companies can easily onboard new software engineers.

This was probably the theory behind their decisions. While I agree that the lack of expressiveness might discourage some incidental complexity, for example premature or unecessary abstractions, the inherent complexity of a problem will remain. Removing expressive power, in general, will lead to ad-hoc and cumbersome workarounds. For example, look what the Kubenetes codebase had to do to work around the lack of generics: https://medium.com/@arschles/go-experience-report-generics-i...

Haskell is perfect for that world you describe. Thanks to purity and strong types, Haskell modules compose better than modules in other PLs.

Reply on news.ycombinator.com