I haven’t used Haskell professionally so I can’t actually weigh in on the veracity of the prominence of difficult-to-learn code. I do know about using another “weird” language though: Common Lisp. We at Rigetti took a bet with Common Lisp and it passes the “senior-written idiomatic code can be junior-learned and modified” smoke test with flying colors. Every group of interns and every new grad that has become involved in the tens of thousands of lines of code has been able to contribute substantially in less than two weeks.
It takes a lot of discipline to write good Common Lisp code.
With Haskell, some of the code may be a bit harder to read at first, but I always have the type signatures to help me. Quite often I dont even need to read the code because the types give me enough of the story.
I am a lot more comfortable to modify code knowing that it just isnt going to break something I wasnt aware of. Far less discipline is required to write good Haskell code. As long as the project is set up so that you don't write everything in IO, you are pretty much good to go.
I would be a lot more confident throwing a junior at a Haskell code base than a Common Lisp one knowing that they would be far less likely to break things.
It does take a bit longer to learn Haskell, but in my opinion, once you get over the hump it is oh so worth it!
I’ve been on Lisp teams where that wasn’t the case and it was a free-for-all with macros and other things. That was a disaster and the code base was a gigantic Rube Goldberg contraption. But bad hygiene is possible in any environment, though Lisp has the capacity to amplify it.
And don’t even start with point-free style, a style where parameters are left implicit. For a reader point-free is appalling and way too clever.
I would say junior Haskell should be unsophisticated. Leave out the higher order abstractions and write longer code which a reader at a lower level has a hope of deciphering.
I used to believe this, but as I started to read more and more Haskell, I realized that I just had to get used to that style of writing Haskell. I now read it fine, in general. Learning to read point-free is a learnable skill.
Tons of non standard sigils, on the other hand, is a bane.
This reminds me of what my boss from my second-ever job told me when he tasked me with starting a new project: "I know I promised you you'll get to choose your own tech stack, but you're going to write it in PHP; I know you'd like something better, perhaps Ruby, but when it comes to hiring developers to help you, I'll have to pay a Ruby developer $X, and I can get PHP developers for $X/2".
I guess it makes business sense for bottom-feeder development. In my case, it burned me out completely.
Anyway, I work in Common Lisp professionally these days too, and we don't shy away from using both simple and moderately-complex macros. There's nothing magic in them. Sure, tracing a problem with the expansion of someone else's macros can be a cognitively taxing work, but you're going to have to do this kind of work somewhere anyway - if not here, then when trying to figure out a convoluted call graph of 20 functions or methods that macro would have abstracted away for you (which was a common thing to do at my previous job, involving Enterprise Java).
As you grow, you will see that not all work is equally important, and you want your more senior guys work on harder problems. And you will also note a number of good, smart developers applying to you who do not yet have the experience of a senior engineer, but could quickly grow.
Then you can start hiring junior engineers, and nurture them.
[Edit: grammar]
If no one writers code that junior developers can understand, then how can we hire junior developers?
1. You miss a lot of great talent this way.
2. Growing and developing juniors is part of what makes a "senior."
3. This isn't sustainable advice -- if noone is hiring juniors, then where are the new seniors coming from?
The reality is something nobody really talks about.. When a company doesn't want to hire a "junior" it doesn't mean they don't want to hire somebody without X amount of experience in a tech stack or without X amount of experience in the industry.. They don't want to hire people bellow a certain aptitude.
Many "juniors" will never be "senior". Even if they get the title and salary. We all know "seniors" in salary and title only.
Some people are inexperienced "seniors" year one.
I really, really wish there was a rapid application development language like PHP or Go written over a functional language like LISP.
I've thought about writing one, and get all the way through it in my head until I come up to the inevitable problem with monads. I believe I can make it work by treating the monads as imaginary numbers with hidden contents and never really solve the problem of mutability, but I don't know what that would look like in practice yet. The language itself would basically be Javascript without mutable variables. There would be no async/await, instead, everything would be synchronous blocking with message-oriented streams in place of messages. Like the Actor model but executing immediately as a graph so it's fully deterministic.
Facebook kind of made one called Skip, although I feel like they might have been working on another one with a "z" in its name, or maybe someone else was, can't remember:
I don’t think this is the right take. Haskell is not Python—there isn’t a single way to do things such that you can say there’s one way, and it does or doesn’t work.
Haskell gives you a lot of flexibility to write code how you would like it. In my experience starting a company in Haskell, there is a subset of it which allows you to be very productive, and also get very high guarantees about the correctness of your code. I strongly recommend it.
Since you have first hand knowledge of the problems outlined in the article, can you comment on how easy it is to hire non-senior Haskell engineers? And how quickly do they come up to speed in a senior devs codebase?
Similarly, had they'd been thought functional programming, some category theory, and a bit more about type theory, etc., then they'd probably be able to ramp up to Haskell in two weeks as well.
On one hand, they come knowing all the concepts and only having to learn a syntax and tool-chain. On the other, they know none of the concepts, and have to learn them all as well as learning the tooling and syntax.
It reminds me of the Manager - HR pipeline, where HR people get a description of technical stuff to input in their job listings, and then proceed to gatekeep applicants away from the positions, because they don't match x % of their technical laundry list.
- A macro to define a string lexer (aka tokenizer) for a programming language
- A macro to define peephole optimizations of linear instruction code
- A macro to define friendly looking bindings to Fortran functions
- A macro to generate highly optimized complex double precision matrix arithmetic code for inner loops
We do use “standard” macros, mostly from the ALEXANDRIA library. But these are idiomatic and have been used since at least the 80s. (Some of these are macros that On Lisp defines from scratch.)
Or a Haskell-illiterate hire, or two weeks' max acceptable 'ramping up time', may not be a good choice.
The problem I run into frequently on my abortive attempts is that when things get harder, it's too easy to just drop back and smash something out in C#.
2019 ends my year of F# focus. In 2020, I will take a look at Rust since it is C-but-not-nearly-impossible-to-correct-insecure.
Between Get Programming with F# and Domain Modelling Made Functional, I am a convert for F# and will continue using it into the future. Why?
Quick example: I'm currently hacking together a program for the RPG system used in Star Wars Fantasy Flight Games, so that the game master can input possible player actions during their turns and keep track of player stats, generate NPC encounters etc. and so forth.
Writing the back-end in F# (stored to SQLite) really helps me keep the game rule book (business logic) straight, with compiler-based warnings if I try to, say, stick XP into a function that expects in-game cash.
On the front end, I'm using plain old Windows Forms in C#. The UI is mostly for data crunching and keyboard-first usage (I'm keeping in mind my FoxPro days and gui.cs / TUI / keyboard-first functionality from that twitter thread a few weeks back), and is mostly for gluing UI controls to the back-end itself (maybe this will be a mobile app, website, etc. in the future depending on the GM's needs).
For this program, I wouldn't write any game logic in C#, now that I'm used to F#. C# lets me get away with too many mistakes compared to F#, for the same reasons JavaScript lets me get away with (even more) too many mistakes compared to C#.
The tooling is pretty good now, but there are still pain points (breakpointing/stepping pipes |>, inlines, and pattern matching expressions), but even w/that said the tooling is probably above avg. now. If you want the best refactoring and debugging experience (Resharper, OzCode, etc.) the C# is still the best there.
Btw you may want to keep an eye on this: https://wende.github.io/elchemy/
Honestly, I wish this would get more traction, it seems like an awesome intersection between type safety and practicality.
Elixir/Erlang/BEAM has a lot going for it but it's not as general purpose as I'd like
My general impression of functional languages with Haskell at the top, is that these languages are inherently not for "junior" programmers of any stripe. That is, if you are a programmer writing Haskell code that actually works and does something useful, by definition you are nothing like a "junior" programmer. A "junior" programmer would be doing it in PHP, C#, or Python. Just the kind of motivation one would need to learn Haskell and actually be functional at it would take you out of the realm of the vast majority of "junior" programmers.
This is based on my own experience of working alongside many other programmers, many of whom were probably not necessarily "junior" however they were the kind of programmers that went home at 5 pm. These people could get a lot done but only in a language that did not require intensive conceptual visualization. Even in Python, parts of code that I would write that would get too clever / recursive / FP-ish would be lost on everyone else and I'd be stuck having to save everyone from that little clump every time something had to change with it.
One example I like to cite is: What I’d you want to tee a stream in Python to two different substreams? Stack Overflow it and you see cargo culted duck-typed classes that don’t derive from any clear specification.
Regarding the tee operator: it's a solved problem, you have ot import it from itertools[0], which should be where any experienced python programmer would strt.
[0] https://docs.python.org/2/library/itertools.html#itertools.t...
So what do you call someone writing useful code in Haskell for their functional programming course during their second year of CS? (That is my little sister right now)
Again, that's the crusty old perpsective informing me on this, your sister could be building out a self-driving car platform for all I know in Haskell, good on them !
The only scenarios I saw where juniors were not needed is overly complex systems where the barrier to entry was so high you needed a huge amount of upfront knowledge to do anything. Those were not good projects to work on.
From my personal experience, instead of writing dumbest possible code to make juniors productive from day one, just don't hire juniors. Or at least, not the absolute beginners. And if you do hire juniors, accept that they'll need more than few weeks to get up to speed.
Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get better over time. Learning is part of the job. And yet it seems to me that more and more people think that what they've learned prior to their first job is all they'll ever need to understand, and anything beyond it is "clever code" that needs to be expunged.
(Of course, keeping everything dumbed down makes sense if you're interested in penny-wise, pound-foolish optimization on the hiring side of the company, or otherwise like to have developers be replaceable cogs. But it's not in the best interest of the developer, and arguably it isn't in the product end-user's best interest either.)
But, organizations aren’t charities, right? I might like mentoring, but that doesn’t mean it’s the best choice for a company to make. Fortunately, there are a plethora of incredibly bright and talented individuals who really can move the needle in your business in a short amount of time. You wouldn’t see it from number-of-years worked, but you’ll find out by investing your time and energy in them. With this attitude and managerial philosophy in mind, I find that you inevitably build stronger, more loyal, more flexible, and exceptionally competent teams this way.
The article is about Haskell, but this advice - make code newbie-friendly, avoid "clever" code - keeps popping up again and again. The extent to what's considered "clever" varies between jobs, languages and programming communities.
As an example, when my old Java job was grudgingly upgrading from Java 7 to Java 8, my boss took me to the side, and said to me: "I knew you'll be happy about the transition, but if you could, perhaps consider refraining from using lambda expressions; I know you understand them, but some of your colleagues do not".
I didn't comply; instead, I've explained lambdas to people in my project. It took few minutes, they understood it almost immediately, and we continued using full feature set of Java 8 just fine. The practice eventually spread around, and the other day I saw a particular developer my boss was worried about, going around the office full of excitement, telling everyone about the cool things he's just learned about Java 8 (namely, lambdas and streams API). Soon thereafter, everyone was using these features, and they've lost their status as "clever code".
So, to put my point another way, perhaps instead of worrying about the code being friendly to experienced developers, one should take the time to teach the new employees - just like you are doing.
Unfortunately, programming is statistically a dead-end job. Ageism kicks in and one has to bail out of programming to get more money, because old programmers are on average not valued in the market-place. I'm just the messenger.
Part of it is the fad-driven nature of our industry that whips around what's "in" technology like the tail of a captured fish. Until Fad Cops clamp down on nonsense and excess, it's a young person's game.
Many companies stick with COBOL not because it's better, but because it's stable, like Latin, because it's a "dead language". Nobody comes along and gums it up with spaghetti "Design Patterns" or 7 layers of microservices because "the big boys are doing it!".
Warren Buffett has said part of his success is due to his ability to say "no" when everyone else is saying "yes". He willingly lets others be the guinea pig.
As far as functional programming, it takes a different mindset than imperative programming, and for many there is a relatively long learning curve until they match or exceed their imperative productivity. If programming is a dead-end career, per above, that curve may not be economical.
I personally find functional harder to debug because it's harder to "x-ray the pipes" of intermediate steps, and have not got over that difficulty yet. I personally find it easier to break up imperative code into smaller intermediate steps or parts, subject to inspection via debuggers or Write() statements. Somebody once said: "Functional makes it easier to express what you want, but imperative makes it easier to see what you actually have." That rang so true for me.
EDIT: RE debugging functional code, I don't find it in any way more difficult than imperative - but with a caveat that my functional programming experience is limited to typical for Lisp, Clojure and Erlang, and not e.g. Haskell. With functional code, you just hook up in some place in the pipeline and start leaking what's coming in and out of there to the outside world (stdout, REPL, debugger). Because it's functional, you can be sure you're not missing any hidden state. You can keep replying the calls manually, perhaps tweaking inputs, to identify the problem. After finding and fixing a bug, it's relatively trivial to turn your debugging work into a regression test.
It seems to me that your complaint is less about functional code and more about point-free style, which is arguably a bit more difficult to hook into, but only because debugging tools aren't really optimized for it.
I get the impression that most companies would rather complain about shortage of talent for months instead of hiring someone who'll spend a few weeks learning.
>
> Boss: It’s time to hire another Haskeller. What are the job requirements?
The job requirements should be the same as the ones the original engineer was hired for. Then they can mentor the newbie. After all, they're not an expert if they've done this, they're still able to explain why they pulled in a shit ton of libraries to do their work.
Asking that person what the new requirements are is doomed to fail because they moved the goal posts. Give them a junior and let them learn.
When you pull on the thread, you find that a lot of successful developers don't really have that clear a picture of what it is they did and how they did it. It gets covered with bluster and bluffs. Impugning the other person for not 'getting it' and getting defensive about the 'documentation' they wrote and how everything you need is in the code.
Fifteen years ago we were still talking about 'cave trolls', the people who work in isolation, and often on their own schedule. Most of those people still exist. They've just had makeovers.
You just knew how to research and fix the problem really fast.
What you need is someone smart and who can demonstrate that they can learn new languages quickly.
They understand the fundamentals of how to write software.
Language specific abstractions are just muscle memory.
The best engineer I've worked with sometimes wrote simpler code and sometimes wrote highly sophisticated code. If there's someone on the team who can't understand a particular piece of code, he should just ask and learn. There's no reason to weigh someone down just to make an inexperienced, incompetent programmer or unwilling to learn something happy.
Good code isn't junior code. Good code isn't senior code. Good code is just what works best in a specific scenario. And it takes experience and details of a problem to decide what that is exactly. Dogmatic, rigid views just don't work well in this line of work.
So in my opinion, there is two type of unreadable code, there is the code that's just plain bad, convoluted, overly complicated, like a Rube Goldberg machine. That one is often written by inexpert programmers, sometimes they are juniors, and sometimes they're senior as well. And then there is code that you personally can't read, but which is great code, simple, coherent, to the point, etc. You just haven't learned the vocabulary and grammar to understand it.
Writing simple code isn't about allowing juniors to be "lazy". Simple code is a business decision. The easier it is to contribute to a codebase:
* the more of your existing staff are able to contribute
* the easier it is to hire people able to contribute
* the cheaper your staffing costs
* the quicker it is for new staff to contribute
* the more resistant you are to staff turnover
* the more resistant you are to changes in the relative popularity of programming languages and libraries
* the cheaper it is to pay off technical debt (because rewrites are easier)
Lowest-common denominator code should be the rule, not the exception. There is definitely a place for "fancy" code, but it should be very carefully considered.
In most languages, the abstraction ladder is short. You have built-in types and user defined types. Those user-defined types are almost always product types (think of structs in Go, or classes in OOP languages). Haskell also has sum types, which allow you to express things like:
data TrafficLight = Green | Yellow | Red
Then come advanced type-level features: data kinds, type families, generalised algebraic data types and many others. Here's the table of contents of a book that deals with type-level programming in Haskell: https://thinkingwithtypes.com/
These concepts allow you to encode more logic at the type level. But they come with the cost of needing to understand them.
You can make a choice to write Haskell without these advanced type features. Maybe you lose some type safety or maybe you repeat yourself more. But the upside is that you use fewer concepts that need to be understand by someone who needs to work on the codebase.
These are the juniors the author is referring to. I'm a junior as well in this regard, because I don't know all these type-level features, even though I've used Haskell professionally.
I also think that “junior code” could mean the opposite of what the author means. Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people. Lots of senior devs stick to a known (and canonical to them) subset of features that proved themselves in battle for them.
Do you really see people do this in Haskell? I'm "junioring" my way through a problem set now (advent of code) and that does not describe my solutions at all. It is definitely not pro-level Haskell. I use direct recursion with an accumulator when I know there's gotta be some recursion scheme that fits the bill, very simple types, very few advanced combinators and symbols, etc.
It definitely could be better, but it suffers from a lack of fanciness rather than an excess. I've peeked at some expert solutions posted online and they are neat and super impressive... but by and large they confuse the shit out of me.
I have a hard time picturing being overly ambitious as a common beginner flaw in this space.
It’s not that all Juniors are this way. Maybe some get it right or maybe they even act too skidding. But I think of it as a Junior trait to sometimes overshoot on complexity.
>Let’s not delete all of our fancy code - it serves a purpose! Let’s make it a small part of our codebase, preferably hidden in libraries with nice simple interfaces.
Says something about the Haskell culture that this isn't already standard practice, regardless of the need to train junior programmers.
(I don't work in Haskell. Now I have mixed feelings about it.)
Servant, the currently dominant API library/framework alone is already based on type level programming.
Otherwise, I don't think many jobs pay more than Java engineer at FAANG.
Complexity is all at our common libraries. So most programmers don't even need to understand our abstractions, they just work. Of course, sometimes our abstractions are not enough so you need to get your hands dirty. However I would say it works well 99% of the time.
A framework has the benefit of having existing documentation you didn't have to write, an existing community of people solving problems the framework may have, and most importantly a slew of idioms that are literally codified and documented.
Do things "The {Framework} Way" and when you onboard someone familiar in {Framework} you should only have to help them with the domain space knowledge and any novelties of your specific implementation. You still get to use advanced concepts, but hiring and onboarding is significantly simplified.
For personal projects, I never use frameworks, it's not nearly as fun as writing greenfields code. But in a commercial project, long term viability of the project should probably come before fun.
They had a good point — if a primary goal in your team is to make code accessible for juniors and maintainable for new hires without weeks or months of ramp-up, and you need to ban Haskell language features, extensions, and libraries to achieve that, perhaps there are better choices than Haskell?
And if the Haskell community needs a repeated rallying cry to “write simple Haskell”, maybe it's a sign that a new Haskell standard should be created that defines what “simple“ Haskell code means.
Juniors could then feel assured that learning the 2050 Haskell standard [or whatever] would be enough to help them get a job as a Haskell junior. And companies would have a target to move their codebases towards that's consistent across the industry.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style
Using a subset of Haskell makes coding fun and productive, but when I have to read and use other people’s code, it takes time to understand what they are doing.
I have made peace with using Haskell in a simple way, enjoy it, but frankly spend most of my time using Lisp languages like Hy, Common Lisp, and Racket. I have been using Lisp languages for 35 years and part time Haskell for about 7 years, so it is understandable why I have an easier time with Lisp.
Specifically, take something like Laravel. It's based on Ruby on Rails, which borrows heavily from .NET. Personally I think that Ruby is a decent language that gets a few things right, despite some early compromises to get closer to the metal which caused some unwieldiness down the road. However, Ruby on Rails has a brutal learning curve unmatched by just about any other framework that I've learned. And the end result unfortunately succumbs to being too opinionated due to emphasizing convention over configuration too much IMHO. I think that's why it fell from favor, and personally I wouldn't recommend it for new development.
Whereas Laravel does a lot of what Rails does, despite using the "hackier" PHP language and less syntactic sugar or magic under the hood. The companion Laracasts are mostly exceptional. I would even go so far as to say that if you want to learn Ruby on Rails, learn Laravel first. That way you can build on context and be comfortable with Rails in a few weeks rather than the months it would take to learn it from scratch. You'll also notice the inconsistencies in Rails more and be able to work around them so your code is conceptually correct, rather than evangelize why their existence is needed or that they're the "one true way" to do something.
What I'm trying to say is that after using Ruby on Rails, I'm still not sure what problem it's trying to solve half the time. It seems to be structured in a way that solves issues encountered late in a project, but it's never really clear why one path was chosen over another. Like I solve a problem in my head, then have to translate it to the Ruby on Rails way. I don't get that as much with less-opinionated frameworks like Laravel. I think the best approach is to provide as much functionality as possible with sane defaults but not force the user into a paradigm.
Simplifying from Angular to Vue is another example of this. There are many others, but to play on this, it's one of the reasons why I'm uncomfortable with stuff like Kubernetes. Or even Unity for that matter. The more monolithic/enterprisy/opinionated something is, the more I'm skeptical of it.
This idea of working from first principles (the way a new user might) is a way to think about how to go about writing code that junior developers can use, even if the concepts involved are senior-level. I practice this technique but it easily gets lost in translation and I find myself explaining the easy vs simple dichotomy a lot. It's probably even cost me jobs to be honest. But that doesn't mean it's wrong.
Can't find any jobs willing to hire me as a junior haskell programmer so I just stick with the popular languages.
This is the litmus test for a good language, in my opinion. Not the way it makes you “feel” when writing it, but how easily it can add in new people to the project and get them running.
This is why — even with all of its shortcomings — I prefer Go to almost every language now.
In a non-functional programming language for instance, I firmly place lambdas in this category. I was working on a legacy Java 7 application the other day, and Netbeans was configured for using lang spec Java 8 (which I later switched over to 7). Every time I wrote an anonymous function, it could give me a yellow underlined hint saying I should convert this to a lambda. Why? Why should I do that? It doesn't make it more readable, it saves only a few characters of space (our target platform had more than enough disk space for this to be irrelevant), and it makes the code more difficult to skim. And it's an extra thing a junior may not know about that they get bogged down trying to understand. Given, it's a simple concept and isn't hard to understand. But this applies to all sorts of other silly syntactic sugar the internet has decided is cutting edge tech, that is making our code bases less readable.