How do you program in Python?

[Grant Edwards]

Perhaps, but I'm puzzled how that explanation would apply to emacs and
those who use it as a swiss army knife, doing everything from editing to
email to laundry in the same editor...

It doesn't. Emacs doesn't follow the Unix way.

(Note: this isn't a flame about emacs, nor vi for that matter,
just a discussion about the apparent conflict in the two
philosophies embodied by the "simple little programs" and the
"emacs" approaches.)

Who said there wasn't a conflict?

 

[Mike Meyer]

Perhaps, but I'm puzzled how that explanation would apply to emacs and
those who use it as a swiss army knife, doing everything from editing
to email to laundry in the same editor...

Since you asked....

Unix tools require a complex environment to run in. Without a Unix
kernel (or some simulation thereof), the don't work at all. Without a
friendly shell, it's hard to get them to communicate with each other -
which is what makes building things out of the pieces so easy. If you
want to run those tools on a different OS, you have to port the
environment.

Emacs tools require a different environment: a running emacs. It's all
kept in one process, so it looks like one big program from the Unix
perspective. But it's actually a lot of smaller(*) programs running in
a shared address space. There's lots of differences between the two,
but a discussion of that is really OT for the group.

<mike

*) Smaller is relative, of course. A UMA or a web browser isn't
exactly a small tool in either environment.

 

[Jorgen Grahn]

What I would really like is something like an old-style BASIC
interpreter, in which I could list, modify and test-run sections of

I use no IDE, just emacs for editing my sources, and a terminal window or
two. And CVS for version control.

Often I run Python interactively to try out small "one-liners". For example,
I don't try to remember the slicing syntax, or what 'list("foo")' means, or
if range(0) is legal, etc -- I just try it out interactively.

If I get stuck or if the problem is non-trivial, or if I'm writing a
standalone module, I use module unittest so I have something easily runnable
at all times. This unittest code doesn't even have to be true unit tests --
it can be any speculative code I want, driven by the unittest framework.

Between these two (interactive tinkering and unittest-based code) I feel
little need for IDEs or 'environments for experimentation'.

Others will feel differently, of course.

/Jorgen

 

[Sybren Stuvel]

Jorgen Grahn enlightened us with:

I use no IDE, just emacs for editing my sources, and a terminal
window or two. And CVS for version control.

Almost the same here, except that I use VIM and Subversion instead of
Emacs and CVS.

If I get stuck or if the problem is non-trivial, or if I'm writing a
standalone module, I use module unittest so I have something easily
runnable at all times. This unittest code doesn't even have to be
true unit tests -- it can be any speculative code I want, driven by
the unittest framework.

Same here. I really love unittest!

Between these two (interactive tinkering and unittest-based code) I
feel little need for IDEs or 'environments for experimentation'.

I'm usually annoyed by IDEs because, for instance, they don't use VIM
as an editor. Since I'm hooked to that, all IDEs I've used so far have
failed to impress me.

Sybren

 

[Dan]

You probably want to check out Wing IDE 2.0. There is a free trial.

 

[Jorgen Grahn]

I'm usually annoyed by IDEs because, for instance, they don't use VIM
as an editor. Since I'm hooked to that, all IDEs I've used so far have
failed to impress me.

Same here (s/VIM/Emacs/, or course).

I try not to make myself too dependent on some specialized software, because
(a) I tend to work on different Linux or Unix machines, or even on Windows
and (b) my development cycle is almost the same whether I'm programming in
Python, Perl, C++ or C (or writing in HTML, troff or LaTeX, for that
matter).

Emacs and vim are almost always installed, or trivially installable. All I
need to remember is to bring my emacs config file.

/Jorgen

 

[Gregory Bond]

Emacs and vim are almost always installed, or trivially installable. All I
need to remember is to bring my emacs config file.

And, fortunately, USB pen drives are now big enough to hold it!

 

[Jorgen Grahn]

And, fortunately, USB pen drives are now big enough to hold it!

Hey, it's not fair to make fun of emacs now that I've mentioned vim
favourably so many times ;-)

Seriously, nothing about emacs seems big or slow today. It has been
outbloated by pretty much everything else. Who could have imagined /that/
ten years ago?

/Jorgen
(And just in case this thread deteriorates into a silly emacs-vs-vi
argument, I hereby declare myself out of the game.)

 

[Mike Meyer]

Hey, it's not fair to make fun of emacs now that I've mentioned vim
favourably so many times ;-)

Seriously, nothing about emacs seems big or slow today. It has been
outbloated by pretty much everything else. Who could have imagined /that/
ten years ago?

Actually, it hasn't. Then again, maybe it depends on how you use it. I
start an xemacs at login, and leave it running forever. Just like I do
a shell. It slowly accretes buffers as time goes by, many of them
useless (why do I need to keep traces of 14 POP sessions around?).

As a result, xemacs is usually the second biggest thing on my system

I treat most programs that way. I never exit them, just unmap them.
My WM is configured to map a single existing window, launch the
application if there is no existing window, or offer a menu of windows
if there's more than one existing window when I ask for an
application. So I tend to have a lot of old, big processes on the
system. And xemacs is usually bigger than everything but X.

And people wondered when I complained that Mac OS 9 and Windows 98
crashed a lot .

<mike