Re: can anyone offer Lisp job?

Juho Snellman <jsnell@xxxxxx> writes:

> <pitman@xxxxxxxxxxx> wrote:
> > Then again, you might try, and it might be cool, and still it might
> > not affect things. Look at how cool CMU's python compiler is and how
> > many people have rushed to prefer that as a result.
>
> Err... What a bizarre thing to say. Quite a lot of people prefer
> Python-based compilers (mainly CMUCL and SBCL).

But I said nothing about how many people preferred these, especially
relative to other implementations. What I said, or meant to say,
was that even with that preference, it wasn't the key to unlocking
the floodgates that would send millions flocking to CL... even these
stats show that.

To get a feeling for
> how many, we might consider "using" and "intending to use" as proxies
> for "preferring" an implementation:
>
> http://www.niksula.cs.hut.fi/~tsiivola/alu-questionnaire-statistics.html

According to this chart, even with the high entry barrier of commercial
fees, the number of people who preferr SBCL and CMU-CL to LW and Allegro
is not even a whole number multiplier, it's just a percentage. Such a
percentage, it seems to me, can EASILY be explained by their freeness
and not their speed. I don't know if you have a chart from the time when
CMU Python was actively being worked on, but I don't think it would show
that the compiler alone was causing people to flock from the commercial
lisps to that free Lisp. Additional barriers to entry on the CMU platform
were, as I recall customers citing, the lack of focus on GUI (i.e., the
resources at the time went into compiler, not GUI), the lack of platform
support, the lack of commercial support, etc.

Look, I certainly do NOT want to be caught in the position of trying to
claim that there's something wrong with this compiler or these
implementations. If you read back through my remarks in this and other
messages, you may be able to see that I have nothing but respect for the
absolutely cool things the CMU crowd did to show that CL can be compiled
in interesting ways.

All I'm doing is making the simple observation that historically, when
this was at its prime, (a) customers didn't abandon paid implementations
for it [even when processors were slower and the need for performance was
at its prime], and (b) commercial vendors did not rush to license it [even
when in principle it could have been argued it would give substantial
commercial value].

I do think some ideas catch on slowly and grow gradually to be well-accepted.
I hope that's true here.

But all of this discussion started in the context of people talking about
whether a simple CL kernel would be a great idea. And my feeling is that
it would have the same kind of "cool, but not the key" effect. I might be
wrong, of course. I often am, and I accept that I am, notwithstanding
remarks by people on other threads who say I'm afraid to be challenged.
One reason I post to this group is the number of people with good points of
view different than my own from which I learn a great many things on a daily
basis. But geez, if I'm wrong, don't just cite statistics, rush out to show
me that making a well-defined kernel is what's standing in the way of
Lisp and the CMU Python compiler crushing ... well, just to be spitefully
confusing in terminology, that OTHER Python thing that Ron Garret keeps
raving about. :)

(Or maybe there is a link between the Python language and the CMU Python
compiler I don't know about--in which case, someone DEFINITELY should
clarify this for me, since the similarity of naming has bothered me
forever and I've never had time to track down the etymologies...)

I wasn't trying to stop this experiment. I outlined how I thought it
could be done. I just wanted people to know my best understanding of
why it hadn't been done until now, so they wouldn't think we in the
community were not looney for not having tried it already.

That's how it is with established wisdom. Sometimes it's just the
right thing and everyone knows it. And sometimes it's totally wrong
and just no one's gotten around to testing it to see it's all a sham.
If someone tests established wisdom and it holds up, they shouldn't
feel ashamed. It's good for the world for someone to run a test now
and then. And if someone tests it and improves things, the old-timers
shouldn't feel ashamed either. Sometimes it takes a fresh look to see
something differently and that's how things progress. It's all just a
matter of resources. You can't go challenging every world truth every
day. It doesn't make sense. But sometimes you have to spot check
cobwebby assumptions. That makes sense, too.

Science, if that's what we practice, isn't about asserting truths. It's
about outlining what it would take to disprove something and then seeing
if someone will. At some point, people stop trying to disprove something
because they haven't the free resources to waste to challenging it, so
they move to challenging other things. And the things left unchallenged
become more accepted as that happens, but never truly fact. It's the best
we can do.
.

Relevant Pages

  • Re: Why not a Python compiler?
    ... compilation by compiling to Common Lisp and using the CL's compiler to ... In order to correctly implement Python addition, ... Expressing simple loops as C for loops... ... optimization for a Python compiler are vague, ...
    (comp.lang.python)
  • Re: Python 3K or Python 2.9?
    ... function/method argument that might as well be hidden in the compiler ... You could add some syntax to Python such that '.x' was equivalent to ... def factory: ... C.method = foo ...
    (comp.lang.python)
  • Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?
    ... pure functional languages can prove facts about the code ... so in theory the compiler can optimize much more away. ... Python carries some extra baggage in each object. ... Haskell is a good pure-functional language to use as a comparison. ...
    (comp.lang.python)
  • Re: magic names in python
    ... They have no special meaning to the Python compiler. ... I don't consider magic in a programming language a bad thing. ... And it would appear we are working with the same definition as regarding methods: a magic name method is an identifier recognized by the compiler as a special case. ... I'm not contesting that some identifiers have special meaning or are treated differently under certain conditions. ...
    (comp.lang.python)