[ale] Why I run emacs

[Michael B. Trausch]

On Fri, 2010-08-20 at 14:10 -0400, Ed Cashin wrote:
> On Fri, Aug 20, 2010 at 12:43 PM, Michael B. Trausch <mike at trausch.us>
> wrote:
> ...
> > Honestly, I would be *truly* happy if there were an editor like
> Emacs
> > that was always in input mode (command mode in vi is evil,
> especially on
> > low bandwidth, high latency links where you can't keep track of what
> > fscking mode you're in), but was extended using Python instead of
> LISP.
> > Seriously.
> 
> Hmm.
> 
>   http://common-lisp.net/project/python-on-lisp/
> 
> Maybe after "(require 'cl)" emacs can use python-on-lisp to
> grant your wish.  Minimalists will react violently, though, if
> they find out what you've done.  ;)

I don't know that I could even do it.  Two levels of VMs/interpreters is
just too much for me.  I Python, in LISP, in a native-code managed
runtime system/interpreter, the very thought makes me cringe.

I am a _huge_ fan of LLVM for the reason that you can use a managed VM
to run your code in (*excellent* idea for development, provided they
take advantage of the fact that they have a VM and therefore better
control for things like debugging and analysis of programs), but also
the ability to compile directly to native code, either at initial
compile time or at installation.  I heard at some point that LLVM may
even become the default compiler suite on systems in the future, though
I don't know how much faith I put in that statement: GCC is still
getting new features added to it and its development is quite active,
even though its developers say that they have a hard time with it
anymore because of the size of the code base.  Some features, like the
recently added link-time optimization that landed in GCC 4.5, are
reimplmentations of features that LLVM has had for a long time.

> I thought lisp was a little odd, but there's good lisp support
> in emacs of course, and there's emacs lisp documentation
> that's helpful.  Breaking stuff up into little functions makes
> programming easier, and then it's just a question of saying
> 
> (if (> 1 2)
>     (message "1 > 2")
>   (message "1 isn't > 2"))
> 
> ... instead of
> 
> if 1 > 2:
>     print "1 > 2"
> else:
>     print "1 isn't > 2" 

For limited stanzas things I can do it.  The major problem I have is
that when I go to do something, I don't just try 100 things to see if it
works without a reason as to why I'd try each individual one.  That is,
I try to truly understand the system before I start working in it or
writing code in it or whatever.  And something about LISP just escapes
me.  One of the biggest issues I have with it is the ordering of
parameters, and the second biggest issue that I have with it is that all
of the people that write LISP code seem to have the ability to wade
through seas of (((((( ))))))) and intuitively see things that I can
only intuitively find in cleanly-written C-family code or in languages
like Python where indentation is the requirement and not just the
convention.  I like to have visual cues as to the structure of a
statement, or a function, or the whole bloody module.

Perhaps I am just being fussy.  I have to read a lot of very poorly
written and formatted (and of course, ill-documented) code pretty much
daily in various languages, and I don't want to subject myself to that
sort of work when I'm just updating a configuration file (admittedly on
some quite hefty steroids).

For that matter, that's why I won't read through someone else's BASIC,
COBOL, or Fortran code.  Actually, the only old language that I can
think of that encouraged cleanly formatted code was Pascal, which I am
still somewhat surprised isn't used more often.

	--- Mike