Hi Norbert,
This discussion has been very useful to me. Let me stress that I am not
criticizing Pharo. I think Pharo is an exciting and promising project.
But I have set requirements for PP that Pharo can't fill. I have no
idea how to fill them or if they can be filled at all. So here is a new
research project that I look forward to digging into as soon as time
permits.
Thanks
-Trygve
On 08.05.2018 09:57, Norbert Hartl wrote:
Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug <tryg...@ifi.uio.no
<mailto:tryg...@ifi.uio.no>>:
Norbert,
I stand corrected because I have not followed the mainstream
languages as well as I probably should. Thank you for your candid
answer, it clearly outlines what I can and cannot expect from Pharo
and any other ST project.
Ok, I didn’t want to sound too harsh but for me there is no benefit in
telling something which is not true. And as a member of such community
you get sometimes allergic to things that sound negative because that
happens far too often. What I said about not upgrading is the thing we
suffer from. While you find it that squeak has moved too fast we
consider it that it didn’t move enough. That is why a lot of the
sub-systems need to be replaced and that causes instability. For me
the stability is outstanding if I look what is changed all the time.
But that is another perspective. For a user of the platform it is
simply annoying. We know that but not moving is not option for us so
that’s why I say that frankly. And sadly the only thing that can
compensate side-effects due to changes is to put a lot of man power
onto it. The programming/software world has not much too say about how
change should be done.
I go back to Alan Kay's vision of a Dynabook: A/personal/computer for
children of all ages. It should contain all its owner's
/personal/data, including his or her/personal/programs, as they
evolve through the years. Continuity is a must; the owner shall
never loose data.
We are onto it. If you look at the way we can work, model inspect etc.
it is still an wonderful tool. And it is getting better every day
while breaking things here and there. I can only repeat what I said
earlier. The part of your IDE that copes with language details might
break the least because that is the most stable part of the pharo
system. But all of the UI system will be replaced in a non-compatible
way. Morphic is great but it has grown into a hugly monster. And in
this century you might not survive having bitmap based graphics. It
might still make perfect sense to you. Because there will be some
effort put into the ability to load it into pharo at wish. But I would
suspect it won’t change much from there.
But it cannot stay because to old-fashioned and not changeable. Maybe
it is missing in the Dynabook vision that is not likely that children
born after 2000 still won’t too use a graphical interface designed in
the 70s being unchanged. But I’m not sure if the Dynabook vision was
supposed to be realized some day or just a vehicle to complain about
everything.
Again, thank you for your answers. They have given invaluable
contributions to my thinking.
I would have liked to say something more encouraging but ….
Norbert
--Trygve.
On 07.05.2018 14:14, Norbert Hartl wrote:
Am 07.05.2018 um 12:42 schrieb Trygve Reenskaug <tryg...@ifi.uio.no
<mailto:tryg...@ifi.uio.no>>:
Please tell me when Java, C, C++, etc programs stopped working
because their runtime systems had changed.
Please tell me when Java, C, C++, etc compilers stopped compiling
old code because the languages had changed.
If we talk about C/C++ the runtime is the operating system.
Everytime I update it the linked libraries are suspect to be invalid
from then. If you have in the same system update a new version of
the C compiler you are doomed. You cannot link your binary with the
new libs. And the new C compiler quirks about your code. So what you
have then? Staying on an old C language standard? Statically link
everything. Ah no that won’t work because you would have to care
about all your dependencies being compilable with the new compiler.
But you don’t update the compiler meaning you don’t update the
operating system. It is the same as staying on pharo 3.
For Java the situation is slightly different because if you use new
programming language features you can only do when switching the
compiler to the new standard. There is a lot of effort that went
into making the java vm recognize the language version and execute
regarding that making version compatible. We are in sync here. I
told you it is about manpower. Do you know how much manpower it
needed and how long it took to add something like closures to the
java language? Do you consider java closure to be en par with other
languages?
We are sorry not everything is to your liking. It is not even to our
own liking because we have dreams far beyond. But we will never get
there if we don’t take the effort. And the point of open source (did
I mention pharo is open source?? ) is that the ones that do it
decide what to do. Nuff said!
Norbert
On 07.05.2018 11:57, Norbert Hartl wrote:
I understand what you are saying but it contains some
misconceptions about the modern software world.
„The earth is not stopping to turn just because you want to stay
on the sunny side“
There is two funny concepts going on in the modern software
industry. The one tells you that because you want to do a product
everything else around you should come to a full stop so can
comfortably build your software not disturbed by other things. The
second one tells you that you _have to upgrade_ … there is this
magical force preventing you from staying where you are. Both
notions are funny alone but they come combined and then they turn
out to be a non-sensical monster.
Let’s take a different approach. Put in everything you say about
software, libraries, etc the word version. So you can build upon
Pharo version 3 your own product. You can stay at that version and
it won’t change. If the software you sell is not 80% pharo but
your own you should not have a problem just to stay on that
version because you develop your own stuff. But still the world
did not stop turning and there is pharo 4. You decide there are a
few nice features but the work to adjust is too big to take the
risk. Then there is pharo 5 and you … nahhh not this time….Then
there is pharo6 and they not only changed the image but also the
way source code is managed. That prevents you further from
adjusting. But hey you can still be happy with pharo3 and it does
not change.
So what is the real problem? Yes, money/time is not enough. I
think there are a lot of people risking their health to promote
pharo and now we have a consortium that can pay engineers to do
work on pharo. So let me tell you a future story:
You see what pharo is doing and you think it is good. You can also
see that there are too less resources to proceed in the way you
need it to go. So you decide to show pharo to the world inspiring
people with some kind of a vision. The result is that more people
pay into the consortium and we hire more engineers. And then one
day the consortium has enough money to pay engineers that can care
about a LTS (long term support) version of pharo. So you can stay
on pharo version 3 and still get those annoying bugs fixed. And
hey this team has also enough time to provide you with tools that
make a migration to pharo version 4 more easy and less annoying
for you. And then you have your own product based on pharo version
4. And then for version 5, version 6,…. Sounds like a dream…but
hey…it is indeed realistic. It just depends on how the people
approach it
How does this sound?
Norbert
Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug
<tryg...@ifi.uio.no <mailto:tryg...@ifi.uio.no>>:
Thanks for your quick answer. I have only a fleeting knowledge
of Pharo but liked what I saw. The Squeak class library has seen
organic growth since 1978 or earlier. Pharo gave it a thorough
overhaul. At the Pharo kernel was a minimal image with a minimal
class library. The rest of the functionality was partitioned into
packages that could be added to the kernel image as required.
Beautiful. But only my dream?
/Matthew 7:24-27: And the rain fell, and the floods came, and
the winds blew and beat on that house, but it did not fall,
because it had been founded on the rock. And everyone who
hears these words of mine and does not do them will be like a
foolish man who built his house on the sand."/
I am developing an IDE for non-programmers called BabyIDE, a
non-intrusive extension of Squeak. Where the Class Browser in
Squeak is used to work with one class at the time, the BabyIDE
browser is used to work with structures of collaborating objects,
ignoring their classes. I would like to develop a BabyIDE image
that gets broad usage and long life. I'm looking for a rock to
build on and hoped it could be what I thought was the Pharo
kernel+ a few selected packages. In your answer, I read that if I
build BabyIDE on Pharo, I will be building on sand.
pharo.org <http://pharo.org/>writes: "/Pharo is a pure
object-oriented programming language.../". The only language I
can see is defined by the release image. A Pharo programmer
builds application programs in this language. He or she can add
new classes, change existing ones, subclass them, add or change
methods, change the Smalltalk dictionary, etc. etc. An extremely
flexible and powerful language.
A tale from the future when Pharo is a mainstream
language:Business customers benefit from end users using
applications that are written by Pharo programmers who built on
the Pharo language and environment that had been developed by the
Pharo community. One day there is a happy announcement: A new
version of Pharo will be launched tomorrow. It is truly cool and
includes any number of improvements, some of them documented.
And, by the way, applications written in the current Pharo will
no longer work. So please inform your customers that you will not
be able to serve them for a while. We are confident that all your
application programmers will be happy to drop whatever they are
doing in order to adapt their applications to the new Pharo so
that you can start serving your customers again.
Cheers
--Trygve
On 06.05.2018 13:00, Norbert Hartl wrote:
Can you elaborate on what you consider as a kernel? There are
always things moving in the pharo world. The last years the
virtual machine got some iterations and it is still not fully
stable. For pharo it is hard to have it stable because we feel
the need that a lot of the existing parts need to be replaced to
be useful in these times. Furthermore pharo is also prototyping
platform for programming language features. All of these are
counter-stability measures. So if you need a stable kernel from
native ground up to UI pharo won‘t be that thing you are looking
for the coming years (if at all). You always need to adopt to
change so you need to define your required scope better in order
to get an estimate.
Norbert
Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug
<tryg...@ifi.uio.no <mailto:tryg...@ifi.uio.no>>:
I'm working on a programing paradigm and IDE for the personal
programmer who wants to control his or her IoT. The size of the
target audience I have in mind is >100 million. I gave up
Squeak long ago as a platform because they obsolete my code
faster than I can write it. I have now frozen Squeak 3.10.2
and hope its runtime will survive until I find a better
foundation. My hope is that Pharo has a stable kernel that I
can build on. According to Stephan, this is not so. Is there
any plan for creating a stable Pharo kernel that people can use
for building software of lasting value for millions of
non-expert users?
--Thanks, Trygve
On 05.05.2018 13:53, Stephan Eggermont wrote:
I’ve taken a look at what would be needed to
support magma on pharo a few years ago. Chris always told us he uses it
professionally on squeak and/*has not enough capacity to keep up with changes in pharo
without having a customer/maintainer for it.*/ Twice a year
or so someone asks about magma on pharo and takes a look. AFAIK there are
no real obstacles to a port, but magma uses a lot of deep implementation
specifics that will take an experienced smalltalker to deal with, and a lot
of mailing list archeology as pharo changed a lot since magma worked on
pharo last
Stephan
--
--
/The essence of object orientation is that
objectscollaboratetoachieve a goal./
TrygveReenskaug mailto: tryg...@ifi.uio.no <mailto:%20tryg...@ifi.uio.no>
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info <http://fulloo.info/>
Norway Tel: (+47) 22 49 57 27
--
/The essence of object orientation is that objects collaborateto achieve
a goal. /
Trygve Reenskaug mailto: tryg...@ifi.uio.no <mailto:%20tryg...@ifi.uio.no>
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 22 49 57 27
