12 ms·

The Future of Computing: Logic or Biology (2003) [pdf]

126 points by panic 8y ago

guhidalg 8y ago
This is very fluffy for Lamport, nothing of real substance in this essay. I did get a chuckle out of this: > In retrospect, thinking of programs as automobiles wasn’t so bad. Automobiles are pretty simple. If their car stops working, people expect any good mechanic to be able to figure out why and fix the problem. Ok, I guess a century of engineering has produced some pretty simple machines :) /s
- eggy 8y ago
  And yet I have a friend with a Triumph motorcycle who has brought it to multiple mechanics and there is an electrical issue somewhere that nobody has been able to definitively fix. Maybe not so simple even after a century of engineering so many variations on a theme.
  - hprotagonist 8y ago
    thus the old joke: “why do the british drink warm beer?” “Lucas makes refrigerators, too!”
- nickelcitymario 8y ago
  If we were great at engineering, a century's worth would have ideally led to simpler machines. Simplicity = sophistication. (Before you hate on me, please know that I mean things should be as simple as possible, but no simpler. Cars, I believe, are not as simple as possible. They are incredibly complex. That said, look at a Tesla. Mechanically speaking, they're impressively simple machines.)
  - leephillips 8y ago
    You’re in good company. Leonardo da Vinci said, “Simplicity is the ultimate sophistication.”
- ghettoimp 8y ago
  Hrmn. The various analogies are perhaps a bit fluffy, and the email and drag-and-drop examples are perhaps not particularly convincing. But man, I wish Lamport's call for our industry to think more logically and design programs more mathematically would gain more traction. These little inconsistencies add up to create horrible messes. This is true everywhere from our programs to our languages to the core abstractions and APIs that we work with. Some examples off the top of my head: - "Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems" (https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html https://www.dwheeler.com/essays/fixing-unix-linux-filenames....) - "Parsing JSON is a Minefield" (http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php) - "Into the Depths of C: Elaborating the De Facto Standards" (http://www.cl.cam.ac.uk/~pes20/cerberus/pldi16.pdf http://www.cl.cam.ac.uk/~pes20/cerberus/pldi16.pdf) - "PHP: a fractal of bad design" (https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/)
petermcneeley 8y ago
"An automobile is a piece of machinery, a program is some kind of mathematical expression" If I build a mechanical computer to output the digits of PI is that a piece of machinery, a program or a mathematical expression?
- federicoponzi 8y ago
  A computer is a piace of machinery capable of running programs. You're building a specialized hardware to run a program - so I guess it's still a piece of machinery even if capable of running one program.
zanker_swe1 8y ago
Perhaps Prof. Lamport is giving too much credit our understanding of automobiles this time around: "There are no homeopathic automobile repair shops, that try to repair your car by putting infinitesimal dilutions of rust in the gas tank. There are no automotive faith healers, who lay their hands on the hood and pray. People reserve such superstitions for things that they don’t understand very well, such as the human body." I don't think that is true. I routinely see automobiles that are 'blessed' on the streets of San Jose (quite likely the owners of these vehicles are developing software that this paper talks about).
- TeMPOraL 8y ago
  True. This can be seen everywhere, from food to football. I believe it can be boiled down to two things: uncertainty, which makes some people desire reassurance from supernatural, and non-obvious failure modes, which makes selling this reassurance pretty much risk-free.
  - zanker_swe1 8y ago
    Yes, most of us not do not seem to be able to resist the desire for the reassurance as you put it. My reading of the paper is that it is more about the lack of mathematical (perhaps rational or logical may be the right word) approach to program development than proving programs or lack of proofs.
- tzahola 8y ago
  I prayed for the starter motor to be able turn the crank with whatever charge was left after my brother borrowed my car and drained the battery by leaving the headlights on.
- whatshisface 8y ago
  Woo is in market competition with evidence-based solutions. Mechanics fix your car essentially every time, in exchange for money. Doctors fix you sometimes, in exchange for a lot more money. So obviously the woo is going to thrive a lot more in the second market.
- 8y ago
deleted 8y ago
[deleted]
smilliken 8y ago
I'm a mathematician. Math shares a lot in common with programming. So much that it's easy to conflate the two. This caused me a lot of misery. The problem is that the constraints around the development of mathematics are entirely different than software. Math is abstract, and there's no tolerance for incorrectness. A single inconsistency and we throw out the entire thing. Math is also not stateful, it costs nothing to throw out a theorem. Software is constrained in all directions: time, cost, performance, memory pressure, hardware compatibility, etc. For all that math shares with programming, practicing math shares very little with practicing programming. It was frustrating trying to design correct programs. My misery ended when I started thinking about software as biological systems. Software isn't constrained by correctness, it's constrained by fitness. Software decays if it's not maintained. It needs a metabolism: it must capture free energy from the environment and use that energy to increase its fitness (eg, making money in commercial software, or being useful to its maintainers in free software). It must reproduce, "infecting" new hosts. Software grows through accreted complexity and mutation, not up-front design. Software is unfit for survival outside of its ecosystem; as the ecosystem changes, it must adapt. Software has competition, predators, prey, symbiotes, and viruses.
- nabla9 8y ago
  Another way software is similar to biology and physical systems is leaky abstraction. Once you define something in mathematics, how you defined it does not matter. You can forget all irrelevant details. In the software irrelevant minute details make systems incompatible. As an example, Norbert Wiener defined ordered pair as: (a,b) := {{{a}, Ø},{{b}}} Hausdorff defined it as: (a,b) := {{a,1},{b,2}}, where 1 and 2 are two distinct objects different from a and b Kuratowski's definition (a,b) := {{a}, {a,b}} .. and there are many other definitions and variations, but still we have only one mathematics not many incompatible ones. Some mathematicians restrict them to subsets, but they don't create incompatible mathematics. If you do something similar in programming languages, you get two different structures you can't use interchangeably without transformation (it incompatibility starts from little endian vs big endian and ending ends with vi vs emacs).
  - smilliken 8y ago
geoalchimista 8y ago
Related: http://lamport.azurewebsites.net/tla/math-knowledge.html http://lamport.azurewebsites.net/tla/math-knowledge.html I think the question itself sort of answered why programmers don't think programs as mathematical expressions.
ArekDymalski 8y ago
Hmm, while I wouldn't argue that program = automobile, I find the author's arguments unconvincing, especially the part about meaning. Both car and software are the tools and in case of every (well designed) tool it's easy to provide the answer to author's question: "what is it supposed to do?". For example, car is supposed to move people and goods quickly and safely. And I think proving that "meaning" wouldn't be harder that proving the meaning of any sufficently complicated software. For example MS Word :)
joe_the_user 8y ago
It's an interesting article but I feel like it fails to actually illuminate what's behind the distinction between logic and biology. "Biology is very different from logic—or even from the physical sciences. If biologists find that a particular mutation of a gene is present in 80% of people suffering from a certain disease, and missing from 80% of a control group, then that’s a significant result. If physicists tried to report an experiment in which 80% of the events supported their theory, they’d be required to explain what happened in the other 20%" This may be true but accuracy by itself is not a very "deep" distinction. If you have crude engineering, you can accept a low percentage of accuracy. If you happen to have done good bioengineering, 80% might not be good enough accuracy. A much more illuminating quality of biological systems is A. they are much more complex and B. they are tolerant of variation everywhere, that biological systems with varying properties interoperate without major problems whereas computer components require very fine tolerances to operate together. Human organs vary from person to person yet different people remain alive. If a given computer component varies substantially, chances are the machine won't stop. The variation of each component of a biological system relates to another property of biological systems - "self-organization"; each of the components of a biological system appears through a million-year long process of self-reproduction. So each component has a bit of something (feedback, intelligence, design, etc) which allows it to keep going even when inputs and outputs are imperfect. And finally, there's the quality of lack of any overall idea. Genetic code involves a haphazard of grouping of "lasagna code" that merely happens to work, that X component accomplishes N tasks, M of which serve no current purpose that's OK. These M purposes functionalities may have served a purpose in the past and may serve a purpose in the future but maybe neither. The methodologies operating haphazardly by itself serves the purpose of having a variety of instances of an organism that can adapt when the environment changes.
araes 8y ago
This article is interesting in terms of producing useful though / mental discussion, yet on completing that thought I disagree with almost all of it. - Programs are not like cars. Programs are like cars. They are a manufactured construct created for a specific purpose, which does have relative degrees of correctness. If I have a car with no wheels, it is not a "correct" car, it is at best a chair. No engine or drivetrain, similiar - not "correct" car. Oddly enough, no seat, possibly still "correct". Hiccuping or jumping behavior, it has a bug, or a glitch. - Software should be pure logic automata. In many respects I would argue this can be a "bad". Such software can be extremely limited - it does X, no more. Or, it can be very brittle. It does does X1, but if I try X2, it breaks. Software like biology is in many ways better. I feed my software an apple, it eats it, producing work and waste. I feed my software a steak, similiar. I hand my software a baseball, it throws it. I hand it a football, it does similiar. I hand it an apple, it may eat it or throw it depending on the need. - Faith healing. This has been a meme since nearly the dawn of computers. "Have you tried restarting it?" Maybe kicking it. Wifi won't work? Bad spirits in your house. I worked with fluid mechanics for years, and many (non-trivial) simulations seemed about as likely to complete due to system noise as they did due to program correctness. Further, there is a serious ivory tower attitude here towards magical thinking and superstition. Technology shamanism is a very real thing. People gravitate towards it often because it works. Its oddly scientific method. If I have my lucky rabbit foot, the program compiles. If I don't, system crash.
hoffcoder 8y ago
Biological systems are logical too. The genome is the program that is hardwired into them. They also run on mathematics involved in chemical reactions. Even the simplest organism like the single-celled amoeba has more complicated and highly optimized algorithms programmed into its genome for survival than the most complex system (like the LHC) ever built by humans. An amoeba behaves the way it behaves because the laws of physics imbued in the mathematics of its chemical reactions caused it to overwrite its own gene code in such a way so as to optimize the mathematical probability of its own survival. Mathematics is merely an abstraction of our mind to understand the reality of our world. The programs that we create solve problems in our world, but are constrained by the same kind of variables that constrain biological systems, but both biological and software systems could be interpreted in terms of mathematics. No real world biological or physical system is 'simple'. Every program starts simple, but even that is up to interpretation. A one liner program in any language is extremely complicated once you factor in the OS, the compiler and the interpreter that will actually run this program. Once the program intakes more complicated functionalities, and also multiple programmers, it becomes anything but simple. Simplicity is good to organize our thoughts and design systems, but it a whole different matter to expect that the designed system will also stay simple. Hence just like any other system in nature, software also has to evolve, and there shouldn't be anything wrong with that. A mathematical proof is not a panacea for the problems in software development. The purpose of software changes, its constraints change, and proofs will have to be rewritten everytime. You don't expect the underlying laws of mathematics to change, that is why once proved, a theorem stays proved. But in software it is expected that the system's underlying purpose will change with time. So proving the current state is what we can do, which is not of much consequence as time goes by.

126 points by panic 8y ago

This is very fluffy for Lamport, nothing of real substance in this essay. I did get a chuckle out of this: > In retrospect, thinking of programs as automobiles wasn’t so bad. Automobiles are pretty simple. If their car stops working, people expect any good mechanic to be able to figure out why and fix the problem. Ok, I guess a century of engineering has produced some pretty simple machines :) /s

eggy 8y ago
And yet I have a friend with a Triumph motorcycle who has brought it to multiple mechanics and there is an electrical issue somewhere that nobody has been able to definitively fix. Maybe not so simple even after a century of engineering so many variations on a theme.
- hprotagonist 8y ago
  thus the old joke: “why do the british drink warm beer?” “Lucas makes refrigerators, too!”
nickelcitymario 8y ago
If we were great at engineering, a century's worth would have ideally led to simpler machines. Simplicity = sophistication. (Before you hate on me, please know that I mean things should be as simple as possible, but no simpler. Cars, I believe, are not as simple as possible. They are incredibly complex. That said, look at a Tesla. Mechanically speaking, they're impressively simple machines.)
- leephillips 8y ago
  You’re in good company. Leonardo da Vinci said, “Simplicity is the ultimate sophistication.”
ghettoimp 8y ago
Hrmn. The various analogies are perhaps a bit fluffy, and the email and drag-and-drop examples are perhaps not particularly convincing. But man, I wish Lamport's call for our industry to think more logically and design programs more mathematically would gain more traction. These little inconsistencies add up to create horrible messes. This is true everywhere from our programs to our languages to the core abstractions and APIs that we work with. Some examples off the top of my head: - "Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems" (https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html https://www.dwheeler.com/essays/fixing-unix-linux-filenames....) - "Parsing JSON is a Minefield" (http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php) - "Into the Depths of C: Elaborating the De Facto Standards" (http://www.cl.cam.ac.uk/~pes20/cerberus/pldi16.pdf http://www.cl.cam.ac.uk/~pes20/cerberus/pldi16.pdf) - "PHP: a fractal of bad design" (https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/)

petermcneeley 8y ago

"An automobile is a piece of machinery, a program is some kind of mathematical expression" If I build a mechanical computer to output the digits of PI is that a piece of machinery, a program or a mathematical expression?

federicoponzi 8y ago
A computer is a piace of machinery capable of running programs. You're building a specialized hardware to run a program - so I guess it's still a piece of machinery even if capable of running one program.

zanker_swe1 8y ago

Perhaps Prof. Lamport is giving too much credit our understanding of automobiles this time around: "There are no homeopathic automobile repair shops, that try to repair your car by putting infinitesimal dilutions of rust in the gas tank. There are no automotive faith healers, who lay their hands on the hood and pray. People reserve such superstitions for things that they don’t understand very well, such as the human body." I don't think that is true. I routinely see automobiles that are 'blessed' on the streets of San Jose (quite likely the owners of these vehicles are developing software that this paper talks about).

TeMPOraL 8y ago
True. This can be seen everywhere, from food to football. I believe it can be boiled down to two things: uncertainty, which makes some people desire reassurance from supernatural, and non-obvious failure modes, which makes selling this reassurance pretty much risk-free.
- zanker_swe1 8y ago
  Yes, most of us not do not seem to be able to resist the desire for the reassurance as you put it. My reading of the paper is that it is more about the lack of mathematical (perhaps rational or logical may be the right word) approach to program development than proving programs or lack of proofs.
tzahola 8y ago
I prayed for the starter motor to be able turn the crank with whatever charge was left after my brother borrowed my car and drained the battery by leaving the headlights on.
whatshisface 8y ago
Woo is in market competition with evidence-based solutions. Mechanics fix your car essentially every time, in exchange for money. Doctors fix you sometimes, in exchange for a lot more money. So obviously the woo is going to thrive a lot more in the second market.
8y ago

deleted 8y ago

[deleted]

smilliken 8y ago

I'm a mathematician. Math shares a lot in common with programming. So much that it's easy to conflate the two. This caused me a lot of misery. The problem is that the constraints around the development of mathematics are entirely different than software. Math is abstract, and there's no tolerance for incorrectness. A single inconsistency and we throw out the entire thing. Math is also not stateful, it costs nothing to throw out a theorem. Software is constrained in all directions: time, cost, performance, memory pressure, hardware compatibility, etc. For all that math shares with programming, practicing math shares very little with practicing programming. It was frustrating trying to design correct programs. My misery ended when I started thinking about software as biological systems. Software isn't constrained by correctness, it's constrained by fitness. Software decays if it's not maintained. It needs a metabolism: it must capture free energy from the environment and use that energy to increase its fitness (eg, making money in commercial software, or being useful to its maintainers in free software). It must reproduce, "infecting" new hosts. Software grows through accreted complexity and mutation, not up-front design. Software is unfit for survival outside of its ecosystem; as the ecosystem changes, it must adapt. Software has competition, predators, prey, symbiotes, and viruses.

nabla9 8y ago
Another way software is similar to biology and physical systems is leaky abstraction. Once you define something in mathematics, how you defined it does not matter. You can forget all irrelevant details. In the software irrelevant minute details make systems incompatible. As an example, Norbert Wiener defined ordered pair as: (a,b) := {{{a}, Ø},{{b}}} Hausdorff defined it as: (a,b) := {{a,1},{b,2}}, where 1 and 2 are two distinct objects different from a and b Kuratowski's definition (a,b) := {{a}, {a,b}} .. and there are many other definitions and variations, but still we have only one mathematics not many incompatible ones. Some mathematicians restrict them to subsets, but they don't create incompatible mathematics. If you do something similar in programming languages, you get two different structures you can't use interchangeably without transformation (it incompatibility starts from little endian vs big endian and ending ends with vi vs emacs).
- smilliken 8y ago

geoalchimista 8y ago

Related: http://lamport.azurewebsites.net/tla/math-knowledge.html http://lamport.azurewebsites.net/tla/math-knowledge.html I think the question itself sort of answered why programmers don't think programs as mathematical expressions.

ArekDymalski 8y ago

Hmm, while I wouldn't argue that program = automobile, I find the author's arguments unconvincing, especially the part about meaning. Both car and software are the tools and in case of every (well designed) tool it's easy to provide the answer to author's question: "what is it supposed to do?". For example, car is supposed to move people and goods quickly and safely. And I think proving that "meaning" wouldn't be harder that proving the meaning of any sufficently complicated software. For example MS Word :)

joe_the_user 8y ago

It's an interesting article but I feel like it fails to actually illuminate what's behind the distinction between logic and biology. "Biology is very different from logic—or even from the physical sciences. If biologists find that a particular mutation of a gene is present in 80% of people suffering from a certain disease, and missing from 80% of a control group, then that’s a significant result. If physicists tried to report an experiment in which 80% of the events supported their theory, they’d be required to explain what happened in the other 20%" This may be true but accuracy by itself is not a very "deep" distinction. If you have crude engineering, you can accept a low percentage of accuracy. If you happen to have done good bioengineering, 80% might not be good enough accuracy. A much more illuminating quality of biological systems is A. they are much more complex and B. they are tolerant of variation everywhere, that biological systems with varying properties interoperate without major problems whereas computer components require very fine tolerances to operate together. Human organs vary from person to person yet different people remain alive. If a given computer component varies substantially, chances are the machine won't stop. The variation of each component of a biological system relates to another property of biological systems - "self-organization"; each of the components of a biological system appears through a million-year long process of self-reproduction. So each component has a bit of something (feedback, intelligence, design, etc) which allows it to keep going even when inputs and outputs are imperfect. And finally, there's the quality of lack of any overall idea. Genetic code involves a haphazard of grouping of "lasagna code" that merely happens to work, that X component accomplishes N tasks, M of which serve no current purpose that's OK. These M purposes functionalities may have served a purpose in the past and may serve a purpose in the future but maybe neither. The methodologies operating haphazardly by itself serves the purpose of having a variety of instances of an organism that can adapt when the environment changes.

araes 8y ago

This article is interesting in terms of producing useful though / mental discussion, yet on completing that thought I disagree with almost all of it. - Programs are not like cars. Programs are like cars. They are a manufactured construct created for a specific purpose, which does have relative degrees of correctness. If I have a car with no wheels, it is not a "correct" car, it is at best a chair. No engine or drivetrain, similiar - not "correct" car. Oddly enough, no seat, possibly still "correct". Hiccuping or jumping behavior, it has a bug, or a glitch. - Software should be pure logic automata. In many respects I would argue this can be a "bad". Such software can be extremely limited - it does X, no more. Or, it can be very brittle. It does does X1, but if I try X2, it breaks. Software like biology is in many ways better. I feed my software an apple, it eats it, producing work and waste. I feed my software a steak, similiar. I hand my software a baseball, it throws it. I hand it a football, it does similiar. I hand it an apple, it may eat it or throw it depending on the need. - Faith healing. This has been a meme since nearly the dawn of computers. "Have you tried restarting it?" Maybe kicking it. Wifi won't work? Bad spirits in your house. I worked with fluid mechanics for years, and many (non-trivial) simulations seemed about as likely to complete due to system noise as they did due to program correctness. Further, there is a serious ivory tower attitude here towards magical thinking and superstition. Technology shamanism is a very real thing. People gravitate towards it often because it works. Its oddly scientific method. If I have my lucky rabbit foot, the program compiles. If I don't, system crash.

hoffcoder 8y ago

Biological systems are logical too. The genome is the program that is hardwired into them. They also run on mathematics involved in chemical reactions. Even the simplest organism like the single-celled amoeba has more complicated and highly optimized algorithms programmed into its genome for survival than the most complex system (like the LHC) ever built by humans. An amoeba behaves the way it behaves because the laws of physics imbued in the mathematics of its chemical reactions caused it to overwrite its own gene code in such a way so as to optimize the mathematical probability of its own survival. Mathematics is merely an abstraction of our mind to understand the reality of our world. The programs that we create solve problems in our world, but are constrained by the same kind of variables that constrain biological systems, but both biological and software systems could be interpreted in terms of mathematics. No real world biological or physical system is 'simple'. Every program starts simple, but even that is up to interpretation. A one liner program in any language is extremely complicated once you factor in the OS, the compiler and the interpreter that will actually run this program. Once the program intakes more complicated functionalities, and also multiple programmers, it becomes anything but simple. Simplicity is good to organize our thoughts and design systems, but it a whole different matter to expect that the designed system will also stay simple. Hence just like any other system in nature, software also has to evolve, and there shouldn't be anything wrong with that. A mathematical proof is not a panacea for the problems in software development. The purpose of software changes, its constraints change, and proofs will have to be rewritten everytime. You don't expect the underlying laws of mathematics to change, that is why once proved, a theorem stays proved. But in software it is expected that the system's underlying purpose will change with time. So proving the current state is what we can do, which is not of much consequence as time goes by.