Yes, it has been 2 years since the last status of IP Pascal.
That certainly calls for an admission on my part. IP Pascal is a project that I work on when I don't have other work. If work on it stops, and status stops, it means I am working 10 hour days on other projects. Good for me, not so good for IP Pascal.
The fundamental reason for this is that IP Pascal does not support itself financially. However, I have good reason to believe that will change.
IP Pascal 1.12, the demo version, and version 1.13, the internal version I use here, was a new high in terms of testing and functionality. There has never been a version of IP that got a more through workout, including the BSI Pascal verification suite (using, I hasten to add, the PUG newsletters version; the BSI version is not available anywhere, at any price).
Based on my experiences with 1.13, and from feedback from demo users, I worked on a series of improvements in the system that constitute such a dramatic improvement that it qualifies for a new version number. 2.0 will be a new world for IP Pascal, and it will incorporate several improvements that I have been working on for the last 10 years, or as long as the 80386 implementation has been in existence (some of the code for IP Pascal goes back to 1980).
Work on 2.0 is nearly complete, and it will enter final testing phase this summer.
So what is new in 2.0?
I have also been working to create a more open working methodology for IP Pascal. It is my goal that the demo version will be a full, unrestricted version of IP Pascal by use of the IP Pascal runtime interpreter. The paid versions will feature the full optimizing compiler back end, and only the users who need full speed and/or assembly level access and embedded design features will need to purchase a full version.
Further, I intend that the language of IP Pascal be open for all use. I will shortly publish a complete specification for the language of IP Pascal on the standard Pascal website (note that Borland has never done this), and it is my intent that the Pascal implementation P5, the version of Niklaus Wirth's P4 compiler that was updated to include full ISO 7185 support, will be brought forward to P6, and fully implement the language of IP Pascal as an open source compiler available to anyone, including for commercial use, including to compete with me if you so desire.
This is not (to me) at odds with my fundamental mission here, which is to deliver high quality, high code density compilers and support systems for IP Pascal. The language of IP Pascal, like Pascal itself, isn't, and should not be proprietary, and I plan to promote IP Pascal as I have promoted original Pascal.
So why do I think IP Pascal can turn a profit? IP Pascal, and Pascal itself, are based on type and access management. In fact, most languages up into the 1970s were, Algol, Fortran, Cobol, Basic and other languages were type and access safe. You didn't just get the address of any variable and start to muck about directly with the memory your variables laid in. With C/C++ in the 1990s, the computer community celebrated "anything goes" programming and "partied hearty" with unlimited use of pointers (and unfortunately, Delphi has been all about importing this mistake from C/C++ from day one). With Java and C#, the world beat a retreat from the massive fall in program reliability that resulted. In fact, I believe that the present popularity of script languages and interpreters is due in large part to the perception that use of "hard" C/C++ and pointers, and the resulting shower of bugs, is simply not worth it for many projects where speed is not critical.
However, programming style arguments aside, the computer world is moving rapidly into muticore, multiprocessing and increasing use of FPGAs and more complex silicon, dictated by the basic mathematics of Moore's law (the other Moore, not me), which means that silicon vendors are staring at chip gate capacities that they don't have clear ideas about what to do with. And to be blunt, C/C++ is simply not equipped to deal with this new world. Its like trying to take a go cart to the Indy 500. Trying to cobble together data security with the primitive tools of C/C++ was bad enough in a single task world. Saying that "good programmers don't need type/access security" in multitask/multiprocessing situations is just not good enough. Attempting to implement and analyse a multitask program with Pthreads and a few well placed "volatile" keywords is simply more than should be reasonably asked of any programmer, no matter what level of expertise (and I say this as a programmer who has implemented both multitask/multithread operating systems in C as well as C compilers).
The answer to this may indeed be Java/C#, and those are good languages. However, it also opens the door, in my opinion, to languages and solutions that have been correct for 40 years, not 10.
San Jose, California
1. Delphi is a trademark of the Borland software company (now Codegear).
2. Borland is the trademark of the Borland software company (now Codegear).