12 ms·

Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inher

Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inheritance for encapsulation to be useful, for instance. The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "the right way to do things" (aka object oriented programming). I blame languages like Java for selling certain ideas as The Right Way, and building walls that intentionally prevent you from using other techniques from different schools of thought ("everything is an object, no you can't write a function outside of a class"). I think the functional paradigm has a lot of good ideas too, but in my experience they're just as annoying if they're strictly and tastelessly applied in the same way OOP principles often are. Don't be a "functional programmer", just take the ideas that are useful. I tend to prefer languages and tools that adopt good ideas without promoting a single specific way of thinking.

spotman 10y ago
Well said. I feel the same way about this as I do platforms. There is amazing projects on every platform. There is horrendous projects on every platform. Taking sides just a narrows your point of view and lessens the amount you can learn.
- tomcam 10y ago
  We have to take sides. If I commit to iPhone, but there's a lot of stuff in android but I can't take advantage of. And vice versa
  - spotman 10y ago
    Would that lead you to write an article that said 'goodbye android forever' and tell people to avoid it because you prefer iOS? That's the kind of 'taking sides' I was intending to articulate.
  - EpicEng 10y ago
    Choosing one platform over another should be a pragmatic decision, not a religious one (the latter of which would constitute 'taking sides').
eutectic 10y ago
Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real problem with OOP is not that it forces you to do things a particular way, it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad, and what's good about it (encapsulation, polymorphism) is not new.
- overgard 10y ago
  There are things that are painful to express in a pure functional language. I'll give you an example: rasterize a triangle to a mutable buffer. (An inherently mutable and stateful algorithm). You can certainly do this in a purely functional language, but I doubt it will be any clearer or more performant than its procedural C counterpart. I think pure functional programming is super useful in other contexts, for instance, a compiler. I'm weary of people suggesting that a specific school of thought is universally applicable, though.
  - MaulingMonkey 10y ago
    While I agree, within the same context, I want to point out that right next to rasterization you have shaders, which are a poster child for functional programming. A vertex shader just transforms an input vertex (and some other inputs) into an output vertex, and a fragment shader just transforms an input fragment (and some other inputs) into an output fragment. This is done at a scale so massively parallel that we have dedicated hardware for it, because your CPU doesn't have enough parallelism. Sure, HLSL and GLSL are locally procedural. The most recent fancy versions ofo them even allow for some shared state mutation within a thread wave, useful for certain niche uses. But in in their traditional contexts? I find even local mutation for most use cases to merely be a source of bugs and obfuscation via poor naming. And most of the built-in functions are pure.
MrBra 10y ago
> Programming paradigms are a lot like political parties And this comment is just.. politically correct.
qwertyuiop924 10y ago
Ah, another lisp programmer, I see.
rattray 10y ago
> I tend to prefer languages and tools that adopt good ideas without promoting a single specific way of thinking. Do you mean promoting, or enforcing? There are many aspects of, say, the Zen of Python that I am very grateful for.
threatofrain 10y ago
I think that inheritance and composition are not the interesting aspects of object oriented design, or of any language or paradigm. These are tools for code brevity / reuse / elegance. Advanced copying or ctrl-c. I would also argue that too much elegance in any language or design paradigm faces the same problem, in that elegance is often (but not completely) in tension with modularity or granularity of control, which is an engineering subgoal, because a common engineering situation is to experience system change (feature growth or reorganization of code), and improvements in granularity or modularity makes system restructuring easier. I think that object oriented design is more essentially about modelling distributed state, because you probably have multiple objects with their own internal state. I believe this means that object oriented design is highly concerned with protocolized communication and synchronization between distributed states, whether via messages or channels or something else. I believe that in distributed situations, object oriented design can be very harmonious with functional reactive programming strategy. You can easily and usefully have a situation where an object functionally updates its internal state with a typed stream of inputs.
frugalmail 10y ago
>everything is an object, no you can't write a function outside of a class This is all really semantics, when you consider static methods and classes as nothing more than namespace or extended function names.
zer0gravity 10y ago
You can view a programming language like a fighting weapon ( although I don't promote violence ). If the enemy is right in front of you, you may kill it easier with a sword then with a nunchaku. But if he is around the corner, you may have better chances with the nunchaku. Or if he's at a distance you may use shuriken. One weapon can't offer all benefits, because it becomes impractical or dangerous. The reason why an OOP language doesn't let you have functions outside a class, may be the same with why you don't have blades on a nunchaku. You may hurt yourself. One needs to understand the strenghts and weaknesess of each weapon, and when it's better to use it.
- turbohz 10y ago
  This will make a great Medium post!
avindroth 10y ago
Do not become a slave to paradigms; become a master. Slave obeys. Master chooses.
tome 10y ago
> Don't be a "functional programmer", just take the ideas that are useful. But it's not about taking. It's about giving. What interfaces do you provide to someone else? Are the datatypes that you define mutable? Do the functions that you expose behave statefully? Do they modify the outside world? All of these things are things that functional programming (I guess I'm thinking of Haskell-alikes specifically) nudge you away from. Functional languages take power away from you to give power to someone else: the consumers of what you write (who may be youself in the future).

spotman 10y ago

Well said. I feel the same way about this as I do platforms. There is amazing projects on every platform. There is horrendous projects on every platform. Taking sides just a narrows your point of view and lessens the amount you can learn.

tomcam 10y ago
We have to take sides. If I commit to iPhone, but there's a lot of stuff in android but I can't take advantage of. And vice versa
- spotman 10y ago
  Would that lead you to write an article that said 'goodbye android forever' and tell people to avoid it because you prefer iOS? That's the kind of 'taking sides' I was intending to articulate.
- EpicEng 10y ago
  Choosing one platform over another should be a pragmatic decision, not a religious one (the latter of which would constitute 'taking sides').

eutectic 10y ago

Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real problem with OOP is not that it forces you to do things a particular way, it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad, and what's good about it (encapsulation, polymorphism) is not new.

overgard 10y ago
There are things that are painful to express in a pure functional language. I'll give you an example: rasterize a triangle to a mutable buffer. (An inherently mutable and stateful algorithm). You can certainly do this in a purely functional language, but I doubt it will be any clearer or more performant than its procedural C counterpart. I think pure functional programming is super useful in other contexts, for instance, a compiler. I'm weary of people suggesting that a specific school of thought is universally applicable, though.
- MaulingMonkey 10y ago
  While I agree, within the same context, I want to point out that right next to rasterization you have shaders, which are a poster child for functional programming. A vertex shader just transforms an input vertex (and some other inputs) into an output vertex, and a fragment shader just transforms an input fragment (and some other inputs) into an output fragment. This is done at a scale so massively parallel that we have dedicated hardware for it, because your CPU doesn't have enough parallelism. Sure, HLSL and GLSL are locally procedural. The most recent fancy versions ofo them even allow for some shared state mutation within a thread wave, useful for certain niche uses. But in in their traditional contexts? I find even local mutation for most use cases to merely be a source of bugs and obfuscation via poor naming. And most of the built-in functions are pure.

MrBra 10y ago

> Programming paradigms are a lot like political parties And this comment is just.. politically correct.

qwertyuiop924 10y ago

Ah, another lisp programmer, I see.

rattray 10y ago

> I tend to prefer languages and tools that adopt good ideas without promoting a single specific way of thinking. Do you mean promoting, or enforcing? There are many aspects of, say, the Zen of Python that I am very grateful for.

threatofrain 10y ago

I think that inheritance and composition are not the interesting aspects of object oriented design, or of any language or paradigm. These are tools for code brevity / reuse / elegance. Advanced copying or ctrl-c. I would also argue that too much elegance in any language or design paradigm faces the same problem, in that elegance is often (but not completely) in tension with modularity or granularity of control, which is an engineering subgoal, because a common engineering situation is to experience system change (feature growth or reorganization of code), and improvements in granularity or modularity makes system restructuring easier. I think that object oriented design is more essentially about modelling distributed state, because you probably have multiple objects with their own internal state. I believe this means that object oriented design is highly concerned with protocolized communication and synchronization between distributed states, whether via messages or channels or something else. I believe that in distributed situations, object oriented design can be very harmonious with functional reactive programming strategy. You can easily and usefully have a situation where an object functionally updates its internal state with a typed stream of inputs.

frugalmail 10y ago

>everything is an object, no you can't write a function outside of a class This is all really semantics, when you consider static methods and classes as nothing more than namespace or extended function names.

zer0gravity 10y ago

You can view a programming language like a fighting weapon ( although I don't promote violence ). If the enemy is right in front of you, you may kill it easier with a sword then with a nunchaku. But if he is around the corner, you may have better chances with the nunchaku. Or if he's at a distance you may use shuriken. One weapon can't offer all benefits, because it becomes impractical or dangerous. The reason why an OOP language doesn't let you have functions outside a class, may be the same with why you don't have blades on a nunchaku. You may hurt yourself. One needs to understand the strenghts and weaknesess of each weapon, and when it's better to use it.

turbohz 10y ago
This will make a great Medium post!

avindroth 10y ago

Do not become a slave to paradigms; become a master. Slave obeys. Master chooses.

tome 10y ago

> Don't be a "functional programmer", just take the ideas that are useful. But it's not about taking. It's about giving. What interfaces do you provide to someone else? Are the datatypes that you define mutable? Do the functions that you expose behave statefully? Do they modify the outside world? All of these things are things that functional programming (I guess I'm thinking of Haskell-alikes specifically) nudge you away from. Functional languages take power away from you to give power to someone else: the consumers of what you write (who may be youself in the future).