Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

TimHunter writes "Peter Cooper's Beginning Ruby: From Novice to Professional has two audiences, novices with no programming experience who want to learn Ruby as their first programming language, and veterans who want to add Ruby to their programming toolkit. Cooper's response to this challenge is a solid entry in the limited arena of Ruby tutorials. Even though the early chapters are marred by the occasional reference to an advanced topic, readers will appreciate the plentiful examples and thoughtful description of the Ruby language." Read below for the rest of Tim's review.

Beginning Ruby: From Novice to Professional

author

Peter Cooper

pages

631

publisher

Apress

rating

7

reviewer

Tim Hunter

ISBN

1590597664

summary

An introduction to Ruby programming

Ruby is an object-oriented programming language in the same family as Perl and Python. Ruby is very popular for writing web applications but also widely used for the general-purpose programming tasks. Ruby is available for Linux, Mac OS X, and Microsoft Windows. It is Open Source software with a commercially friendly license.

I agreed to review this book in particular because, even though the Ruby community has a strong tradition of encouraging newcomers, there are actually very few resources for the Ruby beginner. Ruby has gained a repuation for being easy to learn and therefore is attractive to people with limited or no programming experience. Novice programmers post almost daily requests for help and direction to the ruby-lang mailing list.

In addition to serving people with no progamming experience, Beginning Ruby is also aimed at experienced programmers who want to learn Ruby. Progammers coming from languages such as Java or C++ often struggle with Ruby's dynamic typing and (even with the recent explosion of Ruby-related books) the relative scarcity of documentation. Beginning Ruby tries to satisfy this audience by explaining Ruby's design, history and place in the programming world and including an extensive survey of the currently-available Ruby libraries.

Beginning Ruby is divided into 3 parts. The first part is aimed at neophytes. Experienced programmers, especially those experienced with object-oriented programming, will be able to skip chapter 2 and skim chapters 3 and 4.

The book starts simply. Chapter 1 isn't even about programming. This chapter explains how to install Ruby on Windows, OS X, and Linux. The instructions are thorough and aimed squarely at beginners. For example, Cooper explains how to get a command prompt on Windows and how to run Terminal.app on OS X.

Chapters 2 and 3 introduce fundamental concepts such as variables, expressions, control flow, classes, and objects. Cooper emphasizes experimentation. He says that irb, Ruby's interactive programming module, "provides the perfect environment for tweaking and testing the language, as you cannot do any real damage from within irb." Such assurances are helpful, especially to the beginner who may be slightly afraid that he's going to somehow make a mistake that will "break" his computer.

Explaining programming to beginners is hard. I've read a number of books that try to teach object-oriented programming concepts to people with no programming experience whatsoever. None were stunningly successful. This one isn't either. The problem is that books are linear, but there are simply too many things – concepts, keywords, tools – that have to be introduced nearly simultaneously and initially taken on faith. Cooper distracts his readers by peppering his text with too many "don't worry about this yet" disclaimers and assurances that explanations will appear later. His references C and Perl will be meaningless and possibly confusing to the beginning programmer.

Chapter 4, "Developing a Basic Ruby Application," starts by explaining what a text editor is and offering a few recommendations for text editors on Windows, OS X, and Linux. Then it guides the reader through his first real program, a script to read a text file and compute simple statistics such as the number of lines and words. This is a well-chosen example that will, when completed, make the student feel like he's accomplished something.

Chapter 5, "The Ruby Ecosystem," feels out-of-place. This chapter doesn't teach anything about Ruby programming. Instead it explains Ruby's history, introduces Ruby On Rails, and talks about the Open Source movement. Little, if any, of this material will be interesting to a fledgling programmer. The chapter finishes with a list of internet-based Ruby resources such as mailing lists, IRC, and blogs. All of this seems much better suited as an appendix and indeed the list of resources appears again in Appendix C.

Part 2, "The Core of Ruby," has a slower pace. With the very basic material covered, Beginning Ruby gets a better footing. Starting in this part the material is useful to both beginners and veterans.

This is probably as good a place as any to talk about the examples, which are numerous and very likely the best part of the book. Most of the the examples are short and to the point. A few extend over several pages. My overall impression is that they are well-chosen and well-coded. I especially like the way the examples appear on the page, visually distinctive but without interrupting the flow of the text. Source code for all of the examples may be downloaded from the Apress web site. However, even though the files are divided into a directory per chapter, the examples aren't numbered in the text so it's difficult to find the code for the example you're looking at. I ended up using grep to search for keywords in the sources.

Chapter 6 is a slower pass through Ruby, focusing on Ruby's object-orientation. Though fewer than part 1, there are still problems with references to concepts that have not yet been introduced. For example, Cooper uses the require method in the context of namespaces even though require has not been introduced. Indeed, it's not even necessary to mention namespaces at all in this chapter since the entire concept could've been held off until the next chapter, which explains how to create programs from code in multiple files.

The remaining chapters in this part start to address the needs of the serious Ruby programmer. This is a lot of ground to cover, including documentation, debugging, test-driven development, I/O, databases, and how to deploy Ruby programs. I particularly liked Cooper's thorough instructions for installing and creating RubyGems, Ruby's third-part library management system. There are so many topics to cover that each one gets only an introduction, but Cooper uniformly provides links to extended online documentation.

The last chapter in this part works through an even larger example, a Ruby "chat bot." This is an ingenious and entertaining example, the kind of program that, had I read it when I was just starting to learn programming, would have spent many happy hours tweaking. Call me a geek, but I got a chuckle out of the example on page 383 of two very stupid bots conversing.

Part 3 is called "Ruby Online." Of course it starts with the obligatory chapter on Ruby on Rails. I suppose publishers require such a chapter in all Ruby books, even though RoR is more than amply covered by other excellent books. I'm not a RoR programmer so I blew off this chapter.

Chapter 14 describes Ruby's support for the Internet via its HTTP, email, and FTP libraries. Chapter 15 covers other networking support libraries. As usual there are many excellent examples.
Chapter 16 is a very good survey of the standard and add-on libraries that the serious Ruby programmer will find useful. Each library is demonstrated with an example, and Cooper provides a link to the complete documentation.

At the start of this review I said that Beginning Ruby is divided into 3 parts, but actually there are four. The last part consists of 3 appendices. Appendix A is a summarization of Part 2. Appendix B is sort of a "semi-reference" to Ruby's core libraries. This is not intended to be a complete reference. Instead, Cooper limits his discussion to the most useful methods of the core classes. As I mentioned earlier, Appendix C is a list of Internet-based Ruby resources such as web pages, mailing lists, IRC channels, and blogs.

I'm giving Beginning Ruby a 7. It's a good book for someone who wants to learn Ruby as his first programming language. It could be better. I liked Cooper's patient and thoughtful explanations about installing Ruby and RubyGems, how to use a command line, and what a text editor is for. Cooper supplies answers to all the typical Ruby-nuby questions, but his explanation of basic concepts is marred by the occasional confusing reference to advanced or even irrelevant topics. For the experienced programmer who learns best by reading and working through examples this book is a good choice. Dave Thomas'Programming Ruby, The Pragmatic Programmer's Guide (a.k.a. the Pickaxe) is a tough competitor, but each book has a considerable amount of material that is not found in the other book. For example the Pickaxe's core library reference is exhaustive but it has only a limited amount of the kind of tutorial explanations that is Beginning Ruby's strength. Beginning Ruby is available in PDF format from Apress' web site at about half the price of the paper book.

I have been programming Ruby as a hobby for over 5 years. Apress gave me a review copy of this book, but otherwise I have no connection to the author or publisher."

How many different programming tools do we need?
Wouldn't a venn diagram of key language features show substantial overlap?
Ruby sounds like your typical well-done tool, which clearly has its audience.
The only substantial criticism of Ruby I've ever heard is here:http://ciaranm.org/show_post/110 [ciaranm.org]
Still, I'm wondering, what is the Next Big Thing? Is Python3000 going to rule the day? It's obviously 500 times better than Perl6. Then again, you've another round of C++ coming up for standardization: will svelte compiled languages recover some of the mindshare lost to these SUV scripting languages?
Is the point of making some new tool the buzz of the day simply to sell books?

> Is Python3000 going to rule the day? It's obviously 500 times better than Perl6

Python 3000 is a cleanup of the inevitable evolutionary accretions that languages accumulate. Nothing ground breaking in this release feature-wise. So Python 3000 and Perl 6 are very different in scope. I (as a Python user), for one am very curious of what will come out of Perl 6.

How many different programming tools do we need?Wouldn't a venn diagram of key language features show substantial overlap?

Sure, but that's not to say they overlap in the same places. I've never come across two programming languages with exactly the same strengths and weaknesses.

Ruby sounds like your typical well-done tool, which clearly has its audience.The only substantial criticism of Ruby I've ever heard is here

Bah, you're obviously not looking hard enough:)

You can write pages on criticism on any language. For instance, you could criticise Ruby on it's efficiency, it's dynamic typing, it's syntax quirks, it's libraries, it's readability, it's method naming conventions... The list is substantial, and many people disagree whether certain features are advantag

Sure, but that's not to say they overlap in the same places. I've never come across two programming languages with exactly the same strengths and weaknesses.

There are plenty of pairs where difference are marginal, though. Say, C# and Java.

Whatever it is, I'm hoping it will be functional;)

C# has first-class functions and lambdas already, and will get neat syntax for them in v3.0. Java is going to get lambdas in the next version. Even C++0x is going to get something similar, though not with true closure se

C# has first-class functions and lambdas already, and will get neat syntax for them in v3.0. Java is going to get lambdas in the next version. Even C++0x is going to get something similar, though not with true closure semantics.

Does that include tail call elimination?

You don't have to wait for the Next Big Thing for functional stuff - it's already here, in the mainstream languages. It just doesn't look as neat as Haskell does, but you shouldn't care all that much about the looks.

Sure, this is all a step in the functional direction, but I was rather hoping for a more than just a single step. Since you mention Haskell, you'll probably be aware it contains a lot of functionality that is difficult or impossible to reproduce in a language like C# or Java.

No idea in either case. C++ standard certainly doesn't guarantee it, but IIRC, most optimizing compilers (and GCC in particular) try to perform it already. Java, I don't know. More likely for C#, since CIL already has a special bytecode for optimized tail calls.

Sure, this is all a step in the functional direction, but I was rather hoping for a more than just a single step.

Technically, first-class functions are all that is needed to consider the language functional. Pr

No idea in either case. C++ standard certainly doesn't guarantee it, but IIRC, most optimizing compilers (and GCC in particular) try to perform it already. Java, I don't know. More likely for C#, since CIL already has a special bytecode for optimized tail calls.

I didn't know GCC optimised that, though it would appear you're certainly right! I don't think tail call elimination is planned for Java (from what I've heard), and I haven't heard it being introduced into C#. I guess it's possible though, since as you say it's supported by CIL, although so far as I know only functional languages like F# etc. use it.

Technically, first-class functions are all that is needed to consider the language functional. Pragmatically, it's more like "convenient first-class functions". There are a few other things traditionally associated with functional languages, true - type inference and pattern matching, in particular.

Functional programming is a programming style that attempts to minimise side effects, and whilst first-class functions et all are steps to ensuring that goal,

For instance, if I call the Add method on the array ArrayList in C#, it updates the data in the ArrayList with a new value. If I were to add an element to a list in Haskell, a new list would be returned; the original list would not be altered (indeed, in languages like Haskell, it literally cannot be altered).

I know what pure functional approach means; but it's just not practical for the vast majority of applications - we can't optimize it nearly as well as the more conventional imperative style. That's wh

I know what pure functional approach means; but it's just not practical for the vast majority of applications - we can't optimize it nearly as well as the more conventional imperative style. That's why you see more programs written in O'Caml than Haskell, for example. Haskell is great as a language to learn what FP is about, but pure functional programming certainly won't be the next big thing, not in the next few years at least.

Pure functional programming eliminates all side effects. More pragmatic forms of functional programming only attempt to minimise it. This is why I don't consider C# to be a very functional language, because it doesn't really attempt to minimise side effects. C#'s style is still very imperative.

Regarding optimization, I think you'd be surprised at how much pure functional languages can be optimized. If you compare the benchmarks of pure languages like Haskell or Clean again impure languages like OCaml, you'

### The only substantial criticism of Ruby I've ever heard is here:Another issue Ruby and many other 'scripting' languages have is lack of lexical scoping. I just don't understand where there is a benefit of not declaring variables properly, it not only makes the scope of a variable rather unclear it also makes automatically catching errors much harder. A little "var a = 5" isn't much more to type then "a = 5", but its a hell of a lot more expressive. Ruby does a ton of good stuff, in fact its the languages

No. The days of compiled languages as mainstream are over -- "SUV languages", interpreted, garbage-collected, are here to stay. The programmer base is moving away from having the skills and aptitude to keep their pointers straight, and to be able to debug native code. Just like I never learned how to write large applications solely in asm, "svelte languages" are now the skills of a passing era.

I like your point, but I'm coming to the conclusion that there is a standard normal distribution of tools and the

Very little demand for the native-code-wrangling capable means colleges won't teach it and kids won't want to learn it

Disagree. You overlook: a) curiosity, b) the fact that there will always be a need to squeeze a little more love out of existing configurations, and c) somebody has to know how to bring the box up from cold iron: even if you park the SUV in ROM, you still have to know how to build/maintain the SUV, d) there is much loot to be earned knowing b) and c)

The rules of the game have changed in two important ways over the intervening years, though:

Writing efficient assembly language by hand got harder. With the move to the mainstream of pipelining and caching technologies, you can't just write assembly instructions in any old order to get the fastest results any more. And of course, we have many extra instructions available on modern chips: the Intel/AMD family alone now have something like seven or eight supplementary instruction sets for specialist numeri

Why is Ruby suddenly the big buzz these days? My internets inform me it's a high level server-side language (python for websites). Isn't the most important thing in a server side language fast performance rather than quick development time? I found an article on coding horror [codinghorror.com] in the depths of my RSS reader talking about how Twitter are having no end of problems scaling their system, as they're using Ruby and it just isn't made for big, high traffic sites.
If the main reason for writing server side software is web based applications, or at least dynamic content, isn't a huge factor in this how well it scales? Nobody makes sites to be used by 20 people.

Finally, if anybody can explain it's popularity to me, should I learn it? I'm currently doing freelance web dev mostly in PHP, would it be useful? How? In my spare time I'm writing a AJAX web app with PHP back-end at the moment and it's mostly for my personal use (task tracking from anywhere), is Ruby good here with the limited audience the site'll have?

Ruby isn't any more a server-side language than 68k assembler is. You've probably confused it with Ruby on Rails [rubyonrails.org] which is a framework (and an excellent one, I might add) for making websites. Compared to plain PHP it makes web development easy and fun and even supports stuff like AJAX out of the box.

PHP isn't a framework. It's a programming language. You made the same mistake your parent did. You're comparing a framework (RoR) to a langauge (PHP). If you want to compare them, you'll have to compare it to another framework, like CakePHP.

I disagree. Parent asked about PHP vs. RoR, and it highlights an interesting tendency; sites written in plain PHP are a common sight whereas sites written in plain Ruby are not (compared to RoR-powered sites). Framework or not, they're each self-sufficient and popular approaches to web development.

PHP consists of both a programming language and a framework. I very shallow, "to the metal" framework to be sure, but still a framework. It provides features such as form submission parsing, cookie management and a concept of "sessions". CakePHP and friends add another layer of framework atop this existing functionality.

OT, but I find a lot of people blur the distinction - they have only heard of Ruby in the context of Ruby on Rails, which is great, but Ruby itself is a fantastic language for all sorts of scripting - a better Perl than Perl, a better Python than Python...

I've been doing PHP programming for years, and I really enjoyed working with it as a scripting language.That said, I started playing around with Ruby on Rails. Honestly, simple tasks like database access is so much simpler to handle in RoR it's just amazing. Creating database driven web sites, with one-to-many and many-to-many relationships is at least 10x quicker than in PHP. You have to get used to the MVC style of programming of course.

First, Ruby != Rails. Ruby is the programming language. Rails (or Ruby on Rails) is the web development framework. Ruby has been around a lot longer than Rails, but has certainly had it's popularity boosted by the buzz surrounding Rails.

Second, I'd disagree that system performance is the biggest factor is selecting a web framework. Rails out of the box will support the load more most websites. There are many things that you can do to tune performance once you start getting enough page views for it to matter: caching pages, selectively replacing ActiveRecord's queries with raw SQL, etc. There are also people starting to focus on rails performance both from a developer's standpoint (e.g., the Rails Express Blog [railsexpress.de]) and from the hosting standpoint (e.g., Engine Yard [engineyard.com]).

To me, the first and foremost goal of building a website is to get the functionality there quick in order to attract users. Once you've got that, and have rapidly been able to iterate to what the users want to see, then you can start worrying about performance. And, if your site really makes it big, you are going to have to do custom tuning work no matter what framework you've chosen.

Personally, I've found Rails to be a wonderfully productive framework to use for web development

Isn't the most important thing in a server side language fast performance rather than quick development time?

Of course not. If it were, every high traffic website would be an NSAPI/ISAPI/Apache module. The vast majority of small to medium scale web apps are database limited much more than they are CPU limited on the web server. Twitter is such an app, as that coding horror article eventually mentions.

As far as whether you should learn it, I get paid to write mostly PHP, and I'd say anybody else in my po

Finally, if anybody can explain it's popularity to me, should I learn it? I'm currently doing freelance web dev mostly in PHP, would it be useful? How? In my spare time I'm writing a AJAX web app with PHP back-end at the moment and it's mostly for my personal use (task tracking from anywhere), is Ruby good here with the limited audience the site'll have?

All I can say is that after doing PHP on and off for a few years and then learning Ruby, I never want to touch another line of PHP shite again. Sorry, if

Because sometimes Ruby is too slow.:-(Both Perl and Ruby are really rad. And RAD. And they both operate on the ever-so-helpful principle of least surprise. Unlike PHP, or a lot of other languages.:-/If there was one thing I don't like about perl (and I can totally sympathize from a language beauty POV), it's that sigils represent interpretation intent, and do not describe the base object.

I.E.$foo[bar] is a value in @foo not @foo[bar]. Which seems silly because the array slicing operator has list and value

Isn't the most important thing in a server side language fast performance rather than quick development time?

Only if you need performance. Not every dynamic site on the web needs to serve a bazillion people a day, and throwing hardware at a problem is often far cheaper than employing a skilled software developer for longer.

If the main reason for writing server side software is web based applications, or at least dynamic content, isn't a huge factor in this how well it scales? Nobody makes sites to be used by 20 people.

No, but very few sites have to deal with 11000 page views per second, as Twitter reputedly does. Since Rails (just) handles this, then it should handle more modest needs as well.

Also, the main problem Twitter has is the database bottleneck, not Ruby's speed (or lack thereof). Rails is designed

Ruby isn't "python for websites". It would be closer to say its "python, but different". Sure, its most popular application is a web framework (Rails), but that's not the same thing as the language. Python has web frameworks like Rails too.

Although, while I didn't start with C or Assembler (I started with C++ and felt it was a big piece of shit, though now days I find it quite useful; it is very abstracted though), this is certainly what I recommend for a person who is serious about programming.

As a side note, it is interesting that at the school at which I took my MSc, they used Haskell as a first starting language, basically to tell everyone that "you don't know shit about programming" and bring the sufferers of the perfect programmer syndrome down to the ground. A very good thing indeed.

The problem with learning assembler is that there seems to be very little you can do these days that has any usefulness. I'm one to learn a language by starting a project and just learning as I go. But what kind of project can you do with assembler? I'd actually like to know because I skipped ASM long ago because I just couldn't find a use for it.. especially in these days of protected memory and total hardware abstraction.That said, C is probably a good start. If only so you realize just how much time high

I work a lot with embedded hard real time system, I have worked with full system simulation as well. Assembly is indeed very useful, especially when you try to figure out why the system is crashing only to in the end uncover code generation bugs in the customised version of gcc that was used to compile the embedded software.In any field you tend to learn the basics first and then move in to more abstract levels. Any programmer should grasp the physics of a transistor, how a CMOS circuit works, what gates an

The question remains: What kind of project can one do that would help one learn ASM if one doesn't have embedded systems handy to work with? It is one thing to say "every programmer should be faimilar with assembler," but is that realistic?

What kind of project can one do that would help one learn ASM if one doesn't have embedded systems handy to work with?

Answer: Get an embedded system handy to work with. There are hundreds of types of embedded dev kits out there that can get you started. If you need a project, build a security system for your own home, network a coffee maker, or build an autonomous blimp-bot.

Buy a GBA and a flashcart. About $150 worth of gear, and you have a nice little embedded system with a really nice hardware layout (the ARM has a *wonderful* ISA), plenty of hardware emulators for debugging and so forth (including VBA, which allows you to connect gdb to it and debug an ELF ARM executable directly), and free devkits available.

Heck, you could just use the emulators, if you're cheap. But it is so much cooler to see "Hello World" pop up on your GBA.:)

As a first programming language, if you are serious about programming, learn C or some Assembler, this will make you understand how a computer actually works and think before you write sucky code.

Sucky in what way? Good code now days has more to do with structure and maintainability as opposed to squeezing every possisble extra CPU out of a procedure. Instead of wasting time learning C/assembler, which you probably wouldn't get any use out of, I would go with an OO language such as Java or.net. Stick

It is not only about squeezing out every cycle, it is more about you understanding how a computer works.A few simple example (simple usually means that the compiler will correct your misstakes, but I rather not get into to many details):

unsigned int a;...a = a / 2;// NO NO NO..., this is equivalient to a >> 1 in many cases over 20 times faster

The next block dels with row major ordering, the code risks running several __thousands__ of times slower than foo[i][j] = bar() due to cache and MMU misses Y

For those who couldn't figure it out (it took me a few minutes of thought to "get it") the reason why is that precision is limited such that adding (let's do this in base 10 with 4 significant figures) 1.562*10E-5 to 1.328*10E+30 gets you 1.328*10E+30, even if you do the addition 10E50 times. If you start with the little numbers, you'll have added all of the little numbers up by the time you start pushing your significant digits farther and farther from the decimal point. If the ans

Good code now days has more to do with structure and maintainability as opposed to squeezing every possisble extra CPU out of a procedure.

You write as if the two are mutually exclusive. IME, while this can be true, it rarely is in practice. The number of people who selectively quote part of Hoare's warning about premature optimisation, and use this as an excuse not to consider efficiency in their programming, is a major contributory factor in the amount of sucky code in the world today.

Java and.net devs are a dime a dozen. Learn Assembler and C, learn howto really performance tune a system and you can clock out hundreds an hour. As long as computers run C and Assembler at some level (and you can bet your ass were a ways away from that changing) people who know those tools will be in demand. So stick with writing your buggy and bloated Java storefronts by all means.

As a first programming language, if you are serious about programming, learn C or some Assembler, this will make you understand how a computer actually works and think before you write sucky code.

I disagree. It's not necessary to know C or Assembler to program, or even program well (program efficiently, perhaps). It'll teach you about the low level workings of a computer, sure, but not knowing how computers work at a low level is not, I don't think, the reason for 90% or even 95% of all the "sucky code" you'll find.

As a side note, it is interesting that at the school at which I took my MSc, they used Haskell as a first starting language, basically to tell everyone that "you don't know shit about programming" and bring the sufferers of the perfect programmer syndrome down to the ground. A very good thing indeed.

I created this site [programmingbooks.org] about 6 months ago for programmers to rank their favorite programming books. The concept is simple, you rank your top 5 favorite books for a particular subject like "Ruby" or "Software Engineering". Specifically here are the top ranked Ruby Books [programmingbooks.org]. And here's the list of Top books every programmer should read [programmingbooks.org].
Of course, this only really works well if more people rank books, so if you've read this book, rank it(and any other ones you've read).

I used to buy these books -- Ruby, PHP, Java, etc. But I realized a startling thing -- I never used them after I read the first couple of chapters. Because those first couple of chapters inevitably showed me that it was just another programming language. It was either OO or proedural, but outside of that no significant differences.

So why waste 40-60USD on a book that provides information that is freely available on the Internet? Is it really something that looking at free documentation and examples wo

Try Haskell - I've been trying to learn it for several weeks now, but coming from a C background I'm really struggling. That's not necessarily a criticism of Haskell, more a sign of how different functional programming is to procedural programming.

Me too, but strangely I think it helped more than it hurt. By the time I was fluent in Perl, every other language seemed easy to grasp. It also taught me proper object-oriented programming by punishing me mercilessly for having a poor design. I guess it's kind of like the school of hard knocks for programmers.

Perl is great for sysadmin scripts (actually, though, so is Ruby) - what it's not great for is huge website projects (unless your a masochist - slashcode, i'm looking at you). The problem with Perl and PHP for large web projects is that even with decent project management, one bad programmer can make problems for the whole team a few months down the line after deployment. The thing I like about rails is that it forces the developer into good code-separation practices, which is a very Good Thing when you'v

Heh. Don't get me wrong, I love perl; particularly because of how intuitive it is (at least for me). What I find to be perl's biggest flaw is that while, yes, it is intuitive to many people the perl that I write is almost a different language from the perl that everybody else writes - which helps make it an intuitive language, but at the same time makes it hard as hell to read somebody else's perl code; which, in a production environment is simple unacceptable.

I know (as in, have written a substantial amount in) perl, java, ruby, C++, C, and (god forbid) PL/I. I am acquianted with quite a number more (like Haskel, Lisp) And have no fear, ruby is a fine language to start with. Especially the irb shell is very nice for getting your bearings, and the functional support will be good for you if you ever turn to the hardcore languages, like Haskell, C++ and that ilk. On the other hand, if you prefer the more limited languages, like Java, you will still have a good idea about most concepts you'll find. The only thing you will not learn that are common is static overloading and type checking, which is easy enough to pick up.

the functional support will be good for you if you ever turn to the hardcore languages, like Haskell, C++ and that ilk.

I think that's the first time I've seen Haskell and C++ lunked in an "ilk" together. I don't think that most new programmers would find much use to the functional piece of Ruby, because you can just as easily write procedural or OO code. Functional programming, at least for me, is something that you have to get used to and that I would never have gravitated towards in a self-guided ex

Unless you have an understanding of functional programming in the first place (i.e., have studied the Lambda Calculus, a Lisp dialect or Haskell) I think that most newbies programming in Lisp are going to generate (at first undisciplined) code resembling the bastard child of Smalltalk and Algol, using procedural and OO methodologies, not functional ones.

I don't think that's all that true. I think it easy for people who themselves came to program through imperative and OO programming to think of those approa

I think that's the first time I've seen Haskell and C++ lunked in an "ilk" together.

They are really not that dissimilar, though the syntax are:) (Meta)-programming with templates in C++ and doing Haskell is remarkedly similar, though the syntax is not --- if you don't believe me, have a look at the boost::lambda source. Anyway, above I just meant that they are both advanced languages, as in powerful and difficult to master.

As to the rest of your comment, I think passing closures around will come naturally to most newbies of taught. The hard part of functional languages, using the lambd

Many computer science departments, including MIT, use Scheme as the language for their introductory computer science course. It's a wonderful language and helps the students learn a lot of key concepts that are important for formal computer science.

Scheme, though, is a little hard to use for real-world work. Ruby, on the other hand, is a great real-world language that has many of the features that I miss from Scheme: closures, lambda expresions, etc.

I haven't read this book, so I can't recommend it, but I can heartily recommend Ruby as a language that would be great to learn to program in. It'll let you focus on the key concepts rather than the tedium of implementing them in lower level languages.

Does a beginner programmer really need all those features? Personally, I started out using QBasic. I think it's a good idea to start off simple. You can't expect to know everything as soon as you start. I think it's a good idea to go in small steps. Something like:

Very few languages let you do the first three without worrying about classes and/or functions. If you pick Java as your first programming language you'll have to learn about classes and functions, even to just write your first hello world program. You won't have to know very much, but it's easier to grasp these concepts one at a time. Therefore, I find a good progression of languages to be Basic, C, Java (Or C#,VB.Net,any other OO Language).

I think you're grabbing the wrong end of the question. From either an instructor or student's viewpoint the concern should be whether the language requires you to know all those features to do even simple programs. As you point out, Java requires a lot of overhead to write "Hello world". Ruby doesn't. The reason I think Ruby would be a good teaching language is that you can start small, but take it as far as you want with regard to OOP, functional programming, etc., all without having to switch language

As an MIT alum, I'm a big fan of SICP. However, not many curricula use it and a lot of people "don't get it." I'm not sure why you addressed your response to my earlier message, I wasn't one of the advocates of "learn assembly and C first". I'm saying that Ruby wouldn't be a bad choice for a first language because it doesn't bog you down in lots of overhead early on, but has enough richness that you can carry on with it through some very sophisticated concepts.

I think Ruby would be a great first language. But you may want to also look at Chris Pine's Learn to Program as well as the book reviewed here: what I've heard about it is good, though I haven't looked at it myself.

I would start with Lua, Maybe. Then again, I just might not have enough experience with it to know where it falls short. (Anyone have the answer?). The reason being, is that it is very very simple and that is pretty much it. Not a whole bunch of crap. Then again I started with Javascript and Visual Basic, and those are both great places to begin. Comfortable development environments. With javascript, you can make an HTML form and a button that calls the function, and play around with the language. Ve

+1 on this. Why's Poignant Guide to Ruby [poignantguide.net] is the best tech book I've ever read. I just wish it was available when I was a newb. Why's book is not finished yet, but one can easily learn the basic programming concepts. CHUNKY BACON!!:-)

nah, I'm an old fart LISPer, haven't written any for 13 years. Ruby is more fun if very slightly less powerful. I've decided I like languages that are built to get shit done rather than tickle ivory tower fancies.

Ruby is very much like Lisp in many aspects, of course not in all, especially not syntax, but that is actually the good thing about Ruby. It gives you almost all the power of Lisp, but with a syntax that is much easier to read. I mean macros in Lisp are cool, but the blocks in Ruby are just way more readable and more practical, not as powerful, but powerful enough.

As someone who writes mostly in Scheme, and hence doesn't even have significant line breaks and does (x ((y z) w)) all day, I can say that you're just plain wrong. Set your editor to spaces and you'll never see a problem. You just won't. Any decent editor backspaces over spaces as if they were tabs anyway, so it is completely transparent. Significant whitespace isn't the issue. What might be is a lack of good error reporting. I think if Guido were to start over, he'd disallow tabs completely, and simply er

Scoping is fucked in Python, it's true. It's the main reason I don't use it. Certainly a language like that nowadays should have proper lexical scoping? It isn't as if it is some pure message passing model that it makes sense not to have it.

Sure, that's a problem, but not exactly a big one. You can solve it with a global search and replace if it ever crops up, whilst some of Ruby's problems are more difficult to get around. And the problem only crops up if you're copy-pasting code from a third party who shares different coding conventions to you.

Well, yeah, those are advantages, too. Its hardly as if one advantage negates the others.

Any problem that can be solved in five seconds by a decent editor is not much of a problem. Especially when it's compared against Ruby's performance, or should I say lack of it:)

Once you are an experienced Python programmer it isn't a problem, but it can be a pain dealing with white space sensitivity while you are learning. The biggest problem is that the Python code will *look* right, but not execute.As an experienced programmer prior learning Python it only caused me mild heartache. I don't know how easy or hard it would be for a total newcomer to programming. If they are some of the people that were in my early CS classes, I'd say they'll never get past it without help.

Sure, that's a problem, but not exactly a big one. You can solve it with a global search and replace if it ever crops up, whilst some of Ruby's problems are more difficult to get around.

Such as...what? The two main complaints I've seen about Ruby features are (1) lack of good Unicode support, which is certainly can be a real problem with I18n, but isn't a barrier to its utility in learning to program, for sure; and (2) its "too slow", which, again, isn't a barrier to its utility in learning to program in it

Such as...what? The two main complaints I've seen about Ruby features are (1) lack of good Unicode support, which is certainly can be a real problem with I18n, but isn't a barrier to its utility in learning to program, for sure; and (2) its "too slow", which, again, isn't a barrier to its utility in learning to program in it

Well, I was talking generally, rather than just from a beginners point of view. However, from a learning perspective, personally I found Ruby's class model to be more difficult to grasp than Python's, and it still has some odd bits to it. It's more elegant, however, I'll admit.

Ruby's syntax itself is also not as suited for a beginner, in my opinion, as there a lot of different ways to do the same thing. If you're learning by example, and each example employs a different technique, you have more to learn. S

Ruby's syntax itself is also not as suited for a beginner, in my opinion, as there a lot of different ways to do the same thing. If you're learning by example, and each example employs a different technique, you have more to learn.

I'm not sure this is really a weakness as a language for beginners; certainly, there is more to learn before you've learned every way to do everything, but that also means that there are more different approaches (suited for different learners) that can be taken and still cover t

But Microsoft and 3rd party contributors to.NET will always skew the ecosystem around it to its own ends, even if it is an open standard. No one will care about ECMA-compliance, only the latest-version-of-.NET-on-the-latest-Windows-serve r compliance.

Coming from a background of PHP and some C++, I could never "get" OO-programming - it just seemed over-complicated and pointless. With Ruby it started clicking almost instantly. The way that *everything* in Ruby is an object really forces the paradigm on you, and the ease of creating and extending objects really greases the way into using objects and thinking about your program in object-oriented terms