a) C and C++.  Oh, but they're not modern, you say; balls, I say.  Both standards were revised very recently and C++ is changing quite a bit.<p>b) SLIME and SBCL (to pick freebies) crush any of those under their collective boot.  Eclipse tries real hard but is let down in a number of ways by Java (instability, the fact that the environment is opaque to the user instead of malleable, etc).  LispWorks's GUI is very good, at least as good as Eclipse at the things Eclipse is good at.<p>c) You would be shocked at how bad things are.  GCC, to pick on a weak and somewhat helpless example, tries really hard to optimize C code but is generally content to merely compile C++ code.  XCode with its gcc backend does relatively little real optimization of Objective C, certainly nothing compared to what you expect from a modern JIT in Java.  Not familiar enough with Delphi or MSVS to pick those apart but I doubt it's that much different.<p>d) Ditto.  Eclipse crashes at least once a day for me during heavy use and suffers bizarre and inexplicable errors even more frequently (fun experiment: create a file Foo.java.  Rename it to Bar.java.  Try to create Foo.java again.  The editor cannot be convinced to read the new Foo.java off disk without a restart).  Errors in the native code are not infrequent (I have a bunch of logs here from older Javas where the GC (I think) got confused in the middle of GCing and dumped core), although they seem to be better with Java 6.<p>e) A comp.lang.lisp audience knows about macros and why they're nice.  Other language zealots cannot have their minds made up by a simple reiteration of the benefits of code as data (which I agree are considerable).  The other points are somewhat more relevant inasmuch as they challenge generally accepted but really wrong concepts.<p>And re: memory footprint: be wary of comparing apples to rutabegas.  Remember that every C program benefits from libc and its ancillary stuff; on this here Ubuntu system the system libraries required to bring the system up from a dead stop (not any of this /usr/lib detritus) is already 2.5 MB on disk.  Also remember that the 50 MB program footprint likely includes the runtime compiler system (so you can hot swap code; very useful) which is something like 42 MB for gcc 4.4 alone (again, disk; memory usage is enormous).  I would expect that the amount of code that needs to stay in the CPU cache is equivalent.