1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <michael.offel@web.de>) id 1QglnV-0002z8-Aj
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Jul 2011 22:51:21 +0000
Received: from fmmailgate01.web.de ([217.72.192.221])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QglnR-0005n6-7G for bitcoin-development@lists.sourceforge.net;
Tue, 12 Jul 2011 22:51:21 +0000
Received: from smtp08.web.de ( [172.20.5.216])
by fmmailgate01.web.de (Postfix) with ESMTP id 64933193C0AF6
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Jul 2011 00:51:11 +0200 (CEST)
Received: from [87.194.33.247] (helo=[192.168.1.64])
by smtp08.web.de with esmtp (WEB.DE 4.110 #2) id 1QglnL-0003kZ-00
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Jul 2011 00:51:11 +0200
Date: Tue, 12 Jul 2011 23:50:48 +0100
From: Michael Offel <michael.offel@web.de>
X-Priority: 3 (Normal)
Message-ID: <296725421.20110712235048@web.de>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <CANEZrP1gEx0_A+BQfJLQ1jppc=-qS1DwruR_wXsP-ctqZGGnjA@mail.gmail.com>
References: <97305540.4426247.1310337435268.JavaMail.fmail@mwmweb052>
<CANEZrP1gEx0_A+BQfJLQ1jppc=-qS1DwruR_wXsP-ctqZGGnjA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: michael.offel@web.de
X-Sender: michael.offel@web.de
X-Provags-ID: V01U2FsdGVkX18CMvzDy731NoHxXY+HdjF2BAjmz9hLTdzDZX0o
2LHe8oXpaZ9kHnPo5rElE5XdQ49ByzDvqYZrXgbv24pdV7zAgK
lfGX4AiszuaNfVn/n+zA==
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(michael.offel[at]web.de)
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [217.72.192.221 listed in list.dnswl.org]
0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
X-Headers-End: 1QglnR-0005n6-7G
Subject: Re: [Bitcoin-development] overall bitcoin client code quality
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2011 22:51:21 -0000
Monday, July 11, 2011, 10:33:04 AM, Mike Hearn wrote:
>> My overall suggestion is to begin a complete rewrite, inspired by the old
>> code rather than moving a lot of "known to be somehow functional" around.
> This essay is old but still relevant, I think:
> http://www.joelonsoftware.com/articles/fog0000000069.html
It is indeed a very good one but I disagree in two points. First
> As a corollary of this axiom, you can ask almost any programmer
> today about the code they are working on. "It's a big hairy mess,"
> they will tell you. "I'd like nothing better than to throw it out and start over."
If someone asks me this question about the project I'm currently
working on I would never answer like that. This is important in the
threads context because it gives me the confidence to say you can
build very large C++ projects with lots of programers attached over
multiple years and still have a very clean and nice code base. And the
article does also accidently points to one of the roots of messy code.
> Back to that two page function. Yes, I know, it's just a simple
> function to display a window, but it has grown little hairs and
> stuff on it and nobody knows why. Well, I'll tell you why: those are
> bug fixes. One of them fixes that bug that Nancy had when she tried
> to install the thing on a computer that didn't have Internet
> Explorer. Another one fixes that bug that occurs in low memory
> conditions. Another one fixes that bug that occurred when the file
> is on a floppy disk and the user yanks out the disk in the middle.
> That LoadLibrary call is ugly but it makes the code work on old
> versions of Windows 95.
Well, if you can not identify the meaning of some hairs, they are
either attached to the wrong place, in an unclear way or are just
missing a line of comment. There are studies about what size of
function and up to what number of variables per function can be
covered by the average code reading programer. And these numbers are
low.
Second, I agree with the point that you can not give up your market
leadership by beginning from scratch and you will if you do so. Unless
you do it like microsoft did in his example by simultaneously extend
the old code base. And microsoft does this all the time, just look at
Windows 9x compared to Windows NT and the dead object oriented Windows
kernel. (They did buy lots of that but that is not the point here)
The mistake is to compare a small project like Bitcoin to any
application like Word or Netscape. The author did explicitly write
that he does not mean that partial rewrite is a bad thing. And
rewriting the Bitcoin client with three or four guys is like a tiny
rewrite in a real world application like Word.
> It's important to remember that when you start from scratch there is
> absolutely no reason to believe that you are going to do a better
> job than you did the first time.
In case of Bitcoin there is reason to believe that a rewrite would be
better. The first version was hacked together by far less programmers
and by at least one who did not care about readability, what tells me
that he possibly did never work on a real project before. And we now
have a known to work protocol, what did for sure slow down the
development a lot and caused rewrites.
Michael
|
