skydhash

Because code and data as well as the von Neumann architecture are derived things, not fundamental stuff. The Turing Machine and Lambda Calculus are pure invention thats are logically sound. Almost everything else is downstream of that.

By the time you get to programming language like C and LISP, and software like vim or firefox, everything is abstracted away and the only limits are self-imposed (or imposed by others that have done the work). They are not laws of nature.

So yes there’s a definition of code and data. But for the Turing machine, there’s only the tape and its content.

You only need a monitor to capture the audio output and use that as the input in the recorder software. Pipewire and macOS have a whole graph as their sound system where you can connect node (input, outputs, dsp) however you want. Don’t know much about PulseAudio and Jack.

At the base of it, the TM is an abstraction built with sets and relations. Just like most computers are merely signals flowing around a circuit that get generated from other physical phenomena and will be transformed to other physical phenomenas. You can't hack around physical laws, or ignore the axiomatical rules in mathematics. The code that is not data are those things.

Everything else is data.

I think where people get worked up about this, is that it's not easy to tell what understanding other folks are taking away from their AI usage.

Alongside understanding, you also loose taste and perception. You can still say whether some things is good or bad, especially if you interact with it, but you can no longer articulate why. And with perception loss, you can no longer preempt a bad situation as you lose your awareness of things.

So for you a car may be a vehicle that you drive around. But for a mechanics it's a much complex system. When something doesn't work, you will lack the vocabulary to express what's wrong. And even when everything works, you may not be able to explain how.

The thing is, LLM are very buggy translators. Agents in software development help because they provide a way for LLMs to verify their output. But correctness is very hard to express. OK for a simpler task, but not really for a complex systems. Just like fluency in a foreign language is not about knowing the rules of grammar and a lots of words, but also knowing the idioms and other figure of speech.

Sounds very much like agency over the process versus agency over the outcome.

Some are ok with deciding if and when the process should be started and whether the outcome is good and bad. But often they lack the judgment to truly decide what is good and what is bad. They trust the makers to provide equally good options in terms of lower concerns (that matters to the makers) and only make the judgment according to some other concerns.

The main difference when using a compiler is that the compiler will (99.999...%) produce correct binary code for my programs and will fail loudly if it cannot. But the compiler is not concerned about correctness of the algorithm written in the programming language. Responsibilities are clearly outlined and the compiler does the job perfectly, while I try to do mine as well. So when I do a good job, I don't have to worry about the compiler part and I can assume the result will be good as well.

LLM usage has no such clear line. Assuming the user can judge whether the outcome is good or bad according to the prompt, the LLM tool is not reliable enough to produce a good result for everything that was not specified in the prompt. Which is different when collaborating with humans. If you say to a professional artist "I want a batman drawing", you needn't check for missing toes and the numbers of arms.

State transition in the turing machine are not modifiable, but one of the core advantages of the TM is that it's powerful enough to emulate state transition. So you can model the states of the new machine as data, add the transition mechanism as code, feed those to the TM and you have a new machine that can interpret input that was unrecognizable by the previous one. That's how programming languages works.

So yes, you can't modify the actual embodiment of the state transition if it does not offer you the capability to do so. But as long as it interprets data in a TM manner (input and output are colocated and the alphabet is the same), you can write code that will interpret data as code and manipulate code as data. Not by modifying the base substrate, but by adding a virtualization layer on top.

“code is data and data is code” is a fact of computing. What LISP does is to make it an official feature of the language and provide nice abstraction for it. A lot of languages want you to use some cumbersome reflection library, a dangerous eval function, or a crippled macro mechanism. With LISP, you just use the language mechanism in order to write code that process code.

I spent my whole childhood without computers and a good chunk of my teenage years without stable internet connection. Now, I have both, but due to the state of the internet, I'm returning to my old routine: A load of books to learn from and hopefully finding some time to apply the knowledge.

Some folks don't care much at all about how things work, just that they can shove a thing out the door and get paid with minimal effort. Sometimes their boss is completely in agreement

The issue is not the quality per se (I can write hacky things if that’s needed). The issue is when you become responsible for the shoddy things that were rushed and is now hacks on pile of hacks.

Whenever the subject of AI comes up in connection to programming it feels like the conversation always misses the human element. When you look at this only in terms of human behavior I am not seeing anything new with AI

You’re not wrong. I think that’s the confusion in LLM conversation. It seems that most people believe that programmers only think about code like it’s some kind of lego bricks we have to assemble. While the truth is that most projects is about building a sets of concepts that interacts in a specific way. The code is just the medium to do so, like letters helping to create words when writing.

I was reading the OpenBSD code (some investigation about a pen tablet) and the layers in abstraction was the following:

  xinput
  ws       (driverfor x11)
  --|ioctl syscall|---
  wsmouse  (wscons subsystem)
  hidms    (hid mouse) Some other things use the usb hid format
  ums      (usb mouse)
  uhidev   (usb hid device)
  usb      (root controller hub abstraction)
  xhci     (usb root controller under the hood, usb side
  pci_xhci (usb root controller, pci side)

Programming was always about taking some lower order of things and rearranging it into meaningful concepts for some higher purposes. Whether it’s the DOM api, the jQuery suite of functions, the React model of components and reactive state, the goal is to create UI widgets for a page.

People (sometimes?) see the building blocks (dom api…) and the end result (figma sketch) but have no idea how the two connect.

Let’s say you were trying to say “I like bread” in French (which is “j’aime le pain”) but what come out is “j’aime le vin” (I like wine). It is the wrong statement, but it will produce an effect as the other party may bring you wine (which you may hate). The actual issue here isn’t that you didn’t speak French, but that you didn’t express what you wanted well.

So code is just a notation. But one that is executable. In your example, the code is working, it’s just not what you intended. The issue is not the code, the issue is that you don’t know code well enough to “speak” your algorithm.

And that is the main issue with a lot of LLM users. They are translating specs (which they do understand) to code (that they do not understand) and then relying on superficial outputs to see if they got it right. While also telling fluent speakers that they should follow the same workflow. At least with human languages, the other party may detect discrepancy and the fact that you’re not a native speaker. But a computer will execute things blindly.

Now it's at the level of a competent junior, who can almost do the whole task from start to finish but needs a little supervision.

Define tasks!

The most important aspects is that they’ve always been good at applying patterns, but have no discernment into why and the specific adjustments that needs to be done for a particular contexts. It’s rare that I can’t find discrepancy at the edges if several patterns have been used.

We already have good tools for patterns. It’s called code reusability. So frameworks, libraries, code generators, paradigms, snippets, and the mighty copy and paste (there’s a reason vim has like 26 registers).

Software development is all about managing complexity, which LLM are notoriously bad at. A little supervision won’t cut it.

The cost of prototyping has always been very low. I can quickly sketch a UX flow using balsamiq. Or copy-paste paste code from docs and examples to show a rough working model with. If you can extract the essence of the problem you can quickly realize cheap ways to demonstrate a solution, and not spend two weeks trying to code it.

If there’s something that is wrong with using LLMs to prototype, it is that those prototypes are always too complex. Instead of decomposing a problem and testing unrelated concerns apart from each other, it’s often a mix of everything that the LLM user had been thinking about.

Often there’s no rapid iteration where you are comparing several approaches. Instead it became tunnel vision and confirmation bias where if it’s working, that means it’s the solution.

They are. But engineering is about minimizing costs in solving a problem while ensuring requirements are met. Not worrying about costs is not engineering. It's either a research project (where you want to know if something is possible) or playing around.

Stakeholders will only give you requirements after they see the prototype.

That’s very much incorrect and sounds like someone who love building more than communicating. Even without a prototype, users and other consumers will be able to explain their problems. It may not use the same metaphor map that you’re used to. But it’s very much a description of the problem space.

Once you design a prototype, what you will get is feedback about the solution you’ve designed, not the raw problem. If you’ve not listened well in the first place you may be well off the mark, and have to work harder to correct things.

Even if your story, the junior would do way less work by asking the master what he intends to do with the piece of work instead of focusing on the rock itself.

Determinism isn’t important, but there are usually threshold of acceptable performance in all off those cases. Machine Learning was all about improving accuracy even when you know that there’s probably an error somewhere. But the current LLM hypers refuses to acknowledge that the answer to a prompt may be wrong (even though the providers have a warning line about it).

Instead of assessing the risk and provide corrective methods, all they do is pushing to use it more and more everywhere.

Not really. As the C language was created around 1972 and by 1973, Unix was rewritten in it. By 1975, Unix was released commercially. That’s like 3 years between design and commercial usage.

A spec is a higher level of abstraction than code, which is a higher level of abstraction than machine code

No it’s not.

Just like a quick doodle is not an higher level representation of the Mona Lisa. Sure for someones that knows the latter, it can suggest it. Or for someone that doesn’t know it, it may provide some basis of conversation. But it’s not the real thing. You can’t provide a doodle of something and expect an artist that hasn’t seen it to paint it.

Doodling’s value is that it lets you iterate on ideas without the accidental constraints that comes with the implementation (choosing paints, finding references materials, deciding colors,…). Some necessary choices are kept for later, while you decide on the most important ones.

So a spec is useful in designing software, but it’s severely lacking in implementing it. And the decisions made in implementation are as important as the ones made in the design. Even more after a while in production.

This is one of the reason I like a ticket tracker. I make my commit as descriptive as possible and I tag them with the ticket number. Also I add comments when Product says to cut corners. It's nice to spread responsibility around when things take a bad turn.

The absolute moment you find yourself thinking of putting conditional logic, or string substitution, or anything like that, in your pure config format, switch to a real programming language, before you end up managing several times the complexity of one with only some of the benefits

That’s where you add a plugin system or an ipc mechanism, not a whole programming language.

I have grown pretty negative opinions of “using a programming language as a config language”

Same here. I like the openbsd approach of small DSL (pf, doas) or just simple ini-like key-value config (sysctl, rc.conf). If you want more, just patch the software and be done with it.

A programming language is OK if the intent is to build a platform (Emacs, Vim) but for something that is purely an application software, it's very much not necessary.

no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.

Spend time enough with a codebase and you’ll know stuff about its behavior that is not encoded in a test suite. Especially when you need to adjust an integration tests due to the modification of an invariant in a dependency.

How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?

Because the postgres team is professional and will take care of publishing a changelog for what has been modified since the last version.

Processors today are very fast. If you are spiking it on rendering diffs, you’re doing it wrong. I can’t even stress it building openbsd’s kernel.

That’s not really a big issue. In major OS like the BSD, SMP implementation are not that old. If we can have a full OS running in single core mode, we can have an application being performant too. I’m currently running OpenBSD on 4 cores and it’s basically 99% idle.

Bad coding is just bad coding.

If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.

calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.

There are many things in life that are "fine" only when you take extreme care (knives, cars, industrial machinery,...). The thing is something like C has many usages and you can't just say "use Rust" and be done with it. Using Rust is not cost-free.

I'm not a rust dev. But I've been once asked to take care of a TypeScript codebase and the thing was littered with so many casts to `any`, you're wondering why they bothered with TypeScript in the first place. Some people do choose tech on a vibe and not any real analysis.

The issue is not capabilities (and never was). The issue is reliability.

And that’s assuming you really need to do these type of tasks using an LLM. As GP said, and as you’ve proven, most people are trying to use LLM as an hammer for everything that looks like a nail, without verifying first if it’s a screw or something else.

But it would have been a lot less sexy (actually important for the bottom line!

That’s what the author have been saying. They do for nice demos which sell the illusion of having Jarvis in text format, but the usefulness is not really proven. And that may be important business wise. But as far as end users is concerned, there’s not a lot of productivity boost.

I disagree about the success of chatbots, if the problem is narrowly-defined and chosen properly.

If you can narrow the problem down, then you could design a much better interface for it than a text box and free form text (unless that's the better solution).

As for as AI assisted engineering goes, the thing is that after some time with a project, you already have much of the workflows and routines nailed down as scripts and other various combinations of tooling. And unless it's spaghetti code, you will have various snippets you can copy from for new code. The one thing I've observed about AI projects is that there's often little technical design coherence about them. It's always a kitchen sink of technologies and practices.