Comments on Carlo Pescio - blog: Cut the red wire!

you can start with a recent overview paper, like t...

2011-07-05T12:14:45.470+02:00

you can start with a recent overview paper, like this:

http://cacm.acm.org/magazines/2011/7/109910-dsl-for-the-uninitiated/fulltext

and then pick some of the bibliography. Most authors use a dynamic language, but it's not really needed.

I will wait for you to write down the strategies, ...

2011-07-05T11:49:05.049+02:00

I will wait for you to write down the strategies, then :-)

About your approach to the problem: could you give me some good reading about DLS, please?

Thanks a lot!

Daniele: I'll start with the easy part (C++). ...

2011-07-05T10:49:17.929+02:00

Daniele: I'll start with the easy part (C++).

In a language without extension methods, you can either use subclassing (so you can keep using the dot notation) or change your syntax. The most notable difference between C++ and Java/C# is that in C++ you don't need to put your functions inside a class, so you can leverage that as part of your little DSL. Generally speaking, embedding a DSL inside a programming language requires some creativity and a good knowledge of your material. In C++ we have (for instance) template specialization, which is absent in other languages. We can build stack-based, anonymous objects without using "new". Etc.

Just to play around with syntax, it would be trivial to mix template specialization, integral template parameters, and a couple of enumerated types with a single value inside and come up with a syntax like:

Trim(roll).By<Count>(2).Top<Face>(1).Score();

Where Trim returns a new, stack-based, anonymous object [of a new class, not Roll], and you can figure out the rest :-). The use of template specialization is just for fun, of course, but then I can say By<Count> or By<Face>, which I tend to like.

Your question about strategies made me realize that I never took the time to write them down. It's complicated - for instance, my little DLS could be seen as an instance of an architectural pattern (pipes and filters) but that's a bit of a stretch. I guess that over the years I've accumulated a body of knowledge that I would have to unravel to give you a proper answer. Right now, I can't :-(. A good understanding of architectural patterns and problem frames, however, is a first good step in the right direction.

Fulvio: long before TDD, I used to do a "call...

2011-07-05T10:25:30.342+02:00

Fulvio:
long before TDD, I used to do a "caller-driven design", which is a similar technique, to design the API of libraries / frameworks / components. Designing an API from the outside makes it easier to use, avoiding the temptation to expose the internal model (which is very common when you design an API "from the inside"). TDD is perfect here. Of course, the economic value of keeping all test cases alive forever is less clear-cut, just like the economic value of keeping models alive. I've written about this before in the context of self-fulfilling expectations.

Assertions vs exceptions. I tend to use assertions to guard against programming errors. I tend to use exceptions to guard about unexpected environmental conditions (e.g. your network connection went down). In our specific case, an unchecked assertion (which means we did a poor job of testing our code) would still come up as an exception (out of bound access). There is little point in remapping that to another exception. It's an unrecoverable [programming] error anyway.

I don't have the time and energy, at this time, to organize a design retreat or something. We'll see :-)

Hi Carlo, good post. I actually tried to solve th...

2011-07-04T11:53:41.879+02:00

Hi Carlo,

good post. I actually tried to solve the problem before going on with the reading, but obviously I couldn't find a beautiful solution like yours: the DSL approach is really interesting.

In the post you said: "Not every single problem lends itself well to the DSL approach. As usual, we have to be flexible, understand the nature of the problem, and choose the best design strategy". Quite correct. Which "design strategy" do you know and use?

And finally: what if you had to solve the problem using a language like C++ that doesn't provide Extension Methods?

Thanks
Daniele

you do remember me of Harry Potter, you do magic :...

2011-07-03T20:53:01.847+02:00

you do remember me of Harry Potter, you do magic :D

This is really the kind of post I like to read, where someone explains how and why to challenge a problem, and don't leave you with a plethora of principles context-less.

I know your view about TDD, but there's a context where you may suggest to use TDD?

I noticed that you continue to use assertions where everyone use exceptions. Many think that an assertion goes away in release build, so there's no chance to trap it. Sun (Oracle?) suggests to use assertions in private methods to check precondition and exceptions for public methods of a class. I like assertions cause i think it's the best tool for the scope but someone could say that are useless without complete test coverage or strange runtime behaviour may raise. Why do you use assertion? :)

I remember some times ago you express the will to plan an event to practice design. After this post, I vote to design it :)

Hey there Matteo :-) I wouldn't use a regular...

2011-06-30T00:24:48.333+02:00

Hey there Matteo :-)

I wouldn't use a regular for, I've been bitten by off-by-one errors more than once. I've frequently forgotten to increment an iterator inside a while loop in C++ as well. A foreach would be ok, I guess, as I'm always iterating over the entire collection.
Lacking linq, however, I would probably write my own methods at some point. Having a language with lambda functions and not using them is a capital offense :-)

You wouldn't drown DiceGroup in tests, but I know a few who would. That's the problem with mantras :-).

The next paragraph in Feathers' book reads like this: "You might think that this is severe. What about clean code? If a code base is very clean and well structured, isn't that enough? Well, make no mistake. I love clean code. I love it more than most people I know, but while clean code is good, it's not enough", so I would say that my code is not good enough for him. Too bad :-).

Dice: ouch, ouch, ouch, age is taking its toll? :-) I [quickly] fixed the post. Not the code, but it's kinda late :-). Thanks!

Hi Carlo, fascinating read. I like the idea of ...

2011-06-29T23:36:24.761+02:00

Hi Carlo,

fascinating read. I like the idea of looking for a little language to express the problem. I like the idea of thinking how to write code that works the first time. I like the little list of alternatives that you tried and rejected to design your little language. I like how the "false start" shows by contrast what a good DSL should look like.

I found difficult to follow the Linq bits. It turns out you are way more anti-FOR than I am! I don't know Linq. Also I'm tired right now :-) I wonder if you'd find it that more difficult to write the little loops yourself? (Always in the context of "it should work the first time or else the nukes are off" :-)

Regarding the idea of "drowning" the little DiceGroup class with tests, I feel I should comment, given that I'm a TDD advocate :-) Well I wouldn't write tests for that, because the tests I write in TDD are a design technique, not a test technique.

If I wrote DiceGroup without tests because I used a different design process, like you are doing here, then I would not necessarily need to write tests after. I would only write tests after if the code was not completely trivial.

About the quote from Feathers: it should be taken in context. Feathers is talking of code that makes you afraid to change! If your code is not obviously correct *and* you don't have tests, then you have code that is difficult to change, and that is precisely the problem that Feathers deals with in his book. OTOH, your Yahtzee DSL gives you feedback from the fact that it's so close to the problem. That makes it easy to change because it's very easy to *understand*.

I would guess that Feathers had a lot of discussions with people who were honestly convinced of having good code (OOD and all) but had in fact code that is both nonobvious and without tests, therefore code that is a problem for whomever needs to change it.

This essay reminded me of this story of a programmer who wrote a major bit of a filesystem on paper that worked the first time :-) Pity the story does not say much about what his thinking process was!

(Nitpicking: die=dado, dice=dadi, dices=not a word)