I don't know. The OSS community seems to be a bit *NIX biased, and never showed much interest in BeOS. And the BeOS community is less developer-heavy than the *NIX community. If an active OSS community *had* built around BeOS, though, that would have been wonderful.
Wasn't the kernel built on Mach? Actually, I'm very sure it was. I remember that being used to give it credibility. >>>>>>>>>> Not at all. The BeOS kernel was written entirely from scratch. It was a microkernel by the loose definition of the term (GUI, networking, input in userspace, filesystem, memory management in kernel space) which is why you might have heard references to Mach.
And in the case of the BeOS, it's probably the only good framework written in C++:) >>>>> I don't disagree with the OpenStep heritage, though I must say that it had a slightly different design due to the use of C++ rather than ObjC. That said, I think Qt comes pretty close. It's more complicated, but still rather elegant.
So BeOS has better scheduling than O(1)? >>>>> Algorithmically, I would be surprised if it was even O(1). Probably O(n) give that it puttered out at about 400 threads system-wide. However, the scheduling for a high-thread count server load is very different from scheduling for a medium-thread count desktop. Basically, desktop use requires the scheduler to be able to give best service to the applications the user is working on at the moment. This is something of a black art, and BeOS did it better than anyone.
Multi-user support was, and is, lacking. So it had the power of a Mac, combined with the simplicity of a Mac (before OS X). >>>>>>>>>>>>>>>>> Multi-user support is hardly the defining feature of Unix, especially a UNIX intended for the desktop. BeOS had a UNIX-y filesystem layout, was reasonably POSIX complient, and had a whole lot of ported UNIX software, like gcc, vi, X11, emacs, etc. I can hardly use the terminal in Windows, because Cygwin is too laggy (on small apps) for my taste, and the Windows FS layout is hardly amenable to CLI navigation. In BeOS (when I used it) and KDE (now) I use terminals for most of my code editing and file management.
Convariance means that, you can add a Derived to a list of Base without casting. Contravariance means that you can unpack a Derived from a list of Base without casting. Invariance is what you have in C++, where a list of Derived and a list of Base are two different things.
Um, the Linux kernel and X11 aren't application frameworks. They expose very low-level APIs. Once you throw in all the libraries you need to quickly code large applications, you're just reinvented in the KDE framework anyway, just less consistent and less integrated. KDE uses the services of Linux and X11 whenever they exist. QFile is just a nice, portable, C++ wrapper over Linux file descriptors. KDE follows the XDnD protocol, and the the WM specification, uses the X clipboard mechanism, and uses the X ICE protocol as a basis for its DCOP IPC mechanism. Where the Linux kernel and X11 stop, the KDE framework begins, providing additional services like GUI widgets, database access, interapplication communication and embedding, text formattting, HTML display, etc. Most applications these days need access to these features, and it would be stupid for each one to reinvent them every time.
There is a beauty to a layered architecture. Both the Linux kernel and X11 were designed with a layered architecture in mind. The Linux kernel only includes the minimum of functionality that needs to be in the kernel. It provides simple, basic interfaces to storage, networking, IPC, etc. X11 provides the minimum of functionality that needs to be in the display layer, like context management, window mapping, low-level drawing, and font display. It would be extremely difficult (and stupid) to write an application with just these interfaces, unless you had a very good reason to. Qt and KDE build upon these foundations to provide a portable, complete abstraction upon which applications can be built.
As you can tell from the nick, I was a BeOS user back in the day. Technically, it was way ahead of anything at the time:
1) The kernel was extremely low latency, and the scheduler was superbly designed for user responsiveness. This was at a time when the low-latency and preempt kernels simply didn't exist, and we were putting up with the 100ms+ second latencies of kernel 2.2. While Linux today has caught up with and surpassed the latency targets, it (even in 2.5) still hasn't managed to reach the same quality in the scheduler.
2) The GUI was very fast and responsive. The theme I use today (dotNET on KDE) is probably similarly complex to Be's native look, but BeOS was still faster, even though I ran it on a lowly 300MHz PII, and I run KDE on my 2GHz P4. It was heavily multithreaded, which made a world of difference for a machine under heavy load. In BeOS, an app's GUI would never freeze up while the app did some background task. This was at a time when GTK 1.2.x and Qt 2.x weren't even thread-safe! Even today, KDE and GNOME have yet to make use of multitheading as effectively as BeOS did half a decade ago.
3) It had a very fast journaled filesystem, with attributes and live queries and everything. This was at a time when ext2 would nuke your installation after a bad crash.
4) It was pretty. It was simple, without being austere, and had a colorful asthetic. It had fully-antialiased fonts back when we had Win9x's "font smoothing" and Linux user's were just happy to be finally able to use TrueType fonts.
5) Long before OS X came around, BeOS had the power of Unix with the simplicity of a Mac. The shell was extremely well integrated with the GUI, and you could even script GUI events from the command line.
6) The API was awesome. It was simple, well designed, and well documented. This was back when GTK+' s documentation consisted of source code.
Of course, these days, Linux has come a long long way from what it was then. It's got a kernel much better than BeOS ever did, KDE and GNOME are catching up in the GUI department, XFree86 has fully accelerated OpenGL, and is getting nifty features like XRender and Xr, FreeType/Xft has some of the nicest looking antialiased fonts out there, etc. But BeOS has stagnated for years, and is much the same now as it was then. It's still quite impressive, but not as shiny as it was in its heyday.
This is most definately *not* a troll. The moderator saw "winxp" and his trigger finger twitched. Anyway, as for your question, you can also use NFS. There are NFS clients available for Windows, although I don't know of any free ones. There is a product called PC NFS Pro that runs about $40 dollars. All you have to do is create an NFS share on your Linux system, and you can mount it through the NFS client on the XP system.
KDE is an application framework. If you make things independent of each other, you loose a lot of the consistency and integration that makes an application framework so nice to program for in the first place.
The fish IO-Slave is in the KDE application programming framework, not in the window manager (which is kwin). The KDE folks don't have a lot of say over what goes into the kernel, so putting it in KIO is the best they could do.
I'm claiming that C++'s memory management overall is more powerful and flexible, because you can tailor your memory management scheme to the task at hand, rather than being forced to work with the garbage collector. Right now, I'm using C++ in an OS kernel. Reference-counting smart pointers work very well in that environment, while a GC would cause latency unpredictibility.
C++ garbage collectors can work with almost arbitrary code. The basic requirement is that your code doesn't obfuscate pointers. Some C-style libraries do this, but you can hardly blame C++ for leftovers from a time before modern C++ design existed. More importantly, lots of C++ libraries are available that *don't* do screwy pointer tricks, so you have no excuse to complain if you use one that does. That said, garbage collection is not the optimal method to use for C++ code. C++ is explicitly designed to make garbage collection mostly unnecessary. A quote from Alexander Stepanov, designer of the STL:
"STL data structures will eliminate the majority of the needs for using new. Most people should not allocate arrays because STL does an effective job in doing so. I never need to use new in my code, and I pay great attention to efficiency. The code tends to be more efficient than if I were to use new. With the acceptance of STL, new will sort of fade away. STL also solves the problem of deleting because, for example, in the case of a vector, the destructor will destroy it on the exit from the block. You don't need to worry about releasing the storage as you do when you use new. STL can dramatically minimize the demand for garbage collection. Disciplined use of containers allows you to do whatever you need to do without automatic memory management. The STL constructors and destructors do allocation properly. "
He has a very good point. The first time I used the STL was on a scientific simulation. I did not know a whole lot about "proper STL design" or about modern C++ design in general. I wrote the code in a way that came naturally when using the STL. It was only after the fact that I realized that I had zero calls to new/delete in the entire codebase.
Not really. I think white trash refers to the very distinct poor white population, and its attendant stereotype. Personally, all racial groups have people that they're a little embarrased about (as a Muslim, I'm more than embarrased by some of the people who claim to be doing certain things in the name of our religious culture!) and I don't really see the harm in being aware of that.
socialization, collective guilt, peer pressure... >>>>>>>>>>>>>>>&g t; Yeah, that about covers it. Be thankful that you're only having to deal with some jokes about white trash, rather than still dealing with the after-effects of hundreds of years of social injustice. Same thing goes for those "women have it easy, those poor men!" morons as well.
Are you really using RTTI and exceptions? Most systems guys avoid them out of some sort strange reluctance to spend any cycles in code they didn't write (even when it came with the compiler). >>>>>>>>>> Since GCC is open source, I had access to all the RTTI and exception handling code. It's comparatively small, and very efficient. Basically, exceptions have no overhead unless you actually throw one (which is rare), typeid is O(1), and dynamic_cast is O(n) for small n.
Any nontrivially interacting objects are going to have a cycle, with none being freed. >>>>>>>>>>>> Not if you use a ref-counting pointer only for managed allocations rather than weak references. Simple weak linkages is why references exist.
As for a copying collector --- it's only an option if you can afford non-deterministic timings for collections to happen. In a kernel, that kills latency. If you're not under latency constraints, you can always use one of the many garbage collectors for C++.
Why would any C++ programmer bother to do manual memory management? Try writing STL style code sometime. I managed to write an entire simulation once in C++ without using a single new/delete call. Between the STL's value semantics, the resource acquisition is initialization mechanism, and smart pointers (which implement reference-counted GC) C++ memory management is a whole lot more powerful and flexible than Java memory management. And if you want, you can always use a garbage collector, and many C++ applications use it to great effect. Now, you can get around all of these mechanisms in C++, while in Java, you can't. I consider this a strength, not a weakness. If I want to allow the saftey nets to work, I just write straight forward, safe code. If I don't want the saftey nets to work, I have to conciously work around it, at which point it becomes my responsibility to make sure n othing breaks.
There are lots of applications that don't require sandboxing, including most application development. And lack of static typing is a feature, not a bug. Python uses strong dynamic typing, like Smalltalk and Lisp. Meanwhile, Java, C++, ML, Haskell, and others use strong static typing. They are simply two different paradigms, and each has its attended benifets and limitations.
Systems programming is still done in C; some embedded work uses tiny subsets of C++ (which have often been described as "C with classes") >>>>>>>>>>>>>>>>>>>>> Right now, I'm doing a C++ kernel with exception handling, smart pointers, the STL, the whole shebang. All I had to do was write a few hundred lines of runtime support code. Try doing that with Java. FYI, the OS X I/O manager is C++, and many NT kernel drivers these days are written in C++.
If you can afford "smart pointers" and reference counting, >>>>>>> Reference counting smart pointers boil down to an overhead of one word per pointer, and an indirect increment for object creationyou should be using a higher-level language that clarifies.
you should be using a higher-level language that clarifies >>>>>>>>>> Java isn't a high level language. Both are mid-level. Properly written Java code just looks a lot like properly written C++ code. A real high level language is something like Python, and maybe Smalltalk and some of the functional languages.
rules out entire categories of catastrophic stupid mistakes. >>>>>>>>> Using proper practices can do this in C++. It is not a stupid mistake if someone uses a C-style array, or a raw pointer, instead of a std::vector or smart pointer. That's a concious decision on the part of the developer. Once you decide to use the unsafe features of C++, the language assumes that you're doing so for a reason, and you have no reason to bitch if you get bitten in the ass. Your points would be valid if you *had* to use unsafe features to get real code written, but I've seen a lot of well designed code that doesn't use these unsafe features, so that arguement holds no water.
It boils down to this: There is very little (even in the way of safety features) that C++ can't do that Java can. On the other hand, there is a lot of stuff that C++ can do that Java cannot. If you're not going to program according to best practices, then you're screwed no matter what language you use.
Hey! Get away from that moderate button! It's a joke!
Re:[fvwm] auto-sorting menus
on
fvwm Turns Ten
·
· Score: 1
You can do all that in KDE too. If you don't like auto-rearranged menus, you can turn that off (which I do). KDE is completely different from Microsoft's ideas. KDE is ultimately configurable. By default, it comes configured to look and feel a lot like Windows, but if you're as elite of a user as you think you are, you'll have no problem configuring it to your taste.
Re:I doubt that Java will succeed.
on
Preview of Java 1.5
·
· Score: 2, Insightful
The fact of the matter is that operator overloading always leads to evil abuses. >>>>>>>>> I've seen many C++ libraries, and I've never seen an evil abuse of operator overloading. Of course, I work mostly alone, so I don't encounter crappy programmers that often. But I don't think that a language should sacrifice completeness and orthogonality for the sake of bad programmers.
Some of which are evident in the C++ standard libraries as glaring examples of how irresistively seductive the temptation to abuse operator overloading is. >>>>>>>>> Its not the same operator. One is the bit-shift operator, and is only defined for integral types, because it only makes sense for integral types. It's just like how the % operator is only defined for integral types, and not floating point ones. The other is the stream operator, and is the one that can be overloaded. The fact that they look the same is irrelevent. In Java, addition and concatenation are both operator+, and nobody seems to have a problem with that! Integral division and floating point division is both operator/, and again, nobody seems to have a problem with that. Beyond that, the C++ streaming mechanism is a lot more flexible than Java's method of requiring printable objects to have a toString method.
However, DynamicJava isn't really Java. It's an extension of Java that makes it more palatable for interactive use. Java by itself is too structure-happy to make it suitable for interactive use.
The use of non printing characters as syntax elements is ridiculous on the face of it. >>>>>>>>>>>> Not at all. None of the other language fields (mathematical and human languages) bother with explicit delimiters to group related statements, so the use of synactical block delimiters is totally alien to non-programmers. If the computer doesn't need it, and it is more natural for a human to use whitespace as a delimiter, why bother with explicit delimiters in the language?
Almost all of those "features" you mentioned are actually in the Java *libraries* not in the language. C++ has libraries that do exactly the same thing, in pretty much the same way. The only thing it doesn't have is reflection (and consequently serialization) which really does need language-level support. I think its actually a good thing that C++ has a minimal standard library. A language is supposed to be composed of basic building blocks. Entangling all these libraries with the main specification is not clean design. It might be useful, for when having a library quick at hand is more important than choosing among competing libraries to find the best one, but I hardly think that's a good critereon for long term quality.
ISO C++ was standardized in 1998. GCC 3.x (came out in 2001) supported every language feature except "export" which is now believed to be a mis-feature. All the compilers I use on a daily basis (GCC 3.2.2 and Intel C++ 7.1) compile every bit of code I've thrown at it.
Lack of operator overloading is a defect in a C-style language. Look at it this way: operators in a statically typed language like C++/Java are just functions. Since function overloading is allowed, operator overloading should be allowed as well. Not allowing overloading of operators is not orthogonal. Further, most of the accusations of ambiguity have no basis, since the operators for the built-in types are predefined, and thus not overloadable. In 99% of cases where operator overloading should be used, it simply adds meaning rather than changing existing meaning. Of course, there is the accusation that operator overloading can be used to "lie" in an interface. But you can always write a function called "doThis()" that instead does "That".
Also, Java generics have nowhere near the amount of generative power that C++ templates have. Together, C++ templates and operator overloading are two very powerful building blocks. They let you implement abstractions cleanly, and allow user-defined types to behave like built-in types. These building blocks make smart pointers, numeric class templates, expression templates, and all sorts of other features available. Because Java lacks these basic building blocks, it has to resort to certain hacks, like making a distinction between value and address semantics for operator==, and allowing certain string-related classes to overload operator+, but not user-defined classes.
Slashdot Mirror
Dude. That's so 1993. It's
int main {
Well, figures that SCO would write non-standards complient code.
I don't know. The OSS community seems to be a bit *NIX biased, and never showed much interest in BeOS. And the BeOS community is less developer-heavy than the *NIX community. If an active OSS community *had* built around BeOS, though, that would have been wonderful.
Wasn't the kernel built on Mach? Actually, I'm very sure it was. I remember that being used to give it credibility.
:)
>>>>>>>>>>
Not at all. The BeOS kernel was written entirely from scratch. It was a microkernel by the loose definition of the term (GUI, networking, input in userspace, filesystem, memory management in kernel space) which is why you might have heard references to Mach.
And in the case of the BeOS, it's probably the only good framework written in C++
>>>>>
I don't disagree with the OpenStep heritage, though I must say that it had a slightly different design due to the use of C++ rather than ObjC. That said, I think Qt comes pretty close. It's more complicated, but still rather elegant.
So BeOS has better scheduling than O(1)?
>>>>>
Algorithmically, I would be surprised if it was even O(1). Probably O(n) give that it puttered out at about 400 threads system-wide. However, the scheduling for a high-thread count server load is very different from scheduling for a medium-thread count desktop. Basically, desktop use requires the scheduler to be able to give best service to the applications the user is working on at the moment. This is something of a black art, and BeOS did it better than anyone.
Multi-user support was, and is, lacking. So it had the power of a Mac, combined with the simplicity of a Mac (before OS X).
>>>>>>>>>>>>>>>>>
Multi-user support is hardly the defining feature of Unix, especially a UNIX intended for the desktop. BeOS had a UNIX-y filesystem layout, was reasonably POSIX complient, and had a whole lot of ported UNIX software, like gcc, vi, X11, emacs, etc. I can hardly use the terminal in Windows, because Cygwin is too laggy (on small apps) for my taste, and the Windows FS layout is hardly amenable to CLI navigation. In BeOS (when I used it) and KDE (now) I use terminals for most of my code editing and file management.
En anglias:
Convariance means that, you can add a Derived to a list of Base without casting.
Contravariance means that you can unpack a Derived from a list of Base without casting.
Invariance is what you have in C++, where a list of Derived and a list of Base are two different things.
Um, the Linux kernel and X11 aren't application frameworks. They expose very low-level APIs. Once you throw in all the libraries you need to quickly code large applications, you're just reinvented in the KDE framework anyway, just less consistent and less integrated. KDE uses the services of Linux and X11 whenever they exist. QFile is just a nice, portable, C++ wrapper over Linux file descriptors. KDE follows the XDnD protocol, and the the WM specification, uses the X clipboard mechanism, and uses the X ICE protocol as a basis for its DCOP IPC mechanism. Where the Linux kernel and X11 stop, the KDE framework begins, providing additional services like GUI widgets, database access, interapplication communication and embedding, text formattting, HTML display, etc. Most applications these days need access to these features, and it would be stupid for each one to reinvent them every time.
There is a beauty to a layered architecture. Both the Linux kernel and X11 were designed with a layered architecture in mind. The Linux kernel only includes the minimum of functionality that needs to be in the kernel. It provides simple, basic interfaces to storage, networking, IPC, etc. X11 provides the minimum of functionality that needs to be in the display layer, like context management, window mapping, low-level drawing, and font display. It would be extremely difficult (and stupid) to write an application with just these interfaces, unless you had a very good reason to. Qt and KDE build upon these foundations to provide a portable, complete abstraction upon which applications can be built.
As you can tell from the nick, I was a BeOS user back in the day. Technically, it was way ahead of anything at the time:
1) The kernel was extremely low latency, and the scheduler was superbly designed for user responsiveness. This was at a time when the low-latency and preempt kernels simply didn't exist, and we were putting up with the 100ms+ second latencies of kernel 2.2. While Linux today has caught up with and surpassed the latency targets, it (even in 2.5) still hasn't managed to reach the same quality in the scheduler.
2) The GUI was very fast and responsive. The theme I use today (dotNET on KDE) is probably similarly complex to Be's native look, but BeOS was still faster, even though I ran it on a lowly 300MHz PII, and I run KDE on my 2GHz P4. It was heavily multithreaded, which made a world of difference for a machine under heavy load. In BeOS, an app's GUI would never freeze up while the app did some background task. This was at a time when GTK 1.2.x and Qt 2.x weren't even thread-safe! Even today, KDE and GNOME have yet to make use of multitheading as effectively as BeOS did half a decade ago.
3) It had a very fast journaled filesystem, with attributes and live queries and everything. This was at a time when ext2 would nuke your installation after a bad crash.
4) It was pretty. It was simple, without being austere, and had a colorful asthetic. It had fully-antialiased fonts back when we had Win9x's "font smoothing" and Linux user's were just happy to be finally able to use TrueType fonts.
5) Long before OS X came around, BeOS had the power of Unix with the simplicity of a Mac. The shell was extremely well integrated with the GUI, and you could even script GUI events from the command line.
6) The API was awesome. It was simple, well designed, and well documented. This was back when GTK+' s documentation consisted of source code.
Of course, these days, Linux has come a long long way from what it was then. It's got a kernel much better than BeOS ever did, KDE and GNOME are catching up in the GUI department, XFree86 has fully accelerated OpenGL, and is getting nifty features like XRender and Xr, FreeType/Xft has some of the nicest looking antialiased fonts out there, etc. But BeOS has stagnated for years, and is much the same now as it was then. It's still quite impressive, but not as shiny as it was in its heyday.
This is most definately *not* a troll. The moderator saw "winxp" and his trigger finger twitched. Anyway, as for your question, you can also use NFS. There are NFS clients available for Windows, although I don't know of any free ones. There is a product called PC NFS Pro that runs about $40 dollars. All you have to do is create an NFS share on your Linux system, and you can mount it through the NFS client on the XP system.
KDE is an application framework. If you make things independent of each other, you loose a lot of the consistency and integration that makes an application framework so nice to program for in the first place.
The fish IO-Slave is in the KDE application programming framework, not in the window manager (which is kwin). The KDE folks don't have a lot of say over what goes into the kernel, so putting it in KIO is the best they could do.
I'm claiming that C++'s memory management overall is more powerful and flexible, because you can tailor your memory management scheme to the task at hand, rather than being forced to work with the garbage collector. Right now, I'm using C++ in an OS kernel. Reference-counting smart pointers work very well in that environment, while a GC would cause latency unpredictibility.
C++ garbage collectors can work with almost arbitrary code. The basic requirement is that your code doesn't obfuscate pointers. Some C-style libraries do this, but you can hardly blame C++ for leftovers from a time before modern C++ design existed. More importantly, lots of C++ libraries are available that *don't* do screwy pointer tricks, so you have no excuse to complain if you use one that does. That said, garbage collection is not the optimal method to use for C++ code. C++ is explicitly designed to make garbage collection mostly unnecessary. A quote from Alexander Stepanov, designer of the STL:
"STL data structures will eliminate the majority of the needs for using new. Most people should not allocate arrays because STL does an effective job in doing so. I never need to use new in my code, and I pay great attention to efficiency. The code tends to be more efficient than if I were to use new. With the acceptance of STL, new will sort of fade away. STL also solves the problem of deleting because, for example, in the case of a vector, the destructor will destroy it on the exit from the block. You don't need to worry about releasing the storage as you do when you use new. STL can dramatically minimize the demand for garbage collection. Disciplined use of containers allows you to do whatever you need to do without automatic memory management. The STL constructors and destructors do allocation properly. "
He has a very good point. The first time I used the STL was on a scientific simulation. I did not know a whole lot about "proper STL design" or about modern C++ design in general. I wrote the code in a way that came naturally when using the STL. It was only after the fact that I realized that I had zero calls to new/delete in the entire codebase.
Not really. I think white trash refers to the very distinct poor white population, and its attendant stereotype. Personally, all racial groups have people that they're a little embarrased about (as a Muslim, I'm more than embarrased by some of the people who claim to be doing certain things in the name of our religious culture!) and I don't really see the harm in being aware of that.
SCO gave away the source to Release 7, not System V.
socialization, collective guilt, peer pressure...
>>>>>>>>>>>>>>>&g t;
Yeah, that about covers it. Be thankful that you're only having to deal with some jokes about white trash, rather than still dealing with the after-effects of hundreds of years of social injustice. Same thing goes for those "women have it easy, those poor men!" morons as well.
Are you really using RTTI and exceptions? Most systems guys avoid them out of some sort strange reluctance to spend any cycles in code they didn't write (even when it came with the compiler).
>>>>>>>>>>
Since GCC is open source, I had access to all the RTTI and exception handling code. It's comparatively small, and very efficient. Basically, exceptions have no overhead unless you actually throw one (which is rare), typeid is O(1), and dynamic_cast is O(n) for small n.
Any nontrivially interacting objects are going to have a cycle, with none being freed.
>>>>>>>>>>>>
Not if you use a ref-counting pointer only for managed allocations rather than weak references. Simple weak linkages is why references exist.
As for a copying collector --- it's only an option if you can afford non-deterministic timings for collections to happen. In a kernel, that kills latency. If you're not under latency constraints, you can always use one of the many garbage collectors for C++.
Why would any C++ programmer bother to do manual memory management? Try writing STL style code sometime. I managed to write an entire simulation once in C++ without using a single new/delete call. Between the STL's value semantics, the resource acquisition is initialization mechanism, and smart pointers (which implement reference-counted GC) C++ memory management is a whole lot more powerful and flexible than Java memory management. And if you want, you can always use a garbage collector, and many C++ applications use it to great effect. Now, you can get around all of these mechanisms in C++, while in Java, you can't. I consider this a strength, not a weakness. If I want to allow the saftey nets to work, I just write straight forward, safe code. If I don't want the saftey nets to work, I have to conciously work around it, at which point it becomes my responsibility to make sure n othing breaks.
There are lots of applications that don't require sandboxing, including most application development. And lack of static typing is a feature, not a bug. Python uses strong dynamic typing, like Smalltalk and Lisp. Meanwhile, Java, C++, ML, Haskell, and others use strong static typing. They are simply two different paradigms, and each has its attended benifets and limitations.
Systems programming is still done in C; some embedded work uses tiny subsets of C++ (which have often been described as "C with classes") ;
>>>>>>>>>>>>>>>>>>>>>
Right now, I'm doing a C++ kernel with exception handling, smart pointers, the STL, the whole shebang. All I had to do was write a few hundred lines of runtime support code. Try doing that with Java. FYI, the OS X I/O manager is C++, and many NT kernel drivers these days are written in C++.
If you can afford "smart pointers" and reference counting,
>>>>>>>
Reference counting smart pointers boil down to an overhead of one word per pointer, and an indirect increment for object creationyou should be using a higher-level language that clarifies.
you should be using a higher-level language that clarifies
>>>>>>>>>>
Java isn't a high level language. Both are mid-level. Properly written Java code just looks a lot like properly written C++ code. A real high level language is something like Python, and maybe Smalltalk and some of the functional languages.
rules out entire categories of catastrophic stupid mistakes.
>>>>>>>>>
Using proper practices can do this in C++. It is not a stupid mistake if someone uses a C-style array, or a raw pointer, instead of a std::vector or smart pointer. That's a concious decision on the part of the developer. Once you decide to use the unsafe features of C++, the language assumes that you're doing so for a reason, and you have no reason to bitch if you get bitten in the ass. Your points would be valid if you *had* to use unsafe features to get real code written, but I've seen a lot of well designed code that doesn't use these unsafe features, so that arguement holds no water.
It boils down to this: There is very little (even in the way of safety features) that C++ can't do that Java can. On the other hand, there is a lot of stuff that C++ can do that Java cannot. If you're not going to program according to best practices, then you're screwed no matter what language you use.
Like Scheme, Lisp, and Smalltalk?
fugly?
Hey! Get away from that moderate button! It's a joke!
You can do all that in KDE too. If you don't like auto-rearranged menus, you can turn that off (which I do). KDE is completely different from Microsoft's ideas. KDE is ultimately configurable. By default, it comes configured to look and feel a lot like Windows, but if you're as elite of a user as you think you are, you'll have no problem configuring it to your taste.
The fact of the matter is that operator overloading always leads to evil abuses.
>>>>>>>>>
I've seen many C++ libraries, and I've never seen an evil abuse of operator overloading. Of course, I work mostly alone, so I don't encounter crappy programmers that often. But I don't think that a language should sacrifice completeness and orthogonality for the sake of bad programmers.
Some of which are evident in the C++ standard libraries as glaring examples of how irresistively seductive the temptation to abuse operator overloading is.
>>>>>>>>>
Its not the same operator. One is the bit-shift operator, and is only defined for integral types, because it only makes sense for integral types. It's just like how the % operator is only defined for integral types, and not floating point ones. The other is the stream operator, and is the one that can be overloaded. The fact that they look the same is irrelevent. In Java, addition and concatenation are both operator+, and nobody seems to have a problem with that! Integral division and floating point division is both operator/, and again, nobody seems to have a problem with that. Beyond that, the C++ streaming mechanism is a lot more flexible than Java's method of requiring printable objects to have a toString method.
However, DynamicJava isn't really Java. It's an extension of Java that makes it more palatable for interactive use. Java by itself is too structure-happy to make it suitable for interactive use.
The use of non printing characters as syntax elements is ridiculous on the face of it.
>>>>>>>>>>>>
Not at all. None of the other language fields (mathematical and human languages) bother with explicit delimiters to group related statements, so the use of synactical block delimiters is totally alien to non-programmers. If the computer doesn't need it, and it is more natural for a human to use whitespace as a delimiter, why bother with explicit delimiters in the language?
Almost all of those "features" you mentioned are actually in the Java *libraries* not in the language. C++ has libraries that do exactly the same thing, in pretty much the same way. The only thing it doesn't have is reflection (and consequently serialization) which really does need language-level support. I think its actually a good thing that C++ has a minimal standard library. A language is supposed to be composed of basic building blocks. Entangling all these libraries with the main specification is not clean design. It might be useful, for when having a library quick at hand is more important than choosing among competing libraries to find the best one, but I hardly think that's a good critereon for long term quality.
ISO C++ was standardized in 1998. GCC 3.x (came out in 2001) supported every language feature except "export" which is now believed to be a mis-feature. All the compilers I use on a daily basis (GCC 3.2.2 and Intel C++ 7.1) compile every bit of code I've thrown at it.
Lack of operator overloading is a defect in a C-style language. Look at it this way: operators in a statically typed language like C++/Java are just functions. Since function overloading is allowed, operator overloading should be allowed as well. Not allowing overloading of operators is not orthogonal. Further, most of the accusations of ambiguity have no basis, since the operators for the built-in types are predefined, and thus not overloadable. In 99% of cases where operator overloading should be used, it simply adds meaning rather than changing existing meaning. Of course, there is the accusation that operator overloading can be used to "lie" in an interface. But you can always write a function called "doThis()" that instead does "That".
Also, Java generics have nowhere near the amount of generative power that C++ templates have. Together, C++ templates and operator overloading are two very powerful building blocks. They let you implement abstractions cleanly, and allow user-defined types to behave like built-in types. These building blocks make smart pointers, numeric class templates, expression templates, and all sorts of other features available. Because Java lacks these basic building blocks, it has to resort to certain hacks, like making a distinction between value and address semantics for operator==, and allowing certain string-related classes to overload operator+, but not user-defined classes.