Iain D. wrote:
Iain D. wrote:
That is, I should be able to download, run an installer, click on a
icon, and starting typing ruby code into an editor that can execute
the ruby code. 
Marnen Laibow-Koser wrote:
You can do that already. ĆÆĀæĀ½irb comes standard, and you can use any text
editor for files. ĆÆĀæĀ½If you want to run scripts, āruby my_script.rbā will
do fine. ĆÆĀæĀ½Whereās the problem?
Not quite the same. irb can execute code, but (at least I believe this
to be true, Iām still new around hereā¦) it isnāt an editor.
No, it isnāt. You said, though, that you wanted something where you
could type code in and execute itā¦you got it in irb.
Yes, you
can edit code in a text editor, and execute code from the command
lineā¦but that doesnāt fulfill the criteria.
Why on earth would you want the editor and interactive environment to be
the same? Thatās just confusing.
Thereās still going to be folks that arenāt going to be interested in
a product where they have to go to the command-line/shell to start
using the product.
For end-user software, sure. But for programming?!? This is where I
start saying that if theyāre that lazy, they shouldnāt be programming.
The idea isnāt even part of their world-view,
They can learn.
even
if they have a vague notion of what a shell is.
Anyone who intends to program (outside specialized environments like
Mathematica) needs to get comfortable at the command line. Period.
I switch back and forth across the GUI/shell dividing line pretty
frequently, but that sort of thing was a complete mystery to most of
the people Iāve worked with in the past.
Were these people programmers? If so, what was the context?
[ā¦]
My own preference right now for Ruby/Rails is Emacs+shell, but Iāve
worked with folks for whom thatād be an exercise in frustration.
If the Emacs part is the frustration, they can find another editor. If
the shell part is the frustration, then they shouldnāt be programming.
If they can write arcane Ruby commands, then they should be able to
write arcane shell commands as well.
Both
come from an entirely different world than the one they know.
And how would an IDE make it any better? Youād still have to write the
same Ruby code, and youād still have to run the same shell commands;
itās just that the shell window would be in the IDE instead of being
governed by a separate application. Whereās the advantage?
I think the question to ask is: As Rubyists, what do we want them to
learn? Ruby.
So everything else [installation, editing, execution, debugging]
should be provided in a form familiar to the target audience
The target audience is multifaceted. Therefore, only the basic tools
should be provided by default, and other tools should be available as
necessary to increase the feeling of familiarity.
and
arranged so that it is transparent/smooth.
Ruby installation is plenty transparent. So is installing the editor or
IDE of your choice. You are postulating a nonexistent problem, I think.
Whatever the solution (IDE
or some other clever idea) it should follow the conventions of the
platform/OS it is being installed/used on.
Right. Plenty of editors and IDEs already do that.
Absolutely nothing wrong with Shell+Favorite text editor. Thatās a
route I go often. For me, it is the fastest route to producing code,
because I already know that environment. Eclipse was a frustration to
me, because I needed to be writing code (Java at the time), but
instead I was spending the time learning Eclipse.
Thatās not fair. Any tool has its learning curve (for the record, I
like NetBeans a lot better than Eclipse).
Eventually, Iāll
have to admit the bias that created and give Eclipse another try.
However, the combination of tools that I find familiar and comforting,
could be an exercise in frustration for someone else.
Then they donāt have to use it. Why force the issue by bundling
unnecessary tools?
For instance,
someone very familiar with Eclipse would be much happier learning Ruby
on that platform (provided the platform supports Ruby).
It does. But theyād be making a mistake if they did so. No one should
ever use an IDE to learn a new language, unless (as with Cocoa or some
Java frameworks) the framework being used is so heavy that it requires
the IDE to save the user from boilerplate. This is not the case with
Ruby or Rails.
IDEs are tools, not crutches ā that is, they are for automating things
you do understand, not for preventing you from learning things you
donāt. Most of the people who are addicted to IDEs seem to use them as
crutches. This is not a behavior we should encourage in the Ruby
community or anywhere else. (In other words, the people who most want
IDEs are probably the people who most need not to be using them.)
It is
frustrating to have X to be your goal, and have to slog through Y and
Z.
Frustrating, but also life. And Ruby lowers the bar nicely. Why should
I have to learn a particular IDE to learn Ruby?
I admit, it may not be possible to provide comfortable and familiar
tools to every potential Rubyist. On the other hand, thereās no reason
not to try.
If you want to, go ahead. I think itās interesting, but perhaps a waste
of effort. OTOH, a new project is never a bad thing.
If a new IDE brings in another segment of the audience,
thereās that many more folks using and a few them helping to improve
Ruby.
No. The sort of folks we want in the Ruby community are not the sort of
folks who would hold off on using the language because it doesnāt come
with its own IDE.
We all benefit from an influx of new ideas from a segment of the
population previously unrepresented.
Why are they unrepresented?
Okay, Iāll stop flogging this horse, I already have a far longer
message than necessary.
Iain
Best,
āĆ
Marnen Laibow-Koser
http://www.marnen.org
removed_email_address@domain.invalid
Sent from my iPhone