Cool, makes good sense, and was about what I suspected, was just curious
for the full articulation. Thanks Andrea.
Might be good at some point to lay out this policy explicitly. But to not
over complicate things we can just refer to this thread if it comes up.
On Mon, Jan 21, 2013 at 10:41 AM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
> 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
>
>
------------------------------------------------------------------------------
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/learnnow-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
