Chris holmes wrote:
Out of curiosity, why is this so bad? I mean it complies to pure java bytecode, could just be thought of an
additional library, like the xml stuff we do. It’ll interoperate on any platform, which to me was the big
downside in bringing in other languages.
There is a variety of issues why I believe we should be firm about never including another JVM language in core (unless… read towards the end).
The nice thing about having scripting languages as an extension is that everybody can pick their preferred scripting language and go down writing their cool extension. Someone goes with Jython, another one has a preference for Scale, someone else is a Groovy type, the other guy over there is a JRuby kind of person, and yet everybody is happily writing their own thing. Tomorrow someone comes and wants to use Ceylon, or Kotlin, or Clojure, and by using the JSR for scripting languages we can slot in those as well.
This is splendid… as long as we think in terms of custom extensions that are not shared with a larger community.
Now let’s ramp up a bit, and let’s say people start writing official extensions in non Java languages.
You just download them and add them to your GeoServer, everything is working, it’s all fine, right?
Nope, whilst it’s not too bad, it’s not fine either:
- each scripting language comes with its own runtime library, which is often rather heavy (several megabytes) pushing on our already quite poor permgen situation. And then… what if I need two or three of these extensions, all needing their own different runtime? That just multiplies the problem
- “polyglot” programmers are not the norm today, and even those that are polyglots have made choices,
creating a partitioning of the potential programmer base in tiny pieces, just see GeoScript, how many
people are there developing for a single language? GeoScript might have five developers, but
GeoScript Python or GeoScript Scala really have one, they are one man projects at the moment (scary).
Add to that the GIS nature of the project, and the set of developers that can do GIS in a certain non
Java language becomes a niche within a niche
It means that a module written in a language other than java has a much higher likeliness to just die
if the developer working on it leaves
Now, let’s ramp up another bit and consider a core in which non Java languages are allowed.
The permgen issue would just happen all the time, and some parts of the code would be limited
to a single person, when that one leaves you’ll have two high leaning curves to go after,
first learning a new language, and then learning about whatever the code there is doing.
Moreover, code in “core” is officially maintained “by the PSC”, which is good, it means a group
of people care about that code. But in a multi-language scenario, that’s not possible anymores
unless the PSC members also become “language geeks”.
That’s why I believe that while extensions written in a non Java language are sort of ok
(but they will be troublesome the day we have many), core in non Java language is simply
not an option.
Unless… well, unless the non Java language war starting during these years ends with a clear
winner, a new languages that really takes the place of Java obliterating all of the other
competitors.
If in a future Scala becomes the de facto non Java choice, and Jython, JRuby, Groovy, Clojure, Kotlin, Ceylon
(and all the others that I won’t list) get relegated to a very small percentange, well, in that case I’ll be very happy
to switch the entire project to Scala
Cheers
Andrea
–
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it