127 karma · joined October 11, 2012
Domains in which this is true, specifically domains for which "negative training" gets people killed, are probably the best bet. Military, LEO, disaster preparedness training spring to mind. However, the cost of the real world training exercises replaced has to be more than the cost of the VR, or the training exercise has to be impossible or too dangerous to pull off in the real world.
Source: was at BBN while DARPA pushed the Internet and created SIMNET. Did work for DARPA at own company later. Never met a wooly-haired, wild-eyed fellow nerd or VC with half the imagination of buzz-cut DARPA people.
An in-all-ways superior, analytical model you really ought to know is outlined here:
https://witseie.github.io/software-dev-3/docs/lehmans-laws.p...
RIP, Professor Lehman
While I do not believe I am at liberty to provide details (even lo so many years later), I was witness to the first use of (arguably) VR to prototype and introduce a new weapons platform into a combined arms battlefield simulation. The short version is that on Monday morning, despite all the deep thinking done by smart people about how this would all work out, none of us came close to predicting what turned out to be the net effects of the new system as seen by Friday. I was there in my capacity as a nerd simply to keep the blinking lights blinking (vs the capacity of a combat domain expert), but watching the whole thing unfold was a mind-blowing demonstration of the "Law of Unanticipated Consequences."
None of us are as smart as we think we are. We are no smarter than our adversaries. The world is more complex than either of us can know.
Under active development. Turtles all the way down. Runs on Linux, Raspbian, etc. Runs under (at least) SBCL & CCL.
Don't forget to click the "See all 9 images" link for what I hope you will find to be a treat. (In the interest of full disclosure, I have no financial interest in the book - however, I did buy a copy myself.)
Built with reasonably recent McCLIM and SBCL. At one point, had it running under CCL on one of my Raspberry Pi boxes (the 3, I think). Would have made a cool pocket, ersatz LispM.
Source code:
https://bitbucket.org/symbolicsimulation/com.symsim.oss.lisp...
Yeah, I know it's a mess. With the exception of updating the calls to the inspector just now (in case anybody tried to build it), it's just as I last left it a few years ago - with the proverbial hood open, subsystems not really working, and parts lying all over the floor.
I believe Lehman formalizes the dichotomy you imply as bugs in the "model" (you say "specification"), and bugs in the model's implementation. I think the distinction is important in that the model/spec is an evolving/moving target, subject to evolutionary forces. And the number of bugs in the implementation of any given model's snapshot in time is an increasing function of SLOC, and that updating the model can produce more/latent bugs in previously un-buggy code. (Which I take to mean we need minimize lines of code for any given amount of functionality. Less to write, less lines containing bugs, less to modify, etc.)
Regarding (1): I agree that we perform vastly below our potential due to bugs, but also many other factors - though it might be hard to agree on the what those contributory factors are, and their relative contributions.
I of course realize that people are not perfect (along any axis at all), but I think the importance of this work is highlighting:
(1) software must evolve in order to continue being useful (is this the "cultural" part of your comment?), and
(2) that there are some unavoidable limitations of human capability to achieve that (is this the "people being shit" part of your comment?), particularly in dealing with complexity. And that complexity is an increasing function of lines-of-code count.
So, the obvious conclusion to draw (for me, anyways), is we should work to minimize SLOC by various means: DSLs, &/or expressive/powerful languages.
http://ai2-s2-pdfs.s3.amazonaws.com/5454/5a907a43c798c1193be...
His resulting model of software evolution explains many observations we engineers make about "feature creep," "technical debt," balance of effort between development and maintenance, etc.
I think his model also helps point the way to techniques we can use (e.g., DSLs in preference to OOP) to help improve how we build and maintain software.
The real villain is letting CPFF (cost plus fixed fee) contracts rather the fixed-price contracts.
(1) The nameless model of reality I think is implied by "marginal cost of production is zero" simplifies away some essential aspects of reality (as explained by the late, great, RIP Manny Lehman model of "software evolution"). As the article points out, bug fixes and updates of the existing copy are necessary (to wit, IoT botnets), and in this model one never speaks about the continuing cost to maintaining the zeroth copy.
(2) The anticipated rejoinder to observation (1) is that, given the source, the end-users can do all maintenance, customization, and extension themselves. What we know about complexity (again, thanks, Manny) of any non-trivial application puts the lie to this.
(3) The anticipated rejoinder to observation (2) is existence proofs such as the Linux kernel. My reply to this rejoinder is that Linux is largely corporate-supported as a complement to the supporters products/services.
PDF transcription here http://www.rbcpa.com/mungerspeech_june_95.pdf
Explains a lot (he says, during Presidential Election season in the US)
http://www.barnesandnoble.com/w/the-numbers-game-chris-ander...
to start. I also have a small number of articles I found interesting on my G+ soccer page
It's 15 years beyond 2001 - where is my HAL-9000? There are thousands of times more computing power in my kids' cell phones [insert obligatory reference to cat pictures here] than the computer I shared with 20 other geeks at MIT. The hardware guys have done their jobs - we software guys (for reasons that are probably worth discussing) have not.
My hobby stuff ("it's a hobby until you get paid") is done in Common Lisp wherever possible.
My most personal one was when we were first installing the system on-site at Fort Knox, in a massive building which housed about 90 4-person M1 tank simulators - all networked. 320 soldiers all participating simultaneously. (I also wrote the networking implementation for the simulators, and also helped integrate the custom image generators, which notably contained the first hardware-based texture mapping). The NPC system had Symbolics Lisp machine front-ends hooked up to a multiprocessor system running up to 256 separate CPUs on lightweight OS.
So we installed and booted up the system in the raised-floor machine room (remember them?), which took a long damned time. We were of course concerned about race conditions and memory leaks (the Butterfly was no less tricky to program than any other shared memory box with lots of CPUS). So we dropped down a company of Ivans (Russian tanks), and figured we'd let it run and go get fed (since we were tired and hungry - we might have been there all night - I cannot recall). When we came back into the building after lunch, lots of soldiers were running around, very pissed off, asking "who shot my tank?" and "will you please reset it?" So, I reset the tanks with the magic keyboard sequence, and retreated to the safety of the magnetic swipe-card-protected machine room to check on the Beast.
And lo and behold, there on the digital map display was the Russian tank company, surrounded by the digital corpses of many manned tank simulators.
The Beast was ALIVE. (I had, arguably mistakenly, initialized Ivan to be weapons-free when emplaced. I had also not known the soldiers would joyride through the vast terrain database during lunch break every day, shooting up everything around - none of which would have shot back before the Beast was delivered.)
It was a very Dr. Frankenstein moment.
It is challenging to summarize in a brief reply, and I would not do justice in any event - characterizing the relationships between the evolutionary pressures on software, the limitations of the people and organizations who produce it to handle the attendant complexity of any such system, and the feedback loops which drive the process, etc., is not a 1 paragraph post.
See http://users.ece.utexas.edu/~perry/work/papers/feast1.pdf for instance
My crotchety old geezer, "get off my lawn" take is that minimizing LOC count is vastly unappreciated (as FEAST underscores how increasing LOC count decreases the ability to evolve/change/modify software), and that DSLs are therefore far more promising than are "index cards" and "stories" and "methodologies" to decrease LOC count and thus increase agility