2008/11/21 Stefan de Konink <[EMAIL PROTECTED]>: > Dave Stubbs wrote: >> >> 1) The OSMF through donations and membership, other random donations etc. >> 2) Nobody (not by OSM(F) at any rate), so that means we're limited by >> how much time people are willing to provide for free (either companies >> or individuals). >> >> And besides which it was a general statement in response to your >> general statement about languages. Any applicability to OSM in >> particular is a fairly complex question which is, unsurprisingly, >> going to result in compromises. > > Many corporate boys always go to battle with the stupid argument you made. > Your general statement only points out laziness of developers, doing things > in shorter time resulting (usually) in suboptimal solutions. > > Since we are a group of people that not get paid and therefore need to > produce better work in order to use our facilities more optimal it is to > defend to always try to improve the work, because the userbase grows and the > amount of hardware is limited.
I'm arguing against your pejorative description of several programming languages. Developer time is never free, never unlimited, so you use it in the most effective way possible, and sometimes (and I'm fairly sure you do know this) that means not programming everything in super optimised C code. This isn't about being lazy, this is about getting things done in a tractable amount of time, and putting in the effort where it's most worth it. What you'll probably discover is that "corporate boys" as you so lovingly describe them are expressing the fairly sensible suggestion that you should find the right compromise between optimal solutions and just doing things quickly. Either that or they really are idiots -- it's not unheard of :-) > >>>> Which leaves the important question: does it matter for OSM? >>>> (and is a full rewrite the best way of fixing it if it does) >>> >>> As long it is slow, and someone is stupid enough to try and fix it, it >>> matters :) >> >> Sure, except that the code, once written, doesn't just sit there. >> People have to maintain this stuff. It's not just about, "can it be >> written?", it's "can it be written and maintained?". >> >> So I think a better reply (well, maybe just more complete) is that as >> long as it is slow, and someone is stupid enough to try and fix it, >> and they can convince the guys who are going to end up responsible for >> deploying and maintaining it, it matters. > > The amount of people here that feel responsible for each others code is very > low. If you look at the tools available for processing OSM data it is also > easy to see that some are superseded a long time ago and others get bitrot > by updated APIs. > > In my perspective; if everything is unittested and the limitations are > known, they don't break if they are untouched. To use another well known > sales boy quote: "no one is irreplaceable", there will thus always be > someone that is capable of reading the documentation, and changing the code. Ah, don't worry, sales guys are universally reviled ;-) And actually with well written RoR code your developers become largely interchangeable with remarkably little notice -- that's half the point I was making. > >> Sometimes speed becomes important and it makes sense to replace >> certain parts of the system, ie: the GPX importer which has already >> been down this path. > > Exactly, and so can we do with the API/XAPI if we want to :) > Yes, exactly. XAPI is relatively easy. There's only one API though, so you need to do one awesome job of convincing the right people :-) Dave _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
