On 1 June 2011 00:42, Casimiro de Almeida Barreto <[email protected]> wrote: > Em 31-05-2011 16:12, Igor Stasenko escreveu: >> On 31 May 2011 21:44, laurent laffont <[email protected]> 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.
