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.'"

16 of 266 comments (clear)

  1. In a comparison, Ruby suffers for one big reason by CRCulver · · Score: 4, Insightful

    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.

  2. Anyone else Railed-out? by lifeisgreat · · Score: 4, Interesting
    Has anyone else played with Rails and been turned off?

    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.

    1. Re:Anyone else Railed-out? by JulesLt · · Score: 4, Insightful

      Which bit is causing you the problem - Ruby or Rails? My understanding is that Rails is simply providing, well, Rails to give you a rapid framework for your Ruby app - provides you with a web page that's a 'default form' along with the related MVC code. It's similar to other frameworks that provide default pages from ORM mapped classes in other languages, but I thought it was Ruby, rather than Rails, that was getting people excited.

      I'm an 'SQL' guy myself and I'm not convinced by ORM tools - or at least the way they're being hyped as a solution for having to understand the DB (Newsflash : SQL is supposed to be an abstract query language so that the developer doesn't need to understand the DB - and look how that worked - answer : Mostly it does, but when it goes wrong you're dealing with a black box). I also think that the view of many Java (and Ruby) developers that a DB provides 'persistence' is wrong. It's a failure to understand relational theory - which at least, unlike most object modelling techniques, has a firm mathematical foundation. It's also a failure to use the tools provided to you (and when Bruce Tate complains about Java productivity, this tendency of Java developers might be part of the problem - it's 'not invented here' syndrome).

      You could have used Ruby rather than PHP (a comparison I'd like to see) and I also think that there is much to be said for the MVC structure compared to shoving everything into each page.

      It feels a bit clunky in the current paradigm (pages generated on the server and refreshed to the client, client events sent to server) but it works very well as a design, and I can see it becoming more important again as browser apps support more dynamic features - getting back more towards a client-server architecture with the model on the server, view on the client. (Or more likely a local model for performance and some form of background syncing).

      --
      'Capitalists of the world, unite! Oh ... you have' (League Against Tedium)
    2. Re:Anyone else Railed-out? by shmlco · · Score: 4, Insightful
      "Inexperience can mitigate the benefits of any technology..."

      Inexperience and ignorance. And it sounds as if it applies to you and to this situation. I don't see how you can rant against "bloated" technologies you never bothered to learn. Without that knowledge, you don't understand everything that's happening behind the scenes and, since that scares you, you stick with the subset of the developmentatl universe you do know, no matter how appropriate, or inappropriate, it may be to the problem at hand.

      I strongly suspect that once you've moved on to other victims, the next developer the guy hires will take one look at your carefully-crafted optimum solution, shudder, and then rewrite the whole thing.

      --
      Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
    3. Re:Anyone else Railed-out? by ubernostrum · · Score: 4, Insightful

      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... you basically wrote the application (minus the controller), and then started thinking about using a different platform? Is it any surprise that you didn't want to switch over to Rails (disclaimer: I'm not a Rails guy. In fact, I work for the competition)?

      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.

      OK. It's not like somebody's holding a gun to your head and saying you have to use a framework. Personally, I see a lot of use cases where a framework makes development a lot simpler and easier to manage, because so much of the tedious overhead of web-app development has already been done for you. Think of the framework in terms of an operating system you're programming for: rather than writing all your own device drivers, routines for drawing stuff on the screen, accepting keyboard/mouse input, etc., you've let someone else solve those problems and you're just using the provided APIs to hook up the logic that's unique to your application. And with a framework, rather than write database drivers, routines for accepting and routing input, etc., you've let someone else solve those problems and you're just using the provided APIs to hook up the logic that's unique to your application. Using a web framework is no different, really, than using any other shared library.

      As for all the cruft you complain about, when was the last time you used every single bit of functionality provided by a shared library you linked a C application against? Or is it only bad to draw in automagical functions you won't use when the application isn't being compiled? ;)

  3. Wrong Mentality by MLopat · · Score: 4, Interesting

    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.

  4. Re:In a comparison, Ruby suffers for one big reaso by syntaxglitch · · Score: 4, Interesting

    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.

  5. Uhhh.... by wbren · · Score: 4, Funny

    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
    1. Re:Uhhh.... by Ziviyr · · Score: 5, Funny

      I guess the answer for that is "works great on IE!"

      --

      Someone set us up the bomb, so shine we are!
  6. Re:Still looking for an IDE by k2r · · Score: 4, Funny

    > Here, we simply drag and drop then program the logic behind all those widgets
    > I taught VB myself using this method.
    > Current IDEs I have looked at make things confusing.

    Nothing personal but: This explains much of the VB code I had the misfortune to see in my life.

    k2r

  7. language matters a great deal by idlake · · Score: 4, Insightful

    everyone has their syntax preference, but at the end of the day its the paradigm you apply that matters and not the language.

    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 .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.

    1. Re:language matters a great deal by aricusmaximus · · Score: 4, Informative

      Most studies show that this is blatantly untrue -- programmer productivity is generally independent of language chosen.

      Excuse me? Which studies?

      Certainly not this one:

      http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpp rt_computer2000.pdf

      Nor this one:

      http://www.erlang.se/publications/Ulf_Wiger.pdf

      Nor even this one:

      http://www.theadvisors.com/langcomparison.htm

      And this well-regarded programmer certainly doesn't agree that the choice of language doesn't matter:

      http://www.mindview.net/WebLog/log-0025

      I tell you what -- interview a group of experienced programmers for a prospective project to write a database-backed web application with complex requirements. Tell them that they will be required to program in assembly language because "most studies show that... programmer productivity is generally independent of language chosen." Record their responses and post them to Slashdot.

  8. Really a time saver by pmontra · · Score: 4, Interesting

    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.

  9. Rails rocks (but isn't a silver bullet) by PetriWessman · · Score: 5, Informative

    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 is no Unicode support. For a language coming from Japan that's surprising (and sucks). I'm given to understand that fixing this is in the roadmap for Ruby(?).
    • It's an interpreted language (like Perl, Python etc), so if speed really is an issue for you then it's not a good choice (for most things nowadays, Ruby is more than fast enough)
    • The scoping of variables in blocks is a bit funky.
    • Some of the organization in the standard libraries is a bit weird, and there is some repetition of functionality. I think this is due to historical reasons (std lib code has evolved over the years)

    (there are probably more, but I'm still only learning the language)

    As for Rails, well, again there are downsides. Nothing is perfect.

    • No Unicode support (inherits Ruby weakness). For web apps, this really sucks.
    • Poor localization support in general (again, sucks).
    • ActiveRecord is nice, but works best for from-the-ground-up projects. Integrating with a legacy schema might get ugly, a mapping layer (like Java's Hibernate) would work better there.
    • No support for clustering and other heavy-lifting technologies. If you're building a seriously big app, Rails might not be the optimal choice. But face it, 99% of web apps don't need stuff like that. Right tool for the job, and all that
    • Still a young framework, and evolving. This is both good and bad. Bad, since the framework is changing while you code. Good, since it means that bugs (and maybe the above weaknesses, too) are getting fixed.

    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.

  10. Re:In a comparison, Ruby suffers for one big reaso by kahei · · Score: 4, Interesting


    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.
  11. Re:In a comparison, Ruby suffers for one big reaso by pilkul · · Score: 4, Insightful

    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.