As I understood from reading on both Haskell + OCaml the latter has everything the former has plus the imperative part. So, if my understanding is correct, you won't lose anything concept-wise learning OCaml.

When some time ago I was considering learning a functional language, I first came across Haskell, and it is indeed very elegant, but than I learned about OCaml, and came to the conclusion that I would rather learn the latter. Alas, I had to put it away, but I learned some things about functional languages and realized that Perl has many features of functional languages and that I had already been using a lot of them - I simply hadn't known the term :).

...

In the past I also had exposure to Prolog, and during that time I learned how back-tracking parsers work.

...

AFAIK, Haskell and OCaml communities are cross-friendly.

Two languages I think are worth learning more for what learning them will tell you about programming other languages, than for actually programming in them:

Assembler and Lisp

I generally don't like special purpose languages and I don't think any special purpose languages have important concepts in them that would make them worth learning for some purpose other than being able to use them. So after assembler and Lisp, I'm not impressed with any of the other proposed languages to be learned for its ideas rather than for its practical use.

Thanks for your input.

LISP is definitely great. I'm hearing a lot about it.

And yeah, although the only thing i know about it is that it's pretty much one step above machine-code, i'm generally for understanding what goes on beneath whatever you do, so Assembly is under my list of prime languages to learn.


But don't be so pessimistic about the others. It's something you're supposed to do in your spare time anyway... Depends, after all, on if you actually enjoy it i guess.

Then I'll make an important suggestion there, especially if you already know C or C++:

Lots of tutorials focus on obsolete versions of x86 assembler and/or on writing small programs in assembler. That is a waste of time.

The thing to learn in assembler is how to write small functions that can be called from C (or called from C++ but with a C interface).

That is the role in which assembler might actually be useful, but more importantly, it is the role in which knowing assembler will help you design, debug, and profile projects in other languages. All the random nonsense that goes into just being a program in assembler and/or doing simple I/O in assembler is a waste of time. Learning that aspect of assembler won't leverage anything else. But if you learn the parts and aspects of assembler that are needed to write a function to be called from C, you have learned the foundation of almost everything that happens in the computer.

The assembler architecture to learn is whatever one you normally compile C programs in. Too many tutorials teach 32 bit x86 assembler on 64 bit platforms or even 16 bit x86 on 32 bit platforms.

I decided to learn myself, and I'm starting with perl. The ones I am interested in are Perl, Java, c/c++, php, sql. I started with perl because I have a lot of irc experience and you can write a bot/client with relative ease. Some form of visual basic would be interesting also. Those seem to me the languages you "see everyday".

LISP is monumentary/legendary, and for a reason, but I think it is not strictly typed.

If I'm correct on strict typing, then a more interesting language would be the one which is strictly typed or, at least, both strictly and loosely typed.

What is an interesting language ?
 

----
Hello

If you want to understand what programming is, have first a look at Dijkstra texts [URL="http:://www.cs.utexas.edu/users/EWD/"] and avoid any kind of imperative languages like C,C++, Java. Choose a good functionnal language like Haskell or Caml (OCaml) you will be forced to think the good (logical) way, as Dijkstra pointed it out.

By the way don't listen to gurus (they are programming in C,C++ and Java) and you already know by (bad) experience as a software user what kind of (bad) quality their very tricky codes achieve.

Best.
F.C.

Oh, in that case Assembly Language... absolutely!!

I’d also recommend learning a basic (non Object-Driven) Pascal, after all it was developed as a teaching language, and as such the structure is much better to learn on than C or Perl etc; you can write bad code in C and Perl much easier than you can in Pascal.

If you want to hurt your brain, learn AWK ;)


These all have very different ‘boundaries’ but learning them all will give you a better understanding of programming IMO



Ps. The Vectrex in a very neat machine to write assembly for.

How about x86? its the most common and you can write useful programs without an emulator.

Well the Vectrex has a Motorola 68A09 processor, so it is an early varient of the X86 family.

I just think it's an interesting machine to program, there are good rom routeans, and I just love the vector graphics!

With the processor running at 1.5MHz you have to watch how you are coding as well, sloppy code will produce bad results.

You do know thats a 1/3 of an 8088, right?
Sure, lets all learn languages that are useless/outdated instead of the one your OS is written in!

Err, your point being ;)


I have to write VB and ASPX .net code for money during the day, tinkering around with some proper-nut’s-and-bolts stuff on my old machines now-and-againe keeps me grounded.

I don't like modern languages; I want to go back to the Eighties. :D

I've been programming for a living for almost 20 years, and I interview and hire young programmers regularly.

There is no bigger waste of time in my opinion than spending time thinking about which language you should use for something. Most of the bright young programmers that I meet read about a language with an unusual feature, it piques their interest, and they write some program in it to try it out. We never start with a problem and then try to spend time deciding on which language to use. If you're in a group of 3 developers and they all know Python, maybe you'll start with Python, and if it doesn't work, you'll do something else. It's a much bigger challenge to figure out how the program will solve the problem, not figuring out how to implement the solution in the language.

The other thing that happens is that paradigms come, catch fire, and then burn out. When I was in school, OOP was the trend, then everyone was excited about automatic garbage collection, then there was excitement about type systems. Now we are in the midst of excitement over non-Lisp functional languages, and verifiable (i.e. statically analyzable) message-passing based languages like Sing#.

If you're familiar with a concept it is usually no big deal which of the languages you choose, since its likely that by the time you've heard of them, they've been vetted by language experts and are reasonably sound. For example, you won't go wrong learning either Erlang or Scala or Haskell, since you are probably using them for their functional features.

I would focus on making a list of the paradigms themselves, since many languages don't fit neatly into a single paradigm, and you may wind up understanding the concept poorly if you study only one languages implementation of it.

Definitely BASIC. Not that modern VB nonsense -- I'm talking Altair BASIC. Just don't forget your line numbers. ;)

Definitely C (a great compiled language, fast, used everywhere, as low level as it gets if not for assembly language)
C++ (because it's common)
Java (To really understand OOP)
Python (general-purpose scripting language, in my opinion it's better than Perl, but you can try both and choose)