Re: [fonc] goals
On Thu, 8 Jul 2010 18:01:36 -0700 (PDT) Alan Kay alan.n...@yahoo.com wrote: ...seeing if very compact runable maths could be invented and built to model... Isn't this a good definition of Lisp? Denis vit esse estrany ☣ spir.wikidot.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On 2010-07-08, at 9:21 PM, Steve Dekorte wrote: Thanks for the response. That kind of sounds like the goal is fewer lines of code (and presumably less labor) per unit of function (increasing productivity). Is that correct? Well, I don't speak for Alan, but I have to think it's a bit more than that. The biggest problem we have in computing is that we're terrible at it. Just the other day I remarked to a colleague that the system we were working on had about 10x too much code for what it did, and he agreed. So yes, less code for the same functionality might (might!) be higher productivity, but it's also a rough measure of quality. Writers seek economy of words, athletes seek economy of motion, we seek economy of code. Colin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On 2010-07-09, at 12:56 AM, Colin Putney wrote: On 2010-07-08, at 9:21 PM, Steve Dekorte wrote: Thanks for the response. That kind of sounds like the goal is fewer lines of code (and presumably less labor) per unit of function (increasing productivity). Is that correct? Well, I don't speak for Alan, but I have to think it's a bit more than that. The biggest problem we have in computing is that we're terrible at it. Just the other day I remarked to a colleague that the system we were working on had about 10x too much code for what it did, and he agreed. So yes, less code for the same functionality might (might!) be higher productivity, but it's also a rough measure of quality. Writers seek economy of words, athletes seek economy of motion, we seek economy of code. I agree that labor including maintenance (which may include understandability, extendability, etc) is a better end measure but that code length (or maybe keystrokes, etc) can be a reasonable starting point for measuring it. Btw, this discussion may sound trivial, but consider the question: Is computing technique X is better than Y? We need to know by what measure it's better for the question to be meaningful. And without a measure that matches one's goals, decisions made on their basis may be counterproductive. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
yeah. I guess a lot depends on other factors though. for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? these may matter more in many cases than the total code size. like, if the app is only 10 or 15 kloc, but most of it is composed of if(...) goto ... and ugly use of bit-twiddling and pointer operations (say, you see things like ((int *)(((void **)p)[i+5]))[16]+*(int *)(*(void **)q) pretty much every-other line), and the programmer couldn't be bothered to use more than 3 or 4 characters for most of their function names, this is not necessarily a good thing. a similar app which is maybe 20-25 kloc, but consists of code which may be understood (and doesn't blow up in ones' face as soon as it is fed bad data), may be a little better. but, then again, sometimes an app may benefit from being smaller, for simple sake that ordinary humans can work on it (without having to go up a steep learning curve and having to become experts on the thing before being able to do much of anything). for example, a 350 kloc app may be better, even if it does a little less, than a 5 or 10 Mloc app, if it means that the programmers can more easily understand the thing in its entirety. feature bloat is also a problem. features may be good, but too many features may not be a benefit to ones' purpose, and sometimes a piece of code which is smaller and only does a few things well, may be better than a larger piece of code trying to do everything adequately... (sometimes, we don't need some unified one true implementation). but, a lot comes down to abstraction as well: a much larger codebase with much better abstractions may still be much easier to work on than a smaller codebase with few or poorly-chosen abstractions (for example, if the codebase is relatively well organized, and its code relatively self-explaining, then one can more easily get things done without having to keep as much in-mind, but if changing something one place means they have to fix something somewhere else which breaks as a result, this is a problem...). but, there are many factors involved. or such... - Original Message - From: Colin Putney cput...@wiresong.ca To: Fundamentals of New Computing fonc@vpri.org Sent: Friday, July 09, 2010 12:56 AM Subject: Re: [fonc] goals On 2010-07-08, at 9:21 PM, Steve Dekorte wrote: Thanks for the response. That kind of sounds like the goal is fewer lines of code (and presumably less labor) per unit of function (increasing productivity). Is that correct? Well, I don't speak for Alan, but I have to think it's a bit more than that. The biggest problem we have in computing is that we're terrible at it. Just the other day I remarked to a colleague that the system we were working on had about 10x too much code for what it did, and he agreed. So yes, less code for the same functionality might (might!) be higher productivity, but it's also a rough measure of quality. Writers seek economy of words, athletes seek economy of motion, we seek economy of code. Colin ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern vector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
RE: [fonc] goals
From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of David Leibs Sent: Friday, July 09, 2010 1:33 PM To: Fundamentals of New Computing Subject: Re: [fonc] goals It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. The programmer must also be given permission to take that time. I can remember only once in 23 years of software development when my employer actually told everyone to stop and clean up the code for 2 weeks. No new features, just make the code better. I was astonished, and very pleased. This sort of thing should be done as a matter of course. Alan and Co. seem to me to be trying to make up for decades of our industry refusing to clean up the code. What is 20 million lines of code can be 20 thousand. If you can apply the 80/20 rule to this in the sense that you can provide people with a lever that does 80 percent of what you need, and if the system is tractable for motivated casual coders so that they can provide the other 20 percent then you have something really valuable. Early home computers provided some of this quality in spite of their shortcomings. The machines and languages were simple enough so that anyone with enough attention span to read a 250 page book could bend the computer to his will. That's a vision of personal computing. I think this idea is lost in our popular culture. -Carl Gundel Psyche Systems ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Just to be clear, The foremost experts and definitive source on software metrics -- Fenton and Pfleeger [1] -- do not really support SLOC/day/programmer as a good metric for productivity. It seems to me (from hearing reports by others) that most people do not actually read books on metrics and instead gravitate towards the simplest ones, regardless of effectiveness. Usually SLOC/day/programmer is a good way, though, to convince your boss that a project predicted to be 300,000 lines of brute force coding cannot be done in a weekend. The argument being you literally cannot type that fast. Cheers, Z-Bo [1] http://www.amazon.com/Software-Metrics-Norman-E-Fenton/dp/0534956009 On Fri, Jul 9, 2010 at 2:47 PM, Max OrHai max.or...@gmail.com wrote: Just to clarify, I'm a bit uncomfortable with productivity talk here because it seems too narrow and ill-defined. Productivity of what exactly? By whom? For whom? To what end? To a specific manager of a specific project in a specific development phase, these questions may have specific, meaningful answers. When it comes to fundamentally rethinking basic tools and practices, I'm not so sure. Of course, core values must be somewhat vague, to allow them to mesh with constantly changing circumstances. Personally, I'd rather strive for quality than productivity. I'm generally suspicious of premature quantification: just because you can measure something doesn't make it meaningful! It seems to me that, as crufty, haphazard, hidebound, etc. as software engineering is today, software engineering management (with its productivity metrics such as source lines of code per programmer per day) are even worse. We all know code quality varies wildly between programmers using the exact same sets of tools. Talent and training contribute enormously. However, I imagine that everyone on this list can agree that the tools themselves matter too, even if it's difficult to quantify that difference precisely. Keep it simple is a widely applicable and successful heuristic. I see this project as (largely) an experiment in applying that heuristic to the fairly well-defined category of creating the personal computing experience, with a depth and breadth impossible in the productivity/profit-bound world of commercial software, and a consistency and quality level impossible in the the traditional open-source project. It's just an experiment, though. It's *research* (or, if you prefer, intellectual masturbation). If we already knew the outcome, it wouldn't be research, would it? -- Max On Fri, Jul 9, 2010 at 10:33 AM, David Leibs david.le...@oracle.comwrote: for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern v http://en.wikipedia.org/wiki/Vector_%28geometric%29ector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
I am somewhat dyslexic and I don't always read things in the right order so I read SLOC/day/programmer as SHLOCK/day/programmer it fits in a negative metric kinda way. Maybe it is a meme we should unleash on our overlings. -djl On Jul 9, 2010, at 12:16 PM, John Zabroski wrote: Just to be clear, The foremost experts and definitive source on software metrics -- Fenton and Pfleeger [1] -- do not really support SLOC/day/programmer as a good metric for productivity. It seems to me (from hearing reports by others) that most people do not actually read books on metrics and instead gravitate towards the simplest ones, regardless of effectiveness. Usually SLOC/day/programmer is a good way, though, to convince your boss that a project predicted to be 300,000 lines of brute force coding cannot be done in a weekend. The argument being you literally cannot type that fast. Cheers, Z-Bo [1] http://www.amazon.com/Software-Metrics-Norman-E-Fenton/dp/0534956009 On Fri, Jul 9, 2010 at 2:47 PM, Max OrHai max.or...@gmail.com wrote: Just to clarify, I'm a bit uncomfortable with productivity talk here because it seems too narrow and ill-defined. Productivity of what exactly? By whom? For whom? To what end? To a specific manager of a specific project in a specific development phase, these questions may have specific, meaningful answers. When it comes to fundamentally rethinking basic tools and practices, I'm not so sure. Of course, core values must be somewhat vague, to allow them to mesh with constantly changing circumstances. Personally, I'd rather strive for quality than productivity. I'm generally suspicious of premature quantification: just because you can measure something doesn't make it meaningful! It seems to me that, as crufty, haphazard, hidebound, etc. as software engineering is today, software engineering management (with its productivity metrics such as source lines of code per programmer per day) are even worse. We all know code quality varies wildly between programmers using the exact same sets of tools. Talent and training contribute enormously. However, I imagine that everyone on this list can agree that the tools themselves matter too, even if it's difficult to quantify that difference precisely. Keep it simple is a widely applicable and successful heuristic. I see this project as (largely) an experiment in applying that heuristic to the fairly well-defined category of creating the personal computing experience, with a depth and breadth impossible in the productivity/profit-bound world of commercial software, and a consistency and quality level impossible in the the traditional open- source project. It's just an experiment, though. It's research (or, if you prefer, intellectual masturbation). If we already knew the outcome, it wouldn't be research, would it? -- Max On Fri, Jul 9, 2010 at 10:33 AM, David Leibs david.le...@oracle.com wrote: for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern vector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org
Re: [fonc] goals
Just wondering... when did that metaphor get started at VPRI? The first time I had heart you reference the t-shirt metaphor was October 2009 [1]. I remember joking about it on Lambda the Ultimate in April of 2009 [2], and my joke was actually based on a presentation given by the head operations physicist of the Relativistic Heavy Ion Collider project at BNL, Todd Satogata [3]. He gave a talk about how you can buy a t-shirt with Maxwell's Equations on it and it pretty much describes the whole universe. But he said his goal was to unify the strong force and weak force and come up with a new t-shirt, and make millions of dollars and become famous. When I heard that you were interested in Maxwell's Equations for Computer Science, I immediately made the connection to Todd Satogata's BNL speech (I've heard him give roughly the same pitch in other speeches many times), so that is why I made the joke about printing Maxwell's Equations for Computer Science on a t-shirt. [1] http://media.cs.uiuc.edu/seminars/StateFarm-Kay-2009-10-22a.asx [2] http://lambda-the-ultimate.org/node/3265#comment-48129 [3] http://toddsatogata.net/ On Fri, Jul 9, 2010 at 1:44 PM, Alan Kay alan.n...@yahoo.com wrote: One of my all time favorite metaphors and examples for part of what we are trying to do in this T-shirt programming project. Cheers, Alan -- *From:* David Leibs david.le...@oracle.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Fri, July 9, 2010 10:33:04 AM *Subject:* Re: [fonc] goals for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern v http://en.wikipedia.org/wiki/Vector_%28geometric%29ector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
The metaphor happened to me in grad school in the 60s when I finally took the trouble to trace McCarthy's Lisp in itself and realized just how powerful and comprehensive he had made it in such a compact way. It was not so much the Turing aspect but the slope of the power from nothing. I said to myself this is the Maxwell's Equations of computing. I think I recounted this in the Early History of Smalltalk. And as a science and math major as an undergraduate, I knew the story that David told about how Heaviside had collapsed the difficult to understand partial differential equations form into the vectorized-operatorized t-shirt size we know. As a post-doc I had some fun working in McCarthy's lab at Stanford and a hobby was finding much more compact ways to do Lisp (it can really be shrunk down from John's version) and amounts really to being able to say what it means to send a message from one context to another Cheers, Alan From: John Zabroski johnzabro...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Fri, July 9, 2010 2:48:27 PM Subject: Re: [fonc] goals Just wondering... when did that metaphor get started at VPRI? The first time I had heart you reference the t-shirt metaphor was October 2009 [1]. I remember joking about it on Lambda the Ultimate in April of 2009 [2], and my joke was actually based on a presentation given by the head operations physicist of the Relativistic Heavy Ion Collider project at BNL, Todd Satogata [3]. He gave a talk about how you can buy a t-shirt with Maxwell's Equations on it and it pretty much describes the whole universe. But he said his goal was to unify the strong force and weak force and come up with a new t-shirt, and make millions of dollars and become famous. When I heard that you were interested in Maxwell's Equations for Computer Science, I immediately made the connection to Todd Satogata's BNL speech (I've heard him give roughly the same pitch in other speeches many times), so that is why I made the joke about printing Maxwell's Equations for Computer Science on a t-shirt. [1] http://media.cs.uiuc.edu/seminars/StateFarm-Kay-2009-10-22a.asx [2] http://lambda-the-ultimate.org/node/3265#comment-48129 [3] http://toddsatogata.net/ On Fri, Jul 9, 2010 at 1:44 PM, Alan Kay alan.n...@yahoo.com wrote: One of my all time favorite metaphors and examples for part of what we are trying to do in this T-shirt programming project. Cheers, Alan From: David Leibs david.le...@oracle.com To: Fundamentals of New Computing fonc@vpri.org Sent: Fri, July 9, 2010 10:33:04 AM Subject: Re: [fonc] goals for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern vector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
I know that part. I meant extending the metaphor to the joke about printing t-shirts. David mentioned collapsing this, and I mentioned how I brought up the joke on LtU about doing this for computer science. I've read your Maxwell's Equations for Computer Science before, such as the NSF 2007 report, but never read the t-shirt joke before the talk I linked below. I first heard this joke from Todd Satogata, who wants to keep Maxwell's Equations as simple as a cool t-shirt, but increase its expressive power by unifying the strong and weak forces -- it just shows even physicists don't give up shrinking the size of the core theory that defines their field. Have a good weekend! Z-Bo On Fri, Jul 9, 2010 at 7:24 PM, Alan Kay alan.n...@yahoo.com wrote: The metaphor happened to me in grad school in the 60s when I finally took the trouble to trace McCarthy's Lisp in itself and realized just how powerful and comprehensive he had made it in such a compact way. It was not so much the Turing aspect but the slope of the power from nothing. I said to myself this is the Maxwell's Equations of computing. I think I recounted this in the Early History of Smalltalk. And as a science and math major as an undergraduate, I knew the story that David told about how Heaviside had collapsed the difficult to understand partial differential equations form into the vectorized-operatorized t-shirt size we know. As a post-doc I had some fun working in McCarthy's lab at Stanford and a hobby was finding much more compact ways to do Lisp (it can really be shrunk down from John's version) and amounts really to being able to say what it means to send a message from one context to another Cheers, Alan -- *From:* John Zabroski johnzabro...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Fri, July 9, 2010 2:48:27 PM *Subject:* Re: [fonc] goals Just wondering... when did that metaphor get started at VPRI? The first time I had heart you reference the t-shirt metaphor was October 2009 [1]. I remember joking about it on Lambda the Ultimate in April of 2009 [2], and my joke was actually based on a presentation given by the head operations physicist of the Relativistic Heavy Ion Collider project at BNL, Todd Satogata [3]. He gave a talk about how you can buy a t-shirt with Maxwell's Equations on it and it pretty much describes the whole universe. But he said his goal was to unify the strong force and weak force and come up with a new t-shirt, and make millions of dollars and become famous. When I heard that you were interested in Maxwell's Equations for Computer Science, I immediately made the connection to Todd Satogata's BNL speech (I've heard him give roughly the same pitch in other speeches many times), so that is why I made the joke about printing Maxwell's Equations for Computer Science on a t-shirt. [1] http://media.cs.uiuc.edu/seminars/StateFarm-Kay-2009-10-22a.asx [2] http://lambda-the-ultimate.org/node/3265#comment-48129 [3] http://toddsatogata.net/ On Fri, Jul 9, 2010 at 1:44 PM, Alan Kay alan.n...@yahoo.com wrote: One of my all time favorite metaphors and examples for part of what we are trying to do in this T-shirt programming project. Cheers, Alan -- *From:* David Leibs david.le...@oracle.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Fri, July 9, 2010 10:33:04 AM *Subject:* Re: [fonc] goals for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern v http://en.wikipedia.org/wiki/Vector_%28geometric%29ector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time
Re: [fonc] goals
Max, You mention software engineering management which reminds me of Tom Gilb's book Principles of Software Engineering Management which is still a favorite of mine despite that he replaced it with his more recent Competitive Engineering. He begins any management exercise by defining six to ten measurable goals, and specifying how the numbers shall be calculated. These are usually quality goals with specific numbers attached. If easily learned is a chosen goal, it is accompanied by selected training and testing procedures to find the numbers which measure progress toward that goal. Inventing ways to meet multiple goals is what he means by the term engineering. Lines of code is a number all right, but it's not often a useful number for the stakeholders paying for the effort. Minutes to complete a specified task after a day of training and practice might more likely be a useful target. Perhaps you'd like to have a few of those quality goals. It often seems that the only real goal for software projects is delivery date since the others all give way in the effort to meet that one. I hate it when that happens. No time to do it well, but always time to do it over is a frequent complaint. Richard On Fri, Jul 9, 2010 at 11:47 AM, Max OrHai max.or...@gmail.com wrote: Just to clarify, I'm a bit uncomfortable with productivity talk here because it seems too narrow and ill-defined. Productivity of what exactly? By whom? For whom? To what end? To a specific manager of a specific project in a specific development phase, these questions may have specific, meaningful answers. When it comes to fundamentally rethinking basic tools and practices, I'm not so sure. Of course, core values must be somewhat vague, to allow them to mesh with constantly changing circumstances. Personally, I'd rather strive for quality than productivity. I'm generally suspicious of premature quantification: just because you can measure something doesn't make it meaningful! It seems to me that, as crufty, haphazard, hidebound, etc. as software engineering is today, software engineering management (with its productivity metrics such as source lines of code per programmer per day) are even worse. We all know code quality varies wildly between programmers using the exact same sets of tools. Talent and training contribute enormously. However, I imagine that everyone on this list can agree that the tools themselves matter too, even if it's difficult to quantify that difference precisely. Keep it simple is a widely applicable and successful heuristic. I see this project as (largely) an experiment in applying that heuristic to the fairly well-defined category of creating the personal computing experience, with a depth and breadth impossible in the productivity/profit-bound world of commercial software, and a consistency and quality level impossible in the the traditional open-source project. It's just an experiment, though. It's *research* (or, if you prefer, intellectual masturbation). If we already knew the outcome, it wouldn't be research, would it? -- Max On Fri, Jul 9, 2010 at 10:33 AM, David Leibs david.le...@oracle.comwrote: for example, is a lot of this added code because: the programmer has little idea what he was doing, and so just wildly copy-pasted everywhere and made a big mess?... has lots of code which is actually beneficial, such as doing error checking and building abstractions. similarly, is a piece of code smaller because: the programmer is good at getting work done in less code? or because the code is essentially a tangled mess of hacks? It isn't that the programmer has little idea of what he is doing. Things just take time to be transformed into an optimal form. There is a good example from the history from math, and physics that illustrates the point. Maxwells equations originally applied to a set of eight equations published by Maxwell in 1865. After that the number of equations escalated to twenty equations in twenty unknowns as people struggled with the implications. Maxwell wrestled with recasting the equations in quaternion form. Time passed. It was all very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math from the then cumbersome form to its modern v http://en.wikipedia.org/wiki/Vector_(geometric)ector calculus notation, thereby reducing the twenty equations in twenty unknowns down to the four differential equations in two unknowns that we all love and call Maxwells equations. Heaviside invented the modern notation giving us the tools to make sense of something very profound and useful. Good work on hard things takes time plus a lot of good people that care. cheers, -David Leibs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
