Don't worry. By the time ReactOS reaches version 1.0, those patents will expire. Remember, patent is valid for 20 years only.
Haha! We've already thought of this; here's our plan for accelerated development:
Implement the ReactOS kernel as a GNU Hurd daemon, with built-in 3d graphics support based on the Duke Nukem Forever engine (running on top of WINE's DirectX layer).
The built-in 3d engine will be used as the basis for an implementation of the Berlin windowing API, the suggested application interface to which is the Perl 6 virtual machine. We should have all of this up and running on the Indrema console within a mere three months!
Then, we plan to hire Loki games to implement an X-Windows compatibility layer, and we've arrived!
Ok but te swing api is written in java and compiled into java bytecode. Only the lowlevel graphic calls of the vm are implemented in native code.
I've done a fair amount of Swing programming, so I realize how it's implemented. I really admire the software engineering evident in Swing; it's elegantly customizable through and through.
However, the performance (in both CPU and memory) really sucks. Don't tell me it doesn't; don't tell me it's fixed in Java 1.4. I use a Swing text editor all day every day on Java 1.4.1_01 on Windows 2000 on an Athlon XP 2100+ with 512 MB RAM, and it's still sluggish. This rules out Swing as a serious choice for client-side development in the typical corporate environment, where the client machines are elderly and feeble. That's a real pity.
I do have one complaint: single-line text controls can't be right-aligned (e.g., for monetary values)! I believe this is a wxWindows limitation rather than a wxPython limitation, and wxPython includes a dirty hack to circumvent it, but to me the omission of this feature is senseless.
In recent releases, wxPython has begun to incorporate numerous "high-level composition widgets" that AFAIK don't exist in wxWindows itself, such as calendar controls. They're aimed at making the wxPython programming experience even more high-level, and they succeed admirably.
Unlike some other posters here, I do not find the C++-centric documentation annoying; the documentation is, in fact, excellent. For the most part, the wrapping of the C++ wxWindows API in Python does not introduce any API mismatch; in cases where it must, the transition is handled with a reasonable sacrifice in elegance.
wxWindows uses native widgets, so there are no look and feel problems.
Thanks to Robin Dunn and the wxWindows team for a job well done.
Not familar with python, although I know one form of using it is interperted via a hash-bang (#!/usr/loval/bin/python). However, java is compiled into bytecode run by a jvm en emulator for a system that doesn't exist.
I was referring to the GUI toolkit itself being written in C++ (and thus compiled/fast), not necessarily the surrounding application.
Though I have not used Java, I am told the API is very similar in style (to Swing?). The upside to Qt is that it is compiled and uses C++, so it is fast and you can mix and match system code. A common myth about cross-platform software is that you must cater to the lowest common denominator, which is absolutely not true with Qt.
Even if you are doing development for a single platform, you may still want to use Qt. It is generally easier to use than whatever is native... and it secures you that 'out' in case you want to port later.
It's worth noting that all of the "upsides" you mention here also apply to SWT (for Java), PyQT (for Python), and wxPython (for Python).
It's not necessary to switch from a higher level language to C++ just to use a fast, cross-platform GUI toolkit that renders via native widgets.
Don't confuse Zope with Python. That's like condemning C because Windows 3.0 is written in it. Zope is a bloated monstrosity that happens to be written in Python; Python itself is an elegant gem.
ttfkam wrote: Do it in a higher-level language first. Make sure your algorithms are clean and efficient. If and only if you see a performance or resource problem do you rework portions(!!!) in C. As a bonus, the higher level language acts as a code template for faster C development.
Amen.
Kragg wrote (in his reply to ttfkam): Prototyping in a higher-level language (c# is easy, java everyone knows) is a superb idea, provided you - can release the final product as interpreted, with slow execution speed
Most programs spend 90% of their CPU time executing 10% of their code. If that 10% is optimized in a low-level language such as C, a large-scale interpreted program can boast performance that's virtually indistinguishable from an equivalent program written entirely in a low-level langauge. However, there's likely to be a huge difference in programmer productivity.
As a reference, see this Dr. Dobbs article, which states: """... 90 percent of the software's running time occurs in only 10 percent of the code. This is the whole basis for virtual memory: Potentially, a program can run at full speed with only 10 percent of itself--or whatever the working set is--loaded into memory at any given time. Unlike that nasty segment stuff, the programmer does not specify any of this in advance. The operating system "discovers" a program's working set on-the-fly, through page faults. """
- can afford the time to port all to C, in which case DO, this is an excellent way to make a watertight C program
Why port 90% of the application's code to a low-level and less productive programming language, when that 90% will inevitably evolve and require maintenance as the program is utilized in unforeseen ways? I've never written a large program that didn't end up having features added incrementally over a long period of time after the initial release.
- are happy to learn how to make managed code/vm code call to native and vice-versa (this is far from a trivial problem)
If it's "far from a trivial problem", you're using the wrong tool.
Take Python, for example: it's simple to interface between Python and C using Python's C API. Recently, a tool named Pyrex has appeared that makes it almost trivial. Pyrex is amazing.
Kragg suggested prototyping in C# or Java, but Python surpasses both of those as a prototyping tool. Python is higher-level than C# or Java (and thus better suited to prototyping and/or malleable fusion with C) because it features: - dynamic typing ("dynamic", not "weak" like Perl) - no obession with a particular programming paradigm; use procedural, functional, or OO as appropriate - high-level data structures built into the language - more convenient dynamic code loading - interactive development at a "Python prompt" (the value of this cannot be overestimated) - no separate compilation step in the edit-test-debug cycle - more concise syntax - excellent interface capabilities to C (or C++ via Boost.Python, or Java via Jython)
I suggest that the fusion of a truly high-level (higher than Java-level) language with C is far more broadly applicable than Kragg claims.
I think with Gnome 2.2 when things get a little more polished and the apps ported, Evolution 1.2, Galeon 2, etc, then the GNU/Linux desktop will really start to become viable for many people.
Congratulations! You've just delivered the 958,174,596th instance of The Prediction.
"There are lots of things theorists predict on the basis of what's known and what's already been found," Mr. Siegfried explained in a telephone interview. "The distinction with prediscovery is that theorists discover the existence of something observers have never seen. It's one thing to figure out an explanation for the observation. It's another thing altogether to suggest something exists that no one had any idea about beforehand."
Unlike, say, Leonardo da Vinci's sketches of "flying machines" or Jules Verne's descriptions of submarines and televisions decades before such objects were ever made, scientific prediscoveries, as Mr. Siegfried defines them, are not human inventions awaiting technological realization, but rather insights into the nature of reality.
Where is Mr. Holy Workaholic Philip Greenspun now?
He is, in his own words, "Philip Greenspun, 38 years old, retired...", and he's travelling in Alaska. He must be pretty damn disgusted by those "slackers" who work a mere forty hours a week.
Hmm... I kinda missed your "with little or no application rewrites along the way" part, but with regard to scalability/ease/completeness of language support alone, my post above is still valid.
Your wish for such standards-compliance is unlikely to be granted anytime soon, though. As you know, the various database all use different procedural SQL language for their stored procedures and triggers, and in that area there seems to be no push for standardization whatsoever.
Great, YET ANOTHER article on open source databases that fails to mention SAPDB or Firebird, even though they're both a hell of a lot better than MySQL in most respects (especially true of SAPDB).
Most journalists (and 75% of Slashdotters) apparently are ignorant of the advanced features offered by the "big boy" commercial databases they so love to deride; they end up doing all open source databases a disservice by equating all open source databases (in the mind of the pointy-haired boss) with the puppy of the household, MySQL.
"""while there are ways already defined to call MySQL, PostGres, BerkeleyDB (SleepyCat), etc. from those languages, it appears that I would need to write an access method to Firebird by myself"""
Not so for Python; the kinterbasdb project was revitalized in January, and is now quite stable: http://kinterbasdb.sourceforge.net/
Among them, a somewhat silly but remarkably prescient prediction of World-Wide-Web-like tech:
Of course the Dobsons have a television set. But it is connected with the telephones as well as with the radio receiver, so that when Joe Dobson and a friend in a distant city talk over the telephone they also see each other. Businessmen have television conferences. Each man is surrounded by half a dozen television screens on which he sees those taking part in the discussion. Documents are held up for examination; samples of goods are displayed. In fact, Jane Dobson does much of her shopping by television. Department stores obligingly hold up for her inspection bolts of fabric or show her new styles of clothing.
It's amazing how much harder some things turned out to be than was anticipated:
Automatic electronic inventions that seem to have something like intelligence integrate industrial production so that all the machines in a factory work as units in what is actually a single, colossal organism. In the Orwell Helicopter Corporation's plant only a few trouble shooters are visible, and these respond to lights that flare up on a board whenever a vacuum tube burns out or there is a short circuit. By holes punched in a roll of paper, every operation necessary to produce a helicopter is indicated.
One of the more remarkable electronic machines of 2000 is a development of one on which hundreds of thousands of dollars had been spent in the middle years of the 20th century by Dr. Vladimir Zworykin and Dr. John von Neumann. The purpose of this improved Zworykin-Von Neumann automaton is to predict the weather with an accuracy unattainable before 1980. It is a combination of calculating machine and forecaster. The calculator solves thousands of separate equations in a minute; the automatic forecaster carries out the computer's instructions and predicts the weather from hour to hour. In 1950, meteorologists had no time to deal with the 50-odd variables that should have been mathematically handled to predict the weather 24 hours in advance.
Then, the consumers will forget Linux, not knowing that there are dozens of different flavors out there.
Oh, come on! Most consumers today either haven't heard of Linux, or they think that "Linux is a company", and know virtually nothing about it except that it's considered a threat to Microsoft because some article they read said so.
I don't dispute that AOLinux would probably edge out other Linices in the consumer consciousness, but Linux's current presense in the consumer consciousness is next to nothing, so would AOLinux really do any harm? Even if Microsoft Windows trounced AOLinux, and Linux in general subsequently receded from Average Joe's mind, Linux would be in no worse a position on the desktop than it is today. Besides, while AOLinux's would be unlikely to defeat Windows, it would probably make more progress than today's laughably techy "consumer-oriented distributions".
There's an interesting interview on News.com with Virginia governor Jim Gilmore about Internet taxation. One of his points is that Internet taxation might fragment the Internet as a global community. Could it be that there exists at least one politician with a clue about technological issues? Here's one of the Q/As:
"""
CNET: The European Union is moving toward requiring companies located outside of its borders, especially those in the United States, to collect taxes on digital downloads. What do you think about that? Is that something that the U.S. government should try to block?
Gilmore: This is very draconian. It is tamping down commerce. It raises the specter of Internet sellers across the rest of the world being discriminated against and not having the opportunity to take advantage of their own national philosophy and system of government. And I certainly hope that the European Union doesn't go that way.
I think that it's clear that we should not be taxing Internet access. I don't think we should be taxing downloaded products. And I don't think that we should be taxing retail either. In order to even achieve it, you would have to try to track down people as to what their location is, what their private business is in order to force people beyond their jurisdictions to collect and remit taxes. And that's bad policy.
Slashdot Mirror
Don't worry. By the time ReactOS reaches version 1.0, those patents will expire. Remember, patent is valid for 20 years only.
Haha! We've already thought of this; here's our plan for accelerated development:
Implement the ReactOS kernel as a GNU Hurd daemon, with built-in 3d graphics support based on the Duke Nukem Forever engine (running on top of WINE's DirectX layer).
The built-in 3d engine will be used as the basis for an implementation of the Berlin windowing API, the suggested application interface to which is the Perl 6 virtual machine. We should have all of this up and running on the Indrema console within a mere three months!
Then, we plan to hire Loki games to implement an X-Windows compatibility layer, and we've arrived!
Ok but te swing api is written in java and compiled into java bytecode. Only the lowlevel graphic calls of the vm are implemented in native code.
I've done a fair amount of Swing programming, so I realize how it's implemented. I really admire the software engineering evident in Swing; it's elegantly customizable through and through.
However, the performance (in both CPU and memory) really sucks. Don't tell me it doesn't; don't tell me it's fixed in Java 1.4. I use a Swing text editor all day every day on Java 1.4.1_01 on Windows 2000 on an Athlon XP 2100+ with 512 MB RAM, and it's still sluggish. This rules out Swing as a serious choice for client-side development in the typical corporate environment, where the client machines are elderly and feeble. That's a real pity.
I've used wxPython quite a bit, and I love it.
I do have one complaint: single-line text controls can't be right-aligned (e.g., for monetary values)! I believe this is a wxWindows limitation rather than a wxPython limitation, and wxPython includes a dirty hack to circumvent it, but to me the omission of this feature is senseless.
In recent releases, wxPython has begun to incorporate numerous "high-level composition widgets" that AFAIK don't exist in wxWindows itself, such as calendar controls. They're aimed at making the wxPython programming experience even more high-level, and they succeed admirably.
Unlike some other posters here, I do not find the C++-centric documentation annoying; the documentation is, in fact, excellent. For the most part, the wrapping of the C++ wxWindows API in Python does not introduce any API mismatch; in cases where it must, the transition is handled with a reasonable sacrifice in elegance.
wxWindows uses native widgets, so there are no look and feel problems.
Thanks to Robin Dunn and the wxWindows team for a job well done.
Not familar with python, although I know one form of using it is interperted via a hash-bang (#!/usr/loval/bin/python). However, java is compiled into bytecode run by a jvm en emulator for a system that doesn't exist.
I was referring to the GUI toolkit itself being written in C++ (and thus compiled/fast), not necessarily the surrounding application.
Though I have not used Java, I am told the API is very similar in style (to Swing?). The upside to Qt is that it is compiled and uses C++, so it is fast and you can mix and match system code. A common myth about cross-platform software is that you must cater to the lowest common denominator, which is absolutely not true with Qt.
Even if you are doing development for a single platform, you may still want to use Qt. It is generally easier to use than whatever is native... and it secures you that 'out' in case you want to port later.
It's worth noting that all of the "upsides" you mention here also apply to SWT (for Java), PyQT (for Python), and wxPython (for Python).
It's not necessary to switch from a higher level language to C++ just to use a fast, cross-platform GUI toolkit that renders via native widgets.
Don't confuse Zope with Python. That's like condemning C because Windows 3.0 is written in it. Zope is a bloated monstrosity that happens to be written in Python; Python itself is an elegant gem.
ttfkam wrote:
... 90 percent of the software's running time occurs in only 10 percent of the code. This is the whole basis for virtual memory: Potentially, a program can run at full speed with only 10 percent of itself--or whatever the working set is--loaded into memory at any given time. Unlike that nasty segment stuff, the programmer does not specify any of this in advance. The operating system "discovers" a program's working set on-the-fly, through page faults.
Do it in a higher-level language first. Make sure your algorithms are clean and efficient. If and only if you see a performance or resource problem do you rework portions(!!!) in C. As a bonus, the higher level language acts as a code template for faster C development.
Amen.
Kragg wrote (in his reply to ttfkam):
Prototyping in a higher-level language (c# is easy, java everyone knows) is a superb idea, provided you
- can release the final product as interpreted, with slow execution speed
Most programs spend 90% of their CPU time executing 10% of their code. If that 10% is optimized in a low-level language such as C, a large-scale interpreted program can boast performance that's virtually indistinguishable from an equivalent program written entirely in a low-level langauge. However, there's likely to be a huge difference in programmer productivity.
As a reference, see this Dr. Dobbs article, which states:
"""
"""
- can afford the time to port all to C, in which case DO, this is an excellent way to make a watertight C program
Why port 90% of the application's code to a low-level and less productive programming language, when that 90% will inevitably evolve and require maintenance as the program is utilized in unforeseen ways? I've never written a large program that didn't end up having features added incrementally over a long period of time after the initial release.
- are happy to learn how to make managed code/vm code call to native and vice-versa (this is far from a trivial problem)
If it's "far from a trivial problem", you're using the wrong tool.
Take Python, for example: it's simple to interface between Python and C using Python's C API. Recently, a tool named Pyrex has appeared that makes it almost trivial. Pyrex is amazing.
Kragg suggested prototyping in C# or Java, but Python surpasses both of those as a prototyping tool. Python is higher-level than C# or Java (and thus better suited to prototyping and/or malleable fusion with C) because it features:
- dynamic typing ("dynamic", not "weak" like Perl)
- no obession with a particular programming paradigm; use procedural, functional, or OO as appropriate
- high-level data structures built into the language
- more convenient dynamic code loading
- interactive development at a "Python prompt" (the value of this cannot be overestimated)
- no separate compilation step in the edit-test-debug cycle
- more concise syntax
- excellent interface capabilities to C (or C++ via Boost.Python, or Java via Jython)
I suggest that the fusion of a truly high-level (higher than Java-level) language with C is far more broadly applicable than Kragg claims.
Makes me happy I just got laid off
1. I have plenty of time to play with it.
2. I don't have to worry about someone doing it to me.
Shit, even the gay porn industry is laying people off these days?
I think with Gnome 2.2 when things get a little more polished and the apps ported, Evolution 1.2, Galeon 2, etc, then the GNU/Linux desktop will really start to become viable for many people.
Congratulations! You've just delivered the 958,174,596th instance of The Prediction.
From the article:
"There are lots of things theorists predict on the basis of what's known and what's already been found," Mr. Siegfried explained in a telephone interview. "The distinction with prediscovery is that theorists discover the existence of something observers have never seen. It's one thing to figure out an explanation for the observation. It's another thing altogether to suggest something exists that no one had any idea about beforehand."
Unlike, say, Leonardo da Vinci's sketches of "flying machines" or Jules Verne's descriptions of submarines and televisions decades before such objects were ever made, scientific prediscoveries, as Mr. Siegfried defines them, are not human inventions awaiting technological realization, but rather insights into the nature of reality.
Where is Mr. Holy Workaholic Philip Greenspun now?
He is, in his own words, "Philip Greenspun, 38 years old, retired...", and he's travelling in Alaska. He must be pretty damn disgusted by those "slackers" who work a mere forty hours a week.
Hmm... I kinda missed your "with little or no application rewrites along the way" part, but with regard to scalability/ease/completeness of language support alone, my post above is still valid.
Your wish for such standards-compliance is unlikely to be granted anytime soon, though. As you know, the various database all use different procedural SQL language for their stored procedures and triggers, and in that area there seems to be no push for standardization whatsoever.
1. Small, lite-duty engine mostly for embedded or small-footprint apps. Subset of lanugage of #2.
SQLite: http://www.hwaci.com/sw/sqlite/
2. Full language, but lacking performance tuning. Mostly for development and smaller shops.
Firebird: http://firebird.sourceforge.net/
3. "Big-iron" version that has full language and performance tuning features.
SAPDB (almost, but still not up to Oracle's standards): http://sapdb.org/
Great, YET ANOTHER article on open source databases that fails to mention SAPDB or Firebird, even though they're both a hell of a lot better than MySQL in most respects (especially true of SAPDB).
Most journalists (and 75% of Slashdotters) apparently are ignorant of the advanced features offered by the "big boy" commercial databases they so love to deride; they end up doing all open source databases a disservice by equating all open source databases (in the mind of the pointy-haired boss) with the puppy of the household, MySQL.
Mussolini did say: "Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power."
The governmental system he described sounds kind of familiar, doesn't it?
"""while there are ways already defined to call MySQL, PostGres, BerkeleyDB (SleepyCat), etc. from those languages, it appears that I would need to write an access method to Firebird by myself"""
Not so for Python; the kinterbasdb project was revitalized in January, and is now quite stable:
http://kinterbasdb.sourceforge.net/
"Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power." - Benito Mussolini
> If there were a big government database, then a
> simple "SELECT * FROM WHERE Citizen=foo" would be,
> in my mind, a violation of the 4th amendment.
In my mind, it would be nothing more than a violation of SQL syntax.
My God, I hope they had plenty of security personnel on hand to prevent him from getting mobbed by the fans!
And if that fails, we shall see if these wonderful machines can withstand the attack of a human with a sledgehammer!
The sledgehammer approach has been tried before; it didn't work.
Also of interest: a set of predictions from 1950 entitled "Miracles of the Next Fifty Years".
Among them, a somewhat silly but remarkably prescient prediction of World-Wide-Web-like tech:
Of course the Dobsons have a television set. But it is connected with the telephones as well as with the radio receiver, so that when Joe Dobson and a friend in a distant city talk over the telephone they also see each other. Businessmen have television conferences. Each man is surrounded by half a dozen television screens on which he sees those taking part in the discussion. Documents are held up for examination; samples of goods are displayed. In fact, Jane Dobson does much of her shopping by television. Department stores obligingly hold up for her inspection bolts of fabric or show her new styles of clothing.
It's amazing how much harder some things turned out to be than was anticipated:
"50-odd variables"... :)
the only IT-sector that is currently booming, and that will continue to do so with almost absolute certainty, is the anti-virus sector
I send you this message in order to bolster my job prospects
Then, the consumers will forget Linux, not knowing that there are dozens of different flavors out there.
Oh, come on! Most consumers today either haven't heard of Linux, or they think that "Linux is a company", and know virtually nothing about it except that it's considered a threat to Microsoft because some article they read said so.
I don't dispute that AOLinux would probably edge out other Linices in the consumer consciousness, but Linux's current presense in the consumer consciousness is next to nothing, so would AOLinux really do any harm? Even if Microsoft Windows trounced AOLinux, and Linux in general subsequently receded from Average Joe's mind, Linux would be in no worse a position on the desktop than it is today. Besides, while AOLinux's would be unlikely to defeat Windows, it would probably make more progress than today's laughably techy "consumer-oriented distributions".
There's an interesting interview on News.com with Virginia governor Jim Gilmore about Internet taxation. One of his points is that Internet taxation might fragment the Internet as a global community. Could it be that there exists at least one politician with a clue about technological issues? Here's one of the Q/As:
"""CNET: The European Union is moving toward requiring companies located outside of its borders, especially those in the United States, to collect taxes on digital downloads. What do you think about that? Is that something that the U.S. government should try to block?
Gilmore: This is very draconian. It is tamping down commerce. It raises the specter of Internet sellers across the rest of the world being discriminated against and not having the opportunity to take advantage of their own national philosophy and system of government. And I certainly hope that the European Union doesn't go that way.
I think that it's clear that we should not be taxing Internet access. I don't think we should be taxing downloaded products. And I don't think that we should be taxing retail either. In order to even achieve it, you would have to try to track down people as to what their location is, what their private business is in order to force people beyond their jurisdictions to collect and remit taxes. And that's bad policy.
""""Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power." - Benito Mussolini