Enjoying chatting, hope no one minds (but of course they'll just tune out if they do).
> For some reason this is a lesson people need to learn every few years > because they keep on forgetting it. If software engineering really ever does become a science rather than an impressionist art form, perhaps. But I wonder if it's even possible because being pure mind-stuff, it's infinitely rich and complex and probably beyond human capability to learn and know enough, when you consider all aspects of the complete "software life cycle." And the system doesn't reward people for even trying very hard. How's the quote go? "In software we stand on each other's toes, not shoulders." An exaggeration of course considering how much embedded support we use all the time -- boot loaders, OS, libraries. > ...I see a lot of people trying to replace it with 'context' tools > that end up extremely limited, as in, "it works on the last 2 versions > of windows and at least one linux distribution so that's everything, > right?". Nope, it needs to work on systems you never even heard of. Right, and that was true of libJudy too. But as I mentioned, being short on time and resources and designing only for HPUX and maybe Linux and Windows a little, we didn't spend much effort on global portability. > As a developer, I have to make a decision about whether to rely on it. > Will it be a bottleneck in the future. Or as an admin, can I build an > infrastructure with it where I can be convinced it will either work or > be easily made to work in the future? Oh, totally. Later contracting for both HP and Avago (child of Agilent, child of HP, same site), more than once people knew about my libJudy background and reluctantly invited me to use it in current work. I had to convince them it was rock-solid, I'd check the source code into the local source tree, it really shouldn't be a problem. But of course it was still a problem for mind-to-mind portability even so, as someone wanted to read my source code and didn't know what to make of Judy*() calls, being only familiar with hashing and typical C libraries. Usually I bulled ahead anyway figured this was a way to evangelize the library into THEIR toolboxes. Along with trying to document my work as clearly as possible -- even ASCII diagrams in the comments, illustrating the data structures. > For the record, I'm comfortable relying on judy when circumstances > allow. :) That's high praise! Thanks. > I think it is something of a skill people eventually learn. The right > way to implement things isn't generally much harder than the hacky > way[1], it just takes experience to start doing it by default. Of > course, you gotta _care_ about doing things right to begin with or you > will never learn. I think it is like when practicing the piano, you > have to stop yourself when you mess up and start over or not practice > at all or you end up learning the incorrect thing and it is worse for > you than no practice. Nice narrative... Cheers, Alan ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
