Hacker News Reader

Comment by louthy | Hacker News Reader

Not sure why Scott Wlaschin needs to keep renaming existing concepts ('Monads' to 'Railway Oriented Programming' and 'Function Composition' to 'Pipeline Oriented Programming'), but I really don't think it helps shared understanding.

It feels, at worst, like the height of arrogance to assign new terms to existing concepts, as though you've just invented the concept. And, at best, a form of anti-intellectualism - to try and make functional concepts accessible to ex-OO devs. But it feels to me like all it does is muddy the waters.

Not everything needs to be oriented programming.

View on HN

> It feels, at worst, like the height of arrogance to assign new terms to existing concepts, as though you've just invented the concept.

Hilariously I’ve done exactly that for the exact opposite reason.

I have in the past “come up” with a programming paradigm that perfectly satisfied a need and when I went to tune it up for general use I realized it was similar to a concept I was unfamiliar with, or struggled to grasp previously or previously hated working with in the manner it was taught or interfaced.

~”This looks like a monad, maybe I’ll call this a monad, but I’m unsure what precisely is the mathematical proof supporting, or what the limits and boundaries of the concept of a monad are so to avoid someone mocking me saying ‘this is the worst monad implementation, it’s hardly even a monad, it’s like a low effort subset of what a monad is.’ I’ll just name it something else.”

Spatial Computing is another such ploy to differentiate at the surface level.

While I tend to agree with your critique I also appreciate that a different lens can be more accessible or less held back by historical baggage.

A perfect example of this was back when I had my breakthrough with Scheme and Lisp.

I always struggled with fundamental terminology used in this family of languages, particularly lambda. Lambda as a term does carry historical baggage. The term wasn’t picked out of thin air. And casually looking at Lisp and Scheme code, if you don’t know that baggage, lambda is (at least to me) an opaque term.

But I luckily stumbled upon a book “Simply Scheme”. And the first thing they did was redefine a bunch of terms. No more CAR, CDR, CADR. Instead you got things like FIRST, REST. SECOND. Importantly, they redefined LAMBDA to FUNCTION.

Well, Shazam. Ding, ding, ding. This was an “aha” moment for me. Boy did a lot of stuff suddenly fell into place.

So, simplifying the vocabulary can be very helpful for introducing gateway concepts.

> Not sure why Scott Wlaschin needs to keep renaming existing concepts

That's because most programmers ignore you as soon as they hear the m-word (or Haskell), as all that useless in "the real world"(TM).

> at best, a form of anti-intellectualism

This is an uncharitable viewpoint. Bringing FP concepts to more devs is a good thing. I don't see how teaching better ways is any form of anti-intellectualism.

Because (if the assertion is true) he eschews the terminology used by the FP community for his own wording in an attempt to pander to people who aren't (apparently) willing or able to learn the existing terminology. In my FP library [1] (targeting C# programmers) I regularly get people asking "does the library support Railway Oriented Programming?", which they (if they'd have been taught the terminology used by the FP community and not misled by Scott Wlaschin) wouldn't ask after 10 seconds of looking at the readme to see the word 'monad' all over it.

It's treating OO programmers, who are curious about FP, as though they can't handle anything unless it's got "oriented programming" after it. In my mind that's a form of anti-intellectualism.

I really don't buy that it's needed at all. And I feel I'm in a pretty good place to state that, language-ext has ~6K stars on GitHub and the package has been downloaded nearly 13 million times [2]. It shows that devs that use an OO-first language can and are able to learn FP terminology. I never pandered and I get many OO devs coming to the library. Yeah, sometimes they need some guidance, but I've never needed to invented new terminology.

OO engineers are just as smart as FP engineers, they've just worked in different paradigms and need to learn the lingo when switching - the sooner they do it the better able they are to communicate with others in the FP community.

[1] https://github.com/louthy/language-ext

[2] https://www.nuget.org/packages/LanguageExt.Core

People keep rediscovering and rensnming lisp features. I do think he's talking more about composition as a design concept, which is good for people who have only heard shout OO their entire career.

But yeah, it was weird hearing about this "new" idea I've been using for 30 years.

I worry that lazy evaluation will wind up as "filter based programming" next year.

But if it puts it in a form python or c# programmers can readily consume, it's probably okay.

Also nice to see someone doing something with f#.

https://en.wikipedia.org/wiki/Pipeline_(software)

It's not a renaming. Pipelines have been a thing in software for ages. Correlating differing (surface) systems to each other is very useful when it turns out that they're expressing the same "thing" but in different manners.

He's not insisting that people already familiar with functional programming concepts not use the terminology they have historically used, he's using concrete metaphors as a teaching strategy.

For what it's worth, it helped me a great deal in understanding.

Yeah. If the new term conveys the actual meaning better than the old term, then why not invent a new term when dealing with the new people? We didn't always fully understand what X was when we coined X as the term for it; sometimes better names are possible. Why not start to use them?

Or, probably more often, a new term for the same old thing is not better, serves no useful purpose, and just confuses.

Because The lisp community has been doing this for 50 years and has a different name for it.

While true, they have been doing it in their own silo while being smug toward everybody else.

This what I hate most about the field. Everyone trying to look smart by using big words for stupidly obvious concepts. OO is especially guilty for this with all the design patterns.

Every so often on hacker news you get some article like this that tries to introduce a "new concept" that they didn't know has already existed for the longest time or you get some other person writing a blog post about some programming analogy how programming is like "theory building". I just roll my eyes. I really wonder why you only see programmers who like to think of themselves as "highly intelligent" and calling what they're doing "theory building" and why civil engineers or electrical engineers don't supply this endless vault of "analogy blog posts" for HN readers to self pleasure themselves to.

It might be purely marketing-oriented, or perhaps it’s just sales-funnel-oriented, who knows. And if anything unexpected pops up, look no further, the author can immediately come up with a new name for a decades old solution. Same happened to the “hexagonal,” “ports-and-adapters” and so on, which I noted mostly in the .NET community btw, correct me if that's wrong. Like you know every new consulting agency coming up with some new names for old stuff to stand out perhaps?

Monads/Railway seems one step more than Pipeline in concept. The latter is merely connecting outputs to inputs (though I didn't get to the end of the video). Monads/Railway also handle other aspects such as errors (or side effects etc).

[It is very 'branding' and a disservice to not to mention the popular terms.]

I do see them all as the style I think and write in.

Reply on news.ycombinator.com