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
<mailto: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