Compiling Lisp
R. P. Dillon
I am quite fond of Lisp, having just started learning it. I work with
Java professionally and Python at home, and as I develop, one of my
concerns is that some of the software I write I want to distribute as
Free software for "normal" end users.
Even in common languages like Java and Python, I can hardly expect
average users to have the respective VMs installed, and this has always
been a sort of sore point for me. Sure, there are ways to work around
the requirement for the VM, but most feel fairly kludgey to me.
Moving to Lisp, I am every excited about its power and flexibility.
Given that, I was even more ecstatic to find that SBCL compiles to
native code, though it seems only at run-time. I then discovered GCL,
which appears to offer compilation to actual native binaries.
This is very appealing to me, since I would like to set a very low bar
for any users downloading my programs. They wouldn't even know what
language it was written in, simply that it ran (like C/++ programs).
Finally, my question: using GCL, I haven't been able to produce "end
user" binaries of my Lisp code. I can coax a .o, .h, and .c files out
of it, but upon linking, I get errors.
I tried this with the lisp source file containing simply
(print "hello world!")
and ran
gcl -compile hello.lisp
This produced a .o file for me, but I don't know what to link it against
to produce a final binary.
Does anyone have experience trying to do this, and can they give me any
pointers?
Thanks,
Rick
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Rob Warnock
+---------------
| ... I was even more ecstatic to find that SBCL compiles to
What do you mean "only at run-time?!? Yes, you *can* compile
code at run-time, but for both SBCL and CMUCL [and most other
Common Lisps with native compilers] you can also -- and it is
more common to do so -- COMPILE-FILE the code and produce an
external FASL file containing native code, which can either be
LOAD'd at some later time.
Or for maximum application startup speed[1], one can LOAD all
of the (compiled) components of a large system and then save
the heap as an "image" file, which can be used to initialize
the Lisp system later.
-Rob
[1] Even though it is rare to optimize for this case, since
the usual mode of operation for a large Lisp application
is to leave it running "forever", which makes the startup
time of little consequence.
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
alessi...@gmail.com
produce stand-alone executable files...
BTW I agree this is an important issue. Probably many Lisp programmers
don't care much about executables because they're into web-based
applications or other kinds of software which are not intended to be
distributed to a large pool of users, but I think that if there were
more "normal" apps written in Lisp the language would certainly be more
popular and more people would use it (considering that it's quite
common for Lisp applications to have Lisp as a scripting language). Of
course this brings up the question: is popularity a goal? which I won't
try to answer - there have already been a number of discussions about
this issue, and I don't feel like starting a new one :)
cheers
alessio
dpapathanasiou
executable by the kernel; see
http://www.cons.org/cmucl/doc/executable.html and
http://users.actrix.co.nz/mycroft/runlisp.html for more.
This is a good procedure if you're writing server applications where
you control the server.
I'm not sure whether or not there's an equivalent for client apps --
i.e. when you want to create a windows .exe that your users can install
and run on their own machines.
Pascal Bourguignon
> With CMUCL and Linux, you can make compiled FASL (.x86f) files directly
> executable by the kernel; see
> http://www.cons.org/cmucl/doc/executable.html and
> http://users.actrix.co.nz/mycroft/runlisp.html for more.
Also clisp: http://www.podval.org/~sds/clisp/impnotes/image.html
and Allegro CL: http://www.franz.com/support/documentation/8.0/doc/operators/excl/build-lisp-image.htm
basically, almost all Common Lisp implementations allow you to save a
standalone executable.
> R. P. Dillon wrote:
> [...]
>> This is very appealing to me, since I would like to set a very low bar
>> for any users downloading my programs. They wouldn't even know what
>> language it was written in, simply that it ran (like C/++ programs).
See above, you can do that with the other CL too.
>> Finally, my question: using GCL, I haven't been able to produce "end
>> user" binaries of my Lisp code. I can coax a .o, .h, and .c files out
>> of it, but upon linking, I get errors.
I've not used gcl much, but I'd guess you'll have to link edit with
gcl library (the "core image").
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
----------> http://www.netmeister.org/news/learn2quote.html <-----------
---> http://homepage.ntlworld.com/g.mccaughan/g/remarks/uquote.html <---
__Pascal Bourguignon__ http://www.informatimago.com/
dpapathanasiou
files for windows.
>From the page you quoted, it says the :EXECUTABLE key set to non-nil
produces an image file named with the .exe suffix.
Is this a true standalone (i.e. built statically, with all dependent
libraries included), so that if it's run on a windows machine *without*
clisp installed (and cygwin and whatever else clisp needs to run on
windows) it works?
Or does that resulting .exe still need clisp running as well?
If it's the former, then it solves (assuming he's ok with clisp) the
O.P.'s problem.
Pascal Bourguignon
Well, by standalone I mean that the executable doesn't need the clisp
executable or the clisp image. However, it's a binary program like
any other, it will need the shared libraries of the OS, be it Linux,
cygwin, or MS-Windows. Remember that clisp can be compiled natively
on MS-Windows, without cygwin.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
dpapathanasiou
> executable or the clisp image.
Yes, that's exactly what I meant.
We don't work much on windows, but that's useful to know, just in case
we ever need to, in the future.
At any rate, it answers the O.P.'s question.
> cygwin, or MS-Windows. Remember that clisp can be compiled natively
> on MS-Windows, without cygwin.
Ah, I didn't know that; thanks for pointing it out.
R. P. Dillon
It seems that my definition of "native binary" is different than the
rest of the Lisp world's definition. I've read some of the pages you
linked to, and I get that "horrible kludge" feeling. For example, for
CMUCL:
"This mechanism requires the user to have root access, and obviously to
have compiled binfmt_misc support in the kernel (you can check for this
in /proc/filesystems)."
But wait! There's more:
" You must also create an executable shell script
/usr/local/bin/lisp-start containing the following (you may need to
adjust paths, depending on where you installed CMUCL):
#!/bin/sh
CMUCLLIB=/opt/cmucl/lib/cmucl/lib
export CMUCLLIB
exec /opt/cmucl/bin/lisp -quiet -noinit -batch -load ${1+"$@"}"
Wow. So, basically, this use of a "native binary" requires that the
kernel recognize the file type and *load it with CMUCL* (after ensuring
support for some module is compiled into the kernel)! The whole point
of my endeavor was to *lower* the bar for people who would like to use
my application, but have no idea what Lisp, much less CMUCL, are. I
certainly cannot guarantee they will have it installed.
It seems CLISP has th ability to save "standalone executables" of it's
memory image that you can capture using ext:saveinitmem, but I am not
sure how to create a proper image. I managed to create one as I tried
to do my simple "hello world" example, and it was indeed a standalone
executable (yea!), but it was 7.8 MB and when I ran it, it simply put me
into the CLISP read-eval-print loop. It is not clear to me how I could
save an image this way that would let me execute an application. Maybe
I'm simply being thick-headed about this. =)
Thanks for the replies...I expect there is a way (this is Lisp, after
all!) and I will track it down eventually.
Thanks,
Rick
Pascal Bourguignon
> It seems CLISP has th ability to save "standalone executables" of it's
> memory image that you can capture using ext:saveinitmem, but I am not
> sure how to create a proper image. I managed to create one as I tried
> to do my simple "hello world" example, and it was indeed a standalone
> executable (yea!), but it was 7.8 MB and when I ran it, it simply put
> me into the CLISP read-eval-print loop. It is not clear to me how I
> could save an image this way that would let me execute an application.
> Maybe I'm simply being thick-headed about this. =)
You didn't read the implementation notes hard enough.
(defun save-application (name main &optional (documentation "An application"))
(ext:saveinitmem name
:executable t
:quiet t
:norc t
:init-function main
:script t
:documentation documentation))
(defun main ()
(format t "~%Hello World!~%"))
(save-application "hw" (function main))
(ext:shell "./hw")
Hello World!
And 7.8 MB is small, when you remember that the application generated
contains a compiler amongst other niceties.
R. P. Dillon
I will take your example and work from there. I'm already looking at
this under SBCL (I found sb-ext:save-lisp-and-die). You're right, I
just didn't read the docs... I'll do some experimentation with my apps
and see if I can get the desired result.
Rick
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
Javier
R. P. Dillon ha escrito:
> Thank you!
>
> I will take your example and work from there. I'm already looking at
> this under SBCL (I found sb-ext:save-lisp-and-die). You're right, I
> just didn't read the docs... I'll do some experimentation with my apps
> and see if I can get the desired result.
save-lisp-and-die works exactly as you desire, producing a totally
stand-alone application without the need to distribute SBCL with it at
all.
Elsewhere, save-lisp-and-die produce a huge program, around 22Mb or
even more. If you've to add a lot of resources to your program (like
images and more), your application can quickly become a monster in
size. If you distribute your application for Linux, it is better to
include a fasl file with a little script starting SBCL, inside a RPM or
DEB package, and a dependency to the SBCL package itself.
Juho Snellman
> If you distribute your application for Linux, it is better to
> include a fasl file with a little script starting SBCL, inside a RPM or
> DEB package, and a dependency to the SBCL package itself.
That doesn't sound like a very good idea.
SBCL fasls are version-specific, so the user would need to get an RPM
for exactly the right version of SBCL. A careless "yum update", and,
oops, the application no longer works. Or if somebody needs to install
two applications distributed as fasl files, which were built using
different SBCL versions, he'd also have to install those two SBCL
versions installed on the same machine.
--
Juho Snellman
Pascal Bourguignon
Yes. Better provide the .lisp files.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
Javier
Juho Snellman ha escrito:
> Javier <jav...@gmail.com> wrote:
> > If you distribute your application for Linux, it is better to
> > include a fasl file with a little script starting SBCL, inside a RPM or
> > DEB package, and a dependency to the SBCL package itself.
>
> That doesn't sound like a very good idea.
>
> SBCL fasls are version-specific, so the user would need to get an RPM
> for exactly the right version of SBCL.
You're right, sorry.
I can't get imagine if something similar would hapen with, for example
GCC... the entire system would be broken.
So SBCL would not be very apropiate for constructing an entire system
nor a dreamed Lisp machine.
Markus Grueneis
> Javier <jav...@gmail.com> wrote:
>> If you distribute your application for Linux, it is better to
>> include a fasl file with a little script starting SBCL, inside a RPM or
>> DEB package, and a dependency to the SBCL package itself.
>
> That doesn't sound like a very good idea.
>
> SBCL fasls are version-specific, so the user would need to get an RPM
> for exactly the right version of SBCL. A careless "yum update", and,
Well, what is a package system worth if it cannot handle versioned
depencies? BTW, the user should just do 'apt-get blub', and blub has
the correct version depency... Well, probably I should just look up the
docs myself instead of writing useless posts, but I don't think they
would get such important things wrong... Even Firefox knows that it's
extensions are compatible to 0.9.3+ or <1.0 or whatever!
> oops, the application no longer works. Or if somebody needs to install
> two applications distributed as fasl files, which were built using
> different SBCL versions, he'd also have to install those two SBCL
> versions installed on the same machine.
And what? One SBCL takes 25 MB + fasls. My GCC installation comes to..
pff, don't know, but 125? or so MB. Don't think this is problematic.
And you can always say /usr/...../sbcl/0.9.3/bin in the script.
BTW, there has been a time where people had installed libc5 and glibc at
the same time, so linux folks are used to this ;-)
br,
-- Markus
Javier
Markus Grueneis ha escrito:
> BTW, there has been a time where people had installed libc5 and glibc at
> the same time, so linux folks are used to this ;-)
It is not the same to have this issue once up on a time than having to
fix dependencies every time a new version of a compiler is released.
Stuart Ira Glaser
> I can't get imagine if something similar would hapen with, for example
> GCC... the entire system would be broken.
This happened to me, and it wasn't fun. Soon I'll be upgrading to gcc
4.1.1 (from 3.4.6), and I will have to recompile my entire system. Woohoo
My gentoo system makes upgrading GCC very difficult to do accidentally.
If there are enough lisp programs, then upgrading SBCL will follow a
similar process (carefully upgrade, and then recompile everything).
-Stu
Javier
Stuart Ira Glaser ha escrito:
> On Fri, 22 Sep 2006, Javier wrote:
> > I can't get imagine if something similar would hapen with, for example
> > GCC... the entire system would be broken.
>
> This happened to me, and it wasn't fun. Soon I'll be upgrading to gcc
> 4.1.1 (from 3.4.6), and I will have to recompile my entire system. Woohoo
Just imagine the same thing happening not only when upgrading from one
major version to another, with an interval of several years in the case
of GCC, but also from 0.9.6 to 0.9.7, with an interval of months or
weeks in the case of SBCL.
Juho Snellman
> Juho Snellman schrieb:
>> Javier <jav...@gmail.com> wrote:
>>> If you distribute your application for Linux, it is better to
>>> include a fasl file with a little script starting SBCL, inside a RPM or
>>> DEB package, and a dependency to the SBCL package itself.
>>
>> That doesn't sound like a very good idea.
>>
>> SBCL fasls are version-specific, so the user would need to get an RPM
>> for exactly the right version of SBCL. A careless "yum update", and,
>
> Well, what is a package system worth if it cannot handle versioned
> depencies?
No amount of version support in the package system is going to help,
if you don't have the right versions of the packages available. How
many versions of SBCL does your distribution have? Is any of those
versions (or more likely, that single version) still going to be
available six months from now?
> BTW, the user should just do 'apt-get blub', and blub has
> the correct version depency...
The only way where distributing applications like that would be even
remotely plausible, is if you happen to be in the position of getting
it into the same repository that the lisp implementation is in, so
that you can control that the SBCL package is not replaced with a
newer version. And conversely so that every time you release a new
version, you can also upgrade all of the packages that depend on it,
in lockstep.
Most people aren't in that position. So nobody will use their
software, because getting the right version would be such a pain.
>> oops, the application no longer works. Or if somebody needs to install
>> two applications distributed as fasl files, which were built using
>> different SBCL versions, he'd also have to install those two SBCL
>> versions installed on the same machine.
>
> And what? One SBCL takes 25 MB + fasls. My GCC installation comes to..
> pff, don't know, but 125? or so MB. Don't think this is problematic.
> And you can always say /usr/...../sbcl/0.9.3/bin in the script.
Are you aware of anyone actually distributing rpms or debs of SBCL,
which allow you to install multiple versions of it on the same
machine?
--
Juho Snellman
Marcin 'Qrczak' Kowalczyk
>> I can't get imagine if something similar would hapen with, for example
>> GCC... the entire system would be broken.
>
> This happened to me, and it wasn't fun. Soon I'll be upgrading to gcc
> 4.1.1 (from 3.4.6), and I will have to recompile my entire system. Woohoo
There should be no need to recompile everything in this case.
When I installed my Linux system in 1998, it used gcc-2.7.2. Now it
uses gcc-4.2.0. There were only two cases during that time when binary
compatibility was broken for a significant number of programs:
- In the transition between libc5 and libc6 (not caused by gcc),
mixing libc5 and libc6 libraries within one program was impossible.
- In the transition between gcc-2.x and gcc-3.x the C++ ABI has changed.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Markus Grueneis
> Markus Grueneis ha escrito:
>
>> > BTW, there has been a time where people had installed libc5 and glibc at
>> > the same time, so linux folks are used to this ;-)
>
> fix dependencies every time a new version of a compiler is released.
>
That's correct, but this statement's intend was not to propose such a
stituation, as I remember that at this time the usability of some major
Linux distributions was approaching zero. I'll follow usenet convention
next time and use <sarcasm> instead of ;-).
Juho Snellman schrieb:
> Markus Grueneis <markus....@web.de> wrote:
>> [...]
>> Well, what is a package system worth if it cannot handle versioned
>> depencies?
>
> No amount of version support in the package system is going to help,
> if you don't have the right versions of the packages available. [...]
>
Point taken.
>> BTW, the user should just do 'apt-get blub', and blub has
>> the correct version depency...
>
> The only way where distributing applications like that would be even
> remotely plausible, is if you happen to be in the position of getting
> it into the same repository that the lisp implementation is in, so
> that you can control that the SBCL package is not replaced with a
> newer version. And conversely so that every time you release a new
> version, you can also upgrade all of the packages that depend on it,
> in lockstep.
>
> Most people aren't in that position. So nobody will use their
> software, because getting the right version would be such a pain.
>
Read "the user _should just do_", not the user does. I'm aware that
many things don't work out of the box, nevertheless it would be a nice
to have.
I agree on the point that with currently widely used infrastructure it
is not possible when considering all constraints.
>>> oops, the application no longer works. Or if somebody needs to install
>>> two applications distributed as fasl files, which were built using
>>> different SBCL versions, he'd also have to install those two SBCL
>>> versions installed on the same machine.
>> And what? One SBCL takes 25 MB + fasls. My GCC installation comes to..
>> pff, don't know, but 125? or so MB. Don't think this is problematic.
>> And you can always say /usr/...../sbcl/0.9.3/bin in the script.
>
> Are you aware of anyone actually distributing rpms or debs of SBCL,
> which allow you to install multiple versions of it on the same
> machine?
>
My point was more about that it does not seem as so much work to me, but
you are right, no, I don't know of any rpms or debs, I am actually not
even using linux or bsd ATM, and no, I neither have time nor competence
nor willingness to solve this problem, so I should shut up.
Nevertheless I'm frightened that it seems so much of an issue to have
two versions of some package installed. It's probably the same case as
everywhere: as long as you don't work in the field, you don't appreciate
the complexity, nor is it possible to overlook potential problems.
Best regards,
-- Markus
Frank Buss
> And 7.8 MB is small, when you remember that the application generated
> contains a compiler amongst other niceties.
In Forth you can pack a full system, including compiler, some GUI with
interpreter etc., in 181 KB:
http://www.frank-buss.de/tmp/demo.zip
http://www.frank-buss.de/tmp/forth.jpg
The Source:
http://www.frank-buss.de/tmp/demo.f
And this is big, because if you don't include all the symbolic information
for evaluating Forth commands interactivly, the packed exe file is 67 KB.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
J Thomas
Frank Buss wrote:
> Pascal Bourguignon wrote:
>
> > And 7.8 MB is small, when you remember that the application generated
> > contains a compiler amongst other niceties.
>
> In Forth you can pack a full system, including compiler, some GUI with
> interpreter etc., in 181 KB:
>
> for evaluating Forth commands interactivly, the packed exe file is 67 KB.
[sigh] I fondly remember Frank Sergeant's PygmyForth which was 20K
including compiler, text editor, and assembler, and 8K with just
compiler and interpreter. But it ran on MS-DOS. With 120K of source
code one person could eventually understand the whole thing. Including
every detail of how to use it to compile itself and make a brand new
version. Those were the days. Gone forever, I suppose.
Stefan Schmiedl
> [sigh] I fondly remember Frank Sergeant's PygmyForth which was 20K
> including compiler, text editor, and assembler, and 8K with just
> compiler and interpreter. But it ran on MS-DOS. With 120K of source
> code one person could eventually understand the whole thing. Including
> every detail of how to use it to compile itself and make a brand new
> version. Those were the days. Gone forever, I suppose.
Despair not:
s.
mark.h...@gmail.com
> Pascal Bourguignon wrote:
> > And 7.8 MB is small, when you remember that the application generated
> > contains a compiler amongst other niceties.
>
> In Forth you can pack a full system, including compiler, some GUI with
> interpreter etc., in 181 KB:
Please correct me if I'm wrong, but doesn't the size difference relate
to things like code optimization? I'm not a compilers expert but I'm
pretty sure that code for optimizing compiler output is highly
nontrivial ;)
There are some interesting "small compiler executable size" projects
out there -- tcc (for C code) looks pretty neat, though I think it's
only been targeted for x86 thus far. (It's also designed to be really
fast -- the author actually set it up so that you can boot the Linux
kernel from _source_ by setting tcc to be the OS loader.)
Actually it would be neat to get one of those Lisp-to-C compilers and
then run tcc on the output.
mfh
f...@ultratechnology.com
> [sigh] I fondly remember Frank Sergeant's PygmyForth which was 20K
> including compiler, text editor, and assembler, and 8K with just
> compiler and interpreter. But it ran on MS-DOS. With 120K of source
> code one person could eventually understand the whole thing. Including
> every detail of how to use it to compile itself and make a brand new
> version. Those were the days. Gone forever, I suppose.
I fondly remember the early eighties too. I recall that PygmyForth was
inspired by Forth software on Forth hardware: cmForth on Novix.
That was a 6K OS, optimizing compiler, editor, and interpreter.
I recall the other history through colorforth, compressed source,
through
2K OS, compiler and desktop GUI. Fun was always an important
requirement in the process.
The good old days are gone and the good new days are here.
People still enjoy using Lisp and Forth.
Frank Buss
>> In Forth you can pack a full system, including compiler, some GUI with
>> interpreter etc., in 181 KB:
>
> Please correct me if I'm wrong, but doesn't the size difference relate
> to things like code optimization? I'm not a compilers expert but I'm
> pretty sure that code for optimizing compiler output is highly
> nontrivial ;)
I don't think that Win32Forth does much optimizing, but maybe I'm wrong.
But I think the main reason for the much smaller size is that Forth is more
compact (if you disassemble a Lisp function, it looks longer than what is
possible with Forth) and has less features, like garbage collection, if you
don't implement it yourself.
Marcus Red
Don Seglio
--
Cecil
KD5NWA
www.qrpradio.com www.hpsdr.com
"Sacred Cows make the best Hamburger!" Don Seglio Batuna
sl...@jedit.org
> In Forth you can pack a full system, including compiler, some GUI with
> interpreter etc., in 181 KB:
>
> http://www.frank-buss.de/tmp/demo.zip
> http://www.frank-buss.de/tmp/forth.jpg
>
> The Source:
>
> http://www.frank-buss.de/tmp/demo.f
>
> And this is big, because if you don't include all the symbolic information
> for evaluating Forth commands interactivly, the packed exe file is 67 KB.
You're comparing apples with oranges. A Common Lisp implementation
offers a lot more functionality than a Forth, allowing you to develop
programs quicker while reinventing less wheels. If you like, today's
Forths are somewhat comaparable in functionality to a Lisp from the
70's.
Slava
Elizabeth D Rather
That statement is true if and only if you're trying to do the sort of
thing for which Lisp was designed. Lisp has a very specific set of
things it does well, and it's certainly the tool of choice if that's
what you need to do.
Forth is more general, and allows lower-level access. It was originally
designed for embedded-type applications, and is still very strong there.
Forth has rather primitive list processing tools, but is extremely
good for other things like developing control systems and
computationally-intensive applications. It's pretty hard to beat for
embedded systems, particularly where you're trying to control custom
hardware.
Actually, I used both Lisp (briefly) and Forth in the 70's, and the
Forth I used was a lot more powerful. And modern Forths have come quite
a long way since then, too.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
sl...@jedit.org
Elizabeth D Rather wrote:
> That statement is true if and only if you're trying to do the sort of
> thing for which Lisp was designed. Lisp has a very specific set of
> things it does well, and it's certainly the tool of choice if that's
> what you need to do.
>
> Forth is more general, and allows lower-level access. It was originally
> designed for embedded-type applications, and is still very strong there.
> Forth has rather primitive list processing tools, but is extremely
> good for other things like developing control systems and
> computationally-intensive applications. It's pretty hard to beat for
> embedded systems, particularly where you're trying to control custom
> hardware.
Lisp is not about "List processing". If you take a look at Common Lisp,
it supports a number of data types and programming paradigms (object
oriented, functional, declarative).
I understand that Forth is great for resource-constrained embedded
programming, however claiming that it is a better general-purpose
language than Lisp is a stretch.
Is the online shopping cart and order processing infrastructure that
powers www.forth.com written in Forth? If it was, I think it would be
harder to maintain than an equivalent solution in a higher-level
language such as Ruby or Lisp.
Slava
J Thomas
sl...@jedit.org wrote:
> Is the online shopping cart and order processing infrastructure that
> powers www.forth.com written in Forth? If it was, I think it would be
> harder to maintain than an equivalent solution in a higher-level
> language such as Ruby or Lisp.
Elizabeth doesn't suffer from NIH syndrome. When a tool works well
enough, it isn't necessary to replace it with something written in
Forth just for the ease of maintenance etc. It's OK to buy something
and let somebody else maintain it, and only junk it if they don't do a
good enough job.
But that aside, Forth like Lisp is extensible. We can write extensions
that are as high-level as we want. Done well, they'll be precisely as
easy to maintain as similar routines done that well in Lisp.
If it's true that Lisp is more special-purpose than Forth (which I tend
to doubt), It would only be because Lisp might have been designed
without access to some hardware etc and that lack would give it
limitations. And I'm sure you could add extensions which would give you
whatever access you wanted and remove those (hypothetical) limitations.
Extensible languages are general-purpose languages in their essence.
When choosing whether to use Forth or Lisp I would consider which I'm
more comfortable with (Forth in my case, but that's more a tiebreaker
than a great big criterion), which one already has more of the work
already done (hard to tell at the beginning, you don't know quite how
useful the stuff that looks good will be and the gotchas and hard parts
might be where you don't expect them), performance constraints, and
what the customer wants. Unfortunately the last is often the first and
the last criterion, and neither Forth nor Lisp has been doing too well
on that one. [sigh]
sl...@jedit.org
> Elizabeth doesn't suffer from NIH syndrome. When a tool works well
> enough, it isn't necessary to replace it with something written in
> Forth just for the ease of maintenance etc. It's OK to buy something
> and let somebody else maintain it, and only junk it if they don't do a
> good enough job.
>
> But that aside, Forth like Lisp is extensible. We can write extensions
> that are as high-level as we want. Done well, they'll be precisely as
> easy to maintain as similar routines done that well in Lisp.
>
> If it's true that Lisp is more special-purpose than Forth (which I tend
> to doubt), It would only be because Lisp might have been designed
> without access to some hardware etc and that lack would give it
> limitations. And I'm sure you could add extensions which would give you
> whatever access you wanted and remove those (hypothetical) limitations.
>
> Extensible languages are general-purpose languages in their essence.
> When choosing whether to use Forth or Lisp I would consider which I'm
> more comfortable with (Forth in my case, but that's more a tiebreaker
> than a great big criterion), which one already has more of the work
> already done (hard to tell at the beginning, you don't know quite how
> useful the stuff that looks good will be and the gotchas and hard parts
> might be where you don't expect them), performance constraints, and
> what the customer wants. Unfortunately the last is often the first and
> the last criterion, and neither Forth nor Lisp has been doing too well
> on that one. [sigh]
I agree that Forth is extensible and with enough layers you can do just
about anything in a high-level way. I just think Forth advocates go too
far with this angle. An extensible language can only get you so far if
you have to do all the work yourself. The fact that a large portion of
the traffic in this group is devoted to low-level trivialities such as
how to implement structures, OOP and deferred words suggests that the
Forth community mostly consists of minimalists looking to implement the
language as an exercise, rather than use it to solve problems.
Slava
J Thomas
sl...@jedit.org wrote:
> I agree that Forth is extensible and with enough layers you can do just
> about anything in a high-level way. I just think Forth advocates go too
> far with this angle. An extensible language can only get you so far if
> you have to do all the work yourself. The fact that a large portion of
> the traffic in this group is devoted to low-level trivialities such as
> how to implement structures, OOP and deferred words suggests that the
> Forth community mostly consists of minimalists looking to implement the
> language as an exercise, rather than use it to solve problems.
Pehaps the newsgroup has become an embarrassment that way. It's mostly
minimalists etc who want to play with low-level stuff who post snippets
of code here. I find that fun myself, and yet I sort of cringe when
kibitzers say that's what's going on in Forth. I don't want to stop
doing it just because people get the wrong impression, but here it is
happening again.
I'd like to claim that comp.lang.forth doesn't have lots of clueless
newbies asking how to do things because Forth makes it particularly
easy to find out how to do things. But maybe it's more that we don't
have enough clueless newbies, maybe we'd be better off with more of
that sort of thing.
Anyway, it looks to me like Forth and Lisp are fundamentally very very
similar languages, and the user communities are suffering rather
similar problems. Not much point in a Forth/Lisp language war. It might
be more amusing to discuss which of Intercal and Brainfuck make a
better general-purpose programming language, and which of them should
have more commercial success.
Gary Chanson
<sl...@jedit.org> wrote in message
news:1159148025....@d34g2000cwd.googlegroups.com...
>
> I agree that Forth is extensible and with enough layers you can do just
> about anything in a high-level way. I just think Forth advocates go too
> far with this angle. An extensible language can only get you so far if
> you have to do all the work yourself. The fact that a large portion of
> the traffic in this group is devoted to low-level trivialities such as
> how to implement structures, OOP and deferred words suggests that the
> Forth community mostly consists of minimalists looking to implement the
> language as an exercise, rather than use it to solve problems.
But there are exceptions. Take a look at my Quest32 for example.
--
- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools
Espen Vestre
> That statement is true if and only if you're trying to do the sort of
> thing for which Lisp was designed. Lisp has a very specific set of
> things it does well, and it's certainly the tool of choice if that's
> what you need to do.
>
> Forth is more general, and allows lower-level access.
I won't dispute that Forth is better suited for low-level, embedded-
systems kind of programming, but that doesn't make it more "general"
than Common Lisp.
--
(espen)
Bernd Paysan
> You're comparing apples with oranges.
That's obvious.
> A Common Lisp implementation
> offers a lot more functionality than a Forth, allowing you to develop
> programs quicker while reinventing less wheels. If you like, today's
> Forths are somewhat comaparable in functionality to a Lisp from the
> 70's.
Ah, did Lisp in the 70s already had a GUI library and such like MINOS in
bigFORTH? I thought the GUI didn't come up until the 80s, and it was in
Smalltalk.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bernd Paysan
> I agree that Forth is extensible and with enough layers you can do just
> about anything in a high-level way. I just think Forth advocates go too
> far with this angle. An extensible language can only get you so far if
> you have to do all the work yourself. The fact that a large portion of
> the traffic in this group is devoted to low-level trivialities such as
> how to implement structures, OOP and deferred words suggests that the
> Forth community mostly consists of minimalists looking to implement the
> language as an exercise, rather than use it to solve problems.
But that was mostly discussion for the Forth 200x standard. All these parts
were implemented a long time ago, and are now in use, but these extensions
were different in different Forths. Now we want to standardize on them, so
we have to go back to the trivialities.
In the Lisp world, this is already history, and the standard track went to
Common Lisp, i.e. towards featuritis. Then people invented Scheme, and all
the little trivialities started again.
mal...@gmail.com
spe(spu) chip (8 spe chips in total + a dual PPE one which doesn't have
such memory limitation). So such projects might get reused there, if C
is not suitable for some of the tasks on it.
Lars Brinkhoff
> Ah, did Lisp in the 70s already had a GUI library and such like
> MINOS in bigFORTH?
The first Lisp machines were developed in the mid 1970ies and had a GUI.
> I thought the GUI didn't come up until the 80s, and it was in
> Smalltalk.
According to Wikipedia, the Xerox Alto was developed in 1973, but
wasn't programmed in Smalltalk. Xerox Star was the first commercial
GUI system in 1981.
Lars Brinkhoff
> In the Lisp world, this is already history, and the standard track went to
> Common Lisp, i.e. towards featuritis. Then people invented Scheme, and all
> the little trivialities started again.
Scheme was invented years before Common Lisp.
ken...@cix.compulink.co.uk
<1159146508....@k70g2000cwa.googlegroups.com>,
jeth...@gmail.com (J Thomas) wrote:
> If it's true that Lisp is more special-purpose than Forth
> (which I tend to doubt), It would only be because Lisp might
> have been designed without access to some hardware
I think the origins of a language influence development. Forth
was IIRC originally developed to run a radio telescope. Lisp
originated in the Artificial Intelligence research. Both became
more general purpose with each implementation but like Fortran
and Cobol you can still see the roots. C by the way was designed
to write operating systems not as a general purpose language.
> Unfortunately the last is often the first and
> the last criterion, and neither Forth nor Lisp has been doing
> too well on that one. [sigh]
Judging by numbers of lines of source in use I think you will
find that Cobol is still the most used language, though the last
figures I saw were in 1999.
Ken Young
James
>
> That statement is true if and only if you're trying to do the sort of
> thing for which Lisp was designed. Lisp has a very specific set of
> things it does well, and it's certainly the tool of choice if that's
> what you need to do.
For me, it's like this: If I have a problem that's fairly simple and
contained and maps well to an imperative style of programming, then
Forth is great. An example is decoding a particular file format (like
a COFF header). But for problems that are more complex, I find I can
get results much faster in a language like Lisp (or Perl or Python or
Erlang). A peculiar example is writing an optimizing Forth compiler.
In Forth, I'm not sure how I'd approach this. I'd have to build up a
set of tools first, but I'm not sure which tools I should build. In a
language like Erlang (which has a lot in common with Lisp), I could
bang out a rough prototype in an evening, and I'd have a lot more faith
in the resulting code (no accidental memory overwrites, for example).
James
GP lisper
> sl...@jedit.org wrote:
>
> Lisp has a very specific set of things it does well
NO.
Lisp has a very specific set of things it does not do well.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper
>
> You're right, I just didn't read the docs...
yah, it's always more fun just to rant, right?
Don't worry, we'll remember
GP lisper
> Stuart Ira Glaser <si...@hive.cec.wustl.edu> writes:
>
>>> I can't get imagine if something similar would hapen with, for example
>>> GCC... the entire system would be broken.
>>
>> This happened to me, and it wasn't fun. Soon I'll be upgrading to gcc
>> 4.1.1 (from 3.4.6), and I will have to recompile my entire system. Woohoo
>
> There should be no need to recompile everything in this case.
That's true, and I have done the same as you mentioned. Gentoo makes
a total recompile a painless process, and it can be done as a
background process while continuing to utilize the computer. Alas,
that process is soooo easy, that the Gentoo devs play far out on the
bleeding edge.
Ken Tilton
Elizabeth D Rather wrote:
> sl...@jedit.org wrote:
>
>> Frank Buss wrote:
>>
>>> In Forth you can pack a full system, including compiler, some GUI with
>>> interpreter etc., in 181 KB:
>>>
>>> http://www.frank-buss.de/tmp/demo.zip
>>> http://www.frank-buss.de/tmp/forth.jpg
>>>
>>> The Source:
>>>
>>> http://www.frank-buss.de/tmp/demo.f
>>>
>>> And this is big, because if you don't include all the symbolic
>>> information
>>> for evaluating Forth commands interactivly, the packed exe file is 67
>>> KB.
>>
>>
>> You're comparing apples with oranges. A Common Lisp implementation
>> offers a lot more functionality than a Forth, allowing you to develop
>> programs quicker while reinventing less wheels. If you like, today's
>> Forths are somewhat comaparable in functionality to a Lisp from the
>> 70's.
>
>
> That statement is true if and only if you're trying to do the sort of
> thing for which Lisp was designed.
Programming and drinking beer?
<sigh>
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Espen Vestre
> Programming and drinking beer?
>
> <sigh>
>
> ken
Wine is fine with me, too.
But usually I prefer Ristretto when hacking ;-)
--
(espen)
pablo reda
Espen Vestre ha escrito:
I like MATE (infusion hot water) to program.
Julian V. Noble
Does Common Lisp generally include an assembler?
I use Forth mainly for fp numeric-intensive applications. Some
Forths are optimized for this already, but if I need speed I
hand-code the bottleneck routines in assembler. Very convenient.
I would be willing to bet that most Forth programs that do some
particular thing are a) smaller; b) faster than their Common
Lisp equivalents. But I can't say for sure, as I have not tested
this. I only know it was true for my gamma-matrix algebra program
in HS/Forth vs. one that someone else wrote in Mu-Lisp.
--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
Ken Tilton
Oh, /while/ programming? That would be irish whisky or russian vodka,
straight.
A "few specific things", indeed.
kt
Elizabeth D Rather
In the last 10 years there have been a number of excellent optimizing
Forth compilers developed (including SwiftForth and SwiftX cross
compilers for about a dozen target CPUs), and as far as I know all were
written in Forth.
What language you feel comfortable with for a particular project
probably depends as much on your experience with various languages as
the languages' inherent properties.
Ken Tilton
Elizabeth D Rather wrote:
> What language you feel comfortable with for a particular project
> probably depends as much on your experience with various languages as
> the languages' inherent properties.
Nope. Most lispniks and I imagine forthwrites (?) have mastered many
languages over the years and probably rule the roost at work using
something other than their pet, and /still/ swear by Lisp or Forth
precisely because of its inherent properties.
In fact, a large fraction of Roads to Lisp began with a deliberate
search for Something Better than the inherent properties of the
languages with which they were already kicking ass relative to other
programmers.
ken
Reinhold Straub
J Thomas wrote:
> But that aside, Forth like Lisp is extensible. We can write extensions
> that are as high-level as we want. Done well, they'll be precisely as
> easy to maintain as similar routines done that well in Lisp.
>
> If it's true that Lisp is more special-purpose than Forth (which I tend
> to doubt), It would only be because Lisp might have been designed
> without access to some hardware etc and that lack would give it
> limitations. And I'm sure you could add extensions which would give you
> whatever access you wanted and remove those (hypothetical) limitations.
Most programming languages seem to be good on some levels of
abstraction and difficult to use at others. Lisp and Python are high
level,
and although you can extend them with low level functions written in C,
that doesn't have anything to do with rapid development.
Well, I always wanted to have one language with tools for programming
at
various levels of abstraction: to write fast code for the algorithms
and to
write code for the GUI easily, for instance. Forth could be such a
language, because it is extensible and is low level (at least some
implementations are, that is, have an optimising compiler which is
processor
specific). But extensibility is not enough in itself: you'd have to
have a
library of suitable high level extensions.
A good example is Powermops: it is Forth with an optimising compiler
and
SIMD vector instructions for the low level stuff, while on the other
hand
you can call the Mac API functions and use object programming with
garbage collection for higher level programming.
There is still lacking a lot of features, you still can't write
programs
efficiently, but I think this project is heading towards the right
direction.
Cheers,
Reinhold Straub
Andreas Kochenburger
> Judging by numbers of lines of source in use I think you will
>find that Cobol is still the most used language, though the last
>figures I saw were in 1999.
Being an oldtimer myself, I am curious to know if C, C++ and Java have
not taken the lead over Cobol meanwhile
Andreas
-------
1 + 1 = 3, for large values of 1.
James
>
> In the last 10 years there have been a number of excellent optimizing
> Forth compilers developed (including SwiftForth and SwiftX cross
> compilers for about a dozen target CPUs), and as far as I know all were
> written in Forth.
Oh, yes, I know. What I was trying to say is that, given the task of
writing an optimizing compiler for Forth (or a Forth-like language),
I'd find it much more approachable in a higher-level language. I
*could* write it in Forth or PowerPC assembly language or whatever, but
I could be much more productive in Lisp/Erlang/Prolog/etc. This is
even though I'm experienced with Forth.
Why? Because lots of issues are immediately solved for me, and I can
focus on the high-level problem solving. I can transform source code
on a symbolic level, without worrying about the details of how syntax
trees map to memory. I can do pattern matching on the source code. In
Forth I'd have to build up a toolset first.
John Thingstad
wrote:
>
> I would be willing to bet that most Forth programs that do some
> particular thing are a) smaller; b) faster than their Common
> Lisp equivalents. But I can't say for sure, as I have not tested
> this. I only know it was true for my gamma-matrix algebra program
> in HS/Forth vs. one that someone else wrote in Mu-Lisp.
>
>
Try Corman Lisp.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Stephen Pelc
>A peculiar example is writing an optimizing Forth compiler.
>In Forth, I'm not sure how I'd approach this. I'd have to build up a
>set of tools first, but I'm not sure which tools I should build. In a
>language like Erlang (which has a lot in common with Lisp), I could
>bang out a rough prototype in an evening, and I'd have a lot more faith
>in the resulting code (no accidental memory overwrites, for example).
The key to an optimising compiler is in the data structures and
algorithms. Getting from a "rough prototype" to a production
compiler takes much longer than writing the rough prototype.
For someone familiar with the implementation language of the
compiler, the choice of implementation language may be heavily
impacted by abstraction faults caused by the compiler writer's
language being very different from the target language.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
GP lisper
> On Mon, 25 Sep 2006 06:34:19 -0500, ken...@cix.compulink.co.uk wrote:
>> Judging by numbers of lines of source in use I think you will
>>find that Cobol is still the most used language, though the last
>>figures I saw were in 1999.
>
> Being an oldtimer myself, I am curious to know if C, C++ and Java have
> not taken the lead over Cobol meanwhile
Who cares about lines? I'd rather be paid as a Cobol programmer over
a C/Java programmer anyday!
Julian V. Noble
>
>
> pablo reda wrote:
>> Espen Vestre ha escrito:
>>
>>
>>> Ken Tilton <kent...@gmail.com> writes:
>>>
>>>
>>>> Programming and drinking beer?
>>>>
>>>> <sigh>
>>>>
>>>> ken
>>>
>>> Wine is fine with me, too.
>>> But usually I prefer Ristretto when hacking ;-)
>>> --
>>> (espen)
>>
>>
>> I like MATE (infusion hot water) to program.
>>
>
> Oh, /while/ programming? That would be irish whisky or russian vodka,
> straight.
>
> A "few specific things", indeed.
>
> kt
>
>
Good single malt. Stimulates the little grey cells.
Jecel
Lars Brinkhoff wrote:
> According to Wikipedia, the Xerox Alto was developed in 1973, but
> wasn't programmed in Smalltalk. Xerox Star was the first commercial
> GUI system in 1981.
While not incorrect, the Wikipedia article is very misleading.
Smalltalk-72 was the very first software system ported to the Alto
(from the Data General Nova, hence the design of the standard Alto
macro instruction set) and for a while was the only programming
environment for it. Most non Smalltalk applications were written in
BCPL but unless you lump all Smalltalk apps together there were quite a
few of them.
Back to the topic, I enjoy both Forth and Lisp and don't think either
has an inherent advantage over the other in terms of generality,
minimum size or low level access though comparing specific
implementations might give you this idea. See L. Peter Deutsch's Lisp
for the PDP-1 for an example of how small it can be.
-- Jecel
Rob Thorpe
> Thank you!
>
> I will take your example and work from there. I'm already looking at
> this under SBCL (I found sb-ext:save-lisp-and-die). You're right, I
> just didn't read the docs... I'll do some experimentation with my apps
> and see if I can get the desired result.
>
>From memory this is how you do it on various systems:
CMUCL
* Dump a core with save-lisp-and-die and ship the "lisp" executable &
the core file
SBCL
* Dump a core with save-lisp-and-die and ship the "sbcl" executable &
core file
* Or use the :executable argument to save-lisp-and-die for a single exe
ECL
* Instructions are given in the "reference manual" (not the user
manual) basically they instruct you to rebuild the whole system with
extra lisp files built in.
GCL
* Use si::save-system which does the same thing as
(sb-ext:save-lisp-and-die :executable t)
CLisp
* Do what Pascal B said! It's also in the docs somewhere.
When dumping core SBCL, CMUCL & the ANSI standard Common lisp GCL all
generate large files ~22-30MB. CMUCLs executable system generates
smaller files ~8MB, as does ECL ~2MB and Cltl1 GCL ~4MB.
You can also make fasl files executable on Linux using CMUCL as you
have found, but this is more of a conviences for developers than a
function for distributing programs (AFAIK). It could be useful though
if you want to distribute an application composed of many lisp programs.
Rahul Jain
> Does Common Lisp generally include an assembler?
Implementations that compile to native code directly (as opposed to via
a C compiler) would obviously need one. However, the assemblers in Lisp
compilers tend to have a Lispy syntax (which suits Lispers just fine,
thank you ;). CMUCL and SBCL provide simple ways of writing functions in
assembly that can be called from regular Lisp code.
--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Howerd Oakford
>Those were the days. Gone forever, I suppose.
The colorForth kernel is about 2K bytes and runs directly on a PC's
hardware.
I estimate that when colorForth is written in colorForth it will be
less than 256K bytes of source ( currrently its mostly in assembler ).
Not that this is a competition ( mine's smaller than yours ;) , but it
_is_ possible to understand the whole system...
Regards
Howerd 8^)
J Thomas wrote:
> Frank Buss wrote:
> > Pascal Bourguignon wrote:
> >
> > > And 7.8 MB is small, when you remember that the application generated
> > > contains a compiler amongst other niceties.
> >
> > In Forth you can pack a full system, including compiler, some GUI with
> > interpreter etc., in 181 KB:
> >
> > And this is big, because if you don't include all the symbolic information
> > for evaluating Forth commands interactivly, the packed exe file is 67 KB.
>
Albert van der Horst
Howerd Oakford <how...@yahoo.co.uk> wrote:
>Hi Jonah,
>
>>Those were the days. Gone forever, I suppose.
>The colorForth kernel is about 2K bytes and runs directly on a PC's
>hardware.
>I estimate that when colorForth is written in colorForth it will be
>less than 256K bytes of source ( currrently its mostly in assembler ).
>Not that this is a competition ( mine's smaller than yours ;) , but it
>_is_ possible to understand the whole system...
Spot on. The latest reassemblable source of colorforth is 260 K.
This is for the ciasdis tool.
That source contains:
1. assembler code in (rather verbose) postit-fixup style
2. labels with names related to the Forth words
3. many spaces
4. the hex code of colorforth in comment
5. all graphics symbols as maps of ones and zeros.
6. the screens in pseudo colorcode (palatable for the assembler
but in strict one to one correspondence with color screens)
(in other words, complete.)
It requires in addition a 7 k extension (colorname.frt) to add
handling colorforth characters to ciasdis.
I don't count that as a colorforth source, though.
colorforth is a though cooky for a disassembler, especially
if you want to extract symbolic information (Huffman coded)
from the binary code. This requires dedicated scripting.
More via my site below, click on FTP. This gives you access
to a repository of all historic versions of the disassembly.
Groetjes Albert
>
>Regards
>
>Howerd 8^)
>
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
David Douthitt
> People still enjoy using Lisp and Forth.
I've been a fan of both for a very long time -
along with Smalltalk. It's only recently that
I realized that all three share the same ideas that
make them great (except for the unique OOP that Smalltalk
adds on top of everything else).
All three use the "incremental" idea of programming, and
the concept of working on a "live" system compared to the
edit-compile-test sequence.
Adherents of all three look at people like they have
a third eye when the inevitable question comes up:
"How do I save my program as a standalone binary?" :-)
I have noticed that LISP is entering a major resurgence
apparently (watch the news posting counts). Too bad
FORTH and Smalltalk can't follow suit.
--
David Douthitt
LPIC Level 1, Linux+, SCSA, RHCE
HP-UX, Unixware, BSD, HP-UX, Linux, Solaris
http://www.lulu.com/ssrat
Rob Thorpe
> In comp.lang.forth f...@ultratechnology.com wrote:
> > People still enjoy using Lisp and Forth.
>
> I've been a fan of both for a very long time -
> along with Smalltalk. It's only recently that
> I realized that all three share the same ideas that
> make them great (except for the unique OOP that Smalltalk
> adds on top of everything else).
Well, Common Lisp has an object system too: CLOS. Whatever OOP a
language uses it's normally pretty unique to that language. Common
Lisp has unique OOP too, it's just, well, differently unique.
See http://home.comcast.net/~prunesquallor/guide.html
> All three use the "incremental" idea of programming, and
> the concept of working on a "live" system compared to the
> edit-compile-test sequence.
>
> Adherents of all three look at people like they have
> a third eye when the inevitable question comes up:
> "How do I save my program as a standalone binary?" :-)
Maybe, I don't, I started programming with languages where you had to
think like that.
> I have noticed that LISP is entering a major resurgence
> apparently (watch the news posting counts). Too bad
> FORTH and Smalltalk can't follow suit.
I'm not sure Smalltalk isn't. Lot's of people seem to be talking about
it on the web, that's not always a reliable sign though.
Pascal Costanza
>> I have noticed that LISP is entering a major resurgence
>> apparently (watch the news posting counts). Too bad
>> FORTH and Smalltalk can't follow suit.
>
> I'm not sure Smalltalk isn't. Lot's of people seem to be talking about
> it on the web, that's not always a reliable sign though.
Smalltalk had more an indirect effect in the past, and I think this is
still the case. Currently, Ruby is very clearly influenced by the
Smalltalk object model.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Charlton Wilbur
> Rob Thorpe wrote:
>
> >> I have noticed that LISP is entering a major resurgence
> >> apparently (watch the news posting counts). Too bad
> >> FORTH and Smalltalk can't follow suit.
>
> > I'm not sure Smalltalk isn't. Lot's of people seem to be talking
> > about it on the web, that's not always a reliable sign though.
>
> Smalltalk had more an indirect effect in the past, and I think this is
> still the case. Currently, Ruby is very clearly influenced by the
> Smalltalk object model.
As is Objective-C, which is also experiencing a bit of popularity right now.
Charlton
Pascal Bourguignon
> Rob Thorpe wrote:
>
>>> I have noticed that LISP is entering a major resurgence
>>> apparently (watch the news posting counts). Too bad
>>> FORTH and Smalltalk can't follow suit.
>> I'm not sure Smalltalk isn't. Lot's of people seem to be talking
>> about
>> it on the web, that's not always a reliable sign though.
>
> Smalltalk had more an indirect effect in the past, and I think this is
> still the case. Currently, Ruby is very clearly influenced by the
> Smalltalk object model.
And Objective-C (MacOSX), which takes both the syntax and semantics of
Smalltalk OO and put it almost unchanged over C.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
John Doty
> Pascal Costanza <p...@p-cos.net> writes:
>
>> Rob Thorpe wrote:
>>
>>>> I have noticed that LISP is entering a major resurgence
>>>> apparently (watch the news posting counts). Too bad
>>>> FORTH and Smalltalk can't follow suit.
>>> I'm not sure Smalltalk isn't. Lot's of people seem to be talking
>>> about
>>> it on the web, that's not always a reliable sign though.
>> Smalltalk had more an indirect effect in the past, and I think this is
>> still the case. Currently, Ruby is very clearly influenced by the
>> Smalltalk object model.
>
> And Objective-C (MacOSX), which takes both the syntax and semantics of
> Smalltalk OO and put it almost unchanged over C.
>
>
And that's very nice, because the power tools and the hand tools have
different grips, so you know what you're using. But if you (ala C++)
made chain saws that looked like screwdrivers a lot of people would lose
their fingers...
--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
Neal Bridges
news:4547a68c$0$81350$ae4e...@news.nationwide.net...[snip]
>
> I have noticed that LISP is entering a major resurgence
> apparently (watch the news posting counts). Too bad
> FORTH and Smalltalk can't follow suit.
You should check the actual numbers before making such declarations.
Here are the stats from the last two quarters, Q2 and Q3 2006 -- consider
that the Q3 results may be skewed upward by back-to-school:
comp.lang.smalltalk: posts down 6%, posters down 5%
comp.lang.lisp: posts down 4%, posters down 12%
comp.lang.forth: posts up 59%, posters up 34%
Source: http://netscan.research.microsoft.com
--
Neal Bridges
Quartus Handheld Software
http://www.quartus.net
znmeb
Pascal Costanza wrote:
> Rob Thorpe wrote:
>
> >> I have noticed that LISP is entering a major resurgence
> >> apparently (watch the news posting counts). Too bad
> >> FORTH and Smalltalk can't follow suit.
> >
> > I'm not sure Smalltalk isn't. Lot's of people seem to be talking about
> > it on the web, that's not always a reliable sign though.
>
> Smalltalk had more an indirect effect in the past, and I think this is
> still the case. Currently, Ruby is very clearly influenced by the
> Smalltalk object model.
I'm learning Ruby, and I must say that it has made me appreciate Lisp,
Scheme and Forth more as *practical* alternatives to C! Ruby is a
wonderful language -- I view it as a hybrid of Perl and Smalltalk. But
its internals are written in C, and it can't compile itself or
interpret itself yet in the same manner that Forth, Lisp and Scheme can.