5 ms·
I think Ruby is a beautiful language but you really got to consider it in the context that it was invented in. Matz originally created it kind of as a spiritual
by dusklight 16y ago
I think Ruby is a beautiful language but you really got to consider it in the context that it was invented in. Matz originally created it kind of as a spiritual successor to Perl, and it's original incarnation was as an easy to write, easy to read, fun to use scripting language. Rails came along later, I don't think anyone was really expecting it before it showed up, and it changed the Ruby conversation entirely.
Ruby is excellent in many ways but I feel like Matz never took into account what is needed for a group of programmers to work on the same code base. I don't want to say he completely dropped the ball or anything like that but stuff like monkey patching and other shenanigans that make life easier if you are the sole programmer working on a code base become problematic if you are working in a largish team where not everyone might know everything that is going on.
What I am trying to say is, IMHO Ruby "feels" like it is a good language to teach in, but you can end up using it for a really long time without acquiring programming discipline and fundamentals. If you start in C, for example, and you have to mess with malloc and pointers and stuff like that, you are forced to get that discipline, because otherwise stuff goes south really fast. Someone who starts in Ruby might never really understand the performance cost of initializing an object, or what the stack and heap is, or why it matters. I think it would be better for a new programmer to start out in C or even assembly for a little while, just to understand how a computer really works, then it becomes so much easier to understand why languages like Ruby and Python (and my personal favorite, Clojure) were created and how to use the abstractions that these more modern languages provide.
- macrael 16y agoPeople don't need to start in C. If we required that, there would be many fewer programmers. In University, our CS department got people started in Java (not the best starter language, but certainly cleaner than C) but our required OS course was in C. So, after being introduced to programming in a somewhat simpler form, you were required to spend a semester writing big projects in C, and you learned about pointers and memory allocation really fast. So, I agree that programmers should learn more about how these machines really work if they want to write good code, but I'm not convinced people should have to start at that level. Doing so would unnecessarily discourage people from learning to program. Imagine suggesting that everyone should learn to start programming in assembly. I think that's an analogous claim and is pretty silly. People starting to learn to program shouldn't be worrying about low level details or unnecessary syntax, they should be discovering the joy of creating programs.
- thibaut_barrere 16y agoMy experience has been that Ruby allows to achieve what you need at your pace, and learn what you need as you go. When you start to learn C, you really have a couple of technical points to understand before being able to print a simple hello world. Sidenote but I'm thankful to Matz for creating a language that makes disciplined programmers able to create highly maintainable code bases, too (I find it's easier than in C# or Java at least in my experience).
- Tamerlin 16y ago"Sidenote but I'm thankful to Matz for creating a language that makes disciplined programmers able to create highly maintainable code bases" I agree with that. The "disciplined programmers" part is, however, the reason that I think that Ruby should be a reward for programmers who make it through C programming classes first. Ruby's a great language, and a lot of fun to program with, but the same characteristics that make it an enjoyable language to use also make it possible for undisciplined programmers to get things done.
- dkarl 16y agoI like your point about C, and I have a related point: When beginners see something that looks or reads like natural language, it activates the wrong part of their brain, and they start to wonder why the computer doesn't "understand" what they're telling it. The idea of a logical machine mindlessly executing symbolic instructions comes pretty naturally for some people, but for others, it's the first Big Idea in programming that they have to spend a lot of time getting used to. Every time they read a line of Ruby code that sounds kind of like stilted English, it causes a little regression in their brain back towards the mental model of the computer as something intelligent that understands the natural-language meanings of keywords and variable names. Say what you want about BASIC, but programs like "10 ? "HELLO" 20 GOTO 10" never let you forget you were dealing with a brainless, inflexible automaton. Same thing with C. With C, students are encouraged to ask the question, "What's really happening inside the machine?" There are simple, concrete answers based on a simplified view of the hardware. With Ruby, the answer to that question would be more complicated, and more importantly, it would be less concrete -- it's a long, long way to the hardware. C programmers start out grounded, at least grounded in a simplified model of the machine that is consistent and often helpful. How can beginners develop the habit of looking both up and down the ladder of abstraction, if they're looking down from the mountaintop into a shapeless gray cloudbank?
- xentronium 16y agoAbsolutely agreed. Being the ruby fan myself, I got to admit, that Ruby is so sweet and so abstract that the student starting with ruby is not probably going to lower level language by his own will. People still start programming with pascal in Russia and it's a good thing, imho.
- Xurinos 16y agoOne thing I took away from my SICP experience was the idea that it is languages/abstractions all the way down. You can play in a super high level language like Lisp, or you can mold silicon. Somewhere you have to choose your level of abstraction. If I am teaching somebody how to think about an algorithm like sorting an array, worrying about memory allocations is tangential, an inconvenient burden C delivers unto us. If I want to teach them about working with memory, pointers, and so forth, C is an excellent language for the job. A crazy thing is happening here when we look down upon beginners who want something that feels like a natural language. Why CAN'T we simply say, "I want an app that opens two windows: one with a list of my music files, and the other with cassette controls. Make it so."? Someone could develop a language that does this; AppleTalk, for example, has some crazy high-level stuff similar to this. We have been mentally shackled by our languages. We think in them. It is hubris to suggest that this the canonical way to think when programming, that, for example, "i = i + 1" is the idiom for incrementing a variable. I do believe, to be truly effective in our line of work, that our beginners must eventually come to an understanding of the platform upon which they develop. They must understand memory concepts. They must understand timing concepts. They must understand multiprocessing concepts. But there is no reason to ram C down some poor soul's throat as a first experience. What a terrible language for teaching beginners, full of syntax and slopped-together features. And what a great language to teach somebody in order to prepare them for the industry.
- xentronium 16y ago> like that but stuff like monkey patching and other shenanigans that make life easier if you are the sole programmer working on a code base become problematic if you are working in a largish team where not everyone might know everything that is going on. That's why God invented conventions.
- jemfinch 16y agoConventions: excusing language design flaws since 1956.
- Confusion 16y agoLanguage design trade-offs, easily presented as flaws: inevitable since 1956.
- xentronium 16y agoGun is not the reason you shot yourself in the foot, right?
- jamesbritt 16y ago"Matz originally created it kind of as a spiritual successor to Perl" Really? Matz has called his language "matz-lisp". Yes, he glommed stuff from perl, but from CLU, smalltalk, lisp, and other languages. I agree that anyone serious about programming needs to learn what happens under the hood, but an advantage of using something that is easy to jump into yet still amazingly powerful is that people get to first see if programming is really what they want to invest time in.
- chc 16y agoMatz has also said that it was specifically motivated by his frustration with Perl's lousy OO support, leading him to come up with something similar but strongly based around objects. He specifically called it "the next language after Perl," and named the language "Ruby" for the next birthstone after the pearl. When asked how much of Perl made it into Ruby, he said, "A lot. Ruby's class library is an object-oriented reorganization of Perl functionality … I used too much I guess." The language contained a lot of Perlisms early on that fell out of favor as it diverged further. Overall, the language is more evocative of Perl (in its scripting capabilities) and Smalltalk (in its block-passing pervasive OO model) than any Lisp that I know of. I don't doubt Lisp has had some influence, but he definitely had Perl in his sights when he decided to create it. (Source: http://linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html http://linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html)
- nickik 16y agoI think it depends. For teaching I would start with Scheme to teach the basics. Then switch to C to explain how all that stuff works.