Still my favourite Facebook poster. (And a good question to ask yourself everyday, really).
Metacog
by Eli James 
-
2013-03-04
-
→
What the smartest people do on the weekend is what everyone else will do during the week in ten years
“Business people vote with their dollars, and are mostly trying to create near-term financial returns. Engineers vote with their time, and are mostly trying to invent interesting new things. Hobbies are what the smartest people spend their time on when they aren’t constrained by near-term financial goals.
Today, the tech hobbies with momentum include: math-based currencies like Bitcoin, new software development tools like NoSQL databases, the internet of things, 3D printing, touch-free human/computer interfaces, and “artisanal” hardware like the kind you find on Kickstarter.
It’s a good bet these present-day hobbies will seed future industries. What the smartest people do on the weekends is what everyone else will do during the week in ten years.”
Astute, but counter-examples: stock picking, making board games (Magic The Gathering, anyone). The general idea seems about-right, though.
-
2013-03-03
Proebsting’s Law (a.k.a: is code optimization research irrelevant?)
In 1998, Tom Proebsting made the following observation:
I claim the following simple experiment supports this depressing claim. Run your favorite set of benchmarks with your favorite state-of-the-art optimizing compiler. Run the benchmarks both with and without optimizations enabled. The ratio of of those numbers represents the entirety of the contribution of compiler optimizations to speeding up those benchmarks. Let’s assume that this ratio is about 4X for typical real-world applications, and let’s further assume that compiler optimization work has been going on for about 36 years. These assumptions lead to the conclusion that compiler optimization advances double computing power every 18 years. QED.
This means that while hardware computing horsepower increases at roughly 60%/year, compiler optimizations contribute only 4%. Basically, compiler optimization work makes only marginal contributions.
Perhaps this means Programming Language Research should be concentrating on something other than optimizations. Perhaps programmer productivity is a more fruitful arena.
My impression of programming languages research is that it’s a field of mostly solved problems. Much like operating systems, I suppose.
After all, the most exciting new language to come out from the woodwork in the past 5 years is Go. And Go is not at all exciting from an academic standpoint. It has nearly no new ideas.
(What ideas it does have is cherry-picked from the barrel of proven ones; e.g.: CSP, composition in place of object orientation, forcefully-simple type inference).
What makes it exciting is that it’s very well-designed. In that sense, at least, it’s quite exciting indeed.
I suppose it says a lot about one’s field: that the latest, hottest, newest language is also one of the most boring ever built.
But then again, maybe there’s something here (a move to value design over ideas?) that I’m not seeing.
-
2013-03-02
Why Python, Ruby, and Javascript are Slow
Alex Gaynor’s created another brilliant presentation. (Gosh I love the guy.)
Core idea here: line-for-line, Python, Ruby, and Javascript are all as fast as C (as unintuitive as that sounds). What really makes things slow is the way the language implements commonly-used idioms.
Dynamic language idioms (and the syntactic sugar to make them happen) use data-structures & algorithms that are maladapted, in order to make the language easier to use. The result: your programs are slow simply because you’re encouraged (and sometimes forced) to use slow things. For example: you use a small dict in Python where a C-style struct would give you the same functionality for much better performance.
No longer valid reasons for slow speed: dynamic typing, monkey patching.
Update: counterpoint from Mike Pall of LuaJIT over at Reddit.
-
2013-02-19
The computing deployment phase
Each revolution begins with a financial bubble that propels the (irrationally) rapid “installation” of the new technology. Then there’s a crash, followed by a recovery and then a long period of productive growth as the new technology is “deployed” throughout other industries as well as society more broadly. Eventually the revolution runs its course and a new technological revolution begins.
(…)
This pattern is repeating itself in the computing/internet revolution. Most of the successful startups in the 90s built core infrastructure (e.g. optical switching) whereas most of the successful startups since then built applications on top of that infrastructure (e.g. search). The next phase should see startups higher in the stack. According to historical patterns, these would be ones that require deeper cultural change or deeper integration into existing industries.
-
2013-02-17
Making Fun of Love and Work
I keep thinking back to Alain de Botton’s The Pleasures and Sorrows of Work. In particular:
The strangest thing about the world of work is the widespread expectation that our work should make us happy. For thousands of years, work was viewed as something to be done with as rapidly as possible and escaped in the imagination through alcohol or religion. Aristotle was the first of many philosophers to state that no one could be both free and obliged to earn a living. A more optimistic assessment of work had to wait until the eighteenth century and men like Jean-Jacques Rousseau and Benjamin Franklin, who for the first time argued that one’s working life could be at the centre of any desire for happiness. It was during this century that our modern ideas about work were formed—at the very same time as our modern ideas about love and marriage took shape.
In the pre-modern age, it was assumed that no one could try to be in love and married: marriage was something one did for purely commercial reasons. Things were going well if you maintained a tepid friendship with your spouse. Meanwhile, love was something you did with your mistress, with pleasure untied to the responsibilities of child-rearing. Yet the new philosophers of love argued that one might actually aim to marry the person one was in love with rather than just have an affair. To this unusual idea was added the even more peculiar notion that one might work both for money and to realise one’s dreams, an idea that replaced the previous assumption that the day job took care of the rent and anything more ambitious had to happen in one’s spare time.
We are the heirs of these two very ambitious beliefs: that you can be in love and married, and in a job and having a good time. It has become as impossible for us to think that you could be out of work and happy as it had once seemed impossible for Aristotle to think that you could be employed and human.
This is admittedly set against the backdrop of pre-modern Western societies, but de Botton’s writing makes a rather astute observation: our society tells us that we are to derive meaning primarily from our work, and from love, and we should do this in our day jobs and in our marriages.
This isn’t necessarily true, of course - there’s religion, and stamp collecting, and living vicariously through your children. But those are alternatives; mostly you’re expected to think about your career and your personal life as two separate threads that fork off once you reach adulthood.
So you see friends who hunger for intimacy. And you see friends who shut those needs out and focus exclusively on work.
It’s rather refreshing to think this wasn’t always the case. What might life have been like in the 1800s?
-
2013-02-15
I typesetted this early last week. (original here)
I don’t agree with (9), but I think the spirit of the whole piece is spot-on. Note to self: stop publishing ideas on the Internet without getting things done.
-
2013-02-09
ORMs
Today I learned why people think ORMs are a horrible idea.
I quote Fred Ross:
Codd’s relational model was an upstart in a market of graph, object, tree, and various hybrids and other exotic databases. I do not claim that it the relational model is superior because it survived. Most entrenched artifacts of computing are fixed by social factors, not technical ones. The relational model is superior because it described the semantics a data store needed to specify for most real world use; made the translation of declarative queries into operations a finite, approachable problem; and unified all the expressive power of the other kinds of database in a single mathematical model. SQL, the language, was the result of a natural language project at IBM. It is not intrinsic. The underlying model, as Codd defined it, is intrinsic.
Waddya know.
-
2013-02-06
To paraphrase Thomas Sowell, we should judge people by their means, not their ends, because most people don’t achieve their ends and all we’re left with is their means
-
2013-02-04
On Python security amidst recent Rails/YAML vulnerabilities (Hacker News Comment)
This “encode problems into names” approach is something I first ran into at Facebook.
When a particular function or class is found to be a problem (or when it is known to be a problem in advance), it is (re)named something like “
foo_POTENTIAL_XSS_HOLE” or “FooMapNonStlCompliant” throughout the code base (using pfff or similar tool), and then the potentially long process of removing the problem can go forward with some confidence nobody will add to the problem while you’re working on it.
