3 ms·

Re: the term "Object Pascal". When I say "Object Pascal", I'm referring to the Delphi version that was released in 1995-96, not the older versions. It was sti

Re: the term "Object Pascal". When I say "Object Pascal", I'm referring to the Delphi version that was released in 1995-96, not the older versions. It was still going strong into the early 2000s, but starting to experience some issues due to the C# headwinds and the pressure that MS was putting on Borland (thanks for the link on Anders, I've bookmarked for listening this evening). We were (are) there for the whole thing as a 3rd party component company in the Delphi market. But, my original point was about the pros and cons of the language, itself. Object Pascal seems to solve some major pain points experienced with other languages (specifically strings and dynamic arrays, but also others), but doesn't get copied or adopted as much as one would think. Instead, newer languages keep copying the same bad ideas that kill performance and/or limit the versatility of the language.

pjmlp 8y ago
I think Java is partially to blame for that. When it came out I was disappointed that they adopted and interpreter, followed by JIT with 1.2, leaving to commercial third parties the AOT compiler toolchain. I was then double disappointed with .NET, due to the NGEN/JIT mix, because NGEN was no match for a proper AOT compilation, just for faster startups. And it took them Singularity, Midori, to finally arrive at CoreRT and .NET Native, and still it only applies to certain deployment scenarios. Back then it wasn't only Delphi, there was Oberon, Component Pascal, Eiffel. But they were all commercial and then around the same time FOSS started to pick up steam, Kylix was very badly managed, and due to its UNIX roots everyone was mostly writing GNU tools in C, which wasn't actually that much used in the PC world where we were already quite happily using OWL, VCL and MFC. At least Pascal style syntax is fashionable again.
- TimJYoung 8y ago
  Yeah, I keep remarking that I think that a proper AOT C# or Java is a game-changer, but I'm not sure if these languages will ever be able to shed the baggage of the very large frameworks that developed around them. But, I will also be very glad to be wrong. As for Kylix, I simply think that there was no way that it was going to work on Linux. IOW, trying to do a GUI-based development tool on Linux was a bad idea from the start. They couldn't even nail down a few distributions very well - it was a constant moving target...

pjmlp 8y ago

I think Java is partially to blame for that. When it came out I was disappointed that they adopted and interpreter, followed by JIT with 1.2, leaving to commercial third parties the AOT compiler toolchain. I was then double disappointed with .NET, due to the NGEN/JIT mix, because NGEN was no match for a proper AOT compilation, just for faster startups. And it took them Singularity, Midori, to finally arrive at CoreRT and .NET Native, and still it only applies to certain deployment scenarios. Back then it wasn't only Delphi, there was Oberon, Component Pascal, Eiffel. But they were all commercial and then around the same time FOSS started to pick up steam, Kylix was very badly managed, and due to its UNIX roots everyone was mostly writing GNU tools in C, which wasn't actually that much used in the PC world where we were already quite happily using OWL, VCL and MFC. At least Pascal style syntax is fashionable again.

TimJYoung 8y ago
Yeah, I keep remarking that I think that a proper AOT C# or Java is a game-changer, but I'm not sure if these languages will ever be able to shed the baggage of the very large frameworks that developed around them. But, I will also be very glad to be wrong. As for Kylix, I simply think that there was no way that it was going to work on Linux. IOW, trying to do a GUI-based development tool on Linux was a bad idea from the start. They couldn't even nail down a few distributions very well - it was a constant moving target...