Last time I checked an OS is considered system software.
Portability for NT was not just for the basic 'system'; it included lots of additional applications and tools.
then build your product on the absolute fewest number of platforms possible.
the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.
This is just plain ignorant nonsense. Good cross-platform development tools have been available for decades. Cross-platform support is not 'beyond the reach' of any developer and never has been, if you pick the right libraries and tools. (I talk from experience - I was developing cross-platform GUI applications that ran on Unixes and DOS 20 years ago). Writing code that is limited to a restricted number of platforms is simply bad coding, and there is no excuse for it.
Remember that my original point, apropos this whole Slashdot article, is that Microsoft does make highly-regarded products, and Visual Studio is definitely one of them.
I strongly disagree. Visual Studio is highly tailored to a specific approach to application development that suits Microsoft, in which developers use the Windows API and pre-compiled components. Bill Gates knows how things could have been so much better - in the mid 1980s he saw real object-oriented designs and interactive development systems when he was introduced to Smalltalk. He saw how developers could be free to write extensions to the IDE, how running applications could be interrupted, inspected, and new methods added. He even said 'this is the future'. A few years later, he figured out how such a system could be sufficiently crippled as to make the most money for Microsoft and released... Visual Basic.
Visual Studio is a crippled version of what it should have been.
Imagine someone is applying to you for a job, which requires honesty and a good reputation.
During the interview you find out some facts from their past. Ten years ago, they were a thief, and were procecuted.
4c. The act WAS UNIQUE. Microsoft did not sabotage any other version of DOS to be incompatible with Windows. Just one - DR-DOS.
"But, honestly, I was only a thief once. That hardly counts at all, does it?"
5. Of course my point was good. Microsoft today - both managerially and technologically - is completely different from the company it was in the early 1990s.
"Yes, Ok, the mates who helped me with the robbery still work with me, but we are all reformed!"
It shows that you equate an action that was eventually determined to be worth $23M to be the only deciding factor in the quality of a company that employes 50,000 and has an annual revenue in the high tens-of-billions.
"Look, I got a $10,000 dollar fine when I was convicted, but you can trust me now, as I'm really rich and I could easily pay fines like that now."
It could still easily be ported to alternate hardware as soon as there are custmores for NT on that other hardware.
There were customers for NT on non-intel hardware - there were a lot of complaints as Microsoft dropped support for different CPUs. The point is that Microsoft was solving a Microsoft problem, not a customer problem. This would have been fair enough if they were honest about it, but to have a developer now claim that 'lack of portability' is a good thing is hypocracy and re-writing history.
(got I hate browser sniffing for dhtml)
That is because Microsoft have managed to introduce portability problems where they did not previously exist - by ignoring browser standards.
you should keep the product simple and not support that other platform
Its the reverse - simple products are easy to write and maintain as cross-platform.
Visual C++, which is not a poorly-regarded Microsoft product
Says who? When I lasted used it, it was a typical Microsoft compiler product - a huge system, with very big manuals, and a phenomenal number of options, memory models, segment types, and strange keywords starting with double underlines. It was a monster. I dumped it.
To actually get things done, I used Turbo Pascal for Windows, and then Delphi.
Including windows-specific extensions to Java, and not implementing standard parts, in an attempt to break its portability.
Breaking standards on web browsers, with bugs that are easy to fix (Mozilla does things better - IE easily could too).
Trying to make open systems proprietary, such as including undocumented extensions to the Kerberos security system in Windows 2000, after having promised to release these extensions to universities.
Forced bundling: telling suppliers that they won't be allowed to ship windows if they also included competitors products.
These things are not irrelevant - they are absolutely key to the understanding of a company and its practices. I am regularly left in a state of stunned disbelief as to why anyone trusts Microsoft.
Essentially great software is the one that solves customer's problem. Microsoft is good at it as each product that goes out the door can generally be qualified to solve at least one problem.
Microsoft is good at providing solutions to problems that the customer does not have, and providing features that the customer rarely if ever needs. Microsoft is really great at marketing, which often consists of convincing managers that they have (imaginary) problems which can only be solved by MS software.
And, what about problems that Microsoft deliberately creates, which can only be solved by their software? Remember how they sabotaged Windows so that it would not run with a competitor's version of DOS? Exactly what customer problem did that solve?
22. Change direction then convince everyone that was the direction you were intending to go in at the start.
Like with portability.... NT was supposed to be the portable OS, on MIPS, PowerPC, Alpha. But as that didn't take off, now 'portability is for Canoes'.
No company can match Microsoft for blatant and unabashed hypocracy. This article is a good example.
There are times when to use a strongly-typed, "true" OO language like Java or C++ and times to use a scripting language like PHP or Perl.
There is no reason why you should not use scripting *and* Java at the same time. If you use Jython, Groovy or BeanShell you have all the flexibility of scripting combined with access to the full APIs, security and scalability of Java. If you use BeanShell, you can easily convert your scripts into compiled Java source code if that becomes necessary.
Part of being a good programmer is being smart enough to use the right tool for the right job.
Part of being an experienced programmer is realising that switching tools all the time is a bad idea. It prevents code re-use and results in duplication of effort as the same thing is re-written in different languages by different people in different projects.
If you want to torment yourself by over-engineering a small- or mid-sized website in EJB, go for it,
No sensible developer would go anywhere near EJBs for a small or medium website. The EJB part of J2EE is for scalable and clustered high-end applications. Other parts of J2EE, such as JSPs and Servlets are lightweight and easy to use.
I can't think of a single reason to prefer PostgreSQL over it, in fact.
There are no subselects in production release of Mysql. (version 4.1, which has this in, has been a very long time coming out). Lots of aspects of SQL are present only in different table types in Mysql; its not consistent. PostgreSQL is far easier to manage: You get ACID, PL/SQL, full SQL and speed on all tables.
Being able to manage critical business web application server systems from a command line is invaluable. Tomcat has a simple directory structure, and simple configuration files, yet works superbly as a server for the JSP and Servlet aspects of J2EE. Its easy to start, stop, deploy code to, and configure, from the command line.
I don't know why, but you seem to be refusing to read the posts you reply to.
Here is a final attempt.
JVMs are highly compatible. No-one specifies which manufacturer's VM to run on. If they do, its just to show which ones they have tested. Often packages will install VMs simply to ensure that Java is present on the machine (as with Oracle). Even Oracle say that the parts of their product with use Java will run on any manufacturer's VM above a certain level (1.3 I believe). Something as complex as IBM's eclipse will run fine on any manufacturer's VM; Sun, IBM, HP etc. This is fact. If you don't believe me, try it yourself.
C/C++ library compatibilities always have been a problem. apt-get simply allows you to automatically fix compatibility issues, but other packaging systems such as rpms don't do this automatically, and it can be a mess, and installing newer versions of libraries can break other software. This is not a matter of debate - its well documented fact. Type 'libstdc incompatibilities' into Google.
Speed and language implementation issues with C++ aren't trivial or simple. Virtual method lookup is a simple idea in principle, but making it efficient is very important when you might be making millions of such calls each second. Other matters are the overheads of constructor and destructor calling, particularly with deep inheritance. Fast code requires a lot of skill from the coder and quality compilers.
As for management issues and C++ coding, you can't have it both ways. Either C++ is so good that its features prevent problems such as buffer overruns, or it is necessary for management to impose good practice because it is easy for developers.
As for memory and resource management, Java has full control of any resources it needs. You can either let garbage collection deal with files, network sockets, threads, GUI objects etc., or you can manually close those resources. You don't have to do this by hand in Java, but you can if you want to. Garbage collection is not, and never has been, just to do with memory.
I don't know of any machine but a Sun that comes with a JVM.
Until very recently, every Windows machine was shipped with a JVM. Read what I had posted - I did not say machines where necessarily shipped with VMs - I said they were often pre-installed in organisations so that users could run Java software.
Meanwhile, most machines have libstdc++.so and a variety of other libraries -- along with a plethora of C++ programs.
Yes, but *which* libstdc++.so? If you are installing software, this matters.
So, I have the latest one from Sun, and the latest one from IBM, and which ever one Oracle wants its installer to run on
These are all compatible. For virtually all software, there is no difference. That is the whole point of Java.
and some older versions for the programs that break when you try to run with the new one.
Yes, people can write very bad code in Java too, but this kind of this is extremely rare.
the spurious early 90s claims that C++ code is slower than C code.
Its not spurious - the speed difference, particularly in matters of inheritance and method lookup, was the subject of a lot of academic study.
These "virtual methods with dynamic lookups" are nothing but calls through function pointers.
No, they are look-up tables, and the lookup has to be done at run time.
Memory leaks are a management failure.
In the previous post, it was stated that they had to be actively produced by the coder due to the new features of C++.
the reason Java offers no alternative...
Just not true. I can ensure that memory is tidied up any time I like, by manually removing references to objects. Look:
First they had to get a JVM installed. Then they had to try installing another to see if the program would work on that one, instead.
Most people who use java either use the pre-installed VMs for applets, or have the VMs installed for them in their work environment. I suppose to run C++ programs you need nothing whatever installed? No libaries? Just the linux kernel on a bare machine?
As for your comment about versions, that is just silly. You get the latest stable VM from Sun or IBM or whatever, and it runs the java binary. Apart from highly specialised system software, this simply just works. Your comment about 'half a dozen other VMs' is daft exaggeration - that has never been the case, and you know it. Java is one of the most backward-compatible systems ever developed.
One line: "apt-get install ". Why would I want a binary for some machine other than what I have?
I suggest you read the post you are replying to before you comment - I said 'rpm'. The debian apt-get program is a honourable exception. Even then, you might find yourself having to install a dozen new packages *on each machine you have* just to run a small new binary. Also, if you are actually employed by someone, you may have to deal with more than one machine, and perhaps more than one operating system.
Mozilla, of course, really is largely interpreted: the language is XUL. However, it doesn't seem slow any more.
No. Mozilla is not interpreted. XUL is a language for describing user interfaces. Virtually all of Mozilla is C++. Mozilla does not seem slow because teams of skilled developers have worked on it, and because processor speeds have improved about 5x since it was first launched.
The compilers generate the same code for the same constructs, C or C++
True, but as you say below, C++ users don't use the same constructs! They use virtual methods with dynamic lookups, operator overloading, class libraries and run-time type information. These are not C constructs.
C++ coders have access to a very rich standard library (not to mention other libraries) in which it would actually be extra work to write code with buffer overruns.
So these would not be C constructs? What about your previous comment?
If C++ is so good, then why is is that so much C++ code does suffer buffer overruns? Why are there memory leaks?
You are seriously overestimating the way most C++ is written. Most C++ was, for a long time, written very much like C, and used C libraries.
I suppose that when you're stuck in a niche, it looks like the whole world. "They ain't ignorant, they just don't know no different."
I guess that is true, if you have absolutely no idea what the term 'niche' means. If you define 'niche' to include real-time networking, numerical code, general purpose office software, web services, financial applications, embedded software, clustered applications, games, communications, virus detection software, chatroom and instant messaging, image processing, GIS, multimedia, language research, compiler and interpreter writing, on-line banking, e-mail clients and servers as 'niche', then yes, Java is niche.
Then there are those who believe in using the right tool for the right job.
The idea that developers should switch easily between development languages is one of the great myths of IT. Languages aren't tools: they are entire workshops. Switching may be possible if you work on many very small and entirely independent projects, but for most developers its just not practical or sensible.
For each language that is used in an organisation there has to be an investment in training and the building up of repositories of re-usable code. The last thing you want is to have two developers who both picked what they thought was the best tool for their part of a job trying to combine bits of PERL and Java, or be unable to use large Java class libraries developed over years because someone decided that it would be neat to code a new project in Lisp.
The only sensible approach is to spend a lot of time researching the benefits of different languages and development tools and then standardise on these.
In my experience people find that the GUIs on Java programs run slow. Which they do.
That should read some of the GUIs. There are some very fast Java GUIs. SWT, for example, is a thin layer above native GUIs, and is virtually indistinguishable in terms terms of speed. Years ago Netscape produced a very light portable GUI for java called IFC. That was not native GUI but was fast. The only really slow GUI for java is Swing, and even that is not that bad under later versions of 1.4 and on 1.5.
All those benchmarks have shown me is that unless I am writing a huge computationally intensive application then performance should not be one of the criteria on which I decide whether to use C++ or Java.
There is a very good reason to use Java for computational work: it allows you to make use of mixed hardware clusters and grids. It allows computationally intensive code to be highly portable.
they find that real Java programs really do run slowly.
Not true. Most people who run Java programs have no idea that they are running Java programs.
Nobody complains that C++ programs are slow, because they aren't. Nobody is obliged to notice they are C++ programs, because they are easy to install, and they just work. They don't call much attention to themselves, because they rarely suffer from the security flaws common to C programs.
This is so wrong, its hard to know where to start.
First, installation. Java apps can be packaged as a single JAR or WAR file that can be run just by clicking on it, or putting into the right directory of an app server. Alternatively, you can set up networked installs via WebStart. The thing is you can prepare a single binary for all platforms.
With C++ you need to get the right compiled binary for the processor, and the right versions of system libraries: just look at the trials of installing something via rpms.
As for speed - you must have a short memory. In the 80s and early 90s there were serious worries about C++ performance, with many complaints that it was far too slow when compared with C or assembler. Remember the complaints about the speed of early versions of Mozilla? It was so bad that many of us assumed it was some interpreted system. No - it was C++!
As for 'just working' and 'security flaws' this is directly contrary to evidence. Unless you code using bounds-checked collection libraries (which can be intrinsically slow) there is absolutely no difference between C++ and C in terms of memory access, and an equal possibility of buffer overruns.
As for garbage collection: The comment about niche uses is just nonsense. Not by any rational definition could languages such as Java and C# be defined as 'niche'.
- The city engineers need some new CAD package to manage the sewer sytem. Oh, and all those existing files may need to be converted.
This is something that would really concern me. I often look at converting some CAD users to Linux, but there really aren't the quality CAD tools to do it.
- All of their current development tools
I think you are wrong here. By far the most widely used development language in Germany is Java with Eclipse. That will require almost no conversion effort. However, Office Macro development is going to be a serious problem.
Re:Caught up with the speed, but still the ugliest
on
Java Faster Than C++?
·
· Score: 1
Er no. There's still a fair amount of wrapping that needs to be done.
No. Part of the design of SWT was to ensure that there was absolutely minimal wrapping. API calls in the native GUI (e.g. SendMessage in Win32) are mapped directly to identically named API methods in the Java implementation of SWT for that platform. Then, an thin object layer of the GUI above that provides a common model of the GUI for all platforms.
On windows, something like the '.setText()' method in SWT is a call to a Java SendMessage which calls the Windows SendMessage function via JNI.
So, you think that when you malloc() and get a pointer, that pointer is to a real physical memory address? Well, if you are programming an 8086 or writing hardware drivers, yes, but otherwise, no. Your program is running in a virtualized address space, which the kernel maps to physical pages.
Re:Caught up with the speed, but still the ugliest
on
Java Faster Than C++?
·
· Score: 1
SWT are still FAR slower than QT or the Win32 API
Er no. SWT is the native GUI. Its a library that allows Java to use native GUIs via JNI.
Saying SWT is FAR slower than something like the Win32 API is like saying that Win32 API is FAR slower than the Win32 API!!
It just can't be... Okay, so how could I make a blanket statement like that?
By not understanding how Java and JVMs work.
The java compiler actually compiles to a virtual opcode format, which is then interpreted by the java virtual machine at runtime.
No it's not. Except in very limited cases (such as embedded java, in restricted memory) this has not been true for a very long time.
For a typical modern JVM, it goes like this: Java starts to interpret the bytecode. If a JIT system is used the bytecode is then translated into native machine code, which is cached in memory. If a Hotspot system is used, a separate thread profiles the program and when slow code is found, the JVM translates the bytecode into highly optimised native machine code.
The machine code translators can be very thorough in their analysis, and can work out where it is safe to remove array bound checks etc.
The reasons why Java can be faster that C or C++ are (1) the VM can determine precise details of the processor its running on, so that bytecode can be translated into machine code optimised for that processor, and (2) the VM can profile the application and dynamically optimise and re-optimise. With statically compiled programs the attempt at optimisation is done once only.
2) Java has garbage collection, C++ doesn't. This is specified in the language. This affects performance.
In practice, C++ does have garbage collection of a kind. On a modern operating system, when you malloc() you arent getting 'real memory'; its all virtualized. That memory is managed and swapped. In effect, the operating system is 'garbage collecting' your memory to optimize access.
Slashdot Mirror
I should know, I used both environments back in the DOS/Win3.x days.
Me too. The thing about the Microsoft systems is that they didn't attempt to hide the complexity; they seemed to revel it in.
Last time I checked an OS is considered system software.
Portability for NT was not just for the basic 'system'; it included lots of additional applications and tools.
then build your product on the absolute fewest number of platforms possible.
the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.
This is just plain ignorant nonsense. Good cross-platform development tools have been available for decades. Cross-platform support is not 'beyond the reach' of any developer and never has been, if you pick the right libraries and tools. (I talk from experience - I was developing cross-platform GUI applications that ran on Unixes and DOS 20 years ago). Writing code that is limited to a restricted number of platforms is simply bad coding, and there is no excuse for it.
Remember that my original point, apropos this whole Slashdot article, is that Microsoft does make highly-regarded products, and Visual Studio is definitely one of them.
I strongly disagree. Visual Studio is highly tailored to a specific approach to application development that suits Microsoft, in which developers use the Windows API and pre-compiled components. Bill Gates knows how things could have been so much better - in the mid 1980s he saw real object-oriented designs and interactive development systems when he was introduced to Smalltalk. He saw how developers could be free to write extensions to the IDE, how running applications could be interrupted, inspected, and new methods added. He even said 'this is the future'. A few years later, he figured out how such a system could be sufficiently crippled as to make the most money for Microsoft and released... Visual Basic.
Visual Studio is a crippled version of what it should have been.
Imagine someone is applying to you for a job, which requires honesty and a good reputation.
During the interview you find out some facts from their past. Ten years ago, they were a thief, and were procecuted.
4c. The act WAS UNIQUE. Microsoft did not sabotage any other version of DOS to be incompatible with Windows. Just one - DR-DOS.
"But, honestly, I was only a thief once. That hardly counts at all, does it?"
5. Of course my point was good. Microsoft today - both managerially and technologically - is completely different from the company it was in the early 1990s.
"Yes, Ok, the mates who helped me with the robbery still work with me, but we are all reformed!"
It shows that you equate an action that was eventually determined to be worth $23M to be the only deciding factor in the quality of a company that employes 50,000 and has an annual revenue in the high tens-of-billions.
"Look, I got a $10,000 dollar fine when I was convicted, but you can trust me now, as I'm really rich and I could easily pay fines like that now."
It could still easily be ported to alternate hardware as soon as there are custmores for NT on that other hardware.
There were customers for NT on non-intel hardware - there were a lot of complaints as Microsoft dropped support for different CPUs. The point is that Microsoft was solving a Microsoft problem, not a customer problem. This would have been fair enough if they were honest about it, but to have a developer now claim that 'lack of portability' is a good thing is hypocracy and re-writing history.
(got I hate browser sniffing for dhtml)
That is because Microsoft have managed to introduce portability problems where they did not previously exist - by ignoring browser standards.
you should keep the product simple and not support that other platform
Its the reverse - simple products are easy to write and maintain as cross-platform.
Visual C++, which is not a poorly-regarded Microsoft product
Says who? When I lasted used it, it was a typical Microsoft compiler product - a huge system, with very big manuals, and a phenomenal number of options, memory models, segment types, and strange keywords starting with double underlines. It was a monster. I dumped it.
To actually get things done, I used Turbo Pascal for Windows, and then Delphi.
3. The act was unique.
Unique?
What about:
Including windows-specific extensions to Java, and not implementing standard parts, in an attempt to break its portability.
Breaking standards on web browsers, with bugs that are easy to fix (Mozilla does things better - IE easily could too).
Trying to make open systems proprietary, such as including undocumented extensions to the Kerberos security system in Windows 2000, after having promised to release these extensions to universities.
Forced bundling: telling suppliers that they won't be allowed to ship windows if they also included competitors products.
These things are not irrelevant - they are absolutely key to the understanding of a company and its practices. I am regularly left in a state of stunned disbelief as to why anyone trusts Microsoft.
Essentially great software is the one that solves customer's problem. Microsoft is good at it as each product that goes out the door can generally be qualified to solve at least one problem.
Microsoft is good at providing solutions to problems that the customer does not have, and providing features that the customer rarely if ever needs. Microsoft is really great at marketing, which often consists of convincing managers that they have (imaginary) problems which can only be solved by MS software.
And, what about problems that Microsoft deliberately creates, which can only be solved by their software? Remember how they sabotaged Windows so that it would not run with a competitor's version of DOS? Exactly what customer problem did that solve?
22. Change direction then convince everyone that was the direction you were intending to go in at the start.
Like with portability.... NT was supposed to be the portable OS, on MIPS, PowerPC, Alpha. But as that didn't take off, now 'portability is for Canoes'.
No company can match Microsoft for blatant and unabashed hypocracy. This article is a good example.
There are times when to use a strongly-typed, "true" OO language like Java or C++ and times to use a scripting language like PHP or Perl.
There is no reason why you should not use scripting *and* Java at the same time. If you use Jython, Groovy or BeanShell you have all the flexibility of scripting combined with access to the full APIs, security and scalability of Java. If you use BeanShell, you can easily convert your scripts into compiled Java source code if that becomes necessary.
Part of being a good programmer is being smart enough to use the right tool for the right job.
Part of being an experienced programmer is realising that switching tools all the time is a bad idea. It prevents code re-use and results in duplication of effort as the same thing is re-written in different languages by different people in different projects.
If you want to torment yourself by over-engineering a small- or mid-sized website in EJB, go for it,
No sensible developer would go anywhere near EJBs for a small or medium website. The EJB part of J2EE is for scalable and clustered high-end applications. Other parts of J2EE, such as JSPs and Servlets are lightweight and easy to use.
I can't think of a single reason to prefer PostgreSQL over it, in fact.
There are no subselects in production release of Mysql. (version 4.1, which has this in, has been a very long time coming out). Lots of aspects of SQL are present only in different table types in Mysql; its not consistent. PostgreSQL is far easier to manage: You get ACID, PL/SQL, full SQL and speed on all tables.
apache's tomcat is my answer.
Being able to manage critical business web application server systems from a command line is invaluable. Tomcat has a simple directory structure, and simple configuration files, yet works superbly as a server for the JSP and Servlet aspects of J2EE. Its easy to start, stop, deploy code to, and configure, from the command line.
Diminishing resources won't be a problem. With nanotechnology we can make cars that are very, very small.
I don't know why, but you seem to be refusing to read the posts you reply to.
Here is a final attempt.
JVMs are highly compatible. No-one specifies which manufacturer's VM to run on. If they do, its just to show which ones they have tested. Often packages will install VMs simply to ensure that Java is present on the machine (as with Oracle). Even Oracle say that the parts of their product with use Java will run on any manufacturer's VM above a certain level (1.3 I believe). Something as complex as IBM's eclipse will run fine on any manufacturer's VM; Sun, IBM, HP etc. This is fact. If you don't believe me, try it yourself.
C/C++ library compatibilities always have been a problem. apt-get simply allows you to automatically fix compatibility issues, but other packaging systems such as rpms don't do this automatically, and it can be a mess, and installing newer versions of libraries can break other software. This is not a matter of debate - its well documented fact. Type 'libstdc incompatibilities' into Google.
Speed and language implementation issues with C++ aren't trivial or simple. Virtual method lookup is a simple idea in principle, but making it efficient is very important when you might be making millions of such calls each second. Other matters are the overheads of constructor and destructor calling, particularly with deep inheritance. Fast code requires a lot of skill from the coder and quality compilers.
As for management issues and C++ coding, you can't have it both ways. Either C++ is so good that its features prevent problems such as buffer overruns, or it is necessary for management to impose good practice because it is easy for developers.
As for memory and resource management, Java has full control of any resources it needs. You can either let garbage collection deal with files, network sockets, threads, GUI objects etc., or you can manually close those resources. You don't have to do this by hand in Java, but you can if you want to. Garbage collection is not, and never has been, just to do with memory.
I don't know of any machine but a Sun that comes with a JVM.
Until very recently, every Windows machine was shipped with a JVM. Read what I had posted - I did not say machines where necessarily shipped with VMs - I said they were often pre-installed in organisations so that users could run Java software.
Meanwhile, most machines have libstdc++.so and a variety of other libraries -- along with a plethora of C++ programs.
Yes, but *which* libstdc++.so? If you are installing software, this matters.
So, I have the latest one from Sun, and the latest one from IBM, and which ever one Oracle wants its installer to run on
These are all compatible. For virtually all software, there is no difference. That is the whole point of Java.
and some older versions for the programs that break when you try to run with the new one.
Yes, people can write very bad code in Java too, but this kind of this is extremely rare.
the spurious early 90s claims that C++ code is slower than C code.
Its not spurious - the speed difference, particularly in matters of inheritance and method lookup, was the subject of a lot of academic study.
These "virtual methods with dynamic lookups" are nothing but calls through function pointers.
No, they are look-up tables, and the lookup has to be done at run time.
Memory leaks are a management failure.
In the previous post, it was stated that they had to be actively produced by the coder due to the new features of C++.
the reason Java offers no alternative...
Just not true. I can ensure that memory is tidied up any time I like, by manually removing references to objects. Look:
myObject = null;
That will do it!
First they had to get a JVM installed. Then they had to try installing another to see if the program would work on that one, instead.
Most people who use java either use the pre-installed VMs for applets, or have the VMs installed for them in their work environment. I suppose to run C++ programs you need nothing whatever installed? No libaries? Just the linux kernel on a bare machine?
As for your comment about versions, that is just silly. You get the latest stable VM from Sun or IBM or whatever, and it runs the java binary. Apart from highly specialised system software, this simply just works. Your comment about 'half a dozen other VMs' is daft exaggeration - that has never been the case, and you know it. Java is one of the most backward-compatible systems ever developed.
One line: "apt-get install ". Why would I want a binary for some machine other than what I have?
I suggest you read the post you are replying to before you comment - I said 'rpm'. The debian apt-get program is a honourable exception. Even then, you might find yourself having to install a dozen new packages *on each machine you have* just to run a small new binary. Also, if you are actually employed by someone, you may have to deal with more than one machine, and perhaps more than one operating system.
Mozilla, of course, really is largely interpreted: the language is XUL. However, it doesn't seem slow any more.
No. Mozilla is not interpreted. XUL is a language for describing user interfaces. Virtually all of Mozilla is C++. Mozilla does not seem slow because teams of skilled developers have worked on it, and because processor speeds have improved about 5x since it was first launched.
The compilers generate the same code for the same constructs, C or C++
True, but as you say below, C++ users don't use the same constructs! They use virtual methods with dynamic lookups, operator overloading, class libraries and run-time type information. These are not C constructs.
C++ coders have access to a very rich standard library (not to mention other libraries) in which it would actually be extra work to write code with buffer overruns.
So these would not be C constructs? What about your previous comment?
If C++ is so good, then why is is that so much C++ code does suffer buffer overruns? Why are there memory leaks?
You are seriously overestimating the way most C++ is written. Most C++ was, for a long time, written very much like C, and used C libraries.
I suppose that when you're stuck in a niche, it looks like the whole world. "They ain't ignorant, they just don't know no different."
I guess that is true, if you have absolutely no idea what the term 'niche' means. If you define 'niche' to include real-time networking, numerical code, general purpose office software, web services, financial applications, embedded software, clustered applications, games, communications, virus detection software, chatroom and instant messaging, image processing, GIS, multimedia, language research, compiler and interpreter writing, on-line banking, e-mail clients and servers as 'niche', then yes, Java is niche.
Then there are those who believe in using the right tool for the right job.
The idea that developers should switch easily between development languages is one of the great myths of IT. Languages aren't tools: they are entire workshops. Switching may be possible if you work on many very small and entirely independent projects, but for most developers its just not practical or sensible.
For each language that is used in an organisation there has to be an investment in training and the building up of repositories of re-usable code. The last thing you want is to have two developers who both picked what they thought was the best tool for their part of a job trying to combine bits of PERL and Java, or be unable to use large Java class libraries developed over years because someone decided that it would be neat to code a new project in Lisp.
The only sensible approach is to spend a lot of time researching the benefits of different languages and development tools and then standardise on these.
In my experience people find that the GUIs on Java programs run slow. Which they do.
That should read some of the GUIs. There are some very fast Java GUIs. SWT, for example, is a thin layer above native GUIs, and is virtually indistinguishable in terms terms of speed. Years ago Netscape produced a very light portable GUI for java called IFC. That was not native GUI but was fast. The only really slow GUI for java is Swing, and even that is not that bad under later versions of 1.4 and on 1.5.
All those benchmarks have shown me is that unless I am writing a huge computationally intensive application then performance should not be one of the criteria on which I decide whether to use C++ or Java.
There is a very good reason to use Java for computational work: it allows you to make use of mixed hardware clusters and grids. It allows computationally intensive code to be highly portable.
they find that real Java programs really do run slowly.
Not true. Most people who run Java programs have no idea that they are running Java programs.
Nobody complains that C++ programs are slow, because they aren't. Nobody is obliged to notice they are C++ programs, because they are easy to install, and they just work. They don't call much attention to themselves, because they rarely suffer from the security flaws common to C programs.
This is so wrong, its hard to know where to start.
First, installation. Java apps can be packaged as a single JAR or WAR file that can be run just by clicking on it, or putting into the right directory of an app server. Alternatively, you can set up networked installs via WebStart. The thing is you can prepare a single binary for all platforms.
With C++ you need to get the right compiled binary for the processor, and the right versions of system libraries: just look at the trials of installing something via rpms.
As for speed - you must have a short memory. In the 80s and early 90s there were serious worries about C++ performance, with many complaints that it was far too slow when compared with C or assembler. Remember the complaints about the speed of early versions of Mozilla? It was so bad that many of us assumed it was some interpreted system. No - it was C++!
As for 'just working' and 'security flaws' this is directly contrary to evidence. Unless you code using bounds-checked collection libraries (which can be intrinsically slow) there is absolutely no difference between C++ and C in terms of memory access, and an equal possibility of buffer overruns.
As for garbage collection: The comment about niche uses is just nonsense. Not by any rational definition could languages such as Java and C# be defined as 'niche'.
A couple of points.
- The city engineers need some new CAD package to manage the sewer sytem. Oh, and all those existing files may need to be converted.
This is something that would really concern me. I often look at converting some CAD users to Linux, but there really aren't the quality CAD tools to do it.
- All of their current development tools
I think you are wrong here. By far the most widely used development language in Germany is Java with Eclipse. That will require almost no conversion effort. However, Office Macro development is going to be a serious problem.
Er no. There's still a fair amount of wrapping that needs to be done.
No. Part of the design of SWT was to ensure that there was absolutely minimal wrapping. API calls in the native GUI (e.g. SendMessage in Win32) are mapped directly to identically named API methods in the Java implementation of SWT for that platform. Then, an thin object layer of the GUI above that provides a common model of the GUI for all platforms.
On windows, something like the '.setText()' method in SWT is a call to a Java SendMessage which calls the Windows SendMessage function via JNI.
This is near-complete nonsense.
So, you think that when you malloc() and get a pointer, that pointer is to a real physical memory address? Well, if you are programming an 8086 or writing hardware drivers, yes, but otherwise, no. Your program is running in a virtualized address space, which the kernel maps to physical pages.
SWT are still FAR slower than QT or the Win32 API
Er no. SWT is the native GUI. Its a library that allows Java to use native GUIs via JNI.
Saying SWT is FAR slower than something like the Win32 API is like saying that Win32 API is FAR slower than the Win32 API!!
It just can't be ... Okay, so how could I make a blanket statement like that?
By not understanding how Java and JVMs work.
The java compiler actually compiles to a virtual opcode format, which is then interpreted by the java virtual machine at runtime.
No it's not. Except in very limited cases (such as embedded java, in restricted memory) this has not been true for a very long time.
For a typical modern JVM, it goes like this: Java starts to interpret the bytecode. If a JIT system is used the bytecode is then translated into native machine code, which is cached in memory. If a Hotspot system is used, a separate thread profiles the program and when slow code is found, the JVM translates the bytecode into highly optimised native machine code.
The machine code translators can be very thorough in their analysis, and can work out where it is safe to remove array bound checks etc.
The reasons why Java can be faster that C or C++ are (1) the VM can determine precise details of the processor its running on, so that bytecode can be translated into machine code optimised for that processor, and (2) the VM can profile the application and dynamically optimise and re-optimise. With statically compiled programs the attempt at optimisation is done once only.
2) Java has garbage collection, C++ doesn't. This is specified in the language. This affects performance.
In practice, C++ does have garbage collection of a kind. On a modern operating system, when you malloc() you arent getting 'real memory'; its all virtualized. That memory is managed and swapped. In effect, the operating system is 'garbage collecting' your memory to optimize access.