(blog ‘lucindo)

Two options for lispers:

• Purely functional Lisps (subset of CL or something like Clojure, LFE, etc)
• Cells!!!

I’m completely convinced that mutable objects and the whole approach that is sort of implied by the design of Java, C#, Python, all the languages that followed along this path, is very much the wrong way to do most things… it is ok to do somethings, but it’s the wrong way to do most things.
Mutable objects are the new spaghetti code, and by that I mean that you eventually, with mutable objects, create an intractable mess, and encapsulation does not get rid off that, encapsulation just means: well, I’m in charge of this mess. But the real mess comes from this network you create of objects that can change, and your inability to look at the state of a system and understand how you got there, how to get there to test it next time… so it’s hard to understand the program… it’s very hard to test it. I think that’s interesting in telling all the emphasis on test driven design. I think people are driven to this because they know their systems are completely intractable…

Rich Hickey - Screencast: Clojure Concurrency (”transcrição” do minuto 21 ao 23)

marvin:~ lucindo$ python
Python 2.5.2 (r252:60911, Apr 26 2008, 14:32:15)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>