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

Shlomi Fish shlomif at iglu.org.il
Tue Jun 8 03:49:47 PDT 2004

On Tuesday 08 June 2004 11:55, Yuval Yaari wrote:
> >OK. As long as you don't expect people to use it or even use an editor
> > that can use it.
> Use anything you want.
> I personally would recommend an editor that would cut development time.
> Be it by code-completion, search/replace, macros, debugger integration,
> etc, etc.
> If an editor would offer more features for cutting my development times
> (without harming/risking anything, of course), I'd switch.


> I started with pico too. Can't stand it now...

Hmmm... neither can I. Strangely enough, Israeli universities are infested (or 
at least used to be) with people using pico for writing code. It doesn't even 
have auto-indentation for god's sake! I have no idea how they manage.

> I switched between so many. I didn't use joe, though.
> I didn't like NEdit.
> Without pointing out my selection, I invested a lot of time and efforts
> in both emacs and vim.
> I remember how I couldn't understand anything (C-x C-c??? ESC :q! ???).

Nice. I'm used to gvim and occasionally learn new commands. I tried to use 
Emacs on several occasions, but kept finding it irritating. Some people do. 
(unfortunately ?)

> >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.
> These days, you should allow me to ask more from my editor :)

I allow you to even ask your editor to write your code for you. (M-x 
write-my-code-for-me) However, you should also understand people who still 
don't want to use all the functionality that any editor can offer.

A related item to this thread of this discussion is "The Story of Mel - A Real 


> >>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.
> Perl modules don't count :)

Ah OK.

> I have a shell integrated with my editor, but I usually just background
> my editor, run the command, and type `fg`.
> CVS can be easily integrated to my editor everytime I press a
> key-combination or even everytime I save.

Fair enough.

> >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 use konsole and give names to the shells so it's comfortable.
> If you're comfortable with it, stick with it.

I also use konsole but usually open up several separate terminal windows 
instead of terminals in separate tabs.

> >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".
> Can you give me an example of code that can be maintained by emacs/vim
> but not with notepad?
> Maybe folds will look funny - but except for that, all code should be
> maintainable.
> Maybe I'm forgetting something...

Right. (If I understand you correctly, I guess)

> >OK. Are you sure the situation is any different in a large company? (i.e:
> > that your supervisor won't give you some slack).
>  From people who worked with me and moved to bigger companies, I know
> it's not as simple as here.
> They wouldn't fire you as you call to say you'll be late for work, but
> when they see that you come at 11:00 or take off at 16:00 - they'll
> write down your ID for the "TO-FIRE" list.
> I've never worked for a big company, so I couldn't tell for sure.
> I would like it if someone could comment on this one, as I am interested
> about it.

I don't know either. I only worked for small companies and one mid-sized one. 
But it sounds a bit like paranoia to me. Maybe some big companies are like 
that, but I'm not sure if all of them. (and it can vary depending on your 

> >>Also sometimes it's camelCase.
> >
> >Actually, that's javaCase. ;-)
> HAHA - never heard of this one.
> Ok, I stand corrected.

Well, it is the recommended style for function names (and perhaps even 
variable names) in Java.

> >Package names are in CamelCase. I use 4-whitespace tabs (without using any
> >actual \t characters - these are Evil).
> I've read "tabs are evil" but I don't agree.

I am constantly frustrated by code that uses a mixture of tabs and whitespace 
for indentation. It usually displays incorrectly in my editor (much less in 
"less"), and I have to tweak the settings. The reason I always expand tabs, 
is that a tab-less file will look the same with any editor setting.

> >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)
> I try not to press any keys, and just use the mouse, or things get ugly :)

Well, I usually hate the need to excessively point and click the mouse. I 
think it should be possible to customize ddd somehow to work with different 
key-bindings, but I haven't tried to do it yet.

> >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.
> Don't count on it :)
> They might not know Perl, or even worse, they might use Python instead :)

Right. I meant people who know Perl (or something else) and don't have a good 
reason to use C instead. I heard of someone who tried to do string processing 
in Fortran. There was no way his program could handle files with lines over 
80 characters or so. Now this sounds like hideous code.

> >>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.
> Basically, I tried TK and WxPerl but they both aren't fun to write in or
> maintain.
> Also, I wasn't happy with the way it looked or worked.

Well, if you use Gtk+ and Qt, you are likely to not end up with something 
usable at the first try as well. It requires a lot of tinkering to get right. 
GUI programming is hard in any language. But, trust me, it's much harder in C 
and C++. The reason C/C++ GUIs seem so polished is because they _were 
polished_, either by tinkering with the code, or by the previous experience 
of the programmer or GUI designer.

If you don't think it's fun writing things in Tk, you probably won't find gtk 
or Qt fun either. (much less MFC or Motif... ;-))

Note that I try to avoid programming GUIs as much as I can, and some of the 
GUIs I developed and did not have time or need to polish were quite lame. But 
I can attest that I found GUI programming in Perl much quicker, and much less 
frustrating than C++. 

> Ever tried the Perl OpenGL modules? That's a different kind of GUI though
> :)

OpenGL is not GUI. GUI is Graphical User-Interface. OpenGL is a module for 
creating real-time three-dimenstional _graphics_. You can write a 
full-fledged GUI library using it (with a lot of effort), but it's not what 
it's meant for. Sometimes, people use a GUI library (like Gtk or Qt) and 
within it embed an OpenGL window.

> >Things one should use C for:
> >
> >[...snipped...]
> >
> >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.
> So why do so many people use C/C++ for so many things that don't match
> your criteria?

Well, you need to have some historical perspective. Computers used to be so 
slow, that writing anything serious in interpreted languages was out of the 
question. One example I can think of is that I was told that the 4.2BSD 
manual, had in its instructions for compiling the kernel, something like 

And now type "make". This step may take up to 24 hours.

And the compiler was written in C, mind you. In the old XT days, the C 
compilers produced such relatively sluggish output, that some large-scale 
applications (like Lotus 1-2-3 or WordPerfect) were completely written in 
Assembly (!).

Perl was written in 1987, but back then it was not intended for writing 
serious modular code. This changed only when Perl 5 was released. If you ever 
looked at perlhist it says:

Perl 5 introduced everything else, including the ability to introduce 
everything else.

There were other languages back then, but they weren't either substantially 
more powerful (in the sense of having powerful programming constructs) than 
Perl, or they were simply not down to earth (as was the case for LISP, or 
Smalltalk) or they were mini-languages created for specialized tasks (m4, 

In a way, for a long time programming was crippled by the lack of speed of 
computers. The PDP-10 and PDP-11 mini-computers were so slow that a Pentium I 
processor can run their emulator faster than they could actually run. 
(possibly even several emulators in parallel).

As a result, there is a lot of legacy code written in C, which is still 
maintained. Sometimes, people still write new code in C, because either don't 
know Perl (or Python or whatever) too well, think they are insuitable for 
large codebases, because no layman has heard of them, or other reasons like 

Sometimes it makes sense to write things in C, that could otherwise be written 
in Perl, even without sacrificing too much speed or memory saving. An example 
is many of the GNU utilities, that are preferable to be small and self 
contained, than to depend on the Perl run-time being around. (after all you 
may need to run them on an Embedded system or whatever).

Note that I'm not attesting to it first-hand, as the first computer I had a 
serious experience with was an XT, which was already pretty fast, and could 
be fit nicely on a desk. And it's speed is dwarfed by today's computers.

> Also Perl can handle pretty big data-structures and files very easily
> (read about the bioinformatics stuff...).

True, but it's memory overhead is much larger than C's. A simple Perl scalar 
is an individuallly malloced C structure, containing a few fields and 
possibly followed by some extra fields if it's a special one, which points to 
an individually malloced buffer (in case it is a string). If you allocate a 
large array and fill it with integers (say @my_sequence = (1..10000)), then 
it is bound to be much larger than the equivalent C vector, because every 
element is still a scalar.

In C it would be:

int * my_sequence; /* A pointer to integers */
int i;

my_sequence = malloc(sizeof(int) * 10000);
	my_sequence[i] = (i+1);

/* Now we can use my_sequence */

I think you can understand what's going on here even if you don't know C very 
well. In any case, the size taken by my_sequence here would be the size 
needed to store 10,000 integers (usually 4 bytes each), plus some necessary 
overhead required by the allocation algorithm rounded to the next power of 2. 
64K in our case. 

In Perl, such an array would be much larger because it isn't conceivable a 
scalar would only take 6 bytes of memory.

So, sometimes the Perl memory overhead does not make a difference, and 
sometimes you cannot avoid it.

> [Thanks for your comment, I snipped so Gabor won't make us buy bourekas :)]

Well, I think the current discussion is on-topic. And I also snipped some 

> >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.
> Doesn't that work both ways?
> I hope you're right.

Well, C knowledge can give some advantage in learning Perl. The problem is 
that I learned BASIC (which is like a really lame Perl-like language), before 
I learned C, which was before I learned Perl. I still believe my experiences 
with BASIC later helped make the transition to C a less painful one. (else, I 
would have really not known what to do.) There were still things that took me 
some time to learn in C (it's low-level details are simple, but take time to 
understand), but it was still better than getting introduced to it without 
knowing what a loop is or what a conditional is for, or what a string and 
characters are, etc.

Someone who knows Perl is already familiar with all the basic (pardon the pun) 
programming paradigms and can write full-fledged programs. This will at least 
make him able to understand how to write basic programs in C. What he needs 
to learn is the things specific to C (like pointers, pointer arithmetic, data 
types, casts, etc.) which cannot be harder than to a complete beginner, 
because there are similar things in Perl as well. (or if there aren't, you 
are still more experienced).

Generally, the first programming language one learns always require the most 
effort. This is despite the fact that when I learned other languages, there 
were often many things that surprised me and enlightened me. When learning 
Scheme and Lambda Calculus, for example, I ended up finding out that I can do 
it in Perl, and fully understood the concept of closures and lexical scoping.

> >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 wouldn't know.
> One thing I can be sure of, C/C++ are getting old...

Well, they are still usable, even today. I don't see a point in trying to 
replace all the C and C++ code out there with something else. Especially 
because I don't think there's anything that is more suitable for a large part 
of the programs written in it. Hell, even Java and Perl are written in ANSI 

You can't escape C. It's everywhere. 
Heh heh... heh heh... heh heh.. <evil-laugh />

> Hey, even Perl is, and that's why they're releasing perl6 (I hate it,
> personally), so no offence C/C++ programmers.

Well, Perl 5 is not as old as Perl. I think it is still usable. If you 
followed the discussions on this mailing list, you'd know that I also dislike 
Perl 6, or simply do not understand it, and generally think it's a bad idea. 
I think that we need a different path (and I think I know what it is) if we 
want to adapt Perl 5 to future developments. 


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

More information about the Perl mailing list