I was unable to find anything on this group regarding this issue...
MIT is replacing Scheme by Python in its famous SICS course:
"Why MIT now uses python instead of scheme for its undergraduate CS
program
Tuesday, March 24th, 2009
This week, I find myself lucky enough to be at the International Lisp
Conference at MIT in Cambridge, MA. I won�t get into why I�m here
right now, for those of you who might be surprised. The purpose of
this post is simply to paraphrase what Gerald Jay Sussman, one of the
original creators of Scheme, said yesterday in an a brief impromptu
talk about why the computer science department at MIT had recently
switched to using python in its undergraduate program. This change is
something that was widely panned when it was announced by many people
all across the programming and computing world from various
disciplines, so it seems worthwhile to try to document what Prof.
Sussman said.
....
However, he did say that starting off with python makes an
undergraduate�s initial experiences maximally productive in the
current environment. To that, I suggested that that dynamic makes it
far easier to �hook� undergrads on �computer science� and programming,
and retaining people�s interest and attracting people to the field(s)
is a good thing in general; Prof. Sussman agreed with that tangential
point..."
http://blog.snowtide.com/2009/03
So... If Scheme is that good why they replace it wilt ehem...
Python?...
A.L.
On 19 July, 16:51, A.L. <········@aol.com> wrote:
> I was unable to find anything on this group regarding this issue...
>
> MIT is replacing Scheme by Python in its famous SICS course:
>
> "Why MIT now uses python instead of scheme for its undergraduate CS
> program
>
> Tuesday, March 24th, 2009
>
> This week, I find myself lucky enough to be at the International Lisp
> Conference at MIT in Cambridge, MA. I won’t get into why I’m here
> right now, for those of you who might be surprised. The purpose of
> this post is simply to paraphrase what Gerald Jay Sussman, one of the
> original creators of Scheme, said yesterday in an a brief impromptu
> talk about why the computer science department at MIT had recently
> switched to using python in its undergraduate program. This change is
> something that was widely panned when it was announced by many people
> all across the programming and computing world from various
> disciplines, so it seems worthwhile to try to document what Prof.
> Sussman said.
> ....
> However, he did say that starting off with python makes an
> undergraduate’s initial experiences maximally productive in the
> current environment. To that, I suggested that that dynamic makes it
> far easier to “hook” undergrads on “computer science” and programming,
> and retaining people’s interest and attracting people to the field(s)
> is a good thing in general; Prof. Sussman agreed with that tangential
> point..."
>
> http://blog.snowtide.com/2009/03
>
> So... If Scheme is that good why they replace it wilt ehem...
> Python?...
>
> A.L.
I think the short answer is that Python has many of the positive
features of Scheme with the advantage of being widely supported so
that the UGs can actually find a market for their Python skills when
they graduate. I wouldn't say, per se, it was a better language than
Scheme but I personally would find no hardship in using it.
Mark
A.L. wrote:
> However, he did say that starting off with python makes an
> undergraduate�s initial experiences maximally productive in the
> current environment. To that, I suggested that that dynamic makes it
> far easier to �hook� undergrads on �computer science� and programming,
> and retaining people�s interest and attracting people to the field(s)
> is a good thing in general; Prof. Sussman agreed with that tangential
> point..."
>
> http://blog.snowtide.com/2009/03
>
> So... If Scheme is that good why they replace it wilt ehem...
> Python?...
You quoted the answer just before your question. A nice example, which
might be attractive for undergrads:
http://www.panda3d.org
There is nothing comprehensive and State of The Art (e.g. graphic card
shader integration, skeleton animation etc.) like this for Scheme.
Even for simpler games there are good environments for Python, like this
one:
http://www.pygame.org
Of course, with Lispbuilder at least Common Lisp has catched up a bit for
writing games :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 19 Jul., 18:27, Frank Buss <····@frank-buss.de> wrote:
> A.L. wrote:
> > However, he did say that starting off with python makes an
> > undergraduate’s initial experiences maximally productive in the
> > current environment. To that, I suggested that that dynamic makes it
> > far easier to “hook” undergrads on “computer science” and programming,
> > and retaining people’s interest and attracting people to the field(s)
> > is a good thing in general; Prof. Sussman agreed with that tangential
> > point..."
>
> >http://blog.snowtide.com/2009/03
>
> > So... If Scheme is that good why they replace it wilt ehem...
> > Python?...
>
> You quoted the answer just before your question. A nice example, which
> might be attractive for undergrads:
>
> http://www.panda3d.org
>
> There is nothing comprehensive and State of The Art (e.g. graphic card
> shader integration, skeleton animation etc.) like this for Scheme.
>
> Even for simpler games there are good environments for Python, like this
> one:
>
> http://www.pygame.org
>
> Of course, with Lispbuilder at least Common Lisp has catched up a bit for
> writing games :-)
A quick look at http://www.csail.mit.edu/node/3 suggests that
MIT does lots of research in AI, Systems and Theory.
Games is not that directly on that list.
On Sun, 19 Jul 2009 10:05:54 -0700 (PDT), Rainer Joswig
<······@lisp.de> wrote:
>
>A quick look at http://www.csail.mit.edu/node/3 suggests that
>MIT does lots of research in AI, Systems and Theory.
>
In Python or in Lisp?...
A.L.
On 19 Jul., 23:59, A.L. <········@aol.com> wrote:
> On Sun, 19 Jul 2009 10:05:54 -0700 (PDT), Rainer Joswig
>
> <······@lisp.de> wrote:
>
> >A quick look at http://www.csail.mit.edu/node/3 suggests that
> >MIT does lots of research in AI, Systems and Theory.
>
> In Python or in Lisp?...
In a building.
On Sun, 19 Jul 2009 15:44:05 -0700 (PDT), Rainer Joswig
<······@lisp.de> wrote:
>On 19 Jul., 23:59, A.L. <········@aol.com> wrote:
>> On Sun, 19 Jul 2009 10:05:54 -0700 (PDT), Rainer Joswig
>>
>> <······@lisp.de> wrote:
>>
>> >A quick look at �http://www.csail.mit.edu/node/3�suggests that
>> >MIT does lots of research in AI, Systems and Theory.
>>
>> In Python or in Lisp?...
>
>In a building.
Aaaaaa... Thanks for clarification.
A.L.
On Sun, 19 Jul 2009 18:27:54 +0200, Frank Buss <··@frank-buss.de>
wrote:
>A.L. wrote:
>
>> However, he did say that starting off with python makes an
>> undergraduate�s initial experiences maximally productive in the
>> current environment. To that, I suggested that that dynamic makes it
>> far easier to �hook� undergrads on �computer science� and programming,
>> and retaining people�s interest and attracting people to the field(s)
>> is a good thing in general; Prof. Sussman agreed with that tangential
>> point..."
>>
>> http://blog.snowtide.com/2009/03
>>
>> So... If Scheme is that good why they replace it wilt ehem...
>> Python?...
>
>You quoted the answer just before your question. A nice example, which
>might be attractive for undergrads:
>
>http://www.panda3d.org
>
>There is nothing comprehensive and State of The Art (e.g. graphic card
>shader integration, skeleton animation etc.) like this for Scheme.
This is about the same argument that we don't need to teach Electrical
Engineering students Ohm law any more because we have integrated
circuits. Or that we don't need to teach mechanical engineers
resistance of materials because we have AutoCAD.
There are agguments by Joel Spolsky about the necessity to learn C:
Learn C before graduating
Part two: C. Notice I didn't say C++. Although C is becoming
increasingly rare, it is still the lingua franca of working
programmers. It is the language they use to communicate with one
another, and, more importantly, it is much closer to the machine than
"modern" languages that you'll be taught in college like ML, Java,
Python, whatever trendy junk they teach these days.
http://www.joelonsoftware.com/articles/CollegeAdvice.html
I believe that this is not only about C. Anybody who wants to bear the
label "Software Engineer" should know the "bare to metal" languages
supporting essential programming paradigms: C, Lisp/Scheme and Prolog.
Spolsky's comments apply also to Lisp and Prolog
I believe that the main reason behind MIT's decision is greed. They
were afreid that SICS is too hard and not enough "fancy" to attract
less ambitious studens. And their monies, of course... Ach.. and by
the way, learning must be fun not hard work...
I was hoping that MIT will be the island of quality on the ocean of
deteriorating education, but it seems that I was wrong
A.L.
A.L. wrote:
> I believe that this is not only about C. Anybody who wants to bear the
> label "Software Engineer" should know the "bare to metal" languages
> supporting essential programming paradigms: C, Lisp/Scheme and Prolog.
> Spolsky's comments apply also to Lisp and Prolog
It's silly to say that Lisp is as bare to the metal as C. Python is even
more bare to the metal than Lisp. E.g. the number system: In many Lisp
implementations (/ 2 3) results in the fractional object 2/3. In Python 2.6
"2 / 3" results in "0". Looks like with Python 3.1 they have fixed it, now
it returns "0.6666666666", which will result in lots of fun for porting
applications written for Python <= 2.6. Maybe in Python 10 they'll reach
the Common Lisp level :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 19 Jul., 18:55, Frank Buss <····@frank-buss.de> wrote:
> A.L. wrote:
> > I believe that this is not only about C. Anybody who wants to bear the
> > label "Software Engineer" should know the "bare to metal" languages
> > supporting essential programming paradigms: C, Lisp/Scheme and Prolog.
> > Spolsky's comments apply also to Lisp and Prolog
>
> It's silly to say that Lisp is as bare to the metal as C. Python is even
> more bare to the metal than Lisp. E.g. the number system: In many Lisp
> implementations (/ 2 3) results in the fractional object 2/3. In Python 2.6
> "2 / 3" results in "0". Looks like with Python 3.1 they have fixed it, now
> it returns "0.6666666666", which will result in lots of fun for porting
> applications written for Python <= 2.6. Maybe in Python 10 they'll reach
> the Common Lisp level :-)
>
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
What kind of hardware are you using?
...
2 PUSH FP|2 ;A
3 RATIONAL-QUOTIENT FP|3 ;B
...
Looks like my hardware does know about ratios...
Rainer Joswig wrote:
> What kind of hardware are you using?
>
> ...
> 2 PUSH FP|2 ;A
> 3 RATIONAL-QUOTIENT FP|3 ;B
> ...
>
> Looks like my hardware does know about ratios...
Unlike Symbolics Lisp Machine, modern computers doesn't support rationals
and hardware accelerated GCs. I think this would be a bit too complicated
for students compared to x86 architectures, or maybe simplified instruction
sets, like MMIX or for some microcontrollers, so maybe it is a good idea
from Joel at least to learn the basics of C, which is not as complicated as
assembler (when comparing the implementations for a given problem), but
still very "bare to the metal".
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 19 Jul., 19:32, Frank Buss <····@frank-buss.de> wrote:
> Rainer Joswig wrote:
> > What kind of hardware are you using?
>
> > ...
> > 2 PUSH FP|2 ;A
> > 3 RATIONAL-QUOTIENT FP|3 ;B
> > ...
>
> > Looks like my hardware does know about ratios...
>
> Unlike Symbolics Lisp Machine, modern computers doesn't support rationals
> and hardware accelerated GCs. I think this would be a bit too complicated
> for students compared to x86 architectures, or maybe simplified instruction
> sets, like MMIX or for some microcontrollers, so maybe it is a good idea
> from Joel at least to learn the basics of C, which is not as complicated as
> assembler (when comparing the implementations for a given problem), but
> still very "bare to the metal".
MIT used to be an elite university, often named as the best technical
university in the US, maybe worldwide. If students there can't learn
that stuff, they are probably at the wrong university.
It was at MIT where people built these machines. It was at MIT where
bright
people built a Scheme processor:
http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-514.pdf
In these projects a lot of very young people were involved who
did amazing things (compared to today). They've written operating
systems, designed the circuits, built the machines, etc.
I hope that doesn't have changed to much.
MIT is one of the universities where the next generation of designers
of computer hardware and software gets their education. MIT designed
all kinds of processors up to various supercomputers. I really hope
that
C is not the future of computing.
We can teach students the somewhat sorry state of computing of today,
or
we could try to do it better.
On 2009-07-19, Rainer Joswig <······@lisp.de> wrote:
<...>
> I really hope that
> C is not the future of computing.
As a former C/Assembler/C++ programmer, now working about 50% of the
time with python, I am curious as to what you would think the future
of computing is.
<...>
> We can teach students the somewhat sorry state of computing of today,
> or
> we could try to do it better.
I am a product of a College Computer Science curriculum, and I
consider it vital that programmers understand the architecture of the
computer. Furthermore, if someone wants to work for my little company
as a programmer, he/she damn well better know a bit about the "bare
machine".
What in your opinion would be a better way to learn this aside from C
and assembler?
And please understand, I am not challenging you, rather I would like
to hear your opinion elaborated. Might it be forth?
thanks.
--
Tim
···@johnsons-web.com
http://www.akwebsoft.com
On 19 Jul., 22:17, Tim Johnson <····@johnsons-web.com> wrote:
> On 2009-07-19, Rainer Joswig <······@lisp.de> wrote:
> <...>
>
> > I really hope that
> > C is not the future of computing.
>
> As a former C/Assembler/C++ programmer, now working about 50% of the
> time with python, I am curious as to what you would think the future
> of computing is.
Allow me not to go into detail. Just one remark: operating systems
should
be built with languages that make it easier to build robust systems.
C is not such a language. It is not easy to build safe and robust
software in C.
> <...>
>
> > We can teach students the somewhat sorry state of computing of today,
> > or
> > we could try to do it better.
>
> I am a product of a College Computer Science curriculum, and I
> consider it vital that programmers understand the architecture of the
> computer. Furthermore, if someone wants to work for my little company
> as a programmer, he/she damn well better know a bit about the "bare
> machine".
>
> What in your opinion would be a better way to learn this aside from C
> and assembler?
>
> And please understand, I am not challenging you, rather I would like
> to hear your opinion elaborated. Might it be forth?
> thanks.
I don't think the 'real' purpose of the MIT is to educate
'programmers', but scientists.
A scientist is someone who can advance the state of the art. Someone
who is
enabled to do research. So the expectation should be higher than
'learning
current state of the art and learning how to use it'.
We need to look at the audience. A computer science student will
get have this course as an introduction and learn about
assembler and other things in special courses. I learned in
a course to program a VAX 11/780 in assembler. Long time ago.
To learn about low-level stuff it might be useful to study a compiler
and its implementation. It better be not about C, then the students
would
be busy with lots of not that relevant details. A Scheme compiler that
generates native code is not that large and can be studied. Wirth used
Pascal and later Oberon for this. An ML-variant would also be useful.
Software should not be written in C, thus I would not put it in
prominent place
for computer science students at universities.
In article <································@40tude.net>,
Frank Buss <··@frank-buss.de> wrote:
> Rainer Joswig wrote:
>
> > What kind of hardware are you using?
> >
> > ...
> > 2 PUSH FP|2 ;A
> > 3 RATIONAL-QUOTIENT FP|3 ;B
> > ...
> >
> > Looks like my hardware does know about ratios...
>
> Unlike Symbolics Lisp Machine, modern computers doesn't support rationals
> and hardware accelerated GCs. I think this would be a bit too complicated
> for students compared to x86 architectures, or maybe simplified instruction
> sets, like MMIX or for some microcontrollers, so maybe it is a good idea
> from Joel at least to learn the basics of C, which is not as complicated as
> assembler (when comparing the implementations for a given problem), but
> still very "bare to the metal".
The problem with C is that it's a low-level language masquerading as a
high-level language. The syntax of the language makes it very tempting
to write things like, e.g.:
x = f(g(), h());
but this is almost never a legitimate thing to do, because g and h could
produce errors, and C has no exceptions. So in 99% of the cases, the
above code needs to be written:
temp1 = g();
if (temp1 == ERROR) { ... }
temp2 = h();
if (temp2 == ERROR) { ... }
x = f(temp1, temp2);
This style of writing code makes it more apparent that C is indeed a
low-level language, but hardly anyone actually writes C this way,
especially when they are starting out, because it's just too tempting to
use the more compact form and ignore the possibility of g and h
returning errors. After all, you're a student, and no one is ever
really going to use this code for anything important, right?
Contrariwise, one of Lisp's problems is that it's a high-level language
that masquerades as a low-level language. CONS cells are a low-level
construct, but by conflating CONS cells, lists, and associative maps
(i.e. ALists and PLists) Lisp encourages premature optimization when it
doesn't have to. True abstract lists and abstract associative maps are
straightforward to implement in Lisp, but no one does it because the
first thing Lisp programmers are taught is how to use an AList, and how
to recurse using CDR.
Using Python as a teaching language is quite defensible IMHO because
compared to C and Lisp it is in fact what it purports to be: a
high-level language. Its abstract associative maps (i.e. dictionaries)
do a fairly good job of hiding the fact that they are implemented using
hash tables. Its lists don't do quite as good a job of hiding the fact
that they are adjustable 1-D arrays with fill pointers, but at least
they don't pretend to be anything other then what they are. And it has
a simple but still powerful object model that admit a broad range of
advanced concepts, including multimethods and metaclasses. I am a
two-or-three-sigma outlier in my bias in favor or Lisp, but I think
switching to Python for teaching is not at all unreasonable.
rg
On 19 Jul., 20:22, Ron Garret <·········@flownet.com> wrote:
> In article <································@40tude.net>,
> Frank Buss <····@frank-buss.de> wrote:
>
>
>
>
>
> > Rainer Joswig wrote:
>
> > > What kind of hardware are you using?
>
> > > ...
> > > 2 PUSH FP|2 ;A
> > > 3 RATIONAL-QUOTIENT FP|3 ;B
> > > ...
>
> > > Looks like my hardware does know about ratios...
>
> > Unlike Symbolics Lisp Machine, modern computers doesn't support rationals
> > and hardware accelerated GCs. I think this would be a bit too complicated
> > for students compared to x86 architectures, or maybe simplified instruction
> > sets, like MMIX or for some microcontrollers, so maybe it is a good idea
> > from Joel at least to learn the basics of C, which is not as complicated as
> > assembler (when comparing the implementations for a given problem), but
> > still very "bare to the metal".
>
> The problem with C is that it's a low-level language masquerading as a
> high-level language. The syntax of the language makes it very tempting
> to write things like, e.g.:
I'm not against using a low-level language for beginners. Part of what
they should learn
is what are essential primitives, how to implement them and how to
build up from
there.
I'm just not for using the most stupid low-level language without
error
handling, without safe execution, etc.
Scheme is guilty there, too - error handling was never a strong part
of education with Scheme, IIRC.
In article
<····································@b15g2000yqd.googlegroups.com>,
Rainer Joswig <······@lisp.de> wrote:
> On 19 Jul., 20:22, Ron Garret <·········@flownet.com> wrote:
> > In article <································@40tude.net>,
> > �Frank Buss <····@frank-buss.de> wrote:
> >
> >
> >
> >
> >
> > > Rainer Joswig wrote:
> >
> > > > What kind of hardware are you using?
> >
> > > > ...
> > > > � 2 �PUSH FP|2 � � � � � � � � � � � � �;A
> > > > � 3 �RATIONAL-QUOTIENT FP|3 � � � � � � ;B
> > > > ...
> >
> > > > Looks like my hardware does know about ratios...
> >
> > > Unlike Symbolics Lisp Machine, modern computers doesn't support rationals
> > > and hardware accelerated GCs. I think this would be a bit too complicated
> > > for students compared to x86 architectures, or maybe simplified
> > > instruction
> > > sets, like MMIX or for some microcontrollers, so maybe it is a good idea
> > > from Joel at least to learn the basics of C, which is not as complicated
> > > as
> > > assembler (when comparing the implementations for a given problem), but
> > > still very "bare to the metal".
> >
> > The problem with C is that it's a low-level language masquerading as a
> > high-level language. �The syntax of the language makes it very tempting
> > to write things like, e.g.:
>
> I'm not against using a low-level language for beginners. Part of what
> they should learn
> is what are essential primitives, how to implement them and how to
> build up from
> there.
>
> I'm just not for using the most stupid low-level language without
> error
> handling, without safe execution, etc.
>
> Scheme is guilty there, too - error handling was never a strong part
> of education with Scheme, IIRC.
IMHO the problem with C in the context of pedagogy is not so much that
it lacks these features, but that it superficially resembles languages
that have these features, which causes no end of confusion. (It also
causes no end of actual problems when used for real applications, but
that's a separate topic.)
rg
From: Pascal J. Bourguignon
Subject: Re: If Scheme is so good why MIT drops it?
Date:
Message-ID: <87ljmkbiur.fsf@galatea.local>
Ron Garret <·········@flownet.com> writes:
> Contrariwise, one of Lisp's problems is that it's a high-level language
> that masquerades as a low-level language. CONS cells are a low-level
> construct, but by conflating CONS cells, lists, and associative maps
> (i.e. ALists and PLists) Lisp encourages premature optimization when it
> doesn't have to. True abstract lists and abstract associative maps are
> straightforward to implement in Lisp, but no one does it because the
> first thing Lisp programmers are taught is how to use an AList, and how
> to recurse using CDR.
I can agree with this criticism, but it's not against lisp, it's
against how lisp is used. Indeed, when you see how lisp is considered
by young "engineers", it's obvious that there's a problem in the
teaching of lisp, not in lisp itself.
It would be trivial for university teachers to implement the abstract
data types needed to teach lisp as the high level programming language
it is.
It would be trivial to move the chapter about cons, car, cdr and null
from 1 to chapter "20. Advanced low level lisp constructs".
--
__Pascal Bourguignon__
In article <··············@galatea.local>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Ron Garret <·········@flownet.com> writes:
> > Contrariwise, one of Lisp's problems is that it's a high-level language
> > that masquerades as a low-level language. CONS cells are a low-level
> > construct, but by conflating CONS cells, lists, and associative maps
> > (i.e. ALists and PLists) Lisp encourages premature optimization when it
> > doesn't have to. True abstract lists and abstract associative maps are
> > straightforward to implement in Lisp, but no one does it because the
> > first thing Lisp programmers are taught is how to use an AList, and how
> > to recurse using CDR.
>
> I can agree with this criticism, but it's not against lisp, it's
> against how lisp is used. Indeed, when you see how lisp is considered
> by young "engineers", it's obvious that there's a problem in the
> teaching of lisp, not in lisp itself.
>
> It would be trivial for university teachers to implement the abstract
> data types needed to teach lisp as the high level programming language
> it is.
>
> It would be trivial to move the chapter about cons, car, cdr and null
> from 1 to chapter "20. Advanced low level lisp constructs".
All this is true, but one of the sad facts of the software industry is
that people hew to standards. Most do it because they don't think, and
the rest then do it because they have no choice but to follow the crowd
or be professionally ostracized. So Lisp would be much more likely to
be taught in a sane way if there were a standard for abstract lists and
associative maps rather than requiring everyone who wants these things
to roll their own. The situation is not so different from C. It is
possible to write good code in C, but the structure of the language
discourages it (because it looks like a high-level language, but it's
really not). Likewise, it's possible to write good code in Lisp but the
structure of the language discourages it because the first thing anyone
learns about when using Lisp is CAR, CDR and CONS. This makes Lisp look
like a low-level language when it's really not. Same coin, different
side.
rg
On Jul 19, 2:58 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Ron Garret <·········@flownet.com> writes:
> > Contrariwise, one of Lisp's problems is that it's a high-level language
> > that masquerades as a low-level language. CONS cells are a low-level
> > construct, but by conflating CONS cells, lists, and associative maps
> > (i.e. ALists and PLists) Lisp encourages premature optimization when it
> > doesn't have to. True abstract lists and abstract associative maps are
> > straightforward to implement in Lisp, but no one does it because the
> > first thing Lisp programmers are taught is how to use an AList, and how
> > to recurse using CDR.
>
> I can agree with this criticism, but it's not against lisp, it's
> against how lisp is used. Indeed, when you see how lisp is considered
> by young "engineers", it's obvious that there's a problem in the
> teaching of lisp, not in lisp itself.
>
> It would be trivial for university teachers to implement the abstract
> data types needed to teach lisp as the high level programming language
> it is.
>
> It would be trivial to move the chapter about cons, car, cdr and null
> from 1 to chapter "20. Advanced low level lisp constructs".
A valuable lesson I learned from Prof. Winston
http://people.csail.mit.edu/phw/index.html
is that smart people often misuse of the word "trivial" such
as above. More appropriate words would have been "simple" or
"easy" and trivial is not a synonym for them. Winston points
this out in his classes because young intelligent undergrads
are especially prone to misusing the word trivial to dismiss
whatever they wish no matter how non-trivial it actually is.
KHD
From: Pascal J. Bourguignon
Subject: Re: If Scheme is so good why MIT drops it?
Date:
Message-ID: <87vdlmaap7.fsf@galatea.local>
Keith H Duggar <······@alum.mit.edu> writes:
> On Jul 19, 2:58 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Ron Garret <·········@flownet.com> writes:
>> > Contrariwise, one of Lisp's problems is that it's a high-level language
>> > that masquerades as a low-level language. CONS cells are a low-level
>> > construct, but by conflating CONS cells, lists, and associative maps
>> > (i.e. ALists and PLists) Lisp encourages premature optimization when it
>> > doesn't have to. True abstract lists and abstract associative maps are
>> > straightforward to implement in Lisp, but no one does it because the
>> > first thing Lisp programmers are taught is how to use an AList, and how
>> > to recurse using CDR.
>>
>> I can agree with this criticism, but it's not against lisp, it's
>> against how lisp is used. Indeed, when you see how lisp is considered
>> by young "engineers", it's obvious that there's a problem in the
>> teaching of lisp, not in lisp itself.
>>
>> It would be trivial for university teachers to implement the abstract
>> data types needed to teach lisp as the high level programming language
>> it is.
>>
>> It would be trivial to move the chapter about cons, car, cdr and null
>> from 1 to chapter "20. Advanced low level lisp constructs".
>
> A valuable lesson I learned from Prof. Winston
>
> http://people.csail.mit.edu/phw/index.html
>
> is that smart people often misuse of the word "trivial" such
> as above. More appropriate words would have been "simple" or
> "easy" and trivial is not a synonym for them. Winston points
> this out in his classes because young intelligent undergrads
> are especially prone to misusing the word trivial to dismiss
> whatever they wish no matter how non-trivial it actually is.
Of course, "trivial" is always used tongue-in-cheekly, compared to
"simple" or "easy". That's why it's used instead of them...
I'd bet most people first encounter with "trivial" was in a math
course, where the teacher called "trivial" something that indeed
didn't look so simple, and perhaps never will.
--
__Pascal Bourguignon__
On Jul 19, 9:55 am, Frank Buss <····@frank-buss.de> wrote:
> E.g. the number system: In many Lisp
> implementations (/ 2 3) results in the fractional object 2/3. In Python 2.6
> "2 / 3" results in "0". Looks like with Python 3.1 they have fixed it, now
> it returns "0.6666666666", which will result in lots of fun for porting
> applications written for Python <= 2.6.
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.
On Jul 19, 7:33 pm, fft1976 <·······@gmail.com> wrote:
> How do you explain that something as inferior as Python beat Lisp in
> the market place despite starting 40 years later.
To be mainstream a language has to fit in most programmers' minds.
On Sun, 19 Jul 2009 11:22:30 -0700 (PDT)
Elena <········@gmail.com> wrote:
> On Jul 19, 7:33 pm, fft1976 <·······@gmail.com> wrote:
> > How do you explain that something as inferior as Python beat Lisp in
> > the market place despite starting 40 years later.
>
> To be mainstream a language has to fit in most programmers' minds.
Sometimes I wonder whether Python is not too complex for "most
programmers", since "most programmers" use Java, which is heavily
mainstream. Interesting whether it is in spite of the ridiculous
limitations or because of these. Probably a mix of both.
regards,
Marek
On Mon, 20 Jul 2009 02:54:13 +0200, Marek Kubica
<·····@xivilization.net> wrote:
>On Sun, 19 Jul 2009 11:22:30 -0700 (PDT)
>Elena <········@gmail.com> wrote:
>
>> On Jul 19, 7:33�pm, fft1976 <·······@gmail.com> wrote:
>> > How do you explain that something as inferior as Python beat Lisp in
>> > the market place despite starting 40 years later.
>>
>> To be mainstream a language has to fit in most programmers' minds.
>
>Sometimes I wonder whether Python is not too complex for "most
>programmers", since "most programmers" use Java, which is heavily
>mainstream.
Means, you think that all Java programmers are idiots by
definition?...
Please keep in midn that for majority of programmers, they don't
decide what languege they are using. Their employer makes this
decision.
A.L.
fft1976 wrote:
>
> How do you explain that something as inferior as Python beat Lisp in
> the market place despite starting 40 years later.
How do you explain that something as inferior as the Ford Sierra beat
the Porsche 901 in the market place despite starting 20 years later?
Alberto
fft1976 wrote:
> How do you explain that something as inferior as Python beat Lisp in
> the market place despite starting 40 years later.
Python is not that bad. Unlike Lisp, there is much less undefined behavior,
there is one free unique implementation on the 3 major platforms Linux,
Windows and MacOS X, which is stable, support multithreading and has a
default GUI library binding, which is difficult to find for Lisp (e.g. I
don't know of a free modern and stable Lisp implemenation with
mulithreading support for Windows, with a licence with which you can use it
in closed source commercial programs, like you can do with Python). Many
problems in the Lispbuilder mailing list are related to problems due to
different operating systems and Lisp implementations.
But maybe the most important point: The syntax looks simple compared to
Common Lisp (much less parentheses) and if you program in Python, it feels
easier for programmer newbies. As Sussman says: "undergraduate�s initial
experiences maximally productive". And this holds even for more experienced
programmers. If you know already a bit of C, it is easy to use Python, but
without the ability to do silly errors like writing out of array bounds (of
course, you can do this in Lisp, too, if you remember to set the safe mode
and if you use the right implementation). GC helps, too, to make the
programming task easier than in C. Some more arguments, e.g. 5 times less
program size than Java or C and more productive programmers:
http://www.artima.com/intv/speedP.html
(of course, an interview with Van Rossum might be a bit biased :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
In article <·······························@40tude.net>,
Frank Buss <··@frank-buss.de> wrote:
> there is one free unique implementation on the 3 major platforms Linux,
> Windows and MacOS X
Most people would still consider Solaris to be a "major platform".
On Sun, 19 Jul 2009 15:09:28 -0400
Roy Smith <···@panix.com> wrote:
> In article <·······························@40tude.net>,
> Frank Buss <··@frank-buss.de> wrote:
>
> > there is one free unique implementation on the 3 major platforms
> > Linux, Windows and MacOS X
>
> Most people would still consider Solaris to be a "major platform".
Depends on who you ask. On the desktop it doesn't matter at all
(fortunately, since everytime I work on Solaris I'm entering a world of
pain which is just slowly getting better with OpenSolaris), on the
server it (and other propietary Unices) is losing ground compared to
the free Unices.
But ok, let's say 3 major platforms: Unix, Windows and Mac OS X. Mac OS
X is formally a Unix but everything with GUI is non-Unix'y so it can be
considered a separate platform.
regards,
Marek
In article <·······················@halmanfloyd.lan.local>,
Marek Kubica <·····@xivilization.net> wrote:
> > > there is one free unique implementation on the 3 major platforms
> > > Linux, Windows and MacOS X
> >
> > Most people would still consider Solaris to be a "major platform".
>
> Depends on who you ask. On the desktop it doesn't matter at all
> (fortunately, since everytime I work on Solaris I'm entering a world of
> pain which is just slowly getting better with OpenSolaris), on the
> server it (and other propietary Unices) is losing ground compared to
> the free Unices.
Clearly, there's not much (if any) Solaris on the desktop. But it's sure
alive and kicking in the server world.
One of the things I like about Python is not just how portable is it is,
but how easy it is to build and deploy. We build our product on Windows, N
different Linux distros, Solaris, HPUX, AIX, and OSX. I've built Python
for all of those platforms. Then, I checked the install areas into
Perforce. Deploying is as simple as checking out the right sandbox.
We've gone through the same exercise for Perl. That was a lot more
painful.
On Jul 19, 9:31 pm, Frank Buss <····@frank-buss.de> wrote:
> fft1976 wrote:
> > How do you explain that something as inferior as Python beat Lisp in
> > the market place despite starting 40 years later.
<snip>
> But maybe the most important point: The syntax looks simple compared to
> Common Lisp (much less parentheses)
hahaha.
On Jul 19, 11:31 am, Frank Buss <····@frank-buss.de> wrote:
> I don't know of a free modern and stable Lisp implementation with
> mulithreading support for Windows, with a licence with which you can use it
> in closed source commercial programs
Have you looked at ECL?
http://ecls.sourceforge.net/
I've used it only a little, so I can't vouch for its stability, but it
fits the threading and license requirements (well, some corporate
lawyers have trouble with the LGPL, but I think it's usable).
-- Scott
Scott Burson wrote:
> Have you looked at ECL?
>
> http://ecls.sourceforge.net/
>
> I've used it only a little, so I can't vouch for its stability, but it
> fits the threading and license requirements (well, some corporate
> lawyers have trouble with the LGPL, but I think it's usable).
I didn't tried it myself, but looks like it is not very stable:
···············································@lispniks.com/msg01069.html
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 21 Jul., 06:57, Frank Buss <····@frank-buss.de> wrote:
> Scott Burson wrote:
> > Have you looked at ECL?
>
> >http://ecls.sourceforge.net/
>
> > I've used it only a little, so I can't vouch for its stability, but it
> > fits the threading and license requirements (well, some corporate
> > lawyers have trouble with the LGPL, but I think it's usable).
>
> I didn't tried it myself, but looks like it is not very stable:
>
> ···············································@lispniks.com/msg01069.html
I'm not sure if it is fair to post a reference to a single
post by someone without context and without having used ECL.
If there are stability problems, people can report to the
ECL mailing list. The maintainers are very active.
Frank, I have seen you constructive and posting code a year ago.
What happened? Several messages of yours I've seen here are now
going in the direction of been mostly useless. I thought
you could do better.
If you are no longer interested in Lisp with no first hand usage,
why not switch to comp.lang.misc or some other random place?
Rainer Joswig wrote:
> I'm not sure if it is fair to post a reference to a single
> post by someone without context and without having used ECL.
> If there are stability problems, people can report to the
> ECL mailing list. The maintainers are very active.
This was just one example. Another one:
···············································@lispniks.com/msg01024.html
Luke and Elliott are no beginners, so it is at least difficult to use ECL:
On Windows it doesn't work with MinGW and on MacOS X there was at least one
case were it freezed. But as I have written, I didn't tried it myself, so
this is only some second hand experience. Maybe it is all wrong setups in
combination with Lispbuilder and ECL itself is stable, I don't know.
But I know that it is much easier to get a full featured running Python
system on Windows, MacOS X and Linux, so this is something where Lisp
distributions could be improved.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 21 Jul., 18:44, Frank Buss <····@frank-buss.de> wrote:
> Rainer Joswig wrote:
> > I'm not sure if it is fair to post a reference to a single
> > post by someone without context and without having used ECL.
> > If there are stability problems, people can report to the
> > ECL mailing list. The maintainers are very active.
>
> This was just one example. Another one:
>
> ···············································@lispniks.com/msg01024.html
>
> Luke and Elliott are no beginners, so it is at least difficult to use ECL:
> On Windows it doesn't work with MinGW and on MacOS X there was at least one
> case were it freezed. But as I have written, I didn't tried it myself, so
> this is only some second hand experience. Maybe it is all wrong setups in
> combination with Lispbuilder and ECL itself is stable, I don't know.
>
> But I know that it is much easier to get a full featured running Python
> system on Windows, MacOS X and Linux, so this is something where Lisp
> distributions could be improved.
Python does not interest me a bit, so I removed from the list of
newsgroups. I'm using stuff like LispWorks, CCL and others.
Haven't had a setup problem in a while. Maybe several years.
ECL is also not CPython, has less users and a more ambitious
implementation: real compilation to C on various different platforms.
Other than that I'm extremely impressed by the enthusiasm of the
maintainer.
ECL has improved a lot in the last year(s) and people are now
running larger software with it. CPython has a much more
primitive implementation and lots of (happy) users.
If you are happy with CPython, use it. If you are unhappy
with some Lisp implementation, either help improving it
or use something else. Random whining on comp.lang.lisp
about stability problems you read somewhere of a product
you are not even using does not help at all.
Rainer Joswig wrote:
> If you are happy with CPython, use it. If you are unhappy
> with some Lisp implementation, either help improving it
> or use something else. Random whining on comp.lang.lisp
> about stability problems you read somewhere of a product
> you are not even using does not help at all.
You are right, I should try it myself. I've downloaded the latest stable
release of ECL, ecl-9.7.1. The manual for "Windows with Visual C++
compiler" says:
If you have a commercial version of Microsoft Visual Studio, the steps are
simple:
1. Change to the msvc directory.
2. Run nmake to build ECL.
...
I have Visual Studio 2008 on Windows Vista on a 32 bit machine. Lots of
warnings at step 2, even more serious ones, like "not all control paths
return a value", which is not a good sign for good code quality. Then at
the end a crash, with this output:
compile.lsp
copy /Y ..\src\cmp\sysfun.lsp .
1 Datei(en) kopiert.
date /t > BUILD-STAMP
set ECLDIR=./
ecl_min < compile.lsp
Internal or unrecoverable error in:
Got signal before environment was installed on our thread.
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
NMAKE : fatal error U1077: "ecl_min": R�ckgabe-Code "0xff"
Stop.
Maybe it is more stable when successfully compiled, but I don't trust it,
if it crashs when trying to compile it. Thanks, I'm using something else.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 21 Jul., 22:41, Frank Buss <····@frank-buss.de> wrote:
> Rainer Joswig wrote:
> > If you are happy with CPython, use it. If you are unhappy
> > with some Lisp implementation, either help improving it
> > or use something else. Random whining on comp.lang.lisp
> > about stability problems you read somewhere of a product
> > you are not even using does not help at all.
>
> You are right, I should try it myself. I've downloaded the latest stable
> release of ECL, ecl-9.7.1. The manual for "Windows with Visual C++
> compiler" says:
>
> If you have a commercial version of Microsoft Visual Studio, the steps are
> simple:
>
> 1. Change to the msvc directory.
> 2. Run nmake to build ECL.
> ...
>
> I have Visual Studio 2008 on Windows Vista on a 32 bit machine. Lots of
> warnings at step 2, even more serious ones, like "not all control paths
> return a value", which is not a good sign for good code quality. Then at
> the end a crash, with this output:
>
> compile.lsp
> copy /Y ..\src\cmp\sysfun.lsp .
> 1 Datei(en) kopiert.
> date /t > BUILD-STAMP
> set ECLDIR=./
> ecl_min < compile.lsp
>
> Internal or unrecoverable error in:
> Got signal before environment was installed on our thread.
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> NMAKE : fatal error U1077: "ecl_min": Rückgabe-Code "0xff"
> Stop.
>
> Maybe it is more stable when successfully compiled, but I don't trust it,
> if it crashs when trying to compile it. Thanks, I'm using something else.
I do that, too. I'm not using Windows anymore.
Rainer Joswig wrote:
> I do that, too. I'm not using Windows anymore.
Not an option for me. E.g. some random OS statistics:
http://www.w3schools.com/browsers/browsers_os.asp
As you can see, most people are using Windows. Looks like Linux will need
many more years until it has some significant installed based on desktop
systems. I assume many good developers are using Linux, too, but if you
want to write something for the normal end user, you have to support
Windows, too (try asking a salesman in a big store, if you can get this PC
with Linux, and if you are lucky, he knows at least what Linux is, but of
course, Windows is pre-installed and can't be changed).
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 21 Jul., 23:31, Frank Buss <····@frank-buss.de> wrote:
> Rainer Joswig wrote:
> > I do that, too. I'm not using Windows anymore.
>
> Not an option for me. E.g. some random OS statistics:
>
> http://www.w3schools.com/browsers/browsers_os.asp
>
> As you can see, most people are using Windows.
I'm so lucky that I'm not most people. Life is so short,
why struggle with Windows and feed Microsoft?
> Looks like Linux will need
> many more years until it has some significant installed based on desktop
> systems. I assume many good developers are using Linux, too, but if you
> want to write something for the normal end user, you have to support
> Windows, too (try asking a salesman in a big store, if you can get this PC
> with Linux, and if you are lucky, he knows at least what Linux is, but of
> course, Windows is pre-installed and can't be changed).
At developer conferences (Apache, Python, Lisp, ...) there are few
Windows users.
http://lispm.dyndns.org/lisp/pics/3454840244_d7f8221930_b.jpg
http://lispm.dyndns.org/lisp/pics/3454016237_906383ba1e_b.jpg
Rainer Joswig wrote:
> At developer conferences (Apache, Python, Lisp, ...) there are few
> Windows users.
>
> http://lispm.dyndns.org/lisp/pics/3454840244_d7f8221930_b.jpg
> http://lispm.dyndns.org/lisp/pics/3454016237_906383ba1e_b.jpg
Nice. Was there a MacBook wholesale at the conference? :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Jul 21, 6:57 am, Frank Buss <··@frank-buss.de> wrote:
> Scott Burson wrote:
> > Have you looked atECL?
>
> >http://ecls.sourceforge.net/
>
> > I've used it only a little, so I can't vouch for its stability, but it
> > fits the threading and license requirements (well, some corporate
> > lawyers have trouble with the LGPL, but I think it's usable).
>
> I didn't tried it myself, but looks like it is not very stable:
>
> ···············································@lispniks.com/msg01069...
ECL suffers from fast development problems if this is what you mean.
People are advised to stay with certain releases and we announce when
some ports are broken due to progress along certain lines.
For instance, if I find that the generational garbage collector is
needed for Linux, FreeBSD, OpenBSD and OS X, and it works, I do not
mind dropping temporarily the mingw port until the garbage collector
library catches up. People who wanted to stay with mingw produced a
branch (see Samium's posts) with the old garbage collector.
Now this is not so dramatic. ECL now has a release cycle of ONE MONTH.
If you find that this month's release does not work on your platform
(and this is normally explicit in the announcement), then do not
upgrade and wait one or two months until the problem is solved.
OTOH, people only seem to notice problems when their petty platform is
temporarily broken, but nobody seems to notice the overall stability
and portability of the platform. See the list http://ecls.sourceforge.net/logs.html
which will soon expand including Solaris and regular builds on Windows
using the free Microsoft compiler. And once the ARM computer I have
been gifted by a happy arrives, then Debian-ARM as well.
Juanjo
On Jul 19, 8:31 pm, Frank Buss <····@frank-buss.de> wrote:
> Python is not that bad. Unlike Lisp, there is much less undefined behavior,
> there is one free unique implementation on the 3 major platforms Linux,
> Windows and MacOS X, which is stable, support multithreading and has a
> default GUI library binding, which is difficult to find for Lisp (e.g. I
> don't know of a free modern and stable Lisp implemenation with
> mulithreading support for Windows, with a licence with which you can use it
> in closed source commercial programs, like you can do with Python). Many
> problems in the Lispbuilder mailing list are related to problems due to
> different operating systems and Lisp implementations.
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
Someone should mention Clozure CL - http://trac.clozure.com/openmcl
As you can see there is os x, freebsd, linux, solaris and windows port
and all of them use native threads (python still use green threads ?)
and development is pretty alive, they did planty of developing last
year[s], ccl licence permits you to deliver closed source programs ...
CCL is promising bright feature to CL since looks like the insist of
building stable implementation across most arch in use today
On 2009-07-21 05:37:27 -0400, milanj <······@gmail.com> said:
> Someone should mention Clozure CL - http://trac.clozure.com/openmcl
> As you can see there is os x, freebsd, linux, solaris and windows port
> and all of them use native threads (python still use green threads ?)
> and development is pretty alive, they did planty of developing last
> year[s], ccl licence permits you to deliver closed source programs ...
> CCL is promising bright feature to CL since looks like the insist of
> building stable implementation across most arch in use today
Hear, hear!
--
Raffael Cavallaro
milanj:
> and all of them use native threads (python still use green threads ?)
Python uses native threads.
Neil
From: John Higgins
Subject: Re: If Scheme is so good why MIT drops it?
Date:
Message-ID: <m263dl1umg.fsf@katana.lan>
On Tue, 21 Jul 2009 23:06:02 GMT, Neil Hodgson <···················@gmail.com> wrote:
> Python uses native threads.
With a global lock that prohibits more than one thread running python
code at the same time. This may change in the future, but for now python
threading is not exactly cutting edge or useful.
On 2009-07-19 19:31:36 +0100, Frank Buss <··@frank-buss.de> said:
> (e.g. I
> don't know of a free modern and stable Lisp implemenation with
> mulithreading support for Windows, with a licence with which you can use it
> in closed source commercial programs, like you can do with Python).
Openmcl seems reasonably stable to me, is LLGPL-licensed, and runs on
these platforms and Solaris x86.
It's kind of tragic, of course, that this kind of parasitic behaviour
(will not consider a commercial product to use in your commercial
system) has now become so common.
On Jul 19, 7:33 pm, fft1976 <·······@gmail.com> wrote:
> On Jul 19, 9:55 am, Frank Buss <····@frank-buss.de> wrote:
>
> > E.g. the number system: In many Lisp
> > implementations (/ 2 3) results in the fractional object 2/3. In Python 2.6
> > "2 / 3" results in "0". Looks like with Python 3.1 they have fixed it, now
> > it returns "0.6666666666", which will result in lots of fun for porting
> > applications written for Python <= 2.6.
>
> How do you explain that something as inferior as Python beat Lisp in
> the market place despite starting 40 years later.
The same way like VHS 'beat' the film formats for home videos.
The same way it will be 'beaten'.
On Jul 20, 12:57 am, Rainer Joswig <······@lisp.de> wrote:
> > How do you explain that something as inferior as Python beat Lisp in
> > the market place despite starting 40 years later.
>
> The same way like VHS 'beat' the film formats for home videos.
> The same way it will be 'beaten'.
wishful thinking tech geeking idiots always think that. It's a
psychological defense mechansim. When you are the loser, you enjoin
fancy adages to comfort yourself. Thus, Mac people, lisp people, and
unix people when it comse to Microsoft, always quote the same
mothefucking VHS vs Beta fuck.
In my life experience and interest on this issue in the past 5 years,
i found that, the world is basically pretty fair, all things
considered. Successful are successful not because they are unethical
or whatever motherfuck. Successful people, or products, in any
industry, may it be computing, singer, musics, software,
business ... , are due to reasonable causes, social and or technical.
e.g. the mundane hard working, good price/performance ratio, good
advertising, talent, and with perhaps a little what we'd have to call
fortuity.
Scheme, has become more obscure because it wasn't that great in the
first fucking place. Scheme grew upon a myth that it being elegant,
and this cult largely came from the fact when lisps are all
bewildering industrial langs and Scheme is one come with a design to
reduced lisps's ugliness. Since, the word “elegance” stuck with
Scheme.
As a illustration, the following 2 tech aspects we can see Scheme's
problem: (1) the cons business. (2) no namespace/library mechanism. In
the 1990s or before, these 2 reasons are not sufficient to kill it,
since other langs isn't much better in these areas, and much worse in
general. But today, starting about after 2000s, with proliferation of
langs and tools, Scheme isn't fit to compete for popularity.
References:
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
• Lisp's List Problem
http://xahlee.org/emacs/lisp_list_problem.html
• Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html
• Xah Lee's Computing Experience Bio
http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html
• Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
Xah
∑ http://xahlee.org/
☄
In comp.lang.scheme Xah Lee <······@gmail.com> wrote:
> Scheme, has become more obscure because it wasn't that great in the
> first fucking place. Scheme grew upon a myth that it being elegant,
> and this cult largely came from the fact when lisps are all
> bewildering industrial langs and Scheme is one come with a design to
> reduced lisps's ugliness. Since, the word ?elegance? stuck with
> Scheme.
Then why are most modern languages evolving towards all of the
functionality of functional languages? Things like lexical closure,
higher order functions, garbage collection, etc, are commonplace in your
"accepted and modern" languages these days. Give it another 20 years
and full macro systems will be common place as well. Why does this
diffusion happen?
Because languages like Scheme are "crucible" languages. People explore
the language in their implementations and then the knowledge of what works
and what doesn't gets disseminated throughout the relatively small culture
of language/compiler designers.
Syntax isn't what drives a language forward, any reasonable one will
do just fine. The four things which dominate language acceptance is A)
pure luck, B) the tools one uses to interact with it, C) expressivity
coupled with suggestivity, and D) available libraries.
If you think that because I said libraries I somehow justify your
argument, that isn't so. If you notice, C's libraries are probably the
most prolific and widest in use. Yet, there is no library structure at
all and most other languages create FFIs specifically to bring in the
functionality of C libraries.
Syntax isn't elegant: ideas are elegant.
-pete
On Jul 20, 9:36 am, Peter Keller <·······@merlin.cs.wisc.edu> wrote:
> In comp.lang.scheme Xah Lee <······@gmail.com> wrote:
>
> > Scheme, has become more obscure because it wasn't that great in the
> > first fucking place. Scheme grew upon a myth that it being elegant,
> > and this cult largely came from the fact when lisps are all
> > bewildering industrial langs and Scheme is one come with a design to
> > reduced lisps's ugliness. Since, the word ?elegance? stuck with
> > Scheme.
>
> Then why are most modern languages evolving towards all of the
> functionality of functional languages? Things like lexical closure,
> higher order functions, garbage collection, etc, are commonplace in your
> "accepted and modern" languages these days.
you as a Scheme or Lisp fan, perceives that the world is all copying
you.
Mac fans, perceives that Windows is all copying Mac, even today.
More realistically, the world didn't just copy you. Lisp is one of the
early languages, and in our opinion, a good one, containing many good
ideas. However, just because many lisp's ideas are common in many of
today's lang, you can't say that the world all copied lisp. For
example, automatic memory management, list datatype, are natural ideas
that would naturally come into being with increased computer hardware
power and progress of computer science.
In late 1990s, when Perl is raging, it is common to see here debates
about whether Perl is a lisp. Quite fucking idiotic. When XML is
raging in early 2000s, lisper fanatics think that the world finally
understood sexp, but did a lousy job in copying. What a motherfucking
idiocy. Today, especially like few years ago Ruby is raging with its
Rail whatnotfuck, you see people discussing with subjcet lines like Is
Ruby Lisp Done Right? What a motherfuck.
On the other hand, many, many, today's lang's features are not in
lisp.
It's the magic of wishful thinking at work.
Also, there's functional langs the likes of Mathematica, ML/OCaml/F#,
Haskell, erlang, OZ... and getting more popular today. Some of these
have roots in the 1980s. Lisps, in comparison to these, don't seem to
have a dick. Of course, the hardcore lispers look at these askance,
thinking that they are seeing some oddity of outter space that has
little earthy bearings; the same way imperative coding monkies look at
lisp — something they don't understand and ignore.
Also, lisp's macros, a feature that gets lispers much ado about
nothing. In Mathematica (b ~1989), the whole language can be
considered as a extended lisp macros system. When i learned about
lisp's macros while practical coding elisp, i find lisp macros are
rather so trivial, painful to use, and laughable. In fact, i never use
it, never see a need to use it. But you see lisp fanatics getting
giddy about macros all day, like Hasklers idiots drivel about monads
all day. All day, day and night. Macros! Monads!
> Give it another 20 years
> and full macro systems will be common place as well. Why does this
> diffusion happen?
LOL. (LOL = Laughing Out Loud.) Dream on.
In 20 years, bots will code for you, and meat brains would have
embedded silicon chips, and quantum computing would be reasonable too!
I'm not too sure Common Lisp, Scheme Lisp, Emacs Lisp, would still
exist. LOL.
> Because languages like Scheme are "crucible" languages. People explore
> the language in their implementations and then the knowledge of what works
> and what doesn't gets disseminated throughout the relatively small culture
> of language/compiler designers.
> Syntax isn't what drives a language forward, any reasonable one will
> do just fine.
Is this the “syntax is not important” adage? This is another idiotic
myth, popular among sophomoric computer language geekers, counting
some book writers.
Syntax, is the MOST important aspect of a computer language! Witness
lisp's nested parens. Without it, lisp wouldn't develope its
characteristics and features.
> The four things which dominate language acceptance is A)
> pure luck, B) the tools one uses to interact with it, C) expressivity
> coupled with suggestivity, and D) available libraries.
>
> If you think that because I said libraries I somehow justify your
> argument, that isn't so. If you notice, C's libraries are probably the
> most prolific and widest in use. Yet, there is no library structure at
> all and most other languages create FFIs specifically to bring in the
> functionality of C libraries.
>
> Syntax isn't elegant: ideas are elegant.
What a motherfucking meaningless idiocy.
Xah
∑ http://xahlee.org/
☄
Hallo,
On Jul 21, 12:31 pm, Xah Lee <······@gmail.com> wrote:
>
> Also, lisp's macros, a feature that gets lispers much ado about
> nothing. In Mathematica (b ~1989), the whole language can be
> considered as a extended lisp macros system. When i learned about
> lisp's macros while practical coding elisp, i find lisp macros are
> rather so trivial, painful to use, and laughable. In fact, i never use
> it, never see a need to use it. But you see lisp fanatics getting
> giddy about macros all day, like Hasklers idiots drivel about monads
> all day. All day, day and night. Macros! Monads!
>
This is interesting. This shows you cannot really code in Lisp,
be it Elisp, CL or Scheme. But deeply in your disturbed mind you
believe you can, and to solve this cognitive dissonance you end up
harrassing everyone with your idiotic ideias of how to improve Lisp.
-alex
Xah Lee wrote:
> mothefucking VHS vs Beta fuck.
> whatever motherfuck
> first fucking place
> Quite fucking idiotic
> motherfucking idiocy
> Rail whatnotfuck
> What a motherfuck.
> What a motherfucking meaningless idiocy.
Xah, this should get your creative juices flowing:
http://www.duggar.org/pub/humor/FWordIsBeautiful.wav
KHD
In comp.lang.scheme Xah Lee <······@gmail.com> wrote:
>> Syntax isn't elegant: ideas are elegant.
>
> What a motherfucking meaningless idiocy.
For example: I read the articles on your website and while I think your syntax
was passable, your ideas were not. I don't think there is any language you
could translate that stuff into to make the concepts in it better.
See the difference?
-pete
1. What's wrong with cons again? If you don't like it - just don't use
it.
2. Namespace/library mechanism is not absent. It exists in r6rs. In
r5rs it is not absent, it is just implementation-specific.
On Jul 21, 4:29 am, "Mr.Cat" <··········@gmail.com> wrote:
> 1. What's wrong with cons again? If you don't like it - just don't use
> it.
> 2. Namespace/library mechanism is not absent. It exists in r6rs. In
> r5rs it is not absent, it is just implementation-specific.
dear idiot,
see the FAQ at bottom of:
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Excerpt:
Q: If you don't like cons, lisp has arrays and hashmaps, too.
A: Suppose there's a lang called gisp. In gisp, there's cons but also
fons. Fons are just like cons except it has 3 cells with 3 accessors:
car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in
the lang. Every some 100 lines of code you'll see a use of fons with
its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar,
etc. You got annoyed by this. You as a critic, complains that fons is
bad. But then some gisp fanatics retorts: “If you don't like fons,
gisp has cons, too!”.
You see, by “having something too”, does not solve the problem of
pollution. Sure, you can use just cons in gisp, but every lib or
other's code you encounter, there's a invasion of fons with its cbar,
cbbar, cbbbar. The problem created by fons does not go away by “having
cons too”.
Xah
∑ http://xahlee.org/
☄
On Jul 21, 3:27 pm, Xah Lee <······@gmail.com> wrote:
> On Jul 21, 4:29 am, "Mr.Cat" <··········@gmail.com> wrote:
>
> > 1. What's wrong with cons again? If you don't like it - just don't use
> > it.
> > 2. Namespace/library mechanism is not absent. It exists in r6rs. In
> > r5rs it is not absent, it is just implementation-specific.
>
> dear idiot,
>
> see the FAQ at bottom of:
>
> • Fundamental Problems of Lisp
> http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> Excerpt:
>
> Q: If you don't like cons, lisp has arrays and hashmaps, too.
>
> A: Suppose there's a lang called gisp. In gisp, there's cons but also
> fons. Fons are just like cons except it has 3 cells with 3 accessors:
> car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in
> the lang. Every some 100 lines of code you'll see a use of fons with
> its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar,
> etc. You got annoyed by this. You as a critic, complains that fons is
> bad. But then some gisp fanatics retorts: “If you don't like fons,
> gisp has cons, too!”.
>
> You see, by “having something too”, does not solve the problem of
> pollution. Sure, you can use just cons in gisp, but every lib or
> other's code you encounter, there's a invasion of fons with its cbar,
> cbbar, cbbbar. The problem created by fons does not go away by “having
> cons too”.
Except that fons is useless while I can see use in cons - I can't
imagine lisp without it. Perhaps you can do that though, so please
explain or link me to an article of yours if you've already done so,
how do you imagine lisp without cons cells.
Xah Lee wrote:
>
> A: Suppose there's a lang called gisp. In gisp, there's cons but also
> fons. Fons are just like cons except it has 3 cells with 3 accessors:
> car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in
> the lang. Every some 100 lines of code you'll see a use of fons with
> its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar,
> etc. You got annoyed by this. You as a critic, complains that fons is
> bad. But then some gisp fanatics retorts: “If you don't like fons,
> gisp has cons, too!”.
>
FYI See
Haines, E. C., The TREET List Processing Language. M.S. Thesis, MIT,
Cambridge, Mass., August 1964. Also SR-133, The MITRE Corporation,
Bedford, Mass., April 1965.
As I recall, a lisp with 3 addresses per cell.
I think it had car, cdr, csr.
It didn't catch on.
On Jul 21, 9:23 am, Richard Fateman <·······@cs.berkeley.edu> wrote:
> Xah Lee wrote:
>
> > A: Suppose there's a lang called gisp. In gisp, there's cons but also
> > fons. Fons are just like cons except it has 3 cells with 3 accessors:
> > car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in
> > the lang. Every some 100 lines of code you'll see a use of fons with
> > its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar,
> > etc. You got annoyed by this. You as a critic, complains that fons is
> > bad. But then some gisp fanatics retorts: “If you don't like fons,
> > gisp has cons, too!”.
>
> FYI See
> Haines, E. C., The TREET List Processing Language. M.S. Thesis, MIT,
> Cambridge, Mass., August 1964. Also SR-133, The MITRE Corporation,
> Bedford, Mass., April 1965.
>
> As I recall, a lisp with 3 addresses per cell.
>
> I think it had car, cdr, csr.
>
> It didn't catch on.
Thanks Richard!
Rare is newsgroup discussions come out something informative.
(PS, i'm adding a little addendum to my essay about the existance of
TREET. If no objections, i'm crediting it to you as informer)
Xah
∑ http://xahlee.org/
☄
From: Don Geddis
Subject: Re: If Scheme is so good why MIT drops it?
Date:
Message-ID: <87prbudj2w.fsf@geddis.org>
Xah Lee <······@gmail.com> wrote on Tue, 21 Jul 2009:
> dear idiot,
> see the FAQ at bottom of:
> Fundamental Problems of Lisp
Dear Xah Idiot Lee Moron,
You've posted this link many, many times in the past. It remains just as
wrong now as it was the first time. But long experience has shown that
you're not interested in the truth, and you're not interested in learning
anything. So I'm excited to await the next hundred times you post the
exact same erroneous material!
Yours truly.
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
On Jul 21, 5:27 am, Xah Lee <······@gmail.com> wrote:
> • Fundamental Problems of Lisp
> http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
This sounds very interesting, but the translation is very bad. Did you
use babelfish?
On 21 jul, 15:52, fft1976 <·······@gmail.com> wrote:
> On Jul 21, 5:27 am, Xah Lee <······@gmail.com> wrote:
>
> > • Fundamental Problems of Lisp
> > http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> This sounds very interesting,
You can't be serious.
Xah Lee wrote:
> On Jul 21, 4:29 am, "Mr.Cat" <··········@gmail.com> wrote:
>> 1. What's wrong with cons again? If you don't like it - just don't use
>> it.
>> 2. Namespace/library mechanism is not absent. It exists in r6rs. In
>> r5rs it is not absent, it is just implementation-specific.
>
> dear idiot,
>
> see the FAQ at bottom of:
>
> • Fundamental Problems of Lisp
> http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> Excerpt:
>
> Q: If you don't like cons, lisp has arrays and hashmaps, too.
>
> A: Suppose there's a lang called gisp. In gisp, there's cons but also
> fons. Fons are just like cons except it has 3 cells with 3 accessors:
> car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in
> the lang. Every some 100 lines of code you'll see a use of fons with
> its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar,
> etc. You got annoyed by this. You as a critic, complains that fons is
> bad. But then some gisp fanatics retorts: “If you don't like fons,
> gisp has cons, too!”.
ROTFL. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
>dear idiot,
...
> Q: If you don't like cons, lisp has arrays and hashmaps, too.
No need to be insulting here.
When it comes to lists, scheme is rather close to other functional
languages like haskell or erlang. Lists haskell/erlang also have cons-
cell semantics, but it is a bit less explicit. At the same time in
scheme you're not limited to cons/car/cdr whe dealing with lists.
You've got different utility functions (i.e. srfi-1), pattern matching
and so on.
From: Aaron W. Hsu
Subject: Re: If Scheme is so good why MIT drops it?
Date:
Message-ID: <op.uxfzhowt0p3ku8@localhost>
On Tue, 21 Jul 2009 19:13:45 -0400, Mr.Cat <··········@gmail.com> wrote:
> When it comes to lists, scheme is rather close to other functional
> languages like haskell or erlang. Lists haskell/erlang also have cons-
> cell semantics, but it is a bit less explicit. At the same time in
> scheme you're not limited to cons/car/cdr whe dealing with lists.
> You've got different utility functions (i.e. srfi-1), pattern matching
> and so on.
Xah is, I believe, complaining about the very existence of the construct
in the core language, arguing that its frequent use represents a problem
to him and writing his own code. Apparently, the use of CONS in any code
makes that code bad, for some value of bad. I hope that the illegitimacy
of such "reasoning" appears self-evident to the majority of readers.
Aaron Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
Rainer Joswig wrote:
> On Jul 19, 7:33 pm, fft1976 <·······@gmail.com> wrote:
>> On Jul 19, 9:55 am, Frank Buss <····@frank-buss.de> wrote:
>> > E.g. the number system: In many Lisp
>> > implementations (/ 2 3) results in the fractional object 2/3. In Python
>> > 2.6 "2 / 3" results in "0". Looks like with Python 3.1 they have fixed
>> > it, now it returns "0.6666666666", which will result in lots of fun for
>> > porting applications written for Python <= 2.6.
>>
>> How do you explain that something as inferior as Python beat Lisp in
>> the market place despite starting 40 years later.
>
> The same way like VHS 'beat' the film formats for home videos.
Incompetence?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
On Sun, 19 Jul 2009 10:33:39 -0700, fft1976 wrote:
> On Jul 19, 9:55 am, Frank Buss <····@frank-buss.de> wrote:
>
>> E.g. the number system: In many Lisp
>> implementations (/ 2 3) results in the fractional object 2/3. In Python
>> 2.6 "2 / 3" results in "0". Looks like with Python 3.1 they have fixed
>> it, now it returns "0.6666666666", which will result in lots of fun for
>> porting applications written for Python <= 2.6.
>
> How do you explain that something as inferior as Python beat Lisp in the
> market place despite starting 40 years later.
http://www.jwz.org/doc/worse-is-better.html
Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
to do. It's the right thing to do if you're doing integer maths.
--
Steven
Steven D'Aprano <······@REMOVE.THIS.cybersource.com.au> writes:
> Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
> to do. It's the right thing to do if you're doing integer maths.
I wonder whether 2/3 => ValueError is preferable.
On Jul 20, 9:13 am, Paul Rubin <·············@NOSPAM.invalid> wrote:
> Steven D'Aprano <······@REMOVE.THIS.cybersource.com.au> writes:
> > Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
> > to do. It's the right thing to do if you're doing integer maths.
>
> I wonder whether 2/3 => ValueError is preferable.
Not all software wants this. It shouldn't be part of the language but
rather part of your code if you need such a feature. (for instance, to
distinguish between 2/3 and divisions with 0 dividend).
vippstar <········@gmail.com> writes:
> > I wonder whether 2/3 => ValueError is preferable.
>
> Not all software wants this. It shouldn't be part of the language but
> rather part of your code if you need such a feature. (for instance, to
> distinguish between 2/3 and divisions with 0 dividend).
I don't see how to implement such a thing in my code, if I believe
that the ring of integers doesn't have any concept of division and so
attempts to divide integers should be treated as errors. Yes of
course the present / operator is useful, but I could do just as well
with the divmod function which I think is more explicit.
On Jul 20, 7:50 pm, Paul Rubin <·············@NOSPAM.invalid> wrote:
> vippstar <········@gmail.com> writes:
> > > I wonder whether 2/3 => ValueError is preferable.
>
> > Not all software wants this. It shouldn't be part of the language but
> > rather part of your code if you need such a feature. (for instance, to
> > distinguish between 2/3 and divisions with 0 dividend).
>
> I don't see how to implement such a thing in my code,
Write a function:
(if (< x y)
ValueError
(/ x y))
This will return 0 only if the dividend = 0, not in integer division x/
y with y > x, which will return ValueError. Of course, ValueError must
not be an integer, because that could be the result of an integer
division. If it's not possible to return multiple types, then the
function can make use of some error handling mechanism.
> if I believe that the ring of integers doesn't have any concept
> of division and so attempts to divide integers should be treated
> as errors.
Wouldn't that mean 3/2 would also evaluate to ValueError? But 3/2 = 1
in integer division, not 0, like 2/3. Regardless, it's a specialized
requirement, and thus should either be implemented by the programmer
or the language could provide it if it's specialized, (for instance, I
wouldn't require a language to provide text manipulation features, but
I expect them from perl because it's not a general all purpose
language [the name designates that, however it can be used as one -
like lisp])
> course the present / operator is useful, but I could do just as well
> with the divmod function which I think is more explicit.
What? Python? Aww.
vippstar <········@gmail.com> writes:
> > I don't see how to implement such a thing in my code,
> Write a function:
>
> (if (< x y)
> ValueError
> (/ x y))
I meant changing the behavior of integer division in python.
> Wouldn't that mean 3/2 would also evaluate to ValueError?
Yes, the idea was that one can take the view that integer division
should not be allowed except through a 'div' function or some such.
On Jul 21, 1:22 am, Paul Rubin <·············@NOSPAM.invalid> wrote:
> vippstar <········@gmail.com> writes:
> > > I don't see how to implement such a thing in my code,
> > Write a function:
>
> > (if (< x y)
> > ValueError
> > (/ x y))
>
> I meant changing the behavior of integer division in python.
You'd either have to hack an implementation or change the standard (I
just noticed python doesn't have one).
> > Wouldn't that mean 3/2 would also evaluate to ValueError?
>
> Yes, the idea was that one can take the view that integer division
> should not be allowed except through a 'div' function or some such.
You brought up 3/2 == ValueError as a more appropriate value for the
integer division to evaluate, rather than 0. I thought you meant
specifically those kinds of divisions.
On 7/20/2009 2:13 AM, Paul Rubin wrote:
> Steven D'Aprano <······@REMOVE.THIS.cybersource.com.au> writes:
>> Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
>> to do. It's the right thing to do if you're doing integer maths.
>
> I wonder whether 2/3 => ValueError is preferable.
Not for me :(
On 20 Jul 2009 05:11:17 GMT, Steven D'Aprano
<······@REMOVE.THIS.cybersource.com.au> wrote:
>On Sun, 19 Jul 2009 10:33:39 -0700, fft1976 wrote:
>
>> On Jul 19, 9:55�am, Frank Buss <····@frank-buss.de> wrote:
>>
>>> E.g. the number system: In many Lisp
>>> implementations (/ 2 3) results in the fractional object 2/3. In Python
>>> 2.6 "2 / 3" results in "0". Looks like with Python 3.1 they have fixed
>>> it, now it returns "0.6666666666", which will result in lots of fun for
>>> porting applications written for Python <= 2.6.
>>
>> How do you explain that something as inferior as Python beat Lisp in the
>> market place despite starting 40 years later.
>
>http://www.jwz.org/doc/worse-is-better.html
>
>
>Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
>to do. It's the right thing to do if you're doing integer maths.
I recommend the book by Richard Gabriel (the same guy as in the above
link): "Patterns of Software: Tales from The Software Community",
Oxford University Press, 1996. He says that language acceptance/no
acceptance is social process not technical one. Interesting book.
A.L.
On Jul 20, 5:21 am, A.L. <········@aol.com> wrote:
> On 20 Jul 2009 05:11:17 GMT, Steven D'Aprano
> >http://www.jwz.org/doc/worse-is-better.html
> I recommend the book by Richard Gabriel (the same guy as in the above
> link): "Patterns of Software: Tales from The Software Community",
> Oxford University Press, 1996. He says that language acceptance/no
> acceptance is social process not technical one. Interesting book.
I find the book rather idiotic. One of the worst IT industry social
commentary sort of book.
• Book Review: Patterns of Software
http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
Xah
∑ http://xahlee.org/
☄
On Mon, 20 Jul 2009 06:26:58 -0700 (PDT), Xah Lee <······@gmail.com>
wrote:
>On Jul 20, 5:21 am, A.L. <········@aol.com> wrote:
>> On 20 Jul 2009 05:11:17 GMT, Steven D'Aprano
>
>> >http://www.jwz.org/doc/worse-is-better.html
>
>> I recommend the book by Richard Gabriel (the same guy as in the above
>> link): "Patterns of Software: Tales from The Software Community",
>> Oxford University Press, 1996. He says that language acceptance/no
>> acceptance is social process not technical one. Interesting book.
>
>I find the book rather idiotic. One of the worst IT industry social
>commentary sort of book.
>
>� Book Review: Patterns of Software
> http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
>
> Xah
>? http://xahlee.org/
>
After looking in archive of this group, I found 100% of your posts
100% idiotic
A.L.
On Jul 20, 5:07 pm, A.L. <········@aol.com> wrote:
> On Mon, 20 Jul 2009 06:26:58 -0700 (PDT), Xah Lee <······@gmail.com>
> wrote:
>
>
>
> >On Jul 20, 5:21 am, A.L. <········@aol.com> wrote:
> >> On 20 Jul 2009 05:11:17 GMT, Steven D'Aprano
>
> >> >http://www.jwz.org/doc/worse-is-better.html
>
> >> I recommend the book by Richard Gabriel (the same guy as in the above
> >> link): "Patterns of Software: Tales from The Software Community",
> >> Oxford University Press, 1996. He says that language acceptance/no
> >> acceptance is social process not technical one. Interesting book.
>
> >I find the book rather idiotic. One of the worst IT industry social
> >commentary sort of book.
>
> >• Book Review: Patterns of Software
> > http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
>
> > Xah
> >?http://xahlee.org/
>
> After looking in archive of this group, I found 100% of your posts
> 100% idiotic
But is he sincere or is he trolling? There's much content in his
website, some of it appears technical.
On Mon, 20 Jul 2009 11:13:01 -0700 (PDT), vippstar
<········@gmail.com> wrote:
>On Jul 20, 5:07�pm, A.L. <········@aol.com> wrote:
>> On Mon, 20 Jul 2009 06:26:58 -0700 (PDT), Xah Lee <······@gmail.com>
>> wrote:
>>
>>
>>
>> >On Jul 20, 5:21 am, A.L. <········@aol.com> wrote:
>> >> On 20 Jul 2009 05:11:17 GMT, Steven D'Aprano
>>
>> >> >http://www.jwz.org/doc/worse-is-better.html
>>
>> >> I recommend the book by Richard Gabriel (the same guy as in the above
>> >> link): "Patterns of Software: Tales from The Software Community",
>> >> Oxford University Press, 1996. He says that language acceptance/no
>> >> acceptance is social process not technical one. Interesting book.
>>
>> >I find the book rather idiotic. One of the worst IT industry social
>> >commentary sort of book.
>>
>> >� Book Review: Patterns of Software
>> > �http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
>>
>> > �Xah
>> >?http://xahlee.org/
>>
>> After looking in archive of this group, I found 100% of your posts
>> 100% idiotic
>
>But is he sincere or is he trolling? There's much content in his
>website, some of it appears technical.
I am sensitive on arguments that match word "idiotic". Usually, when I
encounter such "opinion" I don't read any further
A.L.
On Jul 19, 7:33 pm, fft1976 <·······@gmail.com> wrote:
> On Jul 19, 9:55 am, Frank Buss <····@frank-buss.de> wrote:
>
> > E.g. the number system: In many Lisp
> > implementations (/ 2 3) results in the fractional object 2/3. In Python 2.6
> > "2 / 3" results in "0". Looks like with Python 3.1 they have fixed it, now
> > it returns "0.6666666666", which will result in lots of fun for porting
> > applications written for Python <= 2.6.
>
> How do you explain that something as inferior as Python beat Lisp in
> the market place despite starting 40 years later.
Worse is better?
Bobi
http://www.linkedin.com/in/slobodanblazeski
On Sun, 19 Jul 2009 18:55:51 +0200, Frank Buss <··@frank-buss.de>
wrote:
>A.L. wrote:
>
>> I believe that this is not only about C. Anybody who wants to bear the
>> label "Software Engineer" should know the "bare to metal" languages
>> supporting essential programming paradigms: C, Lisp/Scheme and Prolog.
>> Spolsky's comments apply also to Lisp and Prolog
>
>It's silly to say that Lisp is as bare to the metal as C.
This is absulutely not the issue.
A.L.
A.L. wrote:
> This is absulutely not the issue.
Sorry, than I misunderstood what you mean. In the link you posted the only
thing he says about Lisp is:
| "the demand for keypunch operators will exceed 100,000,000 by the year
| 2010" and "lisp careers are really very hot right now."
:-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Sun, 19 Jul 2009 18:55:51 +0200
Frank Buss <··@frank-buss.de> wrote:
> A.L. wrote:
>
> > I believe that this is not only about C. Anybody who wants to bear
> > the label "Software Engineer" should know the "bare to metal"
> > languages supporting essential programming paradigms: C,
> > Lisp/Scheme and Prolog. Spolsky's comments apply also to Lisp and
> > Prolog
>
> It's silly to say that Lisp is as bare to the metal as C.
Lisp is mentioned because of the "essential programming paradigms", not
because of the "bare to metal" aspect.
regards,
Marek
On Sun, 19 Jul 2009 19:12:25 +0200, Marek Kubica
<·····@xivilization.net> wrote:
>On Sun, 19 Jul 2009 18:55:51 +0200
>Frank Buss <··@frank-buss.de> wrote:
>
>> A.L. wrote:
>>
>> > I believe that this is not only about C. Anybody who wants to bear
>> > the label "Software Engineer" should know the "bare to metal"
>> > languages supporting essential programming paradigms: C,
>> > Lisp/Scheme and Prolog. Spolsky's comments apply also to Lisp and
>> > Prolog
>>
>> It's silly to say that Lisp is as bare to the metal as C.
>
>Lisp is mentioned because of the "essential programming paradigms", not
>because of the "bare to metal" aspect.
>
Right. I should write "metal". There are some constructs that are
foundations; other things started from these foundations. Education is
half done if we don't teach students these foundations.
By the way, I forgot to mention Simula. This is the foundation of
object oriented programming
A.L.
On Sun, 19 Jul 2009 18:55:51 +0200, Frank Buss wrote:
> It's silly to say that Lisp is as bare to the metal as C.
C is a good language for programming Von Neumann machines. However, it
isn't good for other types of machines, such as Lisp machines. Lisp
machines and other types of machines not yet invented cannot easily be
programmed in C, but are easier to program in Lisp or perhaps languages
for new paradigms.
These other types of machines are not popular now, but they will be in 50
(or perhaps 100) years.
--
Nathan Stoddard, http://nathanstoddard.com
Nathan Stoddard wrote:
> C is a good language for programming Von Neumann machines. However, it
> isn't good for other types of machines, such as Lisp machines. Lisp
> machines and other types of machines not yet invented cannot easily be
> programmed in C, but are easier to program in Lisp or perhaps languages
> for new paradigms.
I don't think that special instruction sets and CPU features helps very
much for the execution speed. E.g. if you develop a CPU which supports
rational numbers, this might be twice as fast than on a CPU without such
support. But the next generation of a standard CPU is more than twice as
fast some years later, so there is no point in developing special
instruction sets. And I can't see other advantages than speed for special
CPUs (required RAM for a given instruction set is not important on desktop
computer).
See this link for an interesting article about the topic:
http://www.yosefk.com/blog/the-high-level-cpu-challenge.html
> These other types of machines are not popular now, but they will be in 50
> (or perhaps 100) years.
Do you have some examples and can you justify your opinion? At the moment
it looks like the standard Von Neumann architecture will be still very
popular in 50 years, extended to massive parallel computing, as available
already in graphics cards. I have implemented a magnetic flux calculation
for NVIDIA graphics cards and on small graphics cards it is more than 20
times faster (compared to one core on a 3 GHz Pentium) and on bigger ones
up to 100 times faster:
http://www.frank-buss.de/magnetfeld/index.html
Many other modern problems can be parallelized, too, e.g. multimedia data
processing, other scientific calculations and of course, games :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
[...]
> Do you have some examples and can you justify your opinion? At the moment
> it looks like the standard Von Neumann architecture will be still very
> popular in 50 years, extended to massive parallel computing, as available
> already in graphics cards. I have implemented a magnetic flux calculation
> for NVIDIA graphics cards and on small graphics cards it is more than 20
> times faster (compared to one core on a 3 GHz Pentium) and on bigger ones
> up to 100 times faster:
This seems to be extending the definition of "von Neumann" more than a
bit. If everything that fetches instructions and data is von Neumann, no
matter how parallel and how many heterogeneous instruction units, then
only a few weird dataflow and fpga-style architectures can be considered
non-von Neumann.
Or are you thinking from the software side, where almost all of the
parallel work that's being done is still essentially conceptualized as a
bunch of little (ahem) von Neumann machines working side by side either
in concert or conflict?
Paul Wallich wrote:
> This seems to be extending the definition of "von Neumann" more than a
> bit. If everything that fetches instructions and data is von Neumann, no
> matter how parallel and how many heterogeneous instruction units, then
> only a few weird dataflow and fpga-style architectures can be considered
> non-von Neumann.
>
> Or are you thinking from the software side, where almost all of the
> parallel work that's being done is still essentially conceptualized as a
> bunch of little (ahem) von Neumann machines working side by side either
> in concert or conflict?
From a software and hardware side. They behave like the diagram you can see
in the Wikipedia article:
http://en.wikipedia.org/wiki/Von_Neumann_architecture
Of course, there are lots of details, see e.g. this article:
http://developer.download.nvidia.com/compute/cuda/2_0/docs/NVIDIA_CUDA_Programming_Guide_2.0.pdf
But on page 16 (PDF file page 24) you can see that it is basicly just a
bunch of conventional Von Neumann machines.
There are really different concepts, which are not Von Neumann machines,
like Celluar Automata:
http://people.csail.mit.edu/nhm/cam8.pdf
Even Game of Live were proved to be turing complete, so in theory someone
could implements a general purpose computer with it. The advantage would
be, that you can expand it by just adding more cells. Maybe it would be
faster than classic computers.
Another nice idea: neuronal networks, e.g. implemented with the "zero
instruction set computer":
http://www.it.hiof.no/prosjekter/hoit/html/nr1_96/zisc036.html
I don't know of a dataflow computer, but sounds interesting.
FPGA style architectures are not a special kind of computer architecture,
but you could implement all the ideas presented above with FPGAs.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 20 Jul., 06:26, Nathan Stoddard <····@nathanstoddard.com> wrote:
> On Sun, 19 Jul 2009 18:55:51 +0200, Frank Buss wrote:
> > It's silly to say that Lisp is as bare to the metal as C.
>
> C is a good language for programming Von Neumann machines. However, it
> isn't good for other types of machines, such as Lisp machines. Lisp
> machines and other types of machines not yet invented cannot easily be
> programmed in C, but are easier to program in Lisp or perhaps languages
> for new paradigms.
In what way is a Lisp Machine not a von Neumann machine?
>
> These other types of machines are not popular now, but they will be in 50
> (or perhaps 100) years.
>
> --
> Nathan Stoddard,http://nathanstoddard.com
From: Pascal J. Bourguignon
Subject: Re: If Scheme is so good why MIT drops it?
Date:
Message-ID: <87prbwbjia.fsf@galatea.local>
A.L. <········@aol.com> writes:
> http://www.joelonsoftware.com/articles/CollegeAdvice.html
>
> I believe that this is not only about C. Anybody who wants to bear the
> label "Software Engineer" should know the "bare to metal" languages
> supporting essential programming paradigms: C, Lisp/Scheme and Prolog.
> Spolsky's comments apply also to Lisp and Prolog
Notice moreover that SICP is still required reading in some MIT
courses, and that projects are still to be done in scheme...
It's only to get newbies hooked that they decided that python was
better.
--
__Pascal Bourguignon__
On Jul 19, 10:27 am, Frank Buss <····@frank-buss.de> wrote:
>
> Of course, with Lispbuilder at least Common Lisp has catched up a bit for
> writing games :-)
>
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
See also: http://code.google.com/p/xmlisp/ for a way to make games and
simulations in Common Lisp including OpenGL, sound and speech ... (for
now OS X only)
Alex