DEV Community

Discussion on: Switching to Haskell

Collapse
 
rodiongork profile image
Rodion Gorkovenko

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:

  • they told they will prefer to search for person "with ready industrial experience in Haskell" (very funny, provided there are almost no people or companies using it)
  • I myself decided language is not worth further trying.

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.

Collapse
 
gabrielfallen profile image
Alexander Chichigin

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!

they told they will prefer to search for person "with ready industrial experience in Haskell" (very funny, provided there are almost no people or companies using it)

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.

Firstly - it is overburdened with abstract notions

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.

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)

And dealing with JSON could be done in Haskell easily with precisely "types relaxed" as exemplified in a great blog post.

Secondly - despite all it is still not quite mature. Many string types just hint how bad things are.

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 StringBuilder a 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: String in Haskell isn't actual string data type, that's just for educational purposes. ByteStrings and Text libraries cover both actual use cases for the production use of strings very efficiently (better than in many other languages).

Thirdly - it just doesn't add anything interesting. Compare with Erlang - which has threads out of the box and messages between them.

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.

Collapse
 
rodiongork profile image
Rodion Gorkovenko

Please forgive me if I will sound harsh.

Oh, no problems about it :) You are pretty correct, it's better to have professional thoughts here!

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?

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 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.

Frankly speaking I'm suspicious at all about companies which choose the language for which they know it would be hard to hire developers. :)

The same could be said about Design Patterns in Java and C#

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.

If that's a measure of maturity, then what several kinds of equality comparisons in JavaScript and PHP tell us about these languages?!

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.

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.

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 :)

Thread Thread
 
trishaganesh09 profile image
Trisha

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 :)

Thread Thread
 
rodiongork profile image
Rodion Gorkovenko

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!

Thread Thread
 
trishaganesh09 profile image
Trisha

Not at all, I'd be happy to!

Thread Thread
 
gabrielfallen profile image
Alexander Chichigin

I'm answering to @rodiongork comment, but I see no way to reply directly to it, thus attaching my answer here...

You are pretty correct, it's better to have professional thoughts 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. 😃

Nevertheless they invited me to interview, spent their time etc... Then offered the test project, spent time on reviewing it again etc...

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. :)

Frankly speaking I'm suspicious at all about companies which choose the language for which they know it would be hard to hire developers. :)

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.

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.

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.

They need community to build libraries and tools.

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.

Collapse
 
trishaganesh09 profile image
Trisha • Edited

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!