Skip to end of metadata
Go to start of metadata

Here are some general rules of thumb which may help motivate specific
design decisions.

(If people find these useful, we should link them into the Aims page. --jrose)

Stay streamlined

Avoid requiring many tokens when a frequent use case is 'obvious'. (See also PHIM, below.)

  • Prefer instead of the more ornate;.
  • Use the assignment syntax for all sorts of updates, such as amap[akey] = anewval.
  • Compact notations for object (string...) matching and (de-)construction.
  • Optional elision of types in all declarations.

PHIM: "Parse how I mean"

Moderate context sensitivity lets common cases be simple while keeping the general case general.

  • Supply trailing semicolons at newlines when necessary.
  • Allow method invocations to omit empty argument lists; see optional parenthesis.
    (Use a more ornate syntax for the rarer case of getting reflective pointers.)
  • Allow singleton argument lists to omit optional parenthesis.
  • Treat blocks as closures where it's likely the user needs them.
  • Treat names as symbolic constants exactly where it makes sense.
    For example, y instead of y or $y.
  • In contexts which require declarations, let a simple x or x=y suffice.
  • When a context requires only a type, parse a type. Otherwise, suspend judgement between type and method names, until semantic analysis.

The tricky side of this principle is that the context sensitivity must be so smooth that users tend not to notice it.
(Principle of Least Surprise.)

Also, every such clever context sensitivity must provide an escape hatch, a way for the programmer to add extra tokens that force an unusual parsing decision.

Build on the Microarchitecture

Simplified foundations make Groovy consistent and extensible.
A good bazaar has few laws and many negotiable customs.

Many syntaxes can be defined as library methods on top of overloaded operators.

Be like Java

Java expressions (often) behave the same when pasted into Groovy.
(Principle of Least Surprise.)

  • No labels

1 Comment

  1. Take a look at the Aims page, and you'll see that many of the design tactics suggested here are in direct opposition to the language aims.

    Certainly, the first item listed in Aims is to be concise, powerful and high level - allowing people to get things done quickly on the Java platform, which might seem to contradict what I'm saying. But look at the other aims to be easy to learn for Java developers building heavily on existing knowledge & tools, easy to reuse existing Java code and reuse the J2SE and J2EE APIs, have a simple and clean mapping direct to bytecode so that Groovy mixes seamlessly with Java code, follow the principle of least surprise.

    These aims make some things abundantly clear:

    • Groovy is all about Java interoperability. Groovy is about gluing Java code together. Groovy users will inevitably know Java very well.
    • It can be presumed that many Java programmers (some might say most) do not know very many scripting languages, and the ones they do know they do not know well.
    • It says directly that it should be easy to learn for Java programmers, and talks about the principle of least surprise. I believe it is obvious that this should mean Groovy should provide the least surprise to Java programmers.

    These points are critical in determining what the design goals of Groovy should be. Let's assume for a moment that we zoom ahead 3 years and Groovy is a fabulous success. Let's pretend this user base is 100,000 users. And let's take a poll of those users.

    How many of those developers are going to be Perl or Ruby or Python users who switched to Groovy or use Groovy as an alternative on some occasions? I would be astonished if this number was over 5%.

    How many of these developers will be people who wandered in will use Groovy primarily for non-Java scripting tasks? Who literally are using Groovy where people use Perl or Ruby or Python today? This number is probably around 1%.

    Now, how many of those users will be Java developers? How many of them are using Groovy in its primary form - to script Java code? I think you can guarantee that these people will be at 90% or higher.

    Now let's consider those users and Groovy. Obviously, Groovy is supposed to add power and loosen restrictions, and generally make scripting Java a pleasurable and easy activity. Along those lines, Groovy supports native collections, closures, convenience methods added to the JDK, dynamic typing, and a host of other features. The question then becomes - how do you present these features to developers who will overwhelming be Java developers who know little or nothing about perl/Ruby/Python?

    I think there are two obvious roads you can take here. On the one hand, you can show Groovy as a more powerful and concise language to Java, but which is still clearly Java-based. You can clearly add dynamic typing, native collections, closures, etc to Java in a way which is minimally disruptive to Java developers - but which is still far more compact than the Java equivalent, and which still provides more power.

    On the other hand, you can choose to largely ignore Java and invent a new language. To a large extent this is what this design tactics page is advocating. In particular, a language where terseness is one of the top design goals, and to go along with that context sensitivity is used to determine "how I mean", and to go along with those two adding in tons of optionality (driven largely by context sensitivity).

    This combination of tactics do not add power to the language, but they do make the language much more concise. But this begs the question - does this make the language easy enough to learn? Does terseness really make the language to write in? And does terseness make the language easier to read?

    Keep those 90% Java users in mind. Many of them came to Java because it was easy to use, easy to understand, and of course far safer than something like C++. And many of them love it because even very junior Java developers can read just about anyone's Java code and understand what is going on. Oh, they might grok what the code really does, but they will understand the language and the statements.

    But in the design goals put forth here, that is not the case. Average and newbie developers in Java will have a very hard time with Groovy. They will not be able to glance at a bit of code and know what it means - they will have to understand the surroundin context and how the compiler is interpreting that with its clever context sensitivity. Worse, they will try to write code and get cryptic error messages that, as Java programmers, looks perfectly fine to them.

    In fact, Groovy will appear to Java developers as "perl light". It'll be more Java like than perl, but like perl it'll have all these weird rules and optional elements that will serve primarily to confuse. The end result will be a language which gurus love, and average users approach with fear. The end result with be "cargo cult" programming, where average developers copy the guru's incantations verbatim and say a prayer that the incomprehensible code will work for them.

    In conclusion making a scripting language which is more concise than Java and adds power is a very admirable goal. But the question becomes: will that language will be friendly to average Java programmers, and a language they are eager to use? Or will Perlaphobia have a new entry put in beside it - Groovyphobia?

    Or worse - will Groovy just wither on the vine because with all this hassle they might as well use beanshell, or perl, or Python, or Ruby?