Premature optimization bites once again
Why do I so easily succumb to the siren song of premature optimization? I'm now ripping out of Fabric a feature I meant to be a performance boost, but a couple of design decisions later and it was clear the feature was just making things complicated.
Simplify simplify simplify. Optimize later.
Project update:
I've now gotten the first iteration of the Fabric test suite done with a test runner that reads test formulas out of specially delimited files, runs them and verifies the output. Currently I've written 800 lines or so of Fabric test formulas, and that will grow quickly as new functions are added.
So with the test suite in place I'm currently going through all the code and refactoring mercilessly: cleaning up, clarifiying code and comments, and looking for problems.
Big work items left to go:
Compiler error handling - Currently the compiler gives very cryptic error messages on bad formulas.
Core Functions - I've implemented all the operators already, but only a handful of the needed built-in functions.
Date/Time datatype - Completely unimplemented so far.
Performance profiling - I'd like to do some basic profiling just to shake out any egregious performance problems.
Memory Leak testing - I need to add detection of memory leaks into the test suite.
I'm hoping to have all this done and Fabric completely incorporated into CouchDb by March 1.
Posted January 16, 2006 1:58 AM
Comments
Please make sure that you implement an error called "Entry not found in index" that neither specifies which entry, nor which index. This will give developers something to do, since there isn't any better way they could be using their time! ;)
Marcin Szczepanski, January 16, 2006 3:59 AM
I think more than giving developers something to do implementing the error message "Entry not found in index" the way Marcin describes it will more than any other feature you can think of provide a smooth transition path for the domnino developer community into CouchDB.
Slawek Rogulski, January 16, 2006 6:53 PM
Good points about non-informative error messages. I'm going to make it a priority that error messages have as much info as possible.
Also a real debugger is planned, I'm envisioning remote debugging from a web browser. But that's going to come much later.
Damien, January 16, 2006 7:48 PM
See, the way Ruby on Rails does it is very nice. You specify your environment, "development" or "production". In development you get lots of debug info when something breaks, full details of all SQL in the logs, etc but in "production" the user just gets a generic Error 500. This gives you the easy debugging in dev, while still protecting your implementation details in prod.
I think this sort of thing is definitely the way to go.
Marcin Szczepanski, January 17, 2006 1:58 AM
The only way to go is numbered error messages. That way your code looks super important and makes the user feel it's their fault if they see an error "432283". Hook it up to a random number generator and you're sweet.
Brendon Upson, January 17, 2006 5:15 AM
Post a comment