From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: newbie, Spark 2014 or Ada 2012 Date: Thu, 09 Jul 2015 16:25:45 -0700 Organization: A noiseless patient Spider Message-ID: <87bnfk7w1y.fsf@jester.gateway.sonic.net> References: <974c8db0-c9e8-49d4-8db1-3417ec49217b@googlegroups.com> <87k2uenkcw.fsf@nightsong.com> <87615x9s3o.fsf@jester.gateway.sonic.net> <87pp438tm6.fsf@jester.gateway.sonic.net> <87d2028dfy.fsf@jester.gateway.sonic.net> <878uap8539.fsf@jester.gateway.sonic.net> <87zj356p2q.fsf@jester.gateway.sonic.net> <87oajl6jq4.fsf@jester.gateway.sonic.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="22184b02e80198190244f5a2dd813f11"; logging-data="26602"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+UD+Qtrhu2iYpn+DjMCmYv" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:oljBagg8uJ36lEz+7g7WQnKXWq8= sha1:U/jZR1c+UEH92SVuugCGRwiYSLw= Xref: news.eternal-september.org comp.lang.ada:26731 Date: 2015-07-09T16:25:45-07:00 List-Id: "Jeffrey R. Carter" writes: > So when does this bookshelf that doesn't need to be correct, robust, > and reliable need to ship? This is a red herring. It has nothing to do > with what we're discussing. It's possible to make a reliable bookshelf without a lot of engineering is all I'm saying. > Engineering becomes important when the thing will be used by > others. That's at least 99% of S/W. I don't believe that. I'm probably the sole user of 50% of the code that I write at work, and 90%+ of the code that I write at home. And the stuff I write at work that's used by others is generally running on servers, so the users are interacting with it but not actually running it themselves, which also makes things easier. One such program crashed dozens of times a day during its early deployment and nobody noticed or cared (a monitoring daemon restarted it within milliseconds after every crash). Yes we could have worked more of the bugs out before deploying, but that would have meant delaying launch for no significant gains. We instead examined the crash logs and fixed problems when they occurred, and things got stable after a while. That would have been an irresponsible approach for a safety critical or financial site or one with medical records etc., but for what we were doing (an information service) it was fine. It occurs to me, some of the highest reliability systems in the world (phone switches designed for 40-year lifetimes with zero seconds down) are programmed in Erlang, which is typeless like Python. Those systems do need real development and QA processes, but part of the Erlang mindset is that the software WILL have bugs and the system has to keep running in the presence of those bugs. So the programs are written as interacting lightweight processes that are expected to crash if they hit problems. Crashed processes are monitored and restarted, or the workload migrated if the restart scheme fails. One of the mottos is "the power cord is a single point of failure" which means that the systems use redundant hardware and have the ability to keep running (maybe at degraded capacity) even when something breaks.