I'v been using Qt since 1996, and I think it is the best written set of GUI classes out there. I also think C++ is the best compromise between performance and abstraction for graphical user interfaces. That does not mean there aren't some problems, however...
Does anyone else think that Qt should forward declare more classes than it does? The compilation time of Qt projects has went up five fold since Qt 1.x due to excessive of C++ templates. Sure there are ways to cope with it: distcc, ccache - but this is not addressing the primary problem - C++ compiles are too bloody slow and getting slower all the time.
On another topic, who else thinks C++0x should make provisions to forward declare templatized class instances? Including all these template definitions in every header file is complete death for compilation time: #include <string>, for example. Precompiled headers help a little, but are easily corrupted and the cause of many bad builds.
Dude, lighten up. The examples did not call for introspection.
No one said the universal computer language translator was feasible or even practical - just that it would be nice to have. I was already well aware of all the constraints you mentioned. But I guess you never dream.
Tell you what - when I write the universal computer language translator you won't be allowed to use it. <sticking tongue out>
If I didn't have a screwdriver, I might use a hammer to drive in a screw. Depends on the situation. But that's just me. I entirely agree with your point about languages having their respective strengths in certain domains. My only point is that these language features are nothing more than syntax. If the syntax of language X leads me to write far fewer lines of code for the task and it fits in with the overall goals of the project - I'll use that language. But I really haven't seen a new concept in computer languages in 20 years. The next advance will likely be natural language processing - when computer languages simply be human languages. Until then we're just rehashing the same old stuff. (However, I do admit that the Occam transputer language is pretty unique in its own right.:-)
Forth/Postscript/other postfix languages a b + my_function
or assembler: push a push b add jsr my_function
It just boils down to syntax and ease of typing.
It's interesting to note that C-style syntax seems to have won the popularity contest, though. Code is written in any of PHP, Perl, C, C++, Objective C, C#, Java, Javascript are easily understood by anyone versed in any language in the set.
Most languages are stack based, but a few like Lisp and Javascript support the notion of closures. But even closures can be emulated in C of course via heap allocated memory and function objects. Indeed, you can emulate any computer language construct in any other computer language (with varying degrees of efficiency, of course).
In the end, the computer language is usually chosen based on:
popularity (because this implies support for the language and longevity for your system)
ease of coding
execution speed
Too bad there does not exist a universal computer language compiler system whereby one could code in the computer language they prefer and check the code in and the next guy could check out the code in the language they prefer.
If Sun's Pet Store application is not highlighting J2EE "best practice" then what the hell is it for, then? Are you saying that Sun with a billion dollars in cash in the bank could not find a suitable expert to write a decent J2EE example? They invented J2EE, afterall! First Entity Beans were good - and now they are bad. What other surprises can we expect? Who should an average Java programmer believe?
Why on earth would Sun put out such a horribly performing example J2EE program (Pet Store) when it knows damn well that 99% of the programmers out there will copy this program as a shining example of how to code in J2EE correctly? For God's sake, Sun - get a clue! Give the world a better official J2EE example! The J2EE optimization rebuttal seemed awfully complicated to expect a new Java programmer to understand. Nevermind benchmarks optimized by experts - average shops don't have such experts. Think about the lowest common denominator. I'd rather see a benchmark of how average systems perform when designed by novices as an indicator of how good the underlying technology is. If a system has to be designed by leading experts then it is not cost effective for the average shop and I would want no part of it. Object orientation be damned - just give me something that works and does not cost an arm and a leg to extend and maintain.
Let's see... PHP is free and WebLogic is, well, the exact opposite of free. Are you willing to wager a guess how much it would cost for licenses and yearly maintenance for 4,500 WebLogic servers? Let me give you a clue - it is not cheap. Yahoo has done as well as it has in large part by keeping its costs low - using FreeBSD, as an example. On the technical side, unlike Java, PHP does not have a compilation step so webpage development turnaround time is much quicker. Nevermind the fact that you can usually do most tasks in half the number of lines of code and half the development time in the PHP scripting language as you do with the statically typed Java language. Compare the two languages' associative array syntax, as an example. PHP has the ease of use of Javascript with much of the power of Perl. It's syntax is short and sweet with no need to declare variable types. That's why web developers and content providers love using it.
Such non-transferable license agreements will never stand up in court. Reselling licensed software is no different than transfering ownership of a legally purchased music CD. Last time I looked, second-hand record shops have been alive and well for decades.
Mac OS X 10.2 uses a custom version of GCC 3.1 according to this GCC mailing list announcement. It was apparently tweaked to accomodate the GCC 2.95 C++ ABI for certain drivers and libraries. I, for one, hope the GCC steering committee will allow them to add Objective C++ to the GCC main branch.
Legally, Linus can distribute GPL'd code any way he likes. But what gives Linus the ethical right to publicly endorse a commercial source control management system using the GPL'd work of hundreds of contributors to the Linux kernel (of which he is just one)? Was a vote taken? No, he effectively said if you want to be in the fast lane of kernel development use this commercial product to stay in sync with the latest source code in near-realtime. It has been shown time and time again that when something is "free enough" there is very little incentive to create a viable and complete free alternative. Would the world have created a free operating system if Linus never worked on what would become the Linux kernel? Of course - and in short order too. The GNU Hurd was just the next logical piece in the GNU toolchain - the very reason for GNU's existance. Linux with its implicit GNU contract co-opted developer interest from GNU Hurd. As such there is a moral obligation to follow the principles of the original GNU project. Where would free software be without GCC and the GNU tools? Conservatively, at least 25 years behind.
Parrot lacks key builtin opcodes for universal language support - like support for 64 bit ints. As for the embedded Postres support within the Parrot VM itself, no, a C calling facility from Parrot would do just fine. By delaying the decision on how to hook up Parrot to native C APIs you are denying Parrot critical third party support. Like guys who simply want to embed Parrot in their application to control a MP3 player or CAD program or whatever. You need the buy in, you need the additional free testers and proponents. Give them a reason to use Parrot at this stage. Actually this talk of C#/dotGNU/Parrot integration is a good thing - it will give Parrot some focus to run a real language. Perl6 is not the greatest target at this because it keeps shifting.
You think PMCs will cure all ills, it seems. I beg to differ. They just defer the hard work to the high-level language implementor. Now the high level language implementor would have to write custom C code to support such things as basic arithmetic - doesn't that defeat the whole purpose of having a generic VM? I don't think many people would be crazy about the idea of linking in shared libraries for Parrot apps to support the PMCs in other languages.
Dude, by simply saying that something is not true does not make it true. The Parrot calling convention POD was pulled a while back. I don't call saveall/restoreall a true calling convention. Prove me wrong - show me a doc with the new calling convention. Where's Parrot's 64 bit integer type? If you hope to support Java and C# you will need it. You *do* need some form of distributable bytecode library format - bytecodes alone do not cut it - all projects cannot be monolithicly compiled in a single bytecode file. Threading issues *must* be considered from the very start - it affects every aspect of your design - from garbage collection to memory layout. Look at all the trouble Perl 5 had grafting threads to its design - they only "got it right" in Perl 5.8. You're living in a dream world of denial. The project has to address these basic issues if it is to suceed. It's history repeating itself all over again. Remember what happened to Topaz: Perl for the 22nd Century?
Don't worry about about Perl5/XS becoming obsoleted - it will be with us for a long time since the Parrot (perl 6 VM) project seems to be going nowhere fast. Parrot is suffering from kitchen sink/second system syndrome.
Recently, the DotGNU have made an overture to try to use the Parrot runtime for their C# compiler but found that Parrot needs a lot of work to get to the point where they could use it.
Some Parrot VM problems:
no calling conventions yet for subroutines. There is no hope of offering mixed language support unless they do this.
no conversion opcodes for various builtin types (float, char, short, int)
non-perl languages expected to provide additional support in the form of C code libraries for their opcodes. This would nix any hope of having a single standard universal virtual machine.
no way to call out to C code
no equivalent of Java's jar file or CLR's assemblies for parrot library distribution
way too many registers: their register based VM (32 int registers, 32 double registers, 32 string registers, 32 PMC registers plus various stacks) requires a sophisticated compiler to do proper register allocation and needlessly complicates their VM.
no consideration of threads in their design. How will they handle synchronization, for example?
The points above are not coding issues, but issues of design. It seems that Parrot is too hung up on making the VM efficient and are not seeing the bigger picture - to get the features in place first so that high-level languages can work. Or perhaps they should simply concentrate on getting Perl6 to work first. They need more focus. The project tries to be all things to all people, but ends up satisfiying no one.
Too bad unionfs won't be supported in Linux until the 2.7 kernel series. Here is a good description of how unionfs works on BSD. Basically, unionfs allows one or more directories to be superimposed over each other giving the appearance of just a single directory.
While checking out Mandrake 8.2 I looked in/usr/lib and/usr/lib and saw hundreds of files that had no business being there - they dumped all the KDE libraries and include files directly into the system directories. At least they should have thrown KDE into/opt/kde or something. Mandrake sorely needs a major directory structure overhaul - it's a hornet's nest. I'd expect this from Windows (system directory and its thousands of DLLs) but not a major Linux distribution.
I haven't had the time to check out Mandrake 9.0. Did they fix this mess?
Does anyone even care about what Gartner says anymore after all those wrong "new economy" predictions of 1997-2000? B2B bullshit. You can make money by doing the exact opposite of what Gartner says.
I'm very grateful that this guy took the time out of his busy schedule to quantify what every Linux user has suspected for a long time - CPU performance degradation during heavy IO. I have always felt that Linus put too much emphasis on pure CPU-bound tasks and that's why he resisted raising HZ above the ridicously low value of 100 for so long - to the detriment of desktop applications. Hopefully this a start of a trend to create a more universal general purpose kernel for interactive desktops, web servers and number crunchers.
Presumably you meant "The only benefit of increasing HZ is decreasing latency" which is not a bad thing unto itself. Most people run interactive desktop applications, not scientific number crunching jobs for days at a time.
Having a minimum granularity of 1/50th of a second for a select() when HZ=100 really sucks, quite frankly. Music players and animation programs have to resort to busy wait loops to get good response and tie up all CPU in the process. This is completely unnecessary in a modern OS. It's 1/50th not 1/100th of a second with HZ=100 because of the way POSIX defines select() you have to wait for two jiffies at a minimum according to Linus.
Anyway, HZ > 500 sure as hell is better than HZ=100. A HZ-less kernel with on-demand timer scheduling would be much better, though. IBM has such a kernel patch for their mainframe version of Linux to improve responsiveness when hundreds of Linux VMs are running concurrently.
Pity about the USER_HZ = 100 thing to accomodate all the borken programs that pick up HZ from the linux kernel header file and assume it is a) constant, or worse yet b) 100. Had HZ had been a proper syscall instead of a #define in the first place for user-land programs this would not have been a problem today.
Can someone do me a big favor and post RedHat 8.0's asm-i386/param.h file so I can see how they defined HZ, USER_HZ and friends? I'd like to see it without actually going to the trouble of installing RedHat 8.0.
He may have created it in part for fun, but he was also pissed off at Minix's licensing restrictions and cost (Minix cost $169 in those days, I believe) and wanted to produce a free alternative.
There's nothing in the license that prohibits that
Assuming you don't actually work for BM you're pretty naive to believe that. Please read RMS' post again - especially the part about "You have no right to use Bitkeeper, only temporary privileges that we can revoke." Any individual hosting a live BK to [your favorite open source SCM] repository would likely be deemed to be a developer of a competing solution and barred from using BitKeeper. Larry implied in his posts that you need two unrelated parties to distribute BK changesets: one makes the BK patches available and the second imports them into another competing SCM system. That's how pathetic the situation has become: in order to use BK you have to read Larry's tea leaves and daily rule changes about BK's free use. The decision to ban people from using the free version of BK is solely made by Larry is absolute and completely arbitrary. Larry has already demonstrated that he can change the BK license retroactively. (Well technically he rendered the old version of BK with the old license obsolete, which amounts to the same thing since only his servers can be used.) Each of Larry's posts on the BK licensing subject adds a new twist to the licensing scheme which he changes at his whim.
Slashdot Mirror
I'v been using Qt since 1996, and I think it is the best written set of GUI classes out there. I also think C++ is the best compromise between performance and abstraction for graphical user interfaces. That does not mean there aren't some problems, however...
Does anyone else think that Qt should forward declare more classes than it does? The compilation time of Qt projects has went up five fold since Qt 1.x due to excessive of C++ templates. Sure there are ways to cope with it: distcc, ccache - but this is not addressing the primary problem - C++ compiles are too bloody slow and getting slower all the time.
On another topic, who else thinks C++0x should make provisions to forward declare templatized class instances? Including all these template definitions in every header file is complete death for compilation time: #include <string>, for example. Precompiled headers help a little, but are easily corrupted and the cause of many bad builds.
Dude, lighten up. The examples did not call for introspection.
No one said the universal computer language translator was feasible or even practical - just that it would be nice to have. I was already well aware of all the constraints you mentioned. But I guess you never dream.
Tell you what - when I write the universal computer language translator you won't be allowed to use it. <sticking tongue out>
Sheesh.
You're absolutely right about the low memory thing.
I forgot to add "memory consumption" to the list of language considerations.
If I didn't have a screwdriver, I might use a hammer to drive in a screw. Depends on the situation. But that's just me. :-)
I entirely agree with your point about languages having their respective strengths in certain domains. My only point is that these language features are nothing more than syntax. If the syntax of language X leads me to write far fewer lines of code for the task and it fits in with the overall goals of the project - I'll use that language.
But I really haven't seen a new concept in computer languages in 20 years. The next advance will likely be natural language processing - when computer languages simply be human languages. Until then we're just rehashing the same old stuff.
(However, I do admit that the Occam transputer language is pretty unique in its own right.
set/read variables
conditional, branching and looping constructs
call functions
I see very little difference between:
Lisp/Scheme's
(my_function (+ a b))
C/C++/C#/Java/Javascript's
my_function(a + b);
Forth/Postscript/other postfix languages
a b + my_function
or assembler:
push a
push b
add
jsr my_function
It just boils down to syntax and ease of typing.
It's interesting to note that C-style syntax seems to have won the popularity contest, though. Code is written in any of PHP, Perl, C, C++, Objective C, C#, Java, Javascript are easily understood by anyone versed in any language in the set.
Most languages are stack based, but a few like Lisp and Javascript support the notion of closures. But even closures can be emulated in C of course via heap allocated memory and function objects. Indeed, you can emulate any computer language construct in any other computer language (with varying degrees of efficiency, of course).
In the end, the computer language is usually chosen based on:
popularity (because this implies support for the language and longevity for your system)
ease of coding
execution speed
Too bad there does not exist a universal computer language compiler system whereby one could code in the computer language they prefer and check the code in and the next guy could check out the code in the language they prefer.
If Sun's Pet Store application is not highlighting J2EE "best practice" then what the hell is it for, then? Are you saying that Sun with a billion dollars in cash in the bank could not find a suitable expert to write a decent J2EE example? They invented J2EE, afterall!
First Entity Beans were good - and now they are bad. What other surprises can we expect? Who should an average Java programmer believe?
Why on earth would Sun put out such a horribly performing example J2EE program (Pet Store) when it knows damn well that 99% of the programmers out there will copy this program as a shining example of how to code in J2EE correctly?
For God's sake, Sun - get a clue! Give the world a better official J2EE example!
The J2EE optimization rebuttal seemed awfully complicated to expect a new Java programmer to understand.
Nevermind benchmarks optimized by experts - average shops don't have such experts. Think about the lowest common denominator. I'd rather see a benchmark of how average systems perform when designed by novices as an indicator of how good the underlying technology is. If a system has to be designed by leading experts then it is not cost effective for the average shop and I would want no part of it. Object orientation be damned - just give me something that works and does not cost an arm and a leg to extend and maintain.
Let's see... PHP is free and WebLogic is, well, the exact opposite of free. Are you willing to wager a guess how much it would cost for licenses and yearly maintenance for 4,500 WebLogic servers? Let me give you a clue - it is not cheap. Yahoo has done as well as it has in large part by keeping its costs low - using FreeBSD, as an example.
On the technical side, unlike Java, PHP does not have a compilation step so webpage development turnaround time is much quicker. Nevermind the fact that you can usually do most tasks in half the number of lines of code and half the development time in the PHP scripting language as you do with the statically typed Java language. Compare the two languages' associative array syntax, as an example.
PHP has the ease of use of Javascript with much of the power of Perl. It's syntax is short and sweet with no need to declare variable types.
That's why web developers and content providers love using it.
Such non-transferable license agreements will never stand up in court.
Reselling licensed software is no different than transfering ownership of a legally purchased music CD.
Last time I looked, second-hand record shops have been alive and well for decades.
US Court says buyers can unbundle EULA-covered software.
Also take a look at this very well argued thesis on the same issue. Same paper in HTML format
Mac OS X 10.2 uses a custom version of GCC 3.1 according to this GCC mailing list announcement.
It was apparently tweaked to accomodate the GCC 2.95 C++ ABI for certain drivers and libraries.
I, for one, hope the GCC steering committee will allow them to add Objective C++ to the GCC main branch.
We can all throw out our 32-bit DOS extenders now that Sun has graced us with an x86 UNIX.
Legally, Linus can distribute GPL'd code any way he likes. But what gives Linus the ethical right to publicly endorse a commercial source control management system using the GPL'd work of hundreds of contributors to the Linux kernel (of which he is just one)? Was a vote taken? No, he effectively said if you want to be in the fast lane of kernel development use this commercial product to stay in sync with the latest source code in near-realtime.
It has been shown time and time again that when something is "free enough" there is very little incentive to create a viable and complete free alternative.
Would the world have created a free operating system if Linus never worked on what would become the Linux kernel? Of course - and in short order too. The GNU Hurd was just the next logical piece in the GNU toolchain - the very reason for GNU's existance. Linux with its implicit GNU contract co-opted developer interest from GNU Hurd. As such there is a moral obligation to follow the principles of the original GNU project.
Where would free software be without GCC and the GNU tools? Conservatively, at least 25 years behind.
The CPU circuittry would be on the perimeter of the screen, I would think.
Parrot lacks key builtin opcodes for universal language support - like support for 64 bit ints. As for the embedded Postres support within the Parrot VM itself, no, a C calling facility from Parrot would do just fine.
By delaying the decision on how to hook up Parrot to native C APIs you are denying Parrot critical third party support. Like guys who simply want to embed Parrot in their application to control a MP3 player or CAD program or whatever. You need the buy in, you need the additional free testers and proponents. Give them a reason to use Parrot at this stage.
Actually this talk of C#/dotGNU/Parrot integration is a good thing - it will give Parrot some focus to run a real language. Perl6 is not the greatest target at this because it keeps shifting.
You think PMCs will cure all ills, it seems. I beg to differ. They just defer the hard work to the high-level language implementor. Now the high level language implementor would have to write custom C code to support such things as basic arithmetic - doesn't that defeat the whole purpose of having a generic VM? I don't think many people would be crazy about the idea of linking in shared libraries for Parrot apps to support the PMCs in other languages.
Dude, by simply saying that something is not true does not make it true.
The Parrot calling convention POD was pulled a while back. I don't call saveall/restoreall a true calling convention. Prove me wrong - show me a doc with the new calling convention.
Where's Parrot's 64 bit integer type? If you hope to support Java and C# you will need it.
You *do* need some form of distributable bytecode library format - bytecodes alone do not cut it - all projects cannot be monolithicly compiled in a single bytecode file.
Threading issues *must* be considered from the very start - it affects every aspect of your design - from garbage collection to memory layout. Look at all the trouble Perl 5 had grafting threads to its design - they only "got it right" in Perl 5.8.
You're living in a dream world of denial. The project has to address these basic issues if it is to suceed.
It's history repeating itself all over again. Remember what happened to Topaz: Perl for the 22nd Century?
Recently, the DotGNU have made an overture to try to use the Parrot runtime for their C# compiler but found that Parrot needs a lot of work to get to the point where they could use it.
Some Parrot VM problems:
no calling conventions yet for subroutines. There is no hope of offering mixed language support unless they do this.
no conversion opcodes for various builtin types (float, char, short, int)
non-perl languages expected to provide additional support in the form of C code libraries for their opcodes. This would nix any hope of having a single standard universal virtual machine.
no way to call out to C code
no equivalent of Java's jar file or CLR's assemblies for parrot library distribution
way too many registers: their register based VM (32 int registers, 32 double registers, 32 string registers, 32 PMC registers plus various stacks) requires a sophisticated compiler to do proper register allocation and needlessly complicates their VM.
no consideration of threads in their design. How will they handle synchronization, for example?
The points above are not coding issues, but issues of design. It seems that Parrot is too hung up on making the VM efficient and are not seeing the bigger picture - to get the features in place first so that high-level languages can work. Or perhaps they should simply concentrate on getting Perl6 to work first. They need more focus. The project tries to be all things to all people, but ends up satisfiying no one.
This one went around the internet a thousand times already, but in case you haven't seen it:
True in a Nutshell
is $
Too bad unionfs won't be supported in Linux until the 2.7 kernel series.
Here is a good description of how unionfs works on BSD.
Basically, unionfs allows one or more directories to be superimposed over each other giving the appearance of just a single directory.
While checking out Mandrake 8.2 I looked in /usr/lib and /usr/lib and saw hundreds of files that had no business being there - they dumped all the KDE libraries and include files directly into the system directories. At least they should have thrown KDE into /opt/kde or something. Mandrake sorely needs a major directory structure overhaul - it's a hornet's nest. I'd expect this from Windows (system directory and its thousands of DLLs) but not a major Linux distribution.
I haven't had the time to check out Mandrake 9.0.
Did they fix this mess?
Does anyone even care about what Gartner says anymore after all those wrong "new economy" predictions of 1997-2000? B2B bullshit. You can make money by doing the exact opposite of what Gartner says.
I'm very grateful that this guy took the time out of his busy schedule to quantify what every Linux user has suspected for a long time - CPU performance degradation during heavy IO. I have always felt that Linus put too much emphasis on pure CPU-bound tasks and that's why he resisted raising HZ above the ridicously low value of 100 for so long - to the detriment of desktop applications. Hopefully this a start of a trend to create a more universal general purpose kernel for interactive desktops, web servers and number crunchers.
The only benefit of increasing HZ is latency.
Presumably you meant "The only benefit of increasing HZ is decreasing latency" which is not a bad thing unto itself. Most people run interactive desktop applications, not scientific number crunching jobs for days at a time.
Having a minimum granularity of 1/50th of a second for a select() when HZ=100 really sucks, quite frankly.
Music players and animation programs have to resort to busy wait loops to get good response and tie up all CPU in the process. This is completely unnecessary in a modern OS.
It's 1/50th not 1/100th of a second with HZ=100 because of the way POSIX defines select() you have to wait for two jiffies at a minimum according to Linus.
Anyway, HZ > 500 sure as hell is better than HZ=100.
A HZ-less kernel with on-demand timer scheduling would be much better, though. IBM has such a kernel patch for their mainframe version of Linux to improve responsiveness when hundreds of Linux VMs are running concurrently.
Pity about the USER_HZ = 100 thing to accomodate all the borken programs that pick up HZ from the linux kernel header file and assume it is a) constant, or worse yet b) 100.
Had HZ had been a proper syscall instead of a #define in the first place for user-land programs this would not have been a problem today.
Can someone do me a big favor and post RedHat 8.0's asm-i386/param.h file so I can see how they defined HZ, USER_HZ and friends? I'd like to see it without actually going to the trouble of installing RedHat 8.0.
He created it for fun.
He may have created it in part for fun, but he was also pissed off at Minix's licensing restrictions and cost (Minix cost $169 in those days, I believe) and wanted to produce a free alternative.
There's nothing in the license that prohibits that
Assuming you don't actually work for BM you're pretty naive to believe that. Please read RMS' post again - especially the part about "You have no right to use Bitkeeper, only temporary privileges that we can revoke."
Any individual hosting a live BK to [your favorite open source SCM] repository would likely be deemed to be a developer of a competing solution and barred from using BitKeeper. Larry implied in his posts that you need two unrelated parties to distribute BK changesets: one makes the BK patches available and the second imports them into another competing SCM system. That's how pathetic the situation has become: in order to use BK you have to read Larry's tea leaves and daily rule changes about BK's free use.
The decision to ban people from using the free version of BK is solely made by Larry is absolute and completely arbitrary. Larry has already demonstrated that he can change the BK license retroactively. (Well technically he rendered the old version of BK with the old license obsolete, which amounts to the same thing since only his servers can be used.) Each of Larry's posts on the BK licensing subject adds a new twist to the licensing scheme which he changes at his whim.