4 ms·

The fact that there are only two backend developers seems like a big asterisk to me. It's admirable how productive their backend team has been, but tiny teams

by nfw2 5y ago

The fact that there are only two backend developers seems like a big asterisk to me. It's admirable how productive their backend team has been, but tiny teams are often surprisingly productive. Communication costs and distributed decision-making often slow development a lot. What I'm wondering, as someone who doesn't know Haskell, is how well will it work if the team needs to scale? Will they be able to find quality engineers? Will those new engineers be able to easily pick up the pieces if one of the two engineers leaves unexpectedly? I certainly am biased here, but pure functional programming has always seemed unnecessarily abstract and constricted for the purposes of most applications. The communication of function and purpose to other engineers is an important responsibility of code. Using long sequences of poorly-labeled, nested arrow function returns is great fun until you have the task of deciphering someone else's. To be clear, I am not suggesting all Haskell code is poorly-written or hard to understand. But writing clear code is not a priority for a lot of engineers, and in my experience, functional programming can lead to especially opaque codebases.

tome 5y ago
> in my experience, functional programming can lead to especially opaque codebases. That's interesting because my first favourite language was Python, but I gave it up for Haskell because of the former's propensity to lead to especially opaque codebases.
rgoulter 5y ago
For one, yeah, I think in important part is that the choice of technical tools is made for good reasons. A default, boring choice is probably okay. A more exciting choice might be okay. For people who pick NodeJS.. for some, it may be the only thing they know, it might be something they dislike, or it might be something that seems practical. -- I dunno how many people pick Haskell out of practicality but would rather be using something else. It's lame if someone picks a technology for bad reasons, and then makes bad decisions to exasperate it. e.g. Kubernetes is not bad, but I think if you end up with 5x as many microservices as developers, you've made a mistake. All the same.. I think it's easy to write hard-to-understand code in any language.
sullyj3 5y ago
> Using long sequences of poorly-labeled, nested arrow function returns is great fun until you have the task of deciphering someone else's. Something like that would be considered bad Haskell code, yes. Haskell is designed from the ground up to support the functional paradigm. When people try to use functional style in languages that were designed with primarily procedural style in mind, the result is often ugly and difficult to follow. You just don't have the same issue in a language that's designed from the beginning as a functional language. Something that people tend to miss is that you can write code that very much looks like a lot of procedural code in haskell: let x = 1 y = x + 5 z = 10 + y + z in x + y + z You can have bindings, just like you might use variables in a (eg) python function. The only difference is that the bindings are immutable. That turns out to not be as restrictive as you might expect - a lot of good python code only assigns to a given variable once. I think it's a fair criticism to say that Haskell code can become opaque when it relies on more advanced language features and esoteric GHC extensions. The solution to this is to be disciplined and selective as a team about choosing which features you believe are worth their complexity/onboarding cost, and sticking to those choices. Conversely, I find Haskell code that doesn't use those extra features to be much easier to understand than equivalent code in other languages, due to the extra guarantees I have about the code. For instance, I know that variables won't be mutated out from under me, things can't be null where they shouldn't be, and there are plenty of other assorted guarantees that come from having access to an expressive type system.
- mpoteat 5y ago
  Perhaps this is pedantic, but that doesn't look like good procedural code to me. Instead, it looks like a set of mathematical equations. I think there is intrinsic value in simple, procedural code that has state and produces side effects - it can even be typed! However, I think FP maximalism is bad for code readability. How might you write to a MongoDB document in Haskell, for example? A common example in this space is how to specify a baking recipe. Do you list it as a series of steps to perform on the world, or do you reductively assert what a cake is from base principles? I think Haskell developers need to realize that pure functional programming is intrinsically more difficult than other kinds. It requires a much higher ceiling for abstract thought. What I'm essentially trying to assert is that you have to be smarter than average (whatever that means) to read and write Haskell code. I believe this accounts for the majority of the perceived efficiency. The cost is that you are excluding people who are not mathematically talented.

by nfw2 5y ago

tome 5y ago

> in my experience, functional programming can lead to especially opaque codebases. That's interesting because my first favourite language was Python, but I gave it up for Haskell because of the former's propensity to lead to especially opaque codebases.

rgoulter 5y ago

For one, yeah, I think in important part is that the choice of technical tools is made for good reasons. A default, boring choice is probably okay. A more exciting choice might be okay. For people who pick NodeJS.. for some, it may be the only thing they know, it might be something they dislike, or it might be something that seems practical. -- I dunno how many people pick Haskell out of practicality but would rather be using something else. It's lame if someone picks a technology for bad reasons, and then makes bad decisions to exasperate it. e.g. Kubernetes is not bad, but I think if you end up with 5x as many microservices as developers, you've made a mistake. All the same.. I think it's easy to write hard-to-understand code in any language.

sullyj3 5y ago

> Using long sequences of poorly-labeled, nested arrow function returns is great fun until you have the task of deciphering someone else's. Something like that would be considered bad Haskell code, yes. Haskell is designed from the ground up to support the functional paradigm. When people try to use functional style in languages that were designed with primarily procedural style in mind, the result is often ugly and difficult to follow. You just don't have the same issue in a language that's designed from the beginning as a functional language. Something that people tend to miss is that you can write code that very much looks like a lot of procedural code in haskell: let x = 1 y = x + 5 z = 10 + y + z in x + y + z You can have bindings, just like you might use variables in a (eg) python function. The only difference is that the bindings are immutable. That turns out to not be as restrictive as you might expect - a lot of good python code only assigns to a given variable once. I think it's a fair criticism to say that Haskell code can become opaque when it relies on more advanced language features and esoteric GHC extensions. The solution to this is to be disciplined and selective as a team about choosing which features you believe are worth their complexity/onboarding cost, and sticking to those choices. Conversely, I find Haskell code that doesn't use those extra features to be much easier to understand than equivalent code in other languages, due to the extra guarantees I have about the code. For instance, I know that variables won't be mutated out from under me, things can't be null where they shouldn't be, and there are plenty of other assorted guarantees that come from having access to an expressive type system.

mpoteat 5y ago
Perhaps this is pedantic, but that doesn't look like good procedural code to me. Instead, it looks like a set of mathematical equations. I think there is intrinsic value in simple, procedural code that has state and produces side effects - it can even be typed! However, I think FP maximalism is bad for code readability. How might you write to a MongoDB document in Haskell, for example? A common example in this space is how to specify a baking recipe. Do you list it as a series of steps to perform on the world, or do you reductively assert what a cake is from base principles? I think Haskell developers need to realize that pure functional programming is intrinsically more difficult than other kinds. It requires a much higher ceiling for abstract thought. What I'm essentially trying to assert is that you have to be smarter than average (whatever that means) to read and write Haskell code. I believe this accounts for the majority of the perceived efficiency. The cost is that you are excluding people who are not mathematically talented.