• 0 Posts
  • 30 Comments
Joined 2 years ago
cake
Cake day: January 15th, 2024

help-circle



  • I just had one of those “brain-doing-brain-stuff-good” moments (I think normal people call them delusions?) pondering about why it is that AI code extruders are seeing widening adoption.

    tl;dr - there’s a bunch of people uncurious about the nature of the abstractions they use and it’s a tragedy.

    First a moment of background: My first software dev position was using Lisp and one of the most powerful concepts built into the language runtime was the macro facility, the ability to write code that writes code. The main downsides of Lisp are obsequious Lisp developers and hard-to-master C foreign function interfaces, so what you have is a toolchain of abandoned dependencies made by some real annoying characters, but I digress. The ability to write code that writes code is a powerful concept.

    I moved on to working with .Net which sometime around the 4.6 version release got enhancements to built-in language utilities. This led to better code-generators for numerous purposes (certain DI containers started to do dependency resolution at build time for example).

    I did Scala for a time, which had a macro facility that was hot garbage and was rewritten between 2 and 3, so I never bothered to learn it. Around this time the orgs I worked for were placing an emphasis on OpenAPI / swagger specs for reasons I don’t know because while there was tooling that could be used to generate both the entire http client and the set of interfaces used by the surface, we did neither (where I am at right now we still do neither form of code gen).

    Anyways, things like code generation whether via external tooling or internal facilities is magical but it is deterministic magic: Identical input should yield the same result. It is also hard to use well. The ergonomics of the OpenAPI / Swagger codegen tooling is pretty bad though not impossible, and the whole thing under the hood is powered by mustache templates. The .Net stuff is still there and works well, but I don’t think many work places want to invest in really understanding that tooling and how it can be employed. Lisp well always be Lisp, good job Lisp. There are other examples of code generation used for practical ends I am sure.

    The point is that code generation requires being able to think and define certain forms of abstractions outside of the target functionality of a single program and while it’s not hard to do that thinking, it’s just high enough of a bar that your typical enterprise engineer won’t engage with that (but will always be amazed by the results!).

    AI Code Extruders change the cognitive burden that would be required for code generation into something that I guess appeals to engineers. You can specify something in the abstract and a Do-What-I-Mean machine may churn up something minimally useful, determinism be damned. Not only would an engineer not need to consider the abstraction layer between their input and the code but they would be unable to fully interrogate that abstraction because the code extruder does not need to show its work.

    Just a thought. Probably a very silly thought.










  • “these ai girls with 3 boobs really puts strain on the fashion model industry”

    CNC Tool Programmer is a good one and shows that Microsoft, a company that probably has paid for someone to run CNC tooling for prototyping AND supposedly makes software, didn’t do the bare minimum to understand complexeties involved by talking to that someone.

    Yeah, you can make mistakes with programming this thing, it’ll happily destroy hundreds of thousands of dollars in tooling as well as potentially maiming or killing anyone standing too close while the machine is actually physically crashing. It will friction-weld your nice, expensive carbide cutting tool with cooling channels to your work piece (even if they are dissimler metals) by taking too big of a cut because it does exactly as it’s instructed.