Programmer's Editors, Illustrated.
Edit: The moral of the story, for those who didn't get it, is that a serious programming environment ought to be an intimately-personalized affair, like eyeglasses or a hearing aid. And that existing solutions fall laughably short of this goal. Emacs, the supposed counter-example, is conceptually heavy and unbearably complex for everyday "civilian" use - like the phoropter in the upper left hand corner. Vi, another favorite, is reminiscent of the stenopeic eyeglasses that are sometimes donated to poor countries: a "one size fits all" wrong tool for every job. Where, then, is the environment which adapts to its user, rather than demanding that its user adapt to it?
what do you think about this lisp machine emulation:
http://patrickcollison.com/blog/2008/04/lisp-machines
Dear kuvol,
I have been using the x86-64 OpenGenera for quite some time. Though, of late, not very regularly.
Yours,
-Stanislav
if anything
http://webpages.charter.net/edreamleo/front.html
You could probably make a much simpler version of it in Lisp, if you can't stand Python. It seemed like a total waste of time (or even an impediment) at first, but after a while it became strangely fun to use. Makes my own code easier to understand, at least.
Dear vncbl,
I have seen Leo. And a number of similar systems.
In certain aspects, Leo is an example of a "Skrode" - the kind of thing I have been trying to create for some years now. But taken as a whole, it is just the kind of thing I am trying to avoid making: a big ball of mud, bristling with non-orthogonal functionality, cancerous with accidental complexity.
Yours,
-Stanislav
Dear Stanislav,
I am currently building an alternative programmers editor using Clojure and Piccolo 2D. Unlike text file editors like Emacs, Vi, and Notepad, in this editor there won't be any notion of opening, closing, or saving files because you will be able to zoom into any object you want and edit it in place. Furthermore, well all Lisp based data structures (lists, matrices, trees, etc) will be supported in the editor, there will also be a visual interface to a variety of non-text based data structures such as dataflow graphs.
Dear jhuni,
I am glad to hear that you are writing an experimental programming system, and do not wish to discourage you. However, I strongly advise you to get hold of a copy of Mathematica and to experiment with it until you fully understand why it sucks - despite the fact that it lets the user "zoom into any object and edit it in place."
The presence of any complex (i.e. stateful) object (example: Clojure's reader, as opposed to, say, Common Lisp's) which cannot be opened up and arbitrarily modified from within the environment - poisons the whole experience.
But: "Some learn by reading. Some learn by observation. The rest have to pee on the electric fence for themselves."
Write whatever you want.
Yours,
-Stanislav
Dear Stanislav,
I would like for my editor to be demonstrate an alternative to the mainstream programming paradigms. Rather then being based upon the sequential processes which happen to be well suited for text, my development system will be based upon visually modeling relationships such as logical relationships and dataflow relationships. However, as you said yourself "talk is cheap" so I won't go into took much detail here.
I agree with you that the Mathematica experience is poisoned and the biggest reason for that is probably the lack of undo beyond one step. How can such an unforgiving system be sold to people for hundreds of dollars well it doesn't even forgive mistakes!? What a ripoff! My intention is to let users zoom into graphs, networks, trees, and other data structures and edit them in place and then undo those edits later on.
With reversibility my development system won't be poisoned but it certainly won't be free of performance issues, glitches, bugs, crashes, and other flaws as long as its based upon the JVM. These flaws will make having a system with comprehensible innards increasingly desirable.
Maybe I'm taking a swan-dive into the shallow end of the pool, but what I take from the image is that Emacs is just a useful tool for helping define an ideal programming environment. This is also my experience from using it exclusively for the last five years.
Another implication is that there's no present way of instantiating such a creation on the world without dragging the rest of Emacs with it.
Vi/m is good for quick edits, but not much else.
Emacs is pretty decent, though, but it's awkward as fuck to use in a terminal if you can't remember all the commands.
Ed is the standard text editor.
https://www.gnu.org/fun/jokes/ed-msg.txt
"Where, then, is the environment which adapts to its user, rather than demanding that its user adapt to it?" - in every "user's" knapsack! Except of course not every, not user, not knapsack but otherwise same idea 😀