4 ms·

>The last of the unimportant reasons is that we had never written a serious project in common lisp and wanted to get better at it. How was your experience with

by emiljbs 13y ago

>The last of the unimportant reasons is that we had never written a serious project in common lisp and wanted to get better at it. How was your experience with coding in CL?

betterunix 13y ago
I am not the author, but I write most of my grad-student research-project-quality code in CL. Here are some things I have experienced so far: 1. Pure dynamic typing is a headache. I use type hints quite frequently, tend to use defstruct rather than cons, etc. SBCL has a pretty good type inference system and gives very useful compile-time feedback about types. 2. Macros can help improve organization and code re-use when used properly. Macros can also turn code into an unreadable mess when used improperly. The only way to learn what is "proper" is experience / practice; books like On Lisp and Let over Lambda help but you really do need to get your hands dirty. 3. Debugging across an FFI is really painful. The debugging tools for Lisp are fantastic, the debugging tools for C are fantastic, but those tools compose poorly. 4. I wish the standard allowed map, reduce, and similar constructs to be defined for arbitrary sequence types. There is more to life than lists and arrays. 5. I wish the standard came with more useful data structures. Associative lists in CL are great if you never have more than a tiny number of items in them; an associative tree type would be a great addition. It would also be nice to have a standard priority queue type, a standard random-access list type, etc. 6. Performance is easy to underestimate. SBCL does a bang-up job of optimizing code, with a few exceptions. The optimizer in SBCL could use some work, of course, but it is nowhere near as bad as people seem to expect for a high-level language. Overall, I think what CL is desperately in need of is an updated standard. The world has changed a lot since CLtL2; we need a CLtL3. There are a lot of non-standard libraries that are widely used and that should just be standardized -- MOP, generic sequences, an FFI, etc.
- fabriceleal 13y ago
  > The debugging tools for Lisp are fantastic. What is your setup for debugging CL?
n_c 13y ago
I found CL really nice. One nice feature about SBCL is it can be incredibly fast. Sure, not as fast as raw C, but it approaches it. (This is useful when you're using CL as your IR.) The macros were the big win for me with this. I have only a few macros, but without them, the code would be significantly uglier. The entire builtin-generator is a big giant macro, and it was very nice to define my own little DSL to build commands. (fun story: I originally started developing this as a Python interpreter, and abandoned it because (a) it was far too slow, and (b) it was difficult to build a clean, abstract, method of writing builtins) Other than the macros, the other big win was how easy it is to generate lisp code. There's no string munging, just (cons 'add cmds) and you're done. There are some things I don't like about it. I think Scheme has it right with functions and variables sharing one namespace. I find the common lisp (defun something (a) (map #'square (funcall a))) much uglier than the scheme equivalent of (define (something fn) (map square (fn))) but that's purely cosmetic.

by emiljbs 13y ago

>The last of the unimportant reasons is that we had never written a serious project in common lisp and wanted to get better at it. How was your experience with coding in CL?

betterunix 13y ago

I am not the author, but I write most of my grad-student research-project-quality code in CL. Here are some things I have experienced so far: 1. Pure dynamic typing is a headache. I use type hints quite frequently, tend to use defstruct rather than cons, etc. SBCL has a pretty good type inference system and gives very useful compile-time feedback about types. 2. Macros can help improve organization and code re-use when used properly. Macros can also turn code into an unreadable mess when used improperly. The only way to learn what is "proper" is experience / practice; books like On Lisp and Let over Lambda help but you really do need to get your hands dirty. 3. Debugging across an FFI is really painful. The debugging tools for Lisp are fantastic, the debugging tools for C are fantastic, but those tools compose poorly. 4. I wish the standard allowed map, reduce, and similar constructs to be defined for arbitrary sequence types. There is more to life than lists and arrays. 5. I wish the standard came with more useful data structures. Associative lists in CL are great if you never have more than a tiny number of items in them; an associative tree type would be a great addition. It would also be nice to have a standard priority queue type, a standard random-access list type, etc. 6. Performance is easy to underestimate. SBCL does a bang-up job of optimizing code, with a few exceptions. The optimizer in SBCL could use some work, of course, but it is nowhere near as bad as people seem to expect for a high-level language. Overall, I think what CL is desperately in need of is an updated standard. The world has changed a lot since CLtL2; we need a CLtL3. There are a lot of non-standard libraries that are widely used and that should just be standardized -- MOP, generic sequences, an FFI, etc.

fabriceleal 13y ago
> The debugging tools for Lisp are fantastic. What is your setup for debugging CL?

n_c 13y ago

I found CL really nice. One nice feature about SBCL is it can be incredibly fast. Sure, not as fast as raw C, but it approaches it. (This is useful when you're using CL as your IR.) The macros were the big win for me with this. I have only a few macros, but without them, the code would be significantly uglier. The entire builtin-generator is a big giant macro, and it was very nice to define my own little DSL to build commands. (fun story: I originally started developing this as a Python interpreter, and abandoned it because (a) it was far too slow, and (b) it was difficult to build a clean, abstract, method of writing builtins) Other than the macros, the other big win was how easy it is to generate lisp code. There's no string munging, just (cons 'add cmds) and you're done. There are some things I don't like about it. I think Scheme has it right with functions and variables sharing one namespace. I find the common lisp (defun something (a) (map #'square (funcall a))) much uglier than the scheme equivalent of (define (something fn) (map square (fn))) but that's purely cosmetic.