Sacrideo

Its encouraging to be reminded that still not everyone who uses Apple hardware runs MacOS exclusively. https://sivers.org/openbsd http://www.sacrideo.us/openbsd-on-macbook/ However I have not heard any reports of anyone running an alternative OS on iPhone or iPad hardware. With every passing year I continue to think it would be interesting to observe how users would choose if Apple hardware and Apple software were sold separately. Would all users choose Apple software? Expecting to take a little karma subtraction from the thought police for daring to entertain such a nonpermissible idea. Par for the course here and well worth it.

2014? That dates how long I've had this Sidewinder X4 keyboard from my reply there, and roughly how long my experience with the Datahand and Plover has put me off buying another strange or unusual keyboard. Specifically the "Truly Ergonomic"/Cleave keyboard which came up in the last year or so for another round of production, and when I googled it found a review by Xah Lee [1] - who no longer uses it - and this guy I'm sure you'll recognise - https://www.sacrideo.us/not-your-typical-keyboard/ - who seems to no longer use it, and both previously owned a Datahand too [2]. I wonder what the incidence of people continuing using their strange keyboards long term, vs. raving about them and then not using them after a few months, really is. And what happened to the guy who bought my Datahand and paid international shipping to get it. [1] http://xahlee.info/kbd/truly_ergo_keyboard_cleave.html [2] http://xahlee.info/kbd/datahand.html

Then see Aaron Hsu's fountain pen reviews: https://www.sacrideo.us/a-quick-review-of-the-diplomat-nexus/ The way this reads is pretty hysterical. I believe he's on here as user "arcfide".

Aaron's been an academic for most of his career and was working for Dyalog as of 2020 (edit: still there, per [0]). I wouldn't describe his work as "production", since it mainly relates to APL itself rather than some external problem to be solved with it. [0] https://www.sacrideo.us/speaking-at-fnconf-22-dsls-architecture-struct…

> I'm especially fond of the power (⍣) operator Oh boy, I had a mind-melting moment with _inverse_ (⍣¯1). Aaron helped me understand what was going on. He wrote about "Decoding Inverses" here: https://www.sacrideo.us/decoding-inverses/ And that took me from a clunky solution to Dismal Arithmetic (addition): {10(⊤⍣¯1)⍵}∘ {⌈/⍵}∘ {10(⊥⍣¯1)⍵}⊢ 100000 10000 1000 100 10 1 111111 To this little gem: da ← 10⊥(⌈/10⊥⍣¯1⊢) da 169 248 269 (Edit: add code example, fix language)

Thanks! I honestly haven't developed much of Mesh in Mesh, because it's still early in the 'bootstrap cycle' and due to the parse delay issue mentioned above. It's also not nearly as robust to errors as it should be - text editors and traditional spreadsheets allow the user to 'sketch' ideas as discussed by Aaron Hsu [1]. I'd like to stick to a grid for writing 'functional core' logic, but there's potential to use a node interface at the surface of the 'imperative shell', to link up sheets or data feeds (push/pull). I was really impressed by Nodes [2] and I need to spend some time digging into Node-RED [3]. [1] https://www.sacrideo.us/un-structured-programming/ [2] http://nodes.io/story/ [3] https://nodered.org/

Indeed. Reminds me of arcfide's Co-dfns compiler: >I think the first copyright on this compiler is around 2011. That's 6 years for 750 LoC. That's about 125 lines of code per year. >But that doesn't tell the whole story. If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In that time I've added roughly 4,062,847 lines of code to the code base, and deleted roughly 3,753,677 line of code. And there's the real story...It means that for every one of those 750 lines, I've had to examine, rework, and reject around 5400 lines of code. https://www.sacrideo.us/smaller-code-better-code/

R&D Consultant/Developer/Software Engineer | Clinton, New Jersey, USA | ONSITE VISA | Dyalog Labs | Full Time Full Listing: https://www.sacrideo.us/dyalog-is-hiring/ This is an intense, APL-driven position working closely with both Dyalog, Ltd. and one of our major customers as a full-time consultant. You'll be working with both new development and large, legacy application code bases. This position includes extensive training in "the APL way" that I've spoken about in the past, and we're looking for people with the aptitudes and the motivation to go far beyond a simple "code monkey" or software engineer. Our hiring process is very hands-on and somewhat unique, and you should expect to be doing more hands-on programming and exploration throughout the interview and probationary process than just interviewing.

https://www.sacrideo.us/paper-is-dead-long-live-paper-programming/ I think one thing to consider would be actually using paper. The terseness means you don't really pay a 'retyping' penalty.

It's a perennial but: unit tests are more about how you think and rigourously approach a problem than preventing regression. I'd say if you wrote unit tests and then deleted them, your code would be better for it. Indeed, I often don't commit some of the tests I've written in order to write the code! I'll ship some subset of them. It's a notebook. They serve as a form of living documentation for the code and help increase velocity in a build under the right conditions. For example, you do need to know a certain function does what you think it does because the rest of the system isn't even in place yet. You might have to approach this from the outside, via integration, but the speed of doing this is quite slow. Versus a unit test. This is not to mention refactoring! The piece seems to be more about the value of mocking and how far to go with isolation. Which is a slightly tangential issue. I agree that in particular styles of object orientated programming this becomes absurd. This article, which is linked provides a more convincing case, on the grounds that unit testing foregrounds the system as software as opposed to the software as a useful and functional thing in the world, meeting user needs. However, it omits the being about to _react_ to user needs is actually a central party of agility. Unit testing allows maximum reactivity to changing requirements without regressions in the code and makes this code navigable. Changing customer needs means your carefully built…