Ian Bicking: the old part of his blog

simplicity vs. conciseness

Yes, I was thinking of Common Lisp. Or any of the Lisps that have macros, really. Though really a small core is exactly the thing that leads to TMTOWTDI -- it's based on the idea that it is okay if things are simply possible, regardless of whether they are easy, obvious, readable, or reproduceable; that a small core is a virtue in itself, often ignoring the size of the working set of functionality a programmer must use to actually get anything done. Common Lisp includes all that functionality in duplicate in its core, while Scheme includes none of that functionality. Both end up in the same place -- TMTOWTDI. For example, there are many object systems for Scheme. And there's many ways to bind a variable in Common Lisp. Neither place great value in consistency for practical programs.

And maybe Smalltalk isn't a good counterexample -- as a language it's more like Lisp than Python. But culturally it's more like Python in this regard, with a rich library and set of conventions.

Re: expressivity; in this case, there is a fine edge. If you try to handle every case, you've recreated all of Python in a set of weird rules that can be embedded in a function signature. That's bad. This is something frameworks often get wrong -- they write piles of code to save framework users a couple if statements or a loop, confusing everyone in the process. Certainly __init__, a procedure which can do anything it wants with the object, shouldn't and can't go away. But really, the choice here isn't between expressivity/freedom and TOOWTDI. The status quo has simplicity and transparency on its side, while a change has conciseness and uniformity on its side. This isn't a question of consistency vs. expressivity.

Comment on Re: Reducing boilerplate code in __init__
by Ian Bicking