"Smalltalk is not a language, it is an object computer" Wow, that nails it quite nicely.
And it feels a lot like that, especially with tools like GT-Playground. Now, the most complicated bit is for me to get the user to discuss with the object computer through the UI in a satisfying way. Getting the right UI for delivering the value is taking a very long time. Phil On Thu, Sep 11, 2014 at 5:42 PM, Trygve Reenskaug <tryg...@ifi.uio.no> wrote: > Hi kilon alios, > I want to go deeper than any programming language. "What is a computer?" > Almost all programming languages build on the von Neumann architecture > with data processing as " The execution of a systematic sequence of > operations > performed upon data." I believe this is unnecessarily low-level and > complex for general use. Much closer to the human mind is to build on an > object computer where the unit of storage is the object rather than the > bit or byte. Data processing becomes "the systematic exchange of messages > between objects." Lots of stuff that's of no interest to the general user > is then hidden under the hood. > > The users of immediate importance may be power users. Computational > chemists are my favorite examples. What shall be their mental model, what > do we teach them and how do we form our programs such that they can > understand and modify what goes on on the computer? > > I foresee that (virtual) object computers will supersede our current > computers for general programming. They will be supported by experts doing > systems programming on various levels from virtual machines down to > microcode and hardware. When this is achieved; Java, Ruby, C++, C, Haxe, > etc. will no longer be used for general application programming. (Smalltalk > is, of course, not a language but an object computer.) > > The "pythonic" culture should permeate more than Phyton, it should be > behind all we do. Thanks for sharing it. > C. A. R. Hoare says it succintly: > " There are two ways of constructing a software design: > - One way is to make it so simple that there are obviously no > deficiencies > - The other way is to make it so complicated that there are no > obvious deficiencies." > and > "The first method is far more difficult…." > also: > "The price of reliability is the pursuit of the utmost simplicity" > > I think we are in agreement about the need for readable code. But I > disagree when you say "We need very complex solutions to very complex > problems". I believe we can attain simple solutions to very complex > problems. If the complexity is in the user's mental model then a direct > mapping of this model into code will be simple as seen from the user's > point of view. If the program is more complex than the user's mental model, > the program should be simplified. > > It would be helpful if you would suggest an example where Phyton leads to > more readable code than say Pharo. > > > On 07.09.2014 12:29, kilon alios wrote: > > Python has no competition. Sure there are languages that are more popular > than Python for their own reasons. There have been simpler languages before > python, there have been more popular languages, more cross platform > languages etc etc but Python fills a gap that no language was able to fill > before it , easy to use very powerful well documented libraries. Python is > a language that you can teach to a kid now and make a living later on using > until his or her old age. Its not because the language is simple , its > simple enough but not the simplest. Its because the culture surrounding the > creation of libraries . That culture has a name its called "pythonic" > > 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! > > this kind of ideology is why Python has been so successful. It has also > inspired jokes like this > > http://xkcd.com/353/ > > it may look funny and it says thinks about overestimating the simplicity of > those libraries but python does feel at times as simple as this, as simple as > importing antigravity. > > So if a kid comes to me and ask me "what language should I learn" , I will > recommend a language that is fairly easy to learn , has powerful library , > easy to use libraries , well documented and its a language that will able to > keep using even if his or her needs change, forever. For that only Python is > the language that has been able to succeed and I think its adoption will > continue to progress in educational institutions pretty much everywhere on > the planet. > > Referring to the rest of your post I dont agree that we need to separate Data > from Code, I think quite opossite that a kid needs to be taught why Code and > Data are one and what that means in practice. I also don't agree that OO or > functional programming or any other programming paradigm I am aware of are > the future. They are simple solutions for simpler times. The coding community > at large the way I see it is in denial hoping to apply simple recipes to > solve complex problems. We need very complex solutions to very complex > problems , we need tools that can interact with the user in many diffirent > ways. > > Pharo is definitely showing the future, the close integration of IDE , > language and environment. But thats is just the start, the next step is > powerful tools that can deeply interact with code and solve automagically > logical coding problems. Obviously all that has to be wrapped to an easy > enough interface for the user even if the solutions is very complex. > > Fortunately this where the rest of the coding world is heading. For example > iPython is one of the most popular python projects right and it offers a > highly interactive environment for python coders that shares a lot of > similarities with Pharo though the implementation is very different. > > So the future is no longer languages , is no longer IDEs , its not even > environments but tools that are produced in these environments that can > vastly automate coding and hide the increasing complexity of coding > solutions. Maybe one day a child will be able to describe to a computer what > kind of software he or she needs and the computer automatically generate the > code for it. That day is not close enough but is where we are heading. > > > > On Sun, Sep 7, 2014 at 12:34 PM, Trygve Reenskaug <tryg...@ifi.uio.no> > wrote: > >> I have for some time been pondering two problems. One is to identify >> the fourth R in *R*eading, w*R*iting, a*R*ithmetic, and p*R*ogramming. >> There are many contenders for the kids' first step. I believe the English >> government has chosen Phyton as a first language. Scratch has a certain >> popularity, there are many others. My concern is "what comes next"? I want >> the kid to gradually build a mental model of what computing is all about. >> Learn a little, do a little, lean more, do more, etc. up do old age. This >> goes much deeper than any programming language. It's a bit as learning to >> read. Personally, I "broke the reading code"at an early age. Since then, I >> have been learning more and more. What I read today would have been >> incomprehensible to me 75 years ago. But my basic mental model of what >> reading is all about has remained unchanged. I have never had to unlearn >> anything. >> >> I suggest that true object orientation (not class orientation) can form >> the foundation for the human mental model of computing. Internalize it and >> live with it forever. >> ------------------------------------- >> The other problem is to find a better example for DCI presentations. It >> should >> >> 1. Be executable and have a cool demo effect. >> 2. Its domain model should be obvious from the demo. >> 3. It should have very few and very simple Data classes. >> 4. It should have a Context that is clearly and obviously >> separate from the Data. >> 5. It should scale to any number of Contexts (use cases) without >> changing the Data classes. >> >> ----------------------------------------- >> *Last night I got an idea for an example: A waltzing couple. (See the >> attached for a picture and Wikipedia for a movie of the use case).* >> >> The program needs one simple class for a moveable shape and a DCI Context >> for each dance (waltz, foxtrot, tango, ... for two role, polonaise for >> more.) The example will clearly demonstrate the wisdom in separating what >> the system IS from what the system DOES since the simple Shape class would >> be overloaded with instance methods for all dances. >> >> What do you think? >> >> --Trygve >> > >
