Ask Slashdot: Do You Like Functional Programming? (slashdot.org)

An anonymous reader writes: Functional programming seems to be all the rage these days. Efforts are being made to highlight its use in Java, JavaScript, C# and elsewhere. Lots of claims are being made about it's virtues that seem relatively easy to prove or disprove such as "Its use will reduce your debugging time." Or "It will clarify your code." My co-workers are resorting to arm-wrestling matches over this style choice. Half of my co-workers have drunk the Kool-Aid and are evangelizing its benefits. The other half are unconvinced of its virtues over Object Oriented Design patterns, etc.

What is your take on functional programming and related technologies (i.e. lambdas and streams)? Is it our salvation? Is it merely another useful design pattern? Or is it a technological dead-end?
Python creator Guido van Rossum has said most programmers aren't used to functional languages, and when he answered Slashdot reader questions in 2013 said the only functional language he knew much about was Haskell, and "any language less popular than Haskell surely has very little practical value." He even added "I also don't think that the current crop of functional languages is ready for mainstream."

Leave your own opinions in the comments. Do you like functional programming?

Comments

It has its uses

[RightwingNutjob]

but I'm skeptical about functional as the hammer for every nail. Generics and lambda expressions in C++ can make some niche problems disappear entirely by making the compiler do all the work for you, Scheme and Lisp and the like are useful for some very narrow and very academic use cases. As the go-to tool in the tool box? Not so much.

Re:It has its uses

[Anonymous Coward]

Explain to me, what problems do lambdas solve in C++?

Re:It has its uses

[beelsebob]

There's two big things that have come out of the recent move towards more functional programming which are really important.

1) People are understanding that reducing the amount of state that any particular bit of code carries reduces the complexity of working with it. Less state means more testability, more easy reasoning about the code, more clarity, more easy debugging, and fewer edge cases to consider. That's not to say that you should never has state, as pure functional programming would have you believe, but reducing state dependance pretty much helps make your code better universally.

2) People are realising that inheritance is not the be-all and end-all of modelling code that the OOP world would have you believe. They're realising that inheritance is what screws up type systems, and makes them hard to work with. They're realising that deep inheritance hierarchies often lead to complex code which is tricky to understand exactly what code is going to execute when, and where you're going to jump to when you're reading it. Again - this isn't to say you should never use inheritance, but people are realising that composition can work equally well, or better, and that using it over inheritance has some substantial benefits.

As to the bandwagon of "write javascript, it's a functional language, that makes it brilliant". Fuck off... That's just yet another of the latest fads towards pascal on trains; nodeHaskell; and reactMonkey. I'll happily sit here continuing to write ancient languages, but trying to apply some of the concepts from FP to make my code simpler and more readable.

Re:It has its uses

[beelsebob]

The same problem they solve in any other language - they allow you to easily express a function that captures values from a dynamic scope.

Re: It has its uses

[Anonymous Coward]

Same as any other language that supports lambda expressions, one nice one is callbacks, no need to pass a context pointer pointer because the lambda expression is in the context already

Re:It has its uses

[thogard]

I see lambdas as the opposite end of the pendulum swing from the goto statement.

They have their place but they both lead to lots of confusion with poor coders who are trying to maintain very old code.

Re:It has its uses

[Goondra]

Exactly! What is trying to be solved? With garbage collection debugging is greatly reduced. With strong typing many errors are caught at compile time. LISP is nice but I never need it.

Re:It has its uses

[plopez]

*2) People are realising that inheritance is not the be-all and end-all of modelling code that the OOP world would have you believe*

In the GoF book they flat out state that they prefer aggregation to inheritance. There is a reason you cannot do diamond inheritance in Java. Am I the only one who got the memo?

Re:It has its uses

[Anonymous Coward]

Definitely not the only one. Composition has always been preferred.
I think it's that the idea of inheritance is so compelling - and that languages don't make reuse via composition easy. (Or at least didn't, until things like mixins and traits started becoming more popular).

Re:It has its uses

[Dutch Gun]

Few "in the OOP world" (whatever that means) promotes inheritance as the end-all-be-all these days. I think that went out of style fifteen or twenty years ago. The notion of eschewing inheritance whenever possible has its own Wikipedia entry, and was described in detail in the famous "Design Patterns" gang of four book.

That being said, there's a time when reality can intrude on "theoretically" clean designs or programming paradigms. Functional programming and unit testing are things you don't see widely used in the videogame development world, at least that I've seen. Not all paradigms and patterns apply to all types of problems. Ultimately, I think that's the most valuable thing I've learned over time. Use the tools and techniques most appropriate to the problem at hand you're trying to solve. Religious wars over programming techniques and methodologies are for pedantic fools.

Re:It has its uses

[jandrese]

There is certainly value in reducing the amount of state you are managing, but too often it seem like Functional programmers are willing to declare it gone when they've just swept it under the rug. Sure you don't have a variable now, but instead you have the logic tied up in your stack. This is especially true when the language does pattern matches on the parameters to determine which function to call. In the end you have to keep track of that iterator somehow, and I tend to think something like a for loop tends to be clearer than looking through the function headers to figure out how the loop is initialized and when it terminates.

Re:It has its uses

[Anonymous Coward]

As far as I've seen, it's primary use is to allow people to write the least efficient and most memory hungry code possible to handle tasks better approached with OO . It's a shame that more people don't understand what's going on under the hood when they use FP.

Re: It has its uses

[Anonymous Coward]

Callbacks are often just sneaky global variables.

Re:It has its uses

[dcollins]

"People are realising that inheritance is not the be-all and end-all... They're realising that deep inheritance hierarchies often lead to complex code which is tricky to understand exactly what code is going to execute when..."

I'm pretty sure it was 1990 when one of my professors said, "We used to worry about spaghetti GOTOs; now we have to worry about spaghetti inheritance".

Re:It has its uses

[jbolden]

I'm not sure what you mean having to keep track of an iterator. Can you provide an example?

Re: It has its uses

[Dog-Cow]

No, they aren't. Anonymous Cowards seem to often be shitty idiots.

Re:It has its uses

[Anonymous Coward]

Scheme and Lisp and the like are useful for some very narrow and very academic use cases

Scheme and Lisp aren't functional programming languages, although they support programming in a functional style.

Re:It has its uses

[dgatwood]

Functional programming and unit testing are things you don't see widely used in the videogame development world, at least that I've seen.

I'd expect functional programming to be used quite a bit in that space, but only for very small chunks of performance-critical code, such as massively parallel bits down in the guts of raytracing engines. Now whether they actually use functional programming languages or not is another question.

Unit testing is something you don't see widely used in software development, period, unfortunately. But the industry is getting better. Slowly. Very slowly. Very, very slowly. Glacially, really.

Re:It has its uses

[Z00L00K]

Strong typing with static declarations may seem to be cumbersome to many but the good thing with the strong static typing is that you get slapped already when compiling and not late during execution when an obscure obnoxious condition is fulfilled. Of course unit testing should capture even obscure obnoxious conditions but since not every test is updated when the code is updated then it's easy to miss.

However sometimes lambdas are also useful - but they shall be used with care. There's no golden solution that can capture everything, instead different parts of an application shall be implemented in different ways to get the most effective solution. It will of course mean that developers have to know more than one programming language and paradigm.

Re:It has its uses

[Anonymous Coward]

Lambdas are function literals, in the same way that 2 is an int literal. For some situations, it's less work and clearer to put a function directly where it's needed, rather than creating a new named function elsewhere. Example, to check if all elements of a std::vector<int> are positive:

std::vector<int> foo = { /* stuff */ };
bool all_positive = std::all_of(foo.begin(), foo.end(), [](int x){ return x > 0; });

In the same way that 0 does not need to be put into a variable, the test function is better placed inline as a lambda, as it is obvious what it does. It's use is pretty niche, as anything more complicated probably deserves to be written as a standalone function, but it serves a purpose.

Re:It has its uses

[Z00L00K]

And spaghetti inheritance is especially prevalent in some solutions where there's an unnecessary amount of interfaces declared - so that everything is just declared and accessed through badly documented interface items so you can't figure out how to create new objects when you need them.

Don't get me wrong - interface declarations are good too, but they have to be documented so others can understand how the objects they carry are constructed. The overall system design strategy is also something that has to be well thought out. Too much work put into abstracting away the physical world can create a system that's hard to maintain too. Layers upon layers hiding how stuff really works means that nobody will be able to understand it after a while.

Re:It has its uses

[RightwingNutjob]

It ain't f'ing unnecessary. If it's a spaghetti or gotos it'll be a spaghetti of inheritances or a spaghetti of lambda's. At some point, the complexity of the task the program is executing requires complex code. Goto's can be done so that they're easy to understand. So can inheritance. So can lambda's. But you've got to be aware of the fact that some things are just plain hard to understand because they're hard, no matter how good of a communicator the programmer is.

Re:It has its uses

[RightwingNutjob]

I could say the same thing about OO. And frequently do. Touche, AC.

Re: It has its uses

[Anonymous Coward]

That's great in theory, but if you've ever worked with React or Angular you wouldn't be so sure.

Re: It has its uses

[Anonymous Coward]

Lambdas are simple and nice. It's just overhyped and people get confused because hype generates fanboi noise that hide the actual facts.

One good use of Lambdas is to implement the GOF strategy pattern. You can do it without Lambdas, but it's really verbose and hard to read in Java due to the amount of interface and one time use classes and objects simply to define a processing strategy. Lambdas make it much more concise and simple.

Its important for frameworks to allow others to specify processing "strategies". Some frameworks like Spring use such techniques very extensively. When you use a framework you want others to write less code and reduce boilerplate, so people who write frameworks find Lambdas awesome. When I write frameworks and engines I get irritated by the sheer amount of boiler plate to do strategy pattern and comment the code so that people can understand my code. Good code should be self readable and strategy pattern on Java isn't readable to less savvy programmers.

For users of the frameworks it's just a few lines less code which they "cut and paste" anyway and many don't see why they have to spend time learning Lambdas so they can save a few lines here and there.

I think Lambdas are a good feature to make coding in Java more elegant. Coding elegance has a long pay off and inflict short term pain to change which is why people who don't understand hate it. They hate it even more at the level of hype something with so little immediate value gets forced fed to them.

I woul agree that if you have less than 5 years left in your coding career, Lambdas are a waste of time.... but hey think of the children!

Re: It has its uses

[thsths]

The beauty of Lambda expression is that it moves features that are classically considered key language elements into a library: if-then statements, loops, etc can all be library functions. And it makes typical library function like optimization algorithms or other analysis methods much easier to use. In numerical computing, Lambda expressions certainly have their place.

Of course in GUI development, Lambda can also be very convenient. But you need to make sure that you keep concerns together, and that can be a challenge.

Coming back to the original question of Java: Java was a good language, but a poor implementation. What really kept it back was the license: Java (like Flash) was always designed as a plug-in, running side by side with the browser, not an integrated part of the browser. The Javascript engine is much more powerful in terms of interaction with the browser (DOM and stuff), and that is the reason it succeeded.

Re:It has its uses

[arglebargle_xiv]

I would have expected that everyone wants functional programming. Well, except for people being specifically paid to fix up dysfunctional programming, but I'll take functional code any day of the week.

Re:It has its uses

[Anonymous Coward]

1) People are understanding that reducing the amount of state that any particular bit of code carries reduces the complexity of working with it.

That's just false, the opposite is the case. Reducing the amount of state increases complexity, which you would know if e.g. you'd had ever written a library for immutable trees and graphs and compared it to mutable standard representations.

2) People are realising that inheritance is not the be-all and end-all of modelling code that the OOP world would have you believe. They're realising that inheritance is what screws up type systems

That makes no sense either. If a language's type system is correct, no amount of inheritance can 'screw' it up. There are antipatterns in OOP just like in any other programming paradigm. OOP is often not needed or not natural for the data representations, and in some languages it also leads to too much boilerplate, but these things have nothing to do with functional programming.

Re:It has its uses

[Anonymous Coward]

Everyone wants functional programming?

"Clean code" is not the goal. It is a means to an end, a tool. The goal is clean execution!
So, can you have a program with no surprises, with this functional programming?

Write a game or a sound server. No glitchy little pauses because garbage collection happened? You can trust your realtime goals to be met because some three-line construct are never going off on a tangent for 5 whole seconds?

Re: It has its uses

[MichaelSmith]

But with two or three promise implementations, and now you have multiple versions of each control structure.

Re:It has its uses

[Anonymous Coward]

Strong typing is good for long lifecycles and many hands-on people, thus ensuring quality at earliest opportunity. However, for experimentation, prototyping and rapid development, it can hinder some type of creative work that may be better without it. For 90% of the time though, a good strongly typed language is a better fit, but it is good for a developer to vary and have more diverse experiences as well.

Sometimes it is good to use different paradigms, however, they too come with a cost. Just have a look at the typical Scala-program. Usually there are lots of local solution not easily understood by external developers and testers. The real solution though, may not be to standardize everything, though that may also help but at cost of creativity. A better, but also something that needs lots of commitment, is to never build something that cannot be replaced. Smaller services, better system boundaries and being able to replace entire systems over a week, means lack of huge monoliths and complexity that cannot be serviced properly or even replaced. The overall cost for this is more design and development time, more testing, more time for logging, etc., and you cannot do management by the whip and strict adherence to time/cost-estimates anymore, which never worked anyway.

Re: It has its uses

[countach]

Nobody's ever made a type system that doesn't need ways to get around it in a non trivial program. Admittedly the type system ends up still being useful.. up until it isn't.

Re:It has its uses

[DrXym]

They're a relatively concise way of creating a reusable anonymous function and binding values to them and having the code inline and next to the functionality it's relevant to. This isn't a new concept since C has always allowed function pointers to be passed around (e.g. for qsort) and boost has had function bindings well before C++11. But now they're part of the language and therefore more useful.

But like all things they should be used with due consideration. C++ doesn't help itself by having horrible syntax for iterating collections.

Re:It has its uses

[K. S. Kyosuke]

2) People are realising that inheritance is not the be-all and end-all of modelling code that the OOP world would have you believe. They're realising that inheritance is what screws up type systems, and makes them hard to work with. They're realising that deep inheritance hierarchies often lead to complex code which is tricky to understand exactly what code is going to execute when, and where you're going to jump to when you're reading it. Again - this isn't to say you should never use inheritance, but people are realising that composition can work equally well, or better, and that using it over inheritance has some substantial benefits.

I'm not really sure what this has has to do with functional programming specifically, as operator dispatch strategies seem to be a completely orthogonal issue from mutable state reduction (or elimination). Just because contemporary "purer" functional programming languages don't support the same kinds of constructs that, say, CLOS does, it not seem to follow that a functional language has to have only rudimentary facilities for code arrangement.

However, as Sussman has noted in the wizard book, more complicated ontologies do appear to require the kind of automated reasoning and mechanized common sense which we haven't sufficiently tackled (yet, at least), so in languages with stricter requirements for ahead-of-type checking, more complicated constructs can indeed be mutually exclusive with said checking.

(Some special cases do come to mind where a more specialized operation can be more computationally efficient but is semantically equivalent, therefore there is no violation of type checks even if you don't know what will get executed. Imagine operations on special types of matrices taking shortcuts delivering the same result as a more generic operator, only faster. These are often predicate classes, though, so the type system and the language would have to be significantly extended in many cases anyway.)

Re:It has its uses

[angel'o'sphere]

Are you really that dumb?
When you are using Lambdas in C++: you are doing functional programming. (*facepalm*)

Re:It has its uses

[silentcoder]

The value of a lambda is greatly reduced in a language like python (though it supports them) where functions are first-class objects - when you can store functions and pass them around as variables the benefits of named functions hugely improve and much of what a lambda does can be done more cleanly by using data structures.

So, for example, by storing functions as values in a dict you can build complex structures of execution without using any conditional codes . A long cluster of nested if-statements can be reduced to a single dictionary accessor. This is one of the standard ways to the common python-challenge of implementing Conway's game of life without using any if statements.

This, in fact, was what I found most annoying working in Ruby as opposed to python - the fact that functions are not first-class objects force you to use things like lambdas even where more elegant solutions may otherwise have been available.

Re:It has its uses

[silentcoder]

I would argue that OO remains the best paradigm we have for constructing data presentation - especially when the data represents something that exists in the real world (or a reasonable facsimile as in GUI programming or video-game dev). Functional programming on the other hand - is often the best paradigm we have for data processing, especially big data processing. Use them each in their own domains and break these rules-of-thumb whenever it makes sense to.

Re:It has its uses

[dcollins117]

They have their place but they both lead to lots of confusion with poor coders who are trying to maintain very old code.

If you're using poor coders to maintain very old code then perhaps the choice of programming style is not your biggest problem.

Re:It has its uses

[TheRaven64]

In C++14 in particular, lambdas with auto parameters dramatically reduce copy-and-paste coding. If you have a couple of lines of code that's repeated, it isn't worth factoring it out into a separate templated function (in particular, you'll often need to pass so many arguments that you'll end up with more code at the end), but pulling it into a lambda that binds everything by reference and has auto-typed parameters can reduce the amount of source code, while generating the same object code (the lambda will be inlined at all call sites).

Re: It has its uses

[angel'o'sphere]

Any examples for that?

I never had the need to circumwent the type system, and I used plenty of languages, where you simply can't circumvent it.

Re:It has its uses

[TheRaven64]

This needs moderating up. Talk to an Ocaml programmer and a Haskell programmer about what makes a functional language and you'll see very different opinions and these two are languages that were actually designed as functional languages: the bits that end up in other languages are a tiny subset.

Coming from the Haskell side, I see functional programming as programming without side effects and with monads. You can implement monadic constructs in other languages, but it rarely makes code cleaner. Just having higher-order functions doesn't make a language a functional language any more than having structs makes C an object-oriented language.

If the question is 'do you think using higher-order functions simplifies the expression of some algorithms' then the answer is obviously 'yes': programmers have a lot of tools to choose from and most of them are useful at least some of the time.

Re:It has its uses

[angel'o'sphere]

The STL had/has an apply() function (perhaps called slightly different, e.g. for_each() ) since its inception.
Obviously it had no real lambdas, and relied on overwritten "operator()" methods. You called that "functor objects".
So boost was by far not the first one offering that.

Re:It has its uses

[Big Hairy Ian]

Religious wars over programming techniques and methodologies are for pedantic fools.

Us Pastafarians would disagree! We prefer to write Spaghetti Code :D

Re:It has its uses

[Moridineas]

I remember back in school writing a (very rudimentary) MIPS emulator for a class assignment. Since most of the students had never used C before school (and were, in any case, more used to C++ references than pointers), apparently I was the only person in ~10 years that implemented the emulator using an array of function pointers (indexed on op codes). I thought it was a pretty cool innovation, then I read about jump tables.

Still cool :-)

Re:It has its uses

[silentcoder]

That's actually a very similar technique - and its a perfectly valid one, it's also a very FAST one since accessing an array element (or for that matter a dictionary value by key) is an atomic operation that only requires a single CPU instruction. Python making functions first-class object is, effectively, a very elegant way of bringing the capabilities of C's function-pointers into a high-level object oriented language, and a bit easier to work with since you're not (visibly) dealing with pointers since you can address the function by name.

def test( str ):
    print("Hello %s" %str)

test('John') #Calls the function - prints 'Hello John'
mydict = {'X': test} # Address the function, stores it as a value in the dictionary, does not run it
mydict[X]('Mike') #Prints 'Hello Mike'

It is also possible to use a function as the KEY in a dictionary - though I've never seen anybody actually do that and I would be hard pressed to come up with any use-case for doing so.

Re:It has its uses

[Wootery]

very small chunks of performance-critical code, such as massively parallel bits down in the guts of raytracing engines. Now whether they actually use functional programming languages or not is another question.

Looking at OpenCL/Vulkan/Direct3D/OpenMP/etc, the answer seems to be a clear no. The lots-of-'threads'-running-sequential-C-code model seems to work pretty well though, and programmers are essentially forced to think about state. You don't stand much of a chance messing about with globals in those environments (but I guess you could try it).

Re:It has its uses

[Anonymous Coward]

There's two big things that have come out of the recent move towards more functional programming which are really important.

1) People are understanding that reducing the amount of state that any particular bit of code carries reduces the complexity of working with it. Less state means more testability, more easy reasoning about the code, more clarity, more easy debugging, and fewer edge cases to consider. That's not to say that you should never has state, as pure functional programming would have you believe, but reducing state dependance pretty much helps make your code better universally.

2) People are realising that inheritance is not the be-all and end-all of modelling code that the OOP world would have you believe. They're realising that inheritance is what screws up type systems, and makes them hard to work with. They're realising that deep inheritance hierarchies often lead to complex code which is tricky to understand exactly what code is going to execute when, and where you're going to jump to when you're reading it. Again - this isn't to say you should never use inheritance, but people are realising that composition can work equally well, or better, and that using it over inheritance has some substantial benefits.

As to the bandwagon of "write javascript, it's a functional language, that makes it brilliant". Fuck off... That's just yet another of the latest fads towards pascal on trains; nodeHaskell; and reactMonkey. I'll happily sit here continuing to write ancient languages, but trying to apply some of the concepts from FP to make my code simpler and more readable.

Can you tell more about the "less state" stuff? I'm a fairly recent CompSci grad and they never touched on functional programming and I'd like to know about this apparent difference. If it's just the proper keywords to search for in Google, it'd be fine.

Re:It has its uses

[beelsebob]

Games dev actually avoids OOP like the plague these days. Anything that runs on the GPU is purely functional, much of what runs on the CPU is purely functional, and data oriented rather than object oriented. Games devs care more about whether you can keep everything in cache, and crunch through it, rather than whether its modeled nicely.

Re:It has its uses

[beelsebob]

You're right - it is orthogonal. But it's something that comes with the territory. Almost every single functional programming language out there uses some variant on ADTs to model data, not inheritance hierarchies. People start realizing that there are other (better) ways to model concepts when they're temporarily forced to think that way.

Re: It has its uses

[Anonymous Coward]

This was the subject of Brian W. Kernighan's paper: Why Pascal is Not My Favorite Programming Language, where he analyzes converting software tools to Pascal. His conclusion summarized the problems I was having in being forced to use ADA for DOD. Of course in the DOD's case, they deliberately closed the language, and that's why C passed it by.

      9) There is no escape.

This last point is perhaps the most important. The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to replace the defective run-time environment with a sensible one, unless one controls the compiler that defines the ``standard procedures.'' The language is closed.

People who use Pascal for serious programming fall into a fatal trap.

Because the language is so impotent, it must be extended. But each group extends Pascal in its own direction, to make it look like whatever language they really want. Extensions for separate compilation, Fortran-like COMMON, string data types, internal static variables, initialization, octal numbers, bit operators, etc., all add to the utility of the language for one group, but destroy its portability to others.

I feel that it is a mistake to use Pascal for anything much beyond its original target. In its pure form, Pascal is a toy language, suitable for teaching but not for real programming.

http://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html

Re:It has its uses

[Anonymous Coward]

I see lambdas as the opposite end of the pendulum swing from the goto statement.

They have their place but they both lead to lots of confusion with poor coders who are trying to maintain very old code.

If you want confusion, try Regex!

Re: It has its uses

[Anonymous Coward]

My guess is that you'll only be able to pry (void *) away from countach's cold, dead fingers.

Re:It has its uses

[silentcoder]

I could see that in performance heavy FPS's and such - but the idea of trying to code an RPG without objects seems mindbogglingly painful.

Re:It has its uses

[luis_a_espinal]

I see lambdas as the opposite end of the pendulum swing from the goto statement.

They have their place but they both lead to lots of confusion with poor coders who are trying to maintain very old code.

That's not a function of lambdas, or gotos for that matter. I've seen elegant, clear solutions using gotos that made code simpler to read. Same with lambdas. As a matter of fact, same with everything in a programming tool set.

It's not what you use to write code, but how you write code, how you compose it. That's what makes code maintainable, not the lack or usage of some feature.

Re:It has its uses

[jandrese]

Sure, lets look at two examples:
Iterative program:

variable loop_counter;
for ( loop_counter = 0; loop_counter < 10; loop_counter = loop_counter + 1 )
{
do_stuff()
}

Functional program:

function do_stuff_loop(x, x)
{ }
function do_stuff_loop(x, y)
{
do_stuff()
do_stuff_loop(x + 1, y)
}
do_stuff_loop(0, 10)

In the iterative example you have a variable which changes, causing pain to functional programmers who gaze upon it. In the second your iterator is still there, but it's hidden in the stack instead of being explicitly declared.

Re: It has its uses

[Lije Baley]

Heresy! How dare you take the focus away from the almighty Tool? You are practically taking food right out of the mouths of authors and trainers! And don't forget the psychic damage to the gurus! Why won't you think of the gurus??

Re:It has its uses

[DarkOx]

You can do this just fine in Ruby, using the method method, ie to get foo you'd do method :foo. You could do something like

myhash[f:oo] = method :foo
myhash[:foo].call arg1

so you can build the same structure you are describing in Ruby without much difficultly, although admittedly this might be one of the few places where Python might actually be syntactically superior.

Re: It has its uses

[silentcoder]

Thats not a first class object. Having an approximate work-around for one use-case is good - but not comparable. In python I can all methods on methods, and access their attributes, in clean and elegant ways with no hackishness.

Re:It has its uses

[Anonymous Coward]

>They have their place but they both lead to lots of confusion with poor coders who are trying to maintain very old code.

If you wanted quality code you wouldn't have hired H1Bs. Deal with it.

Re: It has its uses

[lgw]

I never had the need to circumwent the type system, and I used plenty of languages, where you simply can't circumvent it.

Not sure what language you're using, but most have either void* or Object. The more refined version is "downcasting" a base type to a derived type. Any time you set the type of an object dynamically at runtime, you're bypassing strong type checking. And don't get me started on reflection.

Re:It has its uses

[Anonymous Coward]

Maybe I'm lucky, I've worked for two large companies for over twenty years and we were doing unit and integration testing back in 1992.

Re:It has its uses

[lgw]

Explain to me, what problems do lambdas solve in C++?

Lambda make for sane "list comprehension", that is, transforming a list in some simple way, or taking a simple action for each item in a list (or any other collection).

C++ was years behind pretty much every other mainstream language but C in list operations. You should never need to code a for loop to do something simple to or with each item in a list.

Also, more generally, lambdas are useful everywhere for defining function that are short, and only called from one place. As a sibling post points out, they are "function literals", and with other sorts of literals, code is more clear if your literals are simply in-line in your code, not defined elsewhere (when the value is only used once).

Returning a lambda as the result of a function is where is gets dubious: usually at that point, it's going to be more clear and easier to debug to make a named class/interface that expresses the captured functionality, with a named method. More typing, but self-documenting. Any time a lambda is used from where you can't see the definition, it's a warning sign the code may be confusing.

Re: It has its uses

[angel'o'sphere]

In languages like Java or C# type safety during a downcast is not compile time enforced ... however it is still type safe (you get runtime exceptions).
It should be avoided of course, but there are situations where you can't. (Have non at hand at the moment, as I wrote my last down cast ages ago and don't remember why it was needed)

Regarding reflection: using reflection is still type safe, so what are you referreing. too?

Re:It has its uses

[Anonymous Coward]

Preferably pirated spaghetti code

Re:It has its uses

[swillden]

There's two big things that have come out of the recent move towards more functional programming which are really important.

You missed the biggest one: Eliminating mutable state makes code inherently safe for concurrency. Not an inconsiderable issue, since the direction of hardware progress seems to be towards ever more cores.

Of course, pure functional programming eliminates mutable state by creating massive numbers of copies. Actual functional programming languages (e.g. Haskell) are quite clever about optimizing out nearly all of those copies, but the result of that is that the generated code has mutable state. Still, this may very well be the best way forward... automatic parallelization of imperative code is very hard. It may well be that it's easier to automatically decide how to split work up by analyzing data copying, and then apply copy optimization to each thread.

Re:It has its uses

[hey!]

At some point, the complexity of the task the program is executing requires complex code.

This is a more profound statement than it appears at first. I'd say that the minimal complexity of the code necessary to accomplish a task defines the complexity of the task itself.

As for GOTO the issue isn't GOTO per se, but implicitly building other control structures like loops using GOTO as a primitive -- a legacy of the very earliest machine languages in which you implemented algorithms using a very limited instruction set. The flexibility of GOTO makes it a good choice if you have only a few control structures to work with; but that same flexibility imposes the cognitive load of figuring out what the original programmer (possibly yourself) meant.

But even if more structured (i.e., limited) control structures available, there are problems where GOTO is the natural way to express them. State machines for example. I've seen them implemented with long if-then-elseif chains or case conditional constructs, but that's just thoughtless programming that obscures what is going on. A state machine is much more clearly implemented with GOTOs, although tail recursion can be a reasonable alternative.

Re:It has its uses

[Anonymous Coward]

Scheme, maybe. Common Lisp isn't purely functional by any means, though one can write functional code with it. I do many languages at work, but pretyt much only Common Lisp at home. Sometimes, even functionally.

Re:It has its uses

[jbolden]

That's just bad functional code. What you are describing (though the notation is hard to follow) sounds like a fold. https://wiki.haskell.org/Fold
That has final and initial values.

The other thing is you don't want to be "doing stuff" and iterating. You want to be computing stuff and then "doing stuff" on the entire set of output. The system as it pulls output will drive the iteration on the computation. What you have above is sequenced. Getting rid of explicit sequencing is part of writing functional code.

Re:It has its uses

[Anonymous Coward]

The functional side should be: (for-each do_stuff (iota 10)). Please don't misrepresent it.

Re:It has its uses

[Anonymous Coward]

Sometimes the poor coder is an excellent coder who needs nudging and mentorship to bring that coder out; but we don't train our devs anymore.

I came from an old-school shop. I was not expected to know everything as soon as I sat down. I was, in the truest sense of the world, extremely *junior*. And the Sr. Developer, who had been coding for longer than I'd been alive, sat down for my monthly status updates, and the one thing he always impressed upon me was that I wasn't writing code for myself; I was writing it for the next developer. Thus, the avoidance of "tricks" and "cleverness", which only serve as a form of mental masturbation. If you ever write a piece of code and feel particularly clever? Rewrite it because the next dev won't have the same context you had when you had your "a-ha!" moment. Unless you absolutely have a reason to have it (and as a jr. developer, that will never be the case. and as a Sr. Developer, you know better than to do so).

Re: It has its uses

[spongman]

Object is still strong. It's just not static.

Re:It has its uses

[Anonymous Coward]

Am I the only one who got the memo?

Looking at the code of other people, yes. Or, perhaps, even if they had recieved the memo, they had not read it.

Re: It has its uses

[Anonymous Coward]

Lol. Like the backend deved with java, .net, node. Hehe. That's called incompetence.

Re: It has its uses

[Anonymous Coward]

I'm interpreting 'easier and hard to work with' as lazy and not very smart.

Easier absolutely does. It mean better. It rarely does. Easy means cheap short cuts and no scalability. OOP projects last multiple generations. I've seen these script kiddie projects - barely working, buggy as hell, and thrown away for a rewrite each version.

Its great for your 'easy' projects. But you see, my dear script kiddies, real programmming projects will always be in foundational languages.

Sure it's more difficult if you don't practice. Sure it may take longer to setup a solid multi-generational framework. There are solid languages built and used by very smart people.

The issues with these OOP languages today are script kiddies don't need to be as smart as an OOP developer. This is a fact. And when script kiddies go from lisp or python to OOP thier little brains get headaches.

Go look at the job boards. More complexity pays more. The value has been decided. If you are smart enough, you'll always find your way to a complex language. If you are average, you'll be a script kiddie.

We still need them. To step on over mudpuddles and to the low value stupid shit.

Higher math Analytics is different to be fair. Its the exception.

Re:It has its uses

[Opyros]

I'd say that the minimal complexity of the code necessary to accomplish a task defines the complexity of the task itself.

Indeed.

Re: It has its uses

[Anonymous Coward]

No. When its compiled, it is compiled into methods. You don't even understand enough to know what happens.

See, there is the writing the little characters on the screen and the compiling and then execution.

Probably you never get to the execution part before with all the compile errors so you didn't know that lamb das are compiles into methods.

Its ok. Hello world isn't usually a lambda.

Re:It has its uses

[jellomizer]

The computer scientist in me loves functional languages, the MBA in me doesn't.
Functional languages makes very tight code. Which for the programmer and the computer scientist is great. Less coding, a solid routine with little effort.
However it makes it difficult to maintain a program over a life time. As it is always near one feature away from a full rewrite, vs just slapping some if conditional in the code which while inelegant, is easy to code, easy to see the change, and easier to test.
 

Re: It has its uses

[jbolden]

The classic example is church number subtraction. (I should mention Haskell solves this now via. rank 2 types, but very few languages have this).

So just to define terms church numbers take two arbitrary values: think f = (+1), z = 0 for the trivial case
zero f z = z
one f z = (f z)
two f z = f ( f z)
three f z = f (f (f z))
etc..

given two church numbers
minus n m should be the church number for their difference
ie, for all f, z
(minus three one) f z = two f z

generally this is done by using the predecessor function
pred n f z = snd $ n f' z' where
    f' (a,b) = (succ a, a)
    z' = (zero, zero)

and then
(minus m n) f z = (n pred m) f z

minus is not expressible as a rank-1 type in any language. Since most languages don't have rank-2 types...

Re:It has its uses

[beelsebob]

You do realise that "objects" are not the only way to encapsulate data, right?

The thing that makes OOP OOP is inheritence, not the fact that you have a structure that represents some object - all programming languages have encapsulated data, whether they're OO or not.

Re:It has its uses

[beelsebob]

The one core concept that makes functional programming different from anything else is "referential transparency". Referential Transparency is the property that you can substitute a call to a function with a given set of arguments with the result of that function in the program, and the behavior won't change at all.

To put it another way - when you call a function, its result has to be determined based *only* on the arguments you pass in, not any external state that might be floating about. It's not allowed to go and fetch an instance variable; it's not allowed to poke a singleton and grab state out of it; it's not allowed to print something; and it's not allowed to launch missiles.

What that gives you is:

1) It's very easy to test those functions - you define a set of arguments, you define a correct result, and you say 'call this, and you should get this result'.

2) It's very easy to parallelise these functions - since they're not affecting any outside state, no locking is necessary, you just run them side by side, and you're done.

3) It's very easy to debug these functions, since you have a defined input, and a defined correct output, you can sit there and easily understand what's going on.

4) it's very easy to reason about these functions, since you never read a chunk of code in them and go "god, what could all the values of this external state be?"

5) It makes code clearer, since you can easily document exactly what that bit of code is doing, without any reference to any external parts of the system, or any prerequisites.

Re: It has its uses

[beelsebob]

Actually, pure functional behaviour is exactly what *gives* you scalability.

By removing state, you make it possible to run things on thousands and thousands of servers without having some shared memory bottleneck that everything needs to talk to.

Re:It has its uses

[HiThere]

Functional languages are a bit more difficult to think about, but that may be a combination of my inexperience and the implementations I've seen. OTOH, some problems do not deal with with lack of state. I'd really like to use Erlang, e.g., but I need mutable state. You can do it in Erlang, but you've got to fight the system to do it.

Note: I don't need externally visible mutable state. That's clearly dangerous in a concurrent system. I need internally mutable state. In Erlang that means either storing things in a hash table, a database, or a block of uninterpreted bytes. All ways that are clumsy to handle (and, I presume, slow). That Erlang allows this indicates that it is seen as something that is concurrently safe. But the difficulty in doing this shows that the designers of Erlang didn't see this as anything important for their use cases.

Now it's a good question whether or not you consider immutability a part of the definition of functional programming. Lisp allows mutable state, so does Scheme. So does Erlang. But they all discourage it and make it difficult to use. It's my contention that the definition should restrict itself to shared mutable state, but I'm not sure that this is the consensus.

Re:It has its uses

[Anonymous Coward]

... the fact that functions are not first-class objects force you to use things like lambdas even where more elegant solutions may otherwise have been available.

I think you misunderstand what it means to be a first-class object. Lambdas *are* first-class objects. The *only* difference between a lambda function and a named function object is that the lambda function is anonymous (i.e., has no name). *All* lambda functions in *all* languages that support lambdas are first-class objects.

Re:It has its uses

[Anonymous Coward]

The thing that makes OOP OOP is inheritence, not ...

Utter nonsense. You can do OOP programming without ever having a class hierarchy more than one level deep.

The essence of OOP is having different classes, having encapsulated data, and having per-class (and sometimes per-object) methods to operate on that data. Inheritance is nice, but is absolutely not essential to doing OOP. In fact I've written many OOP programs where I never even used inheritance.

Re: It has its uses

[lgw]

Static type checking is where all the value comes from. Finding errors at the most convenient time. But every mainstream language has an escape hatch.

Re:It has its uses

[RightwingNutjob]

I personally like case or switch statements for my state machines. But that's just a prettified mess of goto spaghetti, especially if it looks like
while(1){
report_condition(condition);
switch(condition){
case CASE1:
condition = do_case1();
break;
...
} Which it frequently will for complicated transition logic.

Re:It has its uses

[silentcoder]

I never said it was the *only* way to do encapsulation - I said it was arguably the best way we have.

Re:It has its uses

[xski]

Agreed.

IMO, once you move beyond manipulating primitive types, that is, once you start using things like arrays or some C 'struct'-like grouping of data you *are* using objects. Now you can either use good OOP for your purpose not so good OOP (it ain't just a river in Egypt).

Re:It has its uses

[xski]

*rim-shot*

Re: It has its uses

[DarkOx]

It is a first class object. I passed an argument to it but there are all the usual methods on that method object. You absolutely can do something like:

mymethods[:foo].name

its valid and you'd get back its original name in this case. You could even define new methods on the object! It is a first class object in every way but how you happen to access it syntactically.

Re:It has its uses

[xski]

That belongs on a T-shirt.

Or maybe as the quote for one of those motivational posters you see hanging around cube farms.

Or better yet, the inside of the eyelids of every human who even thinks about writing computer programs.

Re: It has its uses

[silentcoder]

We are discussing syntax. That rather makes it an important consideration to the discussion.

Re:It has its uses

[GuB-42]

The simplest one is a comparaison function for a generic "sort" function.
It is much more convenient with lambdas.

Re:It has its uses

[lgw]

None of that sounds right. Every heard of currying? There's no real difference between a lambda and an object full of state, beyond the syntax. Lambdas capture arbitrary state. (Plus, in real software, the results of some functions is often some measurement of some changing real-world thing.)

Re:It has its uses

[beelsebob]

Currying doesn't violate referential transparency. curry is a function that accepts a multiple argument function, and returns a one argument function. It always returns the same function when it's given the same function as an argument. That's referentially transparent.

The difference isn't about being "full of state" it's about accessing state external to you. Again - if a function relies only on its arguments to determine its result, then it is referentially transparent, aka "purely functional".

Re: It has its uses

[DarkOx]

Right but other than capturing the reference to the method in the first place, even the syntax is the same.

Your only real complaint here (and I agree its valid) seems to be the return value of a "def" block is nil rather than the method object.

Re:It has its uses

[JesseMcDonald]

There's no real difference between a lambda and an object full of state, beyond the syntax. Lambdas capture arbitrary state.

When functional programmers talk about state they're referring to mutable state. What you are describing is simply data. Capturing immutable data provided through function arguments does not violate referential transparency. You still get the same result for the same arguments.

Plus, in real software, the results of some functions is often some measurement of some changing real-world thing.

That isn't a function, not in the mathematical sense. In Haskell it would be referred to as an I/O action. In functional programming objects exist which describe "impure" actions, such as sampling a sensor or printing to the console; these objects can be manipulated by pure functions, e.g. combining two actions to make a larger action, or mapping a function over the result, but are only executed (logically speaking[1]) by an impure external interpreter in the language runtime. The program itself is pure, even the parts which evaluate to IO actions—barring abuse of specific constructs like unsafePerformIO. The runtime, inevitably, is not pure, since has the responsibility of interfacing between the pure program and the real world.

[1] For performance reasons, of course, the compiler actually "inlines" the interpreter, generating impure object code similar to a traditional compiled imperative program. The external interpreter, like the C virtual machine model, is merely an aid for thinking about the code, not a concrete implementation.

Re: It has its uses

[Anonymous Coward]

Yeah well in Ruby you can bounce up and down on my rail.

Re:It has its uses

[lgw]

When functional programmers talk about state they're referring to mutable state. What you are describing is simply data.

That isn't a function, not in the mathematical sense.

Until functional programmers start speaking the same language as people in industry, we'll keep rolling our eyes and ignoring you.

Re:It has its uses

[jandrese]

The notation is simplified Erlang omitting the syntax I wasn't using and tweaking the glyphs a bit to make it look similar to the other example. Even if you wouldn't implement this example this way, it is the general way you program in a regex-argument functional language.

Re:It has its uses

[jandrese]

Someone else is going to come in and say the iterative version should be do_stuff().iterate(10) next.

I'm trying to illustrate the difference in the language, not give a course on abstraction primitives.

Re:It has its uses

[JesseMcDonald]

... we'll keep rolling our eyes and ignoring you.

It's your loss. BTW, the mathematical definition of a "function" as a fixed mapping from objects in the domain to objects in the range has been around a whole lot longer than the (mis)use of the term to describe procedures or subroutines in (some) programming languages. The idea that "state" implies mutation is commonplace even within the more mainstream areas of the computer programming industry, not just among functional programmers.

Re: It has its uses

[Anonymous Brave Guy]

On the other hand, if you've used a language that is designed to support functional programming, you probably wouldn't be in much doubt.

For example, here's the all-positive check written in Haskell:

all_positive = all (>0) [1, 2, 3, 5, 8, 13]

which is just a convenient notation for:

all_positive = all (\x -> x > 0) [1, 2, 3, 5, 8, 13]

where the backslash is Haskell's general syntax for introducing a lambda.

Criticising the ideas of functional programming because, for example, C++'s syntax for lambdas is horrific is like criticising OOP because setting up dispatch via vtables is a bit messy in assembly language. It's just not the right tool for the job, and it's unlikely to give great results no matter what you do with it. You have to look at the underlying principles to see whether they're useful or not.

Re:It has its uses

[Anonymous Brave Guy]

That's just bad functional code.

It was a simplified example, but I think the point would still be valid in some more complicated case that doesn't fit one of the everyday functional programming patterns. The state is still there, it's just conveyed by accumulating function argument(s) in recursive, functional code instead of storing it in loop control variable(s) in imperative code.

The other thing is you don't want to be "doing stuff" and iterating. You want to be computing stuff and then "doing stuff" on the entire set of output. The system as it pulls output will drive the iteration on the computation.

I think you're conflating lazy evaluation with functional programming here. In any case, I think that sort of claim needs some qualification. Haskell-style laziness is nice for composition in theory and sometimes it lets us write very elegant code in practice, but it can also become a liability, particularly if you're working with very large amounts of data or anything time-sensitive.

Re:It has its uses

[Anonymous Brave Guy]

Until functional programmers start speaking the same language as people in industry, we'll keep rolling our eyes and ignoring you.

I'm pretty sure maths has been around longer than programming, so who is really redefining the language here?

Also, false dichotomy is false. Functional programming concepts are widely and effectively used in industrial programming. The idea that what we're talking about is some academic, ivory tower idea is decades out of date.

Re:It has its uses

[Anonymous Coward]

U sound like you'd like monads on yo chin.

Re:It has its uses

[Tablizer]

Us Pastafarians...prefer to write Spaghetti Code

That explains it! The coder who came before me at this org must have been a [bleepin'] Pastafarian. Next time I'll apply at a Catholic org.

Re:It has its uses

[jbolden]

I'm going to argue there are no special cases that don't fit.

Basically
the set of all possible for loops (no side effects) \subset the set of all possible hylomorphisms (generalizations of map reduce) \subset of all possible recursions.

That's why I wanted to see a real example, because of mathematically they can't exist.

As for accumulators over loops those can be usually handled via. a fold providing the reduction operation is associative. The initial and final state never present a problem.

___

I'll agree I was considering lazy part of functional. At this point I think purity allows for laziness and laziness demonstrates a lot of the advantages of purity. Otherwise you are backed to mixed paradigm which I dealt with other places in this thread. As for lazy with large amounts of data, Hadoop is lazy. So I'm not sure what you are saying.

Re:It has its uses

[jbolden]

Here we disagree. I think the general way you program that sort of thing is via. a fold. I don't know Erlang but it has the classic folds:

foldl(Fun, Acc0, List) -> Acc1
foldr(Fun, Acc0, List) -> Acc1
Fun = fun((Elem :: T, AccIn) -> AccOut)
Acc0 = Acc1 = AccIn = AccOut = term()
List = [T]
T = term()

foldl is the preferred one for Erlang

Re:It has its uses

[Anonymous Brave Guy]

I'm going to argue there are no special cases that don't fit.

In a strictly mathematical sense, yes, various things are equivalent and various patterns are universal. However, that's a bit like saying you can do anything with sequencing, selection and repetition. While true in a sense, realistically it doesn't necessarily represent the clearest way to express everything. In practice, I have sometimes found that while I might build individual parts of a complicated algorithm from tools like folds, it may be clearer and easier to write the "big picture" using explicit recursion rather than trying to adapt everything to fit some standard algorithm.

As a practical example, not so long ago I was working on some code that would take some information in a certain format as input, and update a rather complicated graph-like data structure to incorporate that extra information. This algorithm involved walking the graph, and depending on the properties of each node reached and of the information to be merged in, either updating that single node "in place" or changing the structure of the graph around it. Each such step would typically transfer some of the remaining information into the graph, and then continue walking the rest of the graph to merge in the rest of the information until one or the other ran out. No doubt with enough mathematical machinations this could have been shoe-horned into some standard pattern, but in practice it was far simpler and more transparent to write a small set of mutually recursive functions that implemented the required behaviour at each step. And of course each of those functions then received information about the state of the graph walk and the state of the information being merged in through parameters.

At this point I think purity allows for laziness and laziness demonstrates a lot of the advantages of purity.

If you only care about the result of evaluating a function, sure, but if you also care about the performance characteristics of your program, I don't think it's so simple. Laziness can be both a blessing and a curse.

As for lazy with large amounts of data, Hadoop is lazy. So I'm not sure what you are saying.

In short, unrestricted laziness can cause huge increases in the amount of working memory required to run a program, until finally something triggers the postponed evaluations and restores order. As I recall, there was even a simple tutorial example in Real World Haskell that could wind up exhausting the available memory just by scanning a moderately large directory tree because of the accumulated lazy thunks.

Re:It has its uses

[jbolden]

OK I gotcha. It is shockingly easy in lazy code to write algorithms that are quadratic in memory. Arguably that's one of the big advantages of using standard morphisms and not recursions.

I also agree it is often (very often) easier to write an explicit recursion; and only then if you have to create a morphism structure. That's a different claim though than with loops. Once the algorithm is written as a loop you have all the pieces for a standard design pattern using morphisms. Which was my point to grandparent. The classification of all possible recursions is coming along nicely but we still have about 50 types of morphisms that (at least in theory) can show up. In practice hylomorphism covers most cases for recursions, and how to do this can be non-obvious. But hylomorphism covers all cases, with simple transformations of for-loops. Having written a for-loop you have the structure you need to do the morphism transformation, its the same work. My point above was about the easy case, not the hard case of general recursion you are talking about.

As an aside, I believe (not an expert) the condition for a graph traversal to be hylomorphic is that the operations follow the distributive law. Assuming I'm right on this, that's not a whole lot of math you just check your operation and apply one of the standard graph traversals.

Re:It has its uses

[Anonymous Coward]

I expect to so RUST or GO make inroads in these areas soon

Re:It has its uses

[Anonymous Coward]

Everything is fine till you religiously fanatical Flying Spaghetti people show up... pissin' in everyones kornflakes...

Re:It has its uses

[Anonymous Coward]

Or ... to put it in more technical terms... ZACTLY... the VM or KERNEL or CPU or whatever are still doing things the same way... just because the language you are stroking to in the bathroom prevent YOU from doing stupid things.. does not mean stupid things are not happening down in the stack... meaning the iterators in Ruby or Python are JUST AS EFFECTIVE as preventing certain problems like off by one errors as Haskel or Scala or whatever... just slower at it... trading stacks for loops help in segmenting the problem to multiple cores atm but loops will catch up when someone rebels against the current group think... not that stacks are bad... but they are limited by the memory accessed by the core that is managing it... and how the OS kernel is tuned. All this arguing is actually HELPFUL for the future... it all get's people thinking.

Re:It has its uses

[jandrese]

That doesn't illustrate tail recursion though. Also, nobody who is not already a functional programmer is going to have a chance of following that.

Re:It has its uses

[jbolden]

foldl in Erlang is tail recursive automatically. foldr is not by default tail recursive in Erlang, Though I should mention foldr is tail recursive in languages like Haskell, and there are implementations of foldr in terms of foldl and visa versa. The conversions between foldr & foldl (depending on which is tail recursive) make explicit what needs to be done to move from non-tail recursive to tail recursive for recursions. Yet another reason you want to use those.

And as for can't follow. Your claim was about the messiness that these imperative artifacts remained and were worse. To avoid the messiness, you have to use the looping structures of functional programming Doing functional programming imperatively, of course is going to be messy. Doing functional programming functionally and you get the benefits.

Re:It has its uses

[Anonymous Coward]

Your last paragraph answered my interrogation a bit. Having studied a functional programming language, I find it weird that a language has lambdas but doesn't have functions as a first-class object (or type).
If functions are first class objects, you're practically guaranteed to find lambdas in that language.

Re: It has its uses

[squiggleslash]

Java (like Flash) was always designed as a plug-in, running side by side with the browser, not an integrated part of the browser. T

Uh, what?

Just because Sun developed a Java plug-in doesn't mean that Sun's vision was ever that Java was primarily supposed to be used that way. Java has always meant to be used as a standalone programming language, and the percentage of Java development targeted at the plugin is absolutely tiny. Most of it is focused on back-end applications, websites, and the occasional desktop app.

I'm not sure where this "Java = applets" thing comes from, and it's especially hard to understand why software developers would think this given it's pretty hard to work in this industry for more than a few years without being given a Tomcat/etc application hosted in a JBoss environment to fix up.

My answer

[Anonymous Coward]

No.

Re:My answer

[ewibble]

yes,

OK a bit more detail, there are advantage to not having state, or at least making the system deal with it it lead to some really elegant code.

Just like most languages it has it limits, mainly input and output.

I have used haskell and I think it has some really good concepts but is plagued by people using being to terse and cryptic, 1 character names for types are not good yes you can work out what it is doing but you shouldn't have to, and the use of random definable operator like '' makes it unreadable without a reference manual for beginners. A part of good code is being clear, being cleaver isn't usually as important as being understandable. At least the uses I have seen generally been quite cryptic.

If the haskel community want haskel to popular they should make an better effort to make it more understandable.

Re:My answer

[Anonymous Coward]

" A part of good code is being clear, being cleaver isn't usually as important as being understandable. At least the uses I have seen generally been quite cryptic.

If the haskel community want haskel to popular they should make an better effort to make it more understandable."

...says the guy whose English is so mangled I had to read it twice...

Re: My answer

[Anonymous Coward]

Ya. Doesn't make what he said any less true and that is something you functional nerds can't seem to accept.

Re:My answer

[Anonymous Coward]

Yeah, but your iranian I bet ain't so hot.

Not that I am, but not that there's anything wrong with it.

Unless you are one of their religious nuts.

Then of course you should be expelled.

To outer space.

Re: My answer

[nasch]

I don't think Iranian is a language.

Re:My answer

[slickwillie]

"being cleaver"

Beaver? I told you not to hang around with the Eddie Haskell.

Re: My answer

[Anonymous Coward]

EF your elegant code. A code in the first place needs to be memory efficient and performant. This is what matters in runtime. This is what customers pay money for, the same money that pay the developer salaries.
I have seen overengineered products and code that look like advanced calculus, very elegant, very ingenious break in production in some aspect or another when you throw a problem at it when the problem has one too many rough edges. I have seen a code that looks like it has been written by a brute and looks like chupacabra munch said curved problems in production in no time and comes back asking for more.

Re:My answer

[Rockoon]

1 character names for types are not good

Says who?

All localized variables and types in my programs have 1-character names, and its for multiple good reasons including that because you can see that something is only 1 character at a glance, that therefore you know for sure that it doesnt have much if any outer scope with that very same glance.

Re: My answer

[Sique]

The actual language is called farsi (new persian).

Re:My answer

[Hognoxious]

being cleaver

That's a cutting remark!

Re:My answer

[DickBreath]

No? So you're saying you prefer dysfunctional programming?

Re: My answer

[Anonymous Coward]

"Understandable" is a relative term. I understood more about multithreaded programming at the age of 10 than most professional programmers who specialize in multithreading will achieve in a lifetime. On the other hand, most children will understand more about socializing than I will in a lifetime.

Re: My answer

[Anonymous Coward]

I think what you're getting at is "Code that looks pretty but kind-of works is the worst kind of code."

Re:My answer

[Anonymous Coward]

This comment is severely underrated.

Dysfunctional programming

[FrankHaynes]

seem to be the prevalent choice on the web these days.

Re: Dysfunctional programming

[Anonymous Coward]

Your attempt at a joke is pretty dysfunctional

Re:Dysfunctional programming

[Anonymous Coward]

Academic spotted. Keep wanking on code elegance while the rest of us get shit done.

Re: Dysfunctional programming

[Anonymous Coward]

Your code must be clean and maintainable, otherwise you won't get shit done for long. You'll just have shitty code.

Re: Dysfunctional programming

[prefec2]

That is why they all use JavaScript and PHP. Thanks.

Lots of claims are being made about it's virtues

[Anonymous Coward]

A properly placed apostrophe has its virtues as well. it's means it is.

It's amazing that people that can learn dozens of languages all more complex than the previous can't seem to grasp the humble apostrophe.

functional composition

[motorsabbath]

I like functional composition, it certainly has its uses (at least as middleware). I disagree with the notion that it makes code more readable though, in general. It only makes code more readable if you're familiar with it (functional programming).

Re:functional composition

[Pseudonym]

It only makes code more readable if you're familiar with it (functional programming).

Well that's a truism. Object-oriented programming is the same: it only makes code more readable if you're familiar with it.

The main distinction between the two, however, is that object-oriented programming was invented, but functional programming was discovered.

Re:functional composition

[Anonymous Coward]

I find the readability of functional programming languages lacking. Well, I mean I am so unfamiliar with that style that it's off-putting. To anyone who would disagree, consider how much flack Perl gets for its "unreadability" (note: I've actually written a lot of Perl code and it doesn't bother me too much).

Re:functional composition

[Anonymous Coward]

My impression is that functional programming comes from Lambda calculus which was introduced in the 1930's. Lambda calculus is used to describe algorithms as a collection of expressions that can be rewritten in more simple expressions. That's why a functional programming language can write faster and more simple code in theory that can be proofed to be correct as if it was a mathematical lemma. It is this lemma bit that makes functional programming very interesting. This means bug free code!
 
Of course computer programs have to be translated to machine code. We have seen an evolution in computer languages where the programmer wrote machine language, assembler, computer language that was close to the metal, computer language that could be easily ported to other systems, computer languages that are written for a virtual machine, and computer languages that are interpreted. Functional programming doesn't really fit in that evolution.
 
How are functional programs translated into machine code? I've played a bit with Haskell around 2005-2007 (as hobby, nothing productive), and I think that behind the scenes it is just translated to some C-like programming language. This kills the main strength which is writing fast and simple algorithms. No matter how simplified you could make your complex algorithm in a functional program, maybe the more complex functional program creates more efficient machine code. That same complex algorithm that is simplified thanks to lambda calculus techniques might be so difficult to translate to machine code that the resulting program is less efficient.

I don't know if this problem is fixed with better interpreters/compilers. I don't even know if the current computer systems can profit from a fully functional language. To me it seems that the current hardware and operating systems have evolved with the C programming language. Java, .NET are build upon C and are also imperative languages although with the OO paradigm. But a language like Haskell needs an interpreter, compiler that translate the functional language to a sort of imperative language so it can be compiled. This adds extra layers of complexity and a lot of work in creating a better compiler/translator. So the theoretical advantages are outweighed by the same disadvantages as Java and even Javascript without a multi billion dollar industry behind it unlike Javascript. Maybe there is still the hardware problem and we might need a complete new kind of computer system/instruction set to make the most out of functional programming.

Re:functional composition

[Pseudonym]

My impression is that functional programming comes from Lambda calculus which was introduced in the 1930's.

Mostly correct. The Lisp family of languages borrow the lambda notation, but they're not based on lambda calculus in the Church/Tarski sense.

The differences (and the differences between functional programming and the theory of sets-and-functions that we teach to high school students) don't really matter at a basic level.

How are functional programs translated into machine code?

Here you go. This book is 30 years old, but the basic principles are the same.

That same complex algorithm that is simplified thanks to lambda calculus techniques might be so difficult to translate to machine code that the resulting program is less efficient.

For what it's worth, the same is true of any high-level language. CPUs don't understand virtual dispatch natively, either.

Scala

[Anonymous Coward]

I prefer to use functional programming where it makes sense (most of the time). One reason I like Scala is that it's not pure. You can always write a for loop if you need to. Haskell, is a bit less forgiving.

Re:Scala

[Anonymous Coward]

> Haskell, is a bit less forgiving

I see what you did there!

And I forgive you, master-of-double-meaning.

Re:Scala

[jbolden]

Haskell has a for loop. The thing is that there are really 2 types of for:

1) Go through an array and do something to each element (map)
2) Do a sequence of actions. for :: (Traversable t, Applicative f) => t a -> (a -> f b) -> f (t b) is just traverse with arguments flipped

As Bruce Lee said

[Z80a]

Use only that which works, and take it from any place you can find it.

Re:As Bruce Lee said

[Anonymous Coward]

And then he suddenly died.

Re:As Bruce Lee said

[Z00L00K]

He's not truly dead until he's forgotten.

Re:As Bruce Lee said

[DickBreath]

Bruce Lee also said: If you spend too much time thinking about a thing, you'll never get it done.

So he must have been an expert at avoiding work. And this quote is "that which works". (Or rather doesn't work.) And I did take it from any place I could find it . . . using google to find Bruce Lee quotes.

"Like"?

[eyenot]

I don't get what you mean by "like".

Procedures are procedures, period.

Sometimes it's helpful to have some procedure (or subroutine) store some value in some location before popping the stack.

What I really don't get in this write-up is the insinuation that a focus on (purely) functional programming is a "recent trend". That implies that the majority of today's coders have no fucking idea how coding has progressed through the last few decades (which I've been there to see firsthand).

That's the only interesting thing about this article.

Re:"Like"?

[gl4ss]

That implies that the majority of today's coders have no fucking idea how coding has progressed through the last few decades

..and you were unaware of this? how in the hell?

Re:"Like"?

[lucm]

What I really don't get in this write-up is the insinuation that a focus on (purely) functional programming is a "recent trend".

There is a new area where functional programming does shine, and it's large scale analytics. Sometimes when you think about solving a specific problem, you can go about it in a few different ways, but almost every time if your solution later needs to be parallelized (i.e. running on a Hadoop cluster) the functional programming way will be easier to adapt.

For instance, let's imagine a situation where you have a small e-commerce website and the marketing team wants to know what are the most common sequences of pages visited by users. You could write a quick & dirty python script that parses the logs and creates a hash of every possible sequence, then you could use that to "rank" sequences by time, browser, location, etc. Or you can play the fancy card and use something like Petri nets in a map-reduce-ish kind of way. Both approaches work.

But then your small website becomes a big success, and grows and grows and grows, and one day your script runs out of steam. So you figure, let's run that bitch on a big Hadoop cluster. Well guess what, a script that is map-reduce friendly will be a lot easier to adapt for that.

I'm not saying every single situation warrants for this kind of thinking. But that qualifies as a kind of problem that is fairly new for mainstream programmers.

 

Re:"Like"?

[dgatwood]

In the long run, I'd expect the tools to adapt to solve those problems more transparently, e.g. through the use of standardized libraries that hide the parallelization behind procedural wrappers so that developers can write seemingly procedural code, but gain the benefits of massively parallelized code for the pieces that matter.

Or not; hard to say.

Re:"Like"?

[Anonymous Coward]

Even better than that, you make a python script first, quick and dirty. then you decide you really like this metric and let the website log the order of pages accessed, so that your query is payed at the moment that the pages are served. Since websites are inherently parallel by design your query grows with the website.

Re:"Like"?

[Anonymous Coward]

Procedures are procedures, period.

Perhaps you should try learning a language like Haskell. Just to open your eyes.

Re:"Like"?

[angel'o'sphere]

You don't know what functional programming is.
That is clear from your comment.

Hence you don't get the question about "like".

Hint: there is wikipedia.

And using "procedures" or "functions" in Pascal or C: that is not functional programming.

Re:"Like"?

[Anonymous Coward]

That implies that the majority of today's coders have no fucking idea how coding has progressed through the last few decades.

I'm always impressed every time I see a CL script (IBM Control Language) still able to run after 20+ years, and still do it's job.

Re:"Like"?

[Anonymous Coward]

Based on the millions of man-hours that have been poured into auto-parallelization and "generic" parallel libraries and how application-specific they still are, I'm going with "or not."

Partitioning the problem space across clusters of varying size and capabilities is also a difficult problem. There have been some attempts at automatic partition scheduling, but too much performance is lost if the scheduler does not have detailed knowledge of the communication required between work partitions.

The exceptions to the above are things that are embarrassingly parallel, which have no communication or map directly to map-reduce or a single library call.

Re:"Like"?

[Anonymous Coward]

Business Requirements that expect the same code be running in 10 years on a massively different scale are usually a not very good idea.

Re:"Like"?

[swillden]

I don't get what you mean by "like".

Procedures are procedures, period.

Indeed they are. And purely functional programming languages don't have procedures.

The grafting of functional programming constructs onto imperative languages is interesting and useful, but every programmer should spend some time learning to program in a purely functional style, even if they then go back to imperative languages for their everyday work. It opens up a whole new way of thinking about code.

Re:"Like"?

[jbolden]

You really do have to start over and write code very differently. That's unavoidable. Procedural languages are good at sequencing things for a von-Neumann architecture. Parallel systems are not von Neumann Architectures. Procedural code encourages bad thinking habits which create runtime problems. To do massive parallelism you want all your code to not not specify order of operations (so the runtime engine can decide) and not involve state changes till the end (since these require synchronizing between computing nodes). If you think about the first thing you learned when you learned to program it was: " a program is a sequence of steps" (order of operations). The second think you learned was print (state change).

You have to reorganize your code in a way consistent with a new paradigm. No library is going to solve that.

Re:"Like"?

[lucm]

Business Requirements that expect the same code be running in 10 years on a massively different scale are usually a not very good idea.

Twitter, Facebook, Amazon...

Re:"Like"?

[Anonymous Coward]

I don't get what you mean by "like".

But surely you understand how people less high on the spectrum have likes and dislikes, right?

I like programming that works

[redmid17]

What the fuck is functional programming, if not that?

Re: I like programming that works

[Anonymous Coward]

Its like "no global variables" it's likeable, it's likers less so.

Re: I like programming that works

[nasch]

Functional programming isn't programming that functions. Look it up if you want to learn what it is.

Re: I like programming that works

[stridebird]

A triple "it's" / "its" error in one sentence. Good work, AC.

Re: I like programming that works

[Anonymous Coward]

Don't read Hobbs you pedantic fuck... would not want your understanding to be forced on you by all the offenceve micpelings.

It's not that I want to brag I'm old...

[gwolf]

But it seems that I will.

Around ten years ago, I started writing a column for a magazine. My first article was precisely a way to use functional programming for "real" code, using a multi-paradigm language (Ruby).

I didn't jump on the Functional bandwagon first time I saw it; it took me around ten years to understand and embrace what it can do. So we are talking about 20 years of hype. At least.

I am far from proficiently thinking functionally, although I have used it for many interesting things. It is a cool, and very different, way to work. It can make many things faster and simpler, but if you completely bite the bullet and make it your dominant paradigm, it will kill your productivity (with many other things that are not best served by that paradigm.

It has a clear spot under your programmer belt. But it should not be The Only Way to approach a program - unless you are Truly One with the Tao.

Re:It's not that I want to brag I'm old...

[Anonymous Coward]

That's the downside to multi-paradigm languages: using one, it'll take you a long time to get what functional programming is.

One benefit to a purer language is that using one forces you (or at least strongly encourages you) to use the functional paradigm. It sinks it pretty quickly that way.

Re:It's not that I want to brag I'm old...

[angel'o'sphere]

(This is not aimed at you, but your post is a good hook)

There is no bandwagon and there is no hype.

Calling something a bandwagon or hype is a very stupid typical american attitude.

You wake up out of your ignoranced "hu ho, what is that 'new' functional thing, everyone is bandwagoning/hyping around right now??"

And you completely ignore the fact: functional programming is probably close to 50 years old (to lazy to google), there is absolutely nothing new about it. Only the "general education" of software developers is so bad that they think: "Oh you see, (after Groovy had it for decades and Scala since over 15 years, .NET probably also about 10 years) that new lambda stuff in Java 1.8!? Who will ever need/use that? What did the Java standard guys think in adding such complete nonsense to Java? Must be a new hype!"

Functional programming might seem "new" because only a very few people like Lisp (I hate Lisp), and other languages like Miranda, Caml/OCaml, Haskel etc. never really became mainstream.

Re:It's not that I want to brag I'm old...

[TheRaven64]

Add to that, the defining feature of a functional language is the set of things that it disallows, not the set of things that it permits. A multi-paradigm language, by definition, has to permit anything that the various paradigms permit and so doesn't gain the benefits that you get from being able to reason about your code in a language that doesn't permit unconstrained mutability or side effects.

Re:It's not that I want to brag I'm old...

[Anonymous Coward]

Old? 10 years ago? 20 years of hype? Get off my lawn youngling!

Re:It's not that I want to brag I'm old...

[michael_wojcik]

functional programming is probably close to 50 years old

It was 50 years old nine years ago.

That's assuming you count from when a programming language with explicit functional constructs was introduced. Conceptually it goes back at least to lambda calculus.

But certainly you're correct that the promotion of functional programming is not new. The earliest example that comes to my mind is Friedman's The Little Lisper, and that was published in 1974 (and is still in print). That's the first widely-circulated text I can think of that embodied the idea that functional programming is a different paradigm (though I don't think Friedman used that word) from procedural programming.

So the bandwagon has been rolling for around 43 years.

I do to an extent

[reanjr]

While I wouldn't want to program in a pure functional, no side effect language, a good mix of differing paradigms seems to me to be the way to go. Java and .NET went overboard on the OOP, and it leads to these poor abstractions in many cases (I.e. AbstractFooProcessor), which are much better approached with some FPd

Pure functional code is super easy to reason about, though, especially asynchronous code. OOP has its role, but oftentimes you find yourself on loose footing, with its focus on always changing state. This can be addressed with good practices, which leads you down class hiearchy hell. Throwing some FP in the mix gives you (mostly) the best of both worlds.

Re:I do to an extent

[Anonymous Coward]

There is no such thing as a programming language that has no side effects. All input and output is by definition a side effect. An ideal/pure functional programming language is 100% useless.

Re: I do to an extent

[reanjr]

You don't know what you're talking about. Just because a program has side effects does not mean the functions have side effects.

f(S) = S'

You pass in the current machine state, and you get back a new machine state. The original state is not modified. There are no side effects.

No

[Anonymous Coward]

And neither should you.

Re:No

[Anonymous Coward]

Imagine you're a 3 to 5 year old kid and the teacher has given you a simple problem: "Count the number pencils in the cup." The total number of pencils do not exceed 10.

The kid would use his fingers to keep count. That is, he starts with all his fingers and thumbs curled and when considers a pencil, he straightens one finger or thumb. After all the pencils have been processed, the number of straightened fingers/thumbs is the same as the number of pencils in the cup.

What does this have to do with programming? Well, processing each pencil is similar to processing objects in a "for" loop. Keeping count with fingers is similar to having a variable that is constantly changed based on the algorithm. FP considers both "for" loops and variables as bad (causing side effects) and does not allow them. That means you have throw away the most fundamental and practical algorithmic skill you learnt as a kid and that's just stupid.

Re:No

[jbolden]

At about age 3 months the child learned "there" or "not there" for things. They could distinguish 0 from 1. Functional counting reduces to an even easier algorithmic skill learned even earlier

I like functions...

[__aaclcg7560]

I supposed there is more to functional programming than using functions in a program?

Re:I like functions...

[mrchaotica]

Yes, it means your functions aren't allowed to have side effects (i.e., all parameters are passed by value and the only result is the value returned to the caller).

Personally, I like it because it's a good way to manage complexity -- kind of like the encapsulation of object-oriented programming, except applied to the verbs instead of the nouns.

Re:I like functions...

[__aaclcg7560]

Yes, it means your functions aren't allowed to have side effects (i.e., all parameters are passed by value and the only result is the value returned to the caller).

I generally program that way in Python. I'll have to add functional programming language to my bucket list.

Re:I like functions...

[vtcodger]

I know squat about Functional Programming. But I'm told that Python's List (and generator) comprehensions are a functional programming concept. Input a list, perform an operation on all or part, and output an altered list. Not terribly readable IMO, but otherwise quite likeable. I find myself using them quite a lot.

As for stuff like closures. The explanations I've read tend to be utterly opaque. Sort of like a color-blind individual trying to explain the color green. I'm not sure if the problem is me or the explainers. After a lot of reading, I think I sort of might understand how closures be done in Python. But it's sort of like reading about how to build a working mechanical arm out of toothpicks. Interesting, but I'll be damned if I can envision a situation where I might want to do that.

Re:I like functions...

[vtcodger]

Here's a document that explains functional concepts in Python. Seems reasonable:to me.

https://docs.python.org/2/howt...

Re:I like functions...

[swillden]

Yes, it means your functions aren't allowed to have side effects (i.e., all parameters are passed by value and the only result is the value returned to the caller).

It's quite a bit more than that, at least if you're talking about pure functional programming. You also have to get rid of most all of your old notions of flow control. Imperative programming is about defining sequences of steps, some of which are conditional. Functional programming is all done with nested transformations; there are no sequential steps, there are no branches, there is no iteration.

If this sounds freakish and impossible to someone raised on imperative programming paradigms... yes, it is. Functional programming requires thinking in an entirely new way. It's a very powerful tool. I'm not sure it's the best tool for the systems I build (though I'm also not sure it isn't), but at a minimum it's a useful way to think about code construction. Every programmer should spend some time learning it.

Re:I like functions...

[jbolden]

In Python you would rarely want to do it. I'll give you some simple examples.

items = [1, 2, 3, 4, 5]
def sqr(x): return x ** 2;
list(map(sqr, items))

Now imagine this were legal:
[1, 2, 3, 4, 5](map(**2,items))

The **2 is a closure

Re:I like functions...

[mrchaotica]

It's quite a bit more than that, at least if you're talking about pure functional programming. You also have to get rid of most all of your old notions of flow control. Imperative programming is about defining sequences of steps, some of which are conditional. Functional programming is all done with nested transformations; there are no sequential steps, there are no branches, there is no iteration.

If you think about it, those are inevitable consequences of the constraints I mentioned. However, it's good that you highlighted them.

If this sounds freakish and impossible to someone raised on imperative programming paradigms... yes, it is. Functional programming requires thinking in an entirely new way.

Yep, both recursion and constructs like map/filter are incredibly useful (even in procedural/OO languages) once you get the hang of them.

Re:I like functions...

[Anonymous Coward]

I'm afraid you do not understand closures.

No, the **2 is not a closure. The **2 is squaring a variable that's passed to the map iterator function.

A closure would be if your map iterator function enclosed a variable from a context outside itself.

Re:I like functions...

[jbolden]

** is a function of two variables. The 2 is coming from a different context. **2, as a squaring function is a closure. No need to be complex about closures.

Re:I like functions...

[JesseMcDonald]

** is a function of two variables. The 2 is coming from a different context. **2, as a squaring function is a closure.

(**2) is a Haskell-style "operator section" which would be shorthand for "lambda x: x**2" in Python. This lambda has no free variables and thus is not a closure. An example of a closure would be the second lambda in "lambda x: lambda y: x**y", which closes over the free variable "x". You can also do this without lambdas:

def pow(x):
____def curried(y): return x**y
____return curried

# returns closure of lambda y: x**y, capturing x=2
f = pow(2)

# returns 2**4
f(4)

(Pretend the underscores are spaces.) The important part is that the function you are capturing includes references to free variables inherited from its original context.

Re:I like functions...

[jbolden]

I was treating (**) as your second case, ignoring the (**2) as a specific function. Remember the idea originally was to show a simple example of the concept for Python.

Re:I like functions...

[JesseMcDonald]

So you were treating (**) as the free variable? That works, provided the operator actually appears as a function argument or local variable in an enclosing function context. References to global definitions do not create closures in Python. (The value of a global variable or function definition is looked up at each call, not captured as part of the lambda.) However, in that case you can't really refer to (**2) as "the squaring function" since (**) could do anything, not just exponentiation.

Re:I like functions...

[Anonymous Coward]

Congratulations! This conversation has succinctly illustrated why functional programming should go away and never come back. It's garbage that gets in the way of making things work. There is no need for these "features" to calculate a power of a number.

It depends on the use

[nanolith]

Functional programming languages like Haskell, ML, and Gallina can be very beautiful. The problem is that they have a steep learning curve that has less to do with the syntax of the language and more to do with the semantics. If one is well versed in category theory or has spent a significant amount of time working with functor spaces, monoids, and monads, then it's much easier to understand a non-trivial application written in Haskell than the equivalent object hierarchy in an object-oriented language. The up-front cost is greater in terms of study and learning the semantics, but the end result is significantly more powerful.

I love functional programming. I went from C++ to Haskell and C as my go-to languages for personal projects. However, in my professional work, I tend to factor long-term language popularity into my decisions. So, I'm more inclined to use languages like Java, C#, Go, Python, and Ruby when I'm paid to write software. I have to consider the total cost of ownership in my professional work, and part of that cost is finding people to maintain it years from now.

I think that FP has an elegance that makes it a worthy model, and I hope that some day, FP becomes more popular than OOP. But, I'm old enough to understand that technical superiority rarely wins out to popularity. Popularity matters. This sort of calculus is one of the reasons why FP has not gained much traction despite all of the buzz.

Re:It depends on the use

[Anonymous Coward]

Wow, here I am reading Cheng's How To Bake Pi. She is a student of category theory and just told me that a one-object category is exactly a monoid. And now I find those concepts here.

Re:It depends on the use

[Pseudonym]

If one is well versed in category theory or has spent a significant amount of time working with functor spaces, monoids, and monads, then it's much easier to understand a non-trivial application written in Haskell than the equivalent object hierarchy in an object-oriented language. The up-front cost is greater in terms of study and learning the semantics, but the end result is significantly more powerful.

I strongly suspect (but can't yet prove) that the supposed up-front cost in understanding Milner-esque functional languages is just the same as the up-front costs for Simula-style object oriented languages. The difference is that in the case of Simula-style object oriented languages, most of the up-front cost has already been largely paid by the time you come to them.

If it's any help, consider that there seems to be a significant learning cost in wrapping your brain around "real" object-oriented languages such as Smalltalk when coming from "broken Simula" object-oriented languages such as Python or C++.

We teach set/function theory and basic logic to high school students. It shouldn't be that much harder to make the very small amount of generalisation to explain the fundamentals of a modern logic-based type system.

Re:It depends on the use

[nanolith]

I don't disagree with your assessment. However, if your assessment is valid, then a functional language is still going to be quite foreign to someone who has only been taught object-oriented programming. I agree that we can go deep down the rabbit hole with OOP as well. The minimal interface that has been extracted from the science behind OOP and introduced to programmers in general is a mere shadow of the works of folks like Barbara Liskov.

FP has yet to have this generational winnowing. It is still fresh and academic. We can build people up to understand this, or we can pull these concepts down to their most basic versions that are still useful. I suspect that both will have to happen before the industry can meet in the middle with FP. We are seeing this happen already as mainstream languages are adopting bits and pieces of functional concepts. I think it's more likely that we will see functional applications of OOP, such as in languages like Scala, than OOP superseded by FP. That's okay. There are already plenty of examples of non-mutable objects with copy-on-write semantics. We are seeing functions treated more and more like first-class objects. There are examples of the FP-as-style movement taking off.

I believe that we should teach higher math in high school and even as a requirement for engineering or information systems disciplines. Currently, most universities top out bachelor degree seeking students specializing in these disciplines to calculus, differential equations, and linear algebra if they are lucky. It would be nice to see abstract algebra and some category theory taught as well. When I advise people genuinely interested in pursuing software development as a career, I strongly recommend that they minor in mathematics so they can have the opportunity to take these more advanced classes.

That being said, there's nothing that prevents people from studying this for self-improvement. Learning either or both OOP and FP will fundamentally change the way that one organizes software. I'd love to see high school kids exposed to these concepts and the mathematics behind them. Then again, I'd also love to see high school kids taught how to build their own CPUs from 74-series logic ICs. Understanding the theory of computation at an intuitive level will do incalculable good for most of these kids through the rest of their careers. If I were to teach a class to high school level students, it would be along this line. I can guarantee that they will never look at a computer, embedded device, or "smart" device the same way again.

Re:It depends on the use

[jbolden]

FP is already more popular than OOP. The world's most popular programming language (Excel) is functional. Think of a spreadsheet as just a bunch of out of order function definitions...

Re:It depends on the use

[vtcodger]

"The world's most popular programming language (Excel) is functional"

Is that intended to be an argument in FAVOR of FP?

Re:It depends on the use

[jbolden]

Yes. I think it counters the "functional programming is too hard to learn for most people" argument fairly well. It shows an example of a functional programming language that lots of low skill developers (i.e. general office workers) use quite comfortably. There are of course more interesting functional languages but because they are more interesting they require more learning.

Re:It depends on the use

[hajile]

You may have a point about Haskell, but not about ML. Further, SML basically gets everything right that Haskell gets wrong.

SML isn't lazy. Humans don't think in terms of lazy evaluation. Even though Haskell is much more popular and has much better tools, MLton will usually compile faster code.

SML allows side effects. Haskell talks about purity, but the presence and reliance on unsafePerformIO shows that purity has limits. The practical answer is to write without side effects then add them to designated parts of the codebase which gets you most of the benefits of purity without all the overhead and headaches for the last 5% of your program.

SML is immutable by default, but allows mutation if needed. Making everything immutable is great for some problems (eg, concurrency), but is generally bad for performance (determining when in-place mutation can occur instead of a new allocation is a hard, branchy problem).

The biggest question is why SML isn't ruling the world. Consider golang vs SML. SML is about as fast, has a similar concurrency model in CML extensions, has a much better type system, and has much more simple syntax (despite being a more powerful syntax). Golang is used because the tooling is very nice, but why did Google choose to pour resources into golang (or even make it in the first place) when a better solution exists? Because familiar beats everything.

In schools where SML is taught as a first language, nobody has problems learning it (compared to imperative languages). A lot of such people I've talked to even prefer the syntax. Most schools teach a language with a C-derived syntax and approach, so those devs learn to prefer that (and usually never even see ML-style syntax). Haskell has issues with popularity because of complexity. SML has issues with popularity because "popularity begets popularity".

Re:It depends on the use

[vtcodger]

Maybe. But in my experience, Excel spreadsheets tend to be slow, clunky and, most annoying, very buggy. I don't think those are admirable characteristics. Nor do I think those problems are essential to the FP paradigm.

AFAICS, the principle value of non-trivial spreadsheets is the ability Excel, Oocalc, etc to generate pretty graphs for presentation purposes with less aggravation than other alternatives. And, I guess maybe under some circumstances a spreadsheet is a viable alternative to a small database.

Re:It depends on the use

[Anonymous Coward]

FP has yet to have this generational winnowing. It is still fresh and academic.

Functional programming slightly predates Algol-60. Lisp dialects were used for a lot of real problems in the 70s and 80s; a Lisp machine was the first workstation capable of processing HD-quality digital video streams in real time. The winnowing was done, but it was mostly forgotten because C was more practical on the affordable hardware of the time.

It seems like the last three decades or so of language design has been trying to shoehorn Lisp-y features into Algol-60 syntax, as cheap hardware becomes more powerful. When it first came out back in the 90s, Java was described by a designer as "dragging C++ programmers halfway to Lisp" (paraphrasing). Now every language is getting lambdas, one of the core features of Lisp as it was first implemented in 1959. It also seems like every scripting language (Lua, Python, etc.) is just the designer's favorite 80% of Lisp with Algol-ish syntax.

Re:It depends on the use

[Anonymous Coward]

Excel spreadsheets don't forget are written by lousy programmers. As for slow, Excel is a very high level language. Functional languages when programmed badly can be extremely slow, so that's not a totally unfair criticism (as long as we remember the quality of the programmers).

As for debugging, that's one of the things better functional languages provide. Actually one of the reasons Microsoft invested so heavily in functional languages is it wanted to introduce user defined functions into Excel in a way that was comprehendible to mainstream Excel users (think Lotus Improv).

____
Switching to Anonymous posting because I'm getting attacked by the systemd crowd who are modding everything I write regardless of topic down, sort of a karma war. Just ping to grandparent if you respond here so I'll see it.

Re:It depends on the use

[jbolden]

ML is a cool language. I don't agree with you that SML issues are driven by lack of popularity. I think the problem was premature specification (essentially the same thing that happened to Common LISP). The spec requires consensus to change and thus SML stagnated. Others in the ML family like F# continue to good work SML started. Arbitrary length integer operations, expression type declaration, string formatting, translations, string joining... Those and many more are real issues.

SML

[Anonymous Coward]

I've only used a functional language for a brief time, in school, in a class that surveyed various programming languages. I wrote some SML (Standard ML) and I really enjoyed it. For some of the programming exercises the solutions were small, elegant, and easy to understand. Writing SML also "felt right" in many circumstances and the functional aspect, once I got used to it, was easy to deal with.

But, since then, almost 20 years later, I haven't touched it or any other functional language. SML doesn't pay the bills. I haven't heard of functional languages being used much at all in the "real world" though. If you want to make a living, it's Java, C#, PHP, maybe C or Python, things like that. I've heard that Erlang is used in the telecom industry, but that's about it.

Gotta do what pays the bills.

Wrong question

[gweihir]

The right question would be "Do you understand functional programming?". And when you see about 99% of all "coders" having no clue, then you could ask the rest why they invested the time.

Re:Wrong question

[Anonymous Coward]

Functional programming. It's a great way to understand pure programming in the sense of lambda calculus and pi calculus and the various calculi.

Another place to find calculus is on your bathroom faucets, but we normally try to clean that shit off because it's embarrassing.

I have nothing against functional programming as a tool but its like teaching modern world languages. For some it'll pay off but for the great many people it'll be a dead skill that has no real world purpose. I have yet to see any real world functional programming in a production setting.

Re:Wrong question

[bzipitidoo]

A more basic question: "Do you understand recursion?" Lot of programmers really struggle with recursion, and avoid it like the plague. A common mistake is thinking that exiting the function means exactly that, rather than exiting only the current invocation of the function.

Re:Wrong question

[gweihir]

Ah, yes. Lots struggle even with basic concepts of coding. Sad, but true.

Re:Wrong question

[Anonymous Coward]

I was using that question in an interview. One candidate answered "To understand recursion in programming, first we must discuss recursion in programming". He laughed a bit and then went on to say that he got it from a web comic.

I hired him. Truth be told, he's a mediocre coder and he doesn't really grok recursion or tail optimization. But, as his easy manner in the interview attests, he's really good at talking to people and he goes to most of the events with clients and partners to shmooze. He's actually very valuable in this role: he wins us the good will we need to finish a late project or get a bit more cooperation from a vendor.

I'm pretty sure he's going to be my boss some day.

Re:Wrong question

[Anonymous Coward]

I avoid recursion like the plague because I work on systems with tight memory constraints and overrunning the stack is a serious concern. In fact, I've had it happen several times. If you don't understand the risks associated with recursive programming you're no better than those who struggle with it.

Re:Wrong question

[Anonymous Coward]

'"Do you understand recursion?"

Lot of programmers really struggle with recursion, and avoid it like the plague.'

I think you'll find that has less to do with understanding recursion and more to do with not thinking recursively. Recursion in practice rarely offers a performance benefit over an equivalent implementation in a loop.

Re:Wrong question

[lgw]

"To understand recursion in programming, first we must discuss recursion in programming".

To understand recursion, first we must understand recursion, and then we must understand tail recursion.

To understand recursion, we must incrementally increase our understanding of primitive recursion.

Re:Wrong question

[gweihir]

Well, first, you can often do it "rolled out" and with no per-level storage. You would need to document that you actually do recursion, just optimized for stack usage. But that is for cases where this (complicated) implementation is still easier to understand than a conceptually iterative one.

But second, I do agree. Stack usage is something any real coder needs to understand. Unfortunately, the modern stuff most people know exclusively (Java, modern scripting) hides that and as soon as such people do run into memory constraints they have no clue what happened and are completely lost.

Re:Wrong question

[gweihir]

Recursion is not about performance. In fact, any recursive program can be made faster by transforming it to iterative form and good compilers actually offer that as optimization. Recursion is about simplicity of the code, which in turn is about reliability, maintainability and security.

Tools are tools

[Anonymous Coward]

Asking whether you like functional programming is like asking whether you like phillips head screwdrivers.

Functional, procedural, and object oriented programming methodologies are tools.
Functional, procedural, and object oriented programming languages help facilitate the methodologies, but are not essential. You can do functional programming with a procedural language, or even procedural programming with an object oriented programming language.

A good programmer uses the right tools for the right job.

Re:Tools are tools

[Anonymous Coward]

Asking whether you like functional programming is like asking whether you like phillips head screwdrivers.

Yes, and many people have opinions along the lines of phillips head screws suck because they are designed to cam out when too much torque is used. There are a few times you want something like that, but otherwise they are way over used and make disassembly difficult.

It is quite valid to ask people's opinions of whether they like functional programming or not, because there are no hard boundaries between the regimes where such a tool is good vs. not good. It is also easy to be stuck in an environment where such a tool is overused, where someone else starts a project with a similar mentality to thinking all screw heads are equal.

Re:Tools are tools

[Pseudonym]

Asking whether you like functional programming is like asking whether you like phillips head screwdrivers.

I do not. Give me JIS screwdrivers any day.

Re:Tools are tools

[lucm]

Asking whether you like functional programming is like asking whether you like phillips head screwdrivers.

I do not. Give me JIS screwdrivers any day.

If you like JIS, you like Phillips. If you like Phillips, you may not like JIS. It's like rectangles and squares.

Re:Tools are tools

[Anonymous Coward]

Asking whether you like functional programming is like asking whether you like phillips head screwdrivers.

Ugh, Phillips head screwdrivers are the worste chisels.

Moderate usage okay

[Anonymous Coward]

There are some really slick things you get with lambdas. I'm glad they were introduced in java 8. I have a usage pattern where I end up pairing them with enums and it simplifies so many things (e.g. You practically never need a switch statement ever again). It really can help with readability in these circumstances.

But I don't like functional only. My head hurts when I try to unwind some of the functions I see in mathematica (some I've created). I find that functional only leads to logic trees that are a hairball because they get simultaneously deep and wide, and the mental map gets tough to hold in the brain's cache. Spaghetti code in functional languages is 1. Easier to produce and 2. An order of magnitude worse.

Re:Moderate usage okay

[west]

I have a usage pattern where I end up pairing them with enums and it simplifies so many things (e.g. You practically never need a switch statement ever again).

Care to share the pattern (or a reference)? I googled a bit, but there didn't seem to be one stand-out pattern and I'm quite curious (if you have the time)

Thanks.

Re: Moderate usage okay

[Anonymous Coward]

I'm zonking out right now, but I'll try to pull something together in the morning. I haven't seen this pattern around...It wouldn't be in the gang of four book...it's something that's evolved as I've been using the new functional specs.

I work with a masters in cs guy who is pretty particular about designs, and he thought it was pretty interesting.

Re:Moderate usage okay

[lgw]

Just guessing what AC means, but assuming he's talking about Java, enum's in Java can take arbitrary values (they're just instances of a class, and so can have as much state as you'd like, including lambdas). It lets you do the equivalent of creating an interface with one method, and a class that implements that one method specifically for each enum, without all that clutter and boilerplate. But it's a bit hacky, and best kept to small, self-evident lambdas. Java-style enums, aka "class enums", let you avoid a lot of switching in general, since often you were just getting some constant value associated with each enum value.

Re: Lots of claims are being made about it's virtu

[Anonymous Coward]

Misusing human language doesn't produce a syntax error, nor does it usually even result in a "bug" (misunderstanding), so speakers/writers are much less likely to learn from mistakes.

What is functional programming?

[corporate zombie]

Wow. Really?

Functional programming.

1. Prefer non-mutable data. No more action at a distance bugs. Hand off a reference to your data structure and don't have to care. Replay any data transform at any point as a unique structure.
2. Prefer a defined and well known API often involving transforms that take a function as an argument to provide the predicate (e.g., filter), transform (e.g., map), aggregation (e.g., foldLeft/Right), or whatever building block.
3. Prefer data structures that you can reason about based on a well-known set of patterns. (Best quote ever: "You say `patterns' and everyone is warm and fuzzy. You say `monad' and every loses their f-ing minds.)

Given (2) in a language you'll often see in a language that functions are first-class data.

Functional programming is just (a set of) best-practices. It's scary when the big words are new. Once you use it a bit you'll wonder why when you say, "use a flatMap", folks freak out because all you've said is, "You are transforming the elements of some container into values that are themselves an instance of the same container but you want to flatten everything back from nested containers. [E.g., Container is C with element type A; thus C[A]. You've run a transform that will create C[C[A]] but want to end up with C[A] at the end]." Now you could say that second part but that's a lot of words. Because of points (2) and (3) above we just say, "use a flatMap" (or however you spell `bind` in your language of choice).

Nothing to see here. Please move along. (And yes. I like functional programming. A lot.)

Re:What is functional programming?

[mikaere]

I'm a C# and BI developer I was paid to learn Clojure (a LISP) for a cloud-based contact centre platform project. I really liked it, but it did take me a while to get my head around the different patterns

If you have a problem that can be solved using functional programming (e.g. operating on sets of data) then it can be a good choice. For example, I reckon it would be extremely useful in a business intelligence transformation layer.

Re:What is functional programming?

[Anonymous Coward]

Turing already proved that everything is an operation on a set of data. That includes BI.

Drink the "kOOl-aid"

[michael.karl.coleman]

Not sure whether that was an intended pun or not, but I'm using it...

I like functional aspects not functional languages

[brian.stinar]

I got my master's degree with this guy, and I had to take a Haskell course, or seminar, every semester. I was, and still am, pretty terrible at Haskell.

However, what I attempted to learn helped my Python out a lot. Map and filter are two of my favorites, and the other functional paradigms are occasionally useful to me as an actually working, productive, programmer. I'm happy I was exposed to those concepts, since they tend to come in handy. Yes, everything is Turing complete, and you can accomplish the same things without functional programming, or without high level language, or without computers, but that doesn't mean they are all equally useful to solving the problem at hand.

I recommend everyone become familiar with functional concepts in some way, if only to make them more well rounded. I don't advocate writing your next web application in Haskell though...

Perspective

[Anonymous Coward]

I think functional programming is the enemy of the state.

Re: Perspective

[Anonymous Coward]

Parent should have been first post!

Should be in everyone's toolbox

[Anonymous Coward]

I think the conversation gets confused by failure to differentiate purely functional programming from incorporating elements of functional programming into an OO or procedural language. Functional programming is extremely useful for certain types of operations, like event handlers, tree traversal and row operations. It can also make code a lot more concise and readable since you don't have to create separate classes to implement the logic for things like Visitors. However, like any paradigm, there are classes of problem that it is less well suited to, and trying to use a purely functional language (like LISP) can feel like pulling teeth with a hammer. I'm a big fan of the way C# has incorporated Lambda expressions to allow interspersing functional programming where it makes sense.

Sure, why not...

[ndykman]

It's a very useful way of thinking about certain problems and it is often simpler that a lot of pattern heavy code. Take something like a template method. With functional programming just provide the functions to the method or instance. It accomplishes the same thing without an explosion of subclasses.

There's a lot of other classic OO patterns that aren't needed or just done a lot more cleanly with higher order functions and other functional programming paradigms. It's also unfortunate that people assume functional programming is embodied in one language. Haskell is indeed a functional programming language (a highly opinionated one), but so is LISP and Scheme, which have completely different approaches.

And FP paradigms are more and more common. List comprehensions in Python are just bog standard adoptions of map and filter higher order functions from functional programming.

Has its uses.

[RedMage]

Not a panacea by any means. Sometimes it's harder to apply to general business programming in a meaningful and useful way - immutable objects aren't necessarily the best fit for data objects, to my mind anyway. Applied correctly and maybe less-than-completely the patterns and thinking from functional programming can be a good thing - but I'm not really a fan of pure functional programming and prefer the hybrid approaches like Scala.

Re:Has its uses.

[angel'o'sphere]

While you are right "immutable objects aren't necessarily the best fit for data objects", however they often are the simplest approach.

Just think about "rewriting" a single threaded application into a multithreaded one. It helps imensly to have a clear understanding which data is immutal and which is not.

FP is awesome

[CloudDrakken]

(operator arg1 arg2 arg3 arg4 arg5 ....) just makes a lot more sense, but it does take some deliberate training to grok in full. The basic for loop is now map, reduce, filter, etc. So there are some bits to know about when transitioning, but I think FP is great. Currently I use Clojure and appreciate the philosophy behind it just as much as the language and its elegance. LISP dialects tend to be beautiful, once the parens have settled into place...

The worst thing about function programming

[OrangeTide]

Are the people who won't stop talking about it.

Yes

[Intellectual Elitist]

Yes, I like functional programming. But like most other things, it depends on the problem you're trying to solve. If you mosty deal with nails, you'll want to use a hammer. If you mostly deal with screws, you'll want to use a screwdriver. Hammers make lousy screwdrivers and vice-versa.

Functional languages are great for highly parallelized computation because well-behaved functions don't have side effects, and that eliminates entire classes of race condition and locking issues. Functional languages are also good for abstracting higher-order patterns, since you can manipulate data and other functions without having to care about their lower-level details. Specific functional languages like Scheme, where code and data share the same form, are great for creating custom syntactic structures and writing self-modifying code.

If you aren't doing any of those types of things, then functional programming may seem pointless to you, and that's OK. But every developer should be aware of the tools available to them in case the day comes when they might benefit from using them.

Do I like Functional Programming?

[gawdonblue]

Sometimes, but just like Object-Oriented Programming it sucks when it's used as The One Paradigm To Rule Them All.

Preferences: Use OOP for GUI, and FSP (functional/structured programming) for services/backed. Use round pegs in round holes.

immutability and no global state

[dseleno]

You can do a functional style of programming in just about any language, but using a true functional language brings you some added benefits.

Immutable data and pure functions make reasoning about your application so much simpler because there is no external state. With the same input, your functions always produce the same output. Testing is easier, debugging is easier, designing is easier, refactoring is much easier.

Another way to think of functional languages vs procedural, is describing to a computer how data moves through your program vs telling a computer what to do step-by-step.

Re:Lots of claims are being made about it's virtue

[OneHundredAndTen]

A properly placed apostrophe has its virtues as well. it's means it is.

Or it has.

It's amazing that people that can learn dozens of languages all more complex than the previous can't seem to grasp the humble apostrophe.

I violently agree. The rule is very simple: If you mean "it is" or "it has" then you can write "it's". Otherwise, it is "its". Why so many out there seem to be unable to comprehend such a simple idea is something deserving of a study.

Java Lambdas

[Anonymous Coward]

I was excited for lambdas in Java 8. Pretty cool and powerful stuff. New syntax, new thinking. Then, reports started to pop up about how the lambda way was slower than the for (T t : List) way. I realize there is lot more to the functional programming than streams. But, I figure, if the simple stuff has performance problems, the rest of it probably does as well. I'll revisit it when it gets more mature and the performance is improved.

Functional is useful when not pure

[PhrostyMcByte]

The best functional programming to me, is the kind being integrated into various primarily procedural languages. I use it daily in C# at work, and find it invaluable in performing complex transformations on data. Python, C#, etc. have the best of both worlds -- the choice to use whatever is best for your situation.

I'll expand further, maybe to start an interesting conversation because I'm sure someone will disagree: purely- or mostly-functional languages are the original hype-driven languages. A lot of people say they're amazing, but don't actually do anything useful with them. Sure, some are making great apps with them, but they're clearly the exception. At the end of the day most of the people I've talked to who preach about how awesome their favorite functional language is have only gone skin-deep. Their experience is limited to the academic or experimental, and has never gone into the practical.

The few times I've tried to really master these languages, I've been left with no epiphanies. I've found it extremely useful for some problems, like data processing mentioned above. But for most everything else, it doesn't get me anything useful. On some level it is nice having the flow of immutability -- it "feels" right, like you've discovered something special. The same way adding an extra layer of abstraction on top of something might feel. But when I'd look back on it and ask myself what I gained from having it, there's really very little to be found. It is, mostly, a dogma.

Re:Functional is useful when not pure

[OzJimbob]

Yep. I like functional programming, but it's a tool. But then OO is just a tool as well. It's not suitable for everything, and attempting to apply OO principles to problems that don't really need them is just a waste of everyone's time, just as being forced into a functional pattern when it's not necessary is useless.

I'm mostly familiar with functional programming in R, where it's an extremely useful part of the language, but you don't have to use it. But once you get used to it, loops end up looking like ugly, clunky constructions when you could just apply a function of a vector. Once you're in this mind-space, going back to language that actually require you to nest loops to get anything done feels annoying as hell.

There is no "The Only Way"

[davidwr]

But it should not be The Only Way to approach a program - unless you are Truly One with the Tao.

Unless you are a total newbie who has only been exposed ot one tool, or a hypothentical/mytical code-master-of-all-code-masters who is "Truly One with the Tao," then you know there is no "Only [one reasonable] Way" to approach a program/problem, at least not one of any reasonable complexity.

Re:There is no "The Only Way"

[lucm]

there is no "Only [one reasonable] Way" to approach a program/problem, at least not one of any reasonable complexity.

One day maybe you will think differently. After all, "what is appropriate for the Master is not appropriate for the novice."

Re:There is no "The Only Way"

[micahraleigh]

"Appropriate" is a glossy disguise for mediocrity.

Inside the box

[Anonymous Coward]

Functional programming has its place when decomposing a software architecture.

When interfaces penetrate deeply, pure functional implementations can be problematic due to the burden of carrying external state for inner functions that otherwise don't have access. F(a,b,c) -> f(a,b)->f(a) etc. if, later, another input d is added, pretty good chance that d is going to be needed somewhere it can't be found.

once data has permeated a low enough level of logical decomposition, functional approaches can drive clarity. If a slice of architecture doesn't decompose any deeper--might as well go functional.

For amateurs only

[Anonymous Coward]

Can be fun as a weekend hobby.

It is great, just don't make a religion out of it

[jma05]

All programming paradigms have useful abstractions to offer. Eventually, they will all come together. Object orientation is great, until one overdoes it in design pattern hell. Likewise with functional programming. There are great many ideas in academic programming languages that will be made more accessible and integrated into mainstream programming languages. Functional programming is a dead end only in the sense SmallTalk was a dead end. People may not use SmallTalk much today, but its ideas live on in nearly every language we use today. Functional programming is here to stay. It won't replace imperative and object-oriented programming, but will add to them.

First and foremost, programming languages are for people, not computers. So if regular programmers who form the bulk of the workforce can't grok them, the languages need to be fixed, not people. Haskell is too hard for most. But it has many wonderful ideas that can be distilled into simpler forms and adopted and integrated elsewhere. Python got list comprehensions from it and perhaps the indentation.

C# is absorbing some features and Java is doing that less elegantly. Scala is a good balance and has already established itself. But people still find the type system complicated. So there are attempts to bring forth a simpler Scala - Kotlin, Ceylon etc.

We all agree that things like compact syntax, first order functions, lambdas, streams, type inference etc that functional languages pioneered, belong in every language. We still haven't sorted out how to make more advanced type systems, provability, strict programming without side effects etc more approachable. We should not need to have this much trouble explaining what a monad is or isn't. We'll get there, eventually.

Re:Lots of claims are being made about it's virtue

[davidwr]

The rule is very simple: If you mean "it is" or "it has" then you can write "it's". Otherwise, it is "its".

Unless you are using the word out of context: There are too many it's in this discussion, don't you think?

Performance .... anyone?

[thesjaakspoiler]

If a programming language is functional by design I can image that it will also be optimized as part of the development. But does anyone know what happens if functional programming concepts are added to a non-functional language? Is there also any performance merit besides enjoying the merits of functional languages as a user? Or does it have performance implications due to the non-functional nature of the language?

Re:Performance .... anyone?

[jbolden]

The results are usually either trivial or dangerous.

To pick two examples. Perl has had a map for many years which is just syntactic sugar for the foreach construct. On the dangerous side we have the new optional monad (Java's name for the Maybe Monad). You can use it trivially like this

Optional person = personMap.get("Name");
if (person.isPresent()) {
    Optional address = person.getAddress();
    if (address.isPresent()) {
        Optiona city = address.getCity();
        if (city.isPresent()) {
            process(city)
        }
    }
}

On the other hand if you try and use it the way Maybe/Optional is really intended things blow up badly. The API aren't retrofitted to lift into the monad the way they should. So code will execute in sequence unless you catch exception in which case you are back to explicit exception catching. The primitives don't lift (there isn't optional int, optional char...), so methods don't lift smoothly ...

Essentially the less purity the less you can pull across non trivially. You can mix in some impurities (LISP) if you assume developers are very aware of theory.

So what ends up coming across are some nifty syntax from functional languages and a few minor features.

No

[Anonymous Coward]

I prefer non-functional software.

I couldn't get past "how do you write a game"?

[Jeremi]

When I was learning about functional programming in college, I got about as far as learning about the avoidance of side effects, at which point I started asking myself, "how would one write a video game in an FP language if you're not supposed to e.g. update the player's on-screen position in response to a keystroke"? The answer I got was to either generate an entire new game-state for each update (which seemed unwieldy), or work around the problem using monads, which admittedly I never really understood. I went back to procedural programming since that looked like the more straightforward way to implement the kinds of programs I wanted to write.

My question now is, do people ever actually write video games using functional programming? And if so, how would an FP-based arcade-style video game realistically handle things like updating the state of the player and the monsters at 60fps, as the game progresses?

Re: I couldn't get past "how do you write a game"?

[tigersha]

You just sketched the worst-case for FP, true. FP is bad for that scenario.

But it is better at modelling the small state transitions in the objects themselves

Re: I couldn't get past "how do you write a game"?

[Anonymous Coward]

All cases are worst-case for functional programming. It's a retarded paradigm that gives turbo-nerd techno-weenies something to jerk off to and feel better about themselves over. You say "modeling the small state transitions blah blah" and I say "I just want the goddamn program to work." I don't give two shits about modeling object transitions or anything else. I want to write a series of directions for my computer to perform a task: "get input, check input, take actions based on input and current program state." There is no need for all this extra complexity and "elegance." Learn C. Never look back. If C is too hard, it should probably just be a shell script.

Re:I couldn't get past "how do you write a game"?

[phantomfive]

I would do it by making a function something like, newGameStateScreen() which is a function of the old screen, and the current state (maybe even the old state). That part is fine enough.

Then I would cheat and optimize it to actually update in place. Conceptually it would still be functional, but every useful functional program ever written mutates state.

But if you have FP, then you have repeatability. Given a particular game state, combined with a given input, you can know what the next game state will be, every time. It's testable, provable, and helps you make sure that every possibility is covered.

Re:I couldn't get past "how do you write a game"?

[jbolden]

Functional reactive programming came out of the functional community. Assume you had an array of all the inputs the end user entered for a game that already happened. Then the engine can create an array of all the corresponding outputs. That's your engine. Now wrap the construction of those two arrays in a stateful monad (IO).

This book ( https://www.amazon.com/Haskell... ) is out of date but it will teach the ideas well. You'll create a video game and a music player.

In general though, no video games don't generally get written in functional languages they are too messy and stateful. Video game engines though can easily be written in functional languages.

Re:I couldn't get past "how do you write a game"?

[Dutch Gun]

As a professional videogame programmer, I can assure you that I haven't heard functional programming discussed much at work or among other peers in the industry. Videogames are giant, data-intense state machines, with lots and lots of state to track and manage. My feeling is that it's really not a great fit for functional programming. Traditional object-oriented programming is *heavily* used (C++ is the defacto industry standard language), because that's a reasonable and proven way to encapsulate complex, independently-operating entities into well-behaved packages of data + code.

It's the same reason that the industry doesn't extensively use unit testing for engines and game code (not broadly at least), which may surprise some programmers in other fields. The reason is simple: many game engine tasks can't be boiled down into simple algorithmic data transformations that can be checked and verified by a simple function. For instance, how would one write a unit test to ensure audio is playing correctly, or a graphic shader is working as intended, or a physics engine "looks" correct in realtime interactions? It's not really practical. Thus, videogames tend to rely on integration tests using QA team members to spot anomalies.

In short, not every programming paradigm can be effectively applied to every problem. That's not to say you *couldn't* write a game purely in a functional language, of course. I just don't think you'd be working to FP strengths.

Re:I couldn't get past "how do you write a game"?

[Anonymous Coward]

As a professional videogame programmer, I can assure you that I haven't heard functional programming discussed much at work or among other peers in the industry.

That's not to say that there hasn't been discussion at all though, see Tim Sweeney's talk "The Next Mainstream Programming Language: A Game Developer's Perspective" or John Carmack's views about Haskell.

Re:I couldn't get past "how do you write a game"?

[Anonymous Coward]

Psst. don tell that to the FP guys, they currently propose that fp fixes everything. Btw. you hit it right on the head, fp is great for certain data transformations and some multithreading situations and generally where statefulness is low. It falls shot if applied to bigger systems due to the lack of organisational paradigms (cough namespaces who needs them) and where there is a lot of state due to the state duplication which comes automatically with the sideeffect free paradigm.
In the end it is a good tool for certain things, but definitely not a hammer which can beat everything.

Re: I couldn't get past "how do you write a game"?

[Anonymous Coward]

The idea is to seperate purely functional code from code that needs states. I/O, by definition, need states. Efficient data structures also need mutability. Most of the remaining stuff does not need either, but we tend to use states and mutations for everything anyway. Functional composition is a powerful tool, even without first class functions. FP is useful, if understanding it helps you to get rid of unneeded states in any code, and using composition of functions when designing your program, in any language.
FP with something like Haskell is really cumbersome if your code has higher proportion of manipulating state code than actually doing computation (rarely the case) or that your computation requires mutability for performance (usually the case.)

Re:I couldn't get past "how do you write a game"?

[Gorobei]

Well, you could read Anthony Courtney's Yampa Arcade paper: it describes the implementation of an arcade game in a functional system.

Re:I couldn't get past "how do you write a game"?

[Anonymous Coward]

Jesus Christ.

If it takes a academic paper to figure out how to write a video game (that could be implemented in ASM with an 8-bit processor) in a functional language, it is a useless tool.

The whole reason I program is to get side effects. Press button, receive bacon.

Re:I couldn't get past "how do you write a game"?

[zifn4b]

As a professional videogame programmer, I can assure you that I haven't heard functional programming discussed much at work or among other peers in the industry. Videogames are giant, data-intense state machines, with lots and lots of state to track and manage. My feeling is that it's really not a great fit for functional programming.

This is complete nonsense. It doesn't have to be ALL object oriented programming or functional programming. First of all, Mr. high and mighty C++ programmer, have you heard of Boost? Boost has some functional programming semantics and they are quite useful. C++11 even has freaking lambdas now! Or perhaps you've heard of lodash that can be used in conjunction with nodeJS or javascript. C# has functional programming syntax using lambdas. Geesh, this isn't a contest for the one programming language/style to rule them all anymore. If you still think that, it's probably time for you to retire.

Re:I couldn't get past "how do you write a game"?

[ripvlan]

Microsoft created a game on XBox using F#. So it is possible. There's an F# compatible release of XNA. I can't remember the game - maybe "Go" ?

Hunt in DotNetRocks for the topic - there have been multiple episodes over the years discussing this. Google "XBox F#" - there's a slideshare on the topic.

Re:I couldn't get past "how do you write a game"?

[Anonymous Coward]

C#, and C++ before it, have had the ability to do functional programming (with enforcement of the no-side-effects rule!) by way of static functions (global or member, either one) for a long-ass time now. Functional programming is not new. It's also not something anyone without a sado-masochistic streak wants to use to the exclusion of other techniques.

Re:I couldn't get past "how do you write a game"?

[Anonymous Coward]

You can do unit tests but they are PITA - e.g. compare shader rendering with a pre-recorded video and setting a hot-pixel threshold, using external mics to record audio etc. It's doable but annoying, so nobody does it.

Re:I couldn't get past "how do you write a game"?

[Anonymous Coward]

Don't confound state changes with side effects. You can do state changes in functional programming; it's just that you need to know when you're doing then.

Re:I couldn't get past "how do you write a game"?

[Anonymous Coward]

Video games with FP? John Carmack wrote an article on what he thinks about FP. He started to use Haskell and he wrote a FPS for that. He updates the entire world, more or less. Google for his article. Very interestoing

I don't get it

[Anonymous Coward]

C was a functional programming language and it was a heck more readable than what today's kids call Functional Programming. Monads, Lambdas and various transformation functions are nice for people who like buzzwords but frankly their readability does not scale. As soon as I see code that chains more than 2-3 functions/transformers the code becomes totally unreadable.

And this is coming from someone who coded in C for years before delving into object-oriented programming languages. It seems that today's kids came more about buzzwords and drinking the cool-aid than seriously evaluating which code is more readability and easier to debug.

Crap code is crap code. It doesn't matter whether it uses OOP or functional programming, it'll suck. But please stop using inheritance as a stray-man argument against OOP. OOP is about a lot more than inheritance. We have this thing called composition, not to mention encapsulation, grouping cohesive functionality, etc.

Functional programming has its place, but anyone who is advocating migrating the majority of the codebase to that paradigm clearly has never had to maintain a large codebase. It doesn't scale from a conceptual perspective.

Re:It is great, just don't make a religion out of

[Pseudonym]

So if regular programmers who form the bulk of the workforce can't grok them, the languages need to be fixed, not people.

I know what you're saying, but there's a real danger here that the industry will find itself caught in a local extremum. An engineer of 1880 could easily have said that if regular engineers who form the bulk of the workforce can't understand this "electricity", then it needs to be fixed to conform to the world of steam.

The worst thing we can do as an industry is think we know what we're doing. And in a sense, we're already there.

you mean like lambda calculus, sonny?

[retiarius]

emil post's rewriting systems were tres reserche, too.
and mccarthy's "lots of tiny parentheses", as well.

Perl

[Anonymous Coward]

Yay! I knew Perl would become fashionable again !!!

Functional programming is trendy hipster garbage

[Anonymous Coward]

Functional programming has no real value. What's the most important part about programming? Giving a machine a series of instructions within a reasonable time frame and with a reasonable degree of correctness for accomplishing a specific task. Functional programming is often referred to by its proponents with platitudes regarding its "beauty" and "elegance," but as much as we'd like to pretend otherwise...programming is not art. It takes too long to write "functional" code. It is difficult to understand and modify, especially for people who are not deeply entrenched in the paradigm already. It is more difficult to understand.

Programming is about translating what you want a computer to do into a set of instructions that the computer understands that mean the same thing. The harder you make it to understand and properly use the computer's language, the less likely you'll translate your intent into a working set of instructions. Functional programming makes things difficult well beyond what other paradigms do. Masturbating over your functional programming skills and creations is the programming equivalent of wine snobbery. You're not a better coder and you're not doing anything valuable. You're just a fucking hipster programmer and your paradigm is shit. Get over it.

Re: It is great, just don't make a religion out of

[Anonymous Coward]

Fortunately, there is a sort of solution evolution going on, so don't worry it will all work out

Didn't Like It At First

[Philotomy]

I didn't like functional programming at first, but after using it for a while I started seeing the benefits of things like first class functions and immutable state. Even if you don't think functional programming is a silver bullet, it's worth learning and understanding how the functional approach differs in solving programming problems. Adding another way to think about programming problems to your arsenal isn't a bad thing.

Functional Programming Considered Harmful

[doom]

I tried a websearch the other day on "functional programming considered harmful" and found remarkably few hits. If anyone is so inspired, there's an opportunity there to gain some fame while earning the emnity of the hordes of javascript kids and half of the Computer Science digirati.

Re:Functional Programming Considered Harmful

[dgatwood]

It needs to be done and done well. Very tempting. But alas, just like drug use, there's only so much any sane person can write about the subject, because anyone who knows functional programming well enough to fully explain why it is harmful is probably mentally damaged beyond the point of being able to understand why it is harmful. :-D

The thing is, functional programming is a good paradigm for students to be exposed to in school. Briefly. It forces you to think about data flow through your program, and forces you to think about your software as a giant state machine and visualize how the states change as your software does work. It is not the only way to teach that concept, but it is a halfway decent way. And once you pick up those concepts, you'll start to understand why singletons are so useful (approximately the polar opposite of functional programming, but often the software equivalent of the data you'd be passing around in a functional world).

So basically, there's a time and a place for everything, and it's called college. But just like with drugs, if you continue to do significant amounts of functional programming after that, don't be surprised if the rest of us ask what you're smoking. Functional programming as a real-world paradigm tends to be almost invariably a disaster, because it neither fits the way we think about problems (human thinking is almost entirely procedural) nor the way machines do work (computers are inherently procedural). It can provide useful extensions to procedural programming languages that serve specific purposes (e.g. closures), but calling functional programming useful for that reason is akin to calling a diesel-electric freight train a perfect commuter car that saves fuel because a Prius is also hybrid hydrocarbon-electric.

About the only space where functional programming techniques might really make sense is when working in a massively multithreaded environment, e.g. creating really efficient implementations of certain massively parallelizable functions (such as FFTs). But for the most part, that functional programming is limited to creating components that are then utilized as small (but performance-critical) parts in what is otherwise on the whole still procedural (or OO) software.

Outside of those very limited scopes, though, the theoretically ivory-tower-pure, zero-side-effect functional programming model is pure garbage. Real world systems don't just have side effects; they are side effects, whether you're talking about storing data on disk, sending it over a wire, drawing it on the screen, reading data from a keyboard, or whatever. The notion of treating all of those "side effects" as some giant state object that mutates as it gets passed around is fundamentally antithetical to real-world use of the data, because state must be stored to be useful. And the entire notion of passing around the complete state of real-world software is so far beyond infeasible that the concept is utterly laughable. Cell phones have a gigabyte of RAM, not a petabyte. There's simply no way to write something like MS Word in a pure functional language, because it would take all the computing resources on the planet to barely run a single instance of it.

Using functional programming in most real-world environments, then, cannot possibly do anything but cause brain damage, because the whole functional paradigm is wrong for the problem space. It is like cutting the grass on a football field using only a single pair of nail clippers—theoretically possible, but completely infeasible. To that end, although I wouldn't say that functional programming is inherently considered harmful, it should be approached with approximately the same level of skepticism as goto statements, and for approximately the same reason. When used correctly, in a very limited way, it is a powerful tool to have in your toolbox that can seriously improve your software. When overused or misused, it is a black hole that consumes infinite amounts of programmer time while emitting very little.

Re:Functional Programming Considered Harmful

[Anonymous Coward]

Well said.

Re:Functional Programming Considered Harmful

[Anonymous Coward]

The aspect of your comment that I agree with is "it is a powerful tool to have in your toolbox that can seriously improve your software."

Like all powerful tools, it is possible to do some bad things with it, or to take the paradigm to the extreme.

But this is equally true of imperative languages, like C: There are are some aspects of C that are good, e.g. it is deceptively simple. But then there are also many aspects of C that are truly terrible, and have inflicted a heavy overhead to software engineers and humanity in general. The language is designed to give the programmer great (too much?) power, but I would guess that 95% of developers writing code in C will end up accidentally writing code this is insecure because C makes it so very very hard and laborious to write code that is secure.

To me, functional programming is really about expressing the problem that you are trying to solve in a simple and safe way. To that end, I somewhat despair when I have to write code without all of the really useful functional tools that are available in some languages.

Sure, you pay a small memory and performance overhead of a functional style. But until recently Hadoop/Spark had the record for sorting 100TB of data. Spark is written in Scala, a functional language, and happened to be 30 times more efficient that the Java based MapReduce engine that it was replacing (3 times faster using a 10th of the computing resources).

So, there is a reason why you are seeing more support for functional constructs (like closures) in fairly mainstream modern languages (C#, C++, Python, Swift, Javascript, Go, Scala, Rust). It is because it allows developers to write better code.

My advice to developers around the world, is to learn functional techniques and apply them whenever you can. It will make you better developers, and very likely improve the quality and security of software everywhere.

[As someone who is very experienced in writing C]

Re:Functional Programming Considered Harmful

[Algan]

Funny, I've been using functional languages for the past 10 years to put out successful commercial products and didn't even know it was supposed to be impossible. Now I am afraid I must be brain damaged.... or smoking some very good shit.

Re:Functional Programming Considered Harmful

[Anonymous Coward]

This is true for a lot of languages that other put off as being impractical, etc. It is not so much that the languages are useless but rather they are useless when used by those that do not understand them or have not learned enough to make them practical.

Re:Functional Programming Considered Harmful

[jbolden]

What you are describing is not remotely how state is handled in functional languages today. What's done is there is a stateful monad (either State, Read, Writer, IO or State&IO) which allows for an imperative style language. That imperative language handles stateful objects and makes function calls to an engine. The engine is stateless. No one is passing around the entire state of the world.

Here is a classic paper from a quarter century ago that summarizes this approach: https://www.microsoft.com/en-u...

Re:Functional Programming Considered Harmful

[Anonymous Coward]

You have succeeded in spite of functional programming, not because of it. Just because you can build a house using screwdriver handles as hammers doesn't mean that your use of a more difficult and unsuited banging device was somehow a good thing.

Re:Functional Programming Considered Harmful

[Tablizer]

I tried a websearch the other day on "functional programming considered harmful" and found remarkably few hits...

That's old-school. Try searching "Functional Programming Sucks". Most won't know about the "considered harmful" reference when issuing criticism.

(By the way, they never objectively proved goto's are "harmful". Their model is merely an assumption about how human programmer brains work. I don't necessarily entirely disagree with the model, but it's never been scientifically validated.)

I've had heated debates at the c2.com wiki (now half-defunct) with FP fanboys. I will agree there may be legitimate niches, but the value of it is greatly over-hyped as a general-purpose technique. As I've stated elsewhere in this topic, most "realistic" examples are a result of comparisons to bad API's and/or languages. They are often defending FP against strawmen.

Re:Functional Programming Considered Harmful

[Tablizer]

I've been using functional languages for the past 10 years to put out successful commercial products and didn't even know it was supposed to be [problematic as described]

The real test is when you leave that company and somebody else has to read and maintain your code.

If I wrote my code using just my favorite paradigms and techniques, it would probably kill the future maintainer.

Re:Functional Programming Considered Harmful

[doom]

... it's never been scientifically validated

Wait. You don't expect a Computer Scientist to get experimental results, do you? What do you think they are, scientists?

Re:Functional Programming Considered Harmful

[Tablizer]

"Computer Science" is indeed not really computer science. It's math + speculation. It should be renamed to "computology": the study of computers and computations.

Re:Functional Programming Considered Harmful

[Anonymous Coward]

Functional Programming killed my poodle, you insensitive clod! Tail recursion turned the poor thing inside-out.

Re: Functional Programming Considered Harmful

[Anonymous Coward]

Not really.

Re:Functional Programming Considered Harmful

[doom]

They're not really up to the Computology level yet, they should start out with Computonetics.

Re:Functional Programming Considered Harmful

[Tablizer]

If you work on Chevies when everyone else is working on Fords, then you may have difficulty finding mechanics for your customized Chevies. I've yet to see evidence FP is objectively "better" in enough circumstances and niches to justify narrowing staffing options except for certain specialties. (I've complained about lack of practical demonstrations elsewhere on this story.)

overrated shit

[Anonymous Coward]

and half the h1b tier retards think u mean procedural when u talkin about it...

Its fantastic for principles

[jbolden]

The functional languages are often about 2 decades ahead of the imperative languages in terms of features and ideas. Truly powerful type systems, purity, laziness, infinite data structures. They really do change the way you think about design. Engines (controllers for MVC) are excellent in those languages. They are also very good for protyping non-vonNeumann architectures (like Hadoop code) unlike the Algol based languages.

They have their own problems like a tendency for slightly less than optimal algorithms to be quadratic in memory.

ML - it just worked!

[Flu]

The only time I've tried functional programming was during a class at the Uni. My memory from that class, was that when I finally got a progam through the compiler, it simply worked. No flaws or bugs at all. Of course, a single class doesn't make me qualified to neither promote nor dismiss it. Having said that, I prefer Python for simple PC-based tasks, C (or the non-obscure parts of C++ if the resources permits) for my daily work as embedded designer on ARM Cortex-M and smaller MCU's.

Re:ML - it just worked!

[elfprince13]

Seriously, I've written multihundred LoC Scala programs at a go before, and when they compiled, they worked (and I was typing them in Scala IDE, so they compiled as soon as I was done typing, because it does the type-checking in real time). It's almost disappointing when you think of a lot of clever error messages for bugs that never materialize.

You already know the answer: monads

[Anonymous Coward]

If you want to take the easy lessons from FP, use immutable data structures and pure functions whenever you can. That in itself is enough to lift your code quality.

If you want to know why the cool kids are doing FP, learn what a monad is. FP is truly different to other coding. It changes your whole world view. But to gain anything from it, you have to know what terms like monad (and functor and applicative and ...) mean.

If you know FP and choose not to use it, then fine. I know it's not the sort of thing everyone likes to use.

And back to your game, you write all your game effects within a monad. That won't make any sense as an answer until you understand, say, the Haskell IO monad. And even then you might say "No thanks" but at least at that point you'll know what you are giving up. I think perhaps you missed the point of your FP lessons.

I don't know of anyone writing serious games in Haskell, but there's no reason it can't be done. Functional doesn't have to be slow, though it's easy to be accidentally slow, or slow because "purity is more important than speed".

The Haskell people are all over this already

[Anonymous Coward]

https://wiki.haskell.org/Game_Development

Re:Functional programming is trendy hipster garbag

[brantondaveperson]

Programming is about translating what you want a computer to do into a set of instructions that the computer understands that mean the same thing.

That is half of what programming is, at most. The other half is, at least, making that set of instructions easily understandable by another human being. Your code will be read thousands more times than it is written, and readability is far more important than your statement suggests.

Most Things Have Their Place

[NicknameUnavailable]

Anyone who is all for functional, OO, actor-model, etc programming is incompetent. Different paradigms work in different scenarios and being a good programmer is mostly about knowing what to use when/where.

Re:Lots of claims are being made about it's virtue

[dgatwood]

For that to be even ostensibly correct, you're missing one single quote mark and some double quotes, e.g.

"There are to many 'it's, don't you think?" he said.

And even that is arguable, because those aren't really apostrophes; they just happen to use the same key on the keyboard, typically.

With only two exceptions, the plural of any word is always spelled with an 's', not an apostrophe followed by an s. The exceptions are:

• The plural of a lowercase letter (e.g. there are too many i's here).
• The plural of an abbreviation that contains periods or mixed case (e.g. there are too many Ph.D.'s here).

And even then, those exceptions might depend on what style guide you go by.

Lern too reed!

[Anonymous Coward]

If the haskel community want haskel to popular they should make an better effort to make it more understandable

You had to read that twice?! "To [be] popular" didn't automatically parse for you? As far as "an better effort" is concerned: clearly the author had second thoughts and realised they ought to acknowledge that at least some effort was being made (hence the insertion of the adjective which rendered the article inappropriate).

Clipper (no, not the chip)

[chthon]

My first encounter with both OO and functional programming was Clipper 5.0, the dBase compiler. It incorporated parts of OO and parts of functional programming, lambdas actually, called code blocks. Both have their uses.

Scala and Scala.js

[trenobus]

I started using Scala in 2011. The tooling was very rough at first, but I really liked the language as an alternative to Java. Since then I've adopted a progressively more functional style in Scala, and found it to be a very natural way to think about code. Some of my code is multi-threaded, and using immutable data structures, I find I spend a lot less time worrying about locking. And the tooling is now fairly reasonable in my opinion. Scala's interoperability with Java was a big selling point in the early days, but the Scala ecosystem is now getting to the point where it stands on its own rather well.

A really great development in the Scala world is Scala.js, which transpiles Scala to JavaScript. I despise JavaScript for any development larger than a page of code, so Scala.js was a welcome relief. If you work on large JavaScript apps, do yourself a favor and check out Scala.js. I look forward to the day when WebAssembly matures enough to be a target for Scala compilation. Hopefully then JavaScript will fade away, and someday it will just seem like a bad dream.

Re:Scala and Scala.js

[Philotomy]

Thanks for the info about Scala.js; I wasn't up-to-speed on that. I tried out Scala around the same time you started (i.e., 2011), and was impressed (Scala provided my introduction to functional programming concepts). Unfortunately, I never had the opportunity to use Scala, much, and I lost track of what is going on with it. These days I'm working with a lot more JavaScript. I don't mind it (it's not bad if you use ES2015/Babel and avoid iffy parts of the language), but it can be pain on larger team projects with developers of mixed experience with JavaScript. Anyway, the Scala.js project sounds like it's something I'd like to check out.

Realistic examples missing

[Tablizer]

I've yet to see realistic examples of improvements, at least for domains I work in. Those pushing FP either invent contrived "lab toy" circumstances where FP shines, use vague buzzwords that don't describe any concrete benefit, or merely expose the weakness of a particular language or API design (such as Java's poor OOP model).

If you want to convince people, show them realistic examples and explain the benefits in concrete and measurable terms. Is that asking too much?

They may say, "If you use it long enough, you'll finally get it"; but there are so many tools and ideas competing for our time that I'll have to ask for more up-front evidence, if you don't mind.

Re:Realistic examples missing

[yes-but-no]

A seed planted yields fruit after a few months/years; it needs to be watered and cared for until it grows to that big tree. There are certain things in existence that can't be shown; you have to do it to see it happen to you. If someone hesitates to walk the path because of a lack of proof likely will miss a lot. As Morpheus says, there is a difference between knowing the path and walking the path. It's a about taking a leap of faith; not based on logic.

Re:Realistic examples missing

[Tablizer]

Assuming that's true, there are 50 or so "great ideas" on my desk. I don't have time to try them all for an extended period of time. Why should I assume FP is more fruitful than the others?

There are certain things in existence that can't be shown

Bullshit! When I found benefits in something I was able to articulate and show realistic examples. Some of it turned out to be purely personal preference, but I say so if that's the case. My eyes and brain prefer certain things organized a certain way that doesn't always match other brains/eyes.

If it cannot be shown objectively, something is probably wrong on the claimer's side. Sorry, I find "can't explain" an anti-scientific copout. You should study benefit articulation over a long period until you finally "get it". Touche!

Re:Realistic examples missing

[jbolden]

The problem domains it shines in are niche: data parallelism, GPU programming, compiler construction. Those fields are dominated by functional languages.

Re:Realistic examples missing

[Tablizer]

Regarding data parallelism: most rank-and-file big-scale data chomping is expected to be done by the database. For example, if you request "ORDER BY" in an SQL query, the database engine may indeed use parallelism under the hood to sort. But that's typically not a concern of the app developer or query writer. The DB engine builder worries about that. (It does help to know a bit about parallelism when considering query performance profiles.)

Functional programming has its purpose

[prefec2]

It is helpful in context of walking data model trees in OO languages. It also allows to write stateless code which supports parallelism. It helps with reactive systems including UIs and PLCs. It also sucks in some high performance areas. When people think Optional is a good idea to avoid if then else as code construct and replace it by function calls.

Re: I couldn't get past "how do you write a game"

[Anonymous Coward]

Exactly this.

FP does not solve the problems Imperative Programming has. FP uses entirely different and much less efficient algorithms than IP, and thus the two aren't even comparable.

FP will be worthwhile when an important video game has been programmed in it. Until then, it is worth the effoet.

The only valid paradigm:

[Anonymous Coward]

"You shall program the way I do, dammit"

Makes you think of data design more

[yes-but-no]

In my experience FP style (in python), makes me spend lot more time in the design phase. The emphasis is on data/data-structure more than the code/algorithm/operations [the spotlight of imperative languages]. You start thinking more about how your data gets transformed from input to output. I felt this way of separating data representation from the code/operation lead to more robust code; also much faster implementation phase. FP surely changes the way you think at a higher plane of the problem at hand.

No true paradigm

[Anonymous Coward]

Although I like it, and I incorporate functional ideas into my non-FP code, I can't see it ever being my primary paradigm (but then, same for OO or imperative). I started looking at FP because of the supposed advantages for writing safe concurrent code, but realised that it's all a bit smoke-and-mirrors. Sure, there are considerable advantages with immutable state, but the real world doesn't quite work that way and so you end up with things like "we'll just copy this data structure with some items changed" and now you potentially have different threads/processes using different versions of the data.

I'd be interested to see research on how non-programmers compare between learning a functional language and a non-functional one, given functional languages are closer to how people think mathematically ("x = x + 1... huh?")

Two ideas

[Boronx]

I have found two ideas that came from Lisp that are invaluable.

Minimize side effects in most functions. Any effort to reduce side effects will be repaid tenfold the next time you have to fix a bug or add a feature.

Keep data objects immutable. This is the key to the easy life if you have to do concurrent programming (and who doesn't these days?).

I like functional programming

[Anonymous Coward]

As the subject says, I've always enjoyed functional programming, but it isn't a magical solution for every problem a programmer can have.

A language will not make you a better programmer, ever, not a functional language nor an OOP one, or any other language type for that matter. Sure, there are tools that are helpful, but as a programmer it's about choosing the right tools for the job and how you think about problems and solve them.

A crap programmer will write crap code in any language. Hell, even a really good programmer writes crap code now and then, even in what's considered "the best language" at the moment.

I'm learning Scala - sort of half / half

[Anonymous Coward]

Scala seems to be functional programming + objects. It may not suit the functional programming purists, but it's a useful step, and lets me write some functional programming components for an application written mostly in Java, but running on Spark.

May well be a step towards functional programming, or it may be all the functional programming I need for now.

it's just another....

[SuperDre]

It's just another framework we've had for ages..
I see it with so many languages, all they do is add functions we already created in the past as standard options. It's really nothing new..
A problem with a lot of newer frameworks, is that a developer doesn't have any idea anymore as how it actually works underneath, so if something doesn't work they can't figure out why as they don't have the understanding (doesn't mean you have to know all the ins and outs).
Problem these days is, there are sooooo many frameworks, and everytime a new framework pops up it'll be a favorite for a while and then we all have to move over to the next new hip framework even if it doesn't actually add anything new to the previous one.

Only 5 lines of code

[Anonymous Coward]

I love it how functional programming lovers show examples of a few lines of code and say "see i solved this difficult problem in just 5 lines of code". Then you ask what the other files are and they have written 10,000 lines of code for all the related functions.

Yea abstracting is not something that only works in functional languages guys.

In small doses

[DrXym]

Anonymous functions / closures / lambdas are fine for small snippets of code, e.g. iterating loops, firing timers, success / fail handlers etc. When you start nesting them or chaining them together with promises or similar constructs, then things can get really hairy.

Try writing sets of asynchronous Jasmine tests that use promises, lodash iterators, success callbacks and other things of that nature arrays and madness swiftly follows.

Wroing question/audience.

[Anonymous Coward]

The question is not whether humans like functional programming, also known as writing down a parse tree as a list structure directly rather than in some human-accessible input language.

The question is whether computers like it. And computers are gung-ho about it, making it rather easy for humans to persuade computers into doing functional programming.

So the salient point is meta-programming, and structure-preserving program transforms. Functional programming is so well-suited for that stuff that you kind of forgive that it sort-of sucks when humans use it for straightforward programming instead.

But one can get used to it.

Re:Wroing question/audience.

[Anonymous Coward]

And you have just shown that you don't have a clue how computers are built.

Functional programming is nearly as unnatural as you can get with respect to how the hardware is built.

It's a fine enough paradigm, but...

[bradley13]

Functional programming is a fine enough paradigm. It can be very educational to look at a problem from a different perspective? imperative, object-oriented, functional, logical, etc.. Hence, yes, functional programming is a very useful thing. I think every programmer should give functional programming a try.

However: Mixing paradigms within a programming language makes code more difficult to understand, and generally leads to language bloat. It's worse, when the underlying language fundamentally cannot support the paradigm.

Prime example: Java + Lambdas. Java does not support working with code the same way you work with data, which is what functional languages are all about. With reflection, Java allows limited inspection of functionality, but no manipulation. Java lambdas are a way of faking one aspect of functional programming: the ability to pass code as a parameter. However, you aren't actually passing code as a parameter. If you were, then you could alter the value of that parameter at runtime, like you can any other variable. Instead, you're just letting Java fill in some blanks at compile-time, because the interface you select has only one abstract method. This is syntactic sugar that kinda, sorta looks like functional programming, but actually isn't. As such, Java lambdas are a really stupid idea. Anyone who has used them thinks they've done functional programming, but they actually have not.

Functional Programming is a good thing.

[Qbertino]

So is knowing and understanding it.

FP basically forces you to do multiple steps in one and trains your brain to think faster. Getting rid of state wherever possible is a neat thing too and enables more complex programms and routines that are less error-prone and more vertasile.

As long as you can wrap your head around what your doing FP is great. I've made a habit of using it whenever I can. ... Although sometimes I'm just to lazy or tired and start wittling about with variables again.

I use it every day, but still use imperative too

[RobinH]

I maintain a large-ish enterprisey system, most of which is written in C#. I use the functional features of C# every day. However, I would caution you against lumping all functional features under a single heading of "functional programming" because you can look at each feature independently and decide whether you want to use it.

For me, I definitely use immutability, both in combination with dependency injection for my service classes, but also in many of my data structures. For instance, I might have a module that pulls a bunch of state from the database and then organizes it into a projection, such as a forecast of material usage. That forecast is immutable. I then (optionally) have the ability to cache that either locally in the program, or cache it to the database, but when I bring it back it's still immutable, so that data with that ID never changes, and none of the consumers of that data need to worry about it changing. In some cases that means I can safely split the further processing of that data across multiple threads rather easily.

Also, LINQ is really just a ripoff of Lisp's S-expressions, and I find it extremely useful. If I have a list of anything, and I need to manipulate it into another form, then LINQ allows me to do that without loops and with less complexity. I generally still use loops for modifying data.

LINQ is really a combination of three features: 1) functions as first-class citizens, 2) lambda expressions/syntax, and 3) closures. These are very useful on their own. Being able to take a function as an argument is extremely powerful, and being able to define a function inline when you call that method, and have it capture values from outside that function in the form of a closure -- very powerful.

That doesn't mean there isn't a use for imperative programming, but when I see a colleague filtering a list of objects with a foreach loop, I just cringe. Just use a .Where() clause! Don't be afraid of functional - use it as one more weapon in your arsenal.

There is really no

[silentcoder]

fundamental difference between a map or an iterator in terms of how they execute.
So the question becomes one of aesthetics - and that must, inevitably, have a subjective aspect to it. Those who love the functional approaches will find them more pleasing, those who prefer the OO approaches will prefer those instead.
And some, like me, will mix and match them according to what looks better for the piece of code I'm currently writing - much as I choose between a for-loop or a list-compression based mostly on how long the list-compression is. Anything over about 60 characters and a for-loop is simply more readable and easier to debug.

Come on! We all know that...

[MarcoPon]

... dysfunctional programming is way more used in the real world..

I agree with Eric Lippert

[billybiro]

Eric Lippert, a former Microsoft employee and one of the main designers of the C# language and someone who understands and appreciates functional programming (having brought many functional paradigms to C# such as lambdas etc.) responded to the question "Why hasn't functional programming taken over yet?" on StackOverflow, which for me, sums up everything I feel about functional programming.

I've quoted Eric's answer below, but the TL;DR is that I believe the future is neither purely functional, nor purely OO, but some hybrid of the two.

Because all those advantages are also disadvantages.

Stateless programs; No side effects
Real-world programs are all about side effects and mutation. When the user presses a button it's because they want something to happen. When they type in something, they want that state to replace whatever state used to be there. When Jane Smith in accounting gets married and changes her name to Jane Jones, the database backing the business process that prints her paycheque had better be all about handling that sort of mutation. When you fire the machine gun at the alien, most people do not mentally model that as the construction of a new alien with fewer hit points; they model that as a mutation of an existing alien's properties.

When the programming language concepts fundamentally work against the domain being modelled, it's hard to justify using that language.

Concurrency; Plays extremely nice with the rising multi-core technology
The problem is just pushed around. With immutable data structures you have cheap thread safety at the cost of possibly working with stale data. With mutable data structures you have the benefit of always working on fresh data at the cost of having to write complicated logic to keep the data consistent. It's not like one of those is obviously better than the other.

Programs are usually shorter and in some cases easier to read
Except in the cases where they are longer and harder to read. Learning how to read programs written in a functional style is a difficult skill; people seem to be much better at conceiving of programs as a series of steps to be followed, like a recipe, rather than as a series of calculations to be carried out.

Productivity goes up (example: Erlang)
Productivity has to go up a lot in order to justify the massive expense of hiring programmers who know how to program in a functional style.

And remember, you don't want to throw away a working system; most programmers are not building new systems from scratch, but rather maintaining existing systems, most of which were built in non-functional languages. Imagine trying to justify that to shareholders. Why did you scrap your existing working payroll system to build a new one at the cost of millions of dollars? "Because functional programming is awesome" is unlikely to delight the shareholders.

Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21th century
Functional programming is very old too. I don't see how the age of the concept is relevant.

Don't get me wrong. I love functional programming, I joined this team because I wanted to help bring concepts from functional programming into C#, and I think that programming in an immutable style is the way of the future. But there are enormous costs to programming in a functional style that can't simply be wished away. The shift towards a more functional style is going to happen slowly and gradually over a period of decades. And that's what it will be: a shift towards a more functional style, not a wholesale embracing of the purity and beauty of Haskell and the abandoning of C++.

I build compilers for a living and we are definitely embracing a functional style for the next generation of compiler tools. That's because functional programming is fundamentally a good match for the sorts of problems we face. Our problems are all about taking in raw information -- string

Poorly understood?

[fyngyrz]

If you're using poor coders to maintain very old code then perhaps the choice of programming style is not your biggest problem.

You may have misunderstood the previous poster's use of "poor coder."

I read it as "unfortunate coder", not "incompetent coder."

I could certainly be wrong. Perhaps clarification will be forthcoming.

Re:Poorly understood?

[johannesg]

The poor commenter shouldn't be blamed for his lack of understanding.

Re:Poorly understood?

[fyngyrz]

Yes, said commenter clearly needs more money.

Fluid type manipulation with unions

[fyngyrz]

Would you consider unions in c a "means to circumvent the type system" as compared to a language with strong up-front typing?

Unions are certainly a very powerful, useful, and concise tool for manipulating data across type boundaries. If you don't have them, in trying to accomplish similar tasks as those unions make easy, in many languages you're going to be a lot more verbose, and likely a lot less efficient, than if you do.

I am assuming competence. Strong typing is a safety net. The need for such a thing varies with one's skill set. The fewer the participants, the more likely it is that the skill sets can be arranged to be similar. With larger teams, the need for safety nets almost always increases.

Re:Fluid type manipulation with unions

[angel'o'sphere]

Yeah,

in Pascal and Modula 2 we had "case records", don't remember how they were named exactly.

I used a union once or twice, but don't really remember why (I mean: for what purpose).

Re:Fluid type manipulation with unions

[lgw]

Skillful coding is writing code that's clear and easy to understand. Insufficient skill leaves one cheating, such as by using unions or "downcasting". From time to time I do such things, because I just can't find a simpler, more clear way without the cheating. But I always wish I could.

Never be proud of writing obscure code.

Re:Fluid type manipulation with unions

[fyngyrz]

Unions aren't the least bit obscure: they do very specific things, and just as you tell them to. It's a matter of skill. Not obscurity.

For instance, in my 6809 emulation, with a register that is sometimes independent 8-bit and sometimes single 16-bit (the 8-bit A and B registers become the 16-bit D register, depending on the instruction in play), a union is just the thing. It does exactly what is needed, when needed, and not otherwise.

Re: Fluid type manipulation with unions

[Anonymous Coward]

Union's aren't the answer. They only serve to kill jobs and enrich themselves. They are destroying America. #MAGA

Re:Fluid type manipulation with unions

[lgw]

I'm afraid that "the 8-bit A and B registers become the 16-bit D register, depending on the instruction in play" is pretty much the essence of obscure legacy cruft. Granted, you're not making it worse in any way by representing it with a union.

Re:Fluid type manipulation with unions

[fyngyrz]

Granted, you're not making it worse in any way by representing it with a union.

More to the point, you can't make it better by avoiding using a union. Because it's optimum as is.

The right tool for the right job.

pretty much the essence of obscure legacy cruft.

The job is the job. I have no problem using the right tool for the job.

Re:Fluid type manipulation with unions

[lgw]

Meh, I'd hope the optimizer was the right tool for the job. Any compiler worth a crap would know just what to do with
uint8_t a = d >> 8;
and that wouldn't rely on any undefined behavior (there's no standard way to directly manipulate registers in C, after all).

Re:Fluid type manipulation with unions

[jeremyp]

Yes, except that it is not portable. You'd need to arrange the 8 bit registers differently for big endian and little endian machines.

This simple example illustrates why C style unions are a means to circumvent the type system and are dangerous to the unwary.

Re:Fluid type manipulation with unions

[jeremyp]

He's emulating a 6809 which is pretty much a legacy processor by now. No amount t of you calling it cruft is going to stop the need for treating two eight bit registers as one 16 bit register because that is what the original hardware did. Same with the Z80 and the 8086.

The problem with using a union to do it is the undefined behaviour.

function dictionaries in Python

[fyngyrz]

So, for example, by storing functions as values in a dict you can build complex structures of execution without using any conditional codes .

This is the core mechanism of my text markup language. Once the specific built-in tokens are parsed out, they are immediately accessed via the language's function dictionary. This approach is quick, ultimately low-complexity, trivially extensible, and highly maintainable.

Re:function dictionaries in Python

[silentcoder]

Nice. I use the technique extensively in my code- it's elegant, easy to use, fast and powerful - I personally think it should be in every python coder's toolbox - but for implementing a lookup table for a markup language is one of the most elegant I've seen :) i will certainly be remembering this if I ever need to create a DSL again.

Unit testing FTW

[fyngyrz]

IMHO, unit testing is a far, far more important aspect of advancing programming in general than are lambdas. Just my 2c. :)

Hard stuff is, in fact, hard

[fyngyrz]

I would add to this that reducing the complexity by turning everything into separate functions tends to also increase what I call "opacity by non-locality."

Not only are some things hard, some things benefit from having the logic right there in front of your face; not in a header, not in some function elsewhere, not in a library.

Benefits in both comprehension, and so ease of construction, but also in execution time and smaller executables depending on just how smart the language is in constructing its own executables.

structs and fundamental OO

[fyngyrz]

Just having higher-order functions doesn't make a language a functional language any more than having structs makes C an object-oriented language.

Structs do, however, make the critical aspects of an object oriented approach practical in c. They can carry data, function pointers, etc., and they can be passed around.

I've been writing my c code like that since the 1980's. There are significant benefits.

Re:structs and fundamental OO

[molarmass192]

Gotta agree with you here, structs are possibly the single most useful feature in C. Sure it's not "real" OO, but it's provides a nice way to encapsulate functionality and state, while providing "good enough" level of abstraction. I've even used anonymous structs to approximate inheritance a few times and polymorphism is the void ptrs cute looking cousin. The latter two I try to avoid because those are just begging to introduce hair pulling out types of bugs.

Re:structs and fundamental OO

[Tablizer]

Structs do, however, make the critical aspects of an object oriented approach practical in c. They can carry data, function pointers, etc., and they can be passed around.

You are just reinventing machine language where data, instructions, and address pointers can be mixed willy-nilly. Higher-level languages merely try to introduce discipline and consistency to such practices.

Re:structs and fundamental OO

[fyngyrz]

You are just reinventing machine language where data, instructions, and address pointers can be mixed willy-nilly.

Because machine language varies hugely, and c varies little or none, when working on one platform and then another, c is a convenient low-level way to get as many advantages of working close to the metal (obvious ones are speed and executable size) as possible.

Higher-level languages merely try to introduce discipline and consistency to such practices.

Yes, they do. And in the process, they often cause the resulting product to suffer in speed and/or execution size (and the source code in clarity.) When "mere" means "the product is less good", I translate it as "not mere."

There are reasons to go one way or another. It's not as simple as "HLL's are always better." Sometimes even machine language is the best place to go, embedded controllers with limited storage and small tasks that must be accomplished efficiently, for instance.

Re:structs and fundamental OO

[Tablizer]

By "merely", I meant C (and HLL's) didn't originate the idea.

I'm not sure what you mean by "less good". You seemed to agree there's a trade-off between optimizing for "machine" resources/time, and abstraction/discipline/consistency/clarity. "Good" would then be relative to needs, such as business requirements/goals.

Sadly...

[buddyglass]

Where I work we only engage in dysfunctional programming.

cars cons crap

[fyngyrz]

((((((((((((I hate lisp too))))))))))

Isn't that the One with 20 Gazillion Brackets?

[wisnoskij]

I have never understood why the language is not considered a parody like the whitespace language. You cannot debug or change code when it is 90% brackets, and more than two to three ")))" brackets in a row and editing the nesting of something becomes really hard and error prone.
A proper language tries to evenly distribute the character usage evenly over a wide array of characters, such that the code is easily readable.

I have only seen a few examples in Scala, which replaced Java in my university the year after my class. But they were the least readable code snippets I have ever seen. It looked like they had replaced all the white space with brackets.

Re:Isn't that the One with 20 Gazillion Brackets?

[david_thornley]

Writing Lisp without a parenthesis-aware editor is really painful. I tried that a few times. When you use an editor like Emacs (which I pretty much use only for Lisp), you don't keep track of the parentheses so much as the shape of the function you're writing or editing.

For the most part, yes

[zifn4b]

I can write certain types of algorithms much faster specifically iterating arrays and associative arrays/dictionaries faster for the purposes of transforming data sets. Functional programming typically is more optimized than a do-it-yourself algorithm. No sense re-inventing the wheel if you don't have too.

functional programming is ok

[slashdice]

what i don't like is functional programmers!

Re:Functional programming is trendy hipster garbag

[zifn4b]

Programming is about translating what you want a computer to do into a set of instructions that the computer understands that mean the same thing.

That is half of what programming is, at most. The other half is, at least, making that set of instructions easily understandable by another human being. Your code will be read thousands more times than it is written, and readability is far more important than your statement suggests.

Writing a website in assembly language is a very useful and pragmatic skill to have. In fact, I encourage those folks that can do it to put it on their resume and see how many job hits they get.

Re:Lots of claims are being made about it's virtue

[angel'o'sphere]

Why so many out there seem to be unable to comprehend such a simple idea is something deserving of a study.

Why are there so many people that can not comprehend that writers completely know the correct form of usage but STILL make simple TYPING MISTAKES!!
And the damn typing mistake is not red underlined because it is a VALID WORD!

And no: proof reading does not make me see such errors, as I'm a whole word or even "whole sentence" pattern match reader.

(And in this text everything is red underlined because I can not make Windows 10 automatically detect the correct dictionary -- gosh this MS bullshit is so anoying ... my 20 year old Mac SE is better in EVERY regard than this windows nightmare)

Started learning functional programming

[Anonymous Coward]

Since I feel like I just do not get it when it comes to functional programming, I started looking at functional programming languages like LISP, Scheme, F#, ML, etc...

I've played with a little functional programming concepts in C# and JavaScript using lamdas and passing functions around like objects. At least I think these are functional programing concepts. If not, what are they? What makes functional programming different from imperative programming languages?

However, I still do not get it. So, I feel like I am missing something.

Maybe I need a better math background than I do now concerning set theory, etc.

So, if I wanted to really learn functional programming - and get it - what do you think is the best way to go? What languages? LISP? What else should I learn as a prerequisite for learning functional programming?

I have been doing C# since it came out.

The past month, I have even installed EMACS since I hear it includes a LSIP interpreter built-in. But I tried LISP examples on the net and some do not work. I think emacs uses a variant of LISP called elisp.

Re:Started learning functional programming

[Anonymous Coward]

>However, I still do not get it. So, I feel like I am missing something.

You're not missing something. It really does suck.

It's All Soup

[sycodon]

I've seen many of these "paradigms" come and go.

It's like someone coming up with a new way to make soup. New ingredients, new cooking methods, new ways to chop vegetables, new pots to put in in, blah blah blah.

In the end, it takes about the same about of time, tastes pretty much the same, and only refrigerates so many times before you have to throw it out.

Right time for functional programming

[Dareth]

Implementing functional programming needs to come at the right time for it to be effective. Until all of your programmers are following the internal style guide without exception, functional programming is not likely to take off. If people are still arguing over block style, forget getting them to agree on proper style for Lisp and the metric ton of braces.

Re:Right time for functional programming

[jbolden]

Mixed paradigm languages (like LISP) can be tough to have style guidelines. The purer functional languages enforce a functional style because bad code is a syntax error. You simply don't have syntax to break many of the rules. Haskell programmers often comment that getting a program with rich type definitions to compile is close to getting that program debugged.

Also standardizing form is less important when the number of lines reduces drastically. Functional programming encourages a paradigm that if a program is long there is an abstraction missing and fix the problem that way.

Re:Right time for functional programming

[Dareth]

"an abstraction missing and fix the problem that way"

If you abstract a functional program enough, you can summarize it as:

"MAGIC!"

Re:Right time for functional programming

[jbolden]

It can feel like magic. The abstractions are incredibly powerful and one line does a tremendous amount.

Science not heresay

[Mybrid]

CS61A, or Introduction to Programming, is a flunk out/weed out class at UC Berkeley. It is taught in LISP and is functional programming. Why? Functional programming runs counter to the way the majority of people think. Science says that functional programming is demotivating for the general population. So, what do you do if you have way more students interested in Computer Science than you have slots available? Easy, just make them pass a functional programming course.

CS61A is the only mandatory functional programming course at Berkeley. All other courses are in Java, C/C++, Python etc.

The only question one needs to ask about a computer language is this: can the language exercise the full functionality of the target computer? If the answer is yes then all such languages are interchangeable and logically equivalent.

Since scientifically speaking most people think in for/while loops and not function calls then procedural programming is the most common.

What have we learned?

1. A. If a language can exercise the full capability of the target computer than it is synonymous with any other such language in capability.
2. B. Science has shown people are far more motivated by procedural programming than functional. For and while loops are more natural to how the mind works. Most people find functional programming an unnatural way to think and therefore do not like it.

Javascript and Hacker News

[Mybrid]

Don't let Javascript and Hacker News fool you. Hacker News is predominantly a hang out for the functional programming crowd. This is a self selective audience. If you are not interested in functional programming then there is not a lot of content on Hacker News for developers.

Javascript is a bloody mess, especially with the Nodejs. A bloody mess is not functional programming. For/while loops are for more prevalent in Javascript then functional programming. At issue is all the callbacks for async event handling. Javascript is very poorly designed software because unless your async code is wrapped in monitors it is not proper async code. Promises? Pick up any programming text book on async programming and it will always teach you to wrap your async code in monitors/semaphores/locks.

FP not ready for prime time

[hax4bux]

I have a erlang team (over two years), and although it seems they work hard there is not much to show for it. Everything is written, then rewritten multiple times. Very ordinary things like web servers require extensive customization. Actually, lots of ordinary stuff requires custom implementation. The dogma and religious wars never end. It is difficult to staff qualified people. In short, many liabilities and it will be a long time before I sign up for another FP project.

Too bad computers don't believe ifn FP.

[thadtheman]

At it's simplest. The first instruction of a function program executed, the PC register is changed and that's that. The state of the machine is changed. Claiming to be startelss is just a fictional abstraction. Moreover most programs are all about state ( eg. databases ). State is something that functional programmers have been trying hard to isolate for a long time, inventing such monstrosities as monads ( which BTW are easy to understand when you don't use category theory ). But I would really like to see something like a word processor written in a purely functional language with monads like Haskell. Then someone take the % of the code spent creating stateful monads ( such as IO or Option ) vs nonmonadic code or stateless monadic code ( like Lists ). I suspect that on averaage over all the programs in the world, 90% of the code ( via code, execution time, or any other size metric ) is spend into stateful monads and 10% in the rest of the code.

I code in Haskell

[xenog]

I always want to get code that works, and better yet that works right after successfully compiling. Haskell with its functional style and rigid type system helps me catch the multiple errors that inevitable end up in my code as I write it. I have done multiple programs and libraries in Haskell and I’m pleased with the small chunks of expressive code that come out of these efforts. Sometimes I have to write verbose monstrosities that do very little in Java. I always dread going back to it. I write many more bugs in Java that I do in Haskell, and fewer get caught at compile time. A Java IDE is where both my productivity and fun go to die.

Functional could be next - maybe

[ripvlan]

Functional programming is getting better. I use lambdas in C# all the time, sometimes in Python too (although I don't like the syntax), and I've tried them in Java. In C#/Java/et al they are fabulous ways to focus on the Functionality and not the Implementation (what the heck is this FOR loop doing?).

Pure functional has problems that will be solved. Jet.com is based on F# (the whole website and backend - yes a bit of C# here and there). Now could be the time to jump in - while being aware that patterns and practice are an emerging area and there will be growing pains.

I've been using F# and R for over a year now. F# caused me to suffer from a problem that early OOP/C++ programming had - methods/layers that hid too much and made debugging difficult because it wasn't clear where it went wrong. Plus the syntax of these languages can be confusing, and procedural languages (C#/++/Java) work the way we "think" "step1 - do this, step2 - do that" Functional focuses on the end product and not the steps in between. Beyond different syntax, we need to think differently.

I've found myself passing too many arguments "down" to the layers (again - something early OOP suffered from). The promise of altering the lower implementation layers without affecting top-level code hasn't panned out. I've had a bit better luck with R but the problems I'm solving are different. F# has been a "real" program and R has been computation of stats (grab data and compute min/max/avg). OOP solved it through better patterns such as ambient properties and policy injection, possibly OCP (which is NOT a functional solution). I'm finding the readability of code to be difficult (esp this Javascript nested stuff -- seems like using the wrong tool for the job, as in, I want to program like this and let's' see what's in the web toolbox... Javascript it is).

While I like F# my biggest mind-bender has been around function composition. The idea of magic params that the runtime simply solves causes a lot of "magic" to occur that isn't obvious to the coder. Yes - shorter code. However, the next person must spend time reading and understanding the code before being able to make changes that doesn't break the implementation. Again - the OOP problem. To read an F# function and wonder "where'd param 3 come from?" or "where *does* param 3 come from?" Quite possibly new patterns that must be learned.

So I say - give it a try. Learn a new language.

Re:Functional could be next - maybe

[retchdog]

"the next person must spend time reading and understanding the code before being able to make changes that doesn't break the implementation."

yes, but does it have any disadvantages?

Re:Functional could be next - maybe

[ripvlan]

har har har..

No - what I meant was... they need to develop an (overly) intimate understanding of what the code is trying to achieve.

In most programming languages I can quickly understand the purpose and make a change. Maybe there's some concept like "functional density" which is "Low" in a language like C# and very "high" in F#. Therefore I can make non-functionality changes in C# that serve little purpose and unlikely to have side-affects because lots of code is crap to fill whitespace. But functional languages lack "white-space-code" :-)

I will add that I've achieved a lot more functionality quickly using R & Python. My implementation of an internal utility was ~50 lines in Python vs the existing utility written in C# which was easily near ~500 lines. Granted I pulled in a lot of modules so the total size was larger -- but my effort was small to achieve the same goal. Same thing with my R programs.

The only reason I can't say the same with F# is that I have a (relatively) lower number of hours in it.

Re:Functional could be next - maybe

[Anonymous Coward]

(overly) intimate understanding

Is there such a thing? Seems like most people have virtually zero understanding of the code before making changes. If anything, even good programmers read what the programmer is trying to do and not what they're actually saying. The devil is in the details.

The best programmer I know has difficulty understanding bad code because he's always trying to read the intentions. Personally, I don't trust intentions, they lie all the time. I pretty much convert all code into ASM in my head. I can tell you what the GC is probably doing, how it will affect the thread scheduler or thrash the cache.

Not really

[Kjella]

I work far more with SQL than programming languages really, but I do work a lot with doing operations on large data sets so I definitively try to avoid looping through a million rows. I use in-memory or temp tables to chain operations without storing state. And that's all neat and well, but without a ton of state in between those set operations to say what's ready, what's running, what's done etc. I'd go nuts. The functional bits are the stretches between the state almost like barriers in computer shaders and other synchronization methods. A pure functional application well I couldn't really imagine it unless it read one file as input and spit out a result, it just flows through the whole application. Every time I try to understand state in FP my head hurts.

descriptive, not prescriptive

[Anonymous Coward]

Functional languages are excellent as a concise descriptive language, and I could see writing specs with one. Most of the definitions and proofs you see in a math class are like a functional language, frequently with recursion involved.

For example fundamentally addition can be defined recursivelly as
a + 0 = a
a + inc(b) = inc(a + b)
and from that you can correctly add numbers like this:
a + 5
= a + inc(4)
= inc(a + 4)
= inc(a + inc(3))
= inc(inc(a + 3))
= inc(inc(a + inc(2)))
= inc(inc(inc(a + 2)))
= inc(inc(inc(a + inc(1))))
= inc(inc(inc(inc(a + 1))))
= inc(inc(inc(inc(a + inc(0)))))
= inc(inc(inc(inc(inc(a + 0)))))
= inc(inc(inc(inc(inc(a)))))

The above is a perfect mathematical description of addition, but if you treat it presciptively and try to use the above as an implementation of addition that's a horrible way to go. Adding a+b would take O(b) in both time and stack space. And even if you add in the lovely tail recursion optimization that functional language enthusiasts always mention to assure us the functional languages are smart, you still end up with addition being implemented as a for loop basically a + 1 + 1 + 1 + 1 ...

In a case this simple, a functional programmer would of course not advocate for addition to be implemented so naively, But in general yes that's exactly the type of thing functional programmers advocate for: it's all about describing the result you want and being amazed by how clean it looks, and letting the compiler optimize its way to the result.

High-brow fails [Re:It depends on the use]

[Tablizer]

"High brow" programming has never proven itself in practice for multiple projects. There's never been a case where top-notch, highly-educated programmers are put into a single organization such that it consistently out-competes the "medium-brow" shops. They may be paid more than average, but in theory they'd be far more productive using high-brow techniques such that it overshadows their higher salaries.

Some bring up Paul Graham and his e-stores company, but that was a one-shot deal. Once the company became established it abandoned Lisp. Quick-to-market entrepreneurial may benefit from it, but I'm talking rank and file projects.

Related discussion:

http://wiki.c2.com/?IfFooIsSoG...

Re:High-brow fails [Re:It depends on the use]

[Pseudonym]

"High brow" programming has never proven itself in practice for multiple projects.

Sure it has. Assembler proved itself against writing binary, high-level languages proved themselves against assembler, managed languages proved themselves against languages compiled to machine code, regular expressions proved themselves against writing custom parsers... most new technologies were "high brow" once.

Re:High-brow fails [Re:It depends on the use]

[Tablizer]

That's true. But it's hard to know what will be "mainstream" in a decade or so. I'm not convinced FP will "trickle down" to mainstream (4-yr-degree staff), at least as a primary technique. It's been around for roughly 60 years (at least as Lisp). If it doesn't go mainstream within 60 years, it probably won't by 70 either.

Thus, it may not match or be part of the evolution pattern you outlined.

Even when GUI's first came out, I couldn't predict they'd go mainstream. While I thought it was "cool", I thought it may stay limited to graphical applications because for non-graphical applications they don't make one more productive than a well-designed command and/or character-based interface. (And still don't.) What I didn't count on was that most found they are easier to learn (pick up). I didn't know that issue would override others in users/manangers' minds.

Re:High-brow fails [Re:It depends on the use]

[Pseudonym]

Thus, it may not match or be part of the evolution pattern you outlined.

Of course. For every highbrow concept that became mainstream, there's three that only became niche and another 20 which died off.

I think that functional programming (and I include the actor model) is more important now because of the trend towards more and more cores on the one machine. Purely functional design scales to lots of cores in a way that sequential code does not. Whether or not the industry realises this is a separate question.

Re:High-brow fails [Re:It depends on the use]

[Tablizer]

is more important now because of the trend towards more and more cores

But the bottleneck is not CPU itself for a good many applications. And specialized languages or sub-languages can handle much of the parallelism. If I ask a database to do a sort, it may use parallelism under the hood, but I don't have to micromanage that in most cases: I don't care if the sort algorithm uses FP or gerbils on treadmills. Similar with 3D rendering: the designer submits a 3D model with polygons and texture maps, and a rendering engine micromanages the parallelism under the hood. That "root engine" may indeed use FP, but the model maker doesn't have to know or care.

And event-driven programming can hide that fact that parallelism is going on, or at least provide a non-FP interface. For example, in a game, a character may be programmed by how they respond to various events. There may be 10 events going on at once, but the app dev is only focusing on one at a time per character or character type. Granted, it may take better languages or API's to abstract parallelism well. The "root engines" may make heavy use of FP, such as the database, rendering, and event handling engines, but the 2nd level, typically called "application developers", probably won't need that any more than SQL query writers (usually) don't have to know how the database engine was written. But only time will tell...

Re:High-brow fails [Re:It depends on the use]

[Tablizer]

Addendum and corrections:

The "actor model" seems pretty close to event driven programming. I don't know the official or exact difference. But my key point is that the event handling programming and interface is procedural. The only non-procedural aspect may be that requests for further actions may need a priority value (rank) and to be submitted to a request queue. For example, a game character may request a "shoot arrow" event on their part as a follow-up. But the event handler writer doesn't have to concern themselves with the direct management of the event-request-queue.

"Any more than...query writers...don't have to know..." should be "Any more than...query writers...have to know...". Remove "don't"

Re:High-brow fails [Re:It depends on the use]

[Pseudonym]

But the bottleneck is not CPU itself for a good many applications.

That's true, but it's also not relevant. For most "apps", the main issues are battery life and responsiveness. Multi-core is increasingly being seen as a tool to increase responsiveness rather than throughput, because the app looks like it hasn't fallen asleep even if it hasn't done the thing that the user asked yet.

If I ask a database to do a sort, it may use parallelism under the hood, [...]

Interesting example. I wrote the sort subsystem for a (non-SQL) DBMS in one of my previous jobs, so... I guess this illustrates that we come from different perspectives on this point. In case you are curious, it was single-threaded, although it was designed to work on a clustered database, so it was parallel in the sense that it did parallel sorting across multiple machines in a cluster (which is what we called it before we called it a "cloud").

That "root engine" may indeed use FP, but the model maker doesn't have to know or care.

Right, and that's the advantage: Pure functional programming ensures that the client doesn't have to care, because workers are guaranteed not to modify anything that they are not supposed to because they are pure functions.

Map/reduce was all the rage a couple of years ago. I think the main advantage was not the map/reduce model, but the realisation that when you have "big data", you take the code to the data rather than taking the data to the code. But on top of that, forcing yourself into a pure functional style means that your code can run anywhere because it doesn't care about the context in which it runs.

Re:High-brow fails [Re:It depends on the use]

[Tablizer]

forcing yourself into a pure functional style means that your code can run anywhere because it doesn't care about the context in which it runs.

Most planners focus on the current needs, not future needs. Whether that's rational (good business planning) is another matter. It's generally cheaper to hire and get future maintenance on procedural code. If and when machine performance issues override that, the planners may THEN care.

It depends on the project. If most of the processing for an app is happening on servers in cloud centers, then it's probably already parallelizing user sessions. Parallelizing at the app level thus won't really give you much more parallelism potential, especially if most of the data chomping is done on the database, which should already be using parallelism. Web servers and databases already take advantage of parallelism. It would thus be diminishing returns to parallelize the app level. If the code is looping on 10,000 items in app code itself, the coder is probably do something wrong.

It's the explanations. Start with examples

[raymorris]

> I'm not sure if the problem is me or the explainers.

I'm fairly sure it's the explanations, which tend to mathematically define them, rather than showing what the heck they are are what they are good for.

I noticed that the other day looking for good explanations of the normal forms in relational databases (sql). Most of the explanations I found were crap. Rigorously correct, and entirely useless to someone who doesn't already fully understand them.

My kid is two. When I wanted her to know what a "horse" is, I didn't start with a rigourous, formal definition of "horse" as distinct from all other species. I showed her a horse, so she could see what it is, then I showed her someone riding a horse, so she can see how it's used. I wish more comp sci people had basic competence in explaining or teaching.

Damn how I hated LISP

[NotSoHeavyD3]

Mostly because when I was taking it in college 20 some odd years ago all the code they gave us as example basically tried to do everything in one line of code. I mean damn, maybe if your terminal gave you a 50,000 volt shock for hitting the enter key I could understand it but it made debugging anything a complete pain. (Well that and the fact you had to have the absolute perfect number of parenthesis. One too many or few and watch the app crash.)

Can someone explain...

[Zo0ok]

I understand this is stupid but I would like to know... have a look at:

http://rosettacode.org/wiki/Luhn_test_of_credit_card_numbers

Look through the inititial text and get an idea. Then jump to the C code (not functional).

Then look at functional implementations: C++11, Python, Closure, Haskell, PicoLisp, Python, Scheme, Swift.

Look at Scala: 2 ways: functional (recommended) and procedural. Look at it.

What do you see?
What do you think?

Apples and Oranges

[tgrigsby]

Object oriented design is here to stay. Functional programming has it's place, but as little more than one off event handlers, I wouldn't call it a programming paradigm. Like interfaces, it's useful, but it's more applicable in some situations than others.

Put it this way, if someone told me OOP was dead, I'd fire them because it would indicate to me that they didn't understand OO and would likely be resistant to understanding it.

Love it in Ruby

[Brian Feldman]

I love how it's done in Ruby. It's compact and yet readable, unlike certain other older languages known to include many paradigms, including OO and Functional.

"Like?"

[Anonymous Coward]

"Liking" functional programming ranks with "believing" a scientific theory. Both verbs are inappropriate. Functional programming has advantages in some situations and perhaps not others. For compiler writers, functional languages are wonderful. The lack of side effects in semantics make them really easy to auto-parallelize without programmer effort. Whole-program optimization after massive inlining gives an opportunity to bring other techniques to bear that result in really fast code.

To preserve single-assignment semantics and generate fast executables, somewhat more storage may be required than using an imperative-language counterpart.

Weak programmers

[Anonymous Coward]

Python creator Guido van Rossum has said most programmers aren't used to functional languages.

Most programmers are weak.

Determine the problem you're solving first

[Anonymous Coward]

An analogy of what I'm seeing since Java hit is people saying "I have a hammer, what's the problem we're solving", instead of "What the problem we're solving, now what's the best tool for the job".

Functional has it's place, web development seems to be that place from what I've seen. So I like functional for web development/streaming systems.

FP becomes more popular than OOP?

[Anonymous Coward]

There are times when imperative programming is more efficient.
Compared to OOP, anything and everything looks great.

Re:FP becomes more popular than OOP?

[Tablizer]

The industry learned the hard way that OOP works well for some things but not others. For example, OOP has mostly failed in domain modeling (modeling real-world "nouns") but is pretty good at packaging API's for computing and networking services.

The industry may also learn the hard way where FP does well and where it chokes. Some understandably don't want to be the guinea pigs.

Injection

[Anonymous Coward]

I inject functional programming where I need to. Usually, I'm writing normal code and then "subscribe" to a functional thought paradigm

Project Euler

[PJ6]

I see a ton of comments here from people that clearly don't understand what functional programming is, or they don't really get it. If you consider yourself a programmer, go to Project Euler and do the first 20 (or 50) problems. Use whatever language you like. You have to do them, because you need to solve them to see all the other solutions.

Look at the solutions, in all the different languages, and compare. Not just for speed, but the design. Take a good look.

Functional Programming IS GROOVY!!!

[Foofoobar]

For all the BS about Groovy not being functional, if you look at partial implementations, Groovy is just as functional as Scala. And better yet... it is 100% compatibale with Java; Take ANY Java class and change the extension to '.groovy' and it will compile!

Re:Lots of claims are being made about it's virtue

[sheph]

Perhaps you could petition and get a government grant. God knows they give away gobs of money to study less important things.

Re:Functional programming is trendy hipster garbag

[Anonymous Coward]

Please explain how my statement "suggests" that readability isn't important, because I didn't say a goddamn thing about readability since that's not what I was addressing in the first place. I said that programming is about giving a computer instructions on what you want it to do. Nothing more, nothing less. If it "suggests" anything, it's that readability is a required part of the process since writing the code is hard to do if you can't read your own instructions back as you bug-fix and refine them. Functional programming is not really readable anyway; it's hard to write and even harder to understand when you try to read it.

Why do I care, in practical terms?

[nctritech]

I have examined the concepts and languages involved in functional programming and I do not see their value. Most of my work is split between C and shell scripts with random PHP, SQL, etc. peppered in as necessary. My question is simple: what can functional programming do for me, in practical terms? Including a real-world example is mandatory to answer the question. I always see platitudes regarding either "elegance" or "you'll have to think differently" but neither is an actual benefit. I don't need a hammer that is hard to use and makes me think about the nature of hammers and their usage; I need something that is efficient and straightforward when I decide to forcefully attach two things using nails.

As far as I can tell, functional programming is only useful as a thought exercise...which means that (compared to "uncool" but widespread languages like the C family) it's not useful when you actually want to get something done.

GUI Example [Re: It has its uses]

[Tablizer]

Of course in GUI development, Lambda can also be very convenient.

Example? I've only seen examples that expose weaknesses in Java and/or its GUI libraries.

For example, if the distinction between on object and class were blurred, then each GUI push-button could and should have an OnClick method. (Language could include an option to add or change the method away from object declaration.)

Instead, one has to "register" the on-click code with a "listener" via a lambda. Why the fock should a typical coder have to care about a fricken GUI listener? That should be under-the-hood guts, or at least something you only care about (mostly just inspect) if there is a tricky bug. The coder mentally associates the on-click behavior with its button, and the GUI API should reflect that common sense. Java's doing it wrong; lambda's are merely a band-aid over bad design in that case.

"We forgot to think this through so instead we randomly shoehorn behavior into the gui via lambda's"

I've seen other "justifications" for lambda's that are usually a kludge over bad languages and/or libraries.

It's like anal sex...

[Anonymous Coward]

In the right time, in the right place, it can be incredible, but most of the time you just end up in pain or covered in shit.

Yes

[leifbork]

Yes

"Half of my co-workers have drunk the Kool-Aid"

[Anonymous Coward]

I can't quite work out whether the poster thinks the idea of functional programming is good or bad. There's nothing to indicate what they think....

NOT.

Look functional programming is very declerative. "Use the source, Luke" is far FAR easier with functional programming than OOP. But the need to use the source should (not that it always is: my problems with OOP acolytes is that, like newly weds, EVERYTHING is OOP'd to the exclusion of everything else, sometimes OOP is a bad idea) be as high with OOP, since the design docs should say what it does and why, and you don't need to know HOW it does it.

"Python creator Guido van Rossum has said most programmers aren't used to functional languages"

WTF???? Now either I'm hella old, or this is a bit hyperbolic. Part of the easy use of correct functional design is because it's simple to comprehend, as opposed to OO which requires a lot more effort to make the object paradigm correct *for the use of the program as envisioned*.

Functional programs get garbled and spaghetti because the code is clear in the original design goals, but as the goals change and morph, the code gets less clear (because there's a cost to a rewrite, but without that you have to find some novel (read obscure) way to get to "there" from "here", even when "Well, if I wanted to get there, I wouldn't start here" were the case).

OO programs get garbled frequently from the off because the object design was not useful for the solution required, or become so because the goal change means the object design should be redone. When you do a decomposition of the object goal and see lots of cross-pollination of objects and upcasting or getter/setter methods galore, that's a hint that the object design is not aligned with the code goal.

And that again was my problem with a lot of OO neophytes, they designed a cool object design that made a lot of code reuse as if it were the goal of the project. Or where the object paradigm, when it met the goals of the code, was kept despite a bad match, because the object design was invested in by the coder. It's the OO version of the hacking a new functional section into code for functional programming fails.

SOOO... Peter... We're putting new cover sheets

[Anonymous Coward]

on all the TPS reports... did you get the memo?

THIS

[Anonymous Coward]

Trading the loops for a stack is what is happening... going deep instead of wide... it is STILL MEMORY... I like / dislike things about most languages, but the religious stuff is usually from people who don't know anything about languages. Iterators have gotten rid of 80% of off by one errors and are making those types of problems go away... Even Javascript is getting them... Composition is being driven hard in OOP... The whole REST thing has been pushed by the OOP crowd for a decade now... as someone who has HATED Javascript for 20 years... it is now becoming a great language... BUT only for certain tasks... I expect the Node crowd to start migrating to Elixir in the next 5 years... OR better yet... CLR like interface on top of the Erlang VM... The good ole' days are coming SOON... Nirvana is at hand.

I am so sick of these hipster what-ifs

[Anonymous Coward]

This question is like asking a carpenter whether he prefers a saw to a hammer.

These are tools. Each one has a use. Maybe it would be better to focus on using the right tool for the right job rather than constantly obsessing over what the current fad is and whether you are on the bleeding edge of it -- whether you got a concert t-shit before anyone else even heard of the band.

WTF happened to engineering?

UPVOTES :: Fake internet points for YOU

[Anonymous Coward]

THIS soooo much...

I love the backend for Elixir SO much more than java... and I think someone will get a language on it that makes programmers happy...

This is the best comment in the whole thread (so far)

Code

[NewYork]

Show me the code --Linus