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.
Write Junior Code
91–100 of 143 posts
Re: Write Junior Code
#92“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.
Re: Write Junior Code
#93Earlier quoted context omitted.
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 develop…
"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 "se…
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.)
Re: Write Junior Code
#94Wish 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.
I used to have the same wish as you but then I just decided to pick up Haskell. Haskell's hard part really is the type system. It's also what ultimately enables you to write very high abstraction level type safe code that does exactly what it's expected to do.
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.
Re: Write Junior Code
#95Earlier quoted context omitted.
I should have added that I'd also prefer mandatory typing and natively compiled code. Elixir/Erlang/BEAM has a lot going for it but it's not as general purpose as I'd like
There's at least one other way to read that comment. Is there an 'Elixir' of Haskell? Maybe someone should write it. What would it look like if you stole the good bits from a framework/library/standard lib in another language and wrote them in Haskell?
There's also some work pushing Haskell to perform better (more like Elixir) in networking/concurrency applications:
http://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/
Re: Write Junior Code
#96This 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 amoun…
As someone who works with a ton of Common Lisp and a bit of Haskell, sure Common Lisp may seem easier to read at a surface level but my god am I a lot more hesitant to make any changes to our code base. Unintended side effects are everywhere.
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!
Re: Write Junior Code
#97One 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.
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.
Re: Write Junior Code
#98I 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'…
> And if you do hire juniors, accept that they'll need more than few weeks to get up to speed.
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.
Re: Write Junior Code
#99I 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 underst…
I think the point of this article escapes anyone who doesn't know Haskell or a language with a similar type system. I don't want this to sound elitist, because it's not my goal, so I will clarify.
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.
Re: Write Junior Code
#100Earlier quoted context omitted.
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, th…
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 "cleve…
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.