[Xotcl] Very severe limitation in XOTcl

Kristoffer Lawson setok at scred.com
Thu Aug 5 09:20:38 CEST 2010

On 5 Aug 2010, at 02:05, SImon Millward wrote:

> I agree there was a case for raising this. I'm sorry if I gave any other impression. ( I don't know why u raised this with me only and not the list? But I have)

My mistake :-) Not hitting the "Reply to All"...

> But, I don't think the case is a valid one, because you are finding difficulty with a dynamic language. Dynamic languages offer power. With power comes responsibility. Responsibility in my book equals things like comprehensive UT. If you don't test you fail.... please demonstrate another industry that doesn't consider testing an essential element of what they do?

I think we're entering a totally unrelated debate here. For what it's worth, I've been using dynamic languages for over 15 years (Tcl in particular), so it's not like they're something totally new to me. This particular problem does not, for instance, exist in Python, whereas PHP is riddled with many (and, in practical situations, has often caused problems for people). I'd say the basic rule should be that common usage with argument passing should be safe. It should not be necessary to do every single instantiation like this:

set ob [MyClass new [list -init arg1 arg2 arg3]]

This makes common use awkward and something that will easily trip up users. Consider that in an OO environment, object instantiation is one of the things you will be doing a lot of. Keep in mind you have to do the above every time, just to avoid mistakingly sending something which will cause a crash or a hole. It seems Gustav agrees, as he pointed out this will not be the case in 2.0. 

>> 1) This particular one is a hobby project, and I don't really fancy spending my free time writing unit tests.
> I'm sorry to be contrary... but... if you are a hobbyist... should you really be commenting on the semantic or operational aspects of a language?

Uhm.. Yes? I didn't realise this community was closed off to hobbyists. I imagine many people using Tcl or XOTcl fit that bill. Naturally it's the right of the authors to implement their language however they feel — it's lot like I'll bring them to court (plus I've enjoyed beers with one of them :-) — but it is also my right not to be happy about a particular implementation.

>> 2) Unit tests, by their nature, don't cover everything. What if the unit tests never passed in a value beginning with "-"?
> Then they are crap unit tests (and probably crap code).. if failed to expect 'dirty' inputs....

Well, I raise my cap if your unit tests are always 100% great, with 100% coverage of all possible values and you have code without bugs. We should probably hire you.

> I fail to see how someone who admits to not being professional can then create a justification for a language change..... I'm more surprised anyone's taking it seriously!

I'm talking about common sense here. A feature of the language makes it awkward to write safe code, and leads to error prone results. For something so basic as object instantiation, requiring awkward syntax is just not going to go down well with many coders. It reduces readability and, in fact, none of the XOTcl examples you see use the safe instantiation model.

There are a few gotchas like this in Tcl. [switch] is dangerous, but the "--" pattern is well established (although I'm not a big fan of that). [puts] is something I imagine most code has got wrong, but the consequences are generally not particularly dangerous. At the end of the day programming languages are for humans, and need to consider that as a factor.

I don't know why I'm ruffling your feathers so much. It's true my initial posting on this was filled with late night "Argh", but I stand by the point. Also, I've been using on and off XOTcl since the 0.8x days and have always been a fan of the language. I've done my part to evangelise it. That it has taken this long to stumble across this issue is exactly why it is particularly dangerous.

Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

More information about the Xotcl mailing list