I have set all the environment variables as directed, yet I cannot get Groovy to work on Windows 98 -- even going directy into groovy\bin I cannot run groovysh or anything else.

Wait a minute. It''s not because Sun/Netscape have subverted the meaning of "scripting language" that scripting is not useful.

Scripting as in "bash" or "perl", which could be called "bash on steroids", scripting is nothing more than the fine-grained scheduling of executables. I mean, it''s always an exercise in IPC (InterProcess Communication).In its true meaning, scripting is absolutely meaningful.

If you''re referring to e.g. javascript, I must say you''re right. But the true issue is that javascript is not a scripting language. It''s not an excercise on IPC. Javascript would not even be able to do it.

If Groovy is meant to be a true scripting language, it should excel at IPC; and be seriously better at it, than what exists already. I doubt, however, that Groovy will be any good at IPC. Java itself, with its VM cum startup time can hardly do any IPC; so where is Groovy supposed to get its IPC talents? Nowhere. And that''s indeed where Groovy is heading.

According to you "javascripting" is not programming and javascripters are not necessarily programmers. I think you are probably right.

But then again, would you attack the Logo afficionados so viciously? Or Playstation2 addicts? Come on...

Why do we want scripting languages? If you can''t program in a real language then go and get a different job. All we do is to wander from job to job and find applications infested with scipting languages and written by unstructured, un-tutored script-kiddies. Go away and do an art degree and leave programming to programmers. Shove Groovy where Sun don''t shine.

I spent a good amount of time on the groovy site and wiki.

It seems there are three killer features:
1) Groovy is both interpreted and compiled. When it is compiled it produces bytecode is indistinguishable from any other compiled java class.
2) Groovy reuses the entire java class library and does NOT come with its own. Thus, unlike Jython, you learn one class libary, not two.
3) Closures and the tree based syntax give a very natural and powerful syntactic support for heirarchical data like XML.

I cannot seem to get it to run the groovyConsole and groovysh under WindowsXP.

I am sorry. I don't care how good it is. I am NOT using anything called "Groovy".

Java is truly a strange beast. On the client it keeps on taking bashings, because its Swing GUIs are not attracting the crowds, to say the least. On the server, Java has erected its own playfield, in it so-called containers, where Java only wants to play with Java. To participate in a shell script, like anybody else? Can't be done: too slow and too resource-hungry.

Either Java will manage to force all non-Java to cease developing interesting stuff, which sounds unlikely, or else most of the interesting action will be elsewhere, and Java won't be able to survive all by itself.

You can't compare Python or Perl to Java. They can interoperate with everybody else.

Java can't, and that's why it won't last.

Seems to me that instead of shooting down Groovy or any other new language or tool, we should be looking at it for what it is--another possible option to use to solve our business problems (strategic or tactical).

Who cares who "owns" Java or Groovy or makes the majority of the profit from it. Microsoft owns most desktops and despite other options, I wrote this note in IE. (And you most probably are reading it in the same.)

Look at the article in the 18 March edition of this article titled "1 in 4 IT Jobs Going Offshore..." and we might all get motivated to focus on growth and delivery.

A bit of perspective from someone who started on punch cards using COBOL and RPG -- the more languages you can wield, the more value you bring to the team.

Regarding the 95 percent of programmers who do not know what Smalltalk or Ruby is one could say either so what (check positions listings for how infrequently one sees Smaltalk or Ruby) or too bad for them as they have become very focused -- maybe too much so for their own good.

Options empower us.

Me? C, C++, Basic, COBOL, Java, assembler, PL/SQL, JavaScript, VBScript, whatever is needed to deliver against the requirements and constraints of the current project.

After reading the Groovy users manual I think I still prefer Python. I just see Groovy syntax to be more similar to Java syntax, but I don't consider it to be an advantage. Maybe it's even dangerous to have such similiar syntaxes doing such diferent things. On the opposite many usefull Python constructs are missing and you loose the multi-platform nature of Python(Windows, Unix, Java, .Net, ...). I've never used Ruby, that some people says is really good so I can't compare with it. ¿Perl? ... well UNfortunatelly is still here with us.

Oh good, another programming language...

Michael,

I imagine the scripting language is mostly for Java programmers. However, this also allows Admins to utilize too if they want to switch from Perl, as this seems to be the most popular scripting language. An advantage for Groovy is that almost all desktops at a certain point will have a JVM on it, whereas Perl needs to be loaded, so scripting will be available from the get go. In addition, Java programmers will be able to look at an admins scripts and modify them. Currently, if a Java person has to support legacy Perl, then he does have to learn a new syntax.

Hakl Du,

I have no idea what you are talking about with Sun''s platform. It seems to me that there are a lot more companies than Sun that work on Java. I wouldn''t say Sun owns Java as IBM, BEA, HP, Oracle, and many others contribute to it. Sun seems to me to be more of a steward. Plus, the JVM from Sun is an implementation and not the "official" JVM by any means. Other companies have developed their own JVM.

I''ll start out by saying that I am not a very good Java programmer. That''s part of why I turned to scripting languages.

I don''t worry so much about which scripting language looks like Java, or which best leverages features used by either pure OO or low-impact languages (well, debatable about python, but ruby still is rare these days), I look at which one helps me get my work done fastest.

Judoscript, without question, was the easiest to pick up, and is the easiest for perl programmers to transition into. http://www.judoscript.com/index.html

Groovy, Jython, Pnuts, Beanshell are all either just as hard as Java, or add new syntax structures which require new learning, but still do not help me with higher level programming.

The excitement around closures and other somewhat esoteric programming constructs (yes, they are esoteric; ask 100 randomly selected programmers if they have tried ruby or smalltalk and don''t be surprised at the 95 who say "Who?") is hitting the problem at the wrong point. Language constructs which are clearly designed to help solve higher level data problems, like Judoscript''s built in tabledata structure, is really where we need to look. http://www.judoscript.com/articles/misc.html#tableData

I don''t need any more tools to reinvent the wheel yet again, I need a language with the wheels already in the kit instead of making "yet another file parser" or "yet another gui framework". If I more basic tools, I''ll just use Java itself; I need a scripting language to help me skip the tedious stuff... and learning yet another syntax is, yes, tedious.

So, I like the thinking that people are pushing towards, but for most of us, the issue is not how we can start to include the more esoteric (if interesting) features. The useful scripting language is the one with the features which lets us get work done, glue programs, and munge data. Perl excels in this, and so does Judoscript. Haven''t seen this for Groovy (other than impressive Ant scripts)

So, I say dump this JSR. If we want agile scripting languages, look for the ones that solve problems, not ones which make you learn a new programming philosophy just to get started.

All in my humble and biased opinion,

Michael

Smalltalk is an old language (1980) but it include virtual machine, garbage collection, exeption handler, meta model, and it''s syntax is as simple as space beetween word and dot at the end of the sentence :-)

myCar start.
myCar engine isBroken ifTrue: [self buyEngine].

Java is the worst possible implementation of Java!

Java as a language has many flaws which compromise its readability and hence its maintenability: its heavy use of punctuation (cf. C) instead of keywords (Pascal) -- you simply can''t come into a piece of unfamiliar Java code and see what''s going on. And it continues to boggle me that not only does Java not define standard mathematical operators for the Number subclasses, it doesn''t support overloading.

The ''cultural'' preference for case-distinguishing words in an identifier -- e.g., thisIsAVariable -- patently absurd from the standpoint of readability. TheAncientGreeksAndOtherLiteratePeopleUsedToWriteSentencesLikeThis --
then came the first century. If spacing between words was an advance in the writing of natural language, why isn''t underscoring an advance in the writing of programming languages?

I guess this is all kind of sour grapes. I had a job programming in Ada in the late 1980''s and, although it couldn''t be called object-oriented, the syntax was so clear that my rate of dumb coding errors went way down, the possibility of subtle syntax errors (like a semicolon after an if in Java) was eliminated, and I could return to a piece of code after six months and start in immediately.

Wouldn''t it be nice to have a community supported alternative to Java? Or even a language integrated tightly into Eclipse to implement quick and dirty scripts? The language could be integrated into IDEs for faster IDE customization and extension in the same way that Emacs supports Lisp.

There are two things which make a HUGE difference:

a) programming paradigm
it's a difference whether you code object oriented, functional, list oriented procedural or assembler or a combination of several of them or mimicking one with the features of the other

b) SYNTAX
I belong to the guys who can not remember why and when to use a $ or a % or a @ in PERL. The distinction makes absolutely no sense to me. Just my brain ...

But what I want to say is: If you are already fluent in Java you pick up Groovy in 5 minutes. If you ever heard anything about other programming languages, notably SmallTalk, then the new features Groovy offers you are easy to learn. Did you notice that Python has a completely uncommon syntax? It has no relation to Pascal or C. It is not Fortran and not PERL, its something DIFFERENT. Please don't talk about easy or not ... alone the fact that you have to "install" Python and to learn something new while Groovy is just another library, another jar file in my class path ... OH, that's a difference.

Groovy seems to offer nothing that you don't already get in Python, and Python has implementations available based on C (C Python), Java/JVM (Jython), and C#/CLR (IronPython).

The only thing Groovy does offer is that it is Java/JVM-specific at this point--there are no implementations based on anything other than the Java/JVM runtime. That may be a good thing for Sun--tying people even more to Sun's platform--but it sure isn't good for anybody else.

fyi you can create servlets using Groovy.

This groovy thing looks like a really nice Smalltalk-esque language that hooks right into Java, enough to satisfy both sides of my brain.

This is cool and I can benefit from this *right now* in my work. Forget Parrot or Perl 666 (heh).

How come I never heard of this?

Groovy is an excellent language. And in case it gains momentum like one has written here, there is no doubt that people will port it to Parrot and the Python VM just like Python is ported to the JVM.

It sounds to me like anywhere you think you want this, you would be better off with actual Python.

Having a glue language to tie together Java objects is definitely cool, as is having the scripting language compile down to bytecode for easy deployment.

Wooohoooo, that''s really great news. I''m quite excited by this JSR :-)