Could Emacs be rewritten in Python?

[Alexander Schmolck]

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?
 
> 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?

- because they can lead to poor encapsulation and code that is impossible to
  understand and dangerous to modify because of hidden dependencies
  (parameterizing e.g. logging as an argument for every single method and
  function doesn't exactly help either, however)

- because they make it hard to avoid inadvertent changes to other parts of the
  program (this problem can be much reduced by dynamic scoping which ensures
  that localized and temporary state changes will be automatically cleaned up,
  *even* if there are errors and *even* if you use multiple thread ( e.g. I
  want to only log a particularly critical code section with a high logging
  level -- how do you do that in a multithreaded python application?))

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

Examples that come to mind are:

* pervasive concerns that affect all or large portions of code such as:
  - logging (e.g. I should be able to change the logging level for a
    particular, critical operation)

  - localization and printing options e.g. output precision, pretty printing,
    maximal print length etc.

  - state information to ease development and debugging (e.g. controlling
    assertions, debugging and hooking into functions for tracing or
    input/output verification etc.). 

* fine tuning aspects of behavior of a class conceptually related functions
  that is are however very widely used

* interfacing to the system or another application and the tracking of changes
  and transactions for error recovery as well as adjustment of details of
  error recovery and handling

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.

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). Rather you just pretended the issue didn't exist and I
was just being stupid for not realizing this to start with.

'as