
Write Junior Code - bibyte
https://www.parsonsmatt.org/2019/12/26/write_junior_code.html
======
reikonomusha
This might be a little bit of a “hot-take”, but if idiomatic code written by a
competent senior engineer remains inscrutable and unmodifiable after around 2
weeks of training an engineer who is at the beginning of their professional
career, then that language is probably a bad choice to use in production. If
lenses, MTL, fancy concurrency are “the way” to do things in Haskell, and
those require an extraordinary amount of time to learn, then Haskell may not
be a good choice for production code from a sociological POV.

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.

~~~
TeMPOraL
Or, just don't hire junior developers :).

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

~~~
Rapzid
"Junior" might as well be an IQ classification.. How many people change their
IQ?

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.

~~~
TeMPOraL
Viewing it from this lens, it still doesn't make sense to sacrifice
productivity of people "with aptitude" for the sake of expanding your hiring
pool to include people "without aptitude". Instead of bringing down everything
to the lowest common denominator, one can try to assign different types of
work to people with different levels of aptitude (or care).

(Personally, I feel what makes "forever juniors" isn't aptitude, but lack of
care. I don't see it as flaw of character - the factors like structural anti-
intellectualism in the industry, lack of enthusiasm due to work being
meaningless, and that not everyone is into programming beyond it being a
9-to-5 job all contribute to some people not learning. This suggests to me
that expecting people to learn and making learning part of their jobs - actual
part, with paid time set aside for it - can overcome this problem.)

~~~
nsomaru
> anti-intellectualism in the industry

Could you expand upon this point?

~~~
TeMPOraL
A bit more here:
[https://news.ycombinator.com/item?id=21909816](https://news.ycombinator.com/item?id=21909816).

But the gist of it is: the industry prefers to work with dumbest tools
possible and throw cheapest bodies they can get at a problem, instead of
expecting people to keep learning, improving themselves, and applying these
improvements to their work. This article is an example of that - it advocates
discarding advanced tools given to the programmer by Haskell, in favor of
writing dumb code that's easily digestible for beginners. Most of the advice
about avoiding "clever code" is a form of that too.

I find it a penny-wise, pound-foolish approach, because when you do this
trade-off, you're losing in two places. First of all, you handicap your
skilled team members. But secondly, the cost (in terms of time, money and
incidental complexity) of a project grows _faster than linear_ with the number
of people you get involved in it. It'll be O(n!) if you do it naively, O(n
logn) if you arrange people into hierarchies, but the problems still grow
faster than they're solved as you scale up.

The alternative approach I'm encouraging is to make responsible but full use
of the power of the tools you have, and if this goes over the head of some new
hire, then _teach them_ until they understand and can make use of that power
too. Embrace and encourage learning as a part of this job (actual, expected,
and paid-for part). Push the industry upwards, instead of dragging it down.

------
smadurange
I think one should write the code that's most suitable for a specific
scenario. Senior vs junior has nothing to do with this (at least not in a
categorical way). I have met many who call themselves seniors who really just
aren't as good as they think they are.

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.

~~~
didibus
Agreed, I'm not a huge fan of junior/senior. What we should be talking about
is inexpert/expert, which doesn't always map 1:1 with how long you've been
working, or practicing. Though obviously, the longer, the more likely you
learned and became more knowledgeable. But some people spend 10 years doing
the same thing over and over, and that's not broadening and deepening their
skills the slightest.

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.

------
zzzeek
To be clear, one of the reasons I decided to focus on Python in the early
2000's was this reason, that I wanted to work within a computing language that
was as accessible as possible to the widest variety of programmers, thus
helping to ensure that the code I write would be maintainable by others, the
libraries I create would be in high demand, and whatever code I write for
employers would be maintain a high degree of transparency to everyone else at
that employer.

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.

~~~
thanatropism
One would expect that a language like Haskell abstracts away the need for
junior programmers. In the same way that digital computers abstract away the
need for pencil-and-paper calculators.

~~~
rubber_duck
I've never seen a scenario like this and even with the ideal case of current
abstraction frameworks there is always tedious grunt work that juniors get to
cut their teeth on - doing minor adjustments to fine-tune requirements, adding
minor functionality, etc. Stuff where you don't want to waste time and focus
of senior devs.

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.

------
TeMPOraL
I have the opposite view. Sure, don't go overboard with power _for your own
sake_. If it ends up a convoluted mess, it's your fault and you should
refactor - proper application of powerful language concepts result in clean
interfaces hiding complexity that rarely, if ever, needs to be touched again.

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

~~~
reikonomusha
One of the most enjoyable aspects of my career has been teaching and mentoring
engineers with little experience. Everybody starts somewhere, and I would
never want to suggest an organization I’m a part of ought to bar a healthy,
tempered number of less experienced folk.

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.

~~~
TeMPOraL
Well, sure. My main point isn't that you shouldn't train hires (you can't
really expect to not train new hires). It's that I don't think it's worth it
to sacrifice your team's internal productivity for the sake of speeding up the
onboarding process and/or making it cheaper - which is what IMO the article is
essentially suggesting.

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.

~~~
clarry
I fully agree with this. I haven't really seen code that is 1) actually useful
but 2) so clever that you can't quickly explain why or how it works (or just
let the person reading it figure it out or ask stackoverflow...). So I don't
really even know what people mean by clever code.

~~~
Viliam1234
In my experience, a big danger is when someone higher in the company hierarchy
is a former developer who no longer writes code.

Such person will perceive the new language features or libraries as "too
clever, and not really necessary", will voice their opinion loudly, and you
can't make them learn and find out that it's actually simple and useful. (And,
yes, lambdas in Java 8 were an example of that.)

~~~
tabtab
Find good examples that you can defend well, and overwhelm them with practical
and relevant examples.

------
bauerd
Wish there was something similar to Elm, but designed with
backend/networking/generality in mind, like Go. Take the Haskell core language
without all the lang extensions, and accompany it with a solid stdlib. I want
an FP ecosystem that's not rooted in research. Can have a more simplistic type
system, etc. Basically a functional Go. Maybe an effect system, idk.

~~~
thrower123
I keep telling myself that this is the year I'm going to really learn F#; it
has a lot of the nice parts of Haskell, but is a little more on the pragmatic
end, and has access to the whole .NET world.

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

~~~
Multicomp
Once you get used to / take for granted the additional compiler features in
F#, you will find yourself weaning yourself off C# code more and more.
Resistance is futile!

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

------
emodendroket
I don't know much about Haskell but I'd say in any language you shouldn't
write code to show off your erudition. Doing that kind of thing in production
code is hardly the mark of a truly senior engineer. If the code is the best
way to solve the problem, though, why is it so inscrutable in this language?

------
ehnto
This is why I advocate for popular frameworks in commercial projects, even
though I don't prefer writing in them myself. Sure, it's easy to find people
who know {Language}, but everyone has their own idioms, and they will need to
spend time learning yours.

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.

------
modernerd
“Why not write Go instead?” was the response from an audience member after a
talk at Haskell eXchange 2019 that encouraged simple use of Haskell.

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.

------
pizlonator
I think that it’s important to hire people who are comfortable with the whole
language that you are using.

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.

~~~
np_tedious
> Lots of smart juniors write code that abuses complex language features in
> noncanonical ways that confuse all of the people.

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.

~~~
pizlonator
Different folks take different paths. In any language, you will find folks who
start out by kinda overshooting before they learn to tone it down.

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.

------
ummonk
>Let us grow Haskell in industry by writing simpler code and making room for
the less experienced.

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

~~~
sukilot
It says something about the Haskell _language_ \-- that it has near infinite
power for abstraction and Don't Repeat Yourself-ism. Most Haskell code is
fancy because if anything else had a large amount of mass, it could be
abstracted to higher-level Haskell. Haskell programs have size approximately
"log(size of program in another language) ^ k" because anything repetitive can
get squeezed out.

------
userbinator
Almost every other language has a problem that it's already so dumbed-down to
the point employees get treated as disposable/replaceable. There's a reason
obscure languages pay very _very_ well, but if you dumb them down, it's not
hard to see what will happen to that advantage...

(I don't work in Haskell. Now I have mixed feelings about it.)

~~~
sukilot
There are more $200K+/yr new-college-grad C++ and Java jobs at FAANG than all
$200K+/yr Haskell jobs in the world.

------
ljm
> Employee writes a ton of really fancy Haskell, delivers fantastically and in
> about 1000 lines of code. Everyone is very impressed. The project grows in
> scope.

>

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

~~~
huffmsa
That's the thing a lot of devs who hire don't get. You don't necessarily need
someone who knows the language inside and out on day one.

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.

~~~
sukilot
No one learns Haskell quickly. "the fundamentals of how to write software" are
very different in Haskell from other languages, even other functional or
functional-ish languages.

------
Cthulhu_
I have a page saved with a load of quotes, some of which are about this very
subject. Here's a selection, from
[http://quotes.cat-v.org/programming/](http://quotes.cat-v.org/programming/):

"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

------
Syzygies
One should code in Haskell as if it were a small language like Scheme (or
Standard ML, or early OCaml, or..). It's a wonderful language for that. The
deep stuff isn't actually necessary.

~~~
verttii
True, but the problem is that any production ready library you come across
uses some pretty advanced type magic that you have to learn to understand. At
least to some extent.

Servant, the currently dominant API library/framework alone is already based
on type level programming.

------
crimsonalucard
I'm kind of having this problem. I'm a senior engineer but junior Haskell
programmer.

Can't find any jobs willing to hire me as a junior haskell programmer so I
just stick with the popular languages.

------
rantwasp
talking about haskell, i always get a laugh out of: [http://steve-
yegge.blogspot.com/2010/12/haskell-researchers-...](http://steve-
yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html)

------
mark_l_watson
I enjoy Haskell and I use it for some of my own projects, but I rarely use it
professionally. I also use a simpler style of writing Haskell: I try to make
as much of my code as possible be pure, with no IO or touching the real world.
I try to isolate impure code as much as possible.

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.

------
pearapps
If code written by a "Senior" Engineer is unreadable/unworkable by someone
with less experience - that is 100% on the writer. Don't enable ego-fueled
programming, best to either do as the article suggests or bring in some actual
more senior engineers who have already learned that code is read 10x more than
written, and should be optimized thusly.

------
tus88
Wow but he continues to recommend using Haskell at all...

------
mendelmaleh
I'm having a similar experience with Golang, 90% of job postings are senior
level, everybody wants 3+ years experience in the field, etc.

------
dreamcompiler
Perfectly fine advice if you're solving a routine problem with well-understood
solutions with no special reliability, productivity, or security requirements.
Terrible advice if you're pushing the envelope. If you're using Haskell with
half its functionality verboten, why use Haskell?

~~~
war1025
Which is, perhaps, why basically no one uses Haskell in production.

------
choeger
While you do it, find a business case for the language development. PL papers
in the <Funny Title>:<Actual Description> format make a good read but a
production language also needs more mundane input and work.

------
hestefisk
Do Haskell programming jobs really pay better than, say, a Java programming
job?

~~~
Sevii
Maybe working on the one internal system Facebook has written in Haskell.
[https://engineering.fb.com/security/fighting-spam-with-
haske...](https://engineering.fb.com/security/fighting-spam-with-haskell/)

Otherwise, I don't think many jobs pay more than Java engineer at FAANG.

------
29athrowaway
What I try to do in my projects is to allow complex code (if it serves a
purpose), but only in libraries and try to make it as self-contained and well
documented as possible. Application code should be simple.

~~~
m45t3r
I concur. We use Clojure, and the actual application logic is boring and
simple. This is good because it is easy to navigate in code from any project
(even from other teams).

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.

------
throwaway8291
Or become senior and apply for that Haskell job in five years.

------
ofrzeta
The same goes for Scala in my opinion. A company using Scala should restrict
themselves to a easily comprehensible subset of Scala.

------
heyflyguy
I feel like you could say some similar things about flutter.

------
golergka
That's why as much as I love Haskell as a language and a way of doing things,
I will not choose it to implement anything in my place of work.

------
lesserknowndan
This post probably also applies to <insert name of programming language here>.

------
zackmorris
Just for another data point, I'm a "senior" developer (been programming for 30
years) and I tend to look more at frameworks than languages. I really think
that starting from first principles allows one to end up with an elegant
solution, regardless of whatever errata is present in a language. A good
framework is the elucidation of an idea with the edge cases covered so that
you don't have to reinvent the wheel. It should give you the tools you need to
integrate with your code and then get out of the way.

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.

------
3fe9a03ccd14ca5
> _The project can’t really grow anymore. Maybe the original employee left,
> and now they have a legacy Haskell codebase that they can’t deal with._

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.

------
Thorentis
Not specific to Haskell but, I think code in general is becoming more complex
than it needs to be without any added benefit other than adding an extra
buzzword to the list of things you know.

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.

