Vim for Ruby?

Ruby
1

I’d like your opinion on this:

I claimed that being able to use vim is an essential skill for people
who code in dynamic languages (for reasons you’ll see in the article). I
haven’t got complete agreement from the few Python developers who’ve
responded, so I’m wondering how the Ruby community sees it.

2

Am 17.02.2014 07:53, schrieb Andrew S.:

I’d like your opinion on this:

Perl training - Geekuni blog: Why learn Vim?

I claimed that being able to use vim is an essential skill for people
who code in dynamic languages (for reasons you’ll see in the article). I
haven’t got complete agreement from the few Python developers who’ve
responded, so I’m wondering how the Ruby community sees it.

I don???t think it is useful to force a developer onto a specific
editor.
Whilst I think that basic editing skills in vi (not necessarily in vim)
are required due to its omnipresence, the final decision heavily depends
on the developer. For my part, I???m very happy using Emacs and I???ve
seen
people doing professional Ruby coding with other editors than vim,
Sublime Text for example. These editors all have different usability
paradigms, and which one you like is a highly personal and subjective
decision. You should use whatever sweets you and makes you most
productive.

Oh and btw, editing your code “in production” on the server is a bad
habit. You shouldn???t be doing that anyway ??? first properly test it.

In conclusion: Yes, basic editing with vi is a useful skill. But whether
to do all the coding with vi(m) or any other editor should be left to
the developer???s choice. You could at least install some more editors
on
your ebox so students can choose whatever they like by setting $EDITOR
in their ~/.bashrc (or whatever shell init file is in use).

Vale,
Marvin

3

Thanks Marvin.

I appreciate your point (and commented on it on the blog). Can you
recommend any other editors which should be available through the
console?

Andrew

4

On Sun, Feb 16, 2014 at 10:53 PM, Andrew S. [email protected]
wrote:

I claimed that being able to use vim is an essential skill for people
who code in dynamic languages.

It’s useful to know to be able to do quick config changes on remote
systems, but that has nothing to do with developing regardless of
the language used.

“edit your code on the box where it runs” ?? I don’t know of anyone
who does that – you develop and test on your local system and then
deploy that code to remote systems to run.

And FWIW my preferred editor (jEdit) can open an edit buffer on a
remote system via ssh, so what’s available on that target system is
really irrelevant to me at least.

YMMV,

5

vi, ed, ex and even cat =)

you can always install pico, nano, vim, edwin or emacs… and many
other
variations of the theme.

oh and no vim is not installed on UNIX and students can make their own
decisions. Maybe if you show what you are attempting to prove. Sort of a
write up tutorial exploring your efficiency model vs “this is how I do
it”.

(nvi use here and still occasionally uses the “one true unix editor” ed)

~Stu

6

On Mon, Feb 17, 2014 at 7:12 PM, Stu [email protected] wrote:

vi, ed, ex and even cat =)

… sed -i

you can always install pico, nano, vim, edwin or emacs… and many other
variations of the theme.

No, not everybody can always install software on a system where she
needs to work on. Permissions or network connectivity might hinder
that.

(nvi use here and still occasionally uses the “one true unix editor” ed)

Hats off to you! I never got around to learning ed more closely.

Kind regards

robert

7

Hello,

On 17 Φεβ 2014, at 08:53 , Andrew S. [email protected] wrote:

I’d like your opinion on this:

Perl training - Geekuni blog: Why learn Vim?

From the above link: “It’s essential that you learn Vim if you want to
be a Perl developer.”

This is a random statement without any reasons to back it up. To make my
point clear I’ll try to run through every relevant statement:

  • “This is because it comes with virtually every Linux/Unix
    installation”
    No, vim[1] is not installed Debian GNU/Linux, which is the reference
    distribution for open source, although not my favorite.
    Plus, you can install any open source command line editor. I like to
    joke about emacs and take part on flames but emacs is equally powerful.
    If it’s not there you can install it.

“And why is that important? Because you can ssh in and edit your code on
the box where it runs*”
Same for every other command line editor (emacs being the primary
counter-example, due to nearly infinite power - like vim). But these
days there are ways to do it on TextMate[2], Sublime[3] and other more
universal solution like editr[4]. See truth is that if you are a good
UNIX hacker, you can find more than X ways to edit remote files with
your editor, execute them remotely and get the result back in your
terminal.

So the answer is absolutely NO. You can chose whatever editor you like,
whatever editor makes you feel better and you should do that. Also I’m a
big fan of respecting the environment you’re getting into: If you are a
professor and you want your students to code in VIM - I don’t see why
the editor should be force in this scenario but nevertheless - they
should respect your choice and go with it. If you join a company which
uses NetBeans as the default editor, then you’d better off using - imho

  • spending some time using the software the people you’re going to work
    with, use in order to facilitate communication.

I know extremely proficient hackers who do not claim or believe that
they have mastered VIM or Emacs because mastering one of these two
beasts take tremendous amount of time and will.

NOTE: VIM is my editor of choice and yes I believe that it’s one and
only.

[1] vim or vi doesn’t really matter these days.
[2] https://joshkerr.com/remote-edit-files-on-linux-with-textmate/
[3]
sublimetext2 - How to use Sublime over SSH - Stack Overflow
[4]
editr - Edit remote files with your local editor - Jason Tokoph

Panagiotis (atmosx) Atmatzidis

email: [email protected]
URL: http://www.convalesco.org
GnuPG ID: 0x1A7BFEC5
gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5