A few questions, Alan Turing and LISP?
Weyoun7
sure and I know that the language they picked to program the robots in the
movie was LISP. Now I know LISP is a real programming language and that it was
developed for Artificial Intelligence programming. My questions are is LISP
dead? Is it better for AI than say C++ or even QBasic for that matter? I have
a copy of Common LISP it reminds of ASM. Am I right or wrong in making that
comparison?
Also has anyone used the CLIPS programming language developed and used by NASA?
I have the windows version of it 5.0 I think. It looks very interesting and
VERY different from something like C++.
And on another note, I was reading a few books the other day and came across
and oddity. I read that Alan Turing, the man behind the modeling computers
after human intelligence and the Turing test, killed himself by an overdose of
potsaaium cyanide in 1954. Is this correct and why would we hold the Turing
test with such high regard if the man who developed it was cracker jack?
Trying to understand the riddles of life,
-Justin R.
President of TRCY
james d. hunter
Well I don't know about the first questions; but if you hold
LISP in high regard, you shouldn't be calling Turing a
cracker jack.
TechnoCrate
>OK, I have watched the move Short Circuit well over 5 million times by now I'm
>sure and I know that the language they picked to program the robots in the
>movie was LISP. Now I know LISP is a real programming language and that it was
>developed for Artificial Intelligence programming. My questions are is LISP
>dead? Is it better for AI than say C++ or even QBasic for that matter? I have
>a copy of Common LISP it reminds of ASM. Am I right or wrong in making that
>comparison?
>
Lisp is for some reason ,unknown to me, popular in universaties where
ai programs are developed. Hofstadter/Mitchell made their Copycat
program in Lisp. Perhaps it's because the character of predicate logic
is so recognizable in Lisp, perhaps it's because of the fancy looking
parentheses (Lisp doesn't stand for LISt Processing as some believe
but for Lost In Stupid Parentheses ;-). It's also used to make little
programs within AutoCAD.
If you mean by ASM Assembly (or Assembler as some call it) then you're
wrong for comparing it to whatever high level language. Assembly is a
more workable representation of machine code (it's a 2nd generation
language, machine code is 1st gen, languages like C, Lisp, Pascal,
Modula, etc. are 3rd gen languages, SQL is 4th gen, English is 5th gen
:-). It truely is the mother of all computer languages but none of her
childs exceeds her in expressing power.
Donald Knuth.... (impressive silence ;-) has his examples in an
Assembly language (MIX, probably derived from the lousy 6502).
>And on another note, I was reading a few books the other day and came across
>and oddity. I read that Alan Turing, the man behind the modeling computers
>after human intelligence and the Turing test, killed himself by an overdose of
>potsaaium cyanide in 1954. Is this correct and why would we hold the Turing
>test with such high regard if the man who developed it was cracker jack?
>
Turing was a genius, he was also gay (in the homosexual sense of the
word). In the UK this was considered an illness and he received
medication for it which made him mentally unstable. I think the UK was
ill and Turing is still a genius.
>Trying to understand the riddles of life,
>-Justin R.
It's 42, and if you don't understand this answer then you didn't
understand the question ;-)
ri...@kana.stanford.edu
> Is lisp dead?
Believe it or not, LISP is still used in some of the most popular
oil industry exploration packages used in the world. This is due to that
that LISP graphics workstations (Symbolics, T.I.) preceded UNIX workstations
for several years in the 80s. And once you get some decent working software
in a system, it can be difficult to extract it. And LISP still has some nice
features hard to do in C++/Java/VB. I don't know how many other "early
adopters" of graphics workstations have LISP legacy code.
Thank deus MIT still uses a LISP variant as its introductory programming
language in 1999 as it did in 1970, or else I won't know how to have fixed
that legacy code :-) :-) :-)
(MIT faculty and students bitterly debate this every year. Students want
to learn the latest money-making language (its was PL1 in 1970 and Java today)
while faculty want to use something that maximizes teaching of computer
science.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
McMalo
I don't know what the Turing test is. May you illustrate me.
I believe that a human being is some kind of machine.
Not a computer-like one but a machine in the sense that
all his existence is 'inside' the domain of physics' laws.
Or in the other hand, it is a machine that has not found
yet its own nature. We could say a Number5 without
the files of his own circuits.
Fucking God (I don't believe) send us without a manula.
So, I human being has a limited power over itself.
Thats means that even a machine better that the media
of its production could have been overcomed for
the situation.
Turing was ...well. Turing. And everybody should learn
for the sake of science to separate the man from his work.
By the way: I don't think that we should consider the last word
about anything, just because he was ..well , he was Turing.
And I don't like gays. I don't hate them also.
Weyoun7 wrote in message <19990130174921...@ng120.aol.com>...
>OK, I have watched the move Short Circuit well over 5 million times by now
I'm
>sure and I know that the language they picked to program the robots in the
>movie was LISP. Now I know LISP is a real programming language and that it
was
>developed for Artificial Intelligence programming. My questions are is
LISP
>dead? Is it better for AI than say C++ or even QBasic for that matter? I
have
>a copy of Common LISP it reminds of ASM. Am I right or wrong in making
that
>comparison?
>
>Also has anyone used the CLIPS programming language developed and used by
NASA?
> I have the windows version of it 5.0 I think. It looks very interesting
and
>VERY different from something like C++.
>
>And on another note, I was reading a few books the other day and came
across
>and oddity. I read that Alan Turing, the man behind the modeling computers
>after human intelligence and the Turing test, killed himself by an overdose
of
>potsaaium cyanide in 1954. Is this correct and why would we hold the
Turing
>test with such high regard if the man who developed it was cracker jack?
>
>Trying to understand the riddles of life,
>-Justin R.
>President of TRCY
Gary H. Merrill
Weyoun7 wrote:
> OK, I have watched the move Short Circuit well over 5 million times by now I'm
> sure and I know that the language they picked to program the robots in the
> movie was LISP. Now I know LISP is a real programming language and that it was
> developed for Artificial Intelligence programming. My questions are is LISP
> dead? Is it better for AI than say C++ or even QBasic for that matter? I have
> a copy of Common LISP it reminds of ASM. Am I right or wrong in making that
> comparison?
LISP has evolved quite a bit over the years and is still very widely used in AI
applications. Its use is in fact broader than that. The newer versions and
implementations of list support a wide variety of language features (including
objects) and have large and sophisticated libraries supporting CORBA, database
access, GUI development, efficient compilers, etc. Unfortunately, these serious
LISP development environments can be quite expensive. To see the features and the
costs, take a look at http://www.harlequin.com or http://www.franz.com for sone
high-end sets of LISP products.
-- Gary Merrill
Gary H. Merrill
james d. hunter wrote:
>
>
> Well I don't know about the first questions; but if you hold
> LISP in high regard, you shouldn't be calling Turing a
> cracker jack.
LISP was implemented by McCarthy and is fundamentally a computer language
implementation of Church's Calculus of Lambda Conversion. What's the
connection to Turing?
-- Gary Merrill
Dean-Christian Strik
AI/ALife, and definitely NOT dead. The mini-howto lists some 'dialects':
ECoLisp [New]
Web site: www.di.unipi.it/~attardi/software.html
ECoLisp (Embeddable Common Lisp) is an implementation of Common Lisp
designed for being embeddable into C based applications. ECL uses standard C
calling conventions for Lisp compiled functions, which allows C programs to
easily call Lisp functions and viceversa. No foreign function interface is
required: data can be exchanged between C and Lisp with no need for
conversion. ECL is based on a Common Runtime Support (CRS) which provides
basic facilities for memory managment, dynamic loading and dumping of binary
images, support for multiple threads of execution. The CRS is built into a
library that can be linked with the code of the application. ECL is modular:
main modules are the program development tools (top level, debugger, trace,
stepper), the compiler, and CLOS. A native implementation of CLOS is
available in ECL: one can configure ECL with or without CLOS. A runtime
version of ECL can be built with just the modules which are required by the
application. The ECL compiler compiles from Lisp to C, and then invokes the
GCC compiler to produce binaries.
CLisp (Lisp)
FTP site: ftp://sunsite.unc.edu/pub/Linux/devel/lang/lisp/
CLISP is a Common Lisp implementation by Bruno Haible and Michael Stoll. It
mostly supports the Lisp described by 'Common LISP: The Language (2nd
edition)' and the ANSI Common Lisp standard. CLISP includes an interpreter,
a byte-compiler, a large subset of CLOS (Object-Oriented Lisp) , a foreign
language interface and, for some machines, a screen editor.
The user interface language (English, German, French) is chosen at run time.
Major packages that run in CLISP include CLX & Garnet. CLISP needs only 2 MB
of memory.
CMU Common Lisp
Web page: www.mv.com/users/pw/lisp/index.html
FTP site: sunsite.unc.edu/pub/Linux/devel/lang/lisp/
CMU Common Lisp is a public domain "industrial strength" Common Lisp
programming environment. Many of the X3j13 changes have been incorporated
into CMU CL. Wherever possible, this has been done so as to transparently
allow the use of either CLtL1 or proposed ANSI CL. Probably the new features
most interesting to users are SETF functions, LOOP and the
WITH-COMPILATION-UNIT macro.
GCL (Lisp)
FTP site: sunsite.unc.edu/pub/Linux/devel/lang/lisp/
GNU Common Lisp (GCL) has a compiler and interpreter for Common Lisp. It
used to be known as Kyoto Common Lisp. It is very portable and extremely
efficient on a wide class of applications. It compares favorably in
performance with commercial Lisps on several large theorem-prover and
symbolic algebra systems. It supports the CLtL1 specification but is moving
towards the proposed ANSI definition. GCL compiles to C and then uses the
native optimizing C compilers (e.g., GCC). A function with a fixed number of
args and one value turns into a C function of the same number of args,
returning one value, so GCL is maximally efficient on such calls. It has a
conservative garbage collector which allows great freedom for the C compiler
to put Lisp values in arbitrary registers.
It has a source level Lisp debugger for interpreted code, with display of
source code in an Emacs window. Its profiling tools (based on the C
profiling tools) count function calls and the time spent in each function.
--
Dean-Christian Strik ("Fluxen") -- de...@bigfoot.com -- ICQ #11760568
"Real programmers like vending machine popcorn. Coders pop it in the
microwave oven. Real programmers use the heat given off by the CPU. They can
tell what job is running just by listening to the rate of popping."
Weyoun7 wrote in message <19990130174921...@ng120.aol.com>...
>OK, I have watched the move Short Circuit well over 5 million times by now
I'm
>sure and I know that the language they picked to program the robots in the
>movie was LISP. Now I know LISP is a real programming language and that it
was
>developed for Artificial Intelligence programming. My questions are is
LISP
>dead? Is it better for AI than say C++ or even QBasic for that matter? I
have
>a copy of Common LISP it reminds of ASM. Am I right or wrong in making
that
>comparison?
>
james d. hunter
I didn't say that there was a connection. I'm just
conjecturing that that may be a fundamental
problem with LISP.
---
Jim
Gary H. Merrill
james d. hunter wrote:
Okay, I'm even *more* confused. Exactly *what* "may be a fundamental problem
with LISP"?
-- Gary Merrill
james d. hunter
The original concerned the appropriateness of LISP to AI.
It is my opinion that Turing is highly relevant to AI,
but that LISP is on its way out.
---
Jim
jem_mi...@hotmail.com
> > We will never know exactly why Turing killed himself or even if he did. If
> > he did, the
> > probable cause was that being homosexual in England in the 1950s, and being
> > convicted in court of that "offence", was perhaps enough to put him over the
> > edge.
[I just joined this thread. Apologies if this echoes someone else.]
It's interesting that in the original Turing Test,
the 'imitation game' he describes is such that one person (A) has to
decide, by teletype-type conversations with a man (B) and a woman (C),
which of his correspondents is a man, and which is a woman.
The man and woman are allowed to lie. The bloke might say he's got
long hair, for example (hey, this was 1949).
Now, he says, imagine a computer taking the place of one of the unseen
people, B or C: is a machine logically imaginable that would be
indistinguishable from B or C?
The original game was perhaps slyly tongue in cheek (sexual identity being
independent of biology?), but the story of his last few years alive makes
it bitterly, grotesquely ironic.
cheers,
John
ri...@kana.stanford.edu
> I don't know what the Turing test is. May you illustrate me.
A number of computer science inventions are attributed to Dr. Turing,
but the famous test is chatting over the InterNet.
He said if you couldn't tell whether whom you were communicating with
was a person or a machine, then if it were a machine, that machine would
be artificially intelligent. It is fairly obvious now when you are
talking to a machine such a search engine or store catalog.
They often give narrow or silly responses.
Most chat rooms and usenet newsgroups appear to be people, but who knows
for sure? What if someone successfully hooked up CYC or Jeeves to usenet,
participanting in intelligent and interesting discussions?
ri...@kana.stanford.edu
> Okay, I'm even *more* confused. Exactly *what* "may be a fundamental
problem
> with LISP"?
A "holy grail" throughout the history of philosophy has been a "magic
language" of power that would solve all our problems. These include the
magic incantations of shamans, the church languages of ancient Hebrew, Latin,
Sanskit, and Koranic Arabic, the clean-up languages logical positivism,
Principa Mathematica and so on. The modern version of this quest is the
perfect programming language for A.I., business, science, etc.
Sergio Navega
>
>> I don't know what the Turing test is. May you illustrate me.
>
>A number of computer science inventions are attributed to Dr. Turing,
>but the famous test is chatting over the InterNet.
>He said if you couldn't tell whether whom you were communicating with
>was a person or a machine, then if it were a machine, that machine would
>be artificially intelligent. It is fairly obvious now when you are
>talking to a machine such a search engine or store catalog.
>They often give narrow or silly responses.
>Most chat rooms and usenet newsgroups appear to be people, but who knows
>for sure? What if someone successfully hooked up CYC or Jeeves to usenet,
>participanting in intelligent and interesting discussions?
>
ERROR: UNDEFINED SITUATION (DISGUISE FOUND)
ECX=04D223 EDX=000234 ESI=032AD97 EDI=41233BB
STANDARD FIXUP TAKEN.
EXCEPTION PROCEDURE CALLED.
EXCEPTION PROCEDURE FAILED, TRYING HUMAN OPERATOR.
HUMAN OPERATOR NOT FOUND (GONE TO TAKE A LEAK).
CALLING NEAREST NEIGHBOR ON THE PHONE.
IRREGULAR WORDING FOUND DURING CONVERSATION WITH NEIGHBOR.
NEIGHBOR ORDERED TO STICK FINGER TO "..." AND SMELL IT.
STICK FOUND.
FINGER NOT FOUND.
LOOKING FOR "..."
Herr Konning
Dean-Christian Strik wrote:
> According to the AI-ALife mini-Howto, LISP is a very suitable language for
> AI/ALife, and definitely NOT dead. The mini-howto lists some 'dialects':
>
I liked LISP when I worked in an AI lab and took a number of classes all geared
around LISP. It was nice for modelling and I really would rather use LISP then
Perl for CGI scripting.
I think the fact that nobody uses LISP for CGI scripting, a task it would be
perfect for, shows the problem with LISP; generally real programmers just don't
use it. Because it is not used it is not learned and not learned means it is
not used any more. It has a niche for itself and it is as old as FORTRAN but it
still remains nothing much more then the language that AI researchers program
academic projects in.
LISP would, IMHO, be a perfect scripting language for CGI form post iff there
were LISP servers in regular use on ISPs. There are not LISP servers so people
write CGI in Perl which reads something like Martain. I once heard a commedian
reading Perl code in poetry form and it was very funny. But Perl is used
because it runs on almost every server in the Universe.
LISP can't even get a break when it deserves it. Its advantages could fill a
library and yet it does not seem to matter. Perhaps it is because the AI
community has not built enough bridges between itself and the entire computer
community. Scheme is a big intro teaching language and so many of the best
academically educated programmers will know LISP, but the computer revolution
is being driven by coders who did not major in computer science in college.
Gary H. Merrill
james d. hunter wrote:
> The original concerned the appropriateness of LISP to AI.
> It is my opinion that Turing is highly relevant to AI,
> but that LISP is on its way out.
So it is a *fundamental problem with LISP" thay your *opinion* is that "LISP is on
its way out"? Well, that's certainly an odd claim, to say the least. Anything to
base this opinion on?
-- Gary Merrill
Gary H. Merrill
ri...@kana.stanford.edu wrote:
> > Okay, I'm even *more* confused. Exactly *what* "may be a fundamental
> problem
> > with LISP"?
>
> A "holy grail" throughout the history of philosophy has been a "magic
> language" of power that would solve all our problems.
Don't try to teach your grandmother to suck eggs.
> These include the
> magic incantations of shamans, the church languages of ancient Hebrew, Latin,
> Sanskit, and Koranic Arabic, the clean-up languages logical positivism,
> Principa Mathematica and so on. The modern version of this quest is the
> perfect programming language for A.I., business, science, etc.
Nothing has been claimed about the "perfect programming language for A.I.,
business, science, etc.", though I would bet quite a great deal that I have much
more experience in these areas and their programming languages than you do. I've
written AI programs in LISP, PL/1 (yeah, believe it or not), SNOBOL, and C.
There are advantages and disadvantages to each. So what's your point? Somebody
seemed to be claiming something about a "fundamental problem with LISP". This
was not *my* phrase. I'm only wondering what this *fundamental* problem is. Do
you have anything to contribute to answering this question?
-- Gary Merrill
Gary H. Merrill
years I made my living as a language designer and compiler writer (in some sense I
still do), creating and maintaining production (that means *commercial*) compilers
and cross-compilers in a number of environments ranging from PCs through mainframes.
Herr Konning wrote:
> I liked LISP when I worked in an AI lab and took a number of classes all geared
> around LISP. It was nice for modelling and I really would rather use LISP then
> Perl for CGI scripting.
>
Good for you. As a programming language, LISP is wonderful in a variety of
respects. Perl, on the other hand, is a language for and by hackers, and should be
banished from the earth. If you are reading this and can't imagine why anyone would
say anything so awful about Perl, then you simply don't know much about programming
languages.
> I think the fact that nobody uses LISP for CGI scripting, a task it would be
> perfect for, shows the problem with LISP; generally real programmers just don't
> use it.
Well, there are lots of scripting languages. And there are lots of reasons for
choosing one over the others. Perl is very powerful in its pattern matching and
string handling capabilities, for example. On the other hand, on UNIX systems I
tend to use ksh because it is always there and is powerful enough for virtually all
the CGI needs I have. When these needs exceed the capabilitities of ksh I retreat
to C or Java. The group I work in finds Tcl to be their best choice. It's a good
language, but of course its use (like that of Perl for the most part) requires that
the Tcl interpreter be installed on the system. "Real programmers" don't use LISP
for several reasons. First, most computer students have a *hell* of a hard time
understanding and using LISP. Since I was trained as (and for a decade worked as) a
logician, LISP is quite natural to me. But I understand the problems that others
have with it. Second, what are you going to use for a LISP development
environment? Either you choose some freeware/shareware environment (which just
doesn't make it in corporate America) or you shell out quite big bucks for something
like Harlequin or Franz. And then they (Harlequin and Franz) want to impose
run-time royaltie on the software you create that requires their run-time
environment. These people are out of their minds. I can buy any C, C++, or Java
environment for a relatively low ($200-$800) one-time fee and have *no* constraints
imposed on my products. Likewise, use of ksh, Perl, Tcl, Rexx, etc. imposes no such
constraints. So why would I choose LISP? Would it be even *reasonable* for me to
choose LISP? Answer: no.
> Because it is not used it is not learned and not learned means it is
> not used any more. It has a niche for itself and it is as old as FORTRAN but it
> still remains nothing much more then the language that AI researchers program
> academic projects in.
Not so. In many places it *is* learned. And the contemporary versions are *very*
"modern" and powerful.
> LISP would, IMHO, be a perfect scripting language for CGI form post iff there
> were LISP servers in regular use on ISPs. There are not LISP servers so people
> write CGI in Perl which reads something like Martain. I once heard a commedian
> reading Perl code in poetry form and it was very funny. But Perl is used
> because it runs on almost every server in the Universe.
>
I don't have a clue what you mean by a "LISP server". Perl is free and you can
install it on a machine in a few minutes. A good LISP environment is very expensive
and comes with a lot of strings attached. A little marketing could go a long way in
making LISP more available and more likely to be used.
-- Gary Merrill
james d. hunter
I think the lack of much in the way of intelligent systems
written in LISP is more than sufficient support for that
claim.
---
Jim
Gary H. Merrill
james d. hunter wrote:
> I think the lack of much in the way of intelligent systems
> written in LISP is more than sufficient support for that
> claim.
>
> ---
> Jim
In that case I have to conclude that you have no idea of what you are
talking about.
-- Gary Merrill
james d. hunter
>
> james d. hunter wrote:
>
> > I think the lack of much in the way of intelligent systems
> > written in LISP is more than sufficient support for that
> > claim.
> >
>
> talking about.
Well, I am excluding the systems that
don't make it off the drawing board.
---
Jim
Rainer Joswig
> I think the fact that nobody uses LISP for CGI scripting,
Which is not true. A number of Scheme implementations are being
used for CGI scripting. For example we have built a complicated web site
with a simulation engine - all CGI stuff in Scheme.
We have written a web log analysis tool - the computation
stuff in Common Lisp and the CGI interface in Scheme.
Several web scripting systems borrow heavily from Lisp (Meta HTML, Rebol, ...).
> LISP would, IMHO, be a perfect scripting language for CGI form post iff there
> were LISP servers in regular use on ISPs. There are not LISP servers
Bill Clinton himself has a web site running on a Lisp machine:
http://www.pub.whitehouse.gov/WH/Publications/html/Publications.html
The server identifies himself:
Server Version: http/1.1
Date: Wed, 03 Feb 1999 09:35:14 GMT
Server: CL-HTTP/67.99 (Symbolics Common Lisp)
Content-type: text/html; charset=ISO-8859-1
Transfer-Encoding: CHUNKED
The server is completely written in Common Lisp and is publicly
available from the MIT AI Lab and runs in Common Lisps on Unix,
Lisp Machines, Windows and Macs:
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
Rainer Joswig
> Good for you. As a programming language, LISP is wonderful in a variety of
> respects. Perl, on the other hand, is a language for and by hackers,
Lisp is one of the original hacker languages. Read the Hacker's Dictionary.
> the Tcl interpreter be installed on the system. "Real programmers" don't use LISP
> for several reasons.
You mean the guys at Boeing who are designing jet turbines with Lisp
systems? Or the guys at Ford who are designing their cars with a Lisp
system? There are quite a few applications you probably have never heard of.
Like the guys at NASA who are scheduling their space missions (the latest
Mars mission) with a Lisp system.
> doesn't make it in corporate America) or you shell out quite big bucks for something
> like Harlequin or Franz.
LispWorks Professional is $800 for Windows.
> And then they (Harlequin and Franz) want to impose
> run-time royaltie on the software you create that requires their run-time
> environment.
LispWorks for Windows has no royalties.
> constraints. So why would I choose LISP?
If you have a difficult problem and you have little time, maybe.
> I don't have a clue what you mean by a "LISP server".
A web server written in pure Lisp, I guess.
For example see: http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
ri...@kana.stanford.edu
Cobol, BASIC- have acquired advanced programming features such as data
abstraction,
structures, class, bitmap/3D/GUI libraries and so on. So you can't judge
a language by its past.
On unmentioned feature of LISP is that programs and data have the same syntax,
so LISP programs can easily extend themselves as they run.
This is useful for A.I. where knowledge is a mix of data and procedure.
ri...@kana.stanford.edu
This is more general and powerful (when used) than conditional statements
and functions in other languages.
Perhaps only Prolog (does anyone use it?) has more explicit logic constructs
than LISP.
james d. hunter
>
> Another feature of LISP useful A.I. is built-in logic- the lambda calculas.
> This is more general and powerful (when used) than conditional statements
> and functions in other languages.
Well, with computer languages I've never been convinced that
more general implies more powerful is necessarily true.
---
Jim
TechnoCrate
>Most of the classic computer languages from the 50s and 60s- LISP, FORTRAN,
>Cobol, BASIC- have acquired advanced programming features such as data
>abstraction,
>structures, class, bitmap/3D/GUI libraries and so on. So you can't judge
>a language by its past.
>
>On unmentioned feature of LISP is that programs and data have the same syntax,
>so LISP programs can easily extend themselves as they run.
>This is useful for A.I. where knowledge is a mix of data and procedure.
>
But this is also a feature of C where functions are of a certain
returntype (any datatype). One of the features of Ansi C is that it is
the most portable language and I even dare to suggest that most
programmers can program in C which is more than I can say of LisP.
TechnoCrate
It's more like the opposite. The Assembly languages are the most
powerfull since compilers are still not able to improve the code of
the good Assembly programmers (after all: human programmers can
cheat). Besides: Assembly (apart from some secret code) covers all of
the capabilities of the targetted cpu while high level languages aim
at portability across several platforms.
Rainer Joswig
Which is not really true anymore. Some modern CPUs are so complicated
and really need optimizing compilers, because writing good
code is very hard to do by hand.
Jim Balter
>
> On Wed, 03 Feb 1999 14:24:02 GMT, ri...@kana.stanford.edu wrote:
>
> >Most of the classic computer languages from the 50s and 60s- LISP, FORTRAN,
> >Cobol, BASIC- have acquired advanced programming features such as data
> >abstraction,
> >structures, class, bitmap/3D/GUI libraries and so on. So you can't judge
> >a language by its past.
> >
> >On unmentioned feature of LISP is that programs and data have the same syntax,
> >so LISP programs can easily extend themselves as they run.
> >This is useful for A.I. where knowledge is a mix of data and procedure.
> >
> But this is also a feature of C where functions are of a certain
> returntype (any datatype).
Programs and data do not have the same syntax in C, in the sense
used here. In LISP, functions are data structures that can
be manipulated just like any other data. Nothing of the sort
is the case in C. That functions can be *referenced* with pointers
is not at all the same thing.
The degree of ignorance about computer languages being displayed
in this newsgroup is almost as great as the degree of ignorance
about neurophysiology, the mathematics of computation, and much else.
But, this being a philosophy group, I suppose it is understandable
that people don't feel they need to actually *know* anything about
a subject before making authoritative pronouncements.
> One of the features of Ansi C is that it is
> the most portable language and I even dare to suggest that most
> programmers can program in C which is more than I can say of LisP.
These claims, aside from being dubious, are complete non sequiturs.
--
<J Q B>
james d. hunter
That is the problem with newer CPUs. It's gotten so bad that
it's getting hard to find people that can do any assembler code
let alone good assembler code.
---
Jim
TechnoCrate
Joswig) wrote:
>In article <36b9800c...@news.euronet.nl>, usu...@euronet.nl (TechnoCrate) wrote:
>
>> On Wed, 03 Feb 1999 11:26:46 -0500, "james d. hunter"
>> <jim.h...@jhuapl.edu> wrote:
>>
>> >ri...@kana.stanford.edu wrote:
>> >>
>> >> Another feature of LISP useful A.I. is built-in logic- the lambda calculas.
>> >> This is more general and powerful (when used) than conditional statements
>> >> and functions in other languages.
>> >
>> > Well, with computer languages I've never been convinced that
>> > more general implies more powerful is necessarily true.
>> >
>> It's more like the opposite. The Assembly languages are the most
>> powerfull since compilers are still not able to improve the code of
>> the good Assembly programmers (after all: human programmers can
>> cheat). Besides: Assembly (apart from some secret code) covers all of
>> the capabilities of the targetted cpu
>
>Which is not really true anymore. Some modern CPUs are so complicated
>and really need optimizing compilers, because writing good
>code is very hard to do by hand.
The complexity of nowadays pipelined cpu's seems to work in the favour
of Assembly programmers since they design with the architecture of the
particular cpu in mind. A C programmer has not the detailed control
over the code which the Assembly programmer has and normally doesn't
think about particular cpu's or platforms since portability is the
important issue.
GNU's C compiler is ranked as one of the best optimizers, I tried it
out by making an expression containing five variables and about 20
logical operations. However: I arranged it in such a way that whatever
the values of the variables would be, the outcome would be always true
(non zero that is). The compiler had no trouble whatsoever to
recognize this fact and dismissed the entire condition (it even saw
that the variables weren't used anywhere else and didn't allocate
memory for it).
This is the kind of stuff optimizing compilers (all compilers
optimize) are good at and yet I was amazed to see how many stalls were
produced within the code. No major re-designing of the code had taken
place to avoid stalls, make parallel processing possible, etc. Also,
the compiler mostly failed to take advantage of features that are not
present in C but are present in the cpu (if you want to start a
flamewar in comp.lang.c then you should mention the carryflag :-)
Furthermore, the Assembly programmer can get the output of the
compiler and optimize it further (this is quite common). This is what
I meant by cheating :-)
Ofcourse: using a lousy operating system is a bigger bottleneck than
the shortcomings of compilers as opposed to Assembly programmers.
TechnoCrate
wrote:
>TechnoCrate wrote:
>>
>> On Wed, 03 Feb 1999 14:24:02 GMT, ri...@kana.stanford.edu wrote:
>> >On unmentioned feature of LISP is that programs and data have the same syntax,
>> >so LISP programs can easily extend themselves as they run.
>> >This is useful for A.I. where knowledge is a mix of data and procedure.
>> >
>> But this is also a feature of C where functions are of a certain
>> returntype (any datatype).
>
>Programs and data do not have the same syntax in C, in the sense
>used here. In LISP, functions are data structures that can
>be manipulated just like any other data. Nothing of the sort
>is the case in C. That functions can be *referenced* with pointers
>is not at all the same thing.
>
I was refering to the mix of data and procedure (this is even more
extended in C++). Not to the syntax. There are a lot of programming
languages out there where data and functions are strictly separated.
In C you can use a function as an expression (but never as lvalue), a
function evaluates to a value of the returntype of the function. This
is much like the list in LisP, for example: (+ 1 2) as opposed to
addthem(1,2); , both evaluate to 3 (if addthem() returns an integer,
namely the integer that is produced by adding its two arguments). A
problem in C is ofcourse that order of evaluation in the argumentlist
of a function is not standardized (perhaps C9X will do something about
this).
Ofcourse a variable in LisP can contain a list (this is why LisP is
mostly an interpreted language instead of one that is only once
compiled). In C we can have an array of functionpointers (as you
already noted) which are called in a proper order by another function.
We can achieve the same functionality with C but this is *very*
cumbersome and results in extreme obfuscated code. LisP's syntax lends
itself much more convenientaly to this kind of programming.
LisP lends itself splendidly for "self modifying" code. In C this
would take quite some effort. Ofcourse, in neither case will the code
modify itself. Nowadays' protected operating systems don't really like
self modifying code although there are often tricks to work around
this.
>The degree of ignorance about computer languages being displayed
>in this newsgroup is almost as great as the degree of ignorance
>about neurophysiology, the mathematics of computation, and much else.
>But, this being a philosophy group, I suppose it is understandable
>that people don't feel they need to actually *know* anything about
>a subject before making authoritative pronouncements.
>
Surely you can't be refering to me :-) I'm an old school programmer.
I do however sense some amount of grumpiness in this group. Perhaps
it's my english.
Gary H. Merrill
Rainer Joswig wrote:
> > It's more like the opposite. The Assembly languages are the most
> > powerfull since compilers are still not able to improve the code of
> > the good Assembly programmers (after all: human programmers can
> > cheat). Besides: Assembly (apart from some secret code) covers all of
> > the capabilities of the targetted cpu
>
> Which is not really true anymore. Some modern CPUs are so complicated
> and really need optimizing compilers, because writing good
> code is very hard to do by hand.
Uh ... yes and no. A good optimizing compiler can generate better code than most
programmers can. But it cannot generate better code than a good code generator writer can
by hand. Been there; done that. Writing good machine-level code is very hard to do by
hand. But you can still do a better job than an optimizing compiler can. It's just not
generally worth the effort -- but sometimes it is.
-- Gary Merrill
Gary H. Merrill
TechnoCrate wrote:
> GNU's C compiler is ranked as one of the best optimizers,
Ha! By whom?
> I tried it
> out by making an expression containing five variables and about 20
> logical operations. However: I arranged it in such a way that whatever
> the values of the variables would be, the outcome would be always true
> (non zero that is). The compiler had no trouble whatsoever to
> recognize this fact and dismissed the entire condition (it even saw
> that the variables weren't used anywhere else and didn't allocate
> memory for it).
>
This kind of trivial thing should be done by any commercial compiler.
> This is the kind of stuff optimizing compilers (all compilers
> optimize) are good at and yet I was amazed to see how many stalls were
> produced within the code. No major re-designing of the code had taken
> place to avoid stalls, make parallel processing possible, etc. Also,
> the compiler mostly failed to take advantage of features that are not
> present in C but are present in the cpu (if you want to start a
> flamewar in comp.lang.c then you should mention the carryflag :-)
>
Yeah, well ... don't make many generalizations from a compiler you get for free, eh?
-- Gary Merrill
Gary H. Merrill
Rainer Joswig wrote:
> Lisp is one of the original hacker languages. Read the Hacker's Dictionary.
>
Yeah, like that's an authority. I was speaking in terms of language design, not pop
computer culture.
> > the Tcl interpreter be installed on the system. "Real programmers" don't use LISP
> > for several reasons.
>
> You mean the guys at Boeing who are designing jet turbines with Lisp
> systems? Or the guys at Ford who are designing their cars with a Lisp
> system? There are quite a few applications you probably have never heard of.
> Like the guys at NASA who are scheduling their space missions (the latest
> Mars mission) with a Lisp system.
>
Don't imagine what I've never heard of.
> > doesn't make it in corporate America) or you shell out quite big bucks for something
> > like Harlequin or Franz.
>
> LispWorks Professional is $800 for Windows.
>
> > And then they (Harlequin and Franz) want to impose
> > run-time royaltie on the software you create that requires their run-time
> > environment.
>
> LispWorks for Windows has no royalties.
>
Look ... I've been negotiating with Harlequin for a number of months. Finally I gave up.
Are *you* fielding a commercial product using Harlequin? If so, I'd like to know the
details. Besides, the Professional edition is still pretty much amateur night for serious
applications. It's the Enterprise edition that has all the goodies. What do you know
about that? What if you want to create a production piece of software for a variety of
systems: NT, Win 95, Solaris, DEC Alpha UNIX, ... Do you know how you would go about
this with LispWorks? Do you know what the royalty arrangements would be? No decent
corporation will become involved in this if for no other reason that it potentially
exposes their books to inspection by Harlequin. The legal department just won't permit
it. End of story. (Plus, it is just ridiculous to use this marketing approach when it is
not used for *any* other languages. That was tried in the early 80s and abandoned.)
-- Gary Merrill
Gary H. Merrill
TechnoCrate wrote:
> But this is also a feature of C where functions are of a certain
> returntype (any datatype). One of the features of Ansi C is that it is
> the most portable language
I know exactly how portable C is. I've been writing C compilers since about 1982.
Try taking any nice windowing interface and porting it from, say, Motif to NT. Try
taking any nice file or database program and porting it from, say, NT to MVS. C is
a portable language if you use it to write portable code. To make any but the most
trivial C programs portable requires some degree of work.
> and I even dare to suggest that most
> programmers can program in C which is more than I can say of LisP.
But what follows from this? At a certain point in time, the same could be said
with 'BASIC' substituted for 'C' and 'C' substituted for 'LISP'. And I'm
reasonably sure that it is still true that most programmers can program in C, which
is more than I can say of Java. But in many respects, Java is a superior
language. If I take even reasonable care and write a sophisticated GUI in Java it
*will* be portable.
-- Gary Merrill
Jim Balter
>
> In article <36b99dde...@news.euronet.nl>, usu...@euronet.nl (TechnoCrate) wrote:
>
> > Ofcourse a variable in LisP can contain a list (this is why LisP is
> > mostly an interpreted language instead of one that is only once
> > compiled).
>
Unadulterated ignorance. LISP has had high quality compilers for
decades,
and the reasons for it being an interpreted language have nothing to do
with
the fact that a variable can contain a list (that's true of just about
any
language), but rather with the fact that the symbol table is available
at run-time and that code can be generated and executed at runtime.
The solution in compiled LISP systems is symply to include a compiler
and/or interpreter in the runtime system. Of course, this wasn't
practical
back when LISP was running on 20K machines like the IBM 1620 I started
programming
on, so it was strictly interpreted back then.
--
<J Q B>
Jim Balter
>
> On Wed, 03 Feb 1999 10:25:39 -0800, Jim Balter <j...@sandpiper.net>
> wrote:
>
> >TechnoCrate wrote:
> >>
> >> On Wed, 03 Feb 1999 14:24:02 GMT, ri...@kana.stanford.edu wrote:
> >> >On unmentioned feature of LISP is that programs and data have the same syntax,
> >> >This is useful for A.I. where knowledge is a mix of data and procedure.
> >> >
> >> returntype (any datatype).
> >
> >Programs and data do not have the same syntax in C, in the sense
> >used here. In LISP, functions are data structures that can
> >be manipulated just like any other data. Nothing of the sort
> >is the case in C. That functions can be *referenced* with pointers
> >is not at all the same thing.
> >
> I was refering to the mix of data and procedure (this is even more
> extended in C++). Not to the syntax.
"the mix of data and procedure" referred to *knowledge*, not programming
languages.
[blah blah blah]
> Ofcourse a variable in LisP can contain a list (this is why LisP is
> mostly an interpreted language instead of one that is only once
> compiled).
More ignorance (or obsolete "knowledge").
[blah blah blah]
--
<J Q B>
Rainer Joswig
> Ofcourse a variable in LisP can contain a list (this is why LisP is
> mostly an interpreted language instead of one that is only once
> compiled).
Can you explain that?
TechnoCrate
<gmer...@mindspring.com> wrote:
>
>
>TechnoCrate wrote:
>
>> GNU's C compiler is ranked as one of the best optimizers,
>
>Ha! By whom?
>
By the people of comp.lang.c for example
>> I tried it
>> out by making an expression containing five variables and about 20
>> logical operations. However: I arranged it in such a way that whatever
>> the values of the variables would be, the outcome would be always true
>> (non zero that is). The compiler had no trouble whatsoever to
>> recognize this fact and dismissed the entire condition (it even saw
>> that the variables weren't used anywhere else and didn't allocate
>> memory for it).
>>
>
>This kind of trivial thing should be done by any commercial compiler.
>
Well, the expression didn't look trivial to the human eye. Ofcourse it
was just an excercise in utilizing some predicate logic (DeMorgan,
distributivity and stuff). The stuff compilers are good at and humans
often fail to see.
>> This is the kind of stuff optimizing compilers (all compilers
>> optimize) are good at and yet I was amazed to see how many stalls were
>> produced within the code. No major re-designing of the code had taken
>> place to avoid stalls, make parallel processing possible, etc. Also,
>> the compiler mostly failed to take advantage of features that are not
>> present in C but are present in the cpu (if you want to start a
>> flamewar in comp.lang.c then you should mention the carryflag :-)
>>
>
>Yeah, well ... don't make many generalizations from a compiler you get for free, eh?
>
Although it is free (compare the free operating system Linux with not
free operating systems like MS windows 95 for example) it's still one
of the best.
TechnoCrate
wrote:
>Rainer Joswig wrote:
>>
>> In article <36b99dde...@news.euronet.nl>, usu...@euronet.nl (TechnoCrate) wrote:
>>
>> > Ofcourse a variable in LisP can contain a list (this is why LisP is
>> > mostly an interpreted language instead of one that is only once
>> > compiled).
>>
>> Can you explain that?
>
>Unadulterated ignorance. LISP has had high quality compilers for
>decades,
>and the reasons for it being an interpreted language have nothing to do
>with
>the fact that a variable can contain a list (that's true of just about
>any
>language), but rather with the fact that the symbol table is available
>at run-time and that code can be generated and executed at runtime.
Well put, Balter. Apart from the fact that most languages don't hold
lists in their variables and certainly don't evaluate that list as
_code_ on run time (that's the interpreted part we're both talking
about). It seems we're both equally ignorant :-)
Ofcourse, you can still do the same in C but it is cumbersome to do
so. Assembly is the number one choice for real self-modifying code.
>The solution in compiled LISP systems is symply to include a compiler
>and/or interpreter in the runtime system. Of course, this wasn't
>practical
>back when LISP was running on 20K machines like the IBM 1620 I started
>programming
>on, so it was strictly interpreted back then.
If that mainframe was new when you programmed on it then you must be
around 50 to 60 years old. (I don't think they allow a 10 year old to
toy with a room filling mainframe).
Some people may wonder why there are still BCD instructions around but
this machine really did its stuff decimal. Don't tell me you worked
with the LUT version.
TechnoCrate
<gmer...@mindspring.com> wrote:
>
>
>TechnoCrate wrote:
>
>> But this is also a feature of C where functions are of a certain
>> returntype (any datatype). One of the features of Ansi C is that it is
>> the most portable language
>
>I know exactly how portable C is. I've been writing C compilers since about 1982.
>Try taking any nice windowing interface and porting it from, say, Motif to NT. Try
>taking any nice file or database program and porting it from, say, NT to MVS. C is
>a portable language if you use it to write portable code. To make any but the most
>trivial C programs portable requires some degree of work.
>
The fact that virtually all C compilers nowadays support the Ansi C
standard already makes it possible to make most code of a general
program portable. General operating stuff can be handled by a number
of Posix standards but this is already less well supported (MS Windows
NT was forced to apply to Posix since the american government would
only take Posix compliant operating systems).
There's work on making a standard for GUI's.
I agree that Ansi C doesn't cover enough to make full blown programs
as we expect them nowadays (there's no mouse support, no graphics,
etc.).
>> and I even dare to suggest that most
>> programmers can program in C which is more than I can say of LisP.
>
>But what follows from this? At a certain point in time, the same could be said
>with 'BASIC' substituted for 'C' and 'C' substituted for 'LISP'. And I'm
>reasonably sure that it is still true that most programmers can program in C, which
>is more than I can say of Java. But in many respects, Java is a superior
>language. If I take even reasonable care and write a sophisticated GUI in Java it
>*will* be portable.
>
Well, this was about readability of code. Java might even be on more
machines than C and I agree that a C programmer shouldn't have too
much trouble in understanding a Java program (after all, it's somewhat
derived from C++).
I favoured C over Lisp for the reason that more people would be able
to try out the code and read it but now I think Java would even be
more appropriate.
TechnoCrate
<gmer...@mindspring.com> wrote:
>
>
>ri...@kana.stanford.edu wrote:
>
>> > Okay, I'm even *more* confused. Exactly *what* "may be a fundamental
>> problem
>> > with LISP"?
>>
>> A "holy grail" throughout the history of philosophy has been a "magic
>> language" of power that would solve all our problems.
>
>Don't try to teach your grandmother to suck eggs.
>
>> These include the
>> magic incantations of shamans, the church languages of ancient Hebrew, Latin,
>> Sanskit, and Koranic Arabic, the clean-up languages logical positivism,
>> Principa Mathematica and so on. The modern version of this quest is the
>> perfect programming language for A.I., business, science, etc.
>
>Nothing has been claimed about the "perfect programming language for A.I.,
>business, science, etc.", though I would bet quite a great deal that I have much
>more experience in these areas and their programming languages than you do. I've
>written AI programs in LISP, PL/1 (yeah, believe it or not), SNOBOL, and C.
>There are advantages and disadvantages to each. So what's your point? Somebody
>seemed to be claiming something about a "fundamental problem with LISP". This
>was not *my* phrase. I'm only wondering what this *fundamental* problem is. Do
>you have anything to contribute to answering this question?
>
Well, I don't think Lisp is flawed in any way (and certainly not for
what's it intended to be used for). The only fundamental problem I can
think of, or rather: a fundamental property of Lisp which could be
perceived as a problem, is the heavy use of parentheses which is often
a source of frustration.
BTW PL/1, is that Prolog?
Rainer Joswig
> about that? What if you want to create a production piece of software for a variety of
> systems: NT, Win 95, Solaris, DEC Alpha UNIX, ...
Commercial Lisps for Unix (Solaris, etc.) are very expensive, I agree.
The only solution I have found, is not to use a commercial Lisp
under Unix.
TechnoCrate
wrote:
>TechnoCrate wrote:
>>
>> On Wed, 03 Feb 1999 10:25:39 -0800, Jim Balter <j...@sandpiper.net>
>> wrote:
>>
>> >TechnoCrate wrote:
>> >>
>> >> On Wed, 03 Feb 1999 14:24:02 GMT, ri...@kana.stanford.edu wrote:
>> >> >On unmentioned feature of LISP is that programs and data have the same syntax,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> >so LISP programs can easily extend themselves as they run.
>> >> >This is useful for A.I. where knowledge is a mix of data and procedure.
>> >> >
>> >> But this is also a feature of C where functions are of a certain
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> returntype (any datatype).
>> >
>> >Programs and data do not have the same syntax in C, in the sense
>> >used here. In LISP, functions are data structures that can
>> >be manipulated just like any other data. Nothing of the sort
>> >is the case in C. That functions can be *referenced* with pointers
>> >is not at all the same thing.
>> >
>> I was refering to the mix of data and procedure (this is even more
>> extended in C++). Not to the syntax.
> ^^^^^^^^^^^^^^^^^
>
>"the mix of data and procedure" referred to *knowledge*, not programming
>languages.
>
Yes, and expressions in C can be functions (a=func(b); for example).
One can use functions as data which (quoting) is usefull in A.I..
Lisp certainly has the same syntax for data and procedure but the mix
of data and procedure is also possible in C (and a number of other
languages).
>[blah blah blah]
>
Speak up Balter, I can't understand you if you murmur.
>> Ofcourse a variable in LisP can contain a list (this is why LisP is
>> mostly an interpreted language instead of one that is only once
>> compiled).
>
>More ignorance (or obsolete "knowledge").
>
>[blah blah blah]
Hehe, you make me smile Jimmy. You remind me of somebody called Scott
Nudds, a beginner DOS programmer who just mastered some 8086 Assembly
and challenged the entire comp.lang.c group by constantly repeating:
"The portability of C is both a scam and a myth".
Ofcourse, no one took him seriously :-)
Rainer Joswig
> Well put, Balter. Apart from the fact that most languages don't hold
> lists in their variables and certainly don't evaluate that list as
> _code_ on run time (that's the interpreted part we're both talking
> about).
You seem to be confused by the definition of "interpretive".
There are certain Lisp systems which don't have an
interpreter at all. Still some of them can generate and execute
code at runtime.
Many Lisp systems have a interpreter and a compiler and
can mix interpreted with compiled code freely. Many
of them have the compiler available at runtime, so
you can generate new code and compile it at runtime.
But this is often only used in the development environment
or certain application types (applications with scripting
capabilities like some CAD systems, for example).
ri...@kana.stanford.edu
> It's more like the opposite. The Assembly languages are the most
> powerfull since compilers are still not able to improve the code of
> the good Assembly programmers (after all: human programmers can
> cheat). Besides: Assembly (apart from some secret code) covers all of
> at portability across several platforms.
I completely disagree. Power == elegance or terseness.
A well designed language/library you can do a lot by writing a little.
Also geneally makes commercial support, which is 75-90% of the effort,
easier because that directly porportional to size of the code.
ri...@kana.stanford.edu
(which to some masochists and gnurds find a turn-on),
but it twists my mind whenever I need to re-visit the language.
Most subsequent (post-1958) languages have followed the block-line verb-object
syntax introduced in Algol and quickly put into FORTRAN IV.
But remember LISP was about the 3rd non-assembly language invented,
just after COBOL and simultaneous with FORTRAN, so there wasn't a lot of
examples then.
Also it was fairly efficient for the computers and compilers of the time.
As each parentheses set was closed, that group of statements would be
evaluated or stored as a lambda subroutine. This resulted in fairly quick
debugging and development compared to a batch compiled language.
There were some LISP variants that tried to drop the parentheses, and editors
such as emacs that keep track of them for you, but this feature remains.
ri...@kana.stanford.edu
> Commercial Lisps for Unix (Solaris, etc.) are very expensive, I agree.
> The only solution I have found, is not to use a commercial Lisp
> under Unix.
But non-commercially, lisp was the 3rd language available for UNIX after
C and FORTRAN, circa 1975, because the emacs hackers needed it.
The late 70s the A.I. community hypothesized a hardware LISP computer, running
a 1000
times faster than then interpreted LISP would solve A.I.'s bottlenecks.
(Subsequently found not to be the bottleneck.) Just about that time Mead of
CalTech and Conway of Xerox computerized circuit design, so the MIT AI lab,
Symbolics, and T.I. built hardware LISP machines. These turned out to be
the first commercial graphics workstations, (following the non-commerical
Xerox machines and preceding the early UNIX workstations).
However, clever compiler designers found you could emulate LISP machines
in generic microprocessors, and this killed the LISP machine market.
A custom LISP CPU took 2-3 for new gneration and could not keep up with
the yearly advance in Intel and Motorola machines.
TechnoCrate
Joswig) wrote:
>In article <36ba6067...@news.euronet.nl>, usu...@euronet.nl (TechnoCrate) wrote:
>
>> Well put, Balter. Apart from the fact that most languages don't hold
>> lists in their variables and certainly don't evaluate that list as
>> _code_ on run time (that's the interpreted part we're both talking
>> about).
>
>You seem to be confused by the definition of "interpretive".
>There are certain Lisp systems which don't have an
>interpreter at all. Still some of them can generate and execute
>code at runtime.
>
That's what is meant by interpreting. Lisp code is interpreted at run
time. You could also say that it is being parsed or compiled at run
time.
The distinction between compilation and interpretation is a subtle
one:
-compilation: source code is being transformed into an executable, the
source code is no longer available in the executable program, it was
translated into machinecode
-interpretation: at runtime the source code is either parsed into
operations (carried out in machinecode as goes for everything) or
compiled and run. In both cases the sourcecode is used at runtime
where in compiled programs the sourcecode was only once used for the
translation to the executable.
So, the big distinction here is the use of sourcecode at runtime.
Sure, interpreted languages like Lisp can be performed by runtime
compilation but it's still an interpreted program which offers the
feature of no distinction between data and procedure. In one case
we're assembling a list as if it is data and in the other case we have
that list evaluated.
Rainer Joswig
> The distinction between compilation and interpretation is a subtle
> one:
Your application of your definition to Lisp is a bit unusual.
> -compilation: source code is being transformed into an executable, the
> source code is no longer available in the executable program, it was
> translated into machinecode
This is nowadays often the case with Lisp.
> -interpretation: at runtime the source code is either parsed into
> operations (carried out in machinecode as goes for everything) or
> compiled and run. In both cases the sourcecode is used at runtime
> where in compiled programs the sourcecode was only once used for the
> translation to the executable.
"Usually" one would say, that an interpreter uses
an immediate representation of the source code (not
necessarily the source code itself.
Interpreter
-----------
load time:
Source is Text
-> parsed and transformed by a reader
-> interned representation as datastructures
(lists, symbols, numbers, strings, etc.)
run time:
The Interpreter executes the interned representation
-> macro expansion and traversal of the interned representation
and executing it
Compiler
--------
A compiler generates code from a source representation
(text) for a machine (virtual or physical).
The steps:
compile time:
Source as text
-> parsed and transformed by a reader
-> interned representation as datastructures
(lists, symbols, numbers, strings, etc.)
->
Source as interned representation
-> macro expansion
-> compilation creates machine code
load time:
- text source is compiled as above or binary code is
loaded and linked
run time:
- machine code gets executed
---------
So, for interpreted Lisp code to run, an interned representation
of the source code is necessary.
For compiled Lisp code to run, only the machine code is necessary.
This is quite common for Lisp systems nowadays.
If I say (compile-file "my-code.lisp") and (load "my-code.pfsl")
I don't need any source at runtime.
If I say (compile nil '(lambda () (+ 1 2))) I don't need
the source code to run the generated code.
So, generally the distinction between "interpreted languages"
and "compiled languages" is not useful.
Especially for Lisp systems which are offering incremental
compilers, batch compilers, compilers who do whole-program
analysis, etc.
Jim Balter
>
> On Wed, 03 Feb 1999 21:50:31 -0500, "Gary H. Merrill"
> <gmer...@mindspring.com> wrote:
>
> >
> >
> >TechnoCrate wrote:
> >
> >> GNU's C compiler is ranked as one of the best optimizers,
> >
> >Ha! By whom?
> >
> By the people of comp.lang.c for example
Once upon a time, long long ago, that was a place for professional
programmers to exchange ideas and information. Nowadays, it's mostly
populated by ignorant newbies.
> Although it is free (compare the free operating system Linux with not
> free operating systems like MS windows 95 for example) it's still one
> of the best.
This was true when the GNU compiler was first developed; these days,
it's a dog compared to most commercial compilers. GNU C will begin to
improve again
now that it is open sourced under EGCS, but only time will tell.
--
<J Q B>
Jim Balter
>
> On Wed, 03 Feb 1999 22:45:56 -0800, Jim Balter <j...@sandpiper.net>
> wrote:
>
> >Rainer Joswig wrote:
> >>
> >> In article <36b99dde...@news.euronet.nl>, usu...@euronet.nl (TechnoCrate) wrote:
> >>
> >> > mostly an interpreted language instead of one that is only once
> >> > compiled).
> >>
> >
> >Unadulterated ignorance. LISP has had high quality compilers for
> >decades,
> >and the reasons for it being an interpreted language have nothing to do
> >with
> >the fact that a variable can contain a list (that's true of just about
> >any
> >language), but rather with the fact that the symbol table is available
> >at run-time and that code can be generated and executed at runtime.
> lists in their variables
That is simply false, as I said.
> and certainly don't evaluate that list as
> _code_ on run time
*That's* the issue, and is totally separate.
> (that's the interpreted part we're both talking
> about).
But it *isn't* what you said.
> It seems we're both equally ignorant :-)
Hardly.
> Ofcourse, you can still do the same in C but it is cumbersome to do
> so.
No, you can't do it at all, since the *source code* isn't available
and cannot be reconstructed. And you can't even get to the binary
under ANSI rules.
> Assembly is the number one choice for real self-modifying code.
No, LISP is the number one choice. Sheesh.
[reference to IBM 1620]
> If that mainframe was new when you programmed on it then you must be
> around 50 to 60 years old. (I don't think they allow a 10 year old to
> toy with a room filling mainframe).
It wasn't quite new when I worked on it in high school, and why does
that matter?
> Some people may wonder why there are still BCD instructions around but
> this machine really did its stuff decimal. Don't tell me you worked
> with the LUT version.
Yes, I did boolean operations by storing a 0 in location 311, so that
1+1=0.
--
<J Q B>
Jim Balter
> BTW PL/1, is that Prolog?
About as much as COBOL is C++.
I think this conversation has hit rock bottom.
Let's take it to alt.newbie.ignorance.programminglanguages
--
<J Q B>
Jim Balter
> Yes, and expressions in C can be functions (a=func(b); for example).
That's a function *call*.
> One can use functions as data which (quoting) is usefull in A.I..
Uh, no, one can't.
--
<J Q B>
TechnoCrate
Joswig) wrote:
>In article <36b9b36d...@news.euronet.nl>, usu...@euronet.nl (TechnoCrate) wrote:
>
>> The distinction between compilation and interpretation is a subtle
>> one:
>
>Your application of your definition to Lisp is a bit unusual.
>
>> -compilation: source code is being transformed into an executable, the
>> source code is no longer available in the executable program, it was
>> translated into machinecode
>
>This is nowadays often the case with Lisp.
>
Hmm, amazing how time flies. Perhaps I'm not sufficiently keeping
track of all progress.
>> -interpretation: at runtime the source code is either parsed into
>> operations (carried out in machinecode as goes for everything) or
>> compiled and run. In both cases the sourcecode is used at runtime
>> where in compiled programs the sourcecode was only once used for the
>> translation to the executable.
>
>"Usually" one would say, that an interpreter uses
>an immediate representation of the source code (not
>necessarily the source code itself.
>
Granted, even in the good old days source code was "tokenized" for
faster interpretation. But it's still interpreted.
>Interpreter
>-----------
[ snipped stuff that seems to make sense, regrettably :-( ]
>So, for interpreted Lisp code to run, an interned representation
>of the source code is necessary.
>
>For compiled Lisp code to run, only the machine code is necessary.
>This is quite common for Lisp systems nowadays.
>If I say (compile-file "my-code.lisp") and (load "my-code.pfsl")
>I don't need any source at runtime.
>
>If I say (compile nil '(lambda () (+ 1 2))) I don't need
>the source code to run the generated code.
>
>
>So, generally the distinction between "interpreted languages"
>and "compiled languages" is not useful.
>
I see.... I guess I have to be thankfull for having acquired better
insight now.
[ attention, increased level of factor sierra hotel alfa mike echo,
tresholds violated, evasive action elicited, compensating now...]
Nice homepage by the way. German hu? I'm so sorry to hear about "die
Mannschaft" (well, I guess it should be "der" but they're not living
up to it). Luckily they are nowadays beaten before they deserve the
right to meet "oranje". After all: having the "Reichsadler" eaten
alive by our dutch lion would be an embarrassement "der Heimat" could
well do without ;-)
[ warning! false sense of victory perceived, based on irrational
nationalism rather than common sense, ignoring origin, keeping signal,
victory perceived, compensation accomplished, feeling better :-) ]
Ah, perhaps it's time to change my handle again ;-)
TechnoCrate
wrote:
>TechnoCrate wrote:
>>
>> It seems we're both equally ignorant :-)
>
>Hardly.
>
Don't be so hard on yourself
>> Ofcourse, you can still do the same in C but it is cumbersome to do
>> so.
>
>No, you can't do it at all, since the *source code* isn't available
>and cannot be reconstructed. And you can't even get to the binary
>under ANSI rules.
>
Nope, but you can construct arrays of function pointers which are
called in some proper order. Ofcourse, to keep the flexibility of Lisp
lists they should all accept a variable number of arguments and there
needs to be a function calling these functions in the proper order
(evaluating from inwards). Every function of that array evaluates to
some value that can be used as argument by other functions.
You could make a function for every operation that can be carried out
by the processor and get an extremely lousy "self-modifying" program
under Ansi C.
I already noted it was cumbersome :-)
>> Assembly is the number one choice for real self-modifying code.
>
>No, LISP is the number one choice. Sheesh.
>
Only in Assembly you get absolute control over the executable.
Ofcourse many believe it's too hard to master it in such a degree that
the code is better than the code produced by compilers/interpreters.
>[reference to IBM 1620]
>
>> If that mainframe was new when you programmed on it then you must be
>> around 50 to 60 years old. (I don't think they allow a 10 year old to
>> toy with a room filling mainframe).
>
>It wasn't quite new when I worked on it in high school, and why does
>that matter?
>
It's a strategic thing, has to do with approach. In order to produce
successfull behaviour one needs at least a good mental representation
of the situation which guides the eliciting of behaviour.
Although behaviour is tuned to the mental representation (internal
state does the eliciting) we're also aware of the possible benefits of
producing behaviour that _might_ be justified within the mental
representation of the situation (by association). But this behaviour
needs to be justified by the mental representation before we can
produce it with a reasonable risk of failure (the risk is ofcourse
product of evaluation). We need to actively provide more information
to the mental representation. This might be done by focusing attention
but in addition to this we're also aware of the fact that we can
provoke the revelation of instrumental facts by exploration (a more
active form of attention one could argue). Ofcourse there's more to
the production of mental representation than this (quite more) but it
suffices to answer your question.
You see, there are two attractive (to me) acts I can perform but I
simply lack the information to choose between them. Here's a taste of
the two of them:
"Listen kid, I was tapping in machine code by hand while you were
still a sleezy thought in your father's mind. So don't give me any
lip, you milk mouth."
"Look gramps, that might have been great in the hay days of the 4040
but time has progressed since then and your ramblings are of no
interest anymore whatsoever unless you're interested in nostalgia. So
shut your teethless mouth and stop boring us with this obsolete
nonsense"
You see? You see? Knowing whether you're considerable older or younger
than me really gives me an edge in winning an argument on aesthetical
grounds ;-)
TechnoCrate
wrote:
>TechnoIgnoramus wrote:
>
>> Yes, and expressions in C can be functions (a=func(b); for example).
>
>That's a function *call*.
>
Yes, it's a function call and therefor an expression
A7.3.2 Function Calls
A function call is a postfix expression, called the function
designator, followed by parentheses containing a possibly empty,
comma-separated list of assignment expressions (A7.17), which
constitute the arguments to the function... etc.etc.
You can look it up in K&R2, page 200, Appendix A section 7 which is
called "Expressions".
>> One can use functions as data which (quoting) is usefull in A.I..
>
>Uh, no, one can't.
A function call is an expression (unless you want to prove Kernighan
and Ritchie wrong) and therefor evaluates to a value. So, function
calls evaluate to a value much like the list in Lisp.
TechnoCrate
wrote:
>TechnoCrate wrote:
>>
>> On Wed, 03 Feb 1999 21:50:31 -0500, "Gary H. Merrill"
>> <gmer...@mindspring.com> wrote:
>>
>> >
>> >
>> >TechnoCrate wrote:
>> >
>> >> GNU's C compiler is ranked as one of the best optimizers,
>> >
>> >Ha! By whom?
>> >
>> By the people of comp.lang.c for example
>
>Once upon a time, long long ago, that was a place for professional
>programmers to exchange ideas and information. Nowadays, it's mostly
>populated by ignorant newbies.
>
Those programmers are now mostly occupying comp.lang.c.moderated but
they still think GNU's C is one of the best optimizers, mostly because
you can set how there should be optimized.
Jim Balter
>
> On Thu, 04 Feb 1999 11:09:55 -0800, Jim Balter <j...@sandpiper.net>
> wrote:
>
> >TechnoIgnoramus wrote:
> >
> >> Yes, and expressions in C can be functions (a=func(b); for example).
> >
> >That's a function *call*.
> >
> Yes, it's a function call and therefor an expression
I didn't question that it is an expression; the point is that
*functions*,
and not just function *calls*, can be data in LISP.
> >> One can use functions as data which (quoting) is usefull in A.I..
> >
> >Uh, no, one can't.
> A function call is an expression (unless you want to prove Kernighan
> and Ritchie wrong) and therefor evaluates to a value. So, function
> calls evaluate to a value much like the list in Lisp.
In LISP a *function*, not just the value of a function *call*,
can be data. The value of a function call can of course be
used as data in any language; like, duh.
--
<J Q B>
Jim Balter
> Those programmers are now mostly occupying comp.lang.c.moderated but
> they still think GNU's C is one of the best optimizers, mostly because
> you can set how there should be optimized.
Only a tiny fraction of all professional C programmers inhabit c.l.c.m,
those who do are a skewed sample with a disproportionate percentage
of GNU C users, you have no statistics showing what percentage of those
think that "GNU's C is one of the best optimizers", and the issue at
hand
was not how many command line options the optimizer has, but rather the
quality of its optimization, and its ability to eliminate expressions
with constant values. And since that is a particularly trivial
optimization
(you could have used 200 operators and 50 variables, and it wouldn't
have been any tougher), it isn't even a measure of optimizer quality
in the first place. OTOH, it failed your own measure of quality:
[TechnoCrate]
> This is the kind of stuff optimizing compilers (all compilers
> optimize) are good at and yet I was amazed to see how many stalls were
> produced within the code. No major re-designing of the code had taken
> place to avoid stalls, make parallel processing possible, etc. Also,
> the compiler mostly failed to take advantage of features that are not
> present in C but are present in the cpu (if you want to start a
> flamewar in comp.lang.c then you should mention the carryflag :-)
[Merrill]
>Yeah, well ... don't make many generalizations from a compiler you get for free, eh?
[TechnoCrate]
> Although it is free (compare the free operating system Linux with not
> free operating systems like MS windows 95 for example) it's still one
> of the best.
So what we have here is just a simple contradiction, and a lot of
blabber,
since there *are* optimizers that take full advantage of CPU features.
Anyway, this is completely and utterly off topic.
--
<J Q B>
Gary H. Merrill
TechnoCrate wrote:
> BTW PL/1, is that Prolog?
Surely you toy with this old man, grasshopper.
-- Gary Merrill
Gary H. Merrill
Rainer Joswig wrote:
> In article <36B90D17...@mindspring.com>, gmer...@mindspring.com wrote:
>
> > about that? What if you want to create a production piece of software for a variety of
> > systems: NT, Win 95, Solaris, DEC Alpha UNIX, ...
>
> Commercial Lisps for Unix (Solaris, etc.) are very expensive, I agree.
> The only solution I have found, is not to use a commercial Lisp
> under Unix.
>
Well, do you have any suggestions? One problem is that having a simple Lisp
interpreter/compiler system is not enough. What is attractive about the Harlequin Enterprise
product, for example, is that it has a knowledge base construction component, database access
modules, CORBA support, GUI development support, etc. I do *not* want to spend my time
writing a KBS development system -- that's not what I get paid for, however entertaining it
might be. Similarly for GUI development. That's why I buy JBuilder instead of writing my own
Java development environment. I'm happy to run a development environment on either UNIX or NT
(I'm not an ideological bigot of either). But if I am creating products for use on these
systems then I need compilers for all of the appropriate targets -- which in my case means *at
least* NT, DEC Alpha UNIX (my own development system), and Solaris (the server system
preferred by the company). When I asked Harlequin if they had cross-compilers the answer was
a pause and then "Uh, no." Okay. My company has deep pockets. I could easily spend several
thousand dollars for a software development system without blinking an eye. But it has to do
what I want and it has to have no strings attached. In fact, I could easily spend $10K or
more for the right system.
By the way, the Harlequin system is still pretty amateurish compared to contemporary
development systems such as Visual C++, VisualAge, JBuilder, etc. It suffers very much from
its history and design philosophy as a UNIX product intended primarily for research and
academic pursuits. Basically it is still a command line system with windows grafted onto it.
Objectively speaking, the interface and debugging capabilities are pathetic compared to what
developers should expect today. And the integration of its NT version with NT is at points
laughable (and at other points utterly frustrating). I've passed on a detailed evaluation of
this to Harlequin, of course (a lot of high-priced consulting and product evaluation for free
from me). I would still buy the product (even just for my Alpha) if I were convinced it
really worked and they would drop the idiotic royalty constraints.
So what do you suggest as an alternative?
-- Gary Merrill
Herr Konning
Gary H. Merrill wrote:
> I've just got to comment on this. Let me begin by saying that for over fifteen
> years I made my living as a language designer and compiler writer (in some sense I
> still do), creating and maintaining production (that means *commercial*) compilers
> and cross-compilers in a number of environments ranging from PCs through mainframes.
>
> Herr Konning wrote:
>
> > I liked LISP when I worked in an AI lab and took a number of classes all geared
> > around LISP. It was nice for modelling and I really would rather use LISP then
> > Perl for CGI scripting.
> >
>
> Good for you. As a programming language, LISP is wonderful in a variety of
> respects. Perl, on the other hand, is a language for and by hackers, and should be
> banished from the earth. If you are reading this and can't imagine why anyone would
> say anything so awful about Perl, then you simply don't know much about programming
> languages.
>
Didn't I just write I would rather use Lisp then Perl. Yes I did: "and I really would
rather use LISP then
Perl for CGI scripting." So you saying that I can't imagine the very point I was making?
> > Because it is not used it is not learned and not learned means it is
> > not used any more. It has a niche for itself and it is as old as FORTRAN but it
> > still remains nothing much more then the language that AI researchers program
> > academic projects in.
>
> Not so. In many places it *is* learned. And the contemporary versions are *very*
> "modern" and powerful.
Its just not used enough day to day to become a natural language for programmers.
>
>
> > LISP would, IMHO, be a perfect scripting language for CGI form post iff there
> > were LISP servers in regular use on ISPs. There are not LISP servers so people
> > write CGI in Perl which reads something like Martain. I once heard a commedian
> > reading Perl code in poetry form and it was very funny. But Perl is used
> > because it runs on almost every server in the Universe.
> >
>
> I don't have a clue what you mean by a "LISP server". Perl is free and you can
> install it on a machine in a few minutes. A good LISP environment is very expensive
> and comes with a lot of strings attached. A little marketing could go a long way in
> making LISP more available and more likely to be used.
>
LISP server = server written in LISP.
> -- Gary Merrill
Herr Konning
Rainer Joswig wrote:
> In article <36B7A8FD...@nospamalo.com>, Herr Konning <rho...@nospamalo.com> wrote:
>
> > I think the fact that nobody uses LISP for CGI scripting,
>
> Which is not true. A number of Scheme implementations are being
> used for CGI scripting. For example we have built a complicated web site
> with a simulation engine - all CGI stuff in Scheme.
> We have written a web log analysis tool - the computation
> stuff in Common Lisp and the CGI interface in Scheme.
>
I'm happy to hear I cam wrong. Please include URLs so I can learn more.
> Several web scripting systems borrow heavily from Lisp (Meta HTML, Rebol, ...).
>
> > LISP would, IMHO, be a perfect scripting language for CGI form post iff there
> > were LISP servers in regular use on ISPs. There are not LISP servers
>
> Bill Clinton himself has a web site running on a Lisp machine:
>
> http://www.pub.whitehouse.gov/WH/Publications/html/Publications.html
>
> The server identifies himself:
>
> Server Version: http/1.1
> Date: Wed, 03 Feb 1999 09:35:14 GMT
> Server: CL-HTTP/67.99 (Symbolics Common Lisp)
> Content-type: text/html; charset=ISO-8859-1
> Transfer-Encoding: CHUNKED
>
> The server is completely written in Common Lisp and is publicly
> available from the MIT AI Lab and runs in Common Lisps on Unix,
> Lisp Machines, Windows and Macs:
>
> http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
>
> --
> http://www.lavielle.com/~joswig
Thank you very much. I have heard myths about the server. Thing is, are their any ISP
that run this thing that I could rent space on?
Jim Balter
>
> My God! You have redirected responses to your post to comp.lang.c!!!
>
> Already one of my posts has ended up there and one of Merrill as well.
> This could result in a flame war between c.a.p and c.l.c (the people
> at c.l.c are nuts, even more than those of c.a.p!)
>
> The last major flame war with c.l.c resulted in the moderation of
> c.l.a.x86
>
> People,
>
> Do NOT respond to Balter's post without setting the targetted
> newsgroup back to comp.ai.philosophy. Balter's post redirects
> responses to comp.lang.c!
I redirected it there because that's where it belongs.
--
<J Q B>
Jim Balter
>
> Gary H. Merrill wrote:
>
> > I've just got to comment on this. Let me begin by saying that for over fifteen
> > years I made my living as a language designer and compiler writer (in some sense I
> > still do), creating and maintaining production (that means *commercial*) compilers
> > and cross-compilers in a number of environments ranging from PCs through mainframes.
> >
> > Herr Konning wrote:
> >
> > > I liked LISP when I worked in an AI lab and took a number of classes all geared
> > > around LISP. It was nice for modelling and I really would rather use LISP then
> > > Perl for CGI scripting.
> > >
> >
> > Good for you. As a programming language, LISP is wonderful in a variety of
> > respects. Perl, on the other hand, is a language for and by hackers, and should be
> > banished from the earth. If you are reading this and can't imagine why anyone would
> > say anything so awful about Perl, then you simply don't know much about programming
> > languages.
> >
>
> Didn't I just write I would rather use Lisp then Perl. Yes I did: "and I really would
> rather use LISP then
> Perl for CGI scripting." So you saying that I can't imagine the very point I was making?
Since the correct English word here is "than", not "then",
Merrill may have misread you as saying "then [use] Perl for CGI
scripting".
> > > Because it is not used it is not learned and not learned means it is
> > > not used any more. It has a niche for itself and it is as old as FORTRAN but it
> > > still remains nothing much more then the language that AI researchers program
> > > academic projects in.
> >
> > Not so. In many places it *is* learned. And the contemporary versions are *very*
> > "modern" and powerful.
>
> Its just not used enough day to day to become a natural language for programmers.
What sort of nonsense is this? LISP is used day to day by many
programmers;
for them, it is a natural language. Even Perl can become "natural",
although
Merrill is right that it is a design abomination. Python is a better
choice
for anything you might do in Perl.
--
<J Q B>
TechnoCrate
Rainer Joswig
> I'm happy to hear I cam wrong. Please include URLs so I can learn more.
SIOD is a popular Scheme variant for CGI scripting...
http://people.delphi.com/gjc/siod.html
> Thank you very much. I have heard myths about the server. Thing is, are their any ISP
> that run this thing that I could rent space on?
CL-HTTP is not normally used by ISPs for this purpose
(hmm, one should change that).
Usually people were building special purpose web applications
with CL-HTTP. Like interactive web sites, tutoring systems,
interfaces to existing Common Lisp software, web crawlers, ...
Rainer Joswig
> > Commercial Lisps for Unix (Solaris, etc.) are very expensive, I agree.
> > The only solution I have found, is not to use a commercial Lisp
> > under Unix.
> >
>
> Well, do you have any suggestions?
No.
> One problem is that having a simple Lisp
> interpreter/compiler system is not enough. What is attractive about the Harlequin Enterprise
> product, for example, is that it has a knowledge base construction component, database access
> modules, CORBA support, GUI development support, etc.
The Enterprise version for Windows costs $2000 (including CORBA support,
Knowledgeworks, ODBC support, ...
Unix versions are more expensive.
> preferred by the company). When I asked Harlequin if they had cross-compilers the answer was
> a pause and then "Uh, no." Okay. My company has deep pockets. I could easily spend several
> thousand dollars for a software development system without blinking an eye. But it has to do
> what I want and it has to have no strings attached. In fact, I could easily spend $10K or
> more for the right system.
Unfortunately a commercial Lisp development system for Unix can
easily be in that range when you add all the options you
have named. The competition might be even more expensive.
> By the way, the Harlequin system is still pretty amateurish compared to contemporary
> development systems such as Visual C++, VisualAge, JBuilder, etc. It suffers very much from
> its history and design philosophy as a UNIX product intended primarily for research and
> academic pursuits. Basically it is still a command line system with windows grafted onto it.
For some of their tools you are right.
> Objectively speaking, the interface and debugging capabilities are pathetic compared to what
> developers should expect today. And the integration of its NT version with NT is at points
> laughable (and at other points utterly frustrating). I've passed on a detailed evaluation of
> this to Harlequin, of course (a lot of high-priced consulting and product evaluation for free
> from me). I would still buy the product (even just for my Alpha) if I were convinced it
> really worked and they would drop the idiotic royalty constraints.
The UI has some rough edges (windows are not responsive when busy, grrr.).
Still, I think it is not that bad.
> So what do you suggest as an alternative?
Can't help you. Look for Smalltalk? Maybe expensive on Unix, too.
For my *personal* development purpose I'm using my Mac.
Sorry,
Rainer Joswig
Herr Konning
Rainer Joswig wrote:
Which is the problem I was speaking about. People learn Perl because almost every server
provides for CGI scripting in Perl, so despite its ugly structures and truly evil regular
expressions people learn it. I want to get an ISP that will rent me a web site so I can write
CGI script in LISP or SCHEME for my own personal web page and I have not been able to find one.
End result even though I took courses in Scheme and LISP and live these languages I do little to
no programming in them, while I struggle through O'Reilly Nutshell hand books on CGI and Perl.
I would love to have a version of LISP or T or Scheme that I could afford that would allow me to
quickly create graphic intensive programs that are portable. I have not found them so I have
used other packages which have forced me to learn other languages, over time I start using
these other languages like VB, Lingo, JS, and Perl so much that they become easier and easier
for me. Meanwhile my LISP gets rustier and rustier.
I really don't understand the arguments here, this is simply the way it generally works when
one leaves University and tries to get a job in computer science. There simply are not many
positions for LISP programmers and you end up writing in something else.
I love LISP and I wish Scheme and not JavaScript where native to IE 4+ and Netscape 2+, I wish
Macromedia used a Scheme like language to author in Director rather then the ugly undisciplined
Lingo. But I can't find anyone who is willing to pay me to do LISP so I don't do it.
Thanks for the URL and information. Maybe when I set up my own server I'll make it run LISP for
CGI.
> --
> http://www.lavielle.com/~joswig
Gary H. Merrill
Rainer Joswig wrote: The Enterprise version for Windows costs $2000 (including CORBA support,
> Knowledgeworks, ODBC support, ...
>
> Unix versions are more expensive.
>
I would not have minded paying the $7K for the version on my Alpha if it had been all there and
working. I was sent a beta copy for testing and examination -- without any installation
documentation (in fact, without any documentation at all), and so I never go around to really
testing it. But it didn't matter since some of the stuff I was interested in was not included in
the beta. At that time the Enterprise edition was not available for the PC.
> The UI has some rough edges (windows are not responsive when busy, grrr.).
> Still, I think it is not that bad.
>
They have made the (in my opinion, and I've been in the same position in porting environments)
deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
with keystrokes) between LispWorks windows and any other windows on the PC. Sure, these are all
things one could get used to. But for the price of the product (ten times as much on the PC as I
just paid for a much more sophisticated Java development environment), one should not have to get
used to such things. Not to mention the documentation -- which is better not mentioned.
> > So what do you suggest as an alternative?
>
> Can't help you. Look for Smalltalk?
Gag me with a spoon, eh? I really wanted the KB stuff as a "light weight" alternative to Cyc. For
just normal development I am drifting in the direction of Java with a native code compiler.
> Maybe expensive on Unix, too.
> For my *personal* development purpose I'm using my Mac.
>
Alas, I am in the position of having to plan for deploying applications throughout one of the
largest pharmaceutical companies in the world. Macs don't cut it, corporate-wise. Even my nifty
little Alpha (330Mhz, 1G memory, 18G disk) is frowned upon by the system support folks (who are
ideologically committed to Solaris).
-- Gary Merrill
Rainer Joswig
> I would not have minded paying the $7K for the version on my Alpha if it had been all there and
> working. I was sent a beta copy for testing and examination -- without any installation
> documentation (in fact, without any documentation at all), and so I never go around to really
> testing it. But it didn't matter since some of the stuff I was interested in was not included in
> the beta. At that time the Enterprise edition was not available for the PC.
Maybe it is time to look again?
> They have made the (in my opinion, and I've been in the same position in porting environments)
> deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
> since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
> with keystrokes) between LispWorks windows and any other windows on the PC.
They have their own editor which is Emacs like. Hmm, I like it.
If they cannot copy to other windows, then I'd say this is
a serios bug. In MCL for example, I'm using the usual Emacs
commands (and the unlimited cut buffer) together with the
usual Mac commands for cut/copy/paste. Shouldn't be that
difficult.
> things one could get used to. But for the price of the product (ten times as much on the PC as I
> just paid for a much more sophisticated Java development environment),
Hmm, the Lisp market is smaller (sadly) and I'd also guess that there
is quite a lot power under the hood of a Lisp system.
Otherwise, maybe there are systems for developing knowledge-based applications
under Java?
> one should not have to get
> used to such things. Not to mention the documentation -- which is better not mentioned.
You get HTML and PDF versions. Printed versions are available, too.
Actually the documentation has improved, compared to earlier versions. ;-)
> > > So what do you suggest as an alternative?
> >
> > Can't help you. Look for Smalltalk?
>
> Gag me with a spoon, eh? I really wanted the KB stuff as a "light weight" alternative to Cyc.
What do you want to do? There are a lot of alternatives in the
knowledge representation area.
> Alas, I am in the position of having to plan for deploying applications throughout one of the
> largest pharmaceutical companies in the world. Macs don't cut it, corporate-wise. Even my nifty
> little Alpha (330Mhz, 1G memory, 18G disk) is frowned upon by the system support folks (who are
> ideologically committed to Solaris).
Well, SPARCs with Solaris are also here in Germany more common than ALPHAs.
I'd wish Symbolics would port Open Genera to UltraSPARCs. Currently it
only runs on DEC ALPHA under Unix.
Gary H. Merrill
Rainer Joswig wrote:
> > Gag me with a spoon, eh? I really wanted the KB stuff as a "light weight" alternative to Cyc.
>
> What do you want to do? There are a lot of alternatives in the
> knowledge representation area.
>
I could make use of a decent knowledge representation language plus an inference engine. While it
would be nice to have something along the lines of CycL, it is not realistic to expect this. However,
some requirements are that it is a commercial product and Y2K compliant. An additional requirement is
that a KBS built with this have good response time in an interactive application. And there should be
decent tools to support development. In the case of NT applications this would include GUI
development, or at least a way to interface in an easy way with something like an interface written in
Java. I should either be able to straightforwardly develop NT based KBS applications or to develop
server applications that run on the Alpha and are web-accessible. All of this I can do (and currently
do) via Cyc. But as I say, the ability to produce applications with considerably less overhead and
with better response time would be advantageous.
> Well, SPARCs with Solaris are also here in Germany more common than ALPHAs.
> I'd wish Symbolics would port Open Genera to UltraSPARCs. Currently it
> only runs on DEC ALPHA under Unix.
It is really difficult (I would say "impossible") to beat the Alpha in terms of its price/performance
ratio. The system I have (again, 330 MHz processor, 1G memory, 18G hard drives, DEC Alpha UNIX) cost
only about $20K. Last time I checked, a comparable system from Sun would have cost twice as much.
(The memory is not DEC memory, but is a third party vendor. It works just fine.)
-- Gary Merrill
Robert Monfera
"Gary H. Merrill" wrote:
(snip)
> They have made the (in my opinion, and I've been in the same position in porting environments)
> deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
> since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
> with keystrokes) between LispWorks windows and any other windows on the PC.
Just because you need to use different keystrokes, you can still copy
and paste between LW and other applications. For example, copy examples
from the HTML documentation and paste them in the listener. You can
easily reassign the keystroke assignments if you want (maybe someone has
example code?).
I understand your point, but for us it is the power of CL rather than
the flashiness of the IDE that matters - that's where productivity is
coming from. I could still create pretty decent GUI functions
(spreadsheet-like grids with automatic layout and dynamic resizing). BTW
we have not chosen CL because of legacy code or AI - we evaluated Java
and Smalltalk as well, and made an informed decision based on
development productivity, application quality and performance.
> Sure, these are all
> things one could get used to. But for the price of the product (ten times as much on the PC as I
> just paid for a much more sophisticated Java development environment), one should not have to get
> used to such things. Not to mention the documentation -- which is better not mentioned.
I am sure you know how much more powerful CLOS is.
Documentation: on the positive side, Common Lisp is a very well
documented language. The additional features (SQL, CAPI, delivery etc.)
are still not documented too verbosely, but their support fills the gaps
(I think it is not as economical to them as adding to the documentation,
but there is some progress).
Robert
Erik Naggum
| It is really difficult (I would say "impossible") to beat the Alpha in
| terms of its price/performance ratio. The system I have (again, 330 MHz
| processor, 1G memory, 18G hard drives, DEC Alpha UNIX) cost only about
| $20K. Last time I checked, a comparable system from Sun would have cost
| twice as much.
well, try this: dual 400 MHz Pentium II, 512M RAM, 3 x 9G SCSI disks, 16G
IDE disk, CD-RW burner, ethernet, no display, no sound. Debian Linux
2.1.125. intended as a small enterprise server. bought in October last
year at about USD 7,500, in Norway, with its world-famous 23% sales tax
included. as an added bonus, an Allegro CL license for Linux is the same
price as the Windows/NT license.
I reviewed Alpha and SPARC at the time, but I tend to distrust Compaq,
and the price/performance ratio was not at all competitive with Intel,
anyway.
#:Erik
--
Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
Julk, August, September, October, November, December.
Paul Meurer
<gmer...@mindspring.com> wrote:
>
>
>Rainer Joswig wrote: The Enterprise version for Windows costs $2000 (including CORBA support,
>
>> Knowledgeworks, ODBC support, ...
>>
>> Unix versions are more expensive.
>>
>
>I would not have minded paying the $7K for the version on my Alpha if it had been all there and
>working. I was sent a beta copy for testing and examination -- without any installation
>documentation (in fact, without any documentation at all), and so I never go around to really
>testing it. But it didn't matter since some of the stuff I was interested in was not included in
>the beta. At that time the Enterprise edition was not available for the PC.
>
>> The UI has some rough edges (windows are not responsive when busy, grrr.).
>> Still, I think it is not that bad.
>>
>
>They have made the (in my opinion, and I've been in the same position in porting environments)
>deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
>since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
>with keystrokes) between LispWorks windows and any other windows on the PC. Sure, these are all
This is simply wrong. You can copy, paste etc. as much as you like,
the only difference is that you use an other key combination.
(ctrl-insert etc.) Takes some getting used to, right, and I too would
prefer ctrl-c etc.
I am very happy that they retained the Emacs interface where most
things can be done with key strokes, without dialogs popping up all
the time (in almost all other environments I am missing incremental
search and query replace). (Not having a decent built-in Emacs
interface is in my view a big shortcoming in the new ACL for Windows.)
Might take some getting used to if you haven't used Emacs before, but
you get a lot for it, in my eyes.
Paul Meurer
Paul Meurer at HIT UiB no
Humanities Information Technologies,
University of Bergen
Allegt. 27
5007 Bergen, Norway
Umut Topkara
McMalo wrote in message <244t2.940$Pf....@newscene.newscene.com>...
>Hmm . I didn't know that Turing killed himself.
>I don't know what the Turing test is. May you illustrate me.
Once there was a thread with subject: "is bloxy's a bot". i was reading the
postings in this newsgroup with a friend and his postings looked very
controversial to me, sensible or nonsense. so to have some fun and have some
AI discussion at the same time my friend started that thread. if you can
reach that thread somehow. see how a man can or cannot prove that he is not
a bot.
-black
Gary H. Merrill
Erik Naggum wrote:
> well, try this: dual 400 MHz Pentium II, 512M RAM, 3 x 9G SCSI disks, 16G
> IDE disk, CD-RW burner, ethernet, no display, no sound. Debian Linux
> 2.1.125. intended as a small enterprise server. bought in October last
> year at about USD 7,500, in Norway, with its world-famous 23% sales tax
> included. as an added bonus, an Allegro CL license for Linux is the same
> price as the Windows/NT license.
>
This would be a nice alternative except basically for two things. First, Linux
will not come remotely close to being accepted for support within a lot of
companies (mine in particular). And this won't be happening for some time.
Don't argue about how this is unreasonable. It is simply a fact. And then ...
> I reviewed Alpha and SPARC at the time, but I tend to distrust Compaq,
> and the price/performance ratio was not at all competitive with Intel,
> anyway.
Oh? So which of the 64-bit Sun and Intel processors were you reviewing?
-- Gary Merrill
Gary H. Merrill
Robert Monfera wrote: I understand your point, but for us it is the power of CL rather than
> the flashiness of the IDE that matters - that's where productivity is
> coming from. I could still create pretty decent GUI functions
> (spreadsheet-like grids with automatic layout and dynamic resizing). BTW
> we have not chosen CL because of legacy code or AI - we evaluated Java
> and Smalltalk as well, and made an informed decision based on
> development productivity, application quality and performance.
>
I fully understand this perspective. However, I take it you are not developing for multiple
platforms? If you are, I suppose you have spent the money for the LISP environment on *each*
platform? Now that really starts to add up. And then there is the unfortunate issue of the
royalties. I think the primary problem I had with Harlequin was that it simply had an unfinished,
academic, not well thought out feel to it. And the documentation of the *product* (not the language)
is pretty sad. I came up to speed in Java (a language I did not know at all) with JBuilder much more
quickly than I was proceeding with LispWorks -- and I at least used to know LISP *very* well. This
says something about the product. Their support people seem to be great. I may in fact try the
product again in a while, after the Enterprise product has been in the field for a release or two.
-- Gary Merrill
Gary H. Merrill
Paul Meurer wrote:
> On Sat, 06 Feb 1999 13:32:18 -0500, "Gary H. Merrill"
> <gmer...@mindspring.com> wrote:
>
>
> >They have made the (in my opinion, and I've been in the same position in porting environments)
> >deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
> >since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
> >with keystrokes) between LispWorks windows and any other windows on the PC. Sure, these are all
>
> This is simply wrong. You can copy, paste etc. as much as you like,
> the only difference is that you use an other key combination.
Please note the phrase "in the normal ways" that was part of my criticism. Thus it is *not* "simply
wrong".
> (ctrl-insert etc.) Takes some getting used to, right, and I too would
> prefer ctrl-c etc.
> I am very happy that they retained the Emacs interface where most
> things can be done with key strokes, without dialogs popping up all
> the time (in almost all other environments I am missing incremental
> search and query replace). (Not having a decent built-in Emacs
> interface is in my view a big shortcoming in the new ACL for Windows.)
> Might take some getting used to if you haven't used Emacs before, but
> you get a lot for it, in my eyes.
Well, I've been using Emacs for about fifteen years. So the problem isn't that I don't know or
appreciate emacs. But on an NT system I really prefer windows to act like *NT* windows uniformly
unless I am specifically intending to use one as an Emacs window. I suppose I might be able to
arrange things so that all of my NT applications conformed to the Emacs conventions (though I'm not
sure how possible this is to do do), but that would be terribly goofy for even the most rabid Emacs
fanatic. And short of that having *one* application's windows conform to a totally foreign convention
is, at least to me, terribly annoying. Software vendors who have attempted to follow the philosophy
(and I've worked for some) of "one common interface across all platforms" have discovered that this is
*not* what their customers want.
-- Gary Merrill
Erik Naggum
| Linux will not come remotely close to being accepted for support within a
| lot of companies (mine in particular). And this won't be happening for
| some time. Don't argue about how this is unreasonable. It is simply a
| fact. And then ...
simple facts tend to be wrong. Linux is a fully supported commercial
operating system.
| Oh? So which of the 64-bit Sun and Intel processors were you reviewing?
64-bit vs 32-bit was not a concern for this acquisition.
Gary H. Merrill
Erik Naggum wrote:
> * "Gary H. Merrill" <gmer...@mindspring.com>
> | This would be a nice alternative except basically for two things. First,
> | Linux will not come remotely close to being accepted for support within a
> | lot of companies (mine in particular). And this won't be happening for
> | some time. Don't argue about how this is unreasonable. It is simply a
> | fact. And then ...
>
> simple facts tend to be wrong. Linux is a fully supported commercial
> operating system.
>
You still don't get it. The fact that Linux is "a fully supported commercial
operation system" is not sufficient. What matters is *who* supports it.
Unless it is supported by the *vendor* (as is OSF/1 for the Alpha, HP/UX, and
Solaris) many (if not most, if not all) large IT organizations will *not* have
anything to do with it.
> | Oh? So which of the 64-bit Sun and Intel processors were you reviewing?
>
> 64-bit vs 32-bit was not a concern for this acquisition.
Yeah, see ... if you are dealing with just tiny programs than almost any
hardware will do. (I do wish the 64-bit Intel chip would hit the market. Then
I would get a 64-bit Linux system real quick.)
-- Gary Merrill
Christopher R. Barry
> Yeah, see ... if you are dealing with just tiny programs than almost
> any hardware will do.
How are you defining "tiny"? AFAICR and know, you only need 64 bitness
for OODB stuff when you've got like more than 4GB physical+virtual
memory. On the Intel processor, you can decide if you want the
physical/virtual split to be 1GB/3GB (the Linux default, I believe) or
2GB/2GB.
> (I do wish the 64-bit Intel chip would hit the market. Then I would
> get a 64-bit Linux system real quick.)
Alpha Linux reputably is very robust these days.
Christopher
[BTW, I wish you would set up your newsreader to wrap lines so that
they are < 80 columns. It's annoying to those of us that fix our
frames at the 80 column "standard" to resize the frame or wrap the
long lines.]
Erik Naggum
having worked with an employee to introduce Linux to a company that had a
similar policy to the one you refer to, I have some solid evidence that I
understand what kinds of concerns managers have and how to answer them.
of course, if it suits you to ignore any and all proof that you might
succeed if you actually tried, that's your problem. I know how such
policies come to be and how to change them without scaring managers who
have legitimate concerns behind their decisions, not just the religious
edicts you imply that these policies are. that you don't understand how
to deal with these things is not my problem. I'm not trying to change
your mind, I'm just trying to make you aware that you make invalid claims
in the interest of making the _real_ concerns explicit. enough stupid
people hide behind things they don't _want_ to change to make it
necessary to figure out what they are frightened of. you give me a very
powerful hint that you are indeed afraid of something. had I had any
incentive (a lot of money) to convince you and your managers otherwise, I
would have succeeded in it, even if you can't.
| The fact that Linux is "a fully supported commercial operation system" is
| not sufficient. What matters is *who* supports it. Unless it is
| supported by the *vendor* (as is OSF/1 for the Alpha, HP/UX, and Solaris)
| many (if not most, if not all) large IT organizations will *not* have
| anything to do with it.
you appear to speak without knowledge of the Linux market. e.g., both
RedHat and Caldera are vendors of considerable size who support their own
Linux distributions and are held accountable for the systems they have
delivered. I'm not talking about the many hackers around the world who
make Linux a great system and for which some people have great disdain,
and who accept money for supporting people.
| Yeah, see ... if you are dealing with just tiny programs than almost any
| hardware will do.
it seems you have a problem with your assumption-generator: it appears to
be completely unchecked by facts or other input from the outside world.
a dual processor with 512M RAM and 40+ G of disk is not a good buy when
you have "tiny programs" and "almost any hardware will do", it's a waste
of money because "almost any hardware" is even _cheaper_.
I don't think further input to you would be anything but a waste, either.
Gary H. Merrill
Erik Naggum wrote:
> * "Gary H. Merrill" <gmer...@mindspring.com>
> | You still don't get it.
>
> having worked with an employee to introduce Linux to a company that had a
> similar policy to the one you refer to, I have some solid evidence that I
> understand what kinds of concerns managers have and how to answer them.
> of course, if it suits you to ignore any and all proof that you might
> succeed if you actually tried, that's your problem. I know how such
> policies come to be and how to change them without scaring managers who
> have legitimate concerns behind their decisions, not just the religious
> edicts you imply that these policies are. that you don't understand how
> to deal with these things is not my problem. I'm not trying to change
> your mind, I'm just trying to make you aware that you make invalid claims
> in the interest of making the _real_ concerns explicit. enough stupid
> people hide behind things they don't _want_ to change to make it
> necessary to figure out what they are frightened of. you give me a very
> powerful hint that you are indeed afraid of something. had I had any
> incentive (a lot of money) to convince you and your managers otherwise, I
> would have succeeded in it, even if you can't.
And just how large was this company in which you succeeded and what was its
organization? I sense the wounded response of the true Linux fanatic. Let me
make this clear. I would be happy to use such a system. I in fact have
suggested a very well defined project to demonstrate the viability of using
such systems in the company. I have offered to support such a demonstration.
But, not being a fanatic, and having a very good knowledge of the actual and
historical workings of this company, I do not choose to devote my time to a
crusade. All your puffery, breast beating, and name calling cannot change the
facts.
> | The fact that Linux is "a fully supported commercial operation system" is
> | not sufficient. What matters is *who* supports it. Unless it is
> | supported by the *vendor* (as is OSF/1 for the Alpha, HP/UX, and Solaris)
> | many (if not most, if not all) large IT organizations will *not* have
> | anything to do with it.
>
> you appear to speak without knowledge of the Linux market. e.g., both
> RedHat and Caldera are vendors of considerable size who support their own
> Linux distributions and are held accountable for the systems they have
> delivered. I'm not talking about the many hackers around the world who
> make Linux a great system and for which some people have great disdain,
> and who accept money for supporting people.
You are still not listening. I am well aware of the commercially distributed
and supported version of Linux. I thought that was clear. That is not the
issue. If it isn't Microsoft and it isn't supported by the *hardware* vendor,
it doesn't count. I can go out and buy any kind of machine I like and run it
in my office as my private lab machine -- as long as *I* support it. If the OS
software is not Microsoft and it isn't supported by the *hardware* vendor, then
the support organization will *not* support it. I can't get the support
organization to support NT on my *notebook*. They support NT on desktops, but
not on notebooks. You really don't have a clue about large organizations of
certain sorts. Your experience must be *very* limited.
> | Yeah, see ... if you are dealing with just tiny programs than almost any
> | hardware will do.
>
> it seems you have a problem with your assumption-generator: it appears to
> be completely unchecked by facts or other input from the outside world.
> a dual processor with 512M RAM and 40+ G of disk is not a good buy when
> you have "tiny programs" and "almost any hardware will do", it's a waste
> of money because "almost any hardware" is even _cheaper_.
>
In some corners of the software world, 512M RAM is a relatively small amount of
memory. Your own assumptions and lack of genuine experience are showing.
> I don't think further input to you would be anything but a waste, either.
>
Certainly not any further input from you.
-- Gary Merrill
Gary H. Merrill
Christopher R. Barry wrote:
> "Gary H. Merrill" <gmer...@mindspring.com> writes:
>
> > Yeah, see ... if you are dealing with just tiny programs than almost
> > any hardware will do.
>
> How are you defining "tiny"? AFAICR and know, you only need 64 bitness
> for OODB stuff when you've got like more than 4GB physical+virtual
> memory. On the Intel processor, you can decide if you want the
> physical/virtual split to be 1GB/3GB (the Linux default, I believe) or
> 2GB/2GB.
>
"AFAICR and know" is the operative phrase. Imagine a VLKB kept all in
memory and containing hundreds of thousands or millions of assertions.
For some things you really need a 64-bit address space.
> > (I do wish the 64-bit Intel chip would hit the market. Then I would
> > get a 64-bit Linux system real quick.)
>
> Alpha Linux reputably is very robust these days.
So is DEC Alpha UNIX -- and it is supported by the hardware vendor.
> Christopher
>
> [BTW, I wish you would set up your newsreader to wrap lines so that
> they are < 80 columns. It's annoying to those of us that fix our
> frames at the 80 column "standard" to resize the frame or wrap the
> long lines.]
80 columns was standard when we were confined to punch cards. It's
always better to wrap at 72 characters in any event. And that in fact is
what this mailer is set to.
-- Gary Merrill
Christopher R. Barry
> Christopher R. Barry wrote:
>
> > "Gary H. Merrill" <gmer...@mindspring.com> writes:
> >
> > > Yeah, see ... if you are dealing with just tiny programs than almost
> > > any hardware will do.
> >
> > How are you defining "tiny"? AFAICR and know, you only need 64 bitness
> > for OODB stuff when you've got like more than 4GB physical+virtual
> > memory. On the Intel processor, you can decide if you want the
> > physical/virtual split to be 1GB/3GB (the Linux default, I believe) or
> > 2GB/2GB.
> >
>
> "AFAICR and know" is the operative phrase. Imagine a VLKB kept all in
> memory and containing hundreds of thousands or millions of assertions.
> For some things you really need a 64-bit address space.
"For some things" is the operative phrase here. Nearly all
applications are comfortable with way under 4GB, and a lot of people
are successfully implementing KR and OODB systems on Intel hardware
with the 4GB limitation. And they are saving themselves a lot of money
by going with hardware that is far more cost effective.
Stop by www.pricewatch.com some time. You can get a top of the line
Pentium II or III motherboard for under $130, and a dual board for
under $200. A Pentium II 400 is $314, and a Pentium III 450 is $544.
And you'd have to see memory prices these days to believe them....
Now that the Alpha 21264 is out, 21164 chip prices are within reason
but you still can't get a motherboard for under $1000.
> > > (I do wish the 64-bit Intel chip would hit the market. Then I would
> > > get a 64-bit Linux system real quick.)
> >
> > Alpha Linux reputably is very robust these days.
>
> So is DEC Alpha UNIX -- and it is supported by the hardware vendor.
And what exactly does "support from the hardware vendor" really buy
you over support from a software vendor? Digital Unix costs at the
very least $1000 per license, and it isn't nearly as nice as Linux or
Solaris except for the Digital FORTRAN compiler, if you're really into
that kind of thing.
> > Christopher
> >
> > BTW, I wish you would set up your newsreader to wrap lines so that
> > they are < 80 columns. It's annoying to those of us that fix our
> > frames at the 80 column "standard" to resize the frame or wrap the
> > long lines.]
>
> 80 columns was standard when we were confined to punch cards.
And it should be abandoned now? Should we all just wrap lines at
whatever weird geometry our xterms or mail clients or IDEs happen to
be at and make printing a nightmare and make people take additional
steps to adjust their clients so that what they have in front of their
face is readable?
> It's always better to wrap at 72 characters in any event. And that
> in fact is what this mailer is set to.
Thank you for configuring it properly, but that's not what it was set
to do a few posts up when you had lines over 100 columns long that
your Windows 95 Mozilla client sent. You probably need a reminder
though. Here:
------
It is really difficult (I would say "impossible") to beat the Alpha in terms of its price/performance
ratio. The system I have (again, 330 MHz processor, 1G memory, 18G hard drives, DEC Alpha UNIX) cost
only about $20K. Last time I checked, a comparable system from Sun would have cost twice as much.
------
Christopher
Johan Kullstam
> "Gary H. Merrill" <gmer...@mindspring.com> writes:
>
> > Christopher R. Barry wrote:
> >
> > > "Gary H. Merrill" <gmer...@mindspring.com> writes:
> > >
> > > > Yeah, see ... if you are dealing with just tiny programs than almost
> > > > any hardware will do.
> > >
> > > How are you defining "tiny"? AFAICR and know, you only need 64 bitness
> > > for OODB stuff when you've got like more than 4GB physical+virtual
> > > memory. On the Intel processor, you can decide if you want the
> > > physical/virtual split to be 1GB/3GB (the Linux default, I believe) or
> > > 2GB/2GB.
> > >
> >
> > "AFAICR and know" is the operative phrase. Imagine a VLKB kept all in
> > memory and containing hundreds of thousands or millions of assertions.
> > For some things you really need a 64-bit address space.
>
> "For some things" is the operative phrase here. Nearly all
> applications are comfortable with way under 4GB, and a lot of people
> are successfully implementing KR and OODB systems on Intel hardware
> with the 4GB limitation. And they are saving themselves a lot of money
> by going with hardware that is far more cost effective.
so he wants/needs 64 bit address spaces? what's it to you?
linux on intel can't really exploit all 4GB either. you get at most 2
GB of user stuff and the rest is gone to virtual memory mapping and
shuffling around.
> Stop by www.pricewatch.com some time. You can get a top of the line
> Pentium II or III motherboard for under $130, and a dual board for
> under $200. A Pentium II 400 is $314, and a Pentium III 450 is $544.
>
> And you'd have to see memory prices these days to believe them....
the price of the hardware is sometimes not an issue. if a $50k
machine does what you need it to do, then that may just be a good
route to take. nevermind if you can cobble together 40 obsolete PCs
into a beo-cluster for half the price. the whole project may be
budgeted in multi-million dollar amount and the price of the computer
you purchase is down in the noise.
> Now that the Alpha 21264 is out, 21164 chip prices are within reason
> but you still can't get a motherboard for under $1000.
>
> > > > (I do wish the 64-bit Intel chip would hit the market. Then I would
> > > > get a 64-bit Linux system real quick.)
> > >
> > > Alpha Linux reputably is very robust these days.
> >
> > So is DEC Alpha UNIX -- and it is supported by the hardware vendor.
>
> And what exactly does "support from the hardware vendor" really buy
> you over support from a software vendor? Digital Unix costs at the
> very least $1000 per license, and it isn't nearly as nice as Linux or
> Solaris except for the Digital FORTRAN compiler, if you're really into
> that kind of thing.
i don't think this is a logic or price-awareness type issue. `support
from hardware vendor' means that his IT department is willing to
service and administer his machine. i think that is _all_ there is to
it. it's a label used by the IT dept to restrict the things they are
going to support. you may think this is an idiotic policy, but it's
_policy_ and anyone who has worked for a large company knows how far
removed from reality policy can become.
some things are just not worth fighting for. i wouldn't care all that
much whether i got digital unix or linux. since the policy is use dec
unix, i'd just use it. big deal.
gary has been more than reasonable. he seems to understand the issues
involved. he even seems to like and respect linux. you are preaching
to the choir but gary's company has a different religion.
--
johan kullstam
Erann Gat
> You are still not listening. I am well aware of the commercially distributed
> and supported version of Linux. I thought that was clear. That is not the
> issue. If it isn't Microsoft and it isn't supported by the *hardware* vendor,
> it doesn't count.
There are hardware vendors that support Linux. VA Research for example.
Erann Gat
g...@jpl.nasa.gov
Pierre Mai
And Compaq(DEC), Dell and Gateway2000 have announced plans to sell
Linux-based servers with support. There are rumours that IBM and HP
want to follow suit.
So choices are increasing, even for those who don't want to fight
their IT departments.
But the whole thread has strayed a bit far from Lisp or AI Philosophy,
so I'd suggest we return to more lispy topics here...
Hmm, IIRC prior to this discussion on Linux, hardware and corporate
live, Greg was talking about using Cyc to either implement KB
applications on NT, or implementing those applications on DU/Alpha
and making them web-accessible, and looking to Lisp as an alternative
to Cyc.
Well, I don't like the first "solution" (I refuse to put critical
functionality of systems on Microsoft-based systems), so I very much
prefer the second modus operandi, since it also gives you instant
portability to most client platforms, and it makes it easy for the
users to further process the output (e.g. integrating it with reports
in their favourite word-processors, etc.).
I'm currently leading a project that is redeveloping a fairly large
simulation package[1]. As part of the redevelopment, we are developing a
fairly extensive suite for evaluating and visualizing the simulation
results, to increase the user transparency and usability. At current,
most of the reports are generating DocBook (SGML) and graphics files
off-line, which are then translated to HTML, RTF and/or TeX/DVI/PDF.
To increase usability, we are currently evaluating cl-http[2] for
on-line generation of HTML and/or DocBook XML reports, as a first
step. Should this prove to be successful and usable, we are thinking
of building a complete interactive simulation desktop environment with
cl-http, so that the users can directly integrate new data-sets into
the simulation project, validate them, simulate and evaluate the
results, without direct involvement of the specialized simulation
group, so that the simulation group would only be involved in the
modelling, simulation development and user support/information.
Anyone who is working on similar things, or is simply interested is
welcome to contact me. I'll also try to keep the group informed of
our successes and failures in using Common Lisp for this project.
Regs, Pierre.
PS: To put some people here into perspective, _all_ applications that
run on single workstations (whether 32bit or 64bit) are tiny. Large
applications run on mainframes, supercomputers and/or clusters, for
various dimensions of large (e.g.. data volume, computation volume,
reliability, transaction throughput, response time, etc.). And despite
all the down-sizing hysteria a few years ago, it turned out that it
will stay this way for quite a while longer. Oh, and BTW, there are
also other people in this newsgroup that have direct experience with
large corporations and organizations, and I'd wager a bet that German
corporate giants are no less bureaucratic than American ones ;) And a
growing number of them are starting to use Linux in various parts of
their operations, and some are even openly admitting it ;) Ditto for
Common Lisp, btw. Wasn't someone in this group looking for Lisp work,
or something like this? Well, a quick glance at www.jobs.de has
revealed to me around 10 job offers that mention Lisp directly in
the last 4 weeks or so...
Footnotes:
[1] The original simulation suite was implemented in C++, with
visualisation tools in Tcl/Tk and some other tools in Perl. It was a
nightmare to maintain or extend, and after deliberations whether to
redevelop it in C++, it was decided (i.e. I convinced my client) to
redevelop it in Common Lisp. As was to be expected, since simulation
is a field where requirements change quickly, and are often only
understood clearly as more simulation projects are undertaken, we are
very much pleased with the speed and flexibility that Common Lisp has
given us. With very little developer resources, we were able to
proceed very far with this redevelopment, earning some of the fruits
along the way, while continue to maintain and support the legacy suit.
As for platform choices, the old simulation was run mostly on
DEC Alpha workstations and servers, with a small simulations running on
Pentium Linux workstations. For a number of reasons, among them the
continuing decrease of DEC support quality (when you have to explain to
the "Unix specialist" basic fundamentals of Unix filesystem operation,
you know it's time you left) and the ever worsening price/performance
ratio, we are moving away from DEC towards Intel/Linux based
workstations. Our current Lisp platform is CMU CL on both Alpha/DU
and Intel/Linux and we are very much satisfied with it and the support
we got from the CMU CL community when we needed it. We are continuing
to survey commercial implementations for the Linux platform, which we
might want to use for more advanced features, like CLIM, SQL,
OO-Databases, etc.
[2] http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
--
Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Dean-Christian Strik
>
>TechnoCrate wrote:
>
>> GNU's C compiler is ranked as one of the best optimizers,
>
>Ha! By whom?
By me, for example...
(not likely that that means anything to you though)
>> I tried it
>> out by making an expression containing five variables and about 20
>> logical operations. However: I arranged it in such a way that whatever
>> the values of the variables would be, the outcome would be always true
>> (non zero that is). The compiler had no trouble whatsoever to
>> recognize this fact and dismissed the entire condition (it even saw
>> that the variables weren't used anywhere else and didn't allocate
>> memory for it).
>
>This kind of trivial thing should be done by any commercial compiler.
Is there any particular reason for the use of the word 'should'? Are there
any RECENT compilers that don't. I just have gcc and egcs, but it's a place
to start for testing. I'll post the results. I think.
--
Dean-Christian Strik ("Fluxen") -- de...@bigfoot.com -- ICQ #11760568
"Real programmers like vending machine popcorn. Coders pop it in the
microwave oven. Real programmers use the heat given off by the CPU. They can
tell what job is running just by listening to the rate of popping."
Dean-Christian Strik
but the LISP dialects. Most notably Mercury and Goedel.
--
Dean-Christian Strik ("Fluxen") -- de...@bigfoot.com -- ICQ #11760568
"Real programmers like vending machine popcorn. Coders pop it in the
microwave oven. Real programmers use the heat given off by the CPU. They can
tell what job is running just by listening to the rate of popping."
ri...@kana.stanford.edu wrote in message <799mkj$dof$1...@nnrp1.dejanews.com>...
>Another feature of LISP useful A.I. is built-in logic- the lambda calculas.
>This is more general and powerful (when used) than conditional statements
>and functions in other languages.
>Perhaps only Prolog (does anyone use it?) has more explicit logic
constructs
>than LISP.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Dean-Christian Strik
--
Dean-Christian Strik ("Fluxen") -- de...@bigfoot.com -- ICQ #11760568
"Real programmers like vending machine popcorn. Coders pop it in the
microwave oven. Real programmers use the heat given off by the CPU. They can
tell what job is running just by listening to the rate of popping."
Rainer Joswig wrote in message ...
>In article <36b9800c...@news.euronet.nl>, usu...@euronet.nl
(TechnoCrate) wrote:
>
>> On Wed, 03 Feb 1999 11:26:46 -0500, "james d. hunter"
>> <jim.h...@jhuapl.edu> wrote:
>>
>> >ri...@kana.stanford.edu wrote:
>> >>
>> >> Another feature of LISP useful A.I. is built-in logic- the lambda
calculas.
>> >> This is more general and powerful (when used) than conditional
statements
>> >> and functions in other languages.
>> >
>> > Well, with computer languages I've never been convinced that
>> > more general implies more powerful is necessarily true.
>> >
>> It's more like the opposite. The Assembly languages are the most
>> powerfull since compilers are still not able to improve the code of
>> the good Assembly programmers (after all: human programmers can
>> cheat). Besides: Assembly (apart from some secret code) covers all of
>> the capabilities of the targetted cpu
>
>Which is not really true anymore. Some modern CPUs are so complicated
>and really need optimizing compilers, because writing good
>code is very hard to do by hand.
>
>--
>http://www.lavielle.com/~joswig
Gary H. Merrill
Christopher R. Barry wrote:
> "For some things" is the operative phrase here. Nearly all
> applications are comfortable with way under 4GB, and a lot of people
> are successfully implementing KR and OODB systems on Intel hardware
> with the 4GB limitation. And they are saving themselves a lot of money
> by going with hardware that is far more cost effective.
And how big are their KBs? How many assertions?And what exactly does "support from the hardware vendor"
really buy
> you over support from a software vendor? Digital Unix costs at the
> very least $1000 per license, and it isn't nearly as nice as Linux or
> Solaris except for the Digital FORTRAN compiler, if you're really into
> that kind of thing.
Look. You folks aren't paying attention. I am not claiming (and have never claimed) that the policy of
preferring or requiring hardware vendor support is a *good* one or a *reasonable* one. I have simply
claimed that in certain organizations it *is* a policy and that changing it is not simple and
straightforward -- in fact, that changing it would require the involvement of large parts of the
organization with various vested interests and simply is unreasonable to expect. I'm sorry, but anyone
who doesn't realize this simply lacks the requisite experience with such organizations. Sure, I could
spend my time going on a crusade about this. But little, if anything, would be accomplished. And my
time is better spent in doing other things for the company. $1000 per license is *nothing*. Just today
I had occasion to go looking for a Java native code compiler. So I wandered down the hall to the
applications development group that is near us and asked them. Well, their manager said, they use Visual
Age Professional. $2,700 per seat on the PC. "Golly", I said, "I had hoped to not spend anywhere near
that much (having just spent less than $300 for JBuilder)." The response? "Ah, what's $3,000? Just
order it." It's not about *cost*. It's about perceived reliability (which may in fact be a
misperception) and response.
-- Gary Merrill
-- Gary Merrill
Gary H. Merrill
Johan Kullstam wrote:
> the price of the hardware is sometimes not an issue. if a $50k
> machine does what you need it to do, then that may just be a good
> route to take. nevermind if you can cobble together 40 obsolete PCs
> into a beo-cluster for half the price. the whole project may be
> budgeted in multi-million dollar amount and the price of the computer
> you purchase is down in the noise.
>
Ah, someone with *experience* and *knowledge*. How refreshing.
> i don't think this is a logic or price-awareness type issue. `support
> from hardware vendor' means that his IT department is willing to
> service and administer his machine. i think that is _all_ there is to
> it. it's a label used by the IT dept to restrict the things they are
> going to support. you may think this is an idiotic policy, but it's
> _policy_ and anyone who has worked for a large company knows how far
> removed from reality policy can become.
Oh Johan. You've been there. These others are as kinder in the garten, eh?
Actually, this has been quite a culture shock to me. Quite an education. I've
been at this place for two years and am still learning. Very odd.
> some things are just not worth fighting for. i wouldn't care all that
> much whether i got digital unix or linux. since the policy is use dec
> unix, i'd just use it. big deal.
>
> gary has been more than reasonable. he seems to understand the issues
> involved. he even seems to like and respect linux. you are preaching
> to the choir but gary's company has a different religion.
Exactly. It is a religious (or ideological, or turf) issue. Even the strongest
technical arguments bounce off.
-- Gary Merrill
Rainer Joswig
> I'm not an expert.... but there seem to be other high-logic languages =
> around
> but the LISP dialects.
Lisp is not a logic language, per se.
> Most notably Mercury and Goedel.
There are several advanced languages implemented on top
of Common Lisp -> see the various description logics
implementations...
Erik Naggum
| its organization?
200 people, 55 million dollars of revenue in 1997. offices in 10 nations.
| I sense the wounded response of the true Linux fanatic.
I sense a moron who needs to see fanatics when he knows he's in the wrong.
| If it isn't Microsoft and it isn't supported by the *hardware* vendor,
| it doesn't count.
you keep switching definitions and modifying what you have said to keep
from being wrong. no wonder you think in terms of fanatics.
| In some corners of the software world, 512M RAM is a relatively small
| amount of memory. Your own assumptions and lack of genuine experience
| are showing.
your fear of being exposed has been showing much longer.
| Certainly not any further input from you.
I sense a pouting, prejudiced moron who knows he's wrong, but who needs
to keep in the right for self-esteem reasons, nothing else.