Skip to content
0:00 / 0:00

#d#c++#compilers

Code Europe 2022 Keynote by Walter Bright "Programming Language Ideas That Work And Don't Work"

Code Europe

1.7K subscribers • 1 video on Hallway

YouTube
  • Recommended by 2 people: 1 on Lobsters and 1 in engineering communities.
  • Presented by Walter Bright, creator of the D programming language
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

7K views3 years ago2 recommendations

Programming languagesLanguage design and type systems

Walter Bright shares insights from designing and implementing compilers for D, C++, and other languages, discussing which language features succeed and which fail.

Walter Bright - most famously the creator of D programming language at Code Europe 2022 in Cracow! "Programming language ideas are a dime a dozen. I'm sure you have your favourite. "Why don't they implement X?". Some are obvious, some are obvious in retrospect, some obvious ideas turn out surprisingly to be very wrong, and some unexpected ideas turn out famously. I've designed two programming languages, ABEL and D. I've implemented compilers for them, along with C, C++, Javascript, and D. I've done the tech support for them. I hear a lot about what works and doesn't from the trenches. I'm sure you'll disagree with a number of my conclusions, but that's what makes it fun!" Excited for more from the very BEST in IT? Get your Code Europe 2023 Tech Festival tickets now! ↙️ 🦖 codeeurope.pl/en/buy-ticket 🐲 22-23 May in Cracow & 🧜‍♀️ 25-26 May in Warsaw Join us as the Partner! 🤝 codeeurope.pl/en/become-a-partner

Why it's here

2 people recommend this

Moments people linked to

u/fredoverflowin r/ProgrammingLanguages • Recommends

Walter Bright: Programming Language Ideas That Work And Don't Work

dbremneron Lobsters • Recommends

Programming Language Ideas That Work And Don't Work (2022)

u/ericbbin r/ProgrammingLanguages • Mentions

On “Walter Bright: Programming Language Ideas That Work And Don't Work”

I think the comment at 4:03 about having to give up the ability to "define their own operator tokens" assumes that the output of the parser has to have a certain structure. My language allows you to "define your own operator tokens" even though I have separate scanning and parsing phases that don't use symbol tables. The parser just produces a syntax tree where operator expressions still need more analysis than they traditionally would at that point.
5View on Reddit

u/nunzariusin r/ProgrammingLanguages • Mentions

On “Can a language be too dense?”

Walter Bright, author of D lang, contends that redundant syntax is very important for improving parsing error messages ([video @ 36:42). This seems to be an under studied aspect of programming languages but it is worth keeping in mind as you develop the language syntax. I'm skeptical that you actually need semicolons for good error messages but the ML syntax definitely has a few places where there isn't enough redundancy which results in unhelpful parse errors.