> 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 >>> <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 objects collaborate to achieve >>>>> a goal. >>>>> Trygve Reenskaug mailto: tryg...@ifi.uio.no >>>>> <mailto:%20tryg...@ifi.uio.no> >>>>> Morgedalsvn. 5A http://folk.uio.no/trygver/ >>>>> <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 collaborate to achieve a >>> goal. >>> Trygve Reenskaug mailto: tryg...@ifi.uio.no >>> <mailto:%20tryg...@ifi.uio.no> >>> Morgedalsvn. 5A http://folk.uio.no/trygver/ >>> <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 collaborate to achieve a > goal. > Trygve Reenskaug mailto: tryg...@ifi.uio.no > <mailto:%20tryg...@ifi.uio.no> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > <http://folk.uio.no/trygver/> > N-0378 Oslo http://fullOO.info <http://fulloo.info/> > Norway Tel: (+47) 22 49 57 27
