korrents

korrents · The Pragmatic Engineer Podcast

TypeScript, C# and Turbo Pascal with Anders Hejlsberg

Anders Hejlsberg · 1h 16m · youtube.com ↗

26 korrents from this recording

1h
Anders Hejlsberg did not write this page.

Every claim below is a statement made in this recording, quoted word for word and linked to the second it was said, so you can hear it rather than take our word for it. The wording comes from the transcript published alongside the recording; the sentence above each quote is our reading of the claim, not their wording.

  1. 0:09:10 · watch on youtube.com↗

    Our reading

    A programming language is not a compiler but an experience: editing, running, debugging and the runtime library all have to fit together as one cycle.

    Their wordsThat was always the idea, and that that goes back even to the predecessor of Turbo Pascal, this idea that it's not just a compiler. It's an experience, right? I mean, you don't just compile your programs. You also edit them. You also run them. You also debug them. You also have a runtime library. It all has to like fit together.
    Interesting
  2. 2 min later

  3. 0:11:17 · watch on youtube.com↗

    Our reading

    Turbo Pascal won because it was ten times better at a tenth of the price — faster, smaller, more interactive and cheaper at once.

    Their wordsIt was just better than all the competition. It was faster. It was smaller. Um it was more interactive and it was also cheaper. So, it was like 10 times better at a tenth of the price of the of the competition, right?
    Interesting
  4. 6 min later

  5. 0:17:39 · watch on youtube.com↗

    Our reading

    It is a bad strategy to bet your development platform on technology licensed from a competitor.

    Their wordsAnd so, we kind of realized at that point, too, that maybe it's not a great strategy to to place your your development platform bet on on technology that's licensed from a competitor.
    Interesting
  6. 2 min later

  7. 0:19:49 · watch on youtube.com↗

    Our reading

    C# exists because developers wanted both things at once: the power and productivity of C++ with the ease of use of Visual Basic.

    Their wordsWell, like I said, I mean the the overarching thing was this: power and productivity of C++ with the ease of use of Visual Basic in a sense, right?
    Interesting
  8. 2 min later

  9. 0:22:03 · watch on youtube.com↗

    Our reading

    A language should be designed by a small group of people rather than by one person.

    Their wordsI think early on we decided that we want to have a team of people design this language, not just one.
    Interesting
  10. 1 min later

  11. 0:22:41 · watch on youtube.com↗

    Our reading

    Language design is ninety per cent the same work every time and ten per cent new, which is why the experience carries from one language to the next.

    Their wordsAnd quite honestly, language design is 90% the same and 10% new for for pretty much every language. Every language you build still has to have a compiler. Compiler is still built in a pretty much the same way.
    Interesting
  12. 1 min later

  13. 0:23:43 · watch on youtube.com↗

    Our reading

    The job of a design group is to try to shoot down every new idea; the ones that survive the attempt are probably the good ones.

    Their wordsAnd everyone was cognizant of okay, if someone comes up with a new idea, now it's our job to try to shoot it down. What What's wrong with this idea? Do Do you know what I mean? And if it could go if it could stand the the test of of that, then it was probably a decent idea.
    Interesting
  14. 7 min later

  15. 0:30:51 · watch on youtube.com↗

    Our reading

    Writing state machines by hand is a nightmare and exactly the kind of transformation a compiler should do for you — which is all await really is.

    Their wordsYou can have the compiler write the state machine. If you introduce syntax that allows you to indicate where you want to yield. And that's what await is.
    Interesting
  16. 2 min later

  17. 0:33:05 · watch on youtube.com↗

    Our reading

    Function colouring is the real cost of async/await, and green threads like Go's avoid it — but for an existing runtime such as JavaScript or C#, async/await was still the right solution.

    Their wordsSo that's unfortunate, and that's why some environments like Go, for example, has has Go routines and green threads, which are really language emulated lightweight threads that kind of do what I'm talking about, but but at a much lower cost. But you avoid the function coloring. So there is a bunch of different things, but but you know, but for an environment that already exists like JavaScript or like C# and and the Windows event loop and and whatever, this this was the right solution.
    Interesting
  18. 2 min later

  19. 0:34:51 · watch on youtube.com↗

    Our reading

    The language that actually delivered write-once-run-anywhere was not Java but JavaScript, because every new device turned out to ship a browser.

    Their wordsbut lo and behold, they all run browsers with JavaScript in it. Lo and behold, the real cross-platform language isn't Java. It's JavaScript.
    Interesting
  20. 1 min later

  21. 0:36:15 · watch on youtube.com↗

    Our reading

    You cannot be best of breed in an ecosystem by telling its developers to write in a different programming language.

    Their wordsI mean, surely you're not going to be best of breed in the JavaScript ecosystem by telling people to write in a different programming language.
    Interesting
  22. 1 min later

  23. 0:36:58 · watch on youtube.com↗

    Our reading

    You cannot build good tooling without a type system — decent tooling perhaps, but nothing that scales to a large team.

    Their wordswe knew from experience that you cannot build good tooling without a type system. You can build decent tooling, but it's never going to scale. It's never going to scale to large teams cuz you can't describe your intents in in the code.
    Interesting
  24. 2 min later

  25. 0:38:34 · watch on youtube.com↗

    Our reading

    A proprietary language licensed from Microsoft had zero chance in the JavaScript ecosystem: TypeScript had to be open source or nobody would come.

    Their wordsAnd we we full well knew that there was absolutely zero chance that we would appeal to the JavaScript ecosystem with a proprietary programming language licensed from Microsoft. No. No one was going to come. It had to be open source. There was just no two ways about it, right?
    Interesting
  26. 1 min later

  27. 0:39:42 · watch on youtube.com↗

    Our reading

    Publishing the source is not the same as developing in the open, and only the second changes how the work actually goes.

    Their wordsYou know, there's open source and there's open development. And and and we were technically open source in the beginning, but it was not open development. We would sort of lob the source code out in this repository and scrape the issues off of that and put it into our internal issue tracker.
    Interesting
  28. 2 min later

  29. 0:41:24 · watch on youtube.com↗

    Our reading

    People adopted TypeScript for the tooling, not the types: an erasable type system is worth having because of the productivity the tooling built on it delivers.

    Their wordsAnd the reason they came, I think, is absolutely because of the the better tooling. And I think we were totally right there that like adding a an erasable type system and then using that to enable great tooling is really where the pro where the programmer productivity boost is realized.
    Interesting
  30. 6 min later

  31. 0:47:36 · watch on youtube.com↗

    Our reading

    A compiler that also serves an IDE has to be lazy and deferred throughout — a different way of building compilers from the one the textbooks teach.

    Their wordsAnd so everything is lazy and deferred and functional and reusable inside the compiler. And it's a very different way of writing compilers than than what the textbooks will traditionally teach you.
    Interesting
  32. 3 min later

  33. 0:50:19 · watch on youtube.com↗

    Our reading

    What makes TypeScript unlike almost every other language is gradual typing: you can have types, but you do not have to.

    Their wordsThe thing that makes it interesting, I think, and and unlike pretty much any other programming language is the gradual typing. This This notion that you can have types, but you don't have to have types.
    Interesting
  34. 2 min later

  35. 0:51:52 · watch on youtube.com↗

    Our reading

    Because its types are erased before the program runs, TypeScript can afford not to be sound: checking 99% beats the 0% JavaScript checked, and buys features a sound language cannot offer.

    Their wordsSo, if we're checking 99% instead of 100%, well, heck, that's better than the 0% that JavaScript checked, right? And it gives you like language features that no other languages can provide because they can't get to 100%.
    Interesting
  36. 5 min later

  37. 0:56:24 · watch on youtube.com↗

    Our reading

    The language best suited to AI is simply the one the models have seen most of in training, which is why they do so well on JavaScript, TypeScript and Python.

    Their wordsthat the language that's most suited for AI is the language that AI has seen the most of in its training set, right? And that's why you could argue AI does really well on JavaScript and TypeScript and Python because it's seen an awful lot of it
    Interesting
  38. 1 min later

  39. 0:57:21 · watch on youtube.com↗

    Our reading

    Forcing an AI to annotate every type would make its programs worse, not better: annotate where there is no context, and let inference do the rest.

    Their wordsbecause if you were to force AI to write a type annotation on everything, then it would probably get it wrong more often because now it has to keep track of all these types and and it and it has to just repeat itself over and over and over, right? And so, types are important where there's no context.
    Interesting
  40. 1 min later

  41. 0:58:33 · watch on youtube.com↗

    Our reading

    The internet is already past peak truth, and picking out training data worth learning from will only get harder.

    Their wordsI mean, you could argue that we we're already past peak truth on the on the on the internet, right? And now there's there's just more and more garbage every every day. It gets harder and harder to suss out the stuff that you do want to include in the training set in order to actually make something more intelligent.
    Interesting
  42. 1 min later

  43. 0:59:32 · watch on youtube.com↗

    Our reading

    Locality is what makes a language good for AI: if a single file states what it imports and what it offers, a model never has to hold the whole program at once.

    Their wordsbut but if you have good locality where you you clearly stating what you're importing and whatever and and you can analyze just a single source file and from that extract its protocol to the outside world without having to to know anything deeper. Do you do you know what I mean? I think those are important aspects just simply to reduce the size of the of the of the context window and also make it easier to summarize each module in a program, right?
    Interesting
  44. 1 min later

  45. 1:00:58 · watch on youtube.com↗

    Our reading

    An agent grepping for a name is not semantic search, and the language services an IDE already has are what AI will increasingly need.

    Their wordsAI today it's just starting to to become aware of you know the existence of of of language services and agents today like to use grep and awk and whatever you know to to find all the places where you reference a certain thing but it's not semantic search, right?
    Interesting
  46. 2 min later

  47. 1:03:11 · watch on youtube.com↗

    Our reading

    Programmers are turning into project managers of an army of junior agents, and the craft is moving from writing code to reviewing it and holding the architecture.

    Their wordsIn a sense, we're all turning into project managers, right? And and we can have an army of junior programmers called agents that will just spit out reams of code, but someone's got to have the big picture and review all of that. And so, increasingly our craft is going from one of writing the code to one of of reviewing the code and and building the architecture of the code and overseeing the work, if if you will.
    Interesting
  48. 2 min later

  49. 1:05:00 · watch on youtube.com↗

    Our reading

    Responsibility for a program lies with the programmer and never with the AI — there is nobody else to hold to account.

    Their wordsAnd ultimately also, you know, the responsibility for a program does not lie with the AI. It lies with the programmer.
    Interesting
  50. 7 min later

  51. 1:12:21 · watch on youtube.com↗

    Our reading

    A programming language is a ten-year play: version one has issues, version two fixes them, version three is finally good — and only then does adoption start.

    Their wordsBut but the thing is like doing programming languages, you come to realize it's a long play. I mean, if if you look back at the the stuff I worked on, it it it goes in 10-year cycles at least. And TypeScript didn't really, for example, or C# for that matter. I mean, it took it it takes 10 years to get to, you know, version one is great, but it has all sorts of issues, and then you got to do version two, and then it's not until version three that it really starts to be great.
    Interesting