GregDavidson

I regularly use my Twiddler with my Android phone. It allows me to fully operate all the applications I use on my desktop computer, e.g. Emacs. https://www.mytwiddler.com/

Different oils vary a lot in how inflammatory they are. In addition, heating during extraction and/or aging or storage conditions can lead to cross linking which makes oils very bad for health. With the exception of olive oil's virgin labeling, I'm not aware of any easy way to navigate this health minefield.

You just got a convert! Huge value in sh compatibility. Bash, not so much!

bash, ksh, zsh and a few other shells have the awesome feature that if you call them with a link named "sh" they accept Posix Bourne-shell syntax.

This means you can make them your /bin/sh system shell which will be used to log you in and your login scripts can then set environment variables for your whole session. This feature is something I count on.

Some system shells (not dash) also allow login scripts to export essential shell functions to the session environment.

I would love to use a nicer shell, fish, oilsh, rc, etc. but it's gotta provide this key Posix compatibility. The Posix Bourne shell language is pretty simple. This is not a big ask.

I didn't connect miniKanren to Scheme. I said "Host Language." I did suggest the value of a multi-paradigm host language.

Oops: s/visible/viable/

Hydrogen fuel cells make more sense for aircraft (weight) and larger vehicles like trucks because of scaling (larger tanks are more efficient, etc.) and fleet advantages (depot refueling). It is amazing to me that Toyota has gotten hydrogen to work in cars, but it can't compete with batteries.

By allowing you to use the features of the host language to complement the features of miniKanren. Having good support for multiple programming paradigms is better than trying to make one paradigm fit all needs. Poplog[1] was an earlier attempt to provide such synergies but it failed to gain market share. It's now free software so take a look! The Racket ecosystem is another approach where each module can choose a language with some of them being Prolog-like[2]. [1] https://en.m.wikipedia.org/wiki/Poplog [2] https://racket-lang.org/languages.html

Prolog predicates are not first class values. Data structures are not abstract. Compare both with any modern lisp or better with functional languages. Mapping and filtering is awkward. Arithmetic is awkward. Indexing and search strategies are not under programmer control. Modes are awkward. Cut and dynamic assert of global facts are abominations which undermine logical reasoning. Prolog programmers often write metacircular interpreters to fix these problems which is wonderfully easy but kills efficiency. The CLP examples aren't integrated with Prolog's Horn clause resolution model, they're just libraries with strange semantics. I've been an enthusiastic Prolog programmer since the mid 1980s, attended lots of conferences, read lots of papers, etc. There have been many promising attempts to fix these problems but they've only shown up as non-standard features in specific implementations. It's similar to the "curse of Lisp" - everyone does their own thing and no consensus emerges to move the standard forward. But it could be worse if the standard were "feature oriented" rather than eliminating the limitations and flaws by cleanly generalizing the model. I study new logic programming languages avidly hoping to see a worthy successor to Prolog. So far none quite make it. Mercury might do it if it got more love.

I keep hoping that the amazing engineering feats going into this boondoggle will be applied to applications where hydrogen is visble, e.g. larger vehicles.

I have a long standing love affair with Prolog and frustration for its failure to grow. Prolog has poor features for abstraction and is actually not declarative enough!

Prolog's limitations can be great for starting to get the paradigm but then you hit a wall. (Kind of like standard Pascal!)

Mercury and Curry fix some of these limitations as does miniKanren. Integrating CLP is important yet so far always clumsy as standard Prolog provides no way to reify the environment.

Some LP resources:

https://minikanren.org/

https://mercurylang.org/

https://www.curry-lang.org/

https://en.m.wikipedia.org/wiki/Constraint_logic_programming

https://logtalk.org/

SQL with CTEs is also Turing complete, which is not necessarily ideal. The Rule of Least Power https://en.m.wikipedia.org/wiki/Rule_of_least_power suggests avoiding OP languages. Less powerful languages can be more transparent (great for expressing contracts, e.g. specifications), tractability (proofs, optimization, termination, etc.) and so on. Many systems have been ruined by making them Turing complete.

I want ALL of what Emacs provides, much more than any other "editor" - actually text-centric programmable productivity platform. And I want more than what Emacs provides, e.g. non-destructive editing and collaboration. So yes, there are other interesting editors out there such as Zed. And no, it's not about adding 1 important feature. I'm greedy!

For finding awesome people, the BurningMan community has been the most effective for me, YMMV! For maintaining quality relationships, e.g. with my late wife, the most effective thing was studying NVC together with a small group of friends. We would take 1-2 weeks to explore each chapter of Marshall Rosenberg's "Nonviolent Communication: A Language of Life" along with Lucy Leu's "Nonviolent Communication Companion Workbook". We would practicing what we were learning during the week and meet 1 evening per chapter to discuss our experience. This became an annual practice with a revolving group of participants.

1. I would like higher-level datatypes for key abstractions, such as

(1.1) Marks -> StableRegions

- reference specified text within a buffer

- continue to reference same text despite insertions or deletions

(1.2) Strings & characters -> StringBuffers

- lightweight immutable buffers (no branches or versions)

- able to hold any content a subset of a buffer can hold

- could be StableRegions of an Arena Buffer

(1.3) AbstractBuffers

- immutable buffers + a tree of deltas

- some special delta types for, e.g. indentation

- AbstractBuffers support transactions and versioning

- can support collaborative editing

- specific versions can be written to textfiles

- all versions can be stored in git or in relational database

2. Use WebAssembly instead of a specific programming language.

- This was the vision for Guile.

  - Scheme one of several languages.
  - ELisp supported but Emacs port efforts keep failing!

- The Racket ecosystem has captured this pretty well - if only it supported ELisp!

3. Prefer languages at least as simple as Scheme, but with monotonic semantics!

Non-mutable operations would appear as transactions appearing as branches/versions.

An editing session would automatically follow the latest transaction in the current branch.

Concurrent edits of the same "file" create different branches as with git, et al.

4. Separate monolithic Emacs process into SessionProcesses, DisplayProcesses and WorkerProcesses.

Multiple DisplayProcesses would allow for tightly-coupled collaborative editing. A WorkerProcess would interface buffers with processes, files, git repositories, etc. on a specific account@host giving functionality like Tramp. A user would start with one DisplayProcess connected to a SessionProcess. A SessionProcess would provide the interface between DisplayProcesses, WorkerProcesses and any co-SessionProcesses of collaborators. WorkerProcesses could be scripted without any other overhead.

Thanks to influence from Dijkstra, Wirth, et al in my formative years, when I program I construct a (usually informal) correctness proof simultaneously (well, kind of interleaved) with my construction of the code. The two constructions assist one another and converge to procedures which solve the required problem. I find this approach more productive than an ad hoc (hack & debug until done) approach. The correctness proof supports the correctness of the solution and the solution is usually more elegant (simpler, etc.). I annotate the code with elements of the proof to assist with maintenance. I think that most programmers do this to some degree, i.e. have an internal argument about why what they're doing will work and include some assertions and comments, etc. When I'm given some hunk of complex procedural code lacking strong types, preconditions, postconditions, invariants, arguments bridging such, etc. I don't find it very useful. Proving the correctness of complex ad hoc code is often harder than just solving the problem again from scratch. There are AI automated reasoning systems (based on incremental theorem provers) that can help me write good code and I follow the evolution of such tools. So far, the code I'm seeing from llm systems seems like a maintenance and reliability nightmare.

The UCSD P-System is the ancestor of many later byte-code VMs: https://en.m.wikipedia.org/wiki/UCSD_Pascal

My life is in OrgMode structured plain text files which are themselves managed by git along with scripts for managing link integrity. This works fairly well but I dream of replacing all of that with relational databases and knowledge representation systems. So far, every fancier system I've used or built has eventually failed, but I'm working on yet another fancy system built on top of Postgres for stability.

I could really use a nice open and modular low power home office server with ecc ram and (optionally?) suitable to be a file server. It would be awesome if many of its components could be swapped with the laptops.

I'm more interested in how they're automating the manufacturing of their robots. Robots making robots driving the learning curve.

One of the disappointments of living in the USA is that when I buy that Gouda imported from the Netherlands, etc. it's actually a special (and not very good) product made for the American market and not sold in Europe. It's a guaranteed fake! Part of why our products are often poor is we can't get the real thing to compare!

Inline SQL functions so I can modularize my code without a massive performance penalty. Foreign key references to system tables so I can reliably store, e.g. function oids.

I recommend studying the short book "Treat Your Own Back" by Robin McKenzie and also finding a physical therapist familiar with his techniques. I was in similar distress and it was fairly quickly resolved by these techniques and I have also observed these techniques being effective for several other people. Physicians in the US are not trained in physical therapy yet physical therapists in the US are only allowed to apply physician-prescribed treatments! This can lead to some bizarre Catch-22 situations until you find a highly experienced physical therapist who can work with you. Checking if they use the "McKenzie methods" is a touchstone.