On 4 November 2011 14:35, Jimmie Houchin <[email protected]> wrote: > Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 > > Hi Folks, > > I'm answering you off-list because I'm not subscribed to the Pharo list. > Feel free to forward this there, if you wish. > > I think it is great to put focus on simplicity (an objective value) over > easyness (a subjective value). Rich also makes a good critic to usual > practices, including the dichotomy between understanding and TDD (test > driven development). > > However, the value of simplicity is not something new. The difference > between essential complexity and accidental complexity is the heart of > "No Silver Bullet — Essence and Accidents of Software Engineering" (by > Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, > http://drdobbs.com/184407534). It is also central to Smalltalk, see > "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, > http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html). > These three articles might be the most important writings on software > engineering ever. > > The problem with this discussion is that everybody will claim simplicity > is a crucial objective of their project. However, Pharo and Squeak don't > realize (or don't want to realize) that simplicity appears only by > removing complexity, never by adding more of it. >
can't say about Squeak, but i observing Pharo activities, i don't see how Juan's claim fit: - bug fixing a bugs found in system could lead to changes which in order to fix them could increase complexity, or otherwise decrease it. So, this activity cannot objectively considered as evil which automatically and always plays against simplicity. - refactoring/rewriting parts of system The intent to rewrite parts were always: reduce complexity. And if it including adding new features, it was always to do it carefully and without horrible complexity. - removing obsolete/unused code no need to comment this one, since obviously it cannot increase complexity of system. > Cuis is a Squeak fork with the #1 objective of being simple and > understandable. It is the result of more than 10 years suffering the > accidental complexity in Squeak, comparing with other Smalltalks, > together with a lot of reflection and work, by me and others. It is, I > believe, the only Smalltalk in active development that pursues this > objective of the original Smalltalk-80 project. You can get it from > http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take > statistics (lines of code, etc). Compare. You might have a nice surprise. > a little of advertisement never hurts, of course :) > Jimmie, you asked "How can we move Pharo to be a better answer to Simple > vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up > feature list as a priority, and focus on simplicity. Make a list of the > features in Pharo that are really important, and not part of Cuis, and > turn them into optional packages. Make that list as short as possible! > Worry more about code quality and less about discarding potentially > useful stuff, that is not good enough. > This is a bit controversial. If you arm such ideology for developing a software, then you end up with 'hello world' application, which is of course very simple and easy to use, but utterly useless. I think the right way to do things is: - improve things which people using - add things which people want to have - remove things which nobody using. f you sacrifice everything for the sake of simplicity, then you will end up with hello world application. -- Best regards, Igor Stasenko.
