Spending today working with Jonathan on some iPhone/Mac Objective-C libraries for SQLite (managing data/schema migrations, etc), I stumbled across this bit of documentation:
After the parser assembles tokens into complete SQL statements, it calls the code generator to produce virtual machine code that will do the work that the SQL statements request.
Cool! SQLite’s Virtual Database Engine (VDBE) is documented in this tutorial, and the vm opcode reference. You can peruse the code generated for your own queries using explain (first using .explain to enable more readable output):
sqlite> .explain
sqlite> EXPLAIN INSERT INTO "testtable" VALUES ("testing");
addr opcode p1 p2 p3
---- -------------- ---------- ---------- --------------------
0 Goto 0 10
1 Integer 0 0
2 OpenWrite 0 2
3 SetNumColumns 0 1
4 NewRowid 0 0
5 String8 0 0 testing
6 MakeRecord 1 0 a
7 Insert 0 11 testtable
8 Close 0 0
9 Halt 0 0
10 Transaction 0 1
11 VerifyCookie 0 1
12 Goto 0 1
13 Noop 0 0
In programming, I find that the purpose of research isn’t to find the solution, but to find the problem. If I find the solution too, that’s a happy bonus.
An externality is an impact (positive or negative) on any party not involved in a given economic transaction.
http://en.wikipedia.org/wiki/Externality
I talk about “externalities” a lot; humans excel at rationalizing short-sighted decisions if they believe that the long-term costs are external to themselves. This is usually an unconcious decision, but no less costly to a community.
Given a technical problem, many engineers will naturally gravitate towards the easiest fix possible. If this fix has long term cost implications, they may even call the fix “temporary”. However, if the cost of this temporary fix is externalized — not levied against the party making the decision — then the temporary fix will become permanent.
This approach to problem solving incurs a long-term organizational cost. Whereas an initial investment of a few hours may have provided a permanent fix, the temporary fix may result in emense aggregate cost over time.
If I ever find myself creating a “temporary fix”, I always try to ensure that I will be the one paying for any long-term costs. This provides additional perspective to my decision making, and encouragement to provide a better solution.
I’ve spent the weekend researching libraries, frameworks, and languages intended to improve the web development experience. Many of these frameworks impose classic fork() concurrency model, holding the mantra that “Hardware is cheap”.
When developers say “Hardware is cheap” in response to poor architectural choices, what they’re really saying is that “Our hardware costs are externalized”. These web developers are rarely responsible for the direct increases in operational costs due to terminally inefficient use of server capacity.
This position presents a false dichotomy: a choice between achieving passable performance through good design, versus optimizing for developer effeciency. Effecient use of resources and ease of development are not mutually exclusive, though they may require different approaches to familiar problems.
