Re: What editor or IDE do you use?

On Thu, Jun 02, 2011 at 04:18:35PM +0900, Xavier Noria wrote:
> Well, the argument "since Ruby is not as heavyweight as Java or C++,
> there's no need for an IDE, I've been doing well with simple editor
> X!" is flawed for me.
>=20
> I've been doing Perl with CPerl for years, and Ruby with TM for
> years. There's still room for a ton of help. There's a negative space
> you don't see out there. That's why people come with plugins, because
> once you have the help of snippets, or once you know how helpful is
> being able to jump from action to view, or from model to test case,
> then you value that and want that extension.

=2E . . for a while.  Just as I thought Dreamweaver, then Homesite, was
great for a while but eventually went back to plain ol' text editors when
I realized they were in my way more than I helped, I have done the same
with IDEs for languages that are not too incoherent and complex in their
implied development models to get work done efficiently without an IDE.
After a while, the IDE becomes "the language", and effort is spent
learning and using the tool rather than the language itself.  While
vi-like editors are very powerful tools -- as powerful as any IDE out
there, I would say, when used within the context of a developer enabling
environment like the Unix userland -- they are essentially *transparent*
tools; they do not obscure the language behind their abstractions,
diverting my attention from the language with their features.  This is,
to a significant degree, what I value most about them.

Dealing too much with an editor's gizmos is a distraction from the code,
as a trade-off for the convenience those gizmos provide.  Getting into
"the zone", as one might call it, becomes very difficult because the
language does not disappear from conscious view by way of a nearly
intuitive grasp of it; it is obscured from view by way of a conscious
attention on the tools for dealing with it.

IDE: I don't really see the language any longer.  I just see drop-down
lists, completion widgets, MVC organizational hierarchy trees, variable
and class managers. . . .

Vim: I . . . I don't even see the code. All I see is blonde, brunette,
red-head. Hey, you uh . . . want a drink?


>=20
> Your reaction is not: "Ruby is simple, I can type
> validates_presence_of myself no prob". Your reaction rather is "ah,
> albeit Ruby is simple, that's still helpful!". That "ah" moment
> happens a lot working with a Rails-aware editors like RubyMine. The
> first day I saw renaming a controller renamed all the folders, tests,
> etc. for you and updated the repo with the changes if you wanted, I
> was sold. The day you make a typo in the table name of add_index and
> gets underlined in red, you say "ah, Ruby is simple, but that's
> helpful".

Actually, my reaction is "I've been using this for a while, and it seemed
helpful at first, but I've eventually discovered this is in my way, a
distraction from the real work," or "This provides a little bit of value,
but the trade-off that comes with using this instead of that is too high
a price to pay."

It's not like I've never tried IDEs or plugins for Vim.

Things like moving or changing the names of large numbers of files,
directories, and so on, are as easily accomplished using the basic tools
in my working environment as using an IDE.


>
> And same with a ton of Rails-specific features (have little experience
> with Ruby-only projects in RubyMine, there's support but have not used
> it).

This might be part of the disconnect between us; I do a lot of Ruby-only,
or (more accurately) Ruby-plus-stuff-that-isn't-Rails.  I alluded to the
complexities of Rails being akin to those of languages like C++, to some
extent; its magic is a bit like the impenetrable depths of C++ in the way
that it's getting to be effectively impossible to hold a complete
understanding of how things work in one's head.  While I would happily
use Rails and improve my facility with it for the right client or
employer, outside of such requirements I prefer to do my work without it,
because while I like tools that give me additional leverage, I prefer
tools that are meant to be understood by mere mortals, rather than
employed as an act of faith.


>=20
> If you could have those features in Vim you'd like them. People prefer
> Vim in spite of not having them because in their pros and cons list
> they value other stuff. Like being able to use it for everything (I
> can't do Perl with RubyMine), extensibility, speed, memory usage, etc.
> I understand that and that's fine of course.

I mentioned a couple of those things, but you seem inclined to ignore
that in favor of telling me I don't know what I'm talking about.


>=20
> But saying "Ruby is simple, we do not need much help" is flawed, when
> you get help you value it. And that's why people install a dozen
> plugins, to get as much help as possible. (And sometimes people don't
> because it gives the feeling of an aggregation of stuff to some and
> prefer a lean environment.)

=2E . . except when that "help" is more illusion than reality.  Facility
with a language, with a particular development workflow, and with a
particular model of software development makes a lot of the stuff one
would get with an IDE or piles of plugins *redundant*, or even
counterproductive because bad automation sometimes does things wrong.

Bad automation is the stuff that tries to make my decisions for me.  Good
automation makes execution of my decisions easier.  An editor that
"knows" the language on a semantic level is an editor of the first type;
an editor that is optimized for dealing efficiently with syntax is of the
second.

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