Search "dungeon minesweeper", there are several in that genre. [Oof, now I'm stuck playing Dragonsweeper instead of working.]
68 karma · joined August 31, 2008
[ my public key: https://keybase.io/cben; my proof: https://keybase.io/cben/sigs/JGI5fI4zkb-2MZpVugiAm-7WyT2s9AWqqNtSYT5QTIg ]
I suppose a "reasonable person" should now conclude that expletives are only part of speech with a reasonable expectation of privacy. /s
[fwiw if I were a human flagged to review these texts, I'd likely report them. My problem is with building huge systems marketed as almost a tool for thought, and then exposing these almost-thoughts for unlimited copyright case retention, for human threat review, and god knows what else.]
[1, 2, 3].inject { |a,b| a + b }
numbers.inject(0) { |a,b| a + b }
numbers.inject(0, :+)
If you mean being able to a generic `list<foo>` type (whether by C++ templates, macros, or good old void* casts), it's more than that. The benefit of non-intrusive is being able to create/manipulate/pass around multiple collections pointing to same payloads, without disturbing the payloads or the other collections in any way¹. That makes it easier to return and manipulate collections functionally (both in the narrow immutable sense, but also in the wider "treat collections like _values_ sense)... The deepest benefit arising from that I suppose is code modularity: different code areas need not be aware of each other's existence.
That all obviously comes at some tradeoff to performance. By definition, not having a full picture of the pathways your data travels means you can't choose the fastest representation!
¹The cheat is GC. For multiple unconnected collections to point to same payload, you need ref counting, or mark&sweep or similar to control its lifetime. Technically, GC does disturb the objects it's tracking (though that's well abstracted from other code).
However, you're largely right that specifically linked lists are rarely a good choice for non-intrusive collections => Arrays usually beat them, and if not then hash sets. (LISP & ML & Haskell do stick to lists for tail sharing — a choice which is arguably outdated by growing CPU / mem random access gap. I suppose Clojure's persistent vectors are an improvement.)
You could counter "if only performance was legally included in the contracts, a better site would be delivered." Maybe, but my point is there is big difference between internal "req. gathering" that informs work while everyone is long-term motivated for good user experience anyway, vs. external contract/deadline gathering for almost adversarial "deliver worst thing that passes and walk away" settings. Brushing both under same wording feels insufficient to me.
The other part is extreme optimizations, from I/O and OS aspects to CPU, both asymptotic complexity (from scratch NFA regex engine), concrete complexity (rust, SIMD) and ad-hoc opitimizations for statistically common uses like fixed strings...
Then there are some "product" choices driven by performance insights, e.g. no line numbering, defaulting to non-deterministic unsorted output order — these go against most programmers' intuition for "ideal tool I'd like", but turns out the speed gains are significant and what I really like is how fast it is :-)
Both usability & optimizations are described in depth by the author in https://burntsushi.net/ripgrep/, which is one of the best perf. readings ever, highly recommended.
"Unfortunately I cannot show it to you," replied the master, "because I burned it in my stove."
"I'm sorry but I don't believe you," said Woland. "You can't have done. Manuscripts don't burn." He turned to his cat. "Come on, Behemoth, let us have the novel."
– towards the end of The Master and Margarita. In the battle against both censorship & entropy, recovering a 2kyo text which was considered forever lost is an incredible victory.
P.S. I'm reminded of the short story "My Father's Singularity" (https://clarkesworldmagazine.com/cooper_06_10/) wrt. the gradual way change accumulates until a significant gap has grown.
I haven't tried reverse-engineering one yet, I hope at least some of these are hackable? Conway's life would certainly be one fun use, but custom games are totally something I'd want to make too!
Are these actually membrane or are there some switches there? I assume membrane, if only based on the dirt-cheap price. Anyway in combination with lighting up + sound the feedback feels immersive enough, it's definitely more fun than poking a tablet.
- Pine64's general model is selling cheap, quite-good, not-fully-documented hardware with expectation community software will(?) grow around it. Some of their products grow fantastic support, some less so, some remain "dev kit" — do your homework.
But then on subsequent interactions between a git client that made a shallow clone various time ago and the git server, it's AFAIU actually expensive for the git server to compute the portion this particular client doesn't yet have.
Intuitively, and very hand-wavingly, I suspect things could be improved by:
(1) clients relaxing "exact depth" requests to "give me approximately N days of stuff, over-sending being OK", and server relaxing "minimal traffic" to roughly map time ranges to whole packfiles — CPU/traffic tradeoff. (2) allowing servers to under-send too (makes (1) tradeoffs easier), by client asking for missing parts right away and/or later — needs on-demand fetch ability to be transparent to user. With "promisor" mechanism in "partial clones" this sounds more realistic? (3) storing history/trees/blobs in entirely separate packfiles(?) I suspect recent years work on bitmaps & MIDX move in this direction, only less naively?
I'm not saying Git can scale as well as a DB, but I do feel we sat on an effectively frozen Git format & protocol for a ~decade, and are now exploring more of the design space so hope future will be less clear-cut...
And specifically, partial clones remove the hard "fully offline vs. centralized" dichotomy we long clinged to. Assuming you stay online (necessary anyway if you consider HTTP/DB), things that used to be up-front UX decisions can now be matters of perf tuning!
* The most dramatic win is if you had to fetch info from every package's separate repo, like Go did. Then, a central DB/caching proxy can build global indexes, unlocking huge wins, no question. It's like "1+N" issues. However, most examples other than Go in the article talk of a single Git repo already storing a global view (still leaving opportunity for custom indexing and querying).
That's an economic win sure, but it's tragic if we fail to unlock more of their flexibility for "end users"! IMHO that's the biggest unsolved problems of computer science: that it takes so much professional learning to unlock the real potential (and even that fails us programmers much of the time! How frequently do you say "I'll solve it myself" and the time invested is actually worth it? In the words of Steve Krouse we've not quite solved "End-programmer Programming" yet.)
I do want FOSS to follow through and offer live inspectors for everything, but no, I no longer believe users should "learn to code" as the salvation. We're nowhere near it being worth their time, we actually went downhill on that :-( Conversational AI and "vibe using" will play a role, but that's more like "adversarial interoperability", doesn't cover what I mean either.
I want cross-app interoperability to be designed in, as something everyone'd understand users want. I want agency over app state — snapshot, fork, rewind, diff etc. I want files back (https://jenson.org/files/), and more¹. I want things like versioning and collaboration to work cross-app. I want ideas and metaphors we haven't found yet — I mean it when I call it unsolved problem of CS! — that would unlock more flexible workflows for users, with less learning curve. The URL was one such idea - unlocking so much coordination by being able to share place[+state] in any medium.
I want software to be malleable (https://malleable.systems/) in ways meaningful to users. I want all apps to expose their command set for OS-level configurability of input devices & keyboard shortcuts (Steam Input on steroids). I want breakthroughs on separating "business logic" from all the shit we piled, so users can "view source" and intervene on important stuff, like they can in spreadsheets. (I want orders of magnitude smaller/simpler shit too.) I want the equivalent of unix pipes combinatorial freedom² in GUI apps. I want universal metaphors for automation, a future not unlike Yahoo Pipes promised us (https://retool.com/pipes) though I don't know in what shape. I want previewable "vector actions", less like record-macro-and-pray-the-loop-works more like multiple cursor editing. I want more apps to expose UX like PhotoShop layers, where users are more productive manipulating a recipe than they'd be directly manipulating the final result. (https://graphite.art/ looks promising but that's again for visual stuff; we need more universal metaphors for "reactive" editing... I want an spreadsheet-like interface to any directory+Makefile. I want ability to include "formulas" everywhere³.) I want various ideas from Subtext (https://www.subtext-lang.org/retrospective.html).
I want user access to the fruits of 100% reproducibility, including full control of software versions (which are presently reserved to VM/Docker/Nix masters). I want universal visibility into app behavior — what it accessed, what it changed on your computer/the world, everything it logged. Ad blockers actually achieve 2 ways to inspect/intervene: starting from the UI (I don't want to see this), and starting from network behavior (I don't want it to contact this), and both give users meaningful agency!
¹ I highly recommend following https://alexanderobenauer.com/ for his "Itemized OS" research ideas. His shared work with Ink & Switch https://www.inkandswitch.com/embark/ is a tantalizing demo too. ² http://conal.net/blog/posts/tangible-functional-programming-... was intriGUIng but still too nerdy for fitting naturally into end-user workflows. (But if you like such nerdy, https://www.tandisgame.com/ is somewhat related & fun) ³ https://calca.io/, https://worrydream.com/ExplorableExplanations/
I guess https://www.folklore.org/Calculator_Construction_Set.html is the closest you get with a compiled language :-)
P.S. https://web.stanford.edu/dept/SUL/sites/mac/parc.html has good historical context on that visit(s)
* Linux live USBs can be a nice safe intro to such power? Give them 2-3 with differnt-looking distros (even if cosmetic ;-), tell them "try this for a day, if you decide which one you like it you can install it permanently". Hmm, I should try this with my kids!
Data structures, control structures/message passing, functional programming... It's really "Scheme in Scratch clothing" under the hood.
In particular, its "build your own blocks" facilities are powerful enough (including macros i.e. custom control structures receiving "body" arguments as unevaluated lambdas) for you to build any scaffolding they need to focus on concepts you want them to learn at this stage.
¹If you don't have much time to sit with them, Scratch may win on "go find tutorials on youtube".
Integration was not perfect, but it does create a json .paper file containing a url. But at least it makes you aware the doc exists every time you look at the folder.
Alas, with Paper desktop & mobile apps being deprecated, that's increasingly useless :-( Will the main app at least take over the ability to [double-]click these .paper docs to open them in a browser?
One sweet quality of RPi this lacks was being unbrickable — the entire state was on SD card; screw up and you can just write a new card. (Recent RPis complicate that with an a boot flash). But by now I've bricked enough RPis by electrical damage — including an 400 — to not be as excited about that :-]
I do agree with your analysis. All I'm saying is if one is considering a competitor, the X4 with x86 running mainline linux might be a safer bet than most less-documented ARM boards...
A pragmatic pedagogical thing I love with Snap! is the ease of creating custom blocks, including macros / custom "C-shaped" control structures. If you have some time, this allows you to "scaffold" helpers that will allow him to create interesting stuff while focusing on things you want him to learn and hiding issues you don't.
* Example: I wanted to teach rendering a custom costume with e.g. health bar or text label. My son is already familiar with Snap!'s turtle-drawing primitives that can render lines & text but there was an impedance mismatch — you draw on the screen, and it does support snapshotting all current drawings to create a costume, but using that involves some careful save-and-restore of much global state (e.g. pen color). I built him a "draw costume" block that takes a body of turtle-drawing commands and affects only current character's costume. If you ask me, Snap! should have had similar API built-in; but what's more important it was easy for me to add one that looks and feels as-if it was builtin. This way I can decide what I want to teach ("you can compute how you appear") and what is incidental complexity.
In retrospect, me unhappy + them unhappy = time to actively seek moving (which they'd still support back then); I stayed into a spiral of feedback => motivation => productivity => ... eventually I was laid off. I can't know how moving would have worked out but I regret not trying. [OT: and other passivity, not taking feedback seriously enough, sticking to WFH despite evidence it was challenging for me.]
That said a fixed-factor mutiplication can probably be done faster AND [more] precisely as a sum of some shifts. Or many other ways with a lookup table.
They also mention _approximate_ cm/inch conversion is doable by double shift on the Fibonacci scale - if golden ratio was exactly 1.6, its square would be 2.56, but actual phi² = 2.618 which is quite bad approximation for 2.54...