What Programming Languages Should You Learn Next?

simoniker writes "Over at Dobbs Code Talk, Chris Diggins has been discussing programming languages beyond C++ or Java, suggesting options such as Ruby ('does a great job of showing how powerful a dynamic language can be, and leverages powerful ideas from Smalltalk, Perl, and Lisp') but suggesting Scala as a first choice ('Very accessible to programmers from different backgrounds.') What would your choice be for programmers extending beyond their normal boundaries?"

Re:Wrong Question

[Anonymous Cowpat]

ouch, still using f77.

Fortran90\95:

if (x == 1) then
*stuff*
end if

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Going from C to others is a matter of right boo

[nuzak]

> Thank goodness for the relatively modern Practical Common Lisp by Seibel

PCL is also free at http://gigamonkeys.com/book [gigamonkeys.com] -- I hate to deprive the authors of their royalties, but hey, it's their choice, and helps in making lisp more popular.

Unfortunately, I really can't stand CL's OBNOXIOUSLY-LONG-IDENTIFIERS that other languages often do with syntax. The purported lack of syntax is not a feature when you end up looking like COBOL with more parenthesis (yes that's hyperbole). There are CLOS workalikes available for most Scheme implementations that have all the features you'll ever use from the real deal (and it's not like most CL's have a 100% perfect CLOS). About the only really unique thing that CL brings to the table these days is conditions and restarts.

Re:Verilog

[exley]

Verilog is a hardware description language, not a programming language. It may look like a high-level language -- wire assignments look like variable assignments, module instantiations look like function calls -- but conceptually it's completely different. Furthermore I don't know how applicable it's going to be for anyone who works in software design, which is the audience this question seems geared towards.

Re:Verilog

[redhog]

It's not. It's a programming language for programming a type of CPU called an FPGA. It is a programming language (that is, it is turing complete), but the programming paradigm is rather different from that of an ALGOL language like C, even if the syntax is similar. But the difference in paradigm is not greater than the difference between C and e.g. Prolog.

If you are to learn new languages, I would suggest the following ones to learn the biggest number of different paradigms and features a language can have:

Assembly language (Low level, manual everything)
C (Low level, ALGOL-family structured programming, manual memmory management, pointers)
Scheme (Declarative/functional, has continuations, lazy-evaluation extentions, lambdas, code is data, real macros)
Smalltalk (Not just object oriented, but object centric)
Prolog (Declarative/Logic programming, code is data)
Verilog (No time-flow/full concurrency, emulates/describes hardware)

You could probably replace Scheme and Smalltalk with Erlang, but I don't know Erlang enough to be sure...

Re:Wrong Question

[krog]

Functional languages seek to express all operations as a chain of functions which operate on data and return other data. "Function" is used in its mathematical sense here. Purely functional languages discourage state, and don't allow mutable variables. The lack of state and mutability give rise to some power; effortless parallelizability, for instance.

Logic languages are something different altogether. They provide a framework for defining the rules of a system, then searching for answers which fit the given rules. Logic programming is not useful for general-purpose tasks, but can hugely reduce programming time in tasks which are difficult to solve any other way.

Re:SQL is next for me

[DJ Jones]

I must point out that SQL isn't a programming language, it's a query language.

But yes, it is useful to know.

Return to roots?

[Michael Iatrou]

Well, after C++ and Java it's a good idea to actually learn C. It still makes a big part of the world to go around, an it seems hard these days to find programmers who know how to write fast and secure code in C.

Re:Going from C to others is a matter of right boo

[WittyName]

Lisp is the mother of all languages. It can do everything. Even things just now becoming mainstream, like lambdas. Back in the day to get a CS degree you had to write a compiler in LISP. A bit of Asm so you know what the computer actually does.

For productivity, any high level language (.Net, Java, whatever has a lot of libraries)

At the command line, Msft PowerShell is powerful.

The libraries available are really the big thing for high productivity.

Re:Wrong Question

[jellomizer]

In general the difference between Logic based and functional is that in Logic Based you setup a relationship Say a Family Tree Structure and you can ask the program is Billy the Son of Robert. and it Will return a true of false. So the bulk of your work is setting up the logical rules. While in functional and procedural languages say for the family tree structure you will need to code methods of traversing the tree to get the answer.

Functional Languages such as LISP are like using one Line programs with calling functions for the parameters to get the data.

For Example (ADD(ADD(1,2),3) would return 6
vs
x=1+2
x=x+3
return x

Functional Languages are actually good with AI where you need to make a Tree (using Lists) relitivly easy to try to figure out all the possibilities that you can do.

Re:Verilog

[s800]

FPGA != CPU

Re:Wrong Question

[redhog]

Functional languages are just like procedural languages (Like C, Java etc), but with the important difference that everything is a function/works like a function, and returns a value. That is (in pseudo-code), you could write y = fie(if(x == 1, foo(), bar())) to assign either fie(foo()) or fie(bar()) to y depending on if x is equal to 1. You can usually create unnamed functions, assign functions to variables, returtn functions and pass functions as parameters to other functions too. It is also common for code to be a type of data structure (parse tree), which you can create programmatically if you want to and pass to an eval() function to get it run. In a procedural language you specify a function by describing what to do first, and then what after that and so on. In a functional language you specify a function by describing what other functions are taken together makes it up (the order is sort of implicit and not that important, only what is passed to what function).

Logic programming languages have no functions, or even a sense of time or order. The operate purely on truths/facts. In a way they are very similar to databases and database query languages, like SQL, but more powerfull. A program is a set of truths, e.g. facts like John is Adams father, Anna is Adams mother, Laura is Annas mother and rules like a is a mother of b and b is a mother of c implies a is a grandmother of c. You can then ask the program wether things are true, e.g. is Laura Adams grandmother? You can usually modify the fact database, have non-logic programming triggers fire when some things are asked for and generate queries on the fly from within a rule (code is data).

Re:Verilog

[Anonymous Coward]

It's a programming language for programming a type of CPU called an FPGA.

It's not. It's a hardware description language, so can be used in FPGAs, but is equally used for ASIC designs.

Furthermore, an FPGA is NOT a CPU of any kind. It's a configurable logic chip. You could program it as a CPU, but it's not one until you do.

Re:Going from C to others is a matter of right boo

[Serious Callers Only]

If you're looking for books on LISP, another book to consider is On Lisp. It's free to download from the following link as it's inexplicably out of print.

http://www.paulgraham.com/onlisptext.html [paulgraham.com]

Re:Wrong Question

[LarsWestergren]

Parallel programming is going to be a HUGE deal in coming years, and current languages don't handle it well - threading is complicated and prone to errors, leading to product delays. Erlang handles parallelism very elegantly and in a low-fault manner, as it must as it's used in critical telecoms applications. Unfortunately, the language also has a high barrier to entry as it is not Algol-based (like C, C++, Java, etc. are).

That might be why they recommend Scala. It is pretty easy to pick up if you know (for instance) Java, you have an "actors" library that is similar to Erlang concurrency, you gain some knowledge of functional programming (though not as much as from a pure functional language such as Lisp or ML, or so I'm told), you can deploy it on the JVM and interoperate with the huge number of existing Java libraries, and you can use existing IDEs such as Netbeans.

Re:Verilog

[CaptKilljoy]

>It's not. It's a programming language for programming a type of CPU called an FPGA. It is a programming language (that is, it is turing complete), but the programming paradigm is rather different from that of an ALGOL language like C, even if the syntax is similar.

Parent post is uninformed garbage.

Verilog is a hardware description language used to describe blocks of logic and the interconnections between them. It has only the most superficial similarities to a conventional procedural programming language.

FPGAs are the Swiss Army knife of digital logic, a large blob of programmable logic gates that can be configured to perform the function of any digital circuit that can fit within it. They do not normally contain a CPU and those that do use the CPU to supplement the gate array.

Re:Going from C to others is a matter of right boo

[grammar fascist]

About the only really unique thing that CL brings to the table these days is conditions and restarts.

And a powerful macro system. Scheme's is interesting, and you can do most anything with it, but certain things require a great deal of hoop-jumping.

Aside from conditions and restarts, macros seem like the last thing that hasn't sneaked into popular languages yet. For the uninitiated: imagine being able to write a function that, at compile time, takes and returns entire syntax trees. Or imagine if the C preprocessor let you write #defines that were full-fledged functions that had the entire language and runtime available during expansion.

Imagine if C let you hook into the tokenizer and the parser! Why, you could invent your own language for solving your problem, and then solve your problem in that language!

It's worth learning Common Lisp just to play with this stuff.

Re:Python?

[steveha]

I agree that Python is a good language to know. It's my favorite language.

I won't claim it's perfect, but IMHO it comes closest of any language I have tried to just letting me code up my thoughts. In any language, there is a certain amount of stuff you need to do to satisfy the syntax of the language; for example, in most languages you cannot do anything with a variable without declaring it first. Fans of Python sometimes claim that Python code looks like pseudocode, but with the extra advantage that it actually works.

Python has object-oriented features, functional programming features, and good-enough performance. It would be an ideal language for introducing a beginner to programming. When you do something that makes no sense, like trying to add an integer and a string, Python will catch it (Python is strongly typed) and Python will raise an exception. Some languages will magically convert types for you, but this can lead to subtle bugs.

Note that Google has standardized on four languages, and Python is one. (The list: Java, C++, Python, Javascript) Google has hired several important people from the Python community, including Guido van Rossum who created Python and still serves as Benevolent Dictator for Life.

I'm happy because my current job lets me do most of my work in Python, and we are doing cool stuff.

steveha

Lots of reasons to start out with Perl

[PerlPunk]

I can think of several good reasons why a beginner should learn Perl:

* It is easy to learn. Don't listen to what the Python advocates tell you. There are lots of good tutorials out there on the web.

* It introduces you to syntax which is similar to other well-used languages such as C and Java. If you're going to do Perl, you're probably doing CGI, and then moving over to Java and J2EE isn't as hard as learning it from the start.

* If you learn Perl first, then classic shell languages such as bourne shell, korn shell, etc., won't be so cryptic when you need to modify or write one (and you will need to at some point). Many of Perl's built-in variables are the same as what you'll find in those shells.

* Regexes - nearly every language out there has them now, but Perl has for a long time been the leader in regexes. In my opinion, Perl's regex syntax along with the Perl culture itself encourages their broad use. When you learn regexes from Perl and you move to another langauge that has libraries for them (e.g. Java or C#), you'll find support for them but you will also find that long-time developers in those languages won't use them as much. If and when they need to use one, and they know you're into regexes, they will come to you to ask you how to construct them.

* Windows API Support - outside of Microsoft only products, Perl's library of Win32 modules is virtually unmatched by other scripting languages. Although they have them, languages like Python and Ruby don't even come close in this area. This is important because someone starting out with a programming language will often be starting out on Windows, not a *NIX platform. If you are a Windows sysadmin trying to break out of VBScript and move on to better things, then Perl is for you.

* Lots of legacy systems in production today use Perl. I was in a company once that hired some Python biggots, who wanted to convert all the programs written in Perl code to Python (and get paid for it -- har har), but the IT manager wisely kept them in check. Perl is ported to almost every flavor of *NIX out there, and then some, and on many platforms it is part of the default install package. (Sun OS is one that comes to mind.) If you know Perl, you're useful when you come across it.

* Quick and dirty scripts. Sometimes you need something that you can use quickly and throw away. Perl is perfect for one liners executed at the command prompt and for multi-line utilities. Plus, there is instant gratification that comes from creating useful one-liners, kind of like an endorphin rush.

Re:None of the above...

[Coryoth]

Just to make this a little more clear for the practical minded: the end result can be learning JML [jmlspecs.org], a language that allows for annotations to Java (such as pre- and post-conditions for methods, assignability clauses for private variables, etc.). What benefit does that get you? Well you can use ESC/Java2 [kind.ucd.ie] to run a theorem prover over those assertions about how things are supposed to work to verify that you code will actually meet all the claims you make of it (which is great for catching subtle unlooked for conrner cases). You can use the jmlunit tool from JML itself to create an automated set of unit tests to exercise you code against your annotations, and you also get (via jmldoc) to have your requirement annotations automatically included in your javadoc api documentation. When you consider that, for a lot of code, you ought to be writing those methods requirements up in api documentation anyway, all the extra extremely rigorous (and static/compile time) checking is just gravy. So there is plenty of practical benefit that's easy to get. To make best use of it, of course, you do need to have some grounding in how this sort of thing works so you can write your specifications well (no different, in many ways, than having some grounding in how CPUs work so you can write more efficient code).

Re:Verilog

[david.given]

JavaScript/EcmaScript -- has nothing to do with Java. Dynamic everything, closures, first-class functions -- most of the Lisp-y goodness, but you already know the C-like syntax.

*shudder* Arrgh.

Javascript is not a nice language. It has all the features you say... but most of them are broken.

Dynamic everything? Yup, it's got that. Except that its primary data structure, the Object (an associative array, basically) coerces all keys into strings. This means that if you try to use another object as a key, it gets coerced into something like "[Object:0x12345678]", and that string is actually what's used... with hilarious results if you actually want to use the keys as anything other than simple hashes. Yes, this happens with numeric keys in arrays, too. And since all the data storage classes share method and data namespaces, which means you can't combine named and numbered items in an array without running the risk of overwriting the array methods.

First-class functions and methods? Yup, it's got that... with some *really weird* semantics when it comes to 'this'. Basically, if I have a function foo(), I can call it in three ways: foo(), object.foo(), or new foo(). Each way, the function gets called. 'this' gets assigned differently in each one. In the first, the current value of 'this' gets propagated into foo(). In the second, foo()'s 'this' gets set to 'object'. Yes, this means that these two lines behave differently:

object.foo();
var f = object.foo; f();

(The new foo() case is still pretty strange, but at least it's consistent with what you'd expect.)

C-like syntax? Yup, it's got that... but C-like syntax is entirely unsuited for a dynamic language like this, because a C-like syntax implies C-like semantics. Like var. var defines a local variable, right? No, it doesn't, it assigns a new value to the current object context. Which means the value remains valid after it looks like it's gone out of scope. Don't believe me? Open up Firefox's error console (in 'Tools') and try any of these lines:

var a=1; alert(a);
{ var a=2; } alert(a);
var a=3; { var a=4; } alert(a);

(The answers are 1, 2 and 4.) If you're used to C, C++, Java, C#, D, or any of the other horde of Algol-based languages, Javascript *lies* to you.

The fact that Javascript has closures is its one redeeming feature, IMO.

The thing about optional semicolons is pretty horrible, too. Try writing a parser for it some time.

If you're interested in dynamic languages, of which Javascript is one, I'd strongly suggest checking out Lua; it's way faster than Javascript, it has all of its features implemented in rather more consistent ways, and is so tiny that one person can understand the entire language (library included) with ease. I do most of my programming in it these days.

(I agree with all your other language choices, BTW; although I'd add Forth to the list as an example of a radically different low-level procedural language, and I'd emphasise Smalltalk more. Smalltalk is a beautiful language. All the shiny new language features people are rediscovering today, Smalltalk had in 1980. Concurrency, dynamicism, polymorphism, extreme programming, closures... it had 'em all. And nobody noticed. It's a shame...)

Sometimes, these things are mutually exclusive -- how do you have a purely-functional, lazily-evaluated language, and also make it simple and imperative?

You might want to check out Io [iolanguage.com].

Re:Wrong Question

[aleander]

No. And one day I'll find all those people who wrote FooMenager, BarMeneger, DeadQueueLenght and BeefDispather. And then I'll do something to them. And then I'll get those people who forced me to write comments in Polish.

Re:Wrong Question

[abigor]

Processes or threads? If processes, then you're right, it's not hard to control shared state and deterministically know when each process is accessing shared objects. If threads, the situation is much different - I work with a massively multithreaded app (100s of threads) as a developer, and the basic truth is that threading is fundamentally non-deterministic and very, very difficult to get right. It's not impossible, but it leads to a lot of wasted money chasing bugs that do nothing to contribute to the bottom line of the client.

Re:Wrong Question

[dargaud]

I agree with you about Erlang and really wanted to get into it. I spent a few days toying with it. Then I noticed that you can't produce an executable file, although it's compiled: it has to run within its environment application. Big no-no. Then it's excruciatingly slow. Then it has virtually no useful libraries. Within one year of existence, Python or Ruby had 50 times more libraries available. In other words I couldn't figure out what to do with it, just like with Logo's turtle after you've taken it around the screen a few times.

Re:None of the above...

[Coryoth]

I've taken a course on this in university. The tools I remember did basically an exhaustive search of all states in your program, and verified that there were no deadlocks and the properties you specified hold in every state.

Needless to say, this is very memory consuming, and can take a long time. So what you really get to verify is simple models, not your actual application with all its different variables. Also, the tools didn't grok Real World programming languages, so you had to write your model in a language other than the one you would eventually write your application in.

I can't comment as to what the OP does, but these days there are tools out there that will do the job fairly well. The tools I have in mind tend to sacrifice a little bit of certainty for a healthy dose of speed. That is, they won't guarantee that there are no errors, and they may in very odd cases, flag things that are not actually errors, but they will run fast -- taking about as long as a compile operation would -- and are quite usable on modern hardware. Don't, btw, be too disheartened by the lack of absolute guarantees; while these tools don't offer complete verification, their weakness is more theoretical: they catch many many errors (on par with unit testing for rigour, though often catching different kinds of errors) very efficiently.

As to the question of whether the tools grok Real World programming languages; the ones I'm thinming of certainly do. Usually they take a Real World programming language and extend it with annotations specifying behaviour, and then verify the actual code against the specification annotations.

That means that you can write Java, annotate your with JML [jmlspecs.org] and have tools like ESC/Java2 [kind.ucd.ie] do verification of the exact Java code you are about to compile against the specifications provided by the annotations. Note that you can get Eclipse plugins to integrate the extended checking right into your Eclipse session.

Alternatively, you can write C# and mark it up according to the extended language Spec# [microsoft.com], and have a theorem prover verifying your C# code against the Spec# verifications (which are just part of the code really) as you go. This is integrated into VisualStudio; you can see an early version of this at work from 2006 here [microsoft.com].

If you're willing to get a little more out there for Real World programming langauges, you also have the otion of using Eiffel with ESpec [yorku.ca] to provide an integrated workbench of theorem proving, automated unit testing, and acceptance testing in one package. There's also the option of going with Ada and using SPARK [praxis-his.com]; in this case you have to use a restricted subset of the full Ada language, but in return SPARK provides real soundness guarantees.

So I guess the answer is: yes, there are real tools that make this sort of approach practical and integrate well with Real World languages.

Re:Best Language to Learn Multithreaded Programmin

[piojo]

Are there any languages that are more efficient for multithreaded programing?

Well, if you are happy programming in a functional style, Haskell has fairly nice parallel capabilities. (However, the difference between Haskell and C++ or Java is so large that you probably oughtn't learn it if you aren't interested in the language for its own sake.)

The basic idea is this: in Haskell (or most other functional languages), you know that different function calls will not interfere with each other (everything is thread safe out of the box), so they can be evaluated in parallel. Function evaluations can be parallelized with the infix operator par. The following evaluates "part1" and "part2" in parallel, before storing them together, as a pair:

let result = (part1 `par` part2) `seq` (part1,part2)

No locks, no writing explicitly threadsafe code. I'm sure there are other languages that are good for parallelism, Haskell just happens to be the one I'm learning.

Re:Verilog

[mrchaotica]

Being a C# developer most of the time, I really wish I could pass the address of a public property to a method. That's about the only time I really wish I could use pointers.

But if you think about it, that doesn't make any sense anyway: the entire point of using a property instead of making the field it aliases public to begin with is that you want to restrict access through the getter and setter. Or in other words, if you could access the address of the field then you could bypass the getter and setter.

If you want to be able to access the field directly, then just make it a public field instead of a property. If you want to access the property of a class you didn't write, then the writer probably had some good reason not to make it a field (i.e. the getter and setter actually check or transform the data) and you should stop trying!

Arc

[dido]

Arc [arclanguage.com] looks like a promising new programming language that goes back to the roots of what Lisp should be. It's managed to build a reasonable community in a very short amount of time and there's a lot of buzz.

Re:Wrong Question

[gnalre]

Check out HiPe(High Performance Erlang), part of the erlang OTP which compiles erlang to native code