Write Junior Code • Hacker News Board

Re: Write Junior Code

#71

Post by didibus » Mon, Dec 30, 2019, 3:41 AM UTC

reikonomusha wrote: post #28

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 amoun…

Now, I'm not particularly a fan of Haskell, but I think it is disingenuous to compare it apple to apple. Most junior devs had multiple years of training in imperative OOP languages prior to joining a company. So if they join a place that uses C#, and they don't know C#, but they already know how every single feature and concept of C# works, well ya, they'll be proficient in two weeks.

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.

Re: Write Junior Code

#72

Post by millstone » Mon, Dec 30, 2019, 3:59 AM UTC

monoideism wrote: post #70

SaxonRobber wrote: post #50

Earlier quoted context omitted.

Part of the trouble with Haskell is the prevalence of syntactic sugar. It is incredibly easy to make code that is tiny and indecipherable because it relies upon functions which are compositions of higher-ordered functions with monads and obscure operators that no other language has. And on top of that Haskell is lazily evaluated, which complicates it further. And don’t even start with point-free style, a style where…

> For a reader point-free is appalling and way too clever. 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.

There's definitely a vein of deliberate unreadability. Types and parameters are often labelled positionally instead of given meaningful names. For example the graph library fgl uses typenames 'a' and 'b' instead of useful names like 'NodeLabel' and 'EdgeLabel'.

Re: Write Junior Code

#73

Post by MaxGabriel » Mon, Dec 30, 2019, 4:07 AM UTC

reikonomusha wrote: post #28

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 amoun…

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

Re: Write Junior Code

#74

Post by ramchip » Mon, Dec 30, 2019, 4:20 AM UTC

hinkley wrote: post #23

bauerd wrote: post #12

Earlier 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 is an attempt at it, yes: https://wiki.haskell.org/Cloud_Haskell

Many languages have some variation of Erlang’s processes and/or distribution available as a library, but the key features like live inspection, code reload, or strong isolation between lightweight processes can’t really be done without language runtime support.

Re: Write Junior Code

#75

Post by 3fe9a03ccd14ca5 » Mon, Dec 30, 2019, 4:42 AM UTC

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

Re: Write Junior Code

#76

Post by 3fe9a03ccd14ca5 » Mon, Dec 30, 2019, 4:45 AM UTC

monoideism wrote: post #70

SaxonRobber wrote: post #50

Earlier quoted context omitted.

Part of the trouble with Haskell is the prevalence of syntactic sugar. It is incredibly easy to make code that is tiny and indecipherable because it relies upon functions which are compositions of higher-ordered functions with monads and obscure operators that no other language has. And on top of that Haskell is lazily evaluated, which complicates it further. And don’t even start with point-free style, a style where…

> For a reader point-free is appalling and way too clever. 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.

> I realized that I just had to get used to that style of writing Haskell. I now read it fine, in general.

The question of course is how true is this for the general engineering community?

Reminds me in some ways of survivor bias: those that stick successfully with Haskell tend to see the shortcomings perhaps as virtues.

Re: Write Junior Code

#77

Post by 3fe9a03ccd14ca5 » Mon, Dec 30, 2019, 4:47 AM UTC

MaxGabriel wrote: post #73

reikonomusha wrote: post #28

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 amoun…

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

> In my experience starting a company in Haskell

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?

Re: Write Junior Code

#78

Post by eru » Mon, Dec 30, 2019, 4:48 AM UTC

gravypod wrote: post #48

TeMPOraL wrote: post #38

Earlier 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…

If no one hires junior developers then how will we make new developers? If no one writers code that junior developers can understand, then how can we hire junior developers?

> If no one hires junior developers then how will we make new developers?

Independent of the serious answer given by BurningFrog, it's also useful to understand that what's best for the world at large is not necessarily best for your company.

Re: Write Junior Code

#79

Post by eru » Mon, Dec 30, 2019, 4:51 AM UTC

reikonomusha wrote: post #33

sukilot wrote: post #29

Earlier quoted context omitted.

Do you use On Lisp (hi, 'pg!) type stuff, with heavy macros? I don't believe a new hire can learn an On Lisp -esque custom embedded language in 2 weeks.

No. Good idiomatic Lisp code might use some macros for domain-specific applications, and if those aren’t increasing readability, then they have no place in production code. A few prominent macros we do use: - 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 function…

That sounds mostly like you'd want to be using something like functions, but Lisp ain't a strong enough language, so you have to use macros?

(Just for comparison, in Haskell you would probably do most of these without macros. They do have (something like) macros in Haskell, though. They are not quite as natural as in Lisp, mostly because of differences in syntax.)

Re: Write Junior Code

#80

Post by monoideism » Mon, Dec 30, 2019, 5:06 AM UTC

millstone wrote: post #72

monoideism wrote: post #70

Earlier quoted context omitted.

> For a reader point-free is appalling and way too clever. 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.

There's definitely a vein of deliberate unreadability. Types and parameters are often labelled positionally instead of given meaningful names. For example the graph library fgl uses typenames 'a' and 'b' instead of useful names like 'NodeLabel' and 'EdgeLabel'.

OK, those are poor stylistic practices, but they’re orthogonal to point-free style.