XSLT may be turing complete, but at a general-purpose programming language, it sucks. Even for complex XML transformations, it gets messy. Would you like to write
No. If you need stability, don't wait for the release of 5.0, wait until the -STABLE branch tracks 5.
Even if I didn't have any problems with 5.0RC2 and it's predecessors yet (I'm a porter, so I need both -STABLE and -CURRENT boxes to test on), on a production server, don't switch until the releng team tells you to. You are unlikely to depend on the new features in 5, so play it safe and don't touch a running system except for the usual fixes.
I strongly doubt that it's impossible. I didn't hear about a Smalltalk compiler, wich would be the obvious thing to look at, but Lisp for example is as dynamic as Ruby (allows building/changing classes at runtime, adding/replacing methods etc.), yet there are lots of native-code compilers for it.
In fact, I only know of one implementation that "only" has a bytecode compiler, CLISP. Last I heard, there are about 15 Lisp systems altogether.
So you need a better excuse for not writing a Ruby compiler right now.:-) Go look at the source code of CMU CL, it has one of the fastest Lisp compilers around, and most of it is in the public domain. (The compiler is called "Python" btw., that may be concern for Ruby people;-))
Contracts in D seem to suffer from the problem that the language doesn't have a way to enforce that pre- and postconditions are side-effect free. Given that the conditions won't be executed in "production" code, this may introduce ugly heisenbugs itself, when the correctness depends on some (accidental) changes made in the conditions - bugs that are not reproducible in debug mode.
I'm not sure about both Stroustroup and Wall: Both basically created a language by merging features others alread had. This is of course a creative process of it's own, but I'd say the origial inventors of these features have deserved being on this list more.
Miguel de Icaza? What's his innovation again? Writing a desktop because he didn't like something about the license used by people who wrote a desktop because they didn't like the license and technology other Desktops (Windows and CDE) used? Copying Outlook? Copying.NET?
In 1960, John McCarthy published a remarkable paper in which he did for programming something like what Euclid did for geometry.
Reminds me that Alonzo Church, father of the lambda calculus, should not be forgotten. Of course, he actually was a mathematician and had little to do with computers, but then again, that's true for a lot of the early giants (after all, Turing did never try to acutally sell his machine or something...)
Given that functions like "invoke-debugger" are part of the Common Lisp standard and hence every program can expect to be able to call them whenever it feels like it (although not much about how the debugger is supposed to work is standardized, for obvious reasons), yes, it usually ships with a Lisp app.
The standard image shipped with CMUCL is about 20 MB on my FreeBSD box. This contains the whole standard library, including the compiler, debugger, profiling and tracing tools, embedded documentation (docstrings attached to functions/variables available programatically, like Python also has now) etc. To that, you add your own code, either as external libraries that get linked at runtime or integrated in the image - you load everything you wrote in a running image, both code and possibly data, and dump its state, so you don't have to re-load it on startup.
It is possible to get rid of functionality, but I doubt it's frequently used. 20 MB for the runtime system are not too much, compare for example with a Java runtime environment (or a basic Unix system, that could be regarded as Cs runtime).
Some commercial Lisps, for example Allegro Common Lisp support a more "conventional" way of delivering apps, as standard executables without the need for a runtime. Given that Franz charges higher license fees if you want to include the compiler/debugger in your app, I guess there is a way in ACL to get smaller executables.
Yet another option is compiling to C, and use standard OS tools like GCC for the final step. Gnu CL and Embeddable CL support this. There is still less difference between the development/production environment than one would think: They also use plain.a/.so libraries to load compiled lisp code when you work interactively.
I can't speak for smalltalk, but Lisp usually is compiled to native code these days, yet it still has a cool debugging environment, with the full language and program state available and ready to be tweaked. Some Lisps, for example the free CMUCL, even tend be able to give you the source of a form that caused the problem, right next to the asm listing of a compiled function.
"Interpreted" is not the same as "dynamic". You can have both speed and a productive environment.
A lot of Lisp applications used to use CLIM, the Common Lisp Interface Manager. It integrates command line and GUI style interaction naturally - it is based around "presentations" of the objects in your program, i.e. whenever you "present" something as either text or an icon or whatnot, it remebers what it is, and the output can be used as input for other functions, be they called by name at the command line or, for example, as a menu entry.
The symbolics Lisp Machine user interface was based around this. For an impression of it looked like and worked, look at this movie. CLIM is available for the two major commercial Lisp implementations from Franz, Inc. and Xanalys; there is also a free implementation in the works. Here are some relevant links.
There are several common definitions of "scripting language", none of which is very useful.
Perl, Python and Java get compiled to bytecode, too - but (AFAIK) Perl always compiles to bytecode "on the fly" and never stores it on disk, Python compiles modules on the first import and keeps bytecode files for faster future loading, and Java uses only the byte-compiled files. Other languages, like OCaml or Lisp, can be interpreted or compiled to either byte- or native code. Somebody wrote an interpreter for C. So, which of these languages is a scripting language?
I guess the best definition would be "People are more likely to consider it for smaller projects". It's not a property of a language or an implementation of a language (which might be identical, e.g. perl defines Perl), but of the mindset of it's users.
That said, the term "scripting" originally meant writing glue code to control the "real" app, which is pretty much what VBA does. (BTW, you do know the difference between VB and VBA, do you? VB is the one that is used for standalone apps, while VBA is what you get in the "macro editor" of MS Office. They are not the same language.)
[VB] is the most widely used programming language in the world.
AFAIK, that award would still go to (the equally enjoyable) COBOL. And it seems to be here to stay; not many banks plan to reimplement the million-line, grown-over-decades custom apps that run their business in either VB or C#. Note also that there are several free COBOL compilers on Sourceforge, and after Java and C++, it is the the third language to be supported by the Eclipse IDE with an "official" project.
It may well be that most shrinked-wrap GUI apps are written (at least partly) in VB these days. For some reason COBOL isn't really popular in this area;-)
AFAIK there are actually some C++ sources in the Linux kernel, but that's not what I was talking about. I referred to the GCC extensions (as in "embrace and extend"?) it depends on. You can't just take any standards compliant C compiler and expect Linux to compile cleanly with it.
Slashdot Mirror
lilo: Booting Logo...
However, wasn't Microsoft Bob implemented largely in Lisp? So MS does have Lisp experience, maybe just not the best...
Have a look at GCC-XML.
Is there a native 1.4.1 yet, or do you use the Linux version?
Even if I didn't have any problems with 5.0RC2 and it's predecessors yet (I'm a porter, so I need both -STABLE and -CURRENT boxes to test on), on a production server, don't switch until the releng team tells you to. You are unlikely to depend on the new features in 5, so play it safe and don't touch a running system except for the usual fixes.
In fact, I only know of one implementation that "only" has a bytecode compiler, CLISP. Last I heard, there are about 15 Lisp systems altogether.
So you need a better excuse for not writing a Ruby compiler right now. :-) Go look at the source code of CMU CL, it has one of the fastest Lisp compilers around, and most of it is in the public domain. (The compiler is called "Python" btw., that may be concern for Ruby people ;-))
No, Emacs is just the Prophet of the New Genera.
Contracts in D seem to suffer from the problem that the language doesn't have a way to enforce that pre- and postconditions are side-effect free. Given that the conditions won't be executed in "production" code, this may introduce ugly heisenbugs itself, when the correctness depends on some (accidental) changes made in the conditions - bugs that are not reproducible in debug mode.
If Solaris and Linux would be the only options, believe me, Linux would rule the world.
Miguel de Icaza? What's his innovation again? Writing a desktop because he didn't like something about the license used by people who wrote a desktop because they didn't like the license and technology other Desktops (Windows and CDE) used? Copying Outlook? Copying .NET?
She was perhaps also the one that introduced the tradition of wearing crappy glasses to computer geekdom.
The use of fake Dijkstra quotes cripples the mind; posting them on /. should, therefore, be regarded as criminal offense.
Duh. GOTO is harmful. Basic only makes you mentally mutilated beyond hope of regeneration.
The standard image shipped with CMUCL is about 20 MB on my FreeBSD box. This contains the whole standard library, including the compiler, debugger, profiling and tracing tools, embedded documentation (docstrings attached to functions/variables available programatically, like Python also has now) etc. To that, you add your own code, either as external libraries that get linked at runtime or integrated in the image - you load everything you wrote in a running image, both code and possibly data, and dump its state, so you don't have to re-load it on startup.
It is possible to get rid of functionality, but I doubt it's frequently used. 20 MB for the runtime system are not too much, compare for example with a Java runtime environment (or a basic Unix system, that could be regarded as Cs runtime).
Some commercial Lisps, for example Allegro Common Lisp support a more "conventional" way of delivering apps, as standard executables without the need for a runtime. Given that Franz charges higher license fees if you want to include the compiler/debugger in your app, I guess there is a way in ACL to get smaller executables.
Yet another option is compiling to C, and use standard OS tools like GCC for the final step. Gnu CL and Embeddable CL support this. There is still less difference between the development/production environment than one would think: They also use plain"Interpreted" is not the same as "dynamic". You can have both speed and a productive environment.
The symbolics Lisp Machine user interface was based around this. For an impression of it looked like and worked, look at this movie. CLIM is available for the two major commercial Lisp implementations from Franz, Inc. and Xanalys; there is also a free implementation in the works. Here are some relevant links.
Perl, Python and Java get compiled to bytecode, too - but (AFAIK) Perl always compiles to bytecode "on the fly" and never stores it on disk, Python compiles modules on the first import and keeps bytecode files for faster future loading, and Java uses only the byte-compiled files. Other languages, like OCaml or Lisp, can be interpreted or compiled to either byte- or native code. Somebody wrote an interpreter for C. So, which of these languages is a scripting language?
I guess the best definition would be "People are more likely to consider it for smaller projects". It's not a property of a language or an implementation of a language (which might be identical, e.g. perl defines Perl), but of the mindset of it's users.
That said, the term "scripting" originally meant writing glue code to control the "real" app, which is pretty much what VBA does. (BTW, you do know the difference between VB and VBA, do you? VB is the one that is used for standalone apps, while VBA is what you get in the "macro editor" of MS Office. They are not the same language.)
... you only have to make sure both your windows and OS X binaries are for the same processor architecture.
It may well be that most shrinked-wrap GUI apps are written (at least partly) in VB these days. For some reason COBOL isn't really popular in this area ;-)
At least he didn't mention c0b01.
AFAIK there are actually some C++ sources in the Linux kernel, but that's not what I was talking about. I referred to the GCC extensions (as in "embrace and extend"?) it depends on. You can't just take any standards compliant C compiler and expect Linux to compile cleanly with it.
In this light, how do we interpret the result for Smalltalk?