There were dozens more, some I can't even remember the name of, but I can safely say that I never met a programming language I didn't like (with the possible exception of RBASE 5000). Each language seemed to introduce a new idea or way of thinking. It wasn't just learning the language, it was also learning the philosophy behind the language.
But none of these language I would describe as "perfect". Each one had something missing, or handled something in a peculiar way, or the syntax was just a bit too heavy. So I kept searching, and eventually concluded that there was no such thing as a "perfect" language.
Instead I found each language was just another tool in my armory. Each had its strengths and its weaknesses, and the right language to use depended very much on what you were using it for. Of course the problem is, everywhere I went, I got "We don't use that language here, we use...". And in a way that was fine, the right language as they perceived it, was the language that meant that didn't have to learn another language.
Never the less, for a long time there, if you asked what my favourite language was, I usually answered with the question "It depends on the purpose?". It might be "C/C++" for writing games or doing language experimentation, Pascal for "education", and for business programming it was the 4th generation language "Powerhouse".
My first serious programming job was in Powerhouse by Cognos. Technically this involved four languages. I think they were Quiz for reports, Quick for Screens, QTP for batch, and I think QDD for schema. There was also a QDesign in there somewhere as well, possibly a screen compiler or something. Each of these languages were similar in many respects, but each was tailored for its specific purpose. The speed by which I could develop solutions with this tool was just incredible, and the Quiz approach to building queries was so superior to SQL.
Alas, the main problem with Powerhouse was really Hewlett Packard's Image, a rather limiting "network database" (network as in hierarchical/network/relational databases) where everything was hashed indexes or linked lists and never a B-Tree in sight.
While I did encounter some other 4Gls, and some XBase related tools that came close, I don't think I found myself nearing the productivity of Powerhouse again until I was given a copy of Access. By then the world had changed from character based mainframes to GUI mid range and the development world was faced with new challenges.
And new languages were appearing to solve this problem. Coming off the mainframes I encountered Visual Basic, then Delphi, then C++ Builder (and Powerbuilder was in there somewhere too).
At the same time Java came along seeming to try and solve a completely different type of problem. I was introduced to Java as "the language that will see the death of C++". Now I've been in this game long enough to realise now that anyone who tries to predict the death of a language is on the wrong side of the "prophecy" to know what they are talking about. I have to hide my COBOL expertise to avoid getting stuck on a job with it.
Java itself had a pretty shaky start, with issues of performance, and an industry that was just coming to terms with object orientated languages, and hadn't quite worked out what object orientated design was all about.
But Java rather quickly became one of my favourite languages and it evolved and improved and became a serious contender for business programming. But I kept coming up against people who held onto "We only use C++ here because we are concerned about performance".
Now I love C++, it's one of my all time favourite languages. But save for a few ISAPI filters, I haven't used it in anger in any business roll for many years now.
Besides the obvious offense of the "we are concerned about performance" implying the rest of us are not, this statement was just so dated and wrong. First, they thought that the only performance factor they had to worry about was CPU speed and possibly memory. But CPU speed at that time was so fast that most desktops were wasting millions of CPU cycles per second, where as the key resource issue for most development projects was developer hours, not cpu cycles. Java basically allowed you to get more bang from your developer buck than C++, not just in the initial writing but also in the subsequent maintenance. Second, Java's performance had radically improved from the early days. And third, if they were really serious about that type of performance then they should have been coding in assembler. (Just disassemble any C++ program to see what I mean about wasted cycles).
At the end of the day, you might be able to write a C++ program that runs faster than say Visual Basic 6, but the Visual Basic 6 program runs fast enough.
If your still not convinced, go and get Battle of Endor. It's one of my favourite computer games and it's written in Visual Basic 6 using Truespace. At its time it was a visually splendid game that runs well on not very demanding software. It's graphics are a little dated by today's standards but it was written a very long time ago (in a galaxy far far away) . Someone is probably saying that Truespace is doing all the grunt work, but that's not entirely correct, since Truespace can handle the graphics but not the AI and other factors. Further I doubt that the grunt part of Truespace is written in C or C++. Most likely it will be inline or linked assembly routines.
Back to the performance point. This is an important theme in the evolution of programming languages. The early languages (machine code, assembler) were concerned around finding a syntax that could be easily parsed and tell the computer exactly what to do. This was fine because computers back then were so slow that compilation took a long time, so the easier the language to parse and compile the better, and the control over every execution allowed for at the least the potential for very efficient code.
As computing power increased, we started to use abstractions in computing language, such as variables, records and objects rather than data addresses, and functions and methods rather than program addresses. These abstractions were closer to how we humans thought and less like how the computer worked. A single statement in the programming language could represent a whole chunk of assembler code, making the language more productive.
I had hoped that as computing power increased that programming language woulds have changed to look more like how we humans think and speak, and less like how the computer works. I can't say that's actually happened, we have natural language parsing, but as it turns out, most of our "natural" languages are not particularly efficient for communication. Ambiguity, consistency and context make this a very challenging space, let alone just understanding what a person just said. I think one day we will get to the point where we just speak English to the computer, but for now, that still seems a long way off.
Instead we are seeing a resurgence in declarative languages (at least in the .Net space). This is partly because some of these languages may support parallelism more efficiently, but there is also the argument that these languages require you to think more about defining the problem you want to solve, and less about how to solve it.
Some also have very powerful syntax's that save an awful lot in very little code.
This is where I start to wonder about how successful these will be. After all in C++ you can say an awful lot in a single line of code, but the message was sometimes very hard to follow. Even with their higher order, some of these languages can have a difficult syntax to read, saying a hell of a lot in a single line. It's like reading a single but very long sentence and forgetting how it started by the time you got to the end.
And sometimes, it's just easier to break a complex problem down into it's imperative steps and solve it that way, than it is to describe the whole problem in one go.
Still, I've been enjoying learning Haskell and F#. I'm a little hesitant to commit a project to them at this time but I'm certainly going to keep playing with them (for a while at least).
On another front we have the the "Domain Specific Languages", which in the Windows inevitably brings us around to Oslo. All I'll say on that front for the moment is "Mmmmm..." If the trial version of Oslo didn't crash so much, and there was a little more documentation on this front I'd be more interested. I'll guess I have to wait for this to mature more.
I've certainly used DSLs in the past to solve what I'd describe as particularly complex configuration problems such as defining a screen's layout or defining a set of business rules to be parsed at run time. But these have always been written in notepad or something even less sophisticated. To define a DSL in such a way as to get full syntax support in your IDE would be very nice.
Also, I think some of these so called XML based languages, such as BEPL and XAML, deserve a good human readable DSL rather than have to read and write XML. XML is something the computer can work with OK, and maybe tolerable for a human for simple data, but as a programming medium, yuck.
In fact, thinking of DSLs, I'm brought back to think about the Powerhouse set of languages, each similar but unique to help solve their specific problem.
But instead of a database orientated 4GL language like Powerhous, what I'd really like is an object orientated 4GL like... (well maybe I should write one). One DSL that handles the UI, be it thick client, web or phone, another DSL that handles services, integration and workflow, one to define the objects and schema, and finally one for handling the data storage.
The language I use most today is C#, both for Windows and Linux (see Mono). Why C# rather than Java? Well, while Java has had solid support in the development and evolution of supporting frameworks and libraries (though I think it lost it's way a little in the J2EE space), the language and JVM has not. I keep feeling the language itself is now trying to keep up with C#, but the lack of focus and invigoration for the language has declined. I'm really worried that we will end up with two or three Java's now, one from IBM and one from Oracle and one possibly from acadamia. Let's hope Java 7 proves me wrong.
On the other hand, C#, which was really just Java+1 from the start, has gone from strength to strength, with generics, LINQ and now dynamic support all being introduced in it's very short life. LINQ gives C# a strong declarative aspect without having to learn a whole new language (if you avoid the new LINQ syntax that is). In fact the "yield" keyword, which predates LINQ but is obviously a prerequisite, is in itself a strong declarative solution to a common problem.
Dynamic support and languages I'm not so frilled with. I prefer explicit declaration. I'm all for less noise in a language, and type inference is ok in certain circumstances, but I like type safeness after too many bloodied noses from not having it.
That said, I started out hating Javascript, but once I realised what I really hated was just the buggy inconsistent DHTML models and a lot of poorly written pages, I found the language itself is incredibly powerful and clever.
Development of programming languages seems just as exciting today as it was when I started in IT. Be it new languages emerging, or older languages being reinvigorated. It is unlikely that the languages I use today will be the same set of languages I use in five or ten years time.
I no longer expect to ever find the perfect language, and today, even if you ask me what my favourite language is, I think the answer will still be "It depends..."
