[josm-dev] Difference between JOSM and JOSM-NG
frederik at remote.org
Tue Aug 12 09:20:04 BST 2008
Gervase Markham wrote:
> standard Java-isms
> industry best practice
> Structural design patterns
I, for one, would like to also attract developers for whom maybe Java
and OO are not the environment in which they spend all of their
programming lifes and for whom a comment like "using decorator pattern
here" is not very helpful. OSM is a project with an enormous breadth of
programming languages and concepts, and I think we profit a lot from
people being able to work across the board. This doesn't mean we should
write Java as if it were Perl, but it also means that it is a good idea
to keep things simple.
> If working on performance, because the
> class used for internal storage is exposed to callers, you can't e.g.
> replace a linked list with a hash for efficiency reasons, or decide to
> lazily compute the value from other values.
Again, empty promises. If I find that I want to replace a linked list
with a hash for efficiency in JOSM, I just do it and check whether the
plugins still compile. Nothing has ever hindered me to do that precisely
beause I am NOT doing things based on well-rehearsed textbook talk. If I
wanted to please the "industry best practice" crowd then it would be
totally inacceptable to make a change that perhaps breaks some
unpublished plugin down the line. If I wanted to do it right, I would
have to put up a corset of guaranteed properties on which plugins could
rely, and beforehand I would have to encapsulate as much as possible
away from plugins so that guaranteeing these properties will not break
my ability to work with the code. Not having such a set of guaranteed
properties gives me the freedom to optimize as much as I want, with the
drawback that sometimes I might have to edit a plugin as well (and any
unpublished plugins might break).
> This and other considerations mean that any book you read on Java best
> practice (or any object-oriented language, for that matter) will
> recommend that you make your variables private and use accessor methods.
> Multiply that up for each change of this sort you want
> to make, and you can see why people don't start down that rocky road.
> The "stop energy" barrier gets too great.
Past JOSM development proves you wrong. And JOSM isn't going to be a
framework used by thousands of developers any time soon. I maintain that
while it's all nice and shiny to put up standard practice rules, they
are mostly very theoretical constructs based on the idea that someone
might want to do something which might then break something else and
everything would go down in flames.
I maintain that for the software that JOSM currently is, with the
purpose that JOSM currently has, and the developer community available
to work on it, JOSM is just right.
I concede that, if OSM were a project where hundreds of developers work
on various aspects of JOSM, or if JOSM was an academic project where it
is more important to show that you have understood a concept than to put
it to practical use, or if JOSM was a commercial enterprise where
instead of having a bunch of part-time programmers that sometimes aren't
even Java specialist, you will have full-time experts working on it - I
concede that in all these cases relying more on "Java-isms" and standard
practices would be more in line with the goal.
> You're right, I can't magically produce more developers if you agreed to
> let people refactor the code to match best practice better. But I can
> give you some reasons why the average Java programmer will find diving
> into the current JOSM codebase an unappealing prospect.
If given a choice, I'd rather have the average mapper dive into current
JOSM, than the average Java programmer!
> One reason perhaps is that open source projects are successful in
> attracting developers when they already work (albeit imperfectly) for a
> task. JOSM-NG is not yet even a basic OSM editor, because (as I
> understand it) it can't return changes to the server.
Something that would probably cost you one day to implement.
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the josm-dev