by bibyte on 12/28/19, 4:17 PM with 141 comments
by reikonomusha on 12/30/19, 12:19 AM
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.
by smadurange on 12/30/19, 1:21 AM
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.
by zzzeek on 12/29/19, 10:28 PM
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.
by TeMPOraL on 12/30/19, 12:48 AM
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.)
by bauerd on 12/29/19, 10:37 PM
by emodendroket on 12/30/19, 2:52 AM
by ehnto on 12/30/19, 5:53 AM
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.
by modernerd on 12/30/19, 9:06 AM
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.
by pizlonator on 12/30/19, 1:18 AM
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.
by ummonk on 12/29/19, 11:50 PM
>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.
by userbinator on 12/29/19, 11:51 PM
(I don't work in Haskell. Now I have mixed feelings about it.)
by ljm on 12/29/19, 10:53 PM
>
> 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.
by Syzygies on 12/29/19, 11:23 PM
by Cthulhu_ on 12/30/19, 11:09 AM
"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
by rantwasp on 12/30/19, 1:48 AM
by mark_l_watson on 12/30/19, 11:59 AM
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.
by tus88 on 12/30/19, 1:57 AM
by mendelmaleh on 12/30/19, 5:28 AM
by pearapps on 12/31/19, 7:09 AM
by dreamcompiler on 12/30/19, 1:25 AM
by choeger on 12/29/19, 10:01 PM
by hestefisk on 12/29/19, 11:58 PM
by 29athrowaway on 12/29/19, 10:49 PM
by throwaway8291 on 12/29/19, 9:57 PM
by ofrzeta on 12/31/19, 6:36 AM
by heyflyguy on 12/30/19, 12:52 AM
by golergka on 12/30/19, 7:57 AM
by lesserknowndan on 12/30/19, 12:33 AM
by zackmorris on 12/30/19, 8:51 PM
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.
by crimsonalucard on 12/29/19, 10:20 PM
Can't find any jobs willing to hire me as a junior haskell programmer so I just stick with the popular languages.
by 3fe9a03ccd14ca5 on 12/30/19, 4:42 AM
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.
by Thorentis on 12/30/19, 1:49 AM
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.