What editor or IDE do you use?

Ruby
21

(In the following, I will use “vi” to refer to vi-like editors in
general, including Vim. I will also use “Emacs” to refer to EMACS-like
editors, including GNU Emacs.)

Interesting . . . right away, when the question was first asked, several
vi users responded. A day later, I find that several Emacs users
finally
responded as well. I can only surmise that the vi users responded more
quickly because vi helps people get things done more quickly.

No, no, I’m kidding. It was probably actually a result of Emacs’ slow
startup time.

No, wait, I’m kidding about that too. The truth of the matter is that
both of these editors have some serious learning curves associated with
them. See the image illustrating those learning curves on this page:

Vim for New Users
http://sob.apotheon.org/?p=981

In terms of what they provide to the person who scales that learning
curve, becoming an adept user of either one of these editors, the return
on investment is incredible. Each has its advantages over the other, of
course, and which you will prefer is a matter of preference more than
anything else, it seems – though of course we (heavy vi and Emacs
users)
are probably all afflicted by the sincere belief that one of them is
objectively superior to the other. It is taking a powerful act of will
to avoid turning this email into a platform for extolling the virtues of
the vi way of doing things. I really do not want to be accused of
starting a flamewar with a partisan attack in this email.

Ultimately, however, my thought is that if you are already comfortable
with either vi or Emacs, you should use it anywhere that it is at all
reasonable to do so. While other editors may provide some handy
features
that make them particularly useful in certain contexts, such as
Redcar[0]
for Ruby development, those features’ payoff is limited – and it goes
away the moment you start working on a different task.

Meanwhile:

  • The payoff for using the vi or Emacs way of doing things applies in
    almost every single situation where entering or altering text is the
    task at hand.

  • The benefits of these editors are not limited to context-specific
    features like those of Visual Studio[0] (or whatever); they grow
    endlessly over time, as you learn more about how to use them, tweak
    them to suit your personal preferences, and acquire the knack of
    applying them effectively in more situations.

  • They are everywhere, while other choices like TextMate[1] are
    generally much more platform-dependent.

  • They aren’t going anywhere. As long-established staples of open
    source
    software culture used by more people than almost any other piece of
    open source software, their durability in the face of developers and
    vendors getting hit by buses, going out of business, suffering
    crippling RSI that prevents them from coding[2], or just getting bored
    with them and ceasing to perform needed maintenance on them is nearly
    unmatched in the world of software development. The same cannot be
    said of UltraEdit’s[1] futureproofing.

Ultimately, there probably isn’t much reason to switch editors if you
are
already comfortable, and gaining increasing proficiency, with vi or
Emacs. If you have never used either, though, and do a lot of coding,
you should probably give each of them enough of a try to get past the
point where you feel completely helpless, then pick the one whose
“philosophy” best suits your taste and stick with it long enough to
start
feeling its benefits. At that point, give it up if you don’t like it,
but if you do a lot of coding (especially in high-level dynamic
languages
like Ruby) you will probably get to love one of these editors –
especially if you spend a lot of time in a Unix-like environment.

NOTES:

[0]: The editor or IDE mentioned in this case is basically just a
placeholder for “pretty much every editor in the world that is not
vi-like or Emacs-like”.

[1]: The editor or IDE mentioned in this case is a basically just a
placeholder for a sizable subset of the applications from note [0].
TextMate users in particular should not take it personally; I’m sure it
is a wonderful editor, despite its platform snobbery.

[2]: I hear this happened to Richard Stallman, famous for his
involvement
in the early development of the original EMACS and for his ongoing
maintenance of GNU Emacs (when he wasn’t suffering crippling RSI).

–
Chad P. [ original content licensed OWL: http://owl.apotheon.org ]

PS: I should probably polish this lengthy ramble into an article for
TechRepublic at some point.

22

Jeez… BSD or Linux… or Doze?

Enough already… back to our regularly scheduled Ruby questions! :smiley:

23

On Thu, Jun 02, 2011 at 03:09:06AM +0900, Wilde, Donald S wrote:

Jeez… BSD or Linux… or Doze?

Enough already… back to our regularly scheduled Ruby questions! :smiley:

. . . although, the editor question does have some relevance for
people
who want some idea of the relative merits and failings of various
editors
when they are assessing the best options for what to use while writing
Ruby code.

24

New POLL!!!

Which layout do you prefer?
QWERTY
DVORAK
PROGRAMMER DVORAK
COLEMAK

=)

25

You made your point succinctly and eloquently Chad.

I do find it interesting that the topic of text editors becomes a
passionate debate even after all these years. I discovered the Z shell
about 6-7 years ago after a two year stint with bash and previously
worked exclusively with (t)csh and (a)sh.

After discovery of zsh I immediately contacted my buddy who I wanted
to share the joy with whom had been using bash since it’s release.

His response was ultimately pragmatic. He felt that he had been using
bash so long that it made no sense for him to switch. I respect that
view.

vi as all good unix utilities builds on the concept that everything is
built from knowledge from the previous tools.

For example if you follow the tool of how shell programming evolved
before perl broke the single command does one thing and one thing
well:

ed => grep => sed => awk ----> perl and now ruby

each one of these builds on the concepts of the previous( much the
same way the shell has evolved). Most of us prefer it because it is on
every unix system so it’s always available in some form or another.

vim has many plugin’s that can make it act like just about any ide
like environment. Support for syntax highlighting in over 3000
languages, programs, and frameworks. Built in regex and (s)ed style
features in ex. Macros, automation and scripting. They even have
auto-completion.

Ultimately unless someone has been stuck using a closed source editor
or any closed software over an extended period of time they might find
it difficult to switch. Essentially every user has a preference based
on their skill and will prefer the tools that they have hit an apex
with.

Sticking with open source editors( even the GUI ones) in any form will
at least get the user the empowerment and freedoms we all enjoy
working with these tools.

I imagine Stillman’s vision wont truly be realized until hundreds of
years after his death where closed source editors and tools will have
hit EOL time and time again while the open source editors based on the
editors of the mid 70’s will still be highly developed and in heavy
use for whatever programming is done in that era. Talk about leaving
your legacy.

26

Markus F. wrote in post #1002374:

to my knowledge there’s nothing you can make % to do
jump between opening begin/class/etc. and closing end.

The matchit plugin adds that functionality to Vim:

http://www.vim.org/scripts/script.php?script_id=39

27

On Thu, Jun 02, 2011 at 06:35:40AM +0900, Xavier N. wrote:

Let me add to this thread that the editors of dedicated IDEs are
generally speaking light-years more aware of their target than vim or
emacs. And I have been an emacs user for years.

I think that the idea of equating tight coupling with superiority is
deeply flawed. Flexibility and composability have, in my experience,
proved significantly more important and empowering than tight coupling.

This is just one reason among many that I prefer vi-like editors over
big
IDEs. Unfortunately, there are cases where, in essence, the language
one
uses is nigh-unusable on its own for nontrivial projects, as in the case
of Java (at least relative to languages like Ruby). Because of this,
their demand for tools that do a lot of the work for you is significant,
which means you need to focus more on tools that know the language than
on tools that aid productivity by helping you edit code more
efficiently.

Ruby has proven to have nowhere near that kind of difficulty associated
with its use, for me. This is one reason of many that I like it. I can
use a vi-like editor, focusing on writing and editing code rather than
on
getting the editor to write the scaffolding and boilerplate I need, and
to help me look up complex chunks of code needed to achieve basic
functionality.

I am talking editors, not integrated environments. I mean, most people
assume working with an IDE means that you’re expected to run rake
tasks within the IDE and launch web servers. Well IDEs provide that,
but you can use an IDE for its powerful editor, and be a console guy,
that’s my case.

Apart from stuff like “Intellisense” and code generation, there isn’t a
whole lot the bare editor part provides that Vim doesn’t – and Vim
actually has an Intellisense-like plugin now. There’s a certain amount
of code generation that could be arranged even with basic functionality,
too. What are these magical capabilities of just the editor that IDEs
provide above and beyond the capabilities of something like Vim?

When I am going to work in the same Rails application for the whole
day, I launch RubyMine and a console. Only use lighter editor for
casual editing nowadays.

Sometimes people say “baahh, IDEs, I don’t an integrated environment”,
and then they go and install a dozen plugins for their favorite editor
to be able to have… an integrated environment! Only, it is never
that complete. This argument is for me kinda a Greenspun’s Tenth Rule
for editors.

Note, by the way, that while I pointed out there’s an Intellisense-like
plugin, I don’t use it. I don’t need it. Ruby is neither Java nor
C#.
It isn’t C++, VisualBasic, or any of a few dozen other languages with
similar complexity issues. Sure, there’s a lot to Ruby, but it requires
much less . . . management than what comes with those other languages.

Y’know what I have for plugins? Nothing. Not a damned thing. The one
thing I actually integrate with Vim for coding in Ruby is irb, via the
interactive_editor gem.

By the way, the reason you have to create an informally specified, buggy
implementation of Lisp when writing nontrivial programs in other
languages (according to Greenspun’s rule) is not because Lisp comes with
crap tons of features piled on top. It’s because Lisp has a simple,
elegant semantic form that provides incredible power and flexibility
belied by that simplicity. That’s shockingly similar to how the core
vi-like experience works: a simple, elegant semantic form (relative to
IDEs, anyway) that provides incredible power and flexibility belied by
that simplicity. Vim throws a lot of features on top of the vi-like
editor experience, most of which I really don’t need, but the center of
the experience helps.

That’s not to say that IDEs should not be used. Especially for C#,
Java,
and other languages in that category of unmanageable complexity, IDEs
are
very useful. They can be very useful for Ruby as well – especially if
Ruby is being written by someone who is not familiar with editors like
Vim and Emacs, and especially if dealing with very complex frameworks.
They are certainly not necessary for Ruby coding, though, nor even
preferable for many developers, even when dealing with those very
complex
frameworks. Maybe an IDE works better for you than Vim, but certainly
not for me.

Of course, working with vim or emacs has a ton of advantages, and a
lot of people prefer them. That’s fine I am not saying they shouldn’t.
But if you want a powerful editor for technology T and there’s a good
IDE for T out there, its editor is going to be really smart about T.

Yeah, maybe so – but the smoother the development experience provided
by
the language itself, the less smart about the language the editor needs
to be to provide a roughly ideal experience programming in that
language.

Ruby is definitely among the top 10 languages I’ve seen for a smooth
development experience.

28

On Thu, Jun 02, 2011 at 08:35:33AM +0900, Wilde, Donald S wrote:

Which is why I REALLY want to get Ruby ported to my little target, so
if anyone has a clue as to how I can get past the little linker bugaboo
that has make failing to pass a symbol file name to ld…

I wish I could help, but that’s beyond my areas of expertise.

I find stories like yours about what people have done with Ruby, without
needing the heavyweight support tools that are part of daily life with
languages like C++, interesting – and, of course, it’s always nice to
have my sense of working with the language confirmed by others’ similar
experiences.

29

Let me add to this thread that the editors of dedicated IDEs are
generally speaking light-years more aware of their target than vim or
emacs. And I have been an emacs user for years.

So, if you want to work with Java, nothing beats IDEA, and no amount
of plugins will give you RubyMine for Rails.

I am talking editors, not integrated environments. I mean, most people
assume working with an IDE means that you’re expected to run rake
tasks within the IDE and launch web servers. Well IDEs provide that,
but you can use an IDE for its powerful editor, and be a console guy,
that’s my case.

When I am going to work in the same Rails application for the whole
day, I launch RubyMine and a console. Only use lighter editor for
casual editing nowadays.

Sometimes people say “baahh, IDEs, I don’t an integrated environment”,
and then they go and install a dozen plugins for their favorite editor
to be able to have… an integrated environment! Only, it is never
that complete. This argument is for me kinda a Greenspun’s Tenth Rule
for editors.

Of course, working with vim or emacs has a ton of advantages, and a
lot of people prefer them. That’s fine I am not saying they shouldn’t.
But if you want a powerful editor for technology T and there’s a good
IDE for T out there, its editor is going to be really smart about T.

30

-----Original Message-----
From: Chad P. [mailto:[email protected]]
Sent: Wednesday, June 01, 2011 10:13 PM
To: ruby-talk ML
Subject: Re: What editor or IDE do you use?

On Thu, Jun 02, 2011 at 08:35:33AM +0900, Wilde, Donald S wrote:

Which is why I REALLY want to get Ruby ported to my little target, so
if anyone has a clue as to how I can get past the little linker
bugaboo that has make failing to pass a symbol file name to ld…

I wish I could help, but that’s beyond my areas of expertise.

I find stories like yours about what people have done with Ruby,
without needing the heavyweight support tools that are part of
daily life with languages like C++, interesting – and, of course,
it’s always nice to have my sense of working with the
language confirmed by others’ similar experiences.

One of the things I’ve been watching more and more as systems and web
programming matures is the way that doing a job right requires multiple
programming languages. UNIX started it with awk and sed and TeX mixed in
with shell script, and the Web almost requires JavaScript on top of
whatever else you use. One area where Rails is definitely ‘done right’
is in its wrapping of database functionality. If you want to have
nightmares, just take a quick glance at the Zend framework. (I’m not
kidding, you WILL have nightmares) Such multi-lingual programming takes
you beyond any IDE really quickly.

C++ is a really special case. It’s the only language I know which has
multiple distinct layers of syntax within itself, and that helps make it
really opaque when reading someone else’s code. If their idioms are
different than yours, look out!

Thanks for the commiseration, Chad. It’s beyond my expertise too, but
I’m about to the point where I’m going to have to become an expert if I
want it to fly.

31

On Thu, Jun 02, 2011 at 04:18:35PM +0900, Xavier N. 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.

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.

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

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.

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.

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

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

32

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.

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.

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

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.

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

33

Chad I never said you don’t know what you are talking about. I think you
do know of course.

My thesis is that the Ruby editor in RubyMine undertands Ruby better
than non-dedicated editors do. That’s it, and I think that is just a
fact.

I insist I am talking about the editor itself, not the integrated
environment as a whole. As I said I use the editor and the console.

When I have a local variable unused, the editor warns me. I appreciate
that. I appreciate a lot of the Ruby and Ruby on Rails knowledge
builtin.

So in my cons and pros balance, it wins. In yours, Vim wins. That’s
totally fine!

34

Curious does RubyMine have a vi mode?

Though I mentioned that vim has plugins I personally don’t use them.
In fact if Bostic’s vi had syntax highlighting I would probably never
install vim.

I do find it interesting that so many IDE style features have been
reproduced in this terminal editor. There are many rails specific
projects for vim.

Though I have never used it there is even a tetris clone that teaches
you the key layout which may be an interesting tool to practice for
the autodidact who need another resource besides vimtutor.

~

35

On Thu, Jun 2, 2011 at 8:40 PM, Stu [email protected] wrote:

Curious does RubyMine have a vi mode?

There’s this plugin

https://skitch.com/fxnoria/fns2x/settings

though I have not used it.

36

Hello,

On 01 Ιουν 2011, at 1:33 π.μ., Mike H. wrote:

I’m pretty new to Ruby. What editor or IDE do you use? I usually use VIM for a
lot of my coding. Rubymine looks pretty cool.

TextMate on Mac. If you don’t want to pay you can try TextWrangler but
you loose a couple of sweet options like “on the fly compile/interpret”
etc, that comes with textmate.

On linux I use vim with a couple of .vimrc lines in order to emulate
textmate’s behavior.

Best Regards,

–
Panagiotis A.

email: [email protected]
blog: http://www.convalesco.org

The wise man said: “Never argue with an idiot. They bring you down to
their level and beat you with experience.”

37

-----Original Message-----
From: Xavier N. [mailto:[email protected]]
Sent: Thursday, June 02, 2011 12:19 AM
To: ruby-talk ML
Subject: Re: What editor or IDE do you use?

[snip]

have not used it).
[snip]

I totally agree that Rails is much more usable with a Rails-aware IDE as
you say.

My HO is that Rails is about as far from a programming language as it’s
possible to get (in its own good way). The structures of directories,
helpers, rules in configuration and method naming conventions are so
distributed that keeping them current is almost impossible without a
very tightly integrated IDE. Especially if you don’t live and breathe
Rails in your dreams.

I stopped using RoR completely when it became apparent that there was no
way to pick a stable point (say 2.2) and build from there. Rails is so
much of a moving target – and it’s guaranteed that somebody is always
using a component that is newer than your stable point – that it
becomes impossible to use as less than a full-time occupation.

MHO is that I wish the Rails team would adopt a two-track model, where
new packages are back-ported to -STABLE as well as -BLEED unless they
only work with -BLEED features, but of course the FOSS answer is “if you
want it, DIY” and I am grateful for the fact that it exists so folks who
can devote full time to it can develop such amazing web systems.

Ruby itself is so intuitive that debugging with puts is sufficient, but
I’ll agree that refactoring (or renaming, such as you suggest) is an
area where I’d like to have support. I’ve found that Ruby’s built-ins –
especially its containers and iteration mechanisms – are so powerful
and elegant that very little code gets beyond a page.

38

On Jun 2, 1:00pm, Xavier N. [email protected] wrote:

On Thu, Jun 2, 2011 at 8:40 PM, Stu [email protected] wrote:

Curious does RubyMine have a vi mode?

There’s this plugin

Skitch | Evernote

though I have not used it.

IdeaVIM is great. I use PyCharm daily at work, and RubyMine and
IntelliJ IDEA occasionally, and I always use IdeaVIM. I think you’d be
hard pressed to find a better vim plugin in an IDE.

39

On Fri, Jun 3, 2011 at 2:45 PM, Red J. [email protected] wrote:

IdeaVIM is great. I use PyCharm daily at work, and RubyMine and
IntelliJ IDEA occasionally, and I always use IdeaVIM. I think you’d be
hard pressed to find a better vim plugin in an IDE.

Not used IntelliJ, but Netbeans’s jvi plugin is superb.
http://jvi.sourceforge.net/

martin

40

Details . . . ?

Janus is sometimes described as being textmate for vim: