Best programming language to learn next?

[joco1500]

Hello all.

I have been learning all of the programming languages i can recently.
somewhat because i want to be a software engineer after i graduate high school and the other reason is because my friend wont stop bragging about the programs that he has made.

dont get me wrong. i already know c, c++, HTML, Javascript, and a little Java

but i know that there is bound to be one that pops up that has capabilities that the others dont.

thst's what im looking for.

a programming language that hasn't been wildly used yet. i want to be a master of it by the time it gets popular. if you guys know on one, please tell me of it




thank you in advance :)

ps. i dont want to have to compile them...i dont like waiting :)

[cortman]

Perl. Python.
If you know C I would say work with it the most.

[ehrt74]

A programming language which is coming very fast is Dart (http://www.dartlang.org/). There's a single download with a development environment.

Dart is a language for building web applications. It compiles down to (a subset of) javascript, though the ide comes with a version of chrome with the Dart virtual machine for faster debugging.

It's also a very simple language to learn, and has (a very few) neat ideas. If you start by thinking of it as Java done right, you'll get a long way. It's a fully open-source project with the backing of Google, so it's not going away anytime soon.

[King Dude]

The language "X10" that's currently being developed by IBM and has been in development since about 2004 I think.

http://x10-lang.org/

[Bufeu]

I would say Python or Perl.

[ofnuts]

a programming language that hasn't been wildly used yet. i want to be a master of it by the time it gets popular. if you guys know on one, please tell me of it

Plenty to choose from: Google for "popularity of computer languages" and pick the ones at the bottom of the list. Now, which one will be the next Java or Python, nobody really knows. Something that makes a language popular is that it's easy to learn and master, so your head start on a good language won't last very long. You should better put yousefl in a position to learn quickly (faster than others) a new language when it becomes popular (or useful). So widen your horizons and find languages that aren't like those you already know.


ps. i dont want to have to compile them...i dont like waiting :)

Find another job :)

[shawnhcorey]

Assembler.

Sooner or later, you will have to learn how the machine actually works. ;)

[King Dude]

I honestly believe you should learn X10, since you can mix it with Java and C++ libraries. It's also a brand new language (9 years old), whereas the previous suggestions of Python and Perl are fairly older languages (about 20+ years). Besides, Python and Perl programmers are common as hell, so a programmer who knows X10 may pan out to be more valuable later down the road.

In the world where processor cores are multiplying and parallel processing is becoming so extensive to the point where neither C++ nor Java can efficiently and easily handle by the average programmer, I can tell you now that languages like X10 will come out King in 20 years.

However, I strongly encourage that you browse yourself and read up on the pros and cons of a language.
Here's an article about X10 you should check out. http://www.byzantinereality.com/2010/10/My-First-Run-with-the-X10-Programming-Language


Assembler.

Sooner or later, you will have to learn how the machine actually works. ;)

I could not agree more, but he might not be interested in Operating System development.

[Mikeb85]

Hello all.

I have been learning all of the programming languages i can recently.
somewhat because i want to be a software engineer after i graduate high school and the other reason is because my friend wont stop bragging about the programs that he has made.

dont get me wrong. i already know c, c++, HTML, Javascript, and a little Java

but i know that there is bound to be one that pops up that has capabilities that the others dont.

thst's what im looking for.

a programming language that hasn't been wildly used yet. i want to be a master of it by the time it gets popular. if you guys know on one, please tell me of it




thank you in advance :)

ps. i dont want to have to compile them...i dont like waiting :)

Ruby, Python or Perl.

[Leuchten]

Scala. Has functional porgramming capabilities, is compatible with java, and you can stick with mostly imperative programming till you're more comfortable with immutable state and stuff.

[ehrt74]

I honestly believe you should learn X10, since you can mix it with Java and C++ libraries. It's also a brand new language (9 years old), whereas the previous suggestions of Python and Perl are fairly older languages (about 20+ years). Besides, Python and Perl programmers are common as hell, so a programmer who knows X10 may pan out to be more valuable later down the road.

In the world where processor cores are multiplying and parallel processing is becoming so extensive to the point where neither C++ nor Java can efficiently and easily handle by the average programmer, I can tell you now that languages like X10 will come out King in 20 years.



For the exact same reasons you may want to have a look at Go. This is a modern, open-source language with a large, active community and unparalleled support for concurrency. You can start programs with literally millions of threads and they still run fast.

http://golang.org/

[ofnuts]

You can start programs with literally millions of threads and they still run fast.

http://golang.org/
One millionth of a Core I5 isn't very fast, with the equivalent of a 2.5kHz clock...

[diesch]

a programming language that hasn't been wildly used yet. i want to be a master of it by the time it gets popular. if you guys know on one, please tell me of it


Have a look at Haskell. Functional programming is likely to get more popular and Haskell is is the best way to really get into pure functional programming, as in "No assignment, loops and such here. Have a look at pattern matching and recursion".
You'll mix it with imperative and/or OO programming later if you need that.

Knowing about imperative programming (like C), classic OOP (like C++), prototype based OOP (like Javascript) and functional programming (like Haskell) will most likely make you fit for whatever programming language you need/want to learn.

[shawnhcorey]

Knowing about imperative programming (like C), classic OOP (like C++), prototype based OOP (like Javascript) and functional programming (like Haskell) will most likely make you fit for whatever programming language you need/want to learn.

I still think that learning assembler after you know the basics of coding will give you more insight to what a computer is capable of. I would download one of the C64 emulators (http://www.zzap64.co.uk/c64/c64emulators.html) and have a go. The C64 used the 6502, an 8-bit CPU with 4 (IIRC) registers. Once you get a feel for it, you can try the real thing on your machine. ;)

[diesch]

I still think that learning assembler after you know the basics of coding will give you more insight to what a computer is capable of.

Maybe learning assembler will give you more insight to what a computer is capable of but it will not give you a new way of thinking about algorithms and programming like Haskell does. In some way learning assembler if you alread know C is like learning Old English if you already speak American English while Haskell is more like learning Mandarion or Arabic.

Even if you never use Haskell for production code (which is quite likely) it gives you another way of thinking about you code, and often you can transfer parts of that to other languages, especially to languages like Python or Scala that support parts of the functional paradigm.

[ehrt74]

One millionth of a Core I5 isn't very fast, with the equivalent of a 2.5kHz clock...


Mm, try to create and coordinate a million posix threads on a Core i5. You can do that with minimal overhead in Go.

[alexfish]

Hey


but i know that there is bound to be one that pops up that has capabilities that the others dont.

thst's what im looking for.

If U really Looking For something Different , U ever heard of BaCon ,

This is one of The Most diffent of languages I ever seen

the setting is a Basic Like Structure . has a easy to use Wrapper for GTK , + can include almost any Lib

The Resulting code is C , but once compiled by Bacon the Exec is Stand alone , First Stable Version now available for down-load

can mix "BASIC" structured commands with c ,

can only try , but a one worth a look , cost is 0,

http://www.basic-converter.org/


Have Fun

alexfish

[Greenbald]

In my opinion, you should not learn to program in various languages. You should really MASTER one language. This way you can make anything with this language. So you wont need to do certain things in a specific language. But i would say that Ruby/Python/Perl are good ones to learn now. Based on this site http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[xb12x]

Assembler.

Sooner or later, you will have to learn how the machine actually works. ;)

I think this is a common misconception.

Learning assembly programming will not necessarily teach you how a machine works. I've met many people that know how to write assembly but know next to nothing about how the machine works. And I've met many people that know next to nothing about writing assembly but are experts in how the machine works.

Most system-level code currently being developed is written in 'C. (and learning 'C' also will not necessarily teach you how the machine works).

The way to learn how the machine works is to read its documentation and specifications, etc. And _then_ write some code to see if you understand correctly what you read.

[WinterMadness]

Have a look at Haskell. Functional programming is likely to get more popular and Haskell is is the best way to really get into pure functional programming, as in "No assignment, loops and such here. Have a look at pattern matching and recursion".
You'll mix it with imperative and/or OO programming later if you need that.

Knowing about imperative programming (like C), classic OOP (like C++), prototype based OOP (like Javascript) and functional programming (like Haskell) will most likely make you fit for whatever programming language you need/want to learn.

Why do you think functional programming is going to get more popular? if anything, I think its going to be even more dead than it already is. It has a very very limited domain.

[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 (http://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 (http://lookatperl.blogspot.ca/2012/11/a-look-at-recursion.html) 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] (www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.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?

[WinterMadness]

I think imperative languages make more sense for people, because you are free to list instructions in a way thats more akin to our spoken languages. In functional programming you're forced to think the way the compiler wants you to, and that makes things difficult a lot of times, which is why languages like lisp have the reputation they do.

[Leuchten]

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?

Argumentum ad populum (http://en.wikipedia.org/wiki/Argumentum_ad_populum) is a fallacy. Don't try to draw conclusions using it.

Also, I learned logo as a child. I also learned basic. Guess which one made me give up programming for years.

[The Cog]

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:

Yes, I'm torn between go and erlang. But go had already been mentioned whereas erlang had not.

And I have my doubts about the reliability of go's libraries. I had a long discussion with them about a bug in their json-rpc library, in that it didn't meet the standard. It had extra restrictions on the types of arguments you could use - the call to the server had to put all arguments into a single argument that was an interface{}[] list. E.g. instead of sending add(1, 2) it send add([1, 2]). The client could not send requests to a server that expected separate arguments, and the server couldn't offer a service that accepted separate arguments. The library developer's final answer was "that's the way it's designed.". Their client couldn't use my existing jsonrpc server, and their server couldn't even be tested as a replacement for my server. So they don't seem to be very interested in making go universal - just enough for their in-house use. As a go beginner, I spent a few hours trying to get my head round introspection enough to write a working server, but lost interest in the end.

[ehrt74]

Yes, I'm torn between go and erlang. But go had already been mentioned whereas erlang had not.

And I have my doubts about the reliability of go's libraries. I had a long discussion with them about a bug in their json-rpc library, in that it didn't meet the standard. It had extra restrictions on the types of arguments you could use - the call to the server had to put all arguments into a single argument that was an interface{}[] list. E.g. instead of sending add(1, 2) it send add([1, 2]). The client could not send requests to a server that expected separate arguments, and the server couldn't offer a service that accepted separate arguments. The library developer's final answer was "that's the way it's designed.". Their client couldn't use my existing jsonrpc server, and their server couldn't even be tested as a replacement for my server. So they don't seem to be very interested in making go universal - just enough for their in-house use. As a go beginner, I spent a few hours trying to get my head round introspection enough to write a working server, but lost interest in the end.

That does seem odd. Go is extremely standard-conform for most things, and the standard libraries are quite exhaustive. I've posted a reply to your post on the mailing list requesting clarification.
On the plus side, modifying the standard libraries to support arguments according to the rpc2 spec should be farely trivial.

[The Cog]

That does seem odd. Go is extremely standard-conform for most things, and the standard libraries are quite exhaustive. I've posted a reply to your post on the mailing list requesting clarification.
On the plus side, modifying the standard libraries to support arguments according to the rpc2 spec should be farely trivial.
I though it would be fairly easy to modify the libraries, but then decided it might be better to leave them alone and write separate server/client modules instead. I don't want to have to keep a forked copy of the standard libraries going. But as I say, I got bogged down in the introspection side of things and gave up in the end.

Maybe I was unlucky in picking that particular library to play with while getting familiar with the language. I was quite keen until then.

[ehrt74]

I though it would be fairly easy to modify the libraries, but then decided it might be better to leave them alone and write separate server/client modules instead. I don't want to have to keep a forked copy of the standard libraries going. But as I say, I got bogged down in the introspection side of things and gave up in the end.

Maybe I was unlucky in picking that particular library to play with while getting familiar with the language. I was quite keen until then.


I haven't had any problems yet with the csv or json parser libraries, so I have high hopes with the others.

Correcting the client code of jsonrpc to support multiple arguments seems to me to mean changing two lines of code, but I'm probably wrong because I don't do much Go programming:

in https://github.com/jnwhiteh/golang/blob/master/src/pkg/net/rpc/jsonrpc/client.go starting line 45:


type clientRequest struct {
Method string `json:"method"`
Params [1]interface{} `json:"params"`
Id uint64 `json:"id"`
}


func (c *clientCodec) WriteRequest(r *rpc.Request, param interface{}) error {
c.mutex.Lock()
c.pending[r.Seq] = r.ServiceMethod
c.mutex.Unlock()
c.req.Method = r.ServiceMethod
c.req.Params[0] = param
c.req.Id = r.Seq
return c.enc.Encode(&c.req)
}
will become

type clientRequest struct {
Method string `json:"method"`
Params []interface{} `json:"params"`
Id uint64 `json:"id"`
}


func (c *clientCodec) WriteRequest(r *rpc.Request, param interface{}) error {
c.mutex.Lock()
c.pending[r.Seq] = r.ServiceMethod
c.mutex.Unlock()
c.req.Method = r.ServiceMethod
c.req.Params = param
c.req.Id = r.Seq
return c.enc.Encode(&c.req)
}

I'll compile it and see what happens :)

----------------


Nope, sorry, doesn't work. There's a whole chain of interfaces et al. which need to be modified as well. Probably easier to roll your own.

[Mikeb85]

I think imperative languages make more sense for people, because you are free to list instructions in a way thats more akin to our spoken languages. In functional programming you're forced to think the way the compiler wants you to, and that makes things difficult a lot of times, which is why languages like lisp have the reputation they do.

Functional programming actually has a very high level of abstraction, it allows you to think in algorithms and use real math (not x = x + 1). Lisp isn't really a functional language - it can be, but you can also use procedural and object-oriented styles.

Functional programming is akin to making a bunch of recipes, many of which rely on the previous ones, and then telling the computer which recipes to use, as opposed to simply explaining the instructions as you go. As a non-programmer myself, I've found functional programming pretty easy to grasp (OCaml mostly), although Haskell seems alot more difficult. Also, the most popular scripting languages (Python, Ruby, Javascript) have alot of 'functional' features, which no doubt contributes to their popularity. You can write Ruby in an OCaml-like way if you want... (and likewise OCaml has classes and objects)

[The Cog]

@ehrt74:
Thanks for trying. That's pretty-much the sequence I went through. Then got hopelessly lost in trying to call use reflection to turn the arguments into the right types and call the server method. Json integers (42, 99) un-marshall as float64 values.

@Leuchten:
I have only had a quick look at erlang, but what I've seen makes me suspect that with familiarity, a programmer might be more sure he's got it right (fewer bugs) with functional programming. I think that its being so radically different to imperative languages which people are more familiar with might be the reason it's not more popular. Think VHS vs betamax, where betamax was the better format but VHS became well known first.

[WinterMadness]

Functional programming actually has a very high level of abstraction, it allows you to think in algorithms and use real math (not x = x + 1). Lisp isn't really a functional language - it can be, but you can also use procedural and object-oriented styles.

Functional programming is akin to making a bunch of recipes, many of which rely on the previous ones, and then telling the computer which recipes to use, as opposed to simply explaining the instructions as you go. As a non-programmer myself, I've found functional programming pretty easy to grasp (OCaml mostly), although Haskell seems alot more difficult. Also, the most popular scripting languages (Python, Ruby, Javascript) have alot of 'functional' features, which no doubt contributes to their popularity. You can write Ruby in an OCaml-like way if you want... (and likewise OCaml has classes and objects)

Your analogy works with imperative programming as well, but it seems like you may have a strong mathematical background(just an assumption really, I could be wrong), which to me, makes it seem unsurprising that you would like functional programming. People who come from math first backgrounds tend to really like FP, whereas, people who just like programming (without saying anything about what they think about mathematics) tend to go imperative. Like I said before, I think imperative programming just makes more sense with natural language, even if there are some weird mathematical oddities as you pointed out.

[trent.josephsen]

Functional programming actually has a very high level of abstraction
And therein lies the problem. More abstraction is not always a good thing. Even when it makes the problem itself simpler, it can still make the solution harder to understand. In particular, abstraction in inexpert hands more often becomes a tool of obfuscation. (See also several comments about Java in another recent thread.)

I have nothing against functional programming, but I suspect it will always live in a niche. Given the choice between making it easy for mediocre programmers to get boring stuff done, and making it easy for good programmers to get amazing stuff done, guess where the money is? (Hint: most programmers are mediocre, and most tasks are boring.)

[alan9800]

IMHO to try to develop (as far as it is possible) the same program with a functional language (for programmers used to use imperative languages) or with an imperative language (for programmers used to use functional languages) may be a good way for better understanding in how many ways a problem may be solved or something may be done.

[Mikeb85]

Your analogy works with imperative programming as well, but it seems like you may have a strong mathematical background(just an assumption really, I could be wrong), which to me, makes it seem unsurprising that you would like functional programming. People who come from math first backgrounds tend to really like FP, whereas, people who just like programming (without saying anything about what they think about mathematics) tend to go imperative. Like I said before, I think imperative programming just makes more sense with natural language, even if there are some weird mathematical oddities as you pointed out.

I've got a background in Finance, so math-y type stuff, but nothing too crazy or abstract. I definitely don't have a computer science background, nor do I ever plan on working as a programmer. I do find when I want to solve a problem (usually related to finance), I tend to write functional-style code (even in Ruby - pattern matching FTW!!). Maybe it isn't coincidence...

[Mikeb85]

Why do you think functional programming is going to get more popular? if anything, I think its going to be even more dead than it already is. It has a very very limited domain.

Functional programming is great for concurrency and distributed computing since data is immutable by default. Many mainstream languages also already have, or are adding functional features. Examples are Ruby, Javascript, Python... There's also several new languages with functional features that have become fairly popular, namely Scala, Clojure, and Microsoft's F#. Pure functional languages will likely never be popular, but functional programming is creeping into imperative, OO languages...

This reminds me, a recommendation for the OP is OCaml, if Haskell seems too esoteric. OCaml has much more familiar syntax, some OO features, and the compiler can do some very cool things (compile bytecode into Javascript, JVM bytecode, and much more).

[alan9800]

a recommendation for the OP is OCaml, if Haskell seems too esoteric. OCaml has much more familiar syntax, some OO features, and the compiler can do some very cool things (compile bytecode into Javascript, JVM bytecode, and much more).I agree: indeed I'm not very skilled in programming nor in mathematics, however, as far as I've had the possibility to compare imperative languages (Python and Ruby) with functional languages (OCaml), it has seemed to me that even people like me can be able to learn how to program with functional languages, obviously with a lot of patience and accepting to make a lot of errors during their learning curve.

[Leuchten]

I've got a background in Finance, so math-y type stuff, but nothing too crazy or abstract. I definitely don't have a computer science background, nor do I ever plan on working as a programmer. I do find when I want to solve a problem (usually related to finance), I tend to write functional-style code (even in Ruby - pattern matching FTW!!). Maybe it isn't coincidence...

I don't think it's because you have a background in math, I think it's because you do not have a background in CS to start with.

When I go back to college, most of what I have left is math classes as I have yet to complete courses like calculus II. I don't completely suck at math, but it's definitely not anywhere close to my strongest subject and to claim I have a background in it would be laughable.

I really and truly believe the problems most programmers have with functional programming is that it deals with problems in completely different ways than imperative programs tend to. Instead of mutating state all over the place, functional programs (especially purely functional languages) mainly keep things immutable. Instead of using while loops, they usually use recursive functions. I think a lot of experienced programmers see this stuff, think "this is hard for me to do, so it must be hard for a new programmer to do" when it's actually hard for them to do because they rarely if ever have to use these techniques in their career.

As for functional programming staying in it's niche, a good example of the growing adoption of functional techniques is the new Rust (http://www.rust-lang.org/) language by Mozilla. It's a strongly typed object oriented systems programming language on the level of c and c++, and it uses type classes instead of inheritance to handle object relationships, a concept originally created in Haskell. It also has pattern matching, lambdas, and all variables are immutable by default (though you can request mutability on a variable).

[ehrt74]

And therein lies the problem. More abstraction is not always a good thing. Even when it makes the problem itself simpler, it can still make the solution harder to understand. In particular, abstraction in inexpert hands more often becomes a tool of obfuscation. (See also several comments about Java in another recent thread.)

I have nothing against functional programming, but I suspect it will always live in a niche. Given the choice between making it easy for mediocre programmers to get boring stuff done, and making it easy for good programmers to get amazing stuff done, guess where the money is? (Hint: most programmers are mediocre, and most tasks are boring.)


Exactly! I often find when trying to teach programming to beginners that starting with a register machine is easiest. Then you can gradually explore why functions or data structures exist. Then they can begin to understand what protected static void etc. mean.

[trent.josephsen]

I don't think it's because you have a background in math, I think it's because you do not have a background in CS to start with. [...]

I really and truly believe the problems most programmers have with functional programming is that it deals with problems in completely different ways than imperative programs tend to. Instead of mutating state all over the place, functional programs (especially purely functional languages) mainly keep things immutable. Instead of using while loops, they usually use recursive functions. I think a lot of experienced programmers see this stuff, think "this is hard for me to do, so it must be hard for a new programmer to do" when it's actually hard for them to do because they rarely if ever have to use these techniques in their career.

So the problem with functional programming is the state of CS education? Much as I'd like to get behind that, I'd say the opposite is more nearly true. People who favor FP are often academics and amateurs. I'm saying that FP will stay in its niche precisely because of its high levels of abstraction. Recursion is a higher level technique than iteration; it's more general, harder to implement in hardware, and requires modeling the problem in a more abstract space, which is hard for some people. Saying it's just about familiarity sees only one side of the issue.

[alan9800]

Recursion is a higher level technique than iteration; it's more general, harder to implement in hardware, and requires modeling the problem in a more abstract space, which is hard for some people. Saying it's just about familiarity sees only one side of the issue.OCaml offers both of the possibilities, since it includes the "for" and the "while" constructs beside the "let rec", thus you may choose each time which of these to use.

[Leuchten]

OCaml offers both of the possibilities, since it includes the "for" and the "while" constructs beside the "let rec", thus you may choose each time which of these to use.

Ocaml seems pretty nice and I've been wanting to look into it, but I'm currently employed to program in Scala and I wanted to master it before I learned a new language, and the lack of threading is kind of a turn off.


So the problem with functional programming is the state of CS education? Much as I'd like to get behind that, I'd say the opposite is more nearly true. People who favor FP are often academics and amateurs. I'm saying that FP will stay in its niche precisely because of its high levels of abstraction. Recursion is a higher level technique than iteration; it's more general, harder to implement in hardware, and requires modeling the problem in a more abstract space, which is hard for some people. Saying it's just about familiarity sees only one side of the issue.

I really don't get the "too much abstraction" arguments. As programmers, we are waist deep in abstraction daily. I have no idea how qt is implemented, or swing, or plenty of other toolkits, but that doesn't stop me from writing UIs. I have no idea how many registers the amd64 architecture has, or what they are used for, but I can do arbitrary precision arithmetic. How is the level of abstraction between a recursive method and a while loop automatically a stumbling block for a beginner when the abstraction between println("hello world") and the machine is so much greater, and yet they manage?

[Mikeb85]

Ocaml seems pretty nice and I've been wanting to look into it, but I'm currently employed to program in Scala and I wanted to master it before I learned a new language, and the lack of threading is kind of a turn off.

OCaml has threading, concurrency and distributed programming libraries, but they're a more recent addition and not part of the standard library.

That being said, Scala looks very nice, it has plenty of functional features, as well as OO features.

Another language I was looking at today is Rust, which seems like the bastard offspring of C, C++, OCaml, Erlang and Ruby, but in a nice way. Mozilla has already made Javascript the default language for our browsers, I wonder if they can pull of the same with Rust?

[Leuchten]

OCaml has threading, concurrency and distributed programming libraries, but they're a more recent addition and not part of the standard library.

That being said, Scala looks very nice, it has plenty of functional features, as well as OO features.

Another language I was looking at today is Rust, which seems like the bastard offspring of C, C++, OCaml, Erlang and Ruby, but in a nice way. Mozilla has already made Javascript the default language for our browsers, I wonder if they can pull of the same with Rust?

I am legitimately excited about rust. It looks to be fast and it looks to be really flexible for a systems programming language.

I didn't realize that ocaml had concurrency libraries, very glad to hear that.

[trent.josephsen]

As programmers, we are waist deep in abstraction daily. I have no idea how qt is implemented, or swing, or plenty of other toolkits, but that doesn't stop me from writing UIs. I have no idea how many registers the amd64 architecture has, or what they are used for, but I can do arbitrary precision arithmetic. How is the level of abstraction between a recursive method and a while loop automatically a stumbling block for a beginner when the abstraction between println("hello world") and the machine is so much greater, and yet they manage?

Not technological abstraction. You can implement recursive and iterative solutions in assembly language and the mental problem-solving model is still different. But I think this thread passed the point of zero productivity several posts back so I won't continue.

[alexfish]

Not technological abstraction. You can implement recursive and iterative solutions in assembly language and the mental problem-solving model is still different. But I think this thread passed the point of zero productivity several posts back so I won't continue.

My thoughts also .

let the purist's who think "This is the way it must be Done" , get on with it , or better still move their post's

Do not A Seven year old will Understand what they are talking about anyway.

Att the end of the day , these are the very comments and values which stall learning and inovation of the Inquisitve Mind.

BR

Alex

[joco1500]

You guys do know that i didn't want you to argue over which is the better language, but what i should learn next.

thank you for all your help, but maybe a admin can make a sticky thread for this stuff

[trent.josephsen]

All sufficiently long-lived threads eventually deteriorate into one of the same few recurring discussions. The subjective nature of the topic made it pretty much inevitable.

Did you still have unanswered questions?

[ofnuts]

All sufficiently long-lived threads eventually deteriorate into one of the same few recurring discussions. The subjective nature of the topic made it pretty much inevitable.
The Godwin point is reached when someone mentions punch cards :)

[Mikeb85]

You guys do know that i didn't want you to argue over which is the better language, but what i should learn next.

thank you for all your help, but maybe a admin can make a sticky thread for this stuff

Learn Ruby next. It's super flexible, it has OO features and many functional features (closures, pattern matching, currying, etc...), you can make things in it very quickly, and even if you decide not to make any applications with it, it's fantastic for scripting.