Maybe it hasn't been tried for Apple software, but at least one EULA was declared enforceable in an U.S. court. Sad, isn't it?
There is nothing wrong with EULAs being enforceable in general: people put effort into creating software and they should get some control over that software.
But there should be limits on what EULAs can impose on you. EULAs should not be permitted to impose restrictions on reverse engineering or resale of software. And you should be able to return software for a full refund if you don't accept the EULA (it should be up to the people creating the software to make sure you see the EULA before you have a chance to copy the media).
First of all, legal guardians are responsible for the actions of minors; if your kid orders $10000 worth of candy from a web site on your credit card, well, that's just too bad for you.
In any case, if you want to avoid having a legally binding contract under which you can use the software, you can dispense with all the complications of having the neighbor's kid install the software, you can just download the software from some file sharing network and save yourself the money: the effect is the same. Either way, you don't have a legal agreement with the vendor, which means you don't have any obligations to them, but you also don't have a license to run their software.
On top of that, some argue that the entire license agreement is BS. By law, a contract requires two parties to agree. Some argue that this agreement needs to be in place at the time of purchase.
The code is still copyrighted and you can only use it because a contract gives you permission to use the code. If you can successfully argue that there is no contract, or that the contract is invalid, then things revert to their previous state.
So, yes, no matter what the EULA says, you can probably fairly easily force the seller to take back the software and return your money. Furthermore, there are unconscionable provisions and legal pitfalls in many EULAs that may not be enforceable at all against consumers (businesses are generally expected to be smart enough to understand the fine print).
But none of that means that you can force the seller to let you use their software for free: the software is still copyrighted and you can still only use it under some sort of agreement.
The same is, incidentally, true for GNU software: you can choose to agree to the GPL or you can choose to challenge its validity; but no matter which choice you make, the software remains copyrighted, and if you challenge the validity of the GPL, then, obviously, you have no right to use the software.
I feel sorry for these guys, American kids that went through hell in Vietnam. But they have turned into angry old men without getting any wiser. Today, they are just letting themselves be used as political pawns. Rather than facing the fact that they were fighting in an purposeless war that the US lost and in which the US injured large numbers of innocent civilians, rather than facing that it was their own government that caused them all this pain and suffering, they want to cling to the illusion that there was nobility and purpose to this war.
The sad thing is that Bush is far more likely to generate the next generation of hurt, confused, and angry veterans. Bush doesn't know first hand what happens to US soldiers in battle and he doesn't seem to care much either (except for photo ops). Kerry may have many flaws, and he may not have seen the worst of Vietnam when he was serving there, but he has actually seen some of the horrors of war and is far more likely to avoid getting US soldiers into trouble unnecessarily.
You're right that hydrogen needs to be generated. The way hydrogen solves the looming oil shortages is by using it for energy storage and transport: the use of hydrogen allows solar and wind energy to be generated where they can be generated efficiently and then safely shipped to where they are needed.
Sorry, you implied it with the line: "C# does not force you to declare exceptions" What am I supposed to think you are saying?
You are supposed to merely be reminded of a difference between the two; a few words like that are not inended as a comprehensive description of exception handling systems. What it points out is that C# never forces you to deal with exceptions, while Java sometimes does force you to deal with exceptions.
Some libraries have exceptions (though not all) and they do not FORCE you to declare them. they force you to DEAL with them, which usually means catching and re-throwing, or catching and ignoring.
You are right, that was somewhat sloppy writing; I think we both agree on the technical details, we just disagree on their implications.
"Something can throw java.io.IOException even though it doesn't declare it." How would that happen? Give me some Java code that will compile and do exactly that.
It happens when you compile against one version of a class but link against another; while the VM checks all other types at load time, it does not check exception signatures either at load time or even when an exception happens.
So you get the best of both worlds in that you can use hard exceptions if you like, or use soft ones for larger systems where it makes sense
Trouble is that I have to deal with checked exceptions in my code that other people decide to throw in their libraries. Worse, I have to live with the mistakes other people make when trying to deal with checked exceptions that they should simply have let alone. In any case, I think Java's checked exceptions by themselves are not enough to condemn the language; they are just one of a number of nagging technical problems with the language, some of them far more serious.
I think it's great that the Croquet project is making their ideas concrete and that they are putting them out there. Only by building lots of prototypes and systems can one see what works and what doesn't.
Having said that, I suspect most people will not find Croquet useful for day-to-day work. But, again, they have put something on the table that one can discuss and criticize, and that's a lot more than can be said for a lot of other innovators. Some ideas and concepts from their system will surely survive, no matter what happens to Croquet itself.
The thing I think people should think about is which of these concepts can be carried over into X11-based desktops: X11 already has a lot of the functionality needed for making applications mobile and collaborative (in fact, that was the original vision of X11 20 years ago). If people are serious about it, some of the most interesting and useful functionality from Croquet could, for example, form the basis of Gnome 4.0.
Now they will be forced to use MS windows to get to the documentation.
While that is unpleasant enough, perhaps more seriously, they will be forced to agree to Microsoft EULAs separate from the documentation in order to access the documentation.
Of course, they could just convert to PDF--everybody does that (not that PDF is such a great format, but it is considerably better than Word and considerably better documented).
PDF's also come in a DRM version, so I don't see an advantage in terms of DRM.
And as far as the formats themselves go, I believe MHT is just a multipart MIME collection of web pages and images--all open stuff; to me, that seems vastly preferable to PDF, which is a huge and complicated spec that Adobe keeps changing around. Recently, Adobe has started to keep some particularly lucrative bits of PDF undocumented and proprietary.
The only problem with MHT, as far as I can tell, is that Mozilla doesn't support it yet. Hopefully, that will get resolved soon.
Correction: C# does not give you the option of using checked exceptions. Java has both checked and unchecked.
Yes, and it's the existence of checked exceptions, any checked exceptions, in Java that is a problem.
Checked exceptions, when used properly, are a very good thing. The point of a checked exception is: "Pardon me developer, but did you ensure that precondition X is satisfied before calling this method?"
Checked exceptions are a way to force a programmer to deal directly inside the caller with error conditions that might arise inside a method, nothing more and nothing less.
If there is a precondition that is not apparent from the API itself, the checked exception is a good compile-time method for getting the developer's attention.
That's what we have types and return values for. Exceptions are there for the opposite purpose: to avoid distracting the programmer at compile-time with irrelevant and useless detail related to error handling.
Re:Except you got exceptions wrong
on
Java 1.5 vs C#
·
· Score: 1
Your original post proclaimed Java must declare exceptions, which is false.
No, it didn't even proclaim that. But, just for the sake of argument, let's say it did: if you tell me that you eat cookies, does that mean that you eat every cookie in existence?
I agree that unechecked exceptions are the way to go for projects of any size, and have been using them in Java for years now.
The problem with Java's declared exceptions is that libraries are full of exceptions you do have to declare, and those cause problems. That is, the existence of an exception declaration mechanism in the language is the problem.
An additional problem is that Java doesn't even type-check the declared exceptions it has correctly: something can throw java.io.IOException even though it doesn't declare it.
Calling unsafe modules is straightforward to do in Java. Okay, so JNI isn't as immediate but it's fairly trivial boilerplate - define an interface with native methods, generate a header, implement the methods the header emits and compile. In other words if you have to do it, it's there.
JNI isn't even close:
with JNI you need to compile and distribute separate version of your unsafe code for every target CPU, with C#, it's just like any other C# code (the JIT compiles it into native code as needed, on each target platform)
doing any kind of native operation has at least a C function call overhead, and more, while unsafe C# compiles unsafe operations inline; so, an unsafe array access in C# is actually faster than a safe array access, while with JNI it is much slower
everything inside a C/C++ JNI module is unsafe (it's C/C++, after all), while with unsafe C# modules, only the specific operations you need to carry out need to be unsafe
Anyway, it is arguable that making it easy to call unmanaged code is an extremely bad thing to do. Call me a cynic
No, I just call you someone who has overdosed on Sun marketing.
but I reckon MS is delighted to see people use unmanaged DLLs, COM interop and other unportable stuff since it locks them into MS Windows.
So? Windows programmers apparently don't care; they are just delighted to be off of C++. And as a C#-using Linux programmer, I don't mind being locked into Linux. In fact, as someone who supports and uses open source software, I don't like using Java because Sun is trying to lock me into Java.
And, yes, C# let's me call unmanaged Xlib, unmanaged Numerical Recipes, unmanaged Tcl/Tk, and a lot of other unmanaged code, and I am not ashamed that I'm doing it--it's a good thing.
What was the point of coding with.NET again?
We are talking about C# here, not.NET. And the point of C# is to give you a powerful language that's easier to use than C++, something C# accomplishes well.
Other points. Java as multidimensional arrays - I used one today in fact.
Not in standard Java. Ragged arrays and the class-based Array definitions are not the same as having true multidimensional arrays in the language.
Also, declaring exceptions is a good thing. It might be a minor pain to declare that your method throws an exception, but it sure beats calling something and having no idea whatsoever if it throws an exception.
In Java, you still don't have any idea if any code you call throws an exception. That is, just because code doesn't declare an exception doesn't mean it doesn't throw one. In fact, in Java, code you call may even throw undeclared exceptions that the language requires you to declare because the VM doesn't check exception declarations. So, you have to write Java code as if any code can throw any exception anyway.
Exception declarations in Java just don't work. Maybe someone with more brains than the Java language designers can make them work, but after many failed attempts, it doesn't seem likely anymore
Re:Java 1.5 vs c# 2.0?
on
Java 1.5 vs C#
·
· Score: 2, Informative
But will you be releasing those apps before dotNet 2.0 is officially released
Well, people seem to be reluctant to release code for Java 1.5 as well because there seem to be some backwards compatibility issues as well.
To me, it doesn't get interesting anyway until gcj and Mono have the features, and both of those are still several months off.
The VM doesn't use information about generic types, but it is stored in the class files and used by the compiler when you import those classes.
That's what I remembered and that isn't statically type safe, since you can compile against one version of a library and load another version of it (that's a pretty common mistake to make). If you do that with non-generic code, you are guaranteed that you will get a type error at load time at the latest. But with generic code, if the VM doesn't check the generic types, you won't get a load time type error but you may instead get a runtime type error at an arbitrary point later in time.
I believe Sun's attempt at backwards compatibility with existing Java class libraries may introduce additional possibilties for type errors.
Please prove to me that seti@home will never interfere with the other software on my production server.
He isn't running it on your production server, he is running it on his production server. It it interferes with anything, he already has to fix it--that's why he had the necessary privileges that allowed him to install SETI@Home in the first place.
But that doesn't mean it is OK to wander around installing extraneous junk on production equipment.
If he can "wander around" and install stuff on a server he isn't administering, then it isn't he who should get fired but the server administrator.
Re:flamebait
on
Java 1.5 vs C#
·
· Score: 4, Informative
.NET in the enterprise is currently painful.
It's not about the enterprise, it's about the desktop. Microsoft had to do something there because C++ and MFC and COM was seriously getting in the way of getting the job done. Java isn't even trying to compete seriously on the desktop, so C# wins by default on the desktop. And (crazy as those people may seem to you and me) Microsoft desktop application developers actually seem to like Visual Studio. If Microsoft can additionally win market share from Java in the enterprise, that's icing on the cake for them.
Yes, and Microsoft happens to be right on this one: "enforced checked exceptions" are a lousy idea.
As for copying, there was very little in Java that was original--languages like it go back to the 1960's. And in the few areas where Sun tried to "innovate", they often screwed up.
Languages can't be "open source", only their implementations can be. Both Java and C# nominally have open source implementations. However, the open source Java implementations may be legally encumbered because Sun owns a lot of intellectual property in Java. The open source C# language implementations conform to an open standard (ECMA/ISO C#), and they seem to be completely unencumbered. The.NET platform may be encumbered by a patent, but you don't have to use.NET in order to use C#--there are, in fact, better toolkits and libraries available for C# already.
Despite being marketed as portable, but have portability issues. Java is not backward compatible with older versions. C# has problems with porting some of the graphics stuff to Linux.
You're confusing language and libraries..NET is not fully supported on Linux and probably never will be. But the C# language is fully supported on Linux, and there are multiple sets of libraries available for it, several of them even cross-platform (Gtk#, wxWindows#, etc.). In fact, C# does not aspire to guarantee the same degree of cross-platform support, and many people view that as an advantage.
We don't really need them. PHP/Perl serve my needs on the web/server side. C++ and Python server my needs on the desktop side.
We need a replacement for C++ because people just don't seem to be able to code safe, secure, reliable applications in it. Java isn't a feasible replacement for C++ because it completely insulates the programmer from the underlying platform. But C# is a plausible successor: it gives programmers access to the underlying platform when they ask for it, but otherwise protects them from accidents.
still very different
on
Java 1.5 vs C#
·
· Score: 4, Informative
Don't be fooled by syntactic similarities; C# and Java are still very different languages:
C# has value classes
C# has operator overloading
C# has multidimensional arrays
C# has unsafe modules; in unsafe modules, you can call C functions directly (no JNI) and manipulate C data structures and pointers
C# does not force you to declare exceptions
C#'s generics are efficient for unboxed types while Java boxes in many cases
C#'s generics are type-safe across compilation boundaries (I believe Java's are not)
Basically, Sun did a bunch of things they could do without changing the VM too much and without breaking old code. But for a bunch of other features, they punted and just added a bit of syntactic sugar to the compiler that makes Java look superficially like it's doing the same thing but is much less efficient under the covers.
For enterprise applications, those differences may not matter much (and they may even be harmful), which is probably why Sun doesn't do anything about them. But for desktop use and application programming, they do matter. Microsoft wanted to create a new language that their legions of C++ programmers could use, and C# is a pretty credible answer for that. Those people don't care about cross-platform features, they care about getting the job done, and if that involves the occasional unsafe module, it doesn't matter to them.
Well, I'm talking about KDE, not pure Qt. You can't develop KDE software for Windows, so it's not really an issue.
Well, gee, why do you think that is? Could it be perhaps that the KDE developers just aren't motivated to port their stuff to Windows, knowing that they couldn't deliver it there anyway?
It would make a lot of sense to have the entire desktop functionality of KDE and/or Gnome available natively on Windows and Macintosh; if you get people used to that kind of end-user software, eventually, they'll ditch the proprietary kernels as well. Gnome's license permits that and its libraries are being ported.
The people who are bothered by C++ are generally kids who taught themselves C in their spare time (and good for them for taking the initiative),
Yeah, just keep putting people into convenient little boxes; you can keep your mind really closed that way.
The fact is that I use C++ for lots of things, and will likely continue to do so long after Gnome and KDE are ancient history. I just don't see it as the future of end user applications software development: Python and C# will go from being common choices to taking over. That will happen via bindings of the respective toolkits to those languages, and they do exist; I just would prefer them not to have dependencies on C++ when most people aren't using C++ anymore for applications development.
Finally, Qt's current license is only a "problem" if you want to close the source of your app and sell it. In that case, you have to buy a copy of Qt. So where's the problem?
The part where money changes hands, and the part where Troll Tech retains ownership of the Qt library. There is also the part where vendors like Sun don't want to have to pay Troll Tech for every copy of their OS that they are shipping, so when they pick their Linux desktop standard, KDE is out.
It's not a question of whether it's justifiable for TT to charge, it's a question of whether there are cheaper alternatives that work reasonably well, and there are.
C is a shitty, shitty desktop and application language
C++ is a shitty, shitty desktop and application language, too. That's probably why you are using PyKDE.
Practically NO commercial desktop software is written in C, and there's a very good reason for that: it's time-consuming (time is money, as we all know) and produces bug-ridden code.
You won't get an argument from me there. And that's why many Gnome applications are not written in plain C.
But the fact that Gtk+ is written in C means that when I'm using PyGnome or Gtk#, I don't also depend on C++. And when I do feel like using a C++ API (because C++ is a great language for numeric applications), I still can.
Laptop backpacks have a built-in pouch for your notebook--convenient if you have to take it out frequently, but they aren't that great for traveling in my experience.
A better solution might be to get a travel backpack together with something that wraps tightly around just the laptop. There are some notebook pouches or cases that even let you open the notebook without opening it.
Another choice might be to get a notebook that is built for it. The Apple iBooks, in particular, are designed for student usage and pretty good for that (if you can live with their OS and modest performance; Linux works pretty well on them, though).
Slashdot Mirror
Maybe it hasn't been tried for Apple software, but at least one EULA was declared enforceable in an U.S. court. Sad, isn't it?
There is nothing wrong with EULAs being enforceable in general: people put effort into creating software and they should get some control over that software.
But there should be limits on what EULAs can impose on you. EULAs should not be permitted to impose restrictions on reverse engineering or resale of software. And you should be able to return software for a full refund if you don't accept the EULA (it should be up to the people creating the software to make sure you see the EULA before you have a chance to copy the media).
First of all, legal guardians are responsible for the actions of minors; if your kid orders $10000 worth of candy from a web site on your credit card, well, that's just too bad for you.
In any case, if you want to avoid having a legally binding contract under which you can use the software, you can dispense with all the complications of having the neighbor's kid install the software, you can just download the software from some file sharing network and save yourself the money: the effect is the same. Either way, you don't have a legal agreement with the vendor, which means you don't have any obligations to them, but you also don't have a license to run their software.
On top of that, some argue that the entire license agreement is BS. By law, a contract requires two parties to agree. Some argue that this agreement needs to be in place at the time of purchase.
The code is still copyrighted and you can only use it because a contract gives you permission to use the code. If you can successfully argue that there is no contract, or that the contract is invalid, then things revert to their previous state.
So, yes, no matter what the EULA says, you can probably fairly easily force the seller to take back the software and return your money. Furthermore, there are unconscionable provisions and legal pitfalls in many EULAs that may not be enforceable at all against consumers (businesses are generally expected to be smart enough to understand the fine print).
But none of that means that you can force the seller to let you use their software for free: the software is still copyrighted and you can still only use it under some sort of agreement.
The same is, incidentally, true for GNU software: you can choose to agree to the GPL or you can choose to challenge its validity; but no matter which choice you make, the software remains copyrighted, and if you challenge the validity of the GPL, then, obviously, you have no right to use the software.
I feel sorry for these guys, American kids that went through hell in Vietnam. But they have turned into angry old men without getting any wiser. Today, they are just letting themselves be used as political pawns. Rather than facing the fact that they were fighting in an purposeless war that the US lost and in which the US injured large numbers of innocent civilians, rather than facing that it was their own government that caused them all this pain and suffering, they want to cling to the illusion that there was nobility and purpose to this war.
The sad thing is that Bush is far more likely to generate the next generation of hurt, confused, and angry veterans. Bush doesn't know first hand what happens to US soldiers in battle and he doesn't seem to care much either (except for photo ops). Kerry may have many flaws, and he may not have seen the worst of Vietnam when he was serving there, but he has actually seen some of the horrors of war and is far more likely to avoid getting US soldiers into trouble unnecessarily.
You're right that hydrogen needs to be generated. The way hydrogen solves the looming oil shortages is by using it for energy storage and transport: the use of hydrogen allows solar and wind energy to be generated where they can be generated efficiently and then safely shipped to where they are needed.
Sorry, you implied it with the line: "C# does not force you to declare exceptions" What am I supposed to think you are saying?
You are supposed to merely be reminded of a difference between the two; a few words like that are not inended as a comprehensive description of exception handling systems. What it points out is that C# never forces you to deal with exceptions, while Java sometimes does force you to deal with exceptions.
Some libraries have exceptions (though not all) and they do not FORCE you to declare them. they force you to DEAL with them, which usually means catching and re-throwing, or catching and ignoring.
You are right, that was somewhat sloppy writing; I think we both agree on the technical details, we just disagree on their implications.
"Something can throw java.io.IOException even though it doesn't declare it." How would that happen? Give me some Java code that will compile and do exactly that.
It happens when you compile against one version of a class but link against another; while the VM checks all other types at load time, it does not check exception signatures either at load time or even when an exception happens.
So you get the best of both worlds in that you can use hard exceptions if you like, or use soft ones for larger systems where it makes sense
Trouble is that I have to deal with checked exceptions in my code that other people decide to throw in their libraries. Worse, I have to live with the mistakes other people make when trying to deal with checked exceptions that they should simply have let alone. In any case, I think Java's checked exceptions by themselves are not enough to condemn the language; they are just one of a number of nagging technical problems with the language, some of them far more serious.
I think it's great that the Croquet project is making their ideas concrete and that they are putting them out there. Only by building lots of prototypes and systems can one see what works and what doesn't.
Having said that, I suspect most people will not find Croquet useful for day-to-day work. But, again, they have put something on the table that one can discuss and criticize, and that's a lot more than can be said for a lot of other innovators. Some ideas and concepts from their system will surely survive, no matter what happens to Croquet itself.
The thing I think people should think about is which of these concepts can be carried over into X11-based desktops: X11 already has a lot of the functionality needed for making applications mobile and collaborative (in fact, that was the original vision of X11 20 years ago). If people are serious about it, some of the most interesting and useful functionality from Croquet could, for example, form the basis of Gnome 4.0.
Now they will be forced to use MS windows to get to the documentation.
While that is unpleasant enough, perhaps more seriously, they will be forced to agree to Microsoft EULAs separate from the documentation in order to access the documentation.
Of course, they could just convert to PDF--everybody does that (not that PDF is such a great format, but it is considerably better than Word and considerably better documented).
No, not "just" like that. Active X is bad, MHT is good.
PDF's also come in a DRM version, so I don't see an advantage in terms of DRM.
And as far as the formats themselves go, I believe MHT is just a multipart MIME collection of web pages and images--all open stuff; to me, that seems vastly preferable to PDF, which is a huge and complicated spec that Adobe keeps changing around. Recently, Adobe has started to keep some particularly lucrative bits of PDF undocumented and proprietary.
The only problem with MHT, as far as I can tell, is that Mozilla doesn't support it yet. Hopefully, that will get resolved soon.
Correction: C# does not give you the option of using checked exceptions. Java has both checked and unchecked.
Yes, and it's the existence of checked exceptions, any checked exceptions, in Java that is a problem.
Checked exceptions, when used properly, are a very good thing. The point of a checked exception is: "Pardon me developer, but did you ensure that precondition X is satisfied before calling this method?"
Checked exceptions are a way to force a programmer to deal directly inside the caller with error conditions that might arise inside a method, nothing more and nothing less.
If there is a precondition that is not apparent from the API itself, the checked exception is a good compile-time method for getting the developer's attention.
That's what we have types and return values for. Exceptions are there for the opposite purpose: to avoid distracting the programmer at compile-time with irrelevant and useless detail related to error handling.
Your original post proclaimed Java must declare exceptions, which is false.
No, it didn't even proclaim that. But, just for the sake of argument, let's say it did: if you tell me that you eat cookies, does that mean that you eat every cookie in existence?
I agree that unechecked exceptions are the way to go for projects of any size, and have been using them in Java for years now.
The problem with Java's declared exceptions is that libraries are full of exceptions you do have to declare, and those cause problems. That is, the existence of an exception declaration mechanism in the language is the problem.
An additional problem is that Java doesn't even type-check the declared exceptions it has correctly: something can throw java.io.IOException even though it doesn't declare it.
JNI isn't even close:
Anyway, it is arguable that making it easy to call unmanaged code is an extremely bad thing to do. Call me a cynic
No, I just call you someone who has overdosed on Sun marketing.
but I reckon MS is delighted to see people use unmanaged DLLs, COM interop and other unportable stuff since it locks them into MS Windows.
So? Windows programmers apparently don't care; they are just delighted to be off of C++. And as a C#-using Linux programmer, I don't mind being locked into Linux. In fact, as someone who supports and uses open source software, I don't like using Java because Sun is trying to lock me into Java.
And, yes, C# let's me call unmanaged Xlib, unmanaged Numerical Recipes, unmanaged Tcl/Tk, and a lot of other unmanaged code, and I am not ashamed that I'm doing it--it's a good thing.
What was the point of coding with
We are talking about C# here, not
Other points. Java as multidimensional arrays - I used one today in fact.
Not in standard Java. Ragged arrays and the class-based Array definitions are not the same as having true multidimensional arrays in the language.
Also, declaring exceptions is a good thing. It might be a minor pain to declare that your method throws an exception, but it sure beats calling something and having no idea whatsoever if it throws an exception.
In Java, you still don't have any idea if any code you call throws an exception. That is, just because code doesn't declare an exception doesn't mean it doesn't throw one. In fact, in Java, code you call may even throw undeclared exceptions that the language requires you to declare because the VM doesn't check exception declarations. So, you have to write Java code as if any code can throw any exception anyway.
Exception declarations in Java just don't work. Maybe someone with more brains than the Java language designers can make them work, but after many failed attempts, it doesn't seem likely anymore
But will you be releasing those apps before dotNet 2.0 is officially released
Well, people seem to be reluctant to release code for Java 1.5 as well because there seem to be some backwards compatibility issues as well.
To me, it doesn't get interesting anyway until gcj and Mono have the features, and both of those are still several months off.
The VM doesn't use information about generic types, but it is stored in the class files and used by the compiler when you import those classes.
That's what I remembered and that isn't statically type safe, since you can compile against one version of a library and load another version of it (that's a pretty common mistake to make). If you do that with non-generic code, you are guaranteed that you will get a type error at load time at the latest. But with generic code, if the VM doesn't check the generic types, you won't get a load time type error but you may instead get a runtime type error at an arbitrary point later in time.
I believe Sun's attempt at backwards compatibility with existing Java class libraries may introduce additional possibilties for type errors.
Please prove to me that seti@home will never interfere with the other software on my production server.
He isn't running it on your production server, he is running it on his production server. It it interferes with anything, he already has to fix it--that's why he had the necessary privileges that allowed him to install SETI@Home in the first place.
But that doesn't mean it is OK to wander around installing extraneous junk on production equipment.
If he can "wander around" and install stuff on a server he isn't administering, then it isn't he who should get fired but the server administrator.
.NET in the enterprise is currently painful.
It's not about the enterprise, it's about the desktop. Microsoft had to do something there because C++ and MFC and COM was seriously getting in the way of getting the job done. Java isn't even trying to compete seriously on the desktop, so C# wins by default on the desktop. And (crazy as those people may seem to you and me) Microsoft desktop application developers actually seem to like Visual Studio. If Microsoft can additionally win market share from Java in the enterprise, that's icing on the cake for them.
Yes, and Microsoft happens to be right on this one: "enforced checked exceptions" are a lousy idea.
As for copying, there was very little in Java that was original--languages like it go back to the 1960's. And in the few areas where Sun tried to "innovate", they often screwed up.
Neither are open source.
.NET platform may be encumbered by a patent, but you don't have to use .NET in order to use C#--there are, in fact, better toolkits and libraries available for C# already.
.NET is not fully supported on Linux and probably never will be. But the C# language is fully supported on Linux, and there are multiple sets of libraries available for it, several of them even cross-platform (Gtk#, wxWindows#, etc.). In fact, C# does not aspire to guarantee the same degree of cross-platform support, and many people view that as an advantage.
Languages can't be "open source", only their implementations can be. Both Java and C# nominally have open source implementations. However, the open source Java implementations may be legally encumbered because Sun owns a lot of intellectual property in Java. The open source C# language implementations conform to an open standard (ECMA/ISO C#), and they seem to be completely unencumbered. The
Despite being marketed as portable, but have portability issues. Java is not backward compatible with older versions. C# has problems with porting some of the graphics stuff to Linux.
You're confusing language and libraries.
We don't really need them. PHP/Perl serve my needs on the web/server side. C++ and Python server my needs on the desktop side.
We need a replacement for C++ because people just don't seem to be able to code safe, secure, reliable applications in it. Java isn't a feasible replacement for C++ because it completely insulates the programmer from the underlying platform. But C# is a plausible successor: it gives programmers access to the underlying platform when they ask for it, but otherwise protects them from accidents.
Basically, Sun did a bunch of things they could do without changing the VM too much and without breaking old code. But for a bunch of other features, they punted and just added a bit of syntactic sugar to the compiler that makes Java look superficially like it's doing the same thing but is much less efficient under the covers.
For enterprise applications, those differences may not matter much (and they may even be harmful), which is probably why Sun doesn't do anything about them. But for desktop use and application programming, they do matter. Microsoft wanted to create a new language that their legions of C++ programmers could use, and C# is a pretty credible answer for that. Those people don't care about cross-platform features, they care about getting the job done, and if that involves the occasional unsafe module, it doesn't matter to them.
Well, I'm talking about KDE, not pure Qt. You can't develop KDE software for Windows, so it's not really an issue.
Well, gee, why do you think that is? Could it be perhaps that the KDE developers just aren't motivated to port their stuff to Windows, knowing that they couldn't deliver it there anyway?
It would make a lot of sense to have the entire desktop functionality of KDE and/or Gnome available natively on Windows and Macintosh; if you get people used to that kind of end-user software, eventually, they'll ditch the proprietary kernels as well. Gnome's license permits that and its libraries are being ported.
The people who are bothered by C++ are generally kids who taught themselves C in their spare time (and good for them for taking the initiative),
Yeah, just keep putting people into convenient little boxes; you can keep your mind really closed that way.
The fact is that I use C++ for lots of things, and will likely continue to do so long after Gnome and KDE are ancient history. I just don't see it as the future of end user applications software development: Python and C# will go from being common choices to taking over. That will happen via bindings of the respective toolkits to those languages, and they do exist; I just would prefer them not to have dependencies on C++ when most people aren't using C++ anymore for applications development.
Finally, Qt's current license is only a "problem" if you want to close the source of your app and sell it. In that case, you have to buy a copy of Qt. So where's the problem?
The part where money changes hands, and the part where Troll Tech retains ownership of the Qt library. There is also the part where vendors like Sun don't want to have to pay Troll Tech for every copy of their OS that they are shipping, so when they pick their Linux desktop standard, KDE is out.
It's not a question of whether it's justifiable for TT to charge, it's a question of whether there are cheaper alternatives that work reasonably well, and there are.
C is a shitty, shitty desktop and application language
C++ is a shitty, shitty desktop and application language, too. That's probably why you are using PyKDE.
Practically NO commercial desktop software is written in C, and there's a very good reason for that: it's time-consuming (time is money, as we all know) and produces bug-ridden code.
You won't get an argument from me there. And that's why many Gnome applications are not written in plain C.
But the fact that Gtk+ is written in C means that when I'm using PyGnome or Gtk#, I don't also depend on C++. And when I do feel like using a C++ API (because C++ is a great language for numeric applications), I still can.
Laptop backpacks have a built-in pouch for your notebook--convenient if you have to take it out frequently, but they aren't that great for traveling in my experience.
A better solution might be to get a travel backpack together with something that wraps tightly around just the laptop. There are some notebook pouches or cases that even let you open the notebook without opening it.
Another choice might be to get a notebook that is built for it. The Apple iBooks, in particular, are designed for student usage and pretty good for that (if you can live with their OS and modest performance; Linux works pretty well on them, though).