Thursday, September 11, 2014

dietzler's law

There are a lot of UI-centric build systems out there. As an old-skool web guy, some of them seem like overkill; but then again, I'm skeptical about the need to load content from a CDN, compressed, and bungled into one giant file, about whether that pulls its weight when you're in an agile mode. (As a final step, it becomes less onerous, and has more potential for being useful, but if you do it rarely than the automation isn't as crucial.)

I google for "Maven vs Rake" (Rake being "Ruby Make") and found this article, Why Everyone (Eventually) Hates (or Leaves) Maven. It cited a "law" -- technically about Access, but applicable to Maven as well as framework selection in general, that rings very true to me:
Dietzler’s Law for Access: Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create, and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions, and users always want 100% of what they want.
The article cites a brilliant example of "composable systems", how systems that contain of simple, "do one thing, do it well" subsystems chained together are better than monolithic constructs: More Shell Less Egg is where 6 piped together unix commands trumped 10+ pages of beautiful Knuth Pascal for a simple word frequency task.

I think Javascript in particular lends itself to "composition over inheritance"; yes, there is a prototype system that can make it object-oriented-ish, but really, I don't think it's the language's most natural paradigm. By making function definitions as easy to assign as an integer, you can really make composable systems work well - and the simple elegance of JSON acts as a pretty decent glue language, just like plain, line and tab delimited text via pipes did for Unix. And as an extension of that, I prefer libraries with take-what-you-need functionality over big monolithic "this is how we do this" frameworks.


No comments:

Post a Comment