In that context, it is impossible to teach OOP alone; it inherently builds on the concepts of procedural programming.
I don't quite understand what you're driving at when you talk about teaching OOP first and from the start. How can you teach OOP without teaching, say, functional decomposition and structured programming?
I had what I thought was a really good example of how to do this from years back - it was the tutorial for Digitalk Smalltalk in the mid 80s. It had a superb introduction to OOP that started from the simple basis of everyday arithmetic and how this could be considered to be messages, and built up from there. This was development for absolute beginners - no mention of functional decomposition or structured programming. And it worked! It had been demonstrated to work a decade earlier during the early development of Smalltalk.
I am not saying this is the way I would do it - just that you can teach pure OOP in isolation.
I would say that inheritance was the most over-used tool in the OOP world; I've seen countless occasions where composition or some other form of collaboration between classes would provide a far more flexible design. Indeed, I have often wondered whether the only time one should use inheritance in a robust OO design is when polymorphism is to be employed, since anything else binds more tightly without gaining any particular benefit over composition.
This is why we differ, or rather, why we don't! I was not talking about the OOP world - I was talking about how languages that have the potential to use OOP for development are used in practice by a very large number of developers - about how developers are using C++ like C, or how they are using Java as simply a set of rich libraries, and barely using any OOP facilities in their own code. I agree that inheritance can be overused by people who use OOP heavily, but that was not my point.
I don't believe that throwing students in at the deep end with Java or the like really works, because it's been common practice in many academic institutions for years; if it worked, we wouldn't be having this conversation.
And I agree with this too, because Java is a complex mixture of paradigms.
Alas you are presuming all that goodness you got with java comes at no cost. That's not true. It comes at the cost of developer productivity.
No, it doesn't. I can design my classes visually and have the schema generated at the click of a mouse. The debate about developer productivity with dynamic vs static languages has been going on for decades, and has come to no conclusion one way or the other. Simply to state that Ruby is more productive to deny the existence of that ongoing debate, and is without foundation.
You will probably disagree with that statement but the legion of java programmers who have used rails tell us otherwise.
Legion? That is a strong statement, and requires evidence. Sorry, but I just don't believe it without firm numbers.
I haven't been constrained by Rails's SQL generation yet.
Sorry if this sounds impolite - but I think you have, but you just don't know it yet:)
And you didn't answer my question. When does it *really* matter?
When performance really matters. I deal with transactions of hundreds of thousands of records, and they need to be fast. This requires optimised SQL.
Also, maybe it is just me, but if my boss has spend thousands on a high-performance database with lots of features which can improve performance, I would feel foolish if I didn't use them!
After doing reporting for twenty years across many projects I've seen most reporting tools out there. If you consider JasperReports powerful then you really don't understand reporting.
The poster was asking to hear about a product that allowed use of an ORM portable query language; that is the reason for mentioning JasperReports.
Hmm, having perform many ports between database products I can honestly say that I've never bumped into this problem outside of SQL Server/Sybase stored procedure insanity. The most often case is 10% of your queries might require a tweak. 1% might require a rewrite.
Hmm, well, I deal with this on a daily basis. It is nothing like you describe. I am involved in porting projects that take months, and I know many others who have had to deal with the same issues.
So, to avoid this you wrap the entire language in an entirely new language? That itself can't support 100% of the features of the first, and isn't usable by everything that supports the first?
The languages are standardised, and they can support all features.
Hmm, I think people should actually learn how to use databases before coming up with ingenious work-arounds like:
- Object Oriented Databases - that can't handle sequential scans, reporting, searching.
- Hierarchical Databases - reinventions of technology thrown away in the 80s.
- XML as a database - completely misses concepts of ACID, concurrent users, sequential scanning
- wrappers to help programmers avoid learning the lingua franca of databases (SQL)
I am not talking about these! I am not talking about OOP, hierarchical databases, or XML.
I am talking about SQL-like languages (that DO require you to understand SQL and its concepts - this is, of course, essential) but allow true effective portability.
Sorry to be so negative towards your point, but I've been on multiple J2EE projects where programmers adopted some brilliant idea like OODBMS, container managed pesistence, or sometimes just EJBs - only to discover later that the way that the java community thinks about data only covers about 50% of its needs.
This is why I was talking about more research needed by posters, as if you think that modern ORMs force any of the above solutions, you are way out of date. I am not talking about OODBMS or container managed persistence! I am talking about rich, lightweight object/relational mapping systems that allow full use of the underlying databases.
Almost as bad, they prevent OOP playing nicely with other programming idioms that, as you observed yourself, should be orthogonal to the use of objects, not in competition with it. I realise that not all OO languages have these limitations, but the mainstream ones all do, and I would argue that this is what most people think of when they talk about OOP.
Yes, but why should this failing prevent the use of OOP when it's use alone (without the use of other idioms) is more powerful than procedural alone?
write code for a living.
Me too.
I've worked on large-scale projects in OO languages, and seen the power of an effective design taking advantage of polymorphism first-hand.
Me too.
But I also have an academic CS background, and experience of other programming styles.
Me too.
After many years of doing this stuff, I'm more convinced than ever that while OO provides a model of certain ideas that is useful because it's accessible to a wide range of programmers, ultimately it doesn't really have any unique ideas of its own. It simply emphasises particular aspects, and presents a particular view of some general ideas.
And I could not disagree more. I think ideas such as inheritance and polymorphism are unquestionably unique and distinctive aspects of OOP, and vastly underused in the software industry. I think their use needs to be far more widely encouraged in order to improve developer productivity and code quality.
Suppose someone taught you how to drive a car, but would not let you go beyond third gear, as not all cars have more gears - would you be content? Of course not! So why are you happy with Rails only using 3 of the gears with its SQL?
And how does Rails prevent you from changing it?
Rails doesn't - you can always implement your own automatic sensing of database capabilities and patch in use of extra SQL where feasible.
But this is really dumb! There are products that do all this for you - why should you have to do this yourself? It is so primitive.
the biggest one is running on virtually anything. no other language even comes close. With many processors (particularlly low end stuff) the choice basically comes down to C or assembler.
True, but Java use in this area is growing dramatically.
IMO its best to teach a language thats as close to the metal as possible (assembler for some simple processor like a PIC may even be a good starting point) first then teach more advanced tools later.
For technical use, sure. For general use? I don't think so.
sure if all you ever wan't your students to do is code similar apps over and over in an application category where performance isn't considered to matter (e.g. boring buisness apps) then go ahead teach people the high level languages first and let them think that what goes underneath is black magic.
This is just not true. Performance matters in business apps too, yet there is simply no need to understand the architecture. The optimisation techniques used by general coders don't need such an understanding. There are many very high-performance multi-threaded portable applications written today that have not required the developer to know anything about the underlying processor architecture.
I've heard of hibernate, but not the JPA. Is that going to be part of the standard JRE? I hate having my code rely on goofy 3rd party add-ons.
JPA is going to be a standard part of J2EE, but can be used stand-alone with JRE. There are many vendors providing implementations - Sun, Oracle, JBoss, BEA, JPOX, Versant. A significant number of these are going to be open source (JBoss, Oracle, BEA). Hibernate is also going to provide an implementation of JPA.
I rarely use SQL in my Rails apps. Pretty much only need it when I need to optimize something, which doesn't happen too often.
It is not just how you use SQL, it is how Rails uses SQL transparently - it is still a non-optimal subset of SQL rather than the rich full-featured and optimised SQL that other ORM systems generate.
I don't understand why you think Migrations are configuration files. What makes something a configuration file? What makes something not a configuration file?
Migrations contain data about columns and their types. This is in a Ruby script.
Java JDO has files that contain data about columns and their types. This in an XML file.
Looks the same to me. Just because what you do with the data in Rails migrations is explicitly stated in the files makes no difference in my view.
Why the horror about configuration files? They can be a huge benefit, isolating your code from changes.
Re:Now, if he could apply the same wisdom to SQL,
on
Exploring Active Record
·
· Score: 2, Informative
Great, "rich query languages" that wrap richer query languages.
No, in some cases the portable query language is more featured that the language it wraps. JDOQL implementations can provide rich querying even on systems with no built-in query language (like filesystem storage).
That are highly portable across databases, but themselves are not portable across application layers (do *any* reporting tools support them?
Of course they are. There are reporting tools like JasperReports that can use Hibernate Query Language directly.
is there an ANSI standard for ORMs?)
There are JCP standards for Java ORMs that are fully supported by many vendors. Is there any modern standard for SQL that is fully supported by any vendor? No.
When a developer needs to run adhoc queries in order to diagnose problems with data in a database, to test impacts of schema migration, etc - do they write SQL or application code? Keep in mind that these are not likely to be simplistic queries...
They can use either. Why on Earth are you assuming that these portable query languages are restricted to simplistic queries?
Seriously SQL isn't the greatest language in the world, but I have a hard time understanding why anyone that works with database applications can't handle complex queries.
You are missing the point. Of course they can handle complex queries. What they don't want to have to do is to re-implement thousands of those complex queries in order to migrate to another database product.
It's like someone working on the linux command line that refuses to learn bash. Or like a web developer that refuses to learn HTML and just uses FrontPage instead.
No. The portable query languages aren't less rich than SQL. They are simply portable. That is the big difference.
And aside from the "When in Rome" argument, consider the benefits of learning a data-oriented approach to working with data.
Who says this isn't the case?
SQL is more different from java, python or ruby than lisp is. One of the best things a programmer can do is to to become fluent in multiple different types of languages. Compare SQL's set-based logic to lisp or python. Learn to think of data in terms of sets and aggregates instead of just one row at a time. Until you do that you'll never understand reporting, which is really about how to answer basic business questions.
This is completely irrelevant. Portable query systems in Java are data-oriented, and work with sets and aggregates just like SQL. The difference is that they are 100% portable.
But maybe that's why we've never seen a powerful reporting tool come out of the java community?
No - you have never seen a powerful reporting tool. This does not mean there aren't any. There are plenty.
JasperReports is a good one.
I think posters really need to do some more research before commenting on matters like this - I keep reading posts like this that bear little relation to reality.
actually, you can generate DDL from an OO class definition in Rails by using migrations, which is the built-in way Rails handles updating databases to the current version. you do "script/generate migration " and a skeleton gets generated for you, and then you fill it out. then just run "rake migrate" and DDL is run that generates your tables.
I know about this, and definitely approve - it is a big step forward for Rails into becoming a modern approach! Actually, I find it rather amusing - it involves basically the kind of configuration files that earlier versions of Rails stated were to be avoided and were unnecessary (just because the config files are written in Ruby does not make them any less config files!).
However, it is still way behind other products. Firstly, it is limited to only a few databases out of the box. With my Java ORMs I can almost any database with a modern JDBC driver (and that is a lot).
Contrary to the article you provide, seeing data-safe schema upgrades done automatically does not 'blow my mind', as I was doing that with a Java JDO product years ago!
Also, this in no way overcomes the limitations of Rails use of restricted native SQL - a very poor substitute for having a portable standardised query language (like JDOQL) that is dynamically translated to optimised vendor-specific SQL at run time. Java products have been able to do this for years.
Rails may be advanced and exciting for developers who have used less structures systems, perhaps based on PERL or PHP, but for many of us it has a long way to go to catch up with where modern ORM products were years ago.
As far as "hard to port" SQL, unless you're using MySQL or old versions of databsae apps, this isn't too much of a problem for most SQL heads, even when you throw in database-specific functions or idioms.
That is easy to say until you are dealing with tens of thousands of lines of legacy SQL.
And it all depends on how much trigger/stored proc code you have to migrate. Tables/Views are pretty simple to move.
Not really - just look at the range of different column types in PostgreSQL or Oracle - converting is not trivial, especially when you have BLOBs or CLOBs.
My point is that there are well-established and highly successful ways to avoid all this - I find it hard to believe that in 2006 we are still writing new application code that uses SQL directly (like Rails).
Anything that causes a person not to reproduce is (eventually) selected against. For example, being sensitive to the meme "there are too many people on this world" is an evolutionary disadvantage and will eventually be removed from the genepool. The same goes for high intelligence (being that intelligent people often don't reproduce).
No, this is far too simplistic. Evolution is based on genes, not people. In some cases evolution can favour individuals not breeding as long as a significant fraction of their genes are passed on - which can involve assisting siblings or parents to help bring up children. This happens a lot in Nature - social insects, and in many mammal and bird species.
To put in more simply, what matters is whether the family as a whole (i.e. close relatives) reproduce. A sensitive or intelligent person may not have children themselves, but may bring assistance or income to help close relatives.
One thing I like about ActiveRecord is that it is database agnostic. If I need to, I can move my app from MySQL to Postgres to Oracle with very little effort.
You can move your app, but how much effort is there in moving your data model? For serious apps, quite a bit. Oracle has seriously different types of columns and restrictions on columns from Postgres or MySQL, and if you want to use really efficient SQL, you have to use SQL that is hard to port (MySQL has only recently got subselects, for example).
This is why I think working in the opposite way to Rails - designing your data model in terms of classes and letting the ORM product generate a schema from that (still DRY, but in the other direction) makes far more sense - I can move my apps between those databases with no effort at all.
Due to the issues mentioned I will probably move away from Hibernate towards something else.
I use a JDO product (Kodo) for very large transactions (hundreds of thousands of records), and it works very well and fast. Hibernate was, according to the developers, not intended for this sort of use - which I interpreted as a coded way of saying 'it is too hard to run write our stuff to run efficiently like that and we aren't bothering':)
Hibernate is extremely popular, but, in opinion, far from the best. The Kodo OSS implementation of JPA is something I am eagerly awaiting!
JPA, Hibernate etc... are very powerful apis, but they are way to complex for a RAD approach and they all have huge areas where they need to be cleaned up instead of being carried over to the next API. The biggest one of them IMHO are the areas mentioned.
Good post, but I would disagree with some points. I don't think Hibernate is the easiest API - I far prefer JDO. Secondly, you don't have to use all that locking or use of lazy objects - you can use it in a very simple manner. The use of those features is for optimisation. Finally, if you want great documentation, use something other than Hibernate - JPOX and Kodo are JDO implementations with superb documentation.
No matter what some of the issues are, I don't think anyone can deny that the Java approaches have far more power and flexibility than Rails, if you want to move beyond simple RAD tasks.
Re:Now, if he could apply the same wisdom to SQL,
on
Exploring Active Record
·
· Score: 3, Interesting
What turns me off is forcing you to store all your data persistence into SQL and relational tables, when it is clearly a hierarchy of objects. Why does everyone think they have to do that? The software would function much more simply and the data would typically work better without it.
It is great to see that developes are finally beginning to see the downsides of Rails!
The thing is, not everyone does think they have to do that! There are perfectly good high-performance ORM systems that do allow you to work with a hierarchy of objects and use rich but portable query languages - examples are Hibernate, JDO and the soon-to-be released JPA (Java Persistence Architecture).
They are as DRY (don't repeat yourself) as Rails, as with quality implementations you can automatically generate schemas from objects, or get object hierarchies generated from schemas, and they don't have to rely on endless configuration files (you can define minimal relational information as annotations in your objects).
Also, unlike Rails, they are extremely portable. You aren't restricted to a subset of SQL to get portability. You can use a full and rich query language (like JDOQL 2.0) and that is automatically translated to high-performance vendor-specific SQL for whatever database you are using. Even if you don't want portability, the ability to do this means you get high-quality SQL largely automatically.
Unlike Rails, they work extremely well with both legacy schemas and schemas that are shared with other applications a developers.
Unlike Rails, some of these APIs (JDO) don't restrict you to relational systems - you can persist just as easily to things like object databases, SOAP services, LDAP, text files, filesystems etc., without changing a single line of code, and all the while using a rich query language!
These products and APIs are available right now, have open source implementations and have been used successfully by a very large number of developers for years.
btw, that inheritance+polymorphism "mess" is what powers gtk, not defending or attacking, just stating. Probably a totally different implementation too.
I'm sure they had good reasons. However, my point is that there is no point implementing OOP-like behaviour yourself in a non-OOP language unless you have exceptionally good reasons.
Depending on the language, that can mean anything. In Smalltalk, every task - even storing something in an array is 'object oriented'. Even in Java, any part of software design can be object-oriented as you can enclose your design in classes for potential re-use.
The biggest problem that I see is that when people use C++ they suddenly feel the need to approach everything from an object-oriented perspective, and they begin by picking the wrong objects with the wrong attributes. To pick good object properties, you don't need to understand OOP, you need to understand the problem you're trying to solve and have a clear idea of how you're going to approach it. The key to OOP is design, not the language you're using to do it.
Of course you need to understand OOP to pick good object properties, as you need to understand how those properties can be used for inheritance and polymorphism.
The big problem I see is developers choosing a language with OOP and not realising all the things that they can use it for. They produce repetitive code that is hard to maintain because they don't know about interitance and polymorphism.
Did you say C# and constrained in the same sentence? It seems to me that C# is designed to break all that is sacred in the OO paradigm (I'm looking at you, keyword new).
By constrained I meant not being able to use OOP at all levels.
There is nothing wrong with the new keyword! It has a long history of use in OOP languages.
However, C# is heading is dangerous, messy directions.
unless you're going to be using polymorphism, I don't see any reason to use inheritance. If I want to use the functionality of one object in another, I just create an instance of it there.
That is uncessarily slow (you are adding an unecessary function call that can't be optimised), and breaks any possibility of polymorphism. Handling this by inheritance is so much easier.
Of course, there may situations where you aren't allowed to instantiate the thing you are inheriting from - the class may be abstract or have a hidden constructor.
Sorry, but I just don't see any advantage in not using inheritance.
Certainly if you use a language with generics, which I take Smalltalk to be from you example, you have inherent polymorphism. But that is a design descision built into the language.
Smalltalk does not have generics - it is dynamically typed.
To make another example, you don't have to think about the modularity of your design when you make a java GUI. That is because the java GUI API already has its modularity defined. There is a given class heirarchy that you are using. And this certainly can be a joy.
Actually, the Java GUI Api is an example where you have to use inheritance to be effective - you have to extent (for example) JComponent.
You don't have to think of modularity to use polymorphism - you just use it. I don't understand what you mean by this requirement.
An example in Java 1.5:
List myList = new ArrayList();
MyList can handle instances of my Account class. But it can also handle any future subclasses of Account that I (or any other developer) create. This is enormously powerful.
Unless you're going to be using polymorphism, I don't see how OO really adds anything to programming.
What about code re-use through inheritance? I use that extensively.
And the trouble with polymorphism is that to really use it effectively you have to plan in advance how you're going to break your program into modular pieces.
You do? Look: I am using polymorphism in the following Smalltalk code:
c:= Collection new. c add: 1. c add: 1.2. c add: 'String value'.
No modularisation needed there.
I really do feel that OO is an organizational aid more than anything else.
No, it is a fundamentally different approach to development, and should be understood by any skilled developer. It is far, far more than just an 'organisational aid'. For example, it means that your application can be cleanly and transparently extended by future developers - even without the code.
For example, if you write code that processes an 'account', some future developer can use your code to handle account subclasses ('customerAccount' etc), due to inheritance and polymorphism. There is no need for you to modularise or re-organise your code.
There's no reason that you can't write in an OO style with C, for instance.
You can attempt to implement inheritance and polymorphism in C (there was a Byte article about in in the early 80s), but the result is a mess.
A colleague of mine once remarked that there is currently a trend to dumb our kids down by teaching them that solutions to problems can be found by throwing design patterns at them until one fits, and if none do, to make one fit. OOP is not the answer to everything. Sometimes nothing beats a good Perl script.
Actually, I strongly agree. I think that the increasing use of design patterns can stifle creativity. However, I think that OOP is another matter altogether. Showing that OOP can be used at all levels is not to show that it need be used at all levels. What I would want to avoid is the idea (depressingly wispread) that OOP is some high-level extension to procedural coding, and can't be used effectively and lightly everywhere if you like.
All I am saying is that playing first with Smalltalk or Ruby and even adding new methods to simple types such as Strings or numbers is a great way to understand what OOP can really do, before the developer most likely moves on to the more constrained and pragmatic approaches of, say, Java or C#.
If you're training a bunch of Arts students maybe, if you're training the next generation of developers, C is the way to go.
Absolutely not. I find it hard to think of any mainstream uses of C that can't now be handled by a safer, more suitable managed language.
C forces good coding practices (not structure =)) while Java encourages sloppy coding with no regard for any optimization.
How on Earth did you get this idea about Java? Good design is as important in Java as in any other language. Just because you can get good run-time performance from Java and other managed languages from run-time optimisation does not mean that slopping coding is acceptable.
Teaching C gives a false impression of what current and future mainstream developers need to know - manual memory management, identity between pointers and arrays etc. These may be vital for device driver developers or compiler writers, but are of no relevance to web coders or financial developers.
You always get sloppy coding. In Java you are usually protected from the results. In C the results can be disastrous. The aim should be to teach quality coding while protecting the developer (and user) from the consequences of inevitable mistakes.
Slashdot Mirror
In that context, it is impossible to teach OOP alone; it inherently builds on the concepts of procedural programming.
I don't quite understand what you're driving at when you talk about teaching OOP first and from the start. How can you teach OOP without teaching, say, functional decomposition and structured programming?
I had what I thought was a really good example of how to do this from years back - it was the tutorial for Digitalk Smalltalk in the mid 80s. It had a superb introduction to OOP that started from the simple basis of everyday arithmetic and how this could be considered to be messages, and built up from there. This was development for absolute beginners - no mention of functional decomposition or structured programming. And it worked! It had been demonstrated to work a decade earlier during the early development of Smalltalk.
I am not saying this is the way I would do it - just that you can teach pure OOP in isolation.
I would say that inheritance was the most over-used tool in the OOP world; I've seen countless occasions where composition or some other form of collaboration between classes would provide a far more flexible design. Indeed, I have often wondered whether the only time one should use inheritance in a robust OO design is when polymorphism is to be employed, since anything else binds more tightly without gaining any particular benefit over composition.
This is why we differ, or rather, why we don't! I was not talking about the OOP world - I was talking about how languages that have the potential to use OOP for development are used in practice by a very large number of developers - about how developers are using C++ like C, or how they are using Java as simply a set of rich libraries, and barely using any OOP facilities in their own code. I agree that inheritance can be overused by people who use OOP heavily, but that was not my point.
I don't believe that throwing students in at the deep end with Java or the like really works, because it's been common practice in many academic institutions for years; if it worked, we wouldn't be having this conversation.
And I agree with this too, because Java is a complex mixture of paradigms.
Alas you are presuming all that goodness you got with java comes at no cost. That's not true. It comes at the cost of developer productivity.
No, it doesn't. I can design my classes visually and have the schema generated at the click of a mouse. The debate about developer productivity with dynamic vs static languages has been going on for decades, and has come to no conclusion one way or the other. Simply to state that Ruby is more productive to deny the existence of that ongoing debate, and is without foundation.
You will probably disagree with that statement but the legion of java programmers who have used rails tell us otherwise.
Legion? That is a strong statement, and requires evidence. Sorry, but I just don't believe it without firm numbers.
I haven't been constrained by Rails's SQL generation yet.
:)
Sorry if this sounds impolite - but I think you have, but you just don't know it yet
And you didn't answer my question. When does it *really* matter?
When performance really matters. I deal with transactions of hundreds of thousands of records, and they need to be fast. This requires optimised SQL.
Also, maybe it is just me, but if my boss has spend thousands on a high-performance database with lots of features which can improve performance, I would feel foolish if I didn't use them!
After doing reporting for twenty years across many projects I've seen most reporting tools out there. If you consider JasperReports powerful then you really don't understand reporting.
The poster was asking to hear about a product that allowed use of an ORM portable query language; that is the reason for mentioning JasperReports.
Hmm, having perform many ports between database products I can honestly say that I've never bumped into this problem outside of SQL Server/Sybase stored procedure insanity. The most often case is 10% of your queries might require a tweak. 1% might require a rewrite.
Hmm, well, I deal with this on a daily basis. It is nothing like you describe. I am involved in porting projects that take months, and I know many others who have had to deal with the same issues.
So, to avoid this you wrap the entire language in an entirely new language? That itself can't support 100% of the features of the first, and isn't usable by everything that supports the first?
The languages are standardised, and they can support all features.
Hmm, I think people should actually learn how to use databases before coming up with ingenious work-arounds like:
- Object Oriented Databases - that can't handle sequential scans, reporting, searching.
- Hierarchical Databases - reinventions of technology thrown away in the 80s.
- XML as a database - completely misses concepts of ACID, concurrent users, sequential scanning
- wrappers to help programmers avoid learning the lingua franca of databases (SQL)
I am not talking about these! I am not talking about OOP, hierarchical databases, or XML.
I am talking about SQL-like languages (that DO require you to understand SQL and its concepts - this is, of course, essential) but allow true effective portability.
Sorry to be so negative towards your point, but I've been on multiple J2EE projects where programmers adopted some brilliant idea like OODBMS, container managed pesistence, or sometimes just EJBs - only to discover later that the way that the java community thinks about data only covers about 50% of its needs.
This is why I was talking about more research needed by posters, as if you think that modern ORMs force any of the above solutions, you are way out of date. I am not talking about OODBMS or container managed persistence! I am talking about rich, lightweight object/relational mapping systems that allow full use of the underlying databases.
Almost as bad, they prevent OOP playing nicely with other programming idioms that, as you observed yourself, should be orthogonal to the use of objects, not in competition with it. I realise that not all OO languages have these limitations, but the mainstream ones all do, and I would argue that this is what most people think of when they talk about OOP.
Yes, but why should this failing prevent the use of OOP when it's use alone (without the use of other idioms) is more powerful than procedural alone?
write code for a living.
Me too.
I've worked on large-scale projects in OO languages, and seen the power of an effective design taking advantage of polymorphism first-hand.
Me too.
But I also have an academic CS background, and experience of other programming styles.
Me too.
After many years of doing this stuff, I'm more convinced than ever that while OO provides a model of certain ideas that is useful because it's accessible to a wide range of programmers, ultimately it doesn't really have any unique ideas of its own. It simply emphasises particular aspects, and presents a particular view of some general ideas.
And I could not disagree more. I think ideas such as inheritance and polymorphism are unquestionably unique and distinctive aspects of OOP, and vastly underused in the software industry. I think their use needs to be far more widely encouraged in order to improve developer productivity and code quality.
Say that's true. When does it matter?
Suppose someone taught you how to drive a car, but would not let you go beyond third gear, as not all cars have more gears - would you be content? Of course not! So why are you happy with Rails only using 3 of the gears with its SQL?
And how does Rails prevent you from changing it?
Rails doesn't - you can always implement your own automatic sensing of database capabilities and patch in use of extra SQL where feasible.
But this is really dumb! There are products that do all this for you - why should you have to do this yourself? It is so primitive.
the biggest one is running on virtually anything. no other language even comes close. With many processors (particularlly low end stuff) the choice basically comes down to C or assembler.
True, but Java use in this area is growing dramatically.
IMO its best to teach a language thats as close to the metal as possible (assembler for some simple processor like a PIC may even be a good starting point) first then teach more advanced tools later.
For technical use, sure. For general use? I don't think so.
sure if all you ever wan't your students to do is code similar apps over and over in an application category where performance isn't considered to matter (e.g. boring buisness apps) then go ahead teach people the high level languages first and let them think that what goes underneath is black magic.
This is just not true. Performance matters in business apps too, yet there is simply no need to understand the architecture. The optimisation techniques used by general coders don't need such an understanding. There are many very high-performance multi-threaded portable applications written today that have not required the developer to know anything about the underlying processor architecture.
That stuff sounds really interesting. Do you have links for some of the research?
Yes. The best place to look is the specifications at the JCP.
JDO 2.0 is
http://www.jcp.org/en/jsr/detail?id=243
EJB 3.0 (including JPA) is
http://www.jcp.org/en/jsr/detail?id=220
I've heard of hibernate, but not the JPA. Is that going to be part of the standard JRE? I hate having my code rely on goofy 3rd party add-ons.
JPA is going to be a standard part of J2EE, but can be used stand-alone with JRE. There are many vendors providing implementations - Sun, Oracle, JBoss, BEA, JPOX, Versant. A significant number of these are going to be open source (JBoss, Oracle, BEA). Hibernate is also going to provide an implementation of JPA.
I rarely use SQL in my Rails apps. Pretty much only need it when I need to optimize something, which doesn't happen too often.
It is not just how you use SQL, it is how Rails uses SQL transparently - it is still a non-optimal subset of SQL rather than the rich full-featured and optimised SQL that other ORM systems generate.
I don't understand why you think Migrations are configuration files. What makes something a configuration file? What makes something not a configuration file?
Migrations contain data about columns and their types. This is in a Ruby script.
Java JDO has files that contain data about columns and their types. This in an XML file.
Looks the same to me. Just because what you do with the data in Rails migrations is explicitly stated in the files makes no difference in my view.
Why the horror about configuration files? They can be a huge benefit, isolating your code from changes.
Great, "rich query languages" that wrap richer query languages.
No, in some cases the portable query language is more featured that the language it wraps. JDOQL implementations can provide rich querying even on systems with no built-in query language (like filesystem storage).
That are highly portable across databases, but themselves are not portable across application layers (do *any* reporting tools support them?
Of course they are. There are reporting tools like JasperReports that can use Hibernate Query Language directly.
is there an ANSI standard for ORMs?)
There are JCP standards for Java ORMs that are fully supported by many vendors.
Is there any modern standard for SQL that is fully supported by any vendor? No.
When a developer needs to run adhoc queries in order to diagnose problems with data in a database, to test impacts of schema migration, etc - do they write SQL or application code? Keep in mind that these are not likely to be simplistic queries...
They can use either. Why on Earth are you assuming that these portable query languages are restricted to simplistic queries?
Seriously SQL isn't the greatest language in the world, but I have a hard time understanding why anyone that works with database applications can't handle complex queries.
You are missing the point. Of course they can handle complex queries. What they don't want to have to do is to re-implement thousands of those complex queries in order to migrate to another database product.
It's like someone working on the linux command line that refuses to learn bash. Or like a web developer that refuses to learn HTML and just uses FrontPage instead.
No. The portable query languages aren't less rich than SQL. They are simply portable. That is the big difference.
And aside from the "When in Rome" argument, consider the benefits of learning a data-oriented approach to working with data.
Who says this isn't the case?
SQL is more different from java, python or ruby than lisp is. One of the best things a programmer can do is to to become fluent in multiple different types of languages. Compare SQL's set-based logic to lisp or python. Learn to think of data in terms of sets and aggregates instead of just one row at a time. Until you do that you'll never understand reporting, which is really about how to answer basic business questions.
This is completely irrelevant. Portable query systems in Java are data-oriented, and work with sets and aggregates just like SQL. The difference is that they are 100% portable.
But maybe that's why we've never seen a powerful reporting tool come out of the java community?
No - you have never seen a powerful reporting tool. This does not mean there aren't any. There are plenty.
JasperReports is a good one.
I think posters really need to do some more research before commenting on matters like this - I keep reading posts like this that bear little relation to reality.
actually, you can generate DDL from an OO class definition in Rails by using migrations, which is the built-in way Rails handles updating databases to the current version. you do "script/generate migration " and a skeleton gets generated for you, and then you fill it out. then just run "rake migrate" and DDL is run that generates your tables.
I know about this, and definitely approve - it is a big step forward for Rails into becoming a modern approach! Actually, I find it rather amusing - it involves basically the kind of configuration files that earlier versions of Rails stated were to be avoided and were unnecessary (just because the config files are written in Ruby does not make them any less config files!).
However, it is still way behind other products. Firstly, it is limited to only a few databases out of the box. With my Java ORMs I can almost any database with a modern JDBC driver (and that is a lot).
Contrary to the article you provide, seeing data-safe schema upgrades done automatically does not 'blow my mind', as I was doing that with a Java JDO product years ago!
Also, this in no way overcomes the limitations of Rails use of restricted native SQL - a very poor substitute for having a portable standardised query language (like JDOQL) that is dynamically translated to optimised vendor-specific SQL at run time. Java products have been able to do this for years.
Rails may be advanced and exciting for developers who have used less structures systems, perhaps based on PERL or PHP, but for many of us it has a long way to go to catch up with where modern ORM products were years ago.
As far as "hard to port" SQL, unless you're using MySQL or old versions of databsae apps, this isn't too much of a problem for most SQL heads, even when you throw in database-specific functions or idioms.
That is easy to say until you are dealing with tens of thousands of lines of legacy SQL.
And it all depends on how much trigger/stored proc code you have to migrate. Tables/Views are pretty simple to move.
Not really - just look at the range of different column types in PostgreSQL or Oracle - converting is not trivial, especially when you have BLOBs or CLOBs.
My point is that there are well-established and highly successful ways to avoid all this - I find it hard to believe that in 2006 we are still writing new application code that uses SQL directly (like Rails).
Anything that causes a person not to reproduce is (eventually) selected against. For example, being sensitive to the meme "there are too many people on this world" is an evolutionary disadvantage and will eventually be removed from the genepool. The same goes for high intelligence (being that intelligent people often don't reproduce).
No, this is far too simplistic. Evolution is based on genes, not people. In some cases evolution can favour individuals not breeding as long as a significant fraction of their genes are passed on - which can involve assisting siblings or parents to help bring up children. This happens a lot in Nature - social insects, and in many mammal and bird species.
To put in more simply, what matters is whether the family as a whole (i.e. close relatives) reproduce. A sensitive or intelligent person may not have children themselves, but may bring assistance or income to help close relatives.
One thing I like about ActiveRecord is that it is database agnostic. If I need to, I can move my app from MySQL to Postgres to Oracle with very little effort.
You can move your app, but how much effort is there in moving your data model? For serious apps, quite a bit. Oracle has seriously different types of columns and restrictions on columns from Postgres or MySQL, and if you want to use really efficient SQL, you have to use SQL that is hard to port (MySQL has only recently got subselects, for example).
This is why I think working in the opposite way to Rails - designing your data model in terms of classes and letting the ORM product generate a schema from that (still DRY, but in the other direction) makes far more sense - I can move my apps between those databases with no effort at all.
Due to the issues mentioned I will probably move away from Hibernate towards something else.
:)
I use a JDO product (Kodo) for very large transactions (hundreds of thousands of records), and it works very well and fast. Hibernate was, according to the developers, not intended for this sort of use - which I interpreted as a coded way of saying 'it is too hard to run write our stuff to run efficiently like that and we aren't bothering'
Hibernate is extremely popular, but, in opinion, far from the best. The Kodo OSS implementation of JPA is something I am eagerly awaiting!
JPA, Hibernate etc... are very powerful apis, but they are way to complex for a RAD approach and they all have huge areas where they need to be cleaned up instead of being carried over to the next API. The biggest one of them IMHO are the areas mentioned.
Good post, but I would disagree with some points. I don't think Hibernate is the easiest API - I far prefer JDO. Secondly, you don't have to use all that locking or use of lazy objects - you can use it in a very simple manner. The use of those features is for optimisation. Finally, if you want great documentation, use something other than Hibernate - JPOX and Kodo are JDO implementations with superb documentation.
No matter what some of the issues are, I don't think anyone can deny that the Java approaches have far more power and flexibility than Rails, if you want to move beyond simple RAD tasks.
What turns me off is forcing you to store all your data persistence into SQL and relational tables, when it is clearly a hierarchy of objects. Why does everyone think they have to do that? The software would function much more simply and the data would typically work better without it.
It is great to see that developes are finally beginning to see the downsides of Rails!
The thing is, not everyone does think they have to do that! There are perfectly good high-performance ORM systems that do allow you to work with a hierarchy of objects and use rich but portable query languages - examples are Hibernate, JDO and the soon-to-be released JPA (Java Persistence Architecture).
They are as DRY (don't repeat yourself) as Rails, as with quality implementations you can automatically generate schemas from objects, or get object hierarchies generated from schemas, and they don't have to rely on endless configuration files (you can define minimal relational information as annotations in your objects).
Also, unlike Rails, they are extremely portable. You aren't restricted to a subset of SQL to get portability. You can use a full and rich query language (like JDOQL 2.0) and that is automatically translated to high-performance vendor-specific SQL for whatever database you are using. Even if you don't want portability, the ability to do this means you get high-quality SQL largely automatically.
Unlike Rails, they work extremely well with both legacy schemas and schemas that are shared with other applications a developers.
Unlike Rails, some of these APIs (JDO) don't restrict you to relational systems - you can persist just as easily to things like object databases, SOAP services, LDAP, text files, filesystems etc., without changing a single line of code, and all the while using a rich query language!
These products and APIs are available right now, have open source implementations and have been used successfully by a very large number of developers for years.
My view is that they make Rails look primitive.
btw, that inheritance+polymorphism "mess" is what powers gtk, not defending or attacking, just stating. Probably a totally different implementation too.
I'm sure they had good reasons. However, my point is that there is no point implementing OOP-like behaviour yourself in a non-OOP language unless you have exceptionally good reasons.
OOP is good for object-oriented tasks.
Depending on the language, that can mean anything. In Smalltalk, every task - even storing something in an array is 'object oriented'. Even in Java, any part of software design can be object-oriented as you can enclose your design in classes for potential re-use.
The biggest problem that I see is that when people use C++ they suddenly feel the need to approach everything from an object-oriented perspective, and they begin by picking the wrong objects with the wrong attributes. To pick good object properties, you don't need to understand OOP, you need to understand the problem you're trying to solve and have a clear idea of how you're going to approach it. The key to OOP is design, not the language you're using to do it.
Of course you need to understand OOP to pick good object properties, as you need to understand how those properties can be used for inheritance and polymorphism.
The big problem I see is developers choosing a language with OOP and not realising all the things that they can use it for. They produce repetitive code that is hard to maintain because they don't know about interitance and polymorphism.
Did you say C# and constrained in the same sentence? It seems to me that C# is designed to break all that is sacred in the OO paradigm (I'm looking at you, keyword new).
By constrained I meant not being able to use OOP at all levels.
There is nothing wrong with the new keyword! It has a long history of use in OOP languages.
However, C# is heading is dangerous, messy directions.
unless you're going to be using polymorphism, I don't see any reason to use inheritance. If I want to use the functionality of one object in another, I just create an instance of it there.
That is uncessarily slow (you are adding an unecessary function call that can't be optimised), and breaks any possibility of polymorphism. Handling this by inheritance is so much easier.
Of course, there may situations where you aren't allowed to instantiate the thing you are inheriting from - the class may be abstract or have a hidden constructor.
Sorry, but I just don't see any advantage in not using inheritance.
Certainly if you use a language with generics, which I take Smalltalk to be from you example, you have inherent polymorphism. But that is a design descision built into the language.
Smalltalk does not have generics - it is dynamically typed.
To make another example, you don't have to think about the modularity of your design when you make a java GUI. That is because the java GUI API already has its modularity defined. There is a given class heirarchy that you are using. And this certainly can be a joy.
Actually, the Java GUI Api is an example where you have to use inheritance to be effective - you have to extent (for example) JComponent.
You don't have to think of modularity to use polymorphism - you just use it. I don't understand what you mean by this requirement.
An example in Java 1.5:
List myList = new ArrayList();
MyList can handle instances of my Account class. But it can also handle any future subclasses of Account that I (or any other developer) create. This is enormously powerful.
Unless you're going to be using polymorphism, I don't see how OO really adds anything to programming.
:= Collection new.
What about code re-use through inheritance? I use that extensively.
And the trouble with polymorphism is that to really use it effectively you have to plan in advance how you're going to break your program into modular pieces.
You do? Look: I am using polymorphism in the following Smalltalk code:
c
c add: 1.
c add: 1.2.
c add: 'String value'.
No modularisation needed there.
I really do feel that OO is an organizational aid more than anything else.
No, it is a fundamentally different approach to development, and should be understood by any skilled developer. It is far, far more than just an 'organisational aid'. For example, it means that your application can be cleanly and transparently extended by future developers - even without the code.
For example, if you write code that processes an 'account', some future developer can use your code to handle account subclasses ('customerAccount' etc), due to inheritance and polymorphism. There is no need for you to modularise or re-organise your code.
There's no reason that you can't write in an OO style with C, for instance.
You can attempt to implement inheritance and polymorphism in C (there was a Byte article about in in the early 80s), but the result is a mess.
A colleague of mine once remarked that there is currently a trend to dumb our kids down by teaching them that solutions to problems can be found by throwing design patterns at them until one fits, and if none do, to make one fit. OOP is not the answer to everything. Sometimes nothing beats a good Perl script.
Actually, I strongly agree. I think that the increasing use of design patterns can stifle creativity. However, I think that OOP is another matter altogether. Showing that OOP can be used at all levels is not to show that it need be used at all levels. What I would want to avoid is the idea (depressingly wispread) that OOP is some high-level extension to procedural coding, and can't be used effectively and lightly everywhere if you like.
All I am saying is that playing first with Smalltalk or Ruby and even adding new methods to simple types such as Strings or numbers is a great way to understand what OOP can really do, before the developer most likely moves on to the more constrained and pragmatic approaches of, say, Java or C#.
If you're training a bunch of Arts students maybe, if you're training the next generation of developers, C is the way to go.
Absolutely not. I find it hard to think of any mainstream uses of C that can't now be handled by a safer, more suitable managed language.
C forces good coding practices (not structure =)) while Java encourages sloppy coding with no regard for any optimization.
How on Earth did you get this idea about Java? Good design is as important in Java as in any other language. Just because you can get good run-time performance from Java and other managed languages from run-time optimisation does not mean that slopping coding is acceptable.
Teaching C gives a false impression of what current and future mainstream developers need to know - manual memory management, identity between pointers and arrays etc. These may be vital for device driver developers or compiler writers, but are of no relevance to web coders or financial developers.
You always get sloppy coding. In Java you are usually protected from the results. In C the results can be disastrous. The aim should be to teach quality coding while protecting the developer (and user) from the consequences of inevitable mistakes.