Date: Mon, 16 Jun 1997 03:48:18 -0400 From: Joel Ray Holveck <joelh@gnu.ai.mit.edu> To: jkh@time.cdrom.com Cc: msmith@atrad.adelaide.edu.au, devnull@gnu.ai.mit.edu, molter@logic.it, adrian@obiwan.psinet.net.au, vas@vas.tomsk.su, chat@FreeBSD.ORG Subject: Re: To UNIX or not to UNIX ;-). Was: PPP problems. Message-ID: <199706160748.DAA17985@ethanol.gnu.ai.mit.edu> In-Reply-To: <17960.866444663@time.cdrom.com> (jkh@time.cdrom.com)
next in thread | previous in thread | raw e-mail | index | archive | help
>> I personally am going to speak up for Guile, because Lisp is a great
>> language.
> It's a fine language, one which I'm a big fan of, but it's still just
> not practical to expect everyone to learn it. FORTH falls into a
> similar category: powerful but arcane.
Correct. It is not practical to expect everyone to learn it. I also
don't expect people to learn PostScript; I just provide an app that
relies on PostScript to draw what the user inputs.
Just as with the package system, most configuration cases can be
handled by a simple structure. One needn't know Lisp to write it;
Lisp excells at reading other structures, and the native read format
is good as it stands. Extentions to this basic structure could be
made to account for various needs, and then in extreme cases then Lisp
or C can be written to handle the new needs on a per-package basis, to
be included in the package and assimilated by the configuration system
at runtime. Consider the following configuration file, for a
hypothetical networking extention MegaFoo, which contains one variable
(a server name) that it puts as FOO_BAZ in /etc/rc.conf, and one flag
which it puts in /etc/foo.cf as "set frob<-yes".
(megafoo
:label "MegaFoo 3.1 Configuration"
:subcategory networking
:options
((baz
:label "Baz Server"
:type string
:accept
"\(\([A-Za-z_]+\.\)*[A-Za-z_]+\)\|\([0-9]\.[0-9]\.[0-9]\.[0-9]\)"
:file "/etc/rc.conf"
:variable "FOO_BAZ")
(frob
:label "Frob Flag"
:type boolean
:booltype yes-no
:file "/etc/foo.cf"
:regexp "^set frob<-[a-z]*$"
:replacement "set frob<-%0")))
>The number of people who can write truly competent ELISP, for example,
>can probably be counted on two hands, and remember that emacs has been
>out for many years now. If there was not a significant learning-curve
>to lisp then it probably would have taken over the world already, QED.
I will object to both points. I have seen many people who can write
very good Emacs Lisp, but I am presently hacking Emacs so tend to have
a skewed viewpoint. Second, learning curve does not indicate
popularity. Lots of other items, including marketing and
happenstance, do that.
>LISP has also already more than had its chance to become *the*
>interpreted language of choice and, instead, we've seen things like
>BASIC brought out of retirement before we've seen a general movement
>to LISP.
Remember that Lisp used to be the interpreted language of choice.
Unix took over a lot of the academic OS share, and with it C took over
the minds of the programmers. However, C is designed for different
problems than Lisp (and DON'T give me Turing arguments here). I think
that this, for the most part, is a Lisp problem, not a C problem. The
interface can be handled by Guile and subterfuge.
>What does that tell you? That all programmers are stupid?
>Perhaps, but such conclusions are hardly valuable. :-)
I won't make that conclusion yet.
>TCL's rapid success, and after only a comparatively recent
>introduction, only demonstrates that there is still a need for more
>simplistic procedural languages, TCL being something which can be
>learned in about an hour by any reasonably competent programmer - it's
>a language of truly trivial implementation and scope.
The other Joel is the one arguing against TCL, not I. Personally, I
have not had the pleasure (or pain, as the case may be) of hacking in
TCL. My language experience is limited primarily to the real biggies:
(in fairly random order) BASIC, Fortran, Lisp (in different dialects),
Pascal, C, C++, Perl, Intercal, assembly (8088, 360, and MIX), and
some special-purpose languages such as Mathematica and TeX. If you
think it to be that important to today's modern programmer, and that
easy to learn, then point me to a TCL reference and I'll learn it. My
point is that each language has its strengths and weaknesses. I
wouldn't write a recursive-descent parser in Fortran, solve the eight
queens problem in Perl, write an x10 interface in Lisp, write a node
graph analyzer in C, or do anything nontrivial in Intercal. Each
language has its own problems it can solve (or, in Intercal's case, to
create), so I say put each problem to its proper language.
>I also know about GUILE's plans to put a mini-C environment on top in
>order to pave over these issues, but I haven't seen that bear much
>fruit yet. It's still just an idea.
Which issues? Can you be more specific?
Happy hacking,
joelh
--
http://www.wp.com/piquan --- Joel Ray Holveck --- joelh@gnu.ai.mit.edu
All my opinions are my own, not the Free Software Foundation's.
Second law of programming:
Anything that can go wrong wi
sendmail: segmentation violation -- core dumped
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706160748.DAA17985>