I saw the Byte magazine in a newsstand for the first time in August 1978, the cover story was about Pascal and I bought it. I still have that magazine. Inside there's an article about how Pascal was compiled to an intermediate form called "P-code". As you can see, the Java VM isn't such a new invention.
It certainly isn't. The VM is much older than that - Smalltalk was using a VM in 1972.
But optimization isn't about byte code alone. As someone mentioned in this thread, algorithms can be much more important. And the big advantage about C/C++ is that they often let you choose the best algorithm for your application. Let's say your program needs to copy a hundred million strings. In C, if you know you can trust those strings to contain no malware, you can do it in a very elegant way: while (*s) *d++ = *s++;. How would an automated optimizer know when you can trust a string to have limited length so you can use this simplified routine without risking a buffer overflow? And, of course, in C/C++ you can use pointers, so maybe the best solution would be to pass pointers to those strings instead of copying their contents.
I don't think C or C++ developers realise quite how advanced Java optimisers and Java class libraries are. If you want to have limited length strings in Java, you can use char arrays:
char [] array = new char [size];
automated optimiser often knows from the source code (you can use a final ('const') value for the size) that the arrays are all within a certain limit, and it can then turn off range checking and use highly optimised machine code to handle the arrays. Just like with C and C++, there is a real advantage in Java in knowing how to write algorithms that make it explicit what the sizes of objects and arrays are, for the best optimisation.
In Java, you can pass pointers to Strings just the way as in C - in Java all object references are already pointer - but safe ones.
Optimization is like that classical joke about "girls looking for husbands and husbands looking for girls". It's not a symmetrical situation. Everything you can do to optimize Java, Ruby, Python, etc, you can also apply to C/C++, but the opposite isn't always true.
No, this is just not true; not anymore. There is something really special that Java can do for optimisation that C and C++ can't - and that is to be able to optimise at run-time for the specific processor you deploy on. With C and C++ you would have to compile for Intel 32-bit. And Intel 64-bit. And AMD 64-bit. And multicore. And PowerPC 64-bit. And Sparc and... so on (and that only deals with processors, not operating systems). With Java, the manufacturer of the processor and the OS writer work together to provide the optimisation techniques for the Java VM on their platform.
We are reaching an interesting point with VM technology - byte code translation and run-time optimisation has finally reached the performance of optimised pre-compilation. Within a decade, it will easily exceed it for almost all applications, and, although C and C++ will continue for a long time, they will be gradually related to the niche where they excel - processor-specific system coding.
That's why I don't buy those Python/Ruby/Java productivity boasts. I'd rather do it efficiently in C/C++ right now than wait for a faster CPU that may never come.
You aren't doing it (much) faster in C or C++; at least not in all cases. Even for algorithms that are routinely used to check language performance (such as Linpack) customised Java VMs equal C code. Java is not interpreted - it is translated to byte code that is then compiled into machine code with a considerable amount of run-time optimisation (with all the optimisation features that C/C++ compilers have). Considerable work is being put into similar technologies for Python and Ruby.
Processors are getting increasingly complicated, and the idea of optimising general purpose code for multi-core chips will soon look antiquated. Even now, writing general purpose high-performance portable multi-threaded code is vastly easier in Java than C or C++. The future will almost certainly be dominated by portable languages running on highly optimising VMs. and they will give high performance.
Once you've sufficiently shattered a rock, detonate a series of warheads, using their released energy to divert and/or slow down the resulting debris cloud.
It wouldn't work. The kinetic energy of many rocks that are dangerous can be phenomenal - we are talking about vastly more than the entire nuclear arsenal of the world. Shattering something into pieces is (literally) astronomically easier than diverting the mass.
Exactly. The open source model is a higher productivity model, so the black hats use it, just like everybody else that produces a lot.
A higher productivity model? Nonsense. It is no more high productivity than any other development model. Productivity depends on the development team, and their movation and interest, and the openness or otherwise of the project has little or no bearing on this. Just look at the number of open source projects stuck in permanent beta because no-one is interested in doing the hard, dull parts that are required to finish things.
Human tissues simply don't survive freezing (at least not with current freezing techniques)." is false.
It is false, and I should have worded things better - certain organs have indeed been shown to survive freezing (after all, the manage it with human embryos!).
What I mean was that no-one has yet demonstrated any technique that would allow a human brain (and all the support tissues) to survive below zero long term. I see no reason why this may not happen in the future, but my point is that to try and use current techniques is pointless - they simply aren't going to work!
Interesting, but my point still stands. Using cryonics now, when it is still certain that irreparable damage will occur, is a matter of faith, not science.
why is it that cryonics in particular is fair game for such defamatory comments?
Possibly because it requires so much faith, while claiming to be based on science. Human tissues simply don't survive freezing (at least not with current freezing techniques). It is unlikely that even a single cell in cryonically 'preserved' tissue is undamaged. Even if nanotechnology works, it is hard to think of any mechanism that would be able to identify and repair all the cells and cell organelles that would be damaged in all sorts of unpredictable ways.
This is not to say that cryonics might not work in the future, but now, it seems like a faith based on poor science.
Not at all, it's entirely implicit. As your application runs through the tests, the missing methods will raise an exception. It's no different than removing a method that exists right in the model.
This just doesn't work effectively for substantial applications (at least in my experience). You can't test all parts of all the code all the time - this effectively removes the agility of Ruby.
Database schemas don't just change at random. To do it the Rails way you even have to write a Ruby script (a migration) to upgrade the database. If you've gone to all that trouble, surely you'll be able to figure out what needs to change in the application.
Databases don't always change that way. It is a very simplistic view to consider that you will have control of all uses of the database, and will be the one who defines what happens and when. It is typical for your application to be just one of several that use a particular database. Figuring out what needs to change may be straightforward, but locating all those changes and updating the code can be a major exercise. Far simpler to is have a mapping between classes and database to allow these changes to be made in one place - the DRY approach.
No it can't. As you said you need a mapper file to map your database to your objects.
In those ORMs that do, it can be generated for you - either from your schema or your classes. You need not touch it yourself. In many ORMs (such as JPA) you need no mapping file at all.
Once again that's precicely the point. Class generation has been around for decades now. Rails specifically didn't want to do that.
No, you are missing the point. Class generation has been indeed around for decades. But the modern approach is to define your data as classes and have schema generation (or something called 'meet in the middle', where schema and class definitions interact). Rails gets it the wrong way round - the relational database is a very poor place to define object models - this was a lesson learned decades ago (but apparently, not learned by Rails).
It's becoming obvious to me that you have never used rails or even ruby.
Nice to know you are a mindreader:) You are wrong.
In rails you can create all the mappings you want. You just do them in your class instead of an external file and you do them only if you want to rename a field. You can can even attach to different databases at runtime. For example if you have a activerecord defined as people but you have 50 databases (one for each client let's say) when you instanticate the people object you can attach to any database you want.
You are missing the point yet again. Of course, you can do all sorts of things with Rails - it is extremely easy to customise anything (that is one of the great things about Ruby). Of course you can create mappings, but this does not help, for example, suppose someone creates additional fields - your mapped classes will pick those up automatically. Your code is still vunerable to schema changes in ways that more robust ORMs aren't. As shipped, and as intended to be used, Rails is fragile.
I think you really should use the framework before making remarks about it. It's clear that you are simply talking out of your butt.
I have used it, and I have researched it in detail. I have a habit of actually researching technologies I comment on. I think you need to take a much deeper look at other technologies (especially modern JDO 2.0 implementations like Kodo, and associated tools) before posting again - you will find some awesome stuff - the ability to define queries in portable languages, and like really high performance transaction handling.
Well those types of frameworks already exist. J2EE immediately comes to mind as well as hibernate, ibatis etc. The rails people have produced an alternative to those types of frameworks because they didn't want to define something in two places (or three or four or five or sixteen). In other words it's not a bug, it's a feature.
If you don't like that feature of Rails then it's not for you but DRY is a major selling point of rails. It sounds like you would be more comfortable with J2EE.
Sorry, but this is wildly out of date. J2EE can be just as DRY as rails. Rails is competing with what J2EE was years ago, not what it is now. For example, with Hibernate and with other ORMs used with J2EE, you can generate you Java classes from a database schema (or part of that schema). However, unlike Rails, this is only done when you request it. Also, there are tools with these ORMs that allow the generation of schemas from your java classes. This is a superb feature, as it means you can automatically generate optimised schemas for just about any database without changing a single line of your code. I would claim that this is even more DRY than Rails, as not only do you define things in one place (your class files) for one database, you define them once for any future database you use. This is not the case with Rails, as use of different databases may require different column name conventions and changes.
I use this feature all the time - my code can run without change on PostgreSQL, MySQL, Oracle, SQL Server, DB2 and so on.
Your tests (you are writing tests, aren't you?) will already catch any problems that arise from changing the schema. Unless of course your production database just changes at random. In which case you've got way bigger problems.
One of the golden rules of development is that you can't predict what data people will throw at your code. However, with Rails/ActiveRecord you can't even predict what your code is! The tests you would have to write are phenomenal - you would have to check for the continued existence of every field of every class generated from database tables.
I have never used any framework where changing the schema didn't lead to all kinds of problems. Rails is actually more resilient then most because objects automatically morph with the change and with frequent use of iterators it drastically reduces the amount of code that needs to be fiddled with.
No, it is the other way around. Rails less resilient because objects automatically morph with the change. This automatic morphing is the aspect of Rails ActiveRecord that I consider to be both uncessary and dangerous. A resilient framework should be able to detect schema changes and isolate code from them, not automatically morph objects. Of course other frameworks have problems with a schema change, but at least with many of them you can detect schema changes and how they impact the rest of the code.
Surely a better approach would have been for Rails to generate Ruby source (or some other representation - even (horrors!) XML) from a schema, and then to introspect this source and the database when an application starts (or when a table is first used) in order to warn of changes. Of course, recent versions of Rails may do this, in which case I have far few objections to it.
Ah, well, in that case, you're definitely unlikely to be happy with AR:-). Well, anyhow, best of luck!
Indeed:)
It is a shame that AR has such publicity when there are far better approaches, in Ruby, which could have been used in Rails instead, like Og.
Re:Rails needs to be more mature
on
Ruby For Rails
·
· Score: 1
Just do it the same way you do in every other language... execute a SQL statement.
Fortunately, that is not the way you do it in every other language. SQL is notorious for its quirks and lack of portability, and using substantial amounts of SQL is a great way to make your app highly dependent on a specific database. Other languages use alternative methods of querying or SQL-like languages that are guaranteed to be portable, and are translated to efficient optimised SQL for whichever database you happen to want to use (such as the recently standardised JDOQL and JPAQL in Java).
"> This is why most ORMs have a separate mapping layer, which protects against this."
I'd submit that many web apps don't need really this layer and that, in many cases, introspecting the DB like AR does is plenty good enough.
The thing is, it leads to fragile code. Changes in a schema lead automatically to changes in code, which are potentially hard to trace, as they happen only at run time. Also, it can seriously inhibit portability, as schema changes are almost always necessary to some extent when switching between different database products.
Sorry, my opinion is that introspecting the DB (or any persistence mechanism) at run time is a seriously bad idea, for many reasons.
Anyhow, not to thrash this out too much, just wanted to make the point that AR adaptors can be written for something other than a relational DB.
I think it does need to be thrashed out:)
The reason is that too many are seeing Rails as some wonderful total solution to all kinds of problems, without a real critical look at its potential problems (and it does have some!).
No, hell no the EU would be defending the company stating that it has a better product and the consumers decided that.
That is not the point. The consumers may have decided that Windows on the desktop is better, but the issue is that Microsoft are using this position to make their Servers more effective because of their dominance of the desktop. In other words, other companies aren't being allowed to give the consumers full choice of servers.
Is it impossible for Linux and apple to use window Servers? Depending on which server application the answer is yes or no.
Wrong. It is not impossible, but they can't use them as effectively, as they don't know the protocols to use them as effectively.
File server, I see people around campus using macs and Linux boxen and store their files on Linux, apple, and windows servers. So Id say either someone did some serious hacking and created a custom way to write to the Windows file server from other Oss, or the EU is just lazy and doesnt want to read what is available or wants to be handed the product. Again being lazy.
Yes, someone did do some serious hacking, and as a result Linux machines can use Windows servers, and Linux servers can provide services to Windows desktops - but not nearly as effectively as if they used the full correct protocols.
Exchange, one needs an exchange client first. If someone makes a Linux exchange client, then Linux can use exchange.
No, because to use exchange effectively, you need to know the full protocols.
"It assumes that the database schema is the centre of the data model.
Hm, although, the folks from salesforce.com wrote a ActiveRecord adaptor to their web services. So AR may be a bit more flexible than your post indicates...
No, it isn't - not really. The issue is that your data model is determined by one source - it doesn't matter if this is a web service, or if it is a relational database.
A data model should be independent of the mechanism of persistence. You should be able to persist the same data model to web services, databases, XML and so on. ActiveRecord still says that the database is defined by the particular schema, no matter what the mechanism of persistence. This is the backward step. Your software is data-driven, not model-driven - change the data and your program breaks, and does so unpredictably. This is why most ORMs have a separate mapping layer, which protects against this.
There's no reason to assume that Rails will fail in the near term. Rails is based on a method of decomposing software functionality that does back to the 1970s (Model-View-Controller). Rails might not be here forever, but it has a very solid architectural foundation and it is easy to adapt it to the latest trends (for instance, you can create AJAX-based Web applications very easily with RoR). In other words, the extensibility and architecure of Rails make it adaptable, just as you mention Ruby being adaptable.
This may be true, but Rails is also based on an approach to object-relational mapping (Active Record) that is not widely used and with only limited applicability. It assumes that the database schema is the centre of the data model. This is a very narrow view of data. Increasingly data comes from other sources than relational databases. To see how sophisticated this can get look at Xcalia - a Java product that can persist and retrieve data from just about anything - LDAP, XML, Databases - even SOAP services. Although I am no Microsoft fan, they are heading the right way with their new LINQ persistence system on.NET that allows querying and persistence to almost anything including in-memory objects. ActiveRecord is a very neat implementation of a very old-fashioned approach.
This is just getting stupid. M$ is getting F'd in the A because they built an o/s that a business 'chooses' to use. That business wants to get additional software that integrates with their servers as smooth as possible. Business chooses M$ software because it smoother than the competition (and not by much I must add). I really don't understand???? Whats the problem here?
Because of something called a 'monopoly'. Microsoft have overwhelming dominance on the desktop. They are using that dominance to sell servers, which is a separate market. Using monopoly dominance in one market to influence sales in another is illegal.
Microsoft server software integrates more smoothly than the competition with their desktop systems because their desktop systems require specific protocols for this integration which Microsoft are keeping secret. Other systems have managed to replicate this only by reverse-engineering what is seen to go across networks.
Microsoft could easily have provided good integration with desktop systems using standard or existing protocols (they have proved in the past that they can produce quality implementations of such things).
None of this would matter if Microsoft were not effectively a monopoly presence on the desktop (that does not mean total dominance - it means enough presence to seriously influence other markets).
First, let me say that you seem to have a tendency to respond to what you think I wrote, not what I actually did.
I have never said that no apps ever break with JRE upgrades, or that you never need to test things with different JREs
What I have actually said is that issues with JRE updates are rare. Java is one of the most backward-compatible systems ever produced. Nothing you have said and no links you have provided have demonstrated otherwise. You seem to be considering matters of how to access JREs or how to package applets as if they were somehow related to the Java language and compatibility. They aren't. You have provided a very minor list of issues that may occur when people upgrade from Java 1.3 (released 6 years ago!) with Java 1.5. That minor list simply emphasises how few programs are going to break, and the minor matters involved.
I realise you are not in a position to give a personal example, but that does not help the debate. Until you can give some specific reason, I can't see any point in continuing.
If anything, this conversation has helped prove my point - that the suggestion made by a poster a while back that 'all your old aplications do not work at all anymore when users install the new JRE' is utter nonsense. (note the use of the word 'all' - not 'some', or 'a very few', but 'all'!).
It it is so obviously nonsense that I can't see why anyone is bothering to argue against it.
The GP complained that he'd seen Java apps break. You said you hadn't and that you couldn't imagine more complex apps. You were definitely implying he was a liar. This isn't a court of law so burdens of proof don't apply here. To me your intent was very clear.
No, I was clearly saying that complex apps obviously don't break with version changes.
In your latest post again you insist that because you haven't in your very limited experience seen Java apps break, that it's rare. It's not.
Yes, a very limited experience based on being a developer for 30 years and using Java since it came out.
That's just the tip of the iceberg and I'm not going to do any more work proving that things have broken because with your attitude I don't see you admitting to a mistake.
Oh for goodness sake! This suggests that you really don't understand the issue! Those links you showed aren't the 'tip of the iceberg' - they are most of it. Of course things wont work if you compile specifically for a later version of the JRE and then expect it to run on them. That is a crazy as expecting an app compiled for MacOS/X to run on Mac OS 7!
This is not an issue of JRE upgrates breaking existing apps - it is an issue of using a JDK upgrade and not taking into account the fact that the compiler produces code for the equivalent JRE. There is nothing wrong with than, and a simple switch can change this.
Guess what happens if you use any 3rd party product that is in any way incompatible. You need to get another version of that product.
Only if that 3rd party product relies on a later JRE or JDK, in which case it is entirely reasonable.
Now you're obviously not interested in reality. In your mind because you haven't had the displeasure of working on something that's been badly broken by a JRE release all is good. Enjoy living your fantasy but don't force it down other people's throats or belittle them when they point out that they've seen it happen.
I haven't worked on something that has been badly broken by a JRE release, because few people have. You haven't shown any such thing. All you have shown what happens if someone compiles for a later JRE and tries to run it on an earlier one. Do you seriously expect all your clients to automatically upgrade to JRE 1.5? Of course not. It is your responsibility as a developer to take into account the versions of runtimes your clients use. If you update your compiler (javac), it is your fault if things break.
Talk about the pot calling the kettle black. You called the GP a liar because his experience didn't match yours. How dare you then come back and point the finger at someone making assumptions you hypocrite!
No, I did not call the GP a liar. I am careful with wording.
Well I have. "It works for me on my machine so stuff you" is nonesense that no professional should be uttering, let alone calling a perfect stranger a liar because they've seen something you haven't.
Again, I did not call him a liar.
Explain my experience then. I'm either lying (and I happen to know for a fact that I'm not, and would gladly prove it if it didn't require breaking my contract and if I thought it would sway you one bit).
Then why are you bothering posting if you can't prove it? I am not saying you are lying. It is certainly possible to write apps that break from one JRE to another, but it is also pretty simple to ensure they don't - the release period between JREs are long, and the guidelines are clear. But if you can't provide actual evidence, what is the point?
JBoss and Netbeans are just two technologies. Most of my experience happens to be with Eclipse though I have used Netbeans, and Weblogic though I've also used Tomcat and JBoss. So what. There are more technologies out there that neither of us have used than you could shake a stick at and to make the assumption that no applications have broken just because you haven't seen it is both arrogant and ignorant.
They aren't just two technologies - they are illustrations of a wide range of aspects of the JRE - GUI, multithreading, file handling, networking, concurrency. If anything should break between releases, these should.
I did, of course, not say that no applications have broken. I said I have not seen any that have broken, and this includes very complex apps.
What do you do when your users complain there's a bug you can't reproduce? Shut your eyes, put your hands over your ears and shout "la la la la la" at the top of your voice?/. stupidity never ceases to amaze me.
I fix the bugs. I deal with them. I write my apps and test them on different JREs. To write an app so tied in to one JRE that it breaks on a new one is, these days, inexcusable and a sign of bad development practice. If Tomcat and NetBeans can manage for this not to happen, so can everyone else. There has rarely been a technology that is so backwards compatible as Java.
Well you've obviously never written anything in a complex Java environment. I've seen apps I've worked on break in 1.5 where they worked fine in 1.4.2_08. This caused our team huge headaches because it was an applet problem that had already been installed on a lot of client machines, some external to the organisation I worked for.
It is great the way that posters assume things! I work on substantial Java applications daily - apps with hundreds of thousands of lines of code.
There are very complex Java applications that run unchanged on different versions of Java - JBoss, NetBeans for example. These are app servers and IDEs - it is hard to think of apps that are more complex. I have never seen a single app break between Java 1.4 and 1.5.
GCC did not even come close to implementing the C++ standard until 3.2 - Your program was not C++, it was implemented in the C++-like dialect that earlier versions of g++ implemented.
This is often the case for pre-standard C++ programs.
(1) It was indeed C++.
(2) This has been an issue with C/C++ - compilers that are allowed to label themselves as C/C++ that aren't compatible. This is not the case with Java.
... until Sun relases a new JRE and all your old aplications do not work at all anymore when users install the new JRE. Unmaintained applications die altogether or require constantly uninstalling and installing various JREs to run them as well as new ones. That's the biggest bug of all in Java and makes any bug tracking useless, and programming in Java pointless.
C/C++ applications tend to work for decades and can be written to be far more reliably cross-platform.
Odd. I have found exactly the opposite. Java is very well know for the excellence of its backward compatibility, and to say 'all your old applications don't work anymore' is just plain false. Java would not have had the huge success it has had if this were not the case, so your statement is plainly wrong.
On the other hand, C/C++ version bugs are well known and well documented - just think of the issues involved with gcc versions and linux kernel compilations. I have a very simple C++ app that compiled and ran fine on one version of gcc, but broke on another.
If you simply exchange C/C++ for Java, and vice versa, throughout your post, it then makes sense.
Slashdot Mirror
I saw the Byte magazine in a newsstand for the first time in August 1978, the cover story was about Pascal and I bought it. I still have that magazine. Inside there's an article about how Pascal was compiled to an intermediate form called "P-code". As you can see, the Java VM isn't such a new invention.
It certainly isn't. The VM is much older than that - Smalltalk was using a VM in 1972.
But optimization isn't about byte code alone. As someone mentioned in this thread, algorithms can be much more important. And the big advantage about C/C++ is that they often let you choose the best algorithm for your application. Let's say your program needs to copy a hundred million strings. In C, if you know you can trust those strings to contain no malware, you can do it in a very elegant way: while (*s) *d++ = *s++;. How would an automated optimizer know when you can trust a string to have limited length so you can use this simplified routine without risking a buffer overflow? And, of course, in C/C++ you can use pointers, so maybe the best solution would be to pass pointers to those strings instead of copying their contents.
I don't think C or C++ developers realise quite how advanced Java optimisers and Java class libraries are. If you want to have limited length strings in Java, you can use char arrays:
char [] array = new char [size];
automated optimiser often knows from the source code (you can use a final ('const') value for the size) that the arrays are all within a certain limit, and it can then turn off range checking and use highly optimised machine code to handle the arrays. Just like with C and C++, there is a real advantage in Java in knowing how to write algorithms that make it explicit what the sizes of objects and arrays are, for the best optimisation.
In Java, you can pass pointers to Strings just the way as in C - in Java all object references are already pointer - but safe ones.
Optimization is like that classical joke about "girls looking for husbands and husbands looking for girls". It's not a symmetrical situation. Everything you can do to optimize Java, Ruby, Python, etc, you can also apply to C/C++, but the opposite isn't always true.
No, this is just not true; not anymore. There is something really special that Java can do for optimisation that C and C++ can't - and that is to be able to optimise at run-time for the specific processor you deploy on. With C and C++ you would have to compile for Intel 32-bit. And Intel 64-bit. And AMD 64-bit. And multicore. And PowerPC 64-bit. And Sparc and... so on (and that only deals with processors, not operating systems). With Java, the manufacturer of the processor and the OS writer work together to provide the optimisation techniques for the Java VM on their platform.
We are reaching an interesting point with VM technology - byte code translation and run-time optimisation has finally reached the performance of optimised pre-compilation. Within a decade, it will easily exceed it for almost all applications, and, although C and C++ will continue for a long time, they will be gradually related to the niche where they excel - processor-specific system coding.
That's why I don't buy those Python/Ruby/Java productivity boasts. I'd rather do it efficiently in C/C++ right now than wait for a faster CPU that may never come.
You aren't doing it (much) faster in C or C++; at least not in all cases. Even for algorithms that are routinely used to check language performance (such as Linpack) customised Java VMs equal C code. Java is not interpreted - it is translated to byte code that is then compiled into machine code with a considerable amount of run-time optimisation (with all the optimisation features that C/C++ compilers have). Considerable work is being put into similar technologies for Python and Ruby.
Processors are getting increasingly complicated, and the idea of optimising general purpose code for multi-core chips will soon look antiquated. Even now, writing general purpose high-performance portable multi-threaded code is vastly easier in Java than C or C++. The future will almost certainly be dominated by portable languages running on highly optimising VMs. and they will give high performance.
Once you've sufficiently shattered a rock, detonate a series of warheads, using their released energy to divert and/or slow down the resulting debris cloud.
It wouldn't work. The kinetic energy of many rocks that are dangerous can be phenomenal - we are talking about vastly more than the entire nuclear arsenal of the world. Shattering something into pieces is (literally) astronomically easier than diverting the mass.
Exactly. The open source model is a higher productivity model, so the black hats use it, just like everybody else that produces a lot.
A higher productivity model? Nonsense. It is no more high productivity than any other development model. Productivity depends on the development team, and their movation and interest, and the openness or otherwise of the project has little or no bearing on this. Just look at the number of open source projects stuck in permanent beta because no-one is interested in doing the hard, dull parts that are required to finish things.
Human tissues simply don't survive freezing (at least not with current freezing techniques)." is false.
It is false, and I should have worded things better - certain organs have indeed been shown to survive freezing (after all, the manage it with human embryos!).
What I mean was that no-one has yet demonstrated any technique that would allow a human brain (and all the support tissues) to survive below zero long term. I see no reason why this may not happen in the future, but my point is that to try and use current techniques is pointless - they simply aren't going to work!
Interesting, but my point still stands. Using cryonics now, when it is still certain that irreparable damage will occur, is a matter of faith, not science.
why is it that cryonics in particular is fair game for such defamatory comments?
Possibly because it requires so much faith, while claiming to be based on science. Human tissues simply don't survive freezing (at least not with current freezing techniques). It is unlikely that even a single cell in cryonically 'preserved' tissue is undamaged. Even if nanotechnology works, it is hard to think of any mechanism that would be able to identify and repair all the cells and cell organelles that would be damaged in all sorts of unpredictable ways.
This is not to say that cryonics might not work in the future, but now, it seems like a faith based on poor science.
Not at all, it's entirely implicit. As your application runs through the tests, the missing methods will raise an exception. It's no different than removing a method that exists right in the model.
This just doesn't work effectively for substantial applications (at least in my experience). You can't test all parts of all the code all the time - this effectively removes the agility of Ruby.
Database schemas don't just change at random. To do it the Rails way you even have to write a Ruby script (a migration) to upgrade the database. If you've gone to all that trouble, surely you'll be able to figure out what needs to change in the application.
Databases don't always change that way. It is a very simplistic view to consider that you will have control of all uses of the database, and will be the one who defines what happens and when. It is typical for your application to be just one of several that use a particular database. Figuring out what needs to change may be straightforward, but locating all those changes and updating the code can be a major exercise. Far simpler to is have a mapping between classes and database to allow these changes to be made in one place - the DRY approach.
No it can't. As you said you need a mapper file to map your database to your objects.
:) You are wrong.
In those ORMs that do, it can be generated for you - either from your schema or your classes. You need not touch it yourself. In many ORMs (such as JPA) you need no mapping file at all.
Once again that's precicely the point. Class generation has been around for decades now. Rails specifically didn't want to do that.
No, you are missing the point. Class generation has been indeed around for decades. But the modern approach is to define your data as classes and have schema generation (or something called 'meet in the middle', where schema and class definitions interact). Rails gets it the wrong way round - the relational database is a very poor place to define object models - this was a lesson learned decades ago (but apparently, not learned by Rails).
It's becoming obvious to me that you have never used rails or even ruby.
Nice to know you are a mindreader
In rails you can create all the mappings you want. You just do them in your class instead of an external file and you do them only if you want to rename a field. You can can even attach to different databases at runtime. For example if you have a activerecord defined as people but you have 50 databases (one for each client let's say) when you instanticate the people object you can attach to any database you want.
You are missing the point yet again. Of course, you can do all sorts of things with Rails - it is extremely easy to customise anything (that is one of the great things about Ruby). Of course you can create mappings, but this does not help, for example, suppose someone creates additional fields - your mapped classes will pick those up automatically. Your code is still vunerable to schema changes in ways that more robust ORMs aren't. As shipped, and as intended to be used, Rails is fragile.
I think you really should use the framework before making remarks about it. It's clear that you are simply talking out of your butt.
I have used it, and I have researched it in detail. I have a habit of actually researching technologies I comment on. I think you need to take a much deeper look at other technologies (especially modern JDO 2.0 implementations like Kodo, and associated tools) before posting again - you will find some awesome stuff - the ability to define queries in portable languages, and like really high performance transaction handling.
Well those types of frameworks already exist. J2EE immediately comes to mind as well as hibernate, ibatis etc. The rails people have produced an alternative to those types of frameworks because they didn't want to define something in two places (or three or four or five or sixteen). In other words it's not a bug, it's a feature.
If you don't like that feature of Rails then it's not for you but DRY is a major selling point of rails. It sounds like you would be more comfortable with J2EE.
Sorry, but this is wildly out of date. J2EE can be just as DRY as rails. Rails is competing with what J2EE was years ago, not what it is now. For example, with Hibernate and with other ORMs used with J2EE, you can generate you Java classes from a database schema (or part of that schema). However, unlike Rails, this is only done when you request it. Also, there are tools with these ORMs that allow the generation of schemas from your java classes. This is a superb feature, as it means you can automatically generate optimised schemas for just about any database without changing a single line of your code. I would claim that this is even more DRY than Rails, as not only do you define things in one place (your class files) for one database, you define them once for any future database you use. This is not the case with Rails, as use of different databases may require different column name conventions and changes.
I use this feature all the time - my code can run without change on PostgreSQL, MySQL, Oracle, SQL Server, DB2 and so on.
Your tests (you are writing tests, aren't you?) will already catch any problems that arise from changing the schema. Unless of course your production database just changes at random. In which case you've got way bigger problems.
One of the golden rules of development is that you can't predict what data people will throw at your code. However, with Rails/ActiveRecord you can't even predict what your code is! The tests you would have to write are phenomenal - you would have to check for the continued existence of every field of every class generated from database tables.
I have never used any framework where changing the schema didn't lead to all kinds of problems. Rails is actually more resilient then most because objects automatically morph with the change and with frequent use of iterators it drastically reduces the amount of code that needs to be fiddled with.
No, it is the other way around. Rails less resilient because objects automatically morph with the change. This automatic morphing is the aspect of Rails ActiveRecord that I consider to be both uncessary and dangerous. A resilient framework should be able to detect schema changes and isolate code from them, not automatically morph objects. Of course other frameworks have problems with a schema change, but at least with many of them you can detect schema changes and how they impact the rest of the code.
Surely a better approach would have been for Rails to generate Ruby source (or some other representation - even (horrors!) XML) from a schema, and then to introspect this source and the database when an application starts (or when a table is first used) in order to warn of changes. Of course, recent versions of Rails may do this, in which case I have far few objections to it.
Ah, well, in that case, you're definitely unlikely to be happy with AR :-). Well, anyhow, best of luck!
:)
Indeed
It is a shame that AR has such publicity when there are far better approaches, in Ruby, which could have been used in Rails instead, like Og.
Just do it the same way you do in every other language... execute a SQL statement.
Fortunately, that is not the way you do it in every other language. SQL is notorious for its quirks and lack of portability, and using substantial amounts of SQL is a great way to make your app highly dependent on a specific database. Other languages use alternative methods of querying or SQL-like languages that are guaranteed to be portable, and are translated to efficient optimised SQL for whichever database you happen to want to use (such as the recently standardised JDOQL and JPAQL in Java).
"> This is why most ORMs have a separate mapping layer, which protects against this."
:)
I'd submit that many web apps don't need really this layer and that, in many cases, introspecting the DB like AR does is plenty good enough.
The thing is, it leads to fragile code. Changes in a schema lead automatically to changes in code, which are potentially hard to trace, as they happen only at run time. Also, it can seriously inhibit portability, as schema changes are almost always necessary to some extent when switching between different database products.
Sorry, my opinion is that introspecting the DB (or any persistence mechanism) at run time is a seriously bad idea, for many reasons.
Anyhow, not to thrash this out too much, just wanted to make the point that AR adaptors can be written for something other than a relational DB.
I think it does need to be thrashed out
The reason is that too many are seeing Rails as some wonderful total solution to all kinds of problems, without a real critical look at its potential problems (and it does have some!).
No, hell no the EU would be defending the company stating that it has a better product and the consumers decided that.
That is not the point. The consumers may have decided that Windows on the desktop is better, but the issue is that Microsoft are using this position to make their Servers more effective because of their dominance of the desktop. In other words, other companies aren't being allowed to give the consumers full choice of servers.
Is it impossible for Linux and apple to use window Servers? Depending on which server application the answer is yes or no.
Wrong. It is not impossible, but they can't use them as effectively, as they don't know the protocols to use them as effectively.
File server, I see people around campus using macs and Linux boxen and store their files on Linux, apple, and windows servers. So Id say either someone did some serious hacking and created a custom way to write to the Windows file server from other Oss, or the EU is just lazy and doesnt want to read what is available or wants to be handed the product. Again being lazy.
Yes, someone did do some serious hacking, and as a result Linux machines can use Windows servers, and Linux servers can provide services to Windows desktops - but not nearly as effectively as if they used the full correct protocols.
Exchange, one needs an exchange client first. If someone makes a Linux exchange client, then Linux can use exchange.
No, because to use exchange effectively, you need to know the full protocols.
Clear now?
"It assumes that the database schema is the centre of the data model.
Hm, although, the folks from salesforce.com wrote a ActiveRecord adaptor to their web services. So AR may be a bit more flexible than your post indicates...
No, it isn't - not really. The issue is that your data model is determined by one source - it doesn't matter if this is a web service, or if it is a relational database.
A data model should be independent of the mechanism of persistence. You should be able to persist the same data model to web services, databases, XML and so on. ActiveRecord still says that the database is defined by the particular schema, no matter what the mechanism of persistence. This is the backward step. Your software is data-driven, not model-driven - change the data and your program breaks, and does so unpredictably. This is why most ORMs have a separate mapping layer, which protects against this.
There's no reason to assume that Rails will fail in the near term. Rails is based on a method of decomposing software functionality that does back to the 1970s (Model-View-Controller). Rails might not be here forever, but it has a very solid architectural foundation and it is easy to adapt it to the latest trends (for instance, you can create AJAX-based Web applications very easily with RoR). In other words, the extensibility and architecure of Rails make it adaptable, just as you mention Ruby being adaptable.
.NET that allows querying and persistence to almost anything including in-memory objects. ActiveRecord is a very neat implementation of a very old-fashioned approach.
This may be true, but Rails is also based on an approach to object-relational mapping (Active Record) that is not widely used and with only limited applicability. It assumes that the database schema is the centre of the data model. This is a very narrow view of data. Increasingly data comes from other sources than relational databases. To see how sophisticated this can get look at Xcalia - a Java product that can persist and retrieve data from just about anything - LDAP, XML, Databases - even SOAP services. Although I am no Microsoft fan, they are heading the right way with their new LINQ persistence system on
This is just getting stupid.
M$ is getting F'd in the A because they built an o/s that a business 'chooses' to use. That business wants to get additional software that integrates with their servers as smooth as possible. Business chooses M$ software because it smoother than the competition (and not by much I must add).
I really don't understand???? Whats the problem here?
Because of something called a 'monopoly'. Microsoft have overwhelming dominance on the desktop. They are using that dominance to sell servers, which is a separate market. Using monopoly dominance in one market to influence sales in another is illegal.
Microsoft server software integrates more smoothly than the competition with their desktop systems because their desktop systems require specific protocols for this integration which Microsoft are keeping secret. Other systems have managed to replicate this only by reverse-engineering what is seen to go across networks.
Microsoft could easily have provided good integration with desktop systems using standard or existing protocols (they have proved in the past that they can produce quality implementations of such things).
None of this would matter if Microsoft were not effectively a monopoly presence on the desktop (that does not mean total dominance - it means enough presence to seriously influence other markets).
Clear now?
First, let me say that you seem to have a tendency to respond to what you think I wrote, not what I actually did.
I have never said that no apps ever break with JRE upgrades, or that you never need to test things with different JREs
What I have actually said is that issues with JRE updates are rare. Java is one of the most backward-compatible systems ever produced. Nothing you have said and no links you have provided have demonstrated otherwise. You seem to be considering matters of how to access JREs or how to package applets as if they were somehow related to the Java language and compatibility. They aren't. You have provided a very minor list of issues that may occur when people upgrade from Java 1.3 (released 6 years ago!) with Java 1.5. That minor list simply emphasises how few programs are going to break, and the minor matters involved.
I realise you are not in a position to give a personal example, but that does not help the debate. Until you can give some specific reason, I can't see any point in continuing.
If anything, this conversation has helped prove my point - that the suggestion made by a poster a while back that 'all your old aplications do not work at all anymore when users install the new JRE' is utter nonsense. (note the use of the word 'all' - not 'some', or 'a very few', but 'all'!).
It it is so obviously nonsense that I can't see why anyone is bothering to argue against it.
The GP complained that he'd seen Java apps break. You said you hadn't and that you couldn't imagine more complex apps. You were definitely implying he was a liar. This isn't a court of law so burdens of proof don't apply here. To me your intent was very clear.
5 31
No, I was clearly saying that complex apps obviously don't break with version changes.
In your latest post again you insist that because you haven't in your very limited experience seen Java apps break, that it's rare. It's not.
Yes, a very limited experience based on being a developer for 30 years and using Java since it came out.
You get such links as:
http://developer.apple.com/qa/qa2006/qa1474.html
http://forums.macosxhints.com/showthread.php?t=47
That's just the tip of the iceberg and I'm not going to do any more work proving that things have broken because with your attitude I don't see you admitting to a mistake.
Oh for goodness sake! This suggests that you really don't understand the issue! Those links you showed aren't the 'tip of the iceberg' - they are most of it. Of course things wont work if you compile specifically for a later version of the JRE and then expect it to run on them. That is a crazy as expecting an app compiled for MacOS/X to run on Mac OS 7!
This is not an issue of JRE upgrates breaking existing apps - it is an issue of using a JDK upgrade and not taking into account the fact that the compiler produces code for the equivalent JRE. There is nothing wrong with than, and a simple switch can change this.
Guess what happens if you use any 3rd party product that is in any way incompatible. You need to get another version of that product.
Only if that 3rd party product relies on a later JRE or JDK, in which case it is entirely reasonable.
Now you're obviously not interested in reality. In your mind because you haven't had the displeasure of working on something that's been badly broken by a JRE release all is good. Enjoy living your fantasy but don't force it down other people's throats or belittle them when they point out that they've seen it happen.
I haven't worked on something that has been badly broken by a JRE release, because few people have. You haven't shown any such thing. All you have shown what happens if someone compiles for a later JRE and tries to run it on an earlier one. Do you seriously expect all your clients to automatically upgrade to JRE 1.5? Of course not. It is your responsibility as a developer to take into account the versions of runtimes your clients use. If you update your compiler (javac), it is your fault if things break.
Talk about the pot calling the kettle black. You called the GP a liar because his experience didn't match yours. How dare you then come back and point the finger at someone making assumptions you hypocrite!
/. stupidity never ceases to amaze me.
No, I did not call the GP a liar. I am careful with wording.
Well I have. "It works for me on my machine so stuff you" is nonesense that no professional should be uttering, let alone calling a perfect stranger a liar because they've seen something you haven't.
Again, I did not call him a liar.
Explain my experience then. I'm either lying (and I happen to know for a fact that I'm not, and would gladly prove it if it didn't require breaking my contract and if I thought it would sway you one bit).
Then why are you bothering posting if you can't prove it? I am not saying you are lying. It is certainly possible to write apps that break from one JRE to another, but it is also pretty simple to ensure they don't - the release period between JREs are long, and the guidelines are clear. But if you can't provide actual evidence, what is the point?
JBoss and Netbeans are just two technologies. Most of my experience happens to be with Eclipse though I have used Netbeans, and Weblogic though I've also used Tomcat and JBoss. So what. There are more technologies out there that neither of us have used than you could shake a stick at and to make the assumption that no applications have broken just because you haven't seen it is both arrogant and ignorant.
They aren't just two technologies - they are illustrations of a wide range of aspects of the JRE - GUI, multithreading, file handling, networking, concurrency. If anything should break between releases, these should.
I did, of course, not say that no applications have broken. I said I have not seen any that have broken, and this includes very complex apps.
What do you do when your users complain there's a bug you can't reproduce? Shut your eyes, put your hands over your ears and shout "la la la la la" at the top of your voice?
I fix the bugs. I deal with them. I write my apps and test them on different JREs. To write an app so tied in to one JRE that it breaks on a new one is, these days, inexcusable and a sign of bad development practice. If Tomcat and NetBeans can manage for this not to happen, so can everyone else. There has rarely been a technology that is so backwards compatible as Java.
Well you've obviously never written anything in a complex Java environment. I've seen apps I've worked on break in 1.5 where they worked fine in 1.4.2_08. This caused our team huge headaches because it was an applet problem that had already been installed on a lot of client machines, some external to the organisation I worked for.
It is great the way that posters assume things! I work on substantial Java applications daily - apps with hundreds of thousands of lines of code.
There are very complex Java applications that run unchanged on different versions of Java - JBoss, NetBeans for example. These are app servers and IDEs - it is hard to think of apps that are more complex. I have never seen a single app break between Java 1.4 and 1.5.
GCC did not even come close to implementing the C++ standard until 3.2 - Your program was not C++, it was implemented in the C++-like dialect that earlier versions of g++ implemented.
This is often the case for pre-standard C++ programs.
(1) It was indeed C++.
(2) This has been an issue with C/C++ - compilers that are allowed to label themselves as C/C++ that aren't compatible. This is not the case with Java.
... until Sun relases a new JRE and all your old aplications do not work at all anymore when users install the new JRE. Unmaintained applications die altogether or require constantly uninstalling and installing various JREs to run them as well as new ones. That's the biggest bug of all in Java and makes any bug tracking useless, and programming in Java pointless.
C/C++ applications tend to work for decades and can be written to be far more reliably cross-platform.
Odd. I have found exactly the opposite. Java is very well know for the excellence of its backward compatibility, and to say 'all your old applications don't work anymore' is just plain false. Java would not have had the huge success it has had if this were not the case, so your statement is plainly wrong.
On the other hand, C/C++ version bugs are well known and well documented - just think of the issues involved with gcc versions and linux kernel compilations. I have a very simple C++ app that compiled and ran fine on one version of gcc, but broke on another.
If you simply exchange C/C++ for Java, and vice versa, throughout your post, it then makes sense.