Static OOP - so much ceremonial overhead to create things, but able to optimize perf
Dynamic OOP - minimal ceremony. but OOP still has challenges. inheritance models make it easy to arrive at awkward abstractions. mutable statement-based syntax naturally leads to challenges in testing/maintainability. takes a while to learn all the practices to make OOP nice.
Static FP with monads - advanced math and inscrutable symbols for maximum conciseness and minimum readability to outsiders. takes a while to learn how to use it.
Lisp Dynamic FP (Clojure) - idea-wise, I like it the best (the language is also the compiler). but hard to get into. relies on tooling a bit. common coding styles seem overly optimized for execution to detriment of human readability.
Static plain FP - almost feels dynamic with type inference. can optimize perf. separating data and functions makes composability and reuse more plausible than with objects. some extra boilerplate w/o advanced type/compiler features.
Static plain FP is my preference. It is highly maintainable when you use immutability and deterministic decisions. If you are are new to programming it is easiest to learn among these, based on my experience training new devs. However if you are already accustomed to statements / mutability, it can be a challenge to transition to using immutability and deterministic decisions.
You can get work done in any of them. And with enough experience or investment, you can even manage to avoid most of the pitfalls mentioned.
Static plain FP - almost feels dynamic with type inference. can optimize perf. separating data and functions makes composability and reuse more plausible than with objects. some extra boilerplate w/o advanced type/compiler features.
Data-scientist who loves to use #datascienceforgood, especially in ecology, energy and the environment. Bonsai, gardening, bikes and music when I'm not at a keyboard.
Neat breakdown. Within the criteria listed above, where would you put R? It is now very common to write 'tidy' R code, which stylistically pipes with the %>%. This, as far as I understand monads, seems to represent the monadic axioms. It however is not static but dynamic (as far as I understand those terms to refer to typing). It's also not a LISP, but derived from a pretty odd language in itself called S. It's also not immutable, however it encourages currying by default.
Personally, it's obviously my bag, but how to the rest of you see it fitting in above?
I'm not too familiar with R, so I won't attempt to declare if/which category it might fall into. (I only went over FP/OO approaches.) But you bring up an interesting point with the pipe operator. A lot of the constructs we use in programming can be proven from category theory or other area of math. But this isn't exactly what I meant by FP with monads.
When I mentioned FP with monads, I was referring to code bases that use named category theory abstractions like Monad, Monoid, Semigroup, etc. The value proposition is enticing... instead of arbitrary abstractions (custom objects), use these known abstractions with mathematically provable properties/behaviors. And build the application up from those. Theoretically, every time someone creates a new custom type of object, you have to learn its custom rules. But basing the code on category theory abstractions, you can learn a single set of math-based objects. Unfortunately to contribute to or even read such code, a dev has to backfill a lot of knowledge from advanced math. Which is a larger barrier than understanding some custom objects. And the interactions of different category theory constructs are many and varied. So the category theory stuff doesn't turn out to be a small set of things to learn, either.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think there are nuances within each.
Static plain FP is my preference. It is highly maintainable when you use immutability and deterministic decisions. If you are are new to programming it is easiest to learn among these, based on my experience training new devs. However if you are already accustomed to statements / mutability, it can be a challenge to transition to using immutability and deterministic decisions.
You can get work done in any of them. And with enough experience or investment, you can even manage to avoid most of the pitfalls mentioned.
Nice synopsis! Head nods to all the goodies
yeah! :D
my favorite too
Neat breakdown. Within the criteria listed above, where would you put R? It is now very common to write 'tidy' R code, which stylistically pipes with the
%>%
. This, as far as I understand monads, seems to represent the monadic axioms. It however is not static but dynamic (as far as I understand those terms to refer to typing). It's also not a LISP, but derived from a pretty odd language in itself called S. It's also not immutable, however it encourages currying by default.Personally, it's obviously my bag, but how to the rest of you see it fitting in above?
I'm not too familiar with R, so I won't attempt to declare if/which category it might fall into. (I only went over FP/OO approaches.) But you bring up an interesting point with the pipe operator. A lot of the constructs we use in programming can be proven from category theory or other area of math. But this isn't exactly what I meant by FP with monads.
When I mentioned FP with monads, I was referring to code bases that use named category theory abstractions like Monad, Monoid, Semigroup, etc. The value proposition is enticing... instead of arbitrary abstractions (custom objects), use these known abstractions with mathematically provable properties/behaviors. And build the application up from those. Theoretically, every time someone creates a new custom type of object, you have to learn its custom rules. But basing the code on category theory abstractions, you can learn a single set of math-based objects. Unfortunately to contribute to or even read such code, a dev has to backfill a lot of knowledge from advanced math. Which is a larger barrier than understanding some custom objects. And the interactions of different category theory constructs are many and varied. So the category theory stuff doesn't turn out to be a small set of things to learn, either.