Actually, it's quite meaningful: the platform itself sucks and the platform definition is bloated. The fact that Sun's implementation is also bloated is icing on the cake.
Again, more ranting opinion based on no evidence.
Why don't you come up with some evidence that Java is actually a technically superior choice to, say, PHP,.NET, C++, Flash, etc.?
Trivial to do. Java is more scalable than PHP (has far better session and application scope data cacheing), and far more secure than PHP (no code injection problems). It is far more portable than.NET. It is far safer (with sandboxing and memory management) and portable at the binary level than C++ and far more versatile than Flash (could you show me a high performance database written in Flash? I can show you one - Hypersoniq - in Java).
And that only again demonstrates that libraries aren't everything, because Java sucks despite its extensive libraries.
In fact, the duplication of effort and multiple incomplete libraries that exist for the Java platform make the platform a real pain to work with. Add to that Java's tendency towards bloat in its libraries (very pronounced also in its "standard" libraries), you have a platform where availability of libraries is actually a liability.
Only a true anti-Java zealot could post such nonsense. Java is not one thing - it is any of dozens of implementations which have different performance and memory characteristics. To say 'Java sucks' is meaningless.
The availability of libraries is never a liability.
There are plenty of incomplete non-standard libraries for Java, but the set for the standard distribution is complete, and is by no standards bloated. The standard libraries (unlike those for C/C++) are designed to work cleanly together, with internationalisation and thread safety and part of their fundamental design.
If you are going to rant against Java, at least come up with some actual evidence.
They can't revoke my right to use my hardware on a whim. Sun, however, can disable every installation of the JVM in every device world-wide for whatever reason they want to. It has a phone-home clause in the license remember?
No, they can't disable every installation of the JVM. They can put what they like in a license, but local laws override such things. If they tried such a thing they would be slapped instantly with major international lawsuits to counter any such attempt.
What interests me is the type of mindset that assumes that they would even if they could. If you are really worrying about such things, you must worry about a lot. I mean, is your PC safe from abduction by aliens?
They would, I don't doubt it. But what are you going to do in the meantime?
What meantime? Are you seriously suggesting that the most widely used development language in use today would instantly vanish? Or that IBM (with its billions of dollars of resources) would not do something immediate to defend the use of Java (which IBM uses extensively)?
I know that some open source supporters feel uncomfortable about the use of non-open products, but to assume that anything could happen to interrupt mass use of Java is plain nonsense. You might equally worry about the fact that the hardware you are using to run open source software isn't open - do you have an open bios? an open processor?
I like open source, and I would personally like an open source Java, but to worry to this extent about licenses is crazy.
So from the example given by O'Reilly I can't immediately see the benefit JDO provides in terms of development, I can come to the exact same point with a comparable amount of code in Ruby or I can short cut it and accept the default behaviour with substantially less. All with no SQL at all.
Actually, you do need SQL. You need SQL to define your schema. You are putting exactly the same amount of effort into defining your data model in the database as you would put into defining your data model as Java classes. But, by defining it in the database you are losing a huge amount of flexibility and portability - it is a huge step backwards in terms of software design.
With the JDO approach, you can freely use inheritance and freely define whatever object relationships you like. And you aren't limited to persisting to relational databases. And you don't need to use any SQL.
Rails has taken the view that theoretical performance issues may never occur and time spent addressing them could well be time wasted, or even worse that your theoretical issues are wrong and bottlenecks occur in other parts of the system. It's this view which means that "high-performance SQL" can not be "automatically generated". The system can't intuitively know the best way to index a table or order data until real world usage occurs, and so that is left as an exercise to the reader.
I fundamentally disagree. I think Rails takes this view because optimisation of querying is extremely hard to do. The system can know the best way to index a table and order data automatically. This is proven by the high-performance of many commercial JDO systems, which generate SQL of equivalent quality to hand-optimised systems. Of course if you want to have to develop hand-optimised SQL yourself, fine, but I thought a framework like Rails should improve productivity?
If/when it becomes an issue then it's time to incrementally start over-writing the default options in the areas that need to be addressed.
Which is a complete waste of time. Why not use a system that already does this for you? As soon as you start to do this, you lose portability.
As oposed to JDO where the the model defines the schema?
No, it doesn't. You can work either way, or in a combined 'meet in the middle' approach. JDO does not specify this. The benefit of JDO is that there can be an explicit mapping that protects code.
but the default for lack of anything better is to tie the two tightly together.
Exactly.
This is incorrect. The scaffold makes it look like this because it is quick. However, ActionPack is a client of your models, and you can make that relationship as fragile or robust as you wish. The model does not "mess" with the code in the controllers or views. They are in a very strict client server relationship.
You are missing the point; I am not talking about scaffolding. I am talking about what happens when you abandon scaffolding - you then explicitly state field names in your own code. If the schema changes, the model classes change, and you code can break.
Even if you put in some isolation, the dynamic nature of Ruby means that you can't use tools or compilation to locate all places where field names are used in code.
Rails can do this as well, just not with the generated code. ActionPack can work with any underlying data model. It is not necessary to use soley the classes derived from ActiveRecord::Base.
You are missing the point again. I am talking about RoR 'as shipped'. Whenever I criticise it, I always get the response 'well, you can always change things!'.
RoR as sh
It does it better then Java for the 80% of the web that really just needs to put dynamic data out over the web.
Sorry, but this is nonsense. There is a niche that needs dynamic production and does not care too much about performance or internationalisation or scalability. But it is a niche.
It may be a better solution for the other 20% if a clean purpose build system with a single language paradyme and rapid startup are better then a complex system of odd libraries and expensive propriatary tool.
I think this shows a fundamental lack of understanding of how most Java developers with - with their modern free tools (like Eclipse) and their modern libraries with fast start-up (like Spring and Hibernate). Trashing Java because of the way it was in the last millenium is no way to defend RoR.
Summary: Sun can fuck you any time they want to for any reason they want to.
Which is completely irrelevant. If Sun did that, then IBM, or HP, or BEA, or PeopleSoft, or SAP or any of a dozen other firms would individually or together implement something that Runs Java code that is not called 'Java' - they have hundreds of millions of dollars of investment in this technology.
As I said, worries about safety of using Java are nothing but ranting.
Will they pull it off in time? Who knows. It's still a huge risk to have invested years into an application that can have the rug pulled out from under it at any time.
No, it isn't a huge risk; it isn't even a little one. Java is backed by almost all major software companies with the exception of Microsoft. In addition to Sun, IBM have invested huge resources and finances into backing Java, as have HP, Oracle, Borland, BEA, PeopleSoft, SAP and just about everyone else. Even if Sun disappeared and took the 'Java' brand with it, there would be large companies producing compatible VMs and products. This multiple vendor backing is one of the reasons why Java is so successful. Calling it a risk is nothing more than open-source paranoia, and is just ranting.
Once you understand how ActiveRecord::Base works you can make all the changes you want to the schema and simply write code in the appropriate model to make the changes transparent.
The fact that you have to do this is an indication of poor design.
Where beginers get hung up is assuming that all those little stub classes in app/models are just there to look nice, and rely on ActiveRecord::Base to do all the hard work. My personal opinion here, but I thing that letting the controllers mess with the actuall data in the models is poor design.
You are missing the point. The point is that controllers and views are always dependent on the structure of the model, and unless you rely on nothing but scaffolding, this leads to fragile code. The model messes with the code in the controllers and views. The bad thing about the Rails design is that there is no isolation prevening the model from doing this. There is no set 'mapping' between model and schema, as the model is the schema.
Other, more mature, systems isolate the object model from the database schema, allowing changes to be made safely in either one.
as well as the catastrophe that has become J2EE through over-engineering
Well, it is one of the most successful 'catastrophe's ever! A catastrophe that is used by most high-performance commercial web applications and server systems (E-Bay, for example).
J2EE is not over-engineering. It has a very specific purpose - high performance on clustered systems. You deploy your application and need neither know or care which platforms it runs on, or how many servers it is using. You can fine-tune how requests and sessions are handled, with different degrees of redundancy and failover without the application programmer needing to do anything.
What is the catastrophe is the huge misunderstanding of what J2EE is and what it was designed to do. Comparing the full J2EE stack with PHP or RoR is like comparing a large truck with a bicycle - both have their roles, and you will screw things up if you use either inappropriatelty.
There are parts of J2EE (the JSP/Servlet API) that are anything but over-engineered, and be used for very fast development - JSP pages can be scripted just like PHP, and require no app reloading to see changes.
Without knowing much about the other systems you mention and how they work, isn't the whole basis of "convention over configuration" taken to mean "if you only want the defaults, do nothing... if you need something more complex/controlled/etc then you can configure it accordingly". And to that, you can customise the SQL used to return a model, define relationships, or pretty much anything you want in rails as well.
The idea being get the system up and running and work out what needs to be addressed from a performance perspective based on real world usage instead of over-engineering based on a preconceived notion on where the problems will be.
But that is exactly what Rails does - it over-engineers by moving away from the idea of modelling with simple objects and allowing an easy object-relational system to automatically handle the data. Defining the model and relationships with SQL is by no means the simplest way! Let me give you an example of how another system works - the Java Data Objects (JDO) system. You define your model as totally normal classes. You can then give the minimal configuration - you simply list the classes you want to store in the database in a configuration file, and that is it. Database tables and columns are defined using sensible defaults, and even better high-performance SQL is automatically generated - you don't have to use any SQL at all. This is far simpler than Rails, and there are open source and free versions. JDO has had convention over configuration since 2000!
I don't mean to criticise, but you really do need to understand other systems in order to understand how limited Rails is. There is a huge amount of understandable enthusiasm for Rails, but mostly from developers who have not used modern fast object-relational systems in other language. They get the impression that Rails is the ultimate, whereas in many respects it is poor design.
As far as I've seen, there isn't that much actually new in RoR. But it's obvious that someone has had a great idea how a whole bunch of known stuff should fit together, in a way that encourages best practices (like a lot of testing, and code reuse). It has near perfect design.
No, it really doesn't, and to claim it does is to ignore the wide range of uses of object persistence. What it has is a great design for getting web interfaces up and running quickly on databases. It has a very poor design for long-term maintenance and growth of applications.
The ActiveRecord pattern is of limited use, especially as implemented in Rails. Your code is not isolated from major changes in the schema, and the dynamic nature of Ruby means that the consequences of such changes can't be tracked by compilation or refactoring tools; especially as the model classes don't even exist as code. Tests are a good way to help with this, but try and design tests to deal with potential schema changes for a large application that may have transactions involving thousands of records...
To see what a good persistence system should be like, take a look at Kodo or Xcalia - very high performance persistence system that allow exactly the same code and queries (which are automatically highly optimised for the particular database - not some minimal portable subset of SQL as in Rails) to be run on small embedded databases and high-end clustered systems. Unlike Rails, these systems can handle transactions of hundreds of thousands of records (something that is not that uncommon for commercial work) without thrashing disk or memory. You can also use the same code to persist and read to XML, LDAP and many other types of store. And yes, these systems also have 'convention over configuration' like Rails - they got there first, and had it years before RoR.
RoR has some great ideas, and definitely has its uses, but to claim it has near perfect design is way out, and sorry, but best practise in data model design in object oriented languages like Ruby does not involve basing things on non-OOP relational tables!
I wish some well-informed pro-microsoft guy would actually respond. Seeing posts like the above repeated on every microsoft story, is ridiculous and sad.
I find this a very interesting point. As the same posts are repeated again and again on stories like this, and as they are responded to every time by posts like your which clearly explain the situation, there are only a few possible conclusions:
1. The posters are Microsoft plants, simply repeating the same dogma again and again, not caring about the response.
2. The posters are trolling.
3. The posters are too lazy to read the responses.
the largest effect of a magnetic pole reversal would be on our technology, especially communications tech.
Go on - please list exactly which technologies are likely to be effected by this. We rarely even use the magnetic field for navigation these days. I can't thing of a single technology where this will have any impact at all.
Maybe something like this occuring leads to accelerated mutations and changes in the human genome (or all animals for that reason).
This is extremely unlikely. We probably get most of our protection from solar and cosmic radiation from the atmosphere, not from the magnetic field. There may be minor ground-level radiation increases during a reveral, but probably nothing signficant. The most significant effect will be spectacular aurorae all the way to the equator!
Significant areas around the poles are not protected by the magnetic field - in fact the field focuses charged particles to there, causing the aurorae. Are there any reports of people and animals in those regions suffering increased mutation rates? I doubt it.
You are saying a 150 meg JVM is somehow smaller than C code that can run on machines with a few kilobytes of ram?
JVMs aren't that big. Almost all new mobile phones have JVMs in, and they are memory limited devices. The J2ME system (Java Micro Edition) typically used in such phones requires only a few 100k for the entire Java system. There is even a J2ME implementation that includes a run-time profiler and native code generator that will fit in under 1MB.
But anyway, if you read what I posted, I was not talking about the size of the JVM. I was talking about the size of java byte code - the code than runs on the JVM. This byte code is compact, which is why it is increasingly favoured for low-memory embedded systems.
Running all your code in an emulator for a platform that doesn't exist... Yeah that sound like a great idea!
It isn't usually a great idea, which is why Java on most computers doesn't do it. On most machines the byte code for the imagined platform is merely a transitional stage before profiling and translation to native code. Sometimes though, it is a great idea. This is because Java byte code is smaller than much native code. So, in low memory situations (such as in memory-limited devices) running java byte code on a JVM is a space-saver.
They could, however, cause the planet to boil or freeze the moment the system strays too far. (If you don't know which Strange Attractor the climate would switch to, you cannot make any useful prediction from past trends.)
This is a bit extreme; The climate has been perturbed a LOT in the past - such by phenomenal heating through asteroid strikes, and substantial cooling after 'supervolcano' eruptions (most recently, only a matter of tens of thousands of years ago), but has not boiled or frozen. The attractors for those states can be that near....
I was always taught by my geography teacher that there as so many variables concerned, and all fairly random - that even a reasonably accurate prediction of climate changes over any length of time would be only ever be wildly inaccurate.
But still, if this helps my local weatherman to tell me it's going to be sunny on laundry day, and it actually is sunny then I'm all for it...
Your geography teacher was wrong. He would be right if he was talking about weather, but climate is not weather - it is the long-term average of things. It is like the flow of a river - there may be chaotic localised turbulence and vortices, but the overall flow is steady and predictable.
Er... you can't be serious. You know that thing called the World Wide Web, the massively revolutionary technological change that has proven to be the way that most people interact with the Internet? Almost entirely FOSS.
It wasn't invented in a FOSS environment. The first web browser ran on the NeXTSTEP platform - proprietary UNIX, using their Objective C language.
And how about the really unique and original permutations that allowed for the creation of online communities, like wikis and blogs? All originated as FOSS projects.
No, they didn't. Similar things had been around for decades before in the form of bulletin boards and similar systems.
And then there's email, IRC and Jabber. Oh, and Perl, which was highly innovative when it arrived. And Firefox's XUL UI, which allows quick, easy and open development of UI elements.
Sorry, nothing new there. E-mail was around long before FOSS, as was messaging (heard of Minitel?). Perl was innovative in some ways, but was based on previous languages - some C syntax, some shell scripting. Quick and easy UI development has been around since Smalltalk in the 70s.
And that's just innovation on features. When you get down to technical innovation (i.e. taking new approaches to old problems), the list gets too long for any individual to compile.
But that is not the point - I can't see anything specific to FOSS here.
I have to agree. There a large number of great FOSS projects, but I can't say I see that many innovative ones. I can't see anything to compare to, say, the work of Xerox developing GUI systems or Smalltalk.
If we were talking about the moon's gravitational field you'd be right. But OP was talking about the combined gravitational field of the hammer and the feather. This is torque, no?
The OP was not taking about the combined gravitation field, but the separate ones - the one from the hammer being stronger than the one from the feather, and the lack of symmetry creates a torque.
Yeah, I did that. Now how do I get my Java applications to display fonts correctly?
Use SWT, or install Java 6.0.
And more generally how do I get my Java applications to use a UI that's compatible with the rest of my system?
Use Java Native Desktop Components or SWT, or install Java 6.0.
How do I get Java applications to play nicely with the way I have audio configured on my OS? I don't think I can, and I've given up on trying regardless.
Try the Java Media Framework.
If Sun really wanted to improve the situation they would write native code compilers. I'd much rather have an application that worked well on one system than an application that worked half-assed on three or four systems, or whatever Sun considers "anywhere" these days.
Having native code precompilation is irrelevant. What matters is the interfaces to the operating system, and these do not depend on whether the bulk of the Java code is native or not.
Certified Java runs on far more platforms than those supported by Sun's implementation.
Slashdot Mirror
Actually, it's quite meaningful: the platform itself sucks and the platform definition is bloated. The fact that Sun's implementation is also bloated is icing on the cake.
.NET, C++, Flash, etc.?
.NET. It is far safer (with sandboxing and memory management) and portable at the binary level than C++ and far more versatile than Flash (could you show me a high performance database written in Flash? I can show you one - Hypersoniq - in Java).
Again, more ranting opinion based on no evidence.
Why don't you come up with some evidence that Java is actually a technically superior choice to, say, PHP,
Trivial to do. Java is more scalable than PHP (has far better session and application scope data cacheing), and far more secure than PHP (no code injection problems). It is far more portable than
Look at SWT and eclipse and you'll see just how much they have accomplished without the source code.
Eclipse is OK, but SWT is now a largely discredited waste of time.
And that only again demonstrates that libraries aren't everything, because Java sucks despite its extensive libraries.
In fact, the duplication of effort and multiple incomplete libraries that exist for the Java platform make the platform a real pain to work with. Add to that Java's tendency towards bloat in its libraries (very pronounced also in its "standard" libraries), you have a platform where availability of libraries is actually a liability.
Only a true anti-Java zealot could post such nonsense. Java is not one thing - it is any of dozens of implementations which have different performance and memory characteristics. To say 'Java sucks' is meaningless.
The availability of libraries is never a liability.
There are plenty of incomplete non-standard libraries for Java, but the set for the standard distribution is complete, and is by no standards bloated. The standard libraries (unlike those for C/C++) are designed to work cleanly together, with internationalisation and thread safety and part of their fundamental design.
If you are going to rant against Java, at least come up with some actual evidence.
They can't revoke my right to use my hardware on a whim. Sun, however, can disable every installation of the JVM in every device world-wide for whatever reason they want to. It has a phone-home clause in the license remember?
No, they can't disable every installation of the JVM. They can put what they like in a license, but local laws override such things. If they tried such a thing they would be slapped instantly with major international lawsuits to counter any such attempt.
What interests me is the type of mindset that assumes that they would even if they could. If you are really worrying about such things, you must worry about a lot. I mean, is your PC safe from abduction by aliens?
They would, I don't doubt it. But what are you going to do in the meantime?
What meantime? Are you seriously suggesting that the most widely used development language in use today would instantly vanish? Or that IBM (with its billions of dollars of resources) would not do something immediate to defend the use of Java (which IBM uses extensively)?
I know that some open source supporters feel uncomfortable about the use of non-open products, but to assume that anything could happen to interrupt mass use of Java is plain nonsense. You might equally worry about the fact that the hardware you are using to run open source software isn't open - do you have an open bios? an open processor?
I like open source, and I would personally like an open source Java, but to worry to this extent about licenses is crazy.
So from the example given by O'Reilly I can't immediately see the benefit JDO provides in terms of development, I can come to the exact same point with a comparable amount of code in Ruby or I can short cut it and accept the default behaviour with substantially less. All with no SQL at all.
Actually, you do need SQL. You need SQL to define your schema. You are putting exactly the same amount of effort into defining your data model in the database as you would put into defining your data model as Java classes. But, by defining it in the database you are losing a huge amount of flexibility and portability - it is a huge step backwards in terms of software design.
With the JDO approach, you can freely use inheritance and freely define whatever object relationships you like. And you aren't limited to persisting to relational databases. And you don't need to use any SQL.
Rails has taken the view that theoretical performance issues may never occur and time spent addressing them could well be time wasted, or even worse that your theoretical issues are wrong and bottlenecks occur in other parts of the system. It's this view which means that "high-performance SQL" can not be "automatically generated". The system can't intuitively know the best way to index a table or order data until real world usage occurs, and so that is left as an exercise to the reader.
I fundamentally disagree. I think Rails takes this view because optimisation of querying is extremely hard to do. The system can know the best way to index a table and order data automatically. This is proven by the high-performance of many commercial JDO systems, which generate SQL of equivalent quality to hand-optimised systems. Of course if you want to have to develop hand-optimised SQL yourself, fine, but I thought a framework like Rails should improve productivity?
If/when it becomes an issue then it's time to incrementally start over-writing the default options in the areas that need to be addressed.
Which is a complete waste of time. Why not use a system that already does this for you? As soon as you start to do this, you lose portability.
As oposed to JDO where the the model defines the schema?
No, it doesn't. You can work either way, or in a combined 'meet in the middle' approach. JDO does not specify this. The benefit of JDO is that there can be an explicit mapping that protects code.
but the default for lack of anything better is to tie the two tightly together.
Exactly.
This is incorrect. The scaffold makes it look like this because it is quick. However, ActionPack is a client of your models, and you can make that relationship as fragile or robust as you wish. The model does not "mess" with the code in the controllers or views. They are in a very strict client server relationship.
You are missing the point; I am not talking about scaffolding. I am talking about what happens when you abandon scaffolding - you then explicitly state field names in your own code. If the schema changes, the model classes change, and you code can break.
Even if you put in some isolation, the dynamic nature of Ruby means that you can't use tools or compilation to locate all places where field names are used in code.
Rails can do this as well, just not with the generated code. ActionPack can work with any underlying data model. It is not necessary to use soley the classes derived from ActiveRecord::Base.
You are missing the point again. I am talking about RoR 'as shipped'. Whenever I criticise it, I always get the response 'well, you can always change things!'.
RoR as sh
It does it better then Java for the 80% of the web that really just needs to put dynamic data out over the web.
Sorry, but this is nonsense. There is a niche that needs dynamic production and does not care too much about performance or internationalisation or scalability. But it is a niche.
It may be a better solution for the other 20% if a clean purpose build system with a single language paradyme and rapid startup are better then a complex system of odd libraries and expensive propriatary tool.
I think this shows a fundamental lack of understanding of how most Java developers with - with their modern free tools (like Eclipse) and their modern libraries with fast start-up (like Spring and Hibernate). Trashing Java because of the way it was in the last millenium is no way to defend RoR.
Summary:
Sun can fuck you any time they want to for any reason they want to.
Which is completely irrelevant. If Sun did that, then IBM, or HP, or BEA, or PeopleSoft, or SAP or any of a dozen other firms would individually or together implement something that Runs Java code that is not called 'Java' - they have hundreds of millions of dollars of investment in this technology.
As I said, worries about safety of using Java are nothing but ranting.
Will they pull it off in time? Who knows. It's still a huge risk to have invested years into an application that can have the rug pulled out from under it at any time.
No, it isn't a huge risk; it isn't even a little one. Java is backed by almost all major software companies with the exception of Microsoft. In addition to Sun, IBM have invested huge resources and finances into backing Java, as have HP, Oracle, Borland, BEA, PeopleSoft, SAP and just about everyone else. Even if Sun disappeared and took the 'Java' brand with it, there would be large companies producing compatible VMs and products. This multiple vendor backing is one of the reasons why Java is so successful. Calling it a risk is nothing more than open-source paranoia, and is just ranting.
Once you understand how ActiveRecord::Base works you can make all the changes you want to the schema and simply write code in the appropriate model to make the changes transparent.
The fact that you have to do this is an indication of poor design.
Where beginers get hung up is assuming that all those little stub classes in app/models are just there to look nice, and rely on ActiveRecord::Base to do all the hard work. My personal opinion here, but I thing that letting the controllers mess with the actuall data in the models is poor design.
You are missing the point. The point is that controllers and views are always dependent on the structure of the model, and unless you rely on nothing but scaffolding, this leads to fragile code. The model messes with the code in the controllers and views. The bad thing about the Rails design is that there is no isolation prevening the model from doing this. There is no set 'mapping' between model and schema, as the model is the schema.
Other, more mature, systems isolate the object model from the database schema, allowing changes to be made safely in either one.
as well as the catastrophe that has become J2EE through over-engineering
Well, it is one of the most successful 'catastrophe's ever! A catastrophe that is used by most high-performance commercial web applications and server systems (E-Bay, for example).
J2EE is not over-engineering. It has a very specific purpose - high performance on clustered systems. You deploy your application and need neither know or care which platforms it runs on, or how many servers it is using. You can fine-tune how requests and sessions are handled, with different degrees of redundancy and failover without the application programmer needing to do anything.
What is the catastrophe is the huge misunderstanding of what J2EE is and what it was designed to do. Comparing the full J2EE stack with PHP or RoR is like comparing a large truck with a bicycle - both have their roles, and you will screw things up if you use either inappropriatelty.
There are parts of J2EE (the JSP/Servlet API) that are anything but over-engineered, and be used for very fast development - JSP pages can be scripted just like PHP, and require no app reloading to see changes.
Without knowing much about the other systems you mention and how they work, isn't the whole basis of "convention over configuration" taken to mean "if you only want the defaults, do nothing... if you need something more complex/controlled/etc then you can configure it accordingly". And to that, you can customise the SQL used to return a model, define relationships, or pretty much anything you want in rails as well.
The idea being get the system up and running and work out what needs to be addressed from a performance perspective based on real world usage instead of over-engineering based on a preconceived notion on where the problems will be.
But that is exactly what Rails does - it over-engineers by moving away from the idea of modelling with simple objects and allowing an easy object-relational system to automatically handle the data. Defining the model and relationships with SQL is by no means the simplest way! Let me give you an example of how another system works - the Java Data Objects (JDO) system. You define your model as totally normal classes. You can then give the minimal configuration - you simply list the classes you want to store in the database in a configuration file, and that is it. Database tables and columns are defined using sensible defaults, and even better high-performance SQL is automatically generated - you don't have to use any SQL at all. This is far simpler than Rails, and there are open source and free versions. JDO has had convention over configuration since 2000!
I don't mean to criticise, but you really do need to understand other systems in order to understand how limited Rails is. There is a huge amount of understandable enthusiasm for Rails, but mostly from developers who have not used modern fast object-relational systems in other language. They get the impression that Rails is the ultimate, whereas in many respects it is poor design.
As far as I've seen, there isn't that much actually new in RoR. But it's obvious that someone has had a great idea how a whole bunch of known stuff should fit together, in a way that encourages best practices (like a lot of testing, and code reuse). It has near perfect design.
No, it really doesn't, and to claim it does is to ignore the wide range of uses of object persistence. What it has is a great design for getting web interfaces up and running quickly on databases. It has a very poor design for long-term maintenance and growth of applications.
The ActiveRecord pattern is of limited use, especially as implemented in Rails. Your code is not isolated from major changes in the schema, and the dynamic nature of Ruby means that the consequences of such changes can't be tracked by compilation or refactoring tools; especially as the model classes don't even exist as code. Tests are a good way to help with this, but try and design tests to deal with potential schema changes for a large application that may have transactions involving thousands of records...
To see what a good persistence system should be like, take a look at Kodo or Xcalia - very high performance persistence system that allow exactly the same code and queries (which are automatically highly optimised for the particular database - not some minimal portable subset of SQL as in Rails) to be run on small embedded databases and high-end clustered systems. Unlike Rails, these systems can handle transactions of hundreds of thousands of records (something that is not that uncommon for commercial work) without thrashing disk or memory. You can also use the same code to persist and read to XML, LDAP and many other types of store. And yes, these systems also have 'convention over configuration' like Rails - they got there first, and had it years before RoR.
RoR has some great ideas, and definitely has its uses, but to claim it has near perfect design is way out, and sorry, but best practise in data model design in object oriented languages like Ruby does not involve basing things on non-OOP relational tables!
I wish some well-informed pro-microsoft guy would actually respond. Seeing posts like the above repeated on every microsoft story, is ridiculous and sad.
I find this a very interesting point. As the same posts are repeated again and again on stories like this, and as they are responded to every time by posts like your which clearly explain the situation, there are only a few possible conclusions:
1. The posters are Microsoft plants, simply repeating the same dogma again and again, not caring about the response.
2. The posters are trolling.
3. The posters are too lazy to read the responses.
the largest effect of a magnetic pole reversal would be on our technology, especially communications tech.
Go on - please list exactly which technologies are likely to be effected by this. We rarely even use the magnetic field for navigation these days. I can't thing of a single technology where this will have any impact at all.
Maybe something like this occuring leads to accelerated mutations and changes in the human genome (or all animals for that reason).
This is extremely unlikely. We probably get most of our protection from solar and cosmic radiation from the atmosphere, not from the magnetic field. There may be minor ground-level radiation increases during a reveral, but probably nothing signficant. The most significant effect will be spectacular aurorae all the way to the equator!
Significant areas around the poles are not protected by the magnetic field - in fact the field focuses charged particles to there, causing the aurorae. Are there any reports of people and animals in those regions suffering increased mutation rates? I doubt it.
You have got to be kidding.
No.
You are saying a 150 meg JVM is somehow smaller than C code that can run on machines with a few kilobytes of ram?
JVMs aren't that big. Almost all new mobile phones have JVMs in, and they are memory limited devices. The J2ME system (Java Micro Edition) typically used in such phones requires only a few 100k for the entire Java system. There is even a J2ME implementation that includes a run-time profiler and native code generator that will fit in under 1MB.
But anyway, if you read what I posted, I was not talking about the size of the JVM. I was talking about the size of java byte code - the code than runs on the JVM. This byte code is compact, which is why it is increasingly favoured for low-memory embedded systems.
Running all your code in an emulator for a platform that doesn't exist... Yeah that sound like a great idea!
It isn't usually a great idea, which is why Java on most computers doesn't do it. On most machines the byte code for the imagined platform is merely a transitional stage before profiling and translation to native code. Sometimes though, it is a great idea. This is because Java byte code is smaller than much native code. So, in low memory situations (such as in memory-limited devices) running java byte code on a JVM is a space-saver.
They could, however, cause the planet to boil or freeze the moment the system strays too far. (If you don't know which Strange Attractor the climate would switch to, you cannot make any useful prediction from past trends.)
This is a bit extreme; The climate has been perturbed a LOT in the past - such by phenomenal heating through asteroid strikes, and substantial cooling after 'supervolcano' eruptions (most recently, only a matter of tens of thousands of years ago), but has not boiled or frozen. The attractors for those states can be that near....
I was always taught by my geography teacher that there as so many variables concerned, and all fairly random - that even a reasonably accurate prediction of climate changes over any length of time would be only ever be wildly inaccurate.
But still, if this helps my local weatherman to tell me it's going to be sunny on laundry day, and it actually is sunny then I'm all for it...
Your geography teacher was wrong. He would be right if he was talking about weather, but climate is not weather - it is the long-term average of things. It is like the flow of a river - there may be chaotic localised turbulence and vortices, but the overall flow is steady and predictable.
Er... you can't be serious. You know that thing called the World Wide Web, the massively revolutionary technological change that has proven to be the way that most people interact with the Internet? Almost entirely FOSS.
It wasn't invented in a FOSS environment. The first web browser ran on the NeXTSTEP platform - proprietary UNIX, using their Objective C language.
And how about the really unique and original permutations that allowed for the creation of online communities, like wikis and blogs? All originated as FOSS projects.
No, they didn't. Similar things had been around for decades before in the form of bulletin boards and similar systems.
And then there's email, IRC and Jabber. Oh, and Perl, which was highly innovative when it arrived. And Firefox's XUL UI, which allows quick, easy and open development of UI elements.
Sorry, nothing new there. E-mail was around long before FOSS, as was messaging (heard of Minitel?). Perl was innovative in some ways, but was based on previous languages - some C syntax, some shell scripting. Quick and easy UI development has been around since Smalltalk in the 70s.
And that's just innovation on features. When you get down to technical innovation (i.e. taking new approaches to old problems), the list gets too long for any individual to compile.
But that is not the point - I can't see anything specific to FOSS here.
Lol, they might be your intellectual equals, but they certainly aren't mine. Dolphins as smart as people? Get a grip
Oh yeah? What do you do all day? What do they do all day? Now who do you think is smarter?
Yes, they're active, but innovative? Hardly.
I have to agree. There a large number of great FOSS projects, but I can't say I see that many innovative ones. I can't see anything to compare to, say, the work of Xerox developing GUI systems or Smalltalk.
If we were talking about the moon's gravitational field you'd be right. But OP was talking about the combined gravitational field of the hammer and the feather. This is torque, no?
The OP was not taking about the combined gravitation field, but the separate ones - the one from the hammer being stronger than the one from the feather, and the lack of symmetry creates a torque.
Yeah, I did that. Now how do I get my Java applications to display fonts correctly?
Use SWT, or install Java 6.0.
And more generally how do I get my Java applications to use a UI that's compatible with the rest of my system?
Use Java Native Desktop Components or SWT, or install Java 6.0.
How do I get Java applications to play nicely with the way I have audio configured on my OS? I don't think I can, and I've given up on trying regardless.
Try the Java Media Framework.
If Sun really wanted to improve the situation they would write native code compilers. I'd much rather have an application that worked well on one system than an application that worked half-assed on three or four systems, or whatever Sun considers "anywhere" these days.
Having native code precompilation is irrelevant. What matters is the interfaces to the operating system, and these do not depend on whether the bulk of the Java code is native or not.
Certified Java runs on far more platforms than those supported by Sun's implementation.