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

[Gervase Markham]

Frederik Ramm wrote:
> I think if someone came along with a real good performance optimization 
> for JOSM that, as an aside, requires more encapsulation than JOSM 
> currently has, that would be a very good reason to add said encapsulation.
> 
> Trouble is, until now we have had a lot of textbook lectures on how 
> everything would be much better if only we had proper encapsulation, but 
> never anything tangible. (Much like on the talk list, where every few 
> weeks someone comes around and says "what, you n00bs not using 
> PostGIS?", to which the much-iterated reply is: show results.)

The trouble with this logic is that it doesn't reveal or account for the
hidden costs. For example, how can I evaluate how much more likely it
would have been that I would currently be a JOSM contributor if I hadn't
taken one look at the code and said "Ick"? I can't, but it's a non-zero
effect. And how many more people are there like me?

By its very nature, it's impossible to tell how many more contributors
there would be, and how much better the code would be, if it was written
more in line with standard Java best practice. But Petr and I are at
least two data points.

There's a great book called "Economics in One Lesson" by Henry Hazlitt.
Even though it was written 50 years ago, the one lesson is still
relevant. It is:

"The art of economics consists in looking not merely at the immediate
but at the longer effects of any act or policy; it consists in tracing
the consequences of that policy not merely for one group but for all
groups."
http://en.wikipedia.org/wiki/Economics_in_One_Lesson

The effects on some groups are particularly hard to measure if they
consist of someone not doing something they would otherwise do, such as
contributing to JOSM.

It's like governments putting up taxes. The visible benefit they claim
is that they can spend more money on improving the lives of their
citizens. The hidden cost is that each citizen has less money, and so
they don't buy things they otherwise would and there's less economic
activity. What things? Impossible to tell. But it's a cost nevertheless.

> Currently, JOSM doesn't care for plugins; everything is more or less 
> wide open, and a plugin can do almost anything that JOSM itself could. 
> Sometimes when you work on JOSM, you break a plugin; but on the whole, 
> JOSM development is not hindered by myriad plugin hooks that have to be 
> maintained, and plugin development is not hindered by having only access 
> to a small plugin API. This makes it easy for both plugin developers and 
> JOSM developers - at the occasional expense of stability.

This is an entirely reasonable plugin model IMO; but it makes it all the
more important for JOSM objects to hide their internal state from
plugins using accessor methods and protected member variables. That way,
you can override something if you need to be doing a derived class, but
it means that plugins can't accidentally mess with stuff they shouldn't be.

Gerv