Comment by msimpson | Hacker News Reader

Comment by msimpson | Hacker News Reader

> Imperative programming is like building assembly lines, which take some initial global state as raw material, apply various specific transformations, mutations to it as this material is pushed through the line, and at the end comes off the end product, the final global state, that represents the result of the computation.

This isn't the best analogy as functional and imperative languages are both often used in a procedural fashion. If I simply replaced "global state" with "immutable arguments", this analogy fits functional programming as well. The fact that the arguments would be copied, however, would be implied.

> Each step needs to change, rotate, massage the workpiece precisely one specific way, so that it is prepared for subsequent steps downstream. Every step downstream depend on every previous step, and their order is therefore fixed and rigid.

This is more about tight coupling than imperative vs. functional paradigms. In general, imperative methods can be just as loosely coupled as functional methods. It basically comes down to what sort of data you're handling.

> Because of these dependencies, an individual computational step has not much use and meaning in itself, but only in the context of all the others, and to understand it, one must understand how the whole line works.

This, again, can be true of functional languages as well. You cannot always guarantee that a method is individually useful given the data at hand.

There is some faulty assumption that functional programming is never imperative. Functional programming has nothing to do with declarative/imperative programming styles. The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together.

If you need to compare functional programming against something contrast it against OOP, which is a different architectural approach.

>Functional programming has nothing to do with declarative/imperative programming styles.

nothing!?

>The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together.

No idea what this means.

> Functional programming has nothing to do with declarative/imperative programming styles.

> The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together.

I think it means a code can be functional but looks imperative. One example is the for-comprehension in Scala:

    val aFuture = future(a)
    val bFuture = future(b)

    (for {
      a <- aFuture
      b <- bFuture
      c <- futureC(a, b)
    } yield c)

This is just a contrived example for working with `Future[T]`, but it can be applied to other monadic types.

For an example library that can be used with a few different styles, have a look at this: http://jsuereth.com/scala-arm/usage.html

>> functional and imperative languages are both often used in a procedural fashion

Exactly.

The most common ELI5 definition of functional programming I get from other developers is that you're piping multiple statements together into a single chain of processing [input(s) > multiple levels of processing > output(s)], without having to explicitly declare variables to hold the temporary inputs and outputs between each sub-statement within the chain. I know just enough to understand that this isn't the "proper definition", but that workflow is true enough that it's what many people associate functional programming with.

The problem with that particular definition is that it tries to make the primary benefit of functional languages seem to be this piping/chaining mechanism. Yet these languages are still written procedurally, executing multiple such pipes in sequence. You still have variables holding the inputs and outputs of each chain, so you can pass them to other unrelated chains. It reduces the overall number of statements and the manual variable/memory management required, but each statement is simply a compressed version of multiple statements merged into one, enforcing "fake immutable" variables for the inputs/outputs within the chain. You don't really have "immutability"; you simply have automatic variable management between sub-statements in a chain.

Now, show me a functional language where the entire program is written as a single piped chain, and I would classify that as its own genre. Literally, the entire program would have to be written top-down as a single block of code that chains every single required input from the top-level, all the way down to a single output, without using a single explicitly declared variable. Only the first line of code would be unindented at the first column, with all other lines having to be indented as part of that primary block. Now that would satisfy me as being "unique" or "different than procedural".

What is the primary metric of a functional language? Is it to write write golf code[1] that folds 10 "procedural statements" into a single 3-line "functional block"? To me that's not "functional programming"; that's just writing less code by chaining multiple operations into smaller blocks, reducing the complexity of having to explicitly declare more global or widely scoped variables.

Random thought association: is perl's well-known Schwartzian transform (@sorted = map { ... } sort { ... } map { ... } @unsorted), applied as a concept to an entire language, what makes a "functional language"? To me, that doesn't seem like enough of a scope change to warrant a different language "type".

[1] https://en.wikipedia.org/wiki/Code_golf

you might want to check this js code I wrote. The whole program is essentially one big function (starting with runApp). Wonder if that is what you were looking for:

https://gist.github.com/MarkusPfundstein/246446e428ab10dbd23...

To meet my new-language-style expectations, you would have to remove every single "const" in your code. You have multiple definitions, all simply executed in sequence based on an initial caller. I was thinking of a single block that took all inputs to result in a single output.

Forgetting my expectations, the code example you linked is practically the antithesis for ES2015/ES6. You've abused the concept of "const". Your example is terrible, using "const" to define things that should have been defined as separate classes, without having to define so many global "const"s.

Even more critically... wtf are you doing with all those "const" definitions? That code is ultimately worse than what I saw in javascript in 1995. Please don't write code that way. :/

To go to the extreme, my ultimate reaction is that the code you linked is straight up unacceptable. You would fail an interview at my company with that code. It screams "I know ES6", while being the worst example of javascript I've ever seen, regardless of the Ecmascript version. You're overcompensating, trying way too hard to prove that you understand the latest spec. There are limits to what "modern javascript" means, and you have gone too far. A dozen global "const" declaration means you know ES6, but don't know how to write proper code.

tldr; Dial back a bit. Upgrading to ES2015/ES6 does not mean transforming all your code to be completely unreadable unless you know the latest spec. Your code should still look like javascript rather than 100% some-new-functional-language.

What are you talking about? How is this code worse than what you might have seen in 1995? How has the concept of const been abused - it is just an assignment keyword, no worse than the var of 1995.

If you attempt to compose functions out of smaller functions, then you need variables to hold on to those small functions. What's wrong with that? And why would you need "separate classes" for those smaller functions? What problem would "smaller classes" solve?

I don't understand your criticism. You asked for a functional program , I showed you one, and you start a rant against it because it looks functional?! It just happens to be in js but it could also be in common lisp or clojure or whatever..

The crucial thing to understand is, that those consts are just assignments for global modules that I use. They are NOT variables. But if you want to go to the full extreme and remove every single const: EASY! Just add all the modules to the environment of the most external Reader monad and inject them into the function chain. This would get rid of 99% of global consts that are not functions. I leave that as an exercise to you.

The rest of the consts are just function assignments. Instead of const f = x => ... I could also write function f(x) { } .. but honestly, I prefer the former. It is more elegant in my opinion ... So in order to get rid of them, just rewrite it. This is trivial.

Finally, you would want to get rid of the two local consts within the two functions putPublicationToElastic and createUploadDocument: Straightforward, they are just there for cosmetic. Again, they are NOT variables, they are just names to make some following lines a bit shorter. Again, exercise to you to remove them.

So if we do all the three steps above, the only const we would have left would be the config variable. The rest is one big function, composed in order to achieve a goal. Mind that calling the function will not produce any output (You'd have to fork it), so the function is even 100% pure...

Honest question to you: Why would I need a class here? I really don't see anything in that code that would profit from being put into a class. It's just a bunch of functions composed together and wrapped into a Reader monad. I can rename runApp to uploadSQLDocumentsToElastic and export it and have a perfectly fine, encapsulated logic. I don't think you could do better with a class. But if, please show me. I'm eager to learn!

P.S. Please tell me the name of your company. Another one I would NEVER ever want to work for ;-)

P.P.S. Sometimes people write code as an intellectual exercise. In order to try out some new paradigm, or coding style. I'd advise you to consider that next time before attacking their efforts.

developer2, please do reveal the name of this company you work at, we're all very curious to know the name of this wonderful workplace.

> piping multiple statements together into a single chain of processing[] without having to explicitly declare variables to hold the temporary inputs

This is known as point-free style. I think point-free style implies functional programming (at least locally; i.e., a point-free function will by definition be functional, although it can call imperative functions) but functional certainly does not imply point-free.

Please tell me you know of a functional language that does not incorporate "point-free style", as you put it. I would love to look at such a language as a way to redefine how I view functional languages in general. No sarcasm involved, I am genuinely interested.

Ah, well... point-free style is going to be more-or-less possible in any decent functional language; it (or rather, functional composition) is one of those things like "while loops" in imperative languages which, if absent, would cause you to consider a functional language kind of rubbish. Functional programming would be far too verbose to be comprehensible otherwise.

That said, Scheme is probably a good example. Lisps in general are a funny case for functional programming: historically they were described as "functional" but the word had a different meaning we would now call "procedural"; I think Lisp may have predated Algol so the concept of having functions at all was fairly notable. However, Lisps generally support functional programming and Scheme has embraced it more fully than the others. Note, for example, that Scheme doesn't actually have loops as a fundamental concept in the language; it emulates them with obligatory TCO and convenience macros.

Reply on news.ycombinator.com