I have to disagree here, the team that designed Ada for instance REALLY understood about application domains and the challenges of developing languages,
In my opinion, Ada is a good example of academic masturbation, coupled in that case with a good deal of practical programmer stupidity, and DOD megalomania. The language is unnecessarily cumbersome, unnecessarily hard to implement, and fails to make good safety guarantees. Eiffel, too, was hugely flawed when it started out (for starters, its type system was just broken), and it took far too long to fix its problems for it to make much of a dent in the market (today, Eiffel is an OK language, but has been obsoleted by other languages).
Your complaints about C are uninformed; C's design was not driven by some kind of macho attempt to save keystrokes, it was driven by trying to squeeze a useful compiler onto a tiny machine. Unlike Ada or Eiffel, which have never in their entire history been a reasonable solution to anything, C was a reasonable choice for its time and purpose; it's just that its time ended about two decades ago.
Of course, even languages as rotten as Ada or Eiffel greatly reduce the potential for errors relative to C, but that really isn't saying much. But there were actually decent, well-designed, practical languages around even in the mid-1980's--there was no need ever to use Ada or Eiffel.
Then go re-read his post and realize that it talked about how it made implementing compilers easier,
So was I. Go read up a little on Lisp and trying using it, then you'll see why.
Lisps awkward syntax (yes, yes, I know "it's not awkward, it's minmal!") will probably prevent it
Coming from someone who advocates Perl-related technologies, that is a ridiculous statement. Perl is a stellar example of how even the worst syntax can't keep a language from being used.
Then put down the Bill Joy doll.
The only thing I would be doing with a Bill Joy doll is put needles in it; Java sucks about as badly as Perl, although in completely different ways.
"Sensitive information" in a startup can be something as simple as "there is a chance that some new product will be launched this year", even if that's already considered common knowledge. And it's not sensitive because the company particularly cares, it's sensitive because regulators and others care.
In different words, what he did is something you might do as well accidentally without even thinking about it; the notion of "sensitive information" can be vague and unobvious in many environments.
KDE has a nice file explorer than Windows and it comes with tons of useful applications that are all integrated well together. Yet, by running it on top of Windows, you still get full Windows compatibility for commercial apps. It's a good thing for people who would like to use KDE but are forced to use Windows.
And how does adding another toolkit and language into the mix reduce the diversity?
Apple's already proven it to be successful/easy to the point that most developers choose to rewrite their frontends using cocoa instead of using a ported windowing toolkit.
You're kidding, right? A huge number of applications on OS X use Carbon, and many of those are toolkit wrappers around Carbon. In fact, it is quite common to see Carbon, Cocoa, Mozilla, Gtk+, Qt, and Java all on the same Mac desktop, together with wxWindows apps and multiple Windows compatibility toolkits bound to Carbon.
I don't want an inconsistent user experience. I want my dialogs / menus / print box / file manager to be the EXACT SAME IN EVERY APPLICATION I RUN.
That's completely under your control: don't run applications that don't behave the way you like.
When Qt originally was QPL'ed and people were complaining, Troll Tech did nothing. Then, a bunch of people got together and started the Harmony project, an truly open source clone of Qt. After that was underway and looked like it was going to become a serious project, Troll Tech gave in and changed their license (and their relationship with the Harmony developers was apparently less than amicable).
Now, people undertake the effort to port Qt to Windows under the GPL, and after they have invested a lot of effort, Troll Tech gives in and changes their license. Apparently, if one wants Troll Tech to do anything, one has to exert this kind of pressure.
While I really don't care about Qt on the desktop (the problem is taking care of itself), something will have to be done about their embedded toolkit, which is currently holding Linux PDAs hostage.
I'd disagree that there aren't people who can design decent languages. The problem is that they can't market them,
No, the problem is that the people who know a lot about languages know little about application domains, and the people who know a lot about application domains know little about how to design languages (or at least don't spend much time on it).
That's why languages like MATLAB dominate scientific computing and languages like Perl, PHP, and Java dominate web computing, and why languages like CAML, Haskell, Lisp, and Smalltalk have never ended up being good general purpose languages.
The problem isn't language designers its us developers, we don't want to spend a week learning a new syntax for a loop, we want to use what we used before. In other words we are luddites.
Programmers contribute to the problem. But while many people have syntactic hangups, even more of them just "don't get" a different approach to programming at all.
I would suggest targetting Parrot [slashdot.org] which makes implementing compilers 1000 times easier than ever before,
In light of more than half a century of dynamic language history, that's just astounding hubris. By comparison with systems like Lisp and Dylan, for example, the Parrot system is still enormously complex, limited, and cumbersome from the programmer's point of view. And compared to Smalltalk, Perl/Parrot isn't even in the same league when it comes to programming environments, browsers, and other tools (in fact, very little really is).
Kay's example of Perl as a language that reinvents the wheel poorly is as appropriate today with Parrot as it was for earlier versions of Perl. The fact that Perl is useful in practice (I use it all the time) because it has lots of libraries and ports doesn't change the fact that its foundations are poorly thought out.
Personally I think Microsoft does actually pay attention to Apple and uses them as a sort of free R&D lab.
Apple used to spend lots of money on R&D and Microsoft nothing. That was when Microsoft was taking Apple's ideas.
These days, Apple doesn't even have a research lab anymore, while Microsoft has the largest CS research lab and has one of the most impressive groups of researchers around anywhere.
WinFS on the other hand is a marketting thing and not a science. Its arrival is as late as possible to slow the pace of innovation but not too late to lose control of the monopolistic market.
That presumes that WinFS is actually "innovation", which it isn't.
Database-driven filesystems are sorta like nuclear fusion.
Not really. Several companies, including IBM, have been shipping database-driven file systems for decades in successful commercial products (!).
They are like nuclear fusion in that people think they are a panacea, while they really are no more than a special-purpose solution for a niche market, a solution that creates at least as many problems as it solves.
The Windows GUI API has no restrictions on it at all. None.
How naive can you be? You have to agree to the Microsoft EULA in order even to run the stuff. It is completely under Microsoft's control, they can change the license and the code at any time and impose whatever requirements they like on you. If you really annoy them, they just start introducing deliberate incompatibilities into their code.
If you find a bug, you can tell them and they will (for a price, generally speaking) figure out what is going on and either fix it or tell you what you need to do to get around it.
Paying Microsoft to fix bugs? Are you from an alternate universe or something?
Aside from that, there is a huge difference between one well defined, encumbrance free target and the multiple encumbered (and moving) targets that comprise the Linux patch-a-GUI fractured environment
Again, you are being naive. There are dozens of toolkits people use to develop Windows applications with. The one that Microsoft happens to put their stamp of approval on, their own, is one of the worst of the bunch. And it is something that Microsoft itself keeps changing. If you want long-term API stability, there are excellent choices for both Windows and Linux.
You don't have any of the big three graphics programs, for instance, and the OS sure could use them, given that the GIMP is all you have right now.
Unlike you, I realize that there are many different user communities with many different needs. Photoshop weenies like you indeed aren't well served by Linux, and I do recommend you stay away from Linux. Please buy yourself a Windows machine or a Macintosh--it's all the computer you will ever be able to handle, and you obviously have no ability to make a positive contribution to Linux. You go pay Adobe or whoever your annual tribute and they'll give you all the shiny, pretty buttons that you so much like to play around with.
Well, that's nice for you. However, many people would like to be able to use high performance, native numerical libraries, graphics libraries, and other such code, while at the same time building complex GUI interfaces. Other people have already taken care of the portability for the native code (Atlas, OpenGL, etc.), so that's not a concern.
JNI is the best solution for Java for doing that sort of thing, but JNI is slow, tedious, and hard to deploy across platforms. C#'s "unsafe" constructs and DLL interfaces offer the same functionality with much better performance, much better portability, and much better runtime safety.
It seems strange for a company to submit a standard they didn't work on, doesn't it?
It is wrong to say that "Apple is submitting it", as if Apple developed the whole thing and then is handing a finished document to IETF. The ZeroConf working group itself has been around since 1999 and the specification was written by people from Apple, Sun, and Microsoft. Go look at the IETF working group instead of Apple's marketing materials; Apple loves to embellish what they are doing ("the world's most advanced operating system", "the world's first 64bit personal computer", give me a break).
And, of course, Apple "worked on" the standard, but so did other people. The idea of dynamically configuring networking devices without a central server has been around even longer than that; all that was missing was an agreement for how to do it for IP.
Furthermore, the first open source implementations didn't come from Apple (and Apple's implementation doesn't even look very useful). In fact, the first shipping commercial implementations didn't come from Apple; I believe Windows had something similar built in before.
Imagine how much more can be accomplished! Combine all the cost of all the landers and satellites to Mars and compare it to a manned mission. I'm willing to bet the cost will be very similar and more can be done in a shorter amount of time.[tt]
Keeping humans alive just for the trip to Mars is hugely expensive. And getting them back requires dozens of robotic missions just in non-scientific preparations, like generating fuel and water, so you still need the robotic technology.
All in all, you can probably fly hundreds of robotic missions to Mars for the cost of a single manned mission. And those robotic missions will generate a lot more useful data and scientific results than a few astronauts walking around on the surface.
I'm sorry if Hollywood gave you the impression that a manned mission is a piece of cake, but it isn't. Even a manned mission to the moon (far more useful and feasible at this point) would be a major undertaking.
Seeing as there are non-MS implementations of almost all of the.NET platform, that's a daft argument.
Depends on what you mean by ".NET platform.". Strictly speaking, "the.NET platform" is C# together with all of Microsoft's APIs. The.NET implementations for other platforms are still incomplete, and it is unclear whether they will be able to remain compatible with Microsoft.NET.
However, what I do consider a good choice is Mono+Gnome: that combination gives you all the advantages of the C# language, together with a complete set of proven, mature open source APIs. Furthermore, Mono+Gnome runs on all major operating systems.
The original argument Gosling had was how easy it was to produce something "unsafe" from legacy code.
No, Gosling wasn't complaining about lack of safety, he was complaining about lack of security. He keeps confusing the two issues, and you apparently do too.
There is nothing wrong with producing something either unsafe or unsecure from legacy code: unlike Java,.NET is a serious desktop platform. Desktop applications are trusted, and hence there is no problem with them running legacy code in a trusted mode. Lack of a good migration path from legacy code to Java is one of the big problems with Java.
On the other hand,.NET enforces the same sandboxing and trust model as Java when it comes to applets and remote code, so there are no security problems arising from the ease with which you can migrate code to it.
because it's just fuel for the m$ minions to go Java bashing.
Gosling started this, Box responded. Box's response was entirely accurate and appropriate.
As for "m$ minions", I am not using.NET because I don't want to tie myself to Microsoft platforms. But Java, at this point, is technologically and legally such a disaster that it is not a reasonable choice for most applications. Java deserves every bashing it gets, from M$ as well as from long-time Java users like me.
In my experience, a lot of innovative software actually starts out in open source form. X11, for example, started out that way. Zoomable user interfaces started out open source. GUI specification languages (now represented by XUL and whatever Longhorn may get) started out in open source form. Entire categories of games started out as open source software. Chat software, innovative mail and news clients, new Internet protocols, etc., all were initially available in open source form.
The usual path for software seems to be that academics have a bright idea and bring out a rough initial version in open source form. People play around with that in the community and then some companies form to commercialize the technology. Eventually, the open source community takes notice (and may even forget about the original research code) and reimplement the commercial versions in open source form.
Furthermore, the companies that actually succeed with a product or new idea are often (usually?) not the ones that invented the technology in the first place.
Apple didn't invent the idea of assigning addresses or finding services in that way; there have been several similar technologies like that before ZeroConf ever came out.
The obstacle to widespread adoption of such technologies has traditionally been standards and compatibility; since Apple can get away with doing its own thing more than other vendors, they often push such technologies into the market even if they weren't the ones to actually invent it.
If the JVM and (say) C code are in separate address spaces, then the C code does not ever need to see the physical addresses of Java objects, or anything else in the JVM address space. Thus, the JNI API can in theory be implemented so as to make it impossible for the C code to break the Java type system.
First of all, people use JNI for buffer and array manipulation; that JNI code wouldn't work if it weren't in the same address space. So, your claim that JNI code can run in a separate address space is just bogus.
Second, even if JNI code did run in a separate address space, it would still be beyond the control of the Java security modules, so it would still be unsafe.
Third, whatever harebrained construction you cook up with JNI in your mind, you can do the same harebrained thing with C#'s unsafe code. In fact, because C#'s unsafe construct has a well-defined language, it would be far easier to do such things.
I'm sorry, but your arguments are just plain stupid.
It doesn't get "linked" through the CLR's equivalent of a JNI interface.
Of course, it doesn't get "linked": it's a language construct. That is one of its advantages over JNI: because the compiler and runtime know about unsafe constructs, they can get inlined. Something that may require a complete API and pages of C code with JNI can be done with just a single line of unsafe code in the CLR.
It's still managed code. There isn't any unmanaged code here to speak of.
Of course, it's "managed code". Why are you re-stating something that is both obvious and irrelevant to the point we are discussing?
You got this wrong too.
No, I didn't. Gosling made the claim that the existence of the "unsafe" construct in C# is a security hole relative to Java. Gosling is wrong: the "unsafe" construct is no more of a security hole than the presence of JNI is in Java. In both Java and C#, unsafe code can only be executed by trusted code.
In fact, the fact that unsafe code in C# is managed actually is better from a runtime safety and security point of view because it arguably greatly reduces the probability of error.
The LGPL is far from a panacea, and anything that uses the LGPL is full of pitfalls for commercial use.
Commercial licenses also have pitfalls.
But that's not the point. I'm simply pointing out that the GPL/QPL license for Qt is a big problem for Qt and KDE. The LGPL simply seems to be a license that works for many commercial companies in the real world. It worked well enough for Sun to build a desktop on.
In my particular area of expertise, the GIMP is "what is available" for Linux. But I have access to something quite a bit more powerful than the GIMP under Windows;
Well, and in my area of expertise there is lots of software that runs well only on Linux or UNIX. What's your point? For lots of different reasons, different communities use different platforms.
The assertion I come back to is that if Linux were more commercially friendly in general, it'd be better off.
Yes, and your assertion is total bullshit because there are lots of companies that are developing commercial software for Linux.
A standard, always-there GUI/API is a key element in this, and, at least as far as I know, there are no solid widget sets that are free of some kind of license / cost / restriction encumbrance, and that is giving both Windows and the Mac a distinct advantage.
Both on Windows and Mac applications are developed using dozens of different toolkits. And neither Windows nor Mac toolkits are "free of legal encumbrances" either, you just choose to ignore the encumbrances they come with.
For instance, it is ridiculous to contemplate going back to twenty-odd layer blend modes when your workflow normally spans seventy-plus; it is a royal pain in the butt to only be able to see one layer at a time; when CYMK work is required, you're simply out of luck; it is hugely annoying to have to select an area, then go select the op, then select, then op, ad infinitum when you are used to working by setting up the op, then selection, selection, selection... etc. Your working speed is reduced by a factor of (at least) two. There are many more issues like this, but these are enough by themselves to pretty much leave the GIMP unused around here.
Well, so it's not the piece of software for you, what can I say. None of the features you mention matter one bit to me, and I work with images daily. I suspect the Gimp already has more functionality than most users, even most professional users, ever really need. (In fact, I suspect that you are simply using the wrong tool for your job out of habit, but that's your problem.)
Now, the GIMP is free, and as such is definitely worth every penny everone pays for it. The commercial alternative I'm talking about will set you back about fifty bucks (US)
Well, then convince the vendor that your $50 are worth porting to Linux for, or contribute to the Gimp.
which high level languages were these, and is the greater safety not in large part due to the relative simplicity of older systems
Many of the classics, among them Lisp, Algol, APL, Simula, and Smalltalk. Modula-3 even had C#-like safe/unsafe sublanguages (as did a few other languages). And while they didn't have GC, languages like Pascal and Modula were safe languages in most other respects.
and is the greater safety not in large part due to the relative simplicity of older systems? I mean, how hard is it to wring all the bugs out of an application or OS written for a machine with 16K of RAM
The world did not begin with 16k Apple II's or the teenage dabblings of some industry luminaries in software. People had large computers running multiuser operating systems and safe, high-level languages in the 1960's.
and did they really bother to weed out all possible "exploits" when weren't 10,000 russian teenagers writing viruses to "zombie box" that machine?
We are talking about runtime safety here. You are confusing runtime safety and security; runtime safety helps with security, but it is neither necessary nor sufficient to guarantee it.
The article exhausts itself in generalities and guesses, unfortunately. For example, it's hard to see why outline fonts (which are cached) or real-time spell checking (for which there are very efficient algorithms) should require a lot of CPU power.
Someone ought to actually do some measurements and profiling, do some real and hard thinking, and write it up. I suspect that most of the features we use daily could be provided at a small fraction of the memory footprint and CPU requirements if people were willing to invest the time and effort to do it. It's probably not worth doing that, but a few performance bottlenecks might be eliminated that way.
It's going to happen someday of course and that's why people created Java and managed code. To minimize the exposure of those regions.
You seem to be blissfully unaware of about half a century of computing history: safe, managed code used to be common in high-level language. The people who created Java no more created it than they created integer addition. The Java language is about where programming languages were in the late 1960's/early 1970's.
The real question to ask is how in the world unsafe languages like C and C++ ever managed to succeed, and why something as poorly designed as Java ended up catching on when there have been far better languages with the same kind of safety guarantees around for decades.
But, perhaps, the answer is simply that people like you write the books that people get their information from. The blind leading the blind, it seems.
Slashdot Mirror
I have to disagree here, the team that designed Ada for instance REALLY understood about application domains and the challenges of developing languages,
In my opinion, Ada is a good example of academic masturbation, coupled in that case with a good deal of practical programmer stupidity, and DOD megalomania. The language is unnecessarily cumbersome, unnecessarily hard to implement, and fails to make good safety guarantees. Eiffel, too, was hugely flawed when it started out (for starters, its type system was just broken), and it took far too long to fix its problems for it to make much of a dent in the market (today, Eiffel is an OK language, but has been obsoleted by other languages).
Your complaints about C are uninformed; C's design was not driven by some kind of macho attempt to save keystrokes, it was driven by trying to squeeze a useful compiler onto a tiny machine. Unlike Ada or Eiffel, which have never in their entire history been a reasonable solution to anything, C was a reasonable choice for its time and purpose; it's just that its time ended about two decades ago.
Of course, even languages as rotten as Ada or Eiffel greatly reduce the potential for errors relative to C, but that really isn't saying much. But there were actually decent, well-designed, practical languages around even in the mid-1980's--there was no need ever to use Ada or Eiffel.
Then go re-read his post and realize that it talked about how it made implementing compilers easier,
So was I. Go read up a little on Lisp and trying using it, then you'll see why.
Lisps awkward syntax (yes, yes, I know "it's not awkward, it's minmal!") will probably prevent it
Coming from someone who advocates Perl-related technologies, that is a ridiculous statement. Perl is a stellar example of how even the worst syntax can't keep a language from being used.
Then put down the Bill Joy doll.
The only thing I would be doing with a Bill Joy doll is put needles in it; Java sucks about as badly as Perl, although in completely different ways.
"Sensitive information" in a startup can be something as simple as "there is a chance that some new product will be launched this year", even if that's already considered common knowledge. And it's not sensitive because the company particularly cares, it's sensitive because regulators and others care.
In different words, what he did is something you might do as well accidentally without even thinking about it; the notion of "sensitive information" can be vague and unobvious in many environments.
Why would you want to run KDE on Windows.
KDE has a nice file explorer than Windows and it comes with tons of useful applications that are all integrated well together. Yet, by running it on top of Windows, you still get full Windows compatibility for commercial apps. It's a good thing for people who would like to use KDE but are forced to use Windows.
(The same argument works for Gnome on Windows)
I'd lean twoard an OpenSTEP like implementation
And how does adding another toolkit and language into the mix reduce the diversity?
Apple's already proven it to be successful/easy to the point that most developers choose to rewrite their frontends using cocoa instead of using a ported windowing toolkit.
You're kidding, right? A huge number of applications on OS X use Carbon, and many of those are toolkit wrappers around Carbon. In fact, it is quite common to see Carbon, Cocoa, Mozilla, Gtk+, Qt, and Java all on the same Mac desktop, together with wxWindows apps and multiple Windows compatibility toolkits bound to Carbon.
I don't want an inconsistent user experience. I want my dialogs / menus / print box / file manager to be the EXACT SAME IN EVERY APPLICATION I RUN.
That's completely under your control: don't run applications that don't behave the way you like.
When Qt originally was QPL'ed and people were complaining, Troll Tech did nothing. Then, a bunch of people got together and started the Harmony project, an truly open source clone of Qt. After that was underway and looked like it was going to become a serious project, Troll Tech gave in and changed their license (and their relationship with the Harmony developers was apparently less than amicable).
Now, people undertake the effort to port Qt to Windows under the GPL, and after they have invested a lot of effort, Troll Tech gives in and changes their license. Apparently, if one wants Troll Tech to do anything, one has to exert this kind of pressure.
While I really don't care about Qt on the desktop (the problem is taking care of itself), something will have to be done about their embedded toolkit, which is currently holding Linux PDAs hostage.
I'd disagree that there aren't people who can design decent languages. The problem is that they can't market them,
No, the problem is that the people who know a lot about languages know little about application domains, and the people who know a lot about application domains know little about how to design languages (or at least don't spend much time on it).
That's why languages like MATLAB dominate scientific computing and languages like Perl, PHP, and Java dominate web computing, and why languages like CAML, Haskell, Lisp, and Smalltalk have never ended up being good general purpose languages.
The problem isn't language designers its us developers, we don't want to spend a week learning a new syntax for a loop, we want to use what we used before. In other words we are luddites.
Programmers contribute to the problem. But while many people have syntactic hangups, even more of them just "don't get" a different approach to programming at all.
I would suggest targetting Parrot [slashdot.org] which makes implementing compilers 1000 times easier than ever before,
In light of more than half a century of dynamic language history, that's just astounding hubris. By comparison with systems like Lisp and Dylan, for example, the Parrot system is still enormously complex, limited, and cumbersome from the programmer's point of view. And compared to Smalltalk, Perl/Parrot isn't even in the same league when it comes to programming environments, browsers, and other tools (in fact, very little really is).
Kay's example of Perl as a language that reinvents the wheel poorly is as appropriate today with Parrot as it was for earlier versions of Perl. The fact that Perl is useful in practice (I use it all the time) because it has lots of libraries and ports doesn't change the fact that its foundations are poorly thought out.
Personally I think Microsoft does actually pay attention to Apple and uses them as a sort of free R&D lab.
Apple used to spend lots of money on R&D and Microsoft nothing. That was when Microsoft was taking Apple's ideas.
These days, Apple doesn't even have a research lab anymore, while Microsoft has the largest CS research lab and has one of the most impressive groups of researchers around anywhere.
WinFS on the other hand is a marketting thing and not a science. Its arrival is as late as possible to slow the pace of innovation but not too late to lose control of the monopolistic market.
That presumes that WinFS is actually "innovation", which it isn't.
Database-driven filesystems are sorta like nuclear fusion.
Not really. Several companies, including IBM, have been shipping database-driven file systems for decades in successful commercial products (!).
They are like nuclear fusion in that people think they are a panacea, while they really are no more than a special-purpose solution for a niche market, a solution that creates at least as many problems as it solves.
The Windows GUI API has no restrictions on it at all. None.
How naive can you be? You have to agree to the Microsoft EULA in order even to run the stuff. It is completely under Microsoft's control, they can change the license and the code at any time and impose whatever requirements they like on you. If you really annoy them, they just start introducing deliberate incompatibilities into their code.
If you find a bug, you can tell them and they will (for a price, generally speaking) figure out what is going on and either fix it or tell you what you need to do to get around it.
Paying Microsoft to fix bugs? Are you from an alternate universe or something?
Aside from that, there is a huge difference between one well defined, encumbrance free target and the multiple encumbered (and moving) targets that comprise the Linux patch-a-GUI fractured environment
Again, you are being naive. There are dozens of toolkits people use to develop Windows applications with. The one that Microsoft happens to put their stamp of approval on, their own, is one of the worst of the bunch. And it is something that Microsoft itself keeps changing. If you want long-term API stability, there are excellent choices for both Windows and Linux.
You don't have any of the big three graphics programs, for instance, and the OS sure could use them, given that the GIMP is all you have right now.
Unlike you, I realize that there are many different user communities with many different needs. Photoshop weenies like you indeed aren't well served by Linux, and I do recommend you stay away from Linux. Please buy yourself a Windows machine or a Macintosh--it's all the computer you will ever be able to handle, and you obviously have no ability to make a positive contribution to Linux. You go pay Adobe or whoever your annual tribute and they'll give you all the shiny, pretty buttons that you so much like to play around with.
Well, that's nice for you. However, many people would like to be able to use high performance, native numerical libraries, graphics libraries, and other such code, while at the same time building complex GUI interfaces. Other people have already taken care of the portability for the native code (Atlas, OpenGL, etc.), so that's not a concern.
JNI is the best solution for Java for doing that sort of thing, but JNI is slow, tedious, and hard to deploy across platforms. C#'s "unsafe" constructs and DLL interfaces offer the same functionality with much better performance, much better portability, and much better runtime safety.
It seems strange for a company to submit a standard they didn't work on, doesn't it?
It is wrong to say that "Apple is submitting it", as if Apple developed the whole thing and then is handing a finished document to IETF. The ZeroConf working group itself has been around since 1999 and the specification was written by people from Apple, Sun, and Microsoft. Go look at the IETF working group instead of Apple's marketing materials; Apple loves to embellish what they are doing ("the world's most advanced operating system", "the world's first 64bit personal computer", give me a break).
And, of course, Apple "worked on" the standard, but so did other people. The idea of dynamically configuring networking devices without a central server has been around even longer than that; all that was missing was an agreement for how to do it for IP.
Furthermore, the first open source implementations didn't come from Apple (and Apple's implementation doesn't even look very useful). In fact, the first shipping commercial implementations didn't come from Apple; I believe Windows had something similar built in before.
Imagine how much more can be accomplished! Combine all the cost of all the landers and satellites to Mars and compare it to a manned mission. I'm willing to bet the cost will be very similar and more can be done in a shorter amount of time.[tt]
Keeping humans alive just for the trip to Mars is hugely expensive. And getting them back requires dozens of robotic missions just in non-scientific preparations, like generating fuel and water, so you still need the robotic technology.
All in all, you can probably fly hundreds of robotic missions to Mars for the cost of a single manned mission. And those robotic missions will generate a lot more useful data and scientific results than a few astronauts walking around on the surface.
I'm sorry if Hollywood gave you the impression that a manned mission is a piece of cake, but it isn't. Even a manned mission to the moon (far more useful and feasible at this point) would be a major undertaking.
Seeing as there are non-MS implementations of almost all of the .NET platform, that's a daft argument.
.NET platform" is C# together with all of Microsoft's APIs. The .NET implementations for other platforms are still incomplete, and it is unclear whether they will be able to remain compatible with Microsoft .NET.
Depends on what you mean by ".NET platform.". Strictly speaking, "the
However, what I do consider a good choice is Mono+Gnome: that combination gives you all the advantages of the C# language, together with a complete set of proven, mature open source APIs. Furthermore, Mono+Gnome runs on all major operating systems.
The original argument Gosling had was how easy it was to produce something "unsafe" from legacy code.
.NET is a serious desktop platform. Desktop applications are trusted, and hence there is no problem with them running legacy code in a trusted mode. Lack of a good migration path from legacy code to Java is one of the big problems with Java.
.NET enforces the same sandboxing and trust model as Java when it comes to applets and remote code, so there are no security problems arising from the ease with which you can migrate code to it.
.NET because I don't want to tie myself to Microsoft platforms. But Java, at this point, is technologically and legally such a disaster that it is not a reasonable choice for most applications. Java deserves every bashing it gets, from M$ as well as from long-time Java users like me.
No, Gosling wasn't complaining about lack of safety, he was complaining about lack of security. He keeps confusing the two issues, and you apparently do too.
There is nothing wrong with producing something either unsafe or unsecure from legacy code: unlike Java,
On the other hand,
because it's just fuel for the m$ minions to go Java bashing.
Gosling started this, Box responded. Box's response was entirely accurate and appropriate.
As for "m$ minions", I am not using
In my experience, a lot of innovative software actually starts out in open source form. X11, for example, started out that way. Zoomable user interfaces started out open source. GUI specification languages (now represented by XUL and whatever Longhorn may get) started out in open source form. Entire categories of games started out as open source software. Chat software, innovative mail and news clients, new Internet protocols, etc., all were initially available in open source form.
The usual path for software seems to be that academics have a bright idea and bring out a rough initial version in open source form. People play around with that in the community and then some companies form to commercialize the technology. Eventually, the open source community takes notice (and may even forget about the original research code) and reimplement the commercial versions in open source form.
Furthermore, the companies that actually succeed with a product or new idea are often (usually?) not the ones that invented the technology in the first place.
Apple didn't invent the idea of assigning addresses or finding services in that way; there have been several similar technologies like that before ZeroConf ever came out.
The obstacle to widespread adoption of such technologies has traditionally been standards and compatibility; since Apple can get away with doing its own thing more than other vendors, they often push such technologies into the market even if they weren't the ones to actually invent it.
If the JVM and (say) C code are in separate address spaces, then the C code does not ever need to see the physical addresses of Java objects, or anything else in the JVM address space. Thus, the JNI API can in theory be implemented so as to make it impossible for the C code to break the Java type system.
First of all, people use JNI for buffer and array manipulation; that JNI code wouldn't work if it weren't in the same address space. So, your claim that JNI code can run in a separate address space is just bogus.
Second, even if JNI code did run in a separate address space, it would still be beyond the control of the Java security modules, so it would still be unsafe.
Third, whatever harebrained construction you cook up with JNI in your mind, you can do the same harebrained thing with C#'s unsafe code. In fact, because C#'s unsafe construct has a well-defined language, it would be far easier to do such things.
I'm sorry, but your arguments are just plain stupid.
It doesn't get "linked" through the CLR's equivalent of a JNI interface.
Of course, it doesn't get "linked": it's a language construct. That is one of its advantages over JNI: because the compiler and runtime know about unsafe constructs, they can get inlined. Something that may require a complete API and pages of C code with JNI can be done with just a single line of unsafe code in the CLR.
It's still managed code. There isn't any unmanaged code here to speak of.
Of course, it's "managed code". Why are you re-stating something that is both obvious and irrelevant to the point we are discussing?
You got this wrong too.
No, I didn't. Gosling made the claim that the existence of the "unsafe" construct in C# is a security hole relative to Java. Gosling is wrong: the "unsafe" construct is no more of a security hole than the presence of JNI is in Java. In both Java and C#, unsafe code can only be executed by trusted code.
In fact, the fact that unsafe code in C# is managed actually is better from a runtime safety and security point of view because it arguably greatly reduces the probability of error.
No. GTK+ has some restrictions and issues.
So does every commercial license in existence.
The LGPL is far from a panacea, and anything that uses the LGPL is full of pitfalls for commercial use.
Commercial licenses also have pitfalls.
But that's not the point. I'm simply pointing out that the GPL/QPL license for Qt is a big problem for Qt and KDE. The LGPL simply seems to be a license that works for many commercial companies in the real world. It worked well enough for Sun to build a desktop on.
In my particular area of expertise, the GIMP is "what is available" for Linux. But I have access to something quite a bit more powerful than the GIMP under Windows;
Well, and in my area of expertise there is lots of software that runs well only on Linux or UNIX. What's your point? For lots of different reasons, different communities use different platforms.
The assertion I come back to is that if Linux were more commercially friendly in general, it'd be better off.
Yes, and your assertion is total bullshit because there are lots of companies that are developing commercial software for Linux.
A standard, always-there GUI/API is a key element in this, and, at least as far as I know, there are no solid widget sets that are free of some kind of license / cost / restriction encumbrance, and that is giving both Windows and the Mac a distinct advantage.
Both on Windows and Mac applications are developed using dozens of different toolkits. And neither Windows nor Mac toolkits are "free of legal encumbrances" either, you just choose to ignore the encumbrances they come with.
For instance, it is ridiculous to contemplate going back to twenty-odd layer blend modes when your workflow normally spans seventy-plus; it is a royal pain in the butt to only be able to see one layer at a time; when CYMK work is required, you're simply out of luck; it is hugely annoying to have to select an area, then go select the op, then select, then op, ad infinitum when you are used to working by setting up the op, then selection, selection, selection... etc. Your working speed is reduced by a factor of (at least) two. There are many more issues like this, but these are enough by themselves to pretty much leave the GIMP unused around here.
Well, so it's not the piece of software for you, what can I say. None of the features you mention matter one bit to me, and I work with images daily. I suspect the Gimp already has more functionality than most users, even most professional users, ever really need. (In fact, I suspect that you are simply using the wrong tool for your job out of habit, but that's your problem.)
Now, the GIMP is free, and as such is definitely worth every penny everone pays for it. The commercial alternative I'm talking about will set you back about fifty bucks (US)
Well, then convince the vendor that your $50 are worth porting to Linux for, or contribute to the Gimp.
which high level languages were these, and is the greater safety not in large part due to the relative simplicity of older systems
Many of the classics, among them Lisp, Algol, APL, Simula, and Smalltalk. Modula-3 even had C#-like safe/unsafe sublanguages (as did a few other languages). And while they didn't have GC, languages like Pascal and Modula were safe languages in most other respects.
and is the greater safety not in large part due to the relative simplicity of older systems? I mean, how hard is it to wring all the bugs out of an application or OS written for a machine with 16K of RAM
The world did not begin with 16k Apple II's or the teenage dabblings of some industry luminaries in software. People had large computers running multiuser operating systems and safe, high-level languages in the 1960's.
and did they really bother to weed out all possible "exploits" when weren't 10,000 russian teenagers writing viruses to "zombie box" that machine?
We are talking about runtime safety here. You are confusing runtime safety and security; runtime safety helps with security, but it is neither necessary nor sufficient to guarantee it.
The article exhausts itself in generalities and guesses, unfortunately. For example, it's hard to see why outline fonts (which are cached) or real-time spell checking (for which there are very efficient algorithms) should require a lot of CPU power.
Someone ought to actually do some measurements and profiling, do some real and hard thinking, and write it up. I suspect that most of the features we use daily could be provided at a small fraction of the memory footprint and CPU requirements if people were willing to invest the time and effort to do it. It's probably not worth doing that, but a few performance bottlenecks might be eliminated that way.
It's going to happen someday of course and that's why people created Java and managed code. To minimize the exposure of those regions.
You seem to be blissfully unaware of about half a century of computing history: safe, managed code used to be common in high-level language. The people who created Java no more created it than they created integer addition. The Java language is about where programming languages were in the late 1960's/early 1970's.
The real question to ask is how in the world unsafe languages like C and C++ ever managed to succeed, and why something as poorly designed as Java ended up catching on when there have been far better languages with the same kind of safety guarantees around for decades.
But, perhaps, the answer is simply that people like you write the books that people get their information from. The blind leading the blind, it seems.