lincoln20xx

I concur. Most of the most painfully over-engineered swamp projects I've dealt with have been a result of not understanding the requirements.

Of course, this is not to imply that it's necessarily possible to know every requirement perfectly before you begin - I find that I frequently don't really understand the requirements until I've built the damn thing and it's made first contact with the real world.

So I usually toss that first version out, and build the second one. And that one is usually good enough that I don't immediately want to throw it out the window.

And by the time I get through the third version, usually a fair bit after the second is done, it's pretty damn good.

Because now I understand the problem and the requirements so much better than I did at the start, and I better understand what the system needs to be to solve that problem.

Will it be perfect? Never, except in a static and unchanging universe. But we can approach optimality for a given moment in time, which is functionally the same thing.

That may be true. But it's pretty great at generating lines of questioning for cross-examination.

I have a non-zero number of industrial process patents under my belt. Allegedly, that means that I had ideas that had not previously been recorded. Once I wrote them down, paid some lawyers a bunch of money, and did some paperwork, I have the right to pay lawyers more money to make someone's life difficult if I think that someone ever tries to do something with the same thoughts, regardless of if they had those thoughts before, after, or independently of me.

In my opinion, there is a very valid argument that the vast majority of things that are patented are not "new" things, because everything builds on something else that came before it.

The things that are seen as "new" are not infrequently something where someone in field A sees something in field B, ponders it for a minute, and goes "hey, if we take that idea from field B, twist it clockwise a bit, and bolt it onto the other thing we already use, it would make our lives easier over in this nasty corner of field A." Congratulations! "New" idea, and the patent lawyers and finance wonks rejoice.

LLMs may not be able to truly "invent" "new" things, depending on where you place those particular goalposts.

However, even a year or two ago - well before Deep Research et al - they could be shockingly useful for drawing connections between disparate fields and applications. I was working through a "try to sort out the design space of a chemical process" type exercise, and decided to ask whichever GPT was available and free at the time about analogous applications and processes in various industries.

After a bit of prodding it made some suggestions that I definitely could have come up on my own if I had the requisite domain knowledge, but would almost certainly never have managed on my own. It also caused me to make a connection between a few things that I don't think I would have stumbled upon otherwise.

I checked with my chemist friends, and they said the resulting ideas were worth testing. After much iteration, one of the suggested compounds/approaches ended up generating the least bad result from that set of experiments.

I've previously sketched out a framework for using these tools (combined with other similar machine learning/AI/simulation tools) to massively improve the energy consumption of industrial chemical processes. It seems to me that that type of application is one where the LLM's environmental cost could be very much offset by the advances it provides.

The social cost is a completely different question though, and I think a very valid one. I also don't think our economic system is structured in such a way that the social costs will ever be mitigated.

Where am I going with this? I'm not sure.

Is there a "ghost in the machine"? I wouldn't place a bet on yes, at least not today. But I think that there is a fair bit of something there. Utility, if nothing else. They seem like a force multiplier to me, and I think that with proper guidance, that force multiplier could be applied to basic research, material science, economics, and "inventions".

Right now, it does seem that it takes someone with a lot of knowledge about the specific area, process, or task to get really good results out of LLMs.

Will that always be true? I don't know. I think there's at least one piece of the puzzle we don't have sorted out yet, and that the utility of the existing models/architectures will ride the s-curve up a bit longer but ultimately flatten out.

I'm also wrong a LOT, so I wouldn't bet a shiny nickel on that.

I've been using build123d (based on cadquery) quite a bit and I really like it. I still use solidworks for simulations, drawings, and most fillet operations - because it turns out that doing fillets right is very non-trivial.

Code-cad is great because you get exactly what you put in, but sometimes it can feel like starting with a bucket of logic gates instead of a microcontroller.

I've had "test LLM's with code-cad" on my todo list for a while, as I think it has the possibility of greatly accelerating the production of the additional part libraries that I'd need to able to make more regular use of it.

Programmable Logic Controllers (PLCs) that follow the IEC 61131-3 standard [0] utilize 5 different programming languages, three of which are visual/graphical, and two of which are text-based.

The graphical languages are well-suited to industrial programming contexts - and especially object-oriented modalities - as nearly everything that is being programmed is a representation of something in the physical world.

Plants have process lines which have equipment types (classes) with different variations (inheritance) which have sensors which have various configuration parameters and so on. Many of these types of equipment have common functionality or requests made of them (interfaces).

One of the IEC text-based languages - Instruction List (IL) - is deprecated, the while other - Structured Text (ST) - is Pascal-based, great for more complex math and logic functions, and likely runs a significant portion of the infrastructure you interact with on a daily basis. This is especially true if you live outside of North America, which tends to still rely heavily on ladder logic.

The three graphical languages have somewhat different ideal use cases and functionality, though for historical reasons ladder logic is frequently used to do 100% of the work when other languages may perhaps be more appropriate. The same may be said of some 100% structured text implementations.

Ladder logic (LD) was designed to represent banks of physical relay logic hardware. It is read left to right, and if a connection exists between the two, the right side is active. As such, it is great for simple controls that rely on boolean logic and simple functional logic. A good ladder program can be seen and understood and debugged quickly by anyone who has any knowledge of the underlying physical system, which makes it very popular for basic on/off systems such as motors or pumps.

Function Block Diagrams (FBD) are exactly what the name implies, and like LD are read and processed left-to-right. I like them for certain kinds of math processing such as linear interpolations.

Sequential Function Chart (SFC) is, like FBD, exactly what it sounds like. These are ideal for describing state machines with a defined start and end point, and discrete steps in between. They are not expressly limited to a single active state at any one time, and can have multiple parallel active branches. Codesys-based systems extend on the base IEC specification by expanding upon the way that actions and transitions can be defined and worked with.

Codesys-based systems also have Continuous Function Chart (CFC) and Unified Modeling Language (UML) languages. CFC may be thought of as an extension of FBD and/or SFC, and is useful for creating higher-level equipment coordination diagrams and designs. UML has class and state diagrams, and I've used it not at all, so I won't comment on it further.

[0] https://en.wikipedia.org/wiki/IEC_61131-3

Git works great with text-based code-cad. My personal favourite flavor is build123d, which is based on cadquery.

Drugs are a big part of the "how are people going faster for longer" equation, of course.

But in an endurance context, adequate fuelling is likely even more important than a new magic drug, because it doesn't matter how many drugs you take if you don't replenish your energy reserves. You can have the biggest engine in the world, or the most efficient, but once you run out of fuel, it's not going anywhere.

For those nearing the pointy end of strength sports, drugs are generally seen as a 10-15% boost for high intermediate level lifters, and single digit for advanced/expert.

When the difference between first place and not ending up on the board is sometimes 1-3%, the drugs are mandatory.

But everything else has to be there as well. Drugs don't replace hard work, dedication, and proper nutrition - they augment it.

If you safely can consume 10% more calories hourly than your competitors in a long endurance race, that means you can burn more calories and put out more average power than everyone else who is likely on a very similar drug cocktail.