The time has come finally for a release of the Groovy Eclipse plugin. The plugin has been published to the update site.
There are a few notes to make.
First off there is now refactoring support inside the plugin for your Groovy Code. To see this demonstrated head over to this wiki page. Besides documentation there are some pretty cool flash demos of the features which should entice.
Second, the groovy plugin now supports the 1.5.7 version of Groovy.
Third, this release does not contain support for the joint compilation of Java and Groovy code by the Groovy compiler. This is a priority for the next release, and is a perfect segue to the next note.
Fourth, please feel free to visit the wiki page Groovy Eclipse Roadmap. There the Groovy Eclipse team is collecting priorities and feedback for features to be added to future versions of Groovy Eclipse. The plan is to release another version here before the end of the year or soon after the new year, depending on the issues that are resolved, feedback from the community of users and the release schedule of new versions of Groovy.
Fifth, if you are having issues with the plugin, please contact either the Groovy Eclipse mailing list (you can subscribe here), follow Groovy Eclipse on Twitter. or browse/add JIRA issues here. Your feedback is much appreciated.
Finally, as the Groovy Eclipse project lead, I would like to thank our contributors that made this release possible, in particular Thorsten Kamann, Michael Klenk, and Heiko Bottger. Finally a shout out to Guillaume Laforge, for helping to keep Groovy Eclipse afloat and me on track. Thanks everyone!
Tuesday, December 02, 2008
Sunday, November 23, 2008
Wednesday, July 16, 2008
Roadmap for Groovy Eclipse work
Hello everyone. I know Ed Povazan has not been active, so I will try and step in to fill the void. There has been activity on the Groovy Eclipse development mailing list requesting a roadmap for the future of plugin work. I know that I have been on a soapbox for a while now about how we need full time and paid work to support the plugin, but I think I should take a stab at what I think that the near future of the plugin should be. I think that the current trunk (or what is out on the dev update site) is a viable candidate for a release. I know I have been telling people over the last couple of months to use the updateDev site and not the main release update site. This is not an acceptable circumstance, the dev site is for internal or beta testing only, but the current release version of the plugin leaves me with no option. I know that there may be some refactoring coolness out there and I do not want to discourage progress in any way, but the current version of the plugin on the release site is quite frankly an embarrassment.
So given this state, I propose that we cut a release that includes Groovy 1.5.6 oand represents what is out there on the update development site, so that we can in good conscience tell people to point at the release update site. After the release of Groovy 1.5.7 so that we can accommodate the refactoring, we can include the new stuff and then release it to the development update site for evaluation. This is based on what I understood from the earlier emails that the refactoring work requires Groovy 1.5.7. After a time, a couple of weeks say, if it proves itself stable and ready, then lets push out a version to the main release site. This is relatively standard practice and I see no reason to circumvent it.
This does bring up an interesting point, a couple of years ago it was possible to get new versions of the plugin out quickly because there was a reliable set of beta testers that could give us feedback quickly. Scott Hickey's (the previous Groovy Eclipse lead) team working on a project would download the plugin and put it through its trials and we could find out trouble quickly. It would be interesting to discover if there is anyone out there who could fill this function. As an Eclipse developer, it is amazing how new eyes can find configuration, provisioning, installation and general plugin bugs when you thought everything was fine. This sort of feedback and work is vital.
If we can get regular activity restarted on the plugin (ahem... listening G2One?), I think that releases should occur at regular intervals of between 4 to 6 weeks, in line with common Agile iteration or spring intervals.
If no one has an issue with this, I will go ahead and build a new release and promote it to the main release update site.
As far as a roadmap goes, I had a brief chat with Scott Hickey (the old Groovy Eclipse plugin lead) and I think we came to a simple understanding.
* First, there is some major work that needs to be done under the hood to not have the plugin use the version of the groovy runtime installed in the workbench, but rather use the one that is set for the workspace.
* Second, there needs to be a structure like IJavaElement, or the equivalent, to allow the Groovy Eclipse plugin to support different versions of the Groovy libraries for different projects. The second issue is related to the first issue to some degree.
* Third, there needs to be better integration of the groovy compiler with Eclipse JDT support. I saw an example in the Scala Eclipse plugin where the project has the Eclipse Java nature added to the project, but the Java Builder was not added. This allows the Scala plugin to provide the scala tools to build the class files. I think that something like this should be done for Groovy Eclipse, especially since the groovy compiler will now compile java as well. This will also prevent collisions between the Java builder and the groovy builder.
* Fourth, we need to be chasing the standard that the good folks at IntelliJ have been blazing. The Groovy Eclipse plugin should try and provide most, if not all, the kind of support that IntelliJ is giving to Groovy now. I think what it does for dynamic methods is awesome.
* Fifth, refactoring tools need to be provided that are robust and first class. Hey great job y'all on this one, this kind of work aint easy. I am still intrigued by this notion, because I would love to see good dynamic language refactoring that is more than just grep and replace.
* Sixth, provide at least a basic level of support for Grails development. I know that there has been some work on providing Grails support, but I know it could only be of the very basic sort and there is so much in Grails that screams for IDE support. I mean how cool could it be to get help with writing those GORM domain classes for instance?
* Seventh, enable Eclipse Plugin Development using the Groovy language. This is really more of a personal desire, I think that Grails support or any of the other points I have listed would affect far more people. Still it would be nice to be able to do more and more Groovy Eclipse work in Groovy, right? I think so. As part of this effort we could try to leverage and improve Groovy support for EMF. Heck maybe we could make EMF usable! (*duck*)
* Eighth, as I stated above, if regular work can be restarted on the plugin, there should be regular releases on the order of 4 to 6 weeks apart.
* Ninth, after getting the plugin in a better state, we need to get companies like Genuitech, eBay and other eclipse distribution providers to start including the plugin, if not included by default, at least as an option. I will make a point to get it in to Genuitech's Pulse service.
Most of the points I came up with really were off the cuff, so if you can think of others, please don't keep it to yourself!
So given this state, I propose that we cut a release that includes Groovy 1.5.6 oand represents what is out there on the update development site, so that we can in good conscience tell people to point at the release update site. After the release of Groovy 1.5.7 so that we can accommodate the refactoring, we can include the new stuff and then release it to the development update site for evaluation. This is based on what I understood from the earlier emails that the refactoring work requires Groovy 1.5.7. After a time, a couple of weeks say, if it proves itself stable and ready, then lets push out a version to the main release site. This is relatively standard practice and I see no reason to circumvent it.
This does bring up an interesting point, a couple of years ago it was possible to get new versions of the plugin out quickly because there was a reliable set of beta testers that could give us feedback quickly. Scott Hickey's (the previous Groovy Eclipse lead) team working on a project would download the plugin and put it through its trials and we could find out trouble quickly. It would be interesting to discover if there is anyone out there who could fill this function. As an Eclipse developer, it is amazing how new eyes can find configuration, provisioning, installation and general plugin bugs when you thought everything was fine. This sort of feedback and work is vital.
If we can get regular activity restarted on the plugin (ahem... listening G2One?), I think that releases should occur at regular intervals of between 4 to 6 weeks, in line with common Agile iteration or spring intervals.
If no one has an issue with this, I will go ahead and build a new release and promote it to the main release update site.
As far as a roadmap goes, I had a brief chat with Scott Hickey (the old Groovy Eclipse plugin lead) and I think we came to a simple understanding.
* First, there is some major work that needs to be done under the hood to not have the plugin use the version of the groovy runtime installed in the workbench, but rather use the one that is set for the workspace.
* Second, there needs to be a structure like IJavaElement, or the equivalent, to allow the Groovy Eclipse plugin to support different versions of the Groovy libraries for different projects. The second issue is related to the first issue to some degree.
* Third, there needs to be better integration of the groovy compiler with Eclipse JDT support. I saw an example in the Scala Eclipse plugin where the project has the Eclipse Java nature added to the project, but the Java Builder was not added. This allows the Scala plugin to provide the scala tools to build the class files. I think that something like this should be done for Groovy Eclipse, especially since the groovy compiler will now compile java as well. This will also prevent collisions between the Java builder and the groovy builder.
* Fourth, we need to be chasing the standard that the good folks at IntelliJ have been blazing. The Groovy Eclipse plugin should try and provide most, if not all, the kind of support that IntelliJ is giving to Groovy now. I think what it does for dynamic methods is awesome.
* Fifth, refactoring tools need to be provided that are robust and first class. Hey great job y'all on this one, this kind of work aint easy. I am still intrigued by this notion, because I would love to see good dynamic language refactoring that is more than just grep and replace.
* Sixth, provide at least a basic level of support for Grails development. I know that there has been some work on providing Grails support, but I know it could only be of the very basic sort and there is so much in Grails that screams for IDE support. I mean how cool could it be to get help with writing those GORM domain classes for instance?
* Seventh, enable Eclipse Plugin Development using the Groovy language. This is really more of a personal desire, I think that Grails support or any of the other points I have listed would affect far more people. Still it would be nice to be able to do more and more Groovy Eclipse work in Groovy, right? I think so. As part of this effort we could try to leverage and improve Groovy support for EMF. Heck maybe we could make EMF usable! (*duck*)
* Eighth, as I stated above, if regular work can be restarted on the plugin, there should be regular releases on the order of 4 to 6 weeks apart.
* Ninth, after getting the plugin in a better state, we need to get companies like Genuitech, eBay and other eclipse distribution providers to start including the plugin, if not included by default, at least as an option. I will make a point to get it in to Genuitech's Pulse service.
Most of the points I came up with really were off the cuff, so if you can think of others, please don't keep it to yourself!
Friday, June 27, 2008
Notes from Eclipse Day at Googleplex
Before I go into any details, I want to say that the Google t-shirt that I got for attending was almost worth the airfare, hotel stay and car rental. Man am I a cheap date or what? Also I would be remiss if I didn't thank Robert Konigsberg and the rest of the Google Open Source Office for organizing the event.
It was great to meet Ian Skerrett, Bjorn Freeman-Benson
, and others that I have only had opportunity to communicate with over blogs or mailing lists. It was also nice to catch up with Chris Aniszczyk and Wes Isberg there as well. Of course while this is all nice and dandy, lets get to the actual event.
Eclipse @ eBay: Michael Galpin
Mr. Michael Galpin did what amounted to the "keynote" address of the event. He went into a brief history of eBay and the technologies used to develop the site and then went into some of the work that has been done at eBay with Eclipse. Before I continue, I should mention that I worked as a contractor for eBay for a little over a year and that I have a better perspective than most on what is going on there. eBay is HUGE into Eclipse, in fact, I wonder if there are many organizations more committed to using Eclipse and working on creating developer tools using Eclipse. Still I found the presentation on what eBay is doing with V4 in the presentation layer quite eye opening. I was working on an Eclipse plugin to support their internal SOA framework, so I was a bit segregated from V4 work. Now I kinda wish I wasn't so segregated, some of it is quite cool. I mean I know I always wanted to leverage Dervlets, but Spyglass is pretty cool. There is a nice PDF of the presentation notes available at this link. One thing to note is how Java centric eBay really is, just about everything is a Java class. I wish I had asked during my time there why the decision was made to do that, particularly the tradeoffs. One other thing, I wish my plugin work and the SOA framework had garnered a bullet in that presentation somewhere, oh well. I mean Wes Isberg's simple, but cool, Auto-configuration plugin got a mention. Not that I am jealous or anything. ;)
One final note, Mr. Galpin literally said that there are plans to open source all the tools shown during that presentation. People should hold them to that promise.
How Mylyn Changes the Way I Develop: Bjorn Freeman-Benson
After the eBay session, the event bifurcated into two parallel tracks. The net effect was that you needed to choose which event to attend. While I have an abstract interest in CDT at the current moment, I was more intrigued by the session on Mylyn. I mean I have tried to use it and I see the arguments for something like that. What I haven't done is well, get it. I have tried it and never managed to successfully integrate it into my workflows. I have gotten to know and respect Mr. Freeman-Benson while interacting with him over at the Eclipse Dash project, so I was hopeful he might allow me to 'get it' or at least motivate me to try again.
Before I get into the notes I have from the presentation I need to pass off some advice. This goes to Bjorn or anyone else giving a presentation, don't ever give a presentation that someone else prepared, period. I know it was probably due to the fact that Bjorn was stepping in for someone else, but yikes.
In the beginning Bjorn covered the motivation for Mylyn, things that I think everyone will admit that modern software engineers have to deal with even with a nice IDE like Eclipse. The problems are the need to context switch, to mulitask and to manage information overload. He did not go into the traditional ways that developers in Eclipse try to manage this, but it bears mentioning. Eclipse users usually use multiple workspaces, multiple workbench instances and try to make use of things like project/team sets. None of the traditional ways are satisfactory. So what is Mylyn's approach? First off, I love this, Mylyn allows you to keep all your stuff in just one workspace. Mylyn's focus is on cutting down the full workspace to only those elements that you need at a given time.
So how does Mylyn accomplish some of this? Well in Mylyn the notion of a task is made a first class citizen. Before you do anything in Eclipse using Mylyn, you need to do it in the context of a task. Mylyn has stuff to manage tasks and to integrate with common issue tracking packages like Bugzilla and JIRA, among others. Mylyn also allows you to be able to acquire your tasks from multiple sources. So once you have a task, Mylyn stores contextual information about what elements in the workspace you associate with a given task. This is where some of the black magic kicks in, Mylyn has a Degree of Interest Model that it maintains in order to know what to filter out of your views. This has always been the rub for me to start with Mylyn, everything is hidden at first and you must start from a task.
The cool thing though is that once a context is created, it is possible to share that easily with other team members. Now the cool thing for me is that the context is not shared via a team provider, but that Mylyn will create an attachment in the issue tracker that another team member can use automatically in their Eclipse workbench using Mylyn. I love that since it is logically associated with the task and that they did not punt the trouble to the team provider.
Another cool item, in fact, a killer app type item for those who like Agile software development methodologies, is the automatic time tracker. When you are using Eclipse with Mylyn, you are always with in the context of a task, so when you are doing stuff in the IDE then, Mylyn will keep a timer. This is a killer app, since anyone who does agile knows that the most difficult thing to do is to estimate the time to implement a given feature. In fact, it is so difficult that XP for instance tells you to use 'yesterday's weather', in other words, look at the last time you had to implement a given feature, and use that time. Well that only works if you accurately track your time on task. Mylyn could make this seamless and easy. This feature alone makes me want to use Mylyn, even if I leave the filtering off all the time.
I want to make one more comment about the presentation on Mylyn concerning workspace provisioning. Bjorn went into alot of Q&A with the audience and did cover more details of Mylyn. Still, what struck me about the presentation was how close Mylyn is to a full workspace provisioning solution. I need to look at Eclipse Buckminster and check out Genuitech's Pulse product again. Workspace provisioning for me is almost as big a deal as P2 and the Eclipse provisioning effort. I mean how long does it take for new people to be able to install Eclipse and get all they need to be able to check out the code from SCM and start working with it? I mean really, how long, do you even know?
Building Great RIA with ATF: Philippe Ombredanne
First off, I want to say I got the chance to meet Philippe at this event and I really like him. Second, is there any Eclipse project that he hasn't been intimately involved with? I think the list of projects at Eclipse he has been involved with would rival some of my earliest Christmas wish lists to Santa, I mean wow! Most of the presentation (at least the part that I was able to grok) covered the ATF project's live Javascript debugger. I am not an AJAX developer, so I admit much of what he showed was a bit lost on me, but even I admit the fact that you could monitor requests easily. He demonstrated how a click in the ATF embedded browser to Google Maps would show up as request response pairs in a nice viewer inside Eclipse. Makes me want to try and do some Web mashups (me even!). The other thing that struck me was the fact that they took the Mozilla Firefox XUL Runner build and embedded it as a bundle inside of Eclipse. I thought that was cool, since it provides an embedded browser to play with that is not the Eclipse default browser and I wonder what kind of API I could potentially play with. You know I am thinking a Groovy/Eclipse Monkey script to try it out. Awww yeah!
Wiring Hacker Synapses: Collaborative Coding and Team Tooling in Eclipse: Scott Lewis & Mustafa K. Isik
First off I want to say that I love what this demo and plugin could entail. Being able to do shared sessions on the same document is the first step towards better collaboration and hopefully better software development in general. If you haven't seen the video, go Google for Cola and ECF and check it out. The simple demo that Mustafa did there was in the most part better than attending this presentation. I wish he had done some more demo instead of theory. Still this is a good first step. The problem comes later. With shared sessions, how do you integrate properly with Team providers and make sure that the workspaces are provisioned correctly? I think that they should focus on allowing a remote Eclipse user to "shadow" the workspace of a local Eclipse user. This way you have a "master" workspace that the local user is responsible for provisioning and the responsibility is removed from the remote user. Still ECF is very cool, I wish them the best of luck.
Concluding Remarks
At the end of the sessions, there was free food and adult beverages for all. I ran one of the two demo stations there. In hindsight, I think that expecting people to really have any more brainpower to devote to Eclipse after five continuous hours of sessions was a bit much. Still I really want to thank those that came over and gave me the chance to show off Groovy Monkey and discuss my plans for Eclipse Monkey.
Once again thanks to Google and to the folks at the Eclipse foundation for showing up. Thanks to all the participants who attended. The event was, for the most part, packed, not the smaller affairs that Eclipse Democamps that I have attended in the past have been.
It was great to meet Ian Skerrett, Bjorn Freeman-Benson
, and others that I have only had opportunity to communicate with over blogs or mailing lists. It was also nice to catch up with Chris Aniszczyk and Wes Isberg there as well. Of course while this is all nice and dandy, lets get to the actual event.
Eclipse @ eBay: Michael Galpin
Mr. Michael Galpin did what amounted to the "keynote" address of the event. He went into a brief history of eBay and the technologies used to develop the site and then went into some of the work that has been done at eBay with Eclipse. Before I continue, I should mention that I worked as a contractor for eBay for a little over a year and that I have a better perspective than most on what is going on there. eBay is HUGE into Eclipse, in fact, I wonder if there are many organizations more committed to using Eclipse and working on creating developer tools using Eclipse. Still I found the presentation on what eBay is doing with V4 in the presentation layer quite eye opening. I was working on an Eclipse plugin to support their internal SOA framework, so I was a bit segregated from V4 work. Now I kinda wish I wasn't so segregated, some of it is quite cool. I mean I know I always wanted to leverage Dervlets, but Spyglass is pretty cool. There is a nice PDF of the presentation notes available at this link. One thing to note is how Java centric eBay really is, just about everything is a Java class. I wish I had asked during my time there why the decision was made to do that, particularly the tradeoffs. One other thing, I wish my plugin work and the SOA framework had garnered a bullet in that presentation somewhere, oh well. I mean Wes Isberg's simple, but cool, Auto-configuration plugin got a mention. Not that I am jealous or anything. ;)
One final note, Mr. Galpin literally said that there are plans to open source all the tools shown during that presentation. People should hold them to that promise.
How Mylyn Changes the Way I Develop: Bjorn Freeman-Benson
After the eBay session, the event bifurcated into two parallel tracks. The net effect was that you needed to choose which event to attend. While I have an abstract interest in CDT at the current moment, I was more intrigued by the session on Mylyn. I mean I have tried to use it and I see the arguments for something like that. What I haven't done is well, get it. I have tried it and never managed to successfully integrate it into my workflows. I have gotten to know and respect Mr. Freeman-Benson while interacting with him over at the Eclipse Dash project, so I was hopeful he might allow me to 'get it' or at least motivate me to try again.
Before I get into the notes I have from the presentation I need to pass off some advice. This goes to Bjorn or anyone else giving a presentation, don't ever give a presentation that someone else prepared, period. I know it was probably due to the fact that Bjorn was stepping in for someone else, but yikes.
In the beginning Bjorn covered the motivation for Mylyn, things that I think everyone will admit that modern software engineers have to deal with even with a nice IDE like Eclipse. The problems are the need to context switch, to mulitask and to manage information overload. He did not go into the traditional ways that developers in Eclipse try to manage this, but it bears mentioning. Eclipse users usually use multiple workspaces, multiple workbench instances and try to make use of things like project/team sets. None of the traditional ways are satisfactory. So what is Mylyn's approach? First off, I love this, Mylyn allows you to keep all your stuff in just one workspace. Mylyn's focus is on cutting down the full workspace to only those elements that you need at a given time.
So how does Mylyn accomplish some of this? Well in Mylyn the notion of a task is made a first class citizen. Before you do anything in Eclipse using Mylyn, you need to do it in the context of a task. Mylyn has stuff to manage tasks and to integrate with common issue tracking packages like Bugzilla and JIRA, among others. Mylyn also allows you to be able to acquire your tasks from multiple sources. So once you have a task, Mylyn stores contextual information about what elements in the workspace you associate with a given task. This is where some of the black magic kicks in, Mylyn has a Degree of Interest Model that it maintains in order to know what to filter out of your views. This has always been the rub for me to start with Mylyn, everything is hidden at first and you must start from a task.
The cool thing though is that once a context is created, it is possible to share that easily with other team members. Now the cool thing for me is that the context is not shared via a team provider, but that Mylyn will create an attachment in the issue tracker that another team member can use automatically in their Eclipse workbench using Mylyn. I love that since it is logically associated with the task and that they did not punt the trouble to the team provider.
Another cool item, in fact, a killer app type item for those who like Agile software development methodologies, is the automatic time tracker. When you are using Eclipse with Mylyn, you are always with in the context of a task, so when you are doing stuff in the IDE then, Mylyn will keep a timer. This is a killer app, since anyone who does agile knows that the most difficult thing to do is to estimate the time to implement a given feature. In fact, it is so difficult that XP for instance tells you to use 'yesterday's weather', in other words, look at the last time you had to implement a given feature, and use that time. Well that only works if you accurately track your time on task. Mylyn could make this seamless and easy. This feature alone makes me want to use Mylyn, even if I leave the filtering off all the time.
I want to make one more comment about the presentation on Mylyn concerning workspace provisioning. Bjorn went into alot of Q&A with the audience and did cover more details of Mylyn. Still, what struck me about the presentation was how close Mylyn is to a full workspace provisioning solution. I need to look at Eclipse Buckminster and check out Genuitech's Pulse product again. Workspace provisioning for me is almost as big a deal as P2 and the Eclipse provisioning effort. I mean how long does it take for new people to be able to install Eclipse and get all they need to be able to check out the code from SCM and start working with it? I mean really, how long, do you even know?
Building Great RIA with ATF: Philippe Ombredanne
First off, I want to say I got the chance to meet Philippe at this event and I really like him. Second, is there any Eclipse project that he hasn't been intimately involved with? I think the list of projects at Eclipse he has been involved with would rival some of my earliest Christmas wish lists to Santa, I mean wow! Most of the presentation (at least the part that I was able to grok) covered the ATF project's live Javascript debugger. I am not an AJAX developer, so I admit much of what he showed was a bit lost on me, but even I admit the fact that you could monitor requests easily. He demonstrated how a click in the ATF embedded browser to Google Maps would show up as request response pairs in a nice viewer inside Eclipse. Makes me want to try and do some Web mashups (me even!). The other thing that struck me was the fact that they took the Mozilla Firefox XUL Runner build and embedded it as a bundle inside of Eclipse. I thought that was cool, since it provides an embedded browser to play with that is not the Eclipse default browser and I wonder what kind of API I could potentially play with. You know I am thinking a Groovy/Eclipse Monkey script to try it out. Awww yeah!
Wiring Hacker Synapses: Collaborative Coding and Team Tooling in Eclipse: Scott Lewis & Mustafa K. Isik
First off I want to say that I love what this demo and plugin could entail. Being able to do shared sessions on the same document is the first step towards better collaboration and hopefully better software development in general. If you haven't seen the video, go Google for Cola and ECF and check it out. The simple demo that Mustafa did there was in the most part better than attending this presentation. I wish he had done some more demo instead of theory. Still this is a good first step. The problem comes later. With shared sessions, how do you integrate properly with Team providers and make sure that the workspaces are provisioned correctly? I think that they should focus on allowing a remote Eclipse user to "shadow" the workspace of a local Eclipse user. This way you have a "master" workspace that the local user is responsible for provisioning and the responsibility is removed from the remote user. Still ECF is very cool, I wish them the best of luck.
Concluding Remarks
At the end of the sessions, there was free food and adult beverages for all. I ran one of the two demo stations there. In hindsight, I think that expecting people to really have any more brainpower to devote to Eclipse after five continuous hours of sessions was a bit much. Still I really want to thank those that came over and gave me the chance to show off Groovy Monkey and discuss my plans for Eclipse Monkey.
Once again thanks to Google and to the folks at the Eclipse foundation for showing up. Thanks to all the participants who attended. The event was, for the most part, packed, not the smaller affairs that Eclipse Democamps that I have attended in the past have been.
Monday, June 23, 2008
Don't call it a static or dynamic language!
I was talking the other day with someone recruiting me for a position. Smart organizations will contact you with someone who can try and sift the wheat from the chaff. In other words, they'll ask you questions in particular computer science or even, *gasp*, Java questions. Well this one guy asked me a standard question, 'what are the advantages and disadvantages of statically typed versus dynamically typed languages?' Now the full debate on that question could not only fill a whole series of blog entries, but could be a book by itself, which I will not get into here. Still as I was giving my answer I prefaced my comments by saying something that I have put a fair bit of thought into, which was: 'I don't like the name static or dynamic typing, I prefer the notion of implicitly typed and explicitly typed languages.'
Definitions
First off let me start with the definitions of explicit and implicit, both of these are horked from Merriam Webster Online. Implicit is defined as "capable of being understood from something else though unexpressed : implied or involved in the nature or essence of something though not revealed, expressed, or developed." Explicit would be defined as "fully revealed or expressed without vagueness, implication, or ambiguity : leaving no question as to meaning or intent" or as "fully developed or formulated ." I think a good way to think about this is to consider the following question, "are details hidden from you or not?"
WTF (What The Friendly) does this have to do with Programming Languages?
I think if you consider it for a while, the language debate between statically and dynamically typed is clearer when it is considered in terms of whether it emphasizes implicitness or explicitness. First off, all languages and programming platforms are implicit to some degree, since there is no way to encapsulate all of the factors that go into programming a software system to a developer. If they did, the resulting interface to the developer would probably be enough to make an airline pilot's jaw drop. Still the point applies if you focus on types. Most of the debate about programming languages focuses on the issues of types, so it is a good area to concern ourselves with. By my reckoning, a strongly/statically typed language, like Java for instance, would be considered 'explicitly typed' in this nomenclature. A dynamically/weakly typed language, like Python or Ruby for instance, would be called an 'implicitly typed' language from now on. An optionally typed language like Groovy would be optionally explicit or optionally implicit, depending on the developers mood that day. ;)
Actually in my opinion, most of the interest in Groovy is due to its 'implicit' capabilities and therefore I would really put in that category. I know you can explicitly type things in Groovy, but that is really an enabling feature. Enabling feature, you say? Yeah, an enabling feature, kinda like (Note: I have no personal experience with the following analogy, really...) how a drug dealer might give out free samples to hook you in and then afterwords start charging. So being able to specify types in Groovy gives Java developers, like myself, a warm fuzzy about trying out the new features and, therefore, try out the Groovy language.
Ok this is awfully pedantic, so what?
So the question that might be formulating in your mind is, "ok so you have a new definition, how does this help anything?" Well for one thing, no matter what you do with software code, the types are there, period. The difference is if they are hidden or not. In the next few sections I am going to compare equivalent sections of code in Java and in Groovy, but I think that the point holds if we were in Ruby, Smalltalk or Python, even though the examples would vary.
I want to show a quick example from groovy and Java, in this I am going to create an instance of ArrayList:
Java(5.0+):
List<> list = new ArrayList<>();
Groovy:
def list = []
So let me ask you a question? What is the difference in this case? Well for one the amount of actual keystrokes to write the examples. Beyond that, there is not much difference, in both cases you have a variable declaration of list that is initialized with a java.util.ArrayList instance. So what is the advantage of the Java version? Well Java's explicitness is key here, you know straight away that list is of type java.util.List and that it is an instance of java.util.ArrayList. Therefore, someone new to the Java platform would probably have an easier time figuring out what is going on in the Java line(at least not including generics, which is another post entirely) than with the Groovy line. To understand the groovy line you need to know that the array notation is shorthand for instantiating a List object and that by default an ArrayList is used, therefore I would term Groovy an "implicit" language in this case.
One other not so small point, if I was looking at this from a tool developer's viewpoint, I prefer the Java version to the Groovy version, in probably just about every case. In general, it is easier to write tools to analyze and provide support to base Java (or other explicitly typed language) than it is to any implicitly (read: dynamic) typed language.
Another example, I am going to do the simple "HelloWorld" application in both Groovy and Java:
Java: HelloWorld.java
public class HelloWorld
{
public static void main( String[] args )
{
System.out.println( "Hello World!" );
}
}
Groovy: HelloWorld.groovy
println "Hello World!"
This is the example that should drive the point home. What is the difference? In the end the bytecode will be functionally the same in both the Groovy and Java cases (Notice I don't say that the bytecode would be exactly the same). The big difference is that the Java version is explicit, not only about types, but also in requiring a class definition and explicit main method. In Groovy, the type is inferred implicitly from the file name and the main method is also implied.
What about the tools man?
The final example I want to consider is the Domain Specific Language (DSL) in the two kinds of languages. Actually, I lied, I am only going to show an example of a builder in Groovy and skip showing the example in Java, because the example for Java would be far too painful to consider. I want to consider the following example because I want to get to the point about what 'explicit' versus 'implicit' means for tool developers.
Example: AntBuilder (Groovy)
// Going to zip up a file
def ant = new AntBuilder()
ant.zip( destfile:"${zip.location}", basedir:"${project.location}" )
What all is going on here? You have an instance of AntBuilder being created and a method called zip being invoked. There is an example of named parameters, which is a very cool feature for Groovy I think. Finally, you see there two GStrings (Groovy Strings, quite the name no?) with its built in templating. There is a lot going on here, someone wanting to write a tool would probably take a deep breath, but envision that he/she will be able to do it. The trick is what about the zip method. What about the zip method? Lets get to that next.
In the previous examples, the types and their signatures are just below the surface so to speak. The notation '[]' is a shorthand for java.util.List and in the case where the statements are just put into the Groovy file without a class definition, means there is an implicit class definition and static main method. In the above example, there is no such nicety. Why would I say that? I mean the variable ant is an instance of AntBuilder right? Yes, but look at the javadoc for AntBuilder, where is the method definition for zip? There is not one, but if you want to see for yourself go ahead and look, I'll wait.
The AntBuilder class is an example of a Builder in Groovy which does something like what java.lang.reflect.Proxy does. Proxy provides an InvocationHandler, which has a method called invoke() which the Java platform provides as a hook to allow you to provide runtime implementations of arbitrary types. The Groovy Builder support allows for creation of nodes and invocation of methods on those nodes. All of this means that not only is the full type definition for AntBuilder implicit, but that there is really no way at compile time to figure it out. What I mean is that there is no way for a source code tool developer to write general tools to provide the kind of language support that is available in explicitly typed languages for DSLs. In the first two examples, you could easily imagine being able to provide tooling support for those cases, the types and signatures were implicit, but they could be figured out relatively simply, there is no real way to do it in the last case.
Tooling support is an area that is usually skipped in alot of discussions on explicitly typed versus implicitly typed languages. It is dismissed by implicit proponents with, "well tooling will just catch up." I don't consider it trivial and, having dabbled a bit in providing IDE support for Groovy, I don't assume that the tooling will just be there in the future. Implicitly typed language designers and proponents need to give this its full consideration, elsewise the best your language could hope for is to be the next Lisp, praised by some and used by none.
Conclusion
So the difference between the two languages in the above examples is best exemplified by asking three questions. First, which version do you think someone new to your codebase or the Java platform would understand better? Usually an explicitly typed language like Java (or maybe Scala/Haskell) would be favored. Second, which version do you think someone with experience with your codebase or the Java platform would prefer to write? Usually, I would think that an implicit language like Groovy, Ruby or even Python would be preferred. Third, what kind of tool, particularly IDE support do you want or need? If your project thinks that the first question is more important than the second one, then an explicit language like Java should be your choice. If the second question seems more important, then an implicit language like Groovy should be your choice. The third question can only be answered by surveying what is available and trying it out to see if it is good enough.
Definitions
First off let me start with the definitions of explicit and implicit, both of these are horked from Merriam Webster Online. Implicit is defined as "capable of being understood from something else though unexpressed : implied
WTF (What The Friendly) does this have to do with Programming Languages?
I think if you consider it for a while, the language debate between statically and dynamically typed is clearer when it is considered in terms of whether it emphasizes implicitness or explicitness. First off, all languages and programming platforms are implicit to some degree, since there is no way to encapsulate all of the factors that go into programming a software system to a developer. If they did, the resulting interface to the developer would probably be enough to make an airline pilot's jaw drop. Still the point applies if you focus on types. Most of the debate about programming languages focuses on the issues of types, so it is a good area to concern ourselves with. By my reckoning, a strongly/statically typed language, like Java for instance, would be considered 'explicitly typed' in this nomenclature. A dynamically/weakly typed language, like Python or Ruby for instance, would be called an 'implicitly typed' language from now on. An optionally typed language like Groovy would be optionally explicit or optionally implicit, depending on the developers mood that day. ;)
Actually in my opinion, most of the interest in Groovy is due to its 'implicit' capabilities and therefore I would really put in that category. I know you can explicitly type things in Groovy, but that is really an enabling feature. Enabling feature, you say? Yeah, an enabling feature, kinda like (Note: I have no personal experience with the following analogy, really...) how a drug dealer might give out free samples to hook you in and then afterwords start charging. So being able to specify types in Groovy gives Java developers, like myself, a warm fuzzy about trying out the new features and, therefore, try out the Groovy language.
Ok this is awfully pedantic, so what?
So the question that might be formulating in your mind is, "ok so you have a new definition, how does this help anything?" Well for one thing, no matter what you do with software code, the types are there, period. The difference is if they are hidden or not. In the next few sections I am going to compare equivalent sections of code in Java and in Groovy, but I think that the point holds if we were in Ruby, Smalltalk or Python, even though the examples would vary.
I want to show a quick example from groovy and Java, in this I am going to create an instance of ArrayList:
Java(5.0+):
List<> list = new ArrayList<>();
Groovy:
def list = []
So let me ask you a question? What is the difference in this case? Well for one the amount of actual keystrokes to write the examples. Beyond that, there is not much difference, in both cases you have a variable declaration of list that is initialized with a java.util.ArrayList instance. So what is the advantage of the Java version? Well Java's explicitness is key here, you know straight away that list is of type java.util.List and that it is an instance of java.util.ArrayList. Therefore, someone new to the Java platform would probably have an easier time figuring out what is going on in the Java line(at least not including generics, which is another post entirely) than with the Groovy line. To understand the groovy line you need to know that the array notation is shorthand for instantiating a List object and that by default an ArrayList is used, therefore I would term Groovy an "implicit" language in this case.
One other not so small point, if I was looking at this from a tool developer's viewpoint, I prefer the Java version to the Groovy version, in probably just about every case. In general, it is easier to write tools to analyze and provide support to base Java (or other explicitly typed language) than it is to any implicitly (read: dynamic) typed language.
Another example, I am going to do the simple "HelloWorld" application in both Groovy and Java:
Java: HelloWorld.java
public class HelloWorld
{
public static void main( String[] args )
{
System.out.println( "Hello World!" );
}
}
Groovy: HelloWorld.groovy
println "Hello World!"
This is the example that should drive the point home. What is the difference? In the end the bytecode will be functionally the same in both the Groovy and Java cases (Notice I don't say that the bytecode would be exactly the same). The big difference is that the Java version is explicit, not only about types, but also in requiring a class definition and explicit main method. In Groovy, the type is inferred implicitly from the file name and the main method is also implied.
What about the tools man?
The final example I want to consider is the Domain Specific Language (DSL) in the two kinds of languages. Actually, I lied, I am only going to show an example of a builder in Groovy and skip showing the example in Java, because the example for Java would be far too painful to consider. I want to consider the following example because I want to get to the point about what 'explicit' versus 'implicit' means for tool developers.
Example: AntBuilder (Groovy)
// Going to zip up a file
def ant = new AntBuilder()
ant.zip( destfile:"${zip.location}", basedir:"${project.location}" )
What all is going on here? You have an instance of AntBuilder being created and a method called zip being invoked. There is an example of named parameters, which is a very cool feature for Groovy I think. Finally, you see there two GStrings (Groovy Strings, quite the name no?) with its built in templating. There is a lot going on here, someone wanting to write a tool would probably take a deep breath, but envision that he/she will be able to do it. The trick is what about the zip method. What about the zip method? Lets get to that next.
In the previous examples, the types and their signatures are just below the surface so to speak. The notation '[]' is a shorthand for java.util.List and in the case where the statements are just put into the Groovy file without a class definition, means there is an implicit class definition and static main method. In the above example, there is no such nicety. Why would I say that? I mean the variable ant is an instance of AntBuilder right? Yes, but look at the javadoc for AntBuilder, where is the method definition for zip? There is not one, but if you want to see for yourself go ahead and look, I'll wait.
The AntBuilder class is an example of a Builder in Groovy which does something like what java.lang.reflect.Proxy does. Proxy provides an InvocationHandler, which has a method called invoke() which the Java platform provides as a hook to allow you to provide runtime implementations of arbitrary types. The Groovy Builder support allows for creation of nodes and invocation of methods on those nodes. All of this means that not only is the full type definition for AntBuilder implicit, but that there is really no way at compile time to figure it out. What I mean is that there is no way for a source code tool developer to write general tools to provide the kind of language support that is available in explicitly typed languages for DSLs. In the first two examples, you could easily imagine being able to provide tooling support for those cases, the types and signatures were implicit, but they could be figured out relatively simply, there is no real way to do it in the last case.
Tooling support is an area that is usually skipped in alot of discussions on explicitly typed versus implicitly typed languages. It is dismissed by implicit proponents with, "well tooling will just catch up." I don't consider it trivial and, having dabbled a bit in providing IDE support for Groovy, I don't assume that the tooling will just be there in the future. Implicitly typed language designers and proponents need to give this its full consideration, elsewise the best your language could hope for is to be the next Lisp, praised by some and used by none.
Conclusion
So the difference between the two languages in the above examples is best exemplified by asking three questions. First, which version do you think someone new to your codebase or the Java platform would understand better? Usually an explicitly typed language like Java (or maybe Scala/Haskell) would be favored. Second, which version do you think someone with experience with your codebase or the Java platform would prefer to write? Usually, I would think that an implicit language like Groovy, Ruby or even Python would be preferred. Third, what kind of tool, particularly IDE support do you want or need? If your project thinks that the first question is more important than the second one, then an explicit language like Java should be your choice. If the second question seems more important, then an implicit language like Groovy should be your choice. The third question can only be answered by surveying what is available and trying it out to see if it is good enough.
Subscribe to:
Posts (Atom)
Posts
