[Israel.pm] Editors as Power Tools [was Re: Variable Naming]

[Shlomi Fish]

On Monday 07 June 2004 23:47, Yuval Yaari wrote:
> Shlomi, I will do some heavy snipping, let me know if I skip anything.
>

OK.

> Shlomi Fish said:
> > auto-completion is a nice-to-have feature, which is useful, but still
> > not a  must. It was introduced rather lately in editors development. And
> > not  everybody use it.
>
> True - I just found it to cut my typing time (finger-pain? :p) without
> cutting my line of thinking.
> That's why I speak of it so highly (just like I do with Perl for the same
> reason) :p

OK. As long as you don't expect people to use it or even use an editor that 
can use it.

> > Seriously now, I think I'm using a very large subset of the features of
> > joe  when I use it. (or at least had when I seriously used it). So joe
> > doesn't  have so many features that I don't use. In the working
> > environments I grew up  with, auto-completion was not present, and so I
> > did not get used to using it.  Maybe now I will.
>
> Well, I didn't have syntax highlighting when I started to write in Perl
> (because my stupid editor didn't).
>

Neither did I. When I started to write in Perl, the only editor I knew was 
pico. I couldn't get used to vi, so I actually compiled Emacs from source on 
Cortext's FreeBSD workstation and tried to work in it. Then I noticed a 
co-worker using joe, tried it and was hooked. I worked with joe for a long 
time since then. joe does not have syntax highlighting or almost anything 
that would cause it to be anything more than a minimalistic but still usable 
editor.

Since then, I dabbled with NEdit (which isn't bad), used FTE for a while 
(which is nice, but idiosyncratic), until I got used to gvim and used it ever 
since. Note that I still use joe when working in terminals (as opposed to 
using X-Windows or MS-Windows), and I set the EDITOR and VISUAL env-vars to 
it.

Believe it or not, but some people still regularly use an editor which doesn't 
even have syntax highlighting. I also consider it a nice-to-have feature and 
not a necessary must in an editor. 

> >> I meant a power tool for programmers.
> >> I can't think of another way to program, please open my eyes to your
> >> telepathic way of programming :)
> >
> > I don't have one. At least not yet. What I meant was that one's editor
> > can be  very powerful, or it can be relatively limited. A text file is a
> > text file.  You can edit it with ed, pico or repetitive bash commands if
> > you want, and  gcc or the Perl interpreter will still be able to process
> > it and run it  correctly.
>
> Right but if it doesn't help you program more effeciently, you should just
> rm -f it.
> As I wrote before, what other tools do you use when programming Perl?

I use the shell (to run the programs, chmod them, etc), perl -d (to debug 
them); for serious things I also use Subversion with its svn client (to 
version control it). When writing CPAN modules, I use MakeMaker, make test, 
Test::Harness, Test::More, etc. There's one program I wrote in Perl and other 
technologies (Quad-Pres) that is auto-confisicated.

> I only use my editor and perl (not Perl).

Good for you. 

> My editor can do grep and cut and all the things I used to do from the
> command line before I started using it.
> It can also easily go into the background if I do need the command line.
> Debugging is done from inside, also Devel::SmallProf for tiny
> optimizations and debugging (oh, I find it as a great tool for debugging,
> but that's a different issue).
>
> Both perl and my editor are my power tools, if you see the situation.
>

I understand. I don't find keeping a few terminal windows open and invoking 
commands in them, to be a nuisance. I'm used to it, and that's how I like to 
work. I think I can do everything from within gvim, but I never tried to get 
used to doing it.

> > I was using the painter's as an analogy. I am very reluctant to call
> > some  editors "powertools", as they are nice, usable and bug-free, but
> > still quite  limited. But some poeple use them.
>
> I think you should consider your editor as your power tool.
> And use an editor which is a power tool.
> Most popular editors are power tools (think of all their features, and
> think of how many of them you know... I know maybe 1/1000th of them).
>

Well, among UNIX hackers the most popular are vi and Emacs. They are divided 
about 50%-50% and the percentage that use the rest is marginal. Note that I 
don't know if it is possible to call the non-vim vi-clones powertools. vi is 
quite feature-full and its macros (which are made of a sequence of individual 
keystrokes) are Turing Complete, but vim is much more powerful.

Nevertheless, while I'm using an editor that is a power-tool, (albeit not sure 
I can call my use of it a "power-use") I intend my code to be maintainable 
even by much less capable editors. Like I said a textfile is simply a 
textfile - a sequence of ASCII characters. The programming language just 
needs it to make sense. And fellow human programmers just want it to be 
readable even when using "less" or "more".

> > Indeed. Does your work start at 09:00.
>
> Basically.
> Working in a small company means you won't get fired for getting there at
> 11:00 one day if you had to go to the doctor or whatever.
> Such situations occur (when I moved to my own place for example) and your
> company shouldn't treat you like a robot :)
> Anyone considering me as a possible employee, cover your eyes:
> I used to exploit this and do some things before work like take mail (the
> physical kind), drink coffee, etc.
> I was nicely asked to come earlier and so I did.
> That's why I said "basically". 9:00 is when I want to be there.
>

OK. Are you sure the situation is any different in a large company? (i.e: that 
your supervisor won't give you some slack). 

> > Right. BTW, why are you using CamelCase for variable names? Most people
> > use words_separated_by_underscore. (and I personally find it much more
> > desirable).
>
> Why are you using words separated by underscore?
> Ok, not being a smart-ass: I don't care as long as I or anyone stick to
> their style for an entire project.
> Sometimes I use underscore separated names for variables and CamelCase for
> subroutines.
> Also sometimes it's camelCase.

Actually, that's javaCase. ;-)

> I do stick with it for an entire project though, so it wouldn't confuse
> anyone.
> Let me know about your style, I am constantly after a better one.
>

Well, I use $words_separated_by_underscore for variables. I don't capitalize 
them often, but sometimes do if they are important, or it otherwise seems 
sexy to capitalize them. Usually, they are just one word in this case, and 
they usually aren't scalars. (but like I said, I don't capitalize much)

Subroutines are also in lowercase separated by underscores. I don't write 
"write_HTML_file", but "write_html_file". 

Package names are in CamelCase. I use 4-whitespace tabs (without using any 
actual \t characters - these are Evil).

I think I'll stop now. If you want you can find examples of my style (some of 
them quite old and my style has changed somewhat since), here:

http://shlomif.il.eu.org/open-source/

And here:

http://search.cpan.org/~shlomif/

> > Notepad does not have auto-completion, or even auto-indentation, last
> > time I  checked. I installed gvim on Windows and consistently uses it
> > for everything  serious. It's funny that MSIE uses notepad to view the
> > source of the HTML.
>
> Funny? It's living hell!
> Can't they write something better or even steal some source code?
> It would be legitimate for this specific case...
>

LOL.

> I used Windows for some project where I wanted to use Win32::IE::Mechanize.
> I had a 6MB (read: small) log file.
> I tried notepad - crashed my computer.
> I tried wordpad - crashed my computer.
> I downloaded my editor (which you know what it is but I'll shut up) and it
> was really fast.
>

Hmmm... installing gvim on Windows is one of the first thing I do when I have 
to seriously work there. I even got used to gvim because it was installed on 
a network drive on the Windows computers of my Technion department. Funnily 
enough, gvim was not installed on the Linux computers back then. The only 
things there were Emacs, and some other crappy editors (CoolEdit, etc.). Even 
typing "vim" on the command line amounted to nothing (albeit "vi" was 
probably "vim").

> > Maybe it's possible to run the perl debugger from within gvim. I never
> > really  tried. I use either perl -d (on the command line) or sometimes
> > ddd (but  usually for C, and even there I mostly use plain gdb). ddd is
> > a very  impressive debugging front-end (for gdb, perl -d, and other
> > debuggers). But  it's quite heavyweight and written in Motif.
>
> I use ddd.
> Sometimes it shows a bad "dump" of weird data-structures.
> Maybe I used an old version.
>
> I was looking for a better debugging solution to be integrated into my
> editor.
> The reason is that I'm used to the keys/colors and ddd is different.

Yes, ddd seems to have a mind of his own regarding key-bindings. I keep 
pressing the wrong keys because I'm used to the keystrokes of MS DevStudio 
(which are different than those of Borland's IDEs, to which I was used 
beforehand)

> What I have comes with my editor and is nice - but it's just perl -d with
> highlighting, basically.
> What I'm missing is selecting a data-structure see it's "dump" on the side
> (or anywhere without losing my current view of the code).
>
> I think it's worth to explore how you can force perl -d to work from
> within your editor.
>

By "dump" do you mean a graphical display of it? That would be nice. 

> > One of the most irritating things about Visual C++ is that its debugger
> > does  not have a command prompt. gdb is so much faster and easier (and
> > more easily  automated and customized). GUIs can seriously suck in
> > comparison to CLIs some  times.
>
> I am a bit ashamed of it, and I should change this; I do not know C/C++.
> Compared to Perl, it's such a mess!
> Everything takes so long to write.

You are right a C code takes longer to write than the equivalent Perl code. 
However, people don't usually use C for things they can use Perl for. 

> Maybe it's because I never had to write something robust and/or serious
> GUI applications that I never learned these 2 languages.

Well, actually Perl code can be very robust. At least, unless we are talking 
about two different meanings of the word "robust". Also, I think Perl, Python 
and friends are much more suitable for writing GUI applications than C or 
C++. Writing GUI in ANSI C is painful. In C++ it's somewhat better. (if you 
have a decent GUI toolkit and not something crappy like MFC, which isn't much 
better than ANSI C). But then, naturally, you are frustrated that g++ is so 
damn slow. In Perl, it's just write and run.

Sometimes it makes sense to write the GUI in Perl/Python/etc. and the 
internals in a more low-level programming language. Sometimes, the amount of 
code in the internals overwhelms the GUI code, so it's a better idea to keep 
the GUI in C, as well.

Things one should use C for:

1. Stuff that works with hardware. (Embedded systems, device drivers, 
operating systems kernels, etc.)

2. Some programs that ought to be very fast and/or consume very little memory. 
These include some real-time programs (i.e programs that should respond to 
certain events within a limited timeframe), or just programs and frameworks 
that need to be very fast.

3. Generally, programs that involve a lot of data crunching, excessive amount 
of loops, conditionals, expressions, assignments and other program logic will 
perform much better in C.

I don't consider Perl and similar languages as such that are not "serious". 
You can perfectly write code that is either very reliable, very large-scale, 
very robust, very maintainable, or all of them in them. There is still a 
place for languages such as C or C++ (or Java - ?) and I expect that they 
will still remain important into the forseeable future. However, one should 
write what he can in Perl/Python/etc. because writing in C is painful and 
error-prone.

> Good sources for the C/C++ basics are welcome in private e-mail :)
>

I'll give you my thoughts here, if you don't mind. (I don't think it's 
off-topic here. As C is useful even for Perl programmers). While I learned C 
and what was then C++ from the Turbo C++ 3.0 manual (and some help from 
fellow programmers), you should probably get a better source. "The C 
Programming Language" by Kerninghan and Ritchie is highly praised, but I did 
not read it. I bought the book "A Book on C" which the Technion professor 
Yehi'el Kimchi (who teaches two introducory courses about C, C++ and UNIX to 
Technion stduents) recommends for my sisters. I don't know what they think of 
it. 

I think that an experienced Perl programmer can possibly learn from a lesser 
quality book.

It would be useful to learn ANSI C before learning C++. C++, especiallly in 
its recent STLish incarnations, can hide a lot of low-level nitty-gritty 
logic of ANSI C by tons of templates, references, inheritance, operator 
overloading and other abstractions. By learning ANSI C, one gets a lot of 
understanding on how a computer performs its operations and how to write 
efficient code.

In any case, one should be thankful if he had the opportunity to learn Perl 
before C and C++. Israeli university students are keep getting confused by 
the low-level gotchas of C.

As for C++, I think it supports Object-Oriented Programming roughly as much as 
COBOL supports Functional Programming. I'm not saying it isn't useful, but 
OOP is so much nicer and easier in higher-level languages.

> > I happen to like command line debuggers.
>
> I get along well with perl -d.
> Did I mention my Devel::SmallProf way for quick-n-dirty debugging?
> You just know what lines ran and how many times (you can also `sort` on it
> which is great) which usually explains a lot of things without going
> through the debugging process.
>

Interesting. I'll keep that in mind.

> > Hmmm... $laazazel_lekh_hapesh_mi_yenaanea_otkha ... ;-)
>
> Have you been watching the comedy store lately? :)
> Great show! Still funny after all those years.
>

They did not invent the term "lekh hapesh mi yenaanea otkha". The Comedy Store 
had some nice exits, but most of their material was relatively unamusing.

> >> I hope the interview went well, good luck.
> >
> > It went pretty well. It involved some discussion about Perl there, but
> > I'd  like to delay discussing it in public until I find out if I got the
> > job or  not. (they have other candidates)
>
> Ok - when you're rich, don't forget who told you "good luck".
>

Heh heh. Right.

Regards,

	Shlomi Fish

-- 

---------------------------------------------------------------------
Shlomi Fish      shlomif at iglu.org.il
Homepage:        http://shlomif.il.eu.org/

Quidquid latine dictum sit, altum viditur.
        [Whatever is said in Latin sounds profound.]