Comments for My Not So Private Tech Life

Comment on Teaching in Impatient Times by Jan Ernsting

Jan Ernsting — Mon, 15 Feb 2010 20:22:57 +0000

At university we are affected by these factors, too. All workshops I attended so far have suffered due to people being distracted from the task at hand. May be a good idea to enforce this again (I remember a CS1 lecturer insisting on having all notebooks stowed away and communication devices muted).

Comment on Refactoring FitNesse Tests by johanneslink

johanneslink — Wed, 11 Nov 2009 18:53:02 +0000

I’ve done some testing with the documentation that comes with FitNesse. It didn’t crash and it finished its tasks. And that was a couple of groovy versions earlier – groovy is supposed to be an order of magnitude faster now.
Give it a try and let me know both ways. I might be willing to invest in ReFit if you cannot use it due to performance reasons.

Comment on Refactoring FitNesse Tests by Ray

Ray — Wed, 11 Nov 2009 17:16:08 +0000

Quite happy to find this.

My team have been using fitnesse for a couple of years now and our suite is enormous. I am very much more concerned with performance. Fitnesse takes so long to search through our suite for references(during a rename or move) that it eventually crashes.

Is ReFit capable of better?

Comment on Refactoring FitNesse Tests by martin

martin — Fri, 02 Oct 2009 07:30:53 +0000

Hi,

sounds interessting. We, at the FH Nordwestschweiz are currently working on extending the FitPro Plugin for Fit test refactoring, in the sense, that when the application code is changed, the appropriate fit tables will be adapted, to. We will present it on the OOPSLA this year: “Reverse Generation and Refactoring of Fit Acceptance Tests for Legacy Code”

Comment on Building Grammars (and Parsers) on the Fly by Bernd Schiffer

Bernd Schiffer — Thu, 13 Aug 2009 22:41:29 +0000

I often hear the point you mentioned, that internal DSLs would restricts the syntax and that non-techs won’t be able to handle them.

I agree with that. So I came up with a mix of both. My example is not a DSL. “10 km” is not a internal Groovy DSL. But “10.km” (see the dot) is. All I have to do to convert the external “10 km”-DSL into an internal “10.km” one is to delete the dot. I’ve done that by a simple regular expression.

So, my point is: Isn’t it totally enough to build an internal DSL and to do some cosmetic surgery with simple tools like regular expressions? Do you really need extra tools for that?

I’m eager to see your example. I’ve set an reminder on that to December 31th, 2009

Comment on Building Grammars (and Parsers) on the Fly by johanneslink

johanneslink — Thu, 13 Aug 2009 19:02:36 +0000

My example has been badly chosen as for the WHY of using an on-the-fly parser. Sometimes internal DSL restrict the syntax too much to be usable for non-tech analysts, testers or customers. Imagine you want to use (parts of) prose texts to be used as executable scenarios. Maybe I’ll blog such an example later… this year .

Comment on Building Grammars (and Parsers) on the Fly by Bernd Schiffer

Bernd Schiffer — Thu, 13 Aug 2009 18:56:29 +0000

This parser might be powerful. However, it’s hart for me to see why, for this purpose, an external DSL would be better than an internal one.

The Cucumber example of yours is an internal DSL. You want “[s]light variations, like using “put in” instead of “entered into…”. But I can’t see how you’ve done that with Pars4SJM. However, you solved another example with Parse4SJM: adding numbers.

Well, even the Groovy Parse4SJM solution here is still much too heavy weight. That’s because you chose an external DSL. An internal DSL would do much better here, e.g. a Groovy one. I think a internal Groovy DSL could deal with the adding numbers thing in one line of code, maybe two, but that’d be all.

(Might want to have a look at this.
Blog: http://berndschiffer.blogspot.com/2007/02/kilometerfresser.html
Code: http://www.bytemycode.com/snippets/snippet/593/
Skip the GUI and the formatting parts and you’ll end up with a one or two liner.)

There could be limits in the use of an internal DSL here, but I don’t see why you could not fix your main problem with an internal DSL, too. The benefit would be a light weight kind of tool: your programming language of choice.

So, what power are you looking for in external DSLs that you could not find in an internal DSL?

Comment on A Unified Theory of Software Design, Architecture and Everything by softestpawn

softestpawn — Tue, 14 Apr 2009 19:59:49 +0000

Good post. I think johannes is talking about the trade off in runtime flexibility vs compile time explicit trust. As you say I think the runtime flexibility is often overrated.

Comment on A Unified Theory of Software Design, Architecture and Everything by johanneslink

johanneslink — Sat, 07 Mar 2009 09:08:26 +0000

@marko Maybe you can give an example for:

Many “dependcy hiding techniques” I have seen, also lower the probability that the Party A has to adapt [...] So I actually often prefer a few strong explicit dependencies over a lot of weaker implicit dependencies.

I have difficulties to discuss that in an abstract way only.

Comment on A Unified Theory of Software Design, Architecture and Everything by marko

marko — Fri, 06 Mar 2009 13:10:47 +0000

You are saying that “explicit dependency is obviously preferable over implicit” and so techniques that hide dependencies may be problematic. I agree with you on this one.

But it has a problem: Many “dependcy hiding techniques” I have seen, also lower the probability that the Party A has to adapt – albeit only to a minor degree. So numerical the hiding may seem like a good idea. Especially because these hidings show up in metrics so unproportionally favourable they are so popular.

So I actually often prefer a few strong explicit dependencies over a lot of weaker implicit dependencies. But while you mention explicit vs. implicit it is not considered in your definition of Good Design.

But besides that: A very good article. Thought provoking.