Ruby for beginners (was: Re: Hello)

Ruby
21

On 2011-04-13, at 08:03, Phillip G. wrote:

On Wed, Apr 13, 2011 at 4:48 PM, Vincent M. <[email protected]

As for Tk not appearing with current Ruby installers, oops on my part.

How often do you check for Tk? :wink:
Not very often, most of my Ruby work isn’t GUI-based. However, on both
OSX 10.6 and Ubuntu GNU/Linux I am running versions of Ruby 1.9.1 that I
built myself from source code, and both seem to have Tk active.

So. How do we get an IDLE-like editor that will work at least on Windows and
Mac that is

plausible to ship as part of the installers?

Preferrably, something written once, yet running everywhere. I’d
suggest using JRuby, and a JRuby-based editor, that is easy to use,
yet works well enough with Ruby (it doesn’t have to be perfect: A
newby who wants to explore programming in the first place isn’t going
to complain about having the wrong editor, as as long as there is an
editor).

This might be a good way to go. I’m queasy about requiring Java to be
installed, though.
Your thoughts on redcar might well alter that.

– vincent

22

On Thu, Apr 14, 2011 at 10:57:02AM +0900, jake kaiden wrote:

Chad P. wrote in post #992591:

It used to be the case that the standard Ruby installer for MS Windows
came with SciTE. Is that still the case?

another vote for SciTE! it helped get me motivated to start
programming when i was still weary of the linux command line.

s/weary/wary/

“Weary” is “tired”. “Wary” is “cautious” or “uncertain”.

the license is open source - and while it’s an older program it seems
that it is still actively developed.

As GUI editors go, it is definitely one of my favorites. I endorse it
for those who need a GUI text editor.

23

On Wed, Apr 13, 2011 at 10:03 AM, Phillip G.
[email protected] wrote:

The downside is that JRuby, great as it is, doesn’t allow for C
extensions as seamlessly as the Windows Ruby with Devkit (I’m sure
Charles will now drop in and correct me :slight_smile: ). OTOH, the end of a “Ruby
for newby” guide could include a means of getting a more, er,
conventional Ruby installed and set up.

I think a DevKit tutorial was posted with JRuby instructions. They
should still be valid.

  • Charlie
24

On Thu, Apr 14, 2011 at 5:03 AM, Chad P. [email protected] wrote:

On Thu, Apr 14, 2011 at 10:35:42AM +0900, Vincent M. wrote:

This might be a good way to go. I’m queasy about requiring Java to be
installed, though. Your thoughts on redcar might well alter that.

That bothers me, too. We should have an option that does not require
installing more than one programming language.

That would depend on how high valued platform independence is.

I propose the following premises:

  • Linux users (For the sake of argument, I think we can lump in the
    BSD Unix flavours with the Linux users) can be expected to be more
    technologically savvy than the “average” computer user, simply because
    they have to take the step of installing anotehr operating system, and
    it is a good idea for most Linux flavours and users to use the Linux
    distribution’s package management system to install and maintain
    software anyway. This group would profit the most from a
    Ruby/programming primer, I think

  • Neither MacOS X nor Windows have integrated package management
    solutions. While Mac users can avail themselves of XCode and a
    compiler toolchain somehow, this is a lot of overhead for a
    package management solution, so these two groups would profit the most
    from a stand-alone installer / package for their operating systems, as
    well as a Ruby/programming primer.

  • Most PCs run a flavour of Windows**, according to all the data we
    can get our hands on. The question is of how large the percentage
    points in the 9x are, more often than not.

  • Windows users are the least educated about PCs, on average (the
    famous Aunt Tillie goes to the store, and buys a PC, and will have
    something that runs Windows after she paid for her groceries).

  • Windows doesn’t ship with a decent* editor, nor a package management
    system.

  • Mac OS X at least includes a Ruby package in its installation.

The value of platform independence:

To cover both Windows and Mac users with one stroke, some sort of
portability of the tools a “Beginning Ruby” package includes is a
necessity, simply to make the burden on maintaining such a package
easier.

Unfortunately, there’s no easy download for SciTE for the Mac OS X
platform, and the Scintilla editor component uses GTK+, which means an
additional dependency for one single operating system, for a 2MB
editor. :wink:

Arguments for something Java based:

  • it is independent by design and in practice nowadays, and JRuby
    supports both Windows and Mac platforms (almost) equally well (the
    issues are more with Windows than OS X).

  • Maintaining the JRE (and that’s all that is needed!) is done by the
    JRE provider (IIRC, Apple supplies the OpenJDK / OpenJRE now), so
    anything pre-installed can be piggy-backed by a “Beginning Ruby”
    package.

  • Java-based editors based on the SWT toolkit don’t look out of place
    (SciTE does). Redcar is based off of the SWT toolkit, but requires a
    lot of configuration to make it execute Ruby code from what I’ve
    looked at so far (though, it does look nice).

Arguments against something Java based:

  • The JRE is a sizeable download if nothing is pre-installed (77MB,
    uncompressed, on my machine for the JRE6 x64 version).

  • Start up time for Java applications can be an issue, at least in
    theory.

  • Introduces a rather large dependency for something small.

Beginning Ruby editor requirements:

  • Easy to use, with no clutter in the UI, and thus allowing the user
    to focus on Getting Stuff Done, and get a success fast.
  • Able to run Ruby from within the editor, so that the user can focus
    on Ruby, and Ruby alone. The CLI on Windows is more of an advanced
    topic.

In a nutshell:
The problem is sourcing a decent-ish editor, while being as
vendor-neutral as humanly possibly.

  • decent meaning “at least syntax highlighting”.
    ** We can completely discount any Windows flavour before XP SP 2.
    Anything older than that shouldn’t be allowed to exist anymore.

–
Phillip G.

Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.

25

Phillip G. wrote in post #992777:

Beginning Ruby editor requirements:

  • Easy to use, with no clutter in the UI, and thus allowing the user
    to focus on Getting Stuff Done, and get a success fast.
  • Able to run Ruby from within the editor, so that the user can focus
    on Ruby, and Ruby alone. The CLI on Windows is more of an advanced
    topic.

To me, it’s about Ruby, NOT the editor.

The programmimg language is NOT the IDE. Yeah, all the cool tools make
it enjoyable to pursue and use Ruby, but that’s not what I believe is
necessary to introduce Ruby. I believe all of that is a distraction
from an introduction to Ruby itself.

In fact, I believe Rails and even RubyGems are a distraction. I’d love
more people to be able to easliy learn about Ruby (and only Ruby).

But, it’s your initiative . . .

Jim M.

26

Phillip G.
http://groups.google.com/group/comp.lang.ruby/msg/6d594307dbaeef2d

27

On Thu, Apr 14, 2011 at 5:28 PM, Jim M. [email protected] wrote:

Phillip G. wrote in post #992777:

Beginning Ruby editor requirements:

  • Easy to use, with no clutter in the UI, and thus allowing the user
    to focus on Getting Stuff Done, and get a success fast.
  • Able to run Ruby from within the editor, so that the user can focus
    on Ruby, and Ruby alone. The CLI on Windows is more of an advanced
    topic.

To me, it’s about Ruby, NOT the editor.

Same here. However, someone who beings Ruby, let alone programming, is
dealing with enough difficulties already, so the fewer assumptions
made about existing knowledge, the better. The more of a safety net
that is provided by a Beginning Ruby package, the easier it makes for
a beginner.

The programmimg language is NOT the IDE. Yeah, all the cool tools make
it enjoyable to pursue and use Ruby, but that’s not what I believe is
necessary to introduce Ruby. I believe all of that is a distraction
from an introduction to Ruby itself.

Absolutely. That’s why I’d prefer a very lightweight editor (at least
on Windows; I have no idea how the situation is on Mac OS X), to
minimize any friction. To provide, more or less, an abstraction for
what the more advanced user of Ruby is used to deal with.

To provide quick and visible results of progress in programming
(“Hello World”, except for the whole of Ruby, you could say).

In fact, I believe Rails and even RubyGems are a distraction. I’d love
more people to be able to easliy learn about Ruby (and only Ruby).

Nobody mentioned any of those. :slight_smile:

I think dealing with getting Rails deployed with ease is best done by
the Rails Installer project http://www.railsinstaller.org/.

But, it’s your initiative . . .

Oh no. It’s a community initiative much more than anything I could
claim as my own, even if I wanted to.

–
Phillip G.

Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.

28

On Thu, Apr 14, 2011 at 6:21 PM, Chad P. [email protected] wrote:

I think this actually applies more to BSD Unix users than Linux-based
system users, on average.

IOW: BSD users are technologically savvy, correct? Not that I
misunderstand what you wanted to say.

To cover both Windows and Mac users with one stroke, some sort of
portability of the tools a “Beginning Ruby” package includes is a
necessity, simply to make the burden on maintaining such a package
easier.

This is a good point. If we’re just talking about something that only
runs on MacOS X and MS Windows, maybe JRuby isn’t as bad a choice as I
had originally thought – because of this point.

Otherwise I wouldn’t have brought it up.

Any project has manpower constraints, and the easier a Beginning Ruby
package is to maintain, the more time can be spent on making it an
excellent experience for newcomers. And I value the latter part higher
than any sort of “purity” native packages can provide.

  • Java-based editors based on the SWT toolkit don’t look out of place
    (SciTE does). Redcar is based off of the SWT toolkit, but requires a
    lot of configuration to make it execute Ruby code from what I’ve
    looked at so far (though, it does look nice).

I think this “look and feel of the OS” thing is heavily, wildly
overstated much of the time. Look at the Chromium browser – it has
taken the approach of looking kinda out-of-place on every operating
system, and it ended up being about the best looking of all the major
browsers.

And Chrom[e|ium]'s market share comes mostly at the expense of Firefox.

Native look and feel is important simply because that’s what a user is
already used to, and knows how to navigate.

That’s not to say that GTK is pretty. It’s not. I think something more
simple and elegant, without big ugly gray buttons and the like, would be
nicer. Still, I don’t know that blending in with the default widget set
of the OS is as important as people seem to think, especially for
something like this.

And we can argue this until the cows come home. I’m not hell bent on
providing native look and feel, but it’s a very nice bonus to have.

Though, it’d be a secondary concern, I think. Bells and whistles are
nice, but not necessarily required.

  • Start up time for Java applications can be an issue, at least in
    theory.

It certainly can for people who are writing little beginner scripts.
They’ll think Ruby is even slower on MS Windows than it actually is. I
hadn’t even thought of that until you brought it up.

The question is if it would be an issue in practicality. MS Word takes
ages to load up, too (at least the first view times, before Windows’
caching mechanisms kick in), and if Ruby can run in the background
perpetually, waiting for some sort of input, start up and seeing
results of Ruby scripts becomes much of a non-issue.

I haven’t tried yet; can interactive_editor be made to work on MS
Windows? If so, I don’t think we need to focus on picking an editor that
can execute code for first-timers. Keep it simple; use the default
editor for the platform, if you can get away with it.

Ideally, yes. And I have no idea about interactive_editor, nor am I
good enough to hack any internals of it, if necessary, however.

If you’re going to bundle an editor with it, you might as well focus on
creating a complete IDE install.

Wouldn’t that go against the goals of simplicity, avoiding to overload
a beginner? Would be a fully fledged IDE be necessary to learn Ruby?

  • decent meaning “at least syntax highlighting”.

I don’t think syntax highlighting is really a major concern here, unless
you’re going to bundle tutorials that refer to the colors to point out
“parts of speech” in Ruby. I think more important concerns are things
like whether it can handle all three major newline types (Mac, Unix,
Windows) and whether it uses a monospace font by default. Not
auto-correcting what it thinks are typos is a huge concern, too.

That’d depend on the tutorials provided. But I think that syntax
highlighting makes easier to see what’s what, than the monospaced
gibberish that would be

WORK_ITEM_TAGS.each do |wit|
puts “Tagged #{wit}:”
puts make_list items, wit
puts “”
end

In the end, though:
The tutorials provided by a Beginning Ruby package as well as that one
get a running Ruby in 30 minutes or your money back are far more
important than how pretty or how advanced the editor is.

–
Phillip G.

Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.

29

I’ve deleted any context to which I didn’t feel a need to respond; it
stands on its own.

On Thu, Apr 14, 2011 at 11:26:25PM +0900, Phillip G. wrote:

Ruby/programming primer, I think
I think this actually applies more to BSD Unix users than Linux-based
system users, on average.

  • Windows doesn’t ship with a decent* editor, nor a package management
    system.

A merely passable editor is probably enough to get people started. I
comment more on editors later on.

To cover both Windows and Mac users with one stroke, some sort of
portability of the tools a “Beginning Ruby” package includes is a
necessity, simply to make the burden on maintaining such a package
easier.

This is a good point. If we’re just talking about something that only
runs on MacOS X and MS Windows, maybe JRuby isn’t as bad a choice as I
had originally thought – because of this point.

Unfortunately, there’s no easy download for SciTE for the Mac OS X
platform, and the Scintilla editor component uses GTK+, which means an
additional dependency for one single operating system, for a 2MB
editor. :wink:

Bundling an editor with the Ruby install suffers some of the same
problems as bundling a Java runtime with it, pretty much regardless of
the editor.

  • Java-based editors based on the SWT toolkit don’t look out of place
    (SciTE does). Redcar is based off of the SWT toolkit, but requires a
    lot of configuration to make it execute Ruby code from what I’ve
    looked at so far (though, it does look nice).

I think this “look and feel of the OS” thing is heavily, wildly
overstated much of the time. Look at the Chromium browser – it has
taken the approach of looking kinda out-of-place on every operating
system, and it ended up being about the best looking of all the major
browsers.

That’s not to say that GTK is pretty. It’s not. I think something more
simple and elegant, without big ugly gray buttons and the like, would be
nicer. Still, I don’t know that blending in with the default widget set
of the OS is as important as people seem to think, especially for
something like this.

  • Start up time for Java applications can be an issue, at least in
    theory.

It certainly can for people who are writing little beginner scripts.
They’ll think Ruby is even slower on MS Windows than it actually is. I
hadn’t even thought of that until you brought it up.

Beginning Ruby editor requirements:

  • Easy to use, with no clutter in the UI, and thus allowing the user to
    focus on Getting Stuff Done, and get a success fast.
  • Able to run Ruby from within the editor, so that the user can focus
    on Ruby, and Ruby alone. The CLI on Windows is more of an advanced
    topic.

I haven’t tried yet; can interactive_editor be made to work on MS
Windows? If so, I don’t think we need to focus on picking an editor
that
can execute code for first-timers. Keep it simple; use the default
editor for the platform, if you can get away with it.

If you’re going to bundle an editor with it, you might as well focus on
creating a complete IDE install.

Don’t misunderstand me – I think Notepad is crap. I don’t know that it
doesn’t cover the basic needs of a beginner’s bundle, though. Once the
nuby (portmanteau of Ruby and newbie?) gets experienced enough to want a
different editor, he or she can probably install SciTE, TextMate,
whatever.

In a nutshell:
The problem is sourcing a decent-ish editor, while being as
vendor-neutral as humanly possibly.

It seems to me that using the native default editor for the system is
probably the easy solution, here.

  • decent meaning “at least syntax highlighting”.

I don’t think syntax highlighting is really a major concern here, unless
you’re going to bundle tutorials that refer to the colors to point out
“parts of speech” in Ruby. I think more important concerns are things
like whether it can handle all three major newline types (Mac, Unix,
Windows) and whether it uses a monospace font by default. Not
auto-correcting what it thinks are typos is a huge concern, too.

Someone stop me if I’m straying into bikeshed painting land.

30

On Thu, Apr 14, 2011 at 9:16 PM, Chad P. [email protected] wrote:

More to the point, there are more users of Linux-based systems who are
not so savvy, thanks to the newbie outreach of distributions like
PCLinuxOS and Mint.

Ah, I see. Well, in such a case a recipe to get up to speed with Ruby
and a good tutorial would be the most useful (leave maintaining Linux
packages to the Linux maintainers, I’d say).

Yeah – my main concern with using JRuby is the requirements on the user
side and the potential issues with more, and more complex, components of
the package that might have issues. A few users having problems can
produce a lot of “Why doesn’t this just work?” noise.

Two solutions:

  1. Vendor the JRE privately, and use the one you include in your
    package (downside: balloons download size).
  2. Check for Java at install time, and download it during install time
    if not present (downside: increases the time an install takes.

Both downsides are one time costs, though.

Mind: I’d rather provide two packages (one for Windows, one for Mac /
Linux) with good user experience, rather than one package with
mediocre experience.

Of course, I was thinking of MS Windows. Apple MacOS X users tend to
care a lot more about that kind of thing, to the point people have
actually made particular Mac purchases for the purpose of matching their
drapes.

There’s a reason Windows applications look, well, boring. :wink:

A native look and feel means that a user doesn’t have to learn new
metaphors for how things are done, since things look and work the same
as (s)he’s used to.

But I don’t think–at all–that providing an editor that looks and
feels slightly odd would put anyone off so completely that they’d
never, ever again try programming and/or Ruby.

Actually, I think it would be better to do without an IDE – but also to
do without pushing an editor on the user, especially when there’s an
editor already on the system with which the user might already be
familiar.

Oh, certainly. But since notepad.exe can’t even show line numbers, and
the Ruby interpreter refers to line numbers, you can end up with
problems there, too.

That said: There’s no problem with bundling an editor, and make it a
default during install time that the user can simply decide not to
install.

Uh . . . since when is monospace “gibberish”? Variable-width fonts are
awful for code editing.

Since you never encountered it otherwise, for example.

Off the top of my head, I can’t think of a single instance where I
encountered a monospaced font outside of programming and related
things (like a website, or technical book).

Of course, users learn fast, too, unless you make it intentionally
difficult for them.

–
Phillip G.

Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.

31

On Fri, Apr 15, 2011 at 01:45:01AM +0900, Phillip G. wrote:

On Thu, Apr 14, 2011 at 6:21 PM, Chad P. [email protected] wrote:

I think this actually applies more to BSD Unix users than Linux-based
system users, on average.

IOW: BSD users are technologically savvy, correct? Not that I
misunderstand what you wanted to say.

More to the point, there are more users of Linux-based systems who are
not so savvy, thanks to the newbie outreach of distributions like
PCLinuxOS and Mint.

Any project has manpower constraints, and the easier a Beginning Ruby
package is to maintain, the more time can be spent on making it an
excellent experience for newcomers. And I value the latter part higher
than any sort of “purity” native packages can provide.

Yeah – my main concern with using JRuby is the requirements on the user
side and the potential issues with more, and more complex, components of
the package that might have issues. A few users having problems can
produce a lot of “Why doesn’t this just work?” noise.

already used to, and knows how to navigate.
Like I said, I think that’s blown way the hell out of proportion.

Of course, I was thinking of MS Windows. Apple MacOS X users tend to
care a lot more about that kind of thing, to the point people have
actually made particular Mac purchases for the purpose of matching their
drapes.

Though, it’d be a secondary concern, I think. Bells and whistles are
nice, but not necessarily required.

That’s pretty much my point.

I haven’t tried yet; can interactive_editor be made to work on MS
Windows? If so, I don’t think we need to focus on picking an editor
that can execute code for first-timers. Keep it simple; use the
default editor for the platform, if you can get away with it.

Ideally, yes. And I have no idea about interactive_editor, nor am I
good enough to hack any internals of it, if necessary, however.

It’s actually a really simple bit of code. I plan to check it on Win7
at
some point, and if it can’t be set up to run Notepad with surprising
ease, I’m going to see if I can figure out why not – and maybe fix it.

If you’re going to bundle an editor with it, you might as well focus
on creating a complete IDE install.

Wouldn’t that go against the goals of simplicity, avoiding to overload
a beginner? Would be a fully fledged IDE be necessary to learn Ruby?

An IDE can have a simple interface. They don’t all have to look like
Eclipse, NetBeans, or Visual Studio.

Actually, I think it would be better to do without an IDE – but also to
do without pushing an editor on the user, especially when there’s an
editor already on the system with which the user might already be
familiar.

highlighting makes easier to see what’s what, than the monospaced
gibberish that would be

Uh . . . since when is monospace “gibberish”? Variable-width fonts are
awful for code editing.

32

I’ve been out of the loop for the last day or so, so I’ve bundled up my
comments rather than try to attach as replies to individual messages.

  1. The whole point of this is to have something useful for newbies. I
    think most of us put together the environments we each like, and this
    should probably continue. It’s surprising how little of an IDE a
    beginner will actually use. For example, syntax coloring. I love it
    myself, but beginners often don’t even notice it, or understand why the
    various words are in different colors. (I taught introductory computer
    science at the university level for a few decades, and that was what I
    saw in labs.) Most of the menu commands are unknown territory to most
    beginners. It seems to me that few beginners see what an asset a good
    editor is. They ask themselves (reasonably, in my opinion) `what’s the
    least I have to know to get my program working?’. Therefore, while in
    general adding features isn’t going to hurt a beginner, keeping the
    environment as simple as possible is highly desirable.

  2. I would identify four environments of immediate interest: Windows, OS
    X, Unx/GNOME, and Unx/KDE. Three of these come with quite reasonable
    editors: TextEdit (OS X), Gedit (GNOME), and Kedit (KDE). (You can argue
    for different editors on those three platforms, I’m just saying that
    they are reasonable.) Windows is the exception (you have to ask yourself
    what kind of deranged company would ship an operating system without a decent editor?', but this is Windows we're talking about :). Notepad is an OK editor, modulo onefeature’: it automatically appends “.txt” to
    file names. Teaching people to put quotes around their file names is not
    that big of a deal, I’d say.

  3. I would not care to say that *ix users are more or less sophisticated
    than any other users. It’s certainly true that most unsophisticated
    users who go out to buy a computer come back with a Windows box, but
    unsophisticated users might be running on any system.

  4. I had a grand total of five minutes to look at the arcadia web page.
    It sounded somewhat interesting, and might factor well into these
    discussions.

As I wrote this message, I think I’m coming up with a concrete proposal.
The Ruby for newbies' (Rewbies’? :slight_smile: page should lead to four different
brief tutorials, one for each of the above operating systems/desktops,
and should lead people through installing and running simple programs on
each of thse systems, using the native text editor. The premium is on
doing as few configuration steps as possible: Ruby programs will be run
in a terminal/command prompt window, and editing is done using the
system’s native editor. A longer-term objective is finding an IDLE-like
IDE that runs with no effort cross-platform. However, I’m inclined not
to let that goal preclude us from doing useful things now.

Comments? – vincent

33

On Thu, Apr 14, 2011 at 11:43 PM, Vincent M. [email protected]
wrote:

  1. The whole point of this is to have something useful for newbies. I think most
    of us put together the environments we each like, and this should probably
    continue. It’s surprising how little of an IDE a beginner will actually use. For
    example, syntax coloring. I love it myself, but beginners often don’t even notice
    it, or understand why the various words are in different colors. (I taught
    introductory computer science at the university level for a few decades, and that
    was what I saw in labs.) Most of the menu commands are unknown territory to most
    beginners. It seems to me that few beginners see what an asset a good editor is.
    They ask themselves (reasonably, in my opinion) `what’s the least I have to know
    to get my program working?'. Therefore, while in general adding features isn’t
    going to hurt a beginner, keeping the environment as simple as possible is highly
    desirable.

In your experience: Did newcomers to programming achieve good results
with Notepad?

It wouldn’t be much of a problem to write a quick batch file that
opens an editor as well as shell (properly linked to from the Start
Menu, too), to provide something like a “Ruby environment” to start
with, after all.

  1. I would identify four environments of immediate interest: Windows, OS X,
    Unx/GNOME, and Unx/KDE. Three of these come with quite reasonable editors:
    TextEdit (OS X), Gedit (GNOME), and Kedit (KDE). (You can argue for different
    editors on those three platforms, I’m just saying that they are reasonable.)
    Windows is the exception (you have to ask yourself what kind of deranged company would ship an operating system without a decent editor?', but this is Windows we're talking about :). Notepad is an OK editor, modulo one feature’: it
    automatically appends “.txt” to file names. Teaching people to put quotes around
    their file names is not that big of a deal, I’d say.

  1. I don’t think we should get too hung up on the editor question. I
    mean, it’ll turn into a holy war sooner rather than later about which
    is the One True Editor.

  2. Since the prospective Ruby user will be perusing a guide already,
    teaching “ancillaries” like saving a file as “myscript.rb” really
    isn’t that big of a deal. They’d be following the guide anyway.

  1. I would not care to say that *ix users are more or less sophisticated than
    any other users. It’s certainly true that most unsophisticated users who go out to
    buy a computer come back with a Windows box, but unsophisticated users might be
    running on any system.

Point taken. Though, I doubt that less sophisticated users will use a
*nix flavour at home, but rather at work.

As I wrote this message, I think I’m coming up with a concrete proposal. The
Ruby for newbies' (Rewbies’? :slight_smile: page should lead to four different brief
tutorials, one for each of the above operating systems/desktops, and should lead
people through installing and running simple programs on each of thse systems,
using the native text editor. The premium is on doing as few configuration steps
as possible: Ruby programs will be run in a terminal/command prompt window, and
editing is done using the system’s native editor. A longer-term objective is
finding an IDLE-like IDE that runs with no effort cross-platform. However, I’m
inclined not to let that goal preclude us from doing useful things now.

I’m in favour of an iterative approach, too (I didn’t make that
obvious, did I?).

The big hurdle is getting a guide written in the first place.
Fortunately, there’s pretty much no difference on the basics in Ruby
platform-wise, so the basic understanding of programming/Ruby wouldn’t
change across platforms.

So, as a refinement on your proposal: the guides could “split” into
pages for different operating systems (how to get up and running on X,
familiarizing the user with the environment), and then merge back into
a “This Ruby, that’s what you can do!” guide, if at all feasible.

The question remaining is: how to teach Ruby and/or programming. I’m
a task-oriented person, so I would prefer exercises / teaching along
those lines: teaching Ruby to get stuff done.

Example tasks:

  • Sorting photos by name, and shuffling them around the file system
  • Checking a news website for new content
  • Sending emails to a number of people at once ← doubtful that this
    would be useful
  • Creating a website to show off photos that are in a directory

I wouldn’t teach “high-level systems”, like OOP immediately, but once
complex-ish tasks come up, nor would I teach anything that would
require a gem or something like that: Just using the core and standard
library should be sufficient, I think.

–
Phillip G.

Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.

34

On Fri, Apr 15, 2011 at 07:12:59AM +0900, Phillip G. wrote:

  1. I don’t think we should get too hung up on the editor question. I
    mean, it’ll turn into a holy war sooner rather than later about which
    is the One True Editor.

That’s not really a big problem. The O. True Editor is clearly vi.
Still, that doesn’t mean we should saddle completely new programmers
with
the task of learning to use vi. Let them use whatever comes by default
with their OS configuration of choice.

As you say, getting hung up on the editor question is bad.

35

On 2011-04-14, at 15:12, Phillip G. wrote:

In your experience: Did newcomers to programming achieve good results
with Notepad?
When I taught people introductory programming, I never covered any more
than what happens to be offered in Notepad. To write small-ish programs
(say < 100 lines) you need to be able to load and save files, delete and
insert text (including maybe cut and paste), and search for text. Global
replace comes about the top of the skill set.

It wouldn’t be much of a problem to write a quick batch file that
opens an editor as well as shell (properly linked to from the Start
Menu, too), to provide something like a “Ruby environment” to start
with, after all.
Yes…set up the paths, ask for what directory is wanted, and away you
go. Such a thing could be shipped as an installable file, and let the
(tiny) installer add it to the Start menu.

  1. I don’t think we should get too hung up on the editor question. I
    mean, it’ll turn into a holy war sooner rather than later about which
    is the One True Editor.
    That’s why I listed four editors that are likely to be found with each
    of those OSes. None of them is my favorite, but all are usable for
    editing small programs.
  1. Since the prospective Ruby user will be perusing a guide already,
    teaching “ancillaries” like saving a file as “myscript.rb” really
    isn’t that big of a deal. They’d be following the guide anyway.
    Agreed.
  1. I would not care to say that *ix users are more or less sophisticated than
    any other users. It’s certainly true that most unsophisticated users who go out to
    buy a computer come back with a Windows box, but unsophisticated users might be
    running on any system.

Point taken. Though, I doubt that less sophisticated users will use a
*nix flavour at home, but rather at work.
I think we forget that people who buy `white-box’ computers because
they’re cheap often don’t take a Windows license. Often they propose to
use Windows illegally, but some use GNU/Linux because it’s cheap.

This particularly applies to high-school students, a group I’d think we
particularly want to attract into Ruby programming.

So, as a refinement on your proposal: the guides could “split” into
pages for different operating systems (how to get up and running on X,
familiarizing the user with the environment), and then merge back into
a “This Ruby, that’s what you can do!” guide, if at all feasible.
Agreed.

I wouldn’t teach “high-level systems”, like OOP immediately, but once
complex-ish tasks come up, nor would I teach anything that would
require a gem or something like that: Just using the core and standard
library should be sufficient, I think.
Totally agreed. In fact, pedagogically, the current CS craze for
`Objects First’ is basically teaching students rituals that in fact get
in the way of teaching concepts.

That’s why I like the Table of Contents of Chris P.'s Learn to
Program. It matches the way I think students learn. Start with
something simple that does something useful, and work up from there.

I would not conceive of this newbies’ page as being a tutorial on
programming. When it gets to that point, a pointer to Pine’s book (not
the out-of-date first edition) gets inserted. (I verified that it is in
at least two suburban Vancouver-area public libraries, so I expect a lot
of libraries would have it, in keeping with the `low-cost’ notion.)

Having said that, your list of `tasks’ (along with perhaps example
solutions) is a great idea. That really adds value to the whole thing,
and would be relatively easy to build.

This feels like it’s ready to move forward. I volunteered to draft the
main page, and I’m feeling like I know what that should look like. I’ll
circulate something in the next few days.

– vincent

36

yup! glad my post caught someones eye =)

you can go a step further and put this in irbrc:

add this to your irbrc

def editor( *name)
name = name.first
unless editor_exists?( name.to_sym) || name == ‘ed’
method_body = <<EOF
def #{name}( *file_to_open)
unless file_to_open.empty?
ed file_to_open.join
else
ed
end
end
EOF
ENV[‘EDITOR’] = name
instance_eval method_body
“#{name} is now ready to use in irb”
else
ENV[‘EDITOR’] = ‘ed’ #Shut up and hack!
puts “setting venerable UNIX line editor ed”
puts “man ed(1) for more information”
puts “#{name} supported out of the box” if editor_exists?(
name.to_sym)
puts “There is no need to set it with editor”
end
end

def editor_exists?( editor)
editor_list = (InteractiveEditor::Editors.instance_methods - [:ed])
!( editor_list.grep( /^#{editor}$/).empty?)
end

to use it you simply type:

editor ‘ed’
or

editor ‘xedit’

then the xedit command will be available to you. or put your favorite
editor
inside irbrc to be there when you need it.
This is one of my first experiment into metaprogramming. I’m sure there
are
better ways to accomplish the same thing =)

Simple way to extend interactive_editor.

~Stu

37

On Apr 12, 8:30pm, Vincent M. [email protected] wrote:

Is there any sentiment that this would all be a worthwhile effort?

– vincent

Ruby is on my list of things to learn and every once in a while I go
check things out. I have a programming background, of sorts (midrange

  • think RPG/Cobol, Rexx, VB and Perl) although not recent. Most of my
    work is done on Windows and I think the closest I came to actually
    learning Ruby was when I downloaded Shoes. I liked playing with the
    sample programs and thought the environment was nice, if quirky and
    hard to modify. But I know some programming and I just thought there
    were too many pieces to deal with. Especially gems that should have
    been standard. (IMO and YMMV)

I do like Scite as an editor, though. I don’t remember if it’s
Autohotkey or Autoit that comes with it installed and also has a help
file with runnable scripts but it’s one of the best approaches I’ve
seen. I might still be using it if all the virus checkers didn’t go
nuts with the resulting programs.

What I would like to see is a true portable version of Ruby, packaged
with a way to make your own executables (or some sort of self-
contained way to distribute programs) without too much trouble. I
think if I would have had that, I would have stuck with it long enough
to actually learn it. (If you look at the newbie questions on any
scripting language, creating an executable is usually one of the top
ten FAQs.)

I play around with Portable Python on my flash drive once in a while.
I don’t like it that much but I do think learning either Python or
Ruby would be a good thing.

Terry (back to lurking)

p.s. the worst thing about Shoes was the Tricky Blocks section right
after the Intro. There has to be a better way to do that. I usually
bail right there and go back to playing with the sample apps.