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