bye for now....

3 views
Skip to first unread message

Ray Dillinger

unread,
Mar 13, 2005, 11:05:54 AM3/13/05
to

Yesterday I had a Profound Idea.

One of those ideas that comes along maybe six or seven times
in a lifetime, if you're smart and think a lot about programming
languages and systems.

As a consequence of this Profound Idea, I think I know a way to
do what nobody has been able to do for forty years - make a
computer language fundamentally more powerful and expressive
than any other Lisp dialect which has ever existed, but which
is also scalable to large projects and amenable to separate
compilation.

Therefore I will be spending the next few months tinkering with
fundamentals deep inside the heart of a Lisp compiler.

The roguelike game I've worked on, currently about half-finished,
goes on a back burner, and I will probably quit reading here in
a couple of weeks. I'll be back in about six months or a year
from now when I have a functioning demo of a new programming
language.

Bear

The Sheep

unread,
Mar 13, 2005, 11:52:39 AM3/13/05
to
Dnia Sun, 13 Mar 2005 16:05:54 GMT,
Ray Dillinger napisal(a):

> As a consequence of this Profound Idea, I think I know a way to
> do what nobody has been able to do for forty years - make a
> computer language fundamentally more powerful and expressive
> than any other Lisp dialect which has ever existed, but which
> is also scalable to large projects and amenable to separate
> compilation.

Take your chance, we're holding our thumbs for you.
We'reawaiting the new language with anxiety :)

--
Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
`The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.

ABCGi

unread,
Mar 13, 2005, 8:16:32 PM3/13/05
to
The Sheep wrote:
> Dnia Sun, 13 Mar 2005 16:05:54 GMT,
> Ray Dillinger napisal(a):
>
>>As a consequence of this Profound Idea, I think I know a way to
>>do what nobody has been able to do for forty years - make a
>>computer language fundamentally more powerful and expressive
>>than any other Lisp dialect which has ever existed, but which
>>is also scalable to large projects and amenable to separate
>>compilation.
>
> Take your chance, we're holding our thumbs for you.
> We'reawaiting the new language with anxiety :)

Good luck!

--
ABCGi (geek) http://codemonkey.sunsite.dk S14 D15 C13 I17 W9 c12
GCS/IT$/L/B$ d+(-) s: a? C++ ULUSU-- P+ L+>++ E- W++$ N+ o+ K--
w+++(--)$ O- !M- V PS++(+) PE-@ Y+(++) PGP>++ t++ 5+ X R(+++) tv
b++(+) DI++++ D+++ G e++>+++ h++(home office!) r++ y++* BAS-----

Hansjoerg Malthaner

unread,
Mar 14, 2005, 4:22:50 AM3/14/05
to
Ray Dillinger wrote::

> As a consequence of this Profound Idea, I think I know a way to
> do what nobody has been able to do for forty years - make a
> computer language fundamentally more powerful and expressive
> than any other Lisp dialect which has ever existed, but which
> is also scalable to large projects and amenable to separate
> compilation.

Wow! I wish you success for your new project. I, too, think current
languages are very restricted, yet I don't have an idea how to change
that. If you can, all power to you :)

> Bear

--
c.u. Hajo

Twisted One

unread,
Mar 14, 2005, 4:30:13 AM3/14/05
to
Hansjoerg Malthaner wrote:
> Wow! I wish you success for your new project. I, too, think current
> languages are very restricted, yet I don't have an idea how to change
> that. If you can, all power to you :)

Adding the ability to define scoped language extensions via a grammar
and translation rules to the original language, perhaps. Maybe the
language should use XML, and XSLT? Then any higher level structure you
can dream of, just about, can be created.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

Hansjoerg Malthaner

unread,
Mar 14, 2005, 5:03:10 AM3/14/05
to
Twisted One wrote::

> Hansjoerg Malthaner wrote:
>
>> Wow! I wish you success for your new project. I, too, think current
>> languages are very restricted, yet I don't have an idea how to change
>> that. If you can, all power to you :)
>
> Adding the ability to define scoped language extensions via a grammar
> and translation rules to the original language, perhaps. Maybe the
> language should use XML, and XSLT? Then any higher level structure you
> can dream of, just about, can be created.

Evolution:

1) Simple stuff, simple use
2) Complex features, diffucult use
3) Complex features, simple use

XML and XSLT are not yet in the "Complex features, simple use" phase, I
think.

--
c.u. Hajo

Jakub Debski

unread,
Mar 14, 2005, 5:48:16 AM3/14/05
to
Dnia Sun, 13 Mar 2005 16:05:54 GMT, Ray Dillinger napisał(a):
> As a consequence of this Profound Idea, I think I know a way to
> do what nobody has been able to do for forty years - make a
> computer language fundamentally more powerful and expressive
> than any other Lisp dialect which has ever existed, but which
> is also scalable to large projects and amenable to separate
> compilation.

Beeing always pesimistic ;) I think you should answer a few question before
you'll start :)
1. Is creating a completely new language necessary?
2. Is that new language has a chance to become popular?
3. Who will write compilers for it?
4. There are already a lot of Lips dialects. Will your language be so
original and powerful?
http://en.wikipedia.org/wiki/Lisp_programming_language#Genealogy_and_variants
5. Have you ever tried to write your own compiler? I did. It's a really
hard and time consuming work...

Well... it's of course your time and your ideas :)
If these thoughts don't let you sleep, then realise them.

regards,
Jakub
--
"We're just toys in the hands of Xom"
xenocide.e-plan.pl - SF roguelike in development
www.graveyard.uni.cc - visit Roguelike Graveyard
www.alamak0ta.republika.pl - my other projects

Jeff Lait

unread,
Mar 14, 2005, 6:11:04 AM3/14/05
to
Ray Dillinger wrote:
> Yesterday I had a Profound Idea.
>
> One of those ideas that comes along maybe six or seven times
> in a lifetime, if you're smart and think a lot about programming
> languages and systems.
>
> As a consequence of this Profound Idea, I think I know a way to
> do what nobody has been able to do for forty years - make a
> computer language fundamentally more powerful and expressive
> than any other Lisp dialect which has ever existed, but which
> is also scalable to large projects and amenable to separate
> compilation.
>
> Therefore I will be spending the next few months tinkering with
> fundamentals deep inside the heart of a Lisp compiler.

Please let us know how this turns out. Even if it turns out not to
work. In that case I want to be forewarned in case I ever think of
that idea myself... :>

To make it scalable to large projects I think you are going have to
invest in bondage and discipline programming techniques, however.
There are somethings in the world I'd like to be proven wrong about,
however.
--
Jeff Lait
(POWDER: http://wwww.zincland.com/powder0

Ray Dillinger

unread,
Mar 14, 2005, 1:09:17 PM3/14/05
to
Hansjoerg Malthaner wrote:
>
> Evolution:
>
> 1) Simple stuff, simple use
> 2) Complex features, diffucult use
> 3) Complex features, simple use
>
> XML and XSLT are not yet in the "Complex features, simple use" phase, I
> think.

Good ideas make good things better. Great ideas make better
things simple.

Bear

Ray Dillinger

unread,
Mar 14, 2005, 1:06:50 PM3/14/05
to
Jakub Debski wrote:
> Dnia Sun, 13 Mar 2005 16:05:54 GMT, Ray Dillinger napisał(a):
>
>>As a consequence of this Profound Idea, I think I know a way to
>>do what nobody has been able to do for forty years - make a
>>computer language fundamentally more powerful and expressive
>>than any other Lisp dialect which has ever existed, but which
>>is also scalable to large projects and amenable to separate
>>compilation.
>
>
> Beeing always pesimistic ;) I think you should answer a few question before
> you'll start :)
> 1. Is creating a completely new language necessary?

Nope. :-) It's a "bug-fix" to the idea of what Lisp is.
In theory, I could adapt an existing Common Lisp or Scheme
to have new and radically different function call semantics
that only become apparent when the new capabilities are
specifically invoked. Although it is not possible to do
what I intend and remain strictly conformant to the
standard for either language, the differences could be
made subtle enough not to impact most extant code.

> 2. Is that new language has a chance to become popular?

Not terribly likely. It will most likely appeal to a subset
of those who currently like Lisps, which is a small minority
of programmers. Maybe a hundred or two hundred Lisp programmers
will understand what the hell happened and get really fanatical
about it, about another thousand will get it and protest by
saying "but that's totally insane!" and the vast majority,
even of LISP programmers, will go, "Huh? I don't get it."
And then there will be a half-dozen university papers and
maybe in ten years or so people will be saying it was
obvious all along and building the idea into other new
lisps, a few of which will eventually become popular.

> 3. Who will write compilers for it?

Like I care? Me, I guess. Hmmm. Actually, I think 3 or 4 of
"mad-scientist-tinkering-in-the-basement" types, like myself,
will "get it", get really fanatical about it and think it's
insanely great and just HAVE TO write their own implementation.
But that'll be it, until time mellows the strangeness of it and
people start thinking it was obvious the whole time.

> 4. There are already a lot of Lips dialects. Will your language be so
> original and powerful?

:-) Yes.

> http://en.wikipedia.org/wiki/Lisp_programming_language#Genealogy_and_variants
> 5. Have you ever tried to write your own compiler? I did. It's a really
> hard and time consuming work...

I've done it twice now. And you're right, it's hard and time-consuming.
I've got a head start on this because my last compiler was a lisp system
in the first place, and supported a lot of different macrology and mu
functions; most of the infrastructure is already in place.

Bear

Ray Dillinger

unread,
Mar 14, 2005, 1:10:51 PM3/14/05
to
ABCGi wrote:
> The Sheep wrote:
>

>> Take your chance, we're holding our thumbs for you.
>> We'reawaiting the new language with anxiety :)
>
>
> Good luck!

Thanks.

Bear

Ray Dillinger

unread,
Mar 14, 2005, 1:24:46 PM3/14/05
to
Twisted One wrote:
> Hansjoerg Malthaner wrote:
>
>> Wow! I wish you success for your new project. I, too, think current
>> languages are very restricted, yet I don't have an idea how to change
>> that. If you can, all power to you :)

Thanks, Hajo. I appreciate the good wishes.

> Adding the ability to define scoped language extensions via a grammar
> and translation rules to the original language, perhaps. Maybe the
> language should use XML, and XSLT? Then any higher level structure you
> can dream of, just about, can be created.

Nah. Lisp already had that. You'd just use the readtable with a
macro or two to implement it.

My epiphany was that functions and macros don't have to be different
things. I figured out how to make first order (code-transforming)
functions (which have up till now been macros in lisp) first-class
values in the language as well, that you can pass to or return from
functions, store in structures, call dynamically, apply, map, etc,
just like any other function.

This will eliminate some kinds of namespace conflicts, eliminate
all intermodule compile-time interdependencies, eliminate the
need for a separate defmacro form, etc, while also making
functions more fundmentally powerful by giving them control not
only of when, but how and in what environment their arguments
are evaluated.

It's like fixing a crack in the mathematical foundations of the
language. most of the "wizardly" uses of it will also be terribly
expensive in CPU, which is why I expect controversy - but it's the
first thing since lisp macros were introduced almost 45 years ago
that substantively *ADDS* capabilities that weren't already there.

Bear


Twisted One

unread,
Mar 14, 2005, 6:28:42 PM3/14/05
to
Ray Dillinger wrote:
> Nope. :-) It's a "bug-fix" to the idea of what Lisp is.

I hope it's more human-readable than the original, and people can use
their choice of text editor. ;)

Ray Dillinger

unread,
Mar 14, 2005, 8:12:20 PM3/14/05
to
Twisted One wrote:
> Ray Dillinger wrote:
>
>> Nope. :-) It's a "bug-fix" to the idea of what Lisp is.
>
>
> I hope it's more human-readable than the original, and people can use
> their choice of text editor. ;)

Sorry, still going to stick with the fully-parenthesized prefix
notation and code-data correspondence. Which is what most people
are complaining about when they say it's hard to read Lisps.

Lisp code is a direct expression of a data representation of
its own parse tree. The ability to manipulate that data using
the same language that manipulates any data is why a Lisp can
rewrite its own code. Lots of people who "don't get it" about
Lisp macros have tried to get rid of the parens, and in every
case they've sacrificed this ability; they wind up with
something like Dylan or ML, which, although cool, don't have
the fundamental metacoding abilities of a Lisp.

And it is those abilities, which depend on the code being its
own parse tree, that are what I'll be making more intense. The
parens aren't going away. In fact the reasons for them will
be getting stronger.

Bear


Twisted One

unread,
Mar 14, 2005, 9:23:24 PM3/14/05
to
Ray Dillinger wrote:
> And it is those abilities, which depend on the code being its
> own parse tree, that are what I'll be making more intense. The
> parens aren't going away. In fact the reasons for them will
> be getting stronger.

No wonder nobody uses lisp anymore, if it's not only write-only and
self-modifying, but it's supposed to stay that way, or even get worse.
:) That's the surest route to unmaintainability I know of.

Doesn't help that the only lisp environments I've seen seem to use their
own little command line environment, with no full-screen code editing or
other capabilities, so it's like using a late-70s BASIC. And, of course,
there's usually less capability than ANSI C, which was designed with
text terminal systems in mind making programming portable graphical
apps, network apps etc. nigh-impossible. At least with pointers and
other low level features programming *non-portable* graphical apps in C
is possible. LISP, however...

MSCHAEF.COM

unread,
Mar 14, 2005, 9:30:03 PM3/14/05
to
In article <OFkZd.10726$m31.1...@typhoon.sonic.net>,
Ray Dillinger <be...@sonic.net> wrote:
...

>My epiphany was that functions and macros don't have to be different
>things. I figured out how to make first order (code-transforming)
>functions (which have up till now been macros in lisp) first-class
>values in the language as well, that you can pass to or return from
>functions, store in structures, call dynamically, apply, map, etc,
>just like any other function.

Have you seen this:

http://www.linearity.org/bawden/mtt/

-Mike
--
http://www.mschaef.com

Martin Read

unread,
Mar 15, 2005, 3:52:58 AM3/15/05
to
twist...@gmail.invalid wrote:
>Doesn't help that the only lisp environments I've seen seem to use their
>own little command line environment, with no full-screen code editing or
>other capabilities, so it's like using a late-70s BASIC.

One of the two full-screen text editors at the incandescent heart of the
text editor holy wars is a lisp environment, although it implements a
somewhat crippled dialect of lisp.
--
Martin Read - my opinions are my own. share them if you wish.
My roguelike games page (including my BSD-licenced roguelike) can be found at:
http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
NP: Maruta Kommand - Mass Grave (Melek-Tha Remix)

Twisted One

unread,
Mar 15, 2005, 4:00:30 AM3/15/05
to
Martin Read wrote:
> twist...@gmail.invalid wrote:
>
>>Doesn't help that the only lisp environments I've seen seem to use their
>>own little command line environment, with no full-screen code editing or
>>other capabilities, so it's like using a late-70s BASIC.
>
> One of the two full-screen text editors at the incandescent heart of the
> text editor holy wars is a lisp environment, although it implements a
> somewhat crippled dialect of lisp.

Elisp doesn't count, since it's just being used as a scripting language,
and emacs doesn't count as a proper editor anyway, since it's not a
graphical editor with all the nice features one expects such as the
ability to select text with the mouse or to actually accomplish stuff
without ever having to hold more than 3 keys down at one time. :P

:)

Ray Dillinger

unread,
Mar 15, 2005, 8:29:36 PM3/15/05
to

Oh yeah. Been all over it. He has first-class macros, but
they're very limited. Compile-time only, not runtime, and
still not unified with functions. It's good work though.

Bear

Glen Wheeler

unread,
Mar 17, 2005, 6:46:01 AM3/17/05
to

"Twisted One" <twist...@gmail.invalid> wrote in message
news:X6WdnabAFrm...@rogers.com...

> Martin Read wrote:
>> twist...@gmail.invalid wrote:
>>
>>>Doesn't help that the only lisp environments I've seen seem to use their
>>>own little command line environment, with no full-screen code editing or
>>>other capabilities, so it's like using a late-70s BASIC.
>>
>> One of the two full-screen text editors at the incandescent heart of the
>> text editor holy wars is a lisp environment, although it implements a
>> somewhat crippled dialect of lisp.
>
> Elisp doesn't count, since it's just being used as a scripting language,
> and emacs doesn't count as a proper editor anyway, since it's not a
> graphical editor with all the nice features one expects such as the
> ability to select text with the mouse or to actually accomplish stuff
> without ever having to hold more than 3 keys down at one time. :P
>
> :)
>

So says you. I say you don't know how to use emacs if that is the case.
Both the aforementioned editors have many more abilities than most graphical
utilities.

--
Glen
L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+


Twisted One

unread,
Mar 17, 2005, 7:01:46 AM3/17/05
to
Glen Wheeler wrote:
> So says you. I say you don't know how to use emacs if that is the case.
> Both the aforementioned editors have many more abilities than most graphical
> utilities.

Yeah but you can't see what you can do at a glance, there's no online
help in hypertext format in a separate window, and more generally you
can't just sit down at it and bang away and be productive in almost no
time, the way you can with a *real* graphical editor.

David Damerell

unread,
Mar 17, 2005, 11:24:39 AM3/17/05
to
Quoting Twisted One <twist...@gmail.invalid>:
>Glen Wheeler wrote:
>>So says you. I say you don't know how to use emacs if that is the case.
>>Both the aforementioned editors have many more abilities than most graphical
>>utilities.
>Yeah but you can't see what you can do at a glance, there's no online
>help in hypertext format in a separate window,

No. There's help in the _same_ window, conveniently divided into two parts
so you may continue to read it while looking at what you are doing.

> and more generally you
>can't just sit down at it and bang away and be productive in almost no
>time, the way you can with a *real* graphical editor.

Unfortunately, ease of initial approach often seems to work against
ultimate power, and that is certainly the case here.
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is First Gouday, March.

Twisted One

unread,
Mar 17, 2005, 12:05:20 PM3/17/05
to
David Damerell wrote:
>>Yeah but you can't see what you can do at a glance, there's no online
>>help in hypertext format in a separate window,
>
> No. There's help in the _same_ window, conveniently divided into two parts
> so you may continue to read it while looking at what you are doing.

Only now you have to look at both of them through keyholes, about 50
characters wide and five high. That's a lot of fun. No hyperlinks, and
nothing like normal window pane behavior (e.g. control-tab to switch
panes, click in a pane to switch to it, arrow key navigation, etc.) adds
to the fun. It's much quicker to alt-tab to a separate window and have
both maximized IMO.

A major part of the problem with apps like emacs is that they use legacy
UIs and bindings instead of industry standard ones. It's like learning a
whole new operating system just to learn one app. And with a bunch of
unix-heritage apps, it's like learning a whole new operating system for
each and every one of them, because unlike all Windows programs, all
Unix programs don't use standard bindings and UI metaphors for standard
actions. If two Windows apps both have a particular feature or function,
you can bet unless it's rather esoteric or the resemblance is
superficial, they are achievable using the same inputs. If two unix apps
have a particular feature or function, you can bet they go to great
lengths to make the user accomplish this one task as differently as
possible in the two apps, and force them to use both hands, their nose,
and their tongue holding down keys in at least one of them.

> Unfortunately, ease of initial approach often seems to work against
> ultimate power, and that is certainly the case here.

It doesn't have to. Basic functionality can be done in a standardized
way while still having advanced functionality.

David Damerell

unread,
Mar 17, 2005, 12:33:02 PM3/17/05
to
Quoting Twisted One <twist...@gmail.invalid>:
>David Damerell wrote:
>>>Yeah but you can't see what you can do at a glance, there's no online
>>>help in hypertext format in a separate window,
>>No. There's help in the _same_ window, conveniently divided into two parts
>>so you may continue to read it while looking at what you are doing.
>Only now you have to look at both of them through keyholes, about 50
>characters wide and five high.

If by that you mean 80x40 or so, yes. The editor can use as much of your
screen real estate as you like. What it doesn't do (although one could
make it do so) is demand varying amounts of it based on what it is doing,
which is a recipe for Windows-style annoyance where you are never able to
see everything you are doing at once.

>to the fun. It's much quicker to alt-tab to a separate window and have
>both maximized IMO.

That's completely braindead. You can't even see what you are doing at the
same time as reading the documentation!

>>Unfortunately, ease of initial approach often seems to work against
>>ultimate power, and that is certainly the case here.
>It doesn't have to.

It doesn't have to be that way, maybe, but it _is_ that way. If you choose
an editor that is initially easy to learn it will never be as good as
Emacs in the hands of an expert - or as lightning fast for simple editing
as vi in the hands of an expert.

Twisted One

unread,
Mar 17, 2005, 1:34:29 PM3/17/05
to
David Damerell wrote:
> If by that you mean 80x40 or so, yes.

How do you get that from dividing 80x25 into two panes?!

> It doesn't have to be that way, maybe, but it _is_ that way. If you choose
> an editor that is initially easy to learn it will never be as good as
> Emacs in the hands of an expert - or as lightning fast for simple editing
> as vi in the hands of an expert.

Lightning fast? Are you mad? Spending 1/4 of your time attempting to
actually perform your main task and 3/4 attempting to navigate
documentation in an arcane interface with no hyperlinking isn't my idea
of "lightning fast" -- or "fun", for that matter. I'd rather get some
actual work done than spend literally days attempting to grok what
amounts to an entire new operating system.

The Sheep

unread,
Mar 17, 2005, 2:47:59 PM3/17/05
to
Dnia Thu, 17 Mar 2005 13:34:29 -0500,
Twisted One napisal(a):

> David Damerell wrote:

>> It doesn't have to be that way, maybe, but it _is_ that way. If you choose
>> an editor that is initially easy to learn it will never be as good as
>> Emacs in the hands of an expert - or as lightning fast for simple editing
>> as vi in the hands of an expert.
>
> Lightning fast? Are you mad? Spending 1/4 of your time attempting to
> actually perform your main task and 3/4 attempting to navigate
> documentation in an arcane interface with no hyperlinking isn't my idea
> of "lightning fast" -- or "fun", for that matter. I'd rather get some
> actual work done than spend literally days attempting to grok what
> amounts to an entire new operating system.

Note the word `expert' used here, which clearly indicates a person who
already knows how to use thosepowerful tools and thus doesn't have to
navigate any documentation.

By the way, I find the vim's online help very comfortable and easy to
use. And pretty complete.

Twisted One

unread,
Mar 17, 2005, 4:09:42 PM3/17/05
to
The Sheep wrote:
> Note the word `expert' used here, which clearly indicates a person who
> already knows how to use thosepowerful tools and thus doesn't have to
> navigate any documentation.

The problem being you can't *become* an expert, at least not via the
normal, painless route of using it for basic stuff and then slowly
adding more complex stuff to your repertoire. Like a lot of
unix-associated stuff, it lacks a shallow end.

The Sheep

unread,
Mar 17, 2005, 4:36:45 PM3/17/05
to
Dnia Thu, 17 Mar 2005 16:09:42 -0500,
Twisted One napisal(a):

> The Sheep wrote:
>> Note the word `expert' used here, which clearly indicates a person who
>> already knows how to use thosepowerful tools and thus doesn't have to
>> navigate any documentation.

> The problem being you can't *become* an expert, at least not via the
> normal, painless route of using it for basic stuff and then slowly
> adding more complex stuff to your repertoire. Like a lot of
> unix-associated stuff, it lacks a shallow end.

I wonder where those experts are popping from then. Alternative
dimensions, probably.

Be warned that it's for people who want (and can) learn new things.
If you start with this kind of attitude (I don't like it but I have to
learn it), then you can give it up. It's kind of... you've got to love
your editor ;)

Twisted One

unread,
Mar 17, 2005, 4:59:44 PM3/17/05
to
The Sheep wrote:
> Be warned that it's for people who want (and can) learn new things.
> If you start with this kind of attitude (I don't like it but I have to
> learn it), then you can give it up. It's kind of... you've got to love
> your editor ;)

Where I come from, you get to know someone *first*; *then* maybe you
fall in love. I guess in your country it's the reverse? You fall in
love, and then you get to know whoever it is you love? :P

Erik Hesselink

unread,
Mar 17, 2005, 5:38:34 PM3/17/05
to
Twisted One wrote:
> The Sheep wrote:
>
>> Be warned that it's for people who want (and can) learn new things.
>> If you start with this kind of attitude (I don't like it but I have to
>> learn it), then you can give it up. It's kind of... you've got to love
>> your editor ;)
>
> Where I come from, you get to know someone *first*; *then* maybe you
> fall in love. I guess in your country it's the reverse? You fall in
> love, and then you get to know whoever it is you love? :P

Ever hear of love at first sight? ;) And you know, it is possible to
learn vim through use. Once you learn four commands, 'i' to enter insert
mode and 'ESC' to leave it, plus ':w' and ':q' to save and quit, you can
use it for simple editing. Then, once you find something you think could
be easier with a different command, the command almost always exists.
Look it up in the reference, and voila, another command learned.

Erik

Twisted One

unread,
Mar 17, 2005, 5:47:43 PM3/17/05
to
Erik Hesselink wrote:
> Ever hear of love at first sight? ;) And you know, it is possible to
> learn vim through use.

Really. I ran into it once. Opened it and attempted to type something
in, and it went nuts. An editor you don't edit by typing into is
definitely not the most perverse thing I've ever encountered, but it
ranks up there with such gems as the 2000 Florida election, the Catholic
concept of "transubstantiation", and the whole phenomeonon of Bobbit
jokes...

Point, click, type is the most basic imaginable functionality for an
editor. If something as cheap and shitty as MS Notepad can get *that*
much right, why can't the unix whizzes? I've never seen an open source
editor where the most basic editing tasks were as easy. The only thing I
can think of is that Microsoft has a software patent for "editing by
simply typing in what you want to type in" and they're afraid of running
afoul of it. ("A paint program whose user interface a normal human being
can actually navigate with both hands and a map" being the gist of an
Adobe patent probably likewise explains the perverstrosity that is the
GIMP's UI.)

> Look it up in the reference, and viola...

Why do I get the feeling that that seemingly simple and innocuous
phrase, "look it up in the reference", involves a whole new layer of
heretofore unimagined perversity accompanied by exquisite pain,
insomnia, and cerebral hemmorhage? :)

At the very least, I suspect it's not as simple as "hit F1 and navigate
with arrow and enter keys some hypertext", let alone "hit F1 and
navigate some hypertext with the FUCKING MOUSE" ... :) I'll bet there's
also a search capability, but there's no handy "Help" menu with a
"Search..." item, or any other advertisement that this exists or how to
get to it, and it doesn't work by simply typing a word or three into a
box and hitting enter. At a bare minimum, I'd expect a unix app to
expect me to learn a whole new programming language just to search its
online documentation, and undoubtedly it will differ idiosyncratically
from every other unix app and from every windows app in regards to
searching the help as well. A separate programming language for every
app's help would be about right for the typical unix environment
learning curve. There's a definite pattern of active newbie-hostility to
most unix associated things after all. Plus a generous helping of the
"not invented here" syndrome to ensure that although everything on the
machine interoperates in some technical sense, none of it actually does
anything in one standard way, however basic, so there's one key
component none of it interoperates well with -- THE USER! :)

Jeff Lait

unread,
Mar 17, 2005, 8:30:01 PM3/17/05
to

Erik Hesselink wrote:
> Twisted One wrote:
> > The Sheep wrote:
> >
> >> Be warned that it's for people who want (and can) learn new
things.
> >> If you start with this kind of attitude (I don't like it but I
have to
> >> learn it), then you can give it up. It's kind of... you've got to
love
> >> your editor ;)
> >
> > Where I come from, you get to know someone *first*; *then* maybe
you
> > fall in love. I guess in your country it's the reverse? You fall in

> > love, and then you get to know whoever it is you love? :P

Where I come from, you get to know someone *first*; then maybe you
learn to hate them. If you are willing to give vi a fair chance, it
can sink its claws into you. At a minimum, you could come up with a
less superficial reason for your dislike than: "It has a different
paradigm for text editting than I'm used to!" If all text editors used
the same approach to editting text, we wouldn't need more than one
editor, would we? Do you write code in Word? I've tried, but the
auto-capitalization of 'i' drives me nuts.

> Ever hear of love at first sight? ;) And you know, it is possible to
> learn vim through use. Once you learn four commands, 'i' to enter
insert
> mode and 'ESC' to leave it, plus ':w' and ':q' to save and quit, you
can
> use it for simple editing. Then, once you find something you think
could
> be easier with a different command, the command almost always exists.

> Look it up in the reference, and voila, another command learned.

I didn't love vi at first sight. My first exposure was when I was
given this horridly complicated sheet of paper which neatly summarized
every possible vi command and somehow neglected to tell you how to save
things.

At some point, however, I decided to give it a good try. This time I
learned the practical approach - learn the four needed commands
(though, for some reason I always have used :x for write & quit rather
than :wq) and expand from there. Haven't wanted to look back.

To me, vi's strength is very apparent if you are editting over a
high-latency connection. With most editors you spend half your time
cursoring, with vi, you describe where you want to go and make your
change, so do not require as much feedback from the other end. If
you've ever tried to edit something with 2-3 second latency on key
presses, you'll know what I mean :>

On the other hand, I have never been a mouse person. In DOS days, my
mouse was trapped in a drawer by my computer and only extricated when
necessary. Nowadays it's primary use is to select which window I will
type in by the simple expedient of bludgeoning it into the correct
pane. I have seen skilled mouse users edit text very efficiently. It
always sort of surprises me - I guess probably for the same reason that
they'd doubt that one could edit text without a mouse to do the cursor
positioning.

Mind you, I'm not one to complain about people refusing to try new
things. My ideal desktop layout, two 80x50 consoles beside each other,
each running seperate editors split vetically once, has remained
unchanged since I discovered it when using OS/2 Warp.

I recently altered my colour scheme as it was a bit dark on my laptop,
so I do admit a small modicum of change... (Forest green title bars
with the active window border being red. The one true colour scheme!)
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)

Max Bolingbroke

unread,
Mar 18, 2005, 2:16:55 AM3/18/05
to
Twisted One wrote:

> Erik Hesselink wrote:
> Point, click, type is the most basic imaginable functionality for an editor. If something as cheap and shitty as MS Notepad can >get *that* much right, why can't the unix whizzes? I've never seen an
open source editor where the most basic editing tasks were
> as easy

Might I reccomend the "nano" editor? You can type straight into it, and
the key shortcuts for common commands are accessed with Ctrl and
displayed at the bottom of the screen. This includes a Help command, so
you can find out about the others at any time.

Max Bolingbroke

Twisted One

unread,
Mar 18, 2005, 3:06:10 AM3/18/05
to
Max Bolingbroke wrote:
> Might I reccomend the "nano" editor? You can type straight into it, and
> the key shortcuts for common commands are accessed with Ctrl and
> displayed at the bottom of the screen. This includes a Help command, so
> you can find out about the others at any time.

Does it have a modern GUI? (Let me guess: no, since a modern GUI puts
menus with shortcut key info at the *top* of the *window*, not the
*bottom* of the *screen*.)

Twisted One

unread,
Mar 18, 2005, 3:05:11 AM3/18/05
to
Jeff Lait wrote:
> To me, vi's strength is very apparent if you are editting over a
> high-latency connection. With most editors you spend half your time
> cursoring, with vi, you describe where you want to go and make your
> change, so do not require as much feedback from the other end. If
> you've ever tried to edit something with 2-3 second latency on key
> presses, you'll know what I mean :>

In other words, it was designed for the 1970s dumb terminals-smart
mainframes paradigm of computing; not optimized for a modern setup where
a developer has a box by his knee containing the equivalent of three
1970s supercomputers, and a full graphical interface in front of him.

> I recently altered my colour scheme as it was a bit dark on my laptop,
> so I do admit a small modicum of change... (Forest green title bars
> with the active window border being red. The one true colour scheme!)

Uh, d00d, christmas was three months ago, and it's the only permissible
excuse for such a clashing color scheme. In fact, in some jurisdictions,
your color scheme could get you fined up to $50,000 and imprisoned up to
six months.

The Sheep

unread,
Mar 18, 2005, 3:42:15 AM3/18/05
to
Dnia Fri, 18 Mar 2005 03:06:10 -0500,
Twisted One napisal(a):

> Max Bolingbroke wrote:
>> Might I reccomend the "nano" editor? You can type straight into it, and
>> the key shortcuts for common commands are accessed with Ctrl and
>> displayed at the bottom of the screen. This includes a Help command, so
>> you can find out about the others at any time.

Hey, it looks a lot like pico and pine's internal editor ;)

> Does it have a modern GUI? (Let me guess: no, since a modern GUI puts
> menus with shortcut key info at the *top* of the *window*, not the
> *bottom* of the *screen*.)

...

>In other words, it was designed for the 1970s dumb terminals-smart
>mainframes paradigm of computing; not optimized for a modern setup where
>a developer has a box by his knee containing the equivalent of three
>1970s supercomputers, and a full graphical interface in front of him.
>
>> I recently altered my colour scheme as it was a bit dark on my laptop,
>> so I do admit a small modicum of change... (Forest green title bars
>> with the active window border being red. The one true colour scheme!)
>
>Uh, d00d, christmas was three months ago, and it's the only permissible
>excuse for such a clashing color scheme. In fact, in some jurisdictions,
>your color scheme could get you fined up to $50,000 and imprisoned up to
>six months.

I see you've got a very strong idea how a `modern' interface looks like.
Wonder where you learned that.

Now think about how `proffessional' interface should look like and whether
it should be `modern'.

Note also, that there are lots of simple editors, with GUI you describe.
In fact, it takes about 5 lines of code to write one using gnome.

Jeff Lait

unread,
Mar 18, 2005, 4:24:20 AM3/18/05
to

Inquiring minds want to know. Do you plan on contributing to this
group at some point? Or are you just here to pick fights?

Twisted One

unread,
Mar 18, 2005, 4:45:41 AM3/18/05
to
The Sheep wrote:
> Now think about how `proffessional' interface should look like and whether
> it should be `modern'.

Any app should have a "shallow end" and a "deep end", not only one or
the other. This is something people in the endless
editor/gui/userfriendliness wars don't seem to get, in their constant
battles over whether shallow apps are better or deep ones. Apps with
sloping learning curves are better.

Also, there seems to be this perception that you're "pandering to the
lowest common denominator" or some such if you don't make your user
interface arcane and as different as possible from everyone else's, and
heaven help you if basic tasks are actually accomplished in the *same
way as another app in the same genre*! This seems to come from a sort of
geek machismo or even elitism -- since rocket science is cool, it should
take rocket science to type and save a short letter or do some quick and
dirty code hacking and not just to fly to the Moon, or worse, the UI
should separate the n00bs from the Real Geeks(tm) or even actively
discourage participation by the Uninitiated.

I hold no truck with this sort of elitism. When it comes to software and
user interface design I'm a populist the whole way. Basic functionality
should be basic to use, and standard stuff should be done in a standard
way across applications. The defacto standard most people have prior
experience with being Windows and very similar GUI systems, this is the
UI paradigm that should be followed, even if there are advanced features
that take more effort to learn and use their own paradigms. Somehow
there's this perception that providing a GUI and standard ways of
getting basic tasks accomplished somehow prevents the inclusion in your
software of an "Advanced" menu, a Preferences dialog with an "Advanced"
tab, some underlying scripting system, or what-have-you. This is
emphatically not the case. There's no reason you can't even retrofit a
legacy UI with a bolt-on Windows interface. Actually I've seen this
done, but it's usually done badly. It can be done well, if all basic
stuff can be done by typical methods Windows users use across apps. All
it requires is a translation layer between the GUI and the underlying,
legacy UI, as well as advanced options to enable the user to directly
access the legacy UI. (Documentation in a modern, standard format such
as HTML, with proper hyperlinks and browseable by the user's choice of
methods and in a separate window if the user so chooses is good too.)

The Sheep

unread,
Mar 18, 2005, 5:26:39 AM3/18/05
to
Dnia Fri, 18 Mar 2005 04:45:41 -0500,
Twisted One napisal(a):

> Also, there seems to be this perception that you're "pandering to the
> lowest common denominator" or some such if you don't make your user
> interface arcane and as different as possible from everyone else's, and
> heaven help you if basic tasks are actually accomplished in the *same
> way as another app in the same genre*! This seems to come from a sort of
> geek machismo or even elitism -- since rocket science is cool, it should
> take rocket science to type and save a short letter or do some quick and
> dirty code hacking and not just to fly to the Moon, or worse, the UI
> should separate the n00bs from the Real Geeks(tm) or even actively
> discourage participation by the Uninitiated.

> I hold no truck with this sort of elitism. When it comes to software and
> user interface design I'm a populist the whole way. Basic functionality
> should be basic to use, and standard stuff should be done in a standard
> way across applications. The defacto standard most people have prior
> experience with being Windows and very similar GUI systems, this is the
> UI paradigm that should be followed, even if there are advanced features
> that take more effort to learn and use their own paradigms.

vi has set it's standards long time before Windows even existed.
Even rogue inherits some of them -- they are really standard standards.
Why should it change it's UI to comply to some new, silly and totally
unintuitive interface (my favorite is a combination of ctrl+a space,
which I usually use to switch between screens, and which will replace
whole text I just type with a space in your `modern' editors).

I refuse to cripple my editor this way.

People who's first editor is vi (or any editor with similar interface,
there are whole lots of them) has absolutely no problem with them.
However they have lots of problems while using `windows' editors.

Just allow people to use the editor they like.

Martin Read

unread,
Mar 18, 2005, 5:52:04 AM3/18/05
to
twist...@gmail.invalid wrote:
>The Sheep wrote:
>> Note the word `expert' used here, which clearly indicates a person who
>> already knows how to use thosepowerful tools and thus doesn't have to
>> navigate any documentation.
>
>The problem being you can't *become* an expert, at least not via the
>normal, painless route of using it for basic stuff

This turns out not to be the case, Neo; I know quite a large number of
people who learned to use vi and/or emacs in precisely that way.

Maybe the bug is in you.

Martin Read

unread,
Mar 18, 2005, 5:48:32 AM3/18/05
to
twist...@gmail.invalid wrote:
>David Damerell wrote:
>> If by that you mean 80x40 or so, yes.
>
>How do you get that from dividing 80x25 into two panes?!

I don't use 80x25 terminals (except when I'm playing roguelikes in a
Linux console window rather than starting up X, or when I'm talking to
the CompactPCI single-board computers next to me at work). I use 80x55
terminals at home and 80x50 terminals at work; if my display was larger,
I'd use even larger terminals.

David, I'd guess, uses 80x80 terminals.

>> It doesn't have to be that way, maybe, but it _is_ that way. If you choose
>> an editor that is initially easy to learn it will never be as good as
>> Emacs in the hands of an expert - or as lightning fast for simple editing
>> as vi in the hands of an expert.
>
>Lightning fast? Are you mad? Spending 1/4 of your time attempting to
>actually perform your main task and 3/4 attempting to navigate
>documentation in an arcane interface with no hyperlinking isn't my idea
>of "lightning fast" -- or "fun", for that matter. I'd rather get some
>actual work done than spend literally days attempting to grok what
>amounts to an entire new operating system.

I don't like emacs very much as a text editor; if I wanted to put in
bizarre sequences of combined presses to do not-terribly-complex things,
I'd turn on my PS2 and play Mortal Kombat. But, people who do like
emacs as a text editor can do utterly terrifyingly complex things quite
easily with it.

I do like vim, and I'm very good at using it, and it has the glorious
merit that I never have to take my hands off the main part of my
keyboard.

David Damerell

unread,
Mar 18, 2005, 9:07:35 AM3/18/05
to
Quoting Twisted One <twist...@gmail.invalid>:
>David Damerell wrote:
>>If by that you mean 80x40 or so, yes.
>How do you get that from dividing 80x25 into two panes?!

I don't. Why do I have to use 80x25?

Of course, unlike an editor surrounded by GUI junk, if I have better uses
for my screen real estate, I _can_ practically run Emacs in an 80x25
window.

>>Emacs in the hands of an expert - or as lightning fast for simple editing
>>as vi in the hands of an expert.
>Lightning fast? Are you mad? Spending 1/4 of your time attempting to
>actually perform your main task and 3/4 attempting to navigate
>documentation

An expert. An expert vi user is phenomenally quick; I'm pretty quick with
it myself, but I've seen guys do what would seem like moderately complex
tasks in less time than it would take to move your hand to the mouse and
start your fancy GUI editor.
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is First Chedday, March - a public holiday.

David Damerell

unread,
Mar 18, 2005, 9:10:35 AM3/18/05
to
Quoting Twisted One <twist...@gmail.invalid>:
>Any app should have a "shallow end" and a "deep end", not only one or
>the other.

This is true, but it isn't a choice you have at the moment. You can
either use a powerful editor or one which is easy to learn. Deal.

Also, sometimes, it's not as simple of that. Much of vi's power for
experts stems directly from the way that there _are_ insert commands
(contrary to popular belief, thinking of "insert mode" is not ultimately
helpful), and that does produce the result that you can't just start it
and type into it.

Hansjoerg Malthaner

unread,
Mar 18, 2005, 9:17:43 AM3/18/05
to
David Damerell wrote::

> Quoting Twisted One <twist...@gmail.invalid>:
>
>>David Damerell wrote:

>>>Emacs in the hands of an expert - or as lightning fast for simple editing
>>>as vi in the hands of an expert.
>>
>>Lightning fast? Are you mad? Spending 1/4 of your time attempting to
>>actually perform your main task and 3/4 attempting to navigate
>>documentation
>
> An expert. An expert vi user is phenomenally quick; I'm pretty quick with
> it myself, but I've seen guys do what would seem like moderately complex
> tasks in less time than it would take to move your hand to the mouse and
> start your fancy GUI editor.

I want to second that. I'm just a beginner, but vi is ok even for me,
and I know a few people - senior programmers and sysadmins - who can
work magic with it.

--
c.u. Hajo

Ray Dillinger

unread,
Mar 18, 2005, 11:53:12 AM3/18/05
to
Twisted One wrote:

> Also, there seems to be this perception that you're "pandering to the
> lowest common denominator" or some such if you don't make your user
> interface arcane and as different as possible from everyone else's, and
> heaven help you if basic tasks are actually accomplished in the *same
> way as another app in the same genre*! This seems to come from a sort of
> geek machismo or even elitism -- since rocket science is cool, it should
> take rocket science to type and save a short letter or do some quick and
> dirty code hacking and not just to fly to the Moon, or worse, the UI
> should separate the n00bs from the Real Geeks(tm) or even actively
> discourage participation by the Uninitiated.

Dude, forgive me for saying this, but this is sounding more and more
like you have some unresolved issues with something here. Learning
a new app just isn't that big a deal. Why you've blown it up into one
in your mind I don't know. But if you want something with a GUI that
works in a way "familiar" to you, you can use Kwrite or something.
This stuff does exist for unix/linux; but it's not as if anybody
who uses unix/linux cares that much about it.

> I hold no truck with this sort of elitism.

It's okay, you don't have to. It will go on existing whether you
hold truck with it or not. If you want to kill emacs, you have
to write something that's better. And I mean better in the eyes
of the people now using emacs. No amount of diatribing about
it will do squat if you don't write something better.

> When it comes to software and
> user interface design I'm a populist the whole way.

Then do what everybody else who uses Unix does: Use software
designed the way you like it. There's enough. Some stuff
you don't like happens to be popular with other Unix users.
But that's no big deal, you don't have to use it. Popularity
just doesn't count in whether something is good or not.

Bear

konijn_

unread,
Mar 18, 2005, 12:25:42 PM3/18/05
to

I dont get it, is this is a hidden joke on windows software, or are
there 'text editing domain' specific shortcuts ? If it's just stuff
like regexp ( does vi/emacs have that ? ) or go-line; regular editors
like EditPlus have that as well.

No bashing, just curious and not willing to do man vi ;)

T.

> c.u. Hajo

David Damerell

unread,
Mar 18, 2005, 2:11:55 PM3/18/05
to
Quoting konijn_ <kon...@gmail.com>:
>I dont get it, is this is a hidden joke on windows software, or are
>there 'text editing domain' specific shortcuts ? If it's just stuff
>like regexp ( does vi/emacs have that ? ) or go-line; regular editors
>like EditPlus have that as well.

Does Emacs have regular expressions? That's a new one on me - a bit like
asking if IBM have ever built a computer.

One example of how vi is very quick is that the commands are highly
orthogonal. For example, any command that acts on a block of text will
accept any cursor movement command as an argument; and there are lots of
cursor movement commands.

Slash

unread,
Mar 18, 2005, 5:07:45 PM3/18/05
to

Yesterday I had a Profound Idea.

One of those ideas that comes along maybe sixty or seventy times in a
lifetime, if you're tired and work a lot on programming languages and
systems.

As a consequence of this Profound Idea, I think I know a way to do what
I have not been able to do for three years - make a vacation trip for a
week fundamentally more relaxing than any other trip which has ever
existed, but which also lets me have enough fun for a while.

Therefore I will be spending the next week tinkering with fundamentals
deep inside the heart of a beach.

The roguelike game I've worked on, currently about half-finished, goes
on a back burner, and I will probably quit reading here in a day. I'll
be back in about one week or two from now when I have a refreshed mind
ready to finish all my projects.


--
Slash
"I am removing Slashing Dragon and X-Dimensional Dragon from the roster.
This is supposed to be a fan club about a game devoted to virtues, not a
place to cause strife and turmoil. We don't like trolls."

Jeff Lait

unread,
Mar 18, 2005, 7:53:27 PM3/18/05
to
konijn_ wrote:
> Hansjoerg Malthaner wrote:
> > David Damerell wrote::
> > > An expert. An expert vi user is phenomenally quick; I'm pretty
> quick with
> > > it myself, but I've seen guys do what would seem like moderately
> complex
> > > tasks in less time than it would take to move your hand to the
> mouse and
> > > start your fancy GUI editor.
> >
> > I want to second that. I'm just a beginner, but vi is ok even for
me,
> > and I know a few people - senior programmers and sysadmins - who
can
> > work magic with it.
>
> I dont get it, is this is a hidden joke on windows software, or are
> there 'text editing domain' specific shortcuts ? If it's just stuff
> like regexp ( does vi/emacs have that ? ) or go-line; regular editors
> like EditPlus have that as well.
>
> No bashing, just curious and not willing to do man vi ;)

A man vi won't help you very much :>

First, vi is a modal editor. You are either in "command mode" or
"insert mode". The second mode is what people are used to in editors -
typing normal keys types them. The first is what confuses new users,
as regular keys are all special commands.

This means if you don't like having to hold down multiple keys to do
something, vi is for you. The keys for editting are the same as for
typing.

Second, vi's commanda are very orthogonal. They almost all take a
count and a destination. The destination can be any movement command.

Let's look at some examples...

For cursor movement, consider a quick list of commands:
$ - Move to end of line
^ - Start of line
% - Move to matching brace
w - Move to start of next word
[return] - Move down a line
[space] - Move forward a space

Some take extra arguments.
fa - Move to the next occurance of a on this line
/foo - Move to the next occurance of foo in the file
n - Repeat the last / command.

Each of these can take a count in front of them. We then have
5w - Move to start of fifth word from here
10[return] - Move down 10 lines
6fa - Move to 6th a on this line.

Now let us consider a command that does something. 'd' is the
delete-to command. As such, it takes one argument which is where to
delete to. This can be almost any movement command!

d$ - Delete to end of line
d[space] - Delete next character
d% - Delete this block of the program.
dw - Delete word
dfa - Delete up to and including the next a on this line

There is a convention that repeating the command means to apply to the
entirety of the current line:
dd - Delete this line.

Note that both the delete command, and the movement part of it can take
counts:
2dfa - Delete up to and including the next a, but do this twice.
d2fa - Delete up to and including the second a

The neat things about this 'd' command, and indeed, all the delete
commands, is that the text isn't discarded. Instead, it is put into a
buffer. The last thing deleted (or yanked with the 'y' command, that
acts like 'd' but doesn't delete the text) can be retrieved with the
'p' command. Each of the examples above can have 'd' changed with 'y'
and become a yank-to command. Or with 'c' and become a change-to
command.

To cut and paste one line is thus: ddp
To copy and paste one line is: yyp

Another deletion command is 'x' which is delete-this-character. An
example of the synergy of vis command set can be seen with this. Say I
have a tyop where I have reversed two letters.

If I move over the 'o' in the tyop, and type "xp", I will delete the o
and then put it back after the p, switching the two letters. While
there is no command "Swap two letters beside each other" in the vi
bindings that I know of, such a command can be fashioned trivially.

Twisted One

unread,
Mar 19, 2005, 12:31:39 AM3/19/05
to
Jeff Lait wrote:
> For cursor movement, consider a quick list of commands:
> $ - Move to end of line
> ^ - Start of line
> % - Move to matching brace
> w - Move to start of next word
> [return] - Move down a line
> [space] - Move forward a space

So far it's got nothing on GUI editors save that it might be slightly
easier to use on a chicklet keyboard on a laptop that doesn't have HOME,
END, DOWNARROW, RIGHTARROW and similar keys. Aside from matching brace
and start of next word, which are, respectively, provincial to a
specific programming language family (e.g. useless if you're writing
text, or HTML, or Python code) and ambiguous. (What is a "word"?
White-space-delimited? Punctuation? Will it consider "3.14159" to be one
word or two, due to the period? Unless your idea of "words" exactly fits
the software author's, you'll be fighting this feature or simply
avoiding it rather than simply using it. Microsoft's editors keep
capitalizing an isolated letter 'i', which is a pain if you're writing
mathematics; its assumption that you're writing grammatical English /and
nothing else/ make this feature one you may end up fighting or, if you
can find out how, turning off.)

> d$ - Delete to end of line

In most windows editors, with no selection initially, SHIFT+END, DEL.
Still two keypresses. And the same two work in Thunderbird's compose
window, in Notepad, in Word, in Wordpad, in Pegasus mail's compose
window, in XNews's compose window, in a text input box in an IE window
where you're posting to a Webboard, in a text input box in a Firefox
window where you're posting to a Webboard, and so on.

Guess where "d$" does this? In vi. And *nowhere else*.

If all you ever do is text editing local files on your hard drive, then
maybe vi is for you. If you ever post to web forums, send email, post to
Usenet (which you, specifically, the poster I'm following up to,
obviously do do), or do much of anything else, then vi is different and
strange. If you use a large number of different apps to do numerous
different tasks of many different kinds, then having most apps do most
things in a standard way is far, far superior to having to learn a
separate idiosyncratic interface for every last one of them. As far as a
"modern" person who grew up with GUI workstations is concerned, learning
basic tasks like text editing/selection basics, interface and help
navigation, and so forth is part of learning the *operating system*, and
normally only needs to be done once to become productive with a huge
number of apps; with each app all that must additionally be learned is
stuff specific to that app's task domain, and mainly only to the extent
that it doesn't overlap with any other. Coding therefore boils down to
learning the language and compiler; text editing you have for free, and
a decent IDE will respect the usual text editing idioms such as
SHIFT+END, DELETE to delete to the end of the line. If of course you
don't prefer just using Notepad and compiling from a command prompt.

The unix world however effectively has a n00b learn a whole new
operating system to edit text in vi; another to edit code in some IDE;
another to compose mail; another to compose news; another to browse vi's
documentation; another to browse the IDE's documentation; another to
browse the mail app's documentation; another to browse the newsreader's
documentation; and another to set up the network connection and hardware
so that the mail app and newsreader actually work. And of course, if you
decide you prefer emacs, then you have to learn another operating
system, and a programming language (elisp), and ...

Need I go on?

The user must relearn some things separately for every app, which slows
down new-user productivity drastically, and knocks them all the way back
to square one if they start using a different app.

Familiar with Notepad, unfamiliar with Word -> productive with Word in
minutes. Later want to switch to WordPerfect -> productive with
WordPerfect in minutes. If you learned Word advanced features, many of
them will work sufficiently similarly in WordPerfect that you can be
more productive in WordPerfect in one hour with prior knowledge of Word
and Notepad than with prior knowledge of only Notepad.

Familiar with vi, unfamiliar with emacs -> productive with emacs exactly
as soon as if you had never heard of a computer before last week.
Familiar with both, unfamiliar with OpenOffice -> productive with
OpenOffice sometime next month.

Learn how to navigate Notepad's help, and you can navigate Word's,
WordPerfect's, photoshop's, the network setup wizard's, Thunderbird's,
Firefox's, IE's, Outlook's, XNews's, and so on. Learn how to navigate
vi's help, and you can navigate vi's help. Learn how to navigate emacs'
help, and now you can navigaye vi's help and emacs' help. Learn how to
navigate the gimp's help (which didn't exist the last time I had access
to a machine with the gimp installed) and now you can navigate the help
for the following: vi, emacs, and the gimp. Want to navigate the help
for the network setup now? You'll have to learn to navigate *that* help now.

The upshot: Unix can stand to learn some interoperability lessons from
Windows, as well as the other way around.

> Note that both the delete command, and the movement part of it can take
> counts:
> 2dfa - Delete up to and including the next a, but do this twice.
> d2fa - Delete up to and including the second a

These have the same effect, though. :)

> The neat things about this 'd' command, and indeed, all the delete
> commands, is that the text isn't discarded. Instead, it is put into a
> buffer. The last thing deleted (or yanked with the 'y' command, that
> acts like 'd' but doesn't delete the text) can be retrieved with the
> 'p' command.

In other words, you can't delete text *without* clobbering the text in
the clipboard. Wonderful. In Notepad, SHIFT-END, DEL doesn't clobber the
clipboard. This doesn't stop you fixing it if it was a mistake: hit
CTRL+Z to Undo, rather than CTRL+V to Paste.

> If I move over the 'o' in the tyop, and type "xp", I will delete the o
> and then put it back after the p, switching the two letters. While
> there is no command "Swap two letters beside each other" in the vi
> bindings that I know of, such a command can be fashioned trivially.

And in emacs, you do it totally differently -- you make an elisp macro
and bind it to a key. And in Notepad, you see what letter it is, hit
del, right-arrow, and type the letter, or you hit shift-arrow,
control-X, right-arrow, control-V -- okay, four keypresses instead of
two, but I assume that enter command mode, "xp", exit command mode is
*at least* four keypresses in vi!

Twisted One

unread,
Mar 19, 2005, 12:33:02 AM3/19/05
to
Ray Dillinger wrote:
> Dude, forgive me for saying this, but this is sounding more and more
> like you have some unresolved issues with something here. Learning
> a new app just isn't that big a deal.

No; learning a new operating system is. And learning a new operating
system for each and every app is a REALLY big deal. It's like being
thrown back to the 1970s or something.

Graeme Dice

unread,
Mar 19, 2005, 1:09:52 AM3/19/05
to
Martin Read wrote:
> twist...@gmail.invalid wrote:
>
>>The Sheep wrote:
>>
>>>Note the word `expert' used here, which clearly indicates a person who
>>>already knows how to use thosepowerful tools and thus doesn't have to
>>>navigate any documentation.
>>
>>The problem being you can't *become* an expert, at least not via the
>>normal, painless route of using it for basic stuff
>
>
> This turns out not to be the case, Neo; I know quite a large number of
> people who learned to use vi and/or emacs in precisely that way.

If I have a text document to work on, then the vast majority of people
require that they should be able to spend less time learning the
interface than working on the document. Savings that happen down the
road don't actually matter to them.

Antoine

unread,
Mar 19, 2005, 2:35:24 AM3/19/05
to

Twisted One wrote:
> [snip]
>
> Need I go on?

No!!

Martin Read

unread,
Mar 19, 2005, 5:29:24 AM3/19/05
to
Graeme Dice <grd...@NOSPAM.sasktel.net> wrote:
>If I have a text document to work on, then the vast majority of people
>require that they should be able to spend less time learning the
>interface than working on the document. Savings that happen down the
>road don't actually matter to them.

Learning enough vi to write a document doesn't take very long at all.

Graeme Dice

unread,
Mar 19, 2005, 10:59:35 AM3/19/05
to
Martin Read wrote:
> Graeme Dice <grd...@NOSPAM.sasktel.net> wrote:
>
>>If I have a text document to work on, then the vast majority of people
>>require that they should be able to spend less time learning the
>>interface than working on the document. Savings that happen down the
>>road don't actually matter to them.
>
>
> Learning enough vi to write a document doesn't take very long at all.

Learning it well enough to make one want to use it instead of simply
loading up a standard editor certainly does.

Twisted One

unread,
Mar 19, 2005, 11:24:45 AM3/19/05
to
Graeme Dice wrote:
>> Learning enough vi to write a document doesn't take very long at all.
>
> Learning it well enough to make one want to use it instead of simply
> loading up a standard editor certainly does.

It must be like tobacco, then. The first few tries are horrible, but if
you keep at it, you become addicted?

Jim Strathmeyer

unread,
Mar 19, 2005, 4:38:07 PM3/19/05
to
Twisted One wrote:
> Hansjoerg Malthaner wrote:
>> Wow! I wish you success for your new project. I, too, think current
>> languages are very restricted, yet I don't have an idea how to change
>> that. If you can, all power to you :)
>
> Adding the ability to define scoped language extensions via a grammar
> and translation rules to the original language, perhaps. Maybe the
> language should use XML, and XSLT? Then any higher level structure you
> can dream of, just about, can be created.

You realize you just suggested XML to a Lisp programmer, right?

Glen Wheeler

unread,
Mar 19, 2005, 5:20:08 PM3/19/05
to

"Twisted One" <twist...@gmail.invalid> wrote in message
news:tIydnQWdW87...@rogers.com...

> Ray Dillinger wrote:
>> Dude, forgive me for saying this, but this is sounding more and more
>> like you have some unresolved issues with something here. Learning
>> a new app just isn't that big a deal.
>
> No; learning a new operating system is. And learning a new operating
> system for each and every app is a REALLY big deal. It's like being thrown
> back to the 1970s or something.
>

What a ridiculous statement; *every* app is learning a new OS? I haven't
seen proof of that. If you're talking about emacs, I don't personally know
much about it (except that I have tried it for a few minutes. If you're
talking about vi, Vim (gvim exists for you GUI folk) or elvis....
Unless you're computer illiterate, learning vi or vim (I don't know about
emacs) is not ``as hard as learning a new OS''. Vim is not from the 70s.
Vim has been around for 13 years; younger than windows! *gasp* If you're
serious about text editing, Vim (and perhaps elvis) are easy to learn.
There is a wonderful book about it, and many communities set up to support
the new user. I don't know how slow I would be without the smart completion
of Vim and integrated features such as :make and text markers. Ever edited
a 10,000 line file? I'd go crazy without Vim.
I've managed to get my girlfriend from word to LaTeX, using the editor
TextPad for windows. She's a history major, back at uni to write a thesis.
It was hard, but it was worth it...she swears by it now. Just like most
people who graduate to a real text editor.

--
Glen
L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+


Glen Wheeler

unread,
Mar 19, 2005, 5:22:00 PM3/19/05
to

"Graeme Dice" <grd...@NOSPAM.sasktel.net> wrote in message
news:H%X_d.725360$8l.725223@pd7tw1no...

Not really. It only takes one command that your previous editor didn't
have to make it preferable. (And there are plenty of those.)

For me, it was only a few weeks.

Graeme Dice

unread,
Mar 19, 2005, 6:31:37 PM3/19/05
to