Functional Programing: stop using recursion, cons. Use map & vectors.
〈Guy Steele on Parallel Programing〉
http://xahlee.org/comp/Guy_Steele_parallel_computing.html
btw, lists (as cons, car, cdr) in the lisp world has always been some
kinda cult. Like, if you are showing some code example and you
happened to use lisp vector datatype and not cons (lists) and it
doesn't really matter in your case, but some lisper will always rise
up to bug you, either as innocent curious question or attacking you
for not “understanding” lisp. (just as other idiocies happen in other
lang that lispers see but other langs don't see)
it's interesting to me that all other high level langs: Mathematica,
perl, python, php, javascript, all don't have linked list as lisp's
list. It's also curious that somehow lispers never realises this. I've
been having problems with lisp's cons ever since i'm learning Scheme
Lisp in 1998 (but mostly the reason is language design at syntax and
lack of abstraction level in calling “cons, car, cdr” stuff, without
indexing mechanism). Realizing the algorithmic property and parallel-
execution issues of linked list is only recent years.
Xah
You might be interested in Clojure, then. Lists are more abstracted, like
in Scheme, and vectors and also dictionaries/maps and sets are first
class citizens along side lists. And unlike Scheme, Clojure has good
library/host interop support. You can write real-world applications in it
without spontaneously combusting.
Nonsense. Several Scheme systems have excellent FFIs with more
than "good library/host interop support".
-alex
> Functional Programing: stop using recursion, cons. Use map & vectors.
>
> 〈Guy Steele on Parallel Programing〉
> http://xahlee.org/comp/Guy_Steele_parallel_computing.html
This is more or less what Backus said in his Turing Award lecture about
FP.
Torben
Stop inflating his ego! Next he'll quote Nobel prize winners...
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Well said.... That inspired me to note:
LISP without recursion would be like a jet airplane without wings....
Recursion is an important part of the functional programming paradigm
(yes, I do know that LISP is not a purely functional language...)
LISP denotes, List Processing. List Processing without cons ????? Ugh.
regards, andy
> On May 23, 4:29 am, Deeyana <d.awlb...@hotmail.invalid> wrote:
>>
>> You might be interested in Clojure, then. Lists are more abstracted,
>> like in Scheme, and vectors and also dictionaries/maps and sets are
>> first class citizens along side lists. And unlike Scheme, Clojure has
>> good library/host interop support. You can write real-world
>> applications in it without spontaneously combusting.
>
> Nonsense.
Classic unsubstantiated and erroneous claim. Nothing that I write is ever
"nonsense".
> Several Scheme systems have excellent FFIs with more than "good library/
> host interop support".
Classic unsubstantiated and erroneous claim. Scheme does not come OOTB
with any suitable libraries for host interop and though it can make calls
to C libraries, doing so is awkward and involves difficulties with the
impedance mismatch between Scheme's data structures and C's char *, void
*, int, double, array, etc. types. To top it off, C lacks automatic
memory management, which means you'll have to concern yourself with
manually disposing of allocated data structures used in interop. (Or,
worse, things will get garbage collected by the Scheme runtime that the
Scheme code no longer references, but the C library is still using, and
bam! SIGSEGV.)
And then you gain what, the diverse mix of platform-specific, unportable,
sometimes-wonky C libraries?
Versus Clojure immediately granting simple, easy to use access to a large
standard Java library that works more or less the same across a broad
range of host platforms, as well as the rest of the JVM library
ecosystem, which mostly has the same qualities. Clojure being designed
for the JVM, there's much less of an impedance mismatch with Java's
types, and the interop call syntax is easy to master and won't set your
hair on fire.
Classic unsubstantiated and erroneous claim.
On your part, asandroq.
1. unpredictable chained close loop recursion that will hang in some bugs
2. with those nested calls in a single line, the old style step-by-step break down for debugging becomes really inconveniently