[Pharo-project] Simple vs. Easy
Hello, I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. www.infoq.com/presentations/Simple-Made-Easy It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy. Where are we in Pharo simple? Where are we easy? What can we do to move things from easy to simple? I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience. Watch the video. I would love to hear some opinions from the community. How can we move Pharo to be a better answer to Simple vs. Easy? Thanks. Jimmie
We are easy in debugging. Now I would like to be easy in C interaction C embedding UI building File manipulation Stef
Hello,
I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. www.infoq.com/presentations/Simple-Made-Easy
It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy.
Where are we in Pharo simple? Where are we easy?
What can we do to move things from easy to simple?
I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience.
Watch the video. I would love to hear some opinions from the community.
How can we move Pharo to be a better answer to Simple vs. Easy?
Thanks.
Jimmie
Hello Stef, In the video he distinguishes and defines Simple and Easy. I will not define them here. I will let the video speak for itself. Easy is what a lot of languages are. Simple is the goal. Simple Made Easy is the ultimate. :) Simple ~= Easy Easy ~= Simple Simple is sometimes Easy Easy is often not Simple Easy and Simple are often used interchangeably when they shouldn't be. It can be confusing. The video is an hour. I would encourage anyone to watch it. The video is not about Clojure a particular language, but is more philosophical. And by the way. I too would love to see Pharo Simple and Easy on your list. :) Or at least as Simple as possible. Jimmie On 11/3/2011 3:39 PM, Stéphane Ducasse wrote:
We are easy in debugging.
Now I would like to be easy in C interaction C embedding UI building File manipulation
Stef
Hello,
I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. www.infoq.com/presentations/Simple-Made-Easy
It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy.
Where are we in Pharo simple? Where are we easy?
What can we do to move things from easy to simple?
I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience.
Watch the video. I would love to hear some opinions from the community.
How can we move Pharo to be a better answer to Simple vs. Easy?
Thanks.
Jimmie
Great talk. Nicolas 2011/11/3 Jimmie Houchin <jlhouchin@gmail.com>:
Hello Stef,
In the video he distinguishes and defines Simple and Easy. I will not define them here. I will let the video speak for itself.
Easy is what a lot of languages are. Simple is the goal. Â Simple Made Easy is the ultimate. :)
Simple ~= Easy Easy ~= Simple Simple is sometimes Easy Easy is often not Simple
Easy and Simple are often used interchangeably when they shouldn't be. It can be confusing. The video is an hour. I would encourage anyone to watch it. The video is not about Clojure a particular language, but is more philosophical.
And by the way. I too would love to see Pharo Simple and Easy on your list. :) Or at least as Simple as possible.
Jimmie
On 11/3/2011 3:39 PM, Stéphane Ducasse wrote:
We are easy in debugging.
Now I would like to be easy in     C interaction     C embedding     UI building     File manipulation
Stef
Hello,
I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. www.infoq.com/presentations/Simple-Made-Easy
It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy.
Where are we in Pharo simple? Where are we easy?
What can we do to move things from easy to simple?
I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience.
Watch the video. I would love to hear some opinions from the community.
How can we move Pharo to be a better answer to Simple vs. Easy?
Thanks.
Jimmie
It is a good talk - thanks for mentioning it here! At several points, I was reminded of Beck's "Lots of little pieces," which is great advice. I have mixed feelings on (what I think he meant??) using undifferentiated collections for holding data. I use dictionaries a lot, and some things really are naturally arrays - no argument there. However, there are times when "points" in some weird cross product space could be represented as arrays, but there are huge benefits from having a class that "understands" the problem-specifics (and proves it via #printOn:). Put another way, one can explore and array of arrays, or an array of objects with named aspects and helpful string representations. The resulting classes then provide natural places to add behavior. Stef, I like your list. I might tweak it just a bit: let's be easy in C integration and simple in UI building. Maybe we can layer an easy tool on top of a simple framework for the latter?? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Thursday, November 03, 2011 4:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy We are easy in debugging. Now I would like to be easy in C interaction C embedding UI building File manipulation Stef
Hello,
I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. www.infoq.com/presentations/Simple-Made-Easy
It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy.
Where are we in Pharo simple? Where are we easy?
What can we do to move things from easy to simple?
I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience.
Watch the video. I would love to hear some opinions from the community.
How can we move Pharo to be a better answer to Simple vs. Easy?
Thanks.
Jimmie
One other thought: "guard-rail programming." I share his skepticism about tests as a panacea, BUT, automated tests are useful, and I have been able to use them to make changes that would have been much harder to make without good tests. One thing that he does not acknowledge is the source of some of the best test cases/methods one can write: newly discovered defects. Tests do not prove that software in correct, but they can help us avoid repeating mistakes. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Thursday, November 03, 2011 6:36 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy It is a good talk - thanks for mentioning it here! At several points, I was reminded of Beck's "Lots of little pieces," which is great advice. I have mixed feelings on (what I think he meant??) using undifferentiated collections for holding data. I use dictionaries a lot, and some things really are naturally arrays - no argument there. However, there are times when "points" in some weird cross product space could be represented as arrays, but there are huge benefits from having a class that "understands" the problem-specifics (and proves it via #printOn:). Put another way, one can explore and array of arrays, or an array of objects with named aspects and helpful string representations. The resulting classes then provide natural places to add behavior. Stef, I like your list. I might tweak it just a bit: let's be easy in C integration and simple in UI building. Maybe we can layer an easy tool on top of a simple framework for the latter?? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Thursday, November 03, 2011 4:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy We are easy in debugging. Now I would like to be easy in C interaction C embedding UI building File manipulation Stef
Hello,
I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. www.infoq.com/presentations/Simple-Made-Easy
It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy.
Where are we in Pharo simple? Where are we easy?
What can we do to move things from easy to simple?
I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience.
Watch the video. I would love to hear some opinions from the community.
How can we move Pharo to be a better answer to Simple vs. Easy?
Thanks.
Jimmie
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. 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. 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. Cheers, Juan Vuletich
On 4 November 2011 14:35, Jimmie Houchin <jlhouchin@gmail.com> 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.
Just as a follow-up. A simple example: Cuis doesn't supports unicode. It simply doesn't exists in Cuis. Does it makes it simpler? Of course. Does it makes life simpler for development of modern applications? Absolutely not. Because as i repeated many times, a unicode and i18n support is a must have in any modern system. And unicode is not _potentially_ useful, which you can just simply discard because it is not flawlessly implemented. It is used a lot by people, who living outside a latin world. -- Best regards, Igor Stasenko.
:) come on igor all these strange alphabets are not useful :) Ok I will stop and continue to work on our future. Stef On Nov 4, 2011, at 4:24 PM, Igor Stasenko wrote:
Just as a follow-up. A simple example: Cuis doesn't supports unicode. It simply doesn't exists in Cuis. Does it makes it simpler? Of course. Does it makes life simpler for development of modern applications? Absolutely not. Because as i repeated many times, a unicode and i18n support is a must have in any modern system. And unicode is not _potentially_ useful, which you can just simply discard because it is not flawlessly implemented. It is used a lot by people, who living outside a latin world.
-- Best regards, Igor Stasenko.
Sure, Cuis is really cool as well as very impressive. However, it is limited: I want: Seaside Moose HTTP Client+Server Monticello Metacello XML JSON Glorp Database Access FFI UTF8 and other encodings ⦠I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks. Pharo takes on all these and at the same time tries to simplify things, the hard way. Sven On 04 Nov 2011, at 14:35, Jimmie Houchin 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.
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.
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.
Cheers, Juan Vuletich
Sven, Sig, Well said. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Friday, November 04, 2011 11:22 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy Sure, Cuis is really cool as well as very impressive. However, it is limited: I want: Seaside Moose HTTP Client+Server Monticello Metacello XML JSON Glorp Database Access FFI UTF8 and other encodings ⦠I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks. Pharo takes on all these and at the same time tries to simplify things, the hard way. Sven On 04 Nov 2011, at 14:35, Jimmie Houchin 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.
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.
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.
Cheers, Juan Vuletich
I agree! I like the focus of Pharo and its goal of enabling people to get things done. Stef, I think you are doing a great job. Especially with the limited resources of the community. And I think you are doing a fantastic job of increasing the resources of the community. You have my profound thanks and appreciation. Jimmie On 11/4/2011 4:32 PM, Schwab,Wilhelm K wrote:
Sven, Sig,
Well said.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Friday, November 04, 2011 11:22 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy
Sure, Cuis is really cool as well as very impressive.
However, it is limited:
I want:
Seaside Moose HTTP Client+Server Monticello Metacello XML JSON Glorp Database Access FFI UTF8 and other encodings â¦
I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks.
Pharo takes on all these and at the same time tries to simplify things, the hard way.
Sven
On 04 Nov 2011, at 14:35, Jimmie Houchin 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.
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.
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.
Cheers, Juan Vuletich
More stuff well said. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Jimmie Houchin [jlhouchin@gmail.com] Sent: Friday, November 04, 2011 9:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy I agree! I like the focus of Pharo and its goal of enabling people to get things done. Stef, I think you are doing a great job. Especially with the limited resources of the community. And I think you are doing a fantastic job of increasing the resources of the community. You have my profound thanks and appreciation. Jimmie On 11/4/2011 4:32 PM, Schwab,Wilhelm K wrote:
Sven, Sig,
Well said.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Friday, November 04, 2011 11:22 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy
Sure, Cuis is really cool as well as very impressive.
However, it is limited:
I want:
Seaside Moose HTTP Client+Server Monticello Metacello XML JSON Glorp Database Access FFI UTF8 and other encodings â¦
I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks.
Pharo takes on all these and at the same time tries to simplify things, the hard way.
Sven
On 04 Nov 2011, at 14:35, Jimmie Houchin 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.
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.
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.
Cheers, Juan Vuletich
I wrote an answer and throw it away. I do not want to argue and keep my positive energy :) We will see in 5 years from now what will be the situation. Because we are getting more and more agile contrary to what people believe. We are making deep changes and working on the infrastructure of the system but with the challenge that we have users. And we want happy and powerful users. Infrastructure work that often invisible at first but after a while they really pay off. I want a system that people can use. The goal of Pharo is a system to build other systems. Now for 1.4 I would like to remove the rest of MethodReference, PseudoClass and Friends. Stef
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.
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.
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.
Cheers, Juan Vuletich
Stef, Please count me as a believer :) Pharo is evolving into a very nice system. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, November 04, 2011 5:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy I wrote an answer and throw it away. I do not want to argue and keep my positive energy :) We will see in 5 years from now what will be the situation. Because we are getting more and more agile contrary to what people believe. We are making deep changes and working on the infrastructure of the system but with the challenge that we have users. And we want happy and powerful users. Infrastructure work that often invisible at first but after a while they really pay off. I want a system that people can use. The goal of Pharo is a system to build other systems. Now for 1.4 I would like to remove the rest of MethodReference, PseudoClass and Friends. Stef
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.
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.
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.
Cheers, Juan Vuletich
participants (6)
-
Igor Stasenko -
Jimmie Houchin -
Nicolas Cellier -
Schwab,Wilhelm K -
Stéphane Ducasse -
Sven Van Caekenberghe