faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Native code FUD
by Richard Dale on Thursday 12/Aug/2004, @17:06
|
"c is here to stay. but c++ i doubt.
dynamic optimisation is not possible
without a jitting mechanism and a
language that doesn't overspecify.
good jit compiler do inlines of
the methods based on execution
profiling. the best c++ compiler
can only guess. and slowly at
that. sure with profile feedback
it can do much better. but still
nowhere near perfect."
I think you've lost the plot here. Which is most important - a gui framework based on a more expressive dynamic language such as ruby, or a statically compiled language which is a bit faster at runtime because of jit compilation? And should a toolkit be written in the same language that end users will program it in?
Which gui toolkits are so awesome that they just need a bit of jit'ing to make them perfect? MFC, Swing, WinForms, Delphi, Taligent, WxWidgets, GTK+, GTK#. To me they're all just a bunch of dogs compared with Cocoa or Qt/KDE.
C# is a complex systems programming language (as a systems programmer I find it fun), but it is most certainly not a RAD language that everyday programmers will feel comfortable with. Ruby doesn't have jit'ing, but does anyone care, it's just much easier to get stuff done with ruby (or python) than C# or java or C++. Why can't we talk about the programming language usability vs. efficiency tradeoff? The Qt toolkit will never be as popular as it should be while it is C++ specific - a jit'ed C# version wouldn't solve that problem at all. |
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
