Iain Davis wrote: >> Iain Davis 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 [email protected] Sent from my iPhone -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
