EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: 0db on August 13, 2020, 01:36:35 pm
-
Since I'd like reading about functional programming, so I have just bought the last book on Haskell written by Graham Hutton, already received the .mobi file on my Kindle PaperWhite, not yet read anything except the index and the introduction and it already sounds like a good opportunity to learn from a real expert.
I would guess that most folks like me coming to Haskell have some programming experience in other languages (C? C++? Pascal? Python? Java? ...) and are looking to expand their horizons and get some functional and static typing enlightenment.
Any Haskell fan here? :D
-
Haskell is mainly interesting for the implications of a system that assures pure functions everywhere that matters and for its system-fc based type system. Together they permit things like implicit lazy evaluation (whether desirable or not) and fully generalized type inference. The most useful features of haskell now exist in many other langs, the main selling point of haskell being the unlimited general applicability of language features and compiler construction techniques that depend on its effectively unique properties.
Going beyond haskell to more intricite type systems pretty much takes you out of the domain of practical general-purpose langs into the universe of theorem provers, constraint solvers, and the like. If the type system angle is the abstraction you're into then haskell is a no-brainer. It's practical, mature, robust, good ecosystem around ghc, etc.
For the zoo of features in the "metaprogramming" category, haskell is lousy / useless, according to my probably obsolete knowledge. Ideas that involve language extensibility may involve designing some underlying building blocks into haskell as a prerequisite. (Like function purity, not easy to cleanly evolve language support as an afterthought.)
For that, https://racket-lang.org/ (https://racket-lang.org/) . I've been adding racket to my workflow at any available excuse.
Further down the rabbit hole into not quite yet practical meta-circular evaluators, https://www.red-lang.org/ (https://www.red-lang.org/)
I would guess that most folks like me coming to Haskell have some programming experience in other languages (C? C++? Pascal? Python? Java? ...) and are looking to expand their horizons and get some functional and static typing enlightenment.
Probably. I'm a never normal special snowflake.
For a total newcomer I'd recommend understanding "interfaces" in C# / Java or even C++-20 "concepts" before attempting to grok algebreic data types. That's a minor challenge in itself if you've never used a static typed lang or come from a multiple-inheritance lang where the overlapping function is less obvious.
-
s/ADTs/type classes/ ;)
ADTs are something that frankly every language should have. I hate C :rant:
-
s/ADTs/type classes/ ;)
Whoopsie! Yes type classes duh. Do as I mean not as I say.
-
looking to expand their horizons and get some functional and static typing enlightenment.
That is definitely great. But the first thing you should realize is that there is nothing special to functional programming when compared to any other paradigm. Whether you use Haskell or Java doesn't matter from a mathematical point of view, you can apply the same principles in both languages. Java's type system is a bit rough, but strong enough to enable enjoyable functional programming.
The big difference between FP and other paradigms is actually how easy or difficult it is to create software *designs* and *architectures*. Unfortunately, many FP languages are notoriously weak in this regard because that's not their focus.
-
Scala and Rust have borrowed a lot from Haskell. The "tagless final", "free monad" and "algebraic effects" design patterns were all pioneered by the Haskell community. Type classes showed up in Haskell over 20 years ago.
Here are some things which set Haskell apart from conventional programming languages:
- no sub-typing
- no implicit conversion of values from one type to another
- no object-based dispatch
and it's interesting to see how you can get real work done without these features.
-
- no sub-typing
- no implicit conversion of values from one type to another
- no object-based dispatch
and it's interesting to see how you can get real work done without these features.
Well, "real work" has also been done without these features long before Haskell appeared. It's not about "getting work done".
Put differently: It is not a sign of quality if you get real work done because that is achieved with each and every programming language, even the worst. Even with COBOL.
-
- no sub-typing
- no implicit conversion of values from one type to another
- no object-based dispatch
and it's interesting to see how you can get real work done without these features.
Well, "real work" has also been done without these features long before Haskell appeared. It's not about "getting work done".
Put differently: It is not a sign of quality if you get real work done because that is achieved with each and every programming language, even the worst. Even with COBOL.
Please don't read too much into my post. I'm not saying Haskell is better because it doesn't have these features - I'm just saying it's different.
-
Please don't read too much into my post. I'm not saying Haskell is better because it doesn't have these features - I'm just saying it's different.
Fair enough! I'm sorry, but this very combination of words makes me feel the strong urge to quote something that is commonly attributed to Jonathan Ive: "It's easy to be different. It's difficult to be better." Please, never mind. The Haskell people are just so adamantly hammering into people's minds that they are smarter and better than everybody else that I can't resist. :)
-
The Haskell people are just so adamantly hammering into people's minds that they are smarter and better than everybody else that I can't resist. :)
Every technical niche has their fanboys :'(
Even though they are not the majority, they do tend to be loud, and therefore easily mistaken to represent the whole. Happens in all technical niches, in my experience. :-//
-
- no sub-typing
- no implicit conversion of values from one type to another
- no object-based dispatch
and it's interesting to see how you can get real work done without these features.
Well, "real work" has also been done without these features long before Haskell appeared. It's not about "getting work done".
Put differently: It is not a sign of quality if you get real work done because that is achieved with each and every programming language, even the worst. Even with COBOL.
Of course. But it looks to me like you're interpreting ledtester's point backwards.
Obviously getting real work done is not a sign of "quality", but OTOH not being able to get any real work done is obviously a showstopper, as it would make said language useless.