jmorrison

I have an admittedly resource-intensive, self-hosted, podman/docker-based slippy map product prototype. Briefly, it incorporates the nominatim geocoder, the valhalla routing engine, a map tiler, and PostGIS. One of its front-ends is https://github.com/nilsnolde/valhalla-app. If you are interested in participating in a beta test, please email me at my work address jm@symbolic-simulation.com.

Both SGI (who had no hardware texture mapping at the time) and 3dfx were explored at the time DARPA SIMNET was being developed. Delta Graphics (Mike Cyrus' and Jay Beck's company - of the Cyrus-Beck line clipping algorithm fame), which did have hardware Z-buffer texture-mapping, were the incumbents, and was fielded. Gary Tarroli personally visited BBN for a chat, but I wasn't involved in that. If Abort-Retry-Fail is interested in the history of SIMNET (in addition to the first hardware texture-mapping fielded, first AI NPC, etc.), there is a lot of info available. Email me and I can provide the info.

You say, correctly I believe, "for virtual reality to count, there must be high stakes, real consequences..."

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.

Not sure that's it. Consider the difference in motivation between trying to figure out how: to get people to click on advertisements; vs prevail when people are trying to kill you.

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.

I dimly recall one was supposed to figure out what TECO would do when one typed one's name in (followed by the double-escape). Never did figure out what mine would do - was too afraid to try.

My worry re: #7 is that this, like the US volunteer military, decreases the cost (in bad PR due to human cost to one's own troops) to the point where starting a conflict feels relatively risk-free. Which would lead to lots more of them (just like the US is now).

"Technical Debt" seems a trite, overly simplistic, if not downright misleading metaphor. No other engineering discipline uses metaphor (as does software "engineering"). They all use analysis.

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

It appears to be hard to predict the effect of the introduction of even a single weapon/platform into a complex conflict which consists of many, qualitatively different weapons/platforms. One of my career-defining "Aha" moments is described on page 19 of https://www.iitsec.org/-/media/sites/iitsec/link-attachments... in the section entitled "Forward Area Air Defense (FAADS)."

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.

https://github.com/McCLIM/McCLIM

Under active development. Turtles all the way down. Runs on Linux, Raspbian, etc. Runs under (at least) SBCL & CCL.

I am using CL in pre-production to avail myself of its ability to compile & load at runtime. I haven't used Lisp in production in a while (dating back to Zetalisp!), and the decades of perspective lead me to some surprising conclusions. I have encountered neither ecosystem issues (due to quicklisp) nor community issues (due to "addition by subtraction" in the Lisp online community). However, I have encountered plenty of issues due to dependency-hell issues in the non-CL software I'm using: Python 2 vs 3 vs Python package incompatibilities; Python 2 vs 3 Ansible/Vagrant container/VM/distro incompatibilities; node.js vs npm vs inter-node-package version incompatibilities; etc. CL has been gloriously stable, and given me substantially less heartburn and fewer headaches.

At upper-left, just under the picture of the book cover (and above the "Follow the Author"), there are a few thumbnails and a "See all Images" hyperlink you can click to get the typical pop-up gallery. You can see even more at his site https://www.antarcticaarts.com/books/WWW.html

A good and talented friend of mine produced a similar book: https://www.amazon.com/Willoughbys-World-Wonder-Stephen-Barn...

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.)

Would you please post the model numbers? I am overdue to upgrade. Especially interested if the motherboards have multiple LAN ports. Thanks!

MA/NH, USA.

https://drive.google.com/file/d/18p8-ip98iev9LW-Gtf0TMOJbfgY...

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 have one whose enclosing/host Mac II no longer boots (I changed the CMOS battery, which was the cause last time, but no joy). No local Apple/Mac repair shop I can find will even look at it. Does anybody know a boutique, antique computer repair service?

When, oh when will we ever finally unlearn "worse is better?" It's hard enough writing good code without having to fight your tooling (non-orthogonal, non-homoiconic, non-malleable, non-backwards-compatible languages, some with header files propagating changes upwards and breaking user code, and some with fascist type systems causing combinatorial explosions of containers and factories, ugh)

Regarding (0): I am not sure what mechanisms for penalty would be better way than those currently in play (e.g., disuse/cloning in the case of open source, bankruptcy in the case of closed source, etc.).

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.

Sorry to not understand exactly what you mean by those two statements. Would you please clarify?

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.

Haven't read anything ever, including the subject of this thread, and including any number of language-advocacy opinion pieces, and including software development methodology opinion pieces, that in any way compares with the empirical data-based work of Manny Lehman (R.I.P.).

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.

I kid you not that there are such things as "proposal schools" and proposal-preparation companies that teach you how to win as low bidder by being "minimally compliant." Then, when the customer finally understands what they are (not) getting, you can hit them up for "change orders" that have to be negotiated. Bottom line strategy is be the low bidder at all costs, and recover your buy-in costs and and also make profits from change orders.

The real villain is letting CPFF (cost plus fixed fee) contracts rather the fixed-price contracts.

Thinking out loud:

(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.

I highly recommend "Charlie Munger On the Psychology of Human Misjudgement."

PDF transcription here http://www.rbcpa.com/mungerspeech_june_95.pdf

Explains a lot (he says, during Presidential Election season in the US)

I am a longtime amateur player, and a youth club coach of about 15 years, having assistant coached a US National Youth Futsal champion team. (I also played pickup after work with PG in Cambridge Back In The Day - I wonder if he still plays?) I would be cautious, however, in generalizing the article's first major point (the game as a simulation) from elite players to garden-variety players. Elite players must, of necessity, maintain and adhere to a perhaps game-specific strategy during the organized chaos of a match. I find, as a coach (vs player), without the distraction of a tired body, tired mind, and somebody trying to kick me, that it is much easier to keep this strategy at the forefront of my mind. My skills are also not so good that they require little conscious thought. So I think an elite player (as I am not) may, in fact, benefit by acting as a coach in these games. The second major point is about data influencing the real game. This is undoubtedly true. Soccer is a very mathematical, probabilistic game at heart, and there are many readily available resources for the technically inclined soccer enthusiast. I would recommen

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

https://plus.google.com/u/0/101713908985994656356

Worked at BBN from 1983-1990, at the tail end of the NCP->IP/TCP "transition." Terrifically interesting stuff to work on, with loads of terrifically smart people to learn from. One of the legendary recruiters there (rest his soul) referred to the place as a "halfway house for failed MIT & Harvard PhDs." A magical place, and I feel lucky to have fooled that recruiter into letting me get hired.

I have an old MacIvory (Symbolics board set housed in a Mac II) which doesn't want to boot anymore. IIRC Googling indicated that the Mac IIs are like cars - they won't turn over if the motherboard battery is dead. I changed the battery - no joy. Anybody have any recommendations, whether for a repair place (New England, USA) or further DIY things to try?

I must confess to having a more cynical view than that. I dimly recall some quotation (I cannot recall enough of it to Google it successfully) about somebody being naked, covered in dirt, surrounded by flies, and thinking it's normal. I concur that it describes our current state of computing, and that opinion is based upon the contrast between the non-mainstream technology I've been privileged to use and mainstream technology that circumstances have (more or less) forced me to use.

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.

In the late 80s I worked on (to the best of my knowledge) the first multiplayer/networked AI-based NPC system for DARPA SIMNET https://en.wikipedia.org/wiki/SIMNET. So M-A-N-Y stories!

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.

I was going to reply with a link to Manny Lehman's "FEAST" publication page, which (tragically - and I am not being cavalier) has seemed to disappear following his passing. I highly recommend chasing links starting from his Wikipedia page: https://en.wikipedia.org/wiki/Manny_Lehman_(computer_scienti...

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

Because in both the doctor and professor cases, the knowledge base is curated, history and experience (at least - I was tempted to add "and judgement learned therefrom") count for something. Alan Kay is right when he says software is "pop culture," and its "disdain for history is what makes computing not-quite-a-field."