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?"

Comments

Verilog

[poindextrose]

If you know C, learn Verilog. Then you can do anything. Anything.

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:Verilog

[poindextrose]

I'm aware that it's an HDL. I learned a crapton of programming models and languages, and I found that there's nothing out there that's that great or really extended my ability to process data. Learning Verilog was easy and actually gave me access to new functionality that no programming language could. I know it's not a programming language, but it's my answer to people looking for a new programming language for a challenge or to enhance their skills. A programming language will not foot that bill, IMO. Maybe if you've never used an OO or Functional language, then you should learn one. Past that, they're just faster/better/easier/more ways to do the same thing.

Re:Verilog

[s800]

FPGA != CPU

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:Verilog

[cayenne8]

"C (Low level, ALGOL-family structured programming, manual memmory management, pointers)"

Uggh...pointers...BAD BAd bAD......no....not...the pointers again....[trembles]

I can deal with about anything, except pointers. Thanks for bringing the nightmares back again....

:-P

Re:Verilog

[AmaDaden]

I know it's not a programming language, but it's my answer to people looking for a new programming language for a challenge or to enhance their skills.

I fully agree. For most people an HDL is worthless but as programing exercise it's a interesting experience to say the least. And I would say look in to VHDL, it seems to be a more open competitor to Verilog but I must admit I've never used Verilog. Can someone summarize the differences?

Re:Verilog

[negro_monolito]

An FPGA is not a CPU. It is closer to a programmable ASIC (application specific IC).

Unlike a cpu, it doesn't have clock, instruction pointer, accumulator, etc. Sure it COULD have all that but then you would be the one programming that in. In fact there exist several softcore cpus like microblaze, etc.

An FPGA is more like a vast sea (or field) of disconnected NAND NOR gates. When you compile your verilog or vhdl code, the compiler literally 'wires' together these gates. (Actually it uses LUTs that mimic gates but you get the idea).

Re:Verilog

[shoor]

Pointers are OK. In fact they're cool! At least I thought so. But then, I spent 5 years programming in assembly languages before I learned C.

Re:Verilog

[Sponge Bath]

Verilog is a hardware description language, not a programming language.

It's both! Writing synthesizeable Verilog (or direct structural descriptions) is more hardware oriented, writing Verilog behavioral models and simulations is more programming language, and I would say the two 'views' overlap in both cases.

While I'm not sure how useful Verilog is for a strictly software developer, as a hardware and software developer I agree the combination of Verilog and C can't be beat. They are complimentary and knowing one often lends insight to using the other.

Re:Verilog

[neuromancer23]

except write a moderately maintainable web application

Re:Verilog

[exley]

This is a great example of mods and commenters (i.e. GP, currently modded informative) who don't know what the hell they're talking about. Parent post is correct -- while you can use Verilog for programming an FPGA (field-programmable gate array), Verilog has many uses in hardware design. It's called Verilog HDL (hardware description language) for a reason. Here is an overview of Verilog for the uninitiated.

Re:Verilog

[twistedsymphony]

Nice to see Assembly at the top of your list. There's something to be said for learning some form of assembly.

after learning C++, Java and a few others I decided to get into Microprocessor and Microcontroller programming and did so in whatever flavor of assembly the chip supported. I gained an entirely new respect and understanding about how these chips work on physical level as well as a much greater understanding about how inefficient most applications are and the enormous potential for improvement, as well as the enormous potential of modern CPUs and how much that potential is squandered on what people actually use them for.

I've developed a number of embedded applications now and the way I think about other applications has really changed too. My next language will probably be Verilog because the price of FGPAs has dropped significantly and they are incredibly versatile tools if you know how to use them... some of the things I've seen people use them for are mind boggling

Re:Verilog

[CapitanMutanda]

Erlang you say? Please elaborate. I daily work on a commercial product that is deeply based on Erlang and would only suggest it to some enemy. Smalltalk is wonderfully, too early in time. Maybe ADA but never did real work with it.

But please no Erlang

Re:Verilog

[daserver]

I like your description of the languages but Erlang can not replace either Scheme er Smalltalk. Erlang, while a functional languges, is very primitive. They instead they focus on parallelism rather than macros and continuations. Smalltalk, was that a joke aimed at Armstrong? :-)

Re:Verilog

[ShatteredArm]

What's so difficult about pointers? Even C# and Java use pointers, you're just forced to dereference them every time you use them.

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:Verilog

[lazyforker]

I've always been a fan of INTERCAL. If you can learn it you can learn anything.

Re:Verilog

[SanityInAnarchy]

I'd suggest erlang for its own sake -- a parallel programming model that doesn't suck as much as threads with locks.

• C -- you think you know it, because you know C++, but you really don't. Also, if you're on Unix, you'll need it at some point.
• 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.
• Haskell -- purely functional programming, lazy-evaluation.
• Erlang -- pervasive message passing as a language construct.
• Ruby -- beautiful syntactic sugar for most of the JavaScript/Lisp tricks you learned elsewhere. Nice for domain-specific languages, too.

Disclaimer: I don't actually know Smalltalk (Squeak won't run on my machine), Prolog, Verilog, or Scheme. I did learn Lisp, once upon a time.

Also: I think that while we do have languages that are good for specific tasks, every language I've tried is missing something I consider to be critical.

Sometimes I'm able to bring it in -- with JavaScript, I can almost emulate Ruby's iterators (each, collect, etc). But sometimes, it's something more pervasive -- for instance, while most languages support some kind of threads, they often allow supporting libraries to be written in such a way that they break when used in threads, and some of my favorite languages (Ruby, Python, Perl) don't support real OS threads actually running in parallel. (Python has a Global Interpreter Lock, and Ruby seems to be about to adopt the same, meaning that a single process of each won't be able to really take advantage of multicore/multiprocessor systems.)

Sometimes, these things are mutually exclusive -- how do you have a purely-functional, lazily-evaluated language, and also make it simple and imperative? But most of the ones I care about aren't -- there's no reason a language like Ruby couldn't be written to be fast, bytecode-compiled, and truly threaded. There's no reason a language like Erlang has to have non-variable variables and ass-ugly syntax.

Re:Verilog

[fpgaprogrammer]

Alternatively, in VHDL:

FPGA /= CPU

It's tends to be harder to get an FPGA to "hello world" but it seems these days that all the cool kids are compiling their dataflow graphs into reconfigurable logic. If you want to be a 1337 fpga programmer, then you should learn Bluespec. Guarded atomic actions for the masses!

Or Excel

Re:Verilog

[Neil Hodges]

And what makes those two languages worse than C++ (for example) is that they don't have static objects! Well, for most cases; I know C# has static structs and simple datatypes (integers, floats, etc). So if you don't like references, stick with languages that don't force you to use them.

Re:Verilog

[encoderer]

True, but if you don't like references, you might ask yourself why you're in this business.

I mean, sure, pointer arithmetic can be complex and convoluted, but, conceptually, if you find if HARD, you may not have made the right career choices.

Same thing with other techniques that get lumped in the "hard" category like recursion, closures, etc.

Re:Verilog

[JebusIsLord]

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. This can still be done through reflection of course, but it is hundreds of times slower.

C# does have a static class though (similar to a java class with a private uncallable constructor). Is that what you mean by a static object?

Re:Verilog

[colmore]

Assembly, contrary to popular belief, is not manual everything. Write an assembler to find out. Memory isn't a big continuous page, and hardware doesn't maintain a stack for you.

I know, I know I'm nitpicking, but it's important to remember this so we keep the right amount of respect for the men (and in those days, very frequently women - "calculator" and "computer" used to be jobs for unmarried women who was good at figures. WWII ballistics? Those huge old log tables? Women did it. This held into the early days of electronic computers) who wrestled ones and zeros out of machines when every cycle really REALLY counted.

Re:Verilog

[Eli Gottlieb]

Same thing with other techniques that get lumped in the "hard" category like recursion, closures, etc. Pointers, recursion and closures are hard?

Dayyum, I must be in the right field.

Re:Verilog

[ShatteredArm]

And even pointer arithmetic only starts to get complex when you're dealing with multidimensional arrays and complex objects.

It's been a couple years since I've used C, but...
int myArray = new int[2] is the same as int* myArray = (int*)malloc(sizeof(int)*2)

myArray[2] is the same as *(myArray + 2 * sizeof(int))

Nothing really complex about that. Array indexers are just syntactical sugar.

Objects are even easier.

String* myStr = new String() is the same as String myStr = new String(), and you just use "." to access its members instead of "->" (but it really means the exact same thing), and you get rid of the C ".".

Honestly, the only somewhat difficult aspect of pointers is having to worry about scope (i.e., when memory needs to be deallocated). You're exactly correct--why are you in this business if you don't like dealing with the most fundamental concepts of computer programming? It's like being an actuary who hates dealing with financial math.

Re:Verilog

[shredswithpiks]

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

It can certainly be used to program an FPGA, but that is not the limitation of what it can "program." To clarify for others, Verilog is a description language: you don't build programs with it, you describe hardware layout. It's kind of misleading to refer to it as a programming language in my opinion. Verilog can be used (well, is used) to fab chips.

Anyway, discussing the paradigm difference between C and Verilog is like comparing a Buick to a Playstation. The languages are completely functionally different, and learning Verilog kind of requires you know something about Logic Circuit design outside of the language.

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.

Re:Verilog

[clampolo]

Can someone summarize the differences?

Basically VHDL is from the ADA/Pascal family of languages. And Verilog looks like old K&R C.

VHDL is used mostly in defense industries and outside the United States. Everywhere else, Verilog is more popular. Nothing you could do in either language that you couldn't do in the other. But the VHDL syntax looks a lot cleaner in my opinion. But the price to pay for this is that VHDL is a fatter language with many more constructs (it even has pointers--to make modeling easier.)

Re:Verilog

[Darfeld]

A FPGA is a little more than that. Some of thoses gates are connected and so you have clocks (yes, with an 's'), latch (baaaad!!!), flip flop, memory cells and sometimes even a reel cpu in it(but it is uncommon).

As for Verilog, it is a programming language. Just because it can describe hardware with it don't disqualify it. You can do the same things with C and VHDL. It's just a matter of compiler.

Re:Verilog

[heelrod]

Not true anymore.

FPGA's are being built with PPC cores now. So there. Verilog is a programming language

Re:Verilog

[redhog]

What is a CPU and what is a programming language? From a comp.sci. point of view, the input language of anything that can execute any algorithm, that is, that is turing complete, is a programming language.

Proof that an FPGA is turing complete:
An FPGA can emulate any set of gates and interconnections given a description of these as input.
A normal processor, e.g. a Z80 is a set of gates and interconnections.
Thus, an FPGA can emulate a Z80.
The Z80 assembler is turing complete.
Anything that can emulate something that is turing complete given the right input, is turing complete.
Thus, and FPGA is a turing complete machine and its input a programming language.

Re:Verilog

[s800]

But that doesn't mean that an FPGA is a CPU, nor that Verilog is used for "programming CPUs" as in the original post. So there yourself. I know you can get various (hard) cores on die with FPGAs.

Re:Verilog

[Your.Master]

myArray[2] is the same as *(myArray + 2 * sizeof(int)) Not quite. It's *(myArray + 2). Malloc takes a value in bytes because it doesn't have any idea of what type it's using (hence your cast), while a pointer dereference is "aware" of the type and so automatically handles the sizeof(int) thing. If, for some ungodly reason, you want to access something that is misaligned with respect to type, you need to fiddle with casting a bit more.

Therefore you can also reference myArray[2] in C as 2[myArray], if you have a fetish for being unclear.

Re:Verilog

[Richard Steiner]

Assembly, contrary to popular belief, is not manual everything. Write an assembler to find out. Memory isn't a big continuous page, and hardware doesn't maintain a stack for you.

A decent macroassembler will also allow you to perform all sort of nifty code generation tricks to make your life a lot easier (e.g., generating conditional/repetitive code sequences and conditional data tables at assembly time, etc.). Many of those tricks take time and effort to learn, but if you write a lot of assembler code it's probably worth your while to figure some of those features out.

Some mainframe macro assemblers are VERY sophisticated (I'm thinking about OS2200's @MASM here, but I'm sure there are others), and I've seen a MASM setup using PROCS in that environment which effectively emulates Pascal to some degree. And of course the stack-based Burroughs A-boxes use an ALGOL variant called NEWP (or ESPOL, or whatever), which is a bit more advanced syntactically than one would expect. :-) I've only seen a little of it, but it doesn't look like a traditional assembler to me at all...

Experienced assembler programmers can be quite productive. Not me, really -- I just dabble enough to get in trouble. :-)

Re:Verilog

[ShatteredArm]

My bad... Like I said, it's been a couple years. (That makes it even less complex, though) :P

What about if you have a void* pointer? In that case, do you have to cast it to the correct pointer type before dereferencing?

Re:Verilog

[kipman725]

Second verilog it will blow your mind certinaly did mine when I first rearlised that everything kind of goes on at once. I have only just started out learning it due to having to keep up with my achidemic studies making me tired but its good fun :D and you get to watch your projects on your desk if you have an FPGA dev board.

Re:Verilog

[CaptKilljoy]

>Z80 is a set of gates and interconnections.

By your asinine definition, a dump truck full of loose vacuum tubes is also Turing complete. There's the little matter of the actual structuring of the gates into something capable of satisfying Turing completeness that you left out.

Re:Verilog

[chromatic]

... some of my favorite languages (Ruby, Python, Perl) don't support real OS threads actually running in parallel.

Perl threads have their flaws (lots of memory copying), but they're native threads (unlike Ruby 1.8) and there's no GIL (unlike Python 2.x).

Re:Verilog

[CaptKilljoy]

>FPGA's are being built with PPC cores now. So there. Verilog is a programming language Fail. The PPC CPUs never even see anything derived from the Verilog. The netlists compiled from the Verilog are only used to configure the FPGA part of the chip.

Re:Verilog

[SETIGuy]

...

• C -- you think you know it, because you know C++, but you really don't. Also, if you're on Unix, you'll need it at some point.

... To your list above, I would add....

• C++ -- you think you know it, because you use C++, but you probably haven't used most of the features. Sit down and learn the rest of it. Besides, it may have changed in the last year.

(By you, I don't mean "you" specifically, but "you" generically.)

Re:Verilog

[GNUThomson]

I definitely recommend http://en.wikipedia.org/wiki/Brainfuck. Ever wondered how CPU feels when you remove its cooling fan? Here's your chance. Also letters, brackets and numbers are for wimps. Real men use http://en.wikipedia.org/wiki/Whitespace_(programming_language). Hello world in Brainfuck: ++++++++++[>+++++++>++++++++++>+++>+++.>+.+++++++..+++.>++. Hello world in whitespace:

Re:Verilog

[Bill, Shooter of Bul]

Is it that you can't deal with processors, or that you can't deal with programmers that can't deal with pointers. I fit in the latter case. If you've ever worked on a project in c that was written with pointers by programmer that had no idea what a pointer was... you'd understand the mother of all nightmares. Every little change, can potentially change the memory layout which causes their buffer overflows to hit meaningful code resulting in a crash completely unrelated to your change.

Re:Verilog

[beallj]

int myArray = new int[2] is the same as int* myArray = (int*)malloc(sizeof(int)*2) Close, but not quite the same. new int[2] also needs to store the length of the array somewhere, so that the right number of elements will later be destroyed by delete[]. C++ is tricksy that way. And myArray[2] is actually the same as *(MyArray + 2), not *(myArray + 2 * sizeof(int)) , as was pointed out above.

Re:Verilog

[smallfries]

Err... have you got some weird exotic hardware in mind?

In x86 protected mode memory is a single contiguous address range. Sure it is split into different pages but that is not something that you have to deal with as a programmer. Hardware does maintain a stack for you on most architectures. On x86 it's done with a dedicated register and standard addressing modes to build the frame.

It's been a while since I've programmed in Z80, or in 68k, but most other CPU architectures also have contiguous addressing and hardware stacks. The only chips that I've used that don't are PIC microcontrollers.

Re:Verilog

[multi io]

First-class functions and methods? Yup, it's got that... with some *really weird* semantics when it comes to 'this'. ... The fact that Javascript has closures is its one redeeming feature, IMO.

Yeah, but closures and first-class functions constitute a more universal concept than OOP and weird "this" semantics. So, if you know what you're doing, you can pretty much forget "this" and JS's weird built-in OOP semantics and use the closures feature to implement your own way of doing OOP with it. Basically, the designers of JS grounded the language on a Smalltalk/Lisp-like feature set, and in the end tacked some Java syntax as well as familar-looking keywords like "this" on top of it to make the whole thing more appealing to Java people.

Re:Verilog

[siufish]

- FPGA is NOT a type of CPU. That is as ridiculous as saying breadboard is a type of motherboard. An FPGA is basically a bunch of programmable logic components, and you can make it to do anything you want. It can also be programmed as a CPU, but it would be rather slow.
- Programming language does NOT have to be Turing complete. Almost all useful languages are, but that is not the definition.
- You can add in gate delays in Verilog/VHDL which describes more realistic components.

I still remember using only NAND gates to design a 16-bit pipelined RISC CPU in college. That was fun.

Re:Verilog

[cayenne8]

"Pointers, recursion and closures are hard?"

I dunno...I just never could get pointers. I could do recursion...not a problem, and I've pretty much been able to figure out and use anything else I've needed, but, I just couldn't get pointers. So...never really programmed in C. I've dome scripting languages, worked with Object Pascal (old Delphi stuff), Java....PHP, and I've done a LOT with Oracle's PL/SQL,worked with PeopleCode, I did some stuff with Forte a long time back...etc.

Luckily, so far professionally...I've never had to deal with C, and hence..never had to mess with pointers.

:-)

I found it is easy to work and make a good bit of $$, and never have to mess with pointers.

Re:Verilog

[bishiraver]

Boggles my mind that you can't do this in C#, but you can in JavaScript!

Idiot Savant programming language...

Re:Verilog

[cibyr]

I'm currently doing a digital logic design course doing VHDL, and I keep thinking the software engineers should have to learn this stuff. It really makes you think about concurrent processes properly - everything happens at the same time. Aren't we headed for excessive numbers of CPU cores and a dearth of people capable of writing code that will actually use them?

Re:Verilog

[riceboy50]

Maybe it's just me, but it doesn't seem like anyone has mentioned the fact that you completely misunderstood the GP.

Then you can do anything. They meant then you can do software and hardware development.

Verilog is a hardware description language, not a programming language. Exactly.

Re:Verilog

[Mad Merlin]

Erlang you say? Please elaborate. I daily work on a commercial product that is deeply based on Erlang and would only suggest it to some enemy. Smalltalk is wonderfully, too early in time. Maybe ADA but never did real work with it.

But please no Erlang

Even without having ever used Erlang, I feel no hesitation in saying that Ada is worse.

Re:Verilog

[ModMeFlamebait]

What about if you have a void* pointer? In that case, do you have to cast it to the correct pointer type before dereferencing?

Yes.

Re:Verilog

[ShatteredArm]

Er, I guess I meant adding rather than dereferencing... As in, (int*)(myPtr + 1) wouldn't work, but (int*)myPtr + 1 would...

Re:Verilog

[mrchaotica]

What about if you have a void* pointer? In that case, do you have to cast it to the correct pointer type before dereferencing?

Yes, because you aren't allowed to dereference a void pointer, period -- it's a syntax error. Think about it: what would you dereference it to, void (which isn't actually a type)?

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!

Re:Verilog

[Mitchell Mebane]

... malloc has to store the size somewhere too, ya know. Free doesn't just magically know how much memory to free. Also, the other major difference between new and malloc is that new will call the default constructor on every object in the array, while malloc will not.

Re:Verilog

[aidan folkes]

Boggles my mind that you can't do this in C#, but you can in JavaScript!

C# has pointer types: http://msdn2.microsoft.com/en-us/library/y31yhkeb(VS.80).aspx

Re:Verilog

[petermgreen]

An FPGA is more like a vast sea (or field) of disconnected NAND NOR gates.
maybe some old FPGAs were (and old MPGAs certainly were)

A typical fpga is a sea of logic units connected by some form of interconnect system. A logic unit typcially contains one or more flip-flops (used as latches and registers) and a lookup table system used to implement logic functions. They often also contain dedicated carry chain logic (addition and subtraction are pretty common in digital design and having dedicated logic for the carry chains can really speed them up).

The interconnect system will generally have a small number of dedicated clock distribution paths as well as the normal data paths to keep clock skew down (clock skew is bad).

Most higher end FPGAs have some dedicated stuff such as PLLs, multipliers etc.

Re:Verilog

[petermgreen]

VHDL and verilog are a bit weired in the sense that they were originally designed as a method of describing hardware so it could be simulated and were later (ab)used for synthisis. This means that there are a lot of constructs that are perfectly legal verilog but will either cause an error in the synthisis tool or will synthisize to give different behaviour from thier simulation beaviour.

Re:Verilog

[Anonymous Coward]

why reflection?. you should use in this case delegates that are more or less the same than a pointer to a method, and for properties you use references.

Re:Verilog

[mako1138]

An FPGA's configuration bitstream is typically not Turing complete. Only the high-end FPGAs (Virtex-5) can reconfigure themselves on the fly.

Re:Verilog

[JavaRob]

True, but if you don't like references, you might ask yourself why you're in this business.

I mean, sure, pointer arithmetic can be complex and convoluted, but, conceptually, if you find if HARD, you may not have made the right career choices.

Same thing with other techniques that get lumped in the "hard" category like recursion, closures, etc. There are different kinds of "hard".
I don't remember finding pointers hard as in "I can't understand how these work"... I found them hard as in, "this is annoying, and why am I spending so much time triple-checking that I haven't fouled up memory management and pointer manipulation instead focusing on the *actual* problem I'm trying to solve?".

Recursion is a different kind of thing; it can make it much *simpler* to solve some problems, which saves me time and effort at the cost of a little practice to wrap my head around it at first. Same thing with closures, which I've been using a lot of lately in JavaScript.

Alas (for a mostly-Java developer), Java screws up recursion that goes too deep (stack overflow, huh?), and closures haven't even made it in yet. They're working on both of those issues, though.... At least the memory management & pointer approach works well.

Re:Verilog

[SanityInAnarchy]

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]"...

I guess I'm struggling to see when using something else as a key would be something you'd want to do.

First-class functions and methods? Yup, it's got that... with some *really weird* semantics when it comes to 'this'.

They're actually about what I'd expect, but maybe that's because I did so much JavaScript development.

Also, I learned how to use call() and apply(), and I'm missing these occasionally in Ruby -- it seems unnecessarily difficult to just hijack a method and apply it to a different object.

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

See, by now, I intuitively know to do:

var f = function() { object.foo(); }

But maybe that's because I used to abuse the callback system so much. I loved writing constructs like this:

some_list.sort(function(x, y) {
...
});

There's also this useful trick, for some of the other strangeness with 'this':

var that = this;

which allows the same value for 'that' to persist up through other closures. I'm not really sure there's a better way to do that.

var defines a local variable, right? No, it doesn't, it assigns a new value to the current object context.

Which is usually enough -- it's local to the function, and as I've just outlined, I use a ton of functions. When I want to define a scope just to define a scope:

(function() {
...
})();

Not pretty -- there are actually quite a few things I find ugly about JavaScript syntax -- but I haven't really found it to be unambiguous in a long time.

The thing about optional semicolons is pretty horrible, too.

They're not optional with the interpreter I was developing against, so not so much of an issue.

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...

Yeah, it looked really cool, but lack of x86_64 support was kind of a deal-breaker for me.

I will look at Io again...

Re:Verilog

[SanityInAnarchy]

I would argue that most C++ features are actually pretty uninteresting, once you know the rest of these. All they really do is add to the bloat -- sometimes hurting the syntax because of it. It's been awhile, but I remember a point at which you have to put a space between closing angle brackets in nested template definitions, because together, they'd be a bitwise shift operator.

So, if you have to work in C++, absolutely learn all the features. I don't think they contain quite the same kind of useful lessons as the other languages I mentioned, though -- when I program JavaScript, I'm still thinking in Ruby, and my code is better for it.

Re:Verilog

[ELProphet]

You did realize his comment was probably sarcastic, no?

Re:Verilog

[legonis]

First, by that you mean they are sharing the same package with PPC cores. Second, this is not now or anything recent, I remember Xilinx released one of these combos 5-6 years ago, and even then wasn't brand new. Last, you cant program the ppc core with verilog.

Re:Verilog

[theonlyaether]

Wow talk about taking things out of context....Lemme help you a bit:

A normal processor is a set of gates and interconnections, let's use a Z80 as an example of that. Please note that the Z80 assembler is turing complete. An FPGA can emulate any set of gates and interconnections given a description of these as input (I suppose this could include a dump truck full of loose vacuum tubes...but why?!) Protip: In this case we're talking about emulating a Z80, which is turing complete.

While I don't agree that the proof is solid, the logic is. It falls apart in that it only proves that an FPGA, given proper descriptions of input, can be turing complete, still not sure why we need to nitpick on the definition though of a normal processor though, which is clearly a Z80.

So yeah I edited the English, but the facts still retain the same logical structure. Any other strange questions/confusions?

Re:Verilog

[RobertM1968]

Define "crapton"...

;-)

Re:Verilog

[tokuchan]

What is a CPU and what is a programming language? From a comp.sci. point of view, the input language of anything that can execute any algorithm, that is, that is turing complete, is a programming language.

Proof that an FPGA is turing complete: snip...

An FPGA can emulate any set of gates and interconnections given a description of these as input. Actually, it can't. After all, for any FPGA you care to mention, I can pick a set of gates and interconnections that is larger than that FPGA can realize. So, I can pick turing machines that require more space than you can offer. You can use induction to show that this is always the case. Therefore, FPGA's are not Turing complete.

A normal processor, e.g. a Z80 is a set of gates and interconnections.
Thus, an FPGA can emulate a Z80.
The Z80 assembler is turing complete.
Anything that can emulate something that is turing complete given the right input, is turing complete.
Thus, and FPGA is a turing complete machine and its input a programming language. Funnily enough, you can show that real CPU's are no more powerful than a simple FSA, and are not Turing complete. This is because you can visualize all of the memory locations, register positions, etc as bits in a very big binary number of length n. Whenever anything happens, that number changes to another number of length n. Since there can never be more than 2^n possible states in this case, the number of states is finite and can be completely described by an FSA. Since that is the case there will be languages that this FSA cannot compute.

Re:Verilog

[the_greywolf]

I would argue that most C++ features are actually pretty uninteresting, once you know the rest of these. All they really do is add to the bloat -- sometimes hurting the syntax because of it. It's been awhile, but I remember a point at which you have to put a space between closing angle brackets in nested template definitions, because together, they'd be a bitwise shift operator.

That's because the C (and C++, among others) parser is greedy. You wouldn't, for example, parse << as < < would you? I agree that it makes template syntax a little awkward when you start nesting, but I hardly see that as hurting the syntax.

In any case, I think you're pointing blame in the wrong directions. C++ does have some flaws (the lack of things like closures in particular bothers me), but that doesn't mean it's not an incredibly powerful tool. (Closures can be simulated to some degree using partially-evaluated templates, and it achieves all of the desirable effects, albeit with slightly verbose syntax... boost::bind<>ing a boost::function<> to a boost::foreach() construct can get messy.) And no matter how long you use C++, you always discover new ways of approaching your problems (sister-class delegation being a good example of some recent epiphanies I've had).

Don't slag it off just because you don't like template syntax. :)

Re:Verilog

[Anonymous Coward]

I could give you a Java book, and by Monday you would be better than most Java pros. Takes a while to get used to generics implemented by erasure, no duck typing, and lack of multiple inheritance. I keep slamming into the wall of limitations imposed by the first. It's incredibly annoying to get halfway through implementing a pretty slick API only to realize that one key feature requires runtime access to parameterized type info, turning a constructor from foo<C>() into foo<C>(Class<C> c).

Re:Verilog

[sean4u]

Maybe you should have been +5 Funny, but not +4 Insightful.

An FPGA might very well be able to do very little. See Adrian Thompson's page, especially his 1990s work on evolving FPGA circuits.

'An FPGA' could be a very limited device.

Re:Verilog

[Fulcrum of Evil]

You can fake closures with interfaces or anonymous instances of abstract classes (with abstract methods defined). I don't think allowing the closure to ref stuff in the calling function works that well in tightly typed languages like Java.

Re:Verilog

[teh loon]

I believe career choice has more to do with interest than aptitude, although certainly, a certain degree of skill is needed.
If you're interested enough, given more time you'll definitely be able to pickup the needed skill.
However, a person who resents doing his job is less likely to be willing to pickup any other skill that he does not currently know.

Re:Verilog

[JAlexoi]

And by same analogy a modern CPU is a block of chemicals and should not be considered Turing complete, since without electricity it cannot do anything.

Re:Verilog

[aadvancedGIR]

As someone who design on both FPGA(VHDL) and DSP/uC(C/C++), I totally agree. The things are so differents I can't work on both during the same day. Only a good night of sleep allow me to reset my mind in the other mode and avoid madness.

However, it is interesting to note that both major FPGA manufacturers (Altera and Xilinx) now propose hybrid chips composed of one or few uC/uP cores embedded in the FPGA logic array, it allows to quickly build a custom chip with dedicated HW controlers driven by high level language running on a real OS.

Re:Verilog

[encoderer]

You're absolutely right about the ease of creating stack overflow conditions in Java.

I mean, this is an issue with recursion in ALL languages, but Java is worse than most. I'm not as learned in the internals of Java as I am of the languages I do daily, but my guess is that it has to do with the types that Java stores on the stack as opposed to the types that it stores on the heap.

Practically, the best way I've found to avoid overflow conditions is to limit the use of local variables as much as possible, and do most the work by passing down a reference to an object. Objects are stored on the heap, and the only thing on the stack in each recursive call is the local var that holds the reference.

Of course, it's impossible to entirely eliminate the use of local vars inside the recursive function, but limiting their use is essential.

And closures in JavaScript are awesome. JavaScript itself is a terribly awesome language. So many developers see JavaScript as, essentially, means to an end, only good for DOM manipulation. They're missing out on one of the better languages out there, right under their nose.

Re:Verilog

[maxume]

A lot of the 'this' wonkiness comes from implementation mistakes, and it is getting fixed(which, in the context of javascript being hard to replace in the browser space, is a good thing).

Re:Verilog

[yellowalienbaby]

well, a computer is a universal machine. Software that runs on the computer is the logical equivalent of building a specific hardware machine.

So, in theory, a hardware description language should be perfectly capable of defining a 'software' machine.

Re:Verilog

[Creepy]

INTERCAL is a bit like learning FORTRAN - it's a bit long of tooth - maybe try bf, unlambda, whitespace or my personal favorite, java2k. Any base 11 probabilistic programming language is tops in my book.

Re:Verilog

[russotto]

Pointers, recursion and closures are hard? Dayyum, I must be in the right field.

FORTRAN programming?

Re:Verilog

[prell]

Hiya twistedsymphony, I tried finding some way to PM you, but didn't find one, so I'll try here. After reading this thread, I read a little about FPGAs, and they sounds really really cool. What uses have you heard of for them so far? Do you have any recommended reading? How much would they be for me to buy? Is there an external peripheral you could get that houses one? Thanks!

Re:Verilog

[EvilBudMan]

ADA - the military uses it.

Re:Verilog

[twistedsymphony]

The best site I've found on them so far is http://www.fpga4fun.com/

Some of the cooler things I've seen built with them are data analysis tools, such as a compact digital oscilloscope, another was a decryption tool that was fast enough to capture decrypt and analyze data traveling across an encrypted system bus in real time (IIRC it was demoed on an Xbox 360).

The impression I get is that they're super powerful for performing straight forward repetitive tasks at high speed. This makes them capable of managing lots of high speed data such as Ethernet, video signals, or even system buses, it also makes them useful for encrypting/decrypting data streams in real time. It also makes the perfect for doing high speed conversions or switching.

Part of why I want to get into FPGAs is that unlike a Microcontroller or CPU that simply execute instructions in order, an FPGA is literally a logic array and can execute dozens if not hundreds of threads at once (you can of course make an array of FPGAs and have them function like one big FPGA as well). This also makes it really useful for robotic applications where lots of things need to be handled at once and executing commands sequentially can be quite a bottleneck in situations where speed is essential.

Re:Verilog

[redhog]

So, if turing completeness is not what makes it a _programming_ language, and describing algorithms to be executed on a turing complete machine is not the whole of programming, then what is? This is basicly straight out of my textbooks at uni so I am a bit bewildered... The interresting thing is that we only disagree on definitions - both of us agree about how an FPGA works (emulatong gates and interconnections described by its input), what it does. Only you don't want to call that "running programs", and I want to. Funny :P

Oh, btw, from the wikipedia article on "programming language":

A programming language is an artificial language that can be used to control the behavior of a machine, particularly a computer. ...
Programming languages are used to facilitate communication about the task of organizing and manipulating information, and to express algorithms precisely. Some authors restrict the term "programming language" to those languages that can express all possible algorithms;[2] sometimes the term "computer language" is used for more limited artificial languages.

So, by this definition, and restriction, verilog is indeed a ptogramming language (and since it can express all possible algorithms/is turing complete), it is not a mere "computer language".

Re:Verilog

[cytg.net]

After reading some of the academic stuff and conversing with ppl i know and trust, i was set on giving scala a shot.
However.
I am just a spoiled brat .. intellij idea and eclipse has just spoiled me rotten.. and while there exists a scala plugin for eclipse .. its shite! Both of them.
I am just not the kinda guy who messes around with yep another language just for the academic side of it .. if i dont see myself getting productive with it? ... its not happening.

Re:Verilog

[SanityInAnarchy]

That's because the C (and C++, among others) parser is greedy....

It's still an ambiguous case, and one that a newbie is fairly likely to hit. There are languages that have none of these problems (lisp), and languages that have far fewer of these problems (Ruby).

The closest I see to that with Ruby (or Perl) is the fact that both have a lot of syntax which is optional in cases where it can be implied. And most of the time, if you hit a case like this, the resolution is obvious -- just add more parentheses. The solution to issues like that template syntax thing is simply not as obvious.

that doesn't mean it's not an incredibly powerful tool.

I see it as powerful the way C is powerful -- Turing-complete, runs fast, and you can build other languages in it, if needed.

Yes, there are interesting things you can do with the object-orientedness. But they are not half as interesting as what is possible in newer languages, IMNSHO. A little basic reflection goes a long way, among other things...

Don't slag it off just because you don't like template syntax. :)

I also like open classes/modules, closures, mixins, and garbage collection, and I don't like such a strict static type system, pointers as integers, the operator overloading used for IO (seriously, std::cout

I mean, I don't like templates in general. I'm hooked on Ruby's duck typing.

I am sure that a lot of these can be worked around or tacked on in various ways, but why bother, when there are already better languages out there?

I suppose we bother because of performance (sometimes) and legacy projects. And maybe Windows drivers. But I can't really think of any other good reasons.

Re:Verilog

[try_anything]

I mean, this is an issue with recursion in ALL languages

In Stackless Python you get to keep recursing until you exhaust the heap :-) And of course tail-recursive languages mean no worries when you can express the function tail-recursively.

my guess is that it has to do with the types that Java stores on the stack as opposed to the types that it stores on the heap

Interesting. This suggests that Java does a better-than-average job of using stack allocation wherever possible instead of storing objects on the heap. It's more space-efficient overall, but it consumes stack space more quickly.

Practically, the best way I've found to avoid overflow conditions is to limit the use of local variables as much as possible, and do most the work by passing down a reference to an object. Objects are stored on the heap, and the only thing on the stack in each recursive call is the local var that holds the reference.

That's just an iterative loop, inefficiently implemented using recursion. Why not use 'for' or 'while'?

Re:Verilog

[try_anything]

Even C# and Java use pointers, you're just forced to dereference them every time you use them.

I don't know if there's a formal distinction between pointers and references, but in common usage the difference seems to be that you can explicitly perform arithmetic on pointers, but not on references. Pointer arithmetic destroys type safety, makes garbage collection problematic, and enables "clever" programmers to be very, very "clever."

(Sorry to give a pedantic response to your witty statement, but I'm sure there are some beginning programmers who appreciate the clarification.)

Re:Verilog

[Anonymous Coward]

I can deal with about anything, except pointers.

A girl? On slashdot!

Re:Verilog

[ariels]

To generalize:
Is it that you can't program, or you can't deal with programmers that can't program. I fit in the latter category. If you've ever worked on a project that was written by programmer that had no idea... you'd understand the mother of all nightmares. Every little change, can potentially change the variable contents which causes the logic to cause code to work resulting in a crash completely unrelated to your change.
Just not necessarily due to buffer overflows.

Re:Verilog

[Anonymous Coward]

But maybe that's because I used to abuse the callback system so much. I loved writing constructs like this:

some_list.sort(function(x, y) {
...
});

That's not abuse at all, it's an entirely appropriate use of anonymous functions.

Re:Verilog

[encoderer]

"That's just an iterative loop, inefficiently implemented using recursion. Why not use 'for' or 'while'?"

Not necessarily.

For example, a project I'm working on right now has a calculation-engine not entirely dissimilar to what you have in Excel. The major difference being that it doesn't implement a formula language. (Instead of a formula language, individual calculations are defined by creating a class that implements the ICalculation interface.)

Anyhoo, a major part of this system is a subsystem for identifying circular dependencies.

So it gathers all the dependency info for each calculation, combines it all into a single data structure, and recurses thru the structure looking for circular references. Originally, the class kept the data structure in a protected property, and the method doing the recursion would pass the current node and an array of its direct-line-of-dependents in the recursive call.

This created an overflow condition about 10% of the time.

So we made the original data structure a bit more complex, having it keep track of the current node and its direct dependents, and instead only passed a reference to that "bookmarked" node with each recursive call.

This is a problem that doesn't lend itself to iteration because we need to look vertically at the tree structure, looking directly up the tree to see what is in this direct-dependency line. That is, we need to process the data structure from Top-to-bottom, Left-To-Right. Whereas iterating thru the tree would be done in a (L2R, T2B) fashion.

And, sure, you CAN iterate in the needed fashion (T2B, L2R) but the code to do so would be MUCH more convoluted than iterating in a conventional (L2R, T2B) manner, and, indeed, more convoluted than the recursive solution.

Anyway, this is definitely an edge-case: There are many cases of recursion being used when iteration should be. But you can, indeed, limit stack space by keeping data outside of the method and only passing references down the stack, acting on the referenced data, and returning a boolean.

Re:Verilog

[ohmpossum]

Well lets see... First I learned

Applesoft BASIC in 1979 age 11.

6502 Machine Language (assembled on paper) in the early 80s

In college I was in the final class required to take FORTRAN

VAX Assembly Class

SPICE (many classes)

68000 Assembly for a Lab

ADA Class

Edited some C64 BASIC once

C and C++ projects in CG, Image Processing, etc classes.

VHDL

Learned enough HTML to make a web page around 1994 (Sun/Mosaic time frame)

Perl

Verilog

I have a book on Java and Java script but have never learned them.

I have a book on Ruby on Rails but I haven't cracked it.

I use VHDL and Verilog for ASIC design but at this point in time people assume if you design ASICS you use Verilog and if you design FPGAs you use VHDL. I use either depending on the situation and SPICE with a mixed signal simulator (Mixed as in analog AND digital with the same simulator)

Most software developers who want to do something with some hardware (finally get around to building that teledildonic robot girlfriend or robot war entry for example or just make a weather monitor interface) should learn VHDL and get a kit from one of the two big FPGA companies. Xilinx, and Altera. Your not going to make an ASIC unless you have hundreds of thousands of dollars handy to make masks and process wafers. Your money is better spent getting an EE degree in a program that lets you fab some parts

Re:Verilog

[ohmpossum]

Where am I even going to FIND a dump truck full of tubes?

Re:Verilog

[msoftsucks]

Take a look at delegates. They are objects that point to methods. They may not be as easy as just passing a pointer, but they do get the job done.

Re:Verilog

[Bill, Shooter of Bul]

Good point: Bad Programmers can cause random crashes regardless of any specific programming language element.

But, to be fair Many programmers tart off as bad. You just hope that they have someone there who transforms their badness to goodness.

Re:Verilog

[try_anything]

So we made the original data structure a bit more complex, having it keep track of the current node and its direct dependents, and instead only passed a reference to that "bookmarked" node with each recursive call.

Okay, I misread your original statement and thought the same object got passed in every call. With each call passing a different object, the stack is storing state for you (as well as the stack bookkeeping data that you don't care about) so it isn't entirely wasted space. Managing that state in a loop using your own Stack object would indeed destroy the simplicity of the code.

Re:Verilog

[PipsqueakOnAP133]

So, I can pick turing machines that require more space than you can offer. I probably just suck at proofs or don't remember correctly what defines a turing machine, but doesn't your statement also mean some processors/languages normally assumed to be turing machines are not because there exist bigger ones with more ram?

The way I'm seeing it is that given an infinite amount of RAM, and then either a FPGA configured to be a CPU through Verilog or any other CPU (say a R3000), they're either both turing machines or not.

Without a RAM limitation, any given set of gates and interconnections can be put onto a FPGA either directly, or emulated through a simpler set of gates and interconnects on the FPGA assisted by a freakin' huge chunk of software dumped into "infinite RAM".

Re:Verilog

[Annymouse Cowherd]

The real question is, do you know what AAA does, and more importantly, do you think AAA should even exist. Seriously, wtf is with all the random instructions that are never used that x86 and friends have?

Re:Verilog

[CableModemSniper]

What about if you have a void* pointer? In that case, do you have to cast it to the correct pointer type before dereferencing?

Yes.

Re:Verilog

[CableModemSniper]

Being able to pass a pointer to a public property (or a pair of getter/setter methods) isn't about bypassing the encapsulation. It's about abstracting away _which_ property (the name of it, and/or even the class or type of the object whose property you are manipulating).

Re:Verilog

[Anonymous Coward]

be able to pickup the needed skill
willing to pickup any other skill

"pick up". ("pickup" is a noun.)

Re:Verilog

[tokuchan]

So, I can pick turing machines that require more space than you can offer. I probably just suck at proofs or don't remember correctly what defines a turing machine, A turing machine is simply a finite state control coupled with an infinite tape and the ability to read a single symbol from that tape, write out a symbol to the current spot on the tape, and determine to move one spot left or right on the tape.

but doesn't your statement also mean some processors/languages normally assumed to be turing machines are not because there exist bigger ones with more ram? The basic argument to the proof is this: Think of a very simple machine, with some registers (at least an accumulator, a PC, and an IR), and a very small amount of RAM. Nothing more. You could visualize all of these registers and memory locations as boxes on a big sheet of paper. Now, line all of these boxes up one after another. Now you have a single, giant, register containing a single number. This number is of finite length, say N bits. Therefore, in binary, there can be no more than 2^N possible numbers that fit in that box. So, write down 2^N boxes, one for each possible number. Read off each of those numbers in turn, load them into the machine's registers and memory and step the clock one cycle. Now, note the new number (which is another of the 2^N states) and draw a line between the corresponding boxes. Do this for every number in the 2^N-sized set of numbers. The result, a finite state automaton, which is exactly equal to some regular expression. (Take the union of all of the accepted starting numbers that result in an "accepting" state where the machine halts.)

The way I'm seeing it is that given an infinite amount of RAM, and then either a FPGA configured to be a CPU through Verilog or any other CPU (say a R3000), they're either both turing machines or not.

Without a RAM limitation, any given set of gates and interconnections can be put onto a FPGA either directly, or emulated through a simpler set of gates and interconnects on the FPGA assisted by a freakin' huge chunk of software dumped into "infinite RAM". Remember, we have never yet built a machine with infinite RAM. Not only that, but we cannot even be certain such a machine could fit in our Universe. So, given an infinite amount of RAM, and a finite state machine, you have a Turing machine. My comment is that we don't have that first condition and probably never will. That means that none of the machines we have ever built are in fact Turing machines. They are merely very complex FSAs that can simulate a Turing machine well enough to get by.

Re:Verilog

[PipsqueakOnAP133]

Just wanted to reply that I thought that's a pretty nice and easy to understand explanation.

Re:Verilog

[tokuchan]

Why, thank you!

Re:Verilog

[prell]

They certainly seem very neat! Thanks for the info!

Yeah, what interests me is that you apparently could turn an algorithm (like decoding/encoding video) into an FPGA device/arrangement, and have it be tons faster. I'm also intrigued by the parallelism -- I'm not sure how much comes built into an FPGA chip.

Re:Verilog

[redhog]

Turing completeness does not require a machine to be a von Neuman machine.

Wrong Question

[jellomizer]

The question is flawed. Anyone worth their weight as a programmer doesn't care what language they
program in but. But Programing Methodoligy should they work with. Assuming that you use to
Object Orianted Languages (C++, Java, .NET) which are a deveation of Procedural Based Languges (C,
Pascal, FORTRAN). So after knowing those methodoligies perhaps you should study functional languages
(LISP, SCHEME, HASCAL) or Logic Based Languges (Prolog).

Procedural and Object Orianted languges tend to have the most programmers and is widly used

Functional comes next used in some Sciencetific applications as well handling a lot of AI type stuff.

Logical Lanagues are used less frequently because it is very tight sometimes too tight to expand into
a full application.

But most good programmers with experience in these languge classes are not normally worried about what
to program in. They may have their personal favorates but, can code sucessfully in any language
even if they never coded in it before. Because once you understand the classes the rest is just a
google search from finding the right command and syntax of the languge.

For example some differences between procedural Languges

        FORTRAN
                IF (X .EQ. 1) THEN
                END IF

        VB
                If (x = 1) then
                end if

        C
                if (x==1) {
                }

        Python
                if x == 1: ... ...
        BASIC
                IF ($X = 1) THEN
                END

Wow there are 5 different languges and they all look simular almost anyone would be able to figure it out

Re:Wrong Question

[Anonymous Cowpat]

ouch, still using f77.

Fortran90\95:

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

Re:Wrong Question

[Actually, I do RTFA]

Excellent comment. I'm currently looking at expanding into functional languages. I fail to understand the difference between functional languages and logic languages. Would you help enable my laziness by expounding a bit more on that?

Also, if you have a sciency-type application, could someone recommend a functional language to represent laws of physics (for example) in?

Re:Wrong Question

[ucblockhead]

Well...programmers usually care what languages they know when it comes to writing their resume. So while in one sense, you are current, in the career advancement sense, I'd go by what they want on Monster.com: (Java, Javascript, C, C++, Python, Perl, PHP.) True, any good programmer could pick any of those up in a few months (except maybe C++) but HR drones don't know that.

When I went to school, we were taught all these methodologies. (Though in my case I'm so old that OO programming was too new to be well taught.) I'd hope your average programmer would know them all before getting that first job. Sadly, I get the feeling I am mistaken.

But in general, I'd say, for instance, to use Javascript rather than Lisp as a functional language...not because it is better...not hardly...but because it is very marketable. (And sadly, most people with Javascript on their resumes have no clue it is anything but a Java clone.)

Re:Wrong Question

[MrEkted]

If you've never checked out Erlang, I recommend it. I've programmed seriously in at least a dozen languages, but this one really made me think. It has sophistication in concurrent programming that I've not seen before. Plus, there's a great movie!

Re:Wrong Question

[morgan_greywolf]

And then there's Korn/Bourne/bash scripting, which is procedural (duh), but seems to be in a category all by itself, because, like Perl, TIMTOWTDI:


if [ $x -eq 1 ]; then
fi


or:


if [ $x = 1 ]; then
fi


or even, the more obtuse:


[ $x -eq 1 ] && ....


Or, for some bash/kshisms:


if (( $x == 1 )); then
fi


I've seen more than one method used in the same script, too.

Re:Wrong Question

[jellomizer]

PRINT *, 'What is wrong with using FORTRAN 77? It is a perfectly fine lan'//
    1 'guage that offers the flexiblity for all generations.'
    PRINT *, 'Where else can I write code that will run on todays system and '//
    1 'still be able to back it up on punch cards for safe keeping that wil'//
    2 'l last for decades'

Re:Wrong Question

[abigor]

Yup, I'll second this. 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).

Re:Wrong Question

[Anonymous Coward]

After reading through jellomizer's post, I really wish he'd take the time to get a better grasp on the English language.

Re:Wrong Question

[tmarthal]

XMLRPC
SOAP
WS-*

Interface standards are becoming more than language specifications. People are more concerned now with API specifications (and language hooks into them) than the actual language (and OS!) that are used to call them. I think we (as a community of networked computers) are moving towards heterogeneous environments widely distributed.

If your C/C++/Perl/Fortran(yeah right)/VB have a well defined xmlrpc interface, it doesn't matter what the implementation of my code is.

So youre right that the question is flawed, everyone can program in whatever language they want, as long as the tools exist to export your logic to the outside world.

Re:Wrong Question

[MagicBox]

Bang on. I did nit agree with the article's narrow vision of "what most programer's background" is in. Today's programmer is not defined by the programming language he uses anymore, they are defined by how well they understand what they are building and coding for. I think a programmer should chose whatever they like to code in, s long as they:

1) Understand the problem, and their choice of coding language (or environment) is the right fit that will produce the best possible solution
2) Are able to adhere to the coding standards, write clean/readeable code, comment (or document it), and strive for efficiency any chance they get.

Personal pride in these matters is stupid.

In my career, having the ability to adapt has been a winnig strategy both professionally and from the employer's point of view.

One thing I can honestly say though: I despised the Java developers that would not touch one fucking line of code other than Java. They were the most unproductive programmers I have ever seen. I am not generalizing. I am speaking about those I had to deal with.

Re:Wrong Question

[tknd]

True, but now let's say you agreed that you are going to program in the OO methodology. Which language do you choose?

There are different reasons for choosing one language over another once you get past the classification of a language (procedural, functional, oo, logical). You will also often find that the industry will gravitate toward what has the cheapest cost for their task.

Re:Wrong Question

[Jeremiah Cornelius]

Learn LISP!

It has a funny name, and carries the mystique and credibility you seek. Nothing says "way old school" and "MIT Wizard" like piles of LISP with your tag on them. Of course, you'll have to leave vim behind - there is only one, true tool for the LISPer, now that dedicated machines like Symbolics are all in the museums.

The opportunities here are boundless - there are whole categories of libraries for HTTP and HTML that simple don't exist yet! If that seems to trivial a challenge, why not look into one of the projects to write and OS in LISP?

Re:Wrong Question

[Nimey]

AOL. I especially liked "sciencetific".

Re:Wrong Question

[Anonymous Coward]

        if (x-1) 10, 20, 50
10      goto 50
20      ...stuff....
        goto 50
50      ...

I don't need any of that fancy OO Fortran

Re:Wrong Question

[whtmarker]

First,
learn to spell (or install firefox2 which underlines textarea typos in red)
methodoligy => methodology
orianted=> oriented
deveation => deviation
languges => languages
widly => widely
sciencetific => scientific
favorates => favorites
sucessfully => successfully
simular => similar

Second,
Never misspell when you code (not comments). Those of us who do know how to spell have to remember which constants, database field names, class names, file names, functions are spelled incorrectly and exactly how it was incorrect to avoid bugs. Another way to introduce more bugs is to go back fix misspelled words.

In summary, bad spelling = bugs

Third,
People these days don't read books enough. They can be on any topic, but if you want to be an expert in your field, read books in your field. As you read you will encounter technical terms. If you weren't familiar with the word write it down. This is how to learn to spell. It is when you focus your reading on professionally edited content instead of user generated content (blogs) you can improve.

[Some people have severe learning disabilities and I sympathize with them, this post is obviously not directed to them]

Re:Wrong Question

[Critical Facilities]

I think if we're nitpicking, the BASIC example above is incorrect as well. This page shows an example of a properly coded IF statement (basically, there shouldn't be parentheses nor should there be a $ in FRONT of the variable name).

Re:Wrong Question

[EWIPlayer]

I'm sorry, but the parent comment is a bit "out there". If you had said something like, "Programmers don't care what language they program in, so long as they only want to be coding in one language just like they're coding in any other language", then maybe. But come on... It's talk like that which makes completely mediocre programmers. Do you know how long it takes to become truly proficient in C++ and OOP? Do you honestly want to tell me that you can come from Java (which doesn't destructors, for example) and simply apply your OO Java programming to C++ and be "good"?

Different languages exist because language A does not do what language B does. And, yes, they can contain a ton of the same kind of idea, which is exactly the reason you need to become highly proficient in them to get anything real out of them. You need to explore the differences not the similarities. I have worked with enough mediocre programmers and enough non-designers in my life, thanks very much. I want people to get deeper, very very deep into alternate languages so that they can broaden their thinking, not just their basic language skill set.

Learning a new language has little to do with that language and more to do with learning new ways of thinking. When I interview people that say that have any OO language, I grill them on OO more than I do on the intricacies of Java interfaces or C++ memory management. How you think is much more important to me than how many times it takes you to successfully compile a file.

Re:Wrong Question

[Kjella]

While what you say is true, I think it would take me a long, long time to be as effective in Java or C# as I am in C++/Qt. Don't get me wrong, I grok the basic syntax but I've found that being well versed in the standard library (ok so Qt isn't a standard library, but it almost replaces it) is something you only get with time. It's incredibly time-consuming if you're constantly looking up the manual to figure out what function to call, arguments to use and so on.

Yes, I can code in everything from javascript to VB, and I write good code in every language, but I wouldn't say I am good at coding in those languages. I don't think anyone can hold five different massively overlapping standard libs for five different languages in their mind at once without going crazy. One thing learning many different design patterns to learn how to write better code, but I definately subscribe to the idea of mastering one language rather than trying to be jack of all, master of none.

Re:Wrong Question

[Anonymous Coward]

I still have to say

IF (X-1) 20,10,20
10 *stuff*
20 *more stuff*

you insensitive clod!

Re:Wrong Question

[idontgno]

Agreed. It's a sad day on /. when I look at purported code examples and say to myself "Hmph. BASIC poser."

"BASIC poser" may be the saddest phrase in the geek sublanguage of the English language.

Re:Wrong Question

[John Betonschaar]

There's a lot more to programming in a specific programming language than just the syntax, you know. It will take even a very, very experienced C++ programmer a lot of time to master the most common Java or C# libraries, or to learn all the weird deviations of the traditional OO model that e.g. Delphi implements. C++ is relatively basic in the sense that it does not have a library of standard functions as large as Java, and still it takes years and years to get proficient in it, mostly because you have so many ways to do the same. What seems like a good idea in language X might be a very bad idea in language Y, although they might be very similar syntactically...

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:Wrong Question

[xZgf6xHx2uhoAj9D]

That's because the 5 languages he chose are all exactly the same language. Specifically, they're all imperative languages, i.e., languages with statements and variables. Try writing the same thing in languages without statements or variables and I think you'd find that they differ in more than just their syntax.

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:Wrong Question

[rijrunner]

There is another aspect to this.

Just learning a language is somewhat pointless. What are you learning the language for? Some languages do some things better than others. Some languages have entire corners of uses that many people never use.

If you are just going out and writing the same app in a different language, who cares? A lot of web stuff, it is irrelevant whether you use php, java, or whatever.

My first answer to the question "What would your choice be for programmers extending beyond their normal boundaries?" would be "quit writing the same crap".

If you've been writing cgi scripts, write a device driver. And use a language appropriate for it. If you're been writing the newest game that will blow everyone's socks off, write a Database app. Push your goals out there and the rest will follow. Stretch your goals into looking at the end goal and weighing the options in languages to get there. If all you are doing is jumping language to language at the same playground level, you're wasting your time. Languages are just a tool to build something, so build something. Something you have never done before. Unless your compiler is less than 20k in size, odds are you haven't explored a fraction of the versatility of the language you are using.

Bite off more than you can chew.

Re:Wrong Question

[WilyCoder]

Parent makes an excellent case for the study of computer science. Once you think in theoretical terms, the syntax of a language is just that, syntax. I'd +rep ya if I could :)

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:Wrong Question

[spottedkangaroo]

Javascript on their resumes have no clue it is anything but a Java clone.)

Um, not it isn't. It's ECMA and doesn't relate to java in any way. That was just a bad naming co-incidence.

Re:Wrong Question

[jellomizer]

The cheapest cost per task means whatever language is being used the most.

CS 101 normally starts with VB. and a lot of people with different majors take CS 101 as well it is taught in High School. So... There are more People who can do VB then other languages so there is a high supply for the language so the price will be lower.

C++/JAVA is only taught to CS and Engineering Majors so there is less of that.

FORTRAN has an aging population so it is very expensive.

Python/Perl/Ruby are limited to Unix/Linux people so still they are more expensive.

It is not about what languge is best or faster to code that makes it cheaper it is the cost of the programmers.

Re:Wrong Question

[tkelechogi]

What would your choice be for programmers extending beyond their normal boundaries? The question hit the nail on the head. Usually these threads try to predict the "next big thing" or discuss what high-paying job requirements are looking for. This question was surprisingly refreshing. I agree with what you're saying, but to become comfortable in any language, you need to expand beyond your normal comfort zone. If you typically use procedural languages, try OO. If you're an OO master, try functional, etc.

Re:Wrong Question

[jockeys]

Agreed. It's the singer, not the song.

Re:Wrong Question

[Kartoffel]

Curry that function! Then, ADD(1)(2)(3) returns 6.

Re:Wrong Question

[Schraegstrichpunkt]

The question is flawed. Anyone worth their weight as a programmer doesn't care what language they program in

If that's true, then why are new programming languages ever invented? Are new programming languages created by people who aren't "worth their weight as programmers"?

I dare you to write some non-trivial security-critical code in PHP.

Re:Wrong Question

[mini me]

Another example is Ruby. Syntax wise, it looks like some kind of Python/Perl hybrid. While you can write your program to be similar to Perl or Python, you really need to start exploring Ruby's metaprogramming abilities to fully utilize what the language has to offer.

Re:Wrong Question

[grahamd0]

But in general, I'd say, for instance, to use Javascript rather than Lisp as a functional language...not because it is better...not hardly...but because it is very marketable. (And sadly, most people with Javascript on their resumes have no clue it is anything but a Java clone.)

Which is why Douglas Crockford calls it the world's most misunderstood programming language.

Re:Wrong Question

[Anonymous Coward]

Read that again. It's an ambiguous statement (e.g. "That's a movie you can't watch too many times"). I think the original poster was thinking the same as you.

Re:Wrong Question

[street struttin']

But Programing Methodoligy should they work with. Assuming that you use to Object Orianted Languages (C++, Java, .NET) which are a deveation of Procedural Based Languges (C, Pascal, FORTRAN).

Procedural and Object Orianted languges tend to have the most programmers and is widly used

Functional comes next used in some Sciencetific applications as well handling a lot of AI type stuff.

Ouch. Obviously the language you should learn is ENGLISH.

Re:Wrong Question

[blueapples]

That was his point.

Re:Wrong Question

[Anonymous Coward]

[Some people have severe learning disabilities and I sympathize with them, this post is obviously not directed to them] would living in a non-english speaking country qualify as a severe learning disability?

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:Wrong Question

[glavenoid]

I remember reading a quote by Larry Wall that was something like "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in". Hmmmm. Makes you think :-)

Re:Wrong Question

[nahpets77]

I wish more companies would realize this when doing interviews. Asking language specific syntax questions is such a useless way to judge how well the candidate grasps the fundamentals. I find that too many HR departments rely on "syntax tests" that ask the candidate to de-mangle spaghetti code to prove they know the language syntax instead of conceptual stuff. And, as you said, specific syntax related issues can be solved with a quick Google search.

Re:Wrong Question

[CapitanMutanda]

Yup, I'll second this. 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). And verrrry error prone to parameter mismatch, sloppy code, quick&dirty coding. A sort of modern age APL. When I started working with Erlang it seemed like a great thing especially parallelism , distributed Erlang etc but reality in a telecom application is certainly sadder.

Re:Wrong Question

[ianare]

You bring up good points, but it's also important to look at other types of usage.
For example, a sysadmin: it is expected to know at least basic Perl AND Python AND sh/ksh. Otherwise you simply can't get work done effectively.
Hell, even just within a standard Linux Gnome or KDE install you've got a good half-dozen languages all doing their thing, usually talking well to each other, but sometimes not.

Or web development: PHP, Perl, Python, and JS if on unixy stack; ASP, VB, JS, and .NET if on the 'other one' (more of a guess here. haven't touched windows servers in years). Oh and possibly some form of SQL too or maybe even ruby.

These aren't usually design decisions (hopefully), but in the real world you come across all sorts of funky setups. And this is reflected in job openings. I've very rarely seen something like "web developper position - only has to know PHP".

Now, for application development, it does make a lot more sense to really specialize, often you only need to deal with your own stuff. Usually a company will standardize on a language. And again looking at job postings, requiring only Java, C#, or borland are not that uncommon.

Personally, I really dig wxWidgets/wxPython for the cross platform abilities, but it seems QT is making good progress on that. Unfortunately, neither is very marketable ... not saying you can't make money off it, but it is much harder to find open positions.

Re:Wrong Question

[grahamd0]

I believe the GP was referring to the misconceptions of the inexperienced, not the reality of the language.

Re:Wrong Question

[abigor]

Yeah, isn't that always the way. Well, I am an Erlang beginner and I doubt I'll ever use it professionally, so my take-away from it is that there are better alternatives to the nightmare that is massive, non-deterministic multithreading. I have no doubt that what you say is correct though.

Re:Wrong Question

[ucblockhead]

Uh...yeah...hence my annoyance that people put it on their resumes without having a clue that it isn't a Java clone.

Re:Wrong Question

[nicklott]

Any sane person would not be using fortran at all...

Re:Wrong Question

[Jack9]

Um, not it isn't. It's ECMA and doesn't relate to java in any way. That was just a bad naming co-incidence.

As a matter of fact, many javascript objects have properties and methods that are near-identical to Java counterparts. It's not just a bad naming coincidence, it's also a language that is Java-like in syntax.

Re:Wrong Question

[archen]

I think that also depends on just why you are learning a new language. Personally I would highly recommend Ruby for system administration. However thinking in Ruby isn't overly different than most other common languages. As such LISP is really cool in the fact that you not only gain a new language, but a new methodology in approaching problems - not just a new language with a different syntax. Prologue is another interesting language although much less useful than LISP in my opinion.

But if you're just looking to pad your resume, then I really don't think LISP will do you much good. It may look cool to the guy making the decisions, but you need to get past HR first, and they have no idea what LISP is nor do they care if you're smart enough to learn other languages.

Re:Wrong Question

[mollymoo]

The question is flawed. Anyone worth their weight as a programmer doesn't care what language they program in but. But Programing Methodoligy should they work with.

Certainly, once you know half a dozen languages picking up a new one with a paradigm you know is trivial and you can be writing code in half a day. But it takes time to learn the APIs, tricks and gotchas that make you a good $language programmer, rather than just a good programmer. Skills are transferable, but knowledge is much less so. I've seen far too many re-implementations of stuff that's already in the language or standard libraries; they generally worked in context, but rarely as efficiently or robustly and it's hardly optimal in terms of productivity.

Re:Wrong Question

[losing balance]

Your spelling is flawed. Why don't you learn English as your next language?

Re:Wrong Question

[Jack9]

The question is flawed. Anyone worth their weight as a programmer doesn't care what language they
program in.

Really? What kind of idiot programmers do you work with? My life is finite and my time is valuable. If you don't care what language you program in, you don't care what language you learn, and you must not care what framework you learn either. Heck, all languages and frameworks must be worth learning! Reality check: What kind of languages you spend time to learn, matters.

Much discussion goes into what languages my team will use for what project and why. We don't fear learning new languages, but even as individuals away from work, nobody wastes time learning languages that do not serve a purpose in the workplace or in our own personal projects just to "know them". I've dabbled in Erlang, Lisp, Perl, Python, Ruby, etc. Mostly Erlang. None of these languages would I claim to "know". I'm not going to learn any of them. It doesn't help me to know them right now or in the future AFAIK, which is the point.

Flex Actionscript programming I've had to learn and have taken Adobe classes to learn. I "know" Flex and the associated Cairngorn framework. It's been the most useful thing I've learned in a long long time. I'd recommend to anyone, learn Flex.

See, that's an answer, not this constant /. nonsense of "you're too dumb to ask the right question".

Re:Wrong Question

[maxwell demon]

Functional languages are just like procedural languages (Like C, Java etc)

Definitely not. In functional languages, functions are first-class citizens. You can use functions to operate on functions in order to build other functions. For example, a typical functional language thing is a function which takes two functions and returns the composition of both functions, i.e. the function f o g: x |-> f(g(x)). Yes, you can emulate that with function objects in C++, but that's equally clumsy as emulating OOP in C.

Re:Wrong Question

[Jack Greenbaum]

Perhaps you should have read the article more carefully. One of the five he suggests is Prolog, perhaps the second most commonly "spoken" declarative language next to SQL.

Re:Wrong Question

[ciggieposeur]

Learn LISP!

I did. I/O performance made it unusable for me though. :( In my case, I needed to analyze the output of molecular simulation packages, which meant converting several gigs of text floats into floats every day. Even using the parse-number package (which is *incredibly* fast compared to using the reader) it was about 4 orders of magnitude slower than C.

I was also a bit frustrated with the lack of portable threads, SQL, networking, Qt/GTK, and the god-awful pathname stuff in the standard (such that it is possible for a file to exist on the system that the Lisp process is unable to open without resorting to non-standard functions).

If I had to do webserver stuff I would probably try out Lisp again though.

Re:Wrong Question

[shakah]

Just because someone disagrees with you it doesn't mean they are smarter then you. The converse is true too.

Do you really mean "converse"? Wouldn't that be:

Just because someone is smarter than you doesn't mean they disagree with you?

Re:Wrong Question

[rbanffy]

"Methodoligy", "widly used", "very tight", "Sciencetific", "favorates", "deveation"?!

Why not English as your next language?

Now, seriously, I can't imagine how this got modded insightful. Funny, perhaps.

Before someone pretends to know many different programming languages (something that is a sign of a good programmer), the person should at least know how to spell their names. Haskell is called, well, "Haskell", not "HASCAL"

And a string in early BASIC (MS-BASIC, Applesoft, circa 1980) is named something like X$, not $X (would be a scalar type in Perl, but I can't imagine what you had in mind). And, BTW, you wouldn't compare it to an integer.

And, before you start comparing the most rudimentary constructs in 5 different languages (4, really and 4 somewhat similar ones) and bragging you can figure them all out, perhaps you should check a little deeper under their hood.

Even Slashdot has some Digg days...

Re:Wrong Question

[Jeremiah Cornelius]

And the "visual appeal" of Perl is...

# Tihs smplier rgexep is porablby all taht is nedeed, and the odelr
    # one ddin't work all the time anaywy. Cehck tihs out:
    #
    # setenv LANG en_US
    # echo -n "foo.bar" | \
    # perl -e '$_ = <>; print join (" | ", split (/([^\w]+)/)) . "\n";'
    # => "foo | . | bar"
    #
    # setenv LANG en_US.utf8
    # echo -n "foo.bar" | \
    # perl -e '$_ = <>; print join (" | ", split (/([^\w]+)/)) . "\n";'
    # => "foo.bar"
    #
    # perl-5.8.0-88, Red Hat 9

Re:Wrong Question

[asc99c]

I think many or even most applications can make use of parallel programming with relatively little real effort. Locks and other mechanisms are tricky to get your head around - the real trick is coming up with a design that doesn't need them, or at least minimises that need.

The systems I write store records in a database and minimising locking issues is really about thinking through the broad states that different tasks will deal with. So anything in state A is managed by task X and all other areas of the system should ignore state A (or at least, not change things out of this state).

This results in a much tidier system and much smaller and more readable code. The system I am currently working on has only about 5 background processes that will do most of the work, and the target hardware has 8 cores, so this leaves 3 for other bits and pieces but mainly for dealing with user interaction. If I need to aim at more cores, I know I can easily split the main 5 into about 12 processes without even having to think about locking.

Re:Wrong Question

[Estanislao Mart�nez]

Functional languages work by simplifying functional expressions according to the rules of the lambda calculus. Logic languages work by searching for combinations of values that satisfy a predicate, according to the rules of propositional logic (with predicate symbols, but without quantifiers).

Yeah, I know, that's kinda technical. Here's a more concrete example:

Re:Wrong Question

[Neil Hodges]

I'm not sure if Python's really a prerequisite there. Although Python's among my favorite languages, I was doing just fine with sysadmin tasks with Perl and a Bourne Shell variant. Heck, Perl makes a more effective replacement for complex shell scripts at times.

For lighter tasks, Awk works pretty well as far as I can tell, but I haven't had much time to write anything in it.

Re:Wrong Question

[hoggoth]

> I think we (as a community of networked computers)

Wintermute, is that you?

Re:Wrong Question

[MBGMorden]

BASIC has such fond memories for me. I was self-taught at it so I did the stupidest crap as a kid. I remember writing programs where I wanted a delay, and what did I do? Look for a command to do that? Of course not! Run a loop that counts up to some insane value before terminating and just count on the computer's slowness at traversing the loop to facilitate my delay :). That was back in the days of Commodore 64, when I didn't understand the difference between compiled and interpreted code. In my mind, everything was interpreted. When I got a PC a few years later and I opened up some .exe file to look inside I was horrified. I saw the binary file and thought "OMG - THIS is how I have to program this thing!?!?!?!". Luckily I found QBASIC shortly afterwards and kept playing around. Despite thinking of some things in completely backwards terms, having my knowledge of BASIC helped tremendously once I got into Computer Science in college.

Re:Wrong Question

[Jeremiah Cornelius]

"4 orders of magnitude slower than C"

OUCH!

I like replacing AJAX with ALAS (Asynchronous LISP and Static text). ;-)

Re:Wrong Question

[redhog]

I know all that, and had you actually read all of my post you'd realized that. I was only comparing them as opposed to logic programming, which is much more different.

And well, you can do functional programming in many structured languages (functiounction pointers in C, function objects, iterators and list comprehension in Python), as you can do imperative programming in many functional languages (E.g. Common LISP has many imperative constructs, and they are well-used in practice; even Haskell has those monads (which is basically just an embedded imperative language). The border isn't that clear cut. It's easier to talk about functional and procedural programming than of functional and procedural languages.

Re:Wrong Question

[Anonymous Coward]

textarea? is that like diarrhea?

Re:Wrong Question

[glavenoid]

Exactly! Perl always kicks my synesthesia into major overdrive -- it looks like the racket the contents of a silverware drawer makes as it tumbles down a flight of wooden stairs :-(

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

[jd]

I'd agree, except that compilers even 20K is size can do an awful lot if they're well-written. Now, 8K compilers... (They do exist, but I can't think of one that's any good. There must be some, though - the PDP-8 and PDP-11 weren't known for having masses of RAM.)

Trying something new is very very important, as is the need to be generalized. Specialists can do very well in their specific field, but if that field dies off (even temporarily, as happened with Java in the DotCom crash) then the person is unmarketable until the field revives or they learn new skills. Generalists can always find employment somewhere, even if they never reach the same giddy heights, the versatility and flexibility for good pay, versus high risk at high pay.

Re:Wrong Question

[Jeremiah Cornelius]

Look! I embedded AWK into C!

Re:Wrong Question

[geekoid]

any sane person would consider it for it's strengths and use it for that.

Re:Wrong Question

[marcosdumay]

"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."

I have this strong supicious that logic programming excells for interface description (software-software and software-human interfaces). I just can't complete creating a system that does it right :(

Re:Wrong Question

[chromatic]

Python/Perl/Ruby are limited to Unix/Linux people so still they are more expensive.

I've never tried Ruby on Windows (and I've heard that there aren't a lot of Ruby porters who compile and test on Windows, but I don't know that), but Perl and Python run just fine on Windows.

Re:Wrong Question

[chromatic]

And the "visual appeal" of Perl is...

It actually has syntax instead of a syntax tree. (Oh, and half the code you complain about is a regular expression, and for the syntax there blame Unix.)

Re:Wrong Question

[hansamurai]

Wow, that was awful. My favorite part was where they showed a 100 line C program and the Erland "equivalent" which was simply:

X=person(address("Big street", 23), telno([1,2,4,6,7,9]))

SO MUCH POWER!

Re:Wrong Question

[nschubach]

I don't know what it is about LISP/Erlang/etc. but I can't read them as easily as I read blocked code like C/C++/Java/JS/AS. When I was a kid, I learned on BASIC (GWBASIC, then QuickBasic) I eventually self taught VB4, and ever since coming out of college hating (need bolder bolds!) COBOL I just simply don't want to touch line delimited code. I've grown to love C-like languages and wished there was a better way to do multiprocessing without threads. I'm going to have to check into Scala as I really haven't heard much about it until recently. I don't understand why it would be that hard to create objects (or object syntax) for existing "block" languages to the point of making objects parallel with messaging. ("myobj proc_spawn { public:int main(){} }" for instance?). I really haven't tried messing with too many, but I too have been on a busy treadmill making threaded programs that don't step on themselves.

Re:Wrong Question

[xRelisH]

Anyone worth their weight as a programmer doesn't care what language they program in but...
Sorry, but you clearly haven't done much research about the less common languages out there. A lot of these languages are designed in such a way that you are forced to look at problems in a completely different manner.
Prolog is a great example - with it's code is data philosophy where the algorithm you use is best described as being "implicit". It's very different from how you'd tackle a problem in C, but there's also something very elegant about it.

Another example is using lambda calculus, which is often taught in programming languages in Universities. The syntax is extremely simple, but with it, you can create any sort of programming language construct you can think of.

Re:Wrong Question

[bar-agent]

it was about 4 orders of magnitude slower than C

Are you sure you meant "orders of magnitude"? That is, if the C program took 5 minutes to do a file, the Lisp program would take 3 and a half days (i.e. 5000 min)?

Re:Wrong Question

[julesh]

For example some differences between procedural Languges

['IF x=1' examples trimmed to avoid lameness filter]

Wow there are 5 different languges and they all look simular almost anyone would be able to figure it out

Well, yes, if use trivial code, the differences between different languages is trivial.

I'm inclined to agree with the writer of the article, I'm afraid. Next language after mastering the traditional OO languages like C++ and Java should be a dynamic OO language. I'm not a fan of Ruby, but it has its followers. Smalltalk could be an interesting sideline, although it is rarely used in new projects these days. Both of these languages will be somewhat familiar, yet introduce important concept that will be new to a pure C++/Java programmer: duck typing and code as data. This allows some different programming styles that are important to master (e.g. use of continuation functions).

(x = 1)
  ifTrue: [
    code goes here, and is passed as a parameter to the ifTrue method of the boolean object
  ]
  ifFalse: [
...
  ].

Different enough for you?

Re:Wrong Question

[mapsjanhere]

You're on slashdot, in a programming language discussion, and are looking for sane persons? QED

Re:Wrong Question

[Jessta]

I had great trouble understanding erlang until I got the new erlang book "Programming Erlang: Software for a concurrent world". It's an awesome book and made learning the basics of erlang a piece of cake.
The actor model feels much more like object orientated programming.

Re:Wrong Question

[abigor]

Thanks very much for the recommendation, I'll look into it.

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

[huckamania]

Do you know how long it takes to become truly proficient in C++ and OOP?

I'm guessing somewhere between a long time and never.

To me, C++ has always been C with more rope to hang yourself. You can still hang yourself in C, but C++ just makes it that much easier. Most of the C++ code I see is a mess. The OOP designs are things of beauty and breaking things into objects makes integration easier, but maintenance is a pain. Usually it takes a long time to trace where the work is being done, where it's all just x->theWork() which calls y->doTheWork() which calls z->reallyReallyDoTheWork(), only they're all called work() which means you have to go find out what type x is to find out what type y is to find out what type z is and then make sure that x is really type x and not some parent type and y is really type y and z is really type z. I was an early advocate for C++ but have since turned indifferent.

If you are just the curious type, I would suggest PHP. It is very easy to pick up and has some very cool features. You can install LAMP in a few minutes and you don't need to wait 30 minutes for something to compile.

If you are looking for job security, I would suggest that a new language may not be your best bet. It maybe better to learn to program in a new environment. If you have Windows application exp, try doing a Linux app. If you have Linux application exp, try doing some kernel mods (seriously, it's fun). If you gots both app and kernel exp on Linux, try something new like the iPhone or Android.

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:Wrong Question

[hemorex]

You guys disappoint me. Seriously. I can't believe no one pointed out that the BASIC example is fundamentally different from the others because it would terminate execution.

Re:Wrong Question

[smallfries]

Logic programming languages have no functions, or even a sense of time or order.

This is not true in practice. Logical relations are a superset of functions, and so most real logic code is written in predicates that are somewhat similar in both form and function to functional languages. The most common logic language Prolog actually has operational semantics similar to a procedural language. It is very easy to write purely procedural code within Prolog, or to use the extra features that a logic language provides.

Prolog does have a well-defined evaluation ordering for reasons of efficiency, and also because it is quite hard to express the semantics of a language which weakens this ordering. Mercury is one language that moves in that direction, also replacing the builtin arithmetic with a CLP library allows more flexibility in ordering of evaluations.

The meta-programming that you describe is not a specific feature of functional languages. Reflection and Reiterfication can be added to any type of language. Some functional languages (such as lisp) have it as a built-in feature, while some (Haskell if I remember correctly) does not. Amongst the logic languages Prolog has very powerful meta-programming features (there is no separation between code and data and both are manipulated in the same way), and amongst the procedural languages I think that Smalltalk has strong meta-programming facilities althought I haven't used it.

Re:Wrong Question

[smallfries]

Actually the difference is very clear. Imperative languages modify state while they are running. Functional languages create values. Just because some functional feature have been added to imperative languages, and vica versa does not weaken this distinction. This is why imperative monads are referred to as "pollution" in functional programs and it is common practice (enforced by the type system) to restrict their use to the "outside" parts of a program, ensuring that the core is purely functional.

Re:Wrong Question

[tupshin]

It's notable that Scala is expressive enough that you can implement Erlang style concurrency using Actors very easily:
http://lambda-the-ultimate.org/node/1615
http://debasishg.blogspot.com/2006/11/threadless-concurrency-on-jvm-aka-scala.html
and still be running inside a standard JVM.

-Tupshin

Re:Wrong Question

[corbettw]

Except that's not how you'd do it in most procedural languages today. Instead, you'd define a function and then call that function recursively. Eg, in Python it would be:

def add(x,y):
    return x+y
add(add(1,2),3)
6


So how is that fundamentally different from your Lisp segment, other than you used a built-in function and I created one that mimicked yours?

Re:Wrong Question

[Ashcrow]

Python/Perl/Ruby are limited to Unix/Linux people so still they are more expensive. Python is actually fine across Mac OS X, Linux/Unix and Windows. In fact it's quite easy to write python applications that work across multiple platforms with very little work (a lot of times without extra work at all).

While I am far from a ruby expert I have heard about Ruby and Windows ... though it seems like there has (and will be) work on that. A quick google search showed results such as

"Ruby is written for POSIX environments, which means that it can take advantage of all of the system calls and libraries that Unix programmers are familiar with."

Re:Wrong Question

[Anonymous Coward]

Yes. And, don't worry, I'm sure he doesn't.

Re:Wrong Question

[gunne]

A functional language would be my first choice, definitely teaches you to think about programming in a different way from all those procedural and oo-languages.

I vote for haskell, www.haskell.org, it's a beautiful language.

Re:Wrong Question

[EWIPlayer]

I'm guessing somewhere between a long time and never.

You've got it on "a long time". After one year of C++, I thought I had it, then after five years, I knew I didn't. Now, after almost ten, I've reached the semi-proficient level, where proficient is measured in terms of Scott Meyers and Herb Sutter level of skill.

But I don't agree with what you're saying about OOP, and most modern programmers would probably side with me. Well designed large scale C apps are not maintainable nearly as well as well designed large scale C++ apps. I've worked on code bases that make my point repeatedly. Redesigning it properly in OO makes all the difference in the world.

Re:Wrong Question

[Aardpig]

Well spoken by someone who obviously knows nothing about high-performance computing!

Re:Wrong Question

[Eth1csGrad1ent]

. They may have their personal favorates but, can code sucessfully in any language
even if they never coded in it before. Because once you understand the classes the rest is just a
google search from finding the right command and syntax of the languge. NOT just a google search, but one of many, MANY google searches...

It is true that you can track down the answer almost any coding question you have through google and forums, and if your question hasn't already been asked, you can post and get results, but don't be fooled into thinking this is a quick solution.

As we all know, there are many different ways to achieve the same result, some good, some bad, and they've ALL been posted on the net somewhere.

Signal to noise ratio can be terrible - resulting in hours wasted wading through pages and pages of search results that aren't quite what you're looking for, trying to come up with THE google search phrase that'll nail it. Other times I'm simply amazed at the detailed solution/explanation someone was prepared to write (for nothing).

You can get code snippets and examples for almost any task in most of the the well known languages, and it can save you time building the app. but in the end, in order to maintain it, you have to understand how it works.

Re:Wrong Question

[febuiles]

The question is flawed. Anyone worth their weight as a programmer doesn't care what language they program in. False, I don't think there's one programmer on earth who sees all languages as the same, without having one predilect language. Knowing how to use tool X in situation Y != don't caring about our tools. That "school" of thinking comes from SE101 courses where they teach you how to draw a lot of diagrams thinking that code and progamming don't matter in the real world, get rid of it.

But Programing Methodoligy should they work with. Some of us program using various paradigms at the same time so this is not as important as you think. Btw, it's methodology.

Assuming that you use to Object Orianted Languages Oriented.

deveation Deviation?

Assuming that you use to Object Orianted Languages which are a deveation of Procedural Based Languges. We could have a nice discussion about that.

They may have their personal favorates but, can code sucessfully in any language even if they never coded in it before Favorites. And making something "kinda work" in a language is not the same as knowing a language. You can start reading some of Peter Norvig's thoughts on the subject: http://norvig.com/21-days.html

Because once you understand the classes the rest is just a google search from finding the right command and syntax of the languge. Yeah...ehh....no, sorry but no. Quoting that article from Norving:

"In 3 days you might be able to learn the syntax of Pascal (if you already knew a similar language), but you couldn't learn much about how to use the syntax. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using Pascal syntax, but you couldn't learn what Pascal is actually good (and bad) for..."

And about your code examples: One thing is writting an "if", something common to every single language, another one's really using a language. A Ruby programmer could give you a block while some Haskell weird dude is throwing crazy ass STM Monads at you, would you be able to write them in another 5 languages as easily as you did with your if's?
Knowing a language's "while", "if" and ";" tokens is not knowing a language.

Re:Wrong Question

[fitten]

Effortless parallelization for certain models of parallel programming, not all I'd wager. Producer/consumer, thread pools, etc, sure (task parallel). Data parallel is difficult because most of the problem there is partitioning the data properly and the inherent issues with synchronization (talking about MPP/MIMD type programs) and notification (message passing, for example), particularly when the data set is too large to fit in a single process or even on a single machine.

Re:Wrong Question

[SeanAhern]

True. Unless they were doing high performance computing on any of the Top500 computers in the world. The advances that Fortran has made in the last 10 years have been amazing, way beyond what you can do in C/C++ for scientific applications. And I'm not talking FORTRAN77, which is what most people think of when they think of Fortran. Please look at Fortran 90/95 and especially Fortran 2003 before dismissing it out of hand.

Re:Wrong Question

[Anonymous Coward]

earlier today, you found and pointed out a grammatical error on Steve Novick's website, and now you say,
"any sane person would consider it for *it is* strengths and use it for that."
Just sayin'

Re:Wrong Question

[quickbasicguru]

Really that slow? Which implementation did you use?

There are portable libraries for SQL, networking, GUI, and threads.

Could you also give an example for "it is possible for a file to exist on the system that the Lisp process is unable to open without resorting to non-standard functions"?

Re:Wrong Question

[weg]

Programing Methodoligy ... Object Orianted Languages ... deveation ... HASCAL ... widly ... Sciencetific ... favorates ... languge ...

Wow.. the next language you should learn is definitely English. Sorry, had to say that.

Anyway, I don't agree with you, certain languages are better suited to learn specific methodologies. C++, for instance, is not particularly well suited to learn object oriented programming, and knowing Eiffel (i.e., an object oriented programming language) doesn't make you a good C++ programmer. The best programmers I've seen have been programming in the same language for years. It takes lots of experience to really master a language. And btw.: Even though I know SML and OCaml, I can't read Scheme or Lisp, so even switching languages within one paradigm is not that easy.

I think that Scala is indeed a nice language to learn if you don't know it, yet, because it allows you to use more than one paradigm, enabling a smooth shift from what you know (e.g., OO in Java) to what you want to learn (e.g., functional programming).

Re:Wrong Question

[DaBookshah]

Idiot. Javascript is not a java clone.

Re:Wrong Question

[Anonymous Coward]

I am only a hobby programmer. The biggest shock to me was that it is almost impossible to program in a "foreign" language. Python probably handles foreign languages best of all but even German Python Code doesn't contain an es-zett or umlautes but English workaround words. I guess operating systems have been written in English.

Re:Wrong Question

[david_thornley]

(+ 1 2 3) is how I'd write it in Lisp.

Common Lisp also has the ability to rewrite itself on the fly efficiently, a really interesting object system that's a lot different from other ones I've seen, strong dynamic typing, and other neat stuff. It's well worth learning for anybody who's interested in learning new things.

Re:Wrong Question

[agendi]

Excellent, couldn't agree with you more. I currently work as a professional database developer but have written a lot of business/desktop style "middle ware", recently I decided to learn ruby/rails and do some web-based stuff - it's not the language that I struggled with it's the features that I took for granted in desktop apps that webapps have their own unique problems AND work arounds. As someone that wants to consider themselves as a programming artist I realised that I have to constantly expose myself to new programming shapes/problems. It can only make your whole programming experience more powerful. The best example of this is when I see the new data developers using SQL like a procedural language - loops and cursors. I explain to them that just because the features exist doesn't mean that it's the right way to go about it, to look for the philosophy of the language.

Re:Wrong Question

[mrchaotica]

But what are FORTRAN 77's strengths, pray tell? It seems to me that everything it does, C does better.

Re:Wrong Question

[Anonymous Coward]

and you can use existing IDEs such as Netbeans.

Jesus. Why?

Eclipse FTW!

Re:Wrong Question

[Pootie Tang]

I've seen (and been guilty of) implementing things for which there is already code for in core libraries. Or otherwise there is a readily available solution which is not used or used poorly. Each language out there has a large set of libraries available, either by default or a download away. This is the real difficulty in learning new languages. Mastering a language can take quite a while. It's true you can get code that "works" fairly quickly if you are familiar with another language in the same class (to use your term) as the syntax is easy.

I agree with the first part of your post. But I no longer agree on the part about picking up new (similar) languages. I used to think it was easy. I'm not sure if I've changed my mind more to my growth as a programmer or the expansiveness of modern core libraries. Maybe it's just old age :)

Re:Wrong Question

[Lars512]

To expand on your post, logic programming languages have an inbuilt form of search. You can program rules, and these constrain the solution space of correct answers. Your code then directs the search, which is depth-first by default, and makes sure that it will explore the space efficiently and give you an answer in reasonable time.

One big difference in comparison to other language families is that the search could have multiple answers, and if the search goes down a branch which "fails", it can also backtrack and try another branch. This type of behaviour is inbuilt, and very useful for some types of problems. For other types of problems, you just end up coding in pretty much the same way that you would for imperative languages. You do get the benefit that variables are (usually) immutable, which can avoid some forms of programming errors, and that the language usually lets you program at a very high level.

Statically typed logical languages with mode systems (like Mercury) can have very good performance, and give the compiler enough information to provide warnings which catch many many more programming bugs than normal, all before your code is even run. The real downside for some applications is the small size of the ecosystem for 3rd party libraries compared to C/C++/Java/Python/Perl/etc. It may or may not be a deal-breaker for whatever you need to get done.

Re:Wrong Question

[Dun Malg]

BASIC has such fond memories for me. I was self-taught at it so I did the stupidest crap as a kid. I remember writing programs where I wanted a delay, and what did I do? Look for a command to do that? Of course not! Run a loop that counts up to some insane value before terminating and just count on the computer's slowness at traversing the loop to facilitate my delay :). That was back in the days of Commodore 64... To be fair, C64 basic didn't HAVE a delay command, so you did the best you could. All we had time-wise was the system variables TI (1/60 sec jiffy clock) and TI$ (time string as "HHMMSS"). You could futz around with TI and get nice, accurate timing and it's only take 3 or 4 lines to do it.... or you could just stick in an empty FOR loop as one line and be done with it. On such a simple machine it made no difference. It wasn't like you were hogging clocks from another process! Even under DOS it was essentially the same thing. It wasn't until later, when clock speeds started ramping, that the whole "sleeping vs wheel-spinning" issue became relevant on desktop machines. Even then, people ignored it for a while. I am still ashamed of Origin's programmers for Ultima VII not including any sort of timing code, making the game runnable but unplayable on a very fast machine 5 years later...

Re:Wrong Question

[Anonymous Coward]

Ok,so how do we get from here to the Answer to Life, the Universe and Everything is 42? :-)

Re:Wrong Question

[huckamania]

Redesigning it properly in OO makes all the difference in the world

I think anything you can do in C++ can also be done in C and I know that anything you do in C++ can be done with less overhead using C. C++ comes with a lot of overhead.

Don't get me wrong, objects are a great abstraction, but that's all they are. They make pretty diagrams, but after you make your design, you should use the best language to do each part.

I do a lot of low level work so C++ is usually not an option.

Re:Wrong Question

[tokuchan]

I'm going to take each of these on one at a time...

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. Well, more specifically, functional languages try to adhere to the precepts of the Lambda Calculus which, among other things, treat programs as data by allowing higher-order functions (functions that can take other functions as arguments and return them as results). This is a defining feature of functional languages, and it turns up in many surprising languages. PERL, Ruby, Python, JavaScript (which is more based upon LISP than Java, despite the name), for instance. So, one could learn any of those languages and learn about functional programming from them. You don't have to learn about functional programming from languages that aren't very popular or commonly used.

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. I have to completely disagree with OP here. First, Logic Programming is based upon the idea of relations between sets of objects. These relations are usually expressed as equations of some form. For instance: in the make language (used to build programs) one specifies an equation relating a target to its dependencies. The program (in this case make) then uses a variant of the Unification algorithm to solve these systems of equations, building your program as it does so. Logic programming turns up in many places: type inference (OCAML, CAML, ML, etc.), dependency analysis (the various make's and project builders), databases (think SQL), and spell checking. IIRC MS Word (at least older versions) used a spell checker written in Prolog.

All of this to one side, one can note that since the set of all functions is a subset of the set of all relations, lambda calculus can be no more powerful than relational programming. Therefore, Logic Programming is at least as capable of solving a problem as C or the like.

Re:Wrong Question

[smellotron]

C++ comes with a lot of overhead.

Nope. Certain features of C++ have a lot of overhead. That's part of the reason it's so complex in the first place—it follows the principle of "if you don't use it, it won't cost you anything." And in many of those cases, the power granted by those features comes at the same cost as it would to handle the same level of complexity in C.

Re:Wrong Question

[try_anything]

Python is actually fine across Mac OS X, Linux/Unix and Windows.

It also runs on .NET (IronPython) and Java (Jython). Jython lagged for a while, but it is catching up quickly, and Sun just hired a Jython developer to work full-time on the project. I believe there's a Python implementation for Parrot in the works as well, so Python's bases are well-covered.

Re:Wrong Question

[HishamMuhammad]

Oh, come on. The guy lost all his cred back in the first paragraph when he called Haskell "HASCAL". By the time I got to the BASIC snippet I was already laughing out loud.

Re:Wrong Question

[try_anything]

Each language out there has a large set of libraries available, either by default or a download away.

Sadly, this is not true. Even for languages such as C and Java, it is true in different ways for different languages. Here is roughly what you do when you need to do Z in different languages:

• C
  It will take you approximately 3.7 seconds to locate seven thousand Z libraries and pick out a mature, tested one. This leaves lots of time to painstakingly learn its arcane (and usually underdocumented) macro usage and memory management conventions, and then write the fifteen hundred lines of C code needed to make three calls into the library.
• C++
  First, see if there is a Boost library for Z. If not, put your affairs in order and check out the handful of large, somewhat specialized C++ frameworks, which were designed for mysterious purposes evidently quite different from yours, and which (owing to compiler limitations that, trust us, were quite a force to be reckoned with in 1855, what with the Crimean War holding up the standardization effort) are very much like C libraries in their use of macros and memory management. With that caveat, I'm sure you can find a framework with a good Z library. Of course, you might as well use the framework's support for logging, concurrency, memory management, networking, file access, and containers. Otherwise, things could be... tense. Awkward. You know what I mean. A guy wakes up and his application architecture is all busted up. Nobody wants that.
• Fortran
  Of course there's a stable, documented, highly performant library for Z. Wait a second, what is this Z thing you're talking about? I can't find it in my encyclopedia of numerical methods.
• .NET languages
  There isn't a Z library per se, but Visual Studio will generate one for you in C#. Just walk through this wizard to generate 8,000 lines of Enterprise Web Z for the Web Enterprise code for your application. Microsoft will make sure that any bugs in the code generator will be scrupulously undocumented and then fixed in the next release of Visual Studio -- which is probably just a year or two away.
• Java
  There are open source libraries, but why not use the official Sun-provided library? It's probably simple, complete, and powerful. Or it may be complex, complete, and powerful. Or it may be powerful, complete, and so complex that it sustains your entire career. You can be "The javax.Z Guy" at your company and make a living writing XML configuration files for people who need to do Z in Java.
• Common Lisp
  Ask on comp.lang.lisp. You'll get one or both (probably both) of the following answers:
  Answer 1. "Why do you want a library to do Z? Common Lisp is so powerful you don't need a library." And, if you're lucky: "Look, here's thirty lines of Lisp that give you most of the functionality you need. Just another fifty lines or so to cover every possible feature." (Go ahead and copy and paste the code. It probably works.)
  Answer 2. "In 1542, Gustavus Flavius Adolphus wrote a Z library in Burgundian Lisp, and it was later translated into Common Lisp by a talented young scribe. It's so perfect nobody has ever dared to offer an alternative. It's available via oftp (Olde File Transfer Protocol) from a server at MIT, unless the server collapsed in a cloud of dust, in which case it is tragically lost forever." (Just download it. Ye olde ftp server is still running, miraculous as it seems, and the library is actually usable, though the culture shock will leave you a bit dazed.)
• Scheme
  There's a Z library available... for another implementation of Scheme. Now is a great time to switch!
• Other languages
  Anyone?

Re:Wrong Question

[Fizzlewhiff]

.NET isn't a language. It is a framework.

Re:Wrong Question

[goose-incarnated]

Except that's not how you'd do it in most procedural languages today. Instead, you'd define a function and then call that function recursively. Eg, in Python it would be:

def add(x,y):
return x+y
add(add(1,2),3)
6

So how is that fundamentally different from your Lisp segment, other than you used a built-in function and I created one that mimicked yours?

Your function cannot be curried. Please learn Lisp and/or Haskell before attempting to claim equivalence.

Re:Wrong Question

[Daniel Dvorkin]

Anyone worth their weight as a programmer doesn't care what language they program in.

This is simply not true. Experienced programmers know full well that (a) one language is very often a better tool than another for a particular task, and (b) some languages are simply better than others, overall. Yes, yes, you can do anything in any Turing-complete language that you can do in any other Turing-complete language, good programming practices are universal, blah blah. But the reality is that plucking a language out of a hat pretty much guarantees that most of your programming tasks will be exercises in wasted time and frustration.

Re:Wrong Question

[anandsr]

FORTRAN does not use the stack and call semantics. This makes it much faster when writing modular code that is fast. The functions will be implemented as simple jumps rather than calls. Almost all mathematical libraries are written in FORTRAN.

Re:Wrong Question

[Anonymous Coward]

"It has a funny name, and carries the mystique and credibility you seek. Nothing says "way old school" and "MIT Wizard" like piles of LISP with your tag on them. Of course, you'll have to leave vim behind - there is only one, true tool for the LISPer, now that dedicated machines like Symbolics are all in the museums."

Open Genera is still available.

BTW someone made the valid observation that the reason some languages do well in the market is that they play well with others. Smalltalk and some other languages are an all or nothing proposition. You accept their environment and if you want to deal with the rest of the world warts and all, you have to use an FFI (which is usually half-assed or has other issues).

Re:Wrong Question

[asc99c]

I believe you are partly right. I do work with multi-process applications, but I think part of the reason these are simpler is that you really have to sit there and decide on data to be shared and explicitly create shared memory segments for this data and then attach each new process to those segments (in C at least).

When I have used multi-threaded programming (in Java), it is very tempting, when lots of extra data is shared to just say 'OK I'll use this variable just as a one off to get this done'. Usually in the long run that's a very bad choice because the data was not designed to be shared.

Actually designing ALL of the data that can be shared is an important part of getting the design right and avoiding a lot of the little bugs that crop up. From this point of view I really prefer multi-process work than multi-threading as it is more natural to do things 'right'.

Re:Wrong Question

[LarsWestergren]

>>and you can use existing IDEs such as Netbeans.

>Jesus. Why?

>Eclipse FTW!

I prefer Netbeans. To each his/her own.

Re:Wrong Question

[gnalre]

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

Re:Wrong Question

[ciggieposeur]

Really that slow? Which implementation did you use?

CMUCL and SBCL. And yeah, really that slow: a non-optimized C++ routine could get through 70MB in about 5-10 seconds, but the Lisp equivalent (after extensive optimization including declared types and minimized memory usage) took about 45-60 minutes (identical hardware). I traced it back to the parsing and construction of so many single-float's from all that data. My final test was to simply (time (dotimes (i 10000000) (parse-float ...))) with nothing else in the loop and compare to sscanf("%f", &var1) on the same input and the difference was 100-1000 times faster for the C code. Someday I might learn the internals of a particular Lisp enough to provide a non-safe (parse-float) that comes within 2x of C, but I didn't have time this year to get into it that far.

There are portable libraries for SQL, networking, GUI, and threads.

Granted, it's been two years, but SBCL's threads worked only on x86 and CMUCL's were portable across platforms but not native threads (though I do like the mp:make-process model). CLSQL broke inside the native Postgres driver somewhere along the way, and the GTK/Qt libraries at the time were not quite feature-complete.

Could you also give an example for "it is possible for a file to exist on the system that the Lisp process is unable to open without resorting to non-standard functions"?

I was iterating through my MP3 collection and eventually encountered a file that looked something like "/path/to/dir/[Artist]---Filename(stuff).mp3" such that the (namestring pathname) CMUCL returned was "/path/to/dir/\[Artist]---Filename(stuff).mp3" . It's been over two years since I last looked at it so I don't remember too closely, but essentially there was no combination of normal functions I could use to determine the actual native filename from the pathname. Come to think of it, I might have been able to open the file, but I really just wanted the file size and there was no way to guarantee that (namestring) would work with (unix:unix-stat).

Re:Wrong Question

[Anonymous Coward]

try objective-c.

Re:Wrong Question

[ciggieposeur]

That is, if the C program took 5 minutes to do a file, the Lisp program would take 3 and a half days (i.e. 5000 min)?

In this case it was the time difference between "(dotimes (i 10000000) (parse-float "1234.567e+8"))" and "for (int i=0; i10000000; i++) sscanf("1234.567e+8", "%f", &foo);" . One completed in something like 30 seconds, the other around 0.3 seconds. Adding the rest of the stuff in (moving those single-floats into CLOS objects) was a bit of a slowdown but not too bad. Overall, a C++ program that could complete in the 10-20 second range took 45-60 minutes in Lisp. Maybe 3 orders of magnitude is more accurate then.

I may get time someday to dig into a Lisp and implement an unsafe-parse-float that could get within 2-3x of C, but I ran out of time for more performance optimizations on this project and had to move on.

Re:Wrong Question

[ciggieposeur]

Yeah, ouch. Other than the parse-float issue and the modern libraries, the rest of Lisp is pretty neat.

I'm hoping that the Lisp Gardener's project has made some progress since then on the portable libraries. Maybe next year I'll be able to revisit Lisp...translating C++ TO Lisp is a lot easier than the other way around. :)

Re:Wrong Question

[Anonymous Coward]

Shame Table oriented programming isn't being mentioned.*

*By a former "/." poster no less.

BTW just how much of languages is just a different view to the AST?

Re:Wrong Question

[setagllib]

Python and Ruby are so *not* limited to Unix people, that Microsoft pays developers supporting Python and Ruby on the CLR/DLR.

Re:Wrong Question

[DKlineburg]

For Example (ADD(ADD(1,2),3) would return 6

I may not know the language, but arn't you missing a ")" or have 1 to many "("?

(ADD
. . .ADD
. . . . . (1,2)
. . .,3)
")" 'Note there is no ) here, this is a sugestion

I think that is why understanding where your program is wrong it is nice to break out in lines. I have the dots there because I can't "tab" out my lines. Just a thought, if you don't need that last ")" my bad.

Re:Wrong Question

[Anonymous Coward]

(dotimes (i 10000000) (parse-float "1234.567e+8"))" and "for (int i=0; i < 10000000; i++) sscanf("1234.567e+8", "%f", &foo);"

Not the best examples of your problem in the world, since even mediocre optimizing compilers should in the first case replace the entire expression with a single call to (parse-float "1234.567e+8") [some will even do parse-float at compile time and replace the sexpr with your fully parsed flonum]. This is especially true in lexically scoped lisp dialects, most notably Scheme.

In the second case, we are stuck probably having to do the parsing every time or make a biiiiig safety tradeoff depending on how foo was declared. If there is nothing else using the contents foo, we can omit the loop entirely, and just set i to 10000000 at compile time, stuff the float into the data segment at compile time, and copy that into &foo just once at runtime.

This is where Lisp-like language have been winning big since the Yale T compiler.

Where they lose big most often is almost certainly affecting you: most Lisps are slow when creating and manipulating strings. Most implementations stuff strings into a differently-managed heap than the familiar one filled with CONSes and ATOMs. The string (or vector) heap generally has much higher allocation costs in order to keep the array of string-elements compact and fast for looking at individual string-elements or substrings. This also saves some work for copying or relocating garbage collectors, since you can leave the string in place in the separate heap, while copying, moving, marking or otherwise processing a pointer to the string header structure that's kept in the normal heap. Reading in many short-lived strings is almost the worst possible workload for such implementations.

There are a variety of approaches to speeding up this kind of stream processing, but a Schemer would likely consider using an FFI to call a function (probably implemented in C) which presents arrays or lists of parsed floats to the Scheme caller. Several CL implementations with really abysmal string performance have usable FFIs too.

You can probably get a much bigger slowdown in C by doing explicit mallocs and frees on each string you read in.

Your speedup is in part because C encourages you to do destructive operations; some faster parse-strings gain the same way, and for the same reason (string allocation is expensive).

Another problem with Lisp-like languages is that numeric literals are much richer than what C's %f can cope with, and if all you're looking to parse is flonums in whitespace delimited %f-compatible format, a kitchen sink CL or RnRS string->number parser is *massive* overkill. However, on modern machines, this sort of computation is cheap because it's L2/L3 instruction cache friendly when streaming, so it's unlikely to be anywhere near as large a factor as the moving of strings into the heap in the first place.

Re:Wrong Question

[Anonymous Coward]

The important word is "properly". Redesigning a large scale procedural C application to C++, only to add OOP and to make it more modern, will make it only chaotic. If want a well designed large scale C++ application, it has to be done from the beginning.

Re:Wrong Question

[Anonymous Coward]

Sorry, but I'm with the parent on this. You're looking for programmers very skilled for a particular field. All well and good - if that's your need, that's the way you'll find them, but it's a niche approach. I've spent a career in parts of the industry (commercial business applications) where legacy code in mutliple languages hangs around for years, and the ability to write clearly, comprehensibly and above all in whatever language is needed is of far more importance than the ability to write "clever" code in a single language or using a single programming model. In that field I'd back the parent's approach over yours any day; it needs people who understand clarity and structure, and who can turn their hands to whatever they're asked, not ones who're deep, deep experts in a single skill. And of the two approaches, I'd back the generalist approach over the specialist 9 times out of 10 in the general case - because when the general case needs the tricky stuff done, you can bet that I can find a couple of generalists who're pretty good on the deep detail as well.

Re:Wrong Question

[EWIPlayer]

I think anything you can do in C++ can also be done in C...

Of course that is true, so long as you keep the scope of "anything" to be "can be computed". But if that's the case, then anything you can do in C you can also do in assembler, or Visual Basic, or Turing...

I've never even heard of anyone taking an OO design and implementing it in a non-OO language, so I think your statement about taking the "pretty diagrams" and then using the "best language to do each part" is dubious at best. In fact, I'd probably go so far as to say that you haven't spent nearly enough time working with object oriented designs and languages to even speak on the subject in this way. I used to say this stuff too, when I thought I understood what C++ and OO were all about, but then I learned I didn't know nearly as much as I thought I did and studied it for years... now I can say I wholly disagree with my former self, and I wholly disagree with you as well.

Re:Wrong Question

[David Parker]

> I've never even heard of anyone taking an OO design and implementing it in a non-OO language ...

The Flaming Thunder compiler is OO, and it's written entirely in assembly language.

Re:Wrong Question

[itlurksbeneath]

... Object Orianted Languages (C++, Java, .NET) which Bzzt.. I'm sorry. When did .NET actually get the title "Language"? ".NET" is no more a language than are the code libraries that you use with C or Java. GNOME would be a language by that definition and it's not.

Re:Wrong Question

[amuzulo]

The generalist's approach is interesting, but there you have no edge. They expect years of experience in that language to get a good-paying job. However, if you go with a new language like Ruby on Rails, you'll find job ads seeking programmers with 5 years of experience when it's only been around for 3 years! So, it might be more interesting to pick an up-and-coming language like Ruby on Rails, if you want the maximum effect to your salary based on the time invested in learning the language.

Re:Wrong Question

[Anonymous Coward]

Any sane person would program in whatever the Boss wants them to program in and enjoy cashing the pay checks.

Re:Wrong Question

[krog]

PERL, Ruby, Python, JavaScript (which is more based upon LISP than Java, despite the name), for instance. So, one could learn any of those languages and learn about functional programming from them. You don't have to learn about functional programming from languages that aren't very popular or commonly used.

You can get your feet wet, but to take advantage of many benefits to functional language (for instance, ML's superb type inference, or Erlang's formidable scalability), you need to go unpopular. You are correct, though; functional programming style fits in many languages which are not strictly functional.

I have to completely disagree with OP here. First, Logic Programming is based upon the idea of relations between sets of objects. These relations are usually expressed as equations of some form.

"rules of a system"

Logic programming turns up in many places: type inference (OCAML, CAML, ML, etc.), dependency analysis (the various make's and project builders), databases (think SQL), and spell checking.

All specialized tasks. You might embed Prolog in Word to perform spell checking; you don't write Word in Prolog.

All of this to one side, one can note that since the set of all functions is a subset of the set of all relations, lambda calculus can be no more powerful than relational programming. Therefore, Logic Programming is at least as capable of solving a problem as C or the like.

Welcome to the Turing tarpit.

Re:Wrong Question

[krog]

Okay, maybe "effortless" was a stretch. If the effort is performed behind the scenes (i.e. in the compiler or execution environment) then it can become pretty effortless to the programmer. In any case, parallelizing shared-nothing code is a much simpler problem than writing threadsafe code in languages with shared anything.

Re:Wrong Question

[popmaker]

But Programing Methodoligy should they work with.

I'm assuming you write in postscript. :D

Re:Wrong Question

[T.E.D.]

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... Unfortunately, the language also has a high barrier to entry as it is not Algol-based (like C, C++, Java, etc. are).

Hmmm. It sounds like you should consider looking at Ada. Its Algol-based, and has threading designed in from the start as a first-class part of the language.

Its also a supported part of GCC, so a compiler is freely available for most platforms. For the windows version, go to The Mingw Download site and search for "gcc-ada".

Re:Wrong Question

[heck]

Parallel programming is going to be a HUGE deal in coming years

I'll believe that when I see it. It's Duke Nukem - been hearing that for years.

From where I sit, and the apps I design, code and support - nope. Not even on the radar. And we have a plan that goes out 5 years.

Re:Wrong Question

[randyest]

That was pretty funny. A little friendly tip about your sig: a sentence about someone being smarter or not should probably use then/than correctly. Otherwise it can be (unintentionally) funny as well ;)

Re:Wrong Question

[huckamania]

C++ is the one language to rule them all? OO is the only design method that can solve problems?

The first C++ compilers were written in C. Do you honestly think they didn't use OO to design those first compilers and IDEs? As far as using a non-OO language in an OO design being dubious, then you must only have experience with small applications. Some of the stuff I've worked on were too big for a single system. Some of it is connected by gasp a network. Doesn't matter to my code if it is C++, Perl, Pascal, Java or MsPacMan, they all understand TCP so what do I care.

Of course that is true, so long as you keep the scope of "anything" to be "can be computed"

What exactly are you doing with OO and C++? Stuff that can't be computed?!? Good luck wit dat...

Re:Wrong Question

[Anonymous Coward]

Here's what google says is actually most popular on Monster.com

    dot NET - 29300 (not inc. C#)
    Java - 25300
    C# - 20100
    c++ - 11900
    Javascript - 9120
    PHP - 4640
    Perl - 3270
    Scheme - 2390
    Ruby - 1100
    python - 821
    fortran - 155
    prolog - 73
    erlang - 61
    lisp - 33
    haskell - 5
    ML - 0
    Postscript - 0 (except for resume format)

So I note that while the languages the article suggests are interesting (and I have studied most of them) they are almost universally unmarketable.

Re:Wrong Question

[Anonymous Coward]

Try RPGIII you might been delighted :-)
<code>
C             DSPLY 'I FIT INTO'
C             DSPLY 'AN 80 POS '
C             DSPLY 'PUNCHED CA'
C             DSPLY 'RD PERFECT'
C             DSPLY 'LY'
C             SETON                                   LR
</code>

Re:Wrong Question

[mrchaotica]

Ah, that's a good answer! It also explains why '77 doesn't allow recursion (and '90 requires it to be explicitly declared). That answer really ought to be in a prominent FAQ or something.

Of course, even though I admit that FORTRAN does do that particular thing better than C, C still can do it (via goto if you want the exact thing with ugly syntax, or inlining if you want something sorta similar with clean syntax and don't care about executable size). It's too bad that C doesn't have a "jump" keyword that's used in a similar way as "inline" but causes the function to use FORTRAN semantics.

Re:Wrong Question

[KittyPrincess]

Beautifully said. I'm a programming n00b. All I have done for the past year is study one language after another (both OOP and procedural). At the end of the day, it really is all about algorithms and methodology. It's about best practices with regard to sucking every bit of information you can from your customer and providing the appropriate solution to the problem they're asking you to solve. It's also about knowing enough about the tools available to you to determine which is the best for the particular application and then applying the appropriate methodology within those tools to accomplish that goal. Beyond that, it's only syntax. That's the easy part.

Re:Wrong Question

[ucblockhead]

Sadly, your English parsing skills don't match your Javascript knowledge.

Re:Wrong Question

[Anonymous Coward]

(though not as much as from a pure functional language such as Lisp or ML, or so I'm told)

Lisp and ML are not pure functional languages.

Re:Wrong Question

[corbettw]

Sure it can:

def curryadd(x):
    return add(1,x)

curryadd(curryadd(2))
4


Unless I'm misunderstanding something about "currying". The mathematics aspect of computer science has never been my strong suit, so if I'm missing something, please enlighten me.

Re:Wrong Question

[weston]

Logic programming languages have no functions, or even a sense of time or order.

It depends.

A Prolog implementation, for example, generally has a well-defined order in which it traverses rules. If you understand it, you can use this to control program flow effectively. And some of the idioms from functional programming transfer as well.

It's kindof fun as an exercise and useful to some extent for small programs. But after the novelty wears off or you have to tackle a project of any size, it wears thin and you realize there's a reason imperative languages exist and you're best off applying both imperative and logical languages where their strengths are an advantage.

Re:Wrong Question

[RAMMS EIN]

In my opinion, the whole machinery of logic programming languages can and should be implemented in terms of a general purpose language. Because what logic programming languages really boil down to (correct me if I'm wrong here) is one or a bunch of solving strategies for logic problems, which they are fed as input. That could easily be done by implementing the solving strategies as functions in a general purpose language, especially if that language supports elegant representation of the inputs to your "logic programming library". And the advantage to this is that it is easy to mix your general purpose language with your special purpose language, so you have the power of the former and the convenience of the latter.

One classic example of this is implementing "Prolog" in Lisp. I wrote Prolog in quotes, because what is usually implemented is a language with Lisp syntax and a small subset of the features of Prolog. But still, it's the sort of thing I mean.

Re:Wrong Question

[tokuchan]

PERL, Ruby, Python, JavaScript (which is more based upon LISP than Java, despite the name), for instance. So, one could learn any of those languages and learn about functional programming from them. You don't have to learn about functional programming from languages that aren't very popular or commonly used.

You can get your feet wet, but to take advantage of many benefits to functional language (for instance, ML's superb type inference, or Erlang's formidable scalability), you need to go unpopular. You are correct, though; functional programming style fits in many languages which are not strictly functional. Oh, I don't know, you can make some pretty big programs with lanugages like PERL, Python, and Ruby. Also, Javascript is no slouch either, and it's based upon Self rather than Java.

I have to completely disagree with OP here. First, Logic Programming is based upon the idea of relations between sets of objects. These relations are usually expressed as equations of some form.

"rules of a system"

Logic programming turns up in many places: type inference (OCAML, CAML, ML, etc.), dependency analysis (the various make's and project builders), databases (think SQL), and spell checking.

All specialized tasks. You might embed Prolog in Word to perform spell checking; you don't write Word in Prolog. None of these tasks are any more specialized than serving up web pages, or processing images, or editing text or any number of other things that one does with computers. Conversely, we can argue that all tasks in computing are specialized. So, what's your point?

All of this to one side, one can note that since the set of all functions is a subset of the set of all relations, lambda calculus can be no more powerful than relational programming. Therefore, Logic Programming is at least as capable of solving a problem as C or the like.

Welcome to the Turing tarpit. Actually, you can create good programs with Logic Programming languages like Prolog. It includes most of the common features of any programming language, including C integration, loops, conditionals, and the like. It's no more of a tarpit than your suggested "unpopular" functional languages. (Erlang's a good example here in that its syntax is about as alien to a C programmer as it can get.)

Re:Wrong Question

[xZgf6xHx2uhoAj9D]

Sorry, I meant the 5 languages that the GP poster mentioned, not the 5 languages mentioned in the article.

Re:Wrong Question

[jgrahn]

The question is flawed. Anyone worth their weight as a programmer doesn't care what language they program in but. But Programing Methodoligy should they work with.
[...]
most good programmers with experience in these languge classes are not normally worried about what to program in. They may have their personal favorates but, can code sucessfully in any language even if they never coded in it before. Because once you understand the classes the rest is just a google search from finding the right command and syntax of the languge.

That is also flawed, unless you're planning to exclusively write "Hello, world!" programs and if clauses.

Any worthwhile programming language has its specific voice. If you believe "it's all just syntactic sugar" or "implementation details", or that you "can google for the details", then I can guarantee your code will suck. You may not realize it, but the person who has to maintain it will.

The old saying "a good programmer can write FORTRAN in any language" wasn't meant as praise.

Re:Wrong Question

[jellomizer]

Unless you are writing code for a system that doesn't have a Fortran 90 compiler. And migrating all the code is more expensive then just writing it in Fortran 77. I actually like the fact that everyone hates FORTRAN it means I get to charge more to program in it.

Re:Wrong Question

[Tablizer]

Note that one does not need parenthesis around IF expression in VB and BASIC.

Re:Wrong Question

[try_anything]

I think anything you can do in C++ can also be done in C and I know that anything you do in C++ can be done with less overhead using C.

Errm, not really. C++ language implementers have more freedom than C programmers. To take gcc as an example, for each C++ language construct, if there were a faster C equivalent, the C++ front-end would just generate the same intermediate code as for the C equivalent. You only get extra overhead if you can't do it in C -- and that doesn't make any sense. (Extra overhead compared to what?) Furthermore, for C++ features like dynamic dispatch that can be faked in C, the compiler has more information to work with when it is expressed via a more specific C++ construct (like a virtual function call) than through a more general C construct (such as calling a function pointer held in a struct). You aren't going to implement dynamic dispatch in C as efficiently as a C++ compiler.

C++ comes with a lot of overhead.

Do you mean C++ libraries, which are only a burden if you use them? Exceptions, which are only a burden when you throw them or offer to catch them? OO stuff, which you don't have to use if you don't want and is at least as cheap as achieving the same functionality in C? RTTI, which is only used to support other optional C++ features that you don't have to use?

C++ is only more expensive than C in the same way that a week in Las Vegas is more expensive than a week in Garden City, Kansas. The base cost is the same, but when you've got a little bit extra to spend, at least Vegas has something fun to spend it on.

Re:Wrong Question

[EWIPlayer]

C++ is the one language to rule them all? OO is the only design method that can solve problems?

Yup... I'm pretty sure that's what I said... oh, wait...

Why do I continue to try and talk to people on this site?

Re:Wrong Question

[spottedkangaroo]

Oh, I see now. I read that backwards.

I compulsively correct the misconception that java is somehow related to javascript about once per week.

Re:Wrong Question

[huckamania]

The object model comes with overhead. My example of x->work calls y->work calls z->work is something you find in virtually all C++ code. C++ coders don't notice it because to them it is part of the design. Maybe it gets optimized out, but to me it just makes for a lot of grepping to figure out where the bug is.

Re:Wrong Question

[huckamania]

The Flaming Thunder compiler is OO, and it's written entirely in assembly language Never heard of it, but I'll check it out. Whoever came up with the name is a genius. Are the developers from Australia?

Re:Wrong Question

[David Parker]

>> The Flaming Thunder compiler is OO, and it's written entirely in assembly language

> Never heard of it, but I'll check it out. Whoever came up with the name is a genius. Are the developers from Australia?

Good guess! From Utah, but the landscape is very similar.

Re:Wrong Question

[krog]

Oh, I don't know, you can make some pretty big programs with lanugages like PERL, Python, and Ruby. Also, Javascript is no slouch either, and it's based upon Self rather than Java.

no shit dude, way to ignore what I just said and listen to yourself yap

It's no more of a tarpit than your suggested "unpopular" functional languages.

I'm talking about the tarpit as a metaphor not for a particular language, but for the uselessness a discussion about computer languages takes on when Turing equivalency is brought up to imply practical equivalency. It doesn't, and never will, and anyone who says it does is probably trying to win an argument at all costs.

So, what's your point?

talking to you sucks and I'm through with it

Re:Wrong Question

[krog]

Paul Graham's Prolog-in-Lisp trick from On Lisp is an inspiring example of embedding a DSL in a general-purpose language. However, when you say:

That could easily be done by implementing the solving strategies as functions in a general purpose language, especially if that language supports elegant representation of the inputs to your "logic programming library".

I do not agree with the boldfaced word. Just because it can be done by Paul Graham, in Lisp, doesn't mean Joe Bitslinger has a chance in hell of doing it in C#, or Java, or even Python or Perl or Ruby, or hell -- even Lisp herself. The bottom-up coding style of Lisp does not translate easily to most other languages, even the Lispy ones.

I think it's more suitable for the world at large to have a few good implementations of Prolog to choose from, and then to hook it into whatever general-purpose language is best for the overall task. I think we will see a lot more of this, and better performance thereof, as VMs are extended to support more languages and more interoperability between languages, as e.g. the Parrot VM from the Perl 6 fiasco aspires to do.

If you're Paul Graham, then you can do what you want; just because Stormtroopers use guns doesn't mean that the Jedi shouldn't use light sabers.

I'll leave you with Greenspun's Tenth Rule, and RTM's Corollary:

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -- Philip Greenspun

"...Including Common Lisp." -- Robert Morris

Re:Wrong Question

[try_anything]

The object model comes with overhead. My example of x->work calls y->work calls z->work is something you find in virtually all C++ code.

That's just code complexity, managed using object-oriented programming. These days C evokes a design style, where a library does one thing and does it in very no-nonsense, straightforward way. Unfortunately, that just doesn't work for a lot of development tasks. Sometimes you have to have bells and whistles and a zillion super-configurable features. The people who implement the bells and whistles rarely use C anymore.

They *used* to use C, and it was damned ugly. They got to choose between two design paradigms: procedural programming and OO. I've had to use ancient procedural libraries from my C++ programs, and I just tear my hair out at the things people used to do before OO. Things that would be fairly simple in an OO style became arcane collections of systematically-named methods of fifteen parameters each. Large procedural systems were awful, so people started implementing large systems using OO. That was a big factor in the early success of C++: people were doing OO development in C and were suffering because of the lack of language support. Basically, C++ was invented so that nobody would ever again have to fake things like polymorphism and inheritance in C. (But of course they went ahead and invented Gnome/GTK+ anyway, and now they're stuck using C macros to express inheritance relationships.)

Really, comparing the simplicity of C to the complexity of C++ only takes two forms. Either you're mocking the skill of the C++ programmer, who overlooked a simpler C-style way of solving his problem, or you're regretting the complexity of the problem that has to be solved. Usually it's the second. I'm guilty of this kind of reasoning all the time, when I say things like, "I wish I could ride my bike to <my favorite restaurant>." My favorite restaurant is thirty miles away, and I actually *could* ride my bike there. It would be sweaty, time-consuming, and a bit dangerous, but I could do it. Obviously when I say I wish I could do it, I mean that I wish that the task of getting there was an easier one that could be reasonably managed with a simple, satisfying, human-scale tool instead of a noisy, smelly monstrosity that is impossible for one person to fully understand. Still, in the end I have to admit that the restaurant really is thirty miles away, it isn't going to get any closer, and consequently it's more pleasant to drive.

Re:Wrong Question

[huckamania]

Nice analogy, and you never once actually used the word 'car'.

I would tend to agree with some of what you are saying, but I stand on the point that OOD does not require an OOL. OOD is a way of thinking about problems. Usually I anthropomorphize whatever piece of a system I am working on, which is a way of objectizing things (isa, hasa, usesa). I do this regardless of the language.

you're regretting the complexity of the problem that has to be solved

I would say that people in general make problems out to be more complex then they really are. OOD is a way of breaking problems down into manageable pieces. Those pieces should be written in the best language available. Sometimes that is C++ but not always. A lot of times it is faster and easier to use C or perl or something else, if you even have a choice in the matter.

Re:Wrong Question

[Pictish Prince]

I disagree that Smalltalk is all or nothing. Objective-C is a strict superset of C (i.e. it will compile unmodified C programs) that incorporates Smalltalk objects and messaging. You can start out in C and only use as much Smalltalk as you want.

I read about Smalltalk in the '80s and was enamored. Unfortunately, I couldn't afford a Lisa and I wasn't an accredited learning institution so I couldn't buy a NeXT. With OSX I can now have Smalltalk (via Objective-C) and a BSD OS. Also I have the Cocoa framework, aka NeXTStep, which is all done in Objective-C. Cocoa is a great coding style guide as well. If you know how to spell and conform to the naming rules, you'll much less rarely have to go searching for the name of a class or message in the documentation. Even memory management is straightforward if you emulate the Cocoa code.

So no FFI needed. I do use Camelbones because the perl's regex and other text processing capabilities are so superior to everything else.

Re:Wrong Question

[Dutch_Cap]

I'm guessing you meant:
(+ (+ 1 2) 3)
which can be simplified to:
(+ 1 2 3)

Re:Wrong Question

[pushf popf]

Instead of a new language, try a new point of view and a new way of approaching problems.

It doesn't really matter if you program in PHP or Java or APL, what matters is how you think about problems.

For example, some very data-intensive applications are better served using in-memory hash tables and low level file I/O than a general purpose disk-based database, however programmers have been trained that data = DBMS.

A properly chosen algorithm will beat the pants off of big hardware any day of the week, however programmers are taught to use specific approaches to different classes of problems and don't always produce optimum solutions.

Re:Wrong Question

[Anonymous Coward]

Parent wrote:

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

I think maybe you're being facetious or at least didn't put a lot of effort into that example, since that the distinction of a "line" versus an "expression" is a bit of a straw man here. Anyone who has ever studied compiler theory knows that the two are functionally equivalent. I can write a parser that produces the same AST given those two inputs after SSA. With constant folding they'll both return a constant value of 6.

The real power of lisp is in concepts like first class functions, continuations (which are more evil than goto imho, unless they're limited to one-shot), and macros. Those are things that "break out" from the abstract syntax tree and provide unique runtime control flow options that aren't present in more traditional languages (without basically writing a lisp interpreter).

What Languages?

[TheRaven64]

I'm sure I've already answered that question. I'd probably add FORTH and Self to that list now (Self is particularly important if you want to ever fully understand JavaScript).

Re:What Languages?

[Chris Mattern]

FORTH learn to want I would why?

Re:What Languages?

[CRCulver]

Self is particularly important if you want to ever fully understand JavaScript

I'd like to completely annihilate JavaScript from the face of the Earth. Do you know a way to do that?

Re:What Languages?

[Anonymous Coward]

You really should learn JavaScript. It's a very nice language once you understand it.

Unless you do understand it, and want to eradicate the dumbass decisions that the language is now crippled with when it comes to the standard library and various other braindeadness, like the fact that it's completely impossible to determine if an object is an array or not. (And, no, "instanceof Array" doesn't always work.)

And you can wonder why on earth JavaScript has the only object-oriented system I know of where child classes can REMOVE properties and methods they inherited from parent classes.

(In other words, just because Bar is-a Foo and Foo has a property Baz does not mean that Bar has a property Baz.)

But other than the brain-dead object system (which, to be fair, a lot of scripting languages fail at), and the completely brain-dead standard libraries, and the complete lack of the concept of namespaces, JavaScript is actually a fairly nice scripting language.

Or could have been.

Re:What Languages?

[Jeremiah Cornelius]

XSS

Re:What Languages?

[kat_skan]

Because what Yoda would use is it.

Re:What Languages?

[penapoco]

Master Yoda, is that you?

Re:What Languages?

[ucblockhead]

FORTH 4K fits

Re:What Languages?

[Tipa]

You mean:

I FORTH learn want would why :P

Re:What Languages?

[mini me]

JavaScript has the only object-oriented system I know of where child classes can REMOVE properties and methods they inherited from parent classes.

Javascript doesn't have classes, it's a prototype-based language. But I agree, Javascript is awesome. It's up there as one of my favourite languages.

Re:What Languages?

[Toonol]

Just to answer you seriously, it's because you'll learn something new while programming Forth. Not the RPN; that's really just a detail. What is unique about Forth is the way most non-trivial applications end up practically rewriting or extending the compiler itself. Sure, other languages do it, but with Forth it's really in your face. Not just defining new procedures, but effectively patching into the compilation loop.

Sure, all languages are interchangeable, to a degree. You can do object oriented programming in Basic, and so forth. But different languages make different approaches more natural, will make different techniques more elegant. Forth will nudge you to do things differently than most other languages, and that will result in you becoming a better programmer in all languages.

The same applies to many other niche languages. I'm not trying to hype Forth. I'm hyping diversity.

Re:What Languages?

[Anonymous Coward]

So Yoda wrote the language spec...now everything about it makes sense. Sort of.

Re:What Languages?

[Anonymous Coward]

What's the stack effect of :P ?

Re:What Languages?

[megaditto]

Unrecognised command. Drops your whole stack to shit.

Re:What Languages?

[shoor]

FORTH you say? How about its child, Postscript?

Re:What Languages?

[Anonymous Coward]

From the security POV, Forth programs can be vulnerable to some buffer overflow problems. It's a bit like C in that respect. So one should be careful when using it for important stuff.

Re:What Languages?

[maxwell demon]

However in the movie they always mispronounced "FORTH", so it sounded like "Force".

Re:What Languages?

[mollymoo]

ECMAScript 4 has classes, namespaces, static types and a bunch of other stuff that you find in "proper" languages.

Re:What Languages?

[Richard W.M. Jones]

Obligatory:

My FORTH tutorial

Rich.

Re:What Languages?

[Comboman]

Thinking FORTH is a great text on FORTH programming (and programming in general) and it's now available for free.

Re:What Languages?

[Anonymous Coward]

May the Forth be with you!

Specialization Versus Breadth

[eldavojohn]

I seem to be at odds here with this mentality.

Stepping outside your comfort zone is a great thing if you have the time or need to do it. Me, I learned scheme & lisp, prolog, a number of instruction set languages and various scripting languages in my undergrad. Because I needed to see what it was like in realms other than Java & C++.

However, these days, I spend my free time looking at frameworks for the latter two languages. Do I want to know Ruby? Sure. But it's not going to make me better at my job. My employer has me jumping from JBoss to Weblogic to Websphere to Jetty to Glassfish to ... whatever's under the sun for application container and all the while I'm trying to be an expert at Maven (which seems limitless) and Ant so I can do a decent job building. Not to mention the UI aspects: JSF, Tiles, Javascript, AJAX, DHTML, JSPs, JSeamless, Flex, GWT ... they just go on and on.

I hate to say it but this specialization programming and time spent with other people's frameworks and libraries seems to make me more valuable in my own realm. You're right, it's a good idea for me to pick up Ruby (or whatever I'm supposed to learn next) because Java is not going to be around forever. But honestly, I feel a lot of people around me could stop re-inventing the wheel week after week at work and just take a couple days to tweak someone else's solution to work.

That said, Lisp & Prolog were my most favorite and least practical languages I've learned (I think Lisp stands for Lost In Stupid Parentheses).

I guess my answer to your question just another question: "What is your motive for learning a new language?" If it's to broaden your view of the world, go with something out of left field. If it's to be more valuable or better at what you do in Java, C++, Pearl, etc then I would actually tell you to start learning how everyone uses those languages.

Honestly, a lot of the older coders I know just don't have the time. The company will both pay for and tell them what they need to learn next or they ain't learning anything at all.

Re:Specialization Versus Breadth

[mckinnsb]

The interesting part about specializing in libraries or frameworks for a language you already know is that it often shows you how to use the language in ways you never thought of, or thought impossible.

Lately I've been doing a lot of stuff with JavaScript, and mooTools has been a framework I've invested a lot of time into. The first time I remember reading the tutorials, I asked myself "The hell? This is javascript?". After a while, I realized that with mooTools and a little creativity, I could create many flash-like effects, without flash. The same thing happened when I started to use CodeIgniter, a PHP framework. I had simply never seen PHP coded in that fashion before. Especially with PHP 5, CI becomes extremely OOP-like, with MCV and everything.When I went to school, the words "Object Oriented" and "Model View Controller" were *never* talked about in my PHP class (even during the advanced segments).

That being said, if you want something that will truly test your resolve as a programmer, I'd try to learn ML. It's not very useful, at all, (although some of its variants are used widely in scientific fields) but it will teach you a lot about type-checking, and how very *nice* a C or Java compiler is to you. Ruby is also a good thing to pick up, especially once you realize how awesome the migrations are in Ruby.

Re:Specialization Versus Breadth

[mardin]

I would advice a framework as well, for one of the available languages you know. My current favorite is Spring. It's not new anymore, but I'm learning a lot about Java and building advanced web apps with much more ease then I thought possible before.

Re:Specialization Versus Breadth

[fahrbot-bot]

That said, Lisp & Prolog were my most favorite and least practical languages I've learned.

Yes, but they're wonderful research languages. I did work on automated programming techniques using abstract data types in LISP (on a Xerox LISP workstation) and n-version fault tolerant programming in PROLOG - both way back in 1985-87. I'd love to get back to using LISP... Still have my InterLISP-D manual too. :-)

Re:Specialization Versus Breadth

[RAMMS EIN]

``I hate to say it but this specialization programming and time spent with other people's frameworks and libraries seems to make me more valuable in my own realm.''

Why would you hate to say that? It's the simple truth. Learning more Java and .NET, and more Java and .NET frameworks is obviously going to make you a more valuable Java and .NET programmer.

``You're right, it's a good idea for me to pick up Ruby (or whatever I'm supposed to learn next) because Java is not going to be around forever.''

Since you already know Lisp, I don't think Ruby is going to teach you a lot. Although, of all the programming languages I know, Ruby is the one that offers the least resistance, in that it allows me to simply do what I want to do. But I think its main advantages over Lisp are just that some idioms are slightly less verbose in Ruby (e.g. blocks vs. lambda, a[1] = 42 vs (setf (aref a 1) 42)) and that it ships with libraries for many modern times needs, such as TCP/IP and XML (whereas, with Lisp, these are, at best, not standardized).

``But honestly, I feel a lot of people around me could stop re-inventing the wheel week after week at work and just take a couple days to tweak someone else's solution to work. ''

And that is exactly why I resent Java. The whole culture, from the initial language design up to the latest and greatest framework, is full of reinventing the wheel and, often enough, touting the reinvention as a Great New Thing. Just imagine what could have been accomplished if all the effort that has gone into Java, the standard library, the build tools, etc. etc. had been used to improve an existing language and set of libraries, build tools, etc. And if all the effort that has gone in building yet another build tool, XML library, GUI library, or whatever, because the previous one wasn't good enough, had gone into existing systems, too. And if people looked at the strengths and weaknesses of existing solutions more, so that they would have avoided going through the "make mistakes, fix mistakes, end up with the same thing that somebody else already made before, but incompatible" cycle.

Of course, sometimes it's good to start over. You can't build a solid house on weak foundations. It's not even bad to have multiple languages, build tools, XML libraries, and whatnot. Competition among them will keep everybody motivated to improve their favorite. Just look at Java and .NET: .NET is basically Java with some of Java's mistakes fixed, and now Java and .NET are both innovating like crazy to be better than the other. Suddenly, we have generics, proper type systems, multiple languages on the same VM, etc.

Re:Specialization Versus Breadth

[pinkstuff]

I 100% agree. Just because one understands how to use 'Java' doesn't mean they know how to use Java for web development, enterprise development, games development etc etc. Even if you stick to one niche such as enterprise development, you could spend a lifetime learning all of the API's. So yeah sure, play around and see what's out there, IMHO tho, in the real world it is extremely difficult to be a guru in more than one language.

Re:Specialization Versus Breadth

[Z-MaxX]

Do I want to know Ruby? Sure. But it's not going to make me better at my job. My employer has me jumping from JBoss to Weblogic to Websphere to Jetty to Glassfish to ... whatever's under the sun for application container and all the while I'm trying to be an expert at Maven (which seems limitless) and Ant so I can do a decent job building. Not to mention the UI aspects: JSF, Tiles, Javascript, AJAX, DHTML, JSPs, JSeamless, Flex, GWT ... they just go on and on.
...
Honestly, a lot of the older coders I know just don't have the time. The company will both pay for and tell them what they need to learn next or they ain't learning anything at all. This sounds like a case of picking a tool and then trying to apply it to your problem--and switching to another tool one whenever something "new" and "cool" comes out--which is totally bass-ackwards.

By having a breadth of knowledge and skills, you can make informed, smart choices about what language, framework, technology, etc. is best suited to solving your problem. Should your current problem be solved with a "Web 2.0" interface, a rich client application, etc. In your case, you should know what the benefits and downsides of the various J2EE containers are, and in fact, you need to know what using J2EE in the first place is buying you. Make informed decisions that help you solve your problem.

JSP, Servlet, PHP, and Rails programmers should have experience with Java Swing, Java Web Start, and other technologies in order to decide what the optimal solution is -- or at least, the lead developer or senior software engineer needs to have an exceptionally wide range of skills in order to make these kinds of decisions.

My team was stuck for years on a project that was forced into a web application mold (using Java servlets, JSP, Apache Struts, etc.) which caused us relentless headaches for most of the time. It should have been a regular application! A rich client. For many reasons. Unfortunately, at the inception of the project, the project lead had firmly decided that it had to be a web application.

At my employer, I'm constantly learning new technologies to find new and better ways to solve problems. You need to be proactive and take the lead, and solve problems! I had previously been focused mostly on graphics programming, Java application and web programming, but when my project needed it, I learned about embedded programming, embedded operating systems, electronic design, microcontroller programming, etc., on my own. I learned how to do things that no one at the company has done yet, and I have found ways to make our product orders of magnitude better (10x smaller, 10x more battery life, 10x better performance). Since many of my colleagues are focused on their more specialized areas of expertise (e.g., Java application programming, or Java web programming, or functional testing, or database programming, or electronic circuit design), I actually am often frustrated because I have no one to consult with when I have a problem to solve.

You express concern about learning technologies you will never use, but the fact is, that unless you acquire some other areas of expertise, you will never know what is the best tool for the job!

Re:Specialization Versus Breadth

[GargamelSpaceman]

Cool languages I've read about, maybe used, but not played with nearly enough:

• Lambda calculus-ish
  • Scheme
  • Haskell
• Combinator/Forth-ish
  • Joy
  • Interesting but not practical: unlamdba iota and jot
• Logic
  • Prolog
  • Mercury - compiled and pure
  • Lygon - prolog like linear logic programming.
• Pi calculus-ish
  • Join calculus
  • Nomadic Pict

I think I want to master logic programming next, though it may be better for me to do some haskell programming first so I have a better foundation. Monads/Arrows give me a headache, but with enough time, I'm sure I could get used to them. s-expressions a-la lisp/scheme are very similar to xml, except better, but logic programming seems more likely to make the hardest parts of internet programming easier.

Unfortuately, I have nowhere near enough time to get proficient in all these languages.

Re:Specialization Versus Breadth

[BotnetZombie]

Java & C++

I think you meant Java && C++, I'm too scared to imagine what the bitwise AND outcome is :/

Re:Specialization Versus Breadth

[rrobbins]

You don't need to master an entire language to evaluate the best tool for the job. Selecting the technology you will develop your expertise in is an interesting game of strategy. I think an obscure, neglected, but widely used language is a good bet if you want steady employment. I would learn RPG and COBOL but there is plenty of work available in web development so I'll stick with advanced JavaScript and pick up more PHP.

10100001010

[midianus]

01000101012

Re:10100001010

[jellomizer]

Coding in Trinary doesn't help unless you know the system architecture.

Re:10100001010

[oatworm]

Don't worry. There's no such thing as a two.

Re:10100001010

[StarvingSE]

Liar! Everyone knows there's no such thing as 2!

Re:10100001010

[Shadow-isoHunt]

What happens when a CPU gos "OH SHI-"?

Love the 'iPhone' tag

[Naughty Bob]

We really have some obscurity-loving masochists among our ranks.

Re:Love the 'iPhone' tag

[Anonymous Coward]

Nah, they would mark it perl/awk/sed then.

no Ps

[whtmarker]

php, perl, and python are not even included in the list.

Re:no Ps

[andy19]

Everyone already knows those inside and out...I think learning something a little more obscure or more up-and-coming than the P's is what the article is trying to get at- expanding your horizons in programming.

Re:no Ps

[Anonymous Coward]

PHP and Perl for good reason.

Re:no Ps

[Millennium]

Agreed. Anyone in doubt as to what language to learn next probably either already knows these languages or has already decided against them for whatever reason.

Re:no Ps

[LighterShadeOfBlack]

As opposed to Ruby? Ruby is more hyped right now than any other language I know of - Ruby on Rails in particular.

Re:no Ps

[mastermemorex]

And everybody has fogotten D? The most versatile an powerful of all languages?
http://www.digitalmars.com/d/

On the other hand, I is also important that the language of my choice should have a wondeful IDE with an integrated debugger, wonderful and tested libraries with nice GUIs, and a wonderful Linux-Windows-Mac interoperability.

Re:no Ps

[Millennium]

It's got a lot of hype, sure, but is it really famous? I'm not so sure. Certainly more people have heard of PHP and Perl, and while Python's a little more iffy in that regard it's probably still more well-known.

Re:no Ps

[rawler]

I second that. D has probably the best potential of all right now. The one thing they HAVE missed, though, is good fundamentals for parallelism. Threads just don't cut it, and even threads aren't really built into the language for D.

Why are monads cheating?

[morgan_greywolf]

Why are monads cheating? My understanding is that one of the biggest reasons people like Haskell is for its support of monads. Isn't that a bit like saying using regular expressions in Perl is cheating?

Re:Why are monads cheating?

[Eli Gottlieb]

Monads are a way of explicitly bolting state and imperative programming onto a pure-functional language. By using them, you lose many of the benefits of a pure-functional language.

Re:Why are monads cheating?

[tilk]

No. Expressing imperative calculations is just one thing monads are good for. There are lots of other things. Parsing, for example. Did you see Parsec? It allows you to express parsers naturally in Haskell, without any preprocessing (or C++ template cheating, like in Boost.Spirit).

Re:Why are monads cheating?

[Pseudonym]

I think that TFA had a point, but expressed it poorly. His point was that you should learn the functional core before using monads, and learning an ML-family language first will essentially force you to do this. IMO, this actually isn't too bad as advice goes:

1. If you've only ever used procedural (or even logic) languages before, you'll be tempted to put everything in a monad, which is bad for your health. Like any programming language, to use a feature well, you need to know when to apply it and when not to apply it. A better analogy is that in Perl, you should learn regular expressions before you try to make a Perl object.
2. The bits of the type system that support monads are advanced, and beyond the experience of programmers who have only ever used Algol-like type systems. And monads are just the first step: After that, there's STM, Arrows and lots of esoteric abstract mathematics made useful. You will never grok the seriously cool stuff if you don't "get" Hindley-Milner.

English

[WillAffleckUW]

Because I can't read the comments in your code that are like this: // GRPL nvm lol grep nsfw sew oui ussse perrl

Python?

[freshman_a]

I'm surprised there was no mention of Python. I think Python is a good language to know. It seems to be used a number of places and forces people to write easily readable (and therefore maintainable) code. And I thought it was pretty easy to learn, especially if you have OOP experience.

Re:Python?

[TheRaven64]

and forces people to write easily readable (and therefore maintainable) code. I really need to bookmark this comment so I can come back to it next time I use a Python program. I have yet to encounter a single piece of nontrivial Python code that actually worked as its author claimed and didn't require debugging before actually being used. It is quite possibly the worst mainstream language, since it has half-arsed support for a load of different paradigms and yet manages to fail to support any of them well. On the plus side, most of the old VB programmers have migrated to Python, and it's probably a step up for them...

Re:Python?

[Otter]

I love Python, but it doesn't really serve as a good example for this discussion because of what another commenter refers to as "half-arsed support for a load of different paradigms". If you want to stretch your mind with immersion in a different way of doing things, Python's collection of diverse best practices isn't an efficient way to do it.

Re:Python?

[uniquename72]

I have yet to encounter a single piece of nontrivial Python code that actually worked as its author claimed and didn't require debugging before actually being used. The same could be said for any language under the sun if no specific examples are given.

(not a Python guy...just sayin')

Re:Python?

[KillerEggRoll]

So your point is that you use shitty programs, maintain shitty code, and work with shitty programmers? How does that translate to being a problem with the language?

Re:Python?

[melted]

Geez, a language without a proper for loop. Where do I sign up? And before anyone jumps at me, I know there's the for keyword in Python. It just doesn't work the same - just try to iterate from 0 to 2 billion and see.

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

Re:Python?

[Just Some Guy]

And before anyone jumps at me, I know there's the for keyword in Python. It just doesn't work the same - just try to iterate from 0 to 2 billion and see.

Ummm, what?

for i in xrange(2000000000): pass

Was it supposed to do something interesting?

Re:Python?

[Russ Nelson]

I have yet to encounter a single piece of nontrivial Python code that didn't work as its author claimed nor any that required debugging before actually being used.

Maybe you need to hang out with better programmers, TheRaven64?

Re:Python?

[sowth]

Perhaps the guy who created Python assumed everyone knew how to do what you are talking about with a while loop. More or less C's for(x=0; x<10; x++); is the same as x=0; while(x<10) x++;

Pythons's iterate through every element for loop is a very useful thing. Instead of expressing to the computer how to count through the size of the array/whatever and tell it how to pick out each element, you just say I want to do something with every element in this variable then you can just do it. If you need an efficient way of counting, use a while loop, not the for/range combo.

Re:Python?

[Speare]

And before anyone jumps at me, I know there's the for keyword in Python. It just doesn't work the same - just try to iterate from 0 to 2 billion and see. I expect that you're getting at the likelihood of using range(2000000000) instead of xrange(2000000000). The first will happily consume your RAM to make a list of two billion integers. You encounter this, you learn your way around it and learn more about python in the process. If you missed the i++ step of a C for loop, you'd get similar results for different reasons. It's a learning opportunity and every language has 'em.

Re:Python?

[ArmyOfFun]

I'm confused, what's the problem? The following works.

for x in xrange(0,2000000000): print x

Re:Python?

[KillerEggRoll]

for i in xrange( 2000000000 ): dosomething(i) (Don't forget the optional stepping and start arguments!) With the caveat that the xrange arguments must fit in a native C long. (Should have said 3 billion!) In Python 3000, xrange will become the new range. Hopefully it will be without the current storage limitation. A better gripe would be that you can't take advantage of overloaded arithmetic operators as you can in C++ for loops. But isn't that a good thing?

Re:Python?

[Russ Nelson]

Is it too much to ask that people not comment in the middle of a stupid attack? Here, read:

for i in xrange(2000000000+1):
        if i % 1000 == 0:
                print "melted is a doo-doo head",i

It got up to 124 million doo-doo heads before I decided to see how fast a plain loop could go:

for i in xrange(2000000000+1):
        pass

4m15s. Much faster than *I* could count up to 2 billion.

Re:Python?

[Minwee]

How could a shitty programmer write shitty code in a language that "forces people to write easily readable (and therefore maintainable) code"?

Either the magic power of python can imbue even the most inept programmer with the ability to write easily maintainable code or it can't. Do you need a whiteboard and some smelly markers to see what this thread is about?

Re:Python?

[DeadDecoy]

I'm just picking up python now, converting some perl code, and it seems pretty nice so far. I've jumped into a few languages and the reason I haven't used python in the past is that there wasn't a need. If I needed some prior solution I could always pick up java and hunt down a library from the community. If I needed something quick and dirty (or doing sequence analysis stuff) I'd use Perl. Hence, my utility for switching to something slightly better but with essentially the same functionality was low. I think it was a problem in that I got introduced to the other stuff first and Python didn't fullfil and niche role.

Re:Python?

[mollymoo]

Why on earth do you think code being readable means it has to work properly? That's a logical non-sequitur. Various languages can and do reduce or eliminate various classes of potential bugs, but none can force a programmer to write good code.

Re:Python?

[Brandon30X]

Ok I tried it:

for i in xrange(2000000000):
    if (i%1000000) == 0: print i

Its slow, and I stopped it after about 200 Million, but I don't see the problem.
-Brandon

Re:Python?

[Alpha830RulZ]

Use google much? It seems to work pretty well there.

Re:Python?

[KillerEggRoll]

Yes, I am partial to root beer and grape scents. :-)

mollymoo answered more eloquently than I could ever have. The GGP post made no claims countering the argument on readability and then made an empty and unrelated argument about Python only having half-assed support for various paradigms.

On the topic of readability, I would add though that Python does not force people to write readable code...it "gently encourages" by encoding a simple whitespace idiom into its specification. There are ways to defeat the readability (escape characters and whatnot).

Re:Python?

[theNeophile]

I really need to bookmark this comment so I can come back to it next time I use a Python program. I have yet to encounter a single piece of nontrivial Python code that actually worked as its author claimed and didn't require debugging before actually being used. It is quite possibly the worst mainstream language, since it has half-arsed support for a load of different paradigms and yet manages to fail to support any of them well. On the plus side, most of the old VB programmers have migrated to Python, and it's probably a step up for them... Well, there's your problem.

Re:Python?

[Anonymous Coward]

In fairness, Bad Things would happen if you used range() instead of xrange() there. But starting with Python 3.0, there won't be both range() and xrange(), just one thing called range() that works like xrange(). In other words, this is a bug in Python, but it's known and they are already fixing it.

No language is perfect, yo, but Python is still awesome.

Re:Python?

[maxwell demon]

So your point is that you use shitty programs, maintain shitty code, and work with shitty programmers? How does that translate to being a problem with the language? He answered to a post which claimed that Python forces you to write non-shitty code. The fact that he regularly gets shitty Python code contradicts that claim.

Of course we all know that real programmers can write FORTRAN in every language. :-)

Re:Python?

[HeroreV]

I love Python, but it doesn't really make me think in new ways like e.g. Lisp does. When you just want to get something done, Python is really great, but if you're trying to expand your horizons, I think Python would be a bad choice.

Go try something different, then come back and apply in Python what you've learned.

Re:Python?

[Just Some Guy]

If you need an efficient way of counting, use a while loop, not the for/range combo.

I think you're looking for enumerate().

Re:Python?

[linguizic]

Yeah, if you're good with OO like Java but like the freedom and flexibillity of Perl then Python really is the place to be. It's like Red Bull, it gives you wings.

Re:Python?

[Anonymous Coward]

I think Python is enough better than Perl to be a win here. But you may disagree.

I know where you care coming from, because I feel the same way about Ruby. Python sits in about the same niche as Ruby, I don't need both, and I'm happy with Python.

Re:Python?

[jjig]

Python is a powerful language to know, but also very easy to learn and use. It is what many would call "executable pseudocode". In other words, when programmers discuss and draft code in pseudocode, it very often turns out to be a lot like Python. That's because Python syntax is simple, straightforward, and what people would expect.
I would agree very much that Python code is readable and maintainable.
More information on Python is available from the Python website.

Re:Python?

[Anonymous Coward]

I agree. We coded quite a few of our internal applications in ruby before realizing that python is has much larger mindshare. That means more libraries, better tools, etc. We are slowly switching everything from ruby to python for that reason. Its going well. Although I like the ruby syntax better python just seems to flow better. Cant put my finger on why though.

Re:Python?

[David Parker]

> Python syntax is simple, straightforward, and what people would expect.

Flaming Thunder is much more simple, straightforward,
and much more what people would expect.

English: Write "Hello world!".
Flaming Thunder: Write "Hello world!".
Python: Print "Hello world!"

Math books: 10^2 = 100.
Calculators: 10^2 = 100.
Math teachers: 10^2 = 100.
Flaming Thunder: 10^2 = 100.
Python: 10^2 == 2.

Re:Python?

[David Parker]

> Flaming Thunder is much more simple, straightforward,
> and much more what people would expect.
> ...
> Math books: 10^2 = 100.
> Calculators: 10^2 = 100.
> Math teachers: 10^2 = 100.
> Flaming Thunder: 10^2 = 100.
> Python: 10^2 == 2.

Oops, that should be:

Python: 10^2 == 8.

Re:Python?

[Anonymous Coward]

Why on earth do you think code being readable means it has to work properly?

He didn't say anything about whether the code works or not, he said "shitty code", which could easily translate to "unreadable and unmaintainable", thereby exposing the OP as the lying fundamentalist that he is.

Re:Python?

[Anonymous Coward]

and forces people to write easily readable (and therefore maintainable) code.

Why do all you idiot Python fundies insist on spreading this ridiculous lie? Python forces absolutely nothing.

Re:Python?

[Anonymous Coward]

He didn't say anything about whether the code works or not, he said "shitty code", which could easily translate to "unreadable and unmaintainable", thereby exposing the OP as the lying fundamentalist that he is. Someone is exposed by your ability to put words in other people's mouths? Bravo!

SQL is next for me

[damn_registrars]

I learned BASIC back in the days of the C64. I then learned Perl when I decided to try my hand at bioinformatics. I picked up C++ at the same time. But there was one language that was used regularly there that always made me feel like a fool.

SQL.

Everything about it seemed backwards and inside out to me. I had a hard time wrapping my mind around "accountant-speak" and "normal forms" (still not sure WTF that means). Yet i know it will likely be in my future. Too much data resides in tables now, and too much data interpretation comes down to data(base) mining. Even the perl::sql modules couldn't save me completely.

So I would say, if you plan for a career that is data-driven, learn SQL if you haven't already. It certainly doesn't seem to get easier to pick up as you wait longer - or at least it hasn't for me.

Re:SQL is next for me

[andy19]

I agree. SQL is definitely something more people should know. It's very different from other programming languages, and when used properly it's extremely powerful. With the amount of software that uses databases, SQL is a must-know language in my opinion.

Re:SQL is next for me

[jellomizer]

I actually have a lot of fun with SQL. It is actually a good language to get your mind around. Knowledge working with LISP does help there are some strong similarities.

Because except for Procedural Languages such as Basic and C. You don't normally look at the Data one unit at a time. But you do your calculations on the entire set.

You can using a cursor make it so you can do a normal loop and for with variables. But for most cases it is easier to do a one line SQL call.

SELECT (X/(SELECT SUM(X) FROM A as B))*100 as PCT from A

It has a LISP like quality to it.

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.

Re:SQL is next for me

[ExCEPTION]

You haven't mentioned Java nor .Net, so I am not sure if ORM will fit your needs. Thanks to Hibernate and EJB3, I am losing my SQL skills and no regret at all. You still need to understand the workings of RDBM, but you can concentrate on OO stuff when programming.

Re:SQL is next for me

[skrolle2]

The only important thing to know about SQL is that it is a declarative language, i.e. in the same family as Prolog. Common to them is that you state how you would want the world to look like, and let the language runtime figure out how to actually do it. This is totally contrary to imperative languages which is a series of explicit instructions, i.e. "first do this, then do that." In SQL you simply state "I wish to have the data that satisfies these criteria. Give it to me. Now."

Re:SQL is next for me

[redhog]

I usually dislike SQL for not being mind bogling enought. But that's just because I know Prolog, and secretly wishes that SQL was prolog...
Anyway, there is one thing I tend to end up doing quite often, and that SQL engines should have been able to optimize, but never seems to manage: pairing every row in a table with the next or previous row. This operation should be O(n), but ends up being O(n), since it's a join... Typical example is a table of timestamps, and you want the deltas between each timestamp and the next (but there are numerous other examples).

Re:SQL is next for me

[Alexandre Lemiere]

If you are looking for a new paradigm, definitely go for SQL, the declarative paradigm is so different than the imperative-procedural one, that some people don't consider it a programming language !
SQL syntax is not fun and looks old style, but concepts are so powerful. Don't forget it's based on relational algebra.

Note that you can also write procedural code with proprietary DB syntax, with cursors and so on, learn nothing new and usually be far less effective...

Re:SQL is next for me

[MajinBlayze]

The problem that most OO/Procedural programmers have when using SQL is the inability to look at things from a set-based point of view. I've seen programmers write some nasty, horribly performing procedures because they can only think about things 1 record at a time.

Now, on that note, there are ORMs that do a great job at helping with this mentality. SqlAlchemy's Unit of Work paradigm is a serious godsend. (I only wish there were something equivalent in one of our company's "official languages")

P.S. I'm a MS SQL DBA with 4 years experience, and so you all don't think I'm a complete Microsoftie, I use Postgres at home, and there are many parts of each that I prefer. IMO the only thing it's missing to compete with MS SQL are bundled/integrated Reporting/OLAP servers

Re:SQL is next for me

[Dragonslicer]

It's very different from other programming languages That's because SQL generally isn't considered a programming language. Straight SQL (i.e. not PL/SQL) is not, to my knowledge, a Turing-complete language.

Re:SQL is next for me

[Dragonslicer]

Keep in mind that learning SQL to pull data from existing databases and learning proper database design can be two very different things. Knowing all about normalization will help if you're writing queries, but it's absolutely critical if you're doing original database design.

There's also the issue that SQL is a rather poorly-followed standard. Different database systems implement slightly different variations of standard SQL. It's rather like knowing C, Perl, and PHP, or Java and C#; they're similar enough that the basic form looks the same, but there are a couple important differences that can catch you by surprise if you aren't careful.

Re:SQL is next for me

[mooingyak]

Give it to me. Now.

That depends on the size of your data, and the quality of your hardware and/or indexes. It frequently comes much closer to "Give it to me. When you have a moment."

Re:SQL is next for me

[hoggoth]

> "normal forms" (still not sure WTF that means)

Greatly simplified: Any time you have redundant copies of the same data, there is the possibility that the two copies could get out of sync. For example:

StaffTable: EmployeeID, EmployeeName, PhoneNumber, ProjectName

In these tables, an employee can appear multiple times if he/she is on multiple projects. 'PhoneNumber' and 'EmployeeName' is redundant in each copy and the possibility exists that one copy of an employee's name or phone number could be updated without all of the matching copies also being updated, thus creating an conflict or error.

"Normal Forms" eliminates this possibility by requiring that redundant data is factored out, split into separate tables if necessary. There should be just a single "key" field that relates data between separate tables, for example:

StaffTable: EmployeeID, EmployeeName, PhoneNumber
ProjectTable: ProjectID, ProjectName
ProjectStaffing: ProjectID, EmployeeID

In this more "normalized" version there is only one record in the StaffTable for each employee. There is only one place where an employees name and phone number are recorded. Other references to that employee are references to his EmployeeID which is a "key" into the StaffTable.
The ProjectStaffing table has one record for each valid combination of employee and project.

Normalizing protects your data from programming errors introducing errors into your data. On the downside your code will probably be slower because you need to join tables together more often than with the redundant version of the database.

Re:SQL is next for me

[IdeaMan]

I second the idea of learning about databases in general, and SQL in particular.
Spend some time reading the Comp.Database.Theory newsgroup and learn about the sins that programmers commit while writing code against databases.

If you're too lazy to do that, then at least watch this set of 3 videos on You-tube on how to make your database performance really suck:

http://www.youtube.com/watch?v=40Lnoyv-sXg

Re:SQL is next for me

[Estanislao Mart�nez]

The only important thing to know about SQL is that it is a declarative language, i.e. in the same family as Prolog. Common to them is that you state how you would want the world to look like, and let the language runtime figure out how to actually do it.

Only most of the time. To really master SQL (or Prolog, for that matter), you need to understand how the system actually carries out your queries, and how to optimize that process for the 20% of the queries that end up taking 80% of the time. In most SQL databases, this is done through a number of mechanisms, for example:

1. Indexing tables on the columns used in the slow queries.
2. Hinting the query in order to guide the optimizer into making better choices.
3. Improving the query itself so that the optimizer can pick a better plan. For example, sometimes adding seemingly redundant conditions to a query speeds it up, because it gives the optimizer information that it couldn't figure out on its own.
4. Using materialized views or equivalent features to precompute frequently reused, expensive relations.

Re:SQL is next for me

[moore.dustin]

I am just piggybacking on the SQL as a good 'language'(query language) to learn. Databases are going to be more and more common with the move towards online environments. Also, there is a huge difference between writing queries and design databases. There is also a much high complexity with SQL than most people ever reach. Most people deal with simple queries or straight joins and not much more. Going deeper into complex queries, stored procedures and data integrity is where the rubber meets the road for those learning SQL at a higher level.

Re:SQL is next for me

[foetusinc]

Fer sure. Far to many programmers write SQL off as not really being a programming language. They're half right, and completely wrong. A solid understanding of set theory, normalization, and transactional isolation can turn pages of byzantine procedural code into a single elegant (and fast) stored procedure. The inverse is doubly true.

And if you don't think it's worth learning from an academic point of view, take a look at the base salaries for database developers in your area. There are few other additions to your resume that will net you the same bump in salary.

Re:SQL is next for me

[rrohbeck]

SQL.

Everything about it seemed backwards and inside out to me. If you knew COBOL it would look familiar :)

I had to learn a little COBOL once to hack an interface for a C library that some COBOL folks needed to call.

Yuck.

But it has one "cool" feature like no other language: PERFORM label1 THROUGH label2. Call a piece of code that's inline somewhere else - no RETURN needed! The ultimate spaghetti ingredient! I hear compiler writers don't like it. Always reminds me of Intercal's COME FROM.

Re:SQL is next for me

[mdritchi]

EXACTLY. It is different. It is not a different syntax but a completely different way of programming.

Re:SQL is next for me

[kpharmer]

> learn SQL if you haven't already

Yep

Even if you prefer to use a ORM like hibernate or active record at some point:
- you'll have to modify an application that doesn't use one
- you've got a bug in the ORM and need to compare its behavior against that of raw SQL
- you'll need to diagnose problems quickly in a database - and will want to quickly write a 1-20 little queries to check everything out
- you'll need to aggregate (pre-process) some data - and given SQL's set-orientation will be able to do it faster in the database than in your application. And it'll be running huge queries - maybe generating a dozen or more temp tables. And the ORM won't support your SQL.
- etc, etc, etc

So, go ahead and use the ORM when it makes sense. Just get familiar with SQL as well - it'll save you a ton of time.

Also, back to the original thread: I see programming as building a house and writing sql as playing chess. It is completely different than writing most other code. And there are many times when I'm *very* glad that it is.

Re:SQL is next for me

[Mad Merlin]

Anyway, there is one thing I tend to end up doing quite often, and that SQL engines should have been able to optimize, but never seems to manage: pairing every row in a table with the next or previous row. This operation should be O(n), but ends up being O(n), since it's a join... Typical example is a table of timestamps, and you want the deltas between each timestamp and the next (but there are numerous other examples).

Yeah, darn.

Re:SQL is next for me

[kpharmer]

> If you knew COBOL it would look familiar :)

Not really - you're thinking about stored procedure language. Which if you close one eye and squink with the other I guess could look a little COBOL-esque, that is without the column-orientation, section headings, etc.

SQL on the other hand looks like this:

SELECT dept.dept_name,
              per.rank,
              count(*) as personnel_rank_count
FROM dept_table dept
          INNER JOIN personnel_table per
                ON dept.dept_id = per.dept_id
WHERE dept.dept_type = 'internal'
GROUP BY dept.dept_name,
                  per.rank
ORDER BY 1,2

Re:SQL is next for me

[IdeaMan]

Actually you probably can use it as a programming language.
The point is that if you are, then your code will SUCK.

I understand that COBOL is pretty hot...

[PC and Sony Fanboy]

I hear that COBOL is a pretty good language to learn. It isn't new, but it is old enough to make a comeback (like disco, aviator glasses and big hair)...

Re:I understand that COBOL is pretty hot...

[kellyb9]

I hear that COBOL is a pretty good language to learn. It isn't new, but it is old enough to make a comeback (like disco, aviator glasses and big hair)... The above actually looks like a syntactically correct COBOL statement.

Re:I understand that COBOL is pretty hot...

[Skee09]

Lords of COBOL, hear our prayer.

Re:I understand that COBOL is pretty hot...

[mdritchi]

I totally second the idea of learning SQL. Virtually all business systems run on a database that uses SQL. It is also a VERY different type of language. 20 years of experience doing C++, VB, Fortran doesn't mean squat when it comes to pulling data from a table. As an SQL guru I find that I can be of value in almost any organization and will never have to go long to look for a decent job.

Re:I understand that COBOL is pretty hot...

[hsmyers]

Then we will dig up the 300 spartan programmers and fend COBOL off at the pass. Remember, come home with your pocket protector on on it!

--hsm

Re:I understand that COBOL is pretty hot...

[hsmyers]

err... that would be 'or on it' where's that can of jolt (and why is there dust on it?)?

Re:I understand that COBOL is pretty hot...

[Anonymous Coward]

COBOL is not hot at all. Also its not like other languages. Firstly it has cumbersome syntax and learning a construct in COBOL cannot be ported (knowledge transfer) to another language. Also there are no jobs in the language. And apparently ii is a dead language with many drawback and loads of false truths. Check this out http://en.allexperts.com/q/Cobol-1443/f_3628806.htm its really good. I hope it will stop you going down the wrong route.

Re:I understand that COBOL is pretty hot...

[Anonymous Coward]

Actually, more than 70% of all commercial, production code is COBOL......

Re:I understand that COBOL is pretty hot...

[rubycodez]

it IS getting hot again, the COBOL coders are retiring.

Going from C to others is a matter of right books

[CRCulver]

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.

None of the above...

[Ckwop]

My advice would be to learn formal verification techniques. These can be applied across languages and across platforms. If you deploy them properly you can reduce your defect rate from 50 per 1,000 statements to 2 per 1,000 before the first test case is run.

That will save you far more time than the latest over-hyped platform. While everyone else is fixing bugs in their application, you've already moved on to greener pastures. It will increase your capacity to build really good quality software and not get in to flame wars over nonsense. Nothing quite ends an argument over style more than saying: "Yes, but can you prove that your approach is correct? I can."

Simon

Re:None of the above...

[Anonymous Coward]

"Yes, but can you prove that your approach is correct? I can." You must be a joy to have as a co-worker.

Re:None of the above...

[Ckwop]

"Yes, but can you prove that your approach is correct? I can." You must be a joy to have as a co-worker.

I know that it sounds like I'm a shit but in the real world office environment, I'm no where near that pretentious!

That said, this does not detract from my underlying point: In this industry we are constantly told that the next big thing is going to revolutionize programming. We here this a lot about Ruby on Rail at the moment. We're told that if we just choose the right framework and programming methodology we can produce awesome software on time and on budget.

We fall for it every. single. fucking. time. until. words. lose. all. meaning.

The simple fact is that a large part of the time spent in a project is spent debugging the code we just wrote. Debugging is expensive. You typically have entire departments devoted to testing code. In fact, debugging routinely kills entire projects because it turns in to a very costly version of whack-a-mole and people eventually get tired and run out of money.

I am convinced that the key to improving programmer productivity is to get them to write the software correct, first time. It does not lie in a language or programming style.

Verification is not perfect. In my original comment I said that even after formal verification you can still expect bugs. After verification you can typically expect a similar error rate to conventional testing strategies. This is simply because you have to abstract things and you can make errors in your abstractions. Or you might simply make a mistake in your proof.

The point is, verification does not have to be perfect to be better than unit testing. It simply has to find more defects faster. The evidence out there is starting to suggest that it does. Certainly with very large products.

Simon

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, 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).

Re:None of the above...

[Coryoth]

The point is, verification does not have to be perfect to be better than unit testing. It simply has to find more defects faster. I would go even further, and say that it doesn't even need to be better than unit testing, it just has to be able catch different classes of problems better. Verification isn't (or shouldn't be) a replacement for unit testing, but rather a useful supplement (or unit testing is stilla useful supplement to verification, depending on your point of view). If it catches some errors faster then it's worth using just to weed out those errors earlier. Done right (with appropriate tool support) verification sits alongside unit testing extremely well. What can be stated easily as a specification can be done so: you can apply theorem provers to it, automatically generate unit tests from it, and not have to worry about your API documentation falling out of date because it will be generated from the specification along with those unit tests. For everything else you can write unit tests. None of this is hard once you have learned some specification languages, and the tool support for it (from JML and associated eclipse plugins, to ESpec, to Spec# and associated tools, to SPARK, to just various tools for Z) are getting better every day.

Re:None of the above...

[wfstanle]

I too know how to verify a program but it is no panacea. For most (non -safety critical) applications, it is too labor intensive to be used. Would you use verification to create a game? Absolutely not! However, if you are software for the avionics of a plane are the software on a medical respirator, you would use it. It's all a balance between cost and reliability.

Re:None of the above...

[RAMMS EIN]

I'm curious how you do your verification.

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.

In the end, the impression I got is that formal verification is great, but the tools we used don't tell you _anything_ about the application you write, because that's not the code you ran the verification on.

I know that's just the tools we used in that course, but how do you do it? Which tools do you use, and how do they work?

Re:None of the above...

[Coryoth]

I too know how to verify a program but it is no panacea. For most (non -safety critical) applications, it is too labor intensive to be used. Would you use verification to create a game? Absolutely not! However, if you are software for the avionics of a plane are the software on a medical respirator, you would use it. It's all a balance between cost and reliability. There are plenty of halfway houses though. There's lightweight formal methods, which tradeoff complete guarantees of soundness for fast an automated static checking that is still far more rigorous than anything most compilers offer (indeed, it is more on par with unit testing, but can catch different kinds of errors). There's also the option of being more rigorous only where it is needed. It would be silly, for instance, to use formal verification for all of Microsoft Office; it's just to big, and there are too many new features getting crammed in regularly. On the other hand, it might still be very useful to formally verify various parts; for instance it might be good to formally verify all the code for calculations in Excel so that it didn't do something silly like display 100,000 instead of 65536. Personally I'd also be keen to verify that writes to files are suitably atomic, so you can guarantee that, even in the event of a crash, Word documents and Excel spreadsheets will not get corrupted.

In short, there's a sliding scale here, and it is easy enough to verify to the quality you need, and only verify as much as you require. That makes it worthwhile for a whole lot more projects than just avionics and medical software.

Re:None of the above...

[arevos]

I am convinced that the key to improving programmer productivity is to get them to write the software correct, first time. It does not lie in a language or programming style. Are you familiar with Haskell? Haskell has a very sophisticated and strict typing system that catches a lot of errors at compile time, so I'd disagree with your implication that a programming language cannot help a programmer make less mistakes.

For instance, in Ruby, this will run fine, up until the NoMethodError when the user inputs an invalid name.

def print_address(customers, name)
  puts customers[name].address
end

On the contrary, if I try to compile the equivalent Haskell code, it throws an error.

findAddress customers name = putStrLn (address (lookup name customers))

I have to explicitly account for what happens when the lookup fails, otherwise my compiler will refuse to have anything to do with it.

findAddress customers name = case (lookup name customers) of
    Nothing -> putStrLn "Customer not found"
    Just customer -> putStrLn (address customer)

In a language like Ruby, or even Java or C, it's rare to have a program work the first time I successfully compile it. In Haskell, if I manage to satisfy the compiler, I find that my program tends to work nine times out of ten.

Re:None of the above...

[lazy_nihilist]

Very true. And here's something from E.W. Dijkstra about Formal Verification. http://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288.html

Re:None of the above...

[epine]

My advice would be to learn formal verification techniques.

Over my career, I wouldn't say that languages as such have been a major influence. Developing language-independent formal coding strategies has proven far more important. I've benefited from the writings of Dijkstra (immeasurably), Stroustrup, Iverson, Backus, Knuth, Plaugher, Stepanov, Brooks, Bertrand Meyer (with reservations), and not a lot else. I haven't learned anything profound from Wall, but thanks for all the Onions.

Machine code gave me a good underlying model of the machine. Essential for many debugging situations, esp. back in the day when compilers would often generate faulty code.

APL taught me the value and power of carefully reasoned primitives, the power *and* risk of concision.

C taught me how easy it is to write a loop that's impossible to validate mentally (and then I taught myself how *not* to write such code).

C++ taught me most of what I know about software engineering: programming in the large. C++ manages to be simultaneously better and worse than almost any other language one cares to name. There is a deep truth there that hardly anybody in the industry wishes to accept.

SNOBOL and PL/1 taught me that kitchen sinks are best used for washing dishes.

Perl taught me that it isn't at all difficult to write a complex regular expression that's harder to read than any APL program I ever wrote. I once had to program in APL on a teletype that lacked the APL character set, so every APL symbol was mapped to its ASCII counterpart based on key location. Reading APL code on this teletype was comparable to reading a particularly hairy Perl regex.

PHP taught me that useful code can be written in a language with no coherent center whatsoever.

LISP taught me that the human brain is not a stack machine. I grew up with Mechano. I don't understand the Lego people while all those identical bricks, and I don't understand the LISP people with all those identical cricks.

COBOL taught me separation of concerns: code should be code, comments should be comments.

Python taught me nothing at all. To me Python is just the metric version of PHP, which spares you the headache of guessing which functions calls are in Imperial or American units (roughly as arbitrary as whether a Wikipedia page uses British or American spellings). To be honest, I learned more from playing around with ChipWits many years ago. But I find Python enjoyable for some reason as much as I've used it.

Pascal taught me that the evolution of a complex program occurs along more than a single dimension. I never enjoyed a single minute of Pascal programming.

By far, I learned the most simply from reading Dijkstra (set aside an hour per page) and practicing the art of coding an algorithm in such a way that by the time you are done, your code couldn't possibly be wrong in any profound way, because you have captured the undiluted purity of essence.

Plaugher helped to convince me that computers are *especially* fast at doing nothing. Whenever possible, when a precondition is not met, I just let the code continue, mostly doing nothing (if every statement is coded not to execute in the absence of its precondition, this is an automatic consequence). When the routine completes, I check state variables to see whether the desired actions were accomplished.

I hate exceptions and have never conclusively demonstrated to myself why exceptions are necessary. I suppose to permit integration with code that *doesn't* rigorously guard every statement. I feel confident about my C++ code until the moment I enable exceptions in the compiler. Then I think to myself: this program could potentially fail in 1000 different ways depending on which exception paths are taken. It took the wizards of STL *years* to make the STL fully exception safe. That troubles me. A lot. More than all the other complaints about C++ piled to the moon and back.

Knuth was wrong about premature opt

Re:None of the above...

[rawler]

Some reflections;

First, the 48 errors/1000LOC is pretty quick to find and catch using regular debugging techniques as well. It's the remaining two that are difficult to find either using formal verification, or debugging. In real-world, stuff like good compilers/lint-tools and som common sense in how you design your API:s will get you a long way.

Second, the usual problem in _most_ software engineering projects is not really bug fixing. It's that requirements usually change pretty drastically during the development process which is quite expensive but hard to avoid (you don't really know until you've tried it). Neither unit-testing nor formal verification is a big help here, since when basic requirements change, so does the entire function of the program, and all unit-code and verification-code needs changing.

Finally, the main problem in any human activity is the risk of human error. I've seen people using test-driven development writing horrible tests that just happen to work for the implementation they planned, but are fundamentally flawed and end up in a broken application anyways. On the flip-side, I've seen very careful skilled developers writing completely functional, relatively complex code completely without unit-testing or verification, and nomatter how much I tried and wanted to prove them wrong, I just could not break the darn thing.

In the end, it comes down to the skill and aptitude of the developer, combined with the assistive tools that can save him from the more common mistakes. (Compiler-checks, lintian, automated security-code-scanners...) What unit-testing AND formal specification models both bring is the N-degree-programming, that is, you must make TWO matching mistakes for an error to go undetected, which adds some extra safety. Of the two, I choose formal verification, since it enables automated tools to do a better job generating tests than I can, and I get an API documentation for free. :)

It's nice to see some new languages like D coming up with subsets of the verification tools built in. In D, you also get the option to run debug-mode of your real code in real environment, with verification turned on, showing you where things go wrong. Kindof like the strict mother of assert().

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 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.

Re:None of the above...

[Beefpatrol]

Can you post some links to stuff that explain some formal verification techniques?

Re:None of the above...

[Anonymous Coward]

I agree that formal methods greatly improve software quality. However, I have never seen anyone embrace it outside mission critical systems. In my experience people are fairly lazy and even have a hard time creating worthwhile designs, comments, unit tests or documentation. It seems only after 20 years of beating their heads against walls that they realize the benefit of what their lecturers taught them as an undergrad.

There is also a perception that heavier processes such as formal methods and design get in the way of getting a product out. This is true but it will have more bugs. So in the end, users get the software they deserve. The product with the latest flashy features seem to sell better. Hopefully, people running nuclear power plants know better :)

Re:None of the above...

[try_anything]

I don't know why the parent got down-modded. I think it deserves visibility.

higher level languages are just ways to automate certain formal methods

A very nice way of putting it.

i will never understand the argument for using languages without declarations and type checking because it "makes people more productive" as long as they don't make spelling errors

That argument is based on the belief that static type-checking requires that the type of *every* function and variable be declared. I know, it's wrong, but it will be years before most programmers are able to name a counter-example. In the meantime, the benefit of static type-checking has a cost: ubiquitous type declarations that clutter up the code and bog down development. The overall value of static type-checking grows with the size of the codebase. In my experience with Python, I start to wish for static type-checking when a project grows to 2,000 to 5,000 lines of code. Most projects eventually reach that size, but it's very frustrating to use a language like Java or C++ for early development on a project, because you are forced to commit a great deal of effort (type declarations) to exploratory code that you know will be thrown away. Early in a project, when you are moving quickly and can keep most of the design in your head, it is better to use a dynamic language and just try not to make mistakes. Neither option works well for all stages and all aspects of a project.

Eventually we won't have to choose. Even mainstream, conservative languages are starting to be a bit more helpful. For example, the new C++ "auto" keyword will save a lot of keystrokes, though it would be better if it were not needed.

Ruby... it's evolving

[dublinclontarf]

I would put my money on Ruby, as a language it's pretty nice & powerfull, on top of that it's got some interesting implementations in the works (Rubinius).

For those who haven't RTA

[derrida]

The options are:

1. Ruby
2. Scheme
3. PostScript (?)
4. Prolog
5. ML
6. Haskell
7. Haskell
8. Scala

Qustionmark mine.

Re:For those who haven't RTA

[dctoastman]

Postscript is a Turing complete language.

assembly

[petes_PoV]

if you have only ever programmed in a high-level language, you should really learn a low level one. This will give you an appreciation of what actually goes on inside a processor.

Even if you never use it commercially, the background it gives you in terms of hardware will improve your ability to write efficient code.

Personally, I think this should be the first language that future programmers (as opposed to CS graduates) should learn.

Re:assembly

[TheSpengo]

I agree, if you know C, assembly shouldn't be particularly hard to pick up. It looks daunting at first glance, but it really isn't as bad as people make it out to be. After you learn it, all your code will look a hell of a lot better since you understand what the CPU is actually doing better.

Re:assembly

[ohxten]

You beat me to it.

The way assembly language is organized is more difficult. You only have a few registers, and then the stack, and then memory. There is no "if" or "else". It's a very different way of thinking.

Example:

if (x == 0) {
/* ... */
} else {
/* ... */
}

is:

test eax, eax
    jz x_is_zero
x_is_not_zero:
    ; ...
    jmp after
x_is_zero:
    ; ...
after:

Re:assembly

[angrytuna]

I'd have to disagree on the 'first language' part. Learning to write code for the first time can be extremely frustrating for some (most?) folks; I was one of them. My first language was Java, and one of the best things about learning in that was the quick turnaround to positive feedback; specifically, positive feedback that looked useful in something other than a non-academic setting. It whetted my appetite, and gave me a bit more of a foundational base to actually understand what was going on when I first wrote in assembly, and how it fit into the grander scheme of things.

I would agree that they should look at it eventually, though, for reasons you've already specified.

Re:assembly

[muridae]

Let me second that idea, and then add to it. Assembly programing will give you a better idea of what your hardware is actually capable of doing, instead of abstracting everything behind objects and function calls.

My suggestion, if you know C++ or Java, is to learn something that isn't slightly object oriented. Pick up Lisp, Haskell, Prolog, any of them. Learn to think in a different direction. Learn straight C. If you really want a challange, hit http://en.wikipedia.org/wiki/Programming_paradigm and learn one language from each paradigm. You don't need to learn them well enough to think in them without looking at a grammar cheat sheet, but just write a simple program in each one. Say, populating a list and sorting it, or a Fibonacci generator.

Then, take your favorite language, and write something for an embedded platform. A telephone, hand held game system, a custom project using any old PIC/Atmel/MIPS/whatever. Get used to writing stuff where you can't abstract everything, because you have a bigger limit on memory and system functions. You don't need to do this in assembly though, by this point, you may find that you want to.

By the time you are done, you will look at programing differently. Not in a 'How do I do this in a language and library set I am comfortable with' way, but from a 'which tool works best for this situation' perspective. That will make you a better programmer.

Re:assembly

[skrolle2]

I'm a CS major, but I can't think of a better way to teach programming than the way it was done at my university.

Our first language was Scheme. It's a simpler variant of lisp, it has a super-simple syntax, and it is very easy to demonstrate algorithms without being bogged down by syntax. The second language was C, it has more syntax, and it introdcues concepts such as compiling and linking which is part of most useful languages. :-) Some time after that we did assembler, and we even had a hardware class where we built our own microprocessor, designed an instruction set for it, and made a program using our instruction set. We also did Smalltalk and Java for object orientation.

So all in all my university gave me an education that spanned the entire length from hardware to high-level languages, and to me it has been invaluable for realising what you trade off at each level, and what you gain.

Re:assembly

[bjanz]

I mostly agree with you. However, as an adjunct professor at a local college, I find that students "get it" more easily and more completely when I start with the free-form conceptual and work down to the physical. For instance, I teach a simple scripting language or simple BASIC first, then a procedural language (C), then compiler theory (which incorporates assembly language). This takes them from the "what do I want to do" stage down to the "how the iron does it" stage.

In the process, the students learn that the language is less important than understanding what you want the system to do. And, they learn that all languages are *NOT* alike: they each have their strong and weak points. For instance, I wouldn't want to write a SCSI disk device driver using C++ templates and virtual classes (although the idea has merit). By the same token, I wouldn't want to write a high-level web-based stock valuation and numerical analysis program using BASIC.

What language should you learn next?

The real question is: do you have enough skill to pick up a language spec and work your way from "hello, world" to advanced techniques? Do you have the time, desire, and "drive" to learn the new language?

If you answer "yes"... you'll do fine.

Re:assembly

[The End Of Days]

I hear this all the time and never see it in real life. I suspect this is just more Slashdot Ludditism - elitist types longing for the days when they belonged to a secret brotherhood filled with arcane rituals and the exciting feeling of shunning and being shunned by society.

Re:assembly

[newbish]

God i can't imagine trying to lean assembly right out of the gate. I definitely think if they did that it would narrow the field as a lot of people would probably run away screaming. I think its a good idea to start out new programmers on a language designed to for learning like python or pascal. On a side note I think its mildly retarded that so many schools have entry level college courses for CS majors start off at such a novice level.

Re:assembly

[Have Brain Will Rent]

Actually it is the first thing CS majors should learn too - that or using a Turing Machine simulator and then assembler.

Re:assembly

[m50d]

Personally, I think this should be the first language that future programmers (as opposed to CS graduates) should learn.

I hope to god you're trolling.

Re:assembly

[WNight]

Full-blown x86 ASM with all addressing modes, etc, may be a bit complex for a new student. But assembly itself is as simple as it can get, if very tedious.

I'd start by describing simple operations. Load a number, store a number, add or subtract, branch if, etc.

Then walk through a simple program, like to multiply one number by another

set a = #
set b = # :start
set a = a + b
set b = b - 1
jump to start unless b == 0

At that point it's just a discussion of steps. Then you replace it with real instructions and the class can see what a computer actually does. It doesn't "sort" a list, it load a character and another, subtracts one from the other, branching if they aren't zero, and then tries the next character, then the next string, and so forth, until the list is sorted.

By seeing the tiny instructions that things break down into, people can see how complex a sort statement could be, and yet how like lego, it's all just simple things repeated.

Then you explain cycles, how time is measured, and the general issues of making sure (via some restaurant metaphor or something) two things are done at once, and that both then take a same amount of time or someone is left waiting, etc.

At that point you mention big-O notation, explaining in general the concept of O(n), O(n^2), etc. The math isn't as important as the idea that each of these tiny instructions you've shown them takes a finite amount of time and at some point, it's possible to count them in a formulaic way and compare that number to another program.

At this point the students don't even know this is assembly code, or that other methods of programming exist. It's just a concept of simple repeated instructions being used to make computer programs.

Sometime after they're comfortable with the general idea of this, I discuss labels, then subroutines, and then the idea of APIs (collections of useful subroutines) and other languages (more concise ways to describe these instructions).

They might not learn what a register is from this, or how to actually write runnable ASM, but it'll give them a grounding in programming that they'll never get if they jump into Java (or other GCing, no-pointer, type-anal language).

That's about an hour of material, for people who haven't programmed before and don't know anything about it.

Re:assembly

[Pictish Prince]

Try it like I did: 360/370 assembler. These machines don't have a stack; you have to save your current location in a "jump register" then branch to that location when your subroutine finishes. This will put hairs on your chest.

Re:assembly

[David Parker]

> ... you have to save your current location in a "jump register" then branch to that location when your subroutine finishes.

Balr. I remember it well.

None

[the computer guy nex]

A good programmer would study design patterns in their downtime rather than a new language. Learning the right way to solve common programming problems is far more useful than learning mindless syntax.

Re:None

[fred fleenblat]

i don't suppose you're willing to make this mental stretch, but pretty much all a computer language is, is an expression of the of design patterns that the language designer thought were most valuable at the time.

if you can think up a new language that is design-pattern-neutral without drowning the user in parentheses, you may be onto something.

Re:None

[fliptout]

Unlike the other response, I see the value in what you are saying. Personally, I am an EE not a CS guy, so now that I have been thrust in to software engineer, spending time learning things like data structures, OS concepts, algorithm development,optimization, etc, would be more valuable than learning another language. These concepts are widely applicable.

Re:None

[JoeCommodore]

What part of Syntax Error did you not understand in your programming work?

While it is nice to understand design patterns without knowing the scope of the language syntax to implement them I don't think those alone will do you much good except for posting comments on Slashdot.

As for programmers extending beyond their boundaries, I think that is really a personal choice of the programmer, what I may want to explore may not be what Joe Codemonkey in Indiana has a passing interest in learning. My last language choice was based mainly on my job needs (and it is a very good choice for my career from my view on the other side), if it was a personal choice, it would have been another language - which might not have been a bad choice either, but I would be less inclined to effectively utilize it in my current career.

Noob's question.

[Ethanol-fueled]

I'm a programming noob,(C/Cpp/java/more to come) so who wants to earn a few mod points explaining things?

Ruby is an extention of java, so should I treat it as a fundamental programming language? For that matter, why dosen't the article list SQL?

Postscript? That seems to be a bit proprietary.

lisp/prolog/haskell - these seem to have a reputation for being developed in academia, for academics. Will they make me the bucks once I leave academia?

erlang - as many slashdotters have pointed out, erlang's gimmick - being parallel, isn't all that efficient.

Finally, what about D? ;)

Re:Noob's question.

[Ethanol-fueled]

Your point 2) was most informative, given java's adaptation of the printf statement.

Re:Noob's question.

[maxume]

Ruby isn't an extension of Java. One implementation of Ruby runs on the JVM, but there are several other implementations of Ruby. It provides a nice contrast to Java. Perl and Python are much like Ruby(Perl is Perl, Python tends to help the reader more than the writer, Ruby tends to help the writer more than the reader).

Postscript is more obscure than it is proprietary(e.g. Ghostscript implements it, but it isn't a very common choice for general programming tasks).

Lisp/Prolog/Haskell/etc. are more valuable for the things they teach you than for marketability, but knowing stuff is a good way to make big bucks.

Erlang is only going to stay interesting to the extent that other languages fail to come up with/bolt on similar concurrency features(its current implementation targets a fairly narrow niche and it can be awkward in other uses).

D isn't really all that different from C/C++, and isn't going to be a huge boost to your marketability, learn it if you like it and want to use it for something.

Re:Noob's question.

[abigor]

Ruby is an extention of java Hahaha, what??

erlang - as many slashdotters have pointed out, erlang's gimmick - being parallel, isn't all that efficient. Erlang is about uptime and fault-tolerance, with acceptable speed. Who cares if your implementation is faster if it crashes, doesn't scale, or can't be updated without stopping execution?

Re:Noob's question.

[Chandon Seldon]

The general answer to the questions you're asking is this article. Actually read it if you haven't seen it before - it's worth the time.

Ruby is an extention of java, so should I treat it as a fundamental programming language?

Ruby is about as far as you can get from Java while still having classes and mutable variables. There might be an argument for treating Perl, Python, and Ruby as the same language - but even that is stretching it a bit; it'd be like saying that C++ and Java are the same language.

lisp/prolog/haskell - these seem to have a reputation for being developed in academia, for academics. Will they make me the bucks once I leave academia?

Academics aren't just screwing around with pointless stuff for no good reason. Those languages are popular in academia because they allow the users to reason about programming problems in specific interesting ways - coincidentally, being able to reason about programming problems is what "makes you the bucks" as a programmer in industry.

erlang - as many slashdotters have pointed out, erlang's gimmick - being parallel, isn't all that efficient.

Erlang itself isn't wildly efficient because that wasn't its design goal. Erlang was designed for *reliability*, and concurrency was selected as an excellent way to accomplish that (in a well written Erlang program, a server exploding is a non-fatal exception). But... saying that Erlang-style concurrency isn't efficient in general is silly. In fact, it looks like exactly that concurrency model is going to be one of the best ways to effectively program for modern 8+ core CPUs.

Re:Noob's question.

[mini me]

Ruby is an extention of java

Considering that Ruby and Java were released at roughly the same time, that would pretty much be an impossibility unless Matz had some kind of inside track at Sun.

Re:Noob's question.

[turgid]

Dip into Ruby (it's not an extension to Java, but there is an implementation that runs on the JVM). The Ruby in Twenty Minutes guide is excellent. There is even a ruby interpreter that runs in your web browser.

Next, dip into scheme. It's a more practical kind of LISP than Common LISP. Get yourself a PLT Scheme with a friendly IDE and tutorials. Play for a while and then go and read about Lambda Calculus :-) Then you can start on Haskell and Erlang etc.

Postscript is a bit domain-specific. FORTH is its grandparent, and much simpler to learn. It's been about for years and there are hundreds of free FORTH systems about. I first learned it when I was 10 on my ZX81.

D looks interesting, but if you have already looked at C and C++, I would strongly recommend looking at Objective-C and contrast it with C++. It's smalltalk-inspired object orientation applied to C vs. Simlua-inspired C++. You will be astounded at the difference. You will also see some similarity with the design of Java...

Most of all, have fun and don't be afraid to start with a quick half hour looking at each one :-) Don't try to become an expert over night. It's taken me 20+ years and I'm still learning, and having more and more fun :-)

Re:Noob's question.

[Anonymous Coward]

Next, dip into scheme. It's a more practical kind of LISP than Common LISP.

Right, that would be why Scheme was designed for theoretical elegance, whereas Common Lisp was designed to be usable in the real world at the expense of some elegance. Idiot.

Re:Noob's question.

[turgid]

Er, um, common LISP has some "powerful features" that make programming in it hard, i.e. less practical. I suppose you think PERL is a good language for learners?

Go Lower

[Jupiter Jones]

If the only programming languages you know are along the lines of C++ and Java, then I'd suggest moving down to lower-level languages rather than up.

I know a lot of people who have mostly just been exposed to the Javas and VBs of the world, on systems with virutally no constraints on speed or memory resources. Consequently, they don't really know anything about how computers actually work. Nor do they have much experience in programming "tightly" where needed.

Maybe it's just me having a "get off my lawn!" moment, but a few weeks spent writing Assembler for a simple, 8-bit chip would probably do them a world of good. At the very least, some good old-fashioned bit-twiddling and pointer-fiddling using non-OOP, 100% portable C would fit the bill.

JJ

Anything But Perl

[Perl-Pusher]

Python would be my choice. Perl isn't bad, just not my first choice for a beginner. Its way too easy to fall into bad habits. I started out in perl and looking back 5-7 years at some of my stuff, ouch! Its way too easy to find really bad, insecure examples on the internet code by using google. I've seen some really horrid stuff end up in production settings because a programmer found a few tid bits on the internet. Not that you can't find crappy python code. It just doesn't seem to come up as readily in a search.

Re:Anything But Perl

[notque]

So don't use code snippets without understanding them. Just because you can find fewer doesn't mean perl is bad language to learn first.

I have only learned perl, and am quite content with it as it does the jobs I need it to. I haven't been using it for 5-7 years, but I look back on code from 3 years ago and it's no less secure than anything I write now. I decided to understand any code snippet I used.

I think Perl is a fine first language as long as you start simply, and expand giving yourself time to take in the concepts. Enjoy the exploration.

I can't speak in comparison to any other languages obviously, but it worked for me.

Re:Anything But Perl

[Firehed]

The exact same is true of PHP and many other easy to learn web-oriented languages. It's easy enough to write safe, secure, and efficient code, but that's not going to stop a moron using a querystring variable directly in a SQL statement (I'm sure that I have something along those lines in my early code, as most of us probably do somewhere - thankfully, it's nothing being used outside of a local testing environment). The trick isn't so much understanding what your code snippet is doing as being able to compare two snippets that do the same thing and figure out which is better and why. Can I get what I need from "SELECT * FROM users" (or better yet, 'SELECT * FROM ' . $_GET['table'])? Of course. That doesn't make it a good idea. I have old code somewhere that was running a query for every cell in a 7x30 cell table, rather than one big query with a GROUP BY clause. It's not far off from The Daily WTF quality.

What works and what you should do are not necessarily the same thing. As long as you learn what you should do before you write production code, then no harm done. Otherwise, you just help perpetuate the stereotype of (some language) is insecure, performs badly, etc.

We've all written bad code. But some people translate bad code into a bad language. Use what works and/or what you know, and follow best practices.

Re:Anything But Perl

[bnenning]

I have only learned perl, and am quite content with it as it does the jobs I need it to.

I was content with Perl, then learned Python and never looked back. Python does everything Perl does, with much less weirdness.

Re:Anything But Perl

[Anonymous Coward]

I hacked Perl for much longer that I've coded in PHP but IMO PHP is missing two things. Perl's comprehensive taint checking which forces you to at least look at all potentially dangereous code & CPAN. While It's true that Perl coders can untaint variables using over-wide regexps I have only seen this on "I learned perl writing this" code which I then eliminated from consideration. All the code I've used from cpan has been good in this respect.
Posting anon because I've already moderated some comments...

Re:Anything But Perl

[samschof]

Learning perl as a first language is a bit like turning 21 in Las Vegas with a big wad of cash in your pocket. There are simply too many options and not enough experience to deal with it.

Perl allows everything from OO to shell script type syntax and you do see everything in between. I love perl, but for a first language, you are much better off with a simpler language that has strong type checking and strongly encourages structured programming practices.

Re:Anything But Perl

[TheSpoom]

I honestly don't know enough about Perl to say (something I intend to remedy one of these days) but my guess is PEAR is to PHP what CPAN is to Perl.

Re:Anything But Perl

[merc]

I must echo the sentiments of the OP; although my experience has been a bit different. I came from a heavy UNIX/C background, which I enjoyed for many years. I began to experiment with Perl when perl5 was released (must confess I was not a big fan of perl4). One of the aspects of Perl that I always found delightful was the fact that it seemed to literally be a wrapper to C, or at least C-like. Not only does it supports system calls, and similiar C library API functions such as sprintf, et al, but without all the management headaches of C. It has a useful capacity to do extremely complex pattern matching with its NDA regular expression engine. Above all is the massive CPAN code repository that seems to satisfy just about any kind of computing need a developer could imagine.

Since then I have come to the conclusion that (at least for me) Perl can, within reason, satisfy just about any computing requirement I run across in my personal and professional life.

Re:Anything But Perl

[sowth]

I think the problem with perl is all the shorthand commands. With two or so characters you can express many common things, however to other programmers (especially those just starting perl), they end up looking very cryptic. Then there is the fact you can express many things thousands of different ways, and most people aren't able to learn them all, and everyone uses different methods depending how they learned, so no one is able to read other programmer's code.

...that was my experience with Perl anyway. Perhaps I didn't go into it far enough, but it does seem the old saying "Perl: write once, read never" rings true.

Re:Anything But Perl

[powerlord]

PEAR might be PHP's equivalent to CPAN for perl, but there is something different in scale.

From http://www.cpan.org/index.html

Comprehensive Perl Archive Network

2008-03-18 online since 1995-10-26
4236 MB 236 mirrors
6503 authors 13220 modules

(emphasis mine)

Yeah ... there are a lot of pointless modules, or ones that aren't as good as they could be, but if even 1% of them are "production" thats 1,300.

If its 10% that number jumps to 13,000, and thats not even counting the modules that might not be "production quality" but are "good enough" for what you need.

The sheer amount of development time that has gone into CPAN is one of the reasons that perl is as popular as it is, and what allows it to be a swiss-army knife language. It is perfectly easy to write one page applications that are obfuscated, but Amazon still uses Mason (perl based site development toolkit similar to PHP, but different) and I know of several companies that sell seven-figure products that are built around perl.

Re:Anything But Perl

[powerlord]

I think the problem with perl is all the shorthand commands.

I'd argue that this is a problem of the programmers, not the language.

If the programmer is truly doing so much in "short" commands, then they should be including proper comments to document what they are doing.

Also, realize that when you first learn any language there is a bit of a learning curve, and you should be looking at "intro" examples, till you start to get up to speed on a language.

I mentioned in another post that there are several companies I know selling seven digit products based around perl (more if you including Amazon, whose entire web front end is based around Mason, a perl library). Trust me, writing good/maintainable code, and writing a "quick script" are two very different things, and a lot of perl programmers either work only on the "quick script", or have their quick useful script evolve into a full blown program, without having the opportunity to code it properly.

There is a piece of perl code that is about 2K lines (in several modules), that has been in use for about the past 8 years at my company. Its been maintained by about 4-5 different people, and the lead programmer kept lamenting that some of it needs to be rewritten because some features got bolted on "overnight" when a requirement came up, but there have been no major problems with expanding it, supporting it, or making sure it keeps running as its supposed to.

Re:Anything But Perl

[Nixoloco]

Comprehensive Perl Archive Network 6503 authors 13220 modules Yeah ... there are a lot of pointless modules, or ones that aren't as good as they could be, but if even 1% of them are "production" thats 1,300. If its 10% that number jumps to 13,000, and thats not even counting the modules that might not be "production quality" but are "good enough" for what you need.

I agree with the spirit of your argument, but I think your math is wrong.

1% of 13220 would be 132.2 not 1,300.

and 10% would be 1,300 not 13,000

Re:Anything But Perl

[Anonymous Coward]

Sorry guy, but using Perl as a first language is a sin!
Most people think Perl is good because it let's you do things quickly. Agreed.
My first language was Perl as well, but once I learned others (C++, Java, Haskell, Prolog) I actually figured out how crap it can be if not used properly. Most of the people learning Perl are simply to lazy to pick up a proper language. Don't take me wrong, I think Perl can be a great language, but not if you don't know how to program in a C-style language first as you will tend to write the most unreadable code Perl let's you write ...

Re:Anything But Perl

[powerlord]

Hmmm good point :)

Thats what I get for not proof reading the numbers when I add them.

Thanks for catching the mistake. (Slashdot, peer review in action? ;) )

Scala is a functional language

[MCRocker]

Scala is a functional language,which is part of why it was recommended.

Whitespace

[ookabooka]

I think Whitespace is worth learning, if only to be a smartass on exams where the prof specifies you may use "any" programming language. Just leave it blank, then after the exam spend a few hours figuring out how the hell you would solve the problem in whitespace, and bring a proof of concept on a USB flashdrive to fight the inevitable incorrect grade you receive for the problem.

I have yet to find the courage to actually attempt this. . .

Re:Whitespace

[mcmonkey]

That settles it. My next language will be lolcode.

KTHXBYE

Re:Whitespace

[Moe1975]

LOL

Re:Whitespace

[3.1415926535]

Whitespace is useless as a programming language. It's more of a machine code. What is could be useful for is a compile target. I once tried to port a toy compiler that I wrote for a class (in Haskell, compiling Lisp to Ocaml bytecode! How's that for wacky languages?) to compile to Whitespace, but was thwarted by its lack of any meaningful memory management. You'd be better off with Brainfuck.

"Beyond C++ and Java?!?!?"

[JamesP]

Wow, that's like, coming from a very narrow range...

But my suggestions are:

Python - go learn why strong-typing doesn't mean a lot in practice (except for headaches).

Lisp / Haskell / whatever - go learn ' a different way' of programming things. Trust me, it rocks.

Ruby / ECMAScript - it's the future baby.

Re:"Beyond C++ and Java?!?!?"

[digitig]

Python - go learn why strong-typing doesn't mean a lot in practice (except for headaches).
In what way? After all, Python is strongly typed. Did you mean "go learn why early binding doesn't mean a lot in practice (except for headaches)"?

Lisp / Haskell / whatever - go learn ' a different way' of programming things. Trust me, it rocks. Well worth a try, but hard to find anything that teaches you how to scale them into real applications. People do it, but I'm blowed if I can find out how they learned.

Ruby / ECMAScript - it's the future baby.
Oh, I do hope not! I just can't find a redeeming feature of Ruby. Except the humour: I still haven't stopped laughing at that bit in the Pragmatic Programmer's Guide about "Ruby, unlike less flexible languages, lets you alter the value of a constant".

Re:"Beyond C++ and Java?!?!?"

[Dragonslicer]

ECMAScript - it's the future baby. So how does it feel to be moving through time in the opposite direction from the rest of us?

Malbologe

[Urger]

Malbologe, a language so painful it took two years just to write a "Hello World" for it:

(=<`:9876Z4321UT.-Q+*)M'&%$H"!~}|Bzy?=|{z]KwZY44Eq0/{mlk**
hKs_dG5[m_BA{?-Y;;Vb'rR5431M}/.zHGwEDCBA@98\6543W10/.R,+O<

Re:Malbologe

[Drantin]

not only did it take two years to write, they had to write a program in another language to make that one...

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 -- 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.

It's not all syntax

[shyberfoptik]

The fact that you think "mindless syntax" is the only difference between lisp, haskell, and c shows that you should probably learn one of these languages.

Re:It's not all syntax

[RAMMS EIN]

In fact, I know all of these languages (although Haskell far less than most other languages I know), and I have a hard time wrapping my head around these "patterns".

Anything you want to program ought to be simple.

If there is some commonly occuring functionality (which I guess is what you have "patterns" for, so that you have a guide for implementing that functionality), you factor that functionality out into a function or macro.

After that, programming with it is simple.

You don't have to go and re-implement the pattern every time you need it; you just reuse the implementation you wrote before.

Unless, of course, your programming language does not allow you to write that implementation; usually because it lacks macros or first-class functions.

Re:It's not all syntax

[grammar fascist]

Also, while some design patterns seem to be universal (structural patterns like facade, adapter and proxy, in particular, are necessary to make independent systems play well together), others indicate that the language you employ them in is lacking in features.

Visitor? If you have first-class closures, it's the most natural thing in the world to pass a function to a traversal function. You don't need a name for it or a specialized set of trigger terms so that maintainers can see easily divine your intentions. You don't name your closure "visit", you name it after what it does.

Singleton? Whatever for, if you can create object literals, or your classes are as first-class and polymorphic as instances?

Factory? In Python, you override __new__...

Learning other languages lets you determine the difference between unification and duct tape.

Re:It's not all syntax

[avandesande]

I think 'arbitrary' would have been a better choice.

Re:It's not all syntax

[maxwell demon]

Visitor? If you have first-class closures, it's the most natural thing in the world to pass a function to a traversal function. You don't need a name for it or a specialized set of trigger terms so that maintainers can see easily divine your intentions. You don't name your closure "visit", you name it after what it does.

I don't think you understand the visitor pattern. It is *not* just a function passed to a traversal function (there are better ways to do that in C++). Yes, visitors do indicate a missing feature, but that feature is not closures. It's multimethods.

Re:It's not all syntax

[shyberfoptik]

All syntax are methods of abstraction. You could author a very long Turing tape, or let a Haskell compiler do that for you. Which of these two activities could be considered 'functional programming?'

When people get together to invent a programming language they choose what they believe is the best syntax, so it's not 'arbitrary' in the sense that there is no reason for favoring one syntax over another.

Learning syntax is different from comprehending an abstraction. If one believes that learning a programming language is simply memorizing a syntax, the whole process becomes 'arbitrary' and that person appears 'mindless.'

Re:It's not all syntax

[grammar fascist]

Yes, visitors do indicate a missing feature, but that feature is not closures. It's multimethods.

Ah! You are absolutely correct, and I learned something new today. Apparently, that part didn't sink in when I read the GoF book. Thanks!

extending beyond their normal boundaries

[witte]

I'm big-boned, you insensitive clod !

Assembly, FORTH

[Average]

If you aren't trying to get a specific job, I recommend getting deep into an assembly for a few months. Preferably, something simple. Something 8-bit (I started with MOS 6502... but the 68HC11/12 with flash/EEPROM and BUFFALO debugger is even easier). Something on a board you've wire-wrapped yourself. Make it blink an LED. Hook it to a DAC. Hook it to a motor, moving something. Learn every opcode on the little chip.

From there, you'll understand what a C compiler (portable assembly) is doing, at least on a basic level.

Instead of Postscript, I'd suggest the language that Postscript is born of... FORTH. Heck, when you get bored with the assembly on your microcontroller board, burn a simple, fixed-point FORTH onto it, and get a whole new appreciation of what can be done with a few 1000 bytes.

Get the Little Schemer

[burris]

Like a lot of people have commented on this thread, it's past time for you to learn a functional language. I'm not sure if it is true, but new CS students at MIT used to have to learn Scheme as their first language. Learning a functional language will transform your programming ability.

I recommend the book The Little Schemer This book is like no other programming book you have ever used. It is a socratic dialog between you and the interpreter. Questions on the left, answers on the right. It is meant to be used with an interpreter.

Once you make it through this book you'll be a much, much better programmer. You'll also have an easy time learning languages like Haskell, which is used quite a bit in academia and is useful for real world software.

So buy a copy of the Little Schemer and download an interpreter, Dr. Scheme is pretty good, and get cracking.

Re:Get the Little Schemer

[HeroreV]

I saw lots of horrific reviews of The Little Schemer, but I bought it anyway because it sounded so different. And you know what? I hated it. A lot.

Anybody planning to read this book should know that reactions have been very mixed. You may love it or you may hate it. Try not to be too disappointed if it doesn't turn out as amazing as it sounds.

I personally recommend SICP (google it) if for nothing more than it being free and it being a meme on 4chan's /prog/ board.

Re:Get the Little Schemer

[iuvasago]

Scheme was the first language I learned as a CS student (not counting a bit of C++ in high school). I agree that it will definitely make you a better programmer. Understanding the basics is the key to mastering any skill.

Re:Get the Little Schemer

[btownb2003]

Dr. Friedman was a professor of mine at Indiana University, which prompted me to buy this and "The Seasoned Schemer." These two books remain at the top of my recommended reading list and would be my first choice for those who wish to dive into programming for the first time.

If you get through both books (which is really easy, given the books' light-hearted nature), you will have a fundamentally sound entry into programming. The other interesting aspect of these two books is the notion that these can be presented to a much younger crowd than a traditional programming book.

I can't tell you how highly I recommend these two books!

Re:Get the Little Schemer

[Anonymous Coward]

"So buy a copy of the Little Schemer and download an interpreter, Dr. Scheme is pretty good, and get cracking."

Except for the problem that I can't find either a prebuilt or a source code one that doesn't give me grief on Suse 10.0. Squeak smalltalk didn't give me as many problems during installation (the installation of extra software is another matter).

Re:Get the Little Schemer

[Anonymous Coward]

Free resources for Scheme.

The classic, Structure and Interpretation of Computer Programs:
http://mitpress.mit.edu/sicp/full-text/book/book.html

SICP videos:
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/

How To Design Programs (somewhat PLT Scheme specific):
http://www.htdp.org/2003-09-26/Book/

The Scheme Programming Language (somewhat Chez Scheme specific):
http://www.scheme.com/tspl3/

Teach Yourself Scheme in Fixnum Days (also PLT to an extent):
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html

Of course there are others, and most of these can be bought in dead-tree form.

Re:Get the Little Schemer

[pimterry]

I'm not sure if it is true, but new CS students at MIT used to have to learn Scheme as their first language.
I'm starting my 1st year in CompSci at Oxford, UK and we do nothing but Haskell for the whole first term, and then the most of the more theoretical courses (design and analysis of algorithms, for one) seem to be in Haskell for majority of the course.

Rest of the course is in a couple other languages including Java for the OO course and Oberon (I'd never heard of it either) for Imperative/Procedural course. After an afternoon working in Oberon, a language which provides the bare minimum of tools for anything, functional programming looks oh so pretty. I'd programmed in Java and Python and things before uni, but functional programming just has a really different way of looking at things, and it's really quite nice. If you want to try coding in a new way, I'd definitely go for it.

Stack based or BrainFsck

[ZeroNullVoid]

Brainfuc* is a fun one - http://en.wikipedia.org/wiki/Brainfsck ASM but seriously the most practical languages to learn next are the scripting languages for installers like NSIS, Inno, or InstallShield.

Re:Stack based or BrainFsck

[Jhan]

Brainfuc*, Brainfsck

I hope that you are aware that the word "fuck" can be freely used on Slashdot?

BrainFuck is a nice toy language, I wrote some simple command line apps in it.

If you really want to explode your mind, try Befunge or the other Funges. Data-is-code, in several dimensions... Multi-threaded Funge is especially cool to watch in a good debugger.

Also check out Shakespear.

I agree with above posters

[Is0m0rph]

If you are a good programmer you don't learn a new language because any language isn't hard to pick up. Make sure you have a good foundation of procedural, OO, and logic languages and you can write code in anything without a lot of learning involved.

Re:I agree with above posters

[TheRaven64]

I'll agree that Algol-family languages are all pretty much the same, and most Prolog-family languages are quite similar, but thinking all OO languages are equivalent is a big mistake. If you compare Smalltalk or Self to something like Eiffel (or something more primitive like Java) then you'll see a huge difference. Even the jump from Smalltalk to Self is difficult for some people.

Re:I agree with above posters

[Is0m0rph]

True I've coded in Smalltalk before and it is a thing of it's own that's for sure. Everything is an object is no joke.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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.

99 bottles of beer in a lot of languages

[MrOion]

Take a look at 99 Bottles of Beer, a website holds a collection of the Song 99 Bottles of Beer programmed in different programming languages. My personal favorite is LOLCODE. :-)

It depends

[natoochtoniket]

The right answer to most such questions is, "It depends."

What sort of tools will be useful in your future career? Or, what sort of knowledge will be interesting to learn?

If you are concerned with serious engineering issues, such as safety and correctness, you might want to learn something about "formal methods". Languages to look at include Z and B. And, of course, there's a little field called "computational logic."

If you are concerned with commercial byte-pushing, you obviously need to be conversant in SQL and an assortment of scripting languages. And, of course, there's a little field called "accounting" that might be useful.

I don't think there is any one right answer. The choice of intellectual tools that you will need really depends on the choice of what kinds of work you want to do.

Re:It depends

[pestilence669]

"... leverages powerful ideas from Smalltalk ..."

I think the answer was written in the posting. Smalltalk has inspired Ruby, Python, Perl, PHP, Java, C++, Objective C, and more. It's also been the breeding ground for progressive ideas and practices such as MVC and automated unit testing (inspiration for JUnit). It's the ultimate language for real computer scientists and passionate hobbyists alike.

Proper and well designed tools are applicable to any career choice. Even if you don't use Smalltalk in everyday coding, the lessons learned from decades of great OO and best practices will surely inspire developers toward greater ideas. Learning a language isn't always about instant applicability. Like children learning a second language, cognitive skills increase despite the frequency of usage. You CAN improve your skills simply by studying the source of great inspiration.

D: The Language

[ion]

I know it still has some issues, but I'm hoping the D takes off. There are a lot of really interesting ideas in that language if you read the spec and write a few sample apps. Even if the language itself doesn't take off its worth a look to see the kinds of things people are thinking about including in next-gen languages.

All of them

[protomala]

I think the more languages you know (don't need to be deeply) the better. Let's see, I've started with (Turbo) Pascal in engineering university, tried a bit of Turbo Pascal for Windows (very, very, very bad one), went to LamdaMOO, Javascript, PHP, then gave up into engineering and changed to computer science, learned C, C++ and a bit of Java. I can't really say any of those was not useful in a manner or other to me, even the ones I hate, like Java :)

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.

Best Language to Learn Multithreaded Programming?

[Avenel]

This seems to be the future. Are there any languages that are more efficient for multithreaded programing?

What about a relative newbie?

[cyclop]

I like programming, but I've never delved into it too much. However, after childhood experiences with Basic (brrr!) and Matlab, I've become a decent Python programmer, and I'm currently developing a modular data analysis application in my research laboratory.

I'd like to learn new languages. I tried to learn C++ just for the sake of it, but the fact is, I never needed it, so I just stopped bothering. I can do practically all what I want to do with Python, and I never found myself in the situation of needing C, C++ or Java. And I'm not the "coding for the coding's sake" kind of person. I like coding a lot, but only if there's a definite purpose for it.

So, what is your advice? What kind of programming language should I learn after Python, and what kind of practical problems could it be applied on that could be interesting? For example, I wondered if PHP and/or Javascript are good choices, since I'd like to do web stuff but I have almost no experience on it. But they're just examples. What I mean, what kind of problems would require me to say "oh s**t, this needs C++/Java/Lisp/Ruby... and not Python"?

Re:What about a relative newbie?

[Alpha830RulZ]

I'm not sure you'll find much that Python can't handle. There are some problems that may need more machine speed, and that's what makes you descend into Java, or C++, or C. But with today's costs for hardware, those are rare, and largely the domain of firmware developers or supercomputing problems. Perl can be pretty handy if you do a lot of text munging (that's a technical term). And it's hard for me to see why a person wouldn't want to pretty comfortable with SQL.

I'd look into Python Frameworks like Django if you want to do web stuff. There's no sense turning your back on an environment you like.

Re:What about a relative newbie?

[Ambidisastrous]

Javascript is good to know for web stuff. Greasemonkey on Firefox is a fun way to try it out -- save yourself the time of building a web page to manipulate by manipulating other people's pages instead. Since you already know Python and a bit of C++, the Javascript interpreter in Firefox should be very easy for you to pick up and start using. I found the small O'Reilly pocket reference to be helpful.

Try playing with Swig, too. Maybe use it to wrap someone else's code, as a way to get more comfortable with using C alongside Python. It may come in handy if you ever do have a problem with a bottleneck in your programs.

If you're working with some form of Unix, you'll become several levels more wizardly if you put some time into really learning Bash (or your shell of choice). The syntax isn't pretty, but it's essentially using Unix as the back-end for your interpreter, so while you're at it you'll learn a lot about how Unix works, how C is intended to work, and where Python gets some of its ideas about the os and subprocess modules. There are situations where a shell script can get the job done even more effectively than a Python script -- for example, Python generally chooses a portable subset of filesystem operations, where a shell command with the right options might let you do what you want more precisely, with fewer separate checks and followup operations. They might not look like "this needs bash" situations until you're aware of which things bash makes easy.

how about..

[greywire]

Brainf*ck?

Re:how about..

[mini me]

Or PATH. It's Brainfuck in 2D.

depends....

[jabjoe]

I would say, depends... Different languages have different uses. What need is your current languages not fulfilling?
Might be worth looking into asm just so you think about what your code really boils down to.
On the other hand, if you just want a language to throw around and knock stuff together quickly, python is good. Really good. I could rave all day about python and it's interactive shell and flexibility. :-) (though seriously, it's worth having a script language under your belt for complex batch tasks at least)
If you only have done C++, might be worth doing pure C, working object oriented with structs, again it makes you think about what your C++ code boils down to.


However, what I would say is that some times rather then learning a new language, might be worth picking/debugging through an open source project that you have no idea how it works. (May I recommend a emulator with JIT). I think I've learnt far more from other people's source then I have from changing languages, and some times what I've learnt is the language, even if I thought I knew it!

SML/NJ

[rukidding]

Standard ML of New Jersey (abbreviated SML/NJ) anyone? http://www.smlnj.org/

I love it just because of its name. :)

Haskell, Scheme or Lisp.

[Kartoffel]

I've been spending the better part of today refactoring some ugly C++ that was written by a crusty old Fortran engineer. It might as well have been Fortran.

Please please please learn a functional programming language. Even if you don't use it in your daily work, your brain will be improved.

Re:Haskell, Scheme or Lisp.

[petes_PoV]

As told to me by someone who did:

"Some programmers write FORTRAN in any language"

Re:Haskell, Scheme or Lisp.

[John C Peterson]

As a Haskell bigot, I'd definitely go for Haskell over Scheme / Lisp. While the lisp family contains many good things, it's really not that different from the currently popular scripty languages (Python, Ruby, Javascript). With Haskell, you learn a completely new way to think about programming - the type system, laziness, and purity are all important things that you learn about when playing with Haskell. Knowledge of Haskell can make you a better programmer in any language - not just the functional stuff, but the type system (which has had so much influence on Java), the use of laziness (a design pattern in other languages!), and the functional style of thinking. Most current design patterns are just things that current languages are too weak to express as ordinary abstractions - the ability to build these patterns directly without resorting to the "cut/paste" style needed in other languages is well worth investigating. Haskell also has constructs analagous to design patterns (monads and arrows for example) but these are much more mathematical in their foundation.

Haskell has an incredibly active research community that is generating new ways of looking at software way faster than I can keep up - whatever the next big thing in mainstream languages will be it's probably something that the Haskell community is doing right now.

Screw them all.

[God of Lemmings]

Write your own language... it's certainly more educational.

Re:Screw them all.

[Eudial]

Write your own language... it's certainly more educational.

Indeed. And then you've naturally got to implement your language in itself. Or if it's too horrible to be done, write a compiler that compiles some other, easier language into your language, and then implement your first language in the auxiliary language.

Re:Screw them all.

[rhizome]

Write your own language... it's certainly more educational.

Yes, then put it at the center of a company's product while you gloat and chuckle over the significant support burden that the lowly sysadmins have to deal with while it falls over repeatedly and often. Not that I didn't work for a company that did this or anything...

Re:Screw them all.

[RAMMS EIN]

And fun. But I also think you can't usufully _design_ your own language without knowing a bunch of different programming paradigms, language constructs, syntaxes, and their strenghts and weaknesses.

I remember I started writing my own programming language when the only programming language I knew was BASIC. Sure enough, it worked around some of the shortcomings I perceived in BASIC. For example, the syntax was more consistent. However, for the most part, it was very much like BASIC. And it used the most ridiculous algorithms and data structures, because BASIC had never taught me to do those right.

Now I know a host of other programming languages, paradigms, syntaxes, language constructs, and data structures. And yet again, I am designing and implementing a programming language. But, this time, it is going to combine the strenghts of various languages into one language, hopefully better than each of the languages its inspired by. And it has some new ideas, too; things that I think no language I know does as well as it could be done.

Oh, and I'm not going to put all my variables in one large string, which then has to be searched on each variable access. Which is what I did in my first programming language implementation. So please. Don't make the mistake I made and think that, since you know one language (and Java and C# are pretty much the same), you know it all.

Re:Screw them all.

[HeroreV]

I'm somehow embarrassed to admit it, but I'm doing that. (And I'm guessing many other people here are also.) I keep telling myself I'm only doing it for the fun and learning, and that I don't expect it to ever actually be used by anybody, but...

In some ways, I feel it is very bad creating a new programming language. All those open source projects, and I'm spending all my time creating a new crappy language to throw on the already far-too-large pile. I could be out there helping, but instead, I'm wasting my time.

Oh, and I was at one time working on my own game engine, too. These wheels, I just keep reinventing them.

If you really want to do something great, join an open source project. Firefox, Gnash, RadeonHD, whatever. You'll get real world experience and be a positive contribution to society.

Re:Screw them all.

[arevos]

remember I started writing my own programming language when the only programming language I knew was BASIC. Sure enough, it worked around some of the shortcomings I perceived in BASIC. For example, the syntax was more consistent. However, for the most part, it was very much like BASIC. And it used the most ridiculous algorithms and data structures, because BASIC had never taught me to do those right. I'll echo this. The first programming languages I designed were mired in the conventions of the few languages I already knew.

The first interpreter I wrote wasn't for a BASIC replacement, but not far off: it was a replacement for the Bash shell. It had some nice features, was a little cleaner and quite a bit faster, but nothing particularly interesting. I wrote it in C++, which in retrospect was a really stupid move, but I guess one learns best through one's mistakes.

Writing that shell took me several months of work. Now I know vaguely what I'm doing, the task is considerably easier. Coincidentally I recently just built a small interpreter in Python for a stack based language of my design, and it took me all of a couple of hours to get working. Thinking back to all the trouble I had with my Bash replacement... experience really counts for a lot in programming.

Re:Screw them all.

[zobier]

You're right in that you could be spending your free time helping an existing project, however the experience you gain from attempting these kinds of exercise will make you a more valuable contributor in the future. Also, you should always follow your heart, that is the way to success.

Beyond java

[cyfer2000]

You mean some one learned everything about java or some one learned the syntax?

Groovy

[Kozz]

Well, there are plenty of voices in the Java community who would like you to learn Groovy.

Re:Groovy

[Panaqqa]

I'll second that. Groovy rocks!

Ada

[D3]

At least according to the TA teaching my languages survey class. Of course, it could be because his grad school work was focused on it and not because it is actually useful.

Re:Ada

[FBSoftware]

I think Ada is a language that everyone would benefit from learning. Its very useful. I have used it for years in my day job, by choice. Ada is probably the most well designed (carefully considered) general purpose language. It can and has been used for everything from GUIs and web servers to games, compilers, flight control systems, low level device drivers and everything in between. It is particularly well suited for low level hardware interfaces and for programming multi-processor systems, real-time or not, and for interfacing with other languages (C, C++, Java, Fortran). The best Ada compiler GPL licensed open-source and is freely available at https://libre.adacore.com/. It supports the latest Ada 2005 language standard. Other information is available at http://www.adaic.org/ Ada has long suffered from a lot of undeserved bad press. Don't believe it. Learn Ada - you probably won't look back.

Re:Ada

[eean]

Ada is the first language taught at the university I went to. I think it's a good first language since it forces good practices on you, which was the whole point of its design. Java is now the most popular first-language, which is odd since you can't write two lines of Java without having to learn about concepts like pointers.

But don't look back? Hardly.

Err...

[gratemyl]

I like how it says:

You must be logged in to a comment.

dynamic languages

[jwhite_chile]

I think that learning dynamic languages are beneficial. They make you think about some things a little differently, like Ruby with it's code blocks for example. And on the other side, it seems that use of dynamic languages, such as Python and Ruby, are growing.

Re:dynamic languages

[Anonymous Coward]

They make you think about some things a little differently, like Ruby with it's code blocks for example.

Code blocks have absolutely nothing to do with dynamic languages. It's just another name for anonymous functions, which are supported by highly static languages like ML and Haskell.

Functional Programming

[PsiCollapse]

It's making a HA-UGE comeback (c# 3.0, closures in Java). Great place to start is Clojure.

Don't Forget Piet

[eldavojohn]

Don't forget Piet. That's produced some of the most beautiful code I've ever seen. It also handles abstraction in a novel way.

Re:Don't Forget Piet

[Scrameustache]

Don't forget Piet. That's produced some of the most beautiful code I've ever seen. It also handles abstraction in a novel way. Wow, a stoners' programming language! I'll be darned :)

Learning languages

[vurg]

For a change I decided to learn and understand programming languages themselves. I went back to the old dragon book, and picked up Michael Scott's Programming Language Pragmatics. It's interesting to learn the low levels, and once you learn the basics (parsing/scanning/compiling), you can easily grasp any language out there.

MATLAB

[Thelasko]

It's great for handling matrices, vectors, plotting and umm... well, that's all it's good for.

Re:MATLAB

[espressojim]

I really like R - but I do a fair amount of scientific work, visualization, and statistics. I really like working with a matrix of data, and being able to apply functions across that matrix very quickly and easily.

I find R is also great for lots of ad-hoc data exploration that I need to do - but I'm sometimes as much of an analyst as I am a programmer.

You can't "Know C++"

[TheGreatOrangePeel]

Between the plethora of classes and variations, one can't really "know" C++. Well, not like one can "know" C, anyway. My "next" languages have been wxWidgets and ncurses. Eventually I'll make it to Ruby ... someday, and I must also admit an idle curiosity about the D programming language (but that isn't very serious).

If you're ever feeling much more silly than that, though, you can always check out the whitespace language or even LOLCODE.

I've got some theories on this

[Anonymous Coward]

I think that the "languagism" that is out there today, especially the Rubinistas are mostly just left over perl-people.

In the .com bubble era, we had in influx of people in to software, most had little to no training and they all seemed to either become web developers or masters of perl. Many of them read "Pragmatic Programmer" and treated it like it turned them in to software engineers (personally, I think it's a great book and good at helping newbies grow in to journeymen, but the gap from there to master is huge and it does not address that) When you get down to it, if you're really that worried about the language, you're probably not that great to begin with. If it's that hard to switch then why do you care at all, you're always going to go back to what you know, you'll write perl in ruby, you'll write perl in your erlang or haskell experiment where you try to learn a language every year. Notably, you'll pretty much hate everything else that doesn't let you write perl, Ruby is pretty good at letting perl-people write perl, ruby can even look like perl in the hands of a true "master." It will always come back to single lines of "code" with like 10 logical paths through them ("well it's pretty easy to read, here, uh, it splits the input line based upon this 32byte regular expression and then it iterates through each part of the split and it creates a hash table of data and then it returns false if the hash table doesn't contain foo... see it all fits on one line, that makes it, uh, elegant and classy coding and easy to read too, like you don't have a full page of code, there aren't any extra whitespaces or extra punctuation to get in your way and make it hard to read, you know? it's just pure code...oh and I used some closures too... I'm l3317 y'all. There was a program that did this in (insert favorite language of contempt: python, java, csharp, etc..) and it was 30 wasteful lines line but ruby let me do it in 1.")

Seriously though, is there a language shift that's happening? I can't really see any strong indicators of that, so if you don't know anything about csharp, I'd download mono and start figuring it out a little and if you don't know anything about java, I'd pull down a jdk and start figuring it out a little, if you know those and want to play with something else then try ocaml, haskell, ruby, or whatever floats your boat.

For many, it's not "what should I learn now?"

[Chas]

It's about "how can I code in the ones I know BETTER?"

There are scads of people out there who pick up a language in a short time, but don't really learn how to utilize it well. So, you get these "wonders" that know half a dozen languages, and suck a coding in ALL of them.

FORTH, definitely

[Giant Electronic Bra]

Anyone who wants to learn about elegance in software design NEEDS to study FORTH. No program ever written by man is more elegant in design than FORTH. Not to mention it is a damned amazing programming language in its own right.

Take your pick

[azadrozny]

So many good and bad languages to pick from. This website contains code samples in just about every known computer language. Cheers!

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

[wonnage]

There's always good 'ol SICP. Although the focus isn't on learning Scheme (lisp dialect) you end up picking it up along the way. I can't think of a good CS undergrad program that doesn't make you read it, anyway.

J-language

[MetalOne]

Since I have seen no mention of J, K or APL I thought I would throw these into the mix. These are great for array processing and in general anything mathematics related. It is like having an executable mathematics language. I have been reading some image processing papers as of late, and I am often thinking that the papers would have been better with some J code thrown in. English is often vague, and the math notation used is sometimes incorrect. With J, I know the math could have been tested for correctness. I think if everybody knew J, and technical papers used it, then these papers would be much better. These languages try to use special symbols to their fullest ability to create a powerful language. They are kind of the anti-LISP. LISP uses as few symbols as possible and then provides macros. J, K, and APL are all quite similar. I don't yet know any of them well enough to recommend one over the other.

The programming languages I know :

[angevin]

I know Python, C, C++, Perl, Java and LISP -- aren't those the most important hacker languages to know ?

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

Newfangled Fortran90 vs. FORTRAN77

[Noren]

Back in the day, I was using FORTRAN77 at work (chemical modeling) and there was a problem for which I really, really needed to use recursion. Avoiding recursion would have been horribly awkward and inefficient. I had a long discussion with my boss and finally got him to agree to lose compatability with FORTRAN77 standards and use Fortran90 style recursion. (Fortran90 was backward compatable enough that the tweaks required for compiling all the rest of the code were minimal.)

When did I drag my former boss, kicking and screaming, all the way from the 1977 version of Fortran to the 1990 version? That's right, it was way way back in the year 2003. Scientific computing fears change, I guess. At the same job I worked with a molecular mechanics code that, I kid you not, had blocks of code in some subroutines from the 1970s still in use, line numbers in columns 73-80 and all.

If all you want to do is math, and enough of it that you're processor speed limited, Fortran is still a fine language. It's fast.

Re:Newfangled Fortran90 vs. FORTRAN77

[Anonymous Coward]

Mod parent up. Fortran is a fine, modern language. Now. Don't think the Fortran77 standard. Think Fortran 2003.

Re:Newfangled Fortran90 vs. FORTRAN77

[sjames]

Much of scientific computing involves simulations done in floating point, oftem requireing many cpu-years of computation for a single result. The math is all fiddly and it's massively iterative nature amplifies even tiny errors until the results become completely invalid. Proving correctness is a huge undertaking when it's possible at all.

Further, much of the code is written by people who understand the problem domain well but aren't really programmers. That tends to result in brittle code filled with odd interactions. Changing compilers or even optomization options can completely invalidate the results.

Given that, change is spelled RISK. I'm amazed the aversion to change isn't even stronger.

Re:Newfangled Fortran90 vs. FORTRAN77

[David Parker]

> The math is all fiddly and it's massively iterative nature amplifies even tiny errors until the results become completely invalid. Proving correctness is a huge undertaking when it's possible at all.

Flaming Thunder at http://www.flamingthunder.com/ has built-in interval arithmetic so that scientists and engineers can automatically get worst-case bounds on their results. Flaming Thunder also has arbitrary precision floating-point, so that scientists and engineers can increase the precision to whatever gives them acceptable results.

Re:Newfangled Fortran90 vs. FORTRAN77

[sjames]

That is a valid solution for some cases. Arbitrary precision simplifies the problem greatly. Unfortunatly, it's not useful in some cases. For example if the problem will require 2048 cpu-years with double precision IEEE floats, the job may not complete before retirement if arbitrary precision is used instead.

Paradigms

[Anonymous Coward]

You got a CS degree yet avoided taking a course in comparative programming languages,
or some equivalent course in that tier?

That's unfortunate. You can function in the workplace without that background, but
it might be the only opportunity to really get it for most people.

Brainfuck

[megaditto]

Plus it will make your resume stand out.

http://en.wikipedia.org/wiki/Brainfuck

Scheme

[RAMMS EIN]

I would recommend Scheme. Not because I recommend you program in it, but because it will change the way you think about programming and programming languages, especially if you also read Structure and Interpretation of Computer Programs (affectionately known as SICP).

Scheme is a small programming language, so you can learn it relatively quickly. This allows you time to read some of the literature about Scheme. And SICP. This will give you insight in the design of programming languages, and how features (like loops, class systems, etc.) can be implemented in terms of simpler constructs, given the right primitives and powerful enough abstractions.

And, in the end, it's the primitives and abstractions that matter. Given the right primitives and abstractions, you can mold your programming language to be anything you want. Scheme, and other languages in the larger Lisp family, are very good at this. That's probably why they are still around, despite tracing their roots back to the 1950s. Other languages are not so good at it, and you will end up writing lots of boilerplate and repetitive code if you program in them.

I could go on and on and list all the insights Scheme has provided me with, but I'd say you go see for yourself. SICP is a good place to start, because it starts at the basics (so you don't need to know Scheme before you start), but gets up to speed really quickly (so you won't get bored). You could also try my Scheme tutorial.

Note that all this is about the 5th revision of Scheme (known as R5RS). R5RS lacks many primitives that would make it useful for Real World applications (just to name one thing, there is nothing about networking). Many implementations of Scheme (and there are many) provide various such primitives - but that's not the point here. The point is about the fundamentals of programming.

As a final remark, if you are used to Java's "everything is part of a class" curfew, Scheme will provide a refreshing change of perspective. R5RS doesn't even have classes. Instead, the focus is on procedures. So you will be decomposing your system in terms of what it does, more than in terms of what real, imaginary, or "forced on you by the programming language" objects it acts on. In my experience, this leads to many small functions, each doing a simple thing, which can then be composed to build your system - or perhaps a very different system that happens to re-use part of the functionality. Unlike Java's classes, each containing a bunch of method, each of which contains gobs of repetitive code...try to adapt _that_ to do something similar, but slightly different. Again, it's all about primitives and abstractions.

Simple answer - biz English

[BigGerman]

The ability to communicate well with co-workers, bosses, clients, etc. over time will dwarf any benefits you can get from learning another programming language.

Programmers

[rockhome]

let's be clear, for the most part, people who learned and write exclusively in interpreted languages are not programmers.

They are scripters. Writing interpreted code is a lot like writing a glorified shell script and often times obfuscates much of what a "traditional" programmer would normally do. A programmer whose background is in python and perl should learn C next, and then probably Lisp.

I've met a lot of people who know a lot about interpreted languages, but they don't know why many of those languages are so bad with handling things like arrays and what their shortcomings are. Programmers ought to start out learning Lisp(yes, it is interpreted but it has greater educational and practical value) and C.

Re:Programmers

[metamatic]

let's be clear, for the most part, people who learned and write exclusively in interpreted languages are not programmers.

Spoken like a language bigot. In truth, the distinction between interpreted and scripted is pretty arbitrary. You can write in interpreted C or compiled Ruby.

I've met a lot of people who know a lot about interpreted languages, but they don't know why many of those languages are so bad with handling things like arrays and what their shortcomings are.

Funny, the languages I know that are the most painful to do array manipulation in are the compiled ones like C and Java.

Re:Programmers

[arevos]

Whether a programming language is compiled or interpreted is an implementation detail, not a feature of the language itself.

Re:Programmers

[Alpha830RulZ]

And therefore, god knows, they can't possibly do anything useful, access and change data, create systems that provide value to people, benefit from the thinkings around patterns, development methods, or any of those other good things that Real Programmers use. [rolls eyes]

I immediately thought about duck typing when I saw your comment. If a piece of code executes, has logic, accesses/modifies/creates data, could have errors, runs on a computer, etc, I'm not sure what the useful distinction is in deriding it as a script. Heck, which one is Java or C#? Are they compiled or interpreted, for your purposes? I'm mostly a Java guy these days, am I a Programmer, or poser? I also use Perl and Python, does that undo any goodness that I accrue from Java? I used to do a lot of C, does that hang with me, or does it get undone when I type while ($line = )...?

I'm old enough that I can remember the Fortran guys sneering at the Basic guys, much as we see here. At the end of the day, the user didn't care, then as now.

Ruby all Hype no substance

[Martin S.]

The Ruby syntax tree needs an LL(k) parser. This tighly couples the parser to the lexical analyser which makes any it deeply flawed, buggy and unreliable. Add into the mix that ruby is really a dynamic scripting language and you find an explaination for it's unreliablility.

Dr. Dermot Hogan agrees, he said To my mind, the Ruby parser and syntax is fundamentally flawed.

That's why there are not grand scalable performant systems written in Ruby.

James Gosling said of Ruby it ... just generate web pages. But none of them attempt any serious breadth in the application domain and they both have really serious scaling and performance problems.

He was proven right by Derek Sivers said after spending two years trying to rewrite a website in Ruby with Jeremy Kemper that it was Like trying to turn a train into a boat. It's do-able with a lot of glue. But it's damn hard. And certainly makes you ask why you're really doing this. In the end he abandoned Ruby and rewote the system in PHP in 2 Months.

If you want to do Dynamic programming, don't be taken in by the hype; learn Python, Smalltalk or the second choice language Schema.

Re:Ruby all Hype no substance

[piojo]

The Ruby syntax tree needs an LL(k) parser. This tighly couples the parser to the lexical analyser which makes any it deeply flawed, buggy and unreliable. Add into the mix that ruby is really a dynamic scripting language and you find an explaination for it's unreliablility. Is this flamebait? That's a pretty bad analysis, because its conclusions are false. Are ruby parsers buggy? The one you can download from ruby-lang.org isn't. Is Ruby unreliable? Only insofar as I can use it to write bad programs.

As for your second point, I agree that PHP is more suited for most web sites that Ruby. I would probably use Rails if (and only if) I had a web site in mind that was well suited to the "model view controller" idea.

But from reading your post, you have clearly never tried Ruby. You didn't criticize the right things ;).

try qore

[barnacle]

why not be different? Why use a standard, popular language with large function/class libraries and a huge user base? Try qore instead!

http://qoretechnologies.com/qore

You will be unique. Your friends and colleagues will applaud your taste in esoteric programming languages.

You just might get a great new job out of it too. Somehow it could lead you to winning the lottery. Or even getting that significant other of your dreams. The possibilities are virtually endless...

run!

[yoprst]

reddit's programming languages virus has just infected slashdot...

Right Answer

[whitehatlurker]

Learn FORTRAN - FORTRAN IV, specifically. None this pussy f95 stuff.

Binary

[kellyb9]

Enough said...

Don't laugh.

[DA_MAN_DA_MYTH]

But I think a really good language to learn is ECMAScript or to the layman, Javascript.

Javascript is the language of the future. It's such a powerful language and so underrated. It's far beyond the whole switching images thing. It's an interpreted langauge deployed on more computers than any other programming language. (think web browser.) It's light, it's fast, it's dynamic. For a scripting language it offers you an extremely familiar syntax, C like. It's becoming the backbone of other environments, and other compiled / interpreted languages are being extended for scripting support.

Re:Don't laugh.

[zoid.com]

This is funny and true at the same time. I'm seeing Javascript/ECMAScript being used more and more as a general purpose embedded language. There is so much I don't like about the language but the truth is it's everywhere.

Re:Don't laugh.

[zobier]

ECMAScript is actually pretty cool, it also supports functional, imperative and object-oriented paradigms and doesn't afraid of anything.

I'm trying to work out the best way to use it on the server-side. I'll probably look into one of the combinations of SpiderMonkey & Apache, mod_js perhaps.

Re:Don't laugh.

[Millennium]

As long as you don't have to deal with browser incompatibilities, JavaScript is actually pretty darn cool.

Eiffel

[Meor]

Eiffel: Native code OO language, design by contract, well implemented multiple inheritance, high order functions, closure, interfaces with C, C++.

Scala and Groovy

[seasunset]

Shameless plug... I have a comparison mainly involving Scala and Groovy. The short story is that I would argue that Scala is not ready for prime time and that FP is not a small step for "Joe Java programmer" requiring hard retraining. Furthermore Groovy has most of the advantages of Scala (and in some cases is clearly more mature)

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.

The natural choice is...

[operon]

...learn the language of butterflies. Don't forget to be imperative.

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.

Prolog or Lisp

[AlgorithMan]

Prolog or Lisp
it's unbelievable, how useful they are, once you are familiar with them...

OCaml

[disassembled]

Give Objective Caml a try.

I used to be a die-hard C/C++ programmer, and I figured I'd never be quite as comfortable in another language. These days, though, I don't feel productive unless I'm using OCaml. You won't realize how broken and clumsy most mainstream languages are until you learn OCaml or one of its ML relatives. It takes some time, but it's worth it.

And yes, you can actually write real programs with it!

Which language leads to more fun and better jobs?

[assertation]

My criteria for choosing what new language to learn would be the language that maximizes both of these at the same time:

1. What language would be good for my career?

2. What language would be interesting / fun to learn?

Many interesting languages. I like programming so I would enjoy learning anything. I have a job and a life. Since there are only so many hours in a day I want to pick something that will lead to more jobs, better paying jobs, and more *interesting* ( fun ) jobs.

Languages MUCH more different than you think

[arevos]

The question is flawed. Anyone worth their weight as a programmer doesn't care what language they
program in but. But Programing Methodoligy should they work with. Assuming that you use to
Object Orianted Languages (C++, Java, .NET) which are a deveation of Procedural Based Languges (C,
Pascal, FORTRAN). So after knowing those methodoligies perhaps you should study functional languages
(LISP, SCHEME, HASCAL) or Logic Based Languges (Prolog). Hold up there! You're vastly over-simplifying the issue. Many programming languages can't be divided cleanly into the categories you name. For instance, is Common Lisp a procedural, functional, or object orientated language?

Some languages are very interchangeable, such as Java and C#. Other languages are vastly different, and attempting to draw discrete boundaries around them is not going to succeed. Any language worth knowing is a methodology all in itself. Smalltalk and Java are both object orientated languages, but there are considerable differences between the two languages, in implementation and philosophy.

My guess is that you're an undergrad at University, as you remind me of myself at that age. Try reading up on Forth, Lisp and Smalltalk. Contrast Qi to Haskell, Io to Java, Clojure to Scala. The differences between programming languages are far more pronounced than you appear to think.

Objective-C

[toph42]

You've got to learn Objective-C. Duh. How else are you going to write iPhone apps. ;)

Think functional

[Richard W.M. Jones]

"Functional" languages, actually a real misnomer. Really you should look at what are currently classed as "research" languages which are interesting because they have advanced features which make programming easier and safer.

My list would include:

1. OCaml (obviously, see my signature)
2. Haskell
3. Erlang
4. SML / MLton
5. CDuce, Aurochs, COQ, etc.

Rich.

Re:Think functional

[Anonymous Coward]

"Functional" languages, actually a real misnomer. Really you should look at what are currently classed as "research" languages

I think you misunderstand the word "functional" as used in computer science.

Languages are called functional when programs are built up through the composition of functions.

Functions take arguments and return values, providing a consistent mapping from one to the other.

Many other languages are procedural (an antonym of functional). Procedures are sets of steps to take with declared data. Procedures can invoke other procedures ("subroutines"), which are called without arguments, and return no values.

Many procedural languages also have some sort of system to allow for functional subroutines, where "function" here again describes a mapping of argument to result. Not all procedural languages support this, and procedural programming style usually concentrates on global data structures which subroutines operate on.

Arithmetic in most languages is functional rather than procedural, in that it tends to be "r = a + b" (where we could write this as r = add(a, b)" rather than "subroutine set-r-to-a-plus-b { while (a > 0) { increment r; decrement a}; while (a 0) { increment r; decrement b}; while (b 0) { decrement r; increment b} } call set-r-to-a-plus-b". Note that we operate on a and b destructively in the procedural approach; in a functional approach, the values of a and b are preserved.

Both approaches are useful.

APL!

[bb5ch39t]

Not only is it capable of destroying your mind, you get to use all these neat Greek language symbols!

Master something, but also taste a wide variety

[hattig]

Learning to improve your job chances? Then it's not so much about the languages that are important as the third party APIs available for languages you may already know.

For yourself, the current vogue is Verilog and playing around with FPGAs. Build/buy a minimig and see what you can do once you've stopped playing robocod.

Otherwise I tend to learn languages on demand, and never anything that'd a fad. It's not hard to learn a new language, although mastering the ins and outs takes a lot longer. Always good to know a popular well paid job language, like Java or C# or even PHP, inside out (i.e., the language and a good selection of APIs like Struts, Hibernate, JDBC, and so on).

Once you've done that, then learn a lower level language if you don't already know C, i.e., learn C. You don't need to master it, most people don't end up writing operating systems. It will help you understand what the computer is doing far better than not paying attention at university ever did (unless you wrote scene demos as a teenager!). Also you might want to write Gnome applications. You could learn assembler, or you could spend some time coding an 8-bit micro (via an emulator) in assembler to learn some cool stuff. WinApe is a CPC emulator with excellent development tools built in (Z80).

If you've got a Mac, learn Objective C, you have all the tools, you'd be a fool not to take advantage of it when you have the time.

Also you should know a scripting language or two. Perl is a good one. Learn shell scripting too.

If you have a job programming something esoteric, then it is very important that you keep up with a modern language in your spare time, in case the worst happens with your job.

Don't forget functional languages either. Nor don't discount selling your soul and learning some Microsoft systems stuff, although I haven't done that yet.

Oh, and as you get older, you'll be hoping to do more management type stuff too, so don't neglect those people skills.

Lots of good languages

[roggg]

If the goal is to learn a language to help you in your career, C, C++, Java, Perl, SQL, PHP are all good things to know. There are others, but you start getting niche specific.

If the goal is to push yourself into new modes of thinking or programming paradigms:

• Learn 1 Wirth language. Modula II or Oberon would be good ones. Wirth had a strong understanding of separation of interface and implementation. His langauges are among the best for encouraging well structured programs.
  
  
• Prolog
  
  
• Smalltalk
  
  
• Scheme
  
  
• Python
  
  
• APL
  
  

All valuable languages for exploring some paradigm of programming. Don't just learn how to write C in each of these languages. Learn what makes them unique, and the patterns and idioms they are designed to express elegantly.

It depends on why you're learning a different lang

[Russ Nelson]

If you're learning a different language to broaden your horizons, then learn something like assembly, or a stack-based language like Postscript or FORTH. If you're learning another language because you need better tools, then learn Python.

Perl

[TheLink]

I'd say _also_ learn perl if just because of CPAN alone. To me the best form of code reuse is being able to reuse someone else's code that's better than yours :).

While languages like Lisp are very powerful - in that smart programmers don't have to write so much to do a lot, the problem for stupid and lazy people like me is I still have to think and write a lot more since there isn't as much great stuff out there to reuse (yes I know the less people using a language = less code out there to reuse, and that is sometimes not the fault of the language).

It's the difference between being able to recursively build a house atom by atom exactly the way you want it, and being able build one using mostly prefab components. The latter is likely to be faster for stupid and lazy people like me :).

The boss/customer usually doesn't care if each door hinge is perfectly macro-crafted - he's probably going to change his mind on where the doors are going to be anyway...

In short:
Lisp is powerful - for the code you write (expressiveness).
C is powerful - for the code you write (low level control + performance).
Perl is powerful - for the code you _didn't_ write (laziness). :)

Verilog, the language for hardware design labs

[Crazy Taco]

This is a great example of mods and commenters (i.e. GP, currently modded informative) who don't know what the hell they're talking about. Parent post is correct -- while you can use Verilog for programming an FPGA (field-programmable gate array), Verilog has many uses in hardware design. It's called Verilog HDL (hardware description language) for a reason. Here is an overview of Verilog for the uninitiated.

The parent post is absolutely correct. I recieved a degree in computer engineering from Iowa State, and have first hand lab experience of using Verilog to design CPUs and memory modules. It is definately a hardware design language. Mod parent and grandparent up.

SML or any sort of functional language

[PureCreditor]

In our world that imperative languages are near ubiquity, functional languages actually teaches us how to code succinctly and cleanly.

The one SML class I took in Sophomore year was more helpful in defining my coding style than any of my other courses. I finally learnt how math and compsci are intrinsically related to each other when all your code is defined in y=f(x) format.

Granted, functional applications currently have too few APIs to allow true RAD (Java being the other extreme with too much API ^^). It's more a learning tool than a production one I guess.

MDX (Multi-dimensional Query Language)

[cyclocommuter]

For mining those ever growing Home Land Security datawarehouses.

That Depends:

[TheGrapeApe]

"Profit!": C# "Freedom!": Rails "Fun!": Lua

PS

[hummassa]

Postscript is a Turing complete language. and a wonderful one, albeit postfixed.

Re:Brainfuck

[Neil Hodges]

Although that language is fun to write in, assembly's a bit more useful in getting a job. Once you understand things such as jumps, which Brainfuck teaches, assembly becomes easier to understand.

SAP's ABAP

[Dgtl_ _Phoenix]

Clearly you fools have been forgetting ABAP, the best business application language 1972 has to offer.

What programming langages should you learn next?

[theeddie55]

What do you want to do next? Most programming languages are good for certain jobs, but not so good for other jobs. If you want to make dynamic websites, PHP, ASP or similar would be a good start. For other things learn an appropriate language for what you want to do

One word...

[Rip Dick]

Brainfuck

Gaaargh, hit submit by accident.

[Estanislao Mart�nez]

Here's an example: in functional pseudo-code, the list append function is defined like this:

append(a, []) = [];
append([], a) = [];
append(head:tail, b) = head : append(tail, b);

When you evaluate append([1,2], [3,4]), the evaluation proceeds as follows:

append([1,2], [3,4])
=> append(1:[2], [3,4])
=> 1 : append([2], [3,4])
=> 1 : append(2 : [], [3,4])
=> 1: 2 : append([], [3,4])
=> 1 : 2 : [3,4]
=> [1,2,3,4]

What you're doing is pattern-matching the expressions to the left-hand sides function definitions, substituting according to the right-hand sides, and using those to simplify step-by-step to a final answer.

In logic programming, on the other hand, there are no functions, just predicates.  Append(A,B,C) is a three-place predicate that is only true if A, B and C are bound to lists such that, if you appended A to B, you'd get C.  In pseudo-code, again:

append([],B,B);
append(A,[],A);
append([HeadA:TailA], B, [HeadA:TailC]) :- append(TailA, B, TailC);

The first predicate is only satisfied if the first argument is an empty list, and if the other two are equal lists: i.e., the append of empty list to B is B.  Likewise for the second.  The third one is satisfied if all these conditions are met:

* The head of the first and third lists is the same value.
* The append of the tail of the first list and the second list is the tail of the third list.

While the functional program operates by applying functions over the "input" lists to produce an "output" list, the logic program accepts any combination of values and unspecifed variables for the argument slots, and searches for values that, replaced for the variables, make the predicate true.  To append two lists, you can specify the first two args and give a variable for the third:

append([1,2], [3,4], C)?
=> C = [1,2,3,4]

...or you can specify the second and third only:

append(A, [3,4], [1,2,3,4])?
=> A = [1,2]

... or even just the third one, in which case, the program produces the following answers (only one at a time; after it's given you an answer, you can request it to produce another one):

append(A, B, [1, 2, 3, 4])?
=> A = [], B = [1,2,3,4]
=> A = [1], B = [2,3,4]
=> A = [1,2], B = [3,4]
=> A = [1,2,3], B = [4]
=> A = [1,2,3,4], B = []

You can do even more complicated queries than that:

append(A, A, [1,2,1,2])?
=> A = [1,2]

First, learn C++ properly...

[serviscope_minor]

First, learn C++ properly. The template language is a strict, pure, referentially transparent functional language.

Then, learn shell scripting. It's different from most languages in that is really requires the use of a number of DSLs. The stream oriented programming is very different from a lot of languages. Parallelism/coporcesses are implicit and very natural in that foo | bar is automatically parallel. Code and data are interchangable and this is idiomatic foo | bar | sh. You can also get parallelism easily. For instance, replacing sh with xargs -d'\n' -n1 -P4 will make good use of your quad core computer. If distributed computing is your thing, you can also make use of passwordless ssh for almost trivial distributed computing. Or you can embed code in HERE documents, giving you PHP like embedding code in data. The possibilities are pretty much endless.

Then learn some other languages. A good dictionary bashing like python, FORTH or postscript is probably worth learning.

It's also worth learning a nicer functional language than C++ templates. Something like Haskell or LISP.

There should be some assembler in there too, something like protected mode x86 asm.

You can also try really constrained programming environments, by getting one of the $100 PIC evaluation boards. Then you can get to practice programming with no OS around to help/hinder.

Then learn Makefiles. If you can do anything above, makefiles are easy. And again, they have implicit parallelism. Nice for your N core machine.

I've probably missed a few important topics, but you get the idea.

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

[haystor]

Practical Common Lisp is the better book for someone starting oiut.

On Lisp is for someone who wants to learn the portions of Lisp that make it worth learning--after they've learned the basic syntax.

sendmail

[Culture20]

Once you have mastered the sendmail.cf, nothing is too complex for you.
Seriously though, this comment is spot on:
http://it.slashdot.org/comments.pl?sid=491582&cid=22785524
although I'd suggest LISP instead of Scheme if you're looking to learn about functional programming (Scheme has common libraries which allow you to fake procedural programming too easily, so it's not as good for learning the functional programming model, despite it being better[?] than LISP).

Python

[zukinux]

no more words are needed. Python > all!

next ? what about enough ?

[unity100]

how many people are there who can come up and say that they learned what language they are mainly using enough ? and, is it mandatory to have a 'next' language to learn ? apart from hobby purposes ? do you know that there are companies looking to hire lisp programmers etc still ?

and whats the definition of 'next' anyway ?

UUghhh Your kidding me, right?

[geekoid]

What is it, flamewar day? It is very easy to make the decsion.

What is it you want to DO?

A language does nothing. It's just something a compiler can interpet.

Do you want to make robots dance? Do you want to make a faster RDBMS? Do you want to write front ends for tellers? DO you want to do web pages? forums? flash?

What someone can do, right ow is so great that there are a million things more important then the language. In days of yor, we were contrained by some 'boxes'. Then we where 'programmers'. Now languages is a means to another goal. Leave that old way of thinking behind. Think "What do I want to create?" not "What can a create with these limited tools"

Now, some pedantic ass is going to say "We always could do anything with C and assembly!" True, but they are intimidating to use, and now we have people creating what ever comes to mind and not have to worry about esoteric bit flipping.

Yes, this means there is more crap, but the Jewels being created right now shine brighter then anyone could have imagined 20 years ago.

What do you want to DO?

Yes and no.

[jd]

Unless you're looking for work today, what they want on Monster today is unimportant. If you are looking for work next week, then your resume needs to reflect the job requirements next week - today's requirements only apply for today. This is where risk analysis comes in. You can't know what's going to be important next week, next year, five years from now. No language lasts forever and it's fair to assume that eventually what is fashionable now will go the way of Cobol and Fortran - into very specialist and limited communities. But which languages will die off? And which languages will replace them?

BCPL evolved into B, which evolved into C. BCPL is no longer used, so technically died off, but C and C-related languages are not only in widespread use, the family is still growing. C#, D, Objective C... Anyone who learned BCPL (so long as they're not dead from old age) could understand the basics of D without ever touching a textbook on it, by virtue of it being a linear descendent. As such, it's less a die-off and more an evolution, which requires minimal training to be able to get right.

Erlang, Haskell, Forth, LISP, Ruby... These are not direct descendents and require additional understanding to program well in. The greater the difference in methodology, abstractness, style and notation, the greater the learning curve to become proficient in that language.

This is where it becomes important. You can't start learning the language the day you start a new job. You can't really start a month before, unless the learning curve only requires you put in a month. You have to determine how likely each language is to be needed and when by, and then make sure you learn sufficiently in advance to compete for those jobs once those positions do become available. Unless it's far enough in advance that you'll have retired, in which case you can probably disregard it except for hobbyist purposes.

Re:Yes and no.

[ucblockhead]

The job market doesn't change that fast. The top-five languages from five years ago are all still extremely popular. If you learn the top five languages for today, you will most likely be in very good shape in five or ten years in the future. If you wait until you actually need the job, it'll be too late.

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

[nuzak]

Most schemes offer unhygenic macros these days alongside the hygenic ones.

I don't know about straight C, but there's OpenC++ for writing syntactic transforms to C++, and OpenJava which does the same for Java. Not sure how up to date they are these days. Thing is, all the extra syntax they have to support makes lisp and scheme macros look simple.

Macros are a often a convenient feature to have, and in some cases they can be awesomely powerful (lambdaweb is done essentially with a big macro that cps-transforms its forms) but unless you get very freaky with metaprogramming, it really doesn't stretch the paradigm all that much.

If you want to play around with the idea of macro metaprogramming, I recommend metalua. There's so little to lua that you don't get confused by the homongous specification of CL or libraries of scheme, so you have a greater understanding of what's going on through experiment.

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

[dfsmith]

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!
One of the joys of C is that it doesn't do this. You can normally tell from looking at a block of code what the compiler will spit out. Key words, arithmetic, function calls and dereferencing all pretty much do what you think they'll do! (And, with the exception of function calls, don't require looking it up in the documentation.)

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

[DougWebb]

I'm pretty sure Perl can do these things too, though I don't know Lisp or Scheme well enough for an apples-to-apples comparison of the capabilities.

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.

Perl's BEGIN functions run during the compile phase, and let you run whatever code you like at that time. You can define new functions based on compile-time options if you like, or based on whatever else you might base it on. You also have full access to the symbol table, which is handy if you want to do something like put wrappers around other functions. Note that you don't have to do this stuff in BEGIN blocks; you have these capabilities at runtime too. If you want to introduce new keywords to the language, there are modules in CPAN that do that, and I'm pretty sure they do it by adding functions to the Core namespace. I've never had a need for this though, so I'm not certain exactly how it's done.

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!

Again, I'm pretty sure that a Perl programs ability to tap into and manipulate its own symbol tree, either that compile time or run time, gives it the ability to do this sort of thing. Or, there are also modules like Parse::RecDescent which might be better for the task.

So very true.

[jd]

Anyone here own a car? Maintain it? Use only a single screwdriver for everything - including hammering, removing bolts, replacing the oil filter....?

Different languages in the same basic family are designed for different, albeit similar, purposes. The similarities should not mislead you. Each will be good for the parameters for which they are designed, each will be bad for almost anything outside of those parameters. Smalltalk, Java and C++ belong to the object-based family (although Smalltalk is the only OO language of the three regarded as pure, Java is mostly OO and C++ is extremely hybrid). Because all are object-based, all are designed for problem-spaces concerned with containers, encapsulation, localizing and tightly-controlled visibility.

On the other hand, C and C++ also belong to a common family. In this case, both support C-style programming and syntax. This is useful when you want to use compilers with a lot of research into techniques behind them. C++ at its slowest was faster than any object-based or object-oriented programming language that required compilers that could learn little or nothing from previous generations of compiler theory. (Experimental languages that follow novel designs and syntax often fall into this category.)

Other examples of languages that fall into a common family and are obviously different: C-shell and BASH. Pascal and Occam. 80x86 and MIPS. Perl and Python. PHP and Javascript. Fortran and BASIC.

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

[chromatic]

This is all possible in Perl, but it's rather difficult to manipulate the syntax tree directly as you would in a Lisp or a Scheme. Unambiguous parser overloading is definitely Deep Magic in Perl 5. (Perl 6 makes this much easier.)

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

[Just Some Guy]

One of the joys of C is that it doesn't do this. You can normally tell from looking at a block of code what the compiler will spit out.

First, that's only true if the compiler has all optimizations turned off. Anything from -O on up will reduce that to a wild guess. Second, I'd consider that a weakness of the language. Sure, it's convenient sometimes to know exactly when memory is allocated and freed or what code gets executed when, but I'd much rather have abstracted multi-threading, lazy evaluation, and other non-obvious bits that make code shorter and faster.

C's pretty spiffy when you need that degree of control. When you want to write it quickly and correctly and run it faster than C could, there are better alternatives.

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

[Just Some Guy]

I'm pretty sure Perl can do these things too, though I don't know Lisp or Scheme well enough for an apples-to-apples comparison of the capabilities.

Umm, we kinda guessed that.

Get thee to Casting SPELs in Lisp and work through the fun example. It's only a glimpse of what Lisp can do, but will disavow you of any notions of Perl equivalence pretty quickly.

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

[umghhh]

In my experience the failure is not caused by people not knowing the language. Incompetence and ignorance are curable by education. Not willing to go through review process, being convinced of own superiority and infallibility, this all is equal to sabotaging the project and all is not curable. I have seen millions sunk not because projects had crews that could not code but because they were not able to communicate. We also have seen new brilliant toys that were to provide silver bullet and failed.
I still have to occasionally write code in assembler of the processor that is all but dead and is simulated by virtual machine. It is still cheaper than writing new RT application of the same functionality in new language and just to be able to add this one single module that nobody wants to write in old proprietary language.

What I wanted to say is that the programming language is just a tool, it is a hard heart eeee cool head that allows to use it properly.

Scala is a multi-paradigm language

[Laz10]

"Scala is a modern multi-paradigm programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages."
http://www.scala-lang.org/intro/index.html

Functional programming is just a part of it. You don't have to use it. Just like you don't have to use generics in java.

If you want to you can use it write something that just looks like cleaner java programs in Scala. That what makes it easy to learn.
I am sure that as soon as the tools get up to speed, we will start seeing people building great things with Scala.

Real Men use...

[scubamage]

Punch cards and FORTRAN.

D Programming Language

[WalterBright]

D combines C++ like power and Python like productivity in one language.

Re:D Programming Language

[sqldr]

And was written by a certain "Walter Bright" :-)

That said, it is a very good language, and deserves to be in the list.

http://www.digitalmars.com/d/

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.

Python. Most universal PL out there.

[Qbertino]

I'm using PHP for my day-to-day work and deal a lot with Ruby fanboys, but I have to say that Python has a special place in my heart.
Here are the upsides (and some things that make Python exceptional) in my book:

1.) Very much like PHP and Perl, Python lacks the academic stench and has a general overall non-challance and n00by friendlyness to it. Things that *really* bug me about C and Java. And a smell that Ruby is gaining due to all the Java people brining their old bad habbits over to ruby.

2.) It's elegant and has a very neat and clean syntax, lacking the bizar and intimidating curly braces and semi-colons strewn all about in classics such as Java or JS. Or PHP for that matter.

3.) Indentation as block delimiter. The most ridiculed thing about Python (ridiculed by people who've never used Python) is acutally one of it's neatest features. Keeps code clean, minimal, human-readably and it's style in sync across many developers. Great for collaboration. And let's not forget that famous Donald Knuth quote: "We will perhaps eventually be writing only small modules which are identified by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." ... He said it best back in '74, nothing to add here.

4.) Python is used in serious non-trivial areas and applications in every field I can think of. Gaming, Multimedia/3D, Science, Large Scale HPC (Google f.i.), Embeded and, last but not least, sophisticated web applications. It apparently integrates very well as a scripting language, judging from the countless applications that use it as their choice of script and it also drives large non-trivial applications as core technology. (Googles Deployment Pipeline or, f.e. Blender)

5.) It's the foundation for the most sophisticated web kit to date: Zope. Zope is way ahead of anything in the Rails ballpark (or any other Web-FW), and it's only due to crappy project marketing on Zope's side that it didn't get as much attention in 2001 as Rails did since 2004. Until the MVC+SQL layering crowd catches up with Zope it will be another few years, until then it will remain the bar for any programmers who've ever come across it. (Like many PHP Framework & CMS developers I know)

6.) It's got a regular Webkit called 'Django' (drinking buddies of the Rails crew) which is quite popular and in itself makes me curious enough to want to pick up Python again.

Bottom line:
If you're looking to learn a new PL, give Python a try. And even if you despise that indentation thing I recommend you try coding in it for 20 minutes. You'll notice that it doesn't bother you at all, since programmers who are experienced enough to worry about that indent correctly all the time anyway.

I have two on my list

[Fuzuli]

I am working on bayesian belief networks, and though I have been able to find some nice libraries, I have writing a simple one just to really get it, and to get quick results, I'll be taking a look at python.
A client of mine has been showing interest in IPhone apps, and if he deals with the quirks of the sdk (registering etc), then it will be objective-c for me.
I have never been able to actually learn or use a language without a clear need for it, so even though there are many others I'd be interested in, I know that as long as I do not have something to produce, the learning process just does not work for me.

Verilog

[sjdude]

Personally, I am learning Verilog. I'm tired of the hardware guys telling me how hard it is to design ASICs.

MMIX

[plstbb]

I would recommend http://www-cs-faculty.stanford.edu/~knuth/mmix.html

A great way to train your brain.

The big one

[SurturZ]

Binary.

Re:Haskell

[Pseudonym]

If you think that C and C++ are one language separated only by a slash, then you probably are better off coming from Java.

C++ has much more in common with Haskell than Java does, because of the un-C-like strict typing, and the template/concept type-level language, which is very close to Haskell's typeclass system. If you know C++ well, then you're probably ready for Haskell.

dynamic programming languages

[sentientbrendan]

there's been tons of dynamic programming languages coming out, most of which are pretty disappointing.

People say a language is "dynamic" as if it were a selling point, but what they really mean is that it is interpreted, they were too lazy to write a compiler for it, and that type checking is always deferred to runtime, even when you don't want it to be.

There's never really any excuse for not writing a compiler. Sometimes during development you don't want to compile things, and that's fine, but you need the choice. Many languages like Java and Ocaml have both interpreters *and* compilers, and I think that's the right way to go.

As for deferring type checks to runtime, any modern language can do that, but the so called dynamic languages have no choice *except* to do that, and have no mechanism whatsoever for checking for obvious type errors. You can run a python program a thousand times, only on the 1001th time to find that there was actually a type error in some statement that was never executed before. On the other hand Java and C# with generics, and C++ will catch your type errors *the first time you compile*. All these languages support dynamic typing, the difference is they *also* support static typing.

The reason languages like Python, Perl, and Ruby are written, the reason that aren't mentioned when evangelizing these languages, is that writing an interpreter is *easier* than writing a compiler (note I said easier and not easy). There's no need to write assembly for lots of platforms, or deal with things like register allocation, so some of the harder problems are taken off your plate. These languages are generally very ad hoc, and special purpose, and that's fine. They are great for writing dinky one off scripts. However, let's not glorify them to the point where we are doing something more sophisticated than that, say writing large web apps.

On the other hand, writing a c++ compiler is a major endeavor both because it is compiled and it is standardized (you can't just say that the standard is whatever the hell buggy way the reference implementation does it). Now, C++ has some problems of its own, but because it is statically typed, and compiles to a highly optimized form, it gives you a very powerful tool for writing large scale and high performance software. Much of the same can be said of java, although some performance is traded for things like cross platform support and ease of programming (a trade off which is appropriate in a number of domains like web programming).

Re:dynamic programming languages

[chromatic]

People say a language is "dynamic" as if it were a selling point, but what they really mean is that it is interpreted, they were too lazy to write a compiler for it, and that type checking is always deferred to runtime, even when you don't want it to be.

People who say that have never programmed in a dynamic language, and wouldn't recognize one if they made small talk with one at a party.

The reason languages like Python, Perl, and Ruby are written, the reason that aren't mentioned when evangelizing these languages, is that writing an interpreter is *easier* than writing a compiler (note I said easier and not easy). There's no need to write assembly for lots of platforms, or deal with things like register allocation, so some of the harder problems are taken off your plate.

That's funny; I seem to recall patching the register allocator of a virtual machine for dynamic languages just last week.

Re:dynamic programming languages

[countach]

Some programming techniques can be programmed much more elegantly without compile time typing. All type systems have problems, especially with things like covariance and contravariance.

Now, I would tend to agree that it is worth sacrificing a little elegance for all the benefits of compile time typing, but you can't say it is an axiom of truth that compile time typing is best way. From a strictly purest perspective, runtime typing is best.

Re:dynamic programming languages

[grumbel]

Some programming techniques can be programmed much more elegantly without compile time typing. Could you name some examples? I basically only know three common use cases for mixing types and all of them could also be done via compile time checking:

1) Out-of-Band Error Values:

def do_something():
    if blabla:
        return 10
    else:
        return None

So instead of returning a magic value of some sort, the dynamic language gives you the option to return a different type that clearly signals that the return value is not to be meant as a value. But that could be checked statically, since you don't want to return any type, but just int and None. Some people use a templates that wrapper a value in C++ to get a similar effect (i.e. Value foo = 5; if (foo.is_valid()) foo.get(); ...)

2) Duck Typing:

def draw_object(obj):
    obj.draw()

Here you call a draw() method, any object that has a draw method could be used with this one. This is basically the same thing you can do with templates or by declaring a Base class in C++ and while it saves you some typing in Python or Ruby, it is again something that could be checked statically, i.e. obj must be an object that has a draw() method, else the function is going to fail.

3) Function overloading:

def do_stuff(foo):
    if type(foo) == int:
        do_this()
    elif type(foo) == str:
        do_that()

This however isn't an advantage, but a downside, since you can express stuff like that much more clearly when you can just indicate that there is a do_stuff(int foo) and a do_stuff(string foo)

The main advantage I see in dynamic languages is that duck-typing allows you to save some typing, since you don't have to write down a base class to define an interface, you simply call the methods. However that isn't really an advantage of the dynamic typing since you can have similar effects in a static language. And of course none of this justifies why there isn't a typed variable. Would it hurt so much to have a any foo; and a int foo; instead of being forced to always use the any type?

Re:dynamic programming languages

[Anonymous Coward]

1. If you're doing that, your design sucks anyway - use exceptions when appropriate, don't change the return type.

3. Misses the point. If you ever write an method/message like that in a dynamic language, then you're doing something wrong - that's two separate methods, not a single one. Just like it would be in a statically typed language.

Python, definitely

[rw63phi]

It's fun to use and it's open source.
Definitely two winning points.
But of course this post, as well as this whole article, is destined to ignite a religious flame war.

wrenches in the tool box

[Dan667]

I have always thought of programming languages as more of a wrench in your tool box. If you need high horsepower I use ANSI C. If I am doing text processing, I use Perl. I think a good question would also be, what do you need to do and what languages would let you do that? That is a pretty practical view that you actually need to build something you need though.

Why do you suppose what I'd suppose?

[shyberfoptik]

Yes, I guess all programming languages are 'design patterns,' but a 'design pattern' is simply a way to abstract. A programming language is an abstraction. All of mathematics is abstraction.

The suggestion was that there is nothing gained from understanding an unfamiliar abstraction - that it's all just 'mindless' syntax. That's equivalent to saying the only thing a programming language is good for is saving time, or LOC, since that's really the only thing we can empirically measure.

But if you've ever gained new insight into the nature of 'process' while learning a new programming language, you know that is absolutely false. I mean, seriously, if you've ever studied any math you know this is false!

if you can think up a new language that is design-pattern-neutral without drowning the user in parentheses, you may be onto something.

What does 'design-pattern-neutral' mean? 'Abstraction-neutral?' That's like wanting an abstraction-free math. Lisp, which I assume you're talking about, is not 'abstraction-neutral' because it is an implementation of the abstraction for studying process known as the Lambda Calculus.

Re:Why do you suppose what I'd suppose?

[fred fleenblat]

>> What does 'design-pattern-neutral' mean?

Good question.

I would say that design-pattern-neutral would describe a language in which no particular design pattern was favored over any other, in terms of simpler syntax let's say. (This would have to extend to anti-patterns as well.) Lambda calculus is a good start, however in order to get things done, common lisp was grafted onto it, establishing preferred design patterns in the process.

I think the crux of the matter is that design patterns are difficult to work with since they are not regular or mathematical, they are fuzzy best-practices type things. So once you have a set of decent design patterns in a language, it becomes popular (since people like to avoid the work of creating design patterns).

In the long run, I'd hope that there are a finite number of distinct and useful design patterns and we'd have one set of languages for exploring design pattern space to find them all, and a second set of languages which take useful subsets of that space and embed them into their syntax (and probably semantics). I suspect that's what's actually going on, but the boundaries between the first set and the second set are not always clear. Possibly this is because there are patterns to designing design-patterns.

Depends on what you're optimizing

[shyberfoptik]

Choice of language is the only thing that optimizes programmer-time. Algorithm development? Try learning or implementing the Unification algorithm without at least some exposure to Prolog. The things you mention are important, especially for an EE guy. I assume that most of the software you need to write is strictly C or assembly. So yeah, if you need to trade off, you probably won't need to learn Haskell. The original post was assuming there's no point at all to learning new languages.

Pointers explained

[Anonymous Coward]

Your computer's memory is like a bunch of post office boxes (I assume these are the same the world over - a huge wall of little mailboxes labelled in some sort of predictable order).

You can store one number on a piece of paper in each box. If you want to store a string, you need a sequential run of boxes (each one storing a character). Pretty straightforward.

A pointer is just a box that has the number of another box stored in it. In other words, you have a value that tells you which box to open to get the value you want. Accessing the pointer directly gets you an address in memory (a P.O Box number), and dereferencing the pointer means getting the value from the box pointed to.

In our imaginary P.O Box computer:
Box abox = 55 // Allocates a P.O Box to store the value 55
Box *pbox = &abox // Allocates a pointer P.O Box and points it at the box that contains 55
print "The box number that has 55 in it is ", pbox
print "The value pointed at by pbox is %d", *pbox // Prints 55

Not hard.

Well, it depends ...

[ScrewMaster]

What would your choice be for programmers extending beyond their normal boundaries?

It depends largely upon whether you want a job or not.

Generally, you are correct.

[jd]

After the DotCom crash, there were a lot fewer Java and ASP programmers getting hired, although that was more of a blip in the job market. Well, to a degree. There's much more demand for J2EE programmers than pure Java developers these days, with the rise of servlet engines such as Tomcat. C# and .NET have caught on very fast, I don't see quite as many pure C positions as I used to, and I can't remember the last time I saw a Visual Basic job in the area where I live. Visual Basic was a major language 5 years ago.

In general, though, yes, there is a lot of stability in job requirements over time. Certainly enough to be sure that if you learned all that is current now, you'd know almost all that was current five, ten, fifteen years down the road. Those who only learn two or three languages have the most need to speculate, as they're at greatest risk of getting left behind, but those who've mastered the bulk of common languages today are in excellent shape for the future.

Nonetheless, I believe the advice holds true. If you keep learning, you will be the stronger for it, and if you second-guess correctly which way the market will swing in the future, you will be the more secure for it.

embedded programming.

[petermgreen]

How about learning how to program some small microcontroller (pic18 series are a nice choice, reasonablly clean architecture, nice package styles, tollerable development tools, free version of the C compiler availible with only minor crippling).

It is a whole different world and learning to deal with systems that are highly resourse limited is a refreshing change from the desktop mentality of "who cares about the bloat just wait for moores law to catch up".

Fortress

[Anonymous Coward]

I'd love to see Fortress from Sun developed more. It sounds perfect for the scientific computing that I do. Mathematical notation, automatically parallelized matrix-vector operations, and more. It's still a research language though, and doesn't seem to have much development occuring now.

C Octothorpe

[LittleBigScript]

Five years of experience at a minimum is required to work with telephone keypads.

http://thedailywtf.com/Articles/5_years_C-pound_experience.aspx

Why Use Someone Else's

[emeri1md]

Everyone feels that any given language is missing something. So make your own that fits your needs.

machete

[Anonymous Coward]

http://machete-lang.blogspot.com/

Digital Mars D

[Anonymous Coward]

Learn D. It's open source under the GNU license.

I find it awesome. Compiled, and object oriented. Garbage collector included. Namespaces too. Templates that are not an eyesore. As fast as C. Comes with a bult-in library, but there is a more popular systems library called Tango.

Arc

[dido]

Arc 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.

Brainfuck

[Children.of.the.Kron]

I would post a example of the versatility and user friendliness of Brainfuck, but the lameness filter cannot handle it. http://en.wikipedia.org/wiki/Brainfuck

Everyone

[ignavus]

Everyone should learn $(SELF->FAVOURITE_LANGUAGE).

There. That will save everyone else the need to post.

Re:Best Language to Learn Multithreaded Programmin

[grumbel]

Erlang is one of the few languages that is build around concurrency.

basically a definitional dispute

[Trepidity]

From a programming languages viewpoint, there's no fundamental distinction between a "description" language and a "programming" language.

Re:basically a definitional dispute

[krog]

HTML

YEssss!

[AutoTheme]

Yeehaaw! This has got to be one of the geekiest discussions recently!

-Shawn

lamda calculus, django & the future of program

[cekander]

What about \lambda calculus?

Also, I haven't heard anybody say, "Ruby? pshaw. Use django instead." Is there a consensus that Ruby is "more valuable" than django?

And third, perhaps most interesting, is the future of programming. I think a few people hinted around the issue here with sentiments such as "they're all the same modulo syntax". Obviously seasoned programmers know better, but there is value in a padawan's comments.

The truth is, all programming languages exist for the same reason, execute a sequence of electronic operations. As time approaches infinity, won't there be some consensus on the perfect blend of power/performance/ease of coding/etc to achieve that electronic operation? Why should we (humans) have 5 ways to do the same thing? The computer SHOULD have 5 ways to the the same thing, but it should decide which is best for a given environment and abstract that from our decision. I don't care!!!

LISP on vim?

[pbaer]

So why you shouldn't code LISP using vim? Hint,"because emacs is better" isn't an answer.

Re:LISP on vim?

[Jeremiah Cornelius]

Because you customise VIM with Python, and Emacs with a LITHP?

6502 assembly.

[liftphreaker]

Go and learn 6502 or Z80 assembly. I'm serious. I believe every coder should have some exposure to what goes on underneath the wonderful VM based hardware agnostic platform agnostic Java code we write. You will truly appreciate the complexities and intricacies of what goes on there when you write a "simple" statement like:

a = new int[10];

IF you have time to waste...

[Eth1csGrad1ent]

..on learning yet another language or paradigm, try this:

http://www.google.com/search?hl=en&q=how+to+build+an+outdoor+setting+from+hardwood&btnG=Google+Search

It will make you a better programmer.

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

[kocsonya]

> 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!

Actually, the humble FORTH allowed you to do that; you had access to the entire compilation process. It's a very cool feature, but like self-modifying code, the power comes at the price of responsibility. You can shoot yourself in the foot big time with those.

Lisp is NOT "Lost In Stupid Parentheses"

[mdm42]

...it's actually "Lisp is Stupid Parentheses"...

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

[Fulcrum of Evil]

One of the joys of C is that it doesn't do this.

I guess you've never seen someone with a hardon for macros. You can make C look a whole lot like fortran if you really want to.

Rebol

[the_arrow]

A language that I have toyed with from time to time, and that is very dynamic, is Relative Expression Based Object Language. Well worth to give it a try.

Your looking at it in the wrong direction.

[forgotten_my_nick]

Often developers pick languages on how cool they are for them to program in. But the truth is the industry would prefer the following in a language.

- Easy to localise.
- Easy to maintain.
- Easy to learn.
- Can integrate with existing systems without having to rewrite anything.

In fact...

[OpenSourced]

What Programming Languages Should You Learn Next?

The one you are using now.

Re:lamda calculus, django & the future of prog

[RPoet]

What about \lambda calculus?

Pick up on of the purely functional languages, like Haskell.

Also, I haven't heard anybody say, "Ruby? pshaw. Use django instead." Is there a consensus that Ruby is "more valuable" than django?

Ruby is a general-purpose programming language. Django is a web application framework. Where is the comparison?

BAL

[jandersen]

It would have to be IBM Basic assembly language http://en.wikipedia.org/wiki/IBM_Basic_assembly_language; definitely. This is only halfways a joke - think about it; there is a huge number of programming languages in the world, all of them sort of more or less the same. Learn C, then you have easy access to learning most of the rest. But assembler, any assembler, will teach you how a computer works at a deeper level, which has got to be beneficial. Also, you can then amaze yourself with how small programs can actually be.

And why BAL? Why not? How many people do you know who can actually program a mainframe in any language, let alone assembler? Especially young people? It's a little like learning flint knapping; it went out of style a while back, but it's bloody cool to be able to do it.

The Pointers

[Keeper Of Keys]

Uggh...pointers...BAD BAd bAD......no....not...the pointers again....[trembles]

I can deal with about anything, except pointers. Thanks for bringing the nightmares back again....

:-P

As they point, do they say "Ni"?

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

[Nurgled]

Regarding treating syntax trees as data, the latest version of C# has a feature which shows a movement in this direction. It's called Expression Trees and it allows the code to capture a representation of the compiler's parse tree for an expression and use it as data. It's used to implement Language Integrated Query against external data sources; for example, Microsoft has code that'll transform an expression tree into an SQL expression.

Of course, you are still constrained by the C# expression syntax and compile-time type checking. That's by design, though: the goal here was to ratain type checking, IDE autocomplete and so forth while being able to "remote" your expression evaluation.

functional program languages are the future

[vegaspace]

Functional program languages are more efficient than object oriented ones. In order to reduce powercompsuntion, a speedful program can use more threads (e.g. Yaws, a web server wrote in erlang). In my opinion, ML and its sons, erlang are the future.

MPNDS

[Anonymous Coward]

I smell a very specific kind of brain damage.
Maybe you should find others like you and start a support group for MPNDS --- Memory Pointer Neuron Deletion Syndrome!

Re:Best Language to Learn Multithreaded Programmin

[barnacle]

well qore ( http://qoretechnologies.com/qore ) was designed for multi-threaded programming, but it does so in a more "classical" way, meaning that it offers easy and safe access to shared data, where global variables are shared between threads and everything else is thread-local more or less. It has thread synchronization primitives, deadlock detection, etc and was designed for interfacing and logic embedding. It also has a strong focus on SMP scalability where a significant amount of time was spent to reduce the amount of cache invalidations (which can cause a big performance hit on SMP machines); so to my knowledge it is unique in this respect - being a dynamically-typed scripting language with such a focus on threading, SMP scalability, and logic embedding.

I describe it as a cross between perl and java, but being small it doesn't have the huge APIs and class libraries that those languages have.

However the new version (still in svn) has a QT module for GUI programming and a documented and stable API and ABI...

It's got some other cool features, like perl5 regex support, easy XML and JSON serialization, HTTP and other socket and socket-based protocol classes, many database drivers and some cool features for transaction management and even transparent per-thread datasource allocation with the DatasourcePool class, and more...

check it out if you're interested!

Sounds familiar...

[Sunsetbeach]

Now you sound just like my father...

Definitely Haskell

[Peaker]

I spent the last week or so finally going ahead and learning Haskell, and I am now very sad that I took so long to start.

Haskell is an amazingly enlightening language. When you approach it, like I did, you are likely to hit some overly-academic descriptions of its features, which are extremely hard to understand. Don't let this discourage you, Haskell can be learned without getting a PhD in mathematics.

I recommend Yet Another Haskell Tutorial as a more down-to-earth explanation of what's going on in there.

I find it far more enlightening than Lisp, and that it is quite amazing what a powerful world was built with such simple primitives.

Another note is that most languages (even C and Lisp) are far more similar to one another than they are to Haskell, so even an experienced programmer will take longer to learn Haskell than just any new language.

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

[rolfwind]

A bit of a handholder, this book starts out basic but is really accesible for the beginning programmer (or someone just trying to wrap their head around lisp never having used a Functional language):

http://www.cs.cmu.edu/~dst/LispBook/index.html

Flaming Thunder

[David Parker]

I would recommend Flaming Thunder, at http://www.flamingthunder.com/

Some of Flaming Thunder's features:

• Interval arithmetic.
• Number theoretic transforms for O(nlog(n)) multiplication of big numbers.
• Easy CGI scripting for website development.
• Supports 32- and 64-bit platforms.
• Cross-compiles for FreeBSD, Linux, Mac OS X (Intel-based) and Windows.
• Programmed entirely in assembly language.
• Takes less than 140K of disk space.
• Easy enough for elementary school students, the program to write "Hello world!" is: Write "Hello world!".

Flaming Thunder is the only language in the world that I know of that has built-in support for CGI scripting and that generates compiled CGIs. Plus, you can cross-compile the CGI scripts for your Linux server on a Windows or Mac, then ftp up the compiled CGIs.

Flaming Thunder is new enough that early adopters can not only learn a new language, but can actually influence the development of the language.

Sorta depends..

[Evil Kerek]

I think the answer to this really depends on whether you are just expanding your horizons (I'm very curious about ruby) or do you need to make a living (if it's windows, your better off learning a .NET language like C#).

I mean..scala? I've never heard of it but I am a bit busy with my clients (doing all sorts of work in C# - that is one very cool thing about it - works great in web or apps) That said, I think I will go check it out.

EK

Haskell

[master_p]

The very top of programming language technology, as we speak, is Haskell. You'll understand a lot more the other languages if you learn it, and you will be disappointed by the lameness of the other languages when you go back to them.

asp, perl, python

[Anonymous Coward]

perl is good to know... python is used as a language in a lot of game engines and 3d apps as well as in other places. asp is ok to know for microsoft junk... but I wouldn't focus solely on it since it's likely to dissappear just like com before it, visual basic when it changed massively, and like .net likely will in the not so distant future. Microsoft centric languages tend to dissappear or become obsolete every time a new OS comes out, mainly to increase sales...

How about something useful?

[GerryHattrick]

I wish I'd kept up-to-date with programming over the last 40 years. But I got too busy managing something or other. Now I can see what's really needed for human systems is a 'rule engine' (with a friendly UI, and superb net-interoperability). Sure, someone has to do the machine code, but the **user** needs something truly high-level. Object orientation comes close, but I can't see how the ever-adapting 'rules' fit in (that's real-world rules, like contractual terms and multi-factor conditional branches). 'JUDE' comes close, but seems to miss a real-world interface and perhaps compilation. This insight can hardly be a novelty - who's got one, and is it open-source?

new languages F# and JavaFX

[peter303]

I am not recommending for commerical reasons. But because they are fairly new they a new mix of software ideas.
F# is a functional language from MicroSoft Research (not to be confused with MicroSoft). It is along the line sof APL and LISP.
JavaFX is Java-like scripting language entirely integrated into Java and their JVM.

What Programming Languages Should You Learn Next?

[Quid Est Veritas]

If a programmer asks himself this question, perhaps it's time to consider a "pattern language" ... :-) For programming languages authors: could "Esperanto" be a hint?! Or simply a look to the evolution of the English language, or it's predecessor - the Latin language? ;-)

C++, Java first?

[sgt scrub]

I went with pascal, fortran, cobol, c, and asm. Was I supposed to learn c++ and java? I mean, I can see Perl but Java?

Using Matlab mixed with C

[syn1kk]

Lots of times I want to do some signal processing or plotting or visualize what I am working on ... but I don't have a convenient way to visualize the data I am processing. I found out recently that you can move your data from C to Matlab and then I can plot the data and actually visualize what I am working on .

What a Load of crap that is stuck in current Realm

[itsybitsy]

What a load of well reasoned crap.

Of course which language matters. Sure many are pretty much the same. Sure it helps to know various paradigms of programming. It always matters which language you code in. It always matters which methodology you perform analysis, design and codding in.

In the simple cases almost all languages are the same, especially within that particular language's paradigm and the group of languages that are similar.

It always matters to the results what language you use.

Sure I can code successfully in almost any programming language, given a month or two of learning curve to grok it's library and weird syntax, or bizarre paradigm; but do I want to? Only if it makes me wealthy doing so. Otherwise, in the general case it does matter to me what language I use.

In fact no one language meets my needs for the systems that I envision. Thus a new language is being born that stands upon the shoulders of giants. In fact I'd rather not create a language at all but that's the nature of computing when you push the limits beyond what others so boringly call the mainstream cutting edge.

One dimensional text based languages are out. New environment based programming paradigms are in. Languages that use text are out; they are so old. Sure the new language under construction will use text as one form of representing computer programs, but it's really only meant for the program rewriting system not for human consumption; at least it's not really meant for the vast majority of programmers, just an automatic programming system to store it's programs and data in an efficient manner that can be read by humans as in the rare cases where it's needed - such as during the bootstrapping of this new system. Once there is enough built up the text based representation can be jettisoned as an artifact of the past. Video game interfaces are the wave of programming in the future - text is just so old.

As two famous advertisers like to say: "Just Do IT! Think Different!".

So while your arguments are well reasoned for the current paradigms of languages, look out and catach the wave of the future or get crushed by the next generation of interactive systems that self program while you use them.

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

[Serious Callers Only]

Well, I don't know, I'm half way through, never having used LISP before, and it seems like a nice introduction to me - surely it's best to start with the stuff that makes it worth learning? After all much of the whole point of learning another language is to absorb the culture which comes with it. Haven't read the other book you're recommending though so will take a look.

Re:Best Language to Learn Multithreaded Programmin

[Anonymous Coward]

The problem with using purely functional programming techniques for concurrency is that you must constrain the topology of your concurrent computation to that of a tree. No cycles, no sideways references allowed, or you have to work out a synchronization mechanism, and none are known that are free from side-effects.

It's a difficult problem, which is why lots of research focuses on lock-free synchronization and result-sharing mechanisms for functional languages. Much of the research focuses on whether duplicate computation is generally more efficient than any sort of wait-based rendezvous.

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

[ShakaUVM]

Most schemes offer unhygenic macros these days alongside the hygenic ones.

I don't know about straight C, but there's OpenC++ for writing syntactic transforms to C++, and OpenJava which does the same for Java. Not sure how up to date they are these days. Thing is, all the extra syntax they have to support makes lisp and scheme macros look simple.
There's bolt-on macros for C that I've seen people use before. You essentially feed your .c files through the macro processor before running gcc on it, and it works reasonably well.

I think it was mainly used in scientific codes when the number of dimensions of an array weren't known, and people didn't want to write N copies of the same function. You'd pass the dimension in at compile-time, and it would spit out the code for that dimensionality.

Kind of ugly, but C doesn't handle it very well otherwise.

Keep yourself employed...

[humdinger70]

Learn. COBOL. Now...

IBM mainframes aren't going away.

You'll never be unemployed.

Besides, somebody has to be around to translate or fix old legacy code to these new-fangled languages (some of which will fall into disuse sooner than you might expect).

Re:Best Language to Learn Multithreaded Programmin

[piojo]

The problem with using purely functional programming techniques for concurrency is that you must constrain the topology of your concurrent computation to that of a tree. No cycles, no sideways references allowed, or you have to work out a synchronization mechanism, and none are known that are free from side-effects. Interesting... that's true.

LBA, maybe. Turing, no.

[tepples]

The Z80 assembler is turing complete. I don't see how. A Turing machine has unbounded memory, and every Z80-based machine I know of has less than 16 MB even with bank switching. LBA, maybe. Turing, no.

Judging ugly ducklings

[MarkusQ]

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.

There's a reason for that. Erlang is designed for writing robust meshes of tightly interacting processes, and supports things such as on-the-fly code upgrades (0 down time!). That doesn't mesh well with the idea of producing an "executable" file. But, when you come to think about it, what does these days? C might be your best answer, but even there you're more likely to end up with a slew of files that need to be installed for any but the most trivial applications.

Then it's excruciatingly slow.

I have that problem for the first day or so any time I switch paradigms. Functional programing is different in a lot of subtle ways, and things that would have been the obvious best way to approach a problem in Ruby (to choose another language I like a lot) simply aren't a good idea in erlang. And visa versa. Using runtime reflection to modify classes on the fly can do amazing things in Ruby, but it's a borderline nonsensical trick to try in erlang. Conversely, launching a bazillion threads diving down tail-recursive rabbit holes would quickly bring Ruby to it's knees, and often works great in erlang.

Then it has virtually no useful libraries.

It has more than you might realize in part because they tend to be called "applications" instead of libraries (probably as a consequence of the "everything is a service" philosophy). You don't think so much in terms of calling a library as requesting a service which is provided by an application.

In other words I couldn't figure out what to do with it

So here's an interesting idea to try, in case you're interested in giving it another shot: how about a highly parallel spam filter? Something that runs on a mail server, vets messages as they come it, and has the following properties:

• Messages that take a long time to scan don't hold up messages that arrive later but can be decided quickly.
• All the test suites proceed in parallel, and as soon as a determination can be made one way or another (spam/ham) the unfinished tests are abandoned.
• New tests / test suites can be added without taking the scanner down for even a fraction of a second, and existing tests can be updated or removed the same way.

Try it in erlang, and then try it in java or something, and I think you'll start to see the value of languages like erlang.

--MarkusQ

Re:Judging ugly ducklings

[dargaud]

Thanks for the detailed answer. I wasn't dissing Erlang, I think it's really cool that there are 'highly different' languages around, and I also think that highly parallel languages are the thing of the future, hence the reason why I gave it a try. But I've been programming 'C'-like for almost 30 years and old habits die hard (I could never understand how to do even one line of Prolog for instance).

I tried Erlang it 2~3 years ago, so it may have evolved since then. My remark about the lack of executable was more in the sense of: is it possible to give an Erlang application to someone else and have them run simply ? At the time I couldn't figure out how to do that without having to install the whole development toolkit. Either a statically linked executable, or an installer would do, otherwise it remains a toy/research tool. But, hey, Java requires a virtual machine too and it even managed to succeed (something that surprises me a lot).

Side question: are there any commercial or open-source application in Erlang I may find inspiration from ? (yes, I know about the telephone switches, but I can hardly run that on my PC). Anyway, good luck to Erlang and I hope it crushes Perl C;-)

Re:Judging ugly ducklings

[David Parker]

> That doesn't mesh well with the idea of producing an "executable" file. But, when you come to think about it, what does these days?

Flaming Thunder.

The Flaming Thunder cross-compiler produces static executables for Windows, Mac (Intel-based), Linux and FreeBSD. Both 32- and 64-bit versions. It can produce all of them at once using a single command:

ft file myprogram.ft target all

You'll get 8 static executables out:

myprogram-w32.exe
myprogram-w64.exe
myprogram-m32
myprogram-m64
myprogram-l32
myprogram-l64
myprogram-f32
myprogram-f64

For example, you can write a CGI program under Window or Mac OS X, compile it for Linux 32, and then ftp the small, fast, agile static executable up to your server:

ft file quickandfast.ft output quickandfast.cgi target linux32

The Flaming Thunder executables are ROMable: they contain no variable data sections. All variable data is allocated dynamically and initialized from constant data stored in the executable.

Thank you!

[MarkusQ]

That doesn't mesh well with the idea of producing an "executable" file. But, when you come to think about it, what does these days?

Flaming Thunder.

Thank you!

I love it when someone comes up with a good solid answer to what I'd thought was a rhetorical question.

--MarkusQ

My list

[psykocrime]

My list wish-list of "languages to learn next" looks something like this, in no specific order:

Haskell

  Ruby

  Erlang

  R

  Prolog

  Groovy

  Scala

  Lua

  Lisp

  Smalltalk

  Scheme

  Ocaml
 

Ruby and Erlang are the two I've spent the most time with so far. I like Ruby enough so far, that I've decided to write the initial
batch of install scripts for OpenQabal in Ruby.

Outside of that wish-list, I also harbor some vague hope of one day finding time to dabble with Forth, Fortran, Perl, and maybe Dylan.

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

[hatrisc]

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.

I'd say that Scheme macros are far more powerful (especially in r6rs) than CL macros for the reasons of both hygiene and referential transparency.

programming languages

[Corson]

if you work for somebody else, learn whatever language they use. if you work for yourself, then stick with fortran if you are an engineer, c if you are a systems programmer, and delphi or visual basic if you are a scientist.