#and I think coming at it from a more mathematical mindset having studied linear algebra last year really helps

[klavierpanda]

Yet another case of pop science warping the impression of physics in a negative way: spin in quantum mechanics.

I've spent this afternoon reading the relevant notes for my quantum mechanics lectures next week which are about spin. And actually it's not this allusive thing that makes no sense like it's so often portrayed as. Yes, it required a lot of work to get to this point but going through the maths and the motivation it actually makes a tonne of sense.

Seeing the maths and formalities behind quantum mechanics makes all the weird properties seem more intuitive. Yeah, they're bloody weird because we don't experience them on the macroscopic scale and so don't have much of a feel for them. And don't get me wrong, them being present as weird gives QM it's charm and certainly got me interested which is the whole purpose of pop science. But I feel like the way quantum mechanics is presented makes it seem very inaccessible and I feel like there is a way to present is in a more accessible way without requiring all of the maths.

I guess what I'm trying to say is I wish we would talk about the weirdness of quantum mechanics as a cool quirk more so than a barrier to understanding it.

[romanandreg]

Introducing Haskell to your Company

I've heard time and time again about how Haskell may be a risky technology choice for business. Some companies might be in a situation where this statement may be true, however, in the end, is always a matter of "it depends."

I would like to explore some of the points that companies may go through before picking Haskell (or any other language for that matter) and distill different strategies that may mitigate the risks of using a new language/stack.

Haskell developers are hard to find

There is no denying that finding Haskell developers can be tricky; however is not impossible, here are some strategies that your company recruiters can try out:

Hire remote developers

There is a big pool of Haskellers around the globe that are looking for an excellent shot to work on Haskell, but haven't found one in their city.

Get acquainted with your local Haskell Meetup

The same people that are looking to work remotely on a Haskell gig are likely to be participating in the local Haskell Meetup, and even though they are not looking for a new job, they might feel tainted to work at your company if you bring Haskell into the equation.

Advertise Job Positions in well-known functional programming channels

For Haskell, some of the channels I would recommend are:

Functional Jobs This page is a great spot to advertise jobs in any FP language (Clojure, Scala, Haskell, OCaml, etc.)

Haskell Weekly An excellent source of news and articles for Haskellers, it provides a space for advertising Haskell jobs (The postings don't last very long which may be a good sign).

Sponsoring an FP Conference Some functional programming conferences provide a great space for advertising your desire to hire Haskellers, some of the most popular ones are:

Curry on

Compose Conference

LambdaConf

Host Public Haskell Study Groups

Now is more approachable than ever to start a study group to learn Haskell, there are proven guidelines on how to run one and also well-established study materials. Making people learn Haskell together is also an excellent opportunity to grasp participants skills to teach others as they learn the language.

As it was the norm with Python a few years ago, it is likely that the Haskeller you hire will be a very competent developer. Whoever learns Haskell is plausible she would be a very passionate and motivated individual and understands the repercussions of side-effects pretty well.

You might be saying that these strategies are not so different from the ones you would use when trying to hire developers in other languages (and yes, that's the point I'm seeking to convey).

Is important to bear in mind that if you are looking for a skilled senior developer in any technology, the search will still be challenging. For example, some companies where I've worked before spent months (some cases a year) to fill a Ruby or Java position.

Haskell concepts are hard to understand

Many friends that have attempted to learn Haskell complained about how hard is to understand the core concepts, and I completely understand their pain. Haskell is a challenging language given how different it is to other mainstream languages; nevertheless, I argue that once you get into an advanced beginner level, the leverage you get in comparison to other languages is quite substantial. How so? Haskell in nature is a very constrained language, not giving you "enough rope to hang yourself"; many of the common pitfalls other languages have by providing "easy" (not simple) APIs will just not happen in Haskell; bye-bye null pointer exceptions.

How can we mitigate the onboarding pain? I think first and foremost we need to acknowledge the Haskell pyramid effect. Paraphrasing what Steven Syrek says in one of his posts:

Haskell is capable of representing extremely abstract mathematical entities, but so is math itself, and you hardly need to understand linear algebra to balance your checkbook.

On the same lines, you don't need to know Category Theory to do a Web APIs with Haskell.

Secondly, we need to acknowledge that most of the interfaces in Haskell are very abstract, and humans (sadly) suck at fully grasping those on the first attempt. You'll need to allow mentees to digest an abstract idea a few times (no, your "Monads are like burritos" blog post won't help), and see many different concrete examples of an abstraction before they can understand it fully. Luckily there are resources like The Scala Red Book and The Haskell Book that you can use as resources to do study groups and go one step at a time into the fascinating world of FP.

My company cannot afford to invest in new tech

The first thing to keep in mind is: If your company is working on a Monolith architecture, it makes no sense to invest in any other technology, is simply not viable for any business to "reimplement all the things" in a new language.

If on the other hand, a Microservice architecture is in place, there may be wiggle room to implement some parts of your system using a new stack as long as you don't have the "too many technologies" problem already[*].

[*] I like to imagine adding every new language to a company as tearing the company's soul apart, like Horcruxes

The trickiness comes when developing applications on an entirely new tech, is not just the challenge of a new language, but all the operational costs that go with it:

How can we debug Haskell code when things go awry?

How can we track garbage collection, memory allocations, performance, etc.?

What options do we have to deploy Haskell applications?

Is the library ecosystem mature enough to cover my business requirements?

All of the above are valid concerns that you need to address and sadly you cannot give reliable answers unless you have done production Haskell somewhere else and had the scars to prove it. If you are not experienced in production and got enough people interested in working with Haskell, try to tackle non-risky projects and assess how you would do the operations around it, make failures be less expensive for the business and learn as much as you can in the process.

Also, it might be a good initiative to provide example projects that showcase how you would tackle Real World™ challenges (HTTP APIs, Usage of AWS/GCE, etc.). These codebases will give guidance to less experienced developers on how to get started and let them feel empowered and productive.

Does this sound like a lot of work? You bet. When advocating a new technology inside your company, you unofficially start having two jobs.

Haskell is more of an academic hobby language right?

I've heard this one before despite the fact that Haskell has been around for the past 20 years, and big companies trust it for fundamental concerns of their business. There is also many stories of companies with some levels of success in Haskell.

Haskell is a language that started as an investigation project trying to answer the question: can laziness be used in production settings for profit? (spoiler alert, not so much). However, in the past ten years, it has had lots of production quality libraries developed on top of the Glasgow Haskell Compiler (GHC), conduit, ekg, wai/warp, async, stm to name a few.

I can argue Haskell is great if you are trying to do performant HTTP servers, reliable CLI applications, and systems which need to excel in parallel/concurrent environments.

People are afraid of change

I've had experiences where some people are very afraid of trying Haskell given how different it is, sometimes they go as far as to reflect there is something wrong with me for not going with standard mainstream languages like C/C++/Java.

Dealing with developers in this mindset is a bit tricky, most of the times this would be the well cherished cynical developer that doesn't believe in silver bullet solutions (and that is great). Starting with an honest conversation about the weaknesses of Haskell and then go on its virtues is a good start to get them going. Move the conversation to more of facts vs. passion argumentation, and you and this person will learn way more about the language.

Conclusion

Here are some non-extensive bullet points on how to get Haskell started at your company, do you think I missed something obvious? Please feel free to share comments and impressions; I'm always in the quest of spreading Haskell knowledge into people so that the language can gain more traction in production settings and your feedback may help in this quest, so highly appreciated.