4 ms·
> 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 wi
by fnord77 7y ago
> 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.
- worldsayshi 7y agoI 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?
- xyzzy_plugh 7y agoExpressiveness 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.
- agumonkey 7y agofair point, expressiveness shifts idioms toward "single man private jokes" A point I just realize the value.
- worldsayshi 7y agoBut you could just have expressiveness through composition then?
- kccqzy 7y agoIt'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.
- willtim 7y agoThis 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-in-kubernetes-25da87430301 https://medium.com/@arschles/go-experience-report-generics-i...
- willtim 7y agoSounds 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.
- est31 7y agoGlobalized 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.
- vikiomega9 7y agoSort 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
- ufo 7y agoI think that these days the Haskell best practices recommend adding a type annotation to all toplevel declarations, to help keep error messages manageable.
- nextos 7y agoI 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.
- johnday 7y agoIt's not difficult to enforce strictness in Haskell in the places where it matters.
- whateveracct 7y agoHaskell is perfect for that world you describe. Thanks to purity and strong types, Haskell modules compose better than modules in other PLs.