2 ms·

"Well, all true Scotsmen like haggis." Or, for those who cannot draw the correlation: "Well, all true Lispers like parentheses." Never mind that pure function

"Well, all true Scotsmen like haggis." Or, for those who cannot draw the correlation: "Well, all true Lispers like parentheses." Never mind that pure functional programming is an ideal that even Lisp does not live up to. Think I'm throwing B.S. around? Try doing I/O in Lisp without side-effects. Now that we've established that Lisp is not at the top of the blub-curve, maybe we can get on with: 1. Writing functional languages people actually use. 2. Advancing the state-of-the-art in programming languages from being mired in a single-threaded monolithic server past. With respect to my second point, much progress has been made; but it is still underpinned by single-threaded programming language design. What we need is someone who truly groks multiprocessor, multi-threaded, heterogeneous run-time environments; and from that knowledge can write a language to take advantage of such an environment.

p_nathan 16y ago
I'm not convinced that Common Lisp is designed to be side-effect free (nor am I convinced that side-effects are an ideal to attain^H^H^H avoid, oops). Even Haskell has side-effects - just pushed into Monads.
- gruseom 16y ago
  I'm not convinced that Common Lisp is designed to be side-effect free It certainly isn't! nor am I convinced that side-effects are an ideal to attain I assume you mean avoiding side-effects? I tend to agree. The style I favor is pretty free-wheeling with side-effects in small scopes (within a function or something smaller) and gets progressively more disciplined as the composed pieces get larger and larger. I find programming this way strikes a nice balance between the two styles (imperative and functional). It lets one write most algorithms in a straightforward, efficient way while providing much of the advantages of strictness. To sum up: side-effects within black boxes, side-effect-freeness outside them, and a lot of small, atomic, composable black boxes. This is a natural way to use Common Lisp. (Especially if you avoid CLOS like I do.)
  - p_nathan 16y ago
    Agreed. I tend to make sure that side-effects are limited to some "block" of code (function/class/module/whatever). I just don't see the problem with syntax much anymore - Python syntax bugs me - a language's usability for the practitioner of the language works around the axis of semantics and maintainability far more than syntax. Obviously J, APL, and egregarious abuses of Perl are examples of syntactical issues, but, as was once said, one can write COBOL in any language.... I'd rather go with the powerful semantics and boring syntax of Lisp. I like this image- http://img264.imageshack.us/img264/1397/lispnd7.png http://img264.imageshack.us/img264/1397/lispnd7.png.
sedachv 16y ago
"What we need is someone who truly groks multiprocessor, multi-threaded, heterogeneous run-time environments; and from that knowledge can write a language to take advantage of such an environment." Please Google: Starlisp, Paralations, NESL, Multilisp, Qlisp, Actors (ACT 1, ABCL), Termite, Kali There have been only two (tuplespaces and STM) parallel programming paradigms that have not been pioneered by people who can be considered "Lispers."

p_nathan 16y ago

I'm not convinced that Common Lisp is designed to be side-effect free (nor am I convinced that side-effects are an ideal to attain^H^H^H avoid, oops). Even Haskell has side-effects - just pushed into Monads.

gruseom 16y ago
I'm not convinced that Common Lisp is designed to be side-effect free It certainly isn't! nor am I convinced that side-effects are an ideal to attain I assume you mean avoiding side-effects? I tend to agree. The style I favor is pretty free-wheeling with side-effects in small scopes (within a function or something smaller) and gets progressively more disciplined as the composed pieces get larger and larger. I find programming this way strikes a nice balance between the two styles (imperative and functional). It lets one write most algorithms in a straightforward, efficient way while providing much of the advantages of strictness. To sum up: side-effects within black boxes, side-effect-freeness outside them, and a lot of small, atomic, composable black boxes. This is a natural way to use Common Lisp. (Especially if you avoid CLOS like I do.)
- p_nathan 16y ago
  Agreed. I tend to make sure that side-effects are limited to some "block" of code (function/class/module/whatever). I just don't see the problem with syntax much anymore - Python syntax bugs me - a language's usability for the practitioner of the language works around the axis of semantics and maintainability far more than syntax. Obviously J, APL, and egregarious abuses of Perl are examples of syntactical issues, but, as was once said, one can write COBOL in any language.... I'd rather go with the powerful semantics and boring syntax of Lisp. I like this image- http://img264.imageshack.us/img264/1397/lispnd7.png http://img264.imageshack.us/img264/1397/lispnd7.png.

sedachv 16y ago

"What we need is someone who truly groks multiprocessor, multi-threaded, heterogeneous run-time environments; and from that knowledge can write a language to take advantage of such an environment." Please Google: Starlisp, Paralations, NESL, Multilisp, Qlisp, Actors (ACT 1, ABCL), Termite, Kali There have been only two (tuplespaces and STM) parallel programming paradigms that have not been pioneered by people who can be considered "Lispers."