3 ms·

The funny thing is that Common Lisp can be used to deliver working systems just fine. In fact, there's nothing "perfect" about it. It has warts. But it is actua

The funny thing is that Common Lisp can be used to deliver working systems just fine. In fact, there's nothing "perfect" about it. It has warts. But it is actually quite practical. "Worse is better," is thankfully a philosophy that is pretty unique (afaik) to software development. It is only really applicable to a sub-set of software development as well. I cannot imagine how "worse is better" would work in mission critical systems where human lives are at stake. Or lab equipment, embedded systems, and other scenarios where failures can result in huge headaches. I don't think there was a battle that was won by any side really. Either approach could be considered for any given problem. Practicality is important and zealotry should be avoided at all costs.

nknight 15y ago
If you substitute "practicality" wherever you see "worse is better", you'll have a much clearer idea of what the "philosophy" really is, and realize it in no way conflicts with critical systems. All software design and development is done to a set of requirements. The more disastrous a failure would be, the stricter the requirements will be, and the more rigorous the processes will be. Like almost all other developers, my software does not run nuclear reactors, therefore I am not going to expend the resources to achieve the safety necessary for a nuclear reactor. It would be both unnecessary and economically infeasible. Do I care if a client makes a call to my IPTV webservice and gets back corrupt data? Well, yeah, but I'm not going to step through the entire software stack to mathematically prove it's impossible, nor am I going to encase the servers in a lightyear of lead to protect them from cosmic rays. I'm going to follow general best practices, let some testers play with it for a few days (while thousands of other lines of code in the client and server get exercised at the exact same time) and ship it. Why? Because the small risk of a user not being able to watch their favorite movie in some weird corner-case has less economic significance than me spending days making 100% sure everything is perfect in my new API call. At the same time, I recognize components of my systems that can have serious economic consequences, and accordingly invest more time in getting them closer to "right" (or avoiding them entirely -- e.g. not so long ago I ripped out all the C-style string/buffer handling from what was ostensibly a C++ library (not mine, originally) and replaced it with std::string and std::vector, which I knew were right, because people smarter than me had made sure they were, because everyone knew they had to be, and time was invested accordingly). This is a continuum, not a pigeonhole.

nknight 15y ago

If you substitute "practicality" wherever you see "worse is better", you'll have a much clearer idea of what the "philosophy" really is, and realize it in no way conflicts with critical systems. All software design and development is done to a set of requirements. The more disastrous a failure would be, the stricter the requirements will be, and the more rigorous the processes will be. Like almost all other developers, my software does not run nuclear reactors, therefore I am not going to expend the resources to achieve the safety necessary for a nuclear reactor. It would be both unnecessary and economically infeasible. Do I care if a client makes a call to my IPTV webservice and gets back corrupt data? Well, yeah, but I'm not going to step through the entire software stack to mathematically prove it's impossible, nor am I going to encase the servers in a lightyear of lead to protect them from cosmic rays. I'm going to follow general best practices, let some testers play with it for a few days (while thousands of other lines of code in the client and server get exercised at the exact same time) and ship it. Why? Because the small risk of a user not being able to watch their favorite movie in some weird corner-case has less economic significance than me spending days making 100% sure everything is perfect in my new API call. At the same time, I recognize components of my systems that can have serious economic consequences, and accordingly invest more time in getting them closer to "right" (or avoiding them entirely -- e.g. not so long ago I ripped out all the C-style string/buffer handling from what was ostensibly a C++ library (not mine, originally) and replaced it with std::string and std::vector, which I knew were right, because people smarter than me had made sure they were, because everyone knew they had to be, and time was invested accordingly). This is a continuum, not a pigeonhole.