Slashdot Mirror

Mutilple technical specifications makes sense, "multiple standards" is an oxymoron.

See also Groklaw on the possibility of creating a single merged standard.

In addition to the computer-assisted proof by Appel and Haken mentioned by the other poster, a fully computerized proof has been carried out by Werner and Gonthier (here): you logically formalize the theorem in a machine parseable way, and the Coq automated theorem prover proves it.

So? They said if someone else did it, they might accept it. So just write it. It's not like the specifications or C source code are any big secret.

Jane Street Capital is running a project like this that revolves around OCaml.
But if you want to apply, you'd better hurry -- today is the deadline for applications.

...as OCaml-programmer (and Perl and C and others, but OCaml is my favourite) I found it very amazing, when I yesterday got a hint to OCamlP3l...

...the decription/abstract looks very promising:

http://ocamlp3l.inria.fr/eng.htm

Ciao, sdnin

such language exist and become more and more common.
Google already released their gwt (http://code.google.com/webtoolkit/) but there are also other languages like HOP (http://hop.inria.fr/) or Links (http://groups.inf.ed.ac.uk/links/)

Another feature that Java 6 has doesn't seem to be getting any attention is JSR 269 (Pluggable Annotation Processing). I'm kind of excited to try it out.

The idea with JSR 269 (as I understand it).. you create a few classes that are specifically recognized as annotation processing classes. Run javac as usual. Javac starts out and looks for classes like these. If it finds any, it will run them on your remaining source code files. The logic you define in your annotation processors can access the source code and do pretty much anything with it.

As a very simple example, you could create an annotation @HasGettersAndSetters, and create a corresponding processor that automatically creates get..() and set..() methods for any class that you stick the annotation on.

There are existing libraries out there (Spoon), but the cool part about this is that it's all built-in to javac.

I'm very picky (i.e. a perfectionist), and I've found something wrong with every language I've tried. That's why I'm working on a language of my own (Mana), but progress is slow, as I'd rather take a few extra years and have a better result than rush things out the door.

I get a lot of pleasure out of programming in Ruby. It has a few quirks, but the big problem is that implementations are so slow. Maybe with Ruby 2.0 this will all be better. At any rate, a lot of the software I use on an everyday basis (especially for email) is written in Ruby (by me).

OCaml is a language I could actually write an operating system in. It's closest to ideal of all languages I've found. A friend of mine was actually writing some code to allow drivers for Minix 3 to be written in OCaml. I would have gladly written some drivers afterwards; unfortunately, he abandoned the project.

I'm also a big fan of Common Lisp. People complain about its parentheses, but once you get over that, it's a very powerful language, and, better yet, you can easily extend and adapt it. There actually is an OS being written in Common Lisp: Movitz.

``Also though it is slightly off-topic I also think that Java under GPL would not benefit as much because the model of contribution is really not as easily understood as the OS world.''

With all the complaints about the Java community process being slow and bureaucratic, and the free Java implementations lagging behind in features, I think having a good, open source Java implementation is a Good Thing in it's own right.

Also, I don't know what you mean by the model of contribution for Java not being as easily understood as the OS world. It's not like there aren't any successful open source programming language implementations yet.

Yes, this method is an obvious way to get some benefit from a small number of extra hardware threads. But it is *not* future proof. This approach may give good CPU utilization up to perhaps 10-20 threads, but after that it will start to take a big dive.

While they are obviously not doing anything that supercomputer programmers didn't invent 30 years ago, they are leading their industry into the future, err, present. Though the article details are pretty weak, its clear that they've already gone beyond the module-level threading (sound, AI, graphics), to something that sounds more like work queues. If done right, those can get you to hundreds of threads as seen on early supercomputers, although it doesn't sound like Valve is dealing with cache-sharing problems yet, which could cause problems far sooner. I'm hoping hardware + language extensions will help mitigate that somewhat, at least on the read-sharing side.

Personally, my bet is on languages like Haskell. Purely functional programming makes multithreading easy, and for the imperative bits it has transactional memory (no locks, no deadlocks, and finally composability even with multithreading). Haskell itself may be too slow, so we may need to find a non-lazy version (laziness is basically the biggest performance problem Haskell has) for it to be practical.

I think OCaml has a lot better chance of becoming mainstream than Haskell. For one thing, I know of programs written in OCaml that aren't written by members of the PL community. For Haskell, outside of compilers and libraries, the only thing I can think of is Darcs, and that project is having all sorts of issues with determining and fixing performance problems (I love darcs though!). I'm not sure a pure-lazy language will ever map well to a soft-realtime media app such as a game. Also, when you really need delayed evaluation (i.e. laziness), ML derivatives have closures and higher-order functions which allow you to implement it easily enough.

The Cimg homepage is here. But if you want to see what it can do, check out some of the sample image restorations on page 6 of this paper. It does a very credible job of restoring missing parts of images, e.g. features hidden behind text.

From the official Caml pages:
http://caml.inria.fr/pub/docs/manual-ocaml/manual0 32.html (look at section 18.1.3)
http://caml.inria.fr/caml-light/index.en.html

The primitives of OCaml, and the bytecode interpreter and runtime system of Caml Light are all implemented in C. I am going to assume that OCaml's interpreter and runtime system are similarly situated.
So that means that if someone forgot to deallocate memory, Caml can leak memory just as well as any language, regardless of garbage collection.
And the fact that you mention that C is used to implement the compilers of GCC just goes to show that C is a good choice of language to write interpreters and compilers. So saying that C++ is an awful language to write anything in, when your hammer is implemented in a language that is generally considered to be more problematic than C++ is a bit fucked up.

From the official Caml pages:
http://caml.inria.fr/pub/docs/manual-ocaml/manual0 32.html (look at section 18.1.3)
http://caml.inria.fr/caml-light/index.en.html

The primitives of OCaml, and the bytecode interpreter and runtime system of Caml Light are all implemented in C. I am going to assume that OCaml's interpreter and runtime system are similarly situated.
So that means that if someone forgot to deallocate memory, Caml can leak memory just as well as any language, regardless of garbage collection.
And the fact that you mention that C is used to implement the compilers of GCC just goes to show that C is a good choice of language to write interpreters and compilers. So saying that C++ is an awful language to write anything in, when your hammer is implemented in a language that is generally considered to be more problematic than C++ is a bit fucked up.

5). Memory leak: I often run Firefoxes for a whole week long. Yes, you read that correctly. I often just leave important links open when I leave work, then I login back from home and continue useing it, then again tomorrow from work, and so on. After a week it often eats up around half a gigs of memory, true. But really, how many of you do such things ?

Sorry, I'm gonna rant now ...

What, a whole week? My computer (running Ubuntu 6.06LTS) is up all the time. Basically it goes down when there's a power cut. Current uptime is 55 days (reflects the fact that I moved house 55 days ago). X hasn't been restarted in all that time.

Why does Firefox need so much memory to display a few web pages? And why doesn't it at the very least return the memory when I, say, close all but one web page? I mean, I know C++ is an awful computing language to write anything in, and modern languages have garbage collectors, but still there's enough memory checking tools out there so they can catch these memory leaks by now.

Or is it a misguided attempt to "cache" stuff in memory, which is about the stupidist thing you can do given that today memory is very slow versus processors, so usually it's faster just to recompute what you need when it's needed. Typical C++ programmers wouldn't know that though - they're still reimplementing reference counting on every one of their classes, when a central, optimized garbage collector would be a lot faster.

/rant over

Rich.

Well, large parts of Firefox are written in Javascript (which is garbage collected), and they are propabaly responsible for many memory leaks. One of the reasons is because of cycles between JS and C++ objects (through XPCOM) which cannot be collected with the GC technologies used on both side. Avoiding cycles require very tricky uses of weak references, which is itself error prone.

There is an ongoing project to add a cycle collector to XPCOM:

https://bugzilla.mozilla.org/show_bug.cgi?id=33307 8

For a web browser written in a garbage collected languages, there is MMM ;-)

http://pauillac.inria.fr/~rouaix/mmm/

There is also active dvi or advi. It provide animations, ability to include any X11 program (ie an xterm) inside a slide to make a demo, etc... http://pauillac.inria.fr/advi/ for more

It will be more maintainable than Scheme and Lisp if it's coded in Caml Light.

While we are on this bit, I would recommend an ML, either SML or OCaml, perhaps even in place of Haskell (Haskell's syntax can be easily argued to be either better than or worse than ML's, and anything you can so in Haskell (including type-classes and lazyness) can be done in ML, so while I do use Haskell, I generally recommend one of the MLs as a well-typed, type-inferring functional language to know (OCaml if they are more systems/applications oriented, and SML if they are more theory oriented or just curious).

Hmmm... you will need libraries and such for that, though some people do use Scheme for all of those things (see http://www.plt-scheme.org/ and http://www-sop.inria.fr/mimosa/fp/Bigloo/). I have personally used it for web applications, though I usually use common lisp and ocaml for that. In fact, if you are looking for an alternative to C++, Java, or Python, I must recommend OCaml. Look at this book. In fact, I wrote an interpreter for R5RS in OCaml...

Hmmm... you will need libraries and such for that, though some people do use Scheme for all of those things (see http://www.plt-scheme.org/ and http://www-sop.inria.fr/mimosa/fp/Bigloo/). I have personally used it for web applications, though I usually use common lisp and ocaml for that. In fact, if you are looking for an alternative to C++, Java, or Python, I must recommend OCaml. Look at this book. In fact, I wrote an interpreter for R5RS in OCaml...

Hmmm... you will need libraries and such for that, though some people do use Scheme for all of those things (see http://www.plt-scheme.org/ and http://www-sop.inria.fr/mimosa/fp/Bigloo/). I have personally used it for web applications, though I usually use common lisp and ocaml for that. In fact, if you are looking for an alternative to C++, Java, or Python, I must recommend OCaml. Look at this book. In fact, I wrote an interpreter for R5RS in OCaml...

Wow, you can get work done quickly (but make an unmaintainable mess of shit) using python, or you can make code that is maintainable (maybe) and runs at a decent speed ucing C# or java. Why not just use a good language instead and get the best of both worlds?

I'm waiting for Firefox 2.0 before I start spell-checking all my /. posts.

Mosex + Emacs + Flyspell.

Not that I always use it, obviously, especially for quickie posts; but when I want to be careful, it's a great combo.

Or you could just use ML...

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

So what exactly is the problem?

I don't have the Sun JDK on my Fedora system by default because of the Sun license.

Meanwhile, Microsoft has been adopting ocaml as the next big language. For once, Microsoft is technically ahead of its competitors -- ocaml (which Microsoft did not produce) is very fast and safe, and from a technical standpoint is much more impressive than C# and Java.

Plus, ocaml can be used as a pure functional language -- such languages eliminate almost all the reason to use (error-prone, difficult to guarantee correctness with) threads. Pure functional code is inherently parallelizable any time the compiler can say "hey, no data dependency here".

Ocaml is picking up quite a bit of steam -- there are a slew of open-source libraries for it out there, it's the only safe language that I'm aware of that provides performance comparable to C and C++, yadda yadda yadda. The INRIA ocaml compiler is open source (though, annoyingly, QPL instead of GPL). The runtimes and the stuff that you stuff into your code is LGPL. I didn't realize that Microsoft was backing it and integrating ocaml support into Visual Studio until quite recently, though. There have been gtk+ bindings for ocaml for a while, but MS may actually be ahead of the OSS world in providing complete ocaml bindings.

If you've never used ocaml before, wait until the first time you break in the debugger at a problem...and then step *backwards* to watch the problem occurring. It's simply delightful. :-) Plus, it's even more concise than C (which is saying quite a bit), is safe and garbage-collected, has very strict typing (I've heard one ML fan say "If your code compiles, it's correct" in only half-jest)...ah.

What's particularly satisfying is that C was well-designed -- for a specific set of systems and circumstances that don't apply to most application software development today. Ocaml is the first language in a long time that I've seen where I can say not just that the language has good ideas, but that it is really well-designed. It's also a lot better-suited to application development than C is.

Gah...sorry. Ocaml gives me the warm fuzzies.

the complexity associated with modern development tools is way too steep a curve for your average 14 year old to wrap their heads around

That's why interactive development tools are the way to go, and Microsoft has already realized that. When I learned programming, 15 years ago, my first programs were 1-liners, and the interpreter gave me immediate feedback. Nowadays, even "Hello World" programs are at least 20 lines long, you have to instantiate classes, and specify which resources and libraries to link. When you run the program, a console window pops up for a second and that was it. Even for simple tasks like reading input from the console you have to know a lot about your class library.

Languages like F# and OCaml are much easier to learn, since they have an interpreter (even though native compilation is possible) and are interactive, and they still allow you to dig into object oriented programming.

Thanks, I've been looking for a development enviroment that surrenders, drinks wine, smokes, and calls me `Ahmereecan Swine`. I'll give it a go.

Compilers are being held back by the programming languages chosen by developers. As hardware concurrency increases, the technology behind compilers for imperative and procedural languages (C, Pascal, Fortran, Java) shows just ill-suited it is take advantage of that power. Instead, we will need to move to new languages that will enable compilers to optimize for concurrency

Such languages exist and have been around for quite some time. Occam was originally designed for the transputer which was supposed to herald the arrival of seriosuly concurrent computing back in the 1980s. As it happened the transputer never took off and Occam has remained a largely fringe language (though it has continued to develop). If you want to have easy to write highly concurrent code with a compiler that can optimize well for concurrency then Occam might be a good place to look.

For a range of other experimental options there's JoCaml (based on OCaml), Pict, Acute (extending OCaml), and Cw (pronounced C-omega) (an extension of C#) which all make some use of Pi-calculus ideas. Some are more experimental than others.

Jedidiah.

You may want to check out OCaml. You can use C++ libraries from it using something like SWIG (and the libraries of other languages too, using something like Pycaml for Python, and there's an interface for Perl too).

Here's a nice comparisong of a ray tracer written in C++ and one written in Ocaml.

And here are many more comparisons and information on why OCaml is so great. :)

Oh, by the way, OCaml is much safer than C++, infinitely more elegant, faster to develop in and more readable.

Ruby has made some important OO design contributions

It has ?! Like what ?! What's in Ruby that wasn't in other languages ?!!

For patience's sake, this is the problem...All I see are ideas that were in other languages, thrown together in a learn-as-you-go experiment. People think continuations are cool? Then look at Scheme and look at Smalltalk. You can't compare years of development to that experiment. Ruby is rubbish. Compare it to any Smalltalk implementation. Download a Common Lisp IDE (LispWorks, Franz) and tell me how cool Ruby is...When people diss Java, remember to also diss HotSpot. Can your little language optimize code statistically like that? I thought not...

You want new stuff? Look at Factor, Joy, the Mozart/Oz system, or Slate.
Wanna compile at gcc performance? Try Scheme with the Bigloo implementation, or Objective Caml. Bechmarks for Ocaml here (and for SML with MLTon compiler here.- The bechmarks for Bigloo were reomved some time ago).

I'll just post the buzzwords for Factor:

Continuations, exception handling.
Powerful and logical meta-programming facilities. Introspection, code generation and extension of both syntax and semantics is very easy.
Higher-order programming allows code blocks to be treated as data and used as parameters.
Highly minimalist, very consistent design. No layers upon layers of indirection, no confusing corner-cases, no poorly-thought-out features.
Postfix syntax with an extensible parser; values are passed on the stack.
Higher-order programming allows code blocks to be treated as data and used as parameters.
A powerful and very generic collections library allows many algorithms to be expressed in terms of bulk operations without micro-management of elements, recursion, or loops.
A very consistent object model based on generic predicate dispatch.
Arithmetic operations that closely model mathematical concepts, rather than just being a thin abstraction over underlying machine arithmetic. All integer operations are done in arbitrary precision, and exact fractions are supported. Complex numbers and complex-valued elementary functions are integrated.
Damn, that Slava Pestov is one smart dude.

When you see those languages, you kinda get sad that Ruby is such an attention-grabber, but I can see clearly that this is just because of disinformation. With the exception of Joy and Slate (for now, I hope), all the others I cited have pretty workable environments.

And by the way, you don't write LISP anymore, it's Lisp.

Ruby has made some important OO design contributions

It has ?! Like what ?! What's in Ruby that wasn't in other languages ?!!

For patience's sake, this is the problem...All I see are ideas that were in other languages, thrown together in a learn-as-you-go experiment. People think continuations are cool? Then look at Scheme and look at Smalltalk. You can't compare years of development to that experiment. Ruby is rubbish. Compare it to any Smalltalk implementation. Download a Common Lisp IDE (LispWorks, Franz) and tell me how cool Ruby is...When people diss Java, remember to also diss HotSpot. Can your little language optimize code statistically like that? I thought not...

You want new stuff? Look at Factor, Joy, the Mozart/Oz system, or Slate.
Wanna compile at gcc performance? Try Scheme with the Bigloo implementation, or Objective Caml. Bechmarks for Ocaml here (and for SML with MLTon compiler here.- The bechmarks for Bigloo were reomved some time ago).

I'll just post the buzzwords for Factor:

Continuations, exception handling.
Powerful and logical meta-programming facilities. Introspection, code generation and extension of both syntax and semantics is very easy.
Higher-order programming allows code blocks to be treated as data and used as parameters.
Highly minimalist, very consistent design. No layers upon layers of indirection, no confusing corner-cases, no poorly-thought-out features.
Postfix syntax with an extensible parser; values are passed on the stack.
Higher-order programming allows code blocks to be treated as data and used as parameters.
A powerful and very generic collections library allows many algorithms to be expressed in terms of bulk operations without micro-management of elements, recursion, or loops.
A very consistent object model based on generic predicate dispatch.
Arithmetic operations that closely model mathematical concepts, rather than just being a thin abstraction over underlying machine arithmetic. All integer operations are done in arbitrary precision, and exact fractions are supported. Complex numbers and complex-valued elementary functions are integrated.
Damn, that Slava Pestov is one smart dude.

When you see those languages, you kinda get sad that Ruby is such an attention-grabber, but I can see clearly that this is just because of disinformation. With the exception of Joy and Slate (for now, I hope), all the others I cited have pretty workable environments.

And by the way, you don't write LISP anymore, it's Lisp.

Three years ago, I could program in C, but had never used a scripting language (except bash, for very basic stuff). I needed to do some non-trivial manipulation of text files and figured that this was a good time to learn. Since others in the group were using perl, I tried perl.

I knew what I wanted to do, but needed to learn the language. I struggled with the awful syntax for three days. The breaking point came when I wanted a list of lists and realised that Perl "flattens" nested lists. How do you write nested lists such as [[1,2],[3,4],5,[6,7,8]]? In Python, it's trivial (that's how you'd write it), but in perl, nobody I talked to could give me an answer. It flattens it, unasked, to [1,2,3,4,5,6,7,8] and, try as I might, I can't see the point. (It turns out it's possible to have nested lists, but it's yet another example of perl's horrendous syntax).

Finally, I decided to give python a try. I spent an hour reading the python tutorial, and in another three hours, I had reimplemented everything I'd done in the last three days in perl, and an hour after that I'd finished the job. Python syntax was, and still is, the cleanest I've ever seen. It's an amazing language. And it changed the way I think about programming: it gave me an appreciation of functional methods (I now use ocaml a lot) and also changed the way I write C (vastly for the better).

That was it. No more perl for me.

Pretty much any functional language has this sort of thing. In Ocaml, for examples, you have "match" statements that can use tuples, lists, or whatever as arguments:

let bool_and boolpair =
match boolpair with
(true, true) -> true
| _ -> false
;;

The site is slashdotted at the moment, so I can't read the article.

A good example of people writing complex but bug-free software under time pressure is the annual ICFP Programming Contest. This contest runs over three days, the tasks are complex enough that you usually need to write 2000 - 3000 lines of code to tackle them, and the very first thing the judges do is to throw corner-cases at the programs in an effort to find bugs. Any incorrect result or crash and you're out of the contest instantly. After that, the winner is generally the highest-performing of the correct programs.

Each year, up to 90% of the entries are eliminated in the first round due to bugs, usually including almost all the programs written in C and C++ and Java. Ocassionally, a C++ program will get through and may do well -- even win, as in 2003 when you didn't actually submit your program but ran it yourself (so it never saw data you didn't have a chance to fix it for). But most of the prize getters year after year seem to use one of three not-yet-mainstream languages:

- Dylan
- Haskell
- OCaml

You can argue about why, and about which of these three is the best, or which of them is more usable by mortals (I pick Dylan), but all of them are very expressive languages with uncluttered code (compared to C++ or Java), completely type-safe, produce fast compiled code, and use garbage collection.

• ion | ratpoision; Pane-based (v. window-based) window managers. Little to no wasted screen real estate. Significantly reduced mouse usage.
• emacs: Wickedly powerful text editor/operating environment.
  • WhizzyTeX: Updates DVI in another window as you edit TeX/LaTeX.
  • AUCTeX: Very powerful emacs extensions for TeX/LaTeX.
• fetchmail + procmail + mutt + spamassassin + msmtp: No-nonsense mail reading and sending.
• bash completions: Quasi-telepathic tab completion.
• Firefox
  • Adblock: Saves an astonishing amount of screen real estate.
• screen: Among many other abilities, screen+ssh can provide VNC-like capabilities for your terminal sessions.

It's also possible to schedule garbage collection in some circumstances - for example by carefully sizing the heap and scheduling garbage collection so it occurs when the machine is idle, these guys have apparently implemented a real time cutting machine on top of a single-threaded garbage collector. I wrote an OpenGL game in OCaml where I scheduled garbage collection to occur between frames, and the game doesn't hang (which would be really annoying in a game as you can probably imagine).

The real problem though is that after the 10th time you do it, implementing reference counting is really uninteresting. I'd rather be getting on with delivering applications.

No idea about Java. Last time I used it which was only 3 years ago, it was still slow, despite what everyone says, and anyway it's a horribly restricted language for real world use.

Rich.

I suggest learning powerful languages like Ocaml and lisp or Smalltalk (or even Prolog). With such languages, you'll learn to think better.

Once you master different languages of various families, learning a new language will be much easier.

learning to think correctly about programming is more important IMHO than learning the currently popular languages.

And I suggest using only open-source language implementations. At some point, you'll learn a lot by diving into their source code (so better use Linux).

At some point, you probably will want to follow a college or university degree. Regards.

Actually an OC-4 seems to be a non-standard American term for a SONET ring providing bandwidth between an OC-3 and an OC-12 (~255Mbps according to this site). I found several other similar references through some google searching using terms like SONET and optical carrier, etc.

No, that's not correct either. It's a single process, but it's multithreaded. Perhaps you're confused by how LinuxThreads (the old Linux 2.0 thread implementation) created a process per thread. There were some issues with that approach, since processes really weren't meant to be threads. The current Linux thread implementation, NPTL, is much more efficient, and is supported in Linux kernel version 2.6 and later (and I guess some 2.5.x development versions).

That question is non-sense. You confuse programming languages with compiler implementation techniques.

A language is a syntax (how do I write it?) and a semantic (what does it do when I run it?). Languages never say anything about you are supposed to implement it, and so asking if a language is interpreted or compiled is just non-sense.

There are many implementations of the Java language, with many different execution strategies.

• Sun's implementation of Java is a Just-In-Time compiler (JIT).
  
• 
  SableVM is also an implementation of the Java language. It's execution strategy is to interpret the bytecode.
  
• 
  GCJ is another implementation of the Java language. It's execution strategy is to compile ahead of time.
  
• 
  DrJava is yet another implementation of the Java language. It's execution strategy is to compile the Java source code to Scheme code, then macro-expand the Scheme code to primitive Scheme, then compile that to bytecode, then interpret the bytecode.
  

• 
  The Ocaml language comes standard with three implementation: an interpreter, a bytecode compiler/bytecode interpreter pair, and an aggresively optimizing native code compiler. Somebody else also implemented a JIT.
  
• 
  The standard Python implementation is an interpreter. Starkiller is a Python compiler, and Psyco is a Python JIT.
  
• Last but not least, GCC is a C compiler (of course), and Cint is a C interpreter.
  

Now go in peace, and never say "compiled language" again.

That question is non-sense. You confuse programming languages with compiler implementation techniques.

A language is a syntax (how do I write it?) and a semantic (what does it do when I run it?). Languages never say anything about you are supposed to implement it, and so asking if a language is interpreted or compiled is just non-sense.

There are many implementations of the Java language, with many different execution strategies.

• Sun's implementation of Java is a Just-In-Time compiler (JIT).
  
• 
  SableVM is also an implementation of the Java language. It's execution strategy is to interpret the bytecode.
  
• 
  GCJ is another implementation of the Java language. It's execution strategy is to compile ahead of time.
  
• 
  DrJava is yet another implementation of the Java language. It's execution strategy is to compile the Java source code to Scheme code, then macro-expand the Scheme code to primitive Scheme, then compile that to bytecode, then interpret the bytecode.
  

• 
  The Ocaml language comes standard with three implementation: an interpreter, a bytecode compiler/bytecode interpreter pair, and an aggresively optimizing native code compiler. Somebody else also implemented a JIT.
  
• 
  The standard Python implementation is an interpreter. Starkiller is a Python compiler, and Psyco is a Python JIT.
  
• Last but not least, GCC is a C compiler (of course), and Cint is a C interpreter.
  

Now go in peace, and never say "compiled language" again.

That question is non-sense. You confuse programming languages with compiler implementation techniques.

A language is a syntax (how do I write it?) and a semantic (what does it do when I run it?). Languages never say anything about you are supposed to implement it, and so asking if a language is interpreted or compiled is just non-sense.

There are many implementations of the Java language, with many different execution strategies.

• Sun's implementation of Java is a Just-In-Time compiler (JIT).
• SableVM is also an implementation of the Java language. It's execution strategy is to interpret the bytecode.
• GCJ is another implementation of the Java language. It's execution strategy is to compile ahead of time.
• DrJava is yet another implementation of the Java language. It's execution strategy is to compile the Java source code to Scheme code, then macro-expand the Scheme code to primitive Scheme, then compile that to bytecode, then interpret the bytecode.

• The Ocaml language comes standard with three implementation: an interpreter, a bytecode compiler/bytecode interpreter pair, and an aggresively optimizing native code compiler. Somebody else also implemented a JIT.
• The standard Python implementation is an interpreter. Starkiller is a Python compiler, and Psyco is a Python JIT.
• Last but not least, GCC is a C compiler (of course), and Cint is a C interpreter.

Now go in peace, and never say "compiled language" again.

That question is non-sense. You confuse programming languages with compiler implementation techniques.

A language is a syntax (how do I write it?) and a semantic (what does it do when I run it?). Languages never say anything about you are supposed to implement it, and so asking if a language is interpreted or compiled is just non-sense.

There are many implementations of the Java language, with many different execution strategies.

• Sun's implementation of Java is a Just-In-Time compiler (JIT).
• SableVM is also an implementation of the Java language. It's execution strategy is to interpret the bytecode.
• GCJ is another implementation of the Java language. It's execution strategy is to compile ahead of time.
• DrJava is yet another implementation of the Java language. It's execution strategy is to compile the Java source code to Scheme code, then macro-expand the Scheme code to primitive Scheme, then compile that to bytecode, then interpret the bytecode.

• The Ocaml language comes standard with three implementation: an interpreter, a bytecode compiler/bytecode interpreter pair, and an aggresively optimizing native code compiler. Somebody else also implemented a JIT.
• The standard Python implementation is an interpreter. Starkiller is a Python compiler, and Psyco is a Python JIT.
• Last but not least, GCC is a C compiler (of course), and Cint is a C interpreter.

Now go in peace, and never say "compiled language" again.

• Haskell
• O' Caml
• Scheme

Thanks for the check. I remembered reading the Reg article and wondered why there hadn't been more reporting, as it seemed fairly innovative. The Coq proof assistant home page.

That's what we are using here at MIT: http://scilabsoft.inria.fr/

I use Sci-Lab regularly. With Sci-Lab, I have no need to dole out bucks for the commercial version: Matlab.

maybe even GNU Octave for those who rightly fear that proprietary software undermines freedom of research

There is also Scilab, from the French INRIA (*) (let's say it's sort of Caltech, MIT, but French - highly competent, they are - they make great croissant and cheese) and ENPC. It's Libre software (FAIF).

I've seen people use it for real research, and they thought it to be excellent. There aren't as many packages as Matlab, apparently (but this is something that depends on the number of power users, so it might change).

(*)INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE

Well, the Coq proof assistant is a program that make semi-automatic proof (semi automatic in the sense that some time it found the proof alone, and often you have to help him to find it). When you have finshid your proof, coq passe it to its proof verifier, and this proof verifier is a (relatively) small function that have been proved by hand (as for some problem linked to the Godel theorem, you cannot proof a theorem prover using it...)

So its mainly the same idea: the proof assistant, and the proof verifier are disconnected (well, the proof assistant may use the proof verifier from time to time, but not the other way arround).