Hello Ruby – Almost there | Hacker News Reader

Hello Ruby – Almost there

blog.helloruby.com

231 pointsyorak122 comments

I'm not sure whether Ruby is a good intro to programming.

It doesn't have first-level functions, instead it has blocks (which can take parameters to serve the same use as functions but aren't). What would syntactically be a reference to a method in other languages instead invokes the method with no arguments. It doesn't have namespaced imports, instead its imports effectively behave like includes (i.e. the "dump truck" approach to imports). I could go on.

Ruby isn't widely used in practice (although its users tend to be vocal and particularly prevalent in the web startup scene). Installing it requires some amount of care and technical knowledge (don't even bother installing it with a Linux package manager -- you're almost guaranteed to end up with the "wrong version" of ruby and rubygems).

I understand that Ruby programmers tend to be very emotionally invested in their programming language and that this book is probably written for Ruby programmers looking to teach their kids programming (using their favourite programming language) but it would be nice if there were well-written books aimed at a more general audience.

I'm not sure what the "best" first programming language is. JS has its merits -- it's becoming increasingly important, can be used throughout the entire stack of a web application and all you need to try it out is a modern web browser. Python is a lot more straightforward to learn and has consistent and mostly unsurprising concepts that are generally very compatible with more mainstream languages (plus it was intentionally based on a language developed for beginners). If market use were the main concern you could probably argue for Java or C# (although I think starting with a class-based language locks you into the wrong mental model).

In any case, I don't think Ruby is the best choice, even with its quirky community lore and the general emphasis on "play" and expressing yourself in code (although this seems to have died down a bit as the community matures).

I guess it depends on whether you want to teach programming as an art form and toy, or as a general skill (like maths, biology or chemistry). Both can be fun and entertaining but maybe I'm just getting old and cranky.

is for kids. I found you post quite strange. Every language has good parts or bad parts. so, because ruby does not have first-level functions is a bad languages, also because does has block is bad. The same for namespace. But let me put it this way. Are you an expert in language design and are you an expert on how children learn new stuff? Or you just don't like ruby as a language. Also, Ruby developers tend to be emotionally. Again very biased against the people that use ruby

Well ruby can be written in a very boring way if it's what you don't like :

     # nobody can say he doesn't understand that code , whatever language he is used to

     reducer = lambda {|res,val,array| return res+val}

      def reduce(array,reducer,initial)
        res=initial
        for i in 0...array.length
          res = reducer.call(res,array[i],array)
        end
        return res
     end

     reduce([1,2,4],reducer,0) # => 7

But there is no perfect language which is a good intro to programming. Ruby has all the building blocks needed for teaching programming.

And you're pointing namespaces but PHP has the exact same problem. Nothing prevents developpers from using namespaces in their scripts.

     #foo.rb
     module Foo
       module Bar
          def biz
            return 10
          end
       end
     end

     # main.rb
     require './foo'
     include Foo::Bar
     biz() # => 10

> don't even bother installing it with a Linux package manager -- you're almost guaranteed to end up with the "wrong version" of ruby and rubygems

Because that's not the case for Python or PHP on linux too? I bet it is,and it has nothing to do with the language itself.

> If market use were the main concern you could probably argue for Java or C#

The course isn't for CS undergrads.

Your opinion but some points aren't fair at all.

Your example is understandable, but not the norm. Most ruby in the wild is much more esoteric (and that's what you get when googling).

>Because that's not the case for Python or PHP on linux too? I bet it is,and it has nothing to do with the language itself.

I don't know about PHP, but the Python situation is very workable. It's basically just 2 or 3, and you can write code that is portable between them, or better yet - it's not difficult to only use python 3.

For PHP you only need a run-of-the-mill sub-$1/month webspace provider and FTP. And that also gives you a way to share your projects with friends.

For JavaScript you only need a browser.

I think PHP is harmful and should never be a first language.

JavaScript is getting good enough to be a good first choice, though, and it is very easy to get up and running with.

We don't disagree.

Python and most JS module systems have namespace-based imports. The idea is that the entire content of a module is wrapped in a namespace (i.e. an object). This allows maintaining a clear separation between your local names and the imported names, you have full control over what names in your local namespace are touched when a module is imported.

I think using PHP as an example in defnese is misguided -- I don't think anyone here would argue that PHP is a good introduction to programming although it's certainly something that introduced a lot of "us" to programming ("us" being web developers who started with programming in the late 1990s or the turn of the millennium).

> Because that's not the case for Python or PHP on linux too? I bet it is,and it has nothing to do with the language itself.

It has everything to do with the language. There's no point learning any language if you won't be able to try it out. So availability is a major factor.

PHP is supported by nearly every a-buck-a-month webspace host out there, which is why it is so accessible to anyone who can figure out how to use FTP. JavaScript is supported by the browser itself -- something nearly everyone is likely to have already installed on their computer.

Python, Ruby and so on have to actually be installed locally. And even if your package manager for some reason doesn't have Python 3 available you can nearly always get a fairly recent version of Python 2 and PIP. But even so, Python is only marginally easier to set up than Ruby.

> Your opinion but some points aren't fair at all.

Sure. I didn't say there is a language that meets all of my requirements. But that's precisely the point: there is no perfect language, but IMO there are generally better choices than Ruby. Which choice is best for any given situation of course depends on how you weigh the different factors (e.g. Ruby is likely the best choice for parents who already are Ruby programmers).

I actually found c# much easier to learn than Ruby. (I learned it before Ruby).

The compiler helped a lot. It's also a lot more consistent. When I started Ruby, I often didn't understand why something I wrote worked. That's not a feeling I got very often from c#.

That's just my experience. But I'd suggest c# is probably a better beginner's language. Especially paired with VS and an outstanding OOB debugging experience far superior and more approachable to anything I've ever seen in Ruby.

I write Ruby for my day job (about a year and a half now) and C# for my own stuff (about ten years) and I'd go with Ruby as a pedagogical language ten times out of ten. C# is a good (not great, but good) language for building stuff you want to put in a production environment, but there's so much drag in the language that I would seriously worry about discouraging novices long before they get to the point where Ruby would bite them in the ass. C#, meanwhile, forces a novice programmer to understand types at a fairly deep level before they actually know how to make things work.

Ruby, on the other hand--well, SublimeLinter or equivalent provides detailed and well-explained warnings if Ruby code doesn't make sense or is potentially problematic. And while, IIRC, RubyMine offers a good interactive debugger if you're willing to pay for it, Pry freely offers an interactive REPL experience at any point in the codebase that, while less mousey, is IMO a better exploratory tool than you get with C#--you can't just drop into your app, at a specific breakpoint, and start whacking at things in the shell, it doesn't work. This is a huge demerit for exploratory programming. And I would gently suggest, and I'm not trying to rip on you in saying this, that it would be worth introspecting to determine whether Ruby's perceived inconsistencies were more on your preconceptions than on the language--because I felt the same way until I internalized it a little bit and went "whoa, that makes total sense, I was just looking at it backwards".

I think you have to understand Types when working with Ruby. Otherwise it's just syntax voodoo.

That's a big part of what helps a language like c# continuously reinforce a mental model that leads to better/easier understanding. IMO.

You can call `open` and pass it a URL in Ruby. But what does that return? What's the Type? Where do I look up documentation for it? What's available to me _right at this point in my code_?

Ruby makes copying examples a bit easier, but you have to hold a lot more in your head before you could be considered "proficient".

And then there's all kinds of caveats. You want to write an O/RM in .NET? Pick up the PoEAA. You want to do the same in Ruby? Well, one of the first things I did was write DataObjects. Because there isn't a consistent database access API for you already.

From there you want to map Rows into Objects? Be prepared to play Ruby Golf. Because your first shot will be unusably slow. Not because it's wrong. But because it turns out Ruby's performance has real world implications. So you memoize anonymous classes. You cache method handles. You run a thousand different micro-benchmarks on the performance difference between re-binding a cached method handle for a setter, or just calling instance_variable_set.

I think the complete lack of type declarations actually makes developing in Ruby much more complex. Even experience programmers can end up debating wether a breaking change between "truthy" and an actual Boolean is a good or bad thing.

With as much experience as I have in Ruby, `extend` and the self class stanza are still just weird.

Even after developing in Ruby for years I'd still run into code that was just real difficult to understand how it worked at all.

I guess what it comes down to is I'd argue declaring all your method parameters as `Object` in c# is not going to make writing working code easier. It may make compiling easier, but that's not really the goal.

It sounds like you're a fan of Pry. I never cared for it personally. I found it much less intuitive than clicking in the gutter, running my program, and being able to mouse over a variable to see it's value, or look in a panel to see the full program state at this point. For a learning tool, I feel like that's got to be light years better than the solutions I've seen in Ruby. I managed that in c# without any help at all.

As far as exploring, Types generally tell me all I need. In Scala and IntelliJ I just hit ^J. Or I'll jump to the source of a method I'm calling with COMMAND+B. Or the implementation of an interface with COMMAND+SHIFT+B. These are just things I got out of the daily tips popup.

Seeing a function called: `generateDownloadUrl: Photo => String` tells me more in less time and space than the equivalent Ruby method or lambda ever did. Because in Ruby you don't know the requirements until you read the source or documentation. Whereas in Scala (which I wouldn't actually recommend to a beginner, but the same is true in c#) you have to resort to documentation or reading the source far far less frequently. Which for me at least is a much lower cognitive load.

Because of checked exceptions, switch statements and FactoryFactoryFactories I probably wouldn't suggest Java. But I think that languages that self-document the Types at declaration points are much easier to grasp than languages that still have the types, still require an understanding of them to be proficient, but omit those declarations (like Ruby). In Ruby you basically have to memorize a large chunk of the standard library before you feel proficient. The same isn't really true for Scala, Java or c#.

It's easier to build a mental model (for me) in those languages. And that's the biggest barrier to understanding and feeling like you grok it (at least for me).

It's interesting that you say all that--because none of that rings true to me. Quite literally none of it. Even the idea of understanding types is foreign to me, because I only think of types as collections of messages that objects respond to and use them only as shorthand for exactly that; like, my yardocs are full of [#to_sym] as a "type" instead. Things like `extend` are trivial to me, and I can explain both their semantic behavior and their implementation in three sentences. I find Ruby fairly consistent and its libraries no more difficult than .NET--and seeing as how because of plenty of bad decisions you can't really trust IntelliSense in the first place (like, say, arrays implementing IList<T> but throwing an exception for Add()), I find myself Googling no less for the documentation in .NET. And much, much less than in Scala, though I am very comfortable in that, too.

I'm curious, though. When you say "Ruby", how much of that was outside of Rails? I don't intend that as an ad-hominem, but rather in the exploration of a theory that I've had for a while. I am wondering if the approach one takes to learning the language and the ecosystem influences how much "magic" there is to Ruby. What you describe sounds familiar from friends and colleagues who learned Rails, and Ruby incidental to it. I only vaguely know Rails at all, I don't use Ruby for web applications beyond a Sinatra server as a dumb API.

(And, as I said, RubyMine has a stop-the-world, click-around debugger, much like Visual Studio. I've only used it once or twice, because the REPL is comfortable to me, but it does exist.)

> When I started Ruby, I often didn't understand why something I wrote worked.

Can you remember any examples? I can't think of very much in plain Ruby that's non-obvious.

Local Jump Errors everywhere.

But I remember specifically using open(url), parsing some HTML, and writing out a CSV. Today there are libraries to make that trivial for an experienced Rubyist, but this was Ruby 1.8.0. FasterCSV was still just around the corner, there was no hpricot yet. And you're working with blocks right out of the gate. The little 40 line program (including whitespace) took me quite awhile. It read (what I thought was) very pretty. But I think the Ruby community tends to take for granted how big a role idiom plays in Ruby. In the early days when you didn't necessarily have access to all that, fighting your way through syntax errors trying to learn the language by referencing the pickaxe was definitely one of the bigger challenges I've faced as a programmer.

By that point I was already very proficient with c#, had written a fair about of VBScript in ASP3. But I really struggled with how opaque learning how to be productive in Ruby felt.

I'm curious how many of your criticisms are reflective of Ruby as of today, rather than the Ruby that upset you when you were starting. I learned Ruby literally eighteen months ago, have never written code against 1.9 to say nothing of 1.8, and everything in this thread is totally foreign to me.

What i don't like about Ruby is that undefined variables can be accessed without error (just like javascript); Python is better in this regard;

However pythons indentation think is not so great for teaching intro to programming.

i have my own small project - the pooh language; it probably has other features which might annoy some people (downside is that it does not have all these libraries that the grown up languages have ...)

http://mosermichael.github.io/cstuff/all/pooh-lan/2012/12/11...

I find that Python's indentation is actually useful for beginners. It forces them to format their code and as long as they use an editor which shows invisible characters and can be configured to convert tabs to spaces, they tend to get used to it very quickly.

I say that as someone who has repeatedly had to help JS beginners with what I like to call accidental indentation (basically the result of copy-paste and accidental programming -- throwing code at the compiler until it works). Consistent indentation can go a long way for making code parseable by humans.

> What i don't like about Ruby is that undefined variables can be accessed without error (just like javascript)

What do you mean by this? Can you give an example?

Accessing undefined/unitialized global or instance variables (like: @i) is not an error and nil will be returned. With -w a warning will be emitted. The weird class variables must be initialized. Local variables (lexically scoped) must be defined and are default-initialized to nil. (Global and class variables are usually not used.)

another example: > a=a => nil

but then:

> a=b NameError: undefined local variable or method `b' for main:Object

ClojureScript could be decent: easy setup (now), extremely simple primitives, unassuming features.

As someone who has taught several beginners (non-programmers) Ruby, I would say the uptake is good. Teaching at events like RailsGirls, I've had complete beginners start to "get it" and deploy their own websites using Rails and Heroku within a day.

My personal experience has been that it makes a great first language, It's very natural to write, and easy to type. You start with super-short examples that are easily understood, using a bare-bones editor. Explaining blocks and iterators is a challenge of course.

There's quite a lot of approachable and creative content about learning Ruby out there, which makes it helpful for beginners looking to self-study. Books like "Hello Ruby" are great for kids starting from zero, who need more motivation and fun compared to the "For Dummies" or "From Scratch" approaches.

That being said, I agree with your feelings about the language as intended for beginners. However, I tried to teach my 9-year-old daughter Java (using an online course for making Minecraft Mods). And although she was able to get through it, Java is still perplexing. The IDE, strictness and verbosity were overwhelming. Similarly, I tried to teach my nephew Javascript (we made a game together) in a browser. Trying to explain `.this` and dealing with input handling was pretty hard to get through. He didn't take it much further.

Re: learning to code... I believe it's not so much about what language you choose to teach. It's about the quality of the course materials, and how quickly the concepts can be understood. Ruby has a lot going for it there.

> It's very natural to write, and easy to type. You start with super-short examples that are easily understood, using a bare-bones editor. Explaining blocks and iterators is a challenge of course.

Same can be said about Python, Swift, JavaScript, Lua, i.e. any high-level language polished and mature enough.

And an anecdote for you: my kids tried some of the above, they liked Lua most and Ruby least of all. Why? I guess the question is as complex as why some games are more popular than others, there is no clear explanation to these things really.

> I'm not sure whether Ruby is a good intro to programming.

> It doesn't have first-level functions, instead it has blocks

Hold it right there. If first-level functions, blocks and module systems are the first thing that springs to your mind when talking about teaching people with _zero, none, absolutely no_ previous experience with coding, you are speaking at a completely different level.

That reads far more like an attempt to discredit a language you don't like then actually caring about the subject matter at hand (teaching coding to kids).

I taught code at a programming bootcamp for a little over year to people who mostly had no experience programming. For the first 12 months the curriculum was mostly Ruby. I found it incredibly easy to teach Ruby to people and my students were able to build cool stuff relatively quickly with Ruby.

I taught over 100 people in that time and the vast majority of them are doing just fine now. Many are programming in some other language (Java, c#, python, js are common ones). Something about Ruby worked for them.

This is a book for teaching young kids. Trying to start them off with a language like Java or C# would be a terrible idea; not because they are bad languages, but because they have such a high learning curve.

With something like Ruby we can start the child right off with

puts 'Hello World'

Immediately they have a positive feedback cycle. At this stage they don't need to know that a top level object has been implicitly created for them and this statement is part of that object. We'll get to that stuff later. Start off basic with some simple lines of working code. Move up to conditionals, loops, add in methods later in a sort of procedural fashion. Eventually higher level concepts will be introduced.

Also to this point of yours, "It doesn't have first-level functions, instead it has blocks (which can take parameters to serve the same use as functions but aren't)."

That is one of those things that comes from someone that hasn't spent enough time with the language. While the treatment is slightly different, the outcome is the same. Ruby supports closures and passing methods to methods.

Before you retort with, "But blocks/procs aren't 'really' methods", you might also want to step back and realize that Ruby also allows any method to be passed as well using &Object.method(:method_name); that basically says "Oh hey; pass this method just like a block".

Sure, C# has a terrible learning curve because you'd have to type `Console.WriteLine("Hello World")` instead of `puts 'Hello World'`.

`Console.WriteLine` is also totally unclear as to what it does compared to `puts`, which basically says exactly what it does. /s

The difference isn't the actual print operation; it's all the boilerplate that has to go around it.

In Ruby, `puts "Hello World"` and you're done. The most you have to explain is puts and string literals.

In C#, you have to create a class with a static main method. You're then left to choose between explaining classes and methods ("what's static? what's void?"), or skipping that and just treating them as the magic incantation for running a program. Pedagogically, neither is satisfactory.

Ruby wins the Hello World simplicity contest, hands down. The question is whether the long-term benefits of C#'s program structure are worth the increased overhead in the Hello World experience.

I think a huge plus for Ruby is the limited amount of specific punctuation required for calls like this. For you average middle or high school student this might not be a big deal, but as soon as you start working with elementary school students every small barrier to entry is a huge deal.

Books like this shouldn't be designed for the children that would enjoy hunting through and finding the missing quotation mark - those children already have tons of resources out there for them. I think Ruby is a great choice, specifically for this reason, and I wish there were more resources like this available when I was setting up K-5 CS curricula a few years ago.

You don't have to create a class with a static method if you use LinqPad which can run like a REPL. It can also pickup a file with that single line in it and execute it, so there is virtually no difference.

That's too many hoops for a child learning programming to jump through. There is a real difference in simplicity between Ruby and C#.

Installing a program is not too many hoops. You have to setup a computer for ruby too and the kids aren't doing that part.

If I'm on a Mac there is no setup; Ruby is pre-installed. Also, if they are just starting out and they don't want to keep things around there is tryruby.org.

For kids using Windows I usually have them sign up for a free account on Cloud 9; again virtually no setup required.

Also, now you are trying to compare LINQPad, a tool, to just using a language?

In your example you used `Console.WriteLine("Hello World")`, excuse me if I'm wrong since I don't write much C# anymore, but isn't that an invalid statement? I'm pretty sure that's missing a semi-colon at the end. Try explaining that to an 8 year old; because that's the age of kids I start working with.

10.times do

  puts "Hello World"

end

That is just easier to explain to a YOUNG child than the following

// Sorry: Using Java here since I don't do much C#, but I think we're in the same ballpark

public class HelloWorld {

  public static void main(String[] args) {

    for(int i=0; i<10; i++){

      System.out.println("Hello World");

    }

  }

}

None of what I said was an insult against any language; it was based on my experiences trying to teach programming to elementary aged kids (8 to 11 year olds).

The kids could also not have Macs and there are similar services for running C# online, so those reasons don't hold any water with me.

What you're argument boils down to is that `10.times.do` is better than `for(int i=0; i<10; i++)` because all things being equal, that's the real difference. You could argue against braces, but the I could also argue against the lack of braces. So the real difference is how you write the controlling section of the for loop.

Now on that point alone, I'd say that `10.times.do` is certainly easier to parse, but easier is not better. Why teach them a bad habit? Learning `for(int i=0; i<10; i++)` is actually better for kids since it hides less and it is actually much more useful in the real world since that's how the most widely used languages do it. Or, are you one of those adults who thinks that hiding the real world from kids is a good idea?

I guess you could also say that there is a reason we make things slightly easier for beginners of any age. Like having training wheels. But that is so you don't get hurt and the computer is not going to hurt anyone if the program doesn't compile. I also honestly don't think age matters here after they've been through the second grade.

EDIT: Also, yes, you can leave the semi-colon off in a LinqPad expression. But I also don't see a problem with explaining what a semi-colon is to a second or third grader, in the context of programming. I could also say "good luck explaining those oddly placed periods to those same kids" and it would make as much sense.

Ruby offers an abstraction that other languages don't. That doesn't mean that using the abstraction is a bad habit.

I agree that C-style for-loops can be handy, but the prevalence of this shorthand doesn't make it good pedagogy to skip right to it. Not everybody is ever gonna enter the real world of programming, and not all of those people are going to use languages with C-style for-loops, and, even then, for-loops aren't fundamental; they're just a shorthand.

> Learning `for(int i=0; i<10; i++)` is actually better for kids since it hides less and it is actually much more useful in the real world since that's how the most widely used languages do it.

C-style for loops are useful, though I think the historical window (that started with the dominance of C) where the most popular languages lack a direct and succinct way of expressing simple do-it-n-times iteration is closing.

Ruby's particular form may be different than others, but lots of current languages have succinct, direct methods for expressing the same thing. By the time a young child learning to code today is a professional programmer, having nothing better than C-style general for loops to express that common idiom will probably be unusual in non-legacy languages.

> Trying to start them off with a language like Java or C# would be a terrible idea

I'm not sure how you got the idea that I argued for Java or C#. I only mentioned them to rule out the argument that being widely used is a necessary or sufficient quality when determining what language you should teach to a beginner.

In the same vein I think we can also agree that Pascal is a horrible choice although it is still frequently used as an introduction to programming.

No, I think we were on agreement on that point. You said, "If market use were the main concern you could probably argue for Java or C# (although I think starting with a class-based language locks you into the wrong mental model)."

I took your main argument to be that Ruby is a bad first language to teach kids and Python is a good first language to teach kids.

I was agreeing with you on Java/C# not being a good choice. I disagree with your opinion on Ruby being a bad first choice. I thought your argument was also that Python was a good (better than Ruby) choice. I actually agree that Python is ALSO a good first choice to teach children with; I do not believe it is a better choice than Ruby; rather I would say they are equally well suited.

I don't think it's just that Ruby isn't a good intro to programming. I don't think Object Oriented languages are a good intro to programming. OOP is just way too abstract. In the teaching I've done (some adults and kids) they tend to get the basics of FP where everything is just a list much better than the weirdness of objects.

I think objects are intuitive. After all, we live in a world made of objects.

What confuses newcomers is the computer science vocabulary that everyone insists on using when teaching objects. I am a big fan of object oriented programming, but the vocabulary and terrible metaphors of introductory books reads like punishment.

The only language that has done a worse job explaining a simple concept is Lisp with macros. My God! It's like they're trying to keep Macro's a secret.

> I think objects are intuitive. After all, we live in a world made of objects.

We do not live in a world made of object in the OOP sense. (On a more fundamental level, we don't live in a world made of objects at all so much as a world we are prone to arbitrarily -- and not always consistently -- break up into objects for the convenience of thinking about it, but those objects still aren't OOP-style objects.)

Your "OOP sense" is exactly what I meant about confusing things with computer science jargon. To a beginner, treating objects as structs with functions is all they need to know.

JS will probably mess up my kid's mind as much as ruby.

My choices for intro programming language would probably be Haskell and Coffeescript - both has a simple but coherent set of concepts and a straightforward syntax designed around those concepts.

> Haskell

seriously? I had a semi difficult time understanding FP a year and a half into my CS degree

I think Haskell -- and FP in general -- is probably easier as an intro to programming than it is for people to pick up after they've been conditioned by imperative programming.

Though I wouldn't use Haskell for kids; I don't think the tooling, resources, and compiler error messages are great for that.

I'm probably in the minority here, but I think that starting with the low level - bits, data representation/interpretation, and logic (which leads to CPU operation) - is the best path to go when starting to learn programming, because it really dispels a lot of the "magic" and mystery behind computers that can confuse beginning programmers when their code doesn't work as they expect.

The idea that computers are conceptually very simple and logical in operation, and that any surprising behaviour is really the result of interacting layers of complexity rather than an intrinsic property of the machine, is something that should be firmly kept in mind whenever programming, or even just using, a computer.

I'm sympathetic to this approach, though it's not necessarily the one I'd pick anymore. I think there's real value to understanding systems at this level, and I find that it informs my everyday work. I'm not sure, however, that it's necessarily the best way to get somebody engaged and interested. I'm sure there are personalities that dig this sort of thing (mine does) but loads of people I've worked with or taught seem to be most engaged by the fast iteration cycle of something like a REPL. Personally, that makes me lean towards teaching with Ruby or Python (probably Ruby, as I think it has more to teach). I guess it's horses-for-courses.

I'm not sure programming is a good intro to programming.

It isn't the actual coding, or syntax of languages that trip people up, at least not when first learning. At any age, it is the logic that needs to come first. How code flows, branches, how to work with variables, and build up to more complex structures.

It is the same as learning math - you learn how to count to 10, then 100, then start manipulating them via basic addition. Or to read, we first learn the alphabet. For teaching kids to code, first they need to understand the very basics.

There are many products coming along that are working on ways to teach these basic concepts to children, using literal blocks in some cases, to give kids a base skill set before ever actually getting into what could be called "code".

Is something like Nand2Tetris ( http://www.nand2tetris.org/ ), but for a younger audience, what you have in mind?

When I was young the paramount thing to consider when picking a language making something cool that my friends/parents/anyone could play with. I could easily share little text adventure games and it was cool enough that I actually got other people to play them.. same thing with TI-85 programs. For this reason I wonder if Ruby will really get kids excited to program but I'm not sure (like you) what the alternative is.

I learned to code at age 7 with QBasic, deconstructing Gorrilas in DOS, and later SmallTalk. Both languages are horrible, but were incredibly easy to learn. No one taught me, I played with them until I learned, and back then there was no internet.

There are so many aspects of Ruby that make it well suited for teaching kids about programming that go WAY, WAY beyond the ridiculous observations you've made. You might as well have pointed out the performance limitations of Ruby too. Installing Ruby is as easy as opening a macbook. It's already there. It's not like little kids, learning the language for the first time are provisioning servers and installing from scratch.

It's not a matter of Ruby programmers being emotionally invested. It's a matter of Ruby, very often, being the right tool for the job. And for teaching purposes, I don't think anything else comes close. The fact that just about everything in Ruby is an object makes for some very interesting syntactical niceties that a child's mind can easily grasp. For children, the higher level the language, the easier it will be to grasp and remember. It doesn't get much easier than

    100.times do

Whether or not a programming language has 1st level functions or is production ready is not a consideration most people make when teaching a child. Learning how to code isn't about performance and elegance, it's finding your creativity, perseverance to stick with a problem, flexibility to adapt and change based on new constraints. After all these are the young minds that will be building the higher level programming languages of tomorrow.

To me that appears to be the strangest way to express a loop in any language I've used (and I've used a lot of them).

It also really bothers me that in ruby you can invoke a function on a null value to see if its null (myvar.nil?). That's really messed up...

> That's really messed up...

No, it's a brilliant use of polymorphism. "null" in Ruby is not a value, it's like everything else an object. So it have methods.

Just because you are not used to it doesn't make it messed up.

It's the wrong way to think about organization of logic.

It's not a number's place to know how to do looping, it's not an object's place to know whether it's nil or not. Why would every single object have a "nil?" method?

You can make it work, but it's just not good style (and it doesn't serve the purpose of implementation efficiency or machine-sympathy, which I would give exception for).

(also, special characters in method names?! my complaints about ruby really don't end with these comments, these are just the most succinct ones)

> It's not a number's place to know how to do looping

If we consider a number as "zero or 1 plus a number", then the "Number" class could very well be the one that knows how to execute a piece of code a number times given that representation. It's actually pretty similar to the Church encoding of numbers in the lambda calculus[1].

[1]: https://en.wikipedia.org/wiki/Church_encoding

> It's the wrong way to think about organization of logic.

This is not an objective statement, it is one of subjective preference, about which people (demonstrably, by the very existence of Ruby) disagree. The right way to think about organization of logic is not an objective fact, and...

> You can make it work, but it's just not good style

...neither is "style".

The number doesn't know how to loop. `100.times` returns an enumerator that can then be iterated upon. In real code, that particular method doesn't get used all that much, but its existence tells you nothing about Ruby's design.

Why shouldn't every single object have a 'nil?' method? It can be very useful. Think about operating on a collection of objects with `map` or `collect` or whatever your favorite language calls it. No need to write code, just send the `:nil?` message to every object, which you can do with one line.

You're right that "everything is an object" is not the most performant way to build a runtime, but it suits the purposes for which Ruby was designed very well. Just because you don't value those priorities doesn't mean others do not.

> To me that appears to be the strangest way to express a loop in any language I've used (and I've used a lot of them).

Well, given that repeating some piece of code N times involves only two "entities", the code to be repeated and the number of repetitions, i see it as a very natural OO design decision to put that looping logic on a method on one of those two entities. The other possibility would be to make the "code" object respond to a method that tells it how many times to execute:

  { puts "Hello, alternate Ruby" }.do_times(10)

It might be more intuitive to do so if the first object you have is the code you want to repeat, but it doesn't read as nicely :P

> It also really bothers me that in ruby you can invoke a function on a null value to see if its null (myvar.nil?). That's really messed up...

Can you elaborate in this please? I personally think that making nil something else than an object on OO language wouldn't make much sense. It would be an unnecessary complexity to stipulate "the way we interact with objects is through message-passing, except with nil, on which you cannot pass any message, but instead you have to compare it by identity to a global value named nil". Nil being a regular object that responds to things like .to_s or .nil? is pretty handy.

If you don't know the type which a name references (or whether it is nil), you have to figure that out before you call any methods on it, in an "external" way. So you have to do " == nil" or "typeof(mything) ==" or "isinstance(mything, type)". This is true for almost every method (except "nil?" in ruby.)

Ruby has a lot of these special cases where there's a gimmicky way to do something which is not the general purpose way and is not the right way to think about that kind of logic. "== nil" is just as short as ".nil?" and isn't as wacky as intentionally calling methods of nil (and every other object needing to have this nil-specific interface).

This isn't a gimmick or a special case. "nil" is an object of type NilClass, which is a subclass of Object: http://ruby-doc.org/core-2.2.0/NilClass.html

In fact, everything in Ruby is an object. Languages that treat "nil" or "44" as not being instances of a class are the ones making special cases.

The absence of an object is not a special case.

To indicate that with a "nill" object is a special case?

It only seems messed up because you know about pointers, which are an implementation detail. In an object-oriented language it makes perfect sense. I assume Smalltalk did something similar.

> To me that appears to be the strangest way to express a loop in any language I've used (and I've used a lot of them).

How is it strange? Feels rather intuitive to me: "Do this 100 times".

> It also really bothers me that in ruby you can invoke a function on a null value to see if its null (myvar.nil?). That's really messed up...

Again: how so? `nil` is just another object, so why shouldn't it have a method telling us if it's nil?

Of course, if you don't like it, you could check to see if it equals `nil`, or you can check if its class is equal to or is a subclass of `NilClass`. Like Perl, There's More Than One Way To Do It (TM).

If you knew nothing about programming that would not look strange to you. On the contrary, it might look as the most intuitive way to do it. And since this book is for kids who know nothing about coding... well, you can see where I am going.

I've gotten several people into programming. I have them start with Python & Ruby. They always think Ruby is simpler and easier to understand. Why's Poignant Guide to Ruby is a great read, too.

oh wow. there are a couple of things here I strongly disagree with.

> Ruby isn't widely used in practice.

Rails, Chef, Puppet, Homebrew, Cocoapods, Vagrant, Jekyll... The list goes on.

> Ruby programmers tend to be very emotionally invested in their programming language.

replace Ruby with any programming language and the statement it's true. human beings just work this way.

> I'm not sure what the "best" first programming language is

This misses the point completely. There is no best first language. People think they have all the answers, when in reality the experience of each individual is unique. Anything that gets you interested in programming / lower the entry barrier is a win in my book.

> Rails, Chef, Puppet, Homebrew, Cocoapods, Vagrant, Jekyll...

Most of these are primarily tools that can be used without being a Ruby programmer (even if treating the DSLs as black magic is worrisome). Rails is popular but despite how vocal its users tend to be it's not as widely used as you may think it is. Ruby is disproportionately widely recognized considering its actual "market share" (just like e.g. Haskell).

> replace Ruby with any programming language and the statement it's true. human beings just work this way.

Different programming language communities are different. I've met plenty of dispassionate PHP, C#, Java and JS programmers. I've yet to meet a Ruby programmer who doesn't hold the opinion that Ruby is the best thing since sliced Jesus, every language should always be replaced with Ruby and that Ruby is pretty damn close to perfect. I haven't met any dispassionate Python programmers either, but they tend to be far more nuanced about their opinion of Python.

Heck, the Ruby community came up with Haml so it could pretend to write Ruby when writing HTML, Sass (proper Sass, not the new-fangled more conservative SCSS) so it could pretend to write Ruby when writing CSS and CoffeeScript so it could pretend to write Ruby when writing JS. They even use Ruby for configuration files "because DSLs are easier" (unless you don't know Ruby).

Let's also not forget that the reason Codes of Conduct for conferences (and even open source projects) had to become a thing (e.g. the brogrammer culture) primarily originated in the Ruby community (before it spread to others). And also the entire _whytheluckystiff and Zed Shaw dramas.

You can fish for equivalents to these things in other communities but the scale and ubiquity is simply exceptional in the Ruby community. Just like PHP is exceptional in how much bad PHP code there is, Ruby is exceptional in what its community is like.

> People think they have all the answers, when in reality the experience of each individual is unique.

I'm not sure why you think we disagree about this. That's precisely what I'm saying: that Ruby programmers tend to love Ruby doesn't mean it's always the right choice for teaching absolute beginners.

I like Ruby. I don't have a problem with other programming languages :) I am more interested in what people build and what can be learned from those things. You can always draw parallels and learn new things. Focus on the good parts, not the trolls.

I don't think that Ruby is "is the best thing since sliced Jesus" (btw the expression is hilarious). So there you go, you have at least one data point that not all Ruby brogrammers are that way.

As an early programmer, I love Ruby. Not just in an emotional way, but rather a practical one.

I started out wanting to learn RoR and took a step back to learn the underlying language. What I found was something that read smoothly and just. Made. Sense.

Beyond that, community support and overall tutorial quality tends to be very high, which I largely attribute to my continued usage of it.

Firstly, I think the project looks beautiful.

Personally, I just can't stand Ruby, so my opinion will not be balanced. I think the optional parenthesis will be terrible for a new programmer. I think the optional return statement will cause confusion in some cases. The absolute worst is the once or twice I've pasted code into the editor, and when run, I get a cryptic error. Using a hex editor, I discovered that some unicode whitespace got in there and was interpreted as a method or variable. wtf.

For my daughter, we started with Python (and bpython from the command line for explorability). She got caught up on classes, but I think that is natural. She is starting to look at javascript now and we will see how that goes. I think both of these are interesting first languages to learn (not without their warts for sure!). For my youngest, we started looking at Scratch from MIT.

Is this book actually teaching programming using the Ruby language? It's a pretty fundamental assumption, but I actually can't tell, given the web site.

As far as I can gather, Ruby is the name of the main character, and it explores programming concepts in general, but does not actually 'teach coding'.

I can't actually find the text of the book, though...

Edit: other comments in the thread seem to indicate that it does not teach actual coding, and does not use the Ruby language.

Check the website: http://www.helloruby.com/about

I can't find any explicit mention of the Ruby programming language being used as an example, but it's pretty clear that the name of the protagonist is not an accident. The book itself doesn't seem to dive too deeply into actual code, though.

I'm sure I can agree that Java, C#, Python, or Javascript are any better than Ruby in terms of difficulty of installing and maintaining the "right" version on your system, or in terms of quirks that are not present in other languages. Python's block definition syntax can be extremely confusing to beginners. Idiomatic Javascript is very difficult to explain to a newbie. And Java and C# are overloaded with so much boilerplate syntax that someone trying to learn the basics gets overwhelmed in the first 10 seconds.

I don't think there's one "right" language to start learning to program in. Different languages appeal to different mindsets and are good at doing different things. There's no limit to what you can accomplish in Ruby, Python, C#, or any other language, so if you find something that works for your brain, go with it.

I would say Python and Javascript are both easier to install--you don't even have to install Javascript--and Python is easier to get coding in thanks to 1) fewer high level concepts that Ruby gets from Smalltalk and 2) Idle.

Having said that, Ruby is the superior language to Python once you get going, in my opinion, because of what it steals from Smalltalk.

I think that for learning basic programming the best language might be Haskell. A lof of people doesn't have in mind that program is "mostly" simple tranformation of data that can be composed of many functions. I think haskell with it's purity and strong type system teaches it fast. REPL helps. But I also believe in educational power of simple C, although it doesn't have REPL or anything like that, but combined with some simple introduction how computer really works - maybe RAM model gives quite an insight. But learning is fastest when you can see cool things happen fastest and I don't think any of 2 mentioned above is good at this. But yeah - for very basics of programming I would rather pick Haskell over Ruby.

> It doesn't have first-level functions, instead it has blocks

Ruby also has lambdas, which if not first-level functions, are pretty darn close.

> It doesn't have namespaced imports, instead its imports effectively behave like includes (i.e. the "dump truck" approach to imports).

I can't tell if you're talking about `require` or `include`.

`require` is strictly meant for loading source files. If you want things to be restricted to a particular namespace, you should use `include` to pull in a particular module (once the module's code has been `require`d or otherwise `eval`d or defined).

> Ruby isn't widely used in practice

What? Ruby on Rails is ridiculously popular as a web framework.

> Installing it requires some amount of care and technical knowledge

On Macs and many GNU/Linux distros, Ruby is already preinstalled.

> don't even bother installing it with a Linux package manager -- you're almost guaranteed to end up with the "wrong version" of ruby and rubygems

Um, what? The only thing I can think of is a really old packaged Ruby. Otherwise, it's actually pretty hard to go wrong, in my experience having installed Ruby on pretty much every GNU/Linux distro known to man.

> but it would be nice if there were well-written books aimed at a more general audience.

O'Reilly and Pragmatic Programmers both publish a wide variety of excellent Ruby programming books that are very much "aimed at a more general audience".

> I'm not sure what the "best" first programming language is. JS has its merits

Oh good god no.

> and all you need to try it out is a modern web browser.

If that's what matters to you, then you can do the same with Ruby. Take a look at tryruby.org, for example.

> What? Ruby on Rails is ridiculously popular as a web framework.

This is the typical HN bias. If you ask someone on HN what framework they think is most popular, they'll likely say Rails. But is this actually true?

In comparison to, say, Django or the various node frameworks, sure, it's popular. But in comparison to the "big guys" (the various frameworks for PHP, Java, C#) it barely registers.

> But in comparison to the "big guys" (the various frameworks for PHP, Java, C#) it barely registers.

[citation needed]

[citation needed] especially for C#; the only .NET-based language I know of that registers as even a blip in web development is, for better or worse, ASP.NET.

[citation needed] also for PHP frameworks; most PHP web "applications", in my experience, don't use any sort of "framework" at all, instead opting to use CGI with direct manipulation of HTML tags in order to do anything. Facebook is the only significant exception that I'm aware of.

> especially for C#; the only .NET-based language I know of that registers as even a blip in web development is, for better or worse, ASP.NET.

ASP.NET isn't a language, its a web framework for .NET; usually used with either C# or VB.NET.

In which case I stand corrected there (I was getting it confused with ASP/VBScript; I've tended to steer clear of either).

> This is the typical HN bias.

Go check on Reddit then ? :)

> Ruby isn't widely used in practice

I paused reading to write this: waaat?

> I guess it depends on whether you want to teach programming as an art form and toy or as a general skill.

So learning it as a general skill excludes the notion of art and gaming? What? If coding wasn't intrinsecally A LOT about PLAYING with ideas and concepts and designing them in the most simple/efficient, beautiful and creative way (art) then IT wouldn't have got where it is now.

> maybe I'm just getting old and cranky

From what you say and how you speak, yes you are. And you are also half conscious about it. You could have reached some kind of saturation point. Maybe you need to do something different for a while and find other stimuli somewhere else.

Looks great.

Recently, I was trying to wrap my head around eigenclass inheritance mechanisms and it was pretty tough. Not to mention the object model, where classes are also objects and the Object - Module - Class relationship. I wouldn't recommend Ruby as a first language to anyone — it may look easy at first, but to grasp it, you need to invest much more time in future.

People can get very far without knowing anything about that.

We are talking about a children's book, I don't think a reader of this book will have to maintain large codebases for a job anytime soon.

Incidentally, Ruby is great for beginners thanks to its expressiveness.

Sometimes the bias you have from learning programming one way makes it more difficult to grasp concepts which are different. I recall a study[1] where they questioned whether recursion is more difficult than iteration if it is introduced first. Certainly recursion was difficult for me when I was first learning because I had done a lot of programming using iteration first. It seems surprising that it may have just been a bias of what was introduced first.

I think that eigenclasses are a good example of this. Just because of the languages I learned early on, eigenclasses were obvious to me. I had a hard time even understanding why they had a name: OO without eigenclasses was just another way of saying "broken OO" ;-) Again, it's a bias which is hard to be aware of.

[1] It may be this one: http://dl.acm.org/citation.cfm?id=2361296

What troubles me the most with the iter/rec debate is that iteration is so trivial for most, but then many problems look intractable. Recursion feels awkwardly void, empty, almost nonsensical, but when you click your horizon broaden dramatically.

That said, I still fail to recognize recursive patterns far to often.

Eigenclasse, had to look that up:

"A hidden class associated with each specific instance of another class." https://en.wiktionary.org/wiki/eigenclass#English

https://gist.github.com/jfarmer/2625060

Yep. Makes perfect sense that if everything is an object, and class methods belong to a class, and a that class method has to be attached to an object -- you'd need an object to attach it to...

And in Ruby they are only "special" because they have been intentionally hidden from the publicly visible inheritance chain. Personally I think that's what makes it hardest for people to grasp.

E.g. if you define class methods on class Foo, all that's happening is that the class of the object defining Foo is no longer an instance of Class but of a subclass of Class. But it gets confusing because Foo.class still returns Class.

These are advanced subjects and even a proficient programmer doesn't need those very often.

The advantages of Ruby as a first language IMO are that it is a pure OO language. No special cases, no unnecessary boilerplate. Much better than Java in that regard. But you could argue if nowadays you still need to focus that much on OO.

I'll be interested on the book turns out. Usually, I wouldn't recommend a generic programming language as a a first language for kids. I would use something with turtle graphics and a REPL.

I think, day-to-day, the Ruby object model can be as simple or as complex as you'd like it to be. Most dynamic or static OO languages have just as much complexity under the hood (vtables, doesNotUnderstand, metaclasses, etc). It has to be complete anyway, so it's made accessible, for better or worse.

I think you're more likely to run into it in the wild in Ruby because it's better exposed than most languages. When you see reflection or meta-object APIs in a lot of (typically not-as-dynamic) languages, it's sort of a "HOLY FUCK, WATCH OUT, I'M METAPROGRAMMING" flag. In Ruby, it's easier to daintily follow the white rabbit into the object model and care about the relationships you're referring to.

But on its surface level (class keyword vs. Class.new, def vs. define_method), I don't see it being any more complicated than similar dynamic languages.

When you say "puts 1+1" in a blank file, I can't imagine that not grasping that you're in a binding of an anonymous singleton instance of an Object named "main" being an hindrance. What's cool is, if you need to know, there's not a weird brick wall in your way.

These are the advance features. You are not required to know how inheritance works (or what the Singleton is) to write runy code. You dont have to use OO design or anything. You can write procedural code in ruby if you want.

These advanced fratures are used mostly in metaprogramming.

Ruby is like the guitar: easy to learn, hard to master.

The character's name is 'Ruby' but I don't expect the book itself to be any sort of introduction to ruby-the-language!

I'm a backer — I expect the book might contain some Ruby code because it's pretty readable though I'm bothered either way. I am full expecting it'll be an engaging story to teach my kids some of the concepts of programming, which have nothing to do with any particular language.

Just to repeat and highlight this: THE BOOK ISN'T ABOUT TEACHING RUBY-THE-LANGUAGE

I've yet to even find a mention of Ruby-the-language on the site.

Right. It teaches programming concepts with Ruby. It's not about learning Ruby the language.

It's unfortunate that the currently top rated post on this thread is about the merits of using Ruby as an introductory programming language. That's completely off topic!

I also backed the book with the understanding that it would essentially use pseudo-code. For as long as I've followed it this has never been advertised as a book about learning a language, it's always been presented as a book about learning basic concepts.

What makes you think the book is ready? We've been told (KS backers) that the book isn't shipping until October 2015. There is absolutely nothing that you've linked to to indicate that it's ready.

Incidentally the book costs less at retail, then even the lowest tier of it's Kickstarter campaign.

It's always really disappointing for me when people see Kickstarting as a way of purchasing the end product. With economies of scale you should really expect prices to come down for retail. What you're getting for the money with a kickstarter campaign is the chance to help someone realise their product, which hopefully you believe in, without the creative inhibitions that come with strings-attached funding.

You must be disappointed a lot then?

I did believe in her product. What I didn't believe in was an utter lack of regard to KS backers, poor communication, misdirections, a publishing contract with Macmillan, a late delivery (while being less than truthful with KS about it).

The author bears some responsibility for changing my mind from believing in her product (what you call helping, "someone realise their product") to simply just wanting the end result of what I paid for at a higher cost than retail.

I guess my point was two-fold.

1) The end product will probably be cheaper than the kickstarter backing. (You seem to agree with this, at least in general)

2) People shouldn't see backing a product as a purchase. There's clearly risk involved in any transaction where the obligation of the seller to provide anything, let alone meet your expectation of exactly how the end product will be realised.

It's sucky that you've had such a bad time with this KS though, the real value in backing ought to be the opposite of what you've experienced!

I just purhcased the finnish version of the book and the status says it is shipped. Perhaps I should have waited until it is in my hands? :)

As another backer, I totally agree. This was one of the worst Kickstarter experiences of many mediocre to bad experiences. Projects like this are killing Kickstarter for me.

I found Python's rule of space and tab is the most confusing thing that will happen to a kid. They open a command prompt, then instead starting writing the real code, they have to <space><space>, blahblah , <enter><space><space>... to do something that they hope to run. It's a waste of time.

ipython improves this quite a bit. If you haven't tried it:

https://asciinema.org/a/2vvs3gg2dk93xizc3splrrfyw

It's all fun and games until the kids reach a gem dependency conflict that bundler doesn't fix......

library dependacy problems could happen with any language.

I don't believe the book is ready to ship yet, but I'm looking forward to when it is! I had the pleasure of working with Linda (author of this book) a few years back and she is really a wonderful person and I'm very happy for the initial success of Hello Ruby.

Ditto, had a chance to meet and work alongside Linda a few months ago and she has an incredible enthusiasm – looking forward to buying this for my younger cousins :)

Cool book, I hope you will get some success with it. I don't have a kid (yet) but I will maybe buy it as a gift as I live in one of the countries with publishers.

Cool. Would you translate into other languages? Having kids speaking Italian I would be interested ;-)

Cool. Would you translate into other languages? Having kids learning Haskell I would be interested ;-)

I probably would. I remember once I offered to translate a kickstarter project for baby girl engineers, so why not a book for baby programmers :-). Feel free to get in touch if needed.

Amazing book! I don't have kids :( but I would be more than happy to help for the italian translation

I have the same feeling, and would be more than happy to help with a brazilian portuguese translation (if the author is reading this, my email is on my profile o/)

That book is absolutely beautiful.

Torilla tavataan!

"Its" not "its'", heads up.

Reply on news.ycombinator.com