Rich_Morin

"With the advent of the new Automatic Programming systems, we'll soon have no need for programmers." -- written about a predecessor of Fortran.

My own programming career began in 1970, and included an intriguing visit to Stanford's AI center. I've been an avid fan boi of AI ever since. Currently the folks I'm watching are the Thousand Brains Project, an effort to replicate a network of cortical columns and support services.

In any event, I've written code in a variety of languages. My current favorite is Elixir, because it offers fewer booby traps and far more capability than any others I've seen. However, my take on languages is that they let you work at a comfortable level of abstraction.

Still, I'm delighted to have an earnest pair of assistants (ChatGPT and Codex CLI) who are able to discuss ideas and issues in my native language. They can also help me translate my rough notes and speculations into (apparently) working code, using whatever resources are available (eg, languages, libraries). Indeed, one of the hardest things to do is to imagine what they are able to do.

I suspect that there are at least a few nerdy nine year olds who are grabbing onto this. I also suspect that there are folks who will do unfortunate things with this capability. Should be interesting...

I'd like something like this for exploration of graph databases such as Neo4j.

The rectangular array is the basic data type for APL. Until fairly recently, the BEAM had no reasonable implementation of this. However, it seems like Nx's tensors might serve...

Breaking lines at logical boundaries in the "source code" makes it easier for me to see the structure of the text. It also gives me the ability to see the text in two different layouts; this often lets me spot errors which would otherwise slip by.

This is sort of a "generative" (aka property-based) approach to testing makefiles. So, I'd like to see a variation that can find a minimal failing subset of the makefile rules, as in QuickCheck:

In QuickCheck, assertions are written about logical properties that a function should fulfill. Then QuickCheck attempts to generate a test case that falsifies such assertions. Once such a test case is found, QuickCheck tries to reduce it to a minimal failing subset by removing or simplifying input data that are unneeded to make the test fail. -- https://en.wikipedia.org/wiki/QuickCheck

Nicely written article, but it seems to conflate "what it should do" with "how it should do it". So, for example, it talks a lot about optimizations (which feel like implementation decisions).

I'm not saying they aren't important in this DB, but they might not be as relevant in another. For example, Datomic doesn't go this direction, but its ability to avoid read locks on long-running queries might dance around many optimization issues.

FWIW, I like the use of Cypher, which I first encountered in Neo4j. It has always felt pretty intuitive to me, though I don't know all of its limitations and strengths.

Life hack: weigh cartons of eggs (Jumbo and any other sizes), then calculate the cost per ounce (or whatever). Jumbo eggs are often a real bargain (but you may need to adjust recipes).

The article consistently talks about "time of day" (e.g., morning), but it could be that "time since arising" is more relevant.

BASIC, Forth, Logo, Python, and Ruby are all reasonable starter languages for children. Although Python's semantic indentation can be a hassle for blind users, this isn't an insuperable problem. And, given Python's immense popularity, it is likely to be around and very usable for a long time.

The other day I wrote a fan letter to a developer who has been maintaining a popular and useful library for several years. In his reply, he said that this was the first fan letter he had ever received. I think we need to show Open Source developers a lot more love and a lot less snark...

@cabal Great project! What tooling do you use to assess and improve the accessibility of your ebooks?

A wonderful vignette. Note how Einstein structured the dialogue and interaction to find out the extent and nature of the problem, then help the listener.

On an only vaguely related topic, I strongly recommend this video by Evelyn Glennie, a deaf percussionist:

How to truly listen https://www.youtube.com/watch?v=IU3V6zNER4g

This seems like a very cool idea. The concurrency model in Erlang/Elixir/... eliminates the issues of shared mutable state and the supervision trees catch unexpected data-related problems, etc.

FWIW, the Elixir/Phoenix community seems to have settled on LiveView, which performs most of the processing at the server, assisted by some small JS routines which handle updates, etc.

Clay- I strongly encourage you to find a way to make your writings available once again. Many of the things you wrote are as true today as they ever were and the rest are valuable as historical reminders. FWIW, GitHub Pages might well be the simplest and best solution.

I just tried out this search engine and was very favorably impressed. It was quite responsive (though that could be affected by demand) and gave good results. I really like the lack of goo (e.g., ads) and the spare, clean presentation. I think it might be a great search engine for visually disabled users who rely on screen readers.

We chop them up coarsely, sprinkle on bits of feta and maybe basil, then add a bit of nice olive oil and stir.

My own preference would be for the pmOS project to pick a target subset of the devices on the Community and (perhaps) Testing lists. These would be chosen for a combination of criteria. For example (ducking):

- How close are their ports to being complete?

- Are they based on the aarch64 architecture?

- How many of them are economically available?

- How easy will it be to install pmOS on them?

With this subset defined, the project could focus on making these devices available to relatively naive users. There could be FAQs and HowTos for installation and setup, specific forum and wiki pages, etc. The knowledge gained in this sprint could help the project to develop an approach for the greater, long-haul effort.

The article closes with a discussion of "true interactive development". I was particularly interested in this and wondered how IEx (Elixir's REPL) compares to Common Lisp's. So, I started this thread on the Elixir Forum: https://elixirforum.com/t/hell-is-other-repls-how-does-iex-c...

Although it's early days, José Valim and some other folks are working on adding AI-related capabilities to Elixir and the (Erlang) BEAM. See "Introducing Nx" (https://www.youtube.com/watch?v=fPKMmJpAGWc) for an intro.

Given that they already have a robust Actor model as a base to work from, it occurs to me that they may be able to use some of Ray's ideas as they go along...

Burt Herring, the author of the Fast-5 diet book, contends that doing physical activity while fasting causes the body to reach into fat reserves for energy. This seems plausible to me, but IANAD.

In any event, I've been able to lose 30+ pounds over the past several months by going for regular walks and (mostly) refraining from eating anything with calories until evening. Interestingly, I also find that my food intake capacity at dinnertime seems to be less than it used to be.

The Lispers contend that the use of parens is merely a surface detail which the reader can get past with a bit of effort. This is clearly true for some people, but I don't believe it to be generally correct.

Much of what we do when reading (whether code or text) happens at a low level, way below conscious thought. This allows us to, for example, skim a list and spot the desired entry without having to think about each one. Formatting and punctuation provide guideposts that help in this process.

Similarly, the syntax of most programming languages contains a wealth of punctuation characters. A well-formatted and idiomatic program can be skimmed quickly, without the need for understanding each symbol.

Lisp, in contrast, removes all of these guideposts. So, in order to skim a Lisp program, the reader must understand at least the general nature each symbol s/he encounters. For example, a cond is a much different operator than an add.

So, although I like the benefits of Lisp, I dislike the syntax so much that I have avoided using it for decades. Fortunately, José Valim has created a language (Elixir) which provides Lisp's benefits but uses a syntax (mostly Ruby) which I find appealing.

I really wish Ubuntu Mate would come out for the RasPi 4.

While running scripted `apt-get -y install ...` commands, I occasionally encounter packages that require answers to configuration questions. In some cases, the "-y" option handles the problem, but in others it does not.

I've thought about going back to the developers of the packages, asking them to provide workarounds based on environment variables, etc. I may still do this, but it seems like Expect might provide a handy workaround in the meanwhile.

However, I'm concerned that the mock-GUI dialogs that these packages use (using terminal graphics) might make it hard for Expect to interact with them. For example, some of these dialogs want the user to navigate through a menu, select an item, etc.

Suggestions, anyone?