If you don't want loop, you can always use iterate. :-)
75 karma · joined January 25, 2013
If you don't want loop, you can always use iterate. :-)
It did not ask for donations. It was purely informational.
Looks useful if you're a Python developer.
"Automatic identification of confusable drug names" (2006, http://goo.gl/W5DK0f PDF)
and
"Identification of Confusable Drug Names: A New Approach and Evaluation Methodology" (2004, http://goo.gl/RziUgf PDF)
Both by Grzegorz Kondrak and Bonnie Dorr.
I've used the BI-SIM in a medical-informatics system and it does quite well. I'm also a big fan of EDITEX, which for some uses is better.
Neither does Emacs Lisp nor ABCL. Yet they are Lisps by your definition.
> different approach about side effects (-> avoid)
Though not precluded. You can write Clojure with side-effects, but to do so you need to be explicit about it.
> different idea of OOP (-> avoid)
Which says nothing about the language or its Lisp-nature. Clojure has generic dispatch with multimethods, supporting runtime polymorphism. As you say later, "OOP" is meaningless since it's definition is vague, so using this as a reason for Clojure to not be a Lisp is odd.
> Just think of it: zero lines of code is shared.
Are saying that a lisp is only a 'Lisp' if you can freely share code between them? Without modification? If the names used for functions aren't the same, then that disqualifies it from being a Lisp?
Your position seems to be that unless the lisp is a direct descendant of Lisp 1.5 then it cannot be called a Lisp. In addition to Clojure, this disqualifies Scheme (and its dialects.)
Different Lisps (by your definition) take different approaches to things like namespace separation (Lisp-1 vs. Lisp-2) and scope (dynamic vs. lexical). These differences can be subtle and lead to hard to find bugs when sharing code.
> My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications.
Yet you have put a stake in the ground and defined the broad idea of 'Lisp' as an entity that shares its roots with the ideas in MacLisp.
The lack of TCO in JVM hosted languages is besides the point.
It is also possible for the Clojure compiler to do TCO in certain cases: Rich Hickey made the conscious decision to not do it.
I use Clojure to implement a portion of a semantic search engine: it is packaged as a REST servlet that responds to requests from a medical POC application. Because of the Java interop I utilize our internal libraries and from the ops perspective they are just deploying a WAR file that plays nicely in their reporting infrastructure.
I've been using Clojure since its first release and am comfortable with it and its ecosystem. ABCL is a contender, but I have yet to do a performance comparison, both for native and interop tests. And in reality the only part of Common Lisp I really miss is the condition system. Clojure as an implementation of CL's format and I was never a big user of loop, so...
Expecting Google to act like a sane company for one developer in a garage is naive.
I sometimes wonder if this type of programming is a side-effect of the short attention spans teens and twenty-somethings have now... but that's a subject for another time.
Also, to add what others have said, he is one of the best speakers I've ever been lucky enough to see in person: SPJ, Philip Wadler, Guy Steele... good company.