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.
fascinating. He discovered hash tables after he released TurboPascal 1.0 and used them 2.0; https://youtu.be/K3qf8gRFESU?t=3265. So perhaps Anders of TurboPascal 1.0 can't pass certain leetcode challenges :)
IIRC, hash tables came with Turbo Pascal v4.0 and not with v2.0 (4 years between v1.0 and v4.0). Interestingly I can't remember what the difference was between v1.0 and v2.0 but looking at the release dates I think there wasn't much…
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 1983
"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."
NOTE: this is just my perspective from observing the language evolve.
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].
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).
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
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.
Anders was one of my early heroes too - way before people like Gates or Ellison were on the scene. I too graduated from BASIC to Turbo Pascal, and couldn't believe the speed differential, and learning about things like recursion etc.
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.
Linus, Anders, Lars Bak (and my humble self) are all Scandinavians. I have been told [far too many times] that we tend to be rather "direct" which often clashes with other cultures (most extreme counter example I've seen are the always polite Japanese).
I have no problem with people with an attitude. I just don't always agree with them (all of the aforementioned included).
Delphi was great! First programming language I used at my first job.
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.
There's an active opensource Delphi clone that is nearly feature equivalent - https://www.lazarus-ide.org/ - if you are interested. And you can use it to create commercial software applications too.
Delphi, C++ Builder, etc do have free licenses for personal use actually[0][1] and they had for a while. It is just that their license is only free until you have $5k annual revenue (the site's wording might sound as if this has to come from selling Delphi software but the actual license[2] isn't that specific).
Embarcadero is unfortunately the typical enterprise software company that makes their pricing as opaque as possible and very hostile towards small companies. Definitely not something I would bet my little company on.
Borland had the Delphi 7 Personal Edition, but it was only for non-commercial use only. It was distributed widely though - I personally still have a copy i got from a magazine coverdisk for example.
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.
Well, many consider Delphi 7 to be the last good Delphi :-P (and FWIW Delphi 2006 to be the worst one - which, incidentally, was also used as the basis for the short lived "Turbo Delphi" that most likely didn't do it any favors)
The Visual Studio Community edition is way, WAY less restricting. It is free for individuals, period (it is the very first thing mentioned in the license[0]). If you are an organization, you can also use it for free as long as no more than five people use it at the same time and you are not an enterprise (defined as an organization with 250 or more than $1m in annual revenue). Regardless of any of the above it is also free if you make open source software.
This is a far cry from Embarcadero's restrictions.
Back then assembly makes sense and many pieces of "large" software were written in assembly (or at least a critical part of them).
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 was by far the fastest compiler I'd ever used. A full 10x faster than their Borland C++ compiler, which was faster than gcc. Delphi didn't do as many optimizations, but the compiled code had runtime performance within a few percent of C, and the lightning fast compiles were worth it for productivity.
It doesn't surprise me to hear it was written in asm.
FWIW i wrote a small raytracing benchmark in C and Pascal (99% the same code just "translated") some time ago[0], mainly for comparing compilers for retrocoding and in my results Delphi 2 produced code that took around the 149% the time the Visual C++ 6 program took. Interestingly Borland C++ 5 was slower, though it predates Delphi 2 (also i forgot to benchmark Borland C++ Builder).
(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.
Well, yeah, maybe if you are writing ray tracers. The focus of Delphi was object oriented data structures (especially for UIs) and there isn't a lot that the compiler can optimize when the function is packed full of method calls, which is why UI in Delphi was nearly identical performance to one in C++. If you want vector math to run fast, those C++ compiler optimizations are a lot more important.
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.
FWIW what i wanted to point out was that even for something as a raytracer Delphi 2 wasn't really that much slower :-P. And as i mention on the site, if i was to use that on retro hardware i'd rather use Delphi 2 and write better code (IMO a good profiler is much more important than a good optimizer when it comes to writing fast code anyway) instead of VC++6 because Delphi 2 is much faster to use.
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)
> I can't imagine building anything complex in x86 assembly, let alone a freakin' compiler!
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.
Another really great video is Anders and Lars Bak around the time Typescript and Dart came out (about the same time.) In this video Anders explains to Lars why TypeScript will win the race to fix JavaScript's drawbacks. Lars was really happy with their Dart VM (as he should be) and didn't really want to hear how TypeScript would prevail. The thing about Anders is that he's usually right and he was.
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.
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.