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. Craziness I say... make it stop, make it stop! :-/ I think these things are better off simplified in the extreme and carried out by automatons, get the humans out of the picture... Humans should focus on higher level requirements not the nuts and bolts of software construction. Or perhaps a more stochastic process like biology and let order emerge from chaos - maybe the logic will be less brittle that way... But that may be a ways off yet. Clearly whatever we are doing isn't working - it is pure madness to continue in this way. Alan Moore On Dec 31, 2012, at 12:09 PM, Paul Homer <[email protected]> wrote: 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 'intelligence' could validate that those types of rules match their intended usage in the real world. If we don't build our internal systems models with this in mind, then they'd be too fragile to solve real problems for us. Like it or not, intelligence is a necessary ingredient, and we don't yet have any alternatives but ourselves to fill it. Paul. ------------------------------ * From: * Marcus G. Daniels <[email protected]>; * To: * <[email protected]>; * Subject: * Re: [fonc] Linus Chews Up Kernel Maintainer For Introducing Userspace Bug - Slashdot * Sent: * Mon, Dec 31, 2012 7:50:13 PM On 12/31/12 12:25 PM, Carl Gundel wrote: “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. In the case of numerical method development, the math is represented in Mathematica (Maple, Sage, Macsyma, etc.) and simulations are done using the same or Matlab (Octave, Scipy, R, etc.). The foundational work is already a program. One practical way to advance the state of the art would be to ensure that the symbolic math packages had compilers that created executables that performed as well as Fortran. In general, I'm imagining more programmers adopting languages like Agda, Coq, and ATS, and elaborating their compilers and runtimes to be practical for programming in the large. Marcus _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
