AdieuToLogic

> Judgemental much?

Not often, but yeah... I did on this occasion.

> Anthropic's goal is to commoditize intelligence.

And Google's original goal was to organize the world's information.

How did that turn out?

> I'm curious what people are sending to Claude that is so secret.

When Claude is used in a professional setting, any or all of:

  Proprietary intellectual property (a.k.a. system code)
  PII[0] of the employee, customers, or both
  HIPAA[1] data known to a system
  Internal communications not meant to be publicized
  Sensitive data, such as SSH keys and the like

Pretty much anything on a machine which uses Anthropic/OpenAI native tools is a candidate to be compromised really.

0 - https://en.wikipedia.org/wiki/Personal_data

1 - https://en.wikipedia.org/wiki/Health_Insurance_Portability_a...

The simulated dialog you have provided is very much representative of what many of us have heard first-hand. However, I disagree with:

  Most businesses don’t care about later risk or any future 
  planning beyond the quarter horizon, they’re not concerned 
  about how it will effect their performance in 3 quarters or 
  lead to instability or issues, those are future problems 
  for a future person and we’re here for money now.

Businesses care about "later risk" and what it implies.

Individuals within an organization do not unless it will specifically affect their bonuses/promotions.

> If your house burns down because of known flaw in Microsoft Windows they are not liable (well as far as EULA let’s them, you can most likely still sue them).

A EULA does not obviate responsibility of a company for its products. Continuing with your example, while it may be very difficult to prove a known flaw in MS Windows was the cause of your house being set afire, if one had said proof, a EULA would not absolve Microsoft.

This reminds me of the old joke[0]:

  There are 10 kinds of people in the world.
  Those who understand binary and those who don't.

0 - https://www.gnu.org/fun/jokes/10-kinds-of-people.html.en

> What is "await" if not a synonym for "suspend"?!?

The `await` keyword in most languages is not a synonym for suspending thread execution so much as it is an effectual attempt to replicate the functionality of `coreturn`[0]. To wit, if an underlying `Future`/`Promise` has completed before the `await` instruction is evaluated, the thread executing same will not be suspended.

0 - https://www.euclideanspace.com/maths/discrete/category/highe...

Like many things in complex projects such as operating systems, accepting PRs is not as simple as "if this one use of a tool works, why not accept it?"

Why? Because the onus of determining fitness of purpose and correctness has to be done by someone. So if a PR is buggy and/or lacking in test coverage, but was made by a contributor making an honest effort, then experienced contributors can help educate the person as to what is missing or needs to be considered. Ultimately, this is a form of apprenticeship.

Contrast that with someone using an LLM to produce the exact same PR. Who can be mentored? Who can be referred to materials which can deepen requisite knowledge?

> has anyone found a good way to improve code quality? just wondering ...

  - keep prompts focused on atomic tasks.
  - use expert prompting[0] when possible.
  - require coding agents to verify changes.
  - require coding agents to create/update unit tests with 100% coverage.
  - use git to commit/revert atomic tasks manually.
  - leverage planning capabilities to review instead of recover.
  - consider using something like Karpathy guidelines[1].
  - leverage Constraint Programming[2] concepts when
    formulating prompts.

0 - https://arxiv.org/pdf/2305.14688

1 - https://github.com/multica-ai/andrej-karpathy-skills

2 - https://en.wikipedia.org/wiki/Constraint_programming

> Optimizing for fewest LOC is probably slightly more bad than more LOC, and both are bad for the same reason - it makes it harder for humans to interpret and understand ...

Concision begets perplexity.

;-)

> It's more like if someone dumped lab-grown diamonds on the side of the road that are virtually indistinguishable from mined diamonds.

Equating LLM generated code to "lab-grown diamonds" is disingenuous at best.

> Someone would be happy to take them and [be] none the wiser.

If the quality of GenAI PRs were equivalent to those authored by experienced contributors, then there would not be as many GenAI PR bans in FOSS operating system repositories.

> The only thing I got out of this article is that both parties + the F500 need to be destroyed.

Destruction is easy, as we are all witnessing.

Making things better is hard. It takes commitment to incremental change, often having to overcome setbacks, and accepting that the product of democracy is inherently nonlinear.

Democracy also demands that its participants understand that most of the time what each individual wants to be, will not be exactly as they envision, since that would be autocracy.

> A separate document explaining how a system works can go out of date.

Good documentation does not explain "the how", it captures "the why."

> I am convinced that there are paid posters on here.

Maybe. More likely is there are AI bots used to proliferate messages much cheaper than "paid posters."

> Why would anyone defend a billion dollar corporation so vehemently and not earn a single dime?

Because some like the products made by said billion dollar corporation?

Because others like to be contrarian?

Because not everyone is motivated by being paid?

Maybe, just maybe, people are different and have differing motivations not easily reduced into being "am I getting paid for this or not."

>> Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.

> I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier.

Here is my corroboration. Apple publishes XNU to the world in this repository:

  https://github.com/apple-oss-distributions/xnu

There is no such publication of the GUI frameworks required by macOS programs.

> I do think there is an argument to be made that Win32 was more straightforward ...

I did not make that argument. Instead, the position I hold regarding Windows is:

  ... an independently derived emulation layer is
  possible (not easy, just possible) ...

When an organizational goal is to sell devices, instead of operating system licenses, there is no need to engineer portability within the OS as the target hardware is well-known. This is a luxury MS-Windows never had, as its goal has been to run on as many disparate devices as plausible. Thus the "intrinsic portability" I referenced.

In fact, you have made my point for me:

> ... while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used.

Microsoft's business model regarding Windows is to sell an operating system capable of running on as many devices as possible.

Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.

The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom of assuming device capabilities/features always present for any given release.

This is because understanding is an intrinsically personal experience. To convey it to others is to choose words, phrasing, and sentences which best express what is in one's mind.

Call it "intention", call it "understanding", call it "effective communication." The lack thereof is obvious and easily identified.

> Most success stories of LLM coding are ports. Because someone already did most of the job with the original code, sometime even twice if we count the tests.

Another way to phrase this is:

  Because someone already thought about the problem and what 
  needs to exist in order to solve it.

> What allows Wine to run so many Windows apps that there's not an equivalent for MacOS? Is it lack of interest? Is it a technical thing?

It is a technical thing.

The XNU[0] kernel, which underpins macOS and is detailed by the exceptional book "Mac OS X internals"[1], can theoretically run on many x86 and/or ARM machines. However, the issue with running macOS apps via other operating systems is not the OS, but instead are the GUI frameworks expected (i.e., Carbon[2], Quartz[3], etc.). These frameworks are intentionally written for Apple hardware/macOS distros. Which makes sense when viewing macOS as a selling point for selling Mac's.

0 - https://en.wikipedia.org/wiki/XNU

1 - https://openlibrary.org/books/OL17205558M/Mac_OS_X_internals

2 - https://en.wikipedia.org/wiki/Carbon_(API)

3 - https://en.wikipedia.org/wiki/Quartz_(graphics_layer)

There's no doubt that hand-written language adapter libraries are less noisy than those generated by a tool such as SWIG. The thing is, debugging tool-generated adapter code is typically more category-based than individual use-case based.

IMHO, both approaches have merit depending on the situation. I lean towards using SWIG until and unless the situation warrants a hand-written solution due to the boilerplate nature of these types of libraries.

> There are reasons all those Py libraries with C code didn't just do it in SWIG.

And those reasons are?

> Python's strength is that it's easy to make C libs work in it.

SWIG[0] makes working with C libraries trivial for over a dozen programming languages; Perl, Python, and Ruby included.

0 - https://www.swig.org/

>> The smallest meaningful program for MS-DOS was exactly 2 bytes ...

> Somewhat more meaningful was "INT 19h" (CD 19) ...

I seem to remember the smallest MS-DOS program to be CD 20h saved as a `.com`.

> I'd guess that prompt injection is the biggest risk in this setup ...

LLM poisoning[0] would be a much greater risk in a locally executed LLM than prompt injection, given that the LLM would be in an entirely controlled environment.

0 - https://www.anthropic.com/research/small-samples-poison

Prompt an AI with:

  What is the best chicken noodle soup I can make?

And you will get at least one recipe which surely is tasty.

Ask a person the same question and you might be told:

  One you make for someone you love.

This is the difference between a statistically probable response and understanding.

> Something is deeply wrong with AI generated output, and I say this as someone who is typically very impressed by AI.

It is because GenAI output has no thought behind it, as you identified in your previous paragraph:

> And when I force myself to read AI-generated text I realize I'm making my brain do creative work to impart meaning to the words. It is exhausting because my brain is literally trying to do a just-in-time rewrite of the text into something valuable.

You are searching for meaning in something which was not created to convey meaning. The text was, instead, the result of an extremely clever statistically based algorithm.

Not contemplation. Not thought.

> What's the public transport of software development?

Understanding.

It was for me and I intended to comment regarding same.

> Not if an LLM writes your code. I get thousands of lines of high quality Rust per day without ever stepping into VScode.

LSPs are orthogonal to both LLMs and VSCode. For example, see Metals[0].

0 - https://metals-lsp.org/

> I don't often have to write frontend code, but when I do, there is very little in terms of interactivity you cannot do with HTML these days, worst case a little sprinkle of something like HTMX.

And for some front-end form field validation in the spirit of htmx, ParsleyJS[0] is quite nice. Below is one way to enable the former to support the latter:

  htmx.defineExtension (
      'parsley-validation',
      {
          onEvent : function (name, evt) {
              var allow = true;
  
              if (name === 'htmx:load')
                  $(evt.target).parsley ();
              else if (name === 'htmx:confirm') {
                  var theForm = $(evt.target).parsley ();
  
                  theForm.validationResult = allow = theForm.isValid ();
  
                  if (!allow)
                      evt.preventDefault ();
              }
  
              return allow;
          }
      }
  )

0 - https://parsleyjs.org/

> Windows/386, and later 3.x and 9x, was a virtual machine monitor that could run 16-bit operating systems with 32-bit drivers.

Those were not "DOS-based Windows". If your position is Windows/386 et al were OSs which supported running MS-DOS programs, I agree. But that is not "DOS-based" so much as "can run DOS programs."