Hacker News new | past | comments | ask | show | jobs | submit login

For an update: Talking with a legend – interview with Anders Hejlsberg

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.




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



From the Byte magazine • November 1987 • p97:

"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."


Interesting. He started using hash tables internally within the compiler as of v2.0.


…he started…? no. He started using hash tables within the compiler as of v4.0.

…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…


Oh absolutely. How smart people not people who can do fizzbuzz and friends.


What a beautiful interview, thanks for sharing.


https://youtu.be/K3qf8gRFESU?t=1550 At the 25min point, Anders talked about ripping from C# 4. Anyone know the reasoning behind it?


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].

[1]: https://docs.microsoft.com/dotnet/csharp/programming-guide/t...

[2]: https://github.com/dotnet/runtime/pull/33060

[3]: https://github.com/dotnet/runtime/issues/27790

[4]: https://en.wikipedia.org/wiki/Dynamic_Language_Runtime


thank you!




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: