[pluma]

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.

[saneshark]

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.

[ploxiln]

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

[epidemian]

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

[ploxiln]

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

[skywhopper]

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.

[svisser]

The absence of an object is not a special case.

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

[byroot]

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

[ploxiln]

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)

[dragonwriter]

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

[epidemian]

> 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

[skywhopper]

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.

[yellowapple]

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

[lmm]

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.

[MrBra]

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.

[Argorak]

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

[dopamean]

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.

[bigtunacan]

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

[pluma]

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

[bigtunacan]

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.

[WorldWideWayne]

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

[matchu]

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.

[eyejay]

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.

[WorldWideWayne]

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.

[twblalock]

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

[WorldWideWayne]

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.

[foz]

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.

[mojuba]

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

[aikah]

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.

[ssmoot]

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.

[eropple]

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

[ssmoot]

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

[eropple]

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

[chc]

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

[ssmoot]

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.

[eropple]

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.

[Sir_Cmpwn]

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.

[pluma]

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.

[Sir_Cmpwn]

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.

[pluma]

We don't disagree.

[pluma]

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

[codingdave]

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

[userbinator]

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

[mirceal]

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.

[pluma]

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

[mirceal]

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.

[userbinator]

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.

[eropple]

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.

[MichaelMoser123]

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

[pluma]

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.

[nateberkopec]

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

[cremno]

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

[yedpodtrzitko]

another example: > a=a => nil

but then:

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

[shostack]

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.

[skywhopper]

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.

[claystu]

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.

[sethammons]

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.

[yellowapple]

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

[pluma]

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

[yellowapple]

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

[dragonwriter]

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

[yellowapple]

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

[MrBra]

> This is the typical HN bias.

Go check on Reddit then ? :)

[kailuowang]

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.

[fokinsean]

> Haskell

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

[dragonwriter]

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.

[claudiug]

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

[machiaweliczny]

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.

[MrBra]

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

[hellbanner]

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.

[Yen]

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.

[pluma]

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.

[zoidb]

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.

[rubiquity]

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.

[claystu]

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.

[dragonwriter]

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

[claystu]

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.

[15155]

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

[MrBra]

> Ruby isn't widely used in practice

I paused reading to write this: waaat?