Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 1
I realize that alot of Programmers like Java because it has alot of features, but as a user, I have yet to come across a Java website I did not hate.
How do you know you are using a Java website?
The minute it starts trying to force a loading of a runtime environment or jar files and screws up the back button or other standard controls I want to leave.
The runtime environment and jar files are only loaded once - when the application server starts. From then on, these do not occur, so have no impact on anything.
The use of controls is highly specific to the way an individual developer has coded their website and used a web framework. It has nothing whatsoever to do with Java.
My view being old-fashioned does not discredit it.
True. I regret this comment, and apologise.
Of course, I know that an application's *data* can be maintained in multiple places, but I argue that the core logic should be in one place (federated database systems are a good example). Yes, it is possible for the application layer or even multiple application layers to maintain the logic, and just use the database as a mere repository. Fine, do that, but in the end any truly sophisticated system of that nature will end up re-implementing many (or even most) of the things already being done by a proper DBMS. Where's the gain?
Performance.
Having logic in the database does not seem to be practical for high-load systems. High-volume websites almost always move this logic close to the user interface and work with cached data where possible, only passing things through to the database where required (such as at the end of transactions).
There is little duplication or re-implementation - logic is simply placed at the appropriate point in the various layers of processing to optimise scalability and performance. Where some things are indeed re-implemented (such as transaction handling) this is usually done by widely-used and robust products (a good Java example is Tangosol Coherence clustered cache), which are neither informal or bug-ridden. Java standards like J2EE describe how such products can cleanly integrate with the application stack. APIs such as JTA provide a unified mechanism for handling transactions that goes all the way from the website code to the database.
You're not misunderstanding. ActiveRecord will automatically add those columns. However, unless your application *uses* them, your Rails app will ignore their existence.
Again, correct me if I am wrong, but I don't believe this is competely true. By default ActiveRecord uses a 'SELECT *' when fetching records. This will fetch ALL columns into memory. They may not be actually used by Ruby code, but they are still there. This can result in major memory issues, particularly in commonly used databases which don't page in groups of records but load them all at once. For example, if a BLOB or LONG field is added to a table and populated. Other ORM systems have a facility often called 'fetch groups', in which a mapping can express that only selected columns are loaded by default, and the others are loaded on demand.
This is one of my dislikes of the RoR approach - minimal configuration may seem like a good idea, but most of the things that that RoR seems to consider tedious and fiddly (config files and detailed mappings) have been introduced into other ORMs because of many years of experience of what is necessary to give scalability, robustness and performance on anything but the smallest systems.
The hype is that in rails you can write your application faster and with way less configuration(almost none).
And you have been able to do this for years with other languages.
Also I just don't see the beauty in Ruby. For example, having prefixes to variable names to indicate scope ($ for globals, @ for instance vars) is (in my view) ugly and can prevent code re-use in different contexts. Other dynamic languages manage fine without this kind of thing.
If you're arguing about 10% of total coding effort, then why are you arguing this point at all?
I am not arguing that. I am saying that 10% of the code (or even less) may require a considerable amount of the development time (far more than 10%) if things like performance become an issue.
And, from personal experience, telling a client that 'performance will get better when the language gets faster, and I'm doing this in a really neat new language' is not going to impress:)
As yet, I have not needed to drop down to Ruby's C-level API to implement any of my basic logic. I *have* used interfaces to libraries that others have written (mostly interfaces that have been written for the core, e.g., zlib and syck/YAML), but I have yet to need to write a C-level implementation of code, especially because of speed concerns.
I have. I have had websites written in scripting languages that have collapsed because of computational load when a considerable amount of data structure manipulation and numerical calculation was required.
I just can't see the point of using a language where this sort of thing can become an issue. Initial coding speed (one of the benefits of Ruby) can be a negligible part of the overall development and support effort for a large and complex website or application.
If someone adds columns to your table a normal rails app will happily continue to work and ignore those extra columns until you deem it necessary to add them to your system.
No it won't. Unless I am seriously misunderstanding things (which is a possibility), ActiveRecord will automatically add those columns to classes which inherit from ActiveRecord::Base when they are constructed.
One also has to compare development costs (high) with deployment costs (variable). If I can develop several times faster with Ruby, the cost difference may be significant.
My experience is that the time spend trying to get the required performance for the 10% of code where this matters can outweigh the time saved in using a concise language.
You may fundamentally disagree that data is king in business.
where did I say that?
The fact that businesses survived for centuries without computers indicates that your fundament is disagreeing with reality.
Not at all. For those centuries business have combined information with business processes to handle it. Both are essential.
It is mostly when data has been lost without any way of reconstructing the processes surrounding the data that companies have run into trouble.
I agree.
If you give me data in a usable form, I can *always* build or rebuild processes and code around that.
No you can't. Not if you don't have an understanding of the business processes that have generated, and that handle, the data.
If you give me code, it will take me far longer to build the data.
No, you couldn't even being to generate the data from just code.
Your fundament happens to be wrong here. If it's wrong on that, it has a good chance of being wrong elsewhere.
You seem to have set up a straw-man argument that either code or data matters. Of course, both matter!
Note that YARV/Rite isn't about JIT for Ruby. If you actually paid attention to Ruby development, instead of spreading FUD and untruths, you might actually know that.
Where did I say it was just about Ruby?
I am NOT spreading FUD! I am a huge supporter of script-based development. But people have to get real. I fully agree that Ruby is fast enough for most purposes, but there are situations when it isn't, and this can be a problem.
I won't be programming 3D engines in it any time soon
Co-incidentally, I am working on a website that DOES require a 3D engine! (it is an interactive walkthrough of buildings). So there is a real life example of how Ruby (and Python, and PERL etc) would fail.
This isn't a matter of hand-waving. It's a matter of knowing when it's appropriate to apply which performance measures, which your moronic statement "Ruby is slow" can't even approach.
It is not moronic when there are real examples of when this statement applies. I gave you one above. I'll give you another: a website application which involves solving complex formulae to get optimal pricing information for products. (I have had a real website collapse under the computation load for things like this).
I prefer to use languages which are productive and when I don't have to put in a lot of work to get performance (or even resort to C coding). The time taken to do this tuning can counteract much of the time saved in using a concise language like Ruby.
Your approach also doesn't take into account the utility of a relational approach to these things, in which changes in base tables in do not necessarily predicate a change in the application layer. We have these wonderful things called views and view updating via triggers or rules. For more sophisticated automated interaction, you can even write set-returning functions or procedures that transparently return data as if they are tables.
There is absolutely no conflict between an application having an object model of the data and a relational database having good relational integrity, views etc. The two ways of working can be combined, and good modern ORM tools allow this to be done easily and efficiently.
Not that I am saying RoR is the ultimate solution, but the idea of an application that can react to database changes is actually a pretty good one, especially when the database is designed properly.
The problem with RoR is that it can react very poorly to database changes. Because there is no column mapping column names are scattered throughout the code - even into web pages.
This approach actually allows for greater decoupling between the application and the database, allowing more business logic to be handled where it belongs: in the database.
Not all business logic needs to be, or should be, in the database. This is a very old-fashioned view. Increasingly data (or subsets of it) are being decentralised and distributed - sometimes into smaller databases, sometimes as files which are snapshots of data, sometimes as web services. The relational database has a key role, but it is not where everything is done.
Only because of people who don't know better--which appears to include you.
I prefer to assume that Oracle know what they are doing. I have been using both object-based and relational approaches for decades. Use of one does not preclude the use of the other. They can work well together.
Class models are inherently tied to a single application or a small class of applications. Database models are far more flexible *and should be*. Any monkey can design a class model that can be used in a single application. It takes someone with real skill to design a reusable database that can be used in ways that aren't expected.
You are assuming that having a class-based approach prevents also having a reusable and rich relational model.
It doesn't.
What it allows is use of one aspect of a relational model in terms of classes.
Quality IT developers haven't been sold on the idea that Bigger Is Better, as has happened with IT management with Java and.NET.
Java is moving in the opposite direction. J2EE is being slimmed down considerably, with new APIs such as EJB version 3.0 making interaction with relational systems very neat.
Ruby is most emphatically not slow. Simply calling Ruby slow doesn't make it so. Running benchmarks means squat.
Running benchmarks shows how fast things can be. Simply repeating 'Ruby is not slow' does not make this statement true. If there were not speed issues, there would be no pressure for JIT development.
Ruby "speed issues" are not, in fact, "established fact."
Oh come on. It is an interpreted language. At some point on any complex application or website there is a situation where processing power is needed.
I have heard this same argument over and over again for years from supporters of different languages. Smalltalk; Java in it's early years. The speed issue was 'hand-waved' away. In my experience, speed always eventually becomes an issue when projects grow. Even the best and most elegant of languages can be abandoned, forcing a rewrite, because of this problem. I have seen this happen again and again.
It has a robust mapping layer, or weren't you reading?
Of course it isn't robust! Even minor changes to schema structure can break code in unpredictable ways.
It also doesn't make you create your databases from scratch
Who says that an object-based approach does?
I wouldn't call the number of hits received by 43places or 43things insignificant.
Number of hits is no indication of the robustness of an approach to change or the ability of code to be supported long term.
Businesses would much rather keep their data than their programs. Good thing, too. It's the data that makes the business run, not the programs.
I fundamentally disagree. Data alone can be meaningless without code that expresses the relationship between data items and expressed the business logic required to manage it.
(I've known a lot of people who manage to make things work well with Excel spreadsheets, clearly indicating that it's the data that's more important.)
Perhaps in that situation. In others there are issues of bulk processing, and large transaction handling that require serious code, and not spreadsheets.
Just out of curiosity, are there any systems designed the other way around? I would think that making an OO design for the entire app, then letting a tool extract the structure for the database tables out of the classes would be a more logical approach then extracting the OO design out of the database tables?
Yes. This approach is often used. For example, there is a Java API for storing objects called JDO. All the major vendors who provide JDO tools (both commercial and open source) allow the generation of database tables from objects. This is not necessarily a one-shot process - many of these tools will even migrate the structure of a live database to reflect changed object structures and relationships.
Ah this is in fact true... but probably not too hard to change if you need to for the unlikely case that this is required.
I would prefer this kind of thing to be available easily in the default setup.
I consider column-based mapping to be very useful as a form of protection for my code - it means my application can easily check for someone having done something silly to the schema.
It also means that I could potentially transfer the database between different types (MySQL -> PostgreSQL or Oracle) without having to worry about any required changes in column names (and therefore generated Ruby instance variables).
With a column-based mapping - either in a file or in Ruby code - I can deal with these issues in a single place in an application.
Ruby on Rails has a mapping layer. It's just not used by default ("convention over configuration"). You can specify that an ActiveRecord is made up of all sorts of different non-default things. It's just rare at this point, because people are mostly using it for "green field," from-scratch, new project development.
A good point; I realise this. My problem is that the default 'out of the box' way that ActiveRecord works encourages things that, in my opinion, are bad practice - such as generation of classes only at run time, and dependence on specific schema in specific databases.
Now you can argue that since the mapping layer is in the code (with statements like "set_table_name:some_table"), that you lose the flexibility of having everything abstracted out in an XML file.
I have no objection at all to having a mapping layer in code! I don't care where it is - all I am after is something that can be edited that allows me to specify precisely which columns in a table are used in my classes. I would also like to have the source code for the mapped classes available to edit and possibly examine and refactor in an IDE for Ruby. Having these things generated at run-time makes many things (such as testing code away from the deployment database) more difficult that I think they could be.
That part of your post wasn't FUD, it's opinion/hypothesis. But you followed it with troll FUD:
OK, let's deal with these issues you consider FUD.
"Secondly, Ruby is slow. There may be future JIT systems that help deal with this, but they are not there yet."
This is not FUD, it is simple fact. Ruby is certainly fast enough for very many uses, but it is still an interpreted language. If there were not speed issues, there would be no JIT project. As for the 'not there yet' - there are no such projects that I know of that are out of beta.
Thirdly, Ruby is changing, and it is likely (from what I read) that the next version will not be fully compatible, so any major project developed now in Rails will have upgrading issues.
Again, this is plain fact. The inventor of Ruby has stated this (the incompatibility) himself! Perhaps you should accuse him of FUD!
That merely maps table names. A mapping layer defines how columns relate to instance variable names within classes, and allow the possibility of some columns being ignored.
This is very important if there are subsequent changes to a table - some user may add additional columns and data to a table; data which is irrelevant to your application.
Mapping involves the possibility of translation. In Rails there is no translation - column names are used directly in the dynamic construction of classes - at least not in the default use of ActiveRecord.
People who dont really know anything about data modelling and relational theory tend to prefer class->table interpretation. People who understand data modelling tend to prefer table->class interpretation.
I have to fundamentally disagree here. Even Oracle, who have a huge vested interest in relational theory, are putting a huge amount of work into class-> table interpretation with projects like TopLink.
This is a straw-man. Ruby most emphatically is not slow.
It emphatically is! Try benchmarking something like XML processing (which is an important part of many current website situations, such as SOAP and Axis). This does not matter in most situations, but there are occasional situations where performance matters. Denying this will not help Ruby.
Rails, on the other hand, is probably appropriate for small-to-medium database-backed web applications.
Quite the reverse. Only with a decent mapping layer can it be robust enough for medium or large-scale use.
IT developers in general have know this for years, but a few Rails developers seem to think they know better!
This response is probably more than your statements deserve, but FUD like yours tends to get rememberedand that is bad.
Far worse is the combination of a 'silver bullet' attitude, and flat denial of established fact (Ruby speed issues) that entices developers into using technologies that prove potentially difficult to support for large projects.
-1, Troll. Please. There are people running real, large-scale web sites on Ruby-on-Rails. Tobias just named several.
This has no relevance to whether or not Ruby on Rails is a fundamentally good design for long-term support and growth of any given software project. We all know that poor designs have been used in large projects!
The issue of database-dependence is a real and important one, and should not be trivially dismissed as 'trolling'. The idea of working dynamically from database tables is great for getting things up and running fast, but is not great for long term use, as at some future date the database may need to be modified or shared with other applications. The changes that result may break existing Ruby on Rails applications. More mature ORM systems have a mapping layer that can help isolate code from such changes. By abandoning that layer as the default setup, Ruby on Rails loses (in my view) an important feature.
There is no downside to using ruby on rails. Closest thing to a silver bullet since the web came out.
There are several significant downsides to using Ruby on Rails.
Firstly, the way that ActiveRecord works by default - generating classes at run-time based on database tables - is considered by many (well, me at least!) to be a very backward step, as it makes code vunerable to changes in those tables, and also makes portability of code between different databases non-trivial. There are far better ways to do this - the Python ORM Dejavu (in in which the data model is expressed as classes) is an example. Almost all modern development languages work this way - with the exception of RoR!
Secondly, Ruby is slow. There may be future JIT systems that help deal with this, but they are not there yet.
Thirdly, Ruby is changing, and it is likely (from what I read) that the next version will not be fully compatible, so any major project developed now in Rails will have upgrading issues.
So Ruby on Rails is very far from a silver bullet. It may a neat way to get small (in terms of code) websites up quickly.
In any case, this is completely bogus. X appeared in 1984 and Windows 1.0 in 1985. For firmly established GUIs, X11 appeared in 1987, Windows 3.0 appeared in 1990, and Windows 3.1 appeared in 1992. There's not ten years in there.
Unix GUIs did not start with X. There was the NeWS system that Sun developed, and there were various other GUIs before that.
I agree it is not ten years, but it is certainly more than 1 or 2.
Apple can move fast and change directions faster because they don't have an installed base that would hate them because they twist and turn
Apple has a large and loyal installed base, but because they have controlled both the hardware and OS they can change things yet maintain backwards compatibility. Compare this to Windows, which still tries to support some old MS-DOS applications that ran where there were no standards for things like graphics.
But MS Windows gave rise to our industry's explosion, and they deserve a small amount of positive affirmation for that.
No it didn't. MS Windows was a result of the IT industry growth, not a cause. The PC was already cheap and widely used (in the UK, Amstrad PCs running DR-DOS and GEM were selling well) before Windows turned up. There were many alternative GUI systems that could have become dominant on the PC.
Isaac Newton created laws of motion that were accepted as law (even stronger than a theory) for centuries, but he was eventually proven wrong by Albert Einstein.
No he wasn't. We still use Newton's laws of motions all the time. Einstein simply showed that Newton's laws were incomplete.
I believe that evolution is how life came to be as it is, but that doesn't make it true.
Eventually, when there is enough evidence, you have to use the word 'true'.
There are problems with evolution, such as the likelyhood that something as complex as a human brain evolved in only 4 billion years.
That is not a problem with evolution - that is a problem with your (and other's) understanding of it. The stages of evolution of brains are pretty clear.
Fine tuning of physical + cosmological parameters.
For example, the observed cosmological constant is at least 10^60 times smaller than predicted by vacuum energy.
The cosmological constant problem is nothing to do with fine tuning - it simply shows that our physics is incomplete.
You could account for this by the Anthropic Principle (i.e., random universes + selection bias) or by Intelligent Design (almost just a different kind of selection bias).
Or just that we are where we are in a very big multiverse.
Neither one of those explanations can be tested by experiment. Either method relies on something or someone which is beyond physical law and which cannot be probed by physical methods.
They can be tested by experiment. For example, the existence of other dimensions (and other universes) can be tested by things such as changes in gravitational strength over small distances.
Well, I have to disagree. My high school Biology teacher got up and ranted "Evolution is FACT!" when one of the students merely suggested that Evolution be considered a theory which is unprovable.
Evolution IS a fact. Life has changed, and is changing all the time.
The point I was making was that most teaching of it will include mention of other ideas. Whether or not a teacher states that evolution is fact has no relevance.
This ranting behavior is seen on both sides of the issue, however, the goals are different - evolutionists want ID totally ruled out, whereas ID proponents want a rational, two sided discussion.
Of course they don't! How can you have a rational two-sided discussion about intelligent design, which is basically nothing more than pointing at arbitrary aspects of life forms and saying 'THAT is too complex to have evolved by itself'.
Slashdot Mirror
I realize that alot of Programmers like Java because it has alot of features, but as a user, I have yet to come across a Java website I did not hate.
How do you know you are using a Java website?
The minute it starts trying to force a loading of a runtime environment or jar files and screws up the back button or other standard controls I want to leave.
The runtime environment and jar files are only loaded once - when the application server starts. From then on, these do not occur, so have no impact on anything.
The use of controls is highly specific to the way an individual developer has coded their website and used a web framework. It has nothing whatsoever to do with Java.
My view being old-fashioned does not discredit it.
True. I regret this comment, and apologise.
Of course, I know that an application's *data* can be maintained in multiple places, but I argue that the core logic should be in one place (federated database systems are a good example). Yes, it is possible for the application layer or even multiple application layers to maintain the logic, and just use the database as a mere repository. Fine, do that, but in the end any truly sophisticated system of that nature will end up re-implementing many (or even most) of the things already being done by a proper DBMS. Where's the gain?
Performance.
Having logic in the database does not seem to be practical for high-load systems. High-volume websites almost always move this logic close to the user interface and work with cached data where possible, only passing things through to the database where required (such as at the end of transactions).
There is little duplication or re-implementation - logic is simply placed at the appropriate point in the various layers of processing to optimise scalability and performance. Where some things are indeed re-implemented (such as transaction handling) this is usually done by widely-used and robust products (a good Java example is Tangosol Coherence clustered cache), which are neither informal or bug-ridden. Java standards like J2EE describe how such products can cleanly integrate with the application stack. APIs such as JTA provide a unified mechanism for handling transactions that goes all the way from the website code to the database.
You're not misunderstanding. ActiveRecord will automatically add those columns. However, unless your application *uses* them, your Rails app will ignore their existence.
Again, correct me if I am wrong, but I don't believe this is competely true. By default ActiveRecord uses a 'SELECT *' when fetching records. This will fetch ALL columns into memory. They may not be actually used by Ruby code, but they are still there. This can result in major memory issues, particularly in commonly used databases which don't page in groups of records but load them all at once. For example, if a BLOB or LONG field is added to a table and populated. Other ORM systems have a facility often called 'fetch groups', in which a mapping can express that only selected columns are loaded by default, and the others are loaded on demand.
This is one of my dislikes of the RoR approach - minimal configuration may seem like a good idea, but most of the things that that RoR seems to consider tedious and fiddly (config files and detailed mappings) have been introduced into other ORMs because of many years of experience of what is necessary to give scalability, robustness and performance on anything but the smallest systems.
The hype is that in rails you can write your application faster and with way less configuration(almost none).
And you have been able to do this for years with other languages.
Also I just don't see the beauty in Ruby. For example, having prefixes to variable names to indicate scope ($ for globals, @ for instance vars) is (in my view) ugly and can prevent code re-use in different contexts. Other dynamic languages manage fine without this kind of thing.
If you're arguing about 10% of total coding effort, then why are you arguing this point at all?
:)
I am not arguing that. I am saying that 10% of the code (or even less) may require a considerable amount of the development time (far more than 10%) if things like performance become an issue.
And, from personal experience, telling a client that 'performance will get better when the language gets faster, and I'm doing this in a really neat new language' is not going to impress
As yet, I have not needed to drop down to Ruby's C-level API to implement any of my basic logic. I *have* used interfaces to libraries that others have written (mostly interfaces that have been written for the core, e.g., zlib and syck/YAML), but I have yet to need to write a C-level implementation of code, especially because of speed concerns.
I have. I have had websites written in scripting languages that have collapsed because of computational load when a considerable amount of data structure manipulation and numerical calculation was required.
I just can't see the point of using a language where this sort of thing can become an issue. Initial coding speed (one of the benefits of Ruby) can be a negligible part of the overall development and support effort for a large and complex website or application.
If someone adds columns to your table a normal rails app will happily continue to work and ignore those extra columns until you deem it necessary to add them to your system.
No it won't. Unless I am seriously misunderstanding things (which is a possibility), ActiveRecord will automatically add those columns to classes which inherit from ActiveRecord::Base when they are constructed.
One also has to compare development costs (high) with deployment costs (variable). If I can develop several times faster with Ruby, the cost difference may be significant.
My experience is that the time spend trying to get the required performance for the 10% of code where this matters can outweigh the time saved in using a concise language.
You may fundamentally disagree that data is king in business.
where did I say that?
The fact that businesses survived for centuries without computers indicates that your fundament is disagreeing with reality.
Not at all. For those centuries business have combined information with business processes to handle it. Both are essential.
It is mostly when data has been lost without any way of reconstructing the processes surrounding the data that companies have run into trouble.
I agree.
If you give me data in a usable form, I can *always* build or rebuild processes and code around that.
No you can't. Not if you don't have an understanding of the business processes that have generated, and that handle, the data.
If you give me code, it will take me far longer to build the data.
No, you couldn't even being to generate the data from just code.
Your fundament happens to be wrong here. If it's wrong on that, it has a good chance of being wrong elsewhere.
You seem to have set up a straw-man argument that either code or data matters. Of course, both matter!
Note that YARV/Rite isn't about JIT for Ruby. If you actually paid attention to Ruby development, instead of spreading FUD and untruths, you might actually know that.
Where did I say it was just about Ruby?
I am NOT spreading FUD! I am a huge supporter of script-based development. But people have to get real. I fully agree that Ruby is fast enough for most purposes, but there are situations when it isn't, and this can be a problem.
I won't be programming 3D engines in it any time soon
Co-incidentally, I am working on a website that DOES require a 3D engine! (it is an interactive walkthrough of buildings). So there is a real life example of how Ruby (and Python, and PERL etc) would fail.
This isn't a matter of hand-waving. It's a matter of knowing when it's appropriate to apply which performance measures, which your moronic statement "Ruby is slow" can't even approach.
It is not moronic when there are real examples of when this statement applies. I gave you one above. I'll give you another: a website application which involves solving complex formulae to get optimal pricing information for products. (I have had a real website collapse under the computation load for things like this).
I prefer to use languages which are productive and when I don't have to put in a lot of work to get performance (or even resort to C coding). The time taken to do this tuning can counteract much of the time saved in using a concise language like Ruby.
Your approach also doesn't take into account the utility of a relational approach to these things, in which changes in base tables in do not necessarily predicate a change in the application layer. We have these wonderful things called views and view updating via triggers or rules. For more sophisticated automated interaction, you can even write set-returning functions or procedures that transparently return data as if they are tables.
There is absolutely no conflict between an application having an object model of the data and a relational database having good relational integrity, views etc. The two ways of working can be combined, and good modern ORM tools allow this to be done easily and efficiently.
Not that I am saying RoR is the ultimate solution, but the idea of an application that can react to database changes is actually a pretty good one, especially when the database is designed properly.
The problem with RoR is that it can react very poorly to database changes. Because there is no column mapping column names are scattered throughout the code - even into web pages.
This approach actually allows for greater decoupling between the application and the database, allowing more business logic to be handled where it belongs: in the database.
Not all business logic needs to be, or should be, in the database. This is a very old-fashioned view. Increasingly data (or subsets of it) are being decentralised and distributed - sometimes into smaller databases, sometimes as files which are snapshots of data, sometimes as web services. The relational database has a key role, but it is not where everything is done.
Only because of people who don't know better--which appears to include you.
.NET.
I prefer to assume that Oracle know what they are doing. I have been using both object-based and relational approaches for decades. Use of one does not preclude the use of the other. They can work well together.
Class models are inherently tied to a single application or a small class of applications. Database models are far more flexible *and should be*. Any monkey can design a class model that can be used in a single application. It takes someone with real skill to design a reusable database that can be used in ways that aren't expected.
You are assuming that having a class-based approach prevents also having a reusable and rich relational model.
It doesn't.
What it allows is use of one aspect of a relational model in terms of classes.
Quality IT developers haven't been sold on the idea that Bigger Is Better, as has happened with IT management with Java and
Java is moving in the opposite direction. J2EE is being slimmed down considerably, with new APIs such as EJB version 3.0 making interaction with relational systems very neat.
Ruby is most emphatically not slow. Simply calling Ruby slow doesn't make it so. Running benchmarks means squat.
Running benchmarks shows how fast things can be.
Simply repeating 'Ruby is not slow' does not make this statement true. If there were not speed issues, there would be no pressure for JIT development.
Ruby "speed issues" are not, in fact, "established fact."
Oh come on. It is an interpreted language. At some point on any complex application or website there is a situation where processing power is needed.
I have heard this same argument over and over again for years from supporters of different languages. Smalltalk; Java in it's early years. The speed issue was 'hand-waved' away. In my experience, speed always eventually becomes an issue when projects grow. Even the best and most elegant of languages can be abandoned, forcing a rewrite, because of this problem. I have seen this happen again and again.
It has a robust mapping layer, or weren't you reading?
Of course it isn't robust! Even minor changes to schema structure can break code in unpredictable ways.
It also doesn't make you create your databases from scratch
Who says that an object-based approach does?
I wouldn't call the number of hits received by 43places or 43things insignificant.
Number of hits is no indication of the robustness of an approach to change or the ability of code to be supported long term.
Businesses would much rather keep their data than their programs. Good thing, too. It's the data that makes the business run, not the programs.
I fundamentally disagree. Data alone can be meaningless without code that expresses the relationship between data items and expressed the business logic required to manage it.
(I've known a lot of people who manage to make things work well with Excel spreadsheets, clearly indicating that it's the data that's more important.)
Perhaps in that situation. In others there are issues of bulk processing, and large transaction handling that require serious code, and not spreadsheets.
Just out of curiosity, are there any systems designed the other way around? I would think that making an OO design for the entire app, then letting a tool extract the structure for the database tables out of the classes would be a more logical approach then extracting the OO design out of the database tables?
Yes. This approach is often used. For example, there is a Java API for storing objects called JDO. All the major vendors who provide JDO tools (both commercial and open source) allow the generation of database tables from objects. This is not necessarily a one-shot process - many of these tools will even migrate the structure of a live database to reflect changed object structures and relationships.
Ah this is in fact true ... but probably not too hard to change if you need to for the unlikely case that this is required.
I would prefer this kind of thing to be available easily in the default setup.
I consider column-based mapping to be very useful as a form of protection for my code - it means my application can easily check for someone having done something silly to the schema.
It also means that I could potentially transfer the database between different types (MySQL -> PostgreSQL or Oracle) without having to worry about any required changes in column names (and therefore generated Ruby instance variables).
With a column-based mapping - either in a file or in Ruby code - I can deal with these issues in a single place in an application.
Ruby on Rails has a mapping layer. It's just not used by default ("convention over configuration").
:some_table"), that you lose the flexibility of having everything abstracted out in an XML file.
You can specify that an ActiveRecord is made up of all sorts of different non-default things. It's just rare at this point, because people are mostly using it for "green field," from-scratch, new project development.
A good point; I realise this. My problem is that the default 'out of the box' way that ActiveRecord works encourages things that, in my opinion, are bad practice - such as generation of classes only at run time, and dependence on specific schema in specific databases.
Now you can argue that since the mapping layer is in the code (with statements like "set_table_name
I have no objection at all to having a mapping layer in code! I don't care where it is - all I am after is something that can be edited that allows me to specify precisely which columns in a table are used in my classes. I would also like to have the source code for the mapped classes available to edit and possibly examine and refactor in an IDE for Ruby. Having these things generated at run-time makes many things (such as testing code away from the deployment database) more difficult that I think they could be.
That part of your post wasn't FUD, it's opinion/hypothesis. But you followed it with troll FUD:
OK, let's deal with these issues you consider FUD.
"Secondly, Ruby is slow. There may be future JIT systems that help deal with this, but they are not there yet."
This is not FUD, it is simple fact. Ruby is certainly fast enough for very many uses, but it is still an interpreted language. If there were not speed issues, there would be no JIT project. As for the 'not there yet' - there are no such projects that I know of that are out of beta.
Thirdly, Ruby is changing, and it is likely (from what I read) that the next version will not be fully compatible, so any major project developed now in Rails will have upgrading issues.
Again, this is plain fact. The inventor of Ruby has stated this (the incompatibility) himself! Perhaps you should accuse him of FUD!
There is a mapping layer. Maybe you should learn about something before you post about it.
:whatever_the_fuck_i_want :has_many(:ppl_who_talk_out_their_ass, :table_name => :whatever_the_fuck_i_want)
set_table_name
That merely maps table names. A mapping layer defines how columns relate to instance variable names within classes, and allow the possibility of some columns being ignored.
This is very important if there are subsequent changes to a table - some user may add additional columns and data to a table; data which is irrelevant to your application.
Mapping involves the possibility of translation. In Rails there is no translation - column names are used directly in the dynamic construction of classes - at least not in the default use of ActiveRecord.
People who dont really know anything about data modelling and relational theory tend to prefer class->table interpretation. People who understand data modelling tend to prefer table->class interpretation.
I have to fundamentally disagree here. Even Oracle, who have a huge vested interest in relational theory, are putting a huge amount of work into class-> table interpretation with projects like TopLink.
This is a straw-man. Ruby most emphatically is not slow.
It emphatically is! Try benchmarking something like XML processing (which is an important part of many current website situations, such as SOAP and Axis). This does not matter in most situations, but there are occasional situations where performance matters. Denying this will not help Ruby.
Rails, on the other hand, is probably appropriate for small-to-medium database-backed web applications.
Quite the reverse. Only with a decent mapping layer can it be robust enough for medium or large-scale use.
IT developers in general have know this for years, but a few Rails developers seem to think they know better!
This response is probably more than your statements deserve, but FUD like yours tends to get rememberedand that is bad.
Far worse is the combination of a 'silver bullet' attitude, and flat denial of established fact (Ruby speed issues) that entices developers into using technologies that prove potentially difficult to support for large projects.
Thanks for the FUD, Guido!
-1, Troll. Please. There are people running real, large-scale web sites on Ruby-on-Rails. Tobias just named several.
This has no relevance to whether or not Ruby on Rails is a fundamentally good design for long-term support and growth of any given software project. We all know that poor designs have been used in large projects!
The issue of database-dependence is a real and important one, and should not be trivially dismissed as 'trolling'. The idea of working dynamically from database tables is great for getting things up and running fast, but is not great for long term use, as at some future date the database may need to be modified or shared with other applications. The changes that result may break existing Ruby on Rails applications. More mature ORM systems have a mapping layer that can help isolate code from such changes. By abandoning that layer as the default setup, Ruby on Rails loses (in my view) an important feature.
There is no downside to using ruby on rails. Closest thing to a silver bullet since the web came out.
There are several significant downsides to using Ruby on Rails.
Firstly, the way that ActiveRecord works by default - generating classes at run-time based on database tables - is considered by many (well, me at least!) to be a very backward step, as it makes code vunerable to changes in those tables, and also makes portability of code between different databases non-trivial. There are far better ways to do this - the Python ORM Dejavu (in in which the data model is expressed as classes) is an example. Almost all modern development languages work this way - with the exception of RoR!
Secondly, Ruby is slow. There may be future JIT systems that help deal with this, but they are not there yet.
Thirdly, Ruby is changing, and it is likely (from what I read) that the next version will not be fully compatible, so any major project developed now in Rails will have upgrading issues.
So Ruby on Rails is very far from a silver bullet. It may a neat way to get small (in terms of code) websites up quickly.
http://www.postscript.org/FAQs/language/node73.htm l says that NeWS started in 1985, the same year as Windows 1.0 and a year after X.
You are right. My fading middle-aged memory has let me down.
[there were various other GUIs before that.]
But any of significance?
I guess not, on Unix at least. However, on other platforms there were pretty advanced GUIs. The Xerox Star, and the Apple Lisa.
In any case, this is completely bogus. X appeared in 1984 and Windows 1.0 in 1985. For firmly established GUIs, X11 appeared in 1987, Windows 3.0 appeared in 1990, and Windows 3.1 appeared in 1992. There's not ten years in there.
Unix GUIs did not start with X. There was the NeWS system that Sun developed, and there were various other GUIs before that.
I agree it is not ten years, but it is certainly more than 1 or 2.
Apple can move fast and change directions faster because they don't have an installed base that would hate them because they twist and turn
Apple has a large and loyal installed base, but because they have controlled both the hardware and OS they can change things yet maintain backwards compatibility. Compare this to Windows, which still tries to support some old MS-DOS applications that ran where there were no standards for things like graphics.
But MS Windows gave rise to our industry's explosion, and they deserve a small amount of positive affirmation for that.
No it didn't. MS Windows was a result of the IT industry growth, not a cause. The PC was already cheap and widely used (in the UK, Amstrad PCs running DR-DOS and GEM were selling well) before Windows turned up. There were many alternative GUI systems that could have become dominant on the PC.
Isaac Newton created laws of motion that were accepted as law (even stronger than a theory) for centuries, but he was eventually proven wrong by Albert Einstein.
No he wasn't. We still use Newton's laws of motions all the time. Einstein simply showed that Newton's laws were incomplete.
I believe that evolution is how life came to be as it is, but that doesn't make it true.
Eventually, when there is enough evidence, you have to use the word 'true'.
There are problems with evolution, such as the likelyhood that something as complex as a human brain evolved in only 4 billion years.
That is not a problem with evolution - that is a problem with your (and other's) understanding of it. The stages of evolution of brains are pretty clear.
Fine tuning of physical + cosmological parameters.
For example, the observed cosmological constant is at least 10^60 times smaller than predicted by vacuum energy.
The cosmological constant problem is nothing to do with fine tuning - it simply shows that our physics is incomplete.
You could account for this by the Anthropic Principle (i.e., random universes + selection bias) or by Intelligent Design (almost just a different kind of selection bias).
Or just that we are where we are in a very big multiverse.
Neither one of those explanations can be tested by experiment. Either method relies on something or someone which is beyond physical law and which cannot be probed by physical methods.
They can be tested by experiment. For example, the existence of other dimensions (and other universes) can be tested by things such as changes in gravitational strength over small distances.
Well, I have to disagree. My high school Biology teacher got up and ranted "Evolution is FACT!" when one of the students merely suggested that Evolution be considered a theory which is unprovable.
Evolution IS a fact. Life has changed, and is changing all the time.
The point I was making was that most teaching of it will include mention of other ideas. Whether or not a teacher states that evolution is fact has no relevance.
This ranting behavior is seen on both sides of the issue, however, the goals are different - evolutionists want ID totally ruled out, whereas ID proponents want a rational, two sided discussion.
Of course they don't! How can you have a rational two-sided discussion about intelligent design, which is basically nothing more than pointing at arbitrary aspects of life forms and saying 'THAT is too complex to have evolved by itself'.