An Acceptable Lisp

On 26 ago, 20:37, Jon Harrop <j...@ffconsultancy.com> wrote:
> Matthew D Swank wrote:
> > He also said:
> > "There should be a simple, easily implementable kernel to the Lisp. That
> > kernel should be both more than Scheme -- modules and macros -- and less
> > than Scheme -- continuations remain an ugly stain on the otherwise clean
> > manuscript of Scheme.
>
> What's wrong with continuations?

Penis envy.

In article
<d112cae6-86b0-4d9e-9857-eab2b4746db3@z66g2000hsc.googlegroups.com>,
Vsevolod <vseloved@gmail.com> wrote:

> On Aug 27, 12:29 am, DeverLite <derby.lit...@gmail.com> wrote:
> > Do we really need or want a 'universal language'?
>
> Need -- don't know, but I suppose, not. Want -- perhaps. At least the
> people, who speculate on this topic (not only me, as you can see all
> over the internet and in this newsgroup in particular), want. (I don't
> mean, though, that I'm not content with the current CL).
> As well, it's a pity, that people, who can make a lot in the CL world,
> move away to other languages -- this means, that CL doesn't fully meet
> their demands (I mean someone, like Paul Graham and Peter Norvig --
> not the ones, who are constantly searching for something new or just
> don't know, what they want, and follow the wave).
>
> Vsevolod

Sorry, but that is bullshit.

Programming languages are tools. There are different types of users,
tasks, different applications to build and different building
methods used. There is not the one tool to build all things.
Do you use a screwdriver for everything? Hammering
nails into the wall? Would the ultimate screwdriver help
with that?

If somebody wants to experiment with new tools, fine.
But this does not make all other tools obsolete.
What we see is that there are different programming languages
with different implementations. There is some overlap in
functionality and there are differences. What is important
to some (say, Lisp syntax or Python's syntax) is
less important to others. Each group of users see
good reasons to like the special feature set. There
are a lot of features that are not possible to have in
one tool. So each tool (which a Common Lisp) has a specific
set of features that in combination make it useful.
Common Lisp had been designed to support an incremental,
interactive software development style where flexibility
is very important. It had been designed to support
the development of complex software by experts. It was
for example not designed to support the education
of computer science students with a minimal language.
I was also not designed to create mission critical
applications that require lots of static checks
(say, like Ada). It was also not designed as a language
to write some kind of business systems in - some which
require decimal numbers.

Paul Graham has some specific design goals. He wants
a smaller, simpler language. He wants short identifiers.
He wants some special magic in the language (read
his book 'On Lisp'?). He has all kinds of design goals
expressed. These goals make the design of that language
not attractive to 'me'. But it could be that there
are others that have similar preferences like Paul.

Peter Norvig doesn't do much with Lisp anymore. Well,
he works for Google, which uses mostly zero Lisp, AFAIK.
Python is popular at Google and it is good enough for
him to use it as an educational language for his
AI books, and it is good enough for them to use
it as a language to write their software in.
If you start at Google, your chance to introduce
Lisp there is close to zero, I guess. The nearest
you get to Lisp at Google is a Symbolics Lisp Machine in their computer
museum:
http://flickr.com/photos/mwichary/21...7603670797176/

There have been lots of attempts to design a 'better' Lisp.
Some nice Lisps have been defined. None of them gained
much market/mind share. None of them was able to replace
Common Lisp. Lots of work had been put into EuLisp,
Dylan and ISLisp. They are really good language designs.
But if you want to develop now an application in Lisp,
the current Common Lisp implementations are to beat and
that is very, very hard.
I'm sure that a small team of highly skilled hackers
could get a new and smaller Lisp based on something
like Dylan going in a few years. Lots of implementations
started that way in the 80s.

One can develop a new nice Lisp, sure. But it never
will be the 'universal language'.

Why do we have so
many different types of motorized vehicles?
Had Mercedes failed to built the ultimate car? The
universal car? One which you can drive on the
Autobahn and the in Blackforest for work? One that
transports a container and can be used to drive for
shopping in the city?

Programming languages are used by people to write software.
Find a group of people that need a better tool
and develop something for them.

Unless you have a more specific idea than to define the
'universal language', you will FAIL, badly.

--
http://lispm.dyndns.org/

On Aug 27, 10:28 am, Rainer Joswig <jos...@lisp.de> wrote:
> In article
> <d112cae6-86b0-4d9e-9857-eab2b4746...@z66g2000hsc.googlegroups.com>,
>
> Vsevolod <vselo...@gmail.com> wrote:
> > On Aug 27, 12:29 am, DeverLite <derby.lit...@gmail.com> wrote:
> > > Do we really need or want a 'universal language'?
>
> > Need -- don't know, but I suppose, not. Want -- perhaps. At least the
> > people, who speculate on this topic (not only me, as you can see all
> > over the internet and in this newsgroup in particular), want. (I don't
> > mean, though, that I'm not content with the current CL).
> > As well, it's a pity, that people, who can make a lot in the CL world,
> > move away to other languages -- this means, that CL doesn't fully meet
> > their demands (I mean someone, like Paul Graham and Peter Norvig --
> > not the ones, who are constantly searching for something new or just
> > don't know, what they want, and follow the wave).
>
> > Vsevolod
>
> Sorry, but that is bullshit.
>
> Programming languages are tools. There are different types of users,
> tasks, different applications to build and different building
> methods used. There is not the one tool to build all things.
> Do you use a screwdriver for everything? Hammering
> nails into the wall? Would the ultimate screwdriver help
> with that?
>
> If somebody wants to experiment with new tools, fine.
> But this does not make all other tools obsolete.
> What we see is that there are different programming languages
> with different implementations. There is some overlap in
> functionality and there are differences. What is important
> to some (say, Lisp syntax or Python's syntax) is
> less important to others. Each group of users see
> good reasons to like the special feature set. There
> are a lot of features that are not possible to have in
> one tool. So each tool (which a Common Lisp) has a specific
> set of features that in combination make it useful.
> Common Lisp had been designed to support an incremental,
> interactive software development style where flexibility
> is very important. It had been designed to support
> the development of complex software by experts. It was
> for example not designed to support the education
> of computer science students with a minimal language.
> I was also not designed to create mission critical
> applications that require lots of static checks
> (say, like Ada). It was also not designed as a language
> to write some kind of business systems in - some which
> require decimal numbers.
>
> Paul Graham has some specific design goals. He wants
> a smaller, simpler language. He wants short identifiers.
> He wants some special magic in the language (read
> his book 'On Lisp'?). He has all kinds of design goals
> expressed. These goals make the design of that language
> not attractive to 'me'. But it could be that there
> are others that have similar preferences like Paul.
>
> Peter Norvig doesn't do much with Lisp anymore. Well,
> he works for Google, which uses mostly zero Lisp, AFAIK.
> Python is popular at Google and it is good enough for
> him to use it as an educational language for his
> AI books, and it is good enough for them to use
> it as a language to write their software in.
> If you start at Google, your chance to introduce
> Lisp there is close to zero, I guess. The nearest
> you get to Lisp at Google is a Symbolics Lisp Machine in their computer
> museum:http://flickr.com/photos/mwichary/21...7603670797176/
>
> There have been lots of attempts to design a 'better' Lisp.
> Some nice Lisps have been defined. None of them gained
> much market/mind share. None of them was able to replace
> Common Lisp. Lots of work had been put into EuLisp,
> Dylan and ISLisp. They are really good language designs.
> But if you want to develop now an application in Lisp,
> the current Common Lisp implementations are to beat and
> that is very, very hard.
> I'm sure that a small team of highly skilled hackers
> could get a new and smaller Lisp based on something
> like Dylan going in a few years. Lots of implementations
> started that way in the 80s.
>
> One can develop a new nice Lisp, sure. But it never
> will be the 'universal language'.
>
> Why do we have so
> many different types of motorized vehicles?
> Had Mercedes failed to built the ultimate car? The
> universal car? One which you can drive on the
> Autobahn and the in Blackforest for work? One that
> transports a container and can be used to drive for
> shopping in the city?
>
> Programming languages are used by people to write software.
> Find a group of people that need a better tool
> and develop something for them.
>
> Unless you have a more specific idea than to define the
> 'universal language', you will FAIL, badly.
>
> --http://lispm.dyndns.org/

I always try to compare programming languages to natural ones (like
the authors of SICP did, when they coined their famous phrase). And I
think this comparison is much more important, than a screwdriver or a
mercedes ones -- those are very limited metaphors. Or, at least,
programming languages may be compared with your hands, because with
them you can make the screwdriver and the mercedes. But that's
philosophy.

Speaking about CL, I understand, what you say about how it fits it's
goals. Moreover it works fine for most of the tasks I can imagine
(because it's more, than just a tool, I think).
But I am trying to understand, what can be done to CL to improve it
without parting with it, like the designers of Qi, Arc and others did.
(By the way, you brought up interesting articles about DKLisp, I'll
definitely read them). And that was not a demand from my side to
create a better Lisp, just a thought-provocation. I am quite content
with the current CL. But, I think, even it can be improved.

Vsevolod

In article
<1e54220b-91e7-421c-af8f-b40e98f8d30e@79g2000hsk.googlegroups.com>,
Vsevolod <vseloved@gmail.com> wrote:

> I always try to compare programming languages to natural ones (like
> the authors of SICP did, when they coined their famous phrase). And I
> think this comparison is much more important, than a screwdriver or a
> mercedes ones -- those are very limited metaphors.

No, programming languages are actually also like tools.
They express algorithms that run on machines and these
algorithms are doing something. There are different
languages for controlling different kind of machines.
Communication of algorithmic ideas to other humans is one
purpose. The other purpose is to program machines to
do something (sometimes even something useful).


> Or, at least,
> programming languages may be compared with your hands, because with
> them you can make the screwdriver and the mercedes. But that's
> philosophy.

Natural languages are tools for communication. In natural
languages you also find no 'universal language'.
Natural languages are in many ways different from
formal languages or programming languages.

>
> Speaking about CL, I understand, what you say about how it fits it's
> goals. Moreover it works fine for most of the tasks I can imagine
> (because it's more, than just a tool, I think).
> But I am trying to understand, what can be done to CL to improve it
> without parting with it, like the designers of Qi, Arc and others did.
> (By the way, you brought up interesting articles about DKLisp, I'll
> definitely read them). And that was not a demand from my side to
> create a better Lisp, just a thought-provocation. I am quite content
> with the current CL. But, I think, even it can be improved.

That's no surprise. It is clear to most here that especially
Common Lisp can be improved. There are lots of small issues
with the standard. There are lots of larger issues with
the language. There have been some authors with very critical
remarks when Common Lisp appeared. There was a first round of
improvements with the ANSI CL standard. Since then most
of the improvements have been done by implementors and users
(and not by the language designers).
For example implementors have been implementing streams
and conditions with CLOS (Gray streams, ...). Threading
had been added, etc. Once can imagine that there
could be some effort to put some small and medium improvements
into CL. But these improvements will not make Common Lisp
an 'universal language'. It is not even the universal Lisp.
People like to experiment with new (or old) and different designs.

See for some older proposal:

http://lispm.dyndns.org/lisp/modernizing-cl.text

Or see

http://www.cliki.net/Proposed%20Extensions%20To%20ANSI

for more specific changes that are proposed.

There is also a proposal to use this as a way
to specify and communicate changes/extensions to CL:

http://cdr.eurolisp.org/final.html


>
> Vsevolod

--
http://lispm.dyndns.org/

On Aug 27, 12:17 pm, Rainer Joswig <jos...@lisp.de> wrote:
> In article
> <1e54220b-91e7-421c-af8f-b40e98f8d...@79g2000hsk.googlegroups.com>,
>
> http://lispm.dyndns.org/lisp/modernizing-cl.text
> http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
> http://cdr.eurolisp.org/final.html
I know about CDR and think, that it's a good idea. I even wanted to
submit a document there -- a reader syntax for hash-tables -- but
decided, that it was to small an issue (just a single function).
For the other links -- thanks a lot.

Vsevolod

Jon Harrop wrote:
> Matthew D Swank wrote:
>> He also said:
>> "There should be a simple, easily implementable kernel to the Lisp. That
>> kernel should be both more than Scheme -- modules and macros -- and less
>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>> manuscript of Scheme.
>
> What's wrong with continuations?

They interact badly with side effects.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Vsevolod wrote:
> On Aug 27, 12:17 pm, Rainer Joswig <jos...@lisp.de> wrote:
>> In article
>> <1e54220b-91e7-421c-af8f-b40e98f8d...@79g2000hsk.googlegroups.com>,
>>
>> http://lispm.dyndns.org/lisp/modernizing-cl.text
>> http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
>> http://cdr.eurolisp.org/final.html
> I know about CDR and think, that it's a good idea. I even wanted to
> submit a document there -- a reader syntax for hash-tables -- but
> decided, that it was to small an issue (just a single function).
> For the other links -- thanks a lot.

Please don't only submit "big improvements." It's the small one that
will add up over a mid-term period and can eventually be combined into
something bigger. But if you you wait for a "big thing" before you do
anything, nothing will happen.

Incremental growth is better than big-bang solutions.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

DeverLite wrote:

> Do we really need or want a 'universal language'?

Mono-anything is always bad.

On 2008-08-26, Matthew D Swank <akopa.gmane.poster@gmail.com> wrote:
> On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:
>
>>> What they are missing is that CL is a great language because it is
>>> extremely well-engineered, and the existing features fit together very
>>> nicely.
>> I completely agree with you.
>>
>> Dick Gabriel said: "I think there will be a next Lisp". (http://
>> www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm willing
>> to put effort in the direction of "the Ultimate Lisp" and plan to do
>> that, when I'm ready. But, surely, my efforts won't be enough, and,
>> moreover, as I've mentioned above, one- man efforts can't lead to
>> something as finely thought-out and engineered, as well as acceptable,
>> as, for example, Common Lisp
>>
>> Vsevolod
>
> He also said:
> "There should be a simple, easily implementable kernel to the Lisp. That
> kernel should be both more than Scheme -- modules and macros -- and less
> than Scheme -- continuations remain an ugly stain on the otherwise clean
> manuscript of Scheme.
>
> The kernel should emphasize implementational simplicity, but not at the
> expense of interface simplicity.

Simplicity is for amateurs. Or maybe for seasoned hackers who are breaking new
ground.

Production quality, N-th generation systems should emphasize reliability and
performance.

If you keep simplicity out of a kernel, it doesn't disappear. It simply moves
somewhere else, and possibly multiplies, because certain things can't be done
in a straightforward way outside of the kernel.

On 2008-08-26, Jon Harrop <jon@ffconsultancy.com> wrote:
> Matthew D Swank wrote:
>> He also said:
>> "There should be a simple, easily implementable kernel to the Lisp. That
>> kernel should be both more than Scheme -- modules and macros -- and less
>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>> manuscript of Scheme.
>
> What's wrong with continuations?

Continuations are one of those features that, as a user, you will probably pay
for even if you don't use them.

Of course, I mean real, first-class, re-invocable, dynamic continuations: the
kind which capture the entire call stack, so that you can re-enter a previously
saved context, and then return through its entire call chain, which may
traverse separate compilation units.

This type of object is the only thing that is worthy of being called
``continuation'', but the distinction needs to be made because of lesser hacks
which are called continuations.

If you implement real continuations so that there is no cost to programs which
don't use continuations, the implementation will suck donkey dung for programs
that do use continuations.

The problem is that a separately-compiled module of code which calls other
modules will have to support being traversed by continuations even if it
doesn't actually use them. If it is compiled to use a regular stack for its
local variables (i.e. user doesn't pay for the continuation feature that isn't
being used), the creation of a continuation will become expensive; it will have
to go back and clone the entire stack.

Lexical closures don't have this problem. If you don't use them, you don't pay.
A function that doesn't close over anything can be compiled in a way that is
oblivious to lexical closures. If a parent function calls some external child
function that makes closures, that activity has no interaction with the parent
function.