[josm-dev] Difference between JOSM and JOSM-NG

[Frederik Ramm]

Hi,

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.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"