Slashdot Mirror

Rust was originally written in C, then a Rust compiler was written in C++. If the creators of Rust know about what makes a good programming language, and they chose to write Rust in C ...

The original Rust compiler was written in OCaml. There was never an official C or C++ version of the front end. The backend of the self-hosted compiler is LLVM, written in C++.

Now most recently they have the front half of a Rust compiler written in Rust.

Rust has been self-hosting since about 2011, which is not "most recently" in my book. There is an independent front end written in C++, which generates LLVM IR and still needs the LLVM backend. It is also incomplete, since it lacks the borrow checker.

It's time that we start writing libraries like these in OCaml. Audio processing libraries, for instance, need to be quite performant. So C has typically been used. But now we run into problems like this, where the insecurity of C becomes a serious issue.

The solution is likely the use of OCaml. With OCaml, we get a native code compiler that generates very performant code. But best of all, we get a far greater degree of safety. OCaml efficient memory management takes care of the dangerous C memory management that leads to vulnerabilities like these found with FLAC.

We already have a typesafe OO language: Ocaml. You can read more about it at ocaml.org.

Those of us in the know have been using it for years for very significant applications. Besides offering native compilation on most popular UNIX platforms and Windows, it also offers a bytecode interpreter. The performance of both is superb.

Good thinking, IBM. Now, let's get SML/NJ, Haskell, and O'Caml ported to these things.

"Why", you may wonder, but the answer is simple: Referential transparency or any kind of confinement of side-effects makes for easy parallelisation, which is what these Cell thingies are supposed to rock at.

This might be the one thing that will put FP back into the undergraduate curriculum.

-- Christoph

I don't know of anything exactly the same, but the Perl culture is full of fun playthings centered on enjoyment of the language for its own sake. One might even argue that much of the development process of Perl 6 itself has this flavor, with Apocalypses and Exegeses that partially are language specifications, but are really more like essays or articles on programming in Perl and how positive it is. That's to say the least of things like the Perl advent calendar, which are much more like the Python challenge.

Having said that, I think that there probably should be something more for Perl along the lines of a programming challenge in particular, rather than just fun dialogue.

The one language that I think is in dire need of this sort of stuff, more than Perl or Python, is Ocaml. It's a powerful language with a dedicated fan base, who enjoy programming in it for its own sake, but lacks the sort of cohesive community that other languages have. A programming challenge sort of thing might appeal to those who might be interested in OCaml.

The Caml language (pronounce "Camel") is missing.
Caml is a programming language, easy to learn, easy to use, and yet amazingly powerful.
It is developed and distributed by INRIA (the main French research institute for computer science), since 1984. It is freely available for Unix, PC or Macintosh.
There exist two flavors of Caml: Caml Light and Objective Caml. Caml Light is merely a subset of Objective Caml, especially designed for teaching and learning the art of programming. In addition to the Caml Light's core language, Objective Caml features a powerful modules system, full support to object-oriented paradigm, and an optimizing compiler.
More information here.

When I get into my evil mindset (usually after a long and frustrating day), I'm tempted to learn (I have a book on Lisp around here somewhere...) one of those rarer languages (ie, lisp, Eiffel, o'caml) , and replace certain mission critical scripts with ones written in them.

let hello foo = "Hello, " ^ foo

let gimme_a_one x = 1;;

I'll suggest here that proper tools are an important way to prevent bugs and make auditing (reasoning about) software easier. And C is probably not a proper tool for creating secure software. Oh sure, if you're a super human coder and stick to a rigorously defined coding standard and have a team of other super human coders auditing the code with a fine tooth comb, you can produce C programs with fewer bugs than normal. But why not let the machines do the work for us? Try a language like O'Caml, or Haskell, you might like it! Besides having fewer lines of code to audit, you'll pretty much eliminate buffer overflows, fence post errors, interger overflows, etc.

Computer languages can be made to resemble human language (English) as much as possible. They can be made to reflect the machine as much as possible (assembler) and they can be made to resemble a drunken sailor with Tourette's syndrome (Pearl).

However, I wonder how functional languages will do. They try to approximate math as much as possible. OCaml Won top 3 spots from '98 till '02 in a contest called ICFP. Although OCaml is both functional and has object-oriented features.

Are functional languages the way of the future? Better brush up on my math. Another functional language feature I heard of was that they can be made multi-threaded automatically, with the runtime environment spreading the execution of the program across multiple threads/processors.

Maybe someone should tell Sony about functional languages as a way for game programmers to handle their Cell PS3 processors. They go the - slower individual chips but more of them working at the same time - route.

If all software was free, why would anyone bother developing it?

Gee, I can't think of anyone who would develop software without getting paid for it...

But seriously, there are several reasons people would write software whose price is 0:

• People want better software to do $WHATEVER (for values of $WHATEVER that make money, which is most of them), so they write it
• People want to get a job as a programmer so they write a software package to prove they aren't total code monkeys
• People like fame; they like being admired and appreciated
• An industry consortium decides they need an open, standard, free way to do $WHATEVER
• Some people have a political motivation to undermine proprietary software (we may not have that same motivation; but it is a real driving force for some people)
• Some people like to help others (ditto)
• Your company might want to make your product universally (or nearly so) used in order to be able to charge money for training, certification, etc.
• I mentioned 15 high-profile products that are competitive with best-of-breed and are available for $0 (and not all of it is Free as in speech). All of them were written because one of the above bullet points (or one I forgot) applied.

There are lots of motivations for people's actions besides money.

Nothing new. It's done better in functional languages like OCaml which ensure type safety without even having to explicitly declare types.

O'Caml has a replay debugger. You can run your program in the debugger until it crashes, then step backwards through the code to see what was happening before it crashed.

Very handy, IMHO, although the O'Caml debugger sucks in other ways. (E.g. no watch conditions.)

The OCaml variant of the very strongly typed languages of the ML family is not only extremely elegant, like Lisp and Scheme, but is extremely fast.

Both Objective Caml and SML (using, say MLton) can be compiled to ELF executables for the x86.

Anyway, native-code compilation versus bytecode compilation isn't a property of a language, it's a property of an implementation. The GNU Compiler for Java exists.

These were pretty arbitrary examples: there are plenty of options for native code executables besides C/C++.

I don't mean to slight D, though!

Maybe not Java, but someone should start an OS project with something like OCaml. You get most of the speed of something like C, with far fewer bugs. Oh, and there's no reason you can't compile your Java.

But what should it be, a whole new library based
on the best from Gnome,
Kde,
Gnustep
Enlightenment Foundation Libraries
and Tao elate
implimentet in Ocaml ??

Or better yet, learn Ocaml. Up with the best of lisp compilers in terms of speed. Has all the stuff to teach about functional programming, but still allows for iterative programming. Makes clear distinction between mutable data and immutable data.

You could complain about C all day, the problem is, it's the best thing we have right now.
Hardly.

One of the problem with modern languages is, you can't write an operating system in them.
Sure you can, with little more ASM code than is required for a C-based operating system. Heck, lots of OSs have been written in things like Lisp. Actually, C is a terrible language for writing operating systems. Because its not safe, you have to have an MMU to protect programs from each other. This sucks for performance. Not only do you have the hit of memory protection, but you have to have bounderies between userspace and kernelspace, and between programs. That's why it takes 600(!) clock cycles on my P4 to do something trivially simple like gettimeofday()! If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. See this SF project for an OS written in a safe language.

One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code.
I don't know what's the current fetish with VMs, but most of the really advanced languages (Lisp, ML) compile to well-optimized native code. Look at the recent comp.lang.lisp thread where they ported Almabench to CMUCL, and got within a few percent the performance of C.

Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable.
Common Lisp
Another Common Lisp
Ocaml
Scheme
Dylan
Another Dylan

We have lots of languages that are much more powerful than C (hell, they're much more powerful than Java/C#), safer than C, and very close in performance. It is merely a failure of programmers and the software industry that we have not been able to utilize them.

C is the BEST? By what twisted calculus could any rational person say that? There is NO problem domain in which C is ever the best choice for doing ANYTHING -- unless said problem domain is, of course, writing C programs. Name me ONE thing that C is better at, and I can provide you with a technology demonstrably superior, without even breaking a sweat.

Anybody in this day and age who chooses to write any program in C anywhere is misguided at best, more likely a dismal backwards-looking sadistic fuckwit who thinks that their own suffering at the hands of '70s technology is somehow the norm. To these sad sacks, I say, welcome to 1980!.

'jfb

Because it's faster and doesn't suck up a lot of memory.

If you want to see a compiler that can produce tighter, smaller code than most C compilers, from a supposedly inefficient functional source language, all the while providing type and bounds safety, take a look at OCAML.

It wasn't until recently that John Carmack switched to writting in C++ instead of C for his new DooM ]|[ engine.

2a. Pure functional (Haskell/ML/Pure lambda calculus)

Small nit (well, not so small if you're in the functional programming camp). ML (SML, O'Caml etc), are impure functional languages. I.e. they support assignement and mutable data (O'Caml is even object oriented). Haskell is about the only non-strict purely functional language around these days (though Miranda hasn't exactly died).

If you're interested, check out O'Caml, which has a nice compiler producing code on par with 'C' for some benchmarks. Lots of good documentation (even a book) on line.

Then, with more and more languages, especially ones with VMs, you get further and further away from the hardware. The end result: you lose performance. It does more and more for you, but at the expense of real optimizations, the kind that only you can do.

Now the zealots will come out and say, "Language X is better than language Y, see!" To me this argument is boring. I tend to use the appropriate tool for the job. So:

• Python for scripts, prototypes, proofs of concept, or components where performance generally is not an issue.
• For desktop apps, Visual Basic (yep, most IT apps are in VB). There is no justifiable reason for an IT department group to write a sales force reporting system in C++! If you want C++, go get a job at a software company. Stop wasting money and time making yourself feel like a hotshot. [I'd consider Kylix here if it was based on Basic. Why? Because honestly, Pascal is just about dead, and Basic is the king of the simple app. Let's just live with it and move on. I do want a cross-platform VB . . . ]
• For web apps, well, I stick around PHP/ASP.NET. Why? Portability! And moreover, the sticking point in a web-based app is not the UI layer; it's usually the underlying data extraction and formatting. Don't waste your time with lower level languages there. IMHO it's just not worth it. JSP and Java stuff, yuck! Too much time for too little bang.
• Java/C# (also consider mono/LISP for most production apps. Why? Portability! I want no vendor holding me by the balls. I want platform independence on the back end, and these are the few ways to achieve it. I'd include Haskell/OCAML here when appropriate. Perl? I'm loathe to use Perl as production, considering most Perl code cannot be understood 2 weeks after it's written. I'd rather take the hit in performance and be able to pass the code to someone else later.
• C++/C for components--just components--where performance is at an absolute premium or there exists some critical library that only has this kind of interface. But this step has to be justified by the team, with considerable explanation why a different architecture could not suffice. Otherwise, the team could waste time checking for dangling pointers when instead it could be doing other things, like finishing up other projects.
• Assembly? Only when there is not a C complier around. Embedded stuff. Nowadays, you just do not have the time to play.

Yes, my teams use many languages, but they also put their effort to where they get the biggest bang for the buck. And in any business approach, that's the key goal. You don't see carpenters use saws to hammer in nails or drive screws. Wise up!

I'm not talking about Python. Python is positioned as a scripting language, and hence doesn't have a powerful compilation infrastructure. Although, Pysco does some very cool dynamic optimizations for Python.

In contrast, there are many high-level languages like Common Lisp, Dylan, Scheme, ML, Ocaml, etc, that have very powerful native compilers. They do optimizations that C/C++ compilers simply cannot do, because of the low-level C memory model. Literally decades of research has gone into making these compilers, and they have optimizations that (while not quite magical) are very impressive.

Variously:

- There are type-inference optimizations that eliminate the overhead of dynamic dispatch.
- There are heap-analysis optimizations that stack-allocate objects whenever possible, to avoid heap allocation.
- There are analysis that avoid heap-allocating closures.
- There are analysis that eliminate type checking and array bounds checking.
- There are analysis that perform large-scale optimization of class heirarchies, to eliminate the over head of OOP.
- There are memory allocation analysis that reduce the overhead of garbage collection (region inference).
- They do method specialization, allowing the C++ template advantage of generic functions optimized for a given type, without actually having to deal with explicit type parameters.

Some useful pointers:

Apple Dylan Wiki
Lisp vs Java vs C/C++ performane
Bigloo Scheme Compiler
Gwydion Dylan compiler
CMU Common Lisp Compiler
UW Vortex Compiler
MLKit ML Compiler
Ocaml Compiler

I expect more hype coming to Python, especially once it gets some EJB-like "Twisted" framework. Or Erlang with its enterprise-quality EJB-like OTP framework.

I like the twisted framework; it's practically another language on top of Python. I've recently discovered another worthy language, O'Caml. It has some really neat idioms, and the native code compilation ability is nice. Unfortunately, it lacks much in the way of EJB type stuff. Still, I'm sure that an EJB-like system could be done well in O'Caml. Those languages are where I'd like to see more hype drifting, for one main reason: simplicity. They're more lightweight, and they carry less of the C/C++ baggage.

Code Generation is for people who don't understand or are too lazy for abstraction ...

Code generation is a practical, efficient tool for solving many problems where OO-style abstraction need not enter the picture. One such class of problems is building interfaces and glue code from external specifications.

A few years ago, I wrote a simple code generator that reads the SQL DDL for a large database and generates an object-based interface to the database. Client coders could then use the object-based interface to access the database. The advantages of this approach proved to be numerous:

• Single, authoritative reference specification. The object interface was always in sync with the reference, which for this project was the database schema.
• Richer compile-time error detection. The projection of the schema into the object interface was fully available to the type system so that many kinds of client errors could be caught at compile time, not run time.
• Reduced opportunity for errors between subsystem boundaries. Because the object-based interface was generated by machine from the actual database -- and not derived from some programmer's understanding of the database -- there were fewer opportunities for impedance mismatch across the boundaries of the application code and the database. (Studies of errors in complex projects have shown that errors are more common between subsystem boundaries, and so this benefit is important.)

But I cannot think of any case in an object-oriented language where it would be both less work and more maintainable to write a code generator than to just abstract away the parts that would be auto-generated.

• When the number of variables affecting the desired code characteristics is large enough to make hand-coding (at any level of abstraction) impractical. E.g., FFTW: "FFTW uses a code generator to produce highly-optimized routines for computing small transforms."
• When your code must conform to an external reference specification that changes rapidly enough to make hand coding (at any level of abstraction) impractical. (See my example above.)
• When the requirement for correctness is so stringent as to make hand-coding methods impractical, mandating code generation from a formal specification.
• When you must target an output language whose native abstraction capabilities are too crude to capture directly the degree of abstraction that is merited. Believe it or not, most popular OO languages fall into this category for many commonly occuring problems. Hence the popularity of design patterns. (Compare, e.g., with the abstraction capabilities of modern functional programming languages like Haskell and O'Caml.)

I've noticed that the home page is kind of slow. There's the original, old one at INRIA.

HTH

Ericsson employee or ex Ericsson employee?

I'm still there, but only a day a week. The rest of the week I'm at Chalmers Computer Science department, which is quite famous in functional programming circles. (That's not my field though; I'm doing computer security).

And while we're on the subject of functional programming with a practical bent, be sure to check out O'Caml as well. It has static typing with automatic type inference, what static typing should always be like.

Until today, both ML and Haskell had a common problem: a lack of commercial and real world interest in it and therefore a lack of real-world libraries and supporting frameworks. But now things are going to be changed.

First Ericson came with Erlang, an excelent essence of FP, LP, scripting and networking. Now M$ (I know - evil, but anyway) came with F# bringing OCaml to the real world saving from being forgotten somewhere in Inria.

What next? I think that would be Haskell, the language even more suprior to ML, with already OOP, Parallel and Cuncurrent extensions. Also I like its Functional-Logical dialect - Curry. But who will bring it to the real world? IBM?

Ocaml doesn't get nearly the attention it deserves. I'm especially surprised it hasn't taken off more in numerical computing (although it is fairly young). Functional, object-oriented, all those good things, with the speed of C/C++. Very compelling.

Go check it out if you haven't already. I'd really like to see ocaml be more widely used, especially over some copy from MS.

ocaml

First, you mix strongly typed languages with statically typed languages. Perl is stronlgy, but dynamically typed language, while C++ is weakly, but statically typed language. But even assuming you meant statically typed languages, your reasoning is flawed.

Well, that's close, but usual terminology is slightly different:

Strongly/weakly typed has to do with what types we consider equivalent. Strongly typed means that the type has to stem from the same definition, weakly typed that they have to be "compatible" e.g. have the same structure. Hence two new types that both derive from are not equivalent in a strongly typed language, while they are equivalent in a weakly typed language. Ada is the prototypical strongly typed language here. Also surprisingly C is also strongly typed, but only because of the twist that 'typedef' doesn't introduce a new type, but only a new name for an old type.

Static/dynamic is as you use it, i.e. has to do with whether the type of the program can be determined statically (at compile time) or dynamically (at runtime).

Now, what you call strong/weak is really type safe/type unsafe. I.e. can the execution of the program ignore the types or not. C.f. C where you even though you have strong static typing, it's also type unsafe, i.e. the running of the program can result in a silent type error, whereas in Scheme for example it cannot, all type errors will be found.

Speaking of types, myself I prefer languages that statically typed, and type safe (with polymorphism). The static types aren't really a problem if you use a language with a Hindley-Milner (like) typesystem, since it will automatically infer the types of all your expressions, meaning that you don't have to annotate the source with types unless you really want to. Such langages as Haskell and O'Caml meet these criteria.

Lisp has one of the best object-oriented paradigm implementation, Meta-Object Protocol among languages with both scripting and bytecompiling capabilities.

Scheme has been proved as a good language for GUI and configuration: GIMP, Sawfish, TeXmacs.

OCaml has all the power as Lips, just in syntax conviniect for many Java/C-poisoned brains to read faster. No wonder there are many real-world applications on it.

Haskell... I just love how it demonstrates that OOP is not everything (and even not enough) :)

Sun works for telecom industry - why not consider Erlang?

And don't ignore Mozart - it's multi-paradigm pradigm might be just what we all will thing as the best in 3-5 years.

The list is not complete, of course. And it's inspired by Functional Programming.

My main point here is: each of above languages, would it be in hands of Sun marketed instead of Java (with all that money invested to), would have quality of implementation much better than Java.

In fact, I am impressed how such poorly designed language as Java succeed so far on the market. It wouldn't without so much money behind. And without so many classes written by Sun to compensate the poor design of the core language itself.

Would Sun invest so much efforts and money to FP language then the result would be much better. Because quality is why FP matters.

OCAML is a very practical functional programming language with excellent compilers. A number of Linux utilities are written in it.

For interactive symbolic manipulation, Maxima is an excellent open-source alternative. For numerical applications, Numerical Python and its associated packages beat both Matlab and Mathematica in my opinion. For 3D visualization, you can get VTK, which also has Python bindings.

Maxima is also used occasionally as a rapid prototyping language, but it's proprietary and it has a lot of rough edges. You are probably better off using one of a number of open languages with similar features, like Scheme, OCAML, SML, Prolog, or Haskell.

Don't forget about C++, however. In many ways, C++ nowadays allows you to write numerical code more naturally than any of these other languages (yes, better than Matlab and Mathematica), it has by far the best libraries available for it, and it gives you excellent performance. And you can even do symbolic mathematics in C++, with the right libraries (though it's not interactive, of course).

For example, try Common Lisp, Objective Caml or Ada (not that high-level, but not the worst idea if you care about security).

It should be a crime to teach people C/C++.

High level languages like Ruby, Python, or even Java are strongly recommended for all new projects.

How about a high level, compiled language with static typing like Ocaml. More speed, more protection, and it's been officially certified as "The programming tool of choice for discriminating hackers".

Ocaml

The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue.

By the way, there is nothing wrong with high-level languages, au contraire. Just use those with efficient native-code compilers. (Objective C in its half-smalltalkness may be nice as well, but personally, I don't really like it.)

O'Reilly has a book available on-line, Developing Applications with O'Caml.

I am so glad to see this topic on Slashdot. I can't say how many times I have asked around with this question, only to see it neglected. I think the issue of whether or not FORTRAN is still kicking belies another, much deeper problem in the numeric computing community that this post touches on. I'm convinced that numeric computing is in quiet crisis at the moment.

FORTRAN is still kicking, very much so, for all of the reasons you enumerate: it has been the standard for so long that everyone uses it, it's widely available, and archaic code has stood the test of time. So in one sense, the answer is "Yes, FORTRAN is still kicking."

In another sense, though, the poster was asking whether or not they should learn FORTRAN. That I just don't know about. Maybe FORTRAN is still kicking. The question, though, is "Should it be?"

True, FORTRAN is fast, it's freely available, everyone knows it, and there's plenty of code available for it.

However, FORTRAN is entirely too archaic. I can't stand the syntax, which I find gratuitously convoluted and difficult to work with (GOTO jokes that apply to BASIC should be applied with equal regularity to FORTRAN). Some might praise FORTRAN for its procedural "simplicity", but I think it's just crude and inefficient. Newer versions of FORTRAN, such as 90, 95, and so forth, take care of these issues, but are irrelevant because practically no one uses them! It's almost as if FORTRAN 90+ exists solely for the purpose of rhetorical argument, to say "Yes, but newer versions solve those problems." It's a trick, because the newer versions are rarely used, undercutting all the benefits of longevity and standardization that F77 provides.

In the end, then, you have this dilemma: C/C++ provides the modern syntax, but lacks the numeric constructs of FORTRAN (native matrix notation, etc.). FORTRAN, on the other hand, is made for numeric computing, but undercuts itself by being nauseatingly convoluted.

Thus, the crisis. Numeric computing is missing a language. We have high-level languages like MATLAB, Octave, R, Maple, Mathematica, and so forth, and the extremely low-level FORTRAN, but nothing in between. True, you can do numeric computing in C++ (that's what I do), but that's sort of bastardized due to the lack of native numeric constructs. Java might work, and has its own benefits for numeric computing, but also it has its own problems. Modern FORTRAN looks good, but no one uses it.

So, in a sense, I don't think this guy should be asking "Should I learn FORTRAN?" We should all be asking ourselves "What the hell are we doing?" Is there a language that we could be using that would be better? Is it time to make a painful but necessary effort to just switch to, e.g., F95? Tacitly shun F77 and translate existing code into F95?

This is something that really bothers me a lot. I don't mean to sound complainy, but I really think there is a problem. There shouldn't be as much of a disconnect between MATLAB/R and C++/FORTRAN as there is; there should be something sitting in the middle.

Are there any other languages that look like serious rivals to FORTRAN that the numeric computing community should be switching to or evaluating? I've seen some suggestions here, like Ada, but are there others?

I for one am surprised that OCaml hasn't proliferated more in numeric computing, given its speed and functional-object-oriented nature. It would be nice to see native OCaml matrix libraries, for example.

So what about it? What else could this guy learn? What else could we all learn and teach in our CompSci 1024, Introduction to Numeric Computing course?

Though it's not (yet =) one of the "major" languages, but it's pretty awesome. Here are some things I've learned and resources I've discovered.

What is OCaml? In a sentence, "fast modern type-inferring functional programming language." But not only does it support the functional programming paradigm, but also imperative and object-oriented models. (These can be mixed in a single program.) OCaml is type-safe and garbage collected. (But even though it's garbage collected, it runs at speeds comparable to C and C++.)

Why use OCaml? Here are some good reasons:

• It's fast! It scores very high (second only to C) on Doug Bagley's computer language shootout
• Very compact code
• Interoperates very easily with C
• Was used by at least one of the top 3 entries in each ICFP Programming Contest between 1998 and 2001. Won 1st prize in 2000 and 1999.
• It's a functional programming language - you can use functions as arguments to other functions.
• It's garbage collected - you don't have to worry about cleaning up memory and can focus on the problem to solve.
• OCaml includes libraries for complex data structures, graphics, regular expressions and string processing, and more.
• Compiles to native code or bytecode.

What kind of things have been implemented in OCaml? Check out the Caml Hump.

OCaml was developed in France, so the "bible" of the language (O'Reilly's Développement d'applications avec Objective Caml - the camel book) is written in French, but a translation of the work by volunteers has been created. Check out Developing Applications with Objective Caml.

The language's official page at INRIA in France.

Another good OCaml page

Yay OCaml!

> I have no idea what you are talking about regarding templates being created at compile-time
> as being a bad thing. That's what generic programming is all about!!! Its the compiler
> generating classes so that you don't have to. It has to be done at compile time. I'd love to
> hear an example of a language that implements some kind of generic stuff at runtime.

Objective Caml is one language which does that. I know there are others, but I can't think of their names just now. Oberon, maybe? Ada? Bueller?

--

All of those are much slower than the equivalent C code.

Proof? Of course, there cannot be one, but if you like benchmarks, compare the Great Computer Language Shootout. Though C "wins", I wouldn't exactly call it "much slower".

They all use byte-code or generate C code, then compile the C code.

Wrong. For all languages I mentioned there are native compilers available. For all (AFAIK, not sure about Standard ML), there are also bytecode compilers available, for some also compilers to C.

BTW, nobody would ever be so stupid to first generate bytecode, then C out of this (At least I hope so). Oh, and assembly isn't what you compile to in the end, thats why there are assemblers.

None that I know of generate assembly language directly.

If you talk of generating native binaries directly, you surely should try to get to know more. Here are a few:

• OCaml
• Standard ML of New Jersey
• MLton
• The Glasgow Haskell Compiler
• NHC 98
• CLisp
• CMUCL
• Stalin

Luckily the boss said only the IDE had to be easy to use ;) Don't forget O'Caml. While the learning curve can be steep for those never introduced to functional languages, the garbage collection, object-oriented/functional+imperative style mix, near-C (when natively compiled, portable bytecode by default) speed, type inference (almost never state the type of a variable again), and bindings to both Tk and GTK make for an impressive beast! And it's free (not much of a surprise these days, but still can't be ignored :) While there's a small lack of documentation, the mailing lists (two: a new one started in the past week caters specially to beginners) can fill any gap in your knowledge.

You should check out OCaml. It is a modern functional programming language. It has parametric polymorphism, as well as subtyping polymorphism and dynamic dispatch, is garbage collected, features an advanced module system to help you structure code, and ports are available for all the usual platforms.

In addition, OCaml interfaces well with Gtk (including using Glade to design GUIs), has database libraries, as well as all many other libraries that one would expect.

OCaml can be either compiled to a portable bytecode, or directly to machine code. It compiles to very efficient code, and it is popular folklore that it can easily match C in terms of execution speed in many circumstances.

The language is at a good point in its evolution right now to be used in commercial circumstances. It has been around long enough that it is well-understood and a lot of useful libraries are available, and its compiler is very robust, but at the same time it is not so old that a lot of the really new and interesting developments in language design haven't made their way into it. Although I prefer Haskell for small one-off programs, I would use OCaml for large projects.

Another language which has had great success in industry (especially telecom equipment, as it was developed at Ericsson to write million-line switching software) is Erlang. Although I have not used it myself, its proponents swear by it as the best tradeoff between elegant PL theory, and the reality of writing large software.

You will note that my recommendations all have a functional programming slant to them, and this is only due to my own preferences. I have not kept up with developments in OO language design, and so I cannot recommend one readily.

If I may step on a soapbox for a moment, however, I would like to say that especially for the design of large systems, a strongly-typed modern funcitonal programming language with a good module system is a very good solution, to rival OO Design Patterns. As modern type systems allow you to express very precise invariants about your modules' behavior, they can be used to help many programmers together write large pieces of code that can then be checked at compile time to behave in a consistent manner. This can save both development time and money. Those are good things.

Not only that, but solve as little of the problem as possible. Someone else has probably already solved much of your problem and made available library/framework code that you can build on. The perfect language isn't if you have to re-invent every wheel with it. I do try to follow my own advice -- the availability of a partial solution for one of my problem domains is why I use Tcl a fair bit despite hating the language. OTOH if you want a language with cool features for the sake of coolness, I'd go with O'Caml.

Cyclone could be a winner if it gave you C-like performance with safety and minimal changes to your programs. But it doesn't match C performance as it is and I don't think large, existing C programs will port to it easily, despite superficial similarities.

The way it is, I think you are better off using O'CAML or MLton. They are probably easier to learn and give you better performance. O'CAML, in particular, has already been used for a number of UNIX/Linux utilities. And Java is probably as C-like as Cyclone and runs faster (although programs have a bigger footprint).

...out there and here.

If you've really only been programming in Lisp for a week or so then you really haven't had time enough to appreciate what its strengths and weaknesses are. It sounds to me as though you have acquired a disease that is all too common amongst programmers - the desire to want to specialise in one language too early on.

I simply cannot emphasise enough how valuable it is to learn as many programming languages as possible. Even if you don't really like it at first, a language can grow on you in ways you would have never imagined. No language is perfect, so knowing a selection of different languages will give you the opportunity to choose a tool that is appropriate to the job in hand. If the only tool you have is a hammer, then every problem you come across starts to look like a nail.

By keeping your horizons broad, most especially by learning languages that might seem strange, counter-intuitive or even downright annoying at first, I can assure you othat you will become a much, much better programmer in the long run. The ways in which languages differ can often give you an insight into the ways that different programmers might solve the same problem.

FWIW, the presence of closures and eval are not the only things that make Lisp distinctive from other languages. The one truly unique (not to mention incredibly powerful) feature of Lisp is macros. You will not be able to find these in Perl. Also, in Perl the standard way to solve problems is with an iterative, procedural style, where Lisp more often employs recursion and an applicative programming style, both of which are techniques well worth the effort to learn about.

Whether Lisp is better than Perl for AI is debatable. I'd argue in favour of Lisp for the following reasons: one is the fact that Lisp is extremely good at knowledge representation (and the subsequent manipulation of that knowledge), but more important is Lisp's ability to generate code with macros, effectively meaning that you can write programs to write other programs. It's also probably worth noting that Lisp is quite a lot faster than Perl, given a decent enough compiler. See The Programming Language Shootout if you don't believe me. Lisp is also a very mature language, with an ANSI standard, so unlike Perl you can be certain that it won't be pulling any carpets out from underneath your feet any time soon.

If I haven't done a enough good job of convincing you that learning Lisp is worthwhile (and I probably haven't) then try checking out Paul Graham's Beating the Averages. Also, be sure to check out Richard Gabriel's Good News, Bad News and How to Win Big. And have a read of Paradigms of Artificial Intelligence Programming by Peter Norvig for some more specific examples of Lisp as an AI programming language. Particularly relevant might be the section in the preface entitled Why Lisp?.

And when you're done with Lisp, I'd recommend a look at Ocaml, SML, Ruby and Smalltalk (particularly the delightful Squeak)!

It wasn't strongly typed (is there such a lisp?)

Yes, it's called ML. See Ocaml or Standard ML (this link is to Moscow ML, an SML implementation), for example.

and the singular type of syntax (lists) make many aspects of the code difficult to unravel.

ML has algebraic datatypes, which might be regarded as a cross between unions and structures in C.