7 ms·

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 wee

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.

sukilot 7y ago
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.
- reikonomusha 7y ago
  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 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.)
  - eru 7y ago
    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.)
    - reikonomusha 7y ago
      It’s true that in a lazy functional language you can get by with fewer syntactic extensions for common programming patterns, but it doesn’t, at the end of the day, actually solve the problem of syntactic extension or code generation.
      - eru 7y ago
        It's not just laziness, though that helps. It's also bunch of other idioms and features. (I've programmed in a strict variant of Haskell for a while.) Ideally, a language like Haskell would actually be total by default; ie all computations are finite. For those computations, the compiler can freely choose evaluation strategies without affecting semantics. For potentially infinite calculations, you'd go into a mode that's somewhat similar to how IO is segregated in existing Haskell. (There's some more complications about things like infinite event-loops, that can be solved very similarly; and for some things you might want the user to provide proofs that they are indeed finite, instead of just overriding the compiler's judgement with an unsafe cast.)
- jgodbout 7y ago
  Fixing your Lisp: (let ((pg! "Paul Graham!")) `(hi ,pg!))
  - jgodbout 7y ago
    Or, really `(hi ,pg!) but please capture that pg!
TeMPOraL 7y ago
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).
- gravypod 7y ago
  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?
  - BurningFrog 7y ago
    The suggestion was to not hire junior for certain projects, where that makes sense. This does not at all imply that no one should ever hire them. So get up from that slippery slope and start walking again!
  - eru 7y ago
    > 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.
- mcqueenjordan 7y ago
  > Or, just don't 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?
SaxonRobber 7y ago
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 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.
- monoideism 7y ago
  > 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.
  - millstone 7y ago
    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'.
    - monoideism 7y ago
      OK, those are poor stylistic practices, but they’re orthogonal to point-free style.
      - edflsafoiewq 7y ago
        It is related. In point-free style the "omitted" parameters have to be distinguished positionally; they have no names at all, not even 'a' or 'b'.
didibus 7y ago
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.
- square_usual 7y ago
  GP's comment talks about how Lisp passes the two week test. Not really apples to apples with Haskell, to be sure, but it still is significantly different from C#.
- reikonomusha 7y ago
  I agree that if our educational institutions changed with respect to what’s taught around programming fundamentals, advanced Haskell would be easier to digest more quickly for someone just coming out of school. My point is sort of that that’s not the case, which potentially makes Haskell a tougher sell for the graduates of today.
MaxGabriel 7y ago
> 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.
- 3fe9a03ccd14ca5 7y ago
  > 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?
  - MaxGabriel 7y ago
    Sort of. So far most of our hires have Haskell experience. Haskell was the main reason programmers would want to join us, so they would be naturally experienced in Haskell. I’ll have a better idea of how non-Haskellers, including very junior engineers, pick up Haskell later this year. Based on our limited sample size so far, I think people become productive within 4–6 weeks or so.
qafy 7y ago
Pragmatism is priceless in large scale production systems. I just recently started a new job as a front-end engineer where we use Go for all our backend services. I have never used Go before, and likely won't much in the future either, but I absolutely love how absolutely dead simple it is. You've got conditionals, loops, structs, slices (arrays), and functions, and that is about it. Even though I don't write Go code I can still read, understand, and reason about all our systems. The same cannot be said about your average junior or front-end dev trying to understand Haskell or Lisp or other obscure high level languages.
weavie 7y ago
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!
- reikonomusha 7y ago
  I think good mentorship, good code review, and good tests are critical to anything, including Common Lisp. We are very strict about that and we’ve had excellent results. Non-sense and language game-playing is quickly and earnestly called out, and everybody lives a better developer life. 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.
TrackerFF 7y ago
I think a problem might be that the jr. devs don't even get the chance to look at the code, because they're not getting hired based on their lack of experience (ref. the laundry list of advanced requirements). 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.
OJFord 7y ago
> then Haskell may not be a good choice Or a Haskell-illiterate hire, or two weeks' max acceptable 'ramping up time', may not be a good choice.

sukilot 7y ago

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.

reikonomusha 7y ago
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 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.)
- eru 7y ago
  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.)
  - reikonomusha 7y ago
    It’s true that in a lazy functional language you can get by with fewer syntactic extensions for common programming patterns, but it doesn’t, at the end of the day, actually solve the problem of syntactic extension or code generation.
    - eru 7y ago
      It's not just laziness, though that helps. It's also bunch of other idioms and features. (I've programmed in a strict variant of Haskell for a while.) Ideally, a language like Haskell would actually be total by default; ie all computations are finite. For those computations, the compiler can freely choose evaluation strategies without affecting semantics. For potentially infinite calculations, you'd go into a mode that's somewhat similar to how IO is segregated in existing Haskell. (There's some more complications about things like infinite event-loops, that can be solved very similarly; and for some things you might want the user to provide proofs that they are indeed finite, instead of just overriding the compiler's judgement with an unsafe cast.)
jgodbout 7y ago
Fixing your Lisp: (let ((pg! "Paul Graham!")) `(hi ,pg!))
- jgodbout 7y ago
  Or, really `(hi ,pg!) but please capture that pg!

TeMPOraL 7y ago

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

gravypod 7y ago
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?
- BurningFrog 7y ago
  The suggestion was to not hire junior for certain projects, where that makes sense. This does not at all imply that no one should ever hire them. So get up from that slippery slope and start walking again!
- eru 7y ago
  > 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.
mcqueenjordan 7y ago
> Or, just don't 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?

SaxonRobber 7y ago

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

monoideism 7y ago
> 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.
- millstone 7y ago
  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'.
  - monoideism 7y ago
    OK, those are poor stylistic practices, but they’re orthogonal to point-free style.
    - edflsafoiewq 7y ago
      It is related. In point-free style the "omitted" parameters have to be distinguished positionally; they have no names at all, not even 'a' or 'b'.

didibus 7y ago

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.

square_usual 7y ago
GP's comment talks about how Lisp passes the two week test. Not really apples to apples with Haskell, to be sure, but it still is significantly different from C#.
reikonomusha 7y ago
I agree that if our educational institutions changed with respect to what’s taught around programming fundamentals, advanced Haskell would be easier to digest more quickly for someone just coming out of school. My point is sort of that that’s not the case, which potentially makes Haskell a tougher sell for the graduates of today.

MaxGabriel 7y ago

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

3fe9a03ccd14ca5 7y ago
> 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?
- MaxGabriel 7y ago
  Sort of. So far most of our hires have Haskell experience. Haskell was the main reason programmers would want to join us, so they would be naturally experienced in Haskell. I’ll have a better idea of how non-Haskellers, including very junior engineers, pick up Haskell later this year. Based on our limited sample size so far, I think people become productive within 4–6 weeks or so.

qafy 7y ago

Pragmatism is priceless in large scale production systems. I just recently started a new job as a front-end engineer where we use Go for all our backend services. I have never used Go before, and likely won't much in the future either, but I absolutely love how absolutely dead simple it is. You've got conditionals, loops, structs, slices (arrays), and functions, and that is about it. Even though I don't write Go code I can still read, understand, and reason about all our systems. The same cannot be said about your average junior or front-end dev trying to understand Haskell or Lisp or other obscure high level languages.

weavie 7y ago

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!

reikonomusha 7y ago
I think good mentorship, good code review, and good tests are critical to anything, including Common Lisp. We are very strict about that and we’ve had excellent results. Non-sense and language game-playing is quickly and earnestly called out, and everybody lives a better developer life. 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.

TrackerFF 7y ago

I think a problem might be that the jr. devs don't even get the chance to look at the code, because they're not getting hired based on their lack of experience (ref. the laundry list of advanced requirements). 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.

OJFord 7y ago

> then Haskell may not be a good choice Or a Haskell-illiterate hire, or two weeks' max acceptable 'ramping up time', may not be a good choice.