The Artima Developer Community
Sponsored Link

Weblogs Forum
JavaOne 2005, Day 1: It's a Groovy Day

14 replies on 1 page. Most recent reply: Oct 16, 2006 8:45 AM by Vadim Voituk

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 14 replies on 1 page
Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

JavaOne 2005, Day 1: It's a Groovy Day (View in Weblogs)
Posted: Jun 28, 2005 11:16 AM
Reply to this message Reply
Summary
Groovy is a Java-compatible scripting language that blends features from Ruby, Python, and Smalltalk. If you need robust ANT scripts, super shell scripts, or want to write fast unit tests, you may want to try something Groovy, for a change.
Advertisement

God, I love the JavaOne conference. Running from session to session; sipping information through one fire hose after another; writing my reports in the evenings, in the mornings, and in spare moments during the day--and guzzling caffeine to get it all done. But even more stimulating than the caffeine is the pure intellectual high of discovering new things and finding out how they work. Besides, the walking is good exercise, and pumps my brain full of oxygen. Thank God the convention only lasts 4 days, though. Right now, I'm jazzed. By Friday, I'll be wiped.

As always, I'll be bringing you reports on cool stuff--primarily language features and tools--things you can use to do a better job more quickly and more easily, so you can spend your time doing the things you love most--you know what they are.

First up: An interesting scripting language called "Groovy". There are several Java-compatible scripting languages, of course. But at first glance, this one seems to do a lot of things right--enough to take a closer look, anyway. The 1.0 release is due out in September, so it should be usable in a production setting sometime shortly thereafter. In the meantime, it's recommended for exploration, quick hacks, and anything else that isn't "mission-critical".

A Groovy Introduction

Let's start by motivating the discussion: Why do you care about a new scripting language, no matter how good it is? There are several reasons, according to Rod Cope, of OpenLogic, Inc.:

  1. ANT Scripts. Have you ever needed to write a loop or a conditional test in an ANT script? Darn near impossible, right? Groovy makes it easy to insert code segments into your ANT script. Once there, you can access ANT functions as APIs. For example, you can code ant.jar ... to access the ANT task that generates a jar file.
  2. Unit Tests. Unit tests be good--so anything that lets you generate them rapidly be also good. Built-in classes like GroovyTestCase and GroovyMock make it easy to generate test cases and mock objects (objects that have the same APIs as real objects, but which return constant values, instead of performing real functions. They let you isolate part of your application for testing, so the parts it depends on don't have to be functionally correct, or even operational). Note, though, that unit tests also have to be maintainable. See The Cautionary Tale below.
  3. Shell Scripts. The jury hasn't quite come in yet, but Groovy looks as though it may be a useful replacement for shell scripts . It supports pipes, cat, grep--all the stuff you love in Unix scripts. So the Groovy scripts figure to be (a) powerful, (b) portable, and (c) runnab;e on Windows, which is as script-deprived as you can get. (I've been tempted to switch to Max OS/X just to take advantage of the TCSH shell underneath the GUI. Groovy looks like a better answer)
  4. Generate and process hierarchical data. Like XML and XHTML. Easily.
  5. Replace XSLT for XML transformations. Use Groovy instead, write a syntax-translator so you can edit something readable, or for a fun thesis project, come up with a process to convert an algorithm writtin in Groovy to its XSLT equivalent.
  6. Launch an ActiveX-enabled app--like Word, Excel, Access, or IE. Display the window or keep it hidden. Print a set of files, perform a series of searches, or generate HTML pages in Word. Carry out calculations in Excel. Get data from Access. Automated testing of a web app by launching IE, accessing a servlet, and checking values in the DOM.
  7. Generally make life easier. Because Groovy does, well, pretty groovy things--intelligently.

Groovy classes are binary-compatible with Java, and the syntax is compatible as well, so you pretty much write Java. Semi-colons are optional, though, so it's a good idea to use a programming editor that lets you indent things easily and keeps the indentations regular.

Note:
For a comparison to BeanShell, see JavaOne 2005 WrapUp: BeanShell vs. Groovy.

More Groovy Features

You can play with things interactively, which is always fun. Using groovysh (the Groovy shell), you type in some commands and then type go to make them execute. That's pretty cool for "lab exercises", when you're trying to find out what an API really does--for example, does it return null, and empty object, or throw an exception when you pass in a funny parameter? Since the API probably doesn't tell you, you can write a quick little experiment and mark down the results in your "lab notebook".

Where Groovy really shines, though, is its capacity for intelligent code generation. It does a lot of the grunt work for you, which makes it a lot easier to write code. For example, when you add a button to a GUI, you simply specify the code to execute when the button is pressed. There's no need to code listeners or call back methods.

Regular-expression processing is built-in, along with robust string processing and file processing, which makes it pretty convenient for those "quick and dirty" hacks where you're converting files from one form to another.

The language makes it easy to process collections, as well, with a built in method (each) to iterate over them. You code something like cars.each(car), and "car" takes on the value of each item in the list of cars. (Multiple syntax choices are available here. See The Cautionary Tale, below.)

It's also pretty darn easy to generate and parse hierarchical data structures like XML, xHTML, and other formats. The functions are built-in, so it only takes a couple of lines of code to parse an XML data set, for example, or to write out a nested collection in XML form.

For SQL, things are similarly simple. You create a SQL object with one line of code. With another line, you invoke the execute method, passing an SQL query or update. Groovy takes care of the details. It opens the connection, processes the SQL, and closes the connection.

One of Groovy's more unusual features is the ability to add methods to existing classes in a use block. So if you want a String contains() method instead of having to code String.indexOf(...) != 0 you can effectively add that method to the String class, rather than having to write a subclass.

The presentation highlighted a few other features, as well, without going into them in detail:

  • Processes: commandString.execute().text executes the command string and returns the result as a string.
  • Plugins: Groovy plugins for Eclipse, IntelliJ, and JEdit.

The Groovy Details

Here, as best I got them down in my notes, are some of the code segments provided in the presentation. The slides won't be online until sometime after the show, so we'll find out how accurate I was then. (In the meantime, I've learned my lesson! I'm taking my digital camera tomorrow, so I can grab pics of the code segments.)

Create a list

    def people = ['Eric', 'Bill', 'Frank']

Creates a list of strings.

Warning:
Lists can be heterogenous. So ['Eric', 1, 'Frank'] is a perfectly fine list, as far as Groovy is concerned. But there is a reason that generics are so valuable in Java. The ability to make sure that a collection contains a predictable set of homogenous values is highly desirable in production code. On the other hand, with sufficient testing (note the emphasis) the issue does become moot--and Groovy does make testing easy.

Create a map

    def cars = ['Eric':'Mazda', 'Bill':..., ...]

Adding a colon maps the keys to values.

Create a nested map

    def stuff = ['Eric':['car':'Mazda', 'computer':'PC'], ...

Putting one map inside of another makes a hierarchical data structure.

Convert the map to XML

    xml = new groovy.xml.MarkupBuilder()
    doc = xml.toys() {
       for (entry in stuff)
          person(name:entry.key) {
             for (thing in entry.value)
                item(name:thing.key; type=thing.value)
          }
    }

The names of the elements are specified as part of the code. To specify attributes, you use the @ prefix on a name, as in @type. That XML data set the results looks like this:

    <toys>
       <person>
          <name>Eric</name>
          <item>
            <name>car</name>
            <type>Mazda<</type>
          </item>
           ...
       </person>
       ...
    </toys>

Parse an XML data set

  xmlData = """
     ...
     """
  toys = new groovy.utils.xmlParser().parseText(xml)

The three quotes open and close the XML data string, so there is no need to escape attribute-quotes inside the string.

Execute SQL and read data from a database

  sql = new groovy.sql.Sql(datasource)
  sql.execute(...)
  toys = sql.dataset("toys")

Execute a SQL command to update the database and read the contents of the table named "toys" into an internal map.

Write a GUI app

  swing = new groovy.swing.SwingBuilder()
  frame = swing.frame('title':'...', 'size':[400, 600]) {
    menubar {
       menuItem... --specify name and code for
                              the action to perform {in braces}
    }
    panel {
       label...    --specify label name
       button...  --specify button text and action to perform
  }
  frame.show()

The Cautionary Tale

So at this point you're thinking, hey, Groovy might be pretty cool. There is one caveat though:

There are several ways to write the same thing.

For example, you can write int a = 1 to define a variable as an integer, or you can write def a = 1 and let the language processor figure it out. The processor is smart enough to figure out a lot of stuff, which is pretty darn convenient, most of the time. But when I hear the words, "there's usually several ways to do things", the hairs on the back of my neck stand up.

For some reason, that kind of flexibility always seems like a good idea to the folks who create scripting languages. It's the Perl syndrome: Never provide one way to do things if you can create three, and make sure that you can use different syntax styles so that, no matter what language people are used to, they'll feel right at home in this new, wonderful environment that will be surely become popular, because everyone can use it, right?

Well, maybe.

The problem with that approach is that while it makes scripts easier to write, it makes them much harder to read. Every program becomes a compilation of the idiosyncracies of the person who wrote it and the idioms they happened to master. And that it makes it much harder for someone else to read, understand, and modify.

Since Groovy is a Java-compatible scripting language, it's too bad it doesn't follow the rule that helped Java take off so rapidly--when you read Java code, you know exactly what it is doing. There is only one to write read it, because there is one only one possible syntax choice--nothing else compiles. So once you learn the basics, you can read any Java code, no matter who wrote it.

In contrast, the pragmas and macros used in other compiled languages and the multiple syntax choices available in scripting languages like Perl tend to produce "write-only" code. When you need to fix it, you may choose to rewrite it, rather than attempting to figure out what it's doing. That's ok when you're hacking in the garage, but it's not a big thrill for a manager or a coder who is working to meet a deadline.

Hopefully, things won't be quite that bad with Groovy--but's a potential pitfall I wish the designers had chosen to avoid.

Resources


Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jun 29, 2005 3:19 AM
Reply to this message Reply
> But when I hear the words, "there's usually several ways to do things", the hairs on the back
> of my neck stand up.
>
> The problem with that approach is that while it makes scripts easier to write,
> it makes them much harder to read. Every program becomes a compilation
> of the idiosyncracies of the person who wrote it and the idioms they happened
> to master. And that it makes it much harder for someone else to read, understand,
> and modify.

Strange how unrelated articles sometimes echo each other. Such as the next Artima weblog: http://www.artima.com/forums/flat.jsp?forum=106&thread=74230

Vince.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jun 29, 2005 8:19 PM
Reply to this message Reply
>> Strange how unrelated articles sometimes echo each other.
>> http://www.artima.com/forums/flat.jsp?forum=106&thread=7423
>
Brilliant. Yes. Enforce it is a part of the language. Personally, I love the Style Guide for the Java Language.
It was developed by practicing professionals who agreed on a set of conventions. Most of them matched my own (so naturally I admired their perspicacity.)

There were two I didn't use. One of those was different from my (at that time) existing standard. But when I tried it their way, I found they were right.

No matter *what* the standard is, though, I would have adjusted to it if it was the first and only thing I ever learned. And if it improves readability, it HAS to be good.

James Tikalsky

Posts: 12
Nickname: jt2190
Registered: Dec, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jun 30, 2005 1:57 PM
Reply to this message Reply
> <p>
> For example, you can write <tt>int a = 1</tt> to define a
> variable as an integer,
> or you can write <tt>def a = 1</tt> and let the language
> processor figure it out.
> The processor is smart enough to figure out a <em>lot</em>
> of stuff, which is
> pretty darn convenient, most of the time. But when I hear
> the words, "there's
> usually several ways to do things", the hairs on the back
> of my neck stand up.
> </p>
...
> <p> The problem with that approach is that while it makes
> scripts easier to <em>write</em>,
> it makes them much harder to <em>read</em>. Every
> ry program becomes a compilation
> of the idiosyncracies of the person who wrote it and the
> he idioms they happened
> to master. And that it makes it much harder for someone
> ne else to read, understand,
> and modify.
> </p>

Well, another way of looking at it is that you, the programmer, have a responsibility to make sure that your code is understandable. Just because Groovy supports different ways of expressing an idea doesn't mean that it is somehow less readable. On the contrary, having multiple ways of doing things allows you to write code that is more understandable.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 1, 2005 6:19 AM
Reply to this message Reply
> Well, another way of looking at it is that you, the
> programmer, have a responsibility to make sure that your
> code is understandable.
>
Sorry, but I'm afraid you've missed the point. My apologies if it wasn't clear. Making readable code is an important goal in any programming effort, I agree. But the problem with multiple syntax choices is that you have to master *all* of them in order to ensure that you can read any given piece of code.
<P>
A language like Perl grows up to have a wide variety of syntax choices, so two people will the same program, and it will look like it was written in entirely different languages. To read both those programs, you are required to excel at both vernaculars. But you acquire expertise by writing code. You will write most of your code in the first vernacular you learn, and you will become most adept at that. Later, you may find that the real hackers use a completely different style. You now go back to the start of the learning curve, to learn a completely different approach. If you don't, there are a whole set of programs you'll have a hard time reading, because you've never learned the language (language subset, really) that they're written in.
<P>
In short, the very existence of multiple syntax choices threatens to waste your time, because the time you spent mastering one syntax is of little help in reading the others.
<P>
However, I hasten to add that I am speaking entirely theoretically, here. I do not yet have enough experience with Groovy to know whether or not the situation is as bad as it is in say, a language like Perl, where I can competently write scripts and read them in one style, and yet come across code that completely mystifies me.
<p>
Hopefully, Groovy hasn't fallen into that trap. Although it hasn't been much credit, it is my personal belief that Java's readability is one of the things that produced it's current popularity.

Bruce Eckel

Posts: 868
Nickname: beckel
Registered: Jun, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 2, 2005 11:09 AM
Reply to this message Reply
Before you over-enthuse about Groovy, you may want to read Mike Spille's writings on the subject, in particular starting with this one: http://www.pyrasun.com/mike/mt/archives/2005/01/09/20.57.06/index.html
You can find some articles a year or so earlier where he starts out as a fan, but in the above posts and the ones that follow it he delves into both the language and the politics behind the development of the language, and has decided that the whole project is a foundering ship. Perhaps he's wrong and they'll come up with something useful, but the number of problems he points out has made me take a "wait and see" attitude. It wouldn't be the first time the Java community process has produced with great fanfare the Solution To All Problems, which is later quietly swept under the rug.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 2, 2005 8:51 PM
Reply to this message Reply
> Before you over-enthuse about Groovy, you may want to read
> Mike Spille's writings on the subject
>
Thanks, Bruce. I'll take a look. I do get enthusiastic about things--especially at JavaOne. That's the nice thing about software you haven't actually used yet--it works perfectly and solves all problems. It's a wonderful world to be in...
:_)

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 4, 2005 5:41 PM
Reply to this message Reply
> Before you over-enthuse about Groovy, you may want to read
> Mike Spille's writings on the subject
>
I pored over that paper, and several of the papers it referenced, as well. It certainly gave me pause for thought.

On the other hand, when I went to http://groovy.codehaus.org, I found what appears to be exceptionally well-written and clear documentation.

The problem, then, must be restricted to the specification, which has to document the thousands of little corner cases that aren't common practice, but which can occur from time to time--and the language has to be prepared to handle, even if they never occur.

I can well understand that creative and gifted people who are working hard to get something running might find it hard to take the time to deal with all that. On the other hand, I quite a agree that there are some confusing behaviors that MUST be ironed out-- where for example, "x = a (linebreak) + 2" fails, "x = a + (linebreak) 2" succeeds, but "x = a + (linebreak) 2;" fails. Discrepancies like that are just plain nuts.

I also think he was right to say that the spec should be put in the hands of someone who experienced in the mysteries of spec-ease (a language which I have yet to learn how to read, much less write). That's an absolute necessity if multiple implementations are intended. (On the other hand, if all versions come from a single source, then a spec really isn't needed--just a good, solid implementation that solves problems like the one mentioned above.

I'm not sure what properties are, yet, so I'm not sure how to react to his comments about those. But I'm convinced that he's dead wrong when he says that builders aren't needed. One of the more brilliant things about the language, in fact, is the fact that it has been designed to solve common problems--the integration with ANT scripts is one such problem. XML builders represent another problem-solving artifact, because they make it possible to think about doing XML transforms in something other than XSLT. (XSLT might still make sense for automated conversions on the fly, but the less I code in it, the better I like it.)

And when I went a bit deeper to one of the papers that *seemed* like it was declaring the project dead ("There is no Groovy Language", at including
http://jroller.com/page/dukejeffrie/20050113#there_is_no_groovy_language

It turned out that the article was in fact delivering high praise! (It contends that there is no "language" in the sense of a detailed spec that would permit cleanroom implementations by a third party, but at the same time there IS a Groovy project--a code base, developers and a set of rabid, active users, all of which add up to a running project according to agile-methodology standards.

Further, since all of the developer's intellectual energy is *not* going into the production of a bulletproof specification, it's going into the production of a library that has the features it's users want (like ANT integration and XML builders). In other words, the project is following fundamental principles of agile design--build what users want, test it thoroughly, fix it when it breaks, and let the abstractions emerge from the use cases--refactoring when you need to--instead of trying to specify everything at the outset.

That's one hell of an interesting approach, actually. It allows for the possibility that the language can actually evolve, by staying light enough on its feet to do so. Give a few years of active use. Either the standard quiesces into something stable that's worth specifying, at which point multiple implmentations become possible, or a better language comes along and the specification process turns out to be pointless.

Either way, it's potentally a win-win/win. You win because you get a lot more functionality, a lot sooner that you would have otherwise. You win because you don't write a premature specification and get shackled by it, or you win because you never need to spend the time on that long, difficult process. (If I only had all the time I invested in optimizing and adding functionality to programs that ran on hardware that doesn't even *exist* any more...)

Of course, there is a danger, too. If bugs never get fixed; if behavior stays inconsistent--these things could become a problem. But if there is an active development effort that is listening and fixing things, the problems shouldn't be insurmountable.

Other notes:

* The DynamicJava interpreter mentioned in the post does look interesting. It's a pretty much a "pure Java" approach. (As someone interested in using a scripting language to solve problems that Java doesn't solve elegantly, I love the fact that Groovy has been extended to optimize solutions for those use cases.)

* The Pyre Blog at http://pyre.third-bit.com/blog/archives/000096.html
makes a much more damaging case, actually. It calls the project a "stew" consisting of each developer's favorite language features, with no particular rhyme, reason, or coordination. And it points out that whitespace can be significant, which is as stupid a problem as any language designer ever allowed to live for more than 20 seconds.
(Of course that one was posted 6 months ago, in September of 2004, so one fervently hopes that things have improved.)

For the moment, then, I'm remaining cautiously optimistic. The fact that the language has problems (as any program would, at this stage) is not that big a problem, as long as progress is being made. One user did report that it fails for large programs, and error reporting seems to need help, as well. (Wrong line numbers in stack traces and classes that compile but won't run were mentioned). The moral for me is that if I run into a problem, switch back to Java straight away--but as long as I'm doing something small enough, utilize Groovy's expressive power productivity improvement to the hilt.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 6, 2005 7:44 PM
Reply to this message Reply
Yawn.

Had all that stuff since 1980. It's called Smalltalk. Specify code without writing a whole listener - you mean like a block? Literals for complex objects? Old news.

Here's something more interesting - is there a debugger? Is it written in groovy too? Can you move the program counter in it? Restart a method? Modify the code?

I just can't get excited about wheel 2000.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 6, 2005 11:53 PM
Reply to this message Reply
> Yawn.
>
> Had all that stuff since 1980. It's called Smalltalk.
>
Yeah. Smalltalk sure was an elegant language. It was great. O-O everything. It just didn't interact with the outside world all that well. It was a great research language, a not-so-great production language.

That's an area where Groovy shows smart thinking. By building on the Java JVM, it gets access to all of the machinery that Java has built to manage those interactions. Was SmallTalk more elegant? Sure. Would I choose it to build a Midi jukebox? No.

For that matter, would I use it to create a script I would use as part of an ANT build script? No again. Every language has it's pluses and minues. SmallTalk invented or popularized *most* of the O-O language features we take for granted today. But scripting is something else, production libraries are something else, and specifically designing a language to solve "point of pain" use cases for developers is something else again.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 7, 2005 12:41 PM
Reply to this message Reply
> Smalltalk sure was an elegant language. It was
> great. O-O everything. It just didn't interact with the
> outside world all that well.
I'd say it integrates much better than Java. But maybe you haven't looked lately.

> It was a great research
> language, a not-so-great production language.

I have production web apps in Squeak with uptimes of several months.

> That's an area where Groovy shows smart thinking. By
> building on the Java JVM, it gets access to all of the
> machinery that Java has built to manage those
> interactions.

Its no better than the Squeak VM and in many ways worse.

> Was SmallTalk more elegant? Sure. Would I
> choose it to build a Midi jukebox? No.

Fortuneatly, that's been done for you. Squeak has good midi support since 1998. It is being used now effectively to do real time 3d rendering. http://www.opencroquet.org

> For that matter, would I use it to create a script I would
> use as part of an ANT build script?

That's a pretty silly example as Smalltalk doesn't require something as arcane as "build scripts". The environment is live all the time. See how far your mindset goes?

> But scripting is something else,
> production libraries are something else, and specifically
> designing a language to solve "point of pain" use cases
> for developers is something else again.

I find the difference between "scripting" and "production" languages a false dichotomy. As far as I can see, "production" language just means "hardest to develop in". The language with the highest reliability is the one with the best debugging facilities.

Here's a "point of pain" - J2EE is a very painful development environment for web applications. Its much too complex. Here's a solution: http://seaside.st

As yet another example, the world's largest online retailer does all of their web page rendering in Perl. So is Perl not a "production" language?

The "production" vs "scripting" language idea doesn't hold. What works in production, works.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 7, 2005 2:36 PM
Reply to this message Reply
> > Smalltalk sure was an elegant language. It was
> > great. O-O everything. It just didn't interact with the
> > outside world all that well.
> I'd say it integrates much better than Java. But maybe
> you haven't looked lately.
>
Interesting news. It's been 20 years since I played with it.
A lot could certainly happen in that time. I hadn't realized that development was ongoing.

> I have production web apps in Squeak with uptimes of
> several months.
>
Intriguing. Something new to explore. When I first
looked at SmallTalk, I hadn't learned how to think with
objects, and I never made the transition. Java gave me
a C language I was used to, and the ability to transition into O-O thinking during several years of working with it,
with most of the learning occurring *after* I thought I knew what objects were good for.

> > That's an area where Groovy shows smart thinking. By
> > building on the Java JVM, it gets access to all of the
> > machinery that Java has built to manage those
> > interactions.
>
> Its no better than the Squeak VM...
>
Ok. Color me intrigued.

> ...Squeak has had good
> midi support since 1998. It is being used now effectively
> to do real time 3d rendering. http://www.opencroquet.org
>
Yup. That's the kind of serious real-world interaction libraries I was talking about. Thanks for correcting my
mis-impression. I hadn't heard about SmallTalk in so long, I figured it was effectively dead. (I must be traveling in the wrong circles.)

> > For that matter, would I use it to create a script I
> > would use as part of an ANT build script?
>
> That's a pretty silly example as Smalltalk doesn't require
> something as arcane as "build scripts". The environment
> is live all the time. See how far your mindset goes?
>
Hey! No need to be critcal. I see something that solves a problem in my current environment, I like it. You show me something that eliminates the problem entirely, and I'll probably like that even better.

Which makes me wonder: How did Java get so popular, if SmallTalk offers all this great stuff? What did Java do that SmallTalk didn't? Was it simply the availability of a free JDK? Network-enabled libraries? The JavaOne convention? What?

I know we're discusssing Groovy vs. SmallTalk, but I've been in the Java camp for a very long time now, which is why I'm familiar with build problems in that environment. Why are so many universities using Java to teach O-O programming? Where are the ads for SmallTalk coders?

(Personally, I *love* elegant language solutions, so I'm interested in the answers.)

> As far as I can see,
> "production" language just means "hardest to develop in".
> The language with the highest reliability is the one with
> the best debugging facilities.
>
Hard to argue with that.

> Here's a "point of pain" - J2EE is a very painful
> development environment for web applications. Its much
> too complex. Here's a solution: http://seaside.st
>
Yup. I've been a J2SE guy. There's a certain level of complexity at which I shake my head and think, "I really don't want to go there". The seaside page does a good
job of listing solutions for "point of pain" use cases.
I'll have to examine it further.

> As yet another example, the world's largest online
> retailer does all of their web page rendering in Perl. So
> is Perl not a "production" language?
>
Gack. At the risk of offending millions of Perl hackers,
it's not, in my mind. I used Perl and CSH scripts to
do processing on things I'll eventually deliver, but I
never use them to implement the deliverable itself. I'm
not sure what it is that makes things different. It's an
area I'm seeking to understand better. But there is some
difference between "internal processing" and "outside
delivery" that makes me use scripting solutions for the
latter, but never the former.

> I find the difference between "scripting" and "production"
> languages a false dichotomy.
> The "production" vs "scripting" language idea doesn't
> hold. What works in production, works.
>
"Production" was an inaccurate choice of terminology. It didn't exactly reflect the concept I had in mind: A program the end-user would interact with directly.

Interestingly, a web service implemented in Perl lies in a middle ground. I wouldn't mind using Perl to deliver a web service to an end user, I just wouldn't deliver a client application that way. Why, you ask? Partly, it's a matter of GUI libaries. But mostly, it's a matter of protecting the algorithms from changing under me, when I have to support them. (If I've got to support it, I want to know what the
heck it is I'm supporting.)

Of course, open source projects are a reality these days. So I have to filter some of my thinking through that prism. These are off-the-cuff reactions on the subject, rather than fully-baked thoughts.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 7, 2005 3:38 PM
Reply to this message Reply
>Which makes me wonder: How did Java get so popular, if SmallTalk offers all this great stuff? What did Java do that SmallTalk didn't? Was it simply the availability of a free JDK? Network-enabled libraries? The JavaOne convention? What?

Free (as in beer) vs WAY pricey. At the critical juncture in about 1996-ish, there were 3-4 companies with good Smalltalk implementations (including IBM which was promoting it as the successor to COBOL!). Smalltalk saved so much effort and was so productive that the companies that sold it felt like it was worth a *lot* of money. They built business models focused on maximizing price per seat vs overall profit via high rates of adoption. So a single developer seat for VisualWorks (probably the most focused on enterprise development) went for about $3k.

This also made it difficult to get new Smalltalkers as even individuals had to pay big bucks to get an environment and learn the language. High cost of entry plus scarcity of talent and the perception that Smalltalk executables were large (about 4-8M, nothing by Java standards) and slow (about 10 times slower than C) and it got a bad rap among the bean counters who pick the technology.

About the time Smalltalk was at its peak, Java showed up for free and got a bunch of mindshare. The web buzz and Smalltalk's slowness to adapt to the web hurt things as well. IBM simply caved and repurposed their Smalltalk tools and VM for Java. Most of IBM's early Java dev stuff is all written in VisualAge Smalltalk.

Meanwhile, the original developers of Smalltalk were annoyed that there wasn't a good free implementation that was unencumbered and so they set out to write a new one. Squeak was the result. The OOPSLA paper describing this is here: http://ftp.squeak.org/docs/OOPSLA.Squeak.html

A great page of links to various docs and papers is here:
http://www.squeak.org/documentation/

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: JavaOne Report, Day 1: It's a Groovy Day Posted: Jul 7, 2005 5:02 PM
Reply to this message Reply
> ... the original developers of Smalltalk were
> annoyed that there wasn't a good free implementation that
> was unencumbered and so they set out to write a new one.
> Squeak was the result. The OOPSLA paper describing this
> s is here: http://ftp.squeak.org/docs/OOPSLA.Squeak.html
>
> A great page of links to various docs and papers is here:
> http://www.squeak.org/documentation/
>
Thanks for the links! I'll check them out.

After posting my last reply, I went to lunch. On the way, it occurred to me that Sun poured a huge amount of money and time into the project, which affected development certainly, but which also affected mindshare with press releases and internet buzz.

Of course, the goal was to pry open the market for their hardware, which by that time seemed to be closing ranks around an Intel/Microsoft hegemony. But in order to do that, they came up with something that offered real portablility--a way around the balakanization of hardware systems that forever limited you to supplying software for one vendor's systems--unless you had the size and sheer determination of an organization like Oracle.

Whether that promise has actually been achieved is a subject of argument in various quarters, but the fact remains that they were able to plausibly make the argument.

And as a result of the investment in development time, they were able to extend the system to accomodate business logic in one direction (J2EE) and embedded systems in the other (J2ME). That's pretty great for schools, in particular, because they can teach basic concepts for the language and give students the preliminary background they need to go in one of three widely varying directions.

I'm still interested in SmallTalk, though. I'm *always* interested in elegant, powerful languages. Thanks again for the links.

Vadim Voituk

Posts: 1
Nickname: voituk
Registered: Oct, 2006

Re: JavaOne 2005, Day 1: It's a Groovy Day Posted: Oct 16, 2006 8:45 AM
Reply to this message Reply
It should be
toys = new groovy.util.XmlParser().parseText(xml)
insted of
toys = new groovy.utils.xmlParser().parseText(xml)

Flat View: This topic has 14 replies on 1 page
Topic: JavaOne 2005, Day 1: It's a Groovy Day Previous Topic   Next Topic Topic: Developers and Requirements


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us