andralex

D also supports POSIX positional arguments: https://dlang.org/library/std/format/formatted_write.html

Thanks! I tried that too, but it's slower than Lomuto. Forgot to mention in the article.

This. Thanks!

(Author here.) That is incorrect. The difficult case is and the real benchmark is with unpredictable data. The low-entropy cases will be about as fast with both partitioning schemes.

This is only a smart part of the benchmarks I've run because I wanted to drive one point home within a limited space. I've run many tests on various data types and shapes, and Lomuto does better than Hoare on most. (E.g. its improvement on double is even larger than on integrals.)

Would love a sequel!

Speaker here. Slides at https://erdani.com/dconf2017-slides.pdf. Ask me anything!

Abstract: Over the years, a few programming paradigms have been successful enough to enter the casual vocabulary of software engineers: procedural, imperative, object-oriented, functional, generic, declarative. There's a B-list, too, that includes paradigms such as logic, constraint-oriented, and symbolic.

The point is, there aren't very many of them altogether. Easy to imagine, then, the immensely humbling pressure one must feel when stumbling upon a way to think about writing code that is at the same time explosively productive and firmly removed from any of the paradigms considered canon.

This talk shares early experience with Design by Introspection, a proposed programming paradigm that has enough demonstrable results to be worth sharing. The tenets of Design by Introspection are:

* The rule of optionality: Component primitives are almost entirely opt-in. A given component is required to implement only a modicum of primitives, and all others are optional. The component is free to implement any subset of the optional primitives.

* The rule of introspection: A component user employs introspection on the component to implement its own functionality using the primitives offered by the component.

* The rule of elastic composition: a component obtained by composing several other components offers capabilities in proportion with the capabilities offered by its individual components.

These rules, and how to use them to build powerful software, are the topic of this talk.

Affirmative.

I want to work on something where I can make a difference, and I think this is it. Paul Graham wrote (paraphrased from http://www.paulgraham.com/procrastination.html) one should at best work on things likely to be part of one's obituary. At this point I feel there'd be little difference if my obituary read "worked for 6 years at Facebook" vs. 7, 8 etc. But if I helped people get code written better, that's a lure I wasn't willing to not seize.

Probably not; D is not a particularly suited language for being a backend target. To be fair, neither is Javascript; it got in that position by accident.

That said, just as a related aside, there's the Daniel Murphy's magicport program that translates real projects from C++ do D semiautomatically (Daniel used it to translate the D compiler itself; we recently committed to bootstrapping).

The income :o). Well, just kidding. I think the best thing about Facebook is its people. They are really really good, and that's felt at all levels.

I think the lack of demand for it has been an indicator that ranges with additions are just enough. We're currently looking at adding optional primitives to ranges in a Design by Introspection manner to support bulk streaming of data.

Multzam!

This is good food for thought. Yes, working through a niche has been a good "in" for some languages.

1. I got std.experimental.allocator accepted for inclusion. On its basis it's not difficult to build the structures and algorithms necessary for garbage collection.

However, there were two concurrent developments. One is Martin Nowak and others did great work on improving D's existing garbage collector. The other trend is that it became increasingly clear that a category of users will always be weary of a GC, be it for the right or wrong reasons. So the better place to hit is to offer a great experience in D without requiring any garbage collection at all.

2. Mobile is an important area for a language like D. We don't have many experts on team to work on that, but we're looking. One thing I can do soon is to encourage ARM support, which right now works only experimentally and in a science project kind of way.

3. I want to make it possible to use a well-defined subset of the standard library without a GC. (The subset part is for legacy compatibility.)

D would be definitely helped by a large corporate sponsor. I think the foundation will make the language a more serious alternative for such adoption.

Competition is good for all involved. Rust and C++ are the competitors closer to the same turf. I think we have a solid value proposition and several ways to enhance it and differentiate ourselves. Time will tell.

I have quite a few things in mind for the immediate future. Organizationally, I want to get the D Language Foundation rolling as an organizational mothership of the language. Technically, I want to focus on: (a) completely defining the language - fuzzy corners such as the meaning of "shared" are a liability; (b) offer a solid experience to users who don't want a garbage collector; and (c) design more libraries using the fledgling Design by Introspection technique.

(EDIT sorry, submitted too soon) With regard to targeted users and uses, D is an ample language that could be used for a large range (heh) of applications. I want to make sure the core language and libraries offers a solid support on which various applications, frameworks, and libraries can build.

This is he. AMA!

My debugging experience with Code:Blocks on Linux has been spectacular.

There's a fair amount of recent work on both improving the GC and making it less used. We'll continue that work this year.

Those won't compile.

s/tr/m/

Affirmative. Use "aHash is anotherHash" to compare references.

Must support comparison for equality and the hash function. Default built-ins provided appropriately.

1. Sheer comparison for equality is used. (It is user definable.) For e.g. built-in hashes, contents must compare equal.

2. The store is a hashtable.

3. Multiple arguments are grouped in a tuple - no major complication.

4. Where memoization doesn't make sense you'll get a compile-time error because e.g. comparison for equality is't defined. At least most of the time :o).

5. The memory is thread-local.

6. memoize takes the name of the memoized argument and creates a distinct type for each memoized function.

TL;DR: business as usual

The macro trick is at https://github.com/philsquared/Catch/blob/785db43bb2cd64bfe7...: planting the tested expression to the right of an operator ->*, which is overloadable and allows for changing the type of the left hand side in the comparison. The rest is a "simple matter of programming". Clever but probably a bit cute - errors would look weird if the expression isn't set up as expected.

Go has been announced as a systems programming language: https://www.youtube.com/watch?v=rKnDgT73v8s. After some backlash the slogan has been changed quietly.

I think it's a good point. I can't speak for Walter, but I can say I've fostered openness ever since joining D development and we're both glad things are now in the right place.

Wierdest thing it's it can: http://goo.gl/88eFzs

Yet.

I appreciate this piece of feedback. I've been consciously trying to keep the article interesting technically and avoid it being construed as an advertisement for D, to the extent a couple of coworkers and at least one other colleague (http://goo.gl/QZ5ELn) were unclear about warp being written in D at all. I'll do my best to tone things down further in the future. There's plenty of exciting stuff going on to be worth avoiding alienating people.