No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Very severe limitation in XOTcl
From: SImon Millward <simon_at_tcbventures.com>
Date: Thu, 5 Aug 2010 00:05:44 +0100
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)
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?
> 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?.... if you are not writing unit tests then you are not behaving like a professional... if you are not, then why should a language implementation adhere to you? If you think that not being a professional excuses you from doing a good job then that is equally worrying.... UT is not a pro Vs hobbyist choice... its how one builds good software... QED... if u can't be bothered then what r u doing?
I hate to bang the drum.. but I am tired of silly crap....
> 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....
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!
Regards
Simon
On 4 Aug 2010, at 18:43, Kristoffer Lawson wrote:
>
> On 4 Aug 2010, at 19:50, SImon Millward wrote:
>
>> Isn't it fair to say that by design, any dynamic language has such possible traps and pitfalls... (although this one is especially awkward). You don't need to try very hard to make TCL fall over in all sorts of ways like this.
>
> Absolutely, dynamic languages do have these (and static languages do too, just in a different way). However I think for many things Tcl is probably reasonably OK. PHP is notorious for holes.
>
> But yes, this a particularly bad one because one normally assumes you can send variables as parameters to methods and constructors quite freely. It's common to be initialising with random pieces of string, for various purposes. It's obvious that something like [eval] or [after] is going to be dangerous. Perhaps even [switch] (although I think there'd be a case against that too). But creating a new ob with initial data passed as a variable?
>
>> The question I always ask my teams when something like this comes up is
>> - Why didn't the unit tests catch it
>> - What 'stock' unit test will we add in future to catch it
>
> 1) This particular one is a hobby project, and I don't really fancy spending my free time writing unit tests.
>
> 2) Unit tests, by their nature, don't cover everything. What if the unit tests never passed in a value beginning with "-"?
>
> The flipside to this, as mentioned, is that the resolution is actually quite ugly, and would need to be utilised for safety reasons almost every time a class is instantiated. I think there is definitely a case for raising some concern over this.
>
> --
> Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
>
Date: Thu, 5 Aug 2010 00:05:44 +0100
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)
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?
> 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?.... if you are not writing unit tests then you are not behaving like a professional... if you are not, then why should a language implementation adhere to you? If you think that not being a professional excuses you from doing a good job then that is equally worrying.... UT is not a pro Vs hobbyist choice... its how one builds good software... QED... if u can't be bothered then what r u doing?
I hate to bang the drum.. but I am tired of silly crap....
> 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....
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!
Regards
Simon
On 4 Aug 2010, at 18:43, Kristoffer Lawson wrote:
>
> On 4 Aug 2010, at 19:50, SImon Millward wrote:
>
>> Isn't it fair to say that by design, any dynamic language has such possible traps and pitfalls... (although this one is especially awkward). You don't need to try very hard to make TCL fall over in all sorts of ways like this.
>
> Absolutely, dynamic languages do have these (and static languages do too, just in a different way). However I think for many things Tcl is probably reasonably OK. PHP is notorious for holes.
>
> But yes, this a particularly bad one because one normally assumes you can send variables as parameters to methods and constructors quite freely. It's common to be initialising with random pieces of string, for various purposes. It's obvious that something like [eval] or [after] is going to be dangerous. Perhaps even [switch] (although I think there'd be a case against that too). But creating a new ob with initial data passed as a variable?
>
>> The question I always ask my teams when something like this comes up is
>> - Why didn't the unit tests catch it
>> - What 'stock' unit test will we add in future to catch it
>
> 1) This particular one is a hobby project, and I don't really fancy spending my free time writing unit tests.
>
> 2) Unit tests, by their nature, don't cover everything. What if the unit tests never passed in a value beginning with "-"?
>
> The flipside to this, as mentioned, is that the resolution is actually quite ugly, and would need to be utilised for safety reasons almost every time a class is instantiated. I think there is definitely a case for raising some concern over this.
>
> --
> Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
>