Interview with Anders Hejlsberg on Delphi (1995)
theopenforce.com
theopenforce.com
https://www.youtube.com/watch?v=K3qf8gRFESU
His brother interviews him. He gets philosophical about some things as he is older and says he will never work at the corporate office again. I enjoy Anders presence, which all great programmers seems to share, which is a certain calmness and reasonableness about code. I really appreciate his contributions over the years.
Borland Pascal v7.0 27th October 1992
Turbo Pascal for Windows v1.5 8th June 1992
Turbo Pascal for Windows v1.0 13th February 1991
Turbo Pascal v6.0 23rd October 1990
Turbo Pascal v5.5 2nd May 1989
Turbo Pascal v5.0 24th August 1988
Turbo Pascal v4.0 20th November 1987
Turbo Pascal v3.0 17th September 1986
Turbo Pascal v2.0 17th April 1984
Turbo Pascal v1.0 20th November 1983Young Anders Hejlsberg at age 28 in an interview...
https://community.embarcadero.com/files/2008/11/tp01_868.jpg
https://community.embarcadero.com/files/2008/11/tp02_871.jpg
https://community.embarcadero.com/files/2008/11/tp03_874.jpg
https://community.embarcadero.com/files/2008/11/tp04_877.jpg
"Borland says version 4.0 will outperform previous versions in compilation speed and efficiency. I compared 3.0 and my preliminary version of 4.0 in compiling the CALC.PAS program provided with Turbo Pascal. On a 4.77 MHz IBM PC with 512K bytes of RAM and an 8087 co processor, version 3.0 took 15 seconds to compile the 1272 line program. Turbo Pascal version 4.0 took just 10 seconds to compile a slightly different 1273 line version of CALC.PAS."
…he stated (in that interview) using hash tables within the compiler as of v2.0? yes! ;-)
What I mean here is that Anders probably remembers that wrong which is absolutely ok, thats now what… 35 years ago…
Anders Hejlsberg specifically mentions the "dynamic"[1] keyword. Normally C# is statically typed, that is at compile time you know the type of everything. With the "dynamic" keyword, function calls and field access are resolved at run time. For example if you have the following code:
dynamic myObj = new object();
Console.WriteLine(myObj.MyProp);
It will compile fine. At runtime it will crash, because System.Object has no property "MyProp". But if the object did have the "MyProp" property, it would have run fine. This example shows how dynamic can take C# from a statically typed language like Java and turn it into a dynamically type language like Python. From a language design perspective, this is a bit of an aberration from the statically typed path C# has taken most of the time.From a language implementation perspective, this feature has a high cost. It requires re-implementing features of the C# compiler as a library in the Microsoft.CSharp namespace. This is required by features like overload resolution for method calls have to happen at runtime instead of compile time. And because compiled programs take dependencies on this library, it is hard to change it without breaking deployed programs. The supporting libraries are so fragile that there is a policy to not change them [3].
As for why you would want this late-bound stuff in the first place, it is kinda nice when interfacing with dynamic language environments. When the feature was originally released, the Dynamic Language Runtime[4] was a big deal. It enabled implemented versions of Ruby and Python (called IronRuby and IronPython) that were based on .NET. And the "dynamic" keyword ease calling into these language implementations. Additionally calling into COM was made easier by the "dynamic" keyword. It was so useful that it was added back to .NET 5 [2].
[1]: https://docs.microsoft.com/dotnet/csharp/programming-guide/t...
[2]: https://github.com/dotnet/runtime/pull/33060
Anders is a bit of a childhood hero of mine.
I got the BLS Pascal 1.2 and the shock of coming from line-based interpreted Microsoft BASIC to full-screen editor with lighting fast compiler in three keypresses (Ctrl-X, C, Return) is hard to describe. (Full-screen editing and compilation representing two quantum leaps).
Studing the internals of the BLS Pascal (Z80, Nascom 2) literally boggled my mind with the genius of the code which was unlike any other Z80 code I had read.
I was fortunate enough to meet the still young Anders at the "Herningmesse" where he was demonstrating Compas Pascal (running a Maze generator to attract eyeballs). He was very nice but I was too shy to ask the really good questions :)
I'm still actually chasing this. I have never managed to get a working version of BLS Pascal 1.3 but I know it exist (help would be most welcome - the one Google find you is corrupted).
Ha. I, too, experienced this same shock when I moved, as a teenager, from MS-BASIC's editor to a Pascal-based (in my case it was Turbo) full-screen editor.
Ton be honest, for the first couple of hours I can recall being very confused about how I was to approch coding with no line numbers? How was I to move to other sections of my program? What, no GOTO...help!
Little did I know at the time almost all GOTO use is bad programming and that Pascal was such an elegant and dare-I-Say beautiful language to program in. It's fairly tame use of pointers (as compared with C smashing you over the head with them) really exposed me to one of CompSci's more powerful paradigms...indirect addressing.
And, OMG, the incredible speed of both the compiler and the programs it generated simply blew my mind...esp. since its very possible I was using a 8Mhz IBM PC/AT at the time. My simulations literally ran 25x faster.
Those were heady times to be a programmer IMHO...you literally had the count the number of bytes in your data structures to squeeze every bit of memory use out of your 64k stacks and 640k DOS limits, and all sorts of tricks were used to overcome these obstacles. ..
Beauty is in the eye of the beholder, but as best I remember I always lamented the verbosity of Pascal (I worked professionally for a time in Turbo Pascal). Modulo-2 was IMhO a much better language and had he used that, revised with a more concise syntax a-la C/C#/Rust, I think I would have been a lot happier. (I must resist the urge to go back and reimplement BLS Pascal the way I would have liked it).
Stepping back a bit, what really made Anders' early designs remarkable wasn't just the engineering, but the deliberate trade-off he made. He emphasized compilation time over almost everything (I think all contemporaries tried to generate as good code as possible). This priority is what dictated a one-pass compiler and in assembler. I saw the same unusual economy in his code where sometimes he would do things in a less efficient way, presumably because it saved code size.
I actually went down the path of changing the Oberon parser to take a different syntax. My PoC worked but I didn’t complete it.
I never met Anders, but I did meet someone who used to work with him at one point and who marvelled at how he use to write blocks or Assembly code off the top of his head when everyone else had to plot the instructions and registers on paper first.
I have no problem with people with an attitude. I just don't always agree with them (all of the aforementioned included).
Direct does not equate an absence of sensitivity and tact.
I have some hobby projects that are still used to this day written in Delphi. I haven't really updated them too much. Too much work to rewrite it. Some critical faults that have emerged overtime. Not really delphi faults. I used Paradox for the database. Which was terrible choice even back then. I recently had it complain about the length of the path to the table.
In another app, for some odd reason I can't remember, I developed a custom a plugin system, using dll com plugins.
As time went on, microsoft limited access to the windows registry. So now I have user running into problems with the install. The program installs, just can't find the plugins because it doesn't have registry access. At least that's my limited understanding of what is going on.
And I think you can't write Delphi apps for the windows app store. But Delphi was very strait forward and simple to write apps. Fantastic! And comparing it to Python, much easier to find bugs.
Sure you can: https://blogs.embarcadero.com/deploying-windows-10-apps-thro...
And to the macOS app store: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Subm...
And to the iOS app store: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Depl...
And to Google Play: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Subm...
If Delphi was open sourced, or heck — if it had a free license for personal use, I would bet it would still be the dominant IDE.
[0] https://www.embarcadero.com/products/delphi/starter
[1] https://www.embarcadero.com/products/cbuilder/starter
[2] https://www.embarcadero.com/products/rad-studio/rad-studio-e...
Lazarus was and is the better choice in any case.
IIRC Borland never did that, and that's why it's no longer a household name.
But TBH Borland also had much lower prices - up to (IIRC) Delphi 5 you could get the most basic version of Delphi (which is good enough for a lot of tasks, especially for individuals) for $100 and that used Borland's "no-nonsense" license that was no strings attached, allowing reselling, etc. It was when they were taken over by Enterprise Envy that things went downhill for them.
But it was back in Ukraine, at a time when everything was pirated, so the question of licensing didn't really come up.
Ah. Enterprise Envy is such a pity. I really had my hopes up when Kylix came out.
This is a far cry from Embarcadero's restrictions.
[0] https://visualstudio.microsoft.com/license-terms/vs2022-ga-c...
> A. The compiler is written in assembly language.
That's amazing to me. My first real language was Java, then Ruby, C#, JavaScript, Python, etc. -- and only a smattering of C/C++ in college.
I can't imagine building anything complex in x86 assembly, let alone a freakin' compiler!
Go back another decade and people naturally take assembly as the second language after they are done with BASIC. Those were teenage hobbyists. Machines then (Apple ][, C64, BBC, etc.) were much simpler and didn't have a lot of memory. It was a lot easier to wrap your head around it. Nowadays it's impossible to do so I think, unless you have a long track of assembly career.
It doesn't surprise me to hear it was written in asm.
(note that this is from the second table where i check compilers that can generate code running on Pentium 1 Win9x - the first table was with whatever compiler i had installed on my PC at the time)
Perhaps i'll try benchmarking it again some day, including running on actual older hardware.
Just to clarify, my main point was the speed at which it would compile the code, which was an order of magnitude faster than anything else.
In practice it'd be fast enough anyway. Sadly i do not have anything fancy made with Delphi 2 specifically, but in this video[0] i play a software rendering 3D game i made for an MSDOS game jam last year (it also works on Windows 95[1]) which was made in Free Pascal that from the table i linked at produces executables with around the same performance as Delphi 2 (at least for the 32bit version without using any modern CPU instructions). The majority of the time is spent in the rasterizer, the innermost bits of which are written in assembly, so even if Delphi 2 was much worse at codegen it wouldn't matter much anyway.
(sometimes i do consider out of curiosity to convert the code to be compatible with Delphi 2, but it relies on language features like generics for the collections and on some FPC-specific bits for object de/serialization that would make the conversion non-trivial)
Note that it's massively simpler than a modern compiler. Simple data structures, very simple passes. If you're thinking about complex graphical manipulation like compilers now, that's not really what it was.
So basically, we still find Delphi quite useful even the older versions.
Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart
i already knew Anders Hejlsberg but that talk left a great impression on me. in fact, after that talk, i knew TypeScript would do something more interesting than Dart. and would definitely be more successful. in fact, anyone watching that talk could tell.
Anders Hejlsberg explained so well what they were doing.
but the dart team displayed a lot of uneasiness. Lars Bak especially. there was another member of the Dart team who seemed less stressed during that interview. iirc they went to work on the go programming language.
"Anders Hejlsberg: A craftsman of computer language"
https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-c...
Fashion cycles in general programming and programming language design are just as real as in any other human activity. And just as fun to watch.