4 ms·

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 Hask

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.

4 ms·

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 Hask

by p_nathan 16y ago

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.