Railway oriented programming

Here's a pretty fascinating talk about how to think of mature error handling as a kind of two-track railway, with errors forcing execution down onto a Failure track. I really like this.

The data engineering ecosystem

Interesting. Very interesting, actually. Sort of an architectural mapping approach.

Explorable explanations

This is a cool post on "the rise of explorable explanations". Very interesting collection of stuff there. On that note, a little musing about combining R and D3.

Nial

Nial is a programming language built on arrays - it compiles in-situ for execution, apparently, so it would seem to be very efficient for data manipulation.

Another spam recipe posted to a blog instead of being processed

Interesting stuff: http://pastebin.com/U7jv9jxS [hnn]

Structured proofs

I know, I know, I'm never going to be a mathematician, but here is an article about a talk by Leslie Lamport about how 21st century proofs should be written. And here is Lamport's own paper on the topic. I'm totally with him on the structure - I think a hierarchical proof structure is a great idea, and a much more careful and explicit structure is also much more understandable. But when he goes to defining a formal language TLA+ for expressing proofs, I have to say that the sheer ugliness of the format is an instant dealbreaker for me. No way. That is not the elegant way to express proofs.

Further thought is necessary. But I'll bet I can come up with a prettier language.

How Patrick McKenzie uses Twilio

Short and sweet - a boon to the international traveler.

Beautiful JS chessboard library

This is how everything should be handled.

Top Python mistakes when dealing with Big Data

Interesting article.

1. Reinventing the wheel. For example, writing one-off code to read a CSV instead of using a convenient purpose-built library that could offer deeper functionality. (Python Pandas, to be specific, in this case - interesting stuff, actually!)
2. Failing to tune for performance. Cuts down on testing cycles per day.
3. Failing to understand time and timezones. Ain't that the truth.
4. Manual integration of different technologies in a solution (copying results files back and forth by hand, etc.)
5. Not keeping track of data types and schemata.
6. Failing to include data provenance tracking. Oooh, I like this notion.
7. No testing, especially no regression testing.

All good points.

Identifying programmers

Another application of NLP techniques to source code. Interesting.

Data structures

Here's a great open resource for data structures.

Why Perl didn't win

Whew. Yeah.

Torch

Torch is a Lua-powered numerical environment that I've never heard of, but that looks incredibly neat. I only mention this because Facebook released some open-source deep-learning modules for Torch today.

Rosetta Code analysis

Neat paper analyzing programming languages based on their Rosetta Code submissions. Comparative programming linguistics, I guess.

Cquence for really simple JS animation

Cquence looks useful.

What happened to Old School NLP?

Answer: statistical methods work OK and they're way easier. 'Struth!

Parsley

Parsley is a data extractor for HTML.

Color

I don't know why this kind of database always interests me.

Flow-Based Programming

Flow-based programming is not a particularly new idea, but it's getting some more attention lately.

Exegesis, literate programming, and Decl

The basic outline of Decl's new syntax parser is complete and passing tests, and as always when a milestone is reached and I look around the corner at what's next, I'm a little overwhelmed. It makes me philosophical.

My initial Marpa NLP article was actually a very simple exegetical analysis of a prototype script I wrote myself, and as usual when doing a first stab, I ended up writing a lot of special-case code and syntax to handle things, representing a technical debt that in such situations nearly always strangles its host. Fortunately, I iterated quickly this time, taking the insights from that and putting them into a new Decl-based plan.

Slowly, I'm feeling my way towards a Decl-based system for literate-style transformational exegesis, one that I hope will eventually encompass everything this blog has been about.

The advantage to basing everything on Decl is that parsing is done. I can now parse a very rich, informationally dense data structure that is designed right from the start to group things in more or less the same way natural language does. It's easily extended and configured, easily indexed - in short, it's a way of taking notes about program structure and using them to evolve a program.

So that's where I'm going. Very slowly.