[ANN] specs 1.5.0

On Thu, May 7, 2009 at 18:41, Eric Torreborre wrote:
>
> I'm very pleased to announce the release of  http://code.google.com/p/specs/
> specs 1.5.0 .

...

>  1. the possibility to adopt a more English-like syntax, following the path
> that ScalaTest has shown with its 0.9.5 release. For example you can now
> write:
>
> "hello" must be matching ("h.*") and not be matching ("z.*")
>
>  instead of
>
> "hello" must (beMatching("h.*") and not(beMatching("z.*")))

It is useless and wrong. Programs need not to be like English text. It
does not make them easier to read, but creates lots of troubles trying
to solve compilation problems for new specs users.

S.

It does make them easier to read.  It is neither useless nor wrong.  Specs can also be used without this style if you so prefer.

2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>

On Thu, May 7, 2009 at 18:41, Eric Torreborre <etorreborre@yahoo.com> wrote:
>
> I'm very pleased to announce the release of  http://code.google.com/p/specs/
> specs 1.5.0 .

...

>  1. the possibility to adopt a more English-like syntax, following the path
> that ScalaTest has shown with its 0.9.5 release. For example you can now
> write:
>
> "hello" must be matching ("h.*") and not be matching ("z.*")
>
>  instead of
>
> "hello" must (beMatching("h.*") and not(beMatching("z.*")))

It is useless and wrong. Programs need not to be like English text. It
does not make them easier to read, but creates lots of troubles trying
to solve compilation problems for new specs users.

S.

The point is not to make Specs syntax into natural language, but to move its DSL into a more literate form.  This is really the whole point to behavior-driven development.  When it really comes down to it, BDD is no different from standard unit testing except for in the syntax.  I'll agree that there is a danger here, but I don't think it's as bad as you think.  I've been using Specs for quite a while now, and while I have had some issues, none of them have ever been caused by the syntax.

Daniel

On Thu, May 7, 2009 at 9:57 AM, Stepan Koltsov <stepancheg@mx1.ru> wrote:

On Thu, May 7, 2009 at 18:41, Eric Torreborre <etorreborre@yahoo.com> wrote:
>
> I'm very pleased to announce the release of  http://code.google.com/p/specs/
> specs 1.5.0 .

...

>  1. the possibility to adopt a more English-like syntax, following the path
> that ScalaTest has shown with its 0.9.5 release. For example you can now
> write:
>
> "hello" must be matching ("h.*") and not be matching ("z.*")
>
>  instead of
>
> "hello" must (beMatching("h.*") and not(beMatching("z.*")))

It is useless and wrong. Programs need not to be like English text. It
does not make them easier to read, but creates lots of troubles trying
to solve compilation problems for new specs users.

S.

On Thursday May 7 2009, Eric Torreborre wrote:
> Hi all,
>
> I'm very pleased to announce the release of
> http://code.google.com/p/specs/ specs 1.5.0 .
>
> Just as a reminder, specs is a Behavior-Driven Development library
> for Scala, providing simple ways to write software specifications:
>
> object helloWorld extends Specification {
> "'hello world' has 11 characters" in {
> "hello world".size must be equalTo(11)
> }
> "'hello world' matches 'h.* w.*'" in {
> "hello world" must be matching("h.* w.*")
> }
> }

Is there a reason why this example (and others like it) can't be more
like this:

... "hellow world" must match("h.* w.*") ...

It seems much more natural to me.

> ...
>
> Cheers,
>
> Eric.
>
> ...

Randall Schulz

On Thu, May 7, 2009 at 19:03, Ricky Clarkson wrote:
> It does make them easier to read.

It raises questions like: Does it really work? Did I miss some another
an article near the noun? Does operator precedence work properly in
complex expression?

You understand what author meant, of course, but when you debugging
code written by somebody else, this complexity works against you.

>  It is neither useless nor wrong.  Specs
> can also be used without this style if you so prefer.

Multiple ways of doing same thing increases library size, so makes
library harder to learn.

S.

> 2009/5/7 Stepan Koltsov
>>
>> On Thu, May 7, 2009 at 18:41, Eric Torreborre
>> wrote:
>> >
>> > I'm very pleased to announce the release of
>> >  http://code.google.com/p/specs/
>> > specs 1.5.0 .
>>
>> ...
>>
>> >  1. the possibility to adopt a more English-like syntax, following the
>> > path
>> > that ScalaTest has shown with its 0.9.5 release. For example you can now
>> > write:
>> >
>> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >
>> >  instead of
>> >
>> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>>
>> It is useless and wrong. Programs need not to be like English text. It
>> does not make them easier to read, but creates lots of troubles trying
>> to solve compilation problems for new specs users.
>>
>> S.
>
>

That's where documentation comes into play.  http://code.google.com/p/specs/wiki/MatchersGuide  Specs has some really excellent documentation.  It's not too much, but it is kept up to date (it is appreciated, Eric!).  My only complaint on this front is the scaladoc is quite a bit behind the times.  Thankfully, the rest of the documentation makes the scaladoc almost unnecessary.

Daniel

On Thu, May 7, 2009 at 10:19 AM, Stepan Koltsov <stepancheg@mx1.ru> wrote:

On Thu, May 7, 2009 at 19:03, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
> It does make them easier to read.

It raises questions like: Does it really work? Did I miss some another
an article near the noun? Does operator precedence work properly in
complex expression?

You understand what author meant, of course, but when you debugging
code written by somebody else, this complexity works against you.

>  It is neither useless nor wrong.  Specs
> can also be used without this style if you so prefer.

Multiple ways of doing same thing increases library size, so makes
library harder to learn.

S.

> 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>>
>> On Thu, May 7, 2009 at 18:41, Eric Torreborre <etorreborre@yahoo.com>
>> wrote:
>> >
>> > I'm very pleased to announce the release of
>> >  http://code.google.com/p/specs/
>> > specs 1.5.0 .
>>
>> ...
>>
>> >  1. the possibility to adopt a more English-like syntax, following the
>> > path
>> > that ScalaTest has shown with its 0.9.5 release. For example you can now
>> > write:
>> >
>> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >
>> >  instead of
>> >
>> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>>
>> It is useless and wrong. Programs need not to be like English text. It
>> does not make them easier to read, but creates lots of troubles trying
>> to solve compilation problems for new specs users.
>>
>> S.
>
>

If it won't work, it won't compile, mostly.  It is trivial to convert that syntax to regular.calls(like).this, if you have any doubts about precedence.  Though doubts about precedence should be resolved by learning the language's rules.

The result is you need to learn Specs via its documentation or tests, instead of via the source or scaladoc.

Multiple ways of doing the same thing can be ok.  Specs' documentation doesn't let the more verbose way get in the way of learning to use Specs.  Imaginary problems are imaginary.

2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>

On Thu, May 7, 2009 at 19:03, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
> It does make them easier to read.

It raises questions like: Does it really work? Did I miss some another
an article near the noun? Does operator precedence work properly in
complex expression?

You understand what author meant, of course, but when you debugging
code written by somebody else, this complexity works against you.

>  It is neither useless nor wrong.  Specs
> can also be used without this style if you so prefer.

Multiple ways of doing same thing increases library size, so makes
library harder to learn.

S.

> 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>>
>> On Thu, May 7, 2009 at 18:41, Eric Torreborre <etorreborre@yahoo.com>
>> wrote:
>> >
>> > I'm very pleased to announce the release of
>> >  http://code.google.com/p/specs/
>> > specs 1.5.0 .
>>
>> ...
>>
>> >  1. the possibility to adopt a more English-like syntax, following the
>> > path
>> > that ScalaTest has shown with its 0.9.5 release. For example you can now
>> > write:
>> >
>> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >
>> >  instead of
>> >
>> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>>
>> It is useless and wrong. Programs need not to be like English text. It
>> does not make them easier to read, but creates lots of troubles trying
>> to solve compilation problems for new specs users.
>>
>> S.
>
>

Daniel Spiewak writes:

>  My only complaint on this front is the scaladoc is quite a bit behind the
times. 

I know. Unfortunately there seems to be a bug with the vscaladoc, choking on
specs. We're trying to solve the issue with David Bernard and I hope to be able
to post the updated scaladoc version online soon.

E.

On Thu, May 7, 2009 at 19:32, Ricky Clarkson wrote:
> If it won't work, it won't compile, mostly.  It is trivial to convert that
> syntax to regular.calls(like).this, if you have any doubts about
> precedence.  Though doubts about precedence should be resolved by learning
> the language's rules.
>
> The result is you need to learn Specs via its documentation or tests,
> instead of via the source or scaladoc.
>
> Multiple ways of doing the same thing can be ok.  Specs' documentation
> doesn't let the more verbose way get in the way of learning to use Specs.
> Imaginary problems are imaginary.

It's a bit flaming statement:
It is imaginary problem while you write small projects alone in your
favorite language. Problems are real when you are trying to hack a big
project, written in foreign language written by a group of people you
don't know. In this case you don't want to read or learn anything.
You'd like everything to be simple and obvious.

S.

> 2009/5/7 Stepan Koltsov
>>
>> On Thu, May 7, 2009 at 19:03, Ricky Clarkson
>> wrote:
>> > It does make them easier to read.
>>
>> It raises questions like: Does it really work? Did I miss some another
>> an article near the noun? Does operator precedence work properly in
>> complex expression?
>>
>> You understand what author meant, of course, but when you debugging
>> code written by somebody else, this complexity works against you.
>>
>> >  It is neither useless nor wrong.  Specs
>> > can also be used without this style if you so prefer.
>>
>> Multiple ways of doing same thing increases library size, so makes
>> library harder to learn.
>>
>> S.
>>
>> > 2009/5/7 Stepan Koltsov
>> >>
>> >> On Thu, May 7, 2009 at 18:41, Eric Torreborre
>> >> wrote:
>> >> >
>> >> > I'm very pleased to announce the release of
>> >> >  http://code.google.com/p/specs/
>> >> > specs 1.5.0 .
>> >>
>> >> ...
>> >>
>> >> >  1. the possibility to adopt a more English-like syntax, following
>> >> > the
>> >> > path
>> >> > that ScalaTest has shown with its 0.9.5 release. For example you can
>> >> > now
>> >> > write:
>> >> >
>> >> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >> >
>> >> >  instead of
>> >> >
>> >> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>> >>
>> >> It is useless and wrong. Programs need not to be like English text. It
>> >> does not make them easier to read, but creates lots of troubles trying
>> >> to solve compilation problems for new specs users.
>> >>
>> >> S.
>> >
>> >
>
>

Congratulations!

We'll update Lift to use Specs 1.5.

Rock on!

On Thu, May 7, 2009 at 7:41 AM, Eric Torreborre <etorreborre@yahoo.com> wrote:

Hi all,

I'm very pleased to announce the release of  http://code.google.com/p/specs/
specs 1.5.0 .

Just as a reminder, specs is a Behavior-Driven Development library for
Scala, providing simple ways to write software specifications:

object helloWorld extends Specification {
 "'hello world' has 11 characters" in {
    "hello world".size must be equalTo(11)
 }
 "'hello world' matches 'h.* w.*'" in {
    "hello world" must be matching("h.* w.*")
 }
}

It is integrated with many other libraries for execution or specification:
JUnit, ScalaTest, ScalaCheck, Mockito, JMock.

This new release brings 2 main features:

 1. the possibility to adopt a more English-like syntax, following the path
that ScalaTest has shown with its 0.9.5 release. For example you can now
write:

"hello" must be matching ("h.*") and not be matching ("z.*")

 instead of

"hello" must (beMatching("h.*") and not(beMatching("z.*")))

 2. a  http://fit.c2.com FIT-like  library. This offers the possibility to
specify (using Scala only) specifications which are readable by non-IT
users. You can find some basic examples
http://specs.googlecode.com/svn/samples/LiterateSpecifications/ here  and a
blog post describing the main ideas
http://etorreborre.blogspot.com/2009/04/fit-like-library-for-scala.html
there .

Note however that this is only considered being at the alpha stage. The api
can evolve a bit and more real-world experience is needed to validate the
approach.

Please provide feed-back, ideas, wishes, comments on the
http://groups.google.com/group/specs-users specs-users  google group.

Cheers,

Eric.

PS: it has been compiled and tested with Scala-2.7.4-final.
--
View this message in context: http://www.nabble.com/-ANN--specs-1.5.0-tp23428328p23428328.html
Sent from the Scala - Tools mailing list archive at Nabble.com.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Daniel,

While the vscaladoc issue is being worked on, you can use the updated scaladoc
I just uploaded: http://specs.googlecode.com/svn/docs/scaladocs-
1.5.0/index.html

I also keep a note to review the scaladoc for the next version as I can see
numerous formatting issues or missing docs.

Eric.

I agree.  I would also maintain that the following is not simple or obvious:

assertEquals(abc, def);
assertGreaterThan(ghi, jkl);

So, which side is which here?  And what if you pass an array (or other collection) into assertEquals?  My point is that just because Specs uses a more natural syntax than JUnit doesn't make it harder to work with in a team setting.  In fact, I would argue that it is easier to read and understand precisely because of that syntax.  I don't think that the Specs API is any harder than JUnit and it certainly results in more natural-sounding code.

Daniel

On Thu, May 7, 2009 at 10:52 AM, Stepan Koltsov <stepancheg@mx1.ru> wrote:

On Thu, May 7, 2009 at 19:32, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
> If it won't work, it won't compile, mostly.  It is trivial to convert that
> syntax to regular.calls(like).this, if you have any doubts about
> precedence.  Though doubts about precedence should be resolved by learning
> the language's rules.
>
> The result is you need to learn Specs via its documentation or tests,
> instead of via the source or scaladoc.
>
> Multiple ways of doing the same thing can be ok.  Specs' documentation
> doesn't let the more verbose way get in the way of learning to use Specs.
> Imaginary problems are imaginary.

It's a bit flaming statement:
It is imaginary problem while you write small projects alone in your
favorite language. Problems are real when you are trying to hack a big
project, written in foreign language written by a group of people you
don't know. In this case you don't want to read or learn anything.
You'd like everything to be simple and obvious.

S.

> 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>>
>> On Thu, May 7, 2009 at 19:03, Ricky Clarkson <ricky.clarkson@gmail.com>
>> wrote:
>> > It does make them easier to read.
>>
>> It raises questions like: Does it really work? Did I miss some another
>> an article near the noun? Does operator precedence work properly in
>> complex expression?
>>
>> You understand what author meant, of course, but when you debugging
>> code written by somebody else, this complexity works against you.
>>
>> >  It is neither useless nor wrong.  Specs
>> > can also be used without this style if you so prefer.
>>
>> Multiple ways of doing same thing increases library size, so makes
>> library harder to learn.
>>
>> S.
>>
>> > 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>> >>
>> >> On Thu, May 7, 2009 at 18:41, Eric Torreborre <etorreborre@yahoo.com>
>> >> wrote:
>> >> >
>> >> > I'm very pleased to announce the release of
>> >> >  http://code.google.com/p/specs/
>> >> > specs 1.5.0 .
>> >>
>> >> ...
>> >>
>> >> >  1. the possibility to adopt a more English-like syntax, following
>> >> > the
>> >> > path
>> >> > that ScalaTest has shown with its 0.9.5 release. For example you can
>> >> > now
>> >> > write:
>> >> >
>> >> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >> >
>> >> >  instead of
>> >> >
>> >> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>> >>
>> >> It is useless and wrong. Programs need not to be like English text. It
>> >> does not make them easier to read, but creates lots of troubles trying
>> >> to solve compilation problems for new specs users.
>> >>
>> >> S.
>> >
>> >
>
>

I wish to support Stepan in his flaming statement. We're not all
English speakers, and almost-English can be quite confusing. It's
important that it things be readable from the get-go -- to say that
you could read it, after you translate it to another form, is not the
same as being able to read it as is.

With DSLs, I think you need to make a distinction between using an
existing DSL (e.g., mathematics, music, chemistry) and inventing a new
DSL. The point of (adapting) an existing DSL is to avoid the need to
learn new rules.

David

On 2009-05-07, at 11:52 AM, Stepan Koltsov wrote:

> On Thu, May 7, 2009 at 19:32, Ricky Clarkson
> wrote:
>> If it won't work, it won't compile, mostly. It is trivial to
>> convert that
>> syntax to regular.calls(like).this, if you have any doubts about
>> precedence. Though doubts about precedence should be resolved by
>> learning
>> the language's rules.
>>
>> The result is you need to learn Specs via its documentation or tests,
>> instead of via the source or scaladoc.
>>
>> Multiple ways of doing the same thing can be ok. Specs'
>> documentation
>> doesn't let the more verbose way get in the way of learning to use
>> Specs.
>> Imaginary problems are imaginary.
>
> It's a bit flaming statement:
> It is imaginary problem while you write small projects alone in your
> favorite language. Problems are real when you are trying to hack a big
> project, written in foreign language written by a group of people you
> don't know. In this case you don't want to read or learn anything.
> You'd like everything to be simple and obvious.
>
> S.

I'd guess those projects are more likely to use Java 1.3 than Scala.  Unless you're going to maintain a whole mirror of Scala, keywords, libs and all, in Russian, you're likely better off learning English properly and writing code in English.

I'm not being xenophobic on this; I read some (C#) code recently in Spanish, and even though I understood all the identifiers, the constant switching of languages detracted a lot from readability.  I think I'd have found it easier either all in English or all in Spanish.

Though @using two languages helps when there are collisions `with` keywords :)

If you think I was flaming, take a look at "useless and wrong" from your opening email.

2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>

On Thu, May 7, 2009 at 19:32, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
> If it won't work, it won't compile, mostly.  It is trivial to convert that
> syntax to regular.calls(like).this, if you have any doubts about
> precedence.  Though doubts about precedence should be resolved by learning
> the language's rules.
>
> The result is you need to learn Specs via its documentation or tests,
> instead of via the source or scaladoc.
>
> Multiple ways of doing the same thing can be ok.  Specs' documentation
> doesn't let the more verbose way get in the way of learning to use Specs.
> Imaginary problems are imaginary.

It's a bit flaming statement:
It is imaginary problem while you write small projects alone in your
favorite language. Problems are real when you are trying to hack a big
project, written in foreign language written by a group of people you
don't know. In this case you don't want to read or learn anything.
You'd like everything to be simple and obvious.

S.

> 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>>
>> On Thu, May 7, 2009 at 19:03, Ricky Clarkson <ricky.clarkson@gmail.com>
>> wrote:
>> > It does make them easier to read.
>>
>> It raises questions like: Does it really work? Did I miss some another
>> an article near the noun? Does operator precedence work properly in
>> complex expression?
>>
>> You understand what author meant, of course, but when you debugging
>> code written by somebody else, this complexity works against you.
>>
>> >  It is neither useless nor wrong.  Specs
>> > can also be used without this style if you so prefer.
>>
>> Multiple ways of doing same thing increases library size, so makes
>> library harder to learn.
>>
>> S.
>>
>> > 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>> >>
>> >> On Thu, May 7, 2009 at 18:41, Eric Torreborre <etorreborre@yahoo.com>
>> >> wrote:
>> >> >
>> >> > I'm very pleased to announce the release of
>> >> >  http://code.google.com/p/specs/
>> >> > specs 1.5.0 .
>> >>
>> >> ...
>> >>
>> >> >  1. the possibility to adopt a more English-like syntax, following
>> >> > the
>> >> > path
>> >> > that ScalaTest has shown with its 0.9.5 release. For example you can
>> >> > now
>> >> > write:
>> >> >
>> >> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >> >
>> >> >  instead of
>> >> >
>> >> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>> >>
>> >> It is useless and wrong. Programs need not to be like English text. It
>> >> does not make them easier to read, but creates lots of troubles trying
>> >> to solve compilation problems for new specs users.
>> >>
>> >> S.
>> >
>> >
>
>

With respect to English being the lingua franca of coding, see this classic article by Eric S Raymond: http://www.catb.org/~esr/faqs/hacker-howto.html  It does sound extremely xenophobic and self-serving, especially coming from an American, but the truth is that English really is the standard language of computer programming.

Daniel

On Thu, May 7, 2009 at 11:26 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

I'd guess those projects are more likely to use Java 1.3 than Scala.  Unless you're going to maintain a whole mirror of Scala, keywords, libs and all, in Russian, you're likely better off learning English properly and writing code in English.

I'm not being xenophobic on this; I read some (C#) code recently in Spanish, and even though I understood all the identifiers, the constant switching of languages detracted a lot from readability.  I think I'd have found it easier either all in English or all in Spanish.

Though @using two languages helps when there are collisions `with` keywords :)

If you think I was flaming, take a look at "useless and wrong" from your opening email.

2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>

On Thu, May 7, 2009 at 19:32, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
> If it won't work, it won't compile, mostly.  It is trivial to convert that
> syntax to regular.calls(like).this, if you have any doubts about
> precedence.  Though doubts about precedence should be resolved by learning
> the language's rules.
>
> The result is you need to learn Specs via its documentation or tests,
> instead of via the source or scaladoc.
>
> Multiple ways of doing the same thing can be ok.  Specs' documentation
> doesn't let the more verbose way get in the way of learning to use Specs.
> Imaginary problems are imaginary.

It's a bit flaming statement:
It is imaginary problem while you write small projects alone in your
favorite language. Problems are real when you are trying to hack a big
project, written in foreign language written by a group of people you
don't know. In this case you don't want to read or learn anything.
You'd like everything to be simple and obvious.

S.

> 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>>
>> On Thu, May 7, 2009 at 19:03, Ricky Clarkson <ricky.clarkson@gmail.com>
>> wrote:
>> > It does make them easier to read.
>>
>> It raises questions like: Does it really work? Did I miss some another
>> an article near the noun? Does operator precedence work properly in
>> complex expression?
>>
>> You understand what author meant, of course, but when you debugging
>> code written by somebody else, this complexity works against you.
>>
>> >  It is neither useless nor wrong.  Specs
>> > can also be used without this style if you so prefer.
>>
>> Multiple ways of doing same thing increases library size, so makes
>> library harder to learn.
>>
>> S.
>>
>> > 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>> >>
>> >> On Thu, May 7, 2009 at 18:41, Eric Torreborre <etorreborre@yahoo.com>
>> >> wrote:
>> >> >
>> >> > I'm very pleased to announce the release of
>> >> >  http://code.google.com/p/specs/
>> >> > specs 1.5.0 .
>> >>
>> >> ...
>> >>
>> >> >  1. the possibility to adopt a more English-like syntax, following
>> >> > the
>> >> > path
>> >> > that ScalaTest has shown with its 0.9.5 release. For example you can
>> >> > now
>> >> > write:
>> >> >
>> >> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >> >
>> >> >  instead of
>> >> >
>> >> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>> >>
>> >> It is useless and wrong. Programs need not to be like English text. It
>> >> does not make them easier to read, but creates lots of troubles trying
>> >> to solve compilation problems for new specs users.
>> >>
>> >> S.
>> >
>> >
>
>

Well, here's the question then: what would be the optimal DSL for defining a specification?  This is very much a subjective issue, as illustrated by the fact that I think that Specs is already pretty close to optimal.  :-)

Daniel

On Thu, May 7, 2009 at 11:18 AM, David Chase <dr2chase@mac.com> wrote:

I wish to support Stepan in his flaming statement.  We're not all English speakers, and almost-English can be quite confusing.  It's important that it things be readable from the get-go -- to say that you could read it, after you translate it to another form, is not the same as being able to read it as is.

With DSLs, I think you need to make a distinction between using an existing DSL (e.g., mathematics, music, chemistry) and inventing a new DSL.  The point of (adapting) an existing DSL is to avoid the need to learn new rules.

David

On 2009-05-07, at 11:52 AM, Stepan Koltsov wrote:

On Thu, May 7, 2009 at 19:32, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

If it won't work, it won't compile, mostly.  It is trivial to convert that
syntax to regular.calls(like).this, if you have any doubts about
precedence.  Though doubts about precedence should be resolved by learning
the language's rules.

The result is you need to learn Specs via its documentation or tests,
instead of via the source or scaladoc.

Multiple ways of doing the same thing can be ok.  Specs' documentation
doesn't let the more verbose way get in the way of learning to use Specs.
Imaginary problems are imaginary.

It's a bit flaming statement:
It is imaginary problem while you write small projects alone in your
favorite language. Problems are real when you are trying to hack a big
project, written in foreign language written by a group of people you
don't know. In this case you don't want to read or learn anything.
You'd like everything to be simple and obvious.

S.

Congratulations!!
Specs is really a fantastic tool.

thanks a lot.

G

On 5/7/09, Eric Torreborre wrote:
>
> Hi all,
>
> I'm very pleased to announce the release of http://code.google.com/p/specs/
> specs 1.5.0 .
>
> Just as a reminder, specs is a Behavior-Driven Development library for
> Scala, providing simple ways to write software specifications:
>
> object helloWorld extends Specification {
> "'hello world' has 11 characters" in {
> "hello world".size must be equalTo(11)
> }
> "'hello world' matches 'h.* w.*'" in {
> "hello world" must be matching("h.* w.*")
> }
> }
>
> It is integrated with many other libraries for execution or specification:
> JUnit, ScalaTest, ScalaCheck, Mockito, JMock.
>
> This new release brings 2 main features:
>
> 1. the possibility to adopt a more English-like syntax, following the path
> that ScalaTest has shown with its 0.9.5 release. For example you can now
> write:
>
> "hello" must be matching ("h.*") and not be matching ("z.*")
>
> instead of
>
> "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>
> 2. a http://fit.c2.com FIT-like library. This offers the possibility to
> specify (using Scala only) specifications which are readable by non-IT
> users. You can find some basic examples
> http://specs.googlecode.com/svn/samples/LiterateSpecifications/ here and a
> blog post describing the main ideas
> http://etorreborre.blogspot.com/2009/04/fit-like-library-for-scala.html
> there .
>
> Note however that this is only considered being at the alpha stage. The api
> can evolve a bit and more real-world experience is needed to validate the
> approach.
>
> Please provide feed-back, ideas, wishes, comments on the
> http://groups.google.com/group/specs-users specs-users google group.
>
> Cheers,
>
> Eric.
>
> PS: it has been compiled and tested with Scala-2.7.4-final.
> --
> View this message in context:
> http://www.nabble.com/-ANN--specs-1.5.0-tp23428328p23428328.html
> Sent from the Scala - Tools mailing list archive at Nabble.com.
>
>

On 2009-05-07, at 12:21 PM, Daniel Spiewak wrote:

> Well, here's the question then: what would be the optimal DSL for
> defining a specification? This is very much a subjective issue, as
> illustrated by the fact that I think that Specs is already pretty
> close to optimal. :-)

Okay, so I can point out one "flaw" from the POV of an English
speaker, at least in the example (this is partly in jest, partly not,
and actual constructive criticism):

> object helloWorld extends Specification {
> "'hello world' has 11 characters" in {
> "hello world".size must be equalTo(11)
> }
> "'hello world' matches 'h.* w.*'" in {
> "hello world" must be matching("h.* w.*")
> }
> }

"be equalTo" vs "be matching" ?

why not

"be equalling" vs "be matching"

or

"be equalTo" vs "be matchTo" ?

From the POV of a non-English speaker, you're actually saying things
two different ways already (partly because English gives you at least
two different ways to say it, you speak English, and it blew right
past you). One's a verb+preposition, the other's be+participle.

So even if you stuck to your present design, you could make it better
by attending to these little details and making the "English" more
uniform (i.e., a smaller subset of English and its grammar). There's
probably a best choice for "lots of other non-English speakers" but I
don't know what it is.

As to would there be anything much better, I am not at all sure. It
seems to me that for a specification language, there are two things
going on -- the language for propositions in the domain you are
specifying against ("the song is written in the key of G") and the
language for stringing together propositions in logics, whether
boolean or temporal.

And consider "the song is written in the key of G" vs "(equals (keyof
song) (key 'G'))" vs "a picture of a (treble) clef and a staff with a
sharp (#) on the top line". If you're really talking about facts in
the music domain, the picture is your (sub)language right there.

It occurred to me as I was writing this, that

"Hello World is written in C and Good-Morning to All is written in G"

is a true statement.

( http://en.wikipedia.org/wiki/File:GoodMorningToAll_1893_song.jpg ;
http://en.wikipedia.org/wiki/Happy_Birthday_to_You ;
I was trying to pick a very familiar song, but they claim copyright,
so I went to the one that was in the public domain that the
copyrighted song stole its melody from. )

This gets messy fast, unless you places limits on your domain and your
DSL. At which point, some people might ask, "why not set the limit
dial to S-expressions?"

(and (equals (language-of "Hello World") (language 'C'))
(equals (keyof "Good-Morning to All") (key 'G'))
)

(And lest you wonder if I am some Lisp crazy, I'm working on Fortress,
we think a lot about DSLs, and one important rule is that if you are
not doing better than Lisp, what's the point -- on the other hand,
Lisp has notably failed to penetrate into many places where it is
objectively and technically complete appropriate, so maybe there
really is something wrong with parentheses.)

Just trying to inject a little uncertainty into your life :-).

By the way, have you ever noticed that the phrase "lingua franca" is
made up of two Latin words? :-)

David

>
> Daniel
>
> On Thu, May 7, 2009 at 11:18 AM, David Chase wrote:
> I wish to support Stepan in his flaming statement. We're not all
> English speakers, and almost-English can be quite confusing. It's
> important that it things be readable from the get-go -- to say that
> you could read it, after you translate it to another form, is not
> the same as being able to read it as is.
>
> With DSLs, I think you need to make a distinction between using an
> existing DSL (e.g., mathematics, music, chemistry) and inventing a
> new DSL. The point of (adapting) an existing DSL is to avoid the
> need to learn new rules.
>
> David
>
>
> On 2009-05-07, at 11:52 AM, Stepan Koltsov wrote:
>
> On Thu, May 7, 2009 at 19:32, Ricky Clarkson
> wrote:
> If it won't work, it won't compile, mostly. It is trivial to
> convert that
> syntax to regular.calls(like).this, if you have any doubts about
> precedence. Though doubts about precedence should be resolved by
> learning
> the language's rules.
>
> The result is you need to learn Specs via its documentation or tests,
> instead of via the source or scaladoc.
>
> Multiple ways of doing the same thing can be ok. Specs' documentation
> doesn't let the more verbose way get in the way of learning to use
> Specs.
> Imaginary problems are imaginary.
>
> It's a bit flaming statement:
> It is imaginary problem while you write small projects alone in your
> favorite language. Problems are real when you are trying to hack a big
> project, written in foreign language written by a group of people you
> don't know. In this case you don't want to read or learn anything.
> You'd like everything to be simple and obvious.
>
> S.
>
>

Actually, the phrase "lingua franca" is from Italian, which I suppose is derived from Latin.  Ironically, the term literally means "Frankish language", or more specifically "French".  So, English is the modern French.  I'm not sure how I feel about that...  :-)

Specs isn't trying to be English, it's just trying to be more natural.  When Martin Fowler talks about DSL design, he often emphasizes the fact that a DSL should not attempt to emulate natural language.  Instead, it should attempt to follow the terminology and syntax of its particular domain.  In this case, the domain is testing, and the terminology is superficially close to English.

As for "be matching" vs "be equalling", the former will compile, the latter will not.  That alone is doing better than Lisp.  :-)

Daniel

On Thu, May 7, 2009 at 12:07 PM, David Chase <dr2chase@mac.com> wrote:

On 2009-05-07, at 12:21 PM, Daniel Spiewak wrote:

Well, here's the question then: what would be the optimal DSL for defining a specification?  This is very much a subjective issue, as illustrated by the fact that I think that Specs is already pretty close to optimal.  :-)

Okay, so I can point out one "flaw" from the POV of an English speaker, at least in the example (this is partly in jest, partly not, and actual constructive criticism):

object helloWorld extends Specification {
 "'hello world' has 11 characters" in {
   "hello world".size must be equalTo(11)
 }
 "'hello world' matches 'h.* w.*'" in {
   "hello world" must be matching("h.* w.*")
 }
}

"be equalTo" vs "be matching" ?

why not

"be equalling" vs "be matching"

or

"be equalTo" vs "be matchTo" ?

From the POV of a non-English speaker, you're actually saying things two different ways already (partly because English gives you at least two different ways to say it, you speak English, and it blew right past you).  One's a verb+preposition, the other's be+participle.

So even if you stuck to your present design, you could make it better by attending to these little details and making the "English" more uniform (i.e., a smaller subset of English and its grammar).  There's probably a best choice for "lots of other non-English speakers" but I don't know what it is.

As to would there be anything much better, I am not at all sure.  It seems to me that for a specification language, there are two things going on -- the language for propositions in the domain you are specifying against ("the song is written in the key of G") and the language for stringing together propositions in logics, whether boolean or temporal.

And consider "the song is written in the key of G" vs "(equals (keyof song) (key 'G'))" vs "a picture of a (treble) clef and a staff with a sharp (#) on the top line".  If you're really talking about facts in the music domain, the picture is your (sub)language right there.

It occurred to me as I was writing this, that

 "Hello World is written in C and Good-Morning to All is written in G"

is a true statement.

( http://en.wikipedia.org/wiki/File:GoodMorningToAll_1893_song.jpg ;
 http://en.wikipedia.org/wiki/Happy_Birthday_to_You ;
I was trying to pick a very familiar song, but they claim copyright, so I went to the one that was in the public domain that the copyrighted song stole its melody from. )

This gets messy fast, unless you places limits on your domain and your DSL.  At which point, some people might ask, "why not set the limit dial to S-expressions?"

(and (equals (language-of "Hello World") (language 'C'))
    (equals (keyof "Good-Morning to All") (key 'G'))
)

(And lest you wonder if I am some Lisp crazy, I'm working on Fortress, we think a lot about DSLs, and one important rule is that if you are not doing better than Lisp, what's the point -- on the other hand, Lisp has notably failed to penetrate into many places where it is objectively and technically complete appropriate, so maybe there really is something wrong with parentheses.)

Just trying to inject a little uncertainty into your life :-).

By the way, have you ever noticed that the phrase "lingua franca" is made up of two Latin words?  :-)

David

Daniel

On Thu, May 7, 2009 at 11:18 AM, David Chase <dr2chase@mac.com> wrote:
I wish to support Stepan in his flaming statement.  We're not all English speakers, and almost-English can be quite confusing.  It's important that it things be readable from the get-go -- to say that you could read it, after you translate it to another form, is not the same as being able to read it as is.

With DSLs, I think you need to make a distinction between using an existing DSL (e.g., mathematics, music, chemistry) and inventing a new DSL.  The point of (adapting) an existing DSL is to avoid the need to learn new rules.

David


On 2009-05-07, at 11:52 AM, Stepan Koltsov wrote:

On Thu, May 7, 2009 at 19:32, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
If it won't work, it won't compile, mostly.  It is trivial to convert that
syntax to regular.calls(like).this, if you have any doubts about
precedence.  Though doubts about precedence should be resolved by learning
the language's rules.

The result is you need to learn Specs via its documentation or tests,
instead of via the source or scaladoc.

Multiple ways of doing the same thing can be ok.  Specs' documentation
doesn't let the more verbose way get in the way of learning to use Specs.
Imaginary problems are imaginary.

It's a bit flaming statement:
It is imaginary problem while you write small projects alone in your
favorite language. Problems are real when you are trying to hack a big
project, written in foreign language written by a group of people you
don't know. In this case you don't want to read or learn anything.
You'd like everything to be simple and obvious.

S.

On 2009-05-07, at 1:14 PM, Daniel Spiewak wrote:

> Actually, the phrase "lingua franca" is from Italian, which I
> suppose is derived from Latin. Ironically, the term literally means
> "Frankish language", or more specifically "French". So, English is
> the modern French. I'm not sure how I feel about that... :-)

Italian IS derived from Latin. And I am wondering how long English
will continue as the lingua franca, and how things will be then --
some people who share my native language are not setting good examples
for the future.

> Specs isn't trying to be English, it's just trying to be more
> natural. When Martin Fowler talks about DSL design, he often
> emphasizes the fact that a DSL should not attempt to emulate natural
> language. Instead, it should attempt to follow the terminology and
> syntax of its particular domain. In this case, the domain is
> testing, and the terminology is superficially close to English.

Right, but that is somewhat a historical accident because so much
computer programming was initially done by English speakers. This is
not a mature domain like music or mathematics, where the point of the
DSL is to make it easy for people outside the CS world to read and
understand our work; it looks a lot more like people on the CS inside,
codifying their jargon, and tweaking and fiddling whenever it gets too
hard for a simple parser to cope. There's a bit of a danger of
creating distilled jargon instead of a true DSL, if there's no outside
reference to act as a check on your creativity.

> As for "be matching" vs "be equalling", the former will compile, the
> latter will not. That alone is doing better than Lisp. :-)

But the point is, as English composition, you've got non-parallel
structure, and two different styles of be-verb-to-ing the object. So
to a picky English speaker, it's not the best English. Similar verbs
should yield similar structure -- it should be -To/-To or -ing/-ing,
not -To/-ing or -ing/-To. An English speaker would get it right
either way, but for a non-English speaker, using a smaller and more
consistent subset lowers the barrier. Don't introduce variation for
the sake of variation -- if it doesn't serve a purpose, it should go.

By-the-way, I slightly prefer the verb+preposition form, assuming that
you are disciplined in your choice of prepositions. It adds a little
bit of redundancy as to which thing is the object, because not all
languages default to subject-verb-object.

David

I must clarify.

Under foreign language I meant "foreign programming language". E. g.
when you need to hack program written in Scala when you program in
Python every day.

Of course, developer must speak English and write programs using English words.

S.

On Thu, May 7, 2009 at 20:26, Ricky Clarkson wrote:
> I'd guess those projects are more likely to use Java 1.3 than Scala.  Unless
> you're going to maintain a whole mirror of Scala, keywords, libs and all, in
> Russian, you're likely better off learning English properly and writing code
> in English.
>
> I'm not being xenophobic on this; I read some (C#) code recently in Spanish,
> and even though I understood all the identifiers, the constant switching of
> languages detracted a lot from readability.  I think I'd have found it
> easier either all in English or all in Spanish.
>
> Though @using two languages helps when there are collisions `with` keywords
> :)
>
> If you think I was flaming, take a look at "useless and wrong" from your
> opening email.
>
> 2009/5/7 Stepan Koltsov
>>
>> On Thu, May 7, 2009 at 19:32, Ricky Clarkson
>> wrote:
>> > If it won't work, it won't compile, mostly.  It is trivial to convert
>> > that
>> > syntax to regular.calls(like).this, if you have any doubts about
>> > precedence.  Though doubts about precedence should be resolved by
>> > learning
>> > the language's rules.
>> >
>> > The result is you need to learn Specs via its documentation or tests,
>> > instead of via the source or scaladoc.
>> >
>> > Multiple ways of doing the same thing can be ok.  Specs' documentation
>> > doesn't let the more verbose way get in the way of learning to use
>> > Specs.
>> > Imaginary problems are imaginary.
>>
>> It's a bit flaming statement:
>> It is imaginary problem while you write small projects alone in your
>> favorite language. Problems are real when you are trying to hack a big
>> project, written in foreign language written by a group of people you
>> don't know. In this case you don't want to read or learn anything.
>> You'd like everything to be simple and obvious.
>>
>> S.
>>
>> > 2009/5/7 Stepan Koltsov
>> >>
>> >> On Thu, May 7, 2009 at 19:03, Ricky Clarkson
>> >> wrote:
>> >> > It does make them easier to read.
>> >>
>> >> It raises questions like: Does it really work? Did I miss some another
>> >> an article near the noun? Does operator precedence work properly in
>> >> complex expression?
>> >>
>> >> You understand what author meant, of course, but when you debugging
>> >> code written by somebody else, this complexity works against you.
>> >>
>> >> >  It is neither useless nor wrong.  Specs
>> >> > can also be used without this style if you so prefer.
>> >>
>> >> Multiple ways of doing same thing increases library size, so makes
>> >> library harder to learn.
>> >>
>> >> S.
>> >>
>> >> > 2009/5/7 Stepan Koltsov
>> >> >>
>> >> >> On Thu, May 7, 2009 at 18:41, Eric Torreborre
>> >> >>
>> >> >> wrote:
>> >> >> >
>> >> >> > I'm very pleased to announce the release of
>> >> >> >  http://code.google.com/p/specs/
>> >> >> > specs 1.5.0 .
>> >> >>
>> >> >> ...
>> >> >>
>> >> >> >  1. the possibility to adopt a more English-like syntax, following
>> >> >> > the
>> >> >> > path
>> >> >> > that ScalaTest has shown with its 0.9.5 release. For example you
>> >> >> > can
>> >> >> > now
>> >> >> > write:
>> >> >> >
>> >> >> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >> >> >
>> >> >> >  instead of
>> >> >> >
>> >> >> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>> >> >>
>> >> >> It is useless and wrong. Programs need not to be like English text.
>> >> >> It
>> >> >> does not make them easier to read, but creates lots of troubles
>> >> >> trying
>> >> >> to solve compilation problems for new specs users.
>> >> >>
>> >> >> S.
>> >> >
>> >> >
>> >
>> >
>
>

It's funny that we misunderstand each other so much in a thread about language.

2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>

I must clarify.

Under foreign language I meant "foreign programming language". E. g.
when you need to hack program written in Scala when you program in
Python every day.

Of course, developer must speak English and write programs using English words.

S.

On Thu, May 7, 2009 at 20:26, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
> I'd guess those projects are more likely to use Java 1.3 than Scala.  Unless
> you're going to maintain a whole mirror of Scala, keywords, libs and all, in
> Russian, you're likely better off learning English properly and writing code
> in English.
>
> I'm not being xenophobic on this; I read some (C#) code recently in Spanish,
> and even though I understood all the identifiers, the constant switching of
> languages detracted a lot from readability.  I think I'd have found it
> easier either all in English or all in Spanish.
>
> Though @using two languages helps when there are collisions `with` keywords
> :)
>
> If you think I was flaming, take a look at "useless and wrong" from your
> opening email.
>
> 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>>
>> On Thu, May 7, 2009 at 19:32, Ricky Clarkson <ricky.clarkson@gmail.com>
>> wrote:
>> > If it won't work, it won't compile, mostly.  It is trivial to convert
>> > that
>> > syntax to regular.calls(like).this, if you have any doubts about
>> > precedence.  Though doubts about precedence should be resolved by
>> > learning
>> > the language's rules.
>> >
>> > The result is you need to learn Specs via its documentation or tests,
>> > instead of via the source or scaladoc.
>> >
>> > Multiple ways of doing the same thing can be ok.  Specs' documentation
>> > doesn't let the more verbose way get in the way of learning to use
>> > Specs.
>> > Imaginary problems are imaginary.
>>
>> It's a bit flaming statement:
>> It is imaginary problem while you write small projects alone in your
>> favorite language. Problems are real when you are trying to hack a big
>> project, written in foreign language written by a group of people you
>> don't know. In this case you don't want to read or learn anything.
>> You'd like everything to be simple and obvious.
>>
>> S.
>>
>> > 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>> >>
>> >> On Thu, May 7, 2009 at 19:03, Ricky Clarkson <ricky.clarkson@gmail.com>
>> >> wrote:
>> >> > It does make them easier to read.
>> >>
>> >> It raises questions like: Does it really work? Did I miss some another
>> >> an article near the noun? Does operator precedence work properly in
>> >> complex expression?
>> >>
>> >> You understand what author meant, of course, but when you debugging
>> >> code written by somebody else, this complexity works against you.
>> >>
>> >> >  It is neither useless nor wrong.  Specs
>> >> > can also be used without this style if you so prefer.
>> >>
>> >> Multiple ways of doing same thing increases library size, so makes
>> >> library harder to learn.
>> >>
>> >> S.
>> >>
>> >> > 2009/5/7 Stepan Koltsov <stepancheg@mx1.ru>
>> >> >>
>> >> >> On Thu, May 7, 2009 at 18:41, Eric Torreborre
>> >> >> <etorreborre@yahoo.com>
>> >> >> wrote:
>> >> >> >
>> >> >> > I'm very pleased to announce the release of
>> >> >> >  http://code.google.com/p/specs/
>> >> >> > specs 1.5.0 .
>> >> >>
>> >> >> ...
>> >> >>
>> >> >> >  1. the possibility to adopt a more English-like syntax, following
>> >> >> > the
>> >> >> > path
>> >> >> > that ScalaTest has shown with its 0.9.5 release. For example you
>> >> >> > can
>> >> >> > now
>> >> >> > write:
>> >> >> >
>> >> >> > "hello" must be matching ("h.*") and not be matching ("z.*")
>> >> >> >
>> >> >> >  instead of
>> >> >> >
>> >> >> > "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>> >> >>
>> >> >> It is useless and wrong. Programs need not to be like English text.
>> >> >> It
>> >> >> does not make them easier to read, but creates lots of troubles
>> >> >> trying
>> >> >> to solve compilation problems for new specs users.
>> >> >>
>> >> >> S.
>> >> >
>> >> >
>> >
>> >
>
>

On Thu, May 7, 2009 at 20:21, Daniel Spiewak wrote:
> Well, here's the question then: what would be the optimal DSL for defining a
> specification?  This is very much a subjective issue, as illustrated by the
> fact that I think that Specs is already pretty close to optimal.  :-)

specs before 1.5 is fine: not too many spaces between words:

something must beLike { case x => true }
something must_== value
something must beEmpty

instead of

something must be like { case x => y }
something must be equal to value
something must be empty

I program in Scala long enough, but I still cannot tell exactly what
is result of compilation of "something must be equal to". And I don't
want to know, until I really need it. I like KISS principle.

S.

> Daniel
>
> On Thu, May 7, 2009 at 11:18 AM, David Chase wrote:
>>
>> I wish to support Stepan in his flaming statement.  We're not all English
>> speakers, and almost-English can be quite confusing.  It's important that it
>> things be readable from the get-go -- to say that you could read it, after
>> you translate it to another form, is not the same as being able to read it
>> as is.
>>
>> With DSLs, I think you need to make a distinction between using an
>> existing DSL (e.g., mathematics, music, chemistry) and inventing a new DSL.
>>  The point of (adapting) an existing DSL is to avoid the need to learn new
>> rules.
>>
>> David
>>
>> On 2009-05-07, at 11:52 AM, Stepan Koltsov wrote:
>>
>>> On Thu, May 7, 2009 at 19:32, Ricky Clarkson
>>> wrote:
>>>>
>>>> If it won't work, it won't compile, mostly.  It is trivial to convert
>>>> that
>>>> syntax to regular.calls(like).this, if you have any doubts about
>>>> precedence.  Though doubts about precedence should be resolved by
>>>> learning
>>>> the language's rules.
>>>>
>>>> The result is you need to learn Specs via its documentation or tests,
>>>> instead of via the source or scaladoc.
>>>>
>>>> Multiple ways of doing the same thing can be ok.  Specs' documentation
>>>> doesn't let the more verbose way get in the way of learning to use
>>>> Specs.
>>>> Imaginary problems are imaginary.
>>>
>>> It's a bit flaming statement:
>>> It is imaginary problem while you write small projects alone in your
>>> favorite language. Problems are real when you are trying to hack a big
>>> project, written in foreign language written by a group of people you
>>> don't know. In this case you don't want to read or learn anything.
>>> You'd like everything to be simple and obvious.
>>>
>>> S.
>>
>
>

I program in Scala long enough, but I still cannot tell exactly what
is result of compilation of "something must be equal to". And I don't
want to know, until I really need it. I like KISS principle.

Deliberate avoidance of learning detected.  Solution: Force learning by providing answer in annoyingly-worded email:
it is really quite simple to work out how it compilesit.is(really).quite(simple).to(work).out(how).it(compiles)
now.please(stop).pretending(the).rules(are).obscure(or).hard(in).some(way)
Solution complete.  Time to mute this thread in gmail.

Eric,

I just have installed eclipse 3.5.0 I20090430-2300 and I am using http://www.scala-lang.org/scala-eclipse-plugin. Compiling my source on the console with scala-2.7.4.final works just fine, but within eclipse I get a couple of errors regarding the specs library, for example:

org.specs.Specification does not have a constructor.

I haven't enabled java weaving by the way.

Do you have any suggestions?

Eric Torreborre wrote:
> Hi all,
>
> I'm very pleased to announce the release of http://code.google.com/p/specs/
> specs 1.5.0 .
>
> Just as a reminder, specs is a Behavior-Driven Development library for
> Scala, providing simple ways to write software specifications:
>
> object helloWorld extends Specification {
> "'hello world' has 11 characters" in {
> "hello world".size must be equalTo(11)
> }
> "'hello world' matches 'h.* w.*'" in {
> "hello world" must be matching("h.* w.*")
> }
> }
>
> It is integrated with many other libraries for execution or specification:
> JUnit, ScalaTest, ScalaCheck, Mockito, JMock.
>
> This new release brings 2 main features:
>
> 1. the possibility to adopt a more English-like syntax, following the path
> that ScalaTest has shown with its 0.9.5 release. For example you can now
> write:
>
> "hello" must be matching ("h.*") and not be matching ("z.*")
>
> instead of
>
> "hello" must (beMatching("h.*") and not(beMatching("z.*")))
>
> 2. a http://fit.c2.com FIT-like library. This offers the possibility to
> specify (using Scala only) specifications which are readable by non-IT
> users. You can find some basic examples
> http://specs.googlecode.com/svn/samples/LiterateSpecifications/ here and a
> blog post describing the main ideas
> http://etorreborre.blogspot.com/2009/04/fit-like-library-for-scala.html
> there .
>
> Note however that this is only considered being at the alpha stage. The api
> can evolve a bit and more real-world experience is needed to validate the
> approach.
>
> Please provide feed-back, ideas, wishes, comments on the
> http://groups.google.com/group/specs-users specs-users google group.
>
> Cheers,
>
> Eric.
>
> PS: it has been compiled and tested with Scala-2.7.4-final.

Cheers,

Hi Normen,

I would say that you need to enable java weaving because I needed to do that
with the latest plugin version.

If you don't succeed, I'll try to have a look at that during next week but
that may not be easy because I'm currently moving from one country to
another.

Eric.

Eric Torreborre wrote:
> I would say that you need to enable java weaving because I needed to do that
> with the latest plugin version.
>

I did so but …

> If you don't succeed, I'll try to have a look at that during next week but
> that may not be easy because I'm currently moving from one country to
> another.
>

… it didn't succeed :(

Cheers,

On Thu, May 7, 2009 at 6:26 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

I'm not being xenophobic on this; I read some (C#) code recently in Spanish, and even though I understood all the identifiers, the constant switching of languages detracted a lot from readability.  I think I'd have found it easier either all in English or all in Spanish.

This is different when you aren't a native english speaker, keywords appear then more like glyphs to you.

Anyway, polyglott code isn't such a bright idea (anymore). Years ago we had the convention that technical (framework) libraries used english identifiers while business logic used German. The obvious advantage was that the business terms where clearly separate from technical terms, but it became a catastrophy as the US branch got established. The code was unreadable for american programmers and it got refactored to "Java.en_US". Comments couldn't get refactored, of course hence I prefer now pidgin english over well-written German as international collaboration has become the norm these days.

-Carsten