Why learn Lisp
Christopher Browne
> Kaz Kylheku wrote:
>
>> In article <umi9336...@corp.supernews.com>, cr88192 wrote:
>>> Kaz Kylheku wrote:
>>>> Nobody cares about the braindamaged spec for your nonexistent language,
>>>> so stop
>>>> bringing it up, you lunatic. It's not topical here. Maybe try the
>>>> patience of comp.compilers for a change.
>>>
>>> hell, at least this is some feedback.
>>> if others feel similar I guess it explains the lack of reply.
>>>
>>> if I write a compiler will this topic be more acceptable?...
>>
>> Not in this forum unless it is a compiler for the language ANSI Common
>> Lisp. Not in comp.lang.scheme, unless it contains an implementation of an
>> RnRS spec.
>
> my last compiler was scheme.
>
> no one in comp.lang.misc seemed to care either when I had posted there.
Why would you _expect_ them to care?
There is a sizable population of people in these newsgroups that are
much more interested in figuring out ways of using the "industrial
grade" systems that they have than they are in hearing about the
latest techniques you just heard about (that they likely knew of ten
years ago) that you added, then took out because it didn't turn out
well.
In comp.lang.scheme, there are _barrels_ of free implementations out
there that are likely a whole lot more featureful than your language
is at this point. There are _largely disused_ implementations that
are likely of wider interest.
On comp.lang.lisp, the main dialect of Lisp under discussion is one
that has been fairly well specified since the 1980s, and your language
doesn't hold a candle to it in terms of overall functionality. Why
SHOULD people on comp.lang.lisp be interested in something that's not
compatible with their favored language, and which lacks a whole lot of
the functionality that they expect and demand.
If you need for people to "care" about your language design
discussion, then perhaps you need to work on a language implementation
that _will_ seem consequential to them. If you were to add a few
features to CLISP, _that_ would be of some interest to people. Ditto
for SBCL or CMUCL. A while back you were looking into Yale T; if you
were to resurrect the code base, and get a compiler running on a
modern Linux or FreeBSD system, I'm _sure_ that would attract some
interest. (Albeit from a different direction.)
But when what you're essentially doing is to fiddle with your own
private language implementation, why WOULD other people find this of
immense interest?
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/sgml.html
"I support Microsoft's right to innovate. I just wish they would make
use of that right." - Steve Shaw
cr88192
> But when what you're essentially doing is to fiddle with your own
> private language implementation, why WOULD other people find this of
> immense interest?
not sure, I could just continue where I left off and add everything I was
thinking to my scheme implementation, this would save having to redesign
and reimplement everything...
the only possible relavence in any case will be that it will be the
language I use for my projects.
it does not matter, I had just wondered if anyone would be interested...
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Erik Naggum
| if people don't care I have little reason to implement it...
That kind of attitude is just so /stupid/ I could scream. Well, let me
scream. THAT ATTITUDE IS SO GODDAMN STUPID! (Thank you.)
What you do with your time should be /completely/ unaffected by what other
people find valuable. You could not possibly attract anyone with some half-
assed non-implementation of an idea, so just give that part of the task up
right now. What you /can/ do, however, is prove to yourself first, and then
to others, that you can accomplish something worth accomplishing. Some
people prove this with degrees in educational institutions. Others start
small companies in their garage with the proceeds of their past successes.
If you are starting out in life and treat creating a language as a means to
learn something, which I do not even consider a worthwhile task if you are
into compiler design, you should not even /ask/ people to care. You have
set out to learn something by explicitly rejecting everything that other
people have done before you. Create your own language and be on your own.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Fred Gilham
> if people don't care I have little reason to implement it...
You have to do some `supply-side' thinking --- `build it and they will
come'. Of course, you are taking the risk that you will build it and
they'll stay away in droves. But if you win, you win really big.
If you decided to revive the T implementation, personally I'd
definitely comment on it, and one part of my comment would be `thank
you very much'.
But I found your language design really frustrating. You seemed to
want to combine some aspects of Python, Scheme and Common Lisp. It
didn't seem at all promising to me and I thought silence would be the
most charitable response.
You should realize that good self-image comes from accomplishment. If
you do something good, you WILL become world famous. I kid you not.
That's just the way the Internet is. You will get messages from all
over the world either praising you or asking for free upgrades. :-)
So you've got a lot of time on you hands: pick a project and see it
through. Then put it out there. Repeat until satisfied.
--
Fred Gilham gil...@csl.sri.com
Do remember you're there to fuddle him. From the way some of you
young fiends talk, anyone would suppose it was our job to teach!
-- The Screwtape Letters, C. S. Lewis
Charlton Wilbur
EN> If you are starting out in life and treat creating a language
EN> as a means to learn something, which I do not even consider a
EN> worthwhile task if you are into compiler design, you should
EN> not even /ask/ people to care. You have set out to learn
EN> something by explicitly rejecting everything that other people
EN> have done before you. Create your own language and be on your
EN> own.
On the contrary, I think this is a valuable exercise -- but its end is
not producing a useful language, especially not one that will be
useful to other people, but in learning about why things are done the
way they are in a particular language. When I was an undergraduate, I
looked at the dozen languages I had been exposed to, and decided that
I didn't like any of them completely, and that I could do a lot better
if I designed a language on my own. I was wrong; my pet language
wound up looking a lot like Objective-C, but I learned an enormous
amount about language design in the process.
All computer languages -- indeed, all engineering decisions -- involve
choices among various sets of tradeoffs. Sometimes the best way to
understand this principle, as well as to see it in action, is to
explicitly reject all existing solutions and to design one from the
ground up. The ancients were wise, but they were also foolish or
short-sighted; how many things in computer languages are there because
of historical precedent? If we were designing LISP today, would we
have functions named car and cdr? If we were designing C++ today,
would we put such immense importance on avoiding run-time typing
decisions?
And even then, designing a new language does not necessarily mean
rejecting all that has gone before. Did Bertrand Meyer discard what
he had learned from other languages when he designed Eiffel? Did
Bjarne Stroustrup discard what he had learned from other languages
when he started down the path that led to C++? Did Kernighan,
Ritchie, and Thompson discard what they had learned when they created
C? Of course not. All of them saw deficiencies in the existing
languages, and created a new language with what they considered
strengths and with as few weaknesses as possible.
Still, it's hardly surprising that comp.lang.lisp doesn't care. I
wouldn't expect it to; the language is neither LISP nor LISP-like, and
it doesn't seem to address any need I might have that isn't already
addressed by a more mature language.
Charlton
Erik Naggum
| And even then, designing a new language does not necessarily mean rejecting
| all that has gone before.
After you know what has gone before, you can be more intelligently creative
than when you start out from scratch.
| Did Bertrand Meyer discard what he had learned from other languages when he
| designed Eiffel? Did Bjarne Stroustrup discard what he had learned from
| other languages when he started down the path that led to C++? Did
| Kernighan, Ritchie, and Thompson discard what they had learned when they
| created C? Of course not.
Of course not. Were they 18-year-old whining loners who craved attention
for their inventions created in a vacuum? Of course not. Do you know
anything worth beans to anyone else when you are 18? Of course not.
| Still, it's hardly surprising that comp.lang.lisp doesn't care.
So far, the willingness to listen does not even extend to Paul Graham's Arc.
Novices with a desire to reinvent the world before they know what it is like
should take notice of this. Improving on Common Lisp is /very/ hard. And
most of the "improvements" on Scheme are neither improvements nor Scheme.
Kaz Kylheku
> rejecting all that has gone before. Did Bertrand Meyer discard what
> he had learned from other languages when he designed Eiffel? Did
> Bjarne Stroustrup discard what he had learned from other languages
> when he started down the path that led to C++? Did Kernighan,
> Ritchie, and Thompson discard what they had learned when they created
> C? Of course not.
Actually I dare say that the answer is yes on all counts. And I would
add the remark that the world would have been better off without
these,
with the possible exception of Eiffel.
These designers, deliberately or not, discarded lots of useful ideas
for
which efficient compilation is difficult to implement. Multiple
dispatch,
garbage collection, dynamic typing.
Stroustrup declined nearly every opportunity to improve on weak areas
of C, in the name of preserving backward compatibility. Actually, many
things can be fixed in an entirely backward compatible way, for
example
allowing arrays to be assigned and returned from functions, or
allowing
the . and -> operators to be interchangeable. Stroustrup could have
specified that C++ evaluation takes place left to right, thereby
eliminating those stupid sequence points that only serve as
programming
pitfalls. That would have been completely backward-compatible as well.
He introduced a completely useless keyword, ``class'' which behaves
only slightly differently from ``struct'', yet he did not fix the
stupid
overloading of the meaning of ``static'', which could have been done
by a new keyword. For example the ``private'' and ``public'' keywords
introduced for writing access specifiers could be used at file scope
to
determine the linkage of an external declaration.
> All of them saw deficiencies in the existing
> languages, and created a new language with what they considered
> strengths and with as few weaknesses as possible.
That's not the case with C; C started out as a deliberately
dumbed-down
imitation of BCPL called B that could fit onto a machine with 8
kilowords
of memory. C was designed to to do job, not to be a showcase of
language
design. That job was maintaining an operating system and related tools
in a reasonably portable and maintainable expression.
In a paper called _The Development of the C Language_, Ritchie admits
that he did not fix the precedence of the & and | operators when
&& and || were added because a whopping 600 kilobytes of C code
already existed.
cr88192
>
>> if people don't care I have little reason to implement it...
>
> You have to do some `supply-side' thinking --- `build it and they will
> come'. Of course, you are taking the risk that you will build it and
> they'll stay away in droves. But if you win, you win really big.
>
maybe.
> If you decided to revive the T implementation, personally I'd
> definitely comment on it, and one part of my comment would be `thank
> you very much'.
>
t was pretty cool, and also a few details of my current scheme vm were
borrowed from t. now that I think of it though still substantial work is
needed on the vm, and maybe I should work more on making persistence work...
I could look into implementing t, and consider how much work it would be
for my current vm. allready many of the internals of my vm have been being
altered, however most of the changes were intended to make it more
general...
I was considering making a kind of "glue" interface to allow persistent
stuff to reference stuff generated at runtime, this would likely solve a
few problems of mine.
> But I found your language design really frustrating. You seemed to
> want to combine some aspects of Python, Scheme and Common Lisp. It
> didn't seem at all promising to me and I thought silence would be the
> most charitable response.
>
I had thought the mishmash aspect was a good point, oh well...
or was it the features from the various languages I had chosen?...
> You should realize that good self-image comes from accomplishment. If
> you do something good, you WILL become world famous. I kid you not.
> That's just the way the Internet is. You will get messages from all
> over the world either praising you or asking for free upgrades. :-)
>
yes, but accomplishment is the hard part. at present my most promising
project is my os, even though development has been slow recently.
my language would have been a branch of my vm, which is a branch of my os.
my vm is still cruddy, as an os involves plenty of other work as well...
> So you've got a lot of time on you hands: pick a project and see it
> through. Then put it out there. Repeat until satisfied.
>
maybe can do...
the simplest approach for me right now would be to continue using scheme
but probably add what stuff I was thinking on top.
the alternate syntax could be a different reader, though selecting which
reader to use might be difficult or kludgy. one idea is to select via a
command line option, or the file suffix. another option could be to have
reader and language configuration stuff embeded in comments, though
possibly this would be annoying...
Kaz Kylheku
wrote:
> things can be fixed in an entirely backward compatible way, for
> example
> allowing arrays to be assigned and returned from functions, or
> allowing
Ewww. That's what you get for trying out Google news posting. The preview
looks normal, then the lines break when you actually post.
Let me guess, Perl? ;)