Bruce Tate - Things that Matter (Lambda Days 2016 )

Slides and more info: www.lambdadays.org/lambdadays2...
Languages succeed for a reason. Their designers make key decisions at the right time, in the right circumstances. In this talk, you'll learn about the key factors contributing to the success of the most important languages of our time. More critically, you'll learn to spot successful languages as they evolve, giving yourself and your company a critical advantage as you adopt new technologies.

[@hondinatos]

Precious insight, pretty informative. Thank you!

[@NormanZhou]

Very helpful, thanks

[@MegaBrownee]

Bruce is right -- syntax DOES matter. It's not just sugar, it is the REIFICATION of the underlying semantics. Imagine, among all the other things C got right, it had:
1) Treated blocks uniformly
2) Unified the syntax between blocks, structs, arrays, and initializers
3) Provided multi-value returns for functions, separating the goes-ins from the goes-outs
4) Treated function parameter lists as structs
5) Made it cleaner to pass a closure environment with a function pointers (depending on 3. for stack-only environments)
6) Treated the comma uniformly (always an operator)
7) Treated parentheses uniformly (call operator vs parameter lists vs precedence vs casting -- really all the same: tuple/struct constructor)
If C had just gotten the full generality and meaning of the {}, (), ',' and ';' right, programming would be 30 years ahead. Because if you think about it, all the uses of { } in C reflect the same underlying concept, recognized aesthetically if not implemented syntactically.
C's syntax was so darned close. But of course there's no way for 2-3 people to get all of that right in 1970, when the language is a means to an end. What's needed, despite the danger of language dialect divergence or compiler deoptimization, is the ability to mutate the language syntax to more closely reflect newly discovered or desired semantics. Communities will eventually converge, and optimizers will catch up with the most desired idioms. But one shouldn't have to wait 15 years for a clean range-for loop, or to invert iteration from passive to active to support parallel programming, or to write clean generators and coroutines, until enough consensus builds in a standards committee made up of busy experts with strong opinions and pet projects/research/corporate agendas.
So identify the desired problem space, pick the necessary semantics to solve it that are (hopefully) not contradictory, get the absolute minimal base syntax fully reflective of those semantics and not artificially limiting or contradictory (to make the compiler writers' job easier), then provide users the ability to build higher-level abstractions on top. Boom! Rapid progress.
Really, the base syntax components are extremely minimal - structs (not lists) and lambdas for the declarative part of programming, and it looks like everything else can be built from there. For the engineering/performance/security side, a fusion/equivalency/dependency syntax to capture domain knowledge necessary for compilers to elide repetitive computations, conversions, allocations, and communication while managing resources and lifecycles.
I say this very tongue in cheek - all dead simple concepts are enormously difficult to execute in their gory detail...The fewer the moving parts, the more difficult, extensive, and sublime the results. Just think of physics with F = ma or E = mc^2

[@thomasweiser5522]

Slides:
www.lambdadays.org/static/upload/media/1456310271193661test.pdf