4 ms·

On the class thing, I bowed to pressure to have some sort of classes. And I can see how we'll use them in our guis, each gui will be a class and we can safely

On the class thing, I bowed to pressure to have some sort of classes. And I can see how we'll use them in our guis, each gui will be a class and we can safely combine them in an uber gui w/o name space conflicts. Could have just as easily been modules (all this crud is built on top of tcl namespaces, it's just syntactic sugar to make things look nice). We are not doing inheritance of any sort. L is not trying to be cool, it's trying to be useful and easy to review. On that note, the n := 1; is shorter than int n = 1; but which one reviews faster? My opinion, which matters a lot in this tiny instance, is the second one reads faster, especially when you consider we flip from C to L to tcl to shell. We're optimizing for the reader, not for the writer. Much bigger win in our code-review heavy environment.

acqq 16y ago
> L is not trying to be cool, it's trying to be useful and easy to review. I appreciate that, but your compiler checks the types anyway, so later n .= "abc" will be an error if I understand it, that's why you have them, so if the code you review compiles without error you certainly won't catch any new error when using eyes?
- luckydude 16y ago
  The types help enormously, but so does being slightly verbose. Lots of "reviews" happen in diffs. Much like Linus reads patches and modifies the patches because he knows the source base, we read commit messages (which are a patch) and the first review frequently happens in email. Which doesn't address your point, I realize. Let's try this. Given the choice between make life better for the writer (n := 1 is shorter) and the reader (int n = 1 is more explicit), we pick the reader every time. We have multiple readers and we work in multiple languages. So while you are absolutely right, n := 1 is just fine, and it is type checked and it is "obvious", it will hiccup anyone coming from C (and is about to switch back to C after this review). We review everything. And the review is just part of it, when a support call comes in we're in the source, looking at the code, trying to make the customer happy with an instant fix (which we do a lot). Every second that we have to spend swapping in tcl syntax is time where the customer is going "why am I paying for this when I could use git for free?". And a few second later they find out when get them a fix. Time matters. Ease of reading yields shorter time on support and shorter time on reviews. That's my take, and that's how it works here. That may not be true for you.

acqq 16y ago

> L is not trying to be cool, it's trying to be useful and easy to review. I appreciate that, but your compiler checks the types anyway, so later n .= "abc" will be an error if I understand it, that's why you have them, so if the code you review compiles without error you certainly won't catch any new error when using eyes?

luckydude 16y ago
The types help enormously, but so does being slightly verbose. Lots of "reviews" happen in diffs. Much like Linus reads patches and modifies the patches because he knows the source base, we read commit messages (which are a patch) and the first review frequently happens in email. Which doesn't address your point, I realize. Let's try this. Given the choice between make life better for the writer (n := 1 is shorter) and the reader (int n = 1 is more explicit), we pick the reader every time. We have multiple readers and we work in multiple languages. So while you are absolutely right, n := 1 is just fine, and it is type checked and it is "obvious", it will hiccup anyone coming from C (and is about to switch back to C after this review). We review everything. And the review is just part of it, when a support call comes in we're in the source, looking at the code, trying to make the customer happy with an instant fix (which we do a lot). Every second that we have to spend swapping in tcl syntax is time where the customer is going "why am I paying for this when I could use git for free?". And a few second later they find out when get them a fix. Time matters. Ease of reading yields shorter time on support and shorter time on reviews. That's my take, and that's how it works here. That may not be true for you.