Personal Programming

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Personal Programming

Trygve Reenskaug
Dear all,
The final draft of my magnum opus about Personal Programming is now ready for review:
http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf

The article's main theme is Personal Programming for everybody with Loke, a personal object computer. Its first purpose is to empower laypeople to take control over their corner of the Net with its IoT. I have created a proof-of-concept implementation as a non-intrusive extension of Squeak version 3.10.2, and have used it to demonstrate how a novice uses the Loke IDE to create a small and intuitive program.

The article describes the concepts behind Loke .The current Squeak implementation should be ported to Pharo and can grow into the preferred Pharo-based IDE for laypeople taking control over their information environment.

I will appreciate your possible comments before Aug. 31.
Enjoy
--Trygve

The article's 43 pages has several high points, I have included one of them here:
----------- begin extract ------------------

C.7.We need a paradigm shift

The history of Western astronomy shows a series of paradigm shifts from the geocentric paradigm with its stationary Earth as the center of the Universe with its epicycles and other bizarre explanations of what appeared to be essential complexities. Astronomy evolved via the heliocentric to the current distributed paradigm with its chunks of mass connected by gravity. What appeared as essential complexity in one paradigm was easily resolved in the next.

It is tempting to look for similar paradigm shifts in computing. Mainstream programming has based much of its theory and practice on the CPU-centric paradigm exemplified by the von Neumann machine. A memory-centric paradigm came in 1960 with the Autokon CAC/ CAM system and its central database (Reenskaug, 1973). The solution was obvious, and there must have been many similar initiatives without me being aware of them.

It is time to realize that the first two paradigms do not meet our current challenges: We are plagued with immensely large, complex, and insecure systems that long ago left the realm of human understanding. A recent example: Customers found that their bank charged them twice for the same transaction. Several weeks after the problem was discovered, the bank publicly admitted that they still didn't understand how the problem could arise: The complexity of their system was clearly beyond human comprehension. The bank has a staff of very competent experts, but they need a better foundation for modeling and implementing their sophisticated requirements.

Computers can transform, store, and communicate data, (Figure below). The essence of the CPU-centric paradigm is that computers are primarily used to transform data; they compute. The essence of the memory-centric paradigm is that computers are used primarily to store data; they organize applications around a shared database. The essence of the communication-centric paradigm is that computers are primarily used to exchange messages with other computers to make them collaborate to achieve a common goal.

The three paradigms of computing

It is time to heed Tony Hoare's plea for simplicity and achieve a better way of separating concerns. Mainstream programming should shift to the communication-centric paradigm exemplified by the object computer that is the foundation for this article.

The communication-centric paradigm has been on the horizon for many years. I first met it in Prokon's idea of distributed computers (Reenskaug, 1977), but there must have been many other initiatives. A newer example is Service-Oriented Architectures (SOA) that, in essence, is communication-centric. It didn't meet with immediate success, possibly because people tried to apply it within the CPU-centric paradigm where it doesn't belong. There are many other examples such as distributed computing. And of course, DCI and the IoT itself are, by definition, communication-centric.

----------- end extract ------------------



Reply | Threaded
Open this post in threaded view
|

Re: Personal Programming

Marcus Denker-4
Looks very interesting! I will read it (it arrives just in time to be part of the holiday reading pile…)

Marcus

On 25 Jul 2019, at 11:29, Trygve <[hidden email]> wrote:

Dear all,
The final draft of my magnum opus about Personal Programming is now ready for review:
http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf

The article's main theme is Personal Programming for everybody with Loke, a personal object computer. Its first purpose is to empower laypeople to take control over their corner of the Net with its IoT. I have created a proof-of-concept implementation as a non-intrusive extension of Squeak version 3.10.2, and have used it to demonstrate how a novice uses the Loke IDE to create a small and intuitive program.

The article describes the concepts behind Loke .The current Squeak implementation should be ported to Pharo and can grow into the preferred Pharo-based IDE for laypeople taking control over their information environment.

I will appreciate your possible comments before Aug. 31.
Enjoy
--Trygve

The article's 43 pages has several high points, I have included one of them here:
----------- begin extract ------------------

C.7.We need a paradigm shift

The history of Western astronomy shows a series of paradigm shifts from the geocentric paradigm with its stationary Earth as the center of the Universe with its epicycles and other bizarre explanations of what appeared to be essential complexities. Astronomy evolved via the heliocentric to the current distributed paradigm with its chunks of mass connected by gravity. What appeared as essential complexity in one paradigm was easily resolved in the next.

It is tempting to look for similar paradigm shifts in computing. Mainstream programming has based much of its theory and practice on the CPU-centric paradigm exemplified by the von Neumann machine. A memory-centric paradigm came in 1960 with the Autokon CAC/ CAM system and its central database (Reenskaug, 1973). The solution was obvious, and there must have been many similar initiatives without me being aware of them.

It is time to realize that the first two paradigms do not meet our current challenges: We are plagued with immensely large, complex, and insecure systems that long ago left the realm of human understanding. A recent example: Customers found that their bank charged them twice for the same transaction. Several weeks after the problem was discovered, the bank publicly admitted that they still didn't understand how the problem could arise: The complexity of their system was clearly beyond human comprehension. The bank has a staff of very competent experts, but they need a better foundation for modeling and implementing their sophisticated requirements.

Computers can transform, store, and communicate data, (Figure below). The essence of the CPU-centric paradigm is that computers are primarily used to transform data; they compute. The essence of the memory-centric paradigm is that computers are used primarily to store data; they organize applications around a shared database. The essence of the communication-centric paradigm is that computers are primarily used to exchange messages with other computers to make them collaborate to achieve a common goal.

The three paradigms of computing
<pbeopicbehdhbfmc.png>
It is time to heed Tony Hoare's plea for simplicity and achieve a better way of separating concerns. Mainstream programming should shift to the communication-centric paradigm exemplified by the object computer that is the foundation for this article.

The communication-centric paradigm has been on the horizon for many years. I first met it in Prokon's idea of distributed computers (Reenskaug, 1977), but there must have been many other initiatives. A newer example is Service-Oriented Architectures (SOA) that, in essence, is communication-centric. It didn't meet with immediate success, possibly because people tried to apply it within the CPU-centric paradigm where it doesn't belong. There are many other examples such as distributed computing. And of course, DCI and the IoT itself are, by definition, communication-centric.

----------- end extract ------------------




Reply | Threaded
Open this post in threaded view
|

Re: Personal Programming

cedreek
Me too !

And on the huge esug discussion points to have ^^

Cheers,

Cedrick 


Le 25 juil. 2019 à 13:09, Marcus Denker <[hidden email]> a écrit :

Looks very interesting! I will read it (it arrives just in time to be part of the holiday reading pile…)

Marcus

On 25 Jul 2019, at 11:29, Trygve <[hidden email]> wrote:

Dear all,
The final draft of my magnum opus about Personal Programming is now ready for review:
http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf

The article's main theme is Personal Programming for everybody with Loke, a personal object computer. Its first purpose is to empower laypeople to take control over their corner of the Net with its IoT. I have created a proof-of-concept implementation as a non-intrusive extension of Squeak version 3.10.2, and have used it to demonstrate how a novice uses the Loke IDE to create a small and intuitive program.

The article describes the concepts behind Loke .The current Squeak implementation should be ported to Pharo and can grow into the preferred Pharo-based IDE for laypeople taking control over their information environment.

I will appreciate your possible comments before Aug. 31.
Enjoy
--Trygve

The article's 43 pages has several high points, I have included one of them here:
----------- begin extract ------------------

C.7.We need a paradigm shift

The history of Western astronomy shows a series of paradigm shifts from the geocentric paradigm with its stationary Earth as the center of the Universe with its epicycles and other bizarre explanations of what appeared to be essential complexities. Astronomy evolved via the heliocentric to the current distributed paradigm with its chunks of mass connected by gravity. What appeared as essential complexity in one paradigm was easily resolved in the next.

It is tempting to look for similar paradigm shifts in computing. Mainstream programming has based much of its theory and practice on the CPU-centric paradigm exemplified by the von Neumann machine. A memory-centric paradigm came in 1960 with the Autokon CAC/ CAM system and its central database (Reenskaug, 1973). The solution was obvious, and there must have been many similar initiatives without me being aware of them.

It is time to realize that the first two paradigms do not meet our current challenges: We are plagued with immensely large, complex, and insecure systems that long ago left the realm of human understanding. A recent example: Customers found that their bank charged them twice for the same transaction. Several weeks after the problem was discovered, the bank publicly admitted that they still didn't understand how the problem could arise: The complexity of their system was clearly beyond human comprehension. The bank has a staff of very competent experts, but they need a better foundation for modeling and implementing their sophisticated requirements.

Computers can transform, store, and communicate data, (Figure below). The essence of the CPU-centric paradigm is that computers are primarily used to transform data; they compute. The essence of the memory-centric paradigm is that computers are used primarily to store data; they organize applications around a shared database. The essence of the communication-centric paradigm is that computers are primarily used to exchange messages with other computers to make them collaborate to achieve a common goal.

The three paradigms of computing
<pbeopicbehdhbfmc.png>
It is time to heed Tony Hoare's plea for simplicity and achieve a better way of separating concerns. Mainstream programming should shift to the communication-centric paradigm exemplified by the object computer that is the foundation for this article.

The communication-centric paradigm has been on the horizon for many years. I first met it in Prokon's idea of distributed computers (Reenskaug, 1977), but there must have been many other initiatives. A newer example is Service-Oriented Architectures (SOA) that, in essence, is communication-centric. It didn't meet with immediate success, possibly because people tried to apply it within the CPU-centric paradigm where it doesn't belong. There are many other examples such as distributed computing. And of course, DCI and the IoT itself are, by definition, communication-centric.

----------- end extract ------------------




Reply | Threaded
Open this post in threaded view
|

Re: Personal Programming

Trygve Reenskaug
I dream of a future with the release of a Loke 1.0 that is firmly embedded in Pharo. A Loke that is quickly becoming the computing environment of choice for millions of homeowners and schoolchildren.
Trygve

On 25.07.2019 18:34, Cédrick Béler wrote:
Me too !

And on the huge esug discussion points to have ^^

Cheers,

Cedrick 


Le 25 juil. 2019 à 13:09, Marcus Denker <[hidden email]> a écrit :

Looks very interesting! I will read it (it arrives just in time to be part of the holiday reading pile…)

Marcus

On 25 Jul 2019, at 11:29, Trygve <[hidden email]> wrote:

Dear all,
The final draft of my magnum opus about Personal Programming is now ready for review:
http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf

The article's main theme is Personal Programming for everybody with Loke, a personal object computer. Its first purpose is to empower laypeople to take control over their corner of the Net with its IoT. I have created a proof-of-concept implementation as a non-intrusive extension of Squeak version 3.10.2, and have used it to demonstrate how a novice uses the Loke IDE to create a small and intuitive program.

The article describes the concepts behind Loke .The current Squeak implementation should be ported to Pharo and can grow into the preferred Pharo-based IDE for laypeople taking control over their information environment.

I will appreciate your possible comments before Aug. 31.
Enjoy
--Trygve

The article's 43 pages has several high points, I have included one of them here:
----------- begin extract ------------------

C.7.We need a paradigm shift

The history of Western astronomy shows a series of paradigm shifts from the geocentric paradigm with its stationary Earth as the center of the Universe with its epicycles and other bizarre explanations of what appeared to be essential complexities. Astronomy evolved via the heliocentric to the current distributed paradigm with its chunks of mass connected by gravity. What appeared as essential complexity in one paradigm was easily resolved in the next.

It is tempting to look for similar paradigm shifts in computing. Mainstream programming has based much of its theory and practice on the CPU-centric paradigm exemplified by the von Neumann machine. A memory-centric paradigm came in 1960 with the Autokon CAC/ CAM system and its central database (Reenskaug, 1973). The solution was obvious, and there must have been many similar initiatives without me being aware of them.

It is time to realize that the first two paradigms do not meet our current challenges: We are plagued with immensely large, complex, and insecure systems that long ago left the realm of human understanding. A recent example: Customers found that their bank charged them twice for the same transaction. Several weeks after the problem was discovered, the bank publicly admitted that they still didn't understand how the problem could arise: The complexity of their system was clearly beyond human comprehension. The bank has a staff of very competent experts, but they need a better foundation for modeling and implementing their sophisticated requirements.

Computers can transform, store, and communicate data, (Figure below). The essence of the CPU-centric paradigm is that computers are primarily used to transform data; they compute. The essence of the memory-centric paradigm is that computers are used primarily to store data; they organize applications around a shared database. The essence of the communication-centric paradigm is that computers are primarily used to exchange messages with other computers to make them collaborate to achieve a common goal.

The three paradigms of computing
<pbeopicbehdhbfmc.png>
It is time to heed Tony Hoare's plea for simplicity and achieve a better way of separating concerns. Mainstream programming should shift to the communication-centric paradigm exemplified by the object computer that is the foundation for this article.

The communication-centric paradigm has been on the horizon for many years. I first met it in Prokon's idea of distributed computers (Reenskaug, 1977), but there must have been many other initiatives. A newer example is Service-Oriented Architectures (SOA) that, in essence, is communication-centric. It didn't meet with immediate success, possibly because people tried to apply it within the CPU-centric paradigm where it doesn't belong. There are many other examples such as distributed computing. And of course, DCI and the IoT itself are, by definition, communication-centric.

----------- end extract ------------------





--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27

Reply | Threaded
Open this post in threaded view
|

Re: Personal Programming

HilaireFernandes
In reply to this post by Trygve Reenskaug
Hi Trygve,

Personal programming is something I always been fascinated by, since
decades, to empower users.

In the domain of teaching, the concept can go as far as giving the
ability to teachers to craft their own numeric tools in their respective
area.

This is for this exact reason I ported DrGeo to Squeak, then Pharo, in
2005. The end user programming gives the power to design very advanced
teaching models[1].

However, Smalltalk scripting can be tricky, so this is with profound
interest I will read your paper in the later days.

Hilaire

[1] http://blog.drgeo.eu/post/2019/The-Newton-Raphson-Method

Le 25/07/2019 à 11:29, Trygve a écrit :
> The final draft of my magnum opus about Personal Programming is now
> ready for review:
> http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf

--
Dr. Geo
http://drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Personal Programming

Richard O'Keefe
There are some spelling issues in the PDF one finds at the Newton-Raphson link.
"bellow" and "below" mean different things and sound quite different
(BELL-owe vs b'-LOW).  In "In the sketch bellow" the one you want is "below".
"bloc" and "block" sound the same but also mean different things, and
the Smalltalk [...] forms are "blocks" not "blocs".

Is writing these interactive documents as much work as it looks like?



On Sat, 27 Jul 2019 at 17:59, Hilaire <[hidden email]> wrote:
Hi Trygve,

Personal programming is something I always been fascinated by, since
decades, to empower users.

In the domain of teaching, the concept can go as far as giving the
ability to teachers to craft their own numeric tools in their respective
area.

This is for this exact reason I ported DrGeo to Squeak, then Pharo, in
2005. The end user programming gives the power to design very advanced
teaching models[1].

However, Smalltalk scripting can be tricky, so this is with profound
interest I will read your paper in the later days.

Hilaire

[1] http://blog.drgeo.eu/post/2019/The-Newton-Raphson-Method

Le 25/07/2019 à 11:29, Trygve a écrit :
> The final draft of my magnum opus about Personal Programming is now
> ready for review:
> http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf

--
Dr. Geo
http://drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Personal Programming

HilaireFernandes
Thanks Richard for your review of the article and your pedagogical
explanations.

For me writing these interactive documents are not that much work. But
it is true you need to know the DrGeo API. Which can be discovered by
exploring the DrGeoSketch class.

I am used to the DrGeo API, so my view is biased. A more user
discoverable programming interface will be easier. So the interest on
Trygve work.

I am finishing writing a textbook on DrGeo math programming for my
middle high school students. But the resources is in French :(

Le 27/07/2019 à 16:26, Richard O'Keefe a écrit :

> There are some spelling issues in the PDF one finds at the
> Newton-Raphson link.
> "bellow" and "below" mean different things and sound quite different
> (BELL-owe vs b'-LOW).  In "In the sketch bellow" the one you want is
> "below".
> "bloc" and "block" sound the same but also mean different things, and
> the Smalltalk [...] forms are "blocks" not "blocs".
>
> Is writing these interactive documents as much work as it looks like?
>
--
Dr. Geo
http://drgeo.eu