You seem to have either misunderstood the term 'out of date', or have got your sense of time mixed up after reading the earlier '100 Years of Special Relativity' topic.
This is nit-picking, I know, but I was under the impression that scripting languages were actually defined by the presence of an actively-running interpreter during execution,
Not necessarily. There have been many languages that have actively running interpreters, and even compilers that are available to modify code at run-time (Smalltalk and LISP are examples), but they are still not considered 'scripting' languages.
The definition of 'scripting' languages has become blurred.
Taking that into consideration, then, would Java with JIT qualify as an interpreted or compiled language? I'm not sure, myself---any thoughts?
Not by itself, as you can't type new expressions or interact with the code once it has started running. There are some interesting tools such as 'BeanShell', which does allow this to be done with Java code.
(System.out.println()? Yeah, yeah, OO, but come on, three nested levels of scope just to get to a command line?),
It makes sense once you get used to it. The 'System' class provides globally available (static) objects. One of these is 'out' - an instance of an output object that is bound to 'stdout'. println() is simply a method of that object.
Previous versions of Java have required code to be explicit about the classes providing such static objects. The latest version (5.0) allows (after the correct 'import' statements) you to write
Unfortuately things can happen like a GC cycle at a bad time that can cause annoying slowdowns at the worst moment.
As Java is now used in real-time control applications, that is certainly avoidable.
bloated: the java class libraries are huge and so deploying a java environment (and you can't assume a decent java system will already be installed by default) is a huge undertaking
Not really. Java can be installed as a single rpm or tgz. Its over 10 mb, but given the size of a CD-ROM, or broadband download speeds, that is hardly a 'huge undertaking'.
and who would seriously wan't to release thier software as java bytecode when jad is arround?
Why the hell did the interviewer decide to turn it into a "how did/does/will Java work with MS technologies" diatribe?
I mean, theyre so disparate in ideaology, while I can understand some of the relationships, why on earth bring them up with the creator of a language that MS has deliberately shunned when they couldnt get it to work "their way"?
Because neither Microsoft.NET (their "Java") or Java are going to go away. Both will be around for a long time, and both are going to have to integrate.
Java is evolving to work better with MS technologies in three ways: First, the Desktop Integration APIs, which allow the portable use of Browsers and features like the systray within Java applications, Secondly, by developing Java GUIs to make them indistinguishable from other Windows applications on Longhorn without losing portability, and Thirdly, with the use of Web Services to allow.NET programs to call Java, and vice versa.
Did anyone else that the "ease of configuration" for building applications might be driven by the Ruby on Rails push?
Not really. Ruby on Rails is in many ways a rather old fashioned approach. While almost all new systems work from the idea that the object model is the centre of design, Rails works from the database design. The idea that objects could be automatically and dynamically created from database tables was done in Smalltalk at least a decade ago.
Also, why does Sun waste all the effort on NetBeans? I'm sure it's a very capable IDE, but isn't nearly everyone else using Eclipse? Where would Java or Eclipse be if Sun put all the engineering time from NetBeans into a more useful project? I guess here I don't see the value of the competition as much...
Eclipse is good (I use it), but it is not that innovative. It has only just released support for the latest Java version, 6 months behind NetBeans.
Comparing Trails to a real lightweight kit says "I'm a fanboy and I don't know what I'm talking about."
Ruby on Rails is a real lightweight kit, but only when you first start developing. It is good at producing templates for later coding, but it very poor at following subsequent changes in database schemas. On the other hand, Trails allows the generation of an object model from a schema and the generation of a schema from an object model.
The Rails model of dynamically generating ORM classes at run time can potentially make applications extremely fragile, and means that much code can be difficult or impossible to debug and test independently of the actual deployment database.
If I don't know what I am talking about here, and Ruby On Rails has improved beyond my last look at it, I would be interested to know.
[Because there are alternatives that are just as easy to use, but can cope (or be adapted to cope) when your website unexpectedly hits that extra load.]
Like?
JSP or Coldfusion, for example. Technologies that allow easy and fast scripting yet allow decent management of connection pools and cacheing.
So now there are constraints in the database to match the validation in the Rails apps.
Exactly! One of the main criticisms often thrown at Object-Relational Mapping (as used in Rails and other APIs) is that it implies that the only way the database should be accessed is via the ORM software, not directly. Of course, this isn't true if you add the right constraints.
I use a Java equivalent to Rails - JDO - and the implementation I use has a tool that automatically adds constraints to the database to ensure that the correct relationships between objects is maintained even if other users access the data directly. I have seen major projects get into trouble because the developers assumed that constraints in their software was enough.
Well, gee, because EVERYTHING has to be some high-end, million-hit per day, dynamic website, right?
Come on. PHP and MySQL have their place. Why do people have to rag on it just because there are higher-end (an sometimes unnecessary) solutions available?
Because there are alternatives that are just as easy to use, but can cope (or be adapted to cope) when your website unexpectedly hits that extra load.
Tomcat must have progressed quite a bit in the last 5 years then.
It certainly has. Especially in terms of performance. The latest Tomcat (5.5) approaches the speed of Apache in some cases.
Yes, you could run Tomcat on port 80, with no Apache, but I seem to recall that Tomcat specifically leaves out much of the functionality that Apache does natively- perhaps lock something down by IP, etc.
This is all available now (RemoteHostValve, RemoteAddrValve etc).
Once you've gone through the nightmare of setting this up properly, you then get to learn Ant to make your WARs. While I did find Ant appealing/nice/whatever, it's quite a bit more complex than you're making it up to be to be serving up.jsp.
The latest versions of NetBeans (4.0, 4.1) does this for you. Every change to a J2EE project automatically updates your WAR file. It even (again automatically) writes and maintains Ant scripts so that you can do this from the command line as well.
I do feel a lot of the criticism of Java/JSP/J2EE is based on the way things were years ago. This have changed a lot!
You're right about the caching. I have no doubt that Java is a better language than PHP for the largest 1% of web apps.
On the contrary. If you are setting up any website that has even moderate demands on a database (particularly if that demand involves things that have to be transactionally safe), and you will want to reduce load on that database. This is where cacheing helps.
Perhaps a better statement that yours is that for a lot of websites, PHP is fine 99% (or even 99.99%) of the time. The problem is when you get that occasional heavy load on the website.
And if you want spaghetti code, both PHP and JSP are happy to help.
This doesn't mean (contra the AC above) that PHP is a toy language.:)
It certainly isn't. However, that does not mean it is suitable for all websites, or even 99% of them. It is fantastic for lots of uses, though.
is only light relative to even heavier Java solutions.:-|
No, it really isn't.
If you have a Java application server set up (like Tomcat - which can only take a few minutes to do), then creating JSP pages in a free open-source IDE like NetBeans can be done in seconds. Everything is done for you. Even better, you have the ability to validate and interactively debug the pages you script. You can add new JSP pages to the live application just like PHP, then when you are finished, NetBeans automatically builds a single file - a WAR, that you can deploy on on any J2EE app server - a process that can involve nothing more than putting the WAR in the right directory.
Compared to the horror that can be involved in compiling and configuring compatible versions of apache and php required for particular PHP applications, this is a dream.
Invariably people who sing the JSP praises have no significant experience with a real lightweight toolkit (Spyce, CherryPy, RoR,...)
This isn't true either. There are Java equivalents for these (such as Trails).
A skilled PHP programmer can write robust, object-oriented code that follows the same design patterns as Java.
This isn't quite true. A good example is that many very-high load Java websites use application-scoped caching of data. This is very hard to do elegantly in PHP.
Java was designed to be object-oriented from the start. With PHP, it was an afterthought.
It's just that certain Java frameworks force every project to be heavyweight, while PHP allows you to do a lot of things simply. If you want to write yourself a simple photo gallery app, why bother with Struts?
Java also allows you to do a lot of things simply. There is nothing forcing you to use those Java frameworks. You can write everything in scripted JSP pages.
Which is sad, because as much as PHP sucks, J2EE solutions suck just as badly in different ways. (That's another article.)
This is wildly unfair to both technologies.
PHP can suck in some ways. J2EE can suck in others.
However, what critics of J2EE often forget is that J2EE can be used in a very light manner. Major applications have been written using only JSP pages, possibly using a rich set of tag libraries. This allows development of scripted pages in a very similar manner to PHP, but with the ability to use the very rich Java libraries if required.
This leads to the question: if you shoot a light ray(velocity c=the speed of light) from the spaceship moving with half= 0.5 c, how come the light ray moves with 1.0 c from the view of both observers, not with 1.5 c from the resting observer?
Maxwell's equations of electromagnetism predicted that an electromagnetic wave (such as light) would travel through space at a certain speed (c). This light is not travelling relative to any physical medium (such as the hypothetical 'aether'). The speed of light is determined by certain physical properties of space. Those properties of space are the same no matter how fast you are travelling. Therefore, the speed of any light you encounter will appear the same to you no matter how fast you travel.
Is it possible this gravitational affect could accelerate the light being bent?
What happens instead is that light gains or loses energy in terms of its wavelength, not its velocity. Light coming out of a strong gravitational well still travels at the speed of light, but is red-shifted.
My diatribe was aimed at those who want to consider Intelligent Design/Creationism alongside Darwins theory of Natural Selection. Apparently the part about testing what a theory proposes escapes them.
I apologise - I mistook irony for the real thing:)
This is an incredible time to be alive and watching the strides made by physics.
My view is that things are rather tedious at the moment. Physics has become mired in a swamp of obscure mathematics and possibly permanently untestable hypotheses (such as String theories). Any attempt to find out 'what is really going on' seems to have been forgotten in the race to publish indecipherable papers and come up with yet another 'how many dimensions this time?' idea. It is definitely Vroomfondel and Magikthise territory....
it's only a theory, not a fact. As such I demand that schools teach that it is tiny demons which are causing the effects we are seeing.
My theory is just as credible as yours since it's only a theory and not a fact.
It is an extremely well tested theory. For example particle accelerators would not work unless it were true.
Ok, now that that diatribe is over, what's truly interesting is not that what Einstein proposed 100 years ago is still being studied and restudied, it's that one portion of it was recently confirmed. Frame dragging was only confirmed last year.
You have, of course, confused Special Relativity with General Relativity.
Slashdot Mirror
So in 15 years Java will be fast? w00t!
You seem to have either misunderstood the term 'out of date', or have got your sense of time mixed up after reading the earlier '100 Years of Special Relativity' topic.
This is nit-picking, I know, but I was under the impression that scripting languages were actually defined by the presence of an actively-running interpreter during execution,
Not necessarily. There have been many languages that have actively running interpreters, and even compilers that are available to modify code at run-time (Smalltalk and LISP are examples), but they are still not considered 'scripting' languages.
The definition of 'scripting' languages has become blurred.
Taking that into consideration, then, would Java with JIT qualify as an interpreted or compiled language? I'm not sure, myself---any thoughts?
Not by itself, as you can't type new expressions or interact with the code once it has started running. There are some interesting tools such as 'BeanShell', which does allow this to be done with Java code.
(System.out.println()? Yeah, yeah, OO, but come on, three nested levels of scope just to get to a command line?),
It makes sense once you get used to it. The 'System' class provides globally available (static) objects. One of these is 'out' - an instance of an output object that is bound to 'stdout'. println() is simply a method of that object.
Previous versions of Java have required code to be explicit about the classes providing such static objects. The latest version (5.0) allows (after the correct 'import' statements) you to write
out.println();
Unfortuately things can happen like a GC cycle at a bad time that can cause annoying slowdowns at the worst moment.
As Java is now used in real-time control applications, that is certainly avoidable.
bloated: the java class libraries are huge and so deploying a java environment (and you can't assume a decent java system will already be installed by default) is a huge undertaking
Not really. Java can be installed as a single rpm or tgz. Its over 10 mb, but given the size of a CD-ROM, or broadband download speeds, that is hardly a 'huge undertaking'.
and who would seriously wan't to release thier software as java bytecode when jad is arround?
There are plenty of bytecode obfuscators around.
I am a Very Big Fan of dynamic languages that can flex like a pretzel to fit my problem domain. Is Java evolving to be that pretzel?
It is getting that way, but I suspect that Groovy will get there first.
Until then, there are plenty of dynamic languages (including LISP) that run on the Java Virtual Machine.
"I knew it was slow, but I figured computer power would eventually catch-up and run things at a reasonable speed. It appears I was wrong."
On the 10th anniversary of Java - a joke that was out of date 5 years ago. (And, I remember the same thing being said about C++ 20 years ago).
Why the hell did the interviewer decide to turn it into a "how did/does/will Java work with MS technologies" diatribe?
.NET (their "Java") or Java are going to go away. Both will be around for a long time, and both are going to have to integrate.
.NET programs to call Java, and vice versa.
I mean, theyre so disparate in ideaology, while I can understand some of the relationships, why on earth bring them up with the creator of a language that MS has deliberately shunned when they couldnt get it to work "their way"?
Because neither Microsoft
Java is evolving to work better with MS technologies in three ways: First, the Desktop Integration APIs, which allow the portable use of Browsers and features like the systray within Java applications, Secondly, by developing Java GUIs to make them indistinguishable from other Windows applications on Longhorn without losing portability, and Thirdly, with the use of Web Services to allow
Did anyone else that the "ease of configuration" for building applications might be driven by the Ruby on Rails push?
Not really. Ruby on Rails is in many ways a rather old fashioned approach. While almost all new systems work from the idea that the object model is the centre of design, Rails works from the database design. The idea that objects could be automatically and dynamically created from database tables was done in Smalltalk at least a decade ago.
Also, why does Sun waste all the effort on NetBeans? I'm sure it's a very capable IDE, but isn't nearly everyone else using Eclipse? Where would Java or Eclipse be if Sun put all the engineering time from NetBeans into a more useful project? I guess here I don't see the value of the competition as much...
Eclipse is good (I use it), but it is not that innovative. It has only just released support for the latest Java version, 6 months behind NetBeans.
Oh, man.
Comparing Trails to a real lightweight kit says "I'm a fanboy and I don't know what I'm talking about."
Ruby on Rails is a real lightweight kit, but only when you first start developing. It is good at producing templates for later coding, but it very poor at following subsequent changes in database schemas. On the other hand, Trails allows the generation of an object model from a schema and the generation of a schema from an object model.
The Rails model of dynamically generating ORM classes at run time can potentially make applications extremely fragile, and means that much code can be difficult or impossible to debug and test independently of the actual deployment database.
If I don't know what I am talking about here, and Ruby On Rails has improved beyond my last look at it, I would be interested to know.
[Because there are alternatives that are just as easy to use, but can cope (or be adapted to cope) when your website unexpectedly hits that extra load.]
Like?
JSP or Coldfusion, for example. Technologies that allow easy and fast scripting yet allow decent management of connection pools and cacheing.
So now there are constraints in the database to match the validation in the Rails apps.
Exactly! One of the main criticisms often thrown at Object-Relational Mapping (as used in Rails and other APIs) is that it implies that the only way the database should be accessed is via the ORM software, not directly. Of course, this isn't true if you add the right constraints.
I use a Java equivalent to Rails - JDO - and the implementation I use has a tool that automatically adds constraints to the database to ensure that the correct relationships between objects is maintained even if other users access the data directly. I have seen major projects get into trouble because the developers assumed that constraints in their software was enough.
Well, gee, because EVERYTHING has to be some high-end, million-hit per day, dynamic website, right?
Come on. PHP and MySQL have their place. Why do people have to rag on it just because there are higher-end (an sometimes unnecessary) solutions available?
Because there are alternatives that are just as easy to use, but can cope (or be adapted to cope) when your website unexpectedly hits that extra load.
If it's normalized and designed correctly, YOU DON'T NEED VIEWS or constraints.
Unless you want to do database development in the real world, with real users who might try and shove anything into your database.
Tomcat must have progressed quite a bit in the last 5 years then.
.jsp.
It certainly has. Especially in terms of performance. The latest Tomcat (5.5) approaches the speed of Apache in some cases.
Yes, you could run Tomcat on port 80, with no Apache, but I seem to recall that Tomcat specifically leaves out much of the functionality that Apache does natively- perhaps lock something down by IP, etc.
This is all available now (RemoteHostValve, RemoteAddrValve etc).
Once you've gone through the nightmare of setting this up properly, you then get to learn Ant to make your WARs. While I did find Ant appealing/nice/whatever, it's quite a bit more complex than you're making it up to be to be serving up
The latest versions of NetBeans (4.0, 4.1) does this for you. Every change to a J2EE project automatically updates your WAR file. It even (again automatically) writes and maintains Ant scripts so that you can do this from the command line as well.
I do feel a lot of the criticism of Java/JSP/J2EE is based on the way things were years ago. This have changed a lot!
You're right about the caching. I have no doubt that Java is a better language than PHP for the largest 1% of web apps.
:)
On the contrary. If you are setting up any website that has even moderate demands on a database (particularly if that demand involves things that have to be transactionally safe), and you will want to reduce load on that database. This is where cacheing helps.
Perhaps a better statement that yours is that for a lot of websites, PHP is fine 99% (or even 99.99%) of the time. The problem is when you get that occasional heavy load on the website.
And if you want spaghetti code, both PHP and JSP are happy to help.
This doesn't mean (contra the AC above) that PHP is a toy language.
It certainly isn't. However, that does not mean it is suitable for all websites, or even 99% of them. It is fantastic for lots of uses, though.
is only light relative to even heavier Java solutions. :-|
...)
No, it really isn't.
If you have a Java application server set up (like Tomcat - which can only take a few minutes to do), then creating JSP pages in a free open-source IDE like NetBeans can be done in seconds. Everything is done for you. Even better, you have the ability to validate and interactively debug the pages you script. You can add new JSP pages to the live application just like PHP, then when you are finished, NetBeans automatically builds a single file - a WAR, that you can deploy on on any J2EE app server - a process that can involve nothing more than putting the WAR in the right directory.
Compared to the horror that can be involved in compiling and configuring compatible versions of apache and php required for particular PHP applications, this is a dream.
Invariably people who sing the JSP praises have no significant experience with a real lightweight toolkit (Spyce, CherryPy, RoR,
This isn't true either. There are Java equivalents for these (such as Trails).
[Despite its title, the book clearly does not tell the reader how to do everything with PHP and MySQL.]
/. articles become more accurate if you insert a 'NOT' in the title...
Darn marketing double-speak, gets you every time!
It is awesome how many
A skilled PHP programmer can write robust, object-oriented code that follows the same design patterns as Java.
This isn't quite true. A good example is that many very-high load Java websites use application-scoped caching of data. This is very hard to do elegantly in PHP.
Java was designed to be object-oriented from the start. With PHP, it was an afterthought.
It's just that certain Java frameworks force every project to be heavyweight, while PHP allows you to do a lot of things simply. If you want to write yourself a simple photo gallery app, why bother with Struts?
Java also allows you to do a lot of things simply. There is nothing forcing you to use those Java frameworks. You can write everything in scripted JSP pages.
Which is sad, because as much as PHP sucks, J2EE solutions suck just as badly in different ways. (That's another article.)
This is wildly unfair to both technologies.
PHP can suck in some ways. J2EE can suck in others.
However, what critics of J2EE often forget is that J2EE can be used in a very light manner. Major applications have been written using only JSP pages, possibly using a rich set of tag libraries. This allows development of scripted pages in a very similar manner to PHP, but with the ability to use the very rich Java libraries if required.
This leads to the question: if you shoot a light ray(velocity c=the speed of light) from the spaceship moving with half= 0.5 c, how come the light ray moves with 1.0 c from the view of both observers, not with 1.5 c from the resting observer?
Maxwell's equations of electromagnetism predicted that an electromagnetic wave (such as light) would travel through space at a certain speed (c). This light is not travelling relative to any physical medium (such as the hypothetical 'aether'). The speed of light is determined by certain physical properties of space. Those properties of space are the same no matter how fast you are travelling. Therefore, the speed of any light you encounter will appear the same to you no matter how fast you travel.
However, SR does include acceleration, jerk
I'm glad this was followed by:
(the third derivative of position with time)
For a second or two I was worried that the discussion was getting a bit aggressive....
So, it's like a prismatic affect?
Not really. A prism bends different wavelengths of light different amounts. Gravitational fields bend and otherwise affect all wavelengths equally.
Is it possible this gravitational affect could accelerate the light being bent?
What happens instead is that light gains or loses energy in terms of its wavelength, not its velocity. Light coming out of a strong gravitational well still travels at the speed of light, but is red-shifted.
My diatribe was aimed at those who want to consider Intelligent Design/Creationism alongside Darwins theory of Natural Selection. Apparently the part about testing what a theory proposes escapes them.
:)
I apologise - I mistook irony for the real thing
This is an incredible time to be alive and watching the strides made by physics.
My view is that things are rather tedious at the moment. Physics has become mired in a swamp of obscure mathematics and possibly permanently untestable hypotheses (such as String theories). Any attempt to find out 'what is really going on' seems to have been forgotten in the race to publish indecipherable papers and come up with yet another 'how many dimensions this time?' idea. It is definitely Vroomfondel and Magikthise territory....
it's only a theory, not a fact. As such I demand that schools teach that it is tiny demons which are causing the effects we are seeing.
My theory is just as credible as yours since it's only a theory and not a fact.
It is an extremely well tested theory. For example particle accelerators would not work unless it were true.
Ok, now that that diatribe is over, what's truly interesting is not that what Einstein proposed 100 years ago is still being studied and restudied, it's that one portion of it was recently confirmed. Frame dragging was only confirmed last year.
You have, of course, confused Special Relativity with General Relativity.