Nothing to add here except that i agree that it should be only pure java in
the core of GeoTools and GeoServer. Plugins and community modules I could
perhaps see an argument for if the module has a stable maintainer.
On Thu, Jan 17, 2013 at 9:55 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> 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
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
