This is a great talk, I love to see companies along with more and more programmers see the light of many of Haskell's attributes. Haskell isn't the only way to get all these benefits, but it is currently the best! Haskell in production WORKS, you just need passionate developers who want to write robust and correct software.
People who think type errors are an annoyance sure must love running bugs on their client's machines lol. Like No Boilerplate said in their video on the Rust compiler, the only thing worse than bad errors is no errors.
Great presentation. My biggest barrier to using Haskell in production is how difficult it is to bind it to the platforms I care about. iOS/Android, and even web. There are some things that are working on this (especially web), but it still doesn't seem to be truly practical. It's very tempting to try to solve these problems and then use Haskell, but that's hard to justify the upfront costs, which is probably why it hasn't really been done.
You are right that Haskell should focus on these platforms more. As far as web goes, I really like the Haskell web frameworks such as Yesod, but they don't integrate with FRP systems such as Netwire.
This is a really old comment, but you might want to look into Clojure. It currently supports full stack web development and with recent developments regarding ClojureDart it may soon support cross-platform mobile development through Flutter. It's not a perfect replacement for Haskell, but with a strong emphasis on functional programming, immutable data structures, and easy concurrency it provides many features that a Haskell developer would appreciate.
That is an impressive rules based processing engine. Haskell. The engine seems to be applicable for many scenarios. Managing with policy and understanding and translating the policy bullets seems like the challenge step. I liked how she stated it just replicated out and reattached to the rules engine. They visualized this process in 1990. Wow.
@@techtutorvideos You forgot the "main :: IO ()" part. Why in the world do I have to tell the compiler that my program lives in the real world and is not just a mathematical abstraction? And why is line feed part of the function call???? Dudes, that is braindead. Having two different function calls instead of a control character is something that only depraved minds can even think up. You might as well be programming in Brainf*ck. ;-)
Programmers learn and use languages like Haskell because somebody above them usually wants them to.... after all, if a language thats stable and been available for years (there are many, and most of us know what they are) can do what you need it to, why learn something else, especially if there is no guarantee it will do as you want? Of course we all want to learn new things, thats how we progress, however, to have the desire to do that we need to know it will enable us to do more or to do better than with what we already have? Does Haskell? That is the question.
Oh how I disagree with the point at 38:18 - the compiler SHOULD yell at you here - that is important - if not then readability and maintainability goes down the drain. A good compiler should be strict and force you to stick to the rules in order to write code that exhibits the trait that two pieces of code that do the same should - more or less - look the same. This is the biggest problem with languages like Python and apparently also with this system!
Should that not be the work of a linter or something like that? There are algorithms that are, for me, more natural to write in one fashion and others in another...
Nice talk, and pretty interesting. That being said I want to learn Haskell and I feel that one main point has not been addressed and that is what I would call the Elitism of the language. I am a PHP programmer (mainly), and yes php has lots of problems, I'm not trying to say it's better than Haskell. But one thing I really hate about Haskell (not specific to haskell mind you) is the elitism of the code. It's difficult to read and understand. Most haskell code thrives to be "elegant" which is just another way of saying we crammed as much instructions as possible in the minimum amount of space, making it basically impossible to understand for an outsider. Take pretty much any Haskell tutorial and look at the function arguments: 'x', 'y', 'z' , '(x:xs)', '(y:ys)' etc... and this is considered standard practice. Why can't you give your parameters meaningfull names ? Can you at least comment your code to help me understand ? No ! How am I supposed to know what those parameters stand for ? Answer: I can't, I have to go read some kind of Documentation somewhere explaining what they are supposed to be, and generally that documentation just makes me feel dumb because I can't understand half of it so it generally boils down to "If you don't have a Phd in Mathematics and don't fully understand what Lambda calculus is, you are not worthy of using this code". Wheras in reality using meaningfull parameter names, adding some comments in the code and using a more explicit way of doing things would have enabled me to understand what the function does without even the need for documentation. I Hate this, I believe good code should be understandable by pretty much anyone, ideally even someone with no programming background should be able to get the idea of what is going on by reading the code. The prime example of this I feel is if/else vs ternary conditions, or explicit return statements vs directly returning the result of an operation in parenthesis. Yes the code is more elegant and requires less lines, but at the end of the day it doest exactly the same thing and is inherently less readable. If I show a simple if/else condition to my wife, she will probably get it, whereas if I show her the exact same condition in ternary form she doesn't have any chance at all of understanding what the code does. There it is, that's my little rant about Haskell and can definitely be applied to many other languages but I do feel Haskell is one of those languages that goes the extra mile to make sure that people who are "unworthy" are not able to understand the source code.
I haven't finished watching this talk yet, but already what I have seen amounts to a kind of response to at least some of what you say here. You say that explicit return statements are more readable than ternary conditionals / not using explicit return statements. But as the talk points out, the reason why you think that's more readable might have to do with your background and prior coding experience. Someone who hasn't done any coding in imperative languages, but who has been exposed to functions in math in primary or secondary school, may find it more intuitive that the function `f`, as defined in Haskell by `f x = x`, is the identity function --- it looks, after all, just like the f(x)=x in math. I'm not saying that everything about Haskell is easier to understand for someone w/o programming experience. But I do think that it's at least not obvious that things like explicit return statements are always easier to understand, and that, as the talk observes, one's perception of what may or may not be confusing might be influenced by one's prior programming experience.
Jeremy List I know she uses GHC and VIM. I use GHC as a compiler as well and sublime text as a text editor but that is pretty much it. I don't have a lot of idea about powerful command line Haskell tools that work with a Graphical front end of IDEs like Leksah or a Visual Studio plugin or a Jetbrain plugin etc. Don't know what sort of other tools they use in Facebook with Haskell other than the regular GHC, Cabal etc. Like tools for debugging, profiling, testing and automation etc.
***** I used to use that plug in as well. It is a fantastic plugin except it did not highlight the syntax properly if a variable name or something had a prime (') character somewhere in the middle. May be it is fixed by now but overall it is a fantastic plugin.
Eddie Seriously Haskell's ghci (in the form of haxlshell) and some neat Vim plugins is really all you need! (Though I now use Stack for my own projects because it makes builds really a lot easier)
Languages are suited for their domain, the benefits if functional programming languages are only there of you have bunch of code to to run in parallel( coz that's where the benefits of pure kick in that you can parallelize) , when you are caching the requests and when you are writing some thing very high level like rules engine where even frequent changes in imperative language would be costly. I don't know why people need to jump the gun and exaggerate. They can simply present the differences in plain and easy style and not try to generalise.
from the sentence "the benefits if functional programming languages are only there of you have bunch of code to to run in parallel" I can tell you have never written a substantial program in any serious functional programming language. The selling points of functional programming have very little to do with parallel, although making parallel code easier to write is one of the many wins you get with purity. Emacs is not mostly written in lisp because of parallelization. My first two years of programming in Haskell I did not write a single multi threaded program and I can confidently say for all of them Haskell was the best tool for the job.
All programming languages are machine code in disguise. That doesn't mean they're the same. The abstractions that each language builds on top of machine code is what matters.
I'd take c++, c, c#, even java, python or even fucking visual basic over something so convoluted and unintuitive any day. You are pressing a problem into a language that can be solved with any number of languages. and because your one example works with haskell still doesn't make it a viable programing language at large. people will use php or asp for server side programming, c#, c++, c, basic or python for general purpose programming and javascript and such for client side programming. anything else really is niece. I mean industry works like this: - Have a problem. - Need an automated solution to the problem. - Analyze the problem and here you select the language to use to solve the problem. will you spend time (money) learning something new, potentially only suited to that one single problem? or will you select a language that your employees already know and work with every day to solve any problem you can possibly solve algorithmically in the first place? Surely the answer is simple. you get a niece problem that can be solved with a niece language, or perhaps less elegant in a language you are already familiar with, but faster, then industry will always choose the second option. who wants to spend time learning something they use once only? especially where that would cost thousands of dollars for essentially doing nothing productive, and then perhaps find out that this or that is not doable because of limitations. coming from qbasic at the age of 8, i could easily pick up a c++ book and learn it rather quickly in my spare time. then going to pascal in school, again easy to learn. then java in university, same thing. then MC6809 assembler, different, but knowing how c translates into machine code made it simple to pick up as well, the concepts are the same, function calls are easy to implement, variables, stack, memory pointers, registers, all the same thing really. first in minecraft, then in logisim i found a hobby at doing some 'hardware engineering', building this and that logic circuit, again the mindset is already there, thinking logically about instructions and how to combine transistors to logic gates, and logic gates to multiplexers, and all those modules you already have to make something larger like an ALU. at work i now work with c#, which I had no experience with before. within a week I learned and wrote a program that works with bus systems and databases, expanding on it and adding functionality to it ever since. And now I see this and think, what the fuck is wrong with people? this resembles nothing of the above. it's math and formal languages pressed into a pancake that tries to be programming. I have an object oriented and procedural programming mindset, it's easy to understand and intuitive. It wouldn't cross my mind to go to something that forces me to bend my mind just to get behind the idea of it. I need to think in instructions and code and it needs to come naturally, something I just couldn't do with something this backwards. It's the same as using base root(15.7) as a number system. useless except for very few niece applications, and hard to wrap the mind around. Side effects can be useful, and even desirable. Disallowing them inhibits the freedom of the programmer. If you do not wish for side effects, then sticking to a few basic guidelines prevent them. a = b + (i++); is the same as a = b + i; i = i+1; and nobody in the right mind would write the first line, it's confusing, but possible. but should it be forbidden? i think not. even worse f(someBool && (i++) == 5) a nightmare. i will only increment if someBool is true, or if some specific compiler settings are set. but again, people don't do that sort of stuff. any oop language, and c like language have strong typing. i don't see how that's any better than those. python or javascript are a clusterfuck though. still i am able to wrap my head around them. class Id {private int ID; public int getID(){return ID;} ...}, strong typing, easy in oop languages. no haskell needed for same results. no one is gonna bother though, because you have names. even the most dumb monkey wouldn't confuse a variable name ID with something like breadrollsIHadThisMorning. To encapsulate a simple number into an object is possible and would have the same effect, but no one would really bother unless there are some critical requirements. usually classes would be used to create complex data types. right. teaching: just don't teach the language, just teach the simple stuff. try teaching c without structs and enums. or c++ without classes and overloading. sure you can still write your hello world, but it's just prohibitive to not know what tool you're working with. By the way, did you know the linux kernel, or any kernel, has no haskell code in it? I don't know even a single program at work or at home that runs haskell code. From what I can see, it isn't really suited as a program in itself anyway, but rather only as a layer between input and output. can you query a database? or can you even read a keyboard input? I don't know. What even is a keyboard to haskell? even the most basic concepts don't apply. When you say challenges, what you mean to say is problems. You have a new problem, haskell might be suitable, but no one knows, because nobody in the imaginary firm has experience with it. But they know the problem can be solved in what the firm's programmers are experienced in, say dotNet. Will they decide to learn the new, foreign and different language, basically from scratch where prior mindsets and ideas don't apply? fuck no, they won't. they will use the tools they are familiar with, the languages they can wrap their head around quickly and write elegant code swiftly to deliver a solution to the problem in a timely manner. Haskell might not solve all your problems. But c++ will, as will c, java, python, c# or basic. Because those languages don't have limitations. you put enough time into it, and they will solve any and all problems that are algorithmically possible to solve.
Ahem, pardon me for the late reply good sir, but you have made me, as the youngsters would call it, "fucking triggered." You don't have to read this, I'm more or less writing this to people who stumbled across your long comment and are crazy enough to read mine as well. Let's go over 3 things: Your assumptions about the power of the language Your assumptions about how niece the language is (how useful it is) Your assumptions about how hard the language is to learn Whenever I say "those languages", I mean C, C++, C#, Java, Python, Javascript etc. things you claimed are more useful The power of the language: I do not have a formal mathematical proof, a scientific experiment, or a research project. Yet, I will claim this: Every *statically typed* (part of a) program expressible in "those languages" is expressible in Haskell, but the other way is not true. I will not try to prove the first claim, but the second? Java has class constructors. Things that take a class and return a new one. Haskell has "class constructors constructors," and beyond. That means you can _transform_ a class constructor by passing it to another. This is not a niece ability. It is an absurdly powerful part of the language, for other people interested in Haskell, look up "fixing GADTs." This is one, single feature in Haskell that is not easily expressible without hacks such as code-generation. There are many more: RankNTypes, DataKinds, *DerivingFunctor/Foldable/etc.* , etc etc. One more thing I would like to point out is Haskell's type system. People say Haskell's type system is strong, not just because it is _very_ statically typed (whatever that means), but also because it can be crazily (and, honestly from my experience, creepily) talented in figuring out the type or _kind_ (basically, type of _type constructors_ ) of anything _without making assumptions_ . The type system is also known to be very strict, which is _good_ . Is the entire reason we adopted static typing not to prevent errors? How useful the language is: Let's look at some things Aeson, a JSON parsing library for Haskell hackage.haskell.org/package/aeson Here's a Haskell HTTP Client github.com/afcowie/http-streams A Game made with Haskell github.com/rainbyte/frag I will stop here for now, you can easily find more stuff online, but let's get to another point... What's the point? Why not use C? Why not C++, Java, Python, and any other language? Hell, we don't even need those languages! Let's use php for everything! Yeah. Maybe there's nothing "productive" (for lack of a more accurate word) that can be made in Haskell that can't be made in those languages. Then again, since all of those languages can be compiled, one can argue that everything that can be made in those languages can be made in assembly code. Let's drop everything else entirely and only use assembly languages. Yeah. Exactly. You know why those languages are "better" to write in. Because you've been learning them for fucking years, duh. I won't even bother explaining the benefits of using Haskell instead, as there are a ton of articles just waiting for _someone to look them up instead of pretending they don't exist_. That gets me to my final point... How hard the language is to learn: "I have an object oriented and procedural programming mindset, it's easy to understand and intuitive." One mistake, change the "it's" to "I find it," because you do. I find speaking Thai easy, because I'm Thai, I grew up in Thailand, and every single person around me when I was young spoke Thai. Now tell me, how well can _you_ speak Thai? You can't? Boohoo, it's easy, go learn it. Exactly. You went on about how you've started learning OO concepts since you were young, then you went on about how "easy" it is. Well, no shit Sherlock. Imagine how awkward it was for people to start learning OO when they were used to "goto" spams. You don't need to know maths to know Haskell. I can call a data constructor with a static member that lifts functions in a certain way a 'Functor' all I want, it is still just what it is. Why call it a Functor? Because otherwise it's a mouthful! But why use maths term? Why _not_ use maths term? We needed a word for it, the idea is inspired by maths, why not give mathematicians some credits? Have you ever been annoyed by all the different "else if"s you learn in languages? "else if" "elif" "elsif". Ever wondered why they didn't just use one? That's a lame example, but it's one I know you've ran into. There's more, things that _you_ know are the same but are called something different. Why? So that each language is "unique" because one calls a leg a leg while another one calls it a tail? There's no need for that, give credits where its due. I would like to finish this rant by talking about one more thing. "Haskell might not solve all your problems. But c++ will, as will c, java, python, c# or basic. Because those languages don't have limitations." Haskell does indeed have some limitations that those languages don't have. Namely, it is a pure language. But Java also has quite a limitation. I can't write the following code : "String aName = 3;" "But that's not a limitation! You can't do that because of type safety, and that's important because *yadeeyadee yada* and you can get around your niche use case with casts or *blablabla*" "Being pure is not a problem, you get stuff like equational reasoning and *yadeeyadee yada*, you can still simulate order of side effects with monads or *blablabla*" We put restrictions on ourselves, so that our compiler can stop us from doing stupid things. Aren't we _just_ mortal humans, after all?
![[TH] 2024 PMGC League | Survival Stage วันที่ 1 | PUBG MOBILE Global Championship](http://i.ytimg.com/vi/FVFT-PFwU80/mqdefault.jpg)
Interesting talk, as a side note: "spit, spit"(плевался, плевался) is translated from Russian as "to find disgusting/repulsive"
Does it literally mean 'to spit', or is it something close to a _spitting_ onomatopoeia?
@@mskiptr it is when you have a bad taste in your mouth and you want to get rid of it (taste).
"At first I spit it out and then I got used to it," like food that's an acquired taste
This is a great talk, I love to see companies along with more and more programmers see the light of many of Haskell's attributes. Haskell isn't the only way to get all these benefits, but it is currently the best! Haskell in production WORKS, you just need passionate developers who want to write robust and correct software.
People who think type errors are an annoyance sure must love running bugs on their client's machines lol. Like No Boilerplate said in their video on the Rust compiler, the only thing worse than bad errors is no errors.
Great presentation. My biggest barrier to using Haskell in production is how difficult it is to bind it to the platforms I care about. iOS/Android, and even web. There are some things that are working on this (especially web), but it still doesn't seem to be truly practical. It's very tempting to try to solve these problems and then use Haskell, but that's hard to justify the upfront costs, which is probably why it hasn't really been done.
You are right that Haskell should focus on these platforms more. As far as web goes, I really like the Haskell web frameworks such as Yesod, but they don't integrate with FRP systems such as Netwire.
This is a really old comment, but you might want to look into Clojure. It currently supports full stack web development and with recent developments regarding ClojureDart it may soon support cross-platform mobile development through Flutter. It's not a perfect replacement for Haskell, but with a strong emphasis on functional programming, immutable data structures, and easy concurrency it provides many features that a Haskell developer would appreciate.
@@allseeingeye93 Phoenix with Elixir has been a blast for web
Haskell has several Web frameworks now such as Warp, Yesod, Spock, Scotty, and even a haskell -> JS compiler to run in the browser.
That is an impressive rules based processing engine. Haskell. The engine seems to be applicable for many scenarios. Managing with policy and understanding and translating the policy bullets seems like the challenge step. I liked how she stated it just replicated out and reattached to the rules engine. They visualized this process in 1990. Wow.
Your post was about as unreadable as hello world in haskell.
@@techtutorvideos You forgot the "main :: IO ()" part. Why in the world do I have to tell the compiler that my program lives in the real world and is not just a mathematical abstraction? And why is line feed part of the function call???? Dudes, that is braindead. Having two different function calls instead of a control character is something that only depraved minds can even think up. You might as well be programming in Brainf*ck. ;-)
Someone please travel back to 2016 and adjust the podum mic for Katie 1.
Great talk! Nice to see how Haskell is used in production and giving us some hope that we can use it in our day to day work sooner rather than later,
Thank you Katie for using "Use case" and actually understanding what it means.
Simon Marlow presented Haxl at Chalmers University last month
Katy1 and Katy2 must be lua programmers
+Velox South Hey, Haskell arrays can be 1-based if you want!
@Mayu Okamoto Lua starts index from 1 instead of 0
That "spit. spit" means you hate something.
Wait. Where's Katie 0?
Is that nine hundred Hz a secret tone suitable to indoctrinate us into using Haskell?
Great talk! Great person!
Programmers learn and use languages like Haskell because somebody above them usually wants them to.... after all, if a language thats stable and been available for years (there are many, and most of us know what they are) can do what you need it to, why learn something else, especially if there is no guarantee it will do as you want?
Of course we all want to learn new things, thats how we progress, however, to have the desire to do that we need to know it will enable us to do more or to do better than with what we already have? Does Haskell? That is the question.
Oh how I disagree with the point at 38:18 - the compiler SHOULD yell at you here - that is important - if not then readability and maintainability goes down the drain. A good compiler should be strict and force you to stick to the rules in order to write code that exhibits the trait that two pieces of code that do the same should - more or less - look the same. This is the biggest problem with languages like Python and apparently also with this system!
Should that not be the work of a linter or something like that?
There are algorithms that are, for me, more natural to write in one fashion and others in another...
the solution for a problem that is non trivial in code can look a great number of ways. that is the art of programming.
¡ Like for a Visual Haskell in the future ! (GTK is hard to install, i can't do that jaja)
Check out Enso (Previously called Luna)
It's basically visual haskell
Nice talk, and pretty interesting. That being said I want to learn Haskell and I feel that one main point has not been addressed and that is what I would call the Elitism of the language.
I am a PHP programmer (mainly), and yes php has lots of problems, I'm not trying to say it's better than Haskell.
But one thing I really hate about Haskell (not specific to haskell mind you) is the elitism of the code. It's difficult to read and understand.
Most haskell code thrives to be "elegant" which is just another way of saying we crammed as much instructions as possible in the minimum amount of space, making it basically impossible to understand for an outsider.
Take pretty much any Haskell tutorial and look at the function arguments: 'x', 'y', 'z' , '(x:xs)', '(y:ys)' etc... and this is considered standard practice. Why can't you give your parameters meaningfull names ? Can you at least comment your code to help me understand ? No ! How am I supposed to know what those parameters stand for ? Answer: I can't, I have to go read some kind of Documentation somewhere explaining what they are supposed to be, and generally that documentation just makes me feel dumb because I can't understand half of it so it generally boils down to "If you don't have a Phd in Mathematics and don't fully understand what Lambda calculus is, you are not worthy of using this code".
Wheras in reality using meaningfull parameter names, adding some comments in the code and using a more explicit way of doing things would have enabled me to understand what the function does without even the need for documentation. I Hate this, I believe good code should be understandable by pretty much anyone, ideally even someone with no programming background should be able to get the idea of what is going on by reading the code.
The prime example of this I feel is if/else vs ternary conditions, or explicit return statements vs directly returning the result of an operation in parenthesis. Yes the code is more elegant and requires less lines, but at the end of the day it doest exactly the same thing and is inherently less readable. If I show a simple if/else condition to my wife, she will probably get it, whereas if I show her the exact same condition in ternary form she doesn't have any chance at all of understanding what the code does.
There it is, that's my little rant about Haskell and can definitely be applied to many other languages but I do feel Haskell is one of those languages that goes the extra mile to make sure that people who are "unworthy" are not able to understand the source code.
I haven't finished watching this talk yet, but already what I have seen amounts to a kind of response to at least some of what you say here. You say that explicit return statements are more readable than ternary conditionals / not using explicit return statements. But as the talk points out, the reason why you think that's more readable might have to do with your background and prior coding experience. Someone who hasn't done any coding in imperative languages, but who has been exposed to functions in math in primary or secondary school, may find it more intuitive that the function `f`, as defined in Haskell by `f x = x`, is the identity function --- it looks, after all, just like the f(x)=x in math.
I'm not saying that everything about Haskell is easier to understand for someone w/o programming experience. But I do think that it's at least not obvious that things like explicit return statements are always easier to understand, and that, as the talk observes, one's perception of what may or may not be confusing might be influenced by one's prior programming experience.
Thank you for the truth about the Haskell!
Great video!
Are the slides somewhere publicly available?
thanks
So what sort of tools, IDEs are used in Facebook for Haskell?
She says in the presentation that she uses ghc and VIM
Jeremy List I know she uses GHC and VIM. I use GHC as a compiler as well and sublime text as a text editor but that is pretty much it. I don't have a lot of idea about powerful command line Haskell tools that work with a Graphical front end of IDEs like Leksah or a Visual Studio plugin or a Jetbrain plugin etc.
Don't know what sort of other tools they use in Facebook with Haskell other than the regular GHC, Cabal etc. Like tools for debugging, profiling, testing and automation etc.
***** I used to use that plug in as well. It is a fantastic plugin except it did not highlight the syntax properly if a variable name or something had a prime (') character somewhere in the middle. May be it is fixed by now but overall it is a fantastic plugin.
Eddie Atom - Haskell-IDE
Eddie Seriously Haskell's ghci (in the form of haxlshell) and some neat Vim plugins is really all you need! (Though I now use Stack for my own projects because it makes builds really a lot easier)
shit, I saw my id there! co-dh
Ultra white user? was that Simon Peyton Jones?
In summary, every preconception you have about Haskell is true.
Languages are suited for their domain, the benefits if functional programming languages are only there of you have bunch of code to to run in parallel( coz that's where the benefits of pure kick in that you can parallelize) , when you are caching the requests and when you are writing some thing very high level like rules engine where even frequent changes in imperative language would be costly. I don't know why people need to jump the gun and exaggerate. They can simply present the differences in plain and easy style and not try to generalise.
from the sentence "the benefits if functional programming languages are only there of you have bunch of code to to run in parallel" I can tell you have never written a substantial program in any serious functional programming language. The selling points of functional programming have very little to do with parallel, although making parallel code easier to write is one of the many wins you get with purity. Emacs is not mostly written in lisp because of parallelization. My first two years of programming in Haskell I did not write a single multi threaded program and I can confidently say for all of them Haskell was the best tool for the job.
Isn’t Haskell just machine code in disguise?
What? No.
id say polar opposite
All programming languages are machine code in disguise. That doesn't mean they're the same. The abstractions that each language builds on top of machine code is what matters.
In the same sense that croissants are wheat in disguise...
Haskell is the new Perl: write once, read never.
i wish i could be on her team lol
Right?
Steven Nguyen not with those ears tho lol.
I'd take c++, c, c#, even java, python or even fucking visual basic over something so convoluted and unintuitive any day.
You are pressing a problem into a language that can be solved with any number of languages. and because your one example works with haskell still doesn't make it a viable programing language at large. people will use php or asp for server side programming, c#, c++, c, basic or python for general purpose programming and javascript and such for client side programming. anything else really is niece.
I mean industry works like this:
- Have a problem.
- Need an automated solution to the problem.
- Analyze the problem
and here you select the language to use to solve the problem. will you spend time (money) learning something new, potentially only suited to that one single problem? or will you select a language that your employees already know and work with every day to solve any problem you can possibly solve algorithmically in the first place?
Surely the answer is simple. you get a niece problem that can be solved with a niece language, or perhaps less elegant in a language you are already familiar with, but faster, then industry will always choose the second option. who wants to spend time learning something they use once only? especially where that would cost thousands of dollars for essentially doing nothing productive, and then perhaps find out that this or that is not doable because of limitations.
coming from qbasic at the age of 8, i could easily pick up a c++ book and learn it rather quickly in my spare time. then going to pascal in school, again easy to learn. then java in university, same thing. then MC6809 assembler, different, but knowing how c translates into machine code made it simple to pick up as well, the concepts are the same, function calls are easy to implement, variables, stack, memory pointers, registers, all the same thing really. first in minecraft, then in logisim i found a hobby at doing some 'hardware engineering', building this and that logic circuit, again the mindset is already there, thinking logically about instructions and how to combine transistors to logic gates, and logic gates to multiplexers, and all those modules you already have to make something larger like an ALU. at work i now work with c#, which I had no experience with before. within a week I learned and wrote a program that works with bus systems and databases, expanding on it and adding functionality to it ever since.
And now I see this and think, what the fuck is wrong with people? this resembles nothing of the above. it's math and formal languages pressed into a pancake that tries to be programming.
I have an object oriented and procedural programming mindset, it's easy to understand and intuitive. It wouldn't cross my mind to go to something that forces me to bend my mind just to get behind the idea of it. I need to think in instructions and code and it needs to come naturally, something I just couldn't do with something this backwards. It's the same as using base root(15.7) as a number system. useless except for very few niece applications, and hard to wrap the mind around.
Side effects can be useful, and even desirable. Disallowing them inhibits the freedom of the programmer. If you do not wish for side effects, then sticking to a few basic guidelines prevent them.
a = b + (i++); is the same as
a = b + i;
i = i+1;
and nobody in the right mind would write the first line, it's confusing, but possible. but should it be forbidden? i think not.
even worse
f(someBool && (i++) == 5)
a nightmare. i will only increment if someBool is true, or if some specific compiler settings are set. but again, people don't do that sort of stuff.
any oop language, and c like language have strong typing. i don't see how that's any better than those. python or javascript are a clusterfuck though. still i am able to wrap my head around them.
class Id {private int ID; public int getID(){return ID;} ...}, strong typing, easy in oop languages. no haskell needed for same results. no one is gonna bother though, because you have names. even the most dumb monkey wouldn't confuse a variable name ID with something like breadrollsIHadThisMorning. To encapsulate a simple number into an object is possible and would have the same effect, but no one would really bother unless there are some critical requirements. usually classes would be used to create complex data types.
right. teaching: just don't teach the language, just teach the simple stuff.
try teaching c without structs and enums. or c++ without classes and overloading. sure you can still write your hello world, but it's just prohibitive to not know what tool you're working with.
By the way, did you know the linux kernel, or any kernel, has no haskell code in it? I don't know even a single program at work or at home that runs haskell code. From what I can see, it isn't really suited as a program in itself anyway, but rather only as a layer between input and output. can you query a database? or can you even read a keyboard input? I don't know. What even is a keyboard to haskell? even the most basic concepts don't apply.
When you say challenges, what you mean to say is problems. You have a new problem, haskell might be suitable, but no one knows, because nobody in the imaginary firm has experience with it. But they know the problem can be solved in what the firm's programmers are experienced in, say dotNet. Will they decide to learn the new, foreign and different language, basically from scratch where prior mindsets and ideas don't apply? fuck no, they won't. they will use the tools they are familiar with, the languages they can wrap their head around quickly and write elegant code swiftly to deliver a solution to the problem in a timely manner.
Haskell might not solve all your problems. But c++ will, as will c, java, python, c# or basic. Because those languages don't have limitations. you put enough time into it, and they will solve any and all problems that are algorithmically possible to solve.
Ahem, pardon me for the late reply good sir, but you have made me, as the youngsters would call it, "fucking triggered." You don't have to read this, I'm more or less writing this to people who stumbled across your long comment and are crazy enough to read mine as well.
Let's go over 3 things:
Your assumptions about the power of the language
Your assumptions about how niece the language is (how useful it is)
Your assumptions about how hard the language is to learn
Whenever I say "those languages",
I mean C, C++, C#, Java, Python, Javascript etc.
things you claimed are more useful
The power of the language:
I do not have a formal mathematical proof, a scientific experiment, or a research project. Yet, I will claim this: Every *statically typed* (part of a) program expressible in "those languages" is expressible in Haskell, but the other way is not true. I will not try to prove the first claim, but the second? Java has class constructors. Things that take a class and return a new one. Haskell has "class constructors constructors," and beyond. That means you can _transform_ a class constructor by passing it to another. This is not a niece ability. It is an absurdly powerful part of the language, for other people interested in Haskell, look up "fixing GADTs." This is one, single feature in Haskell that is not easily expressible without hacks such as code-generation. There are many more: RankNTypes, DataKinds, *DerivingFunctor/Foldable/etc.* , etc etc.
One more thing I would like to point out is Haskell's type system. People say Haskell's type system is strong, not just because it is _very_ statically typed (whatever that means), but also because it can be crazily (and, honestly from my experience, creepily) talented in figuring out the type or _kind_ (basically, type of _type constructors_ ) of anything _without making assumptions_ . The type system is also known to be very strict, which is _good_ . Is the entire reason we adopted static typing not to prevent errors?
How useful the language is:
Let's look at some things
Aeson, a JSON parsing library for Haskell
hackage.haskell.org/package/aeson
Here's a Haskell HTTP Client
github.com/afcowie/http-streams
A Game made with Haskell
github.com/rainbyte/frag
I will stop here for now, you can easily find more stuff online, but let's get to another point...
What's the point? Why not use C? Why not C++, Java, Python, and any other language? Hell, we don't even need those languages! Let's use php for everything!
Yeah. Maybe there's nothing "productive" (for lack of a more accurate word) that can be made in Haskell that can't be made in those languages. Then again, since all of those languages can be compiled, one can argue that everything that can be made in those languages can be made in assembly code. Let's drop everything else entirely and only use assembly languages. Yeah. Exactly. You know why those languages are "better" to write in. Because you've been learning them for fucking years, duh. I won't even bother explaining the benefits of using Haskell instead, as there are a ton of articles just waiting for _someone to look them up instead of pretending they don't exist_. That gets me to my final point...
How hard the language is to learn:
"I have an object oriented and procedural programming mindset, it's easy to understand and intuitive."
One mistake, change the "it's" to "I find it," because you do. I find speaking Thai easy, because I'm Thai, I grew up in Thailand, and every single person around me when I was young spoke Thai. Now tell me, how well can _you_ speak Thai? You can't? Boohoo, it's easy, go learn it.
Exactly. You went on about how you've started learning OO concepts since you were young, then you went on about how "easy" it is. Well, no shit Sherlock. Imagine how awkward it was for people to start learning OO when they were used to "goto" spams.
You don't need to know maths to know Haskell. I can call a data constructor with a static member that lifts functions in a certain way a 'Functor' all I want, it is still just what it is. Why call it a Functor? Because otherwise it's a mouthful! But why use maths term? Why _not_ use maths term? We needed a word for it, the idea is inspired by maths, why not give mathematicians some credits? Have you ever been annoyed by all the different "else if"s you learn in languages? "else if" "elif" "elsif". Ever wondered why they didn't just use one? That's a lame example, but it's one I know you've ran into. There's more, things that _you_ know are the same but are called something different. Why? So that each language is "unique" because one calls a leg a leg while another one calls it a tail? There's no need for that, give credits where its due.
I would like to finish this rant by talking about one more thing.
"Haskell might not solve all your problems. But c++ will, as will c, java, python, c# or basic. Because those languages don't have limitations."
Haskell does indeed have some limitations that those languages don't have. Namely, it is a pure language. But Java also has quite a limitation. I can't write the following code : "String aName = 3;"
"But that's not a limitation! You can't do that because of type safety, and that's important because *yadeeyadee yada* and you can get around your niche use case with casts or *blablabla*"
"Being pure is not a problem, you get stuff like equational reasoning and *yadeeyadee yada*, you can still simulate order of side effects with monads or *blablabla*"
We put restrictions on ourselves, so that our compiler can stop us from doing stupid things. Aren't we _just_ mortal humans, after all?
tuchapoltr thank you for refuting this ignorance!
This is exactly the kind of comment thread I expect to find in a Haskell video 🤣