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