On 6/16/2012 2:20 PM, Miles Fidelman wrote:
BGB wrote:
a problem is partly how exactly one defines "complex":
one definition is in terms of "visible complexity", where basically
adding a feature causes code to become harder to understand, more
tangled, ...
another definition, apparently more popular among programmers, is to
simply obsess on the total amount of code in a project, and just
automatically assume that a 1 Mloc project is much harder to
understand and maintain than a 100 kloc project.
And there are functional and behavioral complexity - i.e., REAL
complexity, in the information theory sense.
I expect that there is some correlation between minimizing visual
complexity and lines of code (e.g., by using domain specific
languages), and being able to deal with more complex problem spaces
and/or develop more sophisticated approaches to problems.
a lot depends on what code is being abstracted, and how much code can be
reduced by how much.
if the DSL makes a lot of code a lot smaller, it will have a good effect;
if it only makes a little code only slightly smaller, it may make the
total project larger.
personally, I assume not worrying too much about total LOC, and more
concern with how much personal effort is required (to
implement/maintain/use it), and how well it will work (performance,
memory use, reliability, ...).
but, I get a lot of general criticism for how I go about doing things...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
