jmorrison · HackerTrans

anno scorsodiscuss

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 [email protected].

jmorrison

anno scorsodiscuss

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.

jmorrison

2 anni fadiscuss

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.

jmorrison

5 anni fadiscuss

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.

jmorrison

6 anni fadiscuss

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.

jmorrison

6 anni fadiscuss

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

jmorrison

6 anni fadiscuss

"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

jmorrison

6 anni fadiscuss

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.

jmorrison

6 anni fadiscuss

https://github.com/McCLIM/McCLIM

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

jmorrison

6 anni fadiscuss

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.

jmorrison

6 anni fadiscuss

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

jmorrison

6 anni fadiscuss

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

jmorrison

6 anni fadiscuss

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

jmorrison

7 anni fadiscuss

MA/NH, USA.

jmorrison

7 anni fadiscuss

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.

jmorrison

7 anni fadiscuss

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?

jmorrison

8 anni fadiscuss

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)

jmorrison

9 anni fadiscuss

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.

jmorrison

9 anni fadiscuss

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.

jmorrison

9 anni fadiscuss

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.

comments