On Tue, Feb 18, 2014 at 9:08 PM, Alan Silverstein <[email protected]> wrote: > Attribute-based means not knowing ahead of time where you are going to > try to run, only what features you care about being present or absent. > (For a really good time, one time I built Perl from sources, and could > not BELIEVE the hundreds of attributes it cared about and checked on.) > > I think it's true that real portability cares about attributes not > preconceived notions of context. Â But also true that autoconf, etc, > while powerful, were inelegantly hacked together (or so it appeared to > me), very hard to learn and use.
Yup. For some reason this is a lesson people need to learn every few years because they keep on forgetting it. Cabal for haskell was particularly agregious as its proponents claimed they were doing something new by cataloging every condition and system up front, when in actualatiy that is how _everything_ worked before autoconf and people moved to it in droves because trying to know the context just doesn't work. So, 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. > After recognizing myself doing it, I coined the phrase "software macho" > to refer to cases where a tool creator's response to complaints is, "it > works for ME, what's YOUR problem?" Â Or worse, "if you don't like it, > don't use it!" Â About as far from user-friendly or user-adoring as you > can get. That is more understandable for desktop software, but for something like judy that is a library, meant to be integrated into tools and processes, thinsg are different. 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? So, "works for me" is barely the first step even if said by me, let alone someone else. Do I have the source, will it work for the weirdest server I can count on, do I have any reason to think it will fail on future systems. If not, then I just can't use it. For the record, I'm comfortable relying on judy when circumstances allow. :) > Just rambling here, but another revealed truth for me over the years was > how hardly anyone ever took the time to get their code "right" to start > with -- actually that's impossible -- but they considered so much of it > as prototypical throw-away trials, yet never had time to go back and > refactor and improve them to high quality before losing control of them. 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. [1] In fact there is a paper proving this, Hutters appropriately titled "The Fastest and Shortest Algorithm for All Well-Defined Problems" proves that the fastest algorithm for any task is always among the shortest that implement it. http://www.hutter1.net/ai/pfastprg.pdf Though, it may just be a cautionary tale about relying on big-O notation too much :) John ------------------------------------------------------------------------------ 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
