4 ms·

I’m just a guy, so take what I say with a grain of salt. This problem is broadly solved by a combination of domain-driven design (DDD) and functional programmi

by epgui 3y ago

I’m just a guy, so take what I say with a grain of salt. This problem is broadly solved by a combination of domain-driven design (DDD) and functional programming (FP). Yes, I know you’re tired of hearing about FP and you think FP engineers are all white bearded monad salespeople. I don’t care. Odds are, if you’re an engineer, you’re not doing purely abstract work: your code has some correspondence to “stuff in the real world”. FP is unencumbered by the class/object model and you can abstract over anything trivially using plain old functions: don’t “choose” your abstractions, use these, and your domain models, to figure out what the correct/real(est) abstractions are. It’s not so much about too much or too little abstractions, it’s about how suitable the abstractions are.

leetrout 3y ago
Speaking for myself I think FP is going to have its moment and it will be when average devs can ignore the syntax and theories in the abstract and just solve problems. Pretty much everything is better with FP and walking a reasonable line when showing benefits _without_ immediately diving into all the esoteric parts wins people. We need the MVC of FP type of trendy bandwagon. The FP rails. I am optimistic about Roc and hope Rust also continues to help make FP style programming more commonplace even if I still dont know how to implement a monad.
- epgui 3y ago
  Re: monad For my part, the most confusing thing was that I was trying to understand monads by looking at both haskell and category theory. However, a monad in computer code is a different beast than a monad in category theory (I believe this may be true in every programming language currently, but if you have a counter-example I'd love to hear about it). They look vaguely similar, but aren’t the same thing. Nobody told me this, but it greatly simplified comprehension once I had that epiphany. A lot of monad explanations just confuse monads and functors too (functors are your burritos / wrapper data types; and functors should probably be understood before monads). IMO seeing monads as being primarily about function composition, kind of like the functions `compose` or `pipe` or `thread_first` or `thread_last`… but in a context that makes use of functors, is the best way to really see the core simplicity of the idea.
avindroth 3y ago
I like FP, but I don't think the situation is solved by FP. There's a lot more room for discussion of abstraction and complexity within FP.
- epgui 3y ago
  My comment said it was “broadly solved” by a combination of FP and DDD, not by FP on its own, and not completely solved either (the problem described is multifaceted and you can find many ways to screw it up regardless of what tools or frameworks you pick up… but certain tools are a bit harder to point at your foot).
intelVISA 3y ago
Functional is generally accepted as The Best Abstraction imo
- epgui 3y ago
  Generally accepted… But by whom? If you mean “the software engineering community at large”, I’m not so sure… I’d say from my experience: [*] - >98% of engineers are mostly familiar with OOP - about 1% of engineers “write FP code imperatively” without knowing that they’re kind of missing the point And among the >98%: - 20% think FP is about using map/filter/reduce (not a bad start, but misses the main ideas) - 35% are openly hostile to FP for a whole variety of reasons, some better than others but none great - The rest don’t really know what FP is, and if they’d have to guess they’d say it’s when you use functions. We no longer have the same performance constraints that computer scientists had to deal with in the very early days of computing, when the theory was being written and the von neumann style of programming began to take hold. It will still take a long time (I’d wager decades) before the findings of academics are accepted in the industry. [*] These figures are all made up and are presented only as a rough way to communicate my perspective based on my experience… But again I am not particularly qualified to speak to this.
  - intelVISA 3y ago
    I fear you may be right. It always felt a struggle to use FP in perf constrained contexts but with modern compute making that largely irrelevant there's really no reason to avoid indulging one's self. It is interesting though, the openly hostile subset you describe I don't really consider as working in SWE as it would be the equiv. of working in a kitchen and saying you reject using knives.
    - epgui 3y ago
      There are certainly specialized areas where FP is inappropriate, maybe even for fundamental reasons (although I am not 100% sure of this: compilers have been improving rapidly, I don't have a great sense of how much further we can theoretically/fundamentally push a c compiler versus a haskell compiler, and the variety of possible type systems adds enough complications to make my head spin). But --and maybe there's a certain skew in my work experience?-- that's probably not really relevant to the vast majority of the programming that gets done. By my estimation, most professional software engineers spend most of their time working on nonrevolutionary, fairly mundane things, like basic crud apps, web apps, microservices, frontend, backend... While a minority (I think?) work on games, codecs, embedded systems, etc. (That's not to say that performance is never a concern in these areas, of course.) But dwarfing all of the above, in numbers, are all the people who are not professional software engineers, and who are writing code as an extension of the specific work they are doing in their domain (that's all your python scripts, R scripts, ad hoc sql, lab work, etc). I'll suggest something controversial here: anything people typically think python is good for, [haskell|racket|...] is probably way better at it. That's kind of where I see the most obvious use cases. In my view anyway, it's a pretty good bet that the step-change in complexity reduction you get with FP (big scary words notwithstanding; I am speaking here of the programs' complexity) would actually have a massive positive impact on the accessibility of programming/sw-engineering to newcomers, as well as on programming/sw-engineering's already-impressive propensity for enabling cross-talk between disciplines. There's soooooooo many low hanging fruits in programming literacy.
keyle 3y ago
One of the best post on FP I read was John Carmack's realisation that FP had a strong place in any code base [0]. It's a really valuable lesson to keep most function as pure and stateless, but transformation of the existing state. Build your entire codebase around this idea and frankly, abstraction will take care of itself. [0] http://www.sevangelatos.com/john-carmack-on/ http://www.sevangelatos.com/john-carmack-on/
- syntheweave 3y ago
  Carmack's ideas did a lot for my code. He has good insights around what to take from different problem domains in order to get a result that gets right to the point and solves a specific category of error. You should never settle for "squishy" code that looks pretty just because: the code must do this, it cannot do that. Write it at the top of the function, and the best code will just go right to the goal without grabbing on to any boilerplate. That's something I was really missing in my earlier programming years, when all I saw were Java, Python and Ruby bloggers regurgitating OOP and Agile terms and I would try out their idea, marvel at the visible complexity of the abstraction, but then see it fail in a practical scenario. WTF.

by epgui 3y ago

leetrout 3y ago

Speaking for myself I think FP is going to have its moment and it will be when average devs can ignore the syntax and theories in the abstract and just solve problems. Pretty much everything is better with FP and walking a reasonable line when showing benefits _without_ immediately diving into all the esoteric parts wins people. We need the MVC of FP type of trendy bandwagon. The FP rails. I am optimistic about Roc and hope Rust also continues to help make FP style programming more commonplace even if I still dont know how to implement a monad.

epgui 3y ago
Re: monad For my part, the most confusing thing was that I was trying to understand monads by looking at both haskell and category theory. However, a monad in computer code is a different beast than a monad in category theory (I believe this may be true in every programming language currently, but if you have a counter-example I'd love to hear about it). They look vaguely similar, but aren’t the same thing. Nobody told me this, but it greatly simplified comprehension once I had that epiphany. A lot of monad explanations just confuse monads and functors too (functors are your burritos / wrapper data types; and functors should probably be understood before monads). IMO seeing monads as being primarily about function composition, kind of like the functions `compose` or `pipe` or `thread_first` or `thread_last`… but in a context that makes use of functors, is the best way to really see the core simplicity of the idea.

avindroth 3y ago

I like FP, but I don't think the situation is solved by FP. There's a lot more room for discussion of abstraction and complexity within FP.

epgui 3y ago
My comment said it was “broadly solved” by a combination of FP and DDD, not by FP on its own, and not completely solved either (the problem described is multifaceted and you can find many ways to screw it up regardless of what tools or frameworks you pick up… but certain tools are a bit harder to point at your foot).

intelVISA 3y ago

Functional is generally accepted as The Best Abstraction imo

epgui 3y ago
Generally accepted… But by whom? If you mean “the software engineering community at large”, I’m not so sure… I’d say from my experience: [*] - >98% of engineers are mostly familiar with OOP - about 1% of engineers “write FP code imperatively” without knowing that they’re kind of missing the point And among the >98%: - 20% think FP is about using map/filter/reduce (not a bad start, but misses the main ideas) - 35% are openly hostile to FP for a whole variety of reasons, some better than others but none great - The rest don’t really know what FP is, and if they’d have to guess they’d say it’s when you use functions. We no longer have the same performance constraints that computer scientists had to deal with in the very early days of computing, when the theory was being written and the von neumann style of programming began to take hold. It will still take a long time (I’d wager decades) before the findings of academics are accepted in the industry. [*] These figures are all made up and are presented only as a rough way to communicate my perspective based on my experience… But again I am not particularly qualified to speak to this.
- intelVISA 3y ago
  I fear you may be right. It always felt a struggle to use FP in perf constrained contexts but with modern compute making that largely irrelevant there's really no reason to avoid indulging one's self. It is interesting though, the openly hostile subset you describe I don't really consider as working in SWE as it would be the equiv. of working in a kitchen and saying you reject using knives.
  - epgui 3y ago
    There are certainly specialized areas where FP is inappropriate, maybe even for fundamental reasons (although I am not 100% sure of this: compilers have been improving rapidly, I don't have a great sense of how much further we can theoretically/fundamentally push a c compiler versus a haskell compiler, and the variety of possible type systems adds enough complications to make my head spin). But --and maybe there's a certain skew in my work experience?-- that's probably not really relevant to the vast majority of the programming that gets done. By my estimation, most professional software engineers spend most of their time working on nonrevolutionary, fairly mundane things, like basic crud apps, web apps, microservices, frontend, backend... While a minority (I think?) work on games, codecs, embedded systems, etc. (That's not to say that performance is never a concern in these areas, of course.) But dwarfing all of the above, in numbers, are all the people who are not professional software engineers, and who are writing code as an extension of the specific work they are doing in their domain (that's all your python scripts, R scripts, ad hoc sql, lab work, etc). I'll suggest something controversial here: anything people typically think python is good for, [haskell|racket|...] is probably way better at it. That's kind of where I see the most obvious use cases. In my view anyway, it's a pretty good bet that the step-change in complexity reduction you get with FP (big scary words notwithstanding; I am speaking here of the programs' complexity) would actually have a massive positive impact on the accessibility of programming/sw-engineering to newcomers, as well as on programming/sw-engineering's already-impressive propensity for enabling cross-talk between disciplines. There's soooooooo many low hanging fruits in programming literacy.

keyle 3y ago

One of the best post on FP I read was John Carmack's realisation that FP had a strong place in any code base [0]. It's a really valuable lesson to keep most function as pure and stateless, but transformation of the existing state. Build your entire codebase around this idea and frankly, abstraction will take care of itself. [0] http://www.sevangelatos.com/john-carmack-on/ http://www.sevangelatos.com/john-carmack-on/

syntheweave 3y ago
Carmack's ideas did a lot for my code. He has good insights around what to take from different problem domains in order to get a result that gets right to the point and solves a specific category of error. You should never settle for "squishy" code that looks pretty just because: the code must do this, it cannot do that. Write it at the top of the function, and the best code will just go right to the goal without grabbing on to any boilerplate. That's something I was really missing in my earlier programming years, when all I saw were Java, Python and Ruby bloggers regurgitating OOP and Agile terms and I would try out their idea, marvel at the visible complexity of the abstraction, but then see it fail in a practical scenario. WTF.