D Day Two: Other Talk Highlights
Here’s some of what we were treated to on Day 2, before the conclusion of Walt’s “Future of D” talk, which will be another post. These are just some of my notes and thoughts. The presentation slides have been put up by Brad Roberts (who did just an awesome job organizing this first conference!) at the conference slides page.
Kirk walked through the capabilities of Pyd, from the straight-forward features (calling D code from python), to the advanced (python callbacks, subclassing in the other language, etc.). As with all the speakers, he fielded a ton of questions, and Kirk handled them particularly well — showing deep knowledge of python, D, and characteristics of various other languages and systems which have cross-bindings.
One interesting part of Kirk’s presentation was looking over at Walter Bright’s reaction — and that was of rapt attention and knowing glances between him and Andrei. Why? Because the mission of D is to make those things that can be done by the compiler, easy for the programmer. And connecting D to the universe of other languages and runtimes (Python, Perl, Ruby, .NET, JVM, etc.) is one of those essential common cases. Kirk has already had an influence on D’s compile-time reflection features, and clearly this talk got Walt thinking about more that can and should be done.
I got a chance to sit at a table with Kirk on Thursday at F.X. McRory’s. Kirk mentioned then that’s he’s down in Portland, only with a two year degree, looking for a job. I hadn’t seen the presentation yet, didn’t know what his skills were — so gave all kinds of probably simplistic advice on the value of a full degree and how to land a position. After seeing the presentation and his depth of knowledge in the Q&A period — ok, forget all that — just hire him already!
As with Kirk’s, Walt just lit up during this presentation. Here you have a domain (vector and matrix algorithms) where, in order to archive the highest possible performance, people are still using Fortran (the horror! ) and optimizing it with assembler (true horror!).
It’s the perfect opportunity for D to show its stuff, and Don has done just that.
The best line of the presentation was one where the room was having a discussion of language features to make this stuff easier. Don took a shot at Walt — “New D features keep making all my best code obsolete! I write 500 beautiful lines of code, and you go make it possible in 3″. Deadpan funny.
Debuggers are tough beasts to write. Cristian took it on himself, and has done quite an amazing job. Cristian talked much about the general case (non-D code), but also some D-specific issues, including how the DWARF symbol file format doesn’t support some D constructs, which creates some limitations (but there’s an opportunity to create standard extensions). Here are the bullets on his one “D language support” slide:
- Demangler, thanks to Thomas Kuhne
- Support for dynamic arrays
- (Some) support for associative arrays
–repurposed DW_AT_containing_type to be the
key type, and DW_AT_data_type gives the
Requires the ZERO_D_SUPPORT
environment variable to be set
Ben walked through some template tricks in D, leading up to some examples of compile-time parsing of domain-specific languages with D. D’s metaprogramming features are wonderful, yet this seemed like it had pushed the language too far (which is only a credit to Benjamin). Some of the examples could segfault the D compiler with anything other than smallish inputs. Walt and Andrei mentioned during the Q&A that the upcoming macro support would achieve some of these same goals very cleanly and concisely — better support for creating domain specific languages is coming.
Like many of the speakers, Bartosz had a fun, dry sense of humor — and brought it to what otherwise might have been a dry topic. Bartosz walked though the multi-threaded conundrum of synchronizing access to resources and avoiding deadlocks. Bartosz then made the pitch for a new set of language features to support software transactional memory, a sophisticated strategy for attacking this problem at a higher level than using traditional semaphores and locks at the application level.
When you have an interesting language with momentum — but that’s still evolving as D is — it’s a great opportunity for groups to pitch problems that are hard to solve without compiler support for their solution. STM is one of those. On the face of it, I suspect it’s not worth complicating the language to include support. But luckily, D has a single focal point for these kinds of decisions (Walt) who can be the unfriendly gatekeeper for these simplicity vs. functionality decisions. Like Linus does with Linux, saying “no” so often can be difficult, but it’s the secret sauce that will make a project like these succeed vs. its committee-designed or corporate-designed cousins.