Widgets are the domain of the toolkits, and I think Qt's are quite pretty. And FreeType is a much better font-renderer than the Apple one. Apple's renderer hints too little (leading to uneven color weight on normal-res screens) and Microsoft's hints too much (very forced, distored glyph shapes). Freetype has a nice mix balance between contrast and proper glyph shapes.
Does it really matter? KDE and Gnome work about the same, they have about the same functionality, and neither of them has an architecture or a design that seems particularly future-proof. ------------ Huh? I just gave you a boat-load of reasons why that is not the case!!!
The Qt license apparently makes KDE unacceptable as the default desktop choice for companies like IBM and Sun. --------------- IBM doesn't have a default desktop, it supports SuSE (KDE default) and RedHat (GNOME default). And Sun's decision to go with GNOME had nothing to do with licensing. The two major reasons were:
- GNOME had not yet done an HIG, so Sun really got to have a big hand in shaping 2.x. KDE was already quite solidified by then, and Sun wouldn't have had as much influence.
- Their programmers were more comfortable with C, and at the time, KDE didn't work with Sun's advanced C++ development tools.
At the link-level, both C and C++ look the same (except with respect to templates). The GTK+ convention of doing OO in C:
do_foo(object* obj,...)
Is equivilent, at the link level, to:
obj.do_foo(...)
In both cases, obj is just a contiguous struct.
There are many more GTK+ bindings, but that's not because doing Qt bindings is that much harder (given the SMOKE library), but because GTK+ just seems to be more popular among developers.
Well, a lot of what you posted is bogus (resize performance is mostly due to Xrender and WM asynchronity - try GTK on Win32 to see what I mean) ---------- All I know is that GNOME is agonizingly slow (in redraw) compared to KDE on my machine. I don't use Windows, so I can't comment on its performance there.
There was an interview recently on OSNews with Owen Taylor, and the speed issue was brought up. His response was basically, "GTK is slow???" He then proceeded to blame the performance of Render.
Well, I'm running NVIDIA's drivers with Render accelerated, and Render is very fast (try the x11perf benchmark on AA text). Its a nice boost for KDE, while doing things like highlighting text and scrolling, but it makes no difference for GTK.
WM synchronization is definately the problem for some things. Even a simple app like GEdit will have the content area lag behind the window frame when resizing. I can load 500KB of text into Kate (which does more than Gedit) and it still resizes perfectly. Qt/KDE operates under the same synchronization problems that GTK+ does, so I see no reason why it should perform so much worse.
Other things are just the fault of the toolkit. GTK+ ListViews are very slow when you have a thousand elements (like gtkpod can). When you try to resize a list column in Rhythmbox, the handle will lag behind your mouse, while in JuK, there is no lag at all. Expose handling is also bad. In KDE 3.1.x, you rarely have applications visibly redraw exposed areas. GNOME has this problem in many places, particularly Evolution.
And you haven't given any evidence to suggest that any of my others points are "bogus."
So to say "KDE already has this" is disingenuous. In many cases, so did Gnome, but the code is actually being moved to where it belongs (and being made nicer in the process). -------------- Good point. However, I looked over the list to see what was in GNOME already, and came up with the following:
- GnomeEntry has a history function, but not a generic autocomplete framework like the feature request mentioned. So 1/2 points back here.
I can't find anything in the GNOME docs about a different file dialog, combo widget, action-based menu API, customizable toolbars, or XCursor support. So of the six points I mentioned originally, 5.5 of them are valid.
Of course, this was with a cursory glance through the docs, I'm not a GNOME programmer, so you can correct me if I missed something.
I hear someone is working on CL bindings for Qt, too.
Peformance isn't a big deal for GUI apps, since all of the above languages have FFIs that let you call C/C++ functions for speed-critical parts. And Psyco has the potential to do nice things for Python performance, and a preliminary CLR implementation of Python is already quite a bit faster.
rather that it makes no sense to implement the base API in high level C++ and shut out every other language in the process. ---------- Whoa. Now *that's* dumb. C++ interoperates just fine with other languages. KDE includes many language bindings.
I left it out because its not a fact. You can dynamically link a GPL library to any application released under a GPL-compatible license. The KDE libraries themselves are LGPL, and many KDE programs are BSD.
The reasoning behind it is that until the dynamic linker actually links the application, the program is not a derived work, and copyright law does not apply. Thus, the source code to the app can be released under any license. The only catch is that when the dynamic linker does link the application (when the user is running it) the license on the app must allow the resulting binary image to follow the terms of the GPL. Most licenses less restrictive than the GPL allow this. Hence, you end up with a list of GPL-compatible licenses.
I see people bitching (mostly ignorantly) about GTK, Gnome, C, --------- Would you claim that any of my original points are ignorant? Can you refute any of them???
whatever and praising the shining pearls of light that is KDE and Qt, yet the fact is that GTK is way more popular. ----------- Popularity is hardly an indication of quality. There are lots of things that are popular, that shouldn't be. Hell, Win95 was the most popular desktop on earth for years. What does that mean? Nothing.
As for why more OSS developers choose GTK+, there are two reasons:
- GTK+ is more or less independent. You can write a GTK+ application without going the whole nine yards and being a GNOME application. This makes them fit more nicely into the Fluxbox and Window Maker desktops that are all over Linux. In contrast, when you build a KDE app, you are tied into the KDE framework. Its a KDE app and that fact is immediately obvious. The same features that make KDE apps integrate so well with each other, also make them stand out quite a bit on an average Fluxbox or Window Maker desktop.
- Like you said, a lot more people know C than C++. While KDE has C bindings, like you said, nobody wants the extra dependency. Ergo, people who know C program GTK+.
Now, its perfectly possible to use a mostly KDE desktop. I use Konqueror for internet, vim for coding, kopete for IM, and knode for newsgroups. The only GTK+ app I use on a regular basis is gtkpod, and that's probably once a month.
So, there are many practical reasons why people may choose GTK+. Yet, not one bit of evidence you provided indicates that there are technical reasons to choose GTK+/GNOME over Qt/KDE.
Actually, your application can use any GPL-compatible license, this includes BSD and LGPL. Several KDE programs use these licenses. Just be sure that you don't copy GPL'ed code into it physically.
The reasoning is that the application doesn't become a derived work until the actual linking process. So at runtime, the linked binary is GPL'ed, and the license on the source must allow that. The source to the program itself, however, is independent of Qt until linking, and can use any GPL-compatible license.
The compiler and SDK on Windows wasn't free until recently. And many companies, including major ones like Boeing, Adobe, and Sharp, seem to be fine with depending on TrollTech for their toolkit.
As for.NET: I prefer PyKDE, but there are C# Qt bindings, and C# KDE bindings are on the way. There are also bindings for a number of other languages.
You missed my point completely. I'm not saying that the file dialog is just a minor thing. What I'm saying is that the file dialog is not representative of GTK+ as a whole. You implied that people getting excited over the file dialog meant that the Linux desktop had a long way to go. It doesn't. The file dialog is an outlier, you can't draw any conclusions from it.
And the new file dialog didn't get put off because people didn't consider it important. It got put off because there was a significant technical challenge in switching to the new API required to support the new dialog. The GTK+ folks didn't want to rush out a half-assed solution, but take the time to implement it properly so something similar doesn't happen again.
And you are misunderstanding what I mean by remote servers. I'm talking remote servers in general, not just special cases for AppleTalk and SMB like MS and Apple do. KDE supports a completely generic filesystem model, where you can access ssh, webdav, smb, etc, servers through the file dialog.
Drag and drop is so manual. Who wants to fuss around with getting windows lined up just to save a file. Instead of hitting "CTRL-S," typing in a filename, and hitting enter, I know have to start up my file manager, unmaximize my window (I almost always have my windows maximized), get the two both visible at once, and drag the file over? And then I still have to name it!
Sounds like a stupid way to sap-away productivity just to adhere to "real world" metaphors.
Actually, there is already a project that uses FUSE to mount KIO-Slaves onto the filesystem. They've got it working, it just needs to be built into a releasable state.
So what does KDE do for a "next-generation save/open box?" Because KDE has had support for this, in the form of KIO, for years. In any KDE file dialog, you can just save a file to "fish://foo" and it works just fine. It supports a ton of protocols, including SMB, bzip2, http, ftp, pop3, smtp, webdav, nntp, etc. Hell, there is even a cool KIO handler for APT, to turn Konqueror into a package manager:)
Hey, its just the GTK+ people that are living in the stone age!
Seriously, though, the file dialog is hardly representative. It was just an oddity in GTK+ that just got put off way longer than it should have. Other parts of the desktop are not like that, and in a lot of respects, they are ahead of Mac/Windows. For example, I can access remote servers transparently, right from the file dialog in KDE. Very handy when you live in a networked environment like a university.
And in 3.2, they messed up the clean lines of the 3.1.x file dialog, and the symmetry between the save and open dialogs by adding an extra widget underneath the filter line.
That, kwin III (which performs worse than kwin II), and khtml bugs are the main regressions in 3.2.
I'm a die-hard KDE user, but 3.2 definately needs some more time!
- GTK's poor resize performance compared to Qt. - GTK's poor expose handling compared to Qt. - For practical purposes, lack of component technology. Bonobo is there, but almost no apps use it. Meanwhile, tons of KDE apps use KParts. - For practical purposes, lack of a network-transparent filesystem. gnome-vfs is there, but not many apps use it, and its not supported through the standard file dialog. Meanwhile, every KDE app uses KIO. - Nothing comparable to DCOP (until D-BUS comes out). - Lower-level UI framework, compared to KDE's higher-level framework. GNOME's button Ok/Cancel button order is dictated by the HIG, while in KDE, its dictated by the framework, and would take a single line of code in kdelibs to change for all KDE apps. - Lack of UI integration at the technology level. KDE apps use XML-GUI to define their layout. GUI layout can be change without touching a single line of code. KDE apps support customizable toolbars at the framework level, so all apps get it for free. The HIG is great, and GNOME's UI is very polished compared to KDE, but it would be nice if GNOME did like KDE and enforced a lot of those things in the code framework level.
Let's look at some of the upcoming GTK+ 2.4's features that Qt/KDE already has.
File selector (#29087) ------ KDE has it.
Combo widget (#50554) ------ Qt has it.
New action-based menu API (#55393) ------- KDE has it.
Toolbar improvements (#55393) -------- If you click on the feature request number and look at the proposed features, you'll see that Qt/KDE has a lot of these already, like customizable toolbars.
What difference does that make? I don't consider Americans in America to be any more important that, say, Mexicans in America. I live in Virginia, and random people in Texas don't mean any more to me than random in Uganda. We are all people, and I believe we should all be treated the same with respect to basic rights like privacy.
I think this is great. If we Americans are going to be childish, I like to see people being childish back.
For god's sake, this 9/11 thing is insane. We killed more people than that just destroying infrastructure after the Gulf War! Shit happens all over the world every day, and we are so surprised to see shit happening to us for once that we have reacted completely out of proportion; in the process destroying the very things that make this country great.
I wanna be more secure from terrorists, like every other US citizen. But do something useful, like catching Osama, or systematically taking out terrorist cells. Anything to make us *actually* safer, instead of just pandering to a public's superficial need to *feel* safer.
Since when to Perl/Python/Java advocates do that? I think its more ASM/C/C++/Java people that have the idea that all high-level languages are interpreted or run on a virtual machine.
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.
Slashdot Mirror
Um, what crappy widgets, and what horrible fonts?
Widgets are the domain of the toolkits, and I think Qt's are quite pretty. And FreeType is a much better font-renderer than the Apple one. Apple's renderer hints too little (leading to uneven color weight on normal-res screens) and Microsoft's hints too much (very forced, distored glyph shapes). Freetype has a nice mix balance between contrast and proper glyph shapes.
Qt doesn't force you to use C++. You can use a number of other available bindings.
Does it really matter? KDE and Gnome work about the same, they have about the same functionality, and neither of them has an architecture or a design that seems particularly future-proof.
------------
Huh? I just gave you a boat-load of reasons why that is not the case!!!
The Qt license apparently makes KDE unacceptable as the default desktop choice for companies like IBM and Sun.
---------------
IBM doesn't have a default desktop, it supports SuSE (KDE default) and RedHat (GNOME default). And Sun's decision to go with GNOME had nothing to do with licensing. The two major reasons were:
- GNOME had not yet done an HIG, so Sun really got to have a big hand in shaping 2.x. KDE was already quite solidified by then, and Sun wouldn't have had as much influence.
- Their programmers were more comfortable with C, and at the time, KDE didn't work with Sun's advanced C++ development tools.
At the link-level, both C and C++ look the same (except with respect to templates). The GTK+ convention of doing OO in C:
...)
do_foo(object* obj,
Is equivilent, at the link level, to:
obj.do_foo(...)
In both cases, obj is just a contiguous struct.
There are many more GTK+ bindings, but that's not because doing Qt bindings is that much harder (given the SMOKE library), but because GTK+ just seems to be more popular among developers.
Well, a lot of what you posted is bogus (resize performance is mostly due to Xrender and WM asynchronity - try GTK on Win32 to see what I mean)
----------
All I know is that GNOME is agonizingly slow (in redraw) compared to KDE on my machine. I don't use Windows, so I can't comment on its performance there.
There was an interview recently on OSNews with Owen Taylor, and the speed issue was brought up. His response was basically, "GTK is slow???" He then proceeded to blame the performance of Render.
Well, I'm running NVIDIA's drivers with Render accelerated, and Render is very fast (try the x11perf benchmark on AA text). Its a nice boost for KDE, while doing things like highlighting text and scrolling, but it makes no difference for GTK.
WM synchronization is definately the problem for some things. Even a simple app like GEdit will have the content area lag behind the window frame when resizing. I can load 500KB of text into Kate (which does more than Gedit) and it still resizes perfectly. Qt/KDE operates under the same synchronization problems that GTK+ does, so I see no reason why it should perform so much worse.
Other things are just the fault of the toolkit. GTK+ ListViews are very slow when you have a thousand elements (like gtkpod can). When you try to resize a list column in Rhythmbox, the handle will lag behind your mouse, while in JuK, there is no lag at all. Expose handling is also bad. In KDE 3.1.x, you rarely have applications visibly redraw exposed areas. GNOME has this problem in many places, particularly Evolution.
And you haven't given any evidence to suggest that any of my others points are "bogus."
So to say "KDE already has this" is disingenuous. In many cases, so did Gnome, but the code is actually being moved to where it belongs (and being made nicer in the process).
--------------
Good point. However, I looked over the list to see what was in GNOME already, and came up with the following:
- GnomeEntry has a history function, but not a generic autocomplete framework like the feature request mentioned. So 1/2 points back here.
I can't find anything in the GNOME docs about a different file dialog, combo widget, action-based menu API, customizable toolbars, or XCursor support. So of the six points I mentioned originally, 5.5 of them are valid.
Of course, this was with a cursory glance through the docs, I'm not a GNOME programmer, so you can correct me if I missed something.
How about Ruby and Python?
I hear someone is working on CL bindings for Qt, too.
Peformance isn't a big deal for GUI apps, since all of the above languages have FFIs that let you call C/C++ functions for speed-critical parts. And Psyco has the potential to do nice things for Python performance, and a preliminary CLR implementation of Python is already quite a bit faster.
rather that it makes no sense to implement the base API in high level C++ and shut out every other language in the process.
----------
Whoa. Now *that's* dumb. C++ interoperates just fine with other languages. KDE includes many language bindings.
KDE has excellent Python bindings. You can even write Qt styles in Python if you are so inclined.
The GPL FAQ is a bit zealous. See the GPL-compatible licensing page.
This thread has been done before. See this kde developers blog thread.
Note the second comment by yours truely, and the reference to the RMS post.
I left it out because its not a fact. You can dynamically link a GPL library to any application released under a GPL-compatible license. The KDE libraries themselves are LGPL, and many KDE programs are BSD.
The reasoning behind it is that until the dynamic linker actually links the application, the program is not a derived work, and copyright law does not apply. Thus, the source code to the app can be released under any license. The only catch is that when the dynamic linker does link the application (when the user is running it) the license on the app must allow the resulting binary image to follow the terms of the GPL. Most licenses less restrictive than the GPL allow this. Hence, you end up with a list of GPL-compatible licenses.
I see people bitching (mostly ignorantly) about GTK, Gnome, C,
---------
Would you claim that any of my original points are ignorant? Can you refute any of them???
whatever and praising the shining pearls of light that is KDE and Qt, yet the fact is that GTK is way more popular.
-----------
Popularity is hardly an indication of quality. There are lots of things that are popular, that shouldn't be. Hell, Win95 was the most popular desktop on earth for years. What does that mean? Nothing.
As for why more OSS developers choose GTK+, there are two reasons:
- GTK+ is more or less independent. You can write a GTK+ application without going the whole nine yards and being a GNOME application. This makes them fit more nicely into the Fluxbox and Window Maker desktops that are all over Linux. In contrast, when you build a KDE app, you are tied into the KDE framework. Its a KDE app and that fact is immediately obvious. The same features that make KDE apps integrate so well with each other, also make them stand out quite a bit on an average Fluxbox or Window Maker desktop.
- Like you said, a lot more people know C than C++. While KDE has C bindings, like you said, nobody wants the extra dependency. Ergo, people who know C program GTK+.
Now, its perfectly possible to use a mostly KDE desktop. I use Konqueror for internet, vim for coding, kopete for IM, and knode for newsgroups. The only GTK+ app I use on a regular basis is gtkpod, and that's probably once a month.
So, there are many practical reasons why people may choose GTK+. Yet, not one bit of evidence you provided indicates that there are technical reasons to choose GTK+/GNOME over Qt/KDE.
Actually, your application can use any GPL-compatible license, this includes BSD and LGPL. Several KDE programs use these licenses. Just be sure that you don't copy GPL'ed code into it physically.
The reasoning is that the application doesn't become a derived work until the actual linking process. So at runtime, the linked binary is GPL'ed, and the license on the source must allow that. The source to the program itself, however, is independent of Qt until linking, and can use any GPL-compatible license.
The compiler and SDK on Windows wasn't free until recently. And many companies, including major ones like Boeing, Adobe, and Sharp, seem to be fine with depending on TrollTech for their toolkit.
.NET: I prefer PyKDE, but there are C# Qt bindings, and C# KDE bindings are on the way. There are also bindings for a number of other languages.
As for
You missed my point completely. I'm not saying that the file dialog is just a minor thing. What I'm saying is that the file dialog is not representative of GTK+ as a whole. You implied that people getting excited over the file dialog meant that the Linux desktop had a long way to go. It doesn't. The file dialog is an outlier, you can't draw any conclusions from it.
And the new file dialog didn't get put off because people didn't consider it important. It got put off because there was a significant technical challenge in switching to the new API required to support the new dialog. The GTK+ folks didn't want to rush out a half-assed solution, but take the time to implement it properly so something similar doesn't happen again.
And you are misunderstanding what I mean by remote servers. I'm talking remote servers in general, not just special cases for AppleTalk and SMB like MS and Apple do. KDE supports a completely generic filesystem model, where you can access ssh, webdav, smb, etc, servers through the file dialog.
Drag and drop is so manual. Who wants to fuss around with getting windows lined up just to save a file. Instead of hitting "CTRL-S," typing in a filename, and hitting enter, I know have to start up my file manager, unmaximize my window (I almost always have my windows maximized), get the two both visible at once, and drag the file over? And then I still have to name it!
Sounds like a stupid way to sap-away productivity just to adhere to "real world" metaphors.
Actually, there is already a project that uses FUSE to mount KIO-Slaves onto the filesystem. They've got it working, it just needs to be built into a releasable state.
So what does KDE do for a "next-generation save/open box?" Because KDE has had support for this, in the form of KIO, for years. In any KDE file dialog, you can just save a file to "fish://foo" and it works just fine. It supports a ton of protocols, including SMB, bzip2, http, ftp, pop3, smtp, webdav, nntp, etc. Hell, there is even a cool KIO handler for APT, to turn Konqueror into a package manager :)
Hey, its just the GTK+ people that are living in the stone age!
Seriously, though, the file dialog is hardly representative. It was just an oddity in GTK+ that just got put off way longer than it should have. Other parts of the desktop are not like that, and in a lot of respects, they are ahead of Mac/Windows. For example, I can access remote servers transparently, right from the file dialog in KDE. Very handy when you live in a networked environment like a university.
And in 3.2, they messed up the clean lines of the 3.1.x file dialog, and the symmetry between the save and open dialogs by adding an extra widget underneath the filter line.
That, kwin III (which performs worse than kwin II), and khtml bugs are the main regressions in 3.2.
I'm a die-hard KDE user, but 3.2 definately needs some more time!
- GTK's poor resize performance compared to Qt.
- GTK's poor expose handling compared to Qt.
- For practical purposes, lack of component technology. Bonobo is there, but almost no apps use it. Meanwhile, tons of KDE apps use KParts.
- For practical purposes, lack of a network-transparent filesystem. gnome-vfs is there, but not many apps use it, and its not supported through the standard file dialog. Meanwhile, every KDE app uses KIO.
- Nothing comparable to DCOP (until D-BUS comes out).
- Lower-level UI framework, compared to KDE's higher-level framework. GNOME's button Ok/Cancel button order is dictated by the HIG, while in KDE, its dictated by the framework, and would take a single line of code in kdelibs to change for all KDE apps.
- Lack of UI integration at the technology level. KDE apps use XML-GUI to define their layout. GUI layout can be change without touching a single line of code. KDE apps support customizable toolbars at the framework level, so all apps get it for free. The HIG is great, and GNOME's UI is very polished compared to KDE, but it would be nice if GNOME did like KDE and enforced a lot of those things in the code framework level.
Let's look at some of the upcoming GTK+ 2.4's features that Qt/KDE already has.
File selector (#29087)
------
KDE has it.
Combo widget (#50554)
------
Qt has it.
New action-based menu API (#55393)
-------
KDE has it.
Toolbar improvements (#55393)
--------
If you click on the feature request number and look at the proposed features, you'll see that Qt/KDE has a lot of these already, like customizable toolbars.
Autocompletion and history for GtkEntry (#69613)
--------
KDE already has this.
XCursor support for GDK. (#69436)
---------
Yep, this too. And they even mention Qt right in the first post of the feature-request thread, how nice!
What difference does that make? I don't consider Americans in America to be any more important that, say, Mexicans in America. I live in Virginia, and random people in Texas don't mean any more to me than random in Uganda. We are all people, and I believe we should all be treated the same with respect to basic rights like privacy.
Americans aren't all that matter. Moron.
I think this is great. If we Americans are going to be childish, I like to see people being childish back.
For god's sake, this 9/11 thing is insane. We killed more people than that just destroying infrastructure after the Gulf War! Shit happens all over the world every day, and we are so surprised to see shit happening to us for once that we have reacted completely out of proportion; in the process destroying the very things that make this country great.
I wanna be more secure from terrorists, like every other US citizen. But do something useful, like catching Osama, or systematically taking out terrorist cells. Anything to make us *actually* safer, instead of just pandering to a public's superficial need to *feel* safer.
Since when to Perl/Python/Java advocates do that? I think its more ASM/C/C++/Java people that have the idea that all high-level languages are interpreted or run on a virtual machine.
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