You are confusing.NET with the CLR and C-sharp..NET includes a huge volume of libraries and also other languages (VB.NET) that haven't been submitted to ECMA.
Apparently the new Java evangelism strategy is lying. There are lots of nice things about Java, and if you have alot of hardware, it scales well. But its still not `ready for the desktop', get over it.
Sorry, but I am using Java for desktop applications that are used on a daily basis. No issues about performance; no issues about repainting. It seems to me that part of the continuing anti-Java envangelism is obviously lying.
JEdit does _not_ launch instantaneously, it takes almost twice as long as firefox.
And this is an example of the blantant lying. No-one was claiming that JEdit launched '_instanteously_'. The claim was that it was no slower than some other typical Windows applications. Simply working through a list of Windows applications until you happen to find one that starts faster than JEdit is not evidence against this, only evidence that you are desperate to try and prove Java slow, for whatever reason.
You are worried about a possible 5MB memory leak, on machines which have typically 50 or 100 times as much memory.
You are worried about issues of GTK look and feel on a system that has hundreds of possible free look-and-feel options.
You are worried about minor details of testing of Swing apps, because it lacks the ability to be tested in ways that have never been available in any other GUI system.
Is that is all you can come up with?
I have never seen such few and trivial complaints about any development system, and I have been developing GUI systems for nearly 30 years.
There seems to be some very strange thing about Java that means that even though, by any standards, it is the most robust and portable system ever developed, posters to Slashdot still complain.
However, in the real world we don't have weeks to fine-tune and optimize our Swing UIs.
And you really don't need to. I find it astonishing the way that criticisms of Swing that were fair 4-5 years ago are still being repeated. Swing has been fast since the later releases of Java 1.4. Swing has no performance issues on Java 1.5, and Java 1.5 apps start fast (I have just opened JEdit on my laptop PC. It started up faster than IE or Acrobat on the same machine. The menus and controls are instantly responsive).
If you have any issues with performance, get an up-to-date Java. Java 1.5 has been around for 18 months - there is no excuse!
Where are the statistics to back up your assertion - that Postgres performs better with a high volume of inserts/updates/deletes than MySQL with InnoDB?
Or are you just repeating something you've heard?
Why are you questioning this? This has been common knowledge for years. Both MySQL and PostgreSQL have their relative strengths.
From Wikipedia:
"Critics find MySQL's popularity surprising in the light of the existence of other open source database projects with comparable performance and in closer compliance to the SQL standards."
MySQL has always been oriented to performance rather than features and its use as a backend for web sites has always been a primary goal for its developers.
No. MySQL has always been oriented to performance for reasonably low volume applications and websites, and it does extremely well in this role, and is a great database for hosting websites. PostgreSQL, on the other hand, has always shown its strength for higher volumes of traffic and higher numbers of concurrent connections.
To moderators. The original post was not intended as flamebait. It was a criticism of the very frequent attitude that all you ever need for any development are popular open source tools, and anyone resorting to Java or Oracle or DB2 is simply wasting their money. The flamebait is surely the original claim that MySQL is suitable for any website!
Keep in mind the target audience of the book. It is called 'Beginning PHP and MySQL 5' because it is for beginners. How many beginners are going to start out creating banking applications? If the developers at "all those banks and stock exchanges handling vast loads" are using PHP and MySQL with the help of this book to develop their applications, then I'm going to stuff my money under my mattress. Lighten up a little.
The problem is that too many beginners are shown easy software development languages and techniques as if those are all they will ever need. This happened with Visual Basic in the 90s, and it is happening with PHP, MySQL and now Ruby on Rails. These are all great tools for development, but I have had personal experience of the disasters that can result when such tools are used beyond their capabilities.
Similarly MySQL is a free database which is ideal for use as a backend for any website.
Any website? Wow! Someone had better tell all those banks and stock exchanges handling vast loads and requiring guaranteed uptime for their websites and web services on their huge clustered servers that they should all switch to MySQL!
Sorry, but saying 'any' website is surely something of an exaggeration?
You might like to consider Stripes as the web framework for the course.
What is the point of teaching a framework that isn't widely used and is non-standard, no matter what the quality?
JSF (a JSR standard) has all the momentum behind it. There are tools for very fast development like Studio Creator. There are powerful components from many vendors, and exciting projects based on it like facelets.
What developers personally use is one thing. What they teach is another, and they have a responsibility to teach what students are actually going to be asked to use.
I'm still convinced that Rails is highly suited for the stuff they're doing right now, whereas the EJB tech they're using seems highly suited for deploying to the enormous server farms that they hope to need in the future.
Java offers a lot between these two scales of development. Anyone thinking of starting a project in Rails should seriously consider matters of performance, internationalisation and the ability to scale up their project later. What looks like a small Rails project now could easily grow, and require re-writing.
There are combinations of Java technologies that allow very fast development of small projects - JSF with facelets combined with Spring and JDO (JPOX) or Hibernate for example, and with this approach you are guaranteed to be able to deal with whatever demand is put on your website.
But students rarely have to write programs that are that complex that that kind of stuff is necessary.... Intuitive understanding of OOP comes from programming in it, not from having an IDE to play with....And refactoring just looks like an automated way to fix your code - having the computer help you so that when you do rewrite your code you don't break it because you weren't paying attention or something equally human.
This is completely the wrong approach, and was shown to be wrong 30 years ago, with the interactive approach introduced by languages such as Smalltalk. It was clearly shown that the best way to understand OOP was indeed having an IDE to play with, so that objects and classes could be experimented with. Even though modern IDEs for other languages are still not up to the level of Smalltalk IDES in the 70s, the same principle applies. Anyone trying to teach OOP with a whiteboard and not by allowing the students to actually create their own objects and inspect and experiment with them (which can be easily done in modern IDEs like Eclipse) is rejecting decades of understanding of this subject.
Sorry, but my view is that anyone who states such things about refactoring is illustrating a deep lack of knowledge about what refactoring is and how it is used. I am not a supporter of all the approaches of 'eXtreme Programming', but one approach I do support is the use of refactoring as a key part of development. Even more conventional developers would not reduce it to 'an automated way to fix code'! (That is as bad as calling OOP 'just a way to organise libraries' - a phrase I have heard far too often).
However, in actuality those people going missing at the second station are actually kidnapped. Of course since five people disappearing is not unusual, you would not care to investigate this at all? Even if many suggested that there may be some foul play involved?
You could easily come up with many more similar scenarios to illustrate my point. Not investigating mysteries, even if just to dispel the myth surrounding them, is what is unscientific.
No, you have it the wrong way around. You are coming up with the myth that they are kidnapped based on no evidence at all, and for no reason.
It would indeed be unscientific to investigate if these people were kidnapped, but it is very disorted logic to come up with the idea from nowhere that kidnapping has happened. You can't start with the principle that there is a mystery!
The problem with your approach is that because it is unlikely that we will be able to find the exact cause of all disappearances, there is always room for myth and mystery. The point of looking at these things rationally is to decide whether such myth and mystery has any place.
So sure, there may be absolutely nothing extraordinary about the Bermuda Triangle and there may be no more disappearances there than anywhere else. If there are unusual circumstances surrounding all or nearly all of those that do take place there though, does that not suggest that there may be something interesting to look at?
It would do if there were any evidence of unusual circumstances. There isn't. There are no more disappearances there than anywhere else, so you could in principle pick anywhere at all and suggest mystery.
Frequency of disappearances is not enough to say that a special explanation is not needed. The question was not "Are there more disappearances in the Bermuda Triangle?" but, "Are the circumstances of disappearances in the Bermuda Triangle unusual?"
It is the same question. If there are no more disapearances there, there is no need for any consideration of unusual circumstances. Unusual circumstances are only needed to explain unusual numbers of disapearances, and there aren't any. Looking for extraordinary explanations of ordinary statistics is unscientific and pointless.
Also, while people keep saying there are statistics, I haven't seen them, nor are sources for the statistics cited.
A good source of statistics is insurance payments for missing vessels: Lloyds of London claim no evidence of any special effect associated with the Bermuda Triangle area (if there were, ships would have to pay extra insurance to enter the area).
I don't know, from my own experience (just a few years ago) I would say that I learned quite a bit from doing some assembly programming. Granted for sake of not being machine dependant we learned fake assembly (LC3) but it was still an interesting and rather useful lesson. One semester only to be sure but still useful.
Yes, but my point is what did you actually learn from it? How was it useful? Machine code development today is vastly different from the way it was decades ago, with multiple cores and multiple pipelines even in the same processor - my view is that assembler programming has moved beyond a useful skill for the average programmer to something best left to specialists and compiler writers.
In the 70s when I first learn C, assembler was useful because it had some direct relevance to what was happening in the C code. But now, it often doesn't. So what is the point?
But seriously, what if in the ocean the waterflow is spinning very hard itself under certain conditions, wouldn't that be a possible explanation for the disappearances in the Bermuda Triangle?
You don't need an explanation for the disappearances in the Bermuda Triangle, at least no special explanation. The disappearances there occur at no greater frequency per unit of shipping or flight than anywhere else in the world.
Sure you can do it without an IDE. "Refactoring" I think is a buzzword anyway for "cleaning up a rough draft" or "good coding practices."
No, it isn't - it is far more than that. Refactoring is a fundamental set of tools for modern development. It includes things like determining where methods and classes are used, and allowing instant experimentation with abstract classes and inheritance - things that are very useful for an interactive understanding of OOP, interfaces etc. With an IDE you can show these approaches easily, whereas without this would be a struggle.
It's certainly made easier with an IDE, but student projects are never large enough to require one. I think teaching IDEs would be great for classes that teach software design or other higher level concepts, but not other programming classes (OS, compilers, etc), and certainly not intro programming courses.
The thing is, they are going to have to use some sort of interface to edit their code, run it and debug it. If you give them VI + bash you are effectively giving them an 'IDE' - a very poor one. Why not allow them to easily step through their code, set breakpoints; examine what happens to variables? Setting all this up as a standard project in an IDE (you can even script examples) is far easier. In fact, I would say this is the best way to run an intro class, as it means the teacher has far more control over what the student is doing - trying to deal with a mess of windows with VI or notepad.exe is far harder than to have a pre-configured Eclipse or NetBeans.
I just can't see the point of forcing students back to the way development was done in the 60s and 70s.
Absolutely no way is machine code necessary, in fact it is a serious distraction from learning good development. (How could understanding the details of wildly different machine codes such as Sparc or IA64 be of any relevance?) I see far, far too many developers worrying about details of optimisation of their C++ code and not working in a far more productive way that is abtracted from the workings of the machine.
I learned about the workings of the machine.
That may well have been relevant on the 6502 or 8088 (it was when I used them), but is a total waste of time now. First of all, good compilers should abstract away these details (just as modern machine code abstracts away microcode), and these days any decent developer should have portability as a primary concern of their development, which means using languages like Ruby, PERL, Python and Java, and even well-written C++. This means understanding general details of what a stack or heap are, but in no way should it require any understanding of the underlying machine code. Extrapolating back to the 8088 or PDP/11 days is equivalent to suggesting that we all write our BASIC code with single-letter variables in order to save memory - historically interesting, but of no practical use for modern development.
Why have one at all? Unless your class is on the specific IDE or "Software Development Techiniques", why chain them to a specific technology?
Because you can't easily teach important modern development techniques like refactoring without a good IDE. You don't have to teach them a specific IDE to do this - but doing this without a good idea is vert difficult.
What will be the best tool for the job in 5 years? In 20 years? Will Sun still be developing Java for Linux in that amount of time?
Why the focus on Sun? Don't you realise that other companies develop Java, including for Linux - like IBM?
Free software is the best tool for the job when your job has very long-term goals, and Negroponte knows it.
This is false. There have been non-free software products that have been around for far longer than free software and have excellent backward compatibility - Oracle is an example. In fact many free software products seem to have little worries about backward compatibility, breaking existing code. Look at migration issues with different versions of GCC and PERL over the past 10-15 years.
I am not saying that there is not some first-rate free software around, but to generalise in this way is nonsense.
A true scientist would note the differences and try to come up with a hypothesis for these differences, but these differences are overlooked. I don't understand why.
The differences aren't overlooked. There have been many hypotheses as to why we have bigger brains and greater intelligence than other apes. One is that humans went through a semi-aquatic phase several million years ago (explaining many physical differences from other apes, such as relative hairlessness and a layer of fat beneath our skin). One advantage of seafood is that it provides fats and nutrients that allow increased brain development.
In the alternative universe that you live in that all might be true. The fact is that Microsoft's server software now outsells all of proprietary Unix combined and keeps on climbing in market share.
I suppose you do realise that one of the most important deployment platforms for J2EE is Windows Server? You are confusing 'server operating systems' with 'software deployed on those operating systems'.
And of course we don't need to discuss the desktop.
Where Swing has a bigger presence than Webforms.
Java was never even a blip on the desktop radar screen...even in the open source world.
Wrong. Java has substantial use for internal desktop development.
But it's not just.NET/Mono that is intruding on Java's server space. You've got LAMP and RoR. And those solutions are chipping away at Java on the low-end. By the time Java only has the very high-end server space left, it'll be all over.
What a set of delusions! Mono simply doesn't exist as a server solution, and RoR, for all its hype, is hardly used at all for serious commercial development.
You need to take your Microsoft blinkers of and take a look at the real world. Java use is still growing - check any technology analysis or job market survey.
Sun doesn't support Java on Linux. Open sourcers complain. Now, they do, thanks to open sourcers complaining.
Sun didn't support Java on Linux because of open source pressure. They supported it because Linux was very successful commercially and so needed an implementation of the primary commercial development language - Java.
Sun doesn't support Java on Linux as a tier-1 platform. Open sourcers complain. Now, they do, thanks to open sourcers complaining.
Which is complete nonsense. Sun have supported Java on Linux as a primary platform for a very long time.
Sun doesn't release source code for Java. Open sourcers complain. Now, they do, thanks to open sourcers copmlaining.
You need to have a far better understanding of Linux and Java history.
I really don't think you understand how little open source matters in this respect. Java is already the number one development language in almost all areas of development - open source, server side, commercial application development. Sun has open sourced more lines of code in the past year than any other organisation - the entire Solaris codebase, and now they are doing this for Java. However, unless they deliver the entire source code as GPL directly to Richard Stallman, along with a grovelling apology for ever having doubted the true open source faith, some people will never be satisfied!
This is hilarious. Sun release a language and make it freely available. Open sourcers complain. Just about everyone else uses it. Sun make the source code available under a restricted license. Open sourcers complain. Java gets even wider adoption. Sun opens up the source even more (with the Java 6.0 project). Open sourcers still complain. Java becomes the number one language in Sourceforge. Sun finally allows distribution of the JRE as part of Linux packages and promises to open source Java.
Open sourcers STILL complain.
If you had any idea about the state of Java in the IT industry, you would realise that Sun really, really don't have to work to get Java 'out there' - Java has become the dominant server-side development language, and.NET isn't even coming close to nipping at Java's heels. Compared to Java use, C# barely registers.
Slashdot Mirror
"Good question. Why are they supporting
because it's not a proprietary standard
http://msdn.microsoft.com/netframework/ecma/
You are confusing
Try it on OS X, then come back. It's tolerable on Windows, but it's not even remotely close on OS X.
Then blame Apple. They write the OS/X versions of Java.
Apparently the new Java evangelism strategy is lying. There are lots of nice things about Java, and if you have alot of hardware, it scales well. But its still not `ready for the desktop', get over it.
Sorry, but I am using Java for desktop applications that are used on a daily basis. No issues about performance; no issues about repainting. It seems to me that part of the continuing anti-Java envangelism is obviously lying.
JEdit does _not_ launch instantaneously, it takes almost twice as long as firefox.
And this is an example of the blantant lying. No-one was claiming that JEdit launched '_instanteously_'. The claim was that it was no slower than some other typical Windows applications. Simply working through a list of Windows applications until you happen to find one that starts faster than JEdit is not evidence against this, only evidence that you are desperate to try and prove Java slow, for whatever reason.
Let's summarise:
You are worried about a possible 5MB memory leak, on machines which have typically 50 or 100 times as much memory.
You are worried about issues of GTK look and feel on a system that has hundreds of possible free look-and-feel options.
You are worried about minor details of testing of Swing apps, because it lacks the ability to be tested in ways that have never been available in any other GUI system.
Is that is all you can come up with?
I have never seen such few and trivial complaints about any development system, and I have been developing GUI systems for nearly 30 years.
There seems to be some very strange thing about Java that means that even though, by any standards, it is the most robust and portable system ever developed, posters to Slashdot still complain.
However, in the real world we don't have weeks to fine-tune and optimize our Swing UIs.
And you really don't need to. I find it astonishing the way that criticisms of Swing that were fair 4-5 years ago are still being repeated. Swing has been fast since the later releases of Java 1.4. Swing has no performance issues on Java 1.5, and Java 1.5 apps start fast (I have just opened JEdit on my laptop PC. It started up faster than IE or Acrobat on the same machine. The menus and controls are instantly responsive).
If you have any issues with performance, get an up-to-date Java. Java 1.5 has been around for 18 months - there is no excuse!
Where are the statistics to back up your assertion - that Postgres performs better with a high volume of inserts/updates/deletes than MySQL with InnoDB?
Or are you just repeating something you've heard?
Why are you questioning this? This has been common knowledge for years. Both MySQL and PostgreSQL have their relative strengths.
From Wikipedia:
"Critics find MySQL's popularity surprising in the light of the existence of other open source database projects with comparable performance and in closer compliance to the SQL standards."
MySQL has always been oriented to performance rather than features and its use as a backend for web sites has always been a primary goal for its developers.
No. MySQL has always been oriented to performance for reasonably low volume applications and websites, and it does extremely well in this role, and is a great database for hosting websites. PostgreSQL, on the other hand, has always shown its strength for higher volumes of traffic and higher numbers of concurrent connections.
To moderators. The original post was not intended as flamebait. It was a criticism of the very frequent attitude that all you ever need for any development are popular open source tools, and anyone resorting to Java or Oracle or DB2 is simply wasting their money. The flamebait is surely the original claim that MySQL is suitable for any website!
Keep in mind the target audience of the book. It is called 'Beginning PHP and MySQL 5' because it is for beginners. How many beginners are going to start out creating banking applications?
If the developers at "all those banks and stock exchanges handling vast loads" are using PHP and MySQL with the help of this book to develop their applications, then I'm going to stuff my money under my mattress. Lighten up a little.
The problem is that too many beginners are shown easy software development languages and techniques as if those are all they will ever need. This happened with Visual Basic in the 90s, and it is happening with PHP, MySQL and now Ruby on Rails. These are all great tools for development, but I have had personal experience of the disasters that can result when such tools are used beyond their capabilities.
Similarly MySQL is a free database which is ideal for use as a backend for any website.
Any website? Wow! Someone had better tell all those banks and stock exchanges handling vast loads and requiring guaranteed uptime for their websites and web services on their huge clustered servers that they should all switch to MySQL!
Sorry, but saying 'any' website is surely something of an exaggeration?
You might like to consider Stripes as the web framework for the course.
What is the point of teaching a framework that isn't widely used and is non-standard, no matter what the quality?
JSF (a JSR standard) has all the momentum behind it. There are tools for very fast development like Studio Creator. There are powerful components from many vendors, and exciting projects based on it like facelets.
What developers personally use is one thing. What they teach is another, and they have a responsibility to teach what students are actually going to be asked to use.
I'm still convinced that Rails is highly suited for the stuff they're doing right now, whereas the EJB tech they're using seems highly suited for deploying to the enormous server farms that they hope to need in the future.
Java offers a lot between these two scales of development. Anyone thinking of starting a project in Rails should seriously consider matters of performance, internationalisation and the ability to scale up their project later. What looks like a small Rails project now could easily grow, and require re-writing.
There are combinations of Java technologies that allow very fast development of small projects - JSF with facelets combined with Spring and JDO (JPOX) or Hibernate for example, and with this approach you are guaranteed to be able to deal with whatever demand is put on your website.
But students rarely have to write programs that are that complex that that kind of stuff is necessary.... Intuitive understanding of OOP comes from programming in it, not from having an IDE to play with....And refactoring just looks like an automated way to fix your code - having the computer help you so that when you do rewrite your code you don't break it because you weren't paying attention or something equally human.
This is completely the wrong approach, and was shown to be wrong 30 years ago, with the interactive approach introduced by languages such as Smalltalk. It was clearly shown that the best way to understand OOP was indeed having an IDE to play with, so that objects and classes could be experimented with. Even though modern IDEs for other languages are still not up to the level of Smalltalk IDES in the 70s, the same principle applies. Anyone trying to teach OOP with a whiteboard and not by allowing the students to actually create their own objects and inspect and experiment with them (which can be easily done in modern IDEs like Eclipse) is rejecting decades of understanding of this subject.
Sorry, but my view is that anyone who states such things about refactoring is illustrating a deep lack of knowledge about what refactoring is and how it is used. I am not a supporter of all the approaches of 'eXtreme Programming', but one approach I do support is the use of refactoring as a key part of development. Even more conventional developers would not reduce it to 'an automated way to fix code'! (That is as bad as calling OOP 'just a way to organise libraries' - a phrase I have heard far too often).
However, in actuality those people going missing at the second station are actually kidnapped. Of course since five people disappearing is not unusual, you would not care to investigate this at all? Even if many suggested that there may be some foul play involved?
You could easily come up with many more similar scenarios to illustrate my point. Not investigating mysteries, even if just to dispel the myth surrounding them, is what is unscientific.
No, you have it the wrong way around. You are coming up with the myth that they are kidnapped based on no evidence at all, and for no reason.
It would indeed be unscientific to investigate if these people were kidnapped, but it is very disorted logic to come up with the idea from nowhere that kidnapping has happened. You can't start with the principle that there is a mystery!
The problem with your approach is that because it is unlikely that we will be able to find the exact cause of all disappearances, there is always room for myth and mystery. The point of looking at these things rationally is to decide whether such myth and mystery has any place.
So sure, there may be absolutely nothing extraordinary about the Bermuda Triangle and there may be no more disappearances there than anywhere else. If there are unusual circumstances surrounding all or nearly all of those that do take place there though, does that not suggest that there may be something interesting to look at?
It would do if there were any evidence of unusual circumstances. There isn't. There are no more disappearances there than anywhere else, so you could in principle pick anywhere at all and suggest mystery.
Frequency of disappearances is not enough to say that a special explanation is not needed. The question was not "Are there more disappearances in the Bermuda Triangle?" but, "Are the circumstances of disappearances in the Bermuda Triangle unusual?"
It is the same question. If there are no more disapearances there, there is no need for any consideration of unusual circumstances. Unusual circumstances are only needed to explain unusual numbers of disapearances, and there aren't any. Looking for extraordinary explanations of ordinary statistics is unscientific and pointless.
Also, while people keep saying there are statistics, I haven't seen them, nor are sources for the statistics cited.
A good source of statistics is insurance payments for missing vessels: Lloyds of London claim no evidence of any special effect associated with the Bermuda Triangle area (if there were, ships would have to pay extra insurance to enter the area).
I don't know, from my own experience (just a few years ago) I would say that I learned quite a bit from doing some assembly programming. Granted for sake of not being machine dependant we learned fake assembly (LC3) but it was still an interesting and rather useful lesson. One semester only to be sure but still useful.
Yes, but my point is what did you actually learn from it? How was it useful? Machine code development today is vastly different from the way it was decades ago, with multiple cores and multiple pipelines even in the same processor - my view is that assembler programming has moved beyond a useful skill for the average programmer to something best left to specialists and compiler writers.
In the 70s when I first learn C, assembler was useful because it had some direct relevance to what was happening in the C code. But now, it often doesn't. So what is the point?
But seriously, what if in the ocean the waterflow is spinning very hard itself under certain conditions, wouldn't that be a possible explanation for the disappearances in the Bermuda Triangle?
You don't need an explanation for the disappearances in the Bermuda Triangle, at least no special explanation. The disappearances there occur at no greater frequency per unit of shipping or flight than anywhere else in the world.
Sure you can do it without an IDE. "Refactoring" I think is a buzzword anyway for "cleaning up a rough draft" or "good coding practices."
No, it isn't - it is far more than that. Refactoring is a fundamental set of tools for modern development. It includes things like determining where methods and classes are used, and allowing instant experimentation with abstract classes and inheritance - things that are very useful for an interactive understanding of OOP, interfaces etc. With an IDE you can show these approaches easily, whereas without this would be a struggle.
It's certainly made easier with an IDE, but student projects are never large enough to require one. I think teaching IDEs would be great for classes that teach software design or other higher level concepts, but not other programming classes (OS, compilers, etc), and certainly not intro programming courses.
The thing is, they are going to have to use some sort of interface to edit their code, run it and debug it. If you give them VI + bash you are effectively giving them an 'IDE' - a very poor one. Why not allow them to easily step through their code, set breakpoints; examine what happens to variables? Setting all this up as a standard project in an IDE (you can even script examples) is far easier. In fact, I would say this is the best way to run an intro class, as it means the teacher has far more control over what the student is doing - trying to deal with a mess of windows with VI or notepad.exe is far harder than to have a pre-configured Eclipse or NetBeans.
I just can't see the point of forcing students back to the way development was done in the 60s and 70s.
Yes.
Hell, yes.
Hell, fuckin' A yes.
Absolutely no way is machine code necessary, in fact it is a serious distraction from learning good development. (How could understanding the details of wildly different machine codes such as Sparc or IA64 be of any relevance?) I see far, far too many developers worrying about details of optimisation of their C++ code and not working in a far more productive way that is abtracted from the workings of the machine.
I learned about the workings of the machine.
That may well have been relevant on the 6502 or 8088 (it was when I used them), but is a total waste of time now. First of all, good compilers should abstract away these details (just as modern machine code abstracts away microcode), and these days any decent developer should have portability as a primary concern of their development, which means using languages like Ruby, PERL, Python and Java, and even well-written C++. This means understanding general details of what a stack or heap are, but in no way should it require any understanding of the underlying machine code. Extrapolating back to the 8088 or PDP/11 days is equivalent to suggesting that we all write our BASIC code with single-letter variables in order to save memory - historically interesting, but of no practical use for modern development.
Why have one at all? Unless your class is on the specific IDE or "Software Development Techiniques", why chain them to a specific technology?
Because you can't easily teach important modern development techniques like refactoring without a good IDE. You don't have to teach them a specific IDE to do this - but doing this without a good idea is vert difficult.
What will be the best tool for the job in 5 years? In 20 years? Will Sun still be developing Java for Linux in that amount of time?
Why the focus on Sun? Don't you realise that other companies develop Java, including for Linux - like IBM?
Free software is the best tool for the job when your job has very long-term goals, and Negroponte knows it.
This is false. There have been non-free software products that have been around for far longer than free software and have excellent backward compatibility - Oracle is an example. In fact many free software products seem to have little worries about backward compatibility, breaking existing code. Look at migration issues with different versions of GCC and PERL over the past 10-15 years.
I am not saying that there is not some first-rate free software around, but to generalise in this way is nonsense.
A true scientist would note the differences and try to come up with a hypothesis for these differences, but these differences are overlooked. I don't understand why.
The differences aren't overlooked. There have been many hypotheses as to why we have bigger brains and greater intelligence than other apes. One is that humans went through a semi-aquatic phase several million years ago (explaining many physical differences from other apes, such as relative hairlessness and a layer of fat beneath our skin). One advantage of seafood is that it provides fats and nutrients that allow increased brain development.
In the alternative universe that you live in that all might be true. The fact is that Microsoft's server software now outsells all of proprietary Unix combined and keeps on climbing in market share.
.NET/Mono that is intruding on Java's server space. You've got LAMP and RoR. And those solutions are chipping away at Java on the low-end. By the time Java only has the very high-end server space left, it'll be all over.
I suppose you do realise that one of the most important deployment platforms for J2EE is Windows Server? You are confusing 'server operating systems' with 'software deployed on those operating systems'.
And of course we don't need to discuss the desktop.
Where Swing has a bigger presence than Webforms.
Java was never even a blip on the desktop radar screen...even in the open source world.
Wrong. Java has substantial use for internal desktop development.
But it's not just
What a set of delusions! Mono simply doesn't exist as a server solution, and RoR, for all its hype, is hardly used at all for serious commercial development.
You need to take your Microsoft blinkers of and take a look at the real world. Java use is still growing - check any technology analysis or job market survey.
That's absolutely right and I dare you to find holes in that, rather than dubious and irrelevent complaints about "open sourcers".
The hole in that is that it is now factually wrong. The license has changed as of a couple of days ago.
OTOH you could view it like this:
Sun doesn't support Java on Linux. Open sourcers complain. Now, they do, thanks to open sourcers complaining.
Sun didn't support Java on Linux because of open source pressure. They supported it because Linux was very successful commercially and so needed an implementation of the primary commercial development language - Java.
Sun doesn't support Java on Linux as a tier-1 platform. Open sourcers complain. Now, they do, thanks to open sourcers complaining.
Which is complete nonsense. Sun have supported Java on Linux as a primary platform for a very long time.
Sun doesn't release source code for Java. Open sourcers complain. Now, they do, thanks to open sourcers copmlaining.
You need to have a far better understanding of Linux and Java history.
I really don't think you understand how little open source matters in this respect. Java is already the number one development language in almost all areas of development - open source, server side, commercial application development. Sun has open sourced more lines of code in the past year than any other organisation - the entire Solaris codebase, and now they are doing this for Java. However, unless they deliver the entire source code as GPL directly to Richard Stallman, along with a grovelling apology for ever having doubted the true open source faith, some people will never be satisfied!
The real problem with Sun's strategy
.NET isn't even coming close to nipping at Java's heels. Compared to Java use, C# barely registers.
This is hilarious. Sun release a language and make it freely available. Open sourcers complain. Just about everyone else uses it. Sun make the source code available under a restricted license. Open sourcers complain. Java gets even wider adoption. Sun opens up the source even more (with the Java 6.0 project). Open sourcers still complain. Java becomes the number one language in Sourceforge. Sun finally allows distribution of the JRE as part of Linux packages and promises to open source Java.
Open sourcers STILL complain.
If you had any idea about the state of Java in the IT industry, you would realise that Sun really, really don't have to work to get Java 'out there' - Java has become the dominant server-side development language, and
Face it - Sun's strategy has worked.