There is no way to mark the language version, no
#pragma stdc version iso99
Delphi:
{$IF CompilerVersion >= 17.0}
Freepascal:
{$if FPC_VERSION > 2}
No make files: the compiler handles that trash for you.
Compatibility: Freepascal supports Delphi, Object Pascal, and has
various switches for all kinds of things should you need it.
Supports Windows, Linux, Mac, Android, Amiga (...seriously) and a
multitude of other systems.
On Wed, May 9, 2018, 6:54 AM Richard O'Keefe <rao...@gmail.com> wrote:
> I have a C++ program written in the late 80s by someone
> else. It used to run fine under cfront 2.0 and early g++.
> Ten years after it was written it was impossible to compile.
>
> *Since* that there have been changes to streams and strings,
> amongst other things.
>
> The 1989 C standard changed the semantics of mixed signed/unsigned
> integer arithmetic. It also inadvertently rendered illegal a
> widely used technique. It is notoriously the case these days
> that compilers taking the C standards literally have "broken"
> quite a lot of code that worked with less ambitious compilers.
> I have been watching this phenomenon with considerable
> nervousness. See for example
> http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf
>
> I have certainly had previously acceptable C89 code be rejected
> by compilers as not being legal C11. It is true that compilers
> tend to have command line/IDE switches to ask that old code be
> compiled under old rules, but you cannot say that *in* the program.
> There is no way to mark the language version, no
> #pragma stdc version iso99
>
>
>
> As for Java, I could rant about the floods of deprecation warnings
> from old code. I shall content myself with one observation.
> Read http://java-performance.info/changes-to-string-java-1-7-0_06/
> Before Java 1.7, the substring operation in Java took O(1) time
> and space. From Java 1.7 on, it takes time and space linear in the
> size of the result. The syntax and abstract semantics did not
> change but the pragmatics did. Code that had adequate performance
> could suddenly start crawling.
>
> Oracle do a tolerably thorough job of describing compatibility
> issues between JDK releases. See for example
>
> http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198
> where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge
> was gone, 32-bit Solaris support (and yes, I was still using 32-bit
> code in SPARC Solaris and Intel Solaris) was gone, and the type
> inference algorithm had changed in a way that could break things.
> I am still somewhat peeved about some of the rewriting I've had to
> do over the last several releases.
>
> Then there is the simple fact that porting code from one release of
> an OS to another can be a pain. Solaris 10 to OpenSolaris was easy.
> OpenSolaris to Solaris 11 was not as painless. Solaris 11 to
> OpenIndiana was not a happy time for me. OpenBSD changes forced
> rework. I'd finally got my program to port smoothly between Solaris,
> Darwin, and Linux. And then I had trouble porting to the next major
> release of Linux. And with Ubuntu 17, I've got another problem I
> still haven't tracked down. All of this in a C program that gets
> regularly (sp)linted and checked all sorts of ways, written with
> the intention of producing portable code.
>
> EVERYTHING BREAKS.
>
>
> On 7 May 2018 at 22:42, Trygve Reenskaug <tryg...@ifi.uio.no> wrote:
>
>> 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.
>>
>>
>> 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 <%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 collaborate to achieve a goal. *
>> Trygve Reenskaug mailto: tryg...@ifi.uio.no <%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 collaborate to
>> achieve a goal. *
>> Trygve Reenskaug mailto: tryg...@ifi.uio.no <%20tryg...@ifi.uio.no>
>> Morgedalsvn. 5A http://folk.uio.no/trygver/
>> N-0378 Oslo http://fullOO.info
>> Norway Tel: (+47) 22 49 57 27
>>
>
>
