So today I have the pleasure of talking with Anders Hejlsberg. He's one of the most influential designers of programming languages of our time.

And from Turbo Pascal to Delphi to C# to now TypeScript, your work shapes how millions of developers write code every single day.

My first exposure to computing was probably in high school, and I was fortunate enough to go to a high school that offered students access to a computer, and this is like, we're talking the late '70s here, and this was not a common thing.

And I got very interested in the programming aspect, and then I decided, uh, when, you know, these 8-bit micros were starting to come out, that I wanted to build my own kit computer.

Then I started writing a lot of software for that thing, and it turned out to be pretty good at it. And so I really enjoyed it.

Honestly, you know, I had no problem doing structured programming in assembly. And and of course you have to realize too that, I mean, with 64K of memory, there's only so much you can squeeze in, and you got to leave something over for the user too, right?

And so you could keep it all in your head, you know, back then.

Turbo Pascal kind of revolutionized the developer experience. It kind of speaks to a focus on shortening the developers, you know, loop, so to speak.

Exactly. And so I do want to hear how much of a deliberate philosophy that was from you from the beginning. Well, so first of all, the reason people really liked BASIC on those early machines was that shortened cycle, right?

I mean, now BASIC is an interpreter where you just type the code in and then you run it, and it runs.

But of course, it doesn't run very fast because you have to pay the price of an interpreter.

And the editor was kind of crappy because it was this line-based editor. And when you looked at word processing systems, they were all on-screen editors where you could cursor around and and whatever.

And that just seemed like a much better way to edit your source code. But this notion that you could just say run and then it would run, that seemed like the right way to do it.

And then so, but in order to do that and get performance with a compiler, well, you had to generate code first.

I think with Turbo Pascal, it was we we just turned it into you say run, it immediately compiles into memory.

It doesn't actually even touch the disk, and then it just runs the code in memory. And then if there's an error, it just drops you into the editor.

The compiler was real primitive. If you knew at what address the error had happened, you could sort of try to compile again, and then when a compiler actually got to that address and was writing code, and then you'd see where where was I in the source code.

Well, that's around here is where the error was, right?

And so so you got this incredibly interactive experience all of a sudden and that was pretty revolutionary.

Was it was it at all like um a bad experience for you or a frustrating experience for you, the idea of something taking an afternoon to compile?

>> Of course it was. No one no one likes it. >> No one likes waiting. You know, you you you, okay, it's like, now I've typed my code, I want to run it.

I don't want to sit around and wait for it to run.

>> Another thing about Turbo Pascal is I think it kind of democratized programming a little bit by being affordable. I know sometimes we don't start these things thinking they're going to impact an entire generation, but now that you're here and you're thinking back, there's an interesting story there.

So, the predecessor of Turbo Pascal was called Poly Pascal, and that was the Pascal compiler that I had developed within our little software company in Denmark.

And then we got in touch with the people who founded Borland.

They came back a week or two later, "This is amazing. We should get together and do a product together and sell it in the US." And then they decided they're going to sell it for $49.95.

And I was like, "Are you nuts? We'll never make any money." In retrospect, it was brilliant because yes, you charged a tenth as much, but you sold three to four orders of magnitude more copies, right?

And in the end, it was fantastic. The kudos there go to the old Borland founders and Philippe, you know, for doing that.

>> Let me ask a question that brings us closer to Delphi.

It also marked kind of like your transition from a solo creator to more of a collaborative team leader.

It's true that in the beginning I was very much a one-man show, you know, although I would work with two or three guys at the original Danish Borland office.

But obviously, that doesn't scale because, you know, the capacities of the machines started to dramatically increase and expectations were ever increasing, and you couldn't do it all yourself.

Um, and so I had to learn to become a team player, which I did throughout Turbo Pascal, but in particular with Delphi.

>> You said learn how to be a team player.

What were some things that you needed to learn? >> Well, you have to accept that things get done in a different way than you would have preferred to do them, right?

Or that the code doesn't look exactly like you would have liked it to look, right?

But still, you know, you don't have enough time to go in and fix it, so to speak. And honestly, fixing it probably wouldn't really change the behavior of the product anyway, right?

But I think you also have to learn to hand off responsibility.

You can't have a team unless people feel empowered, you know, empowered in whatever feature area they own and whatever part of the product they're building.

So there are lots of things to learn. How did your experience on kind of Visual J++ at Microsoft, how did that inform the goals for C# and the .

NET platform? >> So I came to Microsoft in, uh, towards the end of '96, uh, and I joined to work as the chief architect of Microsoft's Java development tool set.

We'd just shipped Visual J++ 1, which was basically take the C++ IDE, yank out the C++ compiler, stick in a Java compiler, and call it good, but it wasn't integrated.

It wasn't it wasn't there was no rapid application development cycle in there at all. So we set out to do that and that was what became Visual J++ 6.0.

We started aligning with the Visual Basic and Visual Studio numbering. I was always sort of like a pragmatist about it.

You know, hey, if we're going to do Java, but for the Microsoft platform for DOS and Windows, you know, I mean, we got to have great interoperability with that environment.

But Java was all about this like write once, run everywhere.

And then you had to go through only their sanctioned UI interfaces which was a least common denominator pretty crappy experience with these applets you could build and that weren't really any good, right?

We ended up adding some extensions that made native interop simpler and we built a class library of, you know, that encapsulated all of the Windows UI and it was just clearly this ain't going to work.

I mean, if we're going to do well by our customers, we got to like do something that allows us to actually build the best possible thing you can build for that environment.

People really wanted the ease of use of Visual Basic and the power and expressiveness of C++.

And so we sort of set out to create that combo and then put on top of the .NET platform, which was a platform that we could evolve to maximally take advantage of the stuff that our customers were running on.

Right. That was that was sort of what it was all about.

Yeah. You're talking about these competing crowds of customers, but you're also describing a situation with knowing that means you're building for both.

Mhm. >> That seems like more of an ecosystem looking at things holistically and I want to understand that.

>> Oh, I think it's you have to look at it all very holistically. Users don't care whether this is a language feature or a framework feature or a platform feature or an editor or debugger or whatever.

It's the whole thing is the experience, right?

And so it's all got to hang together. And so yes, we built the runtime, the JIT compiler, the garbage collector, all of that.

We designed the bytecode for the platform and we built the class library. I worked on the class libraries as well as the language and I worked with the guys that designed the runtime and I think the result is better for it.

You know, otherwise you get these silos and then everyone's like, well, I had this vision of how the problem was going to be solved and this had another vision and then I guess we need an interop layer or something or what have you, right?

And then it's just not best of breed anymore. And we also weren't afraid of interoperating with the underlying platform.

That was I think one of the things that Sun got wrong with Java, you know, was just like this dogmatic insistence that you couldn't do anything to advantage this platform or that platform.

It all had to be this least common denominator stuff, right?

And this is never going to get best of breed that way. If you're thinking back, was there a particular kind of like, aha, moment for you that made you realize that whatever growing pains for scaling JavaScript were a problem that needs to be solved and that you need to solve it, Microsoft needs to solve it.

>> Yeah. Well, this interesting thing started to happen in the industry where the runtimes were getting good enough.

Uh like Google had done excellent work on V8 and all of a sudden, you know, JavaScript code actually ran with decent performance.

HTML5 had gotten ratified and there was actually pretty great UI available now.

And all of a sudden there was this multitude of form factors like phones and iPads and whatever that didn't run Windows. And the world all of a sudden sort of discovered, you know, the real platform game isn't Java.

It's actually JavaScript and the browser and HTML. And then they started writing bigger and bigger and bigger apps because these new runtimes and UI technologies allowed the apps to get big.

But then everyone started discovering how insanely hard that is to do in a dynamic programming language with no good tooling, right?

And so we were seeing the strangest contortions starting to happen.

And one in particular that was when the outlook.com team came to us in .

NET and Clay actually in C# mostly and asked whether we get involved in productizing this thing they had called Script# and I'm like, Script#, what's Script#?

Well, it's this thing that allows you to write in C# and then it translates that into JavaScript and then that's what you run.

And I'm like, well, why on earth would you ever want to do that?

It seems to me like the worst of both worlds, right? Well, it turns out the reason you want to do that is then you can get grown-up tooling.

Then you can actually have a type checker. You can have a team. You can write interfaces.

You can describe how these pieces of the software are going to talk to each other. And that's what we're doing, you know, because we have hundreds if not thousands of programmers that are going to work on this and they can't just like write JavaScript and and and not have something that can check the code and no tooling and no statement completion refactorings or any of that stuff, right?

And I was like, wow, is it really, is JavaScript really that broken, you know?

And and is that really the best thing we could do to fix it, right?

I mean, like tell people to write in a different language and then sort of treat JavaScript as an IR that you or bytecode that you compile to.

Surely we could do better. What what could we fix JavaScript so there were some really interesting things that became possible if you think about it that way, right?

And so so then we started exploring that and you know that it's worked out pretty well.

[laughter] >> The decision to make TypeScript kind of like a strict superset of JavaScript has, you know, had some strategic thinking into it.

How did you champion it and what advice does that, you know, allow you to give to others about this idea of meet developers where they are?

>> It's funny because whenever people come to me and go, oh, I have the, I'm thinking of creating this new programming language that's going to do this and that and fantastic thing.

I'm like, my first my first advice is the world needs another programming language like it needs another hole in the head.

Second, if you decide to do a programming language, realize that 90% of what you're going to do is the same thing that every other programming language has to do.

And that percentage just keeps going up. Like the barrier to entry just keeps getting bigger and bigger and bigger, right?

The expectations of programmers today, it's not enough just to have a compiler. You also have to have a language service that integrates into pretty much every IDE that's out there.

Now, you also have to have LSP servers that can talk to AI and what have you.

You you have to have debuggers, you have to have profilers, you have to I mean, oh my God, the list just goes on and on.

And then you got to like have probably 10 years of time because that's how long it takes for something to actually get a foothold, to get to meaningful usage numbers, right?

No one wants a brand new programming language right out of the gate. And so you're going to be starving for five years at least, you know, with with with not enough users and, "Hey, do we really want to keep funding this?

Do we really?" It's a tough business. But by extending JavaScript, in a sense, we were saying, "We're not going to create a whole new language here." That's that's pre that's precisely what what they were advocating with Script# , right?

It's like, no, we're just going to fix what's broken about it. Our language service in Visual Studio Code, it's the same for TypeScript and JavaScript.

So JavaScript to us is just TypeScript without type annotations, or maybe you're using JSDoc annotations instead or whatever.

But you know, it's the same investment. So it's not like we're building two different things. We're building one thing, and we're building only exactly what we need to build, right, in order to just make the ecosystem better.

Launching TypeScript as an open-source project on GitHub in 2012.

That was a radical move, we could say, for Microsoft at the time. I'd say we had a pretty good understanding of how that JavaScript ecosystem functioned and what the ethos was and what it required to actually engage with that community.

The history of C# and TypeScript with Anders Hejlsberg | GitHub

GitHub is the AI-powered developer platform to build, scale, and deliver secure software. We make it easier for developers to be developers: to work together, to solve challenging problems, and to create the world’s most important technologies. We foster a collaborative community that can come together—as individuals and in teams—to create the future of software and make a difference in the world.

The GitHub platform is where developers can create, share, and ship the best code possible. Our community is made up of students, hobbyists, consultants, enterprise professionals, partners, and executives, building software in the way that works best for them.

GitHub is much more than code. It is the home of open-source collaboration. It is where new developers get started and where experienced developers expand their knowledge. It is a community where developers come together to solve the unsolvable and test the limits of what software can do.


GitHub

Anders Hejlsberg는 Turbo Pascal, Delphi, C#, TypeScript 등 여러 영향력 있는 프로그래밍 언어를 설계했으며, 개발자 경험 개선과 빠른 개발 주기를 위한 철학을 강조했습니다.

그는 대규모 팀에서 효과적으로 협업하는 방법과 초기 Microsoft의 Java 개발 경험이 C# 및 .NET 플랫폼의 '사용 용이성과 강력함의 결합' 목표에 영향을 미쳤다고 설명했습니다.

TypeScript는 JavaScript의 확장으로, 기존 JavaScript 생태계와 도구를 활용하며 AI 시대에도 강점을 가집니다. 프로젝트는 GitHub로 이전 후 커뮤니티와의 개방적인 개발 프로세스를 통해 성공적으로 성장했으며, Go로의 컴파일러 포팅은 성능 향상을 위한 전략적 선택이었습니다.

Anders Hejlsberg: 프로그래밍 언어의 혁신가

Anders Hejlsberg는 Turbo Pascal에서 Delphi, C#, 그리고 현재 TypeScript에 이르기까지 **수백만 명의 개발자가 코드를 작성하는 방식을 형성**한 우리 시대의 가장 영향력 있는 프로그래밍 언어 설계자 중 한 명입니다.

그는 고등학교 시절 8비트 마이크로컴퓨터를 직접 만들고 어셈블리어로 소프트웨어를 작성하며 프로그래밍에 대한 깊은 흥미를 발견했습니다. 당시 **64K 메모리 환경에서 모든 것을 머릿속에 담아두며 효율적으로 작업**했습니다.

Turbo Pascal은 개발자 경험, 특히 개발자 루프를 단축하는 데 집중하여 혁명을 일으켰습니다. BASIC과 같은 인터프리터의 즉각적인 실행 장점을 유지하면서도, 컴파일러의 성능을 제공하기 위해 **빠른 컴파일러와 통합 개발 환경을 구현**했습니다.

특히, 코드를 입력하고 실행 버튼을 누르면 즉시 메모리로 컴파일되어 실행되고, 오류 발생 시 곧바로 편집기로 이동하는 기능은 당시로서는 **매우 상호작용적인 경험으로 혁신적**이었습니다. 이는 개발자들이 오랜 컴파일 시간을 기다리는 것에 대한 좌절감을 해소해주었습니다.

Turbo Pascal은 또한 49.95달러라는 저렴한 가격으로 프로그래밍을 민주화하는 데 기여했습니다. Borland의 설립자들은 초기 우려에도 불구하고 **저렴한 가격으로 훨씬 더 많은 판매를 기록**하며 결국 환상적인 성공을 거두었습니다.

솔로 창작자에서 팀 리더로: Delphi와 함께한 성장

Delphi 프로젝트는 Hejlsberg에게 **솔로 창작자에서 협업적인 팀 리더로의 전환**을 의미했습니다. 기계 성능 향상과 기대치 증가로 혼자서는 모든 것을 할 수 없게 되면서 팀 플레이어가 되는 법을 배워야 했습니다.

팀 리더로서 그는 일이 자신이 선호하는 방식과 다르거나 코드가 자신이 원하는 모습과 정확히 일치하지 않아도 받아들이는 법을 배웠습니다. 또한, **책임을 위임하고 팀원들이 권한을 부여받았다고 느끼게 하는 것이 중요함**을 깨달았습니다.

Microsoft에서의 경험: Visual J++와 C#

Microsoft에서 Visual J++ 개발을 이끌면서, 그는 **고객이 실행하는 환경을 최대한 활용할 수 있는 플랫폼을 구축하는 것의 중요성**을 깨달았습니다. Java의 '한 번 작성하면 어디서든 실행된다'는 철학이 최소 공통 분모의 형편없는 경험을 초래한다는 점을 지적했습니다.

Visual Basic의 사용 편의성과 C++의 강력함을 결합하려는 열망은 .NET 플랫폼과 C#의 탄생으로 이어졌습니다. 이는 **언어 기능, 프레임워크, 플랫폼, 편집기, 디버거 등 모든 요소가 함께 어우러지는 전체적인 경험**을 제공하려는 노력이었습니다.

그는 언어뿐만 아니라 클래스 라이브러리 및 런타임 설계에도 적극적으로 참여했습니다. 이러한 **전체적인 접근 방식은 사일로 현상을 방지하고, 기본 플랫폼과의 상호 운용성을 강화**하여 더 나은 결과물을 만들 수 있었다고 강조했습니다.

TypeScript의 탄생: JavaScript의 문제점 해결

TypeScript의 필요성은 JavaScript 생태계의 성장과 함께 등장했습니다. V8 엔진의 성능 향상과 HTML5의 등장으로 JavaScript 앱이 커지면서, **훌륭한 도구가 없는 동적 언어로 대규모 앱을 만드는 어려움**이 부각되었습니다.

Outlook.com 팀이 C#으로 작성한 코드를 JavaScript로 변환하는 'Script#'을 사용하려는 사례를 보고, Hejlsberg는 **JavaScript의 문제점과 성숙한 도구의 필요성**을 절감했습니다. 타입 검사, 팀 협업, 인터페이스 작성을 위한 도구의 부재가 JavaScript의 가장 큰 문제였습니다.

TypeScript는 JavaScript를 완전히 새로운 언어로 대체하는 대신, **기존 JavaScript의 '망가진 부분'을 고치고 확장하는 접근 방식**을 취했습니다. 이는 개발자들이 이미 익숙한 JavaScript 생태계에 새로운 진입 장벽을 만들지 않고도 타입 안정성과 향상된 개발 도구를 제공하기 위함이었습니다.

오픈 소스 여정: CodePlex에서 GitHub로

2012년 Microsoft는 TypeScript를 오픈 소스 프로젝트로 론칭했는데, 이는 당시로서는 과감한 행보였습니다. JavaScript 생태계의 특성과 커뮤니티와의 소통 방식을 이해했기 때문에, **오픈 소스 공개가 프로젝트 성공의 필수 조건**임을 인지했습니다.

초기에는 Microsoft의 CodePlex에서 출시되었으나, 2년 동안은 사실상 소스 코드만 공개하는 수준이었습니다. **오픈 소스에 대한 Microsoft의 신뢰도가 낮았고, 내부 프로세스에 의존하는 방식** 때문에 프로젝트는 잠잠했습니다.

2014년 GitHub로 이전하면서 상황은 완전히 달라졌습니다. TypeScript 팀은 **외부 기여자들과 완전히 동일한 개방형 개발 프로세스에 참여**하기 시작했고, 모든 기능 개발과 이슈 추적이 공개적으로 이루어졌습니다. 이때부터 프로젝트가 비로소 이륙하기 시작했습니다.

오픈 개발 프로세스로의 전환은 모두에게 윈-윈이었습니다. 사용자와 고객은 '소시지가 만들어지는 과정'을 볼 수 있었고, **개발자들은 커뮤니티의 참여와 감사를 매일 보며 엄청난 만족감**을 느꼈습니다. 커뮤니티의 투표를 통해 가장 원하는 기능을 식별하고 우선순위를 정할 수 있게 되어 개발 과정의 효율성과 만족도가 크게 향상되었습니다.

TypeScript 컴파일러의 Go 포팅: 성능과 유지보수

TypeScript는 처음부터 자체 호스팅되었지만, 프로젝트 규모가 커지고 채택률이 높아지면서 **JavaScript의 단일 스레드 모델과 객체 모델의 비효율성**으로 인한 확장성 문제가 불거졌습니다. 이는 컴퓨팅 성능의 90% 이상을 활용하지 못하고, 실행 비용이 많이 드는 문제로 이어졌습니다.

2014년 여름, 팀은 Go로 스캐너와 파서의 프로토타입을 제작하기 시작했습니다. 그 결과 **네이티브 코드로 얻을 수 있는 10배의 성능 향상과 공유 메모리 동시성 활용**의 이점을 빠르게 확인했습니다. 이러한 엄청난 성능 향상은 Go로의 포팅을 결정하는 주요 동기가 되었습니다.

커뮤니티의 일부에서는 완전히 새로운 컴파일러를 Rust와 같은 언어로 다시 작성하기를 원했지만, 팀은 기존 타입 검사기의 복잡성과 정확한 의미론적 동작을 유지하기 위해 **함수별로 동일한 코드를 Go로 포팅**하는 방식을 선택했습니다. Rust는 순환 데이터 구조와 자동 가비지 컬렉션의 부재로 제외되었고, Go는 JavaScript와 유사한 특성으로 인해 최적의 선택이었습니다.

결과적으로 새로운 Go 기반 컴파일러는 **이전 JavaScript 컴파일러와 버그까지 똑같으면서 10배 더 빠른 성능**을 제공하게 되었습니다. 이는 커뮤니티가 기존의 모든 것을 버릴 필요 없이 성능 향상을 누릴 수 있게 함으로써 큰 호응을 얻을 것으로 예상됩니다.

AI 시대의 프로그래밍 언어와 TypeScript의 미래

Hejlsberg는 AI 시대에 **AI를 대상으로 하는 완벽한 프로그래밍 언어는 AI가 학습할 데이터가 없기 때문에 최악의 언어가 될 것**이라고 주장합니다. AI의 코딩 능력은 AI가 접한 코드의 양에 비례하므로, JavaScript, Python, TypeScript처럼 많이 사용되는 언어가 AI에 가장 적합합니다.

AI 기술은 제품 개발 방식, 특히 지루하고 반복적인 작업을 자동화하는 데 큰 영향을 미치고 있습니다. TypeScript 팀은 Go 포팅 과정에서 AI를 사용하여 수백 개의 풀 요청을 이전하는 등의 작업을 성공적으로 수행했습니다. **AI는 대규모 코드 포팅보다는 포팅을 돕는 프로그램을 생성하는 데 더 효과적**일 수 있습니다.

언어 서비스 측면에서 AI는 구문 완성, 코드 탐색, 리팩토링, 빠른 수정 등 많은 작업을 훨씬 더 잘 수행할 수 있습니다. 따라서 TypeScript의 언어 서비스는 **AI 기반의 새로운 세계에 맞춰 극적으로 적응**하고 있으며, 이는 10년 전 AI가 없던 시절에 만들어진 방식과는 매우 다르게 전개될 것입니다.

AI는 코딩 과정에서 **수고스러운 부분을 제거하고, 지루하고 재미없지만 비용이 드는 관리 작업을 자동화**하는 데 도움이 될 것입니다. 이는 프로그래밍의 본질을 변화시키고 있으며, 모든 개발자가 AI를 활용하여 효율성을 높여야 할 중요한 교훈입니다.

미래를 내다보면, TypeScript는 JavaScript와 마찬가지로 표준화 프로세스를 통해 진화하며, 그 위에 필요한 타입 시스템 기능을 추가할 것입니다. 그러나 도구 측면에서는 큰 변화가 예상됩니다. AI의 발전으로 **IDE 중심에서 AI가 작업을 수행하고 사용자가 감독하는 방식으로 전환**될 것이며, 이는 개발 도구를 획기적으로 바꿀 것입니다.

오픈 소스의 지속 가능성과 프로그래밍 언어의 가치

Hejlsberg는 오픈 소스의 지속 가능성에 대한 우려를 표명합니다. 오픈 소스는 모든 것을 무료로 제공하지만, 결국 **상업 기업이나 누군가가 자금을 지원해야 운영이 가능**합니다. 커뮤니티는 아직 기여자에 대한 보상 모델을 제대로 찾지 못했습니다.

그는 Rust와 Go 같은 다른 프로그래밍 언어에 대한 깊은 존경심을 표합니다. Rust는 메모리 관리에 대한 노력, Go는 메모리 및 타입 안전성을 갖춘 C와 같은 개념에 감탄합니다. 모든 언어 설계자는 **'거인의 어깨 위에 서서' 다른 언어에서 배우고 빌려오는 것이 중요**하다고 강조합니다.

GitHub와 같은 협업 플랫폼 중심의 소프트웨어 개발 환경은 미래에 대한 낙관적인 시각을 제공합니다. 오픈 소스는 자금 조달 방식에 대한 명확한 해결책이 없음에도 불구하고 **계속해서 성장하고 있으며, 점점 더 많은 지식과 능력을 담고 있습니다.** 이 개방적인 개발 문화는 진화와 검색 가능한 역사적 기록을 제공하여 엄청난 가치를 창출하고 있습니다.

Anders Hejlsberg는 Turbo Pascal 개발 당시의 개발자 경험과 관련하여 어떤 철학을 가지고 있었으며, 이것이 어떻게 프로그래밍 언어의 발전에 기여했다고 생각하시나요?

Anders Hejlsberg는 Visual J++ 경험이 C# 및 .NET 플랫폼 설계 목표에 어떤 영향을 미쳤다고 설명하며, '전체적인 관점'의 중요성을 강조한 이유는 무엇인가요?

TypeScript를 JavaScript의 엄격한 상위 집합으로 만들기로 한 결정 뒤에 숨겨진 전략적 사고는 무엇이며, Anders Hejlsberg는 이를 어떻게 옹호하고 있나요?

TypeScript 컴파일러를 Go로 포팅하기로 결정한 주요 동기는 무엇이며, 이 과정에서 어떤 어려움과 장점이 있었다고 설명하나요?

Anders Hejlsberg는 AI 지원 코딩이 프로그래밍 언어 및 도구 설계의 미래를 어떻게 변화시킬 것이라고 예측하며, TypeScript가 AI 워크플로에 특히 적합하다고 생각하는 이유는 무엇인가요?

오늘 저는 Anders Hejlsberg와 이야기를 나누게 되어 기쁩니다. 그는 우리 시대에 가장 영향력 있는 프로그래밍 언어 설계자 중 한 명입니다.

Turbo Pascal에서 Delphi, C#, 그리고 현재 TypeScript에 이르기까지, 당신의 작업은 수백만 명의 개발자가 매일 코드를 작성하는 방식을 형성하고 있습니다.

제가 처음 컴퓨터를 접한 것은 고등학교 때였을 거예요. 운 좋게도 학생들이 컴퓨터를 사용할 수 있는 고등학교에 다녔는데, 70년대 후반이었으니 흔한 일은 아니었죠.

프로그래밍에 매우 관심이 많았고, 8비트 마이크로컴퓨터가 나오기 시작했을 때, 직접 키트 컴퓨터를 만들어야겠다고 결심했죠.

그러고 나서 저는 그 컴퓨터를 위한 소프트웨어를 많이 작성하기 시작했고, 꽤 잘 해냈어요. 정말 즐거웠습니다.

솔직히 말해서, 어셈블리어로 구조적 프로그래밍을 하는 데 아무런 문제가 없었습니다. 그리고 물론 64K 메모리로는 많은 것을 넣을 수 없고, 사용자를 위해 남겨둬야 한다는 것도 아셔야 합니다.

그래서 당시에는 모든 것을 머릿속에 담아둘 수 있었죠.

Turbo Pascal은 개발자 경험에 혁명을 일으켰습니다. 개발자 루프를 단축하는 데 집중했다고 할 수 있죠.

맞습니다. 처음부터 얼마나 의도적인 철학이었는지 듣고 싶습니다. 우선, 초기 컴퓨터에서 사람들이 BASIC을 좋아했던 이유는 바로 그 짧은 주기에 있었죠?

BASIC은 코드를 입력하고 실행하면 바로 실행되는 인터프리터니까요.

하지만 인터프리터 비용을 지불해야 하기 때문에 속도가 빠르지는 않죠.

그리고 편집기는 라인 기반 편집기라서 엉망이었죠. 워드 프로세싱 시스템을 보면 커서를 움직일 수 있는 화면 편집기였잖아요.

그게 소스 코드를 편집하는 훨씬 더 나은 방법인 것 같았습니다. 하지만 실행이라고 말하면 바로 실행되는 개념이 올바른 방법인 것 같았죠.

컴파일러로 성능을 얻으려면 코드를 먼저 생성해야 했습니다.

그래서 빠른 컴파일러가 필요했습니다.

Turbo Pascal의 경우, 실행을 누르면 즉시 메모리로 컴파일되었습니다.

실제로 디스크를 건드리지 않고 메모리에서 코드를 실행합니다. 그리고 오류가 발생하면 편집기로 바로 이동합니다.

컴파일러는 매우 원시적이었습니다. 오류가 발생한 주소를 알고 있다면 다시 컴파일을 시도할 수 있었고, 컴파일러가 실제로 해당 주소에 도달하여 코드를 작성할 때 소스 코드에서 어디에 있었는지 확인할 수 있었습니다.

음, 여기가 오류가 발생한 곳이었죠?

그래서 갑자기 매우 상호작용적인 경험을 하게 되었고, 그것은 꽤 혁신적이었습니다.

오후 내내 컴파일하는 것에 대한 생각이 당신에게 나쁜 경험이나 좌절스러운 경험이었나요?

>> 물론 그랬습니다. 아무도 그걸 좋아하지 않아요. >> 아무도 기다리는 것을 좋아하지 않아요. 코드를 입력했으니 이제 실행하고 싶잖아요.

앉아서 실행될 때까지 기다리고 싶지 않아요.

>> Turbo Pascal의 또 다른 점은 저렴한 가격으로 프로그래밍을 약간 민주화했다고 생각합니다. 때로는 이것이 전체 세대에 영향을 미칠 것이라고 생각하지 않고 시작하지만, 지금 여기에 와서 되돌아보면 흥미로운 이야기가 있습니다.

Turbo Pascal의 전신은 Poly Pascal이라고 불렸는데, 그것은 제가 덴마크에 있는 작은 소프트웨어 회사에서 개발한 Pascal 컴파일러였습니다.

그리고 Borland를 설립한 사람들과 연락이 닿았습니다.

그들은 1~2주 후에 돌아와서 "이것은 놀랍습니다. 함께 제품을 만들어 미국에서 판매해야 합니다."라고 말했고, 그들은 49.95달러에 판매하기로 결정했습니다.

그래서 저는 "미쳤어요? 우리는 절대 돈을 벌 수 없을 거예요."라고 말했습니다. 돌이켜보면 그것은 훌륭했습니다. 왜냐하면 1/10 가격으로 판매했지만 3~4배 더 많은 복사본을 판매했기 때문입니다.

결국에는 환상적이었습니다. 거기에 대한 공로는 Borland의 설립자들과 Philippe에게 돌아갑니다.

>> Delphi에 더 가까워지는 질문을 하겠습니다.

그것은 또한 당신의 솔로 창작자에서 협업적인 팀 리더로의 전환을 의미하기도 했습니다.

초창기에는 저 혼자 거의 모든 일을 처리했지만, 원래 덴마크 볼랜드 사무실에서 두세 명의 동료와 함께 일하곤 했습니다.

하지만 아시다시피, 기계의 성능이 극적으로 향상되고 기대치가 계속 높아지면서 혼자서는 모든 것을 할 수 없게 되었기 때문에 확장하기가 어려웠습니다.

그래서 저는 팀 플레이어가 되는 법을 배워야 했고, 터보 파스칼을 통해, 특히 델파이를 통해 그렇게 했습니다.

>> 팀 플레이어가 되는 법을 배웠다고 하셨는데, 어떤 점들을 배워야 했나요?

>> 글쎄요, 자신이 선호하는 방식과는 다른 방식으로 일이 처리된다는 것을 받아들여야 합니다, 그렇죠?

또는 코드가 자신이 원하는 모습과 정확히 일치하지 않을 수도 있습니다, 그렇죠?

하지만 여전히, 수정할 시간이 충분하지 않습니다. 그리고 솔직히 말해서, 수정한다고 해서 제품의 동작이 크게 바뀌지는 않을 겁니다, 그렇죠?

하지만 책임을 넘겨주는 법도 배워야 한다고 생각합니다.

사람들이 자신이 맡은 기능 영역과 제품의 일부를 구축하는 데 있어서 권한을 부여받았다고 느끼지 못하면 팀을 만들 수 없습니다.

배워야 할 것들이 많습니다. 마이크로소프트에서 Visual J++ 경험은 C# 및 .NET 플랫폼의 목표에 어떤 영향을 미쳤습니까?

>> 저는 96년 말쯤에 마이크로소프트에 합류하여 마이크로소프트의 자바 개발 도구 세트의 수석 설계자로 일하게 되었습니다.

Visual J++ 1을 출시했는데, 기본적으로 C++ IDE에서 C++ 컴파일러를 제거하고 자바 컴파일러를 넣어서 좋다고 말했지만 통합되지는 않았습니다.

빠른 애플리케이션 개발 주기가 전혀 없었습니다. 그래서 우리는 그것을 하기 시작했고 그것이 Visual J++ 6.0이 되었습니다.

Visual Basic 및 Visual Studio 번호 매기기와 일치시키기 시작했습니다. 저는 항상 그것에 대해 실용주의자 같은 사람이었습니다.

아시다시피, 만약 우리가 DOS 및 Windows용 마이크로소프트 플랫폼용 자바를 하려고 한다면, 그 환경과의 훌륭한 상호 운용성이 있어야 합니다.

하지만 Java는 이처럼 '한 번 작성하면 어디서든 실행된다'는 것이 전부였습니다.

그런 다음 그들이 승인한 UI 인터페이스만 거쳐야 했는데, 이는 최소 공통 분모로 꽤 형편없는 경험이었습니다. 만들 수 있는 이 애플릿으로는 그다지 좋은 결과를 얻을 수 없었죠, 그렇죠?

결국 기본 interop을 더 간단하게 만드는 몇 가지 확장을 추가하고 Windows UI를 캡슐화한 클래스 라이브러리를 구축했는데, 이는 분명히 효과가 없을 것이었습니다.

내 말은, 고객에게 제대로 하려면 해당 환경에 맞게 만들 수 있는 최고의 것을 실제로 만들 수 있도록 해야 한다는 것입니다.

사람들은 Visual Basic의 사용 편의성과 C++의 강력함과 표현력을 정말로 원했습니다.

그래서 우리는 그러한 조합을 만들고 .NET 플랫폼 위에 올려놓기로 했습니다. .NET 플랫폼은 고객이 실행하는 것을 최대한 활용하기 위해 발전시킬 수 있는 플랫폼이었습니다.

네. 경쟁하는 고객 집단에 대해 이야기하고 있지만, 그것이 의미하는 바를 아는 상황에 대해서도 설명하고 있습니다. 즉, 둘 다를 위해 구축하고 있다는 것이죠.

음. >> 그것은 사물을 전체적으로 바라보는 더 많은 생태계처럼 보이며, 그것을 이해하고 싶습니다.

The history of C# and TypeScript with Anders Hejlsberg | GitHub

스크립트