You definitely need to start somewhere. I think Java abstracts a lot of the more complicated aspects of programming such as memory management and allows students to start by understanding the logical nature of programming.
I do think though by isolating yourself to Java and not receiving exposure to other languages, you extremely limit your programming ability.
Java students might use three arrays to do something when a C/C++ student does the same with one array, and uses less memory. Why does this happen? Because in C YOU interact with memory. By interacting directly with the memory you begin to understand how allocation and freeing works. In learning the latter, it expands your mind and causes you to program with memory management in mind, albeit many times subconsciously.
In Java you just don't need to know about memory management, at least the nitty gritty(malloc()/free()). You can create as many objects as you want and can assume and hope that the garbage collector picks it up, eventually. In Java your concern is writing software that does what you want it to, not really having to worry about all the little things that add up to get it there. This is a good thing, for the most part. Focus on the goal of the software and not with the little BS details that you might encounter in C(who loves pointers?).
Unfortunately, in writing production software, it sometimes needs to do more than just work. I can name hundreds of Java applications I've used that work fine and get the job done, but usually the application is slow and the responsiveness is crap. That's the sacrifice of having a virtual machine and managed languages. Giving up memory management means giving up the performance gains that good memory management can obtain.
Personally, there is plenty of software that I use that is Java but I would definitely say that if it was written in a different language like C++ I would probably *enjoy* using the software more.
Example: My Tivo is awesome, but its all in Java and FUCK its slow. You think it should take 5 minutes to boot the Tivo, because it shouldn't. Is my Tivo just really underpowered? I don't think so. Tivo just decided that they would rather focus on designing a good DVR than to focus on the little things: memory management, designing their own OS, etc,. Java just got them from Point A to Point B faster.
I can't stand the current status of cable television in the US. It has been plagued with proprietary software and hardware for much too long. Because of that the quality of products and services has sucked it up. I have to say that my Scientific Atlanta set top box is probably the biggest piece of shit I've ever owned.
Also I think that cable providers hate the idea of losing control of an industry that they have always had power in by adopting an "open platform". Unfortunately they have a lot of leverage when it comes to the CableCard specs and thus will be putting their wonderful '2 cents' into the mix.
Recently I just bought a new Tivo HD w/ cablecard and had it installed by Cox(only took 30 minutes..blah). Now I find out that Cox is bringing 80 new HD channels in 2008...most of which will be SDV. Too bad I probably won't get ANY of those new channels because Tivo HD is NOT compatible with SDV but APPARENTLY there is going to be a dongle available. Now I have to wait for them to finish developing a dongle, for it to get in the hands of Cox, and then for them to take 6+ months to get it working on their system. Oh and then I'll get it installed to find out there is a new compatibility "issue".
On a random note, I was just reading about OCAP, and I found out that is Java-based. That won't be slow at all, will it? Can we PLEASE not make things that are performance sensitive and need to be responsive(GUIs?) in Java. This goes for Tivo too. I love my Tivo but I can't stand the lack of responsiveness in the GUI. We have so much processing power available for so low of a cost, let's use it efficiently and not waste it?
In regards to Java, we need to stop teaching our Computer Science students Java and instead a real language(c/c++). I'm sick of hearing of "programmers" who don't know what a pointer is. Are you kidding me? hahahahah
I think that the actual perceived performance difference will really be in how well the operating system handles multiple threads and cores. For example, when I open up Firefox and Photoshop at the same time, depending on how well my OS handles that, MIGHT be the difference in them both opening in 5 seconds or in 10 (I'm aware that there is much more to the time an application takes to launch besides raw speed). Of course, adding cores might only speed up the time it takes to open to a certain degree, after that it is dependent on things like I/O, hardware, latency, etc,.
Most desktop applications will only be able to benefit by a finite amount of parallelization. When you look at concurrency and your application design, the fundamental way that the application interacts with the user and data is going to define the limits of parallelization.
Now when you are using an application and it stops responding when you perform a certain task, that is probably an opportunity for the developer to factor that operation into a new thread (GUI's should never block). But after they've done that and the application's responsiveness is fine, what more can they do? Make another thread that says please wait while we (block) on this thread? You are always going to have things like I/O which is really what the bottleneck usually is.
Slashdot Mirror
You definitely need to start somewhere. I think Java abstracts a lot of the more complicated aspects of programming such as memory management and allows students to start by understanding the logical nature of programming.
I do think though by isolating yourself to Java and not receiving exposure to other languages, you extremely limit your programming ability.
Java students might use three arrays to do something when a C/C++ student does the same with one array, and uses less memory. Why does this happen? Because in C YOU interact with memory. By interacting directly with the memory you begin to understand how allocation and freeing works. In learning the latter, it expands your mind and causes you to program with memory management in mind, albeit many times subconsciously.
In Java you just don't need to know about memory management, at least the nitty gritty(malloc()/free()). You can create as many objects as you want and can assume and hope that the garbage collector picks it up, eventually. In Java your concern is writing software that does what you want it to, not really having to worry about all the little things that add up to get it there. This is a good thing, for the most part. Focus on the goal of the software and not with the little BS details that you might encounter in C(who loves pointers?).
Unfortunately, in writing production software, it sometimes needs to do more than just work. I can name hundreds of Java applications I've used that work fine and get the job done, but usually the application is slow and the responsiveness is crap. That's the sacrifice of having a virtual machine and managed languages. Giving up memory management means giving up the performance gains that good memory management can obtain.
Personally, there is plenty of software that I use that is Java but I would definitely say that if it was written in a different language like C++ I would probably *enjoy* using the software more.
Example: My Tivo is awesome, but its all in Java and FUCK its slow. You think it should take 5 minutes to boot the Tivo, because it shouldn't. Is my Tivo just really underpowered? I don't think so. Tivo just decided that they would rather focus on designing a good DVR than to focus on the little things: memory management, designing their own OS, etc,. Java just got them from Point A to Point B faster.
I can't stand the current status of cable television in the US. It has been plagued with proprietary software and hardware for much too long. Because of that the quality of products and services has sucked it up. I have to say that my Scientific Atlanta set top box is probably the biggest piece of shit I've ever owned.
Also I think that cable providers hate the idea of losing control of an industry that they have always had power in by adopting an "open platform". Unfortunately they have a lot of leverage when it comes to the CableCard specs and thus will be putting their wonderful '2 cents' into the mix.
Recently I just bought a new Tivo HD w/ cablecard and had it installed by Cox(only took 30 minutes..blah). Now I find out that Cox is bringing 80 new HD channels in 2008...most of which will be SDV. Too bad I probably won't get ANY of those new channels because Tivo HD is NOT compatible with SDV but APPARENTLY there is going to be a dongle available. Now I have to wait for them to finish developing a dongle, for it to get in the hands of Cox, and then for them to take 6+ months to get it working on their system. Oh and then I'll get it installed to find out there is a new compatibility "issue".
On a random note, I was just reading about OCAP, and I found out that is Java-based. That won't be slow at all, will it? Can we PLEASE not make things that are performance sensitive and need to be responsive(GUIs?) in Java. This goes for Tivo too. I love my Tivo but I can't stand the lack of responsiveness in the GUI. We have so much processing power available for so low of a cost, let's use it efficiently and not waste it?
In regards to Java, we need to stop teaching our Computer Science students Java and instead a real language(c/c++). I'm sick of hearing of "programmers" who don't know what a pointer is. Are you kidding me? hahahahah
I think that the actual perceived performance difference will really be in how well the operating system handles multiple threads and cores. For example, when I open up Firefox and Photoshop at the same time, depending on how well my OS handles that, MIGHT be the difference in them both opening in 5 seconds or in 10 (I'm aware that there is much more to the time an application takes to launch besides raw speed). Of course, adding cores might only speed up the time it takes to open to a certain degree, after that it is dependent on things like I/O, hardware, latency, etc,.
Most desktop applications will only be able to benefit by a finite amount of parallelization. When you look at concurrency and your application design, the fundamental way that the application interacts with the user and data is going to define the limits of parallelization.
Now when you are using an application and it stops responding when you perform a certain task, that is probably an opportunity for the developer to factor that operation into a new thread (GUI's should never block). But after they've done that and the application's responsiveness is fine, what more can they do? Make another thread that says please wait while we (block) on this thread? You are always going to have things like I/O which is really what the bottleneck usually is.