undefined | Better HN

0 pointsheretohelp14y ago0 comments

Arbitrary interfacing in Ruby and Python, method_missing, TypeError, ValueError, operations, etc.

Most of the time, you're just map, car, cdr, mapcar, reduce, fold, etc in Lisp. Functional iteration/processing semantics are the default in Lisp. Common Lisp makes it VERY obvious when you're not using a standard data structure so it's hard to mess up.

Ruby and Python proliferate arbitrary Object-Oriented interfaces, combined with dynamic typing, it's easy to get the wrong instance of something-or-other and fuck it up.

Contrary to popular belief, Common Lisp code tends to be more consistent in terms of how you interact with your data, even if they go on flights of fancy re: Reader Macros.

0 comments

2 comments · 1 top-level

Drbble14y ago· 1 in thread

That's dodging the point. If you forget whether your list A is an association list ((key value)) or a reverse association list ((value key)), your cars and cdrs won't crash the program, but your program will still fail to produce a correct result, and the source of the bug is a type error.

heretohelpOP14y ago

The universe of common errors you can have in Common Lisp due to dynamic typing is constrained compared to Python and Ruby.

I say this as someone who works with Python daily as my working language and grew up with a copy of this:

http://www.cs.cmu.edu/afs/cs/Web/Groups/AI/lang/lisp/impl/cl...

I'm fully aware of the errors that can arise from dynamic typing in Common Lisp. It's just not my experience that it's that big of a deal.

The reverse association list is contrived compared to the issues one can have in Python or Ruby. Most people just use association lists the normal way and use rassoc as needed.

Lets not kid ourselves and pretend that a reversed assoc list is used in place of a normal rassoc or find :key #'cdr.

j / k navigate · click thread line to collapse