djwonk

Looking for a rigorous mathematical text on efficient random number generation for various statistical distributions? Perhaps you need data generation for simulations or Monte Carlo trials? Then take a look at Non-Uniform Random Variate Generation by Luc Devroye -- it looks to be one of the best collections of its kind.

The text is about one small field on the crossroads of statistics, operations research and computer science. Statisticians need random number generators to test and compare estimators before using them in real life. In operations research, random numbers are a key component In large scale simulations. Computer scientists need randomness In program testing, game playing and comparisons of algorithms.

The book seems geared for these uses:

you are writing a library of random number generators

you want to be confident that you aren't fouling up random number generation (RNG)

you care about performance

you are looking to verify that a software library has done its homework when it comes to RNG implementation details

I've seen citations among R library implementers to Devroye's work; I suspect that other libraries like Apache Commons Math (Java) and NumPy/SciPy do too.

Note: The PDFs are sharp and readable but have some strange encoding issues when it comes to copying, pasting, and searching.

As a side note, the author doesn't hold anything back in explaining why the book is free:

Furthermore, I give anyone the permission, even without asking me, to take these PDF files to a printer, print as many copies as you like, and sell them for profit. If you would like me to advertise the sales points of the hard copies, please let me know. To the libraries: Please do not charge patrons for copying this book. I grant everyone the right to copy at will, for free.

So, there you have it. Eventually, I will do this with all my books. While I love Springer, my honeymoon with them is over. I will of course never start any affairs with the champion bloodsuckers like Elsevier, Kluwer or Dekker. Outfits I like are SIAM (nonprofit), Dover (great pricing) and Oxford University Press (allowing authors to post books on the web). With the arrival of Amazon, book advertising is no longer necessary, and one can publish with any company, really. So, it will be a matter of a few years before the old publishers will come back to the academics on their hands and knees asking for manuscripts. Too late.

Clojure macros are ever-growing longer, without bothering to include visual queues for word breaks. Apparently, these macros draw their inspiration, mysteriously, from the German language (e.g. hauptbahnhof; see more examples at Wiktionary's List of German Compound Words).

So. Hard. To. Read. As is my tradition on this medium, I will rant against things gone wrong that will likely never change. In that spirit, I hang my head in shame and ask: Why? Why? Why?

Look at the examples below. Which is more readable? Which would best fit in with Clojure, the language we love?

defcomponent or def-component

defcomponentk or def-component-k

defroute or def-route

defcomponentmethod or def-component-method

The latter (hyphenated) examples are clearer to read. I won't even go into the scientific studies showing that the latter examples are happier, live longer, and are less likely to bully other macros. In the long run, the happy macros are less likely to resort to violence when things inevitably go south.

Clojure developers don't make these hideous name in other contexts. We use hyphens, because it is obviously better. So why do we do it with macros? Probably because we are lemmings.

I suppose the pattern started with defmacro, defrecord, and so on, way back in the days of the first LISPs. That was ok. Or was it? The anti-hyphen, alphabet smoosh-fest style really wins no style points as your macro names grow longer.

David Schnepper (DS) gave a talk at Ignite in 2014 titled, "Isn't That Code Dead?". The presentation is a mix of conventional and unconventional; you may embrace it or run away screaming. In either case you will learn something about what is worth trying.

Some of DS's points are uncontroversial. For example, "over time, old code is not exercised, the environment changes and it rusts away."

Other suggestions play with fire. DS recommends that if a software developer suspects that a function is dead, add a tombstone function call (such as `tombstone("2014-10-31")`.

There are several advantages to adding a piece of code that serves as a tombstone:

It signals intent to other programmers.

It gives you a dynamic check, beyond what a basic timestamped comment or static analysis can offer.

It enables automation via additional tooling. The video explains how DS's team have tooling to gather metrics and automatically remove code.

Of course there are disadvantages:

It may tempt people to add tombstones instead of quickly removing dead code.

The run-time cost may be undesirable.

In an ideal world, source control and testing allows old code to be mercilessly removed. For real-world situations that don't quite live up to this goal, the tombstone technique may be useful.

You don't have to go far to find people claiming that one of Ansible's strengths is its "declarative" configuration. Some claim this declarative language is better than, say Ruby (used in Chef) or Puppet's custom language. Now, this may indeed be true, but let's get into the details. What declarative language does Ansible use? YAML. This does not seem to raise eyebrows.

My goal is simple. Next time you see any person or project using YAML as a declarative programming language, I want you to raise an eyebrow. If you do this, then I will be happy.

Let's have some fun. What would people say if Ansible had chosen a different "declarative" language? Pick your favorite. Go on.

Oh, you picked XML? Me too! Let's think about it: what would happen if Ansible went with XML instead of YAML?

Madness. Chaos. People would run Ansible straight out of town! The pain from XML is still too fresh.

This is strange, though, because YAML isn't fundamentally different. Yes, I realize that YAML is easier on the eyes (and soul) than XML, but both are fundamentally languages for data transport, not programming.

Perhaps Rails made YAML hip. Perhaps others have not yet despoiled YAML. I suggest to you that Ansible may have, under your very noses, taken YAML too far. Let me explain.

But back to our thought experiment: Ansible + XML! There is little love lost on XML. Big surprise. In addition to being an unwieldy data format for humans to write without significant tool support, it also has come to embody the idea of configuration-gone-too-far. In order to use XML for logic, one often re-invents ways of handling variables, control flow, iteration, and more. To do so, one must create a programming language. Alas, it may not be a good one.

Here is my point: if you find yourself creating a new programming language, why use data exchange format as the substrate? I have a few guesses.

Guess #1: Perhaps you don't realize that you are creating a programming language. You just went for it.

Guess #2: You thought about using an existing language, such as Ruby or Python, but were concerned about users abusing the power.

Guess #3: You didn't want to have to write a parser for a custom language. You chose a data language (e.g. XML or YAML) because it is syntactically easy to parse.

To comment on the last theory: parsing the syntax is the easy part. Afterwards, you have to build additional logic (that acts effectively as a run-time) that can execute your programs. Maybe this is easy too, at least at the beginning.

Perhaps, to start, you only need a few language features; perhaps only some basic looping. But then what about sorting, conditionals, custom functions, and so on? As your tool becomes more popular, I predict you'll find that your users, which happen to be software developers, will ask for more programming-language capabilities.

Personally, I felt a bit uneasy when I saw Ansible using YAML. This uneasiness became more pronounced when I saw `with_items`. Some might say that `with_items` is a helpful hack given the YAML constraints. That's my whole point: Ansible has invented a programming language (a DSL within YAML), probably without admitting it.

My tentative view is that Ansible is taking an Icarus-inspired risk in using data-exchange language for configuration management. My hunch is that an existing programming language would be better suited.

Thankfully Ansible is not using XML, but that don't let that comfort you. YAML isn't fundamentally better, since it is still a data-interchange format.

I see YAML-as-configuration-management as a problem because there have to be better options. Hundreds, if not thousands, of programming languages have evolved to address abstraction, composability, and readability in various ways. It seems like a shame to fall back on YAML without a very good reason.

Yes, this is a one-sided argument. Otherwise, Ansible seems to be a nice configuration management (and remote execution) tool. As a practical matter, YAML may have been a reasonable place to start.

And please don't tell me YAML is a nice choice simply because it is declarative. It is a declarative data language, not a declarative programming language. There are declarative languages that solve particular problems very well. Some of my favorites are: Prolog, SQL, and Verilog. (I realize that if you made it this far into this rant, I might as well compliment SQL while I had the chance.)

That's all I've got for now. If you have ideas for building an elegant declarative language for configuration management, please get in touch.

P.S. I'm not particularly satisfied with the configuration management tools I've seen. They seem too complicated from a data modeling point of view. There seem to be too many arbitrary names being created. It seems to me that all we need are basic functions that can be called, composed, serialized, and versioned. I certainly don't have it figured out, but I have the impression that no one else has really nailed it either.

If there is some truth to a deep learning "gold rush", then I expect the economics will be different from the 19th century gold rush.

I see two key differences in how the underlying resource works:

Finite vs infinite. There is only so much gold available that can be profitably extracted from the earth, but I can't think of any limit to the amount of customer data that can be extracted. This gives a comparatively level playing field when it comes to accessing the resource. Of course, such theoretical access may be quickly limited by business partnerships or technical constraints. Thought leaders in particular technologies will have competitive advantage to get mind-share and access to early adopters.

Rivalrous vs. non-rivalrous. If I own physical land, there is only so much gold available; I cannot simply copy it. But if I own a significant web property, I can pay multiple data analytics firms to mine my data simultaneously without exhausting the source. If you are a data analytics company selling a service to the owner of a web property, you don't necessarily *have* to be the first in to add value and get commercial success, at least not due to this particular line of logic.

There is at least one similarity:

Excludable vs. (partially) excludable. If you own physical land, you have reasonable ways to prevent people from stealing your gold. As the owner of a web property, you might think you can control who accesses your customer data. To a large degree, this is true; unless you get hacked or surveilled, you may retain control of your customer activity data on your web properties. That said, your customers leave tracks on various places on the Internet. So their data that you see is, in effect, only partially excludable. Your customers are also someone else's customers, by way of their other activities and third-party ad placement and cookies. So if you have a valuable customer demographic, you should expect that others are racing to get the insight and value from their data.

Nick M. Garcia's answer grabbed my attention:

I argue that in addition to our history and culture, the biggest impact on fostering social and economic conservatism has been our legacy of rural and low-density urbanization.

Worth a read. How you live, where you live, how many people you interact with is a key driver in how you view the world. This point really hit home:

Rural areas and small towns make it easier to perpetuate the myth of social homogeneity as anyone perceived as "different" or "deviant" is forced to stay in the closet for fear of alienating their entire social network.

I just searched for "ruby gsub!" in DuckDuckGo. Apparently gsub! is a registered DuckDuckHack, so I got whisked away to the less-than-useful Greek Subtitles Project, which I am not going to link, intentionally. I can see why the creators of the site would do this! Still, one has to wonder how many greek movie enthusiasts want subtitle searching as compared to how many programmers want documentation about regular expressions!

So, is this the future of search? Goodbye domain name squatting, hello DuckDuckHat squatting.