Hello Ruby – Almost there(blog.helloruby.com) |
Hello Ruby – Almost there(blog.helloruby.com) |
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.
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
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...
> 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 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.
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".
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.
`Console.WriteLine` is also totally unclear as to what it does compared to `puts`, which basically says exactly what it does. /s
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.
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.
# 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
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
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.
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.
>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.
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).
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".
> 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.
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.
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.
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 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 do you mean by this? Can you give an example?
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.
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.
Having said that, Ruby is the superior language to Python once you get going, in my opinion, because of what it steals from Smalltalk.
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.
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.
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.
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.
seriously? I had a semi difficult time understanding FP a year and a half into my CS degree
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.
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.
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.
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 paused reading to write this: waaat?
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.
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.
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.
Incidentally the book costs less at retail, then even the lowest tier of it's Kickstarter campaign.
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 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
That said, I still fail to recognize recursive patterns far to often.
"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...
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.
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.
Incidentally, Ruby is great for beginners thanks to its expressiveness.
These advanced fratures are used mostly in metaprogramming.
Ruby is like the guitar: easy to learn, hard to master.
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 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.
but then:
> a=b NameError: undefined local variable or method `b' for main:Object
Though I wouldn't use Haskell for kids; I don't think the tooling, resources, and compiler error messages are great for that.
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!
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.
For JavaScript you only need a browser.
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.)
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.
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.
[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.
ASP.NET isn't a language, its a web framework for .NET; usually used with either C# or VB.NET.
Go check on Reddit then ? :)
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 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.
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).
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.
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 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)
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".
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].
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.
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).
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".
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).
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.)
Can you remember any examples? I can't think of very much in plain Ruby that's non-obvious.
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.
To indicate that with a "nill" object is a special case?
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"
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).
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.
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.
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.