Recent submissions

Comment · 6 years ago
Comment · 6 years ago
Thanks! I tried that too, but it's slower than Lomuto. Forgot to mention in the article.
Comment · 6 years ago
This. Thanks!
Comment · 6 years ago
(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.)

Comment · 6 years ago
Would love a sequel!
Comment · 9 years ago
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.

Comment · 9 years ago
Affirmative.
Comment · 11 years ago
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.
Comment · 11 years ago
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).

Comment · 11 years ago
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.
Comment · 11 years ago
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.
Comment · 11 years ago
Multzam!
Comment · 11 years ago
This is good food for thought. Yes, working through a niche has been a good "in" for some languages.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton