BCS: > The video is up: > http://www.youtube.com/watch?v=RlVpPstLPEc
Thank you for the link and thank you to Andrei for the very nice talk. I think the link can be put on Reddit too, if not already present. When Andrei talks he seems a little different from the Andrei that writes in this newsgroup. The talk was quite interactive, and the idea of giving away books for good questions was a good one. The people in the room seem to know how to program. At 8.56: The video says that D builds structure on the C memory model. Years ago C99 has essentially replaced alloca() with something structurally equal but nicer and more type-safe, the Variable Length Arrays, that I prefer over D alloca(). At 14.00: I did know nothing about the number of times a C++ compiler looks at code chars :-) At 14.42: You compare the performance of a D compiler with the performance of a C++ compiler. But Delphi compiler was/is very fast (and probably the FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal) code to compile. I think on average it takes only two thousand clock ticks to compile one line of ObjectPascal code. It sounds a lot, but it means that with a modern single-core CPU you can produce your binary file from a one million ObjectPascal lines long program in less than two seconds. ObjectPascal type system looks a bit simpler than D one (despite it has OOP, generics, modules, inline asm, dynamic strings, records, all basic D types, etc), so this isn't a fully apple-to-apple comparison. 27.50, "transactional file copy": this example was script-like, and as short as possible to fit into one single slide, so in this case I think using enforce() is OK. But in true programs I suggest all D programmers to use DesignByContract with assert() more and to use enforce() less. Among other things enforce() kills inlining possibilities and inflates code. In D.learn I have seen people use enforce() in a situation where DbC is designed for. I think the D community needs to learn a bit more DbC, and in my opinion to do this the leaders have to lead the way. 42.00: I don't know what Big-O() encapsulation is. I think later you explain it a bit more, but I have lost the meaning. 53.00, slide 26: regarding sealed containers: I like the idea of an Hierarchical Allocator for C: http://swapped.cc/halloc/ The idea is simple, when you call a malloc-like function you put the pieces of memory in a hierarchy. And later with a single function call you can free a whole linked list, or a whole data structure that can contain a linked list and and two arrays, or the whole memory allocated by all the data structures used in a whole section of your program. In my opinion this is cool in C. In D with sealed containers you may be able to do something similar. 55.14: Very nice slide :-) In my dlibs1 the Levenshtein distance function is implemented for random accessible inputs only, so it doesn't work correctly with UTF8/UTF16. On an 7-bit ASCII it's probably faster than the Phobos2 one because it is heavily optimized. When the input arrays are small (like two small strings) it uses alloca() to allocate on the stack the array needed by the dynamic programming algorithm, because in my code I often call Levenshtein on small strings and I have seen for this code stack allocation increases performance significantly (another design option that here I have not used is to optionally use heap memory allocated outside the Levenshtein function, as often Tango functions do). 57.36: The Wikipedia Levenshtein entry can be improved a bit, to remove the random access requirement, if not already done :-) Often in practice you have to pay a certain performance price for genericity. So an interesting question is, with the current DMD compiler how much slower than an array-based Levenshtein function is the generic Phobos one when the input is for example a couple of ubyte arrays? If it's only about two or three times slower then it's probably good enough. 1.12.50: Your explanation of the difference between a compiler optimization and an properly defined language feature was nice :-) 1.14.57: I think you have missed to explain the @trusted too that joins the safe and unsafe worlds (in a precedent moment in the talk you have not talked about __gshared, but seems more acceptable). 1.16.04, the question about future success of D: This is not an easy question. Probably the Next Big Language will be JavaScript, that probably will be used in really many situations. Java will probably keep being used a lot in commercial settings, even if only as legacy language. A language that I think has a good chance to become widely used in numerical scientific computations is Chapel, that so far the D community seems to have ignored (I have seen only Bartosz Milewski write about it a bit), despite my repeated attempts to put it in evidence, because I think it contains several very good ideas that are essentially ignored in D. Regarding D2, a problem is of course that D is mostly a system language and the ecological niche for system languages is small and probably will keep being small. Today languages for the Web become way more widespread (and here I have see no enthusiasm in the idea of using D on the Google NaCl platform, to use it on the Web). A language as C#4 is! very good in both commercial applications (often database-centric, where LINQ helps a lot) and it can be used to write many desktop/generic applications too, thanks to its IDE, its wide standard library and the possibility to use other languages (like IronPython, F# etc) to create normal dlls that can be used as the C# ones (Mono too helps). Eventually a version of D2 for the CLI platform will partially solve this problem. Young programmers grow up used to program in JavaScript/Python/PHP and see as more and more alien some lower-level knowledge that is almost necessary to program _efficiently_ in D. D also gives you almost all you can find in the pure Java language, but my experience shows me that if you program in D as you program in Java your programs often come out too much slower than the Java ones (often just because of the D GC), so D is not a drop-in replacement for Java: in D you don't have a powerfully optimizing virtual machine under the language that catches an! d optimizes away a very large number of "efficiency bugs" of your Java code, you have to actually write good D code if you want efficient D programs. In the time has taken me to see and comment the video the number of people that have seen it has gone from 3 to 322. This is a lot in a short time. Bye and thank you for the ride, bearophile
