21–30 of 143 posts
>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.
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.
Earlier quoted context omitted.
Elixir is pretty great if you're not super hung up on type systems.
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
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?
(I don't work in Haskell. Now I have mixed feelings about it.)
Earlier quoted context omitted.
It's like when you're a kid and you think adults have everything figured out. When you pull on the thread, you find that a lot of successful developers don't really have that clear a picture of what it is they did and how they did it. It gets covered with bluster and bluffs. Impugning the other person for not 'getting it' and getting defensive about the 'documentation' they wrote and how everything you need is in the…
I've been through that stage (grumpy defensive programmer). On the other side is a deep humbleness when as a programmer you realise you know nothing, you never really knew. You just knew how to research and fix the problem really fast.
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#.
The tooling is pretty good now, but there are still pain points (breakpointing/stepping pipes |>, inlines, and pattern matching expressions), but even w/that said the tooling is probably above avg. now. If you want the best refactoring and debugging experience (Resharper, OzCode, etc.) the C# is still the best there.
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.
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…
> Employee writes a ton of really fancy Haskell, delivers fantastically and in about 1000 lines of code. Everyone is very impressed. The project grows in scope. > > 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…
That's the thing a lot of devs who hire don't get. You don't necessarily need someone who knows the language inside and out on day one. What you need is someone smart and who can demonstrate that they can learn new languages quickly. They understand the fundamentals of how to write software. Language specific abstractions are just muscle memory.