14.2.05
Links comments
I received useful comments on Links from Garry Hodgson, Amanda Clare, and Rodrigo Barnes. (Posted with permission.)
--------
From Garry Hodgson
i hope you are successful. i worry, though, that much of the focus in your outline is on the language technology, and not on the ecosystem surrounding the language which, i believe, is what will make it "as widely used as python" or not. perl, python, java, etc. are not popular primarily based on their language design.
everyone on this list uses highly advanced languages on a daily basis. but if i want to write a mail or http client or server, or parse or generate xml, or run a unix process and gets its exist code and output, or whatever, how do i do that? yes, there are libraries out there, but i have to go find them, and build them, and integrate them, etc. and this raises the threshold of pain sufficiently high that it's usually easier to just use what i've got.
mind you, i'm a big fan of FP. i use erlang and ocaml whenever i can. but it costs me a lot of effort to do so, both in finding what i need and in justifying the decision. if you want to read the vast majority of users who don't already want to use FP, you'll need to make it easy to do so.
a while back, python was using the slogan "batteries included" to get this idea across. while y'all are designing the ultimate "take over the world" functional language, please don't forget the batteries.
-- Garry Hodgson, Technical Consultant, AT&T Labs
--------
From Amanda Clare
I'll be busy attending NESC's Globus Week in Edinburgh on that date, so won't be able to come (I'm not a language designer anyway, so wouldn't have been much use at this stage). But I love the idea and would be happy to be a real-world user to test any system you make. Python usually wins out over Haskell nowadays for me for most apps I have to say for practical reasons.
Currently my project involves Grid technology - Java-based Globus, to grid-enable laboratory automation systems. The object oriented approach the Globus team have taken to the whole Grid and web services concept (and the WSRF team as well) frequently have me amazed at how complicated they have to make it all.
Just to give an example from Borja Sotomayor's excellent tutorial
(http://gdp.globus.org/gt4-tutorial/):
> Whoa! Three Java classes to implement something as simple
> as addition and subtraction? Yes, it's true. But that's simply
> the price you have to pay for statefulness. Before looking at
> the Java code, let's make sure we understand how these three
> implementation files are related.
(and this is step 2 of a 5 step process to make a web service)
There has to be a better way. Even if in future they automate some of the steps (eg automatically generate WSDL so that I don't have to remember to name my Java get/set methods exactly the same as the resource properties in the WSDL file, and so on), I just feel less and less like I'm in control or have a good feel for what's happening, or understand the interactions and errors.
On the plus side I was interested to see that Polar Humenn had used Haskell as a language for describing XACML policies, so maybe Haskell ideas will sidle into Grid/Globus in the future.
Amanda Clare
--------
From Rodrigo Barnes
I've spent quite a bit of time (8+ years) developing and managing development of networked applications which can be a painful thing! Clearly anything that could make it a more pleasant experience would be worthwhile. On top of that the possibility of developing a new language (in the broadest sense) for this purpose would be interesting in its own right.
As an aside - on the J2EE front have you tracked the workings of http://www.springframework.org ? We've used it in our latest project and it's certainly made some aspects nicer as well as clearer and easier to maintain. Spring + Hibernate (http://www.hibernate.org) is proving a popular complement and/or alternative to the J2EE stack (EJBs and the like).
In general, my concern with such a project, having also spent quite a bit of time developing tools in academia, is that it aims to prove points rather than developing industrially viable tools (witness e.g. some of the problems in getting e-science tools to market). Having said that you only get the chance to develop this sort of innovation in a research context.
Another idea that might appeal to the group is to look at development tools, such as IntelliJ IDEA (http://www.jetbrains.com/) which along with Eclipse (http://www.eclipse.org) made refactoring tools easy to use for the working Java programmer. When I first saw IDEA it struck me they just went through Martin Fowler's 'Refactoring' book and used it as a requirements doc. So if you took his Patterns of Enterprise Application Architecture book (http://www.martinfowler.com/books.html#eaa) what tool would you get?
-- Rodrigo Barnes
--------
--------
From Garry Hodgson
i hope you are successful. i worry, though, that much of the focus in your outline is on the language technology, and not on the ecosystem surrounding the language which, i believe, is what will make it "as widely used as python" or not. perl, python, java, etc. are not popular primarily based on their language design.
everyone on this list uses highly advanced languages on a daily basis. but if i want to write a mail or http client or server, or parse or generate xml, or run a unix process and gets its exist code and output, or whatever, how do i do that? yes, there are libraries out there, but i have to go find them, and build them, and integrate them, etc. and this raises the threshold of pain sufficiently high that it's usually easier to just use what i've got.
mind you, i'm a big fan of FP. i use erlang and ocaml whenever i can. but it costs me a lot of effort to do so, both in finding what i need and in justifying the decision. if you want to read the vast majority of users who don't already want to use FP, you'll need to make it easy to do so.
a while back, python was using the slogan "batteries included" to get this idea across. while y'all are designing the ultimate "take over the world" functional language, please don't forget the batteries.
-- Garry Hodgson, Technical Consultant, AT&T Labs
--------
From Amanda Clare
I'll be busy attending NESC's Globus Week in Edinburgh on that date, so won't be able to come (I'm not a language designer anyway, so wouldn't have been much use at this stage). But I love the idea and would be happy to be a real-world user to test any system you make. Python usually wins out over Haskell nowadays for me for most apps I have to say for practical reasons.
Currently my project involves Grid technology - Java-based Globus, to grid-enable laboratory automation systems. The object oriented approach the Globus team have taken to the whole Grid and web services concept (and the WSRF team as well) frequently have me amazed at how complicated they have to make it all.
Just to give an example from Borja Sotomayor's excellent tutorial
(http://gdp.globus.org/gt4-tutorial/):
> Whoa! Three Java classes to implement something as simple
> as addition and subtraction? Yes, it's true. But that's simply
> the price you have to pay for statefulness. Before looking at
> the Java code, let's make sure we understand how these three
> implementation files are related.
(and this is step 2 of a 5 step process to make a web service)
There has to be a better way. Even if in future they automate some of the steps (eg automatically generate WSDL so that I don't have to remember to name my Java get/set methods exactly the same as the resource properties in the WSDL file, and so on), I just feel less and less like I'm in control or have a good feel for what's happening, or understand the interactions and errors.
On the plus side I was interested to see that Polar Humenn had used Haskell as a language for describing XACML policies, so maybe Haskell ideas will sidle into Grid/Globus in the future.
Amanda Clare
--------
From Rodrigo Barnes
I've spent quite a bit of time (8+ years) developing and managing development of networked applications which can be a painful thing! Clearly anything that could make it a more pleasant experience would be worthwhile. On top of that the possibility of developing a new language (in the broadest sense) for this purpose would be interesting in its own right.
As an aside - on the J2EE front have you tracked the workings of http://www.springframework.org ? We've used it in our latest project and it's certainly made some aspects nicer as well as clearer and easier to maintain. Spring + Hibernate (http://www.hibernate.org) is proving a popular complement and/or alternative to the J2EE stack (EJBs and the like).
In general, my concern with such a project, having also spent quite a bit of time developing tools in academia, is that it aims to prove points rather than developing industrially viable tools (witness e.g. some of the problems in getting e-science tools to market). Having said that you only get the chance to develop this sort of innovation in a research context.
Another idea that might appeal to the group is to look at development tools, such as IntelliJ IDEA (http://www.jetbrains.com/) which along with Eclipse (http://www.eclipse.org) made refactoring tools easy to use for the working Java programmer. When I first saw IDEA it struck me they just went through Martin Fowler's 'Refactoring' book and used it as a requirements doc. So if you took his Patterns of Enterprise Application Architecture book (http://www.martinfowler.com/books.html#eaa) what tool would you get?
-- Rodrigo Barnes
--------
