Paul Prescod (········@csclub.uwaterloo.ca) wrote:
[Snip]
: I think that the average programmer thinks procedurally. No amount of money
: is going to convince him or her to spend the intellectual effort to figure
: out how to express their problems recursively, or using higher order functions;
: especially if their "problem" is handling mouse clicks and sending messages
: to windowing "objects" or databases. You can use Lisp as if it weren't a
: language designed to implement the lambda calculus, but is it really
: competitive as a Better Basic than Basic? Not if you are learning from a
: traditional Lisp text.
On the contrary, I've found Lisp to work well as both a functional
and imperative (procedural) language. Granted, the majority of
applications tend to be non-side effecting functions, but there
are those even in procedural languages so there shouldn't be
any major leap. I'm using Elisp (Emacs' Lisp) and due to severe
limits on recursion capabilities, I find myself programming in
a more imperative style, with greater ease than traditionally
imperative languages (even the simple ones like Basic).
With that said, I do wish Emacs would allow deeper recursion
depths so I could use functional programming.
One thing Lisp would be great for is as a stepping stone to
functional programming. Since you could do both procedural
and functional programming in Lisp, it makes the perfect
platform to bring procedural programmers to the functional
side of the fence.
: So my call is no: Microsoft could not make Lisp fly through sheer force of
: will and cash, unless they turned it into Basic, or worse, "Visual Basic".
M$ would do it simply because they have an unwholesome love of Basic :(.
: Paul Prescod
--
Cya,
Ahmed
Brains for dinner, brains for lunch
Brains for breakfast, brains for brunch
Brains at every single meal
Why can't we have some guts?
"Brain Eaters" by the Misfits
On 12 Feb 1997 01:40:21 GMT, ········@Bayou.UH.EDU
(········@bayou.uh.edu) wrote:
>One thing Lisp would be great for is as a stepping stone to
>functional programming. Since you could do both procedural
>and functional programming in Lisp, it makes the perfect
>platform to bring procedural programmers to the functional
>side of the fence.
Wouldn't it be good - as a long shot - if we could reengineer
programmer society?
If different languages could integrate better, so programmers could
have individual languages... a society where the language a programmer
use is thought to reflect his intelligence/training - rather than the
C-conformist world of today?
A company might hire a team of teenage C programmers to code a game
(typical teenage C programmer goal, believe me!), but when they make a
hash of the AI they try to lay onto their fast graphics engine, hire
an expensive PROLOG god[ess] to code a true genius of an AI?
Then those who took the time to study 'experimental' languages at the
cutting edge of the science would gain /respect/, and on the other
side of the same coin, people would not be content to stick with C++.
They would strive for more powerful languages like athletes strive for
the Olympics...
ABW
--
"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
(Windows for Early Warning and Defence User's manual P385)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3064774168975969@naggum.no>
* ········@Bayou.UH.EDU
| With that said, I do wish Emacs would allow deeper recursion depths so I
| could use functional programming.
it is unclear what you think you need to change in Emacs to get what you
want, but it appears that you have not tried to increase the values of
`max-lisp-eval-depth' and `max-specpdl-size'. I suggest you try that and
see if you can do what you want to do. I think it is safe to assume that
the average user would prefer to have Emacs error early on an infinite
recursion in the making rather than recurse very deeply. after all, none
of the distributed packages recurse very deeply.
#\Erik
--
my other car is a cdr
Erik Naggum (····@naggum.no) wrote:
: * ········@Bayou.UH.EDU
: | With that said, I do wish Emacs would allow deeper recursion depths so I
: | could use functional programming.
: it is unclear what you think you need to change in Emacs to get what you
: want, but it appears that you have not tried to increase the values of
: `max-lisp-eval-depth' and `max-specpdl-size'. I suggest you try that and
: see if you can do what you want to do. I think it is safe to assume that
: the average user would prefer to have Emacs error early on an infinite
: recursion in the making rather than recurse very deeply. after all, none
: of the distributed packages recurse very deeply.
Well I did set max-lisp-eval-depth to max-specdpl-size, but I didn't
touch max-specdpl-size since the way it was described it seemed like
the kind of variable I wouldn't want to touch.
Now I've got a recursion depth of 600, which while excellent for
some tasks is also woefully inadequate for others (consider
processing matches of characters or strings in a text file,
you can easily exceed the 600 mark). I suppose the best solution
would be if Elisp did automatic tail recursion optimization
(or even other recursion optimization), but I won't complain
too much -- it's already a goldmine to have such a powerful
language with which to customize a text editor!
: #\Erik
: --
: my other car is a cdr
Heheheh, nice .sig :)
--
Cya,
Ahmed
And I know she must think I'm screwed,
That I'm only interested in food,
But when I looked deep into her eyes,
I wanted more than a burger and fries.
"Burger King Queen" by the Queers
In article <··········@Masala.CC.UH.EDU>,
········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
>On the contrary, I've found Lisp to work well as both a functional
>and imperative (procedural) language.
...
>One thing Lisp would be great for is as a stepping stone to
>functional programming. Since you could do both procedural
>and functional programming in Lisp, it makes the perfect
>platform to bring procedural programmers to the functional
>side of the fence.
But why would they change to Lisp to do procedural programming?
They don't want to do functional programming and Lisp doesn't
seem any better at procedural programming than anything else.
Paul Prescod