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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[hoggoth]

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

Wintermute, is that you?

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

[geekoid]

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

Re:Wrong Question

[abigor]

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

Re:Wrong Question

[dargaud]

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

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

[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

[gnalre]

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

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

[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!

10100001010

[midianus]

01000101012

Love the 'iPhone' tag

[Naughty Bob]

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

no Ps

[whtmarker]

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

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?

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

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

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

[Alpha830RulZ]

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

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

[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

[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

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

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.

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.

Re:What Languages?

[Chris Mattern]

FORTH learn to want I would why?

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

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

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

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

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

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

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

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.

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

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

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<

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

[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: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:What Languages?

[kat_skan]

Because what Yoda would use is it.

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

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.

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.

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.

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?

Re:Verilog

[s800]

FPGA != CPU

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

Screw them all.

[God of Lemmings]

Write your own language... it's certainly more educational.

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

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.

MATLAB

[Thelasko]

It's great for handling matrices, vectors, plotting and umm... well, that's all it's good for.

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

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

Brainfuck

[megaditto]

Plus it will make your resume stand out.

http://en.wikipedia.org/wiki/Brainfuck

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

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:Going from C to others is a matter of right boo

[grammar fascist]

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

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

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

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

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

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

Lots of reasons to start out with Perl

[PerlPunk]

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

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

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

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

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

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

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

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

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

[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

[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

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

MMIX

[plstbb]

I would recommend http://www-cs-faculty.stanford.edu/~knuth/mmix.html

A great way to train your brain.

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.

Re:Verilog

[mrchaotica]

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

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

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

Arc

[dido]

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

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