Hi, First, I concur with what Norbert said.
@Trygve: Could you describe what you would need in more details? Cheers, Doru > On May 8, 2018, at 9:57 AM, Norbert Hartl <norb...@hartl.name> wrote: > > > >> Am 08.05.2018 um 08:30 schrieb Trygve Reenskaug <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 personaldata, >> 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>: >>>> >>>> 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>: >>>>>> >>>>>> 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 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>: >>>>>>> >>>>>>>> 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 objects collaborate to achieve a >> goal. >> Trygve Reenskaug mailto: tryg...@ifi.uio.no >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info >> Norway Tel: (+47) 22 49 57 27 > -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."
