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

preview_player
Показать описание
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! ↙️
🐲 22-23 May in Cracow
&
🧜‍♀️ 25-26 May in Warsaw

Рекомендации по теме
Комментарии
Автор

40:17 No irregularity is needed. Just banish the empty statement denoted by nothing followed by a semicolon! Make it so the only syntax for the empty statement is { }.

kazkylheku
Автор

36:56 Compilers can definitely insert a missing token like a semicolon and keep parsing. However, it would be wrong to do that without issuing a diagnostic, obviously. Trying to correct the token stream was more common in the old days when the turnaround times for compiling were very long (think: lining up to a job sumission window, where a human clerk takes your deck of punched cards, and then you collect your results 30 minutes later.) Inserting missing tokens into the code and continuing to parse can get the compiler into a loop, and can generate a long flurry of error messages. Creative Computing magazine used to have a contest whose topic was to write the shortest program (any system, any language) that generates the most error messages. "Missing semicolon" is just a guess which could be wrong. x = a() b(); Is there a missing semicolon after a()? Maybe there should be a +.

kazkylheku
Автор

35:22 GNU C++ can find C style casts in code and report them: -Wold-style-cast. I write C code that can compile as C++, and use macros for casting that use C style cast in C, but translate to C++ style casts in C++. The -Wold-style-cast warning helps to find places in the code where "naked" C style casts sneak in.

kazkylheku
Автор

I wonder what is the reason for D making parentheses optional for function calls without arguments. It seems more trouble to make functions not look like functions for the benefit of just not having to type two characters. An innocent looking expression like "x = y + z;" might actually be calling heavy functions with possible side effects if it should have actually been "x = y() + z();".

flaguser
Автор

7:13 That's perhaps understandable from a C/C++ view, but there are things that indicate something is wrong yet shouldn't stop you from trying to run the program, only from getting it past CI. Dead code for example. You could make it so that the compiler does its best to produce a program even when there are errors, but if your compiler can't do that, warnings suit the purpose just fine.

Mostly agree with what he's saying about macros, but they can still be worth the tradeof. Good talk overall.

WitherBossEntity
Автор

33:21 Why do you have to declare things before you use them? Because you said so about variables at the start of the talk. :)

kazkylheku
Автор

As for parsing C++ - GLR is to your rescue. Just parse all variants and collapse them later when you can resolve symbols and types.

Also, lexers should have stayed in the 20th century, they have no place in the modern world.

vitalyl
Автор

And yes, sadly, Walter Bright does not understand macros and DSLs at all. Macros work perfectly with debuggers, macros are very easy to integrate with IDEs, and, more, the correct use of macros make your code orders of magnitude more readable and maintainable than any puny non-meta language can ever be.

vitalyl