Posts tagged as: oop

Making progress on Ruby project

I started writing a framework for my Ruby test site yesterday. All I need right now is a set of simple functions to display the source code of the programs I'm writing, and to execute them and display the results within a standard page format for the site. As is common with OOP languages, I'm just using the existing classes in a procedural manner for now. Once I start building up a larger codebase and have to deal with reuse issues, I will build some classes of my own. So far I'm finding Ruby to be a pleasant language to work with for what is now just text manipulation. The syntax stays out of your way, and it is extremely dynamic. So I can have code that constructs the test code I want to execute and then evaluates it and returns the result as a string. In this way it is reminiscient of the dBASE language, which is great for the "make it up as you go along" style I prefer. Today I hope to start building queries for Amazon in Ruby. I'll have more to say about that in later posts.

Book Note: The Ruby Way

I've already finished this book, so I'll just do more of a final review than a series of notes while reading. This is basically a cookbook aimed at an intermediate Ruby programmer who wants to see the most elegant way to accomplish both standard and fairly advanced techniques. Even so the first chapter is a superb review of the basic language features. I'd recommend it for any experienced programmer who wants an overview of Ruby's syntax and OOP capabilities. The rest of the book is well written, but has too much of a systems programming focus and too little information on application development for me. Hal Fulton's background as a CS professor certainly comes through. For example, there are 30 pages on threaded programming and 3 pages on using MySQL. The idea of controlling multiple threads is cool, but I'd ever do it. I could just launch multiple instances of the interpreter, or more likely use mod_ruby and let Apache deal with multiple threads. In the end, other than the first chapter review of Ruby syntax I found little of use to me, but anyone building a Ruby IDE in Ruby will certainly be pleased.

Book Note: Teach Yourself Ruby in 21 Days

I'm ready to give up on this one. As I expected, he dropped the pretense of writing for both novice and experienced programmers by the fifth chapter and is now in full-blown programmerspeak. That's fine with me, because I'd rather read something that assumes I know how to program, but doesn't assume I know Ruby. What is more frustrating is that he resisted explaining the OO features of Ruby early on, so now he is forced to introduce them as needed throughout unrelated chapters. For example, he explained how to create and use class methods as opposed to object methods in chapter six, which was supposed to be about I/O. He had no choice, because the File class has some methods that are used before a file object is created. Another problem I have is his use of examples. I believe in using either ultra simple examples, such as X = 1 and Y = 2, or useful examples that explain how a language feature can be applied in a practical way. This author is trying to stay somewhere in the middle by using examples that have real looking data but don't actually do anything useful. I'm not sure who would benefit from his approach. My next Ruby book will be Hal Fulton's The Ruby Way.

Book Note: Teach Yourself Ruby in 21 Days

The classic problem facing an author of any introduction to a programming language is whether to assume the reader has ever programmed in any language. This book adopts the approach of no prior programming, which in my experience always tends to break down quickly. It is easy to explain that a memory variable is like a cubbyhole with a name, but what happens when you reach topics like passing pointers to arrays of functions? The initial assumption is revealed as a farce. Taking this approach of no prior knowledge in a book on an object oriented language has the additional burden of explaining concepts such as encapsulation, polymorphism, and inheritance at the same time as saying a variable is like a shoebox that can hold any value. The mistake authors make is worrying that OO concepts are really difficult. The trouble isn't learning the concepts, it is understanding why they are necessary and justifying the extra work in using them. This book tries to avoid the pedantic style of explaining these concepts directly, by giving code examples first and then putting the names of the concepts in text box asides as if you didn't really have to know the names.

Instead of wrapping this term in all these qualifiers, I'd explain polymorphism by having a subheading called Polymorphism with examples of two different classes with a print method. A simple explanation of the consistency benefits of always calling this method print even if it does different things would explain the concept and the benefits at the same time.

Curiously, he even gets the description of inheritance wrong. He says that inheritance is when you add a method to a class and then call it in an object of that class. I always thought inheritance is when a subclass can call a method of the parent class.

This book is trying so hard to say "Don't worry, programming isn't really that hard" that it ends up confusing both new and experienced programmers. For example, it tries to explain that Ruby passes variables by reference through a strange example of changing part of a string in two variables pointing to the same value. To make it cute and more "accessible" he uses the name "Sandra" which he changes to "Sandra Dee." How old is this guy? I'd simply use an example like: After two chapters I'm getting pretty annoyed.

Book Note: Teach Yourself Ruby in 21 Days

I started learning the Ruby programming language today. Ruby and the associated framework product, Ruby on Rails, seem to be all the rage among web 2.0 developers, so I thought I'd give it a try. It seems to be a "real" object oriented language, so I'm looking forward to it. I've programmed in Perl, which can be forced to use OO techniques, and Python, which is much more OOish, but I've mostly used them in a procedural manner. This time I'm going to try and really work with classes as well as objects. Back in the early 90s, when OOP first appeared in popular use, Borland hired me to write a book about their future dBASE for Windows product. I spent a year doing nothing but studying OO ideas and really fell in love with the approach. Sadly, the product was a bust, and the book never saw the light of day.

I have a stack of Ruby books on my desk, and I'm going to start with this one from Sams. You can find the details at Amazon if you want to read along with me.