https://news.ycombinator.com/item?id=19568378
https://www.youtube.com/watch?v=csL8DLXGNlU
I posted these Anders Hejlsberg quotes, who co-designed TypeScript, C#, Delphi, Turbo Pascal, etc:
https://news.ycombinator.com/item?id=19568378
>"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
>"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
>Andrew Hejlsberg:
>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.
>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.
>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.
>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.
>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.
>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.
And these Larry Wall and James Gosling and Guido van Rossum quotes:
>James Gosling wants to punch the "Real Men Use VI" people. "I think IDEs make language developers lazy." -Larry Wall
>"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling
>"In the Java universe, pretty much everybody is really disciplined. It's kind of like mountain climbing. You don't dare get sloppy with your gear when you're mountain climbing, because it has a clear price." -James Gosling
>"I have a feature that I am sort of jealous of because it's appearing in more and more other languages: pattern matching. And I cannot come up with the right keyword, because all the interesting keywords are already very popular method names for other forms of pattern matching." -Guido van Rossum
Also:
https://news.ycombinator.com/item?id=19568860
DonHopkins 10 months ago [-]
>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.
>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.
>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)