Haskell is a great programming language that can be used in any domain. Ideally, it is best suited for business and logic relating to data analysis...
For further actions, you may consider blocking this person and/or reporting abuse
Mutable state is the bane of consistency - that is true! Haskell keeps it to a minimum? Then I should learn too... thanks, Trisha!
You may have happier time trying Erlang. It also has no variables :) so no mutable state. Nor loops. Very easy. But unlike Haskell it is not strictly typed so it is much easier to start coding without being swamped by monads.
You might not be completely serious, but I feel compelled to say you're not doing justice to both Erlang and Haskell. :)
One (major) thing about Erlang is it models mutable state with process' state ("state on parameters" of recursive functions). Another thing about Erlang is it has very much traditional mutable state in the form of ETS tables which are employed very extensively in real production code (and I don't consider this a "bad thing").
And as long as you don't use state in Erlang in either form, you can do exactly the same in pretty much the same way in Haskell without monads anywhere remotely near.
Besides, strictly speaking Erlang is strictly typed, albeit dynamically. Dynamic typing is a minor shortcoming which is alleviated by Dializer. :)
And finally, using monads is simple! Even writing monads isn't hard though very rarely needed. Lenses is where all the fun begins and never ends! :D
Alexander, Hi!
I think I'm too stupid to understand most of the things you've mentioned :)
But I totally agree! It's hard for me to judge about either as I was not in any industrial project using Haskell - and the one with Erlang was too specific in many ways :)
I suspect it is about the tool "dialyzer"? I found this one and tried to make my colleagues using it. That was hard, mostly because dialyzer is still in far not excellent form. And as the language seems to be slowly dying, regretfully, no much hope it will be seriously improved.
Ah, all proponents of Haskell / Scala insist on something like this. Probably this simplicity is why so many articles and videos are trying their best to "explain monads in 5 minutes", generally failing to impress :)
I'd like to see what they will invent by next 10 years :)
Yep, that's what I meant. :)
Last time I wrote in Erlang Dialyzer checking was built-in into VS Code plugin so I need no extra effort to reap its benefits. 🤷
Actually you're exactly up to the point. :) People write the most about what's simple: "Write yourself a blog engine in PHP/RoR/Django", "Make an animation with CSS3", "Build a game with Unity". How many tutorials "write an intrusive concurrent AVL-tree in C" do you know? 😄
Unfortunately doesn't seem like much, Haskell is close to a "saturation point". The two biggest next additions to the Haskell are Linear Types and full-blown Dependent Types. The former were invented more than 30 years ago (at least Linear Logic was), the latter were invented almost 50 years ago and first implemented more than 30 years ago.
It's just most of programming languages still fail to improve upon Lisp that was invented more than 60 years ago... 😄
Well, that's question what we define by "improvement". In the sense of business software development they improved thousand times. Not only about languages themselves, but about infrastructure around them.
Even Lisp split to zounds branches, warring to be more functional or more practical or both :)
However in the sense of the language structure, system of typization etc really progress is not impressive.
BTW, if you are curious about Haskell position - the company I mentioned is "Biocad". Check their HH - they are nice fellows and would be glad at least, I think. Though probably you know them already since Haskell world is tight enough :)
I meant in terms of language features and semantics as I'm kinda PL geek. :)
I totally agree infrastructure improved a lot.
Yeah, I've figured that out. As you said
😄
Thank you!
Hey, another reason to learn both Haskell and Erlang!
Hahaha, I use that every day. But I also use Kotlin.
Not necessarily, it's a fact of life in most domains, but it does provide a rich toolkit for organizing and sequestering the mutable and effectful parts of your code.
If you're referring to mutable state, then it's irrelevant whether it's a fact of life or not. Because in software development we're modelling real-life domains. And we can easily model mutable state with immutable data structures and pure functions. Surprisingly often it leads to both fever errors and simpler code.
This is exactly why side effect-free coding by default is so valuable: it’s far easier to verify correct behavior.
True, but the good thing is that it requires a lot of focus as it is a hard language for most people.
Anytime!
Hi Trisha!
Thanks for that gentle introduction :)
I hope you won't mind my sharing my experience with the language?
In my city (5mln population) there are no more than 3 companies hiring Haskell developers. I tried to apply to one of them. They gave me offline test project. I struggled with it for about a week and have done something. I succeeded (it was a kind of web-application which stores chemical components and their relations in the graph database).
However after it:
Why I thought so? As you told - language is quite difficult for beginner.
Firstly - it is overburdened with abstract notions of type and maniacal preservation of type purity. That's true that strict typing simplifies error prevention in large projects - but this shouldn't come at price of pain when trying to do something which is easier with types relaxed (dealing with Json for example).
Secondly - despite all it is still not quite mature. Many string types just hint how bad things are. There is some choice of tools for building, testing, linting - but far not great.
Thirdly - it just doesn't add anything interesting. Compare with Erlang - which has threads out of the box and messages between them.
So my conclusion - just strictest typing doesn't make good language. Go will be much more popular in this field. And just boasting the language is pure functional - it isn't worth much, because far not all programming tasks well suit functional design.
First of all, let me explicitly state that I'm not trying to make fun of you in any way! As far as I can tell you're a mature experienced developer and I fully respect that. But I strongly disagree with pretty much all the statements you've made in the comment, so for the sake of alternative view for other readers I'll comment on them. Please forgive me if I will sound harsh. No offence intended!
Let me restate it: you tried to apply for a middle/senior position without prior experience with the language at all and you were surprised to get a reject? Frankly speaking I don't know any company that will hire for a middle/senior position without industrial experience in the language, and if there are such companies I'm very suspicious about them.
Disclaimer: I'm a "person with ready industrial experience in Haskell" now working as a C# developer.
Then your critique of Haskell is very subjective at least and sometimes just plain wrong.
That's an example of a subjective judgment. And a relative one in addition. The same could be said about Design Patterns in Java and C#, it's a common place to complain about "abstract factory of abstract factories". Or obscurities of Dependency Injection frameworks and so on.
And dealing with JSON could be done in Haskell easily with precisely "types relaxed" as exemplified in a great blog post.
If that's a measure of maturity, then what several kinds of equality comparisons in JavaScript and PHP tell us about these languages?! Is the fact that plain string concatenation is very inefficient in Java and C# and one should reach for a
StringBuildera sign of immaturity of these languages?Or should we compare with Erlang where there's even no libraries for comfortably working with Unicode strings? ;)
For Haskell beginners reading this:
Stringin Haskell isn't actual string data type, that's just for educational purposes.ByteStringsandTextlibraries cover both actual use cases for the production use of strings very efficiently (better than in many other languages).What about Software Transactional Memory? Not mentioning Parallel Strategies for very high-level program parallelism. Though my favourite is Lenses which gives insanely powerful and practical data query and transformation tools way beyond imaginable in any other language (save for PureScript).
So my conclusion would be that Blub Paradox is very much a thing still. :)
Again, I'm not trying to paint you stupid or something. But I do think you spent too little time and effort with Haskell, learned too little and jumped to very far-fetching but unjustified conclusions in this case. And I've tried to justify my claim with some arguments, that's all.
Oh, no problems about it :) You are pretty correct, it's better to have professional thoughts here!
Honestly, I'm afraid you slightly misunderstand situation :) See, these fellows knew well I have no experience with Haskell, right? Nevertheless they invited me to interview, spent their time etc... Then offered the test project, spent time on reviewing it again etc...
So you may suspect they don't have a lot of choice :)
That is general problem of every team which chooses to use some rare language. I was previously hired as senior erlang dev coming from java/bigdata world.
Frankly speaking I'm suspicious at all about companies which choose the language for which they know it would be hard to hire developers. :)
Holy truth. The lists of design patterns are also a good example of trying to invent more abstraction than we usually need. You may have noticed there are some patterns known to almost everyone - but full lists may include quite whimsical and unheard of things.
It's the same with UML for example. At least few years ago people were praising it highly, but over time it occurs that no one really cares to learn its full extent because others don't learn it too. Hard to explain things with clever diagrams which others don't understand due to their cleverness.
No objection to that again! You are pretty correct :) But we expect Haskell to be different from those, right?
To clarify: I don't object Haskell "as it was conceived". I first heard of it (and even tried some windows version) probably about 20 years ago. It seemed queer but cool.
However I don't expect good outcome from attempts to marry Haskell with needs and purposes of industrial software development. They just have different goals.
That is less or more correct, I think :)
I just am trying to point out that programming languages nowadays don't live in their own universe. They need community to build libraries and tools. Community needs salaries, so needs business projects. If for some reason it is hard for language to win a lot of proponents - it becomes harder to evolve. So it is a thing to consider for language designers - how are we going to attract people.
Well about "own universe" it is not quite correct. There are languages created for amusement, or for some specific study. They don't need to rely on business, of course :)
Adding on to what you were saying about companies - Yes, technically speaking tech companies do hire people who know how to program and will benefit the company; however, it's more about the quality of work they can produce.
Like you said before, Haskell isn't a language most companies would choose to use when hiring their employees. They need people with more experience and passion. In addition to that, Haskell is pretty functional but I do agree that there are many other languages that are also beneficial.
According to my research, some programmers don't use Haskell, some used Haskell in the past, some still use Haskell and some programmers and never even heard of Haskell. So it depends on the ability as well as the strengths and weaknesses in every software engineer's career path.
Of course, not every programmer is at a high level of coding. One of the first programming languages I started learning was Python and I still use it for the same purposes as I used to.
By the way, Haskell isn't the language I code in. I do use it a lot for research and my data analysis work. But I use many other languages as amusement and for important obligations. I will admit I do use Haskell for fun seldom when I'm under ennui. Whenever I'm feeling lethargic I run Haskell programs on my laptop. Many Haskell programmers used to use GHCI to run Haskell programs, I use VSCode to run programs in other languages. I'm sometimes able to improve the program's performance. I used to do that a lot while I was self-teaching myself Haskell.
Although, I do appreciate your comment! Feel free to let me know what you think :)
Hi Trisha!
Could you by the way, in some future post, tell more about your work / research / interests as your comments leave us slightly bewildered and curious at the same time, because you pinpoint some important thoughts which, though supposedly simple, are sometimes so hard to explain to managers and leads... :)
I hope this doesn't sound impolite!
Not at all, I'd be happy to!
I'm answering to @rodiongork comment, but I see no way to reply directly to it, thus attaching my answer here...
Reassuring to hear that! But I know from personal experience that comments in Internet might sound cold and harsh even when author intended nothing like that.
And yet again I'm going to state arguments seemingly contrary to what you're saying. :) But I'm not trying to prove you wrong and "defend Haskell". For one thing I don't think Haskell needs my defence. :) Second, I don't professionally develop in Haskell anymore.
What I'd really like to achieve is to make "perpendicular" arguments and move the discussion from "Haskell vs. Java/C#/etc." dichotomy into broader plane, or better yet into 3D space and have a perspective that includes much more details. 😃
Again that says nothing about programming languages but something about hiring process in the organization. I had my share of strange and seemingly meaningless interviews that led to wasted time from both ends only. Applying for positions in different languages. Mainstream ones.
That supports my point that the question is much broader than just choosing a programming language. It's a truism that any technology has it's good and bad sides. But the processes are objectively good (efficient) or bad (wasteful), and it's up to management that devise and perform these processes whether to improve them or not. They call it "corporate culture" or even "company DNA" nowadays, and it has nothing to do with programming languages. :)
Exactly! Do you have an idea how hard it is to hire a decent (middle/senior) level Java/C# or worse yet JavaScript or PHP developer? Signal-to-noise ratio is abysmal! And the best ones are already very well employed so it's next to impossible to attract them. Would you apply for "another Java/C# position"? Probably not.
So hiring Haskell/OCaml/PureScript/Rust/Scala developers is easier in many regards. I'm not saying it's easy, but the set of tradeoffs is completely different.
We were talking about maturity. To me "language maturity" is about quality of compiler and runtime and backwards compatibility of the language.
In the terms of runtime Haskell is on par with Erlang, Go, HotSpot JVM and .NET Core, the most mature language runtimes available. It implements excellent support for N-to-M concurrency on par with Erlang and Go (arguably even better). Nowadays there are two Garbage Collectors, both parallel, the new one even concurrent. Not mentioning almost unique best in class Software Transactional Memory support.
Again, compiler is on par with C/C++ compilers: in some aspects it's even better due to guaranties of purely functional language, in others it's lagging behind due to insufficient efforts invested, but not that far.
And the language is fully backwards compatible. You can still easily write everything in Haskell'98, or better Haskell'2010 if you absolutely want to stick with standardized part.
The whole deal is so much better than with Python, Ruby and JavaScript it's a bit ridiculous to me to talk about maturity of Haskell compared to such a mainstream languages.
As for "industrial software development" in Haskell it has been happening for a decade already and only grows bigger. I don't want to list the companies, they are pretty well-known for a big part. Industrial Haskell is a boring fact for quite some time.
Actually the community is huge! 😃
What Haskellers complain about nowadays is there are too many libraries - too many dependencies, too long the build time. First world problems! 😃
Another data point, we'd organized a Functional programming conference last year (in Russia) and there was serious competition among Haskell talks. We had to reject several of them because we wanted a general FP-conference, not a Haskell-exclusive one. This year we have even more Haskell talks already, and they are from people working as professional Haskell developers in industry. I bet many of attendees are as well.
Thus my bottom-line. Looking in a broader context Haskell is another well-established and battle-tested production-ready tool with associated community, practices and trade-offs both technological and social ones.
The only issue is it's relatively unheard of outside of FP community. But that's not a Haskell-the-language problem, and I'm not sure it's a big of a problem at all.
Hi Rodion! Yes, I do agree that Haskell is a hard language just like any other programming language; however, it is efficient and well structured. It is really hard to learn depending on what level you are in programming. When I say level I don't mean the standardized level system - beginner, intermediate, advanced. I mean programmers who can code at a faster speed than others. Technically speaking, you may not be a bad Haskell programmer; however, the expectations and competition for tech jobs are incredibly high that even some of the best programmers don't make it. It's a fact, CS is difficult but don't let that discourage you, as long as you can do the job and follow up you'll be fine!
Wow :o , what a language to start with, congrats for not becoming crazy!
lol I use others also
I would say I am not convinced by the arguments you provide 😉
XD
precisely