Best programming language to learn next?

[Leuchten]

Functional programming techniques are being adopted by many older languages (c++, java) and show themselves to be incredibly useful for developing sound, well made code. Purely functional programming also lends itself very well to concurrency and removes the biggest source of errors associated with it.

As far as I've seen, the number and popularity of languages that embrace functional paradigms has been growing a lot recently.

[WinterMadness]

Sure, a few things here and there are being implemented in imperative languages, but I am not seeing a trend to move anything widely used to a functional language, just the thought sounds horrifying because anyone who has worked in a group knows, a lot of people don't understand recursion and I also find that functional languages are far too restrictive in how you can solve problems. Imperative programming is going to be entirely dominant for the foreseeable future imo.

[The Cog]

It might also be worth looking at erlang ( www.erlang.org ). It's a functional language, and designed not just for multithreading but for multi-machine multithreading. And you can upgrade a program while it's running, which is neat. This might be one that makes a big mark in the future. Even if not, learning a functional language can be worthwhile, to help expand that way you can think about problems.

[ehrt74]

It might also be worth looking at erlang ( www.erlang.org ). It's a functional language, and designed not just for multithreading but for multi-machine multithreading. And you can upgrade a program while it's running, which is neat. This might be one that makes a big mark in the future. Even if not, learning a functional language can be worthwhile, to help expand that way you can think about problems.

Well, there's no magic about writing good concurrent code. You just need to limit the possibilities the architecture offers down to an amount that you can reason about. A good way to do this is communication between concurrent functions using streams or "channels of communication" if you like. These are rather like pipes in Unix, and block automatically if needs be. In Go (oh, I do hate to keep harking on about Go) these look like this:

package main


import "fmt"




func mychanuser(ch chan int) {
        for i:=0;; i++ {
                ch<-i
        }
}


func main() {
        ch:=make(chan int)
        go mychanuser(ch)
        for ;; {
                j:=<-ch
                if j==10 {
                        break
                }
                fmt.Printf("%d\n", j)
        }
}

the function 'mychanuser' can only communicate with the outside world over the channel it has received as an argument, but it does have internal state.

for an introduction to stream programming, Sussman and Abelson talk about it in the SICP course: http://www.youtube.com/watch?v=a2Qt9uxhNSM

[Leuchten]

Sure, a few things here and there are being implemented in imperative languages, but I am not seeing a trend to move anything widely used to a functional language, just the thought sounds horrifying because anyone who has worked in a group knows, a lot of people don't understand recursion and I also find that functional languages are far too restrictive in how you can solve problems. Imperative programming is going to be entirely dominant for the foreseeable future imo.

I don't think it's a huge problem. A lot of people don't understand for loops when they first start programming, but somehow it all works out. I think the lack of comprehension when it comes to recursion comes from the lack of focus on anything that is not either object oriented or imperative in curriculum, but that's changing a lot nowadays. Many people have experience with mixed paradigm languages like javascript which is imperative/OO/functional.

Well, there's no magic about writing good concurrent code. You just need to limit the possibilities the architecture offers down to an amount that you can reason about. A good way to do this is communication between concurrent functions using streams or "channels of communication" if you like. These are rather like pipes in Unix, and block automatically if needs be. In Go (oh, I do hate to keep harking on about Go) these look like this:

That looks a lot like the actor model to me, just less robust.

[shawnhcorey]

Sure, a few things here and there are being implemented in imperative languages, but I am not seeing a trend to move anything widely used to a functional language, just the thought sounds horrifying because anyone who has worked in a group knows, a lot of people don't understand recursion and I also find that functional languages are far too restrictive in how you can solve problems. Imperative programming is going to be entirely dominant for the foreseeable future imo.

Recursion is easy to understand if you break it down into steps.

Functional programming has been around for a long as Lisp has and it's not a popular language. People think more in terms of steps than functions.

I don't think it's a huge problem. A lot of people don't understand for loops when they first start programming, but somehow it all works out. I think the lack of comprehension when it comes to recursion comes from the lack of focus on anything that is not either object oriented or imperative in curriculum, but that's changing a lot nowadays. Many people have experience with mixed paradigm languages like javascript which is imperative/OO/functional.

People don't understand looping because the first loop they encounter is the while loop, which does not mean while but if. A while loop does not execute while a condition is true and exits immediately when the condition becomes false. It only tests the condition at the top of the loop. This confusion makes it hard to understand. See Seven Deadly Sins of Introductory Languages [PDF].

[Resistent]

It makes no sence that you learn ALL of the programming languages. If I would be you,
I would define my plan. "Which topic" should be me future work, also maybe, for "which company". Think about if first!
If you can program, then it is easy to learn a new programming language, IF you WILL NEED it as you start working.

I graduated in mechanical engineering, could start to work, but I studied also computer science to build up my knowledge.
My teachter told me, "If I would be you, I would not study computer science, you will have to learn and further educate yourself your whole life".
I told him, yes I know, I will make something special.

True, if you start as a programmer, like in Java, C#, Html, PHP .. and you start working with it, than you have no choice. If you don't educate your further all the time,
all the years in your life.. You will be replaced by younger programmers. As a programmer of a very common language, you are replaceable, ok, maybe you
also have more job opportunities, but you will be replaced with years if you get older and older. More concurrency.

So yes, it would be great if you became an expert of a "new" programming language. But how big is the chance that exacty "you" will be?? (beware of huge concurrency)
Look at the programmer market, as I told it before "make your plan". There are also companies who are looking for programmers of "old" languages. And as
nobody can program it (it's not teached any more), everybody would have to start from zero. So your chances to get the job rise.

My programming language biography looks like: HTML and PHP as a hobby, on university Java and C#.
And guess what I am programming now? PL/I from IBM, developed in the 1960 years.
I have great colleagues, no concurreny, I am not so easy replaceable as younger don't use PL/I.

But also, If I would be you, and I have industrial companies in my near, or where I want to live and work, I would check out the industrial companies which
kind of programmers they need. Work for them programming cars, vehicles, industrial plants, and so on. Or maybe they would send you around the globe for teaching the software for their vehicles, plant and so on. So what I mean, you have to look on the big picture first, than you can concentrate on programming IF NEEDED.

[ofnuts]

Functional programming has been around for a long as Lisp has and it's not a popular language

But it may have nothing to do with functional programming and much to do with Lisp itself.

[josephmills]

QT/QML !!!!!!! the best is for the best
http://qt-project.org/qt5

[shawnhcorey]

But it may have nothing to do with functional programming and much to do with Lisp itself.

A derivative of Lisp, Logo, was created for children and taught in some schools. Still, procedure programming is paramount. If people think in terms of functional programming, then why isn't some variation of Lisp popular? Could it be that people have a greater tendency to think in terms of procedures?