Slashdot Mirror
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?"
You're right that if you know one C-style language you know them all, and in order to expand your development skills you should learn other styles of languages. However, a major problem is that there aren't so many references for non-C-style languages as there are for C(++), Java, Python, and Ruby. Though Lisp is something all developers should encounter, most Lisp books on the market are antiquated. (However, thank goodness for the relatively modern Practical Common Lisp by Seibel.) I wish there were more tutorials out there for the exotic languages that might really teach you new tricks.
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.
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.
Cretin - a powerful and flexible CD reencoder
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
FPGA != CPU
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.
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
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.
Being bitter is drinking poison and hoping someone else will die
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.
I got my Linux laptop at System76.
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.
Just to make this a little more clear for the practical minded: the end result can be learning JML, 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 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).
Craft Beer Programming T-shirts
*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:
(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:
(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...)
You might want to check out Io.
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 and have tools like ESC/Java2 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#, 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.
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 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; 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.
Craft Beer Programming T-shirts