Ruby as First Language

ruby-talk
21

Gene Tani wrote:

Perl has gotten a bad rap, well-written perl is pretty easy to follow.
Also perl's kind of hard to avoid, in certain circles, lots of times i
start somethign by reading CPAN modules, lots of OReilly books have
sample code in perl, etc. so at least being able to read perl code is
helpful

Yes, but this thread is about "first language". I don't know how Perl's
OO has changed since Perl 5 but then it was horrible. Certainly nothing
I'd recommend for learning OO - I'd definitely choose even C++ and of
course Java / C# over Perl for OO.

Kind regards

    robert

22

Dave Burt wrote:

Robert Klemme wrote:

OTOH there is no *direct* access to system libs (as from C for
example). For that you would have to write a C extension. Still, I
think to initially learn to develop software Ruby is a pretty good
choice.

Just to knock down your only negative point a little, Robert, there
is DL, which makes accessing C libraries about equal in pain to doing
it in C, no?

I forgot that. Yeah, with DL it seems reasonably easy. Good point!

Me, I'm all for learning Ruby as a first language. My first language
was Basic, and I do reckon that it probably doesn't matter too much
what you pick, but an important factor is being able to actually
produce something cool/fun/useful as you go. (Games, for instance.)

I wouldn't go that far. For example, at the time I was using BASIC there
were no functions and you had to work with GOSUB and GOTO for
modularization; for me this is a major drawback. I rather recommend to
use PASCAL (no kidding) over ancient BASIC's. I know current BASIC
dialects are much better - but then again, there are so many of them...

Learning a second language will be significantly easier after you've
learnt one already, almost regardless of the language.

I'm not sure; it certainly helps, but I guess the paradigmatic distance
(TM) of the second language makes a difference. I guess it's easier to go
from C++ to SmallTalk (both OO) than from Lisp to BASIC...

Choose Ruby.

Definitively! :slight_smile:

    robert

23

If you plan on working on the web, you should definitely make sure that
ruby is in your tool belt.

···

On Fri, 2006-02-24 at 04:04 +0900, Bill Kelly wrote:

From: "Giacecco" <giacecco@gmail.com>
>
> I am certain that Ruby will grow a lot in the next years and things
> will change, but if you have to decide today, and it is for your job,
> Ruby is still too weak.

It should be noted that many people here are using ruby for our jobs.

:slight_smile:

It's true Ruby isn't suited to every task, but it's working for a lot
of us.

Regards,

Bill

24

John W. Kennedy wrote:

In one respect, we were lucky in the old days. Both of the 1401 assembler languages were easy -- even the machine language was pretty straightforward. (It's been nearly 40 years since I last dealt with a real 1401, and nearly as long since I last dealt with an emulated one, but I could still write a self-booting program today.) It gave you a sense of the real machine that's hard to get nowadays.

I spent 5 or 6 years writing IBM 370 assembler starting in 1983 and I though _I_ was an old-timer, but my hat's off to you! Ain't the Ruby community grand?

25

James Gray wrote:

Here is the problem. With C or even C++ I can learn a few basic
conditional statements, variable declarations, etc. and I can write
just
about any program. Sure, it will be long and inefficient, but at
least
I can write it without knowing any more about the language. In Ruby,
you can't do that. The key to learning Ruby is learning the numerous
methods that come with each class.

I'm not seeing that. Ruby supports pretty much the same constructs
and even index access to Arrays. Iterators are a lot sexier, but if
you want to walk everything by index knock yourself out. If you
don't know the helper methods, you can always roll your own code.

That doesn't make sense to me.

James Edward Gray II

Sure, you can do that stuff, but most of the existing documentation
focuses on the sexy aspects of Ruby. I don't think it means much to a
novice programmer to write some ultra-powerful statement consisting of
one or two lines of code. It's easier to follow something that is three
times as long and more verbose.

Don't get me wrong. I love Ruby. It's just that as a mediocre
programmer, I found it very difficult to learn because I spent too much
time looking for certain methods in the Ruby book. Sometimes it is
easier for beginners to move forward when they don't have 10 different
options for how to do something.

···

On Feb 24, 2006, at 7:56 AM, Rob wrote:

--
Posted via http://www.ruby-forum.com/\.

26

1) Logo as a preteen, or AWK and/or Bourne shell scripting at any age
2) C (second procedural language)
3) Ruby, Python, Java, or C# (first OOP language)

No way. :slight_smile: Ruby before C, any day. It's really not an issue of
"procedural is easier than OOP". You can do procedural Ruby, and it's
so so so so so much easier. The aspiring programmer will be able to
do so much more after their first half-hour lesson. This is
motivating. A motivated student learns faster, retains more (longer),
and most importantly, is less likely to quit! (You wouldn't believe
how often I hear people saying, "I've tried to learn to program over
and over again, but never got into it... until Ruby!")

For someone who is starting out with no programming experience, I consider
Why's Poignant Guide to be the best introductory Ruby text out there. Yes,
really. It introduces concepts gently and humorously.

GIANT HONKING DISCLAIMER:

I have written a tutorial, and recently a book, lovingly and
painstakingly built over the last three years, aimed at teaching
programming, using Ruby, to non-programmers. So I'm totally,
hopelessly biased here...

And I'd also like to say that I *absolutely love* the Poignant Guide
and, as a programmer, I'd much rather read it than my own writings.
Chunky! Bacon! (Seriously. Chunky bacon.) How can one *not* fall
in love with Why instantly? I have personally had an asthma attack
from laughing too hard reading his sidebar dissing asthmatics. His
insight and sensitivity were... (must not say breath-taking....
resist...) um... good.

I totally and sincerely believe that the world is a better, brighter,
more love-filled place now that the Poignant Guide is in it. I do.

However, having said that, I *really* don't think that the Poignant
Guide is the way for a non-programmer to learn programming. Do you
personally know of any non-programmers learning to program from
reading it?

I mean, I feel bad saying that... dude, I love it, too! But, for all
it is, I just don't honestly believe that it meets the
non-programmer's needs.

But as I mentioned, I'm so hopelessly and completely biased... you
should probably take everything I say with 200 parts salt, 1 part
Chris.

:slight_smile:

Chris

···

On 2/25/06, Gregory Seidman <gsslist+ruby@anthropohedron.net> wrote:

27

And if you want to convert those videos to sound files to listen to
during your commute, here's how:

http://tomcopeland.blogs.com/juniordeveloper/2006/02/mp4_to_mp3_one_.html

I'm on lecture 8 at the moment... good stuff!

Yours,

Tom

···

On Fri, 2006-02-24 at 01:27 +0900, James Britt wrote:

If you are looking first to get insight into programming, go learn
Lisp, or enough Lisp to find your way around.

There are free videos online by Hal Abelson and Gerald Jay Sussman of
their book, Structure and Interpretation of Computer Programs

Project MAC Home Page

The book is available online for free as well.

28

I agree.

On the flip side though, I would argue that Perl has better networking, which the original poster was interested in...

James Edward Gray II

···

On Feb 23, 2006, at 9:28 AM, Robert Klemme wrote:

Gene Tani wrote:

Perl has gotten a bad rap, well-written perl is pretty easy to follow.
Also perl's kind of hard to avoid, in certain circles, lots of times i
start somethign by reading CPAN modules, lots of OReilly books have
sample code in perl, etc. so at least being able to read perl code is
helpful

Yes, but this thread is about "first language". I don't know how Perl's
OO has changed since Perl 5 but then it was horrible.

29

But more importantly, *should* Ruby be a first language taught, period?
I tend to think no.

C allows you to have a base understanding of all the technical aspects
of programming, like memory management, procedural thought, and the
basics of writing methods. These are generally good skills to have,
and you'll find that you use them everywhere. C is a lot like latin,
insofar that it's not changing much, and is used to communicate ideas.
I also think it's a little more "native" to initial human understanding
about programming. People tend to think of it as a linear, or
semi-cyclical set of instructions. In that regard, I think C is a good
way to enter the scene.

The thought process overhead in object oriented programming is quite
extensive. It takes a long time to really get in the mode. If you
learn somethings about C, and get a basic grasp before moving on to
Ruby, you'll understand and have a better appreciation for some of the
"magic" going on behind the scenes, as well as opening other avenues
for your programming career. Doubly, it takes a long time to learn how
to think in objects -- something I admit, myself, to just be getting
the hang of. When you start reading about design patterns, you realize
the complexity, and beauty that OOP allows you.

If the original poster decides to forgo C for Ruby in the time being, I
hope the poster eventually returns to it, if even just to have a base
understanding of what's going on beneath the scenes.

30

it still feels "tacked on". i think python's does also...

[incr tcl] has oo similar to C, but i'm not sure i'd recommend that as
a first language...

lua is great as a first language. oo, very clean syntax, cross
platform and small.

it also makes a great embedded language.

http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

···

On Fri, 24 Feb 2006 00:28:32 +0900, you wrote:

Yes, but this thread is about "first language". I don't know how Perl's
OO has changed since Perl 5 but then it was horrible.

31

Rob wrote:

I found it very difficult to learn because I spent too much time looking for certain methods in the Ruby book.
  
This is a big problem for a lot of programmers. We've had Visual Basic programmers looking for the on error gosub handler because that is
all they know and have become incapable of learning anything new. I've seen Cobol written in Perl by Cobol programmers who just couldn't learn anything new. We've had C programmers have fits because they couldn't use the pre / post
increment / decrement operators that they used in C and -= and += was too hard to learn.

You get the picture. Take a deep breath and forget you ever knew C then try again, prior expectations can be a real hindrance when learning something new.

32

While I disagree with most of what you have written (respectfully,
though :), I think you hit the nail on the head here. Most of the
time when we are showing Ruby, we are showing *off* Ruby. How can we
not!

But, for a sufficiently beginner audience, it's not the most helpful
way to go about things. (This was one of the things I really tried to
address in my book.)

Having said that, I seriously doubt that looking up "how to
concatenate strings" in Ruby is much harder than in C, and '+' is
easier to remember than 'strcat', don't you think? So you're less
likely to have to look it up. And which is easier to use?? What,
exactly, does strcat return? What if the strings overlap? Plus, once
you use strcat, you have the potential gotcha of having changed one of
your strings. And, of course, you have to make sure you have enough
space in your destination string... well, not in the "string", but in
the space declared...

How can you possibly think these are equally easy?? You have to know
*more* to get things done in C than in Ruby, not the other way around.

(Have you tried teaching people to program using C? And Ruby? If you
have, and in your experience C is not vastly more difficult for your
students, I'd love to hear about it. :slight_smile:

Chris

···

On 2/24/06, Rob <robert.c.may@gmail.com> wrote:

Sometimes it is
easier for beginners to move forward when they don't have 10 different
options for how to do something.

33

Rob wrote:

Don't get me wrong. I love Ruby. It's just that as a mediocre programmer, I found it very difficult to learn because I spent too much time looking for certain methods in the Ruby book. Sometimes it is easier for beginners to move forward when they don't have 10 different options for how to do something.

Perfectly said.

Wittgenstein's Ladder. http://c2.com/cgi/wiki?WittgensteinsLadder

Training wheels, training wheels, training wheels.

Everybody needs 'em when starting out in a new area. I need 'em. Big time. Especially as I start watching the SiCP LISP videos. And I have some past experience hacking around with Python. Though with my background it looked more like object-oriented VBScript.

God help me.

Just my $.02.

-dave

34

Chris, I really enjoyed your book. The exercises are well thought out
and practical.
The lessons build knowledge in a logical manner. When you are finished the
book you feel "learned", I've been subconsciously buying tween blazers
ever since.

I am a big, really big big... not even in a strictly volume sense, I'm
talking mass...
ridiculously humongous fan of the Poignant Guide.

However I found the actual lesson material was not always as thorough
as I would like, and there are no exercises. I don't think I will ever
forget the forklift, or the caterpillar but _why's book is not really
for a new programmer, unless they
are really strange/wonderful/interesting/open minded type people or unless
they have just finished reading your book :wink:

I think normal[1] folk will probably find _why's guide too distracting.

I think the books add to each other. _why's guide is very entertaining
and fun. Your
guide is very practical. Both guides will teach you a lot and we as a
community are far richer for having both to read.

Thanks Chris, and thanks _why.

[1]People who know how to send email and download music, but not much else.

···

On 2/25/06, Chris Pine <chris@pine.fm> wrote:

I have written a tutorial, and recently a book, lovingly and
painstakingly built over the last three years, aimed at teaching
programming, using Ruby, to non-programmers. So I'm totally,
hopelessly biased here...

--
Alex Combas
http://noodlejunkie.blogspot.com

35

James H. wrote:

But more importantly, *should* Ruby be a first language taught,
period? I tend to think no.

That's precisely the point where we disagree. :slight_smile:

C allows you to have a base understanding of all the technical aspects
of programming, like memory management, procedural thought, and the
basics of writing methods.

It won't teach you anything about methods because there are none in C. :slight_smile:

These are generally good skills to have,
and you'll find that you use them everywhere. C is a lot like latin,
insofar that it's not changing much, and is used to communicate ideas.

I use UML to communicate ideas - or Ruby - but certainly not C. I don't
think it's suited for this at all. There's too much overhead.

I also think it's a little more "native" to initial human
understanding about programming. People tend to think of it as a
linear, or semi-cyclical set of instructions. In that regard, I
think C is a good way to enter the scene.

Even if you want to start with a strictly procedural language I'd strongly
favour Pascal over C exactly because those detailed technical aspects are
*not* present there. Getting memory allocation and pointer handling right
is difficult for a novice and prevents early successes. IMHO it's far
more important to grasp abstract concepts that are common to many
programming languages (like abstraction, modularization, data structures)
than to know how to not shoot yourself in the foot when doing *ptr++.

The thought process overhead in object oriented programming is quite
extensive. It takes a long time to really get in the mode. If you
learn somethings about C, and get a basic grasp before moving on to
Ruby, you'll understand and have a better appreciation for some of the
"magic" going on behind the scenes, as well as opening other avenues
for your programming career. Doubly, it takes a long time to learn
how to think in objects -- something I admit, myself, to just be
getting the hang of. When you start reading about design patterns,
you realize the complexity, and beauty that OOP allows you.

Although I agree with your last paragraph (that OO is more difficult to
grasp than the procedural paradigma) I strongly disagree with what you
state in the first paragraph. If you like to, you can use Ruby
procedurally most of the time.

Kind regards

    robert

36

I see this comment a lot and it bugs me, so I'm going to take it out on you. :wink: (I'm kidding there, really.)

I think it's important to remember that there are many different levels of programmer. Some programmers work on operating systems, bank ATM software, or missile guidance code for a living and we sure hope they have all the knowledge they can get. That's *not* all of us though!

Many people are coming to Ruby right now through exposure to Rails for web programming projects. Do they need to know how absolutely everything works under the hood? Well, it probably depends on the project, but honestly I don't think being able to roll their own binary search off the top of their head is too useful to them.

I work daily with a guy who probably has less language experience then me, but he sure knows which JavaScript library will help us get this week's work done in one day. (He showed me lightbox this week.) His gift may just be that he follows different news sources than me, meaning that it isn't programming knowledge at all. His is just a different kind of knowledge, but still very useful to both of us.

As another example, my wife works for a food company. She's always messing with some data it Excel or Access. One day, I was watching over her shoulder when she was doing some horribly repetitive changes to a document.

Soon after that I taught her enough Perl to roll a Unix filter style input loop, very basic array and hash usage, and a small subset of regular expression. You learn much more from the first three chapters of Programming Perl, I assure you. (She has everything I taught her on a couple of cheat sheets.)

I would not call my wife a programmer and she knows literally nothing about C, but she does program, and I'm confident that I more than doubled her productivity for tasks she is often faced with. There's nothing wrong with someone getting things done at her skill level.

I'm not arguing that knowing fifteen languages won't help you as a programmer. Obviously, experts get to be experts by soaking up all the knowledge in their field they can get their hands on. What I think you are forgetting is that we are not all experts. Some of us aren't even trying to be, and that's okay too.

James Edward Gray II

···

On Feb 23, 2006, at 10:13 AM, James H. wrote:

But more importantly, *should* Ruby be a first language taught, period?
I tend to think no.

37

James H. wrote:

Doubly, it takes a long time to learn how
to think in objects -- something I admit, myself, to just be getting
the hang of.

I think there are two flaws in your argument.

1) Your experience does not set the standard for everyone else.

2) I assume you started with a language similar to C (or at least
procedural), and then learned OO. Because it took you a long time to
fully grasp OO, you think it is best to start with a procedural
language. ?? Is there no possibility that it took you longer to grasp
OO *because* you started with a procedural language?

I was taught both procedural and OO in college, and did not experience
the difficulties you mention.

Alan Shalloway, one of the authors of "Design Patterns Explained"
argues that avoiding design patterns makes it harder to learn them
object-oriented design. Instead, he introduces his students to
object-oriented design *and* design patterns and has found the students
learn object-oriented design faster.

Quote from preface in book:
"The design pattern books I had been reading and the design pattern
experts I had been talking to were saying that you really needed to
have a good grounding in object-oriented design before embarking on a
study of design patterns. Nevertheless, I saw, with my own eyes,
students who learned object-oriented design concurrently with design
patterns learned object-oriented design faster than those just studying
object-oriented design. They even seemed to learn design patterns at
almost the same rate as experienced object-oriented practitioners."

If experience can be used to draw conclusions, I would trust his
experience with a larger test set over yours.

···

--
Glen

38

> I have written a tutorial, and recently a book, lovingly and
> painstakingly built over the last three years, aimed at teaching
> programming, using Ruby, to non-programmers. So I'm totally,
> hopelessly biased here...
>
Chris, I really enjoyed your book. The exercises are well thought out
and practical.
The lessons build knowledge in a logical manner. When you are finished the
book you feel "learned", I've been subconsciously buying tween blazers
ever since.

Chris, I am presently enjoying your book.

I am a big, really big big... not even in a strictly volume sense, I'm
talking mass...
ridiculously humongous fan of the Poignant Guide.

me too!

However I found the actual lesson material was not always as thorough
as I would like, and there are no exercises. I don't think I will ever
forget the forklift, or the caterpillar but _why's book is not really
for a new programmer, unless they
are really strange/wonderful/interesting/open minded type people or unless
they have just finished reading your book :wink:

I think normal[1] folk will probably find _why's guide too distracting.

This depends. I have them both. I printed out Why's guide, and I
also purchased both the PDF and dead tree copy of Chris Pine's Learn
to Program book.

As I've said publicly in other places... Why was one of two things
when he write the Poignant Guide.... he was either 1. VERY stoned. or
  2. VERY much a genius.

Let me qualify. Chris wrote a VERY good book with excellent examples.
Why uses crazy techniques and you think the guy is all over the map.

This will sound painfully obvious... but if it were, schools would be
MUCH different than they are today.

People do NOT learn the same. Let me say that again... people do NOT
learn the same. One person may learn the most from the traditional
'teacher talk - student listen' model. That is what the VAST majority
of our schools still believe and practice to this day.

There was a man named Howard Gardner [2] that came up with the theory
of multiple intelligences. In a nutshell, many different methods of
learning... and if you're trying to teach someone a subject in a
manner that doesn't match what their learning style is, you're missing
the mark!!!

This is where I think Why has it right on, and where I think Chris
might benefit in doing a little research and seeing if he wants to
implement some of these things in his next book.

A present day example would be the Head First series that O'Reilly &
Associates is doing.

I think the books add to each other. _why's guide is very entertaining
and fun. Your
guide is very practical. Both guides will teach you a lot and we as a
community are far richer for having both to read.

AMEN!

Thanks Chris, and thanks _why.

[1]People who know how to send email and download music, but not much else.

--
Alex Combas
http://noodlejunkie.blogspot.com

[2] http://rubyurl.com/g2V

···

On 2/25/06, Alex Combas <alex.combas@gmail.com> wrote:

On 2/25/06, Chris Pine <chris@pine.fm> wrote:

39

> C allows you to have a base understanding of all the technical aspects
> of programming, like memory management, procedural thought, and the
> basics of writing methods.

It won't teach you anything about methods because there are none in C. :slight_smile:

Ah, yes. I have a bad habit of using procedure and method
interchangably =/

Interesting point about Pascal though, and when I read your words I
find myself nodding my head in agreement that it is definitely more
important to understand the concepts found amongst the majority of
programming languages than the specifics of one (e.g. pointers -- one
of the great evils of C).

Okay, how about this: "If you decide to use Ruby as a first language,
it would be wise to learn C later down the road given it's widespread
usage". Does that make more sense?

James

40

Object and Turbo Pascal took the language nicely into the realm of OO. It's still a great way to learn how to program - and even after all of these years, I still can't understand why nearly all major Universities (in the US anyway) have abandoned it completely.

--Steve

···

On Feb 23, 2006, at 8:33 AM, Robert Klemme wrote:

Even if you want to start with a strictly procedural language I'd strongly
favour Pascal over C exactly because those detailed technical aspects are
*not* present there.