Ruby for beginners (was: Re: Hello)

[Chad_Perrin]

> For what it's worth I have been using interactive_editor gem in irb for a
> bit now. It allows me to open nvi or vim within irb and also supports other
> cli editors( emacs, pico/nano, and even ed for those still <3 the original
> unix line editor)

CLI editors are great -- for advanced users.

But the vast majority of people are used to WIMP interfaces, and that's
who should be targeted. vim and EMACS are nice editors, but they
overwhelm non-technically-trained people far too soon.

This is not a problem. Once you have your .irbrc file set up, start irb
and try this:

    irb(main):001:0> ENV['EDITOR'] = 'xedit'
    => "xedit"
    irb(main):002:0> ed

I use xedit here because it's likely to be just about anywhere people are
using the X Window System. Replace it with gvim, scite, or gedit if you
like. You can also set your EDITOR environment variable in your standard
shell environment (of course), or add the editor setting line above to
your .irbrc file if you like, so that setting up interactive_editor
config in .irbrc looks like this:

    require 'rubygems'
    require 'interactive_editor'
    ENV['EDITOR'] = 'xedit'

Then . . . you just enter "ed" at the irb prompt and it automatically
opens that editor, even if it's a GUI editor. Some editors may benefit
from special command line options.

(How do you generate a random string? Sit down a new student in front
of a vim session.)

How do you generate the complete works of Shakespeare within your
lifetime? Teach your monkeys how to use Vim. (It's not as hard as it
seems, once you get past the initial confusion over modal editing).

Anyway, interactive_editor supports nano "natively" (without the
environment variable trick), which is *really* easy for beginners to
understand. They'll just have to learn to use arrow keys instead of the
mouse.

···

On Wed, Apr 13, 2011 at 06:08:08PM +0900, Phillip Gawlowski wrote:

On Wed, Apr 13, 2011 at 5:23 AM, Stu <stu@rubyprogrammer.net> wrote:

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

[Vincent_Manis]

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

How often do you check for Tk?

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

···

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

On Wed, Apr 13, 2011 at 4:48 PM, Vincent Manis <vmanis@telus.netwrote

[Charles_Nutter]

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

- Charlie

···

On Wed, Apr 13, 2011 at 10:03 AM, Phillip Gawlowski <cmdjackryan@googlemail.com> 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 ). OTOH, the end of a "Ruby
for newby" guide could include a means of getting a more, er,
conventional Ruby installed and set up.

[Stu1 (Stu)]

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

···

On Wed, Apr 13, 2011 at 2:44 PM, Chad Perrin <code@apotheon.net> wrote:

On Wed, Apr 13, 2011 at 06:08:08PM +0900, Phillip Gawlowski wrote:
> On Wed, Apr 13, 2011 at 5:23 AM, Stu <stu@rubyprogrammer.net> wrote:
> > For what it's worth I have been using interactive_editor gem in irb for
a
> > bit now. It allows me to open nvi or vim within irb and also supports
other
> > cli editors( emacs, pico/nano, and even ed for those still <3 the
original
> > unix line editor)
>
> CLI editors are great -- for advanced users.
>
> But the vast majority of people are used to WIMP interfaces, and that's
> who should be targeted. vim and EMACS are nice editors, but they
> overwhelm non-technically-trained people far too soon.

This is not a problem. Once you have your .irbrc file set up, start irb
and try this:

   irb(main):001:0> ENV['EDITOR'] = 'xedit'
   => "xedit"
   irb(main):002:0> ed

I use xedit here because it's likely to be just about anywhere people are
using the X Window System. Replace it with gvim, scite, or gedit if you
like. You can also set your EDITOR environment variable in your standard
shell environment (of course), or add the editor setting line above to
your .irbrc file if you like, so that setting up interactive_editor
config in .irbrc looks like this:

   require 'rubygems'
   require 'interactive_editor'
   ENV['EDITOR'] = 'xedit'

Then . . . you just enter "ed" at the irb prompt and it automatically
opens that editor, even if it's a GUI editor. Some editors may benefit
from special command line options.

>
> (How do you generate a random string? Sit down a new student in front
> of a vim session.)

How do you generate the complete works of Shakespeare within your
lifetime? Teach your monkeys how to use Vim. (It's not as hard as it
seems, once you get past the initial confusion over modal editing).

Anyway, interactive_editor supports nano "natively" (without the
environment variable trick), which is *really* easy for beginners to
understand. They'll just have to learn to use arrow keys instead of the
mouse.

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

[Chad_Perrin]

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

···

On Thu, Apr 14, 2011 at 10:35:42AM +0900, Vincent Manis 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.

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

[Phil]

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.

_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.

···

On Thu, Apr 14, 2011 at 5:03 AM, Chad Perrin <code@apotheon.net> wrote:

On Thu, Apr 14, 2011 at 10:35:42AM +0900, Vincent Manis 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.

--
Phillip Gawlowski

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.

[Jim_Maher]

Phillip Gawlowski 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 Maher

···

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

[Adam_Madrigal]

Phillip Gawlowski

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

···

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

[Chad_Perrin]

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

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

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.

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.

···

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

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

[Phil]

Phillip Gawlowski 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.

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

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.

···

On Thu, Apr 14, 2011 at 5:28 PM, Jim Maher <jdmaher@jdmaher.com> wrote:

--
Phillip Gawlowski

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.

[Phil]

- 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

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.

···

On Thu, Apr 14, 2011 at 6:21 PM, Chad Perrin <code@apotheon.net> wrote:

--
Phillip Gawlowski

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.

[Chad_Perrin]

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

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

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.

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

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.

>
> 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

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

···

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

On Thu, Apr 14, 2011 at 6:21 PM, Chad Perrin <code@apotheon.net> wrote:

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

[Phil]

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.

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.

···

On Thu, Apr 14, 2011 at 9:16 PM, Chad Perrin <code@apotheon.net> wrote:

--
Phillip Gawlowski

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.

[Vincent_Manis]

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, Un*x/GNOME, and Un*x/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.

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'? 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

[Phil]

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.

2. I would identify four environments of immediate interest: Windows, OS X, Un*x/GNOME, and Un*x/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.

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.

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'? 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.

···

On Thu, Apr 14, 2011 at 11:43 PM, Vincent Manis <vmanis@telus.net> wrote:

--
Phillip Gawlowski

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.

[Vincent_Manis]

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.

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.

Agreed.

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.

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 Pine'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

···

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

[Chad_Perrin]

That's not really a big problem. The One 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.

···

On Fri, Apr 15, 2011 at 07:12:59AM +0900, Phillip Gawlowski 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.

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]