Could Emacs be rewritten in Python?

Carl Banks imbosol-1050078176 at aerojockey.com
Fri Apr 11 20:30:29 CEST 2003


Alexander Schmolck wrote:
> Carl Banks <imbosol-1049990205 at aerojockey.com> writes:
> 
>> What you're missing is that Globals are Evil(tm), and furthermore, that if
> 
> Oh, so *that's* what I was missing -- silly me.
> 
>> your program depends on changing a global in a dynamic scope, it badly needs
>> to be redesigned. (To wit, that functions that refer to the global you want
>> to change need to be changed to accept it as an argument.)
> 
> You did notice, of course, that you don't only need to change that particular
> function foo, but also everything (directly or indirectly) calling foo? As
> well as everything that is called (directly or indirectly) by foo and that
> uses this global state information? Including 3rd party code and builtin
> constructs of the language?

Yes.  Since the idea here is to rewrite the Emacs in Python, you have
to rewrite all of this anyways.


>> I think dynamic scpoing is a wholly bad idea, and simplifying a very
>> misguided programming practice doesn't make it any less so.
> 
> How much time did you actually spend thinking about global variables and
> dynamic scope or what I wrote before you posted?
> 
> Why are global variables evil?
[snip reasons globals are evil]

I didn't say globals are evil.  I said Globals are Evil(tm).  Big
difference.  (You should learn the meaning of (tm); it means the
writer fully realizes that it's only a general truth, even though
others consider it an absolute truth.)


> Ever wondered why python (and about any non-functional language) still has
> global variables (and makes use of them in core modules such as sys)?
> 
> Because certain aspects of a program are orthogonal in a way that is best
> captured by state that is not explicitly passed around (even if by chance it
> would be possible to do it that way, because you can anticipate and correctly
> parameterize all state and have full control over all the involved code (see
> above)).

Well, in another part of this thread, I argued against total
elimination of global variables, much as you are arguing now.  I do
not oppose global variables in general.

I do oppose global variables where there are situations where it feels
necessary to change it and restore it.  That tells you right away that
your functions should not use a global, but should have it passed in.
Designing such a function to refer to the global anyways is Bad
Programming(tm).


[snip uses of globals]
> All this should *not* require rewriting each and every function and method
> call! How do you propose to address these issues (bearing in mind error
> handling and multithreading)?
> 
> Maybe there is a superior way to handle all or some of those issues (AOP,
> Monads, god knows what), but you haven't mentioned it.

These issues should be handled by global variables if they indeed are
global in nature.  The stuff you mentioned usually is.


> Similarly, you have given no indication why you think lexically
> scoped global state better address these problems than dynamically
> scoped state (or why its downsides such as new sources for bugs and
> complicating the language would outweigh the benefits). 

I have not said lexical scoping handles the issues you have referred
to better than dynamic scoping.  I have said that the issues you refer
are only issues in the presense of Bad Programming(tm).  Anyone using
globals discriminately will not have such issues to deal with.

But to answer your question: yes, dyanmic scoping is so awful it
doesn't justify this particular benefit, especially when the benefit
only arises in Bad Programming(tm).  In fact, dynamic scoping is so
awful is doesn't justify any benefits.

It's not just me; meny, many people regard dynamic scoping as a bad
mistake.

I don't wish to go into detail here.  The main problems are: It forces
you to use defensive naming schemes, even for your local variables.
You cannot determine the variables in effect just by looking at a
function in context.  You cannot do lexical closures.  It's less
efficient.


> Rather you
> just pretended the issue didn't exist and I was just being stupid
> for not realizing this to start with.

Don't be presumptuous.


-- 
CARL BANKS




More information about the Python-list mailing list