Comment by austincheney | Hacker News Reader

Comment by austincheney | Hacker News Reader

The biggest challenge with teaching functional programming is that people tend to take the word function or the concept way to seriously. They start mandating restrictions on input/output, what functions should be used for, and all kinds of other unnecessary nonsense. It’s like they need some sort of self imposed guardrails to qualify making better or more common use of functions. Like they need an official invitation before joining the party.

Perhaps some of that stupidity is bound to a developer’s understanding of their language at hand. Some languages are more expensive than others. This is where the sad confused developer mandates that functional programming must be declarative... until you point out the languages Red and Rebol are functional imperative languages. It’s not some shallow wishful opinion. That is how those languages describe themselves and it’s what they look like.

When you take all the stupidity, assumptions, and restrictions away functions are most universally a bag of instructions, as are classes and various other things. Functions are unique from other instruction bags in that they execute. That creates potential for instruction reuse and thus portability.

Different languages impose different restrictions on where or how functions may present. In JavaScript functions are first class citizens which means they can be used anywhere a primitive may be used, which is almost everywhere. Functions can also be nested in that language which just means subdivided layers of portability/reuse. In this case, in a highly imperative way, functional programming can mean programming with a mindset of functions first, as opposed to other means of structure or extension. Again that interpretation of functional programming tends to make people uncomfortable as there are no restrictive guardrails or super specific defining rules.

> They start mandating restrictions on input/output, what functions should be used for

Like what? You've thrown out a ton of generalisations, but nothing here is concrete.

> When you take all the stupidity, assumptions, and restrictions away functions are most universally a bag of instructions, as are classes and various other things.

If you group all things together as a 'bag of instructions' then there's no point in teaching functional concepts or any paradigm's concepts for that matter.

I am reading between the lines here, but I am assuming by 'restrictions' you're referring to functions taking immutable values and returning immutable values. There are sensible reasons for this (along with referential transparency in general) that enable function composition, which is the 'super power' of functional programming. It isn't a requirement, it's just good practice, and so I can understand why FP advocates would promote it (I certainly do).

A class can have those powers too if it is immutable, because ultimately any class is just a set of functions with an implicit 'this' argument, but it's often understood differently. It doesn't seem unreasonable to promote and talk about the differences in approach, especially in languages that allow you to 'cheat'.

Yes, the narrow definition of a functional language is that it has first class functions. Clearly though there's techniques for success within the paradigm.

Again, it's quite hard to latch onto exactly what you're saying here, but I don't think functions as structure is the argument for FP (as such), it's functions that work like mathematical functions, to leverage the centuries of knowledge of mathematical expressions, proofs, etc. Personally, I find my functional code much easier to understand, compose, test, and generally have confidence in. When I compose two functions I don't have to 'go and look inside' to see what it does first, because they're pure and declarative.

The declarative nature of the functions is an artefact of following the good practice of immutable values, referential transparency, and total functions which lead to 'honest' type-signatures, it just happens on its own.

I spent a reasonable part of my career in imperative-land, and honestly I wish I'd found functional programming much earlier. I write fewer bugs and I have more confidence in my code. And yes, it adds constraints that are annoying sometimes, but those constraints ultimately stop the code becoming a cognitively difficult mass of mutation or hidden complexity.

> You've thrown out a ton of generalisations, but nothing here is concrete.

That was intentional. Specifics aren't necessary for making the point. Had I stated the specifics you were looking for I suspect you would have focused only on that, missing the primary point.

> …missing the primary point.

Like GP, I would have to guess what your point actually is.

They start mandating restrictions on input/output, what functions should be used for, and all kinds of other unnecessary nonsense.

A specific example of what you mean would be great. More comments quoting yourself and refusing to explain what you mean would be not great.

I provided several examples in the last paragraph of my original comment.

Whether or not you're right about functional programming, your use of "stupidity" made me think more about what kind of person you are rather than the merits of your argument.

In your other reply you come off as haughty or patronizing.

One does not need high EQ or SQ to be kind.

> That is how those languages describe themselves and it’s what they look like

Neither Red [1] nor Rebol [2] actually does that; the Rebol family of languages tends to describe itself as paradigm-neutral or multi-paradigm, but historically stays close to imperative constructs and lacks mainstream FP support (e.g. Red doesn't have closures, currying, and tail-call optimization). If you really look at a generic Rebol code it will look like an Algol 60 ocean with occasional DSL islands floating around.

Each time I ask what "functional imperative" buzzword actually means no one can give me a straight answer. If it means "building imperative constructs on top of recursive functions via macros" [3], then it describes something totally remote from Rebol. Care to elaborate?

[1]: https://www.red-lang.org/p/about.html

[2]: http://www.rebol.com/docs/core23/rebolcore-1.html

[3]: https://bitwalker.org/posts/2018-03-18-functional-imperative...

Reply on news.ycombinator.com