×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Groovy For Domain-Specific Languages

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Book Reviews 81

RickJWagner writes "This is a book targeted primarily towards the Java programmer who doesn't yet know Groovy. Groovy is a dynamic scripting language that runs on the JVM and offers easy integration with the Java language. Groovy also offers dynamic language features that lend themselves to the creation of DSLs (Domain-Specific Languages). This book attempts to simultaneously teach the reader how to use Groovy and how to build a DSL." Keep reading for the rest of RickJWagner's review.DSLs are something of a hot topic these days. A DSL is a 'Little Language' or a language written just for one business domain. As programmers, we're familiar with DSLs whether we realize it or not-- each time you use 'Make' to build a C project, or use 'Ant' to make a Java project, you're using a DSL. A DSL is a purpose-built language, with it's own verbs, rules, syntax, etc. It's made for one purpose only, and is meant to make things as easy as possible for the intended user. If the user has a need outside what the DSL can provide-- they're just tough out of luck! General purpose languages are for doing whatever the user needs-- DSLs are for doing only one task, but making that one task exceedingly easy for the user.

The book does a good job of making Groovy understandable for a Java coder. Programmers of other stripes would be able to use the book, but the author aimed squarely for the Java sweet spot and I think did a good job of hitting it. Where language integration was to be shown, the JDK was the reciprocal part in the examples, and the classes singled out for interfacing were ones that would be well-known to a Java coder.

Writing DSLs has been done for many years, but was largely an undocumented process until just recently. I think the rise of dynamic languages has something to do with that. Dynamic languages offer some key features that make DSL creation a little easier. A few of these features the book covers are closures and meta-programming. Closures are anonymous methods, packaged in such a way that they can be passed as parameters to other methods. Meta-programming is using code to write other code, and can be used to perform some neat tricks like allowing the user to call methods that don't have a previously written definition. (If that sounds really strange to you, I agree. But it turns out this is something very handy if you're writing a DSL!)

The book is written in a way that thoroughly the breadth of features offered by the Groovy language, but not a lot of depth in all of them. For this reason, I found myself sometimes referring to external sources when I was encountering some language construct that seemed a little less familiar than most. It wasn't a problem-- the book did a fine job of letting me know of the existence of some language feature and how it might be used in writing a DSL. If I didn't immediately grasp the use of the feature after the typical single example of seeing it used in sample code, I'd just pop out to the internet and get a few more examples. The book is nearly 300 pages as it is, and very little of that is wasted. I give the book good grades for technical content.

Style-wise, I found the book reasonable to read but not great. As well as the author does spelling out the nuances of the Groovy language, the DSL parts are interspersed among the chapters and sometimes could be hard to find unless you read a lot of surrounding technical content. Maybe this is the only way to cover two meaty topics at once, I don't know. But I found myself doing quite a bit of paging when I wanted to refer back to DSL-specific advice, sometimes falling back to the chapter-by-chapter summary in the front of the book to get myself in the right neighborhood.

The book has plenty of sample code, which I found well constructed and easy to read. The author adapted the practice of writing small snippets of code, then used assertions to demonstrate the behavior the reader would expect if the code were to be executed. I really liked that. The code itself was always cleanly formatted and minimal in length, which made it very easy to read.

So, did the book hit it's target? I believe it did. The strengths of using Groovy for Domain Specific Languages are drawn out, and the Groovy language is given a thorough overview. Java coders will find this book a reference that will let them start using dynamic features while still staying on the JVM. (By the way, Groovy compiles to Java, so all your existing Java code is usable from Groovy. So you might write an application that's 95% Java and 5% Groovy, and that's just fine with Groovy.) I think this book covered a lot of ground and did it well.

You can purchase Groovy for Domain-Specific Languages from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

81 comments

Well, not quite... (5, Informative)

macroexp (1002893) | more than 3 years ago | (#32842142)

"Writing DSLs has been done for many years, but was largely an undocumented process until just recently."

Not to discount the review, but that's a bit misleading. There are plenty of books dealing with lex/flex and yacc/bison, which have been used for years to do the same things in a precompiled manner. .Net and Java "just recently" discovered this and have popularized the term DSL for it.

Re:Well, not quite... (2, Interesting)

Anonymous Coward | more than 3 years ago | (#32842432)

Exactly - lex and yacc have been around since the 1970's, and the process is quite well understood and documented.

The article was probably written by someone without a formal CS degree, who was unaware of these things. Nothing wrong with ad-hoc learning of course, it works great for many folks, it's just that you don't get exposed to certain things unless you manage to discover that you should go invest in learning about them.

Re:Well, not quite... (5, Insightful)

metamatic (202216) | more than 3 years ago | (#32842480)

There are plenty of books dealing with lex/flex and yacc/bison, which have been used for years to do the same things in a precompiled manner.

Not to mention Lisp, which has been around since the 50s as a tool for solving problems by building domain-specific Lisp variants.

Re:Well, not quite... (3, Insightful)

overlordofmu (1422163) | more than 3 years ago | (#32843436)

Thank you for the LISP reference. Instead of ranting about no one mentioning this obvious example, I get to say "thank you".

Re:Well, not quite... (4, Informative)

ari_j (90255) | more than 3 years ago | (#32843448)

I stopped reading the review when I got to the "largely an undocumented process until just recently" line, as well. The best book on DSLs I've ever seen is On Lisp [paulgraham.com], published in 1993 and available for free from the author. Lisp is almost a meta-DSL - a domain-specific language for the domain of writing domain-specific languages - and this book will get you from "I don't get why the professor is making us write Hello World in Lisp" to thinking in terms of DSLs (and applying that thought process to all programming languages) between its covers.

You can, of course, write DSLs in any language. But you should learn to do so as a matter of writing DSLs instead of as a language-specific technique. How worthwhile is it to read a book about how to make a linked list specifically in Pascal? Learn how to do the thing in a conceptual sense and then use your knowledge of a language to turn the concept into code.

Re:Well, not quite... (0)

Anonymous Coward | more than 3 years ago | (#32844030)

There are plenty of books dealing with lex/flex and yacc/bison, which have been used for years to do the same things in a precompiled manner.

Not to mention Lisp, which has been around since the 50s as a tool for solving problems by building domain-specific Lisp variants.

Better mention FORTH, too. FORTHs are good for building DSLs for many of the same reasons as Lisps.

Re:Well, not quite... (0)

Anonymous Coward | more than 3 years ago | (#32846346)

AND FORTH
GO.

Re:Well, not quite... (2, Insightful)

Anonymous Coward | more than 3 years ago | (#32842508)

And there's plenty of DSL material for groovy online already.

Other seriously questionable sentences :

"Groovy is compiled"
"Closures are anonymous methods, packaged in such a way that they can be passed as parameters to other methods." - this is like describing a porsche by stating it generally has 4 wheels
"Meta-programming is using code to write other code"
"and can be used to perform some neat tricks like allowing the user to call methods that don't have a previously written definition."

All extremely misleading statements

Re:Well, not quite... (1, Funny)

Anonymous Coward | more than 3 years ago | (#32842974)

+1 Car Analogy

Re:Well, not quite... (1)

the linux geek (799780) | more than 3 years ago | (#32843462)

How is "groovy is compiled" a misleading statement?

Re:Well, not quite... (2, Insightful)

slater.jay (1839748) | more than 3 years ago | (#32843546)

To clarify: the groovy 'interpreter' (groovy) is the groovy compiler (groovyc), except it doesn't save its work and just runs the bytecode straight away.

Re:Well, not quite... (2, Interesting)

mcvos (645701) | more than 3 years ago | (#32845272)

It looks like the reviewer is fairly new to this programming thing, and this was the first insightful book he read on the subject, but he didn't understand everything completely.

By the way, Groovy is compiled. Sort of, in a dynamic way. And it's bloody annoying. When I run Grails and change class A, groovy needs some time to recompile, and then complains it can't cast class A to class A. I never had that problem with Ruby (although Ruby has its own share of reliability issues).

Re:Well, not quite... (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32847064)

. When I run Grails and change class A, groovy needs some time to recompile, and then complains it can't cast class A to class A.

Thats Grails, not groovy. Grails has its upsides, but the auto-recompile stuff doesn't quite work cleanly yet.

Re:Well, not quite... (3, Insightful)

Lunix Nutcase (1092239) | more than 3 years ago | (#32842584)

You seem to be equating the reviewer's poor grasp of the subject matter to trying to equate that Java and .NET developers as a whole think they invented or discovered the notion of a "minilanguage" (or DSL in this case). This is simply not true. Secondly, the term "domain-specific language" was being used almost a decade before C# even came out and long before any such things were being built on top of the JVM.

Re:Well, not quite... (1)

badboy_tw2002 (524611) | more than 3 years ago | (#32842672)

I recommend this one by the author of ANTLR, which is a far superior alternative to lex/flex yacc/bison IMHO. The book uses ANTLR as an example, but is not limited to it. It explores the theory of DSLs and the design around them. A great buy if you need to do this for a project.

http://pragprog.com/titles/tpdsl/language-implementation-patterns [pragprog.com]

Re:Well, not quite... (1)

tcopeland (32225) | more than 3 years ago | (#32842788)

> ANTLR, which is a far superior alternative to lex/flex yacc/bison IMHO.

Another alternative is JavaCC, which (shameless plug!) I document in great detail in my book Generating Parsers with JavaCC [generating...javacc.com].

Re:Well, not quite... (1)

badboy_tw2002 (524611) | more than 3 years ago | (#32842886)

Yeah, its good too. Of course it can't really a replace flex/bison as it doesn't output C, which is why I've gone ANTLR in the past.

Re:Well, not quite... (1)

tcopeland (32225) | more than 3 years ago | (#32842998)

Yeah, ANTLR's great for that... and it would be a pile of work to get JavaCC to output lexers and parsers in languages other than Java... sigh.

It's just a marketing term. (0)

Anonymous Coward | more than 3 years ago | (#32842724)

"Domain-specific language" is nothing more than a marketing term, most frequently used by those wishing to sell books, and by consultants wishing to sucker you into taking expensive courses that "teach" you stuff you already know.

Like "cloud computing", "Ruby-on-Rails" and "NoSQL", it's just a re-branding of old, if not outright ancient, technologies and techniques.

However, they are useful when hiring people. If you're interviewing somebody and they start talking about how they need to develop some domain-specific languages while creating a NoSQL-backed Rails app running in the cloud, you know right away that they're packed full of bullshit, and shouldn't be hired.

Re:Well, not quite... (1)

oldhack (1037484) | more than 3 years ago | (#32842796)

I was gonna mod the parent up, but it's already at the limit. So I'll post a question instead. What about Groovy makes it good to write/generate lexer/parsers?

Re:Well, not quite... (1)

mcvos (645701) | more than 3 years ago | (#32845318)

You don't need to write/generate lexers/parsers. The DSL can be legal Groovy. You just need a handful of methods that read it and turn it into the datastructures you need. It would be a lot of extra work in a more static language.

Re:Well, not quite... (1)

larry bagina (561269) | more than 3 years ago | (#32845518)

How is that better than perl, python, javascript, ruby, php, (ok not php), or any other interpreted language with an eval() function?

Re:Well, not quite... (1)

mcvos (645701) | more than 3 years ago | (#32845600)

How is that better than perl, python, javascript, ruby, php, (ok not php), or any other interpreted language with an eval() function?

Not perl or javascript either, I hope. Python and Ruby are a very similar crowd to Groovy, as far as I can tell. (Personally I prefer Ruby; Groovy has too many Javaisms.)

Groovy-- the worlds most perfect language? (1)

goombah99 (560566) | more than 3 years ago | (#32843564)

lex/flexx are front ends for domain specific languages. they parse things you then have to implement a backend for. THey are great achievements but not stand alone. I think the point here is how you implement the end to end DSL. There have been other books for example that talk about using yacc/lex with objective C to make a complete app.

As for groovy, I've never used it since python and perl I know and they are more mature. But I have to admit when you look at groovy it seem to me to be the holy grail of scripting languages. The one thing all scripting languages lack is a really seamless way to go from your script prototype with duck-typing to a faster compiled version with real static/dynamic typing. All the approaches in python are a kludge (c-python, jython etc...). You can call C or fortran from python and perl (i.e. swig boost, f2py, ...) but it's an interface with a deep moat. in groovy the syntax stays almost the same as you move from the script to the compiled java. THe way you import things is so similar it makes tweaking a script into a compiled version trivial and more importantly can be done incrementally as needed. And it comes with all the legacy libraries of Java for free.

It seems like the ideal modern script language. You just have to get over Java-phobia.

Re:Well, not quite... (0)

Anonymous Coward | more than 3 years ago | (#32848582)

Not sure I agree it is that new in Java either. I did my degree project in the 90s with javacc and jjtree which do this sort of role. But Groovy seems to be getting quite a bit of press so there must be something behind it that I haven't got to yet (hence I did read the whole review).

What about FORTH? (0)

Anonymous Coward | more than 3 years ago | (#32842312)

Doesn't anyone remember FORTH? That's pretty much nothing but a domain specific language.

Re:What about FORTH? (2, Interesting)

digitig (1056110) | more than 3 years ago | (#32843362)

No, FORTH is general purpose, even though it was developed for a particular domain (real-time control). The language extensibility means it's great for writing DSLs as long as security isn't an issue and you don't mind them being reverse Polish (in other words, DSLs for geeks working in god mode anyway), but it's hard to avoid whatever DSL you write being embedded within the general purpose language.

Let me get this straight..... (1, Flamebait)

AnonymousClown (1788472) | more than 3 years ago | (#32842334)

Groovy is a scripting language that runs in an interpreted language virtual machine that runs as an executable on top of the OS.

You CS guys and your "layers" of abstraction! I tell ya.

So does birth control to a CS guy mean banging some chick you met at the bar and telling your wife that the bar chick was just an abstraction and you were really making love to her? The bar chick was just a layer in your relationship?

The more important question is, does it work?

Re:Let me get this straight..... (1)

abigor (540274) | more than 3 years ago | (#32842526)

Groovy is a scripting language that runs in an interpreted language virtual machine that runs as an executable on top of the OS.

No, that's incorrect. I'm not going to tell you which part though, as us CS guys feel that you need some practise with actual thinking.

Re:Let me get this straight..... (1)

jfoobaz (1844794) | more than 3 years ago | (#32842554)

So does birth control to a CS guy mean banging some chick you met at the bar and telling your wife that the bar chick was just an abstraction and you were really making love to her? The bar chick was just a layer in your relationship?

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

Re:Let me get this straight..... (1)

Nadaka (224565) | more than 3 years ago | (#32842800)

No. The proper way to use a bar chick as a layer is to have her sandwiched between you and your wife. That way your output enters the bar chicks input and is then translated almost immediately to her output which enters the input of your wife. This conversion my be a little more complex, but it provides a multiplying effect to the value of the procedure.

Re:Let me get this straight..... (0)

Anonymous Coward | more than 3 years ago | (#32843752)

100% medically accurate.

Re:Let me get this straight..... (0)

Anonymous Coward | more than 3 years ago | (#32843850)

I...I think your bar chick is a dude, dude.

Groovy? (0)

Anonymous Coward | more than 3 years ago | (#32842356)

Far out, man!

Let me get THIS straight..... (5, Funny)

Anonymous Coward | more than 3 years ago | (#32842392)

"A DSL is a purpose-built language, with it's own verbs, "

You software lunatics are continually re-inventing dozens of languages, each looking like an explosion at a typesetter company, but are unable to grasp the simple distinction between it's and its?

Re:Let me get THIS straight..... (2, Informative)

Anonymous Coward | more than 3 years ago | (#32843910)

the simple distinction between it's and its?

As someone who isn't a native english speaker, I disagree with the "simple" part. Or well, it is simple but it most certainly isn't logical! After a decade of studying english and using it practically daily, I still always need to think a few seconds before writing either "its" or "it's".

Re:Let me get THIS straight..... (0)

Anonymous Coward | more than 3 years ago | (#32843982)

The apostrophe stands for one or more letters being omitted. "it's" == "it is", always. How is this not logical?

Still, I'm moving to the opinion that apostrophes should probably just disappear from the language entirely.

Re:Let me get THIS straight..... (1)

cthubik (1588847) | more than 3 years ago | (#32844388)

Because the possessive form is not all that logical. The English language's logic. English's logic. Its logic. It's not logical.

Re:Let me get THIS straight..... (1)

tolan-b (230077) | more than 3 years ago | (#32845062)

My, your, his, her, *its*, our, their.

John's, Jane's, Jerusalem's.

Re:Let me get THIS straight..... (1)

cthubik (1588847) | more than 3 years ago | (#32846010)

Yours, his, hers, its, ours, theirs... mines. But ok, point taken. How about names that end with an s, what do you do there? Whose is this? - It's Chris' brother's! The language is a mess, I tell you.

Re:Let me get THIS straight..... (1)

transwarp (900569) | more than 3 years ago | (#32846366)

Assuming Chris is singular, then it's Chris's brother's. Although I think both ways are considered correct now, IIRC.

Re:Let me get THIS straight..... (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32844528)

Extremely simple and logical. ITS is a possessive pronoun. Something belongs to the it, whatever the "it" is.

In the same class of words, hers, his, ours, theirs. Yet no one ever writes hi's, her's, our's or their's, do they?

Possessive pronouns are ALREADY possessive, so you don't need an apostrophe. Simple. Logical.

IT ' S is a contraction. The apostrophe shows some letters have been elided. IT IS or IT WAS.

So? Take the it's, replace with IT IS. Does it make sense? No? Then you want ITS.

End of lesson.

Re:Let me get THIS straight..... (1)

QRDeNameland (873957) | more than 3 years ago | (#32845712)

After a decade of studying english and using it practically daily, I still always need to think a few seconds before writing either "its" or "it's".

One way that was taught to me...think of you're (contraction) vs. your (possessive), which is easier to distinguish due to the 'e' in the former. It's/its follows the same rule...the apostrophe is the contraction, not the possessive.

Re:Let me get THIS straight..... (-1)

Anonymous Coward | more than 3 years ago | (#32844072)

"It's" is always correct. It follows the rules for a possessive and a contraction and it's easy to figure out by the context. "Its" as a word should just die.

Groovy vs Scala? (1)

Megahard (1053072) | more than 3 years ago | (#32842468)

Scala also runs on top of Java and is purported to be useful as a DSL.

Re:Groovy vs Scala? (0)

Anonymous Coward | more than 3 years ago | (#32842878)

yeah and contraly to groovy it is type-safe and functional

Re:Groovy vs Scala? (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32843700)

Groovy is dynamicly-typed but it also supports several features from functional programming languages. Programming functionaly in groovy is actually pretty idiomatic.

Dynamic Languages? (4, Informative)

LeotheQuick (657964) | more than 3 years ago | (#32842500)

Perhaps a candidate for the latest "revelatory" term. IMHO tailoring languages like Groovy or BSH is a lot of fun and can be pretty easy to do, but it's far from a true "dynamic language". Poster above is right about lex / yacc / bison. Also in the C++ world I can recall reading about boost's "spirit" library. Although I think more of these as "parser generators" (perhaps a less revelatory term), at least that is what they were intended to be. Groovy and BSH are mostly nice cause of how they so cleanly interface with java at runtime (both are capable of resolving references via the classloader). I've always found that using them has been a pretty ugly exercise.

Re:Dynamic Languages? (1)

Lord Ender (156273) | more than 3 years ago | (#32842814)

Isn't Groovy just Java-style Ruby? Ruby is about as dynamic as you can get...

Re:Dynamic Languages? (0)

Anonymous Coward | more than 3 years ago | (#32842986)

Groovy takes ideais from many languages but it was mainly inspired by Python.

Re:Dynamic Languages? (2, Insightful)

hibiki_r (649814) | more than 3 years ago | (#32843368)

That's a major oversimplification. Groovy is not all that Ruby-like in the end. It has closures, and there's a library that resembles Ruby on Rails on it, but it's not really the same kind of animal. I'd say it's closer to a version of Java that tries to look like a scripting language than it is to a version of Ruby that tries to interact with a JVM.

In newer versions of groovy, you could copy Java code, paste it in a .groovy file, and the groovy compiler will treat it as groovy.

Re:Dynamic Languages? (2, Interesting)

mcvos (645701) | more than 3 years ago | (#32845384)

It's a shame. Superficially it looks a lot like Java with all the good stuff from Ruby in it, but Groovy is really hampered by its compatibility with Java.

0 evaluating as false is really incredibly annoying, and a major cause of bugs.

ho28o (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32842914)

most people into a BSD fanatics? I've Theo de RRadt, one ultimately, we

Re:ho28o (0)

Anonymous Coward | more than 3 years ago | (#32843656)

Is this an example of a domain specific language? I'd imagine it'd run on the English VM but would probably cause a core dump in the brain pan.

My girlfriend has DSLs. (1)

scorp1us (235526) | more than 3 years ago | (#32842938)

But she's nothing compared yo your mom!

Re:My girlfriend has DSLs. (1)

fm6 (162816) | more than 3 years ago | (#32842964)

Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.

Such as lame jokes like this one? Thank God for that!

Parser generators (2, Interesting)

Animats (122034) | more than 3 years ago | (#32843328)

Parser generators are a well-studied problem, and there are good solutions. Unfortunately, the "dynamic scripting language" people don't seem to be much into parsing theory. Trying to get a complex grammar to go through yacc or bison isn't easy, but at least once the parser generator will accept it, you know you've hammered out the ambiguities. It's much easier to get parsers from systems like "pyparsing" to sort of work, but you have to run many test cases to get them to work right.

(I'm currently writing a parser with "pyparsing" for US postal addresses. There's a trivial one available, but it doesn't handle the hard cases, and I had to essentially rewrite it. This is not fun. Some current fails: "969 Edgewater G370", "32545B Golden Lantern 147", "3853 7 Trees Blvd". It's not too hard to get to 98% success; then there's a proliferation of special cases.)

Re:Parser generators (3, Insightful)

$RANDOMLUSER (804576) | more than 3 years ago | (#32843772)

It's not about parsers, or parser generators, and particularly not about "parsing theory" at all. It's about writing programs that read and write programs; in the case of DSLs, it's about writing a program in one language, that accepts a program written in another (domain specific) language, which then either performs actions or writes yet another program. As an example, make, written in C, reads a makefile, which contains a domain-specific language which tells make what to do. Or, in the case of lex and yacc, two C programs which read files written in their own mini-languages and output a third program, the lexer/parser itself.

Back in the early 80's, I wrote a control program for a HIPOT tester (in FORTH) which read in a file that looked like:
Test1: Pin 5, 10000 volts, 10 seconds;
Test2: Pin 3, 15000 volts, 5 seconds;
etc.

The control program ran the tests, determined pass/fail, printed failure tickets, etc. The test engineers never knew they were "writing programs", they just thought they were describing a series of test steps to perform.

Re:Parser generators (1)

oldhack (1037484) | more than 3 years ago | (#32847562)

For non-trivial languages, parsing is half the battle, often good deal more. How is Groovy superior to using a parser generator? Or is it only for trivial/simple languages?

Re:Parser generators (1)

fjptdyjs (1859466) | more than 3 years ago | (#32950488)

There are some cheap jerseys [brandjerseys.com] of nfl new york giants .The shop not only has nfl jerseys [nfljerseys...salers.com] but also supplied nhl hockey jerseys [brandjerseys.com] ,mlb baseball jerseys [nfljerseys...salers.com] .It is a good way for us fans to show our enthusiasm .there are some new style :nfl jerseys [jerseysshops.com] new york giants #11 simms m&n blue nfl new york giants 44# bradshaw blue nfl new york giants #80 shockey blue and so on .the more information ,please visit NFL shop [jerseysshops.com]

How is Groovy different from BeanShell? (0)

Anonymous Coward | more than 3 years ago | (#32843566)

I've used BeanShell [beanshell.org] for scripting in Java, so I'm just wondering what advantage Groovy would have.

Re:How is Groovy different from BeanShell? (1)

sourcerror (1718066) | more than 3 years ago | (#32845412)

It feels like Python/Ruby:
- you can redefine methods in runtime
- short syntax for using queue/stack/list
- anonymous functions

Good idea (2, Funny)

ch-chuck (9622) | more than 3 years ago | (#32843842)

I'll have to add the Domain Specific Language to my proposal for cloud computing to be presented at the management consultant meeting.

Re:Good idea (0)

Anonymous Coward | more than 3 years ago | (#32846038)

I use a domain-specific language in my cloud computing solution offering, you insensitive clod!

(I'm not kidding)

Do we need this? (1)

Petersko (564140) | more than 3 years ago | (#32844780)

There should be two questions asked before any new language is undertaken:

1 - Does it allow you to do something that couldn't be done before?

2 - If not, does it allow faster development or better performance than an existing technology?

3 - If not, are all alternatives in licensing you don't agree with?

If not... don't... fucking... start. Seriously, we don't need yet another way to do the same crap we've already been doing.

Yes I CAN Count to 3 (1)

Petersko (564140) | more than 3 years ago | (#32844894)

"There should be two questions asked before any new language is undertaken:"

Make that 3. Yay for proofreading.

Re:Do we need this? (1)

sourcerror (1718066) | more than 3 years ago | (#32845378)

Tell me please, how did you write domain specific languages for the Java platform so far?

Re:Do we need this? (0)

Anonymous Coward | more than 3 years ago | (#32851082)

There is a java version of yacc called JavaCC:

https://javacc.dev.java.net/

I've used it, it works quite well.

Re:Do we need this? (2, Interesting)

DuckDodgers (541817) | more than 3 years ago | (#32847282)

I don't use Groovy, but I understand it was originally built to satisfy your second requirement. It fits in the existing setup of Java servlets and the JVM, but is a scripting language. Using Groovy to cut out the need to recompile and reload your Java web application after most changes often speeds development time dramatically.

Over the past few years a few other methods for loading changes to your Java web app without reloading the entire application have appeared, and I don't see a need for Groovy. But I understand why it was created, and I think its existence probably helped other people to brainstorm cleaner ways to have their applications reload changes more quickly.

I call shillanigans. (0)

Anonymous Coward | more than 3 years ago | (#32936374)

I'd just like to point out that each of Wagner's other Packt reviews were highly favorable. This is unusual for a Packt book, particularly when it comes to their editing process--most of us play "which is the first page with an error", and it's always within the first dozen or two pages. Every single one of his book reviews is a Packt books. Every single one of them is a good review with essentially no negative comments whatsoever.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...