Re: [Geoserver-devel] Ranting about non Java language usage in core
On Tue, Jan 22, 2013 at 12:57 PM, Chris Holmes wrote: > 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. > Seems a little extreme to be making changes to project policy in response to proposals that weren't made. But I guess it is better than waiting until the issue comes up (and confusing policy with the decision made for a specific case.) On Mon, Jan 21, 2013 at 10:41 AM, Justin Deoliveira 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. >> > Well, plugins are currently clear to my knowledge, but GeoServer already has a community module which is written in a non-Java language - the CSS module which I maintain. This has been written in Scala since its inception over two years ago (although I rewrote most of the frontend in Java at Andrea's request about a year ago.) Is it acceptable for a community module to depend on a runtime library like Scala's? What about having Scala code outright? The CSS module originally lived outside of the GeoServer repository so I don't guess it would be a problem to go back. -- David Winslow OpenGeo - http://opengeo.org/ On Thu, Jan 17, 2013 at 9:55 AM, Andrea Aime 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 >>> ye
Re: [Geoserver-devel] Ranting about non Java language usage in core
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 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 > 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 >> >> --- >> >> >> -
Re: [Geoserver-devel] Ranting about non Java language usage in core
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 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
[Geoserver-devel] Ranting about non Java language usage in core
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
