I didn't believe it but I was recently forced to use XSLT to generate unit testing code. So I read the XPath and XSLT specs (not long, easy reading) and thought I would document my personal library of C modules by defining the interfaces as XML and running an XSLT processor (Xalan-J) on it to generate an html reference, man pages, postscript, header files, etc. I'm still in the middle of it and trying to reduce the XML model but I have generated man pages and a very nice HTML reference. Here's an example. As you can see the style sheet isn't quite right. I'm working on it right now. If someone knows XSLT and wants to help, let me know...
Actually, it was (gasp) MICROSOFT (gasp). Think about that before you flame!
Actually this isn't exactly true. Originally IBM did contract MS to write OS/2 however by the time they reached version 3 Windows started to gain in popularity so they focused on that and IBM took over OS/2 entirely. If you read the second link a little more carefully it claims IBM re-wrote everything starting from the 1.x base. That became OS/2 Warp and MS took said version 3 and renamed it to Windows NT.
There are occasional engineering failures, but none as widespread as programming errors. Maybe because we're still forging new ground so quickly that it can't be expected to have solid results.
The problem is the Entropy or rather the lack of it. Entropy is that Law of Thermodynamics that states systems have a tendency toward disorder. With software there is little decay. Even with the possibility of hardware failure things don't just fall apart. If your app gets freaky you recycle it and it's re-born. Linked lists don't spontaniously loose their links in a digital world.
2) Did anyone consider that maybe the MS Java VM being faster than the Sun Java VM had something to do with MS not makeing their full APIs available for other companies to use? Just a thought.
No. In the early days of VMs, MS's was indeed faster but a Java VM is an interpreter/compiler written in C so this has nothing to do with "APIs".
What they did do wrong is they deliberately left out things like Java Native Interface (JNI) and Remote Method Invocation (RMI) which are elemental to the Java language. When Sun cried "foul!" (and rightly so) MS just stonewalled the platform.
If MS had played nice and genuinely supported the Java platform Java would be a much bigger success than it is today. Just imagine how awesome it would be if there was a native Win32 GUI API. Of course it never happend so we're forced to putz along with the Swing library.
It would be far more effective to isolate and the concepts associated with changing the behavior of a system (or group of systems) rather than just mapping check boxes to booleans and selects to lists.
Like AIX's smit ?
Humm, smit does look interesting. I particularly like the part about dropping out to a shell with the command on the commandline without actually executing it right away. That's a great idea. Are you familiar with this program? If so, what are it's weaknesses?
I absolutely beleive their should be a/etc/xml-config hierarchy, optionally populated, with translators between the old and new formats.
Once done, any of the usual xml property editors can be used to edit same.
No. This is a very naive approach that does nothing to solve the real problems. XML is a file format. This UnixConfig issue will not be solved with a file format. We are not writing a property editor.
better thing is to have prolog language based database of configuration that is able to keep facts from text files and put it into system of knowledge. You will be able to ask that base non-trivial questions about your configuration, which is not possible in other approaches.
If if calculates dependencies between functionality then it sounds like a great idea. Otherwise I'm not convinced this "system of knowledge" would really be useful.
Regarding the text file vs. database issue, I suppose the config file data could be parsed on demand and cached for the prolog interpreter. You would just have to come up with a normalized data structure to address every datum and then load the file(s) when one of those datums is trapped. That's really how a database works albeit this UnixConfig Prolog Interpreter version would be a bit more complex due to the inconsistent nature of datafiles under it.
Unfortunately, don't see app developers committing to it though. Having a 'prolog language' backend must not be required for the app to run at least. And it cannot be another daemon mucking up my process table! Make it a lib and use shared memory pls:~)
I was ready to post my message to the UnixConfig message board but apparently I wasn't logged into sourceforge. I think I'll just post my comments in response to the documents prepared there here instead:
--8<--
A core system would handle parsing, verification and storage of text-based configuration files in one or two basic formats.
We cannot do this. We must be able to handle arbirary file formats. There is no way we will get anyone to change the format of Samba's smb.conf, Apaches truly arcane httpd.conf, or DNS zone files for example. We *could* standardize on a uniform in memory representation but I'm not in favor of that either. I think we have to go all the way up to the API level (e.g. int exports_add(const char path, int flags,...,{SMB|HTTP|NFS|...}).
The master copy of the configuration is always left in the native text files (in/etc and ~/.*). This is where linuxconf falls down, it starts keeping its own copy of the configuration, which means if linuxconf takes over your system and then later something stuffs up, it's difficult to edit a text file manually without losing linuxconf completely.
Absolutely. The confuration files *are* the database. On a separate front, we might provide an idealized open-ended application configuration library for assisting new development but I think there would have to be some weight behind the main front before developers would even consider it. That might also give us the opportunity to normalize on a few file formats (e.g. scanf, WINI, XML).
Another option is to allow plugins to handle how the data is stored.
That's a goodish idea but there are interfacing issues. By "plugins" are you suggesting one could write their parser in C or C++ or Perl? At what point do you normalize on a common language? Keep in mind this has nothing to do with *file* formats.
In order for some features to work, it might be necessary for application developers to switch to the use of the configuration manager for their internal routines.
We cannot do this. We must transparently manage data within the configuration files of the applications themselves. There is no way in heck we'll get app developers to convert. Their intrests are far more important in their mind (and they're probably rigth).
A key element would be the configuration format description file. This would list the configuration options for a given piece of software, giving for each one the name, type (boolean, list, string, filename, internet address, etc.), options, category (for sub-sections within the config), and help text (short and long).
You'll end up with a glorafied property editor and that's not what you want. What I mean by this is that you do NOT just want to map configuration options within application config files to the configuration options of whatever tool we're talking about. This is one of the greatest failures of UNIX confuration tools. It would be far more effective to isolate and the concepts associated with changing the behavior of a system (or group of systems) rather than just mapping check boxes to booleans and selects to lists. The KDE runlevel editor is a spectacular example of this failure; it does not isolate the concept of what it means to change the initialization behavor of your system.
For example, rather than writing configuration screens for Samba, Apache, Pro-FTPd, and NFS exports, write an "Exports" module that handles all of them uniformly. They all do essentially the same thing; make a portion of your filesystem available as a network service. Similarly, instead of having a PPP dialer, make a module that controls your "Network Interfaces" (RH has largely done this working PPP into network-scripts). Again, isolate concepts rather than parameterize configuration options.
The only way to become a good programmer is to write lots of programs so in this respect I suppose writing code for an OpenSource project is just as good as any. From a corporate job marketability perspective it's virtually useless however. Most employers will not know what OpenSource means and will probably think you're some kind of communist code hippie if you try to explain it to them. Best leave it off the resume unless you know the reader will appreciate it. Rather than procrastinate working on another worthless runlevel editor for Joe-Bobs-Great-But-Kinda-Slow-Desktop-Environment, you would be much wiser to make your skills available to a professor writing ulitmately useless code. Right now, students should be worried about grades and diplomas, certs, and boring stuff like that. It all comes down to peices of paper folks. Don't fool yourself into thinking your enthusiasm for writing Free code will help you.
Well, I don't remember the exact details although I think it had to do with how CPU ids where initially assigned on boot rather than how processes were actively schedualed. Regardless I think the effect I described is accurate. I wish I could remember where I saw the discussion.
Wow, kinda sucks if your OS has a per CPU license, like NT and Win2K server!
You want to know something even better? The way CPU ids are managed is by bits in an integer. Every other bit represents the "virtual" CPUs. Now when the Windows kernel is selecting CPUs for schedualing purposes it enumerates them in order. This means that when a process is schedualed to run on the next available CPU theres a very good chance it will get a virtual CPU even though a real CPU is completely free. So if you have an 4 CPU machine (4 real, 4 virtual means 8 Hyperthreaded total) and you have 4 processes that can run only 2 real CPUs will be used.
Ok, ok, ok stop laughing. Here's the kicker. MS fixed this. But did they provide the fix to there customers? No. You have to get the Data Center version to enumerate your CPUs properly!
Take a look at the Flyweight pattern in Design Patterns [amazon.com] book. Yep, a model of a word processor where every single character is represented by a very light-weight reusable object.
True, although that example uses the same object instances over and over. You ultimately only have 100 or so object types to represent different characters. I suppose that's what a Flyweight is (donno, have the book, never quite committed it to memory). Actually, the more I think about it, the more I think the approach is flawed. It might work for a small character set but what if you're using UCS codes like UTF-8? The only reason you would want to have an object to represent a character and not just use an integer would be if you wanted to actually control the rendering of glyphs as subviews of views. Even then it's probably not a good idea. Those examples are just examples.
Whether OO "should" model the real world is heavily debated among OO fans. Modeling the "real world" seams mostly about modeling one's personal viewpoint
I said "real-world" because the OP used that term. If you look at the response to the other thread you'll see my position is more sophisticated than that.
In short, you don't model the "real-world", you model concepts which may or may not encompass tangable entities.
The point of the cards example is that in real life you don't really have self shuffling decks of cards
I understood you perfectly but you're not modeling "real-life". Decouple yourself from the physical world man! Of course the deck should have the capcity to shuffle itself. My point is that there is nothing wrong with this in the context of modeling a game. If you were modeling a person handling some cards it might not.
First, but what is the purpose of making modeling easier? Isn't the goal of almost all new language to make programming easier in some respect.
Everything's hard until you understand it. OO is easier once you understand it because with 10 lines of OO preamble you can create a seeming simple relationship that can greatly reduce the complexity of a program. The compiler now takes care of things that are not possible in C (without potentially large switch statements or ugly lookup tables).
Second, I am not one one of the "objects as real-world entities" people. I believe strongly that to effectively partition work -- to make programming more tractable -- many times you will create work partitions and create objects that have no correlation to the real-world.
This is wrong. Any objects you define do correlate to the "real-world" (your model). If they dont your program will not make sense. You have taken a wrong turn somewhere.
A contrived example would be a deck of cards. Imagine that you make each card an object, then you have a deck object, and a dealer object.
Ok, sounds good to me.
In the real-world the dealer would shuffle a deck, but in our code this responsibility would fall on the deck, but the dealing mechanics would probably rest with the dealer.
What are you modeling? Are you modeling a deck of cards and how a dealer physically interacts with them or are you modelling a game? You're probably modeling poker or black jack right?. OO could be real handy for abstracting which game of cards you're modeling. You're probably not modeling a physical human being "handling" some cards. See the difference?
I think that to effectively use the OO paradigm, you need to really abuse it.
OO is only one attempted solution to the larger problem of making programming easier on the programmer.
No. You're thinking of MSVC++ and drag and drop programming. OO is about modeling and it can be very effective.
It does this by trying to compartmentalize functionality and seperate implementation from usage.
This is the stuff trolls are made of Jayson. OO does not "compartmentalize" and it is not about contract programming. You have a very superficial understanding of OO principles.
Each instance of an object in a program is a model. You think about what it is conceptually that you are modeling and derive classes for those concepts. In practice these objects usually have hierarchial and recursive relationships. For example a stock is a security but a security is not a stock because it could be a fund. Or a WWW document has elements and frames where frames may be sub documents. These relationships are found everywhere and can be modeled most effectively using OO priciples. That's not to say you should use OO for everything (e.g. you wouldn't want to represent each character in a document using a separate object). Indeed I don't beleive 9 out of 10 developers using an OO language are actually writing OO code. It's modular at best. To use it effectively is non-trivial.
To see how OO has eschewed its own features just look at how delegation is favored over inheritance. This is a functional way of programming.
Like I was saying above, the results of OO are most effective when used strategically. The highest level superstructure benifits greatly from an OO organization. But using OO to a fine degree is not necesarily good.
Overrated. It must be because I'm getting along pretty well with vi.
simplified GUI design and event handling
This is a tough one. The GUI frameworks are unconditionally complicated. Use what you're team is most familar with.
advanced error handling
errno? Just kidding. But real exception handling is pretty expensive. Those are really your only options besides maybe something like this.
advanced object oriented design including multiple inheritance, abstract classes, and garbage collection
This is kinda funny because multiple inheritance a feature that is only justified in a very small number of cases (I believe it should be avoided alltogther) and is a really good way to get into trouble lick-ity-split, abstact classes is mearly a convention and really doesn't buy you anything in terms of functionality and garbage collection makes languages far too forgiving to the idiot using crappy data structures and algorithms.
full support for operator and function overloading
Well, you just want everything and the kitchen sink don't you? They did that already, it's that morass of a language called C++. Do the next guy a favor and pick features that suit the needs of the application rather than features you think will make it easier for you or the result will be indecipherable.
and portable (at compile-time) across various platforms
Why? Is this really that great? The XOpen and ANSI standards are designed to reduce system dependancies to the point where this shouldn't be an that much of an issue. Even if you're not using C/C++ the language binding likely is. In either case, as long as you consider the scope of those specifications your code should be portable without too much effort. Of course if you cheat and call those Win32 API functions it wouldn't matter what language you're using.
Sounds like you're trolling for some super Java/C++ language. It will probably never happen and rightly so because it would undoubtedly result in unrecognisable code that's dog slow.
I'm willing to bet your application could be written very well with plain ANSI C a few additional libraries and some C++ for the GUI.
Doesn't this patch just add a bunch of extra schedualling points in stategic places? That's not technically "preemptible". Or perhaps I'm thinking of one of the other "preemptible" kernel patches:~)
Slashdot Mirror
I didn't believe it but I was recently forced to use XSLT to generate unit testing code. So I read the XPath and XSLT specs (not long, easy reading) and thought I would document my personal library of C modules by defining the interfaces as XML and running an XSLT processor (Xalan-J) on it to generate an html reference, man pages, postscript, header files, etc. I'm still in the middle of it and trying to reduce the XML model but I have generated man pages and a very nice HTML reference. Here's an example. As you can see the style sheet isn't quite right. I'm working on it right now. If someone knows XSLT and wants to help, let me know...
We just wait ~50 years to run out of fossil fuels.
Actually, it was (gasp) MICROSOFT (gasp). Think about that before you flame!
Actually this isn't exactly true. Originally IBM did contract MS to write OS/2 however by the time they reached version 3 Windows started to gain in popularity so they focused on that and IBM took over OS/2 entirely. If you read the second link a little more carefully it claims IBM re-wrote everything starting from the 1.x base. That became OS/2 Warp and MS took said version 3 and renamed it to Windows NT.
There are occasional engineering failures, but none as widespread as programming errors. Maybe because we're still forging new ground so quickly that it can't be expected to have solid results.
The problem is the Entropy or rather the lack of it. Entropy is that Law of Thermodynamics that states systems have a tendency toward disorder. With software there is little decay. Even with the possibility of hardware failure things don't just fall apart. If your app gets freaky you recycle it and it's re-born. Linked lists don't spontaniously loose their links in a digital world.
2) Did anyone consider that maybe the MS Java VM being faster than the Sun Java VM had something to do with MS not makeing their full APIs available for other companies to use? Just a thought.
No. In the early days of VMs, MS's was indeed faster but a Java VM is an interpreter/compiler written in C so this has nothing to do with "APIs".
What they did do wrong is they deliberately left out things like Java Native Interface (JNI) and Remote Method Invocation (RMI) which are elemental to the Java language. When Sun cried "foul!" (and rightly so) MS just stonewalled the platform.
If MS had played nice and genuinely supported the Java platform Java would be a much bigger success than it is today. Just imagine how awesome it would be if there was a native Win32 GUI API. Of course it never happend so we're forced to putz along with the Swing library.
It would be far more effective to isolate and the concepts associated with changing the behavior of a system (or group of systems) rather than just mapping check boxes to booleans and selects to lists.
Like AIX's smit ?
Humm, smit does look interesting. I particularly like the part about dropping out to a shell with the command on the commandline without actually executing it right away. That's a great idea. Are you familiar with this program? If so, what are it's weaknesses?
I absolutely beleive their should be a /etc/xml-config hierarchy, optionally populated, with translators between the old and new formats.
Once done, any of the usual xml property editors can be used to edit same.
No. This is a very naive approach that does nothing to solve the real problems. XML is a file format. This UnixConfig issue will not be solved with a file format. We are not writing a property editor.
better thing is to have prolog language based database of configuration that is able to keep facts from text files and put it into system of knowledge.
:~)
You will be able to ask that base non-trivial questions about your configuration, which is not possible in other approaches.
If if calculates dependencies between functionality then it sounds like a great idea. Otherwise I'm not convinced this "system of knowledge" would really be useful.
Regarding the text file vs. database issue, I suppose the config file data could be parsed on demand and cached for the prolog interpreter. You would just have to come up with a normalized data structure to address every datum and then load the file(s) when one of those datums is trapped. That's really how a database works albeit this UnixConfig Prolog Interpreter version would be a bit more complex due to the inconsistent nature of datafiles under it.
Unfortunately, don't see app developers committing to it though. Having a 'prolog language' backend must not be required for the app to run at least. And it cannot be another daemon mucking up my process table! Make it a lib and use shared memory pls
I was ready to post my message to the UnixConfig message board but apparently I wasn't logged into sourceforge. I think I'll just post my comments in response to the documents prepared there here instead:
...,{SMB|HTTP|NFS|...}).
/etc and ~/.*). This is where linuxconf falls down, it starts keeping its own copy of the configuration, which means if linuxconf takes over your system and then later something stuffs up, it's difficult to edit a text file manually without losing linuxconf completely.
--8<--
A core system would handle parsing, verification and storage of text-based configuration files in one or two basic formats.
We cannot do this. We must be able to handle arbirary file formats. There is no way we will get anyone to change the format of Samba's smb.conf, Apaches truly arcane httpd.conf, or DNS zone files for example. We *could* standardize on a uniform in memory representation but I'm not in favor of that either. I think we have to go all the way up to the API level (e.g. int exports_add(const char path, int flags,
The master copy of the configuration is always left in the native text files (in
Absolutely. The confuration files *are* the database. On a separate front, we might provide an idealized open-ended application configuration library for assisting new development but I think there would have to be some weight behind the main front before developers would even consider it. That might also give us the opportunity to normalize on a few file formats (e.g. scanf, WINI, XML).
Another option is to allow plugins to handle how the data is stored.
That's a goodish idea but there are interfacing issues. By "plugins" are you suggesting one could write their parser in C or C++ or Perl? At what point do you normalize on a common language? Keep in mind this has nothing to do with *file* formats.
In order for some features to work, it might be necessary for application developers to switch to the use of the configuration manager for their internal routines.
We cannot do this. We must transparently manage data within the configuration files of the applications themselves. There is no way in heck we'll get app developers to convert. Their intrests are far more important in their mind (and they're probably rigth).
A key element would be the configuration format description file. This would list the configuration options for a given piece of software, giving for each one the name, type (boolean, list, string, filename, internet address, etc.), options, category (for sub-sections within the config), and help text (short and long).
You'll end up with a glorafied property editor and that's not what you want. What I mean by this is that you do NOT just want to map configuration options within application config files to the configuration options of whatever tool we're talking about. This is one of the greatest failures of UNIX confuration tools. It would be far more effective to isolate and the concepts associated with changing the behavior of a system (or group of systems) rather than just mapping check boxes to booleans and selects to lists. The KDE runlevel editor is a spectacular example of this failure; it does not isolate the concept of what it means to change the initialization behavor of your system.
For example, rather than writing configuration screens for Samba, Apache, Pro-FTPd, and NFS exports, write an "Exports" module that handles all of them uniformly. They all do essentially the same thing; make a portion of your filesystem available as a network service. Similarly, instead of having a PPP dialer, make a module that controls your "Network Interfaces" (RH has largely done this working PPP into network-scripts). Again, isolate concepts rather than parameterize configuration options.
The only way to become a good programmer is to write lots of programs so in this respect I suppose writing code for an OpenSource project is just as good as any. From a corporate job marketability perspective it's virtually useless however. Most employers will not know what OpenSource means and will probably think you're some kind of communist code hippie if you try to explain it to them. Best leave it off the resume unless you know the reader will appreciate it. Rather than procrastinate working on another worthless runlevel editor for Joe-Bobs-Great-But-Kinda-Slow-Desktop-Environment, you would be much wiser to make your skills available to a professor writing ulitmately useless code. Right now, students should be worried about grades and diplomas, certs, and boring stuff like that. It all comes down to peices of paper folks. Don't fool yourself into thinking your enthusiasm for writing Free code will help you.
Well, I don't remember the exact details although I think it had to do with how CPU ids where initially assigned on boot rather than how processes were actively schedualed. Regardless I think the effect I described is accurate. I wish I could remember where I saw the discussion.
Uh, how about never. This is only an issue on machines with 4 procs or more.
Wow, kinda sucks if your OS has a per CPU license, like NT and Win2K server!
You want to know something even better? The way CPU ids are managed is by bits in an integer. Every other bit represents the "virtual" CPUs. Now when the Windows kernel is selecting CPUs for schedualing purposes it enumerates them in order. This means that when a process is schedualed to run on the next available CPU theres a very good chance it will get a virtual CPU even though a real CPU is completely free. So if you have an 4 CPU machine (4 real, 4 virtual means 8 Hyperthreaded total) and you have 4 processes that can run only 2 real CPUs will be used.
Ok, ok, ok stop laughing. Here's the kicker. MS fixed this. But did they provide the fix to there customers? No. You have to get the Data Center version to enumerate your CPUs properly!
US05206951
Integration of data between typed objects by mutual, direct invocation between object managers corresponding to object types
S05226161
Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data types
These should be an example of why software patents are ridiculous. These two only differ by the changing objects to data structures.
Take a look at the Flyweight pattern in Design Patterns [amazon.com] book. Yep, a model of a word processor where every single character is represented by a very light-weight reusable object.
True, although that example uses the same object instances over and over. You ultimately only have 100 or so object types to represent different characters. I suppose that's what a Flyweight is (donno, have the book, never quite committed it to memory). Actually, the more I think about it, the more I think the approach is flawed. It might work for a small character set but what if you're using UCS codes like UTF-8? The only reason you would want to have an object to represent a character and not just use an integer would be if you wanted to actually control the rendering of glyphs as subviews of views. Even then it's probably not a good idea. Those examples are just examples.
oop.ismad.com
This link is seriously misguided. There are ligitimate arguments against using OOP and this page does not do that argument any justice.
Whether OO "should" model the real world is heavily debated among OO fans. Modeling the "real world" seams mostly about modeling one's personal viewpoint
I said "real-world" because the OP used that term. If you look at the response to the other thread you'll see my position is more sophisticated than that.
In short, you don't model the "real-world", you model concepts which may or may not encompass tangable entities.
The point of the cards example is that in real life you don't really have self shuffling decks of cards
I understood you perfectly but you're not modeling "real-life". Decouple yourself from the physical world man! Of course the deck should have the capcity to shuffle itself. My point is that there is nothing wrong with this in the context of modeling a game. If you were modeling a person handling some cards it might not.
First, but what is the purpose of making modeling easier? Isn't the goal of almost all new language to make programming easier in some respect.
Everything's hard until you understand it. OO is easier once you understand it because with 10 lines of OO preamble you can create a seeming simple relationship that can greatly reduce the complexity of a program. The compiler now takes care of things that are not possible in C (without potentially large switch statements or ugly lookup tables).
Second, I am not one one of the "objects as real-world entities" people. I believe strongly that to effectively partition work -- to make programming more tractable -- many times you will create work partitions and create objects that have no correlation to the real-world.
This is wrong. Any objects you define do correlate to the "real-world" (your model). If they dont your program will not make sense. You have taken a wrong turn somewhere.
A contrived example would be a deck of cards. Imagine that you make each card an object, then you have a deck object, and a dealer object.
Ok, sounds good to me.
In the real-world the dealer would shuffle a deck, but in our code this responsibility would fall on the deck, but the dealing mechanics would probably rest with the dealer.
What are you modeling? Are you modeling a deck of cards and how a dealer physically interacts with them or are you modelling a game? You're probably modeling poker or black jack right?. OO could be real handy for abstracting which game of cards you're modeling. You're probably not modeling a physical human being "handling" some cards. See the difference?
I think that to effectively use the OO paradigm, you need to really abuse it.
What an absurd statement.
Check out Deja news list of compilers, where the programmers got to vote
Deja news? Was this post stuck in the queue since 1998? Seriously, got a link?
Nicely put.
OO is only one attempted solution to the larger problem of making programming easier on the programmer.
No. You're thinking of MSVC++ and drag and drop programming. OO is about modeling and it can be very effective.
It does this by trying to compartmentalize functionality and seperate implementation from usage.
This is the stuff trolls are made of Jayson. OO does not "compartmentalize" and it is not about contract programming. You have a very superficial understanding of OO principles.
Each instance of an object in a program is a model. You think about what it is conceptually that you are modeling and derive classes for those concepts. In practice these objects usually have hierarchial and recursive relationships. For example a stock is a security but a security is not a stock because it could be a fund. Or a WWW document has elements and frames where frames may be sub documents. These relationships are found everywhere and can be modeled most effectively using OO priciples. That's not to say you should use OO for everything (e.g. you wouldn't want to represent each character in a document using a separate object). Indeed I don't beleive 9 out of 10 developers using an OO language are actually writing OO code. It's modular at best. To use it effectively is non-trivial.
To see how OO has eschewed its own features just look at how delegation is favored over inheritance. This is a functional way of programming.
Like I was saying above, the results of OO are most effective when used strategically. The highest level superstructure benifits greatly from an OO organization. But using OO to a fine degree is not necesarily good.
intuitive and easy to use IDE
Overrated. It must be because I'm getting along pretty well with vi.
simplified GUI design and event handling
This is a tough one. The GUI frameworks are unconditionally complicated. Use what you're team is most familar with.
advanced error handling
errno? Just kidding. But real exception handling is pretty expensive. Those are really your only options besides maybe something like this.
advanced object oriented design including multiple inheritance, abstract classes, and garbage collection
This is kinda funny because multiple inheritance a feature that is only justified in a very small number of cases (I believe it should be avoided alltogther) and is a really good way to get into trouble lick-ity-split, abstact classes is mearly a convention and really doesn't buy you anything in terms of functionality and garbage collection makes languages far too forgiving to the idiot using crappy data structures and algorithms.
full support for operator and function overloading
Well, you just want everything and the kitchen sink don't you? They did that already, it's that morass of a language called C++. Do the next guy a favor and pick features that suit the needs of the application rather than features you think will make it easier for you or the result will be indecipherable.
and portable (at compile-time) across various platforms
Why? Is this really that great? The XOpen and ANSI standards are designed to reduce system dependancies to the point where this shouldn't be an that much of an issue. Even if you're not using C/C++ the language binding likely is. In either case, as long as you consider the scope of those specifications your code should be portable without too much effort. Of course if you cheat and call those Win32 API functions it wouldn't matter what language you're using.
Sounds like you're trolling for some super Java/C++ language. It will probably never happen and rightly so because it would undoubtedly result in unrecognisable code that's dog slow.
I'm willing to bet your application could be written very well with plain ANSI C a few additional libraries and some C++ for the GUI.
Doesn't this patch just add a bunch of extra schedualling points in stategic places? That's not technically "preemptible". Or perhaps I'm thinking of one of the other "preemptible" kernel patches :~)
Is it really the most attractive people you see having the most children? I think not...
Well, I didn't say "the most attractive" did I?