On 1 June 2011 00:42, Casimiro de Almeida Barreto <casimiro.barreto@gmail.com> wrote:
Em 31-05-2011 16:12, Igor Stasenko escreveu:
On 31 May 2011 21:44, laurent laffont <laurent.laffont@gmail.com> wrote:
Another idea (don't know how hard it is) is to have test coverage + comment coverage in Hudson. Then we can start to consider that dead code = code with no test or no comment. Laurent, have you tried to run lint rule checker in pharo image? I tried once and if i remember correctly, there are like 30000 notices. Now, what you think, is it possible for any human to visit all of them step by step analyze and then fix the code? It is enormous amount of data (and most of it is just white noise, or insignificant detail). Now how to filter that noise and address the only things which you should take care of? Here comes the importance of having a foundation or any other kind of entity enabled to run for financial resources necessary to keep people, doing these "insane tasks" :) as well as physical resources (computers with versions of OS, etc)... And since we're continuting development, every time you doing an update, this stuff should be revisited, compared and cross-checked again. And we don't have such facility: take image A and B, and compare their lint output. Here comes the importance of agreeing about a closed (in terms of scope) and reduced (in terms of size (ie, # of classes and messages)) core that can be frozen while cleaning is done. Otherwise it's like manufacturing an airplane while it's flying from factory to owner... which increases the "insanity factor" several orders of magnitude.
Nice allegory. I like it. I personally insane enough, that i would like to be able to manufacture airplane while it flying from factory to owner. Because life is short, and you not always sure that fix you just made is final one.. maybe there are some more, which you may need to add in a last minute :) Code is just another form of data, and smalltalk is an exceptionally brilliant proof of it. And as any data we should learn how to transform it without breaking it into meaningless pieces. I'd like to know, how we can teach system (and ourselves) to understand that whole is more than just a sum of elementary parts. A system can be extremely modular. Modules can be as little as one module per class (or even per object). But the thing is, no matter how small the bricks and how well (an fully) you studied every piece which you put into system. Because when these pieces start interacting with each other - they creating a multidimentional space, where it is no longer possible to prove anything: - are your system secure? - is it stable? - is it bug free? - is it performant? etc etc
I imagine this would require a quite sophisticated database , with UI on top of that, which will allow you to navigate through these notices mark them as invalid, or fixed etc etc.. What i mean that automated tools is cool. But they cannot solve all our problems: every such issue should be analyzed and considered by developer. Because we're still not yet at the point, where system can reason about itself and automatically improve itself without need of our attention :) If this day will come, then it will be the end of humanity (at least in its current form - homo sapiens sapiens ;)
Laurent.
Additionally, one issue with metacello is that it incorporates both infra-structure stuff and things that are more like end-user applications. It's not a tradition to keep things orthogonal: there is code that inserts/deletes/modifies things in places that should constitute foundations. For instance, some time ago there was discussion about ad-hoc (thus mostly undocumented) methods/messages in places like OrderedCollection... What's the sense in this state of affairs? IMHO it's an ad-hoc situation and cleaning process must fix & transform it into a sustainable situation. That's overcoming past.
CdAB
-- Best regards, Igor Stasenko AKA sig.