Slashdot Mirror
Exploring Active Record
An anonymous reader writes "Everyone knows that no programming language is a perfect fit for every job. This article launches a 'new series by Bruce Tate that looks at ways other languages solve major problems and what those solutions mean to Java developers. He first explores Active Record, the persistence engine behind Ruby on Rails.'"
By looking at Active Record Java developers can be happy and thankful they have a language taking good advantage of Unicode, unlike Ruby which treats users of non-ASCII alphabets (the overwhelming majority of people on Earth) as second-class citizens thanks to poor Unicode support.
I've volunteered to create a recipe-wiki-site-thing for a friend, and coming from a background in C and SQL there was just too steep a curve to map a procedural train of thought and pre-planned SQL onto the Rails way of doing things. I already created the database schema, wrote all the SQL to get the information I want, have a lot of HTML written for the general template, and was looking at abandoning much of it for controllers, models, automagic foreign key relationships, automagic methods popping out of thin air.. I wanted more control I guess.
So I've done most of the site in PHP instead. Direct, to the point, fast enough (though I'm thinking about a rewrite in C for a pure CGI/FastCGI binary), a minimum of automagic hand-holding - just start each page with sanity checking, authorization, the SQL the page needs and nothing more, and then format the output. No wondering how many hundred methods have been created that I don't know about, what happens when a record is deleted/updated (I'll let the database handle null/ignore/cascade thankyou) or whatever else Rails is doing behind my back.
I'm a C guy - I don't like things being done that I don't explicitly ask for. I want init() functions. I want implicit declarations. Heck I don't even like C++ for fogging-over-functionality with inheritance, virtual functions and overloading.
Ranting aside, I can see how Rails would mesh with a lot of people. But it's definitely not for me, and I guess (hope) a few other nutjobs around here.
Don't Hate, Gestate
People, and usually not developers, are still caught up in the idea of a programming language instead of the concept of applying an API or SDK to a task. My favorite example of this is the often held C++, C#, Visual Basic debate -- everyone has their syntax preference, but at the end of the day its the paradigm you apply that matters and not the language.
A politician giving an address in German instead of French is not more effective as his points will still remain the same. The language isn't the tool, the intention is the tool.
I like rails, but the poor apache integration sucks.
But ActiveRecord is awesome. Most of us build databases that work like objects already.. so an object oriented interface to your database is very easy to use and maintain.
Kind of ironic, really, given that Ruby actually comes from a country that uses a non-ASCII alphabet... well, not really an alphabet at all, actually.
Everyone knows that no programming language is a perfect fit for every job.
I program in raw machine code. It's a perfect fit for every job, every time!
-William Brendel
Here, we simply drag and drop then program the logic behind all those widgets we've dragged onto the form. I also looked for something in relation to Python but could not find anything! I taught VB myself using this method. Current IDEs I have looked at make things confusing. Am I looking for what does not exist? Hope not!
Active Record is just the name of the persistence layer used in Rails, not some attempt to call persistence a new technology.
I don't want to start a language war, because there are a lot of things that Perl is very good at. But I've done medium-scale application development in object-oriented Perl, and I came away from the experience convinced that object-oriented Perl just doesn't work very well above a certain scale -- very few of the things that make it easy to abstract things and work with multiple developers on a common project are there. As always, YMMV based on particular circumstances.
Ruby's syntax is similar to Perl for a number of areas, but the object orientation is a lot cleaner. Neither Ruby the language nor Rails the framework is perfect, but it can be a very productive toolkit for MVC web applications.
An object-relation mapping (ORM) that "just works" and uses reflection on the database to produce business objects without the developer writing more than 3 lines of code is anything but a minor improvement. ActiveRecord is also more than an ORM. It allows developers to declare that an object "acts as a list," which then allows the object to be sorted in an array. There are many other such "meta-programming" constructs in ActiveRecord.
It also gives you a lot of stuff for free; migrations from one database schema to another, for example, are wrapped in ActiveRecord calls and are thus database-agnostic. You don't have to worry about packaging one SQL update file for MySQL and another for Postgres and another for MS SQL. The console is really cool too...it allows you to interactively play with your objects. You can even run it in 'sandbox' mode, so that all of your changes are rolled back when you're done playing.
You haven't the slightest idea what you are talking about. It said right in the article it was an ORM - you're acting like it was hiding this fact in order to hype it up. I guess we have reached the pinnacle of ORM design, anyhow, because Animats already wrote something similar in Perl. Have you ever used ActiveRecord? I have; it's quite an interesting ORM, unlike others I have used before due to the heavy reliance on polymorphic method naming.
Really, did you even read the article?
everyone has their syntax preference, but at the end of the day its the paradigm you apply that matters and not the language.
.NET development house. You may not understand why C# is better for you than C++, your productivity may not increase, but the fact that you have switched means that your software will ultimately still cause fewer problems.
The differences between C++, C#, and VisualBasic are far deeper than syntactic. C#, for example, guarantees fault isolation, while C++ does not. C# has full reflection, while C++ does not. Programmer productivity in different languages can be orders of magnitude different.
Of course, most working programmers have the same superficial view of programming languages as you do and will make the same glib and ill-informed analogies to natural languages that you did. That's why people keep choosing C and C++, believing the differences to other languages to be merely syntactic, and then producing code that crashes, silently mangles data, and has gaping security holes.
Fortunately, the herd mentality is driving even people who don't know what they are doing away from C/C++. Even your own company bills itself as a
I have to give a shout-out to Ruby on Rails and database handling - specifically for the new developer. I've seen clients of mine (whom I consult and help deploy Rails apps) new to OO latch on to ActiveRecord very quickly, and the rapidly growing support (and marketing!) for the Rails community is promising for its long-term success.
Kudos to Yukihiro, David, Dave, Thomas, and the hundreds of others who have put together Ruby and the Rails framework to help developers grow the Web 2.0.
~William
www.RailsHosting.org
I'm amazed, a whole article by Bruce and not a single anecdote about kayaking. His writing is improving. :-)
Being bitter is drinking poison and hoping someone else will die
I think that you're missing the point. There's more to ActiveRecord than just DB wrapping: It's Ruby's strengths of reflection and meta-programming, and being able to dynamically add methods and properties to objects at runtime that allow ActiveRecord to really fly, and that is why people get excited about it. Sure you can still do these things in Perl, but it's more painful.
I recently wrote two applications that included a registration form, validation checks, sending email with a URL to click to confirm the registration and finalizing the registration.
I wrote the first one in Java and the second one with Ruby On Rails, to learn the language and experiment with the framework. The Rails application needed half as much time to be coded than the Java one, despite being totally new to Ruby and to Rails.
The merit goes almost entirely to ActiveRecord and expecially to the validation feature.
Another time saver is Ruby's being interpreted instead of compiled. That saves a few time at every change to the code, even if strong type checking at compile time would have occasionally saved me a lot of time. It's difficult to assess if I gained or lost time.
What I'm looking forward to now is a good ActiveRecord implementation for Java because Rails is great but Ruby's syntax is really appalling. Even Perl (admittedly one of my languages of choice) looks more consistent. On the other side, halving development time is something that tempts me a lot. Java on Rails would be great.
I've been playing around with Rails and AR quite a bit lately, and it has changed the way I think about programming in many (positive) ways. I come from a heavy Java / J2EE background (do that for a living, serverside systems), and Ruby + Rails is a breath of fresh air. Ruby is simply a wonderful language, there is something very "zen" about it, and Rails is inspired. Sure, it builds on a lot of old concepts, but the brilliance is where it leverages the power of the Ruby language to do things in very efficient and nice ways.
Yes, there is a lot of "black automagic" involved in Rails. It's where the power is, and you can override pretty much everything is you want to. If you're uncomfortable with magic stuff happening behind the scenes and don't want to learn Ruby so you really understand that magic, Rails might not be for you.
I'd claim that pretty much every serious programmer (VB scripters don't count :) should learn Ruby, at least the basics. It might not become your new favorite language (like it has for me), but it will give you a fresh new perspective on how to code stuff.
Ruby does have a few downsides:
(there are probably more, but I'm still only learning the language)
As for Rails, well, again there are downsides. Nothing is perfect.
So: it's not a silver bullet. Nothing is. But for a large majority of the modern-day web app use cases, it's very nice, productive and, well, elegant. It lets you to do quick prototypes and keep your code clean, you don't end up with the insecure and ugly mess most PHP apps end up being.
The current engine's something like a decade old, so it's hardly surprising. Ruby 2 is supposed to greatly improve support for Unicode, along with just about everything else.
What a revolutionary insight of a Java-follower! Congratulation, when looking at all these language flamewars, its extra ordinary that anybody can mention this and even be published by a company which bases their SW business on Java.
... (not enough knowlegde to make recommendations)
I'd like to give Bruce Tate or IBM some tips in which direction they might venture to get more insight:
- Web-Clients: HTML + Javascript with the Dojo toolkit (http://dojotoolkit.org/)
- Web-Servers: PHP/Perl/Ruby/..., whatever you like
- Binary applications: C++ with the wxWidgets framework (http://www.wxwidgets.org/)
- Database: SQL with
There are probably many more areas with recomendations but not from me, so just add your own. But think there isn't a perfect language for everthing so it should be now clear that one needs a multi language strategy to become or stay successful.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
whats the matter.. you couldnt understand RoR? Your statement about access is so far off base that I doubt you have ever read more than crappy slashdot posts about it. you have fud packed so far up your ass its coming out of your mouth.
If something exists that does not need a creator (god) then why must the cosmos need one?
Oh, get over it. Does this have to happen any time anything developed less than 10 years ago is mentioned on slashdot? Ruby on Rails being the current favourite example. Here is how it goes every time...
Article: "here is a link to an interesting review of (insert technology here)".
Random guru: "That's nothing! I wrote something similar myself 6 years ago using perl/punchcards/blood from my own hand!"
Elitist Java developer: "Hahaha! You amateurs! How does your pathetic toy deal with redundant HA database clusters in a real-time mission-critical enterprise environment with a 5-nines uptime guarantee? Come back when you've grown up!!"
And so on. Personally, I'm a big fan of Ruby on Rails. I'm rather bored of seeing it compared to Java, a language I have never used. I moved to RoR from PHP, and let me tell you, its like a breath of fresh air. Yes, I could develop the exact same websites using PHP, but it involves writing a lot more code. Aren't computers supposed to do mundane work for us? Why make life difficult for yourself - I'm interested in results, not in worrying about whether I've escaped my SQL queries correctly using some function I had to write myself because PHP can't even do that properly.
Bottom line - RoR means better sites with less work. And that means more time to concentrate on making sites better for users, which is really what its all about.
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.
Maybe it's okay with things like EUC-JP and SHIFT-JIS but not okay with Unicode... who knows, I've put off reading that part of the book for ages.
Karma: It's all a bunch of tree-huggin' hippy crap!
Java though, treats people who want to use UTF-32 as second-class citizens. It's perverse too... we were all taught in University that Java supported Unicode, and then it was only in the real world where we discovered that it didn't support things like surrogate pairs. And don't try to tell me that 16 bits is enough bits to store every character you'll ever want to display or print.
Karma: It's all a bunch of tree-huggin' hippy crap!
I'm pretty sure it does in fact use one of those sort of schemes, which have been in common use in Japan for much longer than Unicode has existed. I'm not certain though, as my grasp of Japanese is far too tenuous to worry about being able to type it. :)
"Hahaha! You amateurs! How does your pathetic toy deal with redundant HA database clusters in a real-time mission-critical enterprise environment with a 5-nines uptime guarantee? Come back when you've grown up!!"
Rails is scalable, but not in an interesting fashion at all. You want more processing power, you run more instances. Where's the fun in that? I love it in Java land, where creating something scalable inevitably means exciting things like building a single JVM that runs on multiple machines, or wrapping things in five layers of EJB so that they can work across multiple machines.
Karma: It's all a bunch of tree-huggin' hippy crap!
I've recently been writing a project with Rails, using MySQL as the backend. Supporting UTF-8 has been no problem at all. UCS-2 support may well be lacking, but it's certainly not like you can't support people with non-ASCII alphabets.
PenguiNet: the (shareware) Windows SSH client
Java though, treats people who want to use UTF-32 as second-class citizens.
Java has support for Unicode 4 since Java 5, released september 2004.
Being bitter is drinking poison and hoping someone else will die
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.
Yes, Ruby and it's author have an interesting attitude to string representation in general and Unicode in particular. It's partly what inspired me to write this:
Psychology of Unicode in Japan
It's really been a very interesting struggle between people's psychological and I.T. needs -- a struggle that's pretty well over now, but has left behind things like Ruby's way of doing things.
Whence? Hence. Whither? Thither.
I worked on mainframe 4GL systems nearly 20 years ago that could do screen to record mapping. Likewise, MS Access has had the same functionality for a long time.
The point is that ActiveRecord type technology is nothing new, nothing revolutionary. It's also very seductive, until you actually start using it for real, and find that in a lot of environments you don't simply do a table read/table update for a lot of applications. You often need to take a view of data across many tables, or do updates that are more complex.
Well lets say it that way, I have been using hibernate for quite a while and it has a lots of quirks, the most annoying aspects of it, for many is: a) many to many mappings which simply need more documentation, the best way to do is is to enforce surrogates on the many to many tables otherwise you will often run into implicit clashes via compound keying (rails already enforces it, hibernate does not, it is not documented but after many hours of trying to fix this problem on a compound key I came to the conclusion there is no sane other way to handle it)
b) The whole locking, merge save, update, persist api is a huge mess, which was carried over to a big degree into the whole jpa, partially also caused by a huge lack of documentation in exactly this critical area. (90% of all problems regarding saving usually circle around the lock persistence functions and many to many resolution)
Having to juggle with lazy non lazy objects, with merge, save, update, lock, persist wich all do almost the same but not exactly the same, with referencing issues on many to many relationships etc... Is nothing I would call a walk in the park either.
I was at a conference a while ago where one of the people hosting the conferences said, that one thing many frameworks simply have lost is the KISS principle, and the guy clearly said, the perfect example is Hibernate where someone has to be an expert in it to be able to handle it. And Hibernate is considered to be the one of the easier ones in the java world. And no this guy knew what he was talking about, I have used hibernate very often and I agree with him.
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.
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.
You bring up a point here with using something else, until recently Hibernate was the only OSS based implementation of an ORM system usable and coming close to being a standard and having good tools, now that JPA is out, we have finally a good number of them all based on JPA:
Hibernate, KODO JPA, Toplink JPA all OSS based on various licenses. Due to the issues mentioned I will probably move away from Hibernate towards something else.
The main problem with Kodo simply used to be the price which was way too high for small developments, and still is if you need KODO JDA, but the JPA implementations are there now or will be there soon and usuable for a budget.
Apart from its inherent inadequacies compared to 'real' databases, what's the big disaster area about Access? What do people do horribly wrong, and what's the wonderfully better approach?
Real Daleks don't climb stairs - they level the building.
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!
Well KODO is considered to be the best persistence layer for java around, I am glad that Bea decided to opensource the KODO EJB3/JPA layer under an Apache license. And I agree Hibernate is subotimal, there are issues with performance in certain areas, there are issues with mass data, and the whole many to many handly in combination with some of the Hibernate core people (not Gavin King he always is nice) in the JBoss forums gives it the rest. I cannot await to move away from Hibernate towards EJB3 JPA based on Kodo.
accordingly, things i dislike about active record:
1) it seems to mirror tables pretty directly;
2) i don't think the objects you work with in code should know how they are stored - this means they don't inherit or mix-in any database code at all. there should be separate classes that handle this.
this holds for other languages too, of course. python in this case:a Ticket may consist of data aggregated from several tables; the client code doesn't care about that. the TicketStorage class worries about storage.
now, inside TicketStorage, you might use your ORM of choice, or access the DB directly, or whatever. the point is, the public methods of TicketStorage draw the line in the sand between the code using the Ticket objects and anything storage-related.
that's my preference from a design perspective, anyway.
free software, open standards, open file formats, no software patents.
People just getting in to rails and ruby are not likely to have done more than scratched the surface of what ActiveRecord is capable of. This is a great introductory article, but I'm curious just how far you can push ActiveRecord.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
What's so hard about that?You're not confusing ActiveRecord with Scaffolding are you? Nobody uses the latter in the real world.
In fact, rather then ASCII Ruby was designed with SHIFT-JIS, a sort of japanese ascii.
autopr0n is like, down and stuff.
Well, java is older then utf32, but whatever.
autopr0n is like, down and stuff.
Do you use any of the Class::* modules?
I use Class::MethodMaker. It's nice for declaring member variables but OO is pretty clunky it perl 5, and Perl 6 doesn't seem much better.
Fascinating write up. I had no idea there was such a debate even going on. Excellent work.
My comment about Access is admittedly a bit of a stretch but everything else is spot on. It's a toy. Not there's anything wrong with toys just so long as the Rails fanatics are willing to admit it (which of course they aren't). I'm guessing most of them don't even understand what I was talking about in my original post.
Any man who afflicts the human race with ideas must be prepared to see them misunderstood. -- H. L. Mencken
The ActiveRecord pattern is NOT new, and it won't scale out past a few dozen tables. Never has, there is a REASON that it is not a successful pattern in ALL languages. For TOY applications, it might be fine, but for say something like an ERP system with thousands of tables, it just won't scale out performance or maintanence wise, never will.
no, I'm thinking more about retrieving a much more complex data query than that.
How, precisely, does Ruby not support Unicode? What can't you do in Ruby wrt Unicode that you want to do?
"Everyone knows that no programming language is a perfect fit for every job."
there is nothing stopping you from doing whatever query you wish to do. why does everybody assume that the simple example stuff in the demos and crappy articles are all that RoR has to offer. Do some research before completely dismissing something as a toy. I have been programming database applications for more years than most slashdot posters have been alive and I see a ton of value in RoR. No it is not for every situation but its damn sure a good fit for most. Most peoples opposition seems to stem from they cant grok it in an instant so it must be crap. I found the learning curve to be about 2 weeks and have found nothing I cant acheive in a elegant and efficient maner. RoR is the most well thought out framework I have ever used and I have used a ton. Its not perfect but what is? If you dismiss it you are missing out. Once you understand the internals of the framework you will be better off when developing in other platforms as well.
If something exists that does not need a creator (god) then why must the cosmos need one?
thread.article(parent.id).getPoster() == +1 Funny!
I'm not sure I get your neutral tone in that document. Even though the Unicode standard has certain minor flaws and is not entirely perfect for Japanese needs, do you really believe the arguments put forth by the Japanese nationalists at all justify the total rejection of Unicode in favor of some incompatible local standard? To me this seems a very clear case of politics getting in the way of sound technical decisions.
I hear where you are coming from, and I'm not dismissing RoR out of hand. I'm just saying that sometimes frameworks can be very seductive, and that demos can often make things appear as a shortcut.
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.
The ActiveRecord pattern is NOT new, and it won't scale out past a few dozen tables.
How many applications out there have more than a few dozen tables? I'd have serious concerns with a system that had a single application, with a single database, comprising of hundreds of tables. In reality such systems are quite rare--for every massive ERP implementation there are hundreds or thousands of smaller applications where Ruby on Rails' Active Record model would work very well.
For TOY applications, it might be fine, but for say something like an ERP system with thousands of tables, it just won't scale out performance or maintanence wise, never will.
There are other approaches to system design as well--how about applying a modular "UNIX philosophy" to an enterprise system with several
distinctly defined "TOY applications" each dealing with a smaller number of tables, all loosely coupled together? Even big, old accounting systems are broken into "modules" after all (which historically are more tightly coupled with the main system but still deal solely with a smaller subset of tables/files).
I, for one, like "toy applications". I don't think I've ever heard a developer get real enthusiastic about implementing or maintaining an ERP system--not the way a manager or marketing person does anyways. Come to think of it I don't know a lot of enthusiastic end users of such systems either. Perhaps a mega-corporation saves a lot of time and makes its business more efficient with its mega-ERP systems, however, feeding and caring of that beast is still tedious and annoying--it's just less tedious, annoying and expensive than dealing with mistakes, redundancies and general idiocy an enterprise has to deal with in the absence of a good business management system.
One thing is certain: there are different tools suited to different jobs, and Ruby on Rails/Active Record is best suited to smaller-sized applications where everything is developed from the ground up. Saying it lacks legitimacy because it cannoy scale to handle apps of gigantic proportions or properly interface to complicated, arcane legacy systems (ALL contemporary ERP systems in production use today are "legacy systems" IMHO) is like saying the familiar operator interface of an automobile is a failure because it cannot "scale out" to handle "real" vehicles like high-speed super-trains, jumbo jets or spacecraft. Over 90% of us never need to scale out past four wheels going up to 125km/h and carrying a couple of passengers.
And don't get me started on performance: Java was widely criticised for its performance, as were PHP and Perl for being interpreted and "slow"...however the use of all of those in very high-volume, demanding production systems. The hardware is out there to handle it now, and I've never heard people complain that Rails or Active Record are way too slow to handle the tasks asigned to them.
That stuff sounds really interesting. Do you have links for some of the research? 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.
autopr0n is like, down and stuff.
Well, what are you storing in your database? A simple hierarchy is captured pretty well with a standard, relational database with foreign keys. If you think of trees as a subset of graphs, and a relational database as a graph, you can see that any tree can be encoded as a relational database, you just need a table for every separate type of object. Going further, you can also see that any and all graphs can be expressed as a relational database, just have a "node" table and an "edge" table. (and probably an attributes table for attributes of nodes and edges, to store your data). In memory, you may end up with something much more complicated then a tree, with lots of back links and whatnot. That can't be encoded as a tree, but it can be encoded as a relational database. (I'd love to see someone come up with a graph query language. Get ready for NP-complete queries!) --- Personally, I think relational databases are great. Not because they're 'the way data is' but because they require the programmer to actually sit down and *think* about the data they are saving, and make something that's comprehensible. On the other hand, if they can just save whatever and have it persist, then you might end up with god knows what in your files. Different programs, and even worse: different versions of the same programs might not be able to read the tree properly. On the other hand, yes, it would be much easier to write the code in the first place if you didn't have to write a DAL to convert your objects to queries and vice-versa.
autopr0n is like, down and stuff.
Ouch.
There were linebrakes in that when I hit the "submit" button...
autopr0n is like, down and stuff.
Aren't computers supposed to do mundane work for us? Why make life difficult for yourself - I'm interested in results, not in worrying about whether I've escaped my SQL queries correctly using some function I had to write myself because PHP can't even do that properly.
A note for the job-seekers out there: When I'm hiring, this attitude is the number one thing I look for. Why? Because a developer who automates away the boring parts of the job has much more energy and brainpower to devote to the important work. There are a lot of people who know how to program, but it's a distressingly small percentage who understand that their job isn't programming, it's making things happen, and doing that better and better.
So, are you hiring? :-)
Cool, and how well does Active Record's cache work in a clustered environment?
Why don't you build one and find out? If you don't have one, what the hell are you worried about that for?
It's like asking how well you toyota will withstand the pressures of the antartic climate... who the fuck cares?
Remember that a large part of the resistance that people have to learning a computer language has to do with how difficult it was to learn the last one.
When it's difficult to learn to do something, one doesn't want to write off that investment. Do you still use a qwerty keyboard? So do I. But I'm well aware that other keyboards are easier and faster. If you press me, I'm likely to make up an excuse, but the real answer is I don't want to invest the time involved in relearning touch typing.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
"I already created the database schema, wrote all the SQL to get the information I want, have a lot of HTML written for the general template, and was looking at abandoning much of it for controllers, models, automagic foreign key relationships, automagic methods popping out of thin air.. I wanted more control I guess."
So, you wrote most of the app, then started looking at frameworks, then you were dissapointed when the framework didn't mesh with the work you'd already done.
I'm not looking to be the great defender of rails, but I'm very surprised that your post was modded +4, Interesting. Rails is meant to eliminate a lot of the work you had already done (mostly the SQL stuff). Their mantra is convention over configuration. If you prefer control of course rails isn't going to be for you.
That's kind of funny since I've written programs that parse Japanese text using Ruby and I have actually switched the code and database between EUC, SJIS, and UTF-8 with no problems. As far as I know, you can't use UCS-2, but UCS-2 is deprecated anyway since you can't encode the whole Unicode space in it anyway.
My other first post is car post.
don't try to tell me that 16 bits is enough bits to store every character you'll ever want to display or print.
Okay, I won't, but can you tell me why I would need more than 16 bits to store a single character ? Why the hell do we need so many characters in the world ? Are there so many ways to say "Hello" that we need millions of characters to communicate with our neighbors ? I'm not saying everyone should speak english (I'm french myself), but eventually the various dialects will condense into more portable languages.
Maybe in a few decades, maybe in a century.. sooner or later the concept of unity will be more than just words on the back of a student flyer, and we will want to understand others no matter what land they hail from. Why should a computer understand 4 billion characters when humans only use a few hundred at best, for most of us just a few dozen.
-Billco, Fnarg.com
You Unicode fans might like to know that Japanese in Unicode is not done well, it leaves much to be desired for computation/sorting/searching in the three character/pictograph sets in use by average literate Japanese person. Other encodings are prefered and more useful
Okay, I won't, but can you tell me why I would need more than 16 bits to store a single character ? Why the hell do we need so many characters in the world ? Are there so many ways to say "Hello" that we need millions of characters to communicate with our neighbors ? I'm not saying everyone should speak english (I'm french myself), but eventually the various dialects will condense into more portable languages.
Of course. For example, we don't need to runic characters in real life, however if you wanted to write a textbook on Anglo-Saxon linguistics, you'd be up shit creek if those characters weren't in there. Same goes for any given language.
Karma: It's all a bunch of tree-huggin' hippy crap!
You're right, that the language itself is not the only thing that matters. Extra libraries to work with makes life much more pleasant.
But what's under the hood of that do_something_with_file_data? In this fairly trivial example, there's not much difference between a do_something_with_file_data in C versus Perl.
Nice code examples deleted 'cause of /. stupid lameness filters inserting random spaces, even when I had spaces nearby. GRRRR! Suffice to say both were functionally equivalent and of about the same length: about 8 lines for reasonably readable code that output reasonable, though not strictly standards-compliant, HTML.
For more complicated web work, however, I would still maintain that there are better languages than C (and Perl for that matter) to be doing the work. I'm not for a moment suggesting that I can replace what would take me a year in C with a day's work in Python (excepting the library issues), but I think that the so-called "scripting languages" are faster to develop many types of applications even without the library advantages they have.
Execution speed arguments are less a function of the language itself than a function of those environments the languages themselves typically operate in. There are python, perl and Java compilers and I'm sure somebody has made a C interpreter for some strange reason. Most applications do not need to be as efficient as possible by virtue of the fact that a lot of them sit in an idle state most of the time anyway. There are notable exceptions (scientific computing, games, etc.), but there you're going to be writing as close to the hardware as you dare and maybe even C is too much of a luxury and you'll have to write assembly.
I agree that a language choice, given appropriate and featurewise compatible libraries existing for the task at hand, isn't usually going to make a many orders of magnitude difference in development speed. I do still contend however that appropriate languages to the task at hand can save you a decent slice of project time. My gut instinct would be to say the average would be around 20 to 30. Not massive, but noticeable on the bottom line. Sometimes that choice will even be C. And some things still need the raw power of C. Not bagging on C at all, here! It was the fifth language* I learned, after TRS-80 Extended Color Basic, 6809 Assembly IBM 360 Assembly, and Pascal. Of those five, it's the only one I still use at all, much less remember, and I still love hacking on it.
I will concede that my gut is not (perhaps) as accurate as a study, but my only point was to say I will still trust my experience over a random stranger on Slashdot waving "studies" around without any reference to what they're referring to.
*- FORTH was sixth. I've forgotten it, too.
It's called "objectivity". He should be applauded, not condemned, for writing something so balanced. You came to the conclusion that the Japanese are being unnecessarily stubborn regarding Unicode. So did I. I think that says something given the fact that neither of us believe he took a stance on way or the other.
Yes, I'm not criticizing him about it especially. I was mostly trying to poke him into giving his opinion, since he seems better-informed than I am.
Okay good point, but why not just use a dedicated runic font for that specific purpose ? We already have those, they're just poorly supported in general-purpose software. Why the hell would general-purpose applications need to know foreign charsets ? Just because a handful of people want a feature does not mean the whole world should change the way they write code just to accomodate that minority. Unicode is such a big deal yet I can't justify the need in my daily computing tasks. Even if I spoke a foreign language that requires non-latin characters, I would simply use that specific font, I don't need the other 2700 languages along with it. I think it would be far easier for an application to support two or three individual charsets than 32-bit character spaces.
-Billco, Fnarg.com
Yes. About the only use for Unicode is keeping track of your Elvish and Klingon dipthongs in the same character set. 2 byte words is enough for China and Japan has their own system that works. Meanwhile, everyone uses ascii except when representing pictograph characters.
Okay good point, but why not just use a dedicated runic font for that specific purpose ?
For semantics. An application that processes text won't deal with fonts. If it did deal with fonts, it would still need a way to convert the bogus text into a real representation, and for that representation, we would use Unicode.
Karma: It's all a bunch of tree-huggin' hippy crap!
have you ever used unicode?