31–40 of 143 posts
Do Haskell programming jobs really pay better than, say, a Java programming job?
Otherwise, I don't think many jobs pay more than Java engineer at FAANG.
>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.
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…
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.
- 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.)
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 o…
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.
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.)
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 o…
One example I like to cite is: What I’d you want to tee a stream in Python to two different substreams? Stack Overflow it and you see cargo culted duck-typed classes that don’t derive from any clear specification.
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…
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).
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.
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#.
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.)