[Pharo-project] About FS: sad reality.
stephane.ducasse at inria.fr
Fri Feb 4 19:45:34 CET 2011
sven, I know. Still I think that I read a lot of code in a lot of languages and even more in Smalltalk
and if I cannot find my way with anObject because it was too complex to write aStringOrReference then I should stop and
this is what I'm doing. I stopped. I started to read fileMan and rio again not to integrate them but to have a look.
In addition I'm not in the mood to get a sensitive abstraction dictated by 'oh we should not change it because it should run in squeak'.
I feel the pain of Monticello without comments and I do not want that for files. I will not crawl to comment it even if people like the design
because I have something else to do about my time.
I also think that there are funny ideas. Why I cannot create an empty file or why a workingDirection isWorkingDirection is false and why
workingDirection does not return a reference instead of a path......and a lot more.
second test in black box (because most of the tests cannot be used to understand the public api and this is why I was trapped all the time)
but it will not be me.
>> Hi guys
>> I'm sorry but I stopped working on FS. I cannot guess what is private or not, what is the interface of this code.
>> I spent my time guessing and guessing wrong. So I stop. Simple.
>> In addition I will veto the integration of this code in this state to be added into pharo (sad I started to write an help but
>> it is probably full of mistakes). I HATE undocumented code that tell me eveyr minutes that I'm a fucking idiot.
>> Too bad I'm not smart enough. Now without decent comments (I mean more than a line in class comment when there is one) we cannot accept code.
>> Sad but true. Good luck if you want to use it and improve it.
> Your quest for more comments is a good and a valid one, no question about it.
> And I don't want to defend FS, I only know it from Lukas' blog post and it seemed better than what we have now.
> But the quality of a good design is certainly not just comments.
> It is perfectly possible to have code with lots of comments that is still bad.
> And if you take away all comments from a good design, it can still be a good design.
> Good abstractions, good names, separations of concerns, .. all those things that we all value are important.
> Using proper language idioms and conventions is another good idea.
> Many good programmers are a bit reluctant to write comments, and they usually value elegant code that speaks for itself.
> I have certainly seen lots of really good code in the image that has little to no comments.
> And I have seen lots of comments that make me sick.
> It also seems pretty hard for someone who is not the original author to write comments.
> And a prerequisite to writing comments is that you understand and like the system that you are commenting.
> If you are struggling with something, that does not seem like a good state of mind to improve the comments.
> PS: the public/private distinction is a bit hard in Smalltalk, but the conventions seem to be method categories with 'private' in them, no ?
More information about the Pharo-project