Linked by Thom Holwerda on Mon 14th Jan 2013 23:15 UTC, submitted by MOS6510
General Development "Programming languages are living phenomena: They're born, the lucky ones that don't die in infancy live sometimes long, fruitful lives, and then inevitably enter a period of decline. Unlike real life, the decline can last many, many years as the presence of large legacy codebases means practiced hands must tend the code for decades. The more popular the language once was, the longer this period of decline will be."
Thread beginning with comment 548805
To read all comments associated with this story, please click here.
Comment by RareBreed
by RareBreed on Tue 15th Jan 2013 04:49 UTC
RareBreed
Member since:
2011-10-10

I do hope that functional programming languages undergoes a renaissance. However, in my opinion, imperative style languages have made it harder for people to think that way if they have been coding in an imperative style for too long. The thought process requires a radical shift which takes time. For me, it became relatively easy to pick up a new OO or imperative style language. However, it took me several months of wracking my brain to even begin to program in a functional style.

immutable vs. mutable data
recursion vs. iteration
closures vs. objects
method dispatch vs. polymorphism
pattern matching vs. switches
composition of functions vs. aggregation of objects
Macros vs. DSLs
Continuations vs. Exceptions/goto/setjmp

But once you do figure out, it just becomes more elegant. I don't know how software is going to get faster with multi-cores unless people switch to functional languages. Lock-based concurrency is just really hard to get right.

If you don't believe me, read Bartosz Milewski's post on why he switched to FP (and if you don't know who Bartosz is, just google him).

http://fpcomplete.com/the-downfall-of-imperative-programming/

My own dabble with functional languages has been mostly clojure and scheme based. Next on my list to learn is haskell. I tried Scala and didn't like it much (personal choice, it reminded me of perl's TIMTOWTDI and it wasn't really all that functional to which Odersky himself agreed). Clojure is nice, and it's way more readable than lisp/schemes since it also has [] for vectors and {} for maps. That little change makes clojure way more readable. That being said, being hosted on the JVM sucks for system programming. So that's why I've been learning scheme and next on my list is haskell.

Reply Score: 5

RE: Comment by RareBreed
by torbenm on Tue 15th Jan 2013 10:21 in reply to "Comment by RareBreed"
torbenm Member since:
2007-04-23

I started programming in 1975 with BASIC and COMAL and then later Pascal, FORTRAN, COBOL and assembly language at university. On the third year of university, I was taught LISP and was immediately sold. I have also used C, Java, Scheme, ML, Haskell and a dozen less known languages. I tend to use mainly Standard ML. Though it is not purely functional and rather less advanced than Haskell, I like its simplicity: I find that Haskell has evolved to a testbench for weird language and type features so people can write extremely generic programs that you need a PhD to understand.

Standard ML is, however, rather dated. Some attempts at revising it has been made, but they have, IMO, failed mainly by trying to add too many new features to the language. Then there are what I would call misguided derivatives (O'Caml and F#) that add object-oriented features to the language. I would rather see a minimal update that solves some of the more pressing problems (such as lack of Unicode support) and a more modern standard library. And parallelism, of course.

Reply Parent Score: 2

RE[2]: Comment by RareBreed
by Accident on Tue 15th Jan 2013 16:56 in reply to "RE: Comment by RareBreed"
Accident Member since:
2005-07-29

Have you tried F#? It's a Functional Language. Comes in Visual Studio and can be used in MONO.

Reply Parent Score: 4

RE: Comment by RareBreed
by moondevil on Tue 15th Jan 2013 10:33 in reply to "Comment by RareBreed"
moondevil Member since:
2005-07-08

The functional programming is going to be just another tool of multi-paradigm programming languages, I think.

From my enterprise experience I think functional programming has more chances of success by being integrated into mainstream languages (C#, Scala, ...) as pure functional only.

People finally discovered that single paradigm languages are not a good idea.

Reply Parent Score: 4

RE[2]: Comment by RareBreed
by hhas on Tue 15th Jan 2013 12:37 in reply to "RE: Comment by RareBreed"
hhas Member since:
2006-11-28

People finally discovered that single paradigm languages are not a good idea.


I disagree. Maintaining a clear, precise focus is a Very Good Thing (see: Coupling and Cohesion 101). You never see a joiner using the same tool to do everything from slice wood to turn screws to drive nails to apply varnish. There's a reason for that.

I think the real problem is developers not being able to hop quickly and effortlessly between different languages within a project. That may be partly down to bridging and tools not being good enough to allow seamless mixing and matching. But I suspect the biggest barrier is developers themselves lacking the mental agility to switch between languages and idioms. That, compounded by a self-indulgent fondness for inventing complex solutions using tools they already know rather than seeking out simple solutions involving tools they don't. The modern trend for Computer Science courses to silently retool as Software Engineering, and from there to lowest-common-denominator Java diploma mills, probably doesn't help either; but that's another debate.

Reply Parent Score: 2

RE[2]: Comment by RareBreed
by Delgarde on Tue 15th Jan 2013 20:33 in reply to "RE: Comment by RareBreed"
Delgarde Member since:
2008-08-19

The functional programming is going to be just another tool of multi-paradigm programming languages, I think.


Agreed. Over the years, I've found very little value in purely-functional languages - but I find a *lot* of value in having functional elements within more traditional procedural or OO languages.

Reply Parent Score: 2

RE[2]: Comment by RareBreed
by RareBreed on Wed 16th Jan 2013 20:46 in reply to "RE: Comment by RareBreed"
RareBreed Member since:
2011-10-10

I would disagree here. The problem is that it only takes one mutable piece of data or one function with a side effect to ruin an entire call chain. Mixing and matching pure FP with anything else renders your code non-pure and thus you may as well not have written in an FP style at all.

Less seriously, it forces users to think multiple ways. I saw many java developers complain vehemently about the upcoming lambdas in Java 8. So one developer might write code in an OO style, and another in an FP style, and now everybody has to learn both ways of doing it.

Reply Parent Score: 2

RE: Comment by RareBreed
by Valhalla on Tue 15th Jan 2013 17:11 in reply to "Comment by RareBreed"
Valhalla Member since:
2006-01-24

Carmack had a (imo) interesting blog post on functional programming from a C++ perspective:

http://www.altdevblogaday.com/2012/04/26/functional-programming-in-...

Reply Parent Score: 3

RE: Comment by RareBreed
by MollyC on Tue 15th Jan 2013 23:53 in reply to "Comment by RareBreed"
MollyC Member since:
2006-07-04

I love functional programming.
But imperative programming more matches the way that people actually think. People think in concrete, step-by-step terms: I get out of bed, I take a shower, I brush my teeh, I comb my hair, I get dressed, I eat breakfast, I leave the house, I go to work, I park my car, I walk into the office, I etc, etc, etc. In order to achieve a particular goal, people do each step in a particular order.

Functional (and logic) programming, is more atuned to abstract/mathematical thinking (and the more declarative the programming is, the more it becomes like math). Most people are not adept at that.

Reply Parent Score: 2

RE[2]: Comment by RareBreed
by ndrw on Thu 17th Jan 2013 00:47 in reply to "RE: Comment by RareBreed"
ndrw Member since:
2009-06-30

I get out of bed, I take a shower, I brush my teeh, I comb my hair, ...


If that was how OO programs are written the world would be better. Most programs (and toolkits) look more like this:

"[You,] get out of bed! Take shower! Brush teeth! Comb your hair!"

or even:
"take a comb, raise your hand, do {stroke your hair} until (enough)".

Calling other object's "doSomething" or "setSomething" methods is modern equivalent of calling "goto". A single setter may look innocent but try to sequence a number of them and you will have to deal with all the complexity (structure, sequencing, side effects) that leaked out from the object. That's because the control is no longer inside the object but in a caller of the method.

Reply Parent Score: 2