Unlike Charter (who probably uses something not all that different from an mbox file), Google has a global, highly redundant data store that is easier to insert information into than it is to delete from. Even when an email is "deleted" from the GMail interface, there's no guarantee that the data in GoogleFS is actually gone. Google themselves have stated that it may take months (or even years) before the data is purged from the system.
Which is part of the reason why I actually trust Google with my email. I wouldn't mind them providing a proper backup mechanism (no, POP3 isn't a worthwhile mechanism for me), but it simply isn't as necessary as some hosting providers.
That being said, this entire mess could have been avoided if someone took a tape backup before purging data from the system...:-/
If you use a different tool for every job, you need to maintain all those tools and a task force that's able to use all of them.
That's why the "right tool for the job" is sometimes the tool that meets the greatest cross-section of a company's needs rather than a jumble of tools that are ideal at a lot of little tasks.
e.g. While it's fashionable to hate Java these days, you have to admit that it does have a rather massive cross-section of needs it can meet. Thus one of the reasons why it's so popular in large companies. Yet a smaller company might find more value in using Ruby toolkits to do all their work. Ruby may not be ideal for some of the less glamorous back-end tasks, but tools like Rails gain so much on the front end that Ruby meets a greater cross-section of needs than Java would.
Bugger that common language crap, here in the UK we're generally far more permissive than folk in the US./sweeping generalisation.
Except for Nunchuks and Ninjas. Thus the cartoon "Teenage Mutant Hero Turtles" in which Michaelangelo had a grappling hook rather than a pair of 'chuks.
Yet there are naked women in the newspaper.
It's surprising how much the taboos of cultures can vary. Something perfectly acceptable to one culture is utterly offensive to another culture. Weird, isn't it? =)
I'm well aware that the JVM can (and does) crash. That's why there are certain precautions that should be taken. The key one is to not jump to the latest version of the JVM. Stay with the last major version until a few minor releases have come out to repair any possible defects in the JVM. The next best one is to ensure that the JVM has proper resources. (e.g. Setting -mXm can do wonders.) Another one is making sure that you're running on Big Iron. The JVM is less stable on Windows due to the Windows APIs. (You usually see this in high performance graphics work with the JVM, but it does occasionally happen on the server.)
Last but not least, make sure your programs are correct! If your developers leak threads (yes, I've seen developers do this), of COURSE your JVM is going to crash! Solaris can handle a LOT of threads, but having several thousand hanging threads is not going to keep the JVM stable for very long.:-)
That's easy enough to fix. Sun will be purchasing PHP soon and renaming it to "Sun Java System PHP HyperText Preprocessor" or SJSPHP for short. I only wish I was joking.:-/
Uhhh... no. This article links to a previous article, which links to the article you linked to. Each of these articles shows a progressive evolution of the concept. The article you linked to used reflective tape to accomplish the IR tracking. The article linked to by this article shows how to use a light pen for greater accuracy. THIS article combines the two approaches using IR equipped gloves to create a highly accurate touch surface.
I think everyone might be missing the point. How many people purchase low-end LAMP servers? Whether they be from hosting providers, or setup at home, LAMP is a well-known name in the industry.
Sun has OpenSolaris. Which so far has not quite caught on well enough to challenge LAMP dominance in the low-end of the market. Now imagine if Sun started shipping fully supported SAMP (Solaris Apache MySQL PHP) software distributions branded with "High Performance*, 64-bit Sun MySQL". If they can gain enough brand recognition this way, this free software could be their ticket into gaining more market share.
More market share on the low-end means more mind share with the same developers and IT folks who keep forgetting that Sun exists. If Sun can become de facto, they can probably own the low-end, mid-range, and high-end of the market rather than constantly retreating to the ever-shrinking Big Iron market. (Maybe people will even notice that Sun makes extremely affordable Intel machines?)
* Expect Sun to announce the "fastest database ever" by tuning MySQL for their Niagara processors, turning off all transactional safety, and then running benchmarks against the system. With any luck, these semi-valid benchmarks would earn Sun some goodwill for having "improved" MySQL. The double-edged sword here is that Sun would get a reputation for performance with those who don't understand that Niagara is a key component AND Sun would sell more Niagara servers to those who DO understand that Niagara is a key component.
Sun produces a commercial version under the confusing title of "Sun Java System Application Server". (Sun seriously needs to fire their marketing department.:-/) It's worlds away better than Tomcat; which is really a straightforward development server. SJSAS/Glassfish will serve you better in a production environment than Tomcat will. It's also integrated with Netbeans (in a way that actually works!) making it a suprisingly good, if not a bit hefty, development environment.
The article is also missing one other important fact related to this statement:
It appears though that the additional features of the Enterprise version are not enough to compensate for the revenue-destroying effects of the free Community alternative. What else could explain the surprising fact that MySQL has quietly filled out its open source portfolio with a closed source proprietary management software tool known as Enterprise Software Monitor?"
Customers don't pay for MySQL professional because it's not that great of a database. As a "free" option, there's tons of support for it. It was seen early on as "the" database for OSS work. As a result, nearly every OSS tool in existence is built around MySQL.
However, if we're talking about someone looking to pay for support, we're probably talking about a business of some sort. And for businesses, features like ANSI syntax, transactions, reliability, scalability, tools, familiarity to the DBAs, and a strong reputation for customer service are all factors that play into their decision. Why would they purchase MySQL when options like SQL Server, Oracle, DB2, Informix, Pervasive, Teradata, and half a dozen other RDBMSes with stronger reputations in the market are available?
While MySQL has made great strides in their progress toward becoming a competitor in the Enterprise market, it's a bit of an uphill battle that they're going to have a hard time winning. The market sees MySQL as an OSS toy that children play with before they grow up and use a REAL database. Changing that perception is going to be hard.
Worse yet, it's a race against time before powerful new competitors like Apache Derby (formerly Cloudscape) start pushing MySQL out of the market.
That being said, I wish I invented an "OSS toy". A billion dollars as compensation sounds like a rather sweet deal.;-)
oak project (the java origin) was all about programable portable devices
Actually, James Gosling is on record having said that Oak began as an attempt to make a C++ compiler that didn't need to recompile the entire codebase when only one class changed. From there it evolved into a more complex platform that became Oak and later Java.
The Java programming language has things about architecture-neutral executions, for instance, and dealing with the fragile base-class problem. You can actually solve those problems within the context of C++. I mean, it's just sort of an artifact of the way the C++ compilers are built that they have this problem. My original goal was to build a C++ compiler that didn't have these problems. But then as I worked on that, and as the developers on the project sort of came after me, it became really clear that there were other problems that needed solving, and it sort of evolved into just a new language.
Of course, it won't matter. At least until some major browsers support it.
Several of the features (e.g. Canvas) are already supported by all major browsers save for IE.
And it really won't matter until IE supports it.
One of the interesting aims of the HTML 5 standard was to spec the new functionality in such a way as to make it possible to emulate the new APIs in old browser. e.g. Canvas working in IE. (Make sure you click outside the block area to start. I haven't implemented the key passing yet.)
The Storage APIs would be similarly easy to emulate through Cookies, Flash, or Google Gears. (Take your pick.) Server Side Events are more difficult, but I think it might be possible to emulate with XMLHttpRequest. If I'm wrong, there's always a Flash or Java shunt possible. DOM 2 Events is still not supported by IE, but that's easy enough to patch for by wrapping IE's attachEvent scheme.
Basically, we can force Microsoft's hand on this. A simple runtime patch and BAM, we're coding to HTML 5 standards. If enough people do it, Microsoft will realize they've lost that front and move on.
I actually recommend classic assembly as early as possible. If you use a virtual machine that displays the state of the memory and CPU, it will give students a chance to get a grip on what the computer is really doing. THEN they can move on to C. (And/Or LISP, depending on what you want to teach them.)
Of course, we don't quite live in a world where Virtual Machines of antique computers are accepted by teachers as a valid teaching method. (Yet.) So barring assembly, I recommend BASIC first. (Oh, I can hear Dijkstra's cries already. Mwhahaha!) Classic BASIC provides a set of I/O routines that allow a student to become comfortable with working out the logical flow of a program without worrying about the details of printing to the screen or reading a line of input. Just don't dwell on BASIC for too long or you may make the student too comfortable for their own good.
While I understand where you're coming from, I think you need to understand how Java got where it did. Coders of the 80's and 90's were faced with a variety of problems on a regular basis. Problems that were wasting their coding time to the point where they spent more time trying to track down the issues than they did writing the software to begin with. Even the most experience programmer was regularly bit by these issues!
What were they?
Manual memory handling lead to leaks
Mismanaged pointers would dive into the wrong memory by accident
Compiled software was difficult to debug (particularly for low-level DOS software where the debugger rarely worked)
Chaging a base class (C++ specific) would require a recompile of all related classes. Which invariably meant a clean and compile. (This issue was actually the origin of Java.;))
Software rarely compiled across multiple platforms, much less shared binaries across platforms. Write, rewrite, #IFDEF your code like a Christmas tree, compile/test regularly least you break some other platform, yo-ho-ho it's a programmer's life for me.
Pay $5,000 a pop for a TARGA decoder or write your own? (Again and again and again.) Yup, that was life as a C/C++ programmer.
Java solved these problems by looking to the most advanced technology in the industry, and packaging it in a way that was so straightforward and simple that it was the DEFINITION of the KISS principle. What were these wonders?
Garbage Collecting
Complete lack of manual memory management
Stack-based design
Easily implemented, reversible bytecode
Objects/Classes (there's a difference which I won't expand on here) as first-class citizens in the language.
Separation of Classes into dynamic code files
Portable bytecode
Abstract libraries that implemented common data structures and functionality similar to that proposed in STL
The productivity gains from these changes were astounding! But it didn't completely replace low-level coding in C/C++. Why? Because sometimes you needed to get down to the metal to make things work well.
Today, the JVMs have been optimized like crazy. They can automatically make a program run faster as long as you know how to work with the GC and data structures that it provides. If you fight it, your performance drops like a rock. If you don't know how to use it, you might as well be fighting it.
Yet how is a student supposed to know what the JVM is doing if he's never had to scrounge for bytes? If he's never had a practical need for a linked list? If he's never had to implement memory management? If he doesn't have the first clue how to balance a tree? If he can't understand how a garbage collector works? If he doesn't know what a circular reference is? If he can't explain what a pointer is and how a reference is related but different to a pointer? If he doesn't even know what "Turing Complete*" means?
Java as a tool can be sharper than any other blade. But it is a double-edged blade. If you swing it wildly, it will cut you. If you wield it like a master, it will allow you to attack your problems with precision and vigor.
As a side note, I wonder if it isn't time to start teaching students using virtual machines that replicate the limited environments of yesteryear? Not only would it force them into solving the low-level problems, but it would also provide them with the ability to visually inspect the state of the virtual processor, memory, and I/O. Much better than a simple stack-trace, wouldn't you say?;-)
*Imagine a computer scientist with no knowledge of what "Turing Complete" means being assigned to design the future of computers. Frightening concept? Very. Perhaps Quantum Computing would already be here if we had a greater number of qualified scientists?
a CS prof can require assignments to NOT USE Hashtable, Maps etc.
An excellent point, which does indeed refute the authors' argument. To furhter back your comment, I've done advanced algorithms in Java before; sometimes as just a learning experience. There are no barriers to going low-level if you want to. However, I did mention that I felt that their argument only scratched the surface.;-)
My own argument tends to go farther down the line to the point of obtaining an understanding of how to code in the first place. What I have found is that a new programmer rarely knows how to put one line of code in front of another. (Yes, the mere logic of ordering statements often escapes them.) Introducing a new programmer to an object oriented environment at an early stage forces them to think in terms of "magic".
"Yeah, don't worry about that 'public class HelloWorld' bit. We'll get to that later."
"Trust me. You need to have that import in your code. Otherwise it won't work."
"We'll get to that main() method later."
"Why System.out.println? Don't worry, you'll understand that once you understand objects and fields and methods. For now we're just compiling a simple [ed: *cough*] Hello World program."
If these barriers were truly debilitating to a student, then we wouldn't have a problem. They'd learn what they needed to know along the way. Unfortunately, these barriers are far more insidious than that. The student knows this magic works without understanding how it works. So he's able to coast through a variety of tasks without ever worrying about it. Then when he gets to the real world... oops. You mean that wasn't actually magic? I needed to know what that did? But all I ever learned was some control structures! My professor didn't even make me format my code properly!
*sigh*
That's the scene I see far too often. A good programmer can't do a good job unless he knows why he's doing it.
"But AKAImBatman," you say. "Won't most kids going into school these days have prior exposure to programming?"
You are correct! Which makes teaching them the basics that much more important. Once again, when they muddled through as teenagers, they focused on WHAT they could do and not WHY they could do it. Code snippets and tutorials and IDEs abounded! They didn't need to KNOW what they were doing. Just fiddle enough and it will work!
If you take things down to a low level, the majority of the students will be forced to learn or find an easier major. If they already know what you're teaching, then great! They can help with the rest of the class. But if they don't, then they're learning something priceless. Either way, the knowledge is KEY to data structures. One cannot truly understand the intent of most algorithms and data structures until he's visited the metal of the machine and tried to work with the likes of strings, memory allocation, and low-level hardware control. That's when he truly "gets it" and 40+ years of computer science suddenly SNAP into place.
"Ohhhh, I get it! I really do! Hey, I had problem X a month ago that I could have solved if I had just..."
Best. Sound. Evar.;-)
(P.S. In case you're wondering? C++ should NEVER be taught in school. Worst drain bramage you can do to a poor kid. Especially as his first language!)
But when it comes to serious applications for big iron, Java just ain't it.
You'll have to forgive me, but I must raise an eyebrow at this. While the (generically speaking) Java Platform has many potential homes, it has found no better home for its technology than on big iron. Its straightforward design allows for the Virtual Machine to automatically adapt to memory, processors, and optimize away sections of code at runtime in ways that a static compiler will never be able to match. In addition, Java's natural fault tolerance allows for complex multiuser applications that provide logical firewalls between each user. Except in cases of poorly designed code (extremely poorly!), no single user can take down the entire application.
If anything, Java is the ideal solution for Big Iron usage. Which is why I must ask you to clarify. There are certainly super-computing applications where Java is a poor fit. This is due the non-standard low-level design of the hardware that requires a completely different toolkit to take advantage of. (Like it or not Cell is a prime example of this environment.) Other than that exception, though, I have a hard time imagining where Java would be ill suited for Big Iron work.
I guess what I'm suggesting is that Java is a great language for non-programmers to learn to get a task done quickly and painlessly.
I vehemently disagree with this statement. I deal with the incredible task of training amateurs on a regular basis. (Some are even degreed-idiots.) VB is friendly to these amateurs. PHP is friendly to these amateurs..NET is friendly to these amateurs. Java is anything but friendly to someone who can't figure out how to setup their classpath. Even worse, the APIs are ripe for extremity destruction. Nothing says "I don't know what I'm doing" like a coder not using a data structure when it's available, using the wrong data structure (Ouch! My memory! Ouch! My CPU time! Ouch! My I/O!), or simply developing a massive megastructure of code to replicate (badly) something that should take 10 lines of code for anyone who bothered to read the JavaDocs!
As I said, Java is a wonderful tool in the hands of an experienced programmer who knows what it is capable of. In the hands of an amateur or (sometimes worse!) an old hand who's not used to the tools that Java offers, using Java in your project is like asking for your company to be nuked from orbit.
I hope you don't take offense at this, I'm simply pointing out where the language's strengths really apply.
I'm not offended. I'm merely perplexed. You sound like the type of fellow who should have a solid understanding of the platform. So perhaps I am merely misunderstanding your statements?
It would be amazing if people actually read the article every once in a while.:-/
I make a living as a Java programmer. I enjoy the work I do and feel that no other language/platform can even touch Java's capabilities in team and enterprise development. Even for single-programmer development, there are a lot of situations where Java is the solution to end all solutions.
That being said, I agree with the article.
As the author tried to explain, programmers need a solid foundation in data structures and algorithms before they should even begin looking at Java. The specific problem he calls out (which I actually feel only scratches the surface) is that Java offers such a featureful API that the programmer isn't forced to learn the basics. He is able to simply use a Hashtable, a Sort, a LinkedList, or whatever he needs without understanding why it works. Which is a very dangerous thing for someone training to be a Computer Scientist.
A much better approach is to force the student to work through lower-level programming before ever reaching a modern layer that abstracts everything away. Otherwise the student is liable to shoot himself in the foot at a much later date. (Primarily due to a lack of knowledge.) This is very comparable to many sports where expensive, advanced equipment can be an asset to a well-trained athlete. But in the hands of an amateur, the attributes that make the equipment powerful becomes liabilities - and even barriers! - to the athlete's success.
I was asking what the point of his post was. Not what the point of removing these devices was. As I was trying to communicate in my post, the issue of optical drives is becoming null and void in many situations.
Offtopic, but I know a lot of people like to beat up on Apple for the "no internal optical drive on the MacBook Air" thing.
I really have no clue why everyone thought I was trying to be negative about the lack of an optical drive. I thought the emoticon would make it clear that I was pointing to the optical drive's decreasing lack of relevance. It's not obvious at first blush (as optical drives are so ingrained in our thinking), but they really not NOT get used that much any more. If you can't get the software you want over the Internet, then there's a good chance it's too painful to go to the store for anyway.
Slashdot Mirror
See, I thought it went something like this:
Boss: "We need more space on the server"
System Operator: (clickety, clickety) "Sure! What's your username again?"
Boss: (pauses) "Oh shit..."
Unlike Charter (who probably uses something not all that different from an mbox file), Google has a global, highly redundant data store that is easier to insert information into than it is to delete from. Even when an email is "deleted" from the GMail interface, there's no guarantee that the data in GoogleFS is actually gone. Google themselves have stated that it may take months (or even years) before the data is purged from the system.
:-/
Which is part of the reason why I actually trust Google with my email. I wouldn't mind them providing a proper backup mechanism (no, POP3 isn't a worthwhile mechanism for me), but it simply isn't as necessary as some hosting providers.
That being said, this entire mess could have been avoided if someone took a tape backup before purging data from the system...
That's why the "right tool for the job" is sometimes the tool that meets the greatest cross-section of a company's needs rather than a jumble of tools that are ideal at a lot of little tasks.
e.g. While it's fashionable to hate Java these days, you have to admit that it does have a rather massive cross-section of needs it can meet. Thus one of the reasons why it's so popular in large companies. Yet a smaller company might find more value in using Ruby toolkits to do all their work. Ruby may not be ideal for some of the less glamorous back-end tasks, but tools like Rails gain so much on the front end that Ruby meets a greater cross-section of needs than Java would.
Except for Nunchuks and Ninjas. Thus the cartoon "Teenage Mutant Hero Turtles" in which Michaelangelo had a grappling hook rather than a pair of 'chuks.
Yet there are naked women in the newspaper.
It's surprising how much the taboos of cultures can vary. Something perfectly acceptable to one culture is utterly offensive to another culture. Weird, isn't it? =)
You don't say?
I'm well aware that the JVM can (and does) crash. That's why there are certain precautions that should be taken. The key one is to not jump to the latest version of the JVM. Stay with the last major version until a few minor releases have come out to repair any possible defects in the JVM. The next best one is to ensure that the JVM has proper resources. (e.g. Setting -mXm can do wonders.) Another one is making sure that you're running on Big Iron. The JVM is less stable on Windows due to the Windows APIs. (You usually see this in high performance graphics work with the JVM, but it does occasionally happen on the server.)
Last but not least, make sure your programs are correct! If your developers leak threads (yes, I've seen developers do this), of COURSE your JVM is going to crash! Solaris can handle a LOT of threads, but having several thousand hanging threads is not going to keep the JVM stable for very long.
That's easy enough to fix. Sun will be purchasing PHP soon and renaming it to "Sun Java System PHP HyperText Preprocessor" or SJSPHP for short. I only wish I was joking.
No, you lose (sorry, loose) points for that. Tom Cruise stars in that movie, remember? Which means you get scored -1 Scientology Wacko Supporter. :-P
How easily you forget. Slashdot's "scalability" has more to do with Slashcode and ever-improving hardware than it does with--
500 Internal Server Error
(refresh)
500 Internal Server Error
(refresh)
Front Page - Logged Out
(reply)
500 Internal Server Error
GAAAAHHHHH!!!!
If you actually need a YouTube video to know what I'm talking about, you need to hand in your geek card. NOW.
Uhhh... no. This article links to a previous article, which links to the article you linked to. Each of these articles shows a progressive evolution of the concept. The article you linked to used reflective tape to accomplish the IR tracking. The article linked to by this article shows how to use a light pen for greater accuracy. THIS article combines the two approaches using IR equipped gloves to create a highly accurate touch surface.
I think everyone might be missing the point. How many people purchase low-end LAMP servers? Whether they be from hosting providers, or setup at home, LAMP is a well-known name in the industry.
Sun has OpenSolaris. Which so far has not quite caught on well enough to challenge LAMP dominance in the low-end of the market. Now imagine if Sun started shipping fully supported SAMP (Solaris Apache MySQL PHP) software distributions branded with "High Performance*, 64-bit Sun MySQL". If they can gain enough brand recognition this way, this free software could be their ticket into gaining more market share.
More market share on the low-end means more mind share with the same developers and IT folks who keep forgetting that Sun exists. If Sun can become de facto, they can probably own the low-end, mid-range, and high-end of the market rather than constantly retreating to the ever-shrinking Big Iron market. (Maybe people will even notice that Sun makes extremely affordable Intel machines?)
* Expect Sun to announce the "fastest database ever" by tuning MySQL for their Niagara processors, turning off all transactional safety, and then running benchmarks against the system. With any luck, these semi-valid benchmarks would earn Sun some goodwill for having "improved" MySQL. The double-edged sword here is that Sun would get a reputation for performance with those who don't understand that Niagara is a key component AND Sun would sell more Niagara servers to those who DO understand that Niagara is a key component.
I love the Power Glove. It's so baaad.
Meet Glassfish:
https://glassfish.dev.java.net/
Sun produces a commercial version under the confusing title of "Sun Java System Application Server". (Sun seriously needs to fire their marketing department.
Customers don't pay for MySQL professional because it's not that great of a database. As a "free" option, there's tons of support for it. It was seen early on as "the" database for OSS work. As a result, nearly every OSS tool in existence is built around MySQL.
However, if we're talking about someone looking to pay for support, we're probably talking about a business of some sort. And for businesses, features like ANSI syntax, transactions, reliability, scalability, tools, familiarity to the DBAs, and a strong reputation for customer service are all factors that play into their decision. Why would they purchase MySQL when options like SQL Server, Oracle, DB2, Informix, Pervasive, Teradata, and half a dozen other RDBMSes with stronger reputations in the market are available?
While MySQL has made great strides in their progress toward becoming a competitor in the Enterprise market, it's a bit of an uphill battle that they're going to have a hard time winning. The market sees MySQL as an OSS toy that children play with before they grow up and use a REAL database. Changing that perception is going to be hard.
Worse yet, it's a race against time before powerful new competitors like Apache Derby (formerly Cloudscape) start pushing MySQL out of the market.
That being said, I wish I invented an "OSS toy". A billion dollars as compensation sounds like a rather sweet deal.
Actually, James Gosling is on record having said that Oak began as an attempt to make a C++ compiler that didn't need to recompile the entire codebase when only one class changed. From there it evolved into a more complex platform that became Oak and later Java.
http://www.artima.com/intv/gosling1P.html
Several of the features (e.g. Canvas) are already supported by all major browsers save for IE.
One of the interesting aims of the HTML 5 standard was to spec the new functionality in such a way as to make it possible to emulate the new APIs in old browser. e.g. Canvas working in IE. (Make sure you click outside the block area to start. I haven't implemented the key passing yet.)
The Storage APIs would be similarly easy to emulate through Cookies, Flash, or Google Gears. (Take your pick.) Server Side Events are more difficult, but I think it might be possible to emulate with XMLHttpRequest. If I'm wrong, there's always a Flash or Java shunt possible. DOM 2 Events is still not supported by IE, but that's easy enough to patch for by wrapping IE's attachEvent scheme.
Basically, we can force Microsoft's hand on this. A simple runtime patch and BAM, we're coding to HTML 5 standards. If enough people do it, Microsoft will realize they've lost that front and move on.
Who suggested C? ;-)
I actually recommend classic assembly as early as possible. If you use a virtual machine that displays the state of the memory and CPU, it will give students a chance to get a grip on what the computer is really doing. THEN they can move on to C. (And/Or LISP, depending on what you want to teach them.)
Of course, we don't quite live in a world where Virtual Machines of antique computers are accepted by teachers as a valid teaching method. (Yet.) So barring assembly, I recommend BASIC first. (Oh, I can hear Dijkstra's cries already. Mwhahaha!) Classic BASIC provides a set of I/O routines that allow a student to become comfortable with working out the logical flow of a program without worrying about the details of printing to the screen or reading a line of input. Just don't dwell on BASIC for too long or you may make the student too comfortable for their own good.
What were they?
Java solved these problems by looking to the most advanced technology in the industry, and packaging it in a way that was so straightforward and simple that it was the DEFINITION of the KISS principle. What were these wonders?
The productivity gains from these changes were astounding! But it didn't completely replace low-level coding in C/C++. Why? Because sometimes you needed to get down to the metal to make things work well.
Today, the JVMs have been optimized like crazy. They can automatically make a program run faster as long as you know how to work with the GC and data structures that it provides. If you fight it, your performance drops like a rock. If you don't know how to use it, you might as well be fighting it.
Yet how is a student supposed to know what the JVM is doing if he's never had to scrounge for bytes? If he's never had a practical need for a linked list? If he's never had to implement memory management? If he doesn't have the first clue how to balance a tree? If he can't understand how a garbage collector works? If he doesn't know what a circular reference is? If he can't explain what a pointer is and how a reference is related but different to a pointer? If he doesn't even know what "Turing Complete*" means?
Java as a tool can be sharper than any other blade. But it is a double-edged blade. If you swing it wildly, it will cut you. If you wield it like a master, it will allow you to attack your problems with precision and vigor.
As a side note, I wonder if it isn't time to start teaching students using virtual machines that replicate the limited environments of yesteryear? Not only would it force them into solving the low-level problems, but it would also provide them with the ability to visually inspect the state of the virtual processor, memory, and I/O. Much better than a simple stack-trace, wouldn't you say?
*Imagine a computer scientist with no knowledge of what "Turing Complete" means being assigned to design the future of computers. Frightening concept? Very. Perhaps Quantum Computing would already be here if we had a greater number of qualified scientists?
An excellent point, which does indeed refute the authors' argument. To furhter back your comment, I've done advanced algorithms in Java before; sometimes as just a learning experience. There are no barriers to going low-level if you want to. However, I did mention that I felt that their argument only scratched the surface.
My own argument tends to go farther down the line to the point of obtaining an understanding of how to code in the first place. What I have found is that a new programmer rarely knows how to put one line of code in front of another. (Yes, the mere logic of ordering statements often escapes them.) Introducing a new programmer to an object oriented environment at an early stage forces them to think in terms of "magic".
"Yeah, don't worry about that 'public class HelloWorld' bit. We'll get to that later."
"Trust me. You need to have that import in your code. Otherwise it won't work."
"We'll get to that main() method later."
"Why System.out.println? Don't worry, you'll understand that once you understand objects and fields and methods. For now we're just compiling a simple [ed: *cough*] Hello World program."
If these barriers were truly debilitating to a student, then we wouldn't have a problem. They'd learn what they needed to know along the way. Unfortunately, these barriers are far more insidious than that. The student knows this magic works without understanding how it works. So he's able to coast through a variety of tasks without ever worrying about it. Then when he gets to the real world... oops. You mean that wasn't actually magic? I needed to know what that did? But all I ever learned was some control structures! My professor didn't even make me format my code properly!
*sigh*
That's the scene I see far too often. A good programmer can't do a good job unless he knows why he's doing it.
"But AKAImBatman," you say. "Won't most kids going into school these days have prior exposure to programming?"
You are correct! Which makes teaching them the basics that much more important. Once again, when they muddled through as teenagers, they focused on WHAT they could do and not WHY they could do it. Code snippets and tutorials and IDEs abounded! They didn't need to KNOW what they were doing. Just fiddle enough and it will work!
If you take things down to a low level, the majority of the students will be forced to learn or find an easier major. If they already know what you're teaching, then great! They can help with the rest of the class. But if they don't, then they're learning something priceless. Either way, the knowledge is KEY to data structures. One cannot truly understand the intent of most algorithms and data structures until he's visited the metal of the machine and tried to work with the likes of strings, memory allocation, and low-level hardware control. That's when he truly "gets it" and 40+ years of computer science suddenly SNAP into place.
"Ohhhh, I get it! I really do! Hey, I had problem X a month ago that I could have solved if I had just..."
Best. Sound. Evar.
(P.S. In case you're wondering? C++ should NEVER be taught in school. Worst drain bramage you can do to a poor kid. Especially as his first language!)
Fair enough. :-)
You'll have to forgive me, but I must raise an eyebrow at this. While the (generically speaking) Java Platform has many potential homes, it has found no better home for its technology than on big iron. Its straightforward design allows for the Virtual Machine to automatically adapt to memory, processors, and optimize away sections of code at runtime in ways that a static compiler will never be able to match. In addition, Java's natural fault tolerance allows for complex multiuser applications that provide logical firewalls between each user. Except in cases of poorly designed code (extremely poorly!), no single user can take down the entire application.
If anything, Java is the ideal solution for Big Iron usage. Which is why I must ask you to clarify. There are certainly super-computing applications where Java is a poor fit. This is due the non-standard low-level design of the hardware that requires a completely different toolkit to take advantage of. (Like it or not Cell is a prime example of this environment.) Other than that exception, though, I have a hard time imagining where Java would be ill suited for Big Iron work.
I vehemently disagree with this statement. I deal with the incredible task of training amateurs on a regular basis. (Some are even degreed-idiots.) VB is friendly to these amateurs. PHP is friendly to these amateurs.
As I said, Java is a wonderful tool in the hands of an experienced programmer who knows what it is capable of. In the hands of an amateur or (sometimes worse!) an old hand who's not used to the tools that Java offers, using Java in your project is like asking for your company to be nuked from orbit.
I'm not offended. I'm merely perplexed. You sound like the type of fellow who should have a solid understanding of the platform. So perhaps I am merely misunderstanding your statements?
It would be amazing if people actually read the article every once in a while. :-/
I make a living as a Java programmer. I enjoy the work I do and feel that no other language/platform can even touch Java's capabilities in team and enterprise development. Even for single-programmer development, there are a lot of situations where Java is the solution to end all solutions.
That being said, I agree with the article.
As the author tried to explain, programmers need a solid foundation in data structures and algorithms before they should even begin looking at Java. The specific problem he calls out (which I actually feel only scratches the surface) is that Java offers such a featureful API that the programmer isn't forced to learn the basics. He is able to simply use a Hashtable, a Sort, a LinkedList, or whatever he needs without understanding why it works. Which is a very dangerous thing for someone training to be a Computer Scientist.
A much better approach is to force the student to work through lower-level programming before ever reaching a modern layer that abstracts everything away. Otherwise the student is liable to shoot himself in the foot at a much later date. (Primarily due to a lack of knowledge.) This is very comparable to many sports where expensive, advanced equipment can be an asset to a well-trained athlete. But in the hands of an amateur, the attributes that make the equipment powerful becomes liabilities - and even barriers! - to the athlete's success.
I was asking what the point of his post was. Not what the point of removing these devices was. As I was trying to communicate in my post, the issue of optical drives is becoming null and void in many situations.
I really have no clue why everyone thought I was trying to be negative about the lack of an optical drive. I thought the emoticon would make it clear that I was pointing to the optical drive's decreasing lack of relevance. It's not obvious at first blush (as optical drives are so ingrained in our thinking), but they really not NOT get used that much any more. If you can't get the software you want over the Internet, then there's a good chance it's too painful to go to the store for anyway.
Indeed. Remind me, what was the point of that?