My take is that crafting software is essentially creating a formal system. No
doubt there is some clean, normalized way to construct each one, but given that
the work is being done by humans, a large number of less than optimal elements
find their way into the system. Since everyone is
I would hope that something like
http://en.wikipedia.org/wiki/Z_notationcould be used to specify
computer systems. No, I've never used Z
notation. It looks like WSDL 2.0 contains it. Cucumber seems more
practical, but along the same lines. I've never used Cucumber either. The
problem is that
I don#39;t think a more formalized language really gets around the problem. If
that were true, we#39;d have already fallen back to the most consistent, yet
simple languages available, such as assembler. But on top of these we build
significantly more complex systems, bent by our own internal
On 12/31/12 10:30 AM, Paul Homer wrote:
Now I know that sounds weird, but not if one accepts that a clunky,
ugly language like COBOL was actually very successful. Lots of stuff
was written, much of it still running. Its own excessive verbosity
helps in making it fixable by a broader group of
Most programs are models of our irrational world. Reflections of rather
informal systems that are inherently ambiguous and contradictory, just like our
species. Nothing short of #39;intelligence#39; could validate that those
types of rules match their intended usage in the real world. If we
+1
From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Paul
Homer
Sent: Monday, December 31, 2012 3:09 PM
To: fonc@vpri.org
Subject: Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing
Userspace Bug - Slashdot
Most programs are models of our irrational world.
I agree with Paul...
As programmers we have too many degrees of freedom, too many chances for
random variation that needs to be negotiated at every interface between
components, etc.
Imagine building a car with randomly varying bolt and nut sizes, with no
two cars following the same pattern.
On 12/31/12 2:32 AM, BGB wrote:
in this case, I think Torvalds was right, however, he could have handled
it a little more gracefully.
code breaking changes are generally something to be avoided wherever
possible, which seems to be the main issue here.
While many people posting in the slashdot
On Mon, Dec 31, 2012 at 12:24 PM, Paul D. Fernhout
pdfernh...@kurtz-fernhout.com wrote:
On 12/31/12 2:32 AM, BGB wrote:
in this case, I think Torvalds was right, however, he could have handled
it a little more gracefully.
code breaking changes are generally something to be avoided wherever
Carl Gundel ca...@psychesystems.com writes:
“If there are contradictions in the design, the program shouldn't
compile.”
How can a compiler know how to make sense of domain specific
contradictions? I can only imagine the challenges we would face if
compilers operated in this way.
On 12/31/12 1:39 PM, Marcus G. Daniels wrote:
Of course, there is rarely the time or incentive structure to do any of
this. Productive programmers are the ones that get results and are fast
at fixing (and creating) bugs. In critical systems, at least, that's
the wrong incentive structure. In
On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
Unless you know what to look for (and even sometimes if you do), it is
hard to tell whether a programmer spending a month or two refactoring
or writing tests is making the system better, or making the system
worse, or maybe just is not doing much at
On Dec 31, 2012, at 1:21 PM, Pascal J. Bourguignon p...@informatimago.com
wrote:
Now we know that a given formal system cannot be at the same time
complete and consistent, but nothing prevents an automatic system to
work with an incomplete system or an inconsistent system (or even a
system
On 12/31/12 1:44 PM, Paul D. Fernhout wrote:
So, it was a meta-bug in that sense about an unexpected meaning shift
when a number leaked beyond a boundary that was supposed to contain it.
[..]
I'm not sure what sort of automated systems could deal with that kind
of unexpected semantic shift?
On 12/31/12 6:36 PM, Marcus G. Daniels wrote:
2. The programmer has a belief or preference that the code is easier to
work with if it isn't abstracted.
It's all right in front of them in the context they want it. Perhaps
they are copying the code from foreign modules they don't maintain and
On 12/31/12 8:30 PM, Paul D. Fernhout wrote:
So, I guess another meta-level bug in the Linux Kernel is that it is
written in C, which does not support certain complexity management
features, and there is no clear upgrade path from that because C++ has
always had serious linking problems.
But
16 matches
Mail list logo
