3 ms·

Pipelines are effective for expressing functional concepts but are not suitable for general programming. E.g writing merge sort or a chaining hash table as a pi

Pipelines are effective for expressing functional concepts but are not suitable for general programming. E.g writing merge sort or a chaining hash table as a pipeline won't work out well. The problem is state. There are dataflow programming languages like Lustre and Esterel that tried to incorporate state as back arrows in their pipelines. It didn't work out so well.

anonzzzies 3y ago
But most things most people do during the day is not general programming. it would benefit from having to use principles like this instead of using 'general programming' to do them in a way that's harder to understand, harder to debug etc.
- AnimalMuppet 3y ago
  > But most things most people do during the day is not general programming. Well, in one sense, nobody ever writes a general program - they only write specific ones. But if your claim is "most things most people do during the day could be pipelined", I'd like to see your supporting evidence, because I'm not at all sure that claim is true. For example, as far as I understand, GUIs are very hard to pipeline. How much of the programming done in the average day is on GUIs?
  - anonzzzies 3y ago
    > I'd like to see your supporting evidence, because I'm not at all sure that claim is true I believe it is, but of course it's hard to prove; I have my own libs in whatever language I use which are piping libraries very much inspired by FP, LINQ, Haskell, APL/k and other such things. And most things I do, do fit. But yeah; how to show that; I can translate most things we write anyway. We write SaaS in the broadest sense. > For example, as far as I understand, GUIs are very hard to pipeline. Are they? Aren't we pulling data in reducers, transforming it to structures that can be shown in the templates and transforming again on input/click and sending somewhere? It's all pipes, kind of. Sure, some things are not, but those things at least we don't encounter very often. And when they are pipes, other ways of processing are just plainly worse in every way imho.
- bjourne 3y ago
  I don't believe in creating methodologies for blub programmers which they nevertheless have to abandon to do "real" programming. 90% of the problems comes from 10% of the code so that's what you got to address. I.e. Give me a blabla-oriented programming paradigm that makes writing efficient merge sorts easier and I'm all ears, one that can't even realistically do it just makes me yawn.
  - anonzzzies 3y ago
    Apparently you write merge sorts a lot; why and for what? Who writes low level code like that? I have and can but I don’t need it often. Seems you do? And if you do, then sure, it doesn’t fit the case.
mrkeen 3y ago
"The problem is state" is precisely why I do my general programming with functions.
- marginalia_nu 3y ago
  Isn't the call stack also a form of state?
  - mrkeen 3y ago
    It is, but not in the way that imperiative aficionados would use it. There are no imperative programmers, who are interested in FP - but won't switch to it because they'd have to give up their pragmatic getCallStack() and setCallStack() methods.
trashtensor 3y ago
There are some things it's useful for and some things it isn't. Go figure.

anonzzzies 3y ago

But most things most people do during the day is not general programming. it would benefit from having to use principles like this instead of using 'general programming' to do them in a way that's harder to understand, harder to debug etc.

AnimalMuppet 3y ago
> But most things most people do during the day is not general programming. Well, in one sense, nobody ever writes a general program - they only write specific ones. But if your claim is "most things most people do during the day could be pipelined", I'd like to see your supporting evidence, because I'm not at all sure that claim is true. For example, as far as I understand, GUIs are very hard to pipeline. How much of the programming done in the average day is on GUIs?
- anonzzzies 3y ago
  > I'd like to see your supporting evidence, because I'm not at all sure that claim is true I believe it is, but of course it's hard to prove; I have my own libs in whatever language I use which are piping libraries very much inspired by FP, LINQ, Haskell, APL/k and other such things. And most things I do, do fit. But yeah; how to show that; I can translate most things we write anyway. We write SaaS in the broadest sense. > For example, as far as I understand, GUIs are very hard to pipeline. Are they? Aren't we pulling data in reducers, transforming it to structures that can be shown in the templates and transforming again on input/click and sending somewhere? It's all pipes, kind of. Sure, some things are not, but those things at least we don't encounter very often. And when they are pipes, other ways of processing are just plainly worse in every way imho.
bjourne 3y ago
I don't believe in creating methodologies for blub programmers which they nevertheless have to abandon to do "real" programming. 90% of the problems comes from 10% of the code so that's what you got to address. I.e. Give me a blabla-oriented programming paradigm that makes writing efficient merge sorts easier and I'm all ears, one that can't even realistically do it just makes me yawn.
- anonzzzies 3y ago
  Apparently you write merge sorts a lot; why and for what? Who writes low level code like that? I have and can but I don’t need it often. Seems you do? And if you do, then sure, it doesn’t fit the case.

mrkeen 3y ago

"The problem is state" is precisely why I do my general programming with functions.

marginalia_nu 3y ago
Isn't the call stack also a form of state?
- mrkeen 3y ago
  It is, but not in the way that imperiative aficionados would use it. There are no imperative programmers, who are interested in FP - but won't switch to it because they'd have to give up their pragmatic getCallStack() and setCallStack() methods.

trashtensor 3y ago

There are some things it's useful for and some things it isn't. Go figure.