4 ms·

I'm not sure if people using functional languages are more productive. One of the points Uncle Bob makes in his talk supporting functional programming is that i

I'm not sure if people using functional languages are more productive. One of the points Uncle Bob makes in his talk supporting functional programming is that it is harder and slower to write: https://youtu.be/7Zlp9rKHGD4 https://youtu.be/7Zlp9rKHGD4 That said, I have to wonder if these dynamic scripting languages are truly enabling productivity or if it just feels like that because you can write it and try many things quickly. It reminds me of being such in traffic on the highway - sometimes I get off and take back roads even if my GPS tells me it will take longer, because it is more pleasant to be moving than feeling stuck. That said, I think the biggest benefit of dynamic languages is that they are so easy to refactor. You don't have as rigid a structure, so you can try easily hack together some idea that, done "properly", would require a big refactor. Despite being functional, Haskell's strong type system makes refactoring a huge pain. If course the same things enabling this quick refactoring in the dynamic languages works against you when it comes to speed and reliability.

ggm 8y ago
I sit with an FP expert (he might deny it, but he is). What I find, is that he takes a lot longer to get to the solution that I hack out in a day in Python3 (with his assistance most of the time) but his solution has three interesting properties. 1) its usually founded on a very good understanding of the problem, and the abstractions inherent in the problem. If he can re-use the abstractions he has used before he does, to great effect in speed-to-solution 2) it is very usually correct. it is remarkably bug free because the Haskell typing removes a huge amount of ambiguity about the problem going in 3) he has absolutely no problem explaining what it does 3 months or more later. I value these behaviours immensely. My own Python is usually buggy, often re-produces techniques I did a week ago, badly, and I can't explain why I used that lambda/map function.
- 2wrist 8y ago
  It is really cool when you can find people like this. He sounds class!
  - ggm 8y ago
    He is!
- gugagore 8y ago
  I'm very curious about what kinds of problems these are. Any chance you can give us an idea?
  - ggm 8y ago
    Typically processing data from logs, analyses of SQL state changes in the absence of good knowledge of the prior states. Some stuff which is aggregation over disparate inputs where a DSL can be useful. A lot of the time radix trees and other prefix/length matching logic is being used. Sometimes we're cross correlating different sources against disparate common keys. Some stuff connecting type: value record structures into JSON. We work a lot on ill-formed requests to refine data previously worked on with new questions. We work a lot on small distributed systems exploring eventual consistency and event sourcing. We work with quite large logfiles collected asynchronously, with poor clock alignment. So data buffering and sorting is not uncommon.
michaelcampbell 8y ago
Faster to write -> faster to market Slower to write (and get right) -> fewer bugs to deal with later Pick your poison
- coldtea 8y ago
  That's really a no brainer. Having your company survive (because you got something faster to market), and having bugs to deal with later, is a so-called "nice problem to have". The bug-less software of a dead company does nobody good.
  - dTal 8y ago
    Quick 'n' dirty might be fine for a move-fast-and-break-things web startup, but the world is much larger than that. I sincerely hope the people writing the software in, let's say an airliner to choose a topical example, choose option 2. Dealing with bugs that have killed people is not a "nice problem to have". (It depresses me that I have to write a defense of good engineering on Hacker news. The value of doing things correctly should be a tacit core principle of any engineer, to be broken only under circumstances of exceptional duress.)
    - coldtea 8y ago
      Most domains are not of the "killing people" type. In those places, they also have other kinds of compliance requirements for the code -- which makes sense: I wouldn't leave the airline software PMs to chose between the above two options.
      - dTal 8y ago
        Most domains are also not the "finish the job by next Thursday or the company folds" type either. You're going to have to pay back that technical debt someday, with interest - why not save time and do it right the first time? (Typical SV answer: you're only thinking of the short term because you're trying to get investment and you plan to exit stage left with a fat packet long before the technical debt rears its ugly head, leaving somebody else to clean up the mess. But this is not how most engineering is done in the real world.)
nikofeyn 8y ago
i don't think that's true for multiparadigm functional languages like f#, racket, and others. these languages allow you to solve problems in the best way and don't necessarily bind you to some draconian perspective like haskell. functional doesn't necessarily mean static typing. scheme and racket are functional languages.
- dual_basis 8y ago
  I have found that much of the benefit of functional programming is in the consistent guarantees it makes, not only about your own code but also others' that you depend on. Languages that try to do it all often leave me feeling disjointed. You end up with some libraries written in a strong OOP style, but then others are written with a functional flavor, and then your own code necessarily has to take on a strange amalgamation of the two.

ggm 8y ago

I sit with an FP expert (he might deny it, but he is). What I find, is that he takes a lot longer to get to the solution that I hack out in a day in Python3 (with his assistance most of the time) but his solution has three interesting properties. 1) its usually founded on a very good understanding of the problem, and the abstractions inherent in the problem. If he can re-use the abstractions he has used before he does, to great effect in speed-to-solution 2) it is very usually correct. it is remarkably bug free because the Haskell typing removes a huge amount of ambiguity about the problem going in 3) he has absolutely no problem explaining what it does 3 months or more later. I value these behaviours immensely. My own Python is usually buggy, often re-produces techniques I did a week ago, badly, and I can't explain why I used that lambda/map function.

2wrist 8y ago
It is really cool when you can find people like this. He sounds class!
- ggm 8y ago
  He is!
gugagore 8y ago
I'm very curious about what kinds of problems these are. Any chance you can give us an idea?
- ggm 8y ago
  Typically processing data from logs, analyses of SQL state changes in the absence of good knowledge of the prior states. Some stuff which is aggregation over disparate inputs where a DSL can be useful. A lot of the time radix trees and other prefix/length matching logic is being used. Sometimes we're cross correlating different sources against disparate common keys. Some stuff connecting type: value record structures into JSON. We work a lot on ill-formed requests to refine data previously worked on with new questions. We work a lot on small distributed systems exploring eventual consistency and event sourcing. We work with quite large logfiles collected asynchronously, with poor clock alignment. So data buffering and sorting is not uncommon.

michaelcampbell 8y ago

Faster to write -> faster to market Slower to write (and get right) -> fewer bugs to deal with later Pick your poison

coldtea 8y ago
That's really a no brainer. Having your company survive (because you got something faster to market), and having bugs to deal with later, is a so-called "nice problem to have". The bug-less software of a dead company does nobody good.
- dTal 8y ago
  Quick 'n' dirty might be fine for a move-fast-and-break-things web startup, but the world is much larger than that. I sincerely hope the people writing the software in, let's say an airliner to choose a topical example, choose option 2. Dealing with bugs that have killed people is not a "nice problem to have". (It depresses me that I have to write a defense of good engineering on Hacker news. The value of doing things correctly should be a tacit core principle of any engineer, to be broken only under circumstances of exceptional duress.)
  - coldtea 8y ago
    Most domains are not of the "killing people" type. In those places, they also have other kinds of compliance requirements for the code -- which makes sense: I wouldn't leave the airline software PMs to chose between the above two options.
    - dTal 8y ago
      Most domains are also not the "finish the job by next Thursday or the company folds" type either. You're going to have to pay back that technical debt someday, with interest - why not save time and do it right the first time? (Typical SV answer: you're only thinking of the short term because you're trying to get investment and you plan to exit stage left with a fat packet long before the technical debt rears its ugly head, leaving somebody else to clean up the mess. But this is not how most engineering is done in the real world.)

nikofeyn 8y ago

i don't think that's true for multiparadigm functional languages like f#, racket, and others. these languages allow you to solve problems in the best way and don't necessarily bind you to some draconian perspective like haskell. functional doesn't necessarily mean static typing. scheme and racket are functional languages.

dual_basis 8y ago
I have found that much of the benefit of functional programming is in the consistent guarantees it makes, not only about your own code but also others' that you depend on. Languages that try to do it all often leave me feeling disjointed. You end up with some libraries written in a strong OOP style, but then others are written with a functional flavor, and then your own code necessarily has to take on a strange amalgamation of the two.