Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.223.181 as permitted sender)
	client-ip=209.85.223.181; envelope-from=jgarzik@bitpay.com;
	helo=mail-ie0-f181.google.com; 
MIME-Version: 1.0
In-Reply-To: <CADJgMztRdNWyogPCjv64qpUHcvGDiOZDVAkv5Ra8hn25Z9xa8w@mail.gmail.com>
References: <20141215124730.GA8321@savin.petertodd.org>
	<CADJgMztRdNWyogPCjv64qpUHcvGDiOZDVAkv5Ra8hn25Z9xa8w@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Mon, 15 Dec 2014 10:20:47 -0500
Message-ID: <CAJHLa0OvDPazCQVonhokm0KopN-WYj0_PP_LO8gPewc1LG5Qow@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: multipart/alternative; boundary=089e011602a8a59a65050a42ca99
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Recent EvalScript() changes mean
 CHECKLOCKTIMEVERIFY can't be merged
Precedence: list

--089e011602a8a59a65050a42ca99
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <btcdrak@gmail.com> wrote:

> We all want to see more modular code, but the first steps should just be
> to relocate blocks of code so everything is more logically organised in
> smaller files (especially for consensus critical code). Refactoring should
> come in a second wave preferably after a stable release.
>

This is my opinion as well.  In the Linux kernel, we often were faced with
a situation where you have a One Big File driver with > 1MB of source
code.  The first step was -always- raw code movement, a brain-dead breaking
up of code into logical source code files.

Refactoring of data structures comes after that.

While not always money-critical, these drivers Had To Keep Working.  We had
several situations where we had active users, but zero hardware access for
debugging, and zero access to the vendor knowledge (hardware documentation,
engineers).  Failure was not an option.  ;p

Performing the dumb Break Up Files step first means that future, more
invasive data structures are easier to review, logically segregated, and
not obscured by further code movement changes down the line.  In code such
as Bitcoin Core, it is important to think about the _patch stream_ and how
to optimize for reviewer bandwidth.

The current stream of refactoring is really a turn-off in terms of
reviewing, sapping reviewer bandwidth by IMO being reviewer-unfriendly.  It
is a seemingly never-ending series of tiny
refactor-and-then-stuff-in-a-class-and-make-it-pretty-and-do-all-the-work.
Some change is in order, gentlemen.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

--089e011602a8a59a65050a42ca99
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <span dir=3D"ltr=
">&lt;<a href=3D"mailto:btcdrak@gmail.com" target=3D"_blank">btcdrak@gmail.=
com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>We all want to=
 see more modular code, but the first steps should just be to relocate bloc=
ks of code so everything is more logically organised in smaller files (espe=
cially for consensus critical code). Refactoring should come in a second wa=
ve preferably after a stable release.</div></div></blockquote></div><div cl=
ass=3D"gmail_extra"><br></div>This is my opinion as well.=C2=A0 In the Linu=
x kernel, we often were faced with a situation where you have a One Big Fil=
e driver with &gt; 1MB of source code.=C2=A0 The first step was -always- ra=
w code movement, a brain-dead breaking up of code into logical source code =
files.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>Refactoring of data structures comes after that.</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">While not always money-critical=
, these drivers Had To Keep Working.=C2=A0 We had several situations where =
we had active users, but zero hardware access for debugging, and zero acces=
s to the vendor knowledge (hardware documentation, engineers).=C2=A0 Failur=
e was not an option. =C2=A0;p</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">Performing the dumb Break Up Files step first means=
 that future, more invasive data structures are easier to review, logically=
 segregated, and not obscured by further code movement changes down the lin=
e.=C2=A0 In code such as Bitcoin Core, it is important to think about the _=
patch stream_ and how to optimize for reviewer bandwidth.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The current stream of=
 refactoring is really a turn-off in terms of reviewing, sapping reviewer b=
andwidth by IMO being reviewer-unfriendly.=C2=A0 It is a seemingly never-en=
ding series of tiny refactor-and-then-stuff-in-a-class-and-make-it-pretty-a=
nd-do-all-the-work.=C2=A0 Some change is in order, gentlemen.</div><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">-- <br><div class=
=3D"gmail_signature">Jeff Garzik<br>Bitcoin core developer and open source =
evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.co=
m/" target=3D"_blank">https://bitpay.com/</a></div>
</div></div>

--089e011602a8a59a65050a42ca99--