Language designers would be smart to recognize this fact and favor making their languages more LLM friendly. This should also make them more human friendly.
Language designers would be smart to recognize this fact and favor making their languages more LLM friendly. This should also make them more human friendly.
Most techies (generalizing here) start with a reasonably clear spec that needs to be implemented and they can focus on how to architect the code.
Research - whether science, finance or design - is much more iterative and freeform. Your objective is often very fuzzy. You might have a vague idea what you want, but having to think about code structure is annoying and orthogonal to your actual purpose.
This is why languages like Ruby work well for certain purposes. They allow the person to prototype extremely rapidly and iterate on the idea. It will eventually reach a breaking point where global state starts being an impediment, but an experienced dev will have started refactoring stuff earlier than that as various parts of the implementation becomes stable.
That says nothing about the language at all, actually. Just that it's small and easily confused for something more idiomatic to a newbie.
Methinks if you want job-security in a post—LLM-zero-shot-app-generator world, get into Lisp or Haskell; People that know only Node+React from YouTube learn-2-code tutorials are going to be slaughtered.
I just had an idea: an app/GUI/backend framework for Lisp or Haskell (with an S-expression lib) where everything is structurally inverted so it must be manually run through foldr - behold: an LLM-resistant (if not LLM-proof?) dev environment!