David Hanley <·····@netright.com.delete.me.silly> wrote:
> Gee---I wonder which they'll choose.
Actually someone did that by telling them to use this brain-damaged Unix
shells. So why shouldn't they learn something different? Each
Microsoft-User learns using this Word-Shell or this Excel-Shell. What's
so big a deal about it?
_You_ may personally have misconceptions about Lisp-systems. But that
remains totally _your_ problem. You can't argue that _we_ (we as the
bunch of Lisp-users) are on the wrong track just because _you_ don't see
the benefits. You may argue that _you_ can't use Lisp for the mentioned
reasons because _you_ are unable to see the solutions to the problems.
But that isn't a fault of Lisp. It's totally yours.
BTW: It's really funny to deny Lisp any commercial value by arguing with
programs in the shell-util area. When did you last sell "cat" or "tee"
or "hello world"? But when you can sell Word or Excel, you can sell
programs written in Lisp, too. People _don't_ see executable size.
Actually only people from the C-camp argue with executable size - and
then go on and write monsters like Word or Excel.
And - as many pointed out - there are several Lisp-implementations that
make use of DLLs or shared-libraries for there runtime system.
And a last thought: when you have to build a bunch of utilities, you are
maybe better off writing them to a Lisp shell. Just put one of the many
algebraic syntaxes on top of the Lisp shell and people won't even notice
the difference. Except that the system will be much more powerfull.
bye, Georg
Georg Bauer wheezed these wise words:
> And a last thought: when you have to build a bunch of utilities, you are
> maybe better off writing them to a Lisp shell. Just put one of the many
> algebraic syntaxes on top of the Lisp shell and people won't even notice
> the difference. Except that the system will be much more powerfull.
I think that this is a cultural issue, rather than a language issue.
Lisp isn't the only language to use a listener, nor is it the only one
to be viewed with suspicion by the C bigots. Coincidence? I wonder.
A listener gives you a loosely structured interface, which is ideal
for programmers and power users. Perhaps this is why it's not so
popular with some people? Could it be that most users prefer a tightly
structured interface? Such an interface may be simpler and easier to
learn for many people. If these are the people who use the software,
and/or who pay for it, then this is what they'll get.
In an ideal world, we'd _all_ be power users. Alas, the world is full
of people with different desires. This complicates matters. There's no
"one size fits all" solution. Fortunately, the world is full of
solutions. ;)
My favourite solutions give me the choice of using a listener when I
want one, and not using one when I don't. This is where I disagree
with many C programmers. I could probably find a C system with a
listener, but most C people confuse this with a batch language.
Their alternative is a tightly structured system called an IDE, which
is like wearing a straight jacket. Even some C programmers find them
limited and frustrating. Some suggest that "plug-ins" can help. This
is a step toward a more loosely structured system.
If I sometimes ask for a more tightly structured Lisp system, it's coz
I often write code for tightly structured systems. It seems to me that
this should be possible for Lisp, even if not everyone can understand
why it will be desirable for some of us. As I said above, the world is
full of solutions...and it's also full of users.
Any flames I get for posting this may be the result of conflicting
culturals. ;) The cultures of users vs programmers...? Hmm.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> A listener gives you a loosely structured interface,
I doubt you have ever seen or used a "Lisp Listener"?
> My favourite solutions give me the choice of using a listener when I
> want one, and not using one when I don't. This is where I disagree
> with many C programmers. I could probably find a C system with a
> listener, but most C people confuse this with a batch language.
???
> Their alternative is a tightly structured system called an IDE, which
> is like wearing a straight jacket. Even some C programmers find them
> limited and frustrating. Some suggest that "plug-ins" can help. This
> is a step toward a more loosely structured system.
???
> If I sometimes ask for a more tightly structured Lisp system, it's coz
> I often write code for tightly structured systems. It seems to me that
> this should be possible for Lisp, even if not everyone can understand
> why it will be desirable for some of us. As I said above, the world is
> full of solutions...and it's also full of users.
???
I'm not sure I could understand your posting fully. ;-)
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> > A listener gives you a loosely structured interface,
>
> I doubt you have ever seen or used a "Lisp Listener"?
That's a cheap shot, Rainer. Real cheap.
I've seen a fair number of Lisp listeners, and listeners for other
languages, too. I've even written a few.
> > My favourite solutions give me the choice of using a listener when I
> > want one, and not using one when I don't. This is where I disagree
> > with many C programmers. I could probably find a C system with a
> > listener, but most C people confuse this with a batch language.
>
> ???
Even the compiler has an interface, and some compilers give a choice
of interfaces. In Lisp, for example, you can often run the compiler
from the Lisp listener.
Sometimes you also have the option of using a command line interface.
In other words, a batch interface.
> I'm not sure I could understand your posting fully. ;-)
Then I'll explain. ;)
Users and programmers can have very different views of computer
software. Users will often not require the same freedom as a
programmer. The programmer may prefer not to give the user the same
degree of freedom.
Of course, this isn't unique to Lisp, but the tradition of a listener
does make it a little more obvious, while some languages have a
tradition of using a batch oriented interface. C, for example.
Recall a few years ago, when a C programmer (not alone) was trying to
convince people in a fair number of newsgroups that Lisp wasn't as
good as C. He posted some C code that allegedly adjusted the contrast
in a bitmap, reading from the standard input, scaling the value, and
then writing it to the standard output. Ignoring the many technical
flaws in this code, it assumes that the user will accept a batch style
interface for a task like this.
The Lisp programmer who responded did so with a simple and very short
point. He wouldn't use a file for the bitmap; he'd use a variable.
The implication is that both programmers were thinking in terms of a
loosely structured system, typing commands at a prompt of some kind.
A listener, perhaps?
However, can you imagine how a typical user might alter the contrast
in an image? Probably by using an like Photoshop. This is a tightly
structured system, with a window for each image (a variable) and an
interface that allows the user to invoke editing commands, like
adjusting the constrast.
Plug-ins make the system extensible (more loosely structured), within
limits set by Adobe. It's not in their interest to make to many of the
internals of an app accessible to programmers, never mind users.
So, sometimes limitations are put there deliberately. They're an
intentional feature of the design, reflecting the desires of the
people who create and use the software. Features of a language
environment may not always be ideal for the delivered application,
even if they do help the programmer write that app.
Is that clearer?
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Rainer Joswig wheezed these wise words:
>
> > > A listener gives you a loosely structured interface,
> >
> > I doubt you have ever seen or used a "Lisp Listener"?
>
> That's a cheap shot,
I was referring to the DW-based "Lisp Listener" (hence
the double quotes) of Genera.
> Is that clearer?
I'm still not very sure what you are talking about and why.
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> > > I doubt you have ever seen or used a "Lisp Listener"?
> >
> > That's a cheap shot,
>
> I was referring to the DW-based "Lisp Listener" (hence
> the double quotes) of Genera.
Then why not make that clear, in the first place? The phrase "Lisp
Listener" could refer to any Lisp Listener.
No, I have not used Genera. If you have a point to make about the
Genera listener, why not just make it? All I can see it an obscure
reference. It could still be a cheap shot, for all I know.
> I'm still not very sure what you are talking about and why.
Then consider another way in which Lisp is a loosely structured
system. Lisp allows you direct access to its tools. Instead of hiding
them inside the compiler, many tools are exposed to the programmer.
For example, in CL we have DESTRUCTURING-BIND. This gives us part of
the bahaviour of macro functions, but the language exposes instead of
simply hiding it inside DEFMACRO. This allows us to use it in our own
macros, and perhaps create new control structures with it.
HANDLER-BIND and HANDLER-CASE are another example. The former could've
been hidden from the programmer, but by exposing it, we can exploit it
ourselves. A more tightly structured language would only give us the
HANDLER-CASE structure.
The tools used to create most of CL are also available for us to use
to build yet more features. This is also true for some other
languages, like Forth. It's not true for a language like C, where we'd
either need the compiler source code in order to extend the language,
or use a complex preprocessor (embedded SQL, for example), or perhaps
even a complete compiler for a superset of the language.
These same ideas can be applied to other things, like applications. A
loosely structured app could be a collection of command line tools, to
be run from a shell or a script. A more tightly structured app could
be a framework for plug-in tools. Adobe Photoshop is a good example.
Take a look at the SDK for this app. Photoshop is itself a platform.
And of course we have AutoCAD and Emacs, which use Lisp. The loose
structuring of Emacs allows entirely new apps to be created. A great
many apps have been also been written within AutoCAD.
Then there's the OS. This too can be loosely structured, even to the
point where we only see the language used to build the system. Lisp
and Forth have been used in excellent examples of this. However, there
can also be systems somewhere between the tightly structured and
loosely structured systems. Instead of using just one single language
and building a system around it, some people want to build scripting
into many parts of an OS. Today, that scripting facility can be
language independant. Some of it already exists.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser