--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 02, 2011 at 06:35:40AM +0900, Xavier Noria 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.


>=20
> 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?


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


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

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

--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk3mw6AACgkQ9mn/Pj01uKVg+gCePZT7u5ijiH0HY/uEv562jj2q
xIYAnjKdSibU2HH/NGp3JquON1BYlGqO
=ZHBk
-----END PGP SIGNATURE-----

--LZvS9be/3tNcYl/X--

On Thu, Jun 02, 2011 at 06:35:40AM +0900, Xavier Noria 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.


>=20
> 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?


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


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

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk3mw6AACgkQ9mn/Pj01uKVg+gCePZT7u5ijiH0HY/uEv562jj2q
xIYAnjKdSibU2HH/NGp3JquON1BYlGqO
=ZHBk
-----END PGP SIGNATURE-----