I really needed this channel, thank you so much Also, GHC is probably THE best compiler I've ever worked with; it even suggested the actual code snippet to achieve something I was trying to do Also also, if you approach Haskell community with humility you'll find out it's one of the most wholesome communities
Agreed. Then add also Haskell lsp-mode into your Emacs so that it runs GHC continuously in the background while you code, to get online coding hints and so on. And watch an Intel i5 CPU burn bright red, trying to keep up...
@@mattinykanen4780 nah, not a fan of Emacs as I don't write any lisp as Polish notation alone is reason enough for me to quit before I start 😸 (Neo)Vim is more my sort of poison
The biggest Haskell Discord group was a bunch of weirdos making shitposts about being "milk maids", and now "Yandere Mommies"...Shits weird but hilarious.
I have 3 points: 1) There is no category Hask 2) I don't think I can get over :: for type annotation instead of : (I know, I know... maybe I'll try someday) 3) IMHO, the ML family languages such as OCaml, F#, or even SML are a much friendlier introduction to FP for programmers than Haskell
@@AndreiGeorgescu-j9p 1. Nope. Sorry, there simply is not. You may be thinking of ωCPO, or "Scott domains and Scott-continuous functions," but that is not "Hask" as envisaged by your everyday Haskeller. Random YT commenters like me are not valid sources, of course, so I'll point you toward Andrej Bauer's 2016 article, "Hask is not a category," along with "A note on inconsistencies caused by fixpoints in a cartesian closed category" by H. Huwig and A. Poigne, Theoretical Computer Science 1990 (PDF is easy to find on Google Scholar). 2. Well, I meant it only half-seriously. But in actuality, yes, it is. Aesthetics and ergonomics are legitimate concerns for programming languages. It's a matter of personal taste, but perfectly valid nonetheless. 3. Your argument is nonsensical. C++ is by no means an introduction of any kind to FP. As for advanced features, what need does a beginner (who may have spent the past decade eyeballs-deep in imperative code) have for the most advanced Haskell features? Beginners need to get their heads around basics like currying, fmap, reduce, and monads. Learning an ML-family language will teach these things. Crawl first, then walk, then run. "Functional-first" (but imperative okay) is a very effective stepping stone between "imperative-first" and "muh PURE FP, imperative = le evil!!" Also, StandardML is stuck because of its formal standard, but F# and OCaml continue to develop exciting new features.
@@AndreiGeorgescu-j9p (it looks like my reply didn't post? I'll try again) 1. Nope. Sorry, there simply is not. You may be thinking of ωCPO, or "Scott domains and Scott-continuous functions," but that is not "Hask" as envisaged by your everyday Haskeller. Random YT commenters like me are not valid sources, of course, so I'll point you toward Andrej Bauer's 2016 article, "Hask is not a category," along with "A note on inconsistencies caused by fixpoints in a cartesian closed category" by H. Huwig and A. Poigne, Theoretical Computer Science 1990 (PDF is easy to find on Google Scholar). 2. Well, I meant it only half-seriously. But in actuality, yes, it is. Aesthetics and ergonomics are legitimate concerns for programming languages. It's a matter of personal taste, but perfectly valid nonetheless. 3. Your argument is nonsensical. C++ is by no means an introduction of any kind to FP. As for advanced features, what need does a beginner (who may have spent the past decade eyeballs-deep in imperative code) have for the most advanced Haskell features? Beginners need to get their heads around basics like currying, fmap, reduce, and monads. Learning an ML-family language will teach these things. Crawl first, then walk, then run. "Functional-first" (but imperative okay) is a very effective stepping stone between "imperative-first" and "muh PURE FP, imperative = le evil!!" Also, StandardML is stuck because of its formal standard, but F# and OCaml continue to develop exciting new features.
@@AndreiGeorgescu-j9p OOkkay, so my reply is still not showing. Maybe third time's the charm. 1. No, there is not. CPO is a category, as is the category of Scott domains and Scott-continuous functions. But neither is the "Hask" of the usual Haskeller's imagination. And I've yet to see anything that differentiates "platonic" Hask from Set. The article by Andrej Bauer is a great read (the comment section is also full on insight). Knowing where and how Haskell fails to be a category is _as important_ to being proficient with the language as knowing all of the ways CT does kind of apply (which, by the way, ALSO apply to any ML-family language). I also highly recommend "A note on inconsistencies caused by fixpoints in a cartesian closed category" by Huwig and Poigne. 2. lol I meant that mostly as a joke, but as you seem a bit defensive about Haskell, I'll lean into it. :) Aesthetics and ergonomics are valid concerns. I find the double-colon displeasing. On one hand, that's a personal preference thing. On the other hand, I'm not alone. It's not a big deal, but it's not nothing. 3. Nah. You can say that SML is stuck in the past, due to the difficulty of updating the formal spec. However, F#, OCaml, and other descendants continue to innovate. The point is that they allow devs who have spent 10+ years writing imperative code can get comfortable with FP principles without having to give up imperative patters that they find comfy. Over time, they get more and more comfy with the functional way, and their code starts to reflect that. It's a real farce IMHO that Haskell fans don't see the pedagogical value in slightly less religious FP languages: it's always: "my beloved Haskell, or _nothing!"_
Alright, maybe there's a problem with the replying system. Sorry if 5x of the same comment shows up later. Here is my reply to @user-tx4wj7qk4t. (or is it Andrei Georgescu? YT seems inconsistent about displaying usernames recently...) 1. No, there is not. CPO is a category, as is the category of Scott domains and Scott-continuous functions. But neither is the "Hask" of the usual Haskeller's imagination. And I've yet to see anything that differentiates "platonic" Hask from Set. The article by Andrej Bauer is a great read (the comment section is also full on insight). Knowing where and how Haskell fails to be a category is _as important_ to being proficient with the language as knowing all of the ways CT does kind of apply (which, by the way, ALSO apply to any ML-family language). I also highly recommend "A note on inconsistencies caused by fixpoints in a cartesian closed category" by Huwig and Poigne. 2. lol I meant that mostly as a joke, but as you seem a bit defensive about Haskell, I'll lean into it. :) Aesthetics and ergonomics are valid concerns. I find the double-colon displeasing. On one hand, that's a personal preference thing. On the other hand, I'm not alone. It's not a big deal, but it's not nothing. 3. Nah. You can say that SML is stuck in the past, due to the difficulty of updating the formal spec. However, F#, OCaml, and other descendants continue to innovate. The point is that devs who have spent 10+ years writing imperative code can get acclimated to FP principles without having to give up _all_ of the imperative patters they find comfy. Over time, they get more and more comfy with the functional way, and their code starts to reflect that. It's a real shame IMHO that Haskell fans don't see the pedagogical value in slightly less religious FP languages; rather, it's always: "my beloved Haskell, or _nothing!"_
Hi, I wonder if Haskell is easy to find a job. I am an EDA compiler engineer in C++ but in love with Haskell. I'm not quite sure it is worth investing the time in here since if I figured out the way to do some stuff in Haskell, I might need to relearn it with other programming languages for practical use (or for a good salary)
Getting a Haskell job (especially the first one) is more challenging than in mainstream languages - many enthusiasts want one, and not that many companies offer one. It's easier to find a job doing something else + Haskell, for example, Scala and Haskell (thanks to the microservice era). Also, introducing Haskell at work is an excellent opportunity to get more experience (both for yourself and your CV). Learning Haskell helps to learn other languages - even though some of its concepts (and constructs) are rare, many are becoming mainstream and adopted by other languages.
Once upon a time Laurence Poulson wrote a book titled "ML for the Working Programmer". I wish he'd written a book titled "Work for the ML Programmer" instead.
While I am still in awe of Haskell even after all these years, I did find a rather strong counterargument just a couple of months ago. I namely read "The Programmer's Brain" by Felienne Hermans. She pointed out that human cognition needs anchors: something which it meets time and time again. This is why "while" and "for" and so on make us feel that we are on familiar ground. Haskell has none of that: it has even taken "do" to mean something else.
Is it an argument? Or is it a matter of it being familiar or unfamiliar? Here is the same "argument" in reverse: This is why "semigroups" and "monoids" and so on make us feel that we are on familiar ground. Imperative languages have none of that: they have even taken "+" to mean something else.
Sorry I was unclear: (i) The argument against Haskell was mine, based on what she wrote. (ii) She wrote about human cognition in general, and how it applies into learning a programming language. (iii) For me, while mathematics as a whole can transcend the limitations of the human mind, every single mathematician is still constrained by the inherent limitations of his or her own central nervous system. (I guess that makes me a kind of neuro-Brouwerist then.)
Almost nobody starts programming with Haskell, so people are usually getting stuck in imperative procedural thinking. That's why recursion is one of the most difficult conceptions everybody's facing with eventually. And the most funny thing is that any kind of loops can be replaced by recursion, while opposite is not applicable. My personal experience is that you have lot of things to unlearn before getting into.
@@qandak Why "unlearn"? If anything, programming is all about developing abstractions which are _useful_ in a particular context. This was evident from the very dawn of our field: Back in 1936, Alan Turing published the Turing machines, which we now consider as the paradigmatic abstract machine model of stateful computation. In that very same year, Alonzo Church published independently the lambda calculus, which we now consider as the paradigmatic abstract model of programming languages. After he became aware of Turing's work, he posited that Turing machines did indeed capture the intuitive meaning of what a "mechanically computable function" is. In contrast, the definition of lambda calculus does not contain any kind of a "machine". Nevertheless both lead to the same class of functions. Does this mean that one is The Only Right Way and the other a mere wannabe? Certainly not! Both illuminate the same class, but from different viewpoints: Turing machines reveal the machine but obscure the algorithm (which is "merely" the blueprint of how to build the machine) while lambda calculus reveals the abstract algorithm (as an explicit lambda term) but obscures the underlying mechanics. That said, I do believe that lambda calculus and (especially lazy) functional programming is "first among equals". (Even though King Arthur commissioned the Round Table for his knights, so that nobody would be seated in a higher or lower position than others, everyone still remembered him as their host and patron.) It is namely the "lingua franca" of the realm: the language into which all other models of computation are relatively easy to translate. I similarly enjoy Haskell because it makes me ask "Does this algorithm or data structure _really_ need to be stateful or not?" (There seem to be a few which really do, like "union-find" and "BDD".)
In the city of Utrecht, The Netherlands there is a parking guidance system for bicycles. AFAIK it is written in Haskell. Here is a video about that system. th-cam.com/video/RTce86dBbzk/w-d-xo.html
The Netherlands was also the home of the main rival to Haskell: the Clean programming language (by Rinus Plasmeijer & al.). They just made two bad platform choices: First, they targeted the Mackintosh and its original operating system, which was a mistake both technologically and commercially. I was one of the very few owners of a Mac SE amongst my fellow students, because they were very expensive, and certainly the only one who wrote any code using Clean. Then they switched into Windows instead of Linux - another decision to alienate hobbyist and student programmers.
@@AndreiGeorgescu-j9p Ironic you say that, considering you're once more trying to dunk by saying "Haskell is too hard for you" seemingly unaware that this destroys your entire thesis
@@AndreiGeorgescu-j9p You did though. You said it, you keep saying it, and you show no signs of stopping it. "haskell doesn't have libraries" Compared with a real language, no it doesn't. "d it can't do side effects. " It can, it's just extremely cumbersome.
In statically typed FP languages you rarely needs a debugger, because normally if it builds, it works. Of course there are edge cases where you need to see what you have in the runtime, but there are loggers, tracers and more as libraries for the same purpose.
GHCi _does_ actually have an integrated debugger with breakpoints and whatnot. It's just hardly ever used: First, the very strong and expressive type system ensures that if the code compiles, then it does not crash. And second, debugging a non-strict language by tracing its execution is rather odd...
@@nieczerwony There's no argument there, you just offered a nice-sounding phrase. If that is what moves you to choose technologies then you have no chance of succeeding in this field.
zig is much better than C, simple as that, the language is far more capable, has good interop, is more safe, expressive, has good error handling, multiple allocator model, defer, allows for generics without a horrible pre processor and has compile time execution. zig is just so far ahead of C in every aspect.
@@marcs9451 It's neither more capable than C, nor does it have any better interoperability. It's definitely not more safe, as no language that purports to handle low-level programming can be safe at all, nor should they try to be as that's on the user of the language to guarantee. The error handling isn't better than C, nor hugely different from C. Providing certain facilities such as alternative allocators and deferrals out of the box is nice, but doesn't prevent C from having such facilities, just that you have to use your brain and write them yourself. Looks like C is going to have compile time execution soon, not that it's a necessary feature because it was never terribly onerous to write a configuration program yourself and run it before fully building your program, and truthfully with people pushing for all of these other languages it makes no sense for C to add most of these features so late in the game. People that use it tend to be more intelligent and patient and thus can cope without them. I will agree with one thing though, generics in C suck, even now that _Generic was added to the language with C11, but it does obviate a lot with it implemented the way it is now as compared to merely using macros before.
the statement "you need a phd for X" is totally stupid itself. A phd is a highly specialized work that is barely useful out of its field of study. It does not make you smarter or anything like that.
the problem with Haskell is the DX is absolutely horrible, because they've not yet fully solved a proper effects system. It's still an open research. Yes there are many different libraries and approach/attempts at some kind of effect system but they all have different trade off and incompatible with each other. When solving problems, I don't want to care about building up a Monad stack and use transformers and keep track of which layer I'm in and lift and unlift etc, I don't don't wan to have to deal with converting between different incompatible stacks etc. The language itself is easy, but I don't think until the effects system is solved it will forever remain niche. But ironically by the time there is a solved effects system most likely it will end up looking and feeling every other mainstream language and given that a fair amount of features is now already available in most modern languages why would anyone want to transition over?
@@AndreiGeorgescu-j9p monad stacks are awful because of the cognitive overhead, hence it's normal practice to keep the stacks as few layers as possible, then it gets worse because if different libraries use different stacks you have to do a lot of plumbing and converting/marshalling etc. Yes you can over complicate in any language, but Haskell's abstraction allows one to take it to extremes that other languages can't. So you end up with horrible codebases because different authors have decided on different abstractions and created their own little worlds etc. Anyway Haskell isn't growing, and the Haskell foundation is scratching their heads wondering why, even though when ex Haskell users provide feedback, Haskellers become defensive instead of actually listening to what they're saying. Hey ho, it's a dying language no one cares.
@@AndreiGeorgescu-j9p Haskell isn't growing it's practically dead. The main reason is every other mainstream language has adopted a lot of the good parts of Haskell already. So why would anyone want to waste time and effort learning Haskell that is known to have a deeper learning curve when existing languages provide many of the features? No Haskell has always been niche, it drew some attention around 2014, but that hype train crashed and burned because mainstream languages simply adopted the good parts. Are there Haskell fanbois telling us how amazing it is and how it's growing "exponentially"? Absolutely, but they're delusional, devoid of the actual reality.
Haskell will live on because it is a good testbed for new ideas on type theories for programming languages. Reassignment is namely damn hard to get right in type theories. Hence researchers try out their ideas first in Haskell, and if they work there, then they will carry them over to other languages too. This is why Haskell will continue to spawn innovation in the future too. In short, the future of programming languages is already a part of today's Haskell - we're just not certain which part...
@@AndreiGeorgescu-j9p I don't think it's a "hard language". I've written and deployed production applications in Haskell. I just don't like the language and ecosystem there is a difference.
@@AndreiGeorgescu-j9p I've written and deployed production Haskell, I just don't like the language nor the ecosystem. You're a fanboy and that's good for you. Category theory is actually pretty simple but Haskell doesn't strictly follow category theory, take for example the Hask which is NOT a category because it contains bottom aka the infamous _|_ type. Sure Haskell could be said to be influenced/inspired by CT but it's not CT proper. Now go cry.
Haskellers say: "Avoid success at any cost". That is, if you are ready and willing to sacrifice every principle you ever had just to be successful, then that "victory" is hollow indeed: _you_ didn't win anything after all, because whoever stands on the podium is no longer you.
@@AndreiGeorgescu-j9p "Justin Bieber" in your example could be something like Javascript. The key is that Haskell is not popular, but at the same time it's successfully used in big projects in place of many other solutions!
![[MV] A leap of faith...ความเชื่อใจครั้งสุดท้าย (From "Petrichor the series")](http://i.ytimg.com/vi/U1piZH2CNXA/mqdefault.jpg)
Useful vid. I hear these a lot, so I can just respond with a timestamp to this video next time.
"Haskell isn't suitable for web development."
My brother in christ, javascript isn't suited for any development.
And yet it's vastly favoured over Haskell.
Should tell you something about Haskell
@@joestevenson5568 I think this just tells us Haskell has a higher barrier to entry, literally anyone can code in JS, doesn't mean its better.
"Haskell isn't suitable for web development."
I used Asp, Laravel and Node. Yesod is by far my most loved web framework.
I really needed this channel, thank you so much
Also, GHC is probably THE best compiler I've ever worked with; it even suggested the actual code snippet to achieve something I was trying to do
Also also, if you approach Haskell community with humility you'll find out it's one of the most wholesome communities
Agreed. Then add also Haskell lsp-mode into your Emacs so that it runs GHC continuously in the background while you code, to get online coding hints and so on.
And watch an Intel i5 CPU burn bright red, trying to keep up...
@@mattinykanen4780 nah, not a fan of Emacs as I don't write any lisp as Polish notation alone is reason enough for me to quit before I start 😸
(Neo)Vim is more my sort of poison
The biggest Haskell Discord group was a bunch of weirdos making shitposts about being "milk maids", and now "Yandere Mommies"...Shits weird but hilarious.
Haskell has everything needed to do what any imperative language does
I have 3 points:
1) There is no category Hask
2) I don't think I can get over :: for type annotation instead of : (I know, I know... maybe I'll try someday)
3) IMHO, the ML family languages such as OCaml, F#, or even SML are a much friendlier introduction to FP for programmers than Haskell
@@AndreiGeorgescu-j9p
1. Nope. Sorry, there simply is not. You may be thinking of ωCPO, or "Scott domains and Scott-continuous functions," but that is not "Hask" as envisaged by your everyday Haskeller. Random YT commenters like me are not valid sources, of course, so I'll point you toward Andrej Bauer's 2016 article, "Hask is not a category," along with "A note on inconsistencies caused by fixpoints in a cartesian closed category" by H. Huwig and A. Poigne, Theoretical Computer Science 1990 (PDF is easy to find on Google Scholar).
2. Well, I meant it only half-seriously. But in actuality, yes, it is. Aesthetics and ergonomics are legitimate concerns for programming languages. It's a matter of personal taste, but perfectly valid nonetheless.
3. Your argument is nonsensical. C++ is by no means an introduction of any kind to FP. As for advanced features, what need does a beginner (who may have spent the past decade eyeballs-deep in imperative code) have for the most advanced Haskell features? Beginners need to get their heads around basics like currying, fmap, reduce, and monads. Learning an ML-family language will teach these things. Crawl first, then walk, then run. "Functional-first" (but imperative okay) is a very effective stepping stone between "imperative-first" and "muh PURE FP, imperative = le evil!!" Also, StandardML is stuck because of its formal standard, but F# and OCaml continue to develop exciting new features.
@@AndreiGeorgescu-j9p
(it looks like my reply didn't post? I'll try again)
1. Nope. Sorry, there simply is not. You may be thinking of ωCPO, or "Scott domains and Scott-continuous functions," but that is not "Hask" as envisaged by your everyday Haskeller. Random YT commenters like me are not valid sources, of course, so I'll point you toward Andrej Bauer's 2016 article, "Hask is not a category," along with "A note on inconsistencies caused by fixpoints in a cartesian closed category" by H. Huwig and A. Poigne, Theoretical Computer Science 1990 (PDF is easy to find on Google Scholar).
2. Well, I meant it only half-seriously. But in actuality, yes, it is. Aesthetics and ergonomics are legitimate concerns for programming languages. It's a matter of personal taste, but perfectly valid nonetheless.
3. Your argument is nonsensical. C++ is by no means an introduction of any kind to FP. As for advanced features, what need does a beginner (who may have spent the past decade eyeballs-deep in imperative code) have for the most advanced Haskell features? Beginners need to get their heads around basics like currying, fmap, reduce, and monads. Learning an ML-family language will teach these things. Crawl first, then walk, then run. "Functional-first" (but imperative okay) is a very effective stepping stone between "imperative-first" and "muh PURE FP, imperative = le evil!!" Also, StandardML is stuck because of its formal standard, but F# and OCaml continue to develop exciting new features.
@@AndreiGeorgescu-j9p OOkkay, so my reply is still not showing. Maybe third time's the charm.
1. No, there is not. CPO is a category, as is the category of Scott domains and Scott-continuous functions. But neither is the "Hask" of the usual Haskeller's imagination. And I've yet to see anything that differentiates "platonic" Hask from Set. The article by Andrej Bauer is a great read (the comment section is also full on insight). Knowing where and how Haskell fails to be a category is _as important_ to being proficient with the language as knowing all of the ways CT does kind of apply (which, by the way, ALSO apply to any ML-family language). I also highly recommend "A note on inconsistencies caused by fixpoints in a cartesian closed category" by Huwig and Poigne.
2. lol I meant that mostly as a joke, but as you seem a bit defensive about Haskell, I'll lean into it. :) Aesthetics and ergonomics are valid concerns. I find the double-colon displeasing. On one hand, that's a personal preference thing. On the other hand, I'm not alone. It's not a big deal, but it's not nothing.
3. Nah. You can say that SML is stuck in the past, due to the difficulty of updating the formal spec. However, F#, OCaml, and other descendants continue to innovate. The point is that they allow devs who have spent 10+ years writing imperative code can get comfortable with FP principles without having to give up imperative patters that they find comfy. Over time, they get more and more comfy with the functional way, and their code starts to reflect that. It's a real farce IMHO that Haskell fans don't see the pedagogical value in slightly less religious FP languages: it's always: "my beloved Haskell, or _nothing!"_
Alright, maybe there's a problem with the replying system. Sorry if 5x of the same comment shows up later. Here is my reply to @user-tx4wj7qk4t. (or is it Andrei Georgescu? YT seems inconsistent about displaying usernames recently...)
1. No, there is not. CPO is a category, as is the category of Scott domains and Scott-continuous functions. But neither is the "Hask" of the usual Haskeller's imagination. And I've yet to see anything that differentiates "platonic" Hask from Set. The article by Andrej Bauer is a great read (the comment section is also full on insight). Knowing where and how Haskell fails to be a category is _as important_ to being proficient with the language as knowing all of the ways CT does kind of apply (which, by the way, ALSO apply to any ML-family language). I also highly recommend "A note on inconsistencies caused by fixpoints in a cartesian closed category" by Huwig and Poigne.
2. lol I meant that mostly as a joke, but as you seem a bit defensive about Haskell, I'll lean into it. :) Aesthetics and ergonomics are valid concerns. I find the double-colon displeasing. On one hand, that's a personal preference thing. On the other hand, I'm not alone. It's not a big deal, but it's not nothing.
3. Nah. You can say that SML is stuck in the past, due to the difficulty of updating the formal spec. However, F#, OCaml, and other descendants continue to innovate. The point is that devs who have spent 10+ years writing imperative code can get acclimated to FP principles without having to give up _all_ of the imperative patters they find comfy. Over time, they get more and more comfy with the functional way, and their code starts to reflect that. It's a real shame IMHO that Haskell fans don't see the pedagogical value in slightly less religious FP languages; rather, it's always: "my beloved Haskell, or _nothing!"_
2:12 - they don't have to because the Hindley-Milner inference engine does it for them.
Nice video! Keep up the good work.
Hi, I wonder if Haskell is easy to find a job. I am an EDA compiler engineer in C++ but in love with Haskell. I'm not quite sure it is worth investing the time in here since if I figured out the way to do some stuff in Haskell, I might need to relearn it with other programming languages for practical use (or for a good salary)
Getting a Haskell job (especially the first one) is more challenging than in mainstream languages - many enthusiasts want one, and not that many companies offer one.
It's easier to find a job doing something else + Haskell, for example, Scala and Haskell (thanks to the microservice era). Also, introducing Haskell at work is an excellent opportunity to get more experience (both for yourself and your CV).
Learning Haskell helps to learn other languages - even though some of its concepts (and constructs) are rare, many are becoming mainstream and adopted by other languages.
Once upon a time Laurence Poulson wrote a book titled "ML for the Working Programmer". I wish he'd written a book titled "Work for the ML Programmer" instead.
"Haskell isn't suitable for web development"
Are we going to pretend PHP is?
Nice Euclidean T-shirt! Where can I find one of that?
I got it from the Curiosity Box. They sell tees separately as well:
www.curiositybox.com/products/4th-side-of-the-triangle-shirt
"How to think like a functional programmer" course:
impurepics.thinkific.com/courses/functional-thinking
Perhaps any justification for tooling should not require a mention of facebook, works against the purpose.
Sorry but cabal/stack suck real bad compared to cargo, but on the other hand almost everything sucks compared to cargo.
@@AndreiGeorgescu-j9p that's the thing! They had 30 years to make it right!
While I am still in awe of Haskell even after all these years, I did find a rather strong counterargument just a couple of months ago. I namely read "The Programmer's Brain" by Felienne Hermans. She pointed out that human cognition needs anchors: something which it meets time and time again. This is why "while" and "for" and so on make us feel that we are on familiar ground. Haskell has none of that: it has even taken "do" to mean something else.
Is it an argument? Or is it a matter of it being familiar or unfamiliar?
Here is the same "argument" in reverse: This is why "semigroups" and "monoids" and so on make us feel that we are on familiar ground. Imperative languages have none of that: they have even taken "+" to mean something else.
Sorry I was unclear: (i) The argument against Haskell was mine, based on what she wrote. (ii) She wrote about human cognition in general, and how it applies into learning a programming language. (iii) For me, while mathematics as a whole can transcend the limitations of the human mind, every single mathematician is still constrained by the inherent limitations of his or her own central nervous system. (I guess that makes me a kind of neuro-Brouwerist then.)
Almost nobody starts programming with Haskell, so people are usually getting stuck in imperative procedural thinking. That's why recursion is one of the most difficult conceptions everybody's facing with eventually. And the most funny thing is that any kind of loops can be replaced by recursion, while opposite is not applicable.
My personal experience is that you have lot of things to unlearn before getting into.
@@qandak Why "unlearn"? If anything, programming is all about developing abstractions which are _useful_ in a particular context. This was evident from the very dawn of our field: Back in 1936, Alan Turing published the Turing machines, which we now consider as the paradigmatic abstract machine model of stateful computation. In that very same year, Alonzo Church published independently the lambda calculus, which we now consider as the paradigmatic abstract model of programming languages. After he became aware of Turing's work, he posited that Turing machines did indeed capture the intuitive meaning of what a "mechanically computable function" is. In contrast, the definition of lambda calculus does not contain any kind of a "machine". Nevertheless both lead to the same class of functions. Does this mean that one is The Only Right Way and the other a mere wannabe? Certainly not! Both illuminate the same class, but from different viewpoints: Turing machines reveal the machine but obscure the algorithm (which is "merely" the blueprint of how to build the machine) while lambda calculus reveals the abstract algorithm (as an explicit lambda term) but obscures the underlying mechanics.
That said, I do believe that lambda calculus and (especially lazy) functional programming is "first among equals". (Even though King Arthur commissioned the Round Table for his knights, so that nobody would be seated in a higher or lower position than others, everyone still remembered him as their host and patron.) It is namely the "lingua franca" of the realm: the language into which all other models of computation are relatively easy to translate.
I similarly enjoy Haskell because it makes me ask "Does this algorithm or data structure _really_ need to be stateful or not?" (There seem to be a few which really do, like "union-find" and "BDD".)
@@mattinykanen4780 OK, by bad, just forgot to put "unlearn" in quotes. As I said it was my own experience.
In the city of Utrecht, The Netherlands there is a parking guidance system for bicycles. AFAIK it is written in Haskell. Here is a video about that system. th-cam.com/video/RTce86dBbzk/w-d-xo.html
The Netherlands was also the home of the main rival to Haskell: the Clean programming language (by Rinus Plasmeijer & al.). They just made two bad platform choices: First, they targeted the Mackintosh and its original operating system, which was a mistake both technologically and commercially. I was one of the very few owners of a Mac SE amongst my fellow students, because they were very expensive, and certainly the only one who wrote any code using Clean. Then they switched into Windows instead of Linux - another decision to alienate hobbyist and student programmers.
clicked for cats stayed for Haskell
Literally none of these are myths ¯\_(ツ)_/¯
@@AndreiGeorgescu-j9p Saying "Haskell is too hard" is not the W you think it is
@@AndreiGeorgescu-j9p What are you doing with those goalposts? Bring them back!
@@AndreiGeorgescu-j9p Ironic you say that, considering you're once more trying to dunk by saying "Haskell is too hard for you" seemingly unaware that this destroys your entire thesis
@@AndreiGeorgescu-j9p You did though. You said it, you keep saying it, and you show no signs of stopping it.
"haskell doesn't have libraries"
Compared with a real language, no it doesn't.
"d it can't do side effects. "
It can, it's just extremely cumbersome.
Haskell has no debugger.
Who needs a debugger anyways?
print "!!!! test !!!!"
print "is this working?"
In statically typed FP languages you rarely needs a debugger, because normally if it builds, it works. Of course there are edge cases where you need to see what you have in the runtime, but there are loggers, tracers and more as libraries for the same purpose.
@@WalkerLeitethat's probably because you don't actually use it for anything meaningful.
@@AlexanderThomasHaseltonlmao roasted
GHCi _does_ actually have an integrated debugger with breakpoints and whatnot. It's just hardly ever used: First, the very strong and expressive type system ensures that if the code compiles, then it does not crash. And second, debugging a non-strict language by tracing its execution is rather odd...
If you're doing work with embedded platforms, C, not Rust or Zig. Why would you use an inferior language?
My man here. My teacher was saying this:" Learn any language you want, but master C."
@@nieczerwony There's no argument there, you just offered a nice-sounding phrase. If that is what moves you to choose technologies then you have no chance of succeeding in this field.
zig is much better than C, simple as that, the language is far more capable, has good interop, is more safe, expressive, has good error handling, multiple allocator model, defer, allows for generics without a horrible pre processor and has compile time execution. zig is just so far ahead of C in every aspect.
@@marcs9451 It's neither more capable than C, nor does it have any better interoperability. It's definitely not more safe, as no language that purports to handle low-level programming can be safe at all, nor should they try to be as that's on the user of the language to guarantee. The error handling isn't better than C, nor hugely different from C. Providing certain facilities such as alternative allocators and deferrals out of the box is nice, but doesn't prevent C from having such facilities, just that you have to use your brain and write them yourself. Looks like C is going to have compile time execution soon, not that it's a necessary feature because it was never terribly onerous to write a configuration program yourself and run it before fully building your program, and truthfully with people pushing for all of these other languages it makes no sense for C to add most of these features so late in the game. People that use it tend to be more intelligent and patient and thus can cope without them. I will agree with one thing though, generics in C suck, even now that _Generic was added to the language with C11, but it does obviate a lot with it implemented the way it is now as compared to merely using macros before.
"I came to bury and not praise C, sir!"
the statement "you need a phd for X" is totally stupid itself. A phd is a highly specialized work that is barely useful out of its field of study. It does not make you smarter or anything like that.
Haskell isn't suited for Industrial Programming - Change my Mind
the problem with Haskell is the DX is absolutely horrible, because they've not yet fully solved a proper effects system. It's still an open research. Yes there are many different libraries and approach/attempts at some kind of effect system but they all have different trade off and incompatible with each other. When solving problems, I don't want to care about building up a Monad stack and use transformers and keep track of which layer I'm in and lift and unlift etc, I don't don't wan to have to deal with converting between different incompatible stacks etc. The language itself is easy, but I don't think until the effects system is solved it will forever remain niche. But ironically by the time there is a solved effects system most likely it will end up looking and feeling every other mainstream language and given that a fair amount of features is now already available in most modern languages why would anyone want to transition over?
@@AndreiGeorgescu-j9p monad stacks are awful because of the cognitive overhead, hence it's normal practice to keep the stacks as few layers as possible, then it gets worse because if different libraries use different stacks you have to do a lot of plumbing and converting/marshalling etc. Yes you can over complicate in any language, but Haskell's abstraction allows one to take it to extremes that other languages can't. So you end up with horrible codebases because different authors have decided on different abstractions and created their own little worlds etc. Anyway Haskell isn't growing, and the Haskell foundation is scratching their heads wondering why, even though when ex Haskell users provide feedback, Haskellers become defensive instead of actually listening to what they're saying. Hey ho, it's a dying language no one cares.
@@AndreiGeorgescu-j9p Haskell isn't growing it's practically dead.
The main reason is every other mainstream language has adopted a lot of the good parts of Haskell already.
So why would anyone want to waste time and effort learning Haskell that is known to have a deeper learning curve when existing languages provide many of the features?
No Haskell has always been niche, it drew some attention around 2014, but that hype train crashed and burned because mainstream languages simply adopted the good parts.
Are there Haskell fanbois telling us how amazing it is and how it's growing "exponentially"? Absolutely, but they're delusional, devoid of the actual reality.
Haskell will live on because it is a good testbed for new ideas on type theories for programming languages. Reassignment is namely damn hard to get right in type theories. Hence researchers try out their ideas first in Haskell, and if they work there, then they will carry them over to other languages too. This is why Haskell will continue to spawn innovation in the future too. In short, the future of programming languages is already a part of today's Haskell - we're just not certain which part...
@@AndreiGeorgescu-j9p I don't think it's a "hard language". I've written and deployed production applications in Haskell. I just don't like the language and ecosystem there is a difference.
@@AndreiGeorgescu-j9p I've written and deployed production Haskell, I just don't like the language nor the ecosystem. You're a fanboy and that's good for you. Category theory is actually pretty simple but Haskell doesn't strictly follow category theory, take for example the Hask which is NOT a category because it contains bottom aka the infamous _|_ type. Sure Haskell could be said to be influenced/inspired by CT but it's not CT proper. Now go cry.
If you need a list of companies that use a language, you know the language isn't good.
Haskellers say: "Avoid success at any cost". That is, if you are ready and willing to sacrifice every principle you ever had just to be successful, then that "victory" is hollow indeed: _you_ didn't win anything after all, because whoever stands on the podium is no longer you.
If people are always arguing that haskell is useless in real world production, then you do.
@@AndreiGeorgescu-j9p "Justin Bieber" in your example could be something like Javascript. The key is that Haskell is not popular, but at the same time it's successfully used in big projects in place of many other solutions!
If your statement were true, then it means that java is good.
ah so conformity is the basis of good software
Readability is a property of the reader, not the language.
So many C-like languages have been a depriment for all programmers.
*the writer