If I'm teaching someone to program, I want them to learn to appreciate useful, general concepts like modular design, or the nature of an expression, or the effective use of functions, or structured programming.
Understood.
OOP, ultimately, is just syntactic sugar for a particular style of procedural programming, a specific application of these general principles.
No, it isn't. It is far more than just syntactic sugar, introducing ideas such as polymorphism which are fundamental to a the power of OOP development.
I think that presenting OOP as The One Truth, which you do at least implicitly if you start by teaching a language such as Java or Ruby, is doing your students a disservice.
I understand this point, but I would suggest it is far better to introduce what OOP can really do right at the start rather than as some kind of later confusing 'add-on' to procedural code, which OOP certainly is not, and OOP used this way is poorly used.
Teaching OOP is no barrier to the teaching of modular design or structured programming - they are orthogonal concepts.
I am a great believer in the use of 'pure' languages to teach concepts - Pascal for structured programming, Smalltalk for OOP, Prolog etc. for declarative development, and then you can introduce 'compromise' languages like Java and C++.
If you can't think about what the machine is actually doing, you will never be as good at programming and especially debugging as someone who can. The abstractions that you trust with your program's life will fail you in the end. Then what do you do?
How on Earth is understanding assembly supposed to help with this? It is of no relevance at all. You might as well suggest that developers deal with processor microcode. Some of the worst developers are those who won't abstract and insist on handling things at the lowest levels, and won't let the compiler or runtime system do the work for them. I have not developed with a system where I have needed to know about the underlying assembler for about a decade.
If you have never fiddled with pointers in memory, then you will be confounded by the differences between:
This has nothing whatever to do with assembly. It is to do with abstractions about memory use, and can be understood in a totally abstract fashion.
And heaven forbid that you ever get anywhere near any security-critical code.
Fortunately development these days is moving away from the use of languages with the sort of horrors you showed above and towards safer managed systems.
You can make a Java app a complete pig if you have no inkling of what's going on behind the scenes, and that's why most Java apps suck. They're not coded by people who use the features of Java, etc. as a tool, they're coded by people who use those features as a crutch. Start 'em off with BASIC, show them some C++ so they can get results, ASM so they know what's going on at machine level, and then onto the OO design for big programs. OOP really isn't useful until you hit the big, GUI programs anyway.
This has to be one of the most old-fashioned views I have read for quite a while. The time when you needed to 'get behind the scenes' and know what was going on at the ASM level has long gone, and the comment that 'most Java apps suck' is no relevance for a reasoned debate. Anyone with a modern understanding of software design understands that safety, security and automated memory handling aren't a crutch, but a major step forward in the quality of software production. These days they are no barrier to efficiency or performance.
The idea that OOP isn't really useful until you hit big GUI programs went out of date decades ago - OOP is a fundamental technique that can be used at even the smallest level efficiently. To suggest that it is only for GUI and only for large scale is to completely misrepresent what it is for and how it can help software design.
Of course, I could be reading things wrong, and this post is some sort of ironic joke - a parody of how to teach software?
Once they get to the point where they start prefixing every function with a module name, then its time to introduce them to OOP and Java.
I disagree. This is the wrong way to introduce OOP, as it treats it as some sort of high level way of managing code rather than as a fundamental technique that can be used at all levels. My view is that the best way is to teach something like Smalltalk or Ruby initially in a procedural style, and then show that everything in the language is an object, with methods and properties. Then, perhaps, the compromises made in a language like Java can be explained. One thing that should definitely be avoided is C - for goodness sake teach a safe language like Pascal instead. Beginners should not be dealing with pointers to memory (most developers never need to anyway).
OOP needs to be taught at the start, not as an optional add-on.
I'll troll back. After you wait the obligatory 90 minutes for the IDE to load on your dual core PC with 4 gigs of ram.
Yes, you sure are trolling. Of course, it is nothing like this.
I was not trolling.
And after you generate the app, it's a beautiful thing to behold! 80k worth of code to maintain for a single form with an additional 15 xml files to store the configurations and data mappings, and proprietary HTML elements and tag specific to the java world....
Nothing like being ignorant is there? There are, of course, no proprietary HTML tag elements (how could there possibly be?) only a few lines of code, and only 2 xml files. If you are going to argue, it is best to know what you are talking about. You are showing laughable igornance here.
Several other aspects, such as table creation, column types, auto-increment variables, and stored procedures, have varying degrees of differences or support between the various databases such that in any sufficiently complex application you would need to write a separate copy of db interface code for every DBMS that you want to support.
There are open (and closed) source products that have dealt with these issues for years. Modern ORMs products handle all of these matters, and automatically provide translation between portable query languages (such as JDOQL) and high-performance vendor-specific SQL depending on the database you deploy on.
It is astonishing to see these matters still being discussed as if no solution exists!
With Java Studio Creator, I can create a data-linked web application (with full MVC structure) in seconds using the visual design tool. And, I have full code-browsing, debugging and refactoring tools.
I'm sorry but when did "consensus" become a standard for scientific truth? Truth in science, has often come at the expense of breaking with consensus. And along those lines, science has been led down the wrong roads many times because scientists were trying to marry their data with the agreed "scientific consensus" of their time.
In practice, consensus has become a very useful standard for scientific usefulness most of the time. We all use Newton's theories all the time, even though they have been subsequently refined.
We know that CO2 causes global warming - there is no doubt. Some fine details may need to be sorted out, but that is all.
For a more developed argument, please see Crichton's Aliens Cause Global Warming paper for the explosive and decisive attack against the method of scrutinizing scientific truth which you just proposed.
Yes, let's pick a single science fiction author (and a bad one at that) with absolutely no qualifications in the subject as a source for 'developed argument'.
But what's your point? When using native bindings to C libraries, they act just like other perl modules. It's the same reason we don't use native perl database drivers as well. I don't see how using C bindings in modules is an argument against using the language. Perl was written in C as well, after all.
Because it is a mess when you have to do it yourself. You are having to support two languages in your project - two sets of compilers, two types of debugger, and you are having to package additional libraries with your code. All this is uncessary if you find a fast enough language.
So what you're saying is that the ORM layer groks the foreign keys from the object models and places the constraints on the database when it is available as a feature.
Exactly.
Go read your logs show me this magic SQL and the joins you're talking about and the functions as well.. I'll believe that they exist when I see them.. I've been developing web applications for a long time; I must have missed out on all this special tech.
OK. However, this is not 'magic SQL' or 'special tech' - this are features that should be well-known to experienced database developers. Things like using sub-queries in some databases where they are allowed (Oracle), using vendor-specific sql functions (e.g. 'decode' in Oracle) and coding specific join types that are optimised for specific databases.
Let me emphasise - with a good Java ORM, you don't have to be a database expert to get these optimisations - you get them automatically because the ORM developer knows when they can be used and produces optimised SQL from your portable query. You can get this in Java because there are standards for ORMs, and database vendors can compete to provide optimal implementations (like Oracle and TopLink). You aren't forced to resort to some sub-standard subset of SQL as with Rails.
This is not bad, but once again, you can't rely on those keys for data validation in your application unless you know that all of your development/deployment systems have this ability.
You aren't requiring this for validation in your application - it is adding safety (and efficiency) in certain deployment situations. You aren't relying on them in, say, an embedded test database as you don't need them there. You can rely on them in situations where they are appropriate - multi-user databases where other applications may share the data store.
And, again, you don't need to specify these manually in your database. The ORM can generate them for you.
You're right, the domain model resides inside the database. That is its purpose and the reason it is relational. Maybe this is a difference of philosophy.
It is, and it is an old-fashioned and very restrictive philosophy. I assumed that most development had moved to OOP and flexibility, from the relational model that was commonplace in the 80s. It seems Rails wants to step back decades! With my JDO java ORM I can persist the same truly object-oriented model to high-performance relational stores, hierarchical XML or even CSV. Even better, I can allow the user of my application to choose. I can say 'here is my application - you pick the database'. And I get the full features of a portable query language no matter what store - I can run complex queries on CSV files! It may not be efficient, but I can do it - and for small volumes of data that is incredibly powerful.
Any less flexibility seems primitive to me; because it is primitive.
I honestly believe that a lot of Rails supporters really haven't investigated what modern Java ORMs can do. If they did, they would demand far more of Rails. I really don't understand why they put up with so little.
If you define in your model that you have foreign keys but you deploy to sqlite, you don't have foreign keys. That is a trade off for any application in any framework. Therefore if sqlite is your deployment database your application has to decide that you can't rely on features not implemented in sqlite. This is what I meant. These are decisions made when the application is planned.
You are missing the point. You don't need to make these decisions, or if you do make them, you don't need to make them once and for all for all deployments.
For example, you may have test datasets that don't need constraints as you are the only one using them. But, for the real deployment (which may be a multi-user and multi-app environment) you get the constraints for free that protect your data.
If you're saying that you will just define the maximum set of features and then the database tool will skip the ones that aren't available in one database when deploying to it, and will use them on deployment to another database, then fine. But that is simply a waste of your time.
I didn't say that, as this is not how things work. Imagine that the ORM is like an optimising compiler that analyses the database and produces the best SQL given the particular database. Sort of like compiling automatically with 64-bit instructions on a 64-bit processor if you are running on one.
The only way you could ever have an application that relies on sophisticated database features in a deployment environment is to also have those features available for you in your testing and development environment.
No, not true. There may be (and are) particular functions or ways of doing joins etc. that are available on one database but not on another. You don't need these around at testing - the ORM will automatically use them if you select that database. No testing or use in development environment required.
Also, what features are we even talking about? The only possible feature I could think of is foriegn keys and user defined data types since that is something that can be represented in a model. Everything else an ORM does is select, update, insert, and delete in very standard ways.
No, it doesn't. It can use highly specific optimisations (types of joins, specific functions available in specific database products etc.) to produce very highly tuned queries. And it can do this automatically.
All of these other 'features' like views, triggers, stored procedures, indices, caching etc. are indepedent of the queries or frameworks that you use and are carried out by the database and not implemented in any model objects.
No, you are wrong again. Views and triggers are database-specific, but indices and cacheing can be very finely controlled by the ORM automatically based on analysis of your object model. They can, in some systems, even be implemented directly in model objects via annotations.
I know for a fact ORMs like Hibernate simply write normal SQL queries even if they have to translate them from special query languages like HQL.
No, you are wrong again. They can produce not only very vendor-specific SQL (not 'normal' queries), but systems like JDO don't even need to use SQL - they can use a very wide range of persistence mechanisms - object database, SOAP, XML, CSV, file systems, LDAP.
All of the special options that you put in hibernate models merely tell it how to form the SQL and which other models to join or save when performing different operations.
That is Hibernate. Java ORMs consist of far more than Hiberbate - there are many systems that are far more efficient and far more powerful.
We use functional, unit, and integration tests with fixtures.
You can use as much of these as you like, but they don't hide the fact that your data model simply doesn't exist away from the database, and even worse, if you (or someone else) changes the database, your data classes change. Testing is simply papering over this design flaw of Rails.
Why does you not being the only user of the database mean that foreign key constraints have to be kept in the database? Foreign keys don't somehow make your colleagues better developers..:)
No, but it makes sure they can't screw up your data.
So which is it? Are we generating models from databases or databases from models?
Both. Depends on the circumstances. Which is why most Java ORMs have 'meet in the middle' schema handling where your requirements can match the constraints of existing schema information.
Once again the java ORM can't generate foriegn keys in sqlite or other databases that don't support them. This has the possibility of leaving your database schema inconsistent between database vendors and if you were relying on foriegn keys for any type of data validation then your entire application is going to be inconsistent. The solution is simple, don't rely on foreign keys. Relying on foreign keys actually places you closer to your database implementation and not further away from it, which you argued earlier is what you don't want. Also use of foreign keys doesn't allow for rich features like polymorphic associations.
Of course your application need not be inconsistent.
Having this flexiblity in Java ORMs allows you to develop and run test cases on lighter databases - perhaps without foreign keys, and then deply on more robust databases in a multi-user, multi-application environment with foreign keys. It is a powerful and simple facility that gives your code flexibility and robustness.
If database portability is a major concern for the application then you have to pick the set of features for some set of databases that you want your application to be portable across and only use features from those databases. Like I said, java has made this tradeoff, but it has only worried about db2, sql server, and oracle.
No, you are wrong. You don't have to pick a set of features with a Java ORM - you get the full set of features for the database you deploy on automatically. There is no tradeoff, and to say there is is to misunderstand how well Java systems work.
In the case where you make your database first and then generate your object models, well then rails is much better at this than any java ORM mainly because of the strong run-time reflection that ruby allows.
No. The issue of using run-time reflection is irrelevant to where you define your model. Java can easily work with definitions in the database as the place where the model is defined. But anyway, run-time reflection seems cool but has major disadvantages, such as the inability to test parts of the code away from the database. It also makes your code potentially highly fragile - your code is succeptible to run-time changes in the schema by other code or other users.
Rails prefers to keep this information at the ruby level right now using the has_many, belongs_to, etc. modifiers in the models.
Yes, because that is easy to support. However for a significant number of situations, you aren't the only only user of the database, and such relationships have to be put and kept in the database. More mature ORMs than Rails handle this.
SQL-99 has been supported by all database vendors for years.
No, it hasn't. Neither Oracle, Microsoft or IBM fully support SQL 99. They support different parts of the core standard.
If you are using the 'full power' features that are available in one database that aren't available in another no amount of magic database tools are going to make the features available.
Sorry, you are flat wrong about this. Quality Java ORM systems will automatically make use of the full features of specific databases in order to provide optimum efficiency in querying - as a developer you don't have to put work in to get this. If you have a complex object query, vendor-specific features will be used to make that query work fast. However, if you port exactly the same object query code to another database, it will use different vendor features automatically.
Can you now see why I think Rails is primitive?
The only thing that is not included in the ORM is automatically forming object relations from foriegn keys without having to explicity tell the model about it. But you can't do that in java either, you have to tell the models about their foriegn key relationships even when they are specified in the database already.
No, you don't. Most quality Java ORMs have features to generate object models from databases.
But you are missing the point. The way I work is to develop my object model in one place only - Java classes. The ORM will automatically generate foreign keys in whatever database I choose when it generates the schema to represent my classes. If I pick another vendor's database and switch to that, it does this for me again. It is the DRY principle that Rails is supposed to represent! I specify (and change) things in one place - my object model.
ther than that the ORM (ActiveRecord) writes the same standard SQL-99 for select, update, delete, insert, count, etc. as any ORM would write from its models in java or otherwise; nothing special is required at this layer.
As indicated above, you are wrong. There are ORMs that are far more mature and capable than Rails, and that will automatically go beyond SQL-99 and use powerful features of specific databases to get performance.
My view is that trying to use some sort of common portable subset of SQL-99 is a cop-out, which would be considered a very poor solution in any other situation. I would imagine a database manager who had purchased Oracle or DB2 would be somewhat disappointed if you weren't using the latest features of that database in order to get performance. Sure, you can do that with Rails, but at the cost of losing portability. With a good Java ORM you can do that automatically, and you don't lose portability.
So the question is where do you draw the line with the features you expect to be portable amongst all of your database implementations and where should your database tools draw the line? For rails the line is drawn at sqlite which has a very small feature set compared to other databases.
Indeed, and this seems very poor to me. Sorry, but this seems typical of the Rails approach - implement only a little, then claim that is this 'all you need'.
Does java even write things like views for you? This would seem a bit over the top and unecessary.
No - the idea of Java ORMs is to write things that relate to the object model, and are required to keep that object model valid and consistent (constrains, foreign keys etc.). If there are view and triggers etc, those are the result of some other use of the same data store, and are not relevant to the Java code (although Java ORMs can easily make use of views and stored procedures).
I've run the same non-trivial Rails app on three different database products (MySQL on the old Web host, PostgresQL on the new host, and SQLite locally) with minimal headaches -- just migrate the data, tweak a config-file setting, and It Just Works (tm).
Right. Add a foreign key constraint to the PostgreSQL version. Show me an automatic migration of that to the others. Add a couple of 'text' columns to the PostgreSQL version. Show me an automatic migration to Oracle.
Actually all of these database problems are solved by Migration in ruby on rails. Not only do they allow you a database agnostic representation of your database schema defined purely in ruby (for sql server, mysql, sqlite, db2, oracle, postgres). They also give you schema versioning capabilities that tie into your deployment tasks if you're using switchtower.
No, these problem aren't solved. Look at the schema migration documentation. There are significant things that aren't migrated - 'minor' things like foreign keys!
Why should I put up with a half-working Rails version when my Java ORM allows me to port things in seconds? In fact the more interesting question is - why to Ruby on Rails users put up with such poor quality products?
I also find the idea of having to write my queries in a specialized 'portable' query language pretty annoying.
Why?
If you use standard SQL it is portable anyhow and adding one more level of indirection so I can do the same thing is, not too bright. But with migrations you don't have to worry about any of that anyway.
This is false in almost every respect. Standard SQL is not and has never been portable - migrations between, say SQL Server and DB2 are a nightmare in terms of SQL. Some small subset may be roughly portable, but if you use this subset, you aren't using the full power of the databse.
Secondly, the migrations don't port the SQL you are using, do you do have to worry about this.
We did have to resort to a few native queries to work around it however.
The thing is, I have dealt with small projects that soon grew to substantial ones, with hundreds of thousands of lines, and hundreds of native queries!
For me, the best insurance is an agile language that lets me quickly respond to change, and that lets me get to the heart of a problem without having to pile up gobs of scaffolding and configuration code.
This is an area where Java is changing fast. The era of huge amounts of scaffolding and configuration is going.
To give an example - I don't use configuration at all: All the information about my schema is in my Java classes, with a few Annotations. I can generate my schema from the se classes with the click of a mouse, or via a single Ant task.
There are great new systems for Java like Seam, that allows both the web presentation and the schema to all be generated and controlled from just a few annotated classes!
The idea (often promoted by Rails supporters) that Java has to be swamped by configuration is way out of date.
Part of this may be personal preference however. I enjoy programming in Ruby more, for reasons beyond productivity, and therefor am able to stay focused longer. Ruby just jives with me I suppose. I like the way it works -- it's very intuitive to me.
I hope you continue to enjoy it!
However, I still think there are huge benefits to the type-safe approach. Given a 100,000-line project, how long would it take you to find all usages of a particular column name from a table? With my approach, I can find this out in seconds. Because (unlike with Rails) I have a mapping structure (via the Annotations in my data model classes), my code is isolated from many changes in the schema.
Java fairs better than C here, but why hobble the productivity of my entire project by using static language for everything when only 1% of it is performance critical code?
Because it is a myth that it hobbles productivity, or at least a strongly debated point. The productivity issue of static vs dynamic languages has been a matter of strong debate for decades, with no side winning! This is an extremely complex matter.
At their core, most web apps do little more than move around data. Why not use a language that's well suited to this sort of task?
Because Ruby isn't suited to this for some types of data. And then you have to either rely on someone else's beta-level library for your commercial site or drop down to Java or C yourself. Then you have lost the supposed productivity benefits of using a simple language.
Sure, you can't just pull out your database and replace it with LDAP with a simple configuration change but, in my experience at least, these sorts of requirements just don't come up very often,
You would be surprised! Of course, the issue is that when they do come up, you are really at a loss with Rails. I consider portability a very valuable form of insurance.
Trying to track all uses of a table or column in a large project written in a dynamic language isn't always easy (I have never found it so).
and the products that do support such things tend do so at the expense of something more important. All that abstraction doesn't count for much if I'm left high and dry when I have to do bulk update or sum(), or if I'm going to have to spend the rest of my life setting the thing up.
I think you should take a look at some products like Kodo. They simply don't give you portability at the expense of anything else. With APIs like JDO 2.0 and EJB 3.0 I can do operations like sum() with a single line of portable query language just like with SQL. With a good product like Kodo I can easily do bulk updates with very high performance using ORM, with almost no additional work needed for tuning. It is very easy.
There is this common belief that you need to be close to the database for efficiency - efficiency is counter to portability. This is just not true anymore. My app handles millions of records and I can switch my it between PostgreSQL, Oracle or MySQL in seconds.
However, as much as I'd like to believe otherwise, I don't, in fact, know everything, and I'd be interested in hearing about your experiences. Have you had problems with Rails in this area? What was the situation?
Not specifically with Rails, but with similar approaches, over many years (since the 80s!). One of the most recent examples was a website that I was supporting that was developed years ago in an interpreted language - Cold Fusion. Not only was this website slow, but it included code that was highly specific to the underlying Microsoft database that was providing information for the site. Of course, eventually, under the load of increasing complexity and demand the site collapsed. It was then my task to re-code the entire thing for higher performance. At the time, I used JSPs as I could quickly port Cold Fusion pages to JSP. JSP gets translated to Java code, then compiled on demand so could provide much higher performance. The problem was made a lot worse because of the closeness of the code to the underlying database. We did not have a Microsoft host for the site, so it had to be ported to a non-MS datastore. I resolved never to tie a website to a specific database again, and I fixed this issue by using a Java standard ORM system - JDO. This meant I could deploy with trivial changes to PostgreSQL, MySQL even Oracle or a dozen others. The site has been up since and has dealt with hugely greater loads and demands (such as high-volume transactions to update the information).
Another recent example was when a colleague, against my advice, decided to use highly vendor-specific SQL to implement a website instead of a portable system - JDO or Hibernate. It turned out that all his development for a modern version of PostgreSQL under Windows was wasted because the hosting system was a rather older version of RedHat, and we did not have the option of installing newer versions of the database. The only practical database for use on that host was a somwehat out-of-date version of MySQL. Now, if he had used a portable ORM, this would have been a trivial matter. Instead it took weeks of work.
So, my experience that that portability can be a real problem, and even worse - you can't predict when it will be an issue!
Now I develop using a high-performance Java ORM - Kodo. This works fine both for simple tasks and very large batch operations. Even better, there is the option for automated clustering and cacheing as my website grows. There are nice open-source ORMs like JPOX and Hibernate that offer the same capabilities, if not quite the same performance.
Most of yahoo is written in PHP. Microsoft.com was, last I checked, uncomplied, pre.NET ASP. Google uses Python for most of it's applications. Slashdot uses Perl. Penny Arcade, A List Apart, 43Things, and all the 37 Signals sites use Ruby.
No, you are wrong. Most of Yahoo is not written in PHP, and Google does not use Python for most of its applications. They use these languages for some aspects of their sites, but increasingly pass of 'heavy lifting' to higher performance systems based on J2EE and C/C++.
Using a language does not mean that that a site only or primarily uses the language for everything. Major sites may have the time and resources to manage complex mixed-language development. Small developers don't.
All of these sites receive 1000x more traffic than Gary's Auto Repair ever will, and yet they're holding up just fine, despite being written in relatively poorly performing languages.
Factually incorrect. They use higher performance languages where necessary, and they have the money and resources to scale parts of the site by simply throwing more hardware at things. If you suggest to a small-scale customer that they can deal with occasional high demand by stringing together machines you will be shown the door pretty quickly - saying that a you are dealing with a 'cool new development system' is no excuse for inefficiency.
Language performance simply isn't much of a factor for the vast majority of web apps, where the bottleneck is almost always in the database.
Why not respond to the point made in a post? Have you actually tried handling a significant volume of XML in Ruby or Perl (and I mean in the language, not passing stuff off to a C library)? Have you tried doing something like image management (often a requirement of content managemenent sites) purely in these languages?
Besides, Rails is not only very young, but it works fine, performance-wise, for 75% of the business sites that need database support. You wouldn't use it for Amazon.com, but it might work fine for Gary's Auto Repair's business site, which is the sort of thing most free-lance developers are doing in their spare time.
I have heard this sort of false statement so often!
Sorry, but this kind of thing does not work fine for these sites. They may work find for these sort of sites most of the time, but what generally happens is that sooner or later the site will have a burst of high demand, or some additional functionality will be added which requires extra processing (transferring masses of updates to the site by a SOAP service, for example), and the either site collapses, or loses you friends when your site takes up all the CPU on a multi-site machine! Then what happens is the site is re-written and re-hosted in a faster, more established technology, and the expensed saved by using the cool new technology is lost.
I have seen this happen far too often, (but as I am paid to clean up the results, why should I complain?).
I'm overwhelmed by your citation of sources and real-world examples proving your claim of Ruby's slowness!
It is an interpreted language without even a native code translator (at least not one that is out of early beta).
If you would like to explain how that is supposed to be fast , I would be very interested..... Unless, of course, compiler writers have been wasting their time for the past 50 years.
So, you think reinventing the wheel when it comes to GUI is a great idea? One database, one platform independent GUI - sounds perfect to me,
How does reinventing the GUI wheel come into it? If anything is providing yet another re-invented GUI it is Rails. And, having platform independent GUI but producing code that can be very fragile if you attempt to migrate between different database products (or even if someone else radically changes your schema) sounds plain nuts to me.
And now with Ruby-On-Rails being a killerapp for forward looking web designers
No - it is a killer app for getting mentions on Slashdot.
Having a development system with the relative lack of performance of Ruby, and the very close tie-in to the database and schema of Rails is more of a website killer than an killer app, I am afraid to report.
Slashdot Mirror
If I'm teaching someone to program, I want them to learn to appreciate useful, general concepts like modular design, or the nature of an expression, or the effective use of functions, or structured programming.
Understood.
OOP, ultimately, is just syntactic sugar for a particular style of procedural programming, a specific application of these general principles.
No, it isn't. It is far more than just syntactic sugar, introducing ideas such as polymorphism which are fundamental to a the power of OOP development.
I think that presenting OOP as The One Truth, which you do at least implicitly if you start by teaching a language such as Java or Ruby, is doing your students a disservice.
I understand this point, but I would suggest it is far better to introduce what OOP can really do right at the start rather than as some kind of later confusing 'add-on' to procedural code, which OOP certainly is not, and OOP used this way is poorly used.
Teaching OOP is no barrier to the teaching of modular design or structured programming - they are orthogonal concepts.
I am a great believer in the use of 'pure' languages to teach concepts - Pascal for structured programming, Smalltalk for OOP, Prolog etc. for declarative development, and then you can introduce 'compromise' languages like Java and C++.
If you can't think about what the machine is actually doing, you will never be as good at programming and especially debugging as someone who can. The abstractions that you trust with your program's life will fail you in the end. Then what do you do?
How on Earth is understanding assembly supposed to help with this? It is of no relevance at all. You might as well suggest that developers deal with processor microcode. Some of the worst developers are those who won't abstract and insist on handling things at the lowest levels, and won't let the compiler or runtime system do the work for them. I have not developed with a system where I have needed to know about the underlying assembler for about a decade.
If you have never fiddled with pointers in memory, then you will be confounded by the differences between:
foo(bar baz);
foo(bar* baz);
foo(bar*& baz);
foo(bar& baz);
This has nothing whatever to do with assembly. It is to do with abstractions about memory use, and can be understood in a totally abstract fashion.
And heaven forbid that you ever get anywhere near any security-critical code.
Fortunately development these days is moving away from the use of languages with the sort of horrors you showed above and towards safer managed systems.
You can make a Java app a complete pig if you have no inkling of what's going on behind the scenes, and that's why most Java apps suck. They're not coded by people who use the features of Java, etc. as a tool, they're coded by people who use those features as a crutch. Start 'em off with BASIC, show them some C++ so they can get results, ASM so they know what's going on at machine level, and then onto the OO design for big programs. OOP really isn't useful until you hit the big, GUI programs anyway.
This has to be one of the most old-fashioned views I have read for quite a while. The time when you needed to 'get behind the scenes' and know what was going on at the ASM level has long gone, and the comment that 'most Java apps suck' is no relevance for a reasoned debate. Anyone with a modern understanding of software design understands that safety, security and automated memory handling aren't a crutch, but a major step forward in the quality of software production. These days they are no barrier to efficiency or performance.
The idea that OOP isn't really useful until you hit big GUI programs went out of date decades ago - OOP is a fundamental technique that can be used at even the smallest level efficiently. To suggest that it is only for GUI and only for large scale is to completely misrepresent what it is for and how it can help software design.
Of course, I could be reading things wrong, and this post is some sort of ironic joke - a parody of how to teach software?
Once they get to the point where they start prefixing every function with a module name, then its time to introduce them to OOP and Java.
I disagree. This is the wrong way to introduce OOP, as it treats it as some sort of high level way of managing code rather than as a fundamental technique that can be used at all levels. My view is that the best way is to teach something like Smalltalk or Ruby initially in a procedural style, and then show that everything in the language is an object, with methods and properties. Then, perhaps, the compromises made in a language like Java can be explained. One thing that should definitely be avoided is C - for goodness sake teach a safe language like Pascal instead. Beginners should not be dealing with pointers to memory (most developers never need to anyway).
OOP needs to be taught at the start, not as an optional add-on.
Can I hire you? My company specializes in 1 minute solutions. You'll get your full one minute worth of pay in advance. Thank you.
Why bother - you can download Studio Creator for free and do it yourself.
I'll troll back. After you wait the obligatory 90 minutes for the IDE to load on your dual core PC with 4 gigs of ram.
Yes, you sure are trolling. Of course, it is nothing like this.
I was not trolling.
And after you generate the app, it's a beautiful thing to behold! 80k worth of code to maintain for a single form with an additional 15 xml files to store the configurations and data mappings, and proprietary HTML elements and tag specific to the java world....
Nothing like being ignorant is there? There are, of course, no proprietary HTML tag elements (how could there possibly be?) only a few lines of code, and only 2 xml files. If you are going to argue, it is best to know what you are talking about. You are showing laughable igornance here.
Several other aspects, such as table creation, column types, auto-increment variables, and stored procedures, have varying degrees of differences or support between the various databases such that in any sufficiently complex application you would need to write a separate copy of db interface code for every DBMS that you want to support.
There are open (and closed) source products that have dealt with these issues for years. Modern ORMs products handle all of these matters, and automatically provide translation between portable query languages (such as JDOQL) and high-performance vendor-specific SQL depending on the database you deploy on.
It is astonishing to see these matters still being discussed as if no solution exists!
10 minutes? Why are you taking so long?
With Java Studio Creator, I can create a data-linked web application (with full MVC structure) in seconds using the visual design tool. And, I have full code-browsing, debugging and refactoring tools.
10 minutes? Slow.
I'm sorry but when did "consensus" become a standard for scientific truth? Truth in science, has often come at the expense of breaking with consensus. And along those lines, science has been led down the wrong roads many times because scientists were trying to marry their data with the agreed "scientific consensus" of their time.
In practice, consensus has become a very useful standard for scientific usefulness most of the time. We all use Newton's theories all the time, even though they have been subsequently refined.
We know that CO2 causes global warming - there is no doubt. Some fine details may need to be sorted out, but that is all.
For a more developed argument, please see Crichton's Aliens Cause Global Warming paper for the explosive and decisive attack against the method of scrutinizing scientific truth which you just proposed.
Yes, let's pick a single science fiction author (and a bad one at that) with absolutely no qualifications in the subject as a source for 'developed argument'.
But what's your point? When using native bindings to C libraries, they act just like other perl modules. It's the same reason we don't use native perl database drivers as well. I don't see how using C bindings in modules is an argument against using the language. Perl was written in C as well, after all.
Because it is a mess when you have to do it yourself. You are having to support two languages in your project - two sets of compilers, two types of debugger, and you are having to package additional libraries with your code. All this is uncessary if you find a fast enough language.
So what you're saying is that the ORM layer groks the foreign keys from the object models and places the constraints on the database when it is available as a feature.
Exactly.
Go read your logs show me this magic SQL and the joins you're talking about and the functions as well.. I'll believe that they exist when I see them.. I've been developing web applications for a long time; I must have missed out on all this special tech.
OK. However, this is not 'magic SQL' or 'special tech' - this are features that should be well-known to experienced database developers. Things like using sub-queries in some databases where they are allowed (Oracle), using vendor-specific sql functions (e.g. 'decode' in Oracle) and coding specific join types that are optimised for specific databases.
Let me emphasise - with a good Java ORM, you don't have to be a database expert to get these optimisations - you get them automatically because the ORM developer knows when they can be used and produces optimised SQL from your portable query. You can get this in Java because there are standards for ORMs, and database vendors can compete to provide optimal implementations (like Oracle and TopLink). You aren't forced to resort to some sub-standard subset of SQL as with Rails.
This is not bad, but once again, you can't rely on those keys for data validation in your application unless you know that all of your development/deployment systems have this ability.
You aren't requiring this for validation in your application - it is adding safety (and efficiency) in certain deployment situations. You aren't relying on them in, say, an embedded test database as you don't need them there. You can rely on them in situations where they are appropriate - multi-user databases where other applications may share the data store.
And, again, you don't need to specify these manually in your database. The ORM can generate them for you.
You're right, the domain model resides inside the database. That is its purpose and the reason it is relational. Maybe this is a difference of philosophy.
It is, and it is an old-fashioned and very restrictive philosophy. I assumed that most development had moved to OOP and flexibility, from the relational model that was commonplace in the 80s. It seems Rails wants to step back decades! With my JDO java ORM I can persist the same truly object-oriented model to high-performance relational stores, hierarchical XML or even CSV. Even better, I can allow the user of my application to choose. I can say 'here is my application - you pick the database'. And I get the full features of a portable query language no matter what store - I can run complex queries on CSV files! It may not be efficient, but I can do it - and for small volumes of data that is incredibly powerful.
Any less flexibility seems primitive to me; because it is primitive.
I honestly believe that a lot of Rails supporters really haven't investigated what modern Java ORMs can do. If they did, they would demand far more of Rails. I really don't understand why they put up with so little.
If you define in your model that you have foreign keys but you deploy to sqlite, you don't have foreign keys. That is a trade off for any application in any framework. Therefore if sqlite is your deployment database your application has to decide that you can't rely on features not implemented in sqlite. This is what I meant. These are decisions made when the application is planned.
You are missing the point. You don't need to make these decisions, or if you do make them, you don't need to make them once and for all for all deployments.
For example, you may have test datasets that don't need constraints as you are the only one using them. But, for the real deployment (which may be a multi-user and multi-app environment) you get the constraints for free that protect your data.
If you're saying that you will just define the maximum set of features and then the database tool will skip the ones that aren't available in one database when deploying to it, and will use them on deployment to another database, then fine. But that is simply a waste of your time.
I didn't say that, as this is not how things work. Imagine that the ORM is like an optimising compiler that analyses the database and produces the best SQL given the particular database. Sort of like compiling automatically with 64-bit instructions on a 64-bit processor if you are running on one.
The only way you could ever have an application that relies on sophisticated database features in a deployment environment is to also have those features available for you in your testing and development environment.
No, not true. There may be (and are) particular functions or ways of doing joins etc. that are available on one database but not on another. You don't need these around at testing - the ORM will automatically use them if you select that database. No testing or use in development environment required.
Also, what features are we even talking about? The only possible feature I could think of is foriegn keys and user defined data types since that is something that can be represented in a model. Everything else an ORM does is select, update, insert, and delete in very standard ways.
No, it doesn't. It can use highly specific optimisations (types of joins, specific functions available in specific database products etc.) to produce very highly tuned queries. And it can do this automatically.
All of these other 'features' like views, triggers, stored procedures, indices, caching etc. are indepedent of the queries or frameworks that you use and are carried out by the database and not implemented in any model objects.
No, you are wrong again. Views and triggers are database-specific, but indices and cacheing can be very finely controlled by the ORM automatically based on analysis of your object model. They can, in some systems, even be implemented directly in model objects via annotations.
I know for a fact ORMs like Hibernate simply write normal SQL queries even if they have to translate them from special query languages like HQL.
No, you are wrong again. They can produce not only very vendor-specific SQL (not 'normal' queries), but systems like JDO don't even need to use SQL - they can use a very wide range of persistence mechanisms - object database, SOAP, XML, CSV, file systems, LDAP.
All of the special options that you put in hibernate models merely tell it how to form the SQL and which other models to join or save when performing different operations.
That is Hibernate. Java ORMs consist of far more than Hiberbate - there are many systems that are far more efficient and far more powerful.
We use functional, unit, and integration tests with fixtures.
You can use as much of these as you like, but they don't hide the fact that your data model simply doesn't exist away from the database, and even worse, if you (or someone else) changes the database, your data classes change. Testing is simply papering over this design flaw of Rails.
Why does you not being the only user of the database mean that foreign key constraints have to be kept in the database? Foreign keys don't somehow make your colleagues better developers..:)
No, but it makes sure they can't screw up your data.
So which is it? Are we generating models from databases or databases from models?
Both. Depends on the circumstances. Which is why most Java ORMs have 'meet in the middle' schema handling where your requirements can match the constraints of existing schema information.
Once again the java ORM can't generate foriegn keys in sqlite or other databases that don't support them. This has the possibility of leaving your database schema inconsistent between database vendors and if you were relying on foriegn keys for any type of data validation then your entire application is going to be inconsistent. The solution is simple, don't rely on foreign keys. Relying on foreign keys actually places you closer to your database implementation and not further away from it, which you argued earlier is what you don't want. Also use of foreign keys doesn't allow for rich features like polymorphic associations.
Of course your application need not be inconsistent.
Having this flexiblity in Java ORMs allows you to develop and run test cases on lighter databases - perhaps without foreign keys, and then deply on more robust databases in a multi-user, multi-application environment with foreign keys. It is a powerful and simple facility that gives your code flexibility and robustness.
If database portability is a major concern for the application then you have to pick the set of features for some set of databases that you want your application to be portable across and only use features from those databases. Like I said, java has made this tradeoff, but it has only worried about db2, sql server, and oracle.
No, you are wrong. You don't have to pick a set of features with a Java ORM - you get the full set of features for the database you deploy on automatically. There is no tradeoff, and to say there is is to misunderstand how well Java systems work.
In the case where you make your database first and then generate your object models, well then rails is much better at this than any java ORM mainly because of the strong run-time reflection that ruby allows.
No. The issue of using run-time reflection is irrelevant to where you define your model. Java can easily work with definitions in the database as the place where the model is defined. But anyway, run-time reflection seems cool but has major disadvantages, such as the inability to test parts of the code away from the database. It also makes your code potentially highly fragile - your code is succeptible to run-time changes in the schema by other code or other users.
Rails prefers to keep this information at the ruby level right now using the has_many, belongs_to, etc. modifiers in the models.
Yes, because that is easy to support. However for a significant number of situations, you aren't the only only user of the database, and such relationships have to be put and kept in the database. More mature ORMs than Rails handle this.
SQL-99 has been supported by all database vendors for years.
No, it hasn't. Neither Oracle, Microsoft or IBM fully support SQL 99. They support different parts of the core standard.
If you are using the 'full power' features that are available in one database that aren't available in another no amount of magic database tools are going to make the features available.
Sorry, you are flat wrong about this. Quality Java ORM systems will automatically make use of the full features of specific databases in order to provide optimum efficiency in querying - as a developer you don't have to put work in to get this. If you have a complex object query, vendor-specific features will be used to make that query work fast. However, if you port exactly the same object query code to another database, it will use different vendor features automatically.
Can you now see why I think Rails is primitive?
The only thing that is not included in the ORM is automatically forming object relations from foriegn keys without having to explicity tell the model about it. But you can't do that in java either, you have to tell the models about their foriegn key relationships even when they are specified in the database already.
No, you don't. Most quality Java ORMs have features to generate object models from databases.
But you are missing the point. The way I work is to develop my object model in one place only - Java classes. The ORM will automatically generate foreign keys in whatever database I choose when it generates the schema to represent my classes. If I pick another vendor's database and switch to that, it does this for me again. It is the DRY principle that Rails is supposed to represent! I specify (and change) things in one place - my object model.
ther than that the ORM (ActiveRecord) writes the same standard SQL-99 for select, update, delete, insert, count, etc. as any ORM would write from its models in java or otherwise; nothing special is required at this layer.
As indicated above, you are wrong. There are ORMs that are far more mature and capable than Rails, and that will automatically go beyond SQL-99 and use powerful features of specific databases to get performance.
My view is that trying to use some sort of common portable subset of SQL-99 is a cop-out, which would be considered a very poor solution in any other situation. I would imagine a database manager who had purchased Oracle or DB2 would be somewhat disappointed if you weren't using the latest features of that database in order to get performance. Sure, you can do that with Rails, but at the cost of losing portability. With a good Java ORM you can do that automatically, and you don't lose portability.
So the question is where do you draw the line with the features you expect to be portable amongst all of your database implementations and where should your database tools draw the line? For rails the line is drawn at sqlite which has a very small feature set compared to other databases.
Indeed, and this seems very poor to me. Sorry, but this seems typical of the Rails approach - implement only a little, then claim that is this 'all you need'.
Does java even write things like views for you? This would seem a bit over the top and unecessary.
No - the idea of Java ORMs is to write things that relate to the object model, and are required to keep that object model valid and consistent (constrains, foreign keys etc.). If there are view and triggers etc, those are the result of some other use of the same data store, and are not relevant to the Java code (although Java ORMs can easily make use of views and stored procedures).
I've run the same non-trivial Rails app on three different database products (MySQL on the old Web host, PostgresQL on the new host, and SQLite locally) with minimal headaches -- just migrate the data, tweak a config-file setting, and It Just Works (tm).
Right. Add a foreign key constraint to the PostgreSQL version. Show me an automatic migration of that to the others. Add a couple of 'text' columns to the PostgreSQL version. Show me an automatic migration to Oracle.
Sorry, but Rails is primitive.
Actually all of these database problems are solved by Migration in ruby on rails. Not only do they allow you a database agnostic representation of your database schema defined purely in ruby (for sql server, mysql, sqlite, db2, oracle, postgres). They also give you schema versioning capabilities that tie into your deployment tasks if you're using switchtower.
No, these problem aren't solved. Look at the schema migration documentation. There are significant things that aren't migrated - 'minor' things like foreign keys!
Why should I put up with a half-working Rails version when my Java ORM allows me to port things in seconds? In fact the more interesting question is - why to Ruby on Rails users put up with such poor quality products?
I also find the idea of having to write my queries in a specialized 'portable' query language pretty annoying.
Why?
If you use standard SQL it is portable anyhow and adding one more level of indirection so I can do the same thing is, not too bright. But with migrations you don't have to worry about any of that anyway.
This is false in almost every respect. Standard SQL is not and has never been portable - migrations between, say SQL Server and DB2 are a nightmare in terms of SQL. Some small subset may be roughly portable, but if you use this subset, you aren't using the full power of the databse.
Secondly, the migrations don't port the SQL you are using, do you do have to worry about this.
We did have to resort to a few native queries to work around it however.
The thing is, I have dealt with small projects that soon grew to substantial ones, with hundreds of thousands of lines, and hundreds of native queries!
For me, the best insurance is an agile language that lets me quickly respond to change, and that lets me get to the heart of a problem without having to pile up gobs of scaffolding and configuration code.
This is an area where Java is changing fast. The era of huge amounts of scaffolding and configuration is going.
To give an example - I don't use configuration at all: All the information about my schema is in my Java classes, with a few Annotations. I can generate my schema from the se classes with the click of a mouse, or via a single Ant task.
There are great new systems for Java like Seam, that allows both the web presentation and the schema to all be generated and controlled from just a few annotated classes!
The idea (often promoted by Rails supporters) that Java has to be swamped by configuration is way out of date.
Part of this may be personal preference however. I enjoy programming in Ruby more, for reasons beyond productivity, and therefor am able to stay focused longer. Ruby just jives with me I suppose. I like the way it works -- it's very intuitive to me.
I hope you continue to enjoy it!
However, I still think there are huge benefits to the type-safe approach. Given a 100,000-line project, how long would it take you to find all usages of a particular column name from a table? With my approach, I can find this out in seconds. Because (unlike with Rails) I have a mapping structure (via the Annotations in my data model classes), my code is isolated from many changes in the schema.
Java fairs better than C here, but why hobble the productivity of my entire project by using static language for everything when only 1% of it is performance critical code?
Because it is a myth that it hobbles productivity, or at least a strongly debated point. The productivity issue of static vs dynamic languages has been a matter of strong debate for decades, with no side winning! This is an extremely complex matter.
At their core, most web apps do little more than move around data. Why not use a language that's well suited to this sort of task?
Because Ruby isn't suited to this for some types of data. And then you have to either rely on someone else's beta-level library for your commercial site or drop down to Java or C yourself. Then you have lost the supposed productivity benefits of using a simple language.
Sure, you can't just pull out your database and replace it with LDAP with a simple configuration change but, in my experience at least, these sorts of requirements just don't come up very often,
You would be surprised! Of course, the issue is that when they do come up, you are really at a loss with Rails. I consider portability a very valuable form of insurance.
Trying to track all uses of a table or column in a large project written in a dynamic language isn't always easy (I have never found it so).
and the products that do support such things tend do so at the expense of something more important. All that abstraction doesn't count for much if I'm left high and dry when I have to do bulk update or sum(), or if I'm going to have to spend the rest of my life setting the thing up.
I think you should take a look at some products like Kodo. They simply don't give you portability at the expense of anything else. With APIs like JDO 2.0 and EJB 3.0 I can do operations like sum() with a single line of portable query language just like with SQL. With a good product like Kodo I can easily do bulk updates with very high performance using ORM, with almost no additional work needed for tuning. It is very easy.
There is this common belief that you need to be close to the database for efficiency - efficiency is counter to portability. This is just not true anymore. My app handles millions of records and I can switch my it between PostgreSQL, Oracle or MySQL in seconds.
However, as much as I'd like to believe otherwise, I don't, in fact, know everything, and I'd be interested in hearing about your experiences. Have you had problems with Rails in this area? What was the situation?
Not specifically with Rails, but with similar approaches, over many years (since the 80s!). One of the most recent examples was a website that I was supporting that was developed years ago in an interpreted language - Cold Fusion. Not only was this website slow, but it included code that was highly specific to the underlying Microsoft database that was providing information for the site. Of course, eventually, under the load of increasing complexity and demand the site collapsed. It was then my task to re-code the entire thing for higher performance. At the time, I used JSPs as I could quickly port Cold Fusion pages to JSP. JSP gets translated to Java code, then compiled on demand so could provide much higher performance. The problem was made a lot worse because of the closeness of the code to the underlying database. We did not have a Microsoft host for the site, so it had to be ported to a non-MS datastore. I resolved never to tie a website to a specific database again, and I fixed this issue by using a Java standard ORM system - JDO. This meant I could deploy with trivial changes to PostgreSQL, MySQL even Oracle or a dozen others. The site has been up since and has dealt with hugely greater loads and demands (such as high-volume transactions to update the information).
Another recent example was when a colleague, against my advice, decided to use highly vendor-specific SQL to implement a website instead of a portable system - JDO or Hibernate. It turned out that all his development for a modern version of PostgreSQL under Windows was wasted because the hosting system was a rather older version of RedHat, and we did not have the option of installing newer versions of the database. The only practical database for use on that host was a somwehat out-of-date version of MySQL. Now, if he had used a portable ORM, this would have been a trivial matter. Instead it took weeks of work.
So, my experience that that portability can be a real problem, and even worse - you can't predict when it will be an issue!
Now I develop using a high-performance Java ORM - Kodo. This works fine both for simple tasks and very large batch operations. Even better, there is the option for automated clustering and cacheing as my website grows. There are nice open-source ORMs like JPOX and Hibernate that offer the same capabilities, if not quite the same performance.
Most of yahoo is written in PHP. Microsoft.com was, last I checked, uncomplied, pre .NET ASP. Google uses Python for most of it's applications. Slashdot uses Perl. Penny Arcade, A List Apart, 43Things, and all the 37 Signals sites use Ruby.
No, you are wrong. Most of Yahoo is not written in PHP, and Google does not use Python for most of its applications. They use these languages for some aspects of their sites, but increasingly pass of 'heavy lifting' to higher performance systems based on J2EE and C/C++.
Using a language does not mean that that a site only or primarily uses the language for everything. Major sites may have the time and resources to manage complex mixed-language development. Small developers don't.
All of these sites receive 1000x more traffic than Gary's Auto Repair ever will, and yet they're holding up just fine, despite being written in relatively poorly performing languages.
Factually incorrect. They use higher performance languages where necessary, and they have the money and resources to scale parts of the site by simply throwing more hardware at things. If you suggest to a small-scale customer that they can deal with occasional high demand by stringing together machines you will be shown the door pretty quickly - saying that a you are dealing with a 'cool new development system' is no excuse for inefficiency.
Language performance simply isn't much of a factor for the vast majority of web apps, where the bottleneck is almost always in the database.
Why not respond to the point made in a post? Have you actually tried handling a significant volume of XML in Ruby or Perl (and I mean in the language, not passing stuff off to a C library)? Have you tried doing something like image management (often a requirement of content managemenent sites) purely in these languages?
Besides, Rails is not only very young, but it works fine, performance-wise, for 75% of the business sites that need database support. You wouldn't use it for Amazon.com, but it might work fine for Gary's Auto Repair's business site, which is the sort of thing most free-lance developers are doing in their spare time.
I have heard this sort of false statement so often!
Sorry, but this kind of thing does not work fine for these sites. They may work find for these sort of sites most of the time, but what generally happens is that sooner or later the site will have a burst of high demand, or some additional functionality will be added which requires extra processing (transferring masses of updates to the site by a SOAP service, for example), and the either site collapses, or loses you friends when your site takes up all the CPU on a multi-site machine! Then what happens is the site is re-written and re-hosted in a faster, more established technology, and the expensed saved by using the cool new technology is lost.
I have seen this happen far too often, (but as I am paid to clean up the results, why should I complain?).
I'm overwhelmed by your citation of sources and real-world examples proving your claim of Ruby's slowness!
It is an interpreted language without even a native code translator (at least not one that is out of early beta).
If you would like to explain how that is supposed to be fast , I would be very interested..... Unless, of course, compiler writers have been wasting their time for the past 50 years.
So, you think reinventing the wheel when it comes to GUI is a great idea? One database, one platform independent GUI - sounds perfect to me,
How does reinventing the GUI wheel come into it? If anything is providing yet another re-invented GUI it is Rails. And, having platform independent GUI but producing code that can be very fragile if you attempt to migrate between different database products (or even if someone else radically changes your schema) sounds plain nuts to me.
And now with Ruby-On-Rails being a killerapp for forward looking web designers
No - it is a killer app for getting mentions on Slashdot.
Having a development system with the relative lack of performance of Ruby, and the very close tie-in to the database and schema of Rails is more of a website killer than an killer app, I am afraid to report.
very annoying to users yet the darling of developers?
Only those developers who can't see that a tight coupling between your code and your database is not a good idea.