HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
86% Positive
Analyzed from 1674 words in the discussion.
Trending Topics
#programming#llms#llm#languages#language#actually#written#don#need#software

Discussion (34 Comments)Read Original on HackerNews
Programming languages allow LLMs to build invariants they can’t enforce themselves (type systems), reduce context window (syntax sugar) and represent abstract models in a way that may improve understanding i.e. increase the likelihood of predicting a correct next token.
Plus, we want to understand LLM output, so it should at least be convertible into a language that’s easy for humans.
EDIT: and actually reading the article, learning a new programming paradigm improves your ability to model even in your head, by noticing some abstract thing fits some programming concept, then manipulating the concept (e.g. translation your data model into the algebraic data type,`(a | b) * (a | c)`, then realizing it’s isomorphic to `a * (b | c)`).
I wish we had a language that was targeted specifically for LLMs to write and humans and LLMs to inspect:
- Simple robust syntax
- One obvious way to do things
- Static type checking
- Purely functional encouraged, escape hatches for performance
- Inspect-able, testable, and reviewable in small pieces
- Something like formal predicates, preconditions, post-conditions, assertions, or effects typing
Giving LLMs all the surface area of Python, JavaScript, TypeScript, or C++ seems like a huge mistake. It's amazing it works as well as it does. Well written Haskell is beautiful, but there are way too many ways to write Haskell:
https://people.willamette.edu/~fruehr/haskell/evolution.html
> - Inspect-able, testable, and reviewable in small pieces
This is more a property of the architecture than a property of the language, although some programming languages support it better than others.
I review a lot of Go code, which means I review a lot of LLM Go code. Even though the human vs LLM authorship distinction has strong signals, Go's simple nature seems like a useful constraint on how LLMs can express themselves.
Elixir's exhaustive pattern matching and gradual type checking is also on my radar.
I guess I don't know what you mean by effects typing.
These allow the model to cheat in ways that are harder to detect. In actually pure FP you can be sure that it's not counting function invocations to bypass tests.
Maybe these well known cases could be hidden in the API, but it's easy to come up with other examples. I forget what Clojure calls it, but they have some notion about things where they're mutable during "birth" and then locked down.
Someone smarter than me knows how to do this right.
When I observe its reasoning I see it doing this all the time.
I'm a programming languages nerd. I was paid to program in over 20 different languages over my 25 year career. I read up on many more languages along the way, and I wrote pet projects in a few of those. I've written a couple assemblers, compilers, and interpreters for my own languages.
I think literally everyone should be taught to program in elementary school. It's arguably one of the best ways to teach logical thought and careful organization of ideas. I like Alan Perlis's quote: You think you know when you can learn, are more sure when you can write, even more when you can teach, but certain when you can program.
With all of that out of the way, I think there are interesting questions to ask going forward:
If you were starting a business for a great software idea, with your own savings on the line, would you hire 10 AI hostile programmers to implement the idea or 2 AI friendly people and get them some subscriptions to the top models? Remember: if it doesn't come together, it's YOUR money on the line.
What are the best programming languages for LLMs to program with? Could someone design a better language that fits their strengths and weaknesses? I think the most popular human languages have way too much affordance for concerns that don't apply to models. I think letting LLMs program in human friendly languages makes the results more difficult for humans to inspect. There's a slight chicken and egg problem based on the training sets used by large models, but this can be addressed with LoRA tuning and similar techniques for open weight models.
How can we make LLMs scale better so that people who don't like to program can get better "vibe coding" results? Tools like Excel are huge force multipliers for so many people who aren't interested in writing traditional code. I think it should be possible for non-programmers to solve their own problems and trust the results without becoming programmers.
Anyways, I've got my own partially formed answers to those questions, but I'd like to hear what other people who aren't still suffering stages of LLM programming grief have to say and ask.
Does it? I think for example Ruby seems to work quite well with LLMs in this regard. Or is this not what you would consider human friendly?
Actually a pretty interesting question. I think it depends on the software, if it's some web app or something fairly trivial and mechanical the AI friendly devs would probably be cheaper and faster. If it was like, a robotics platform or something I would hire the 10 AI hostile devs. But ideally I would hire 5 expert programmers who use AI in a pragmatic way.
It’s very fast and very difficult to read.
Software engineers feeling down should think about software designed to track medication administration, or validate their tax calculations, or to decide whether to flag you for a CIFAS marker, or whatever, and then imagine the generic "fuck it, that'll do" type vibecoder-level-engineer handling the code.
That makes me feel even more down, because I know this will happen.
I know this may be some kind of reverse survivorship bias and that I simply do not notice all of the slop around me that somehow is truly "good enough", but I think I need to see some concrete examples to convince me.
That kind of proves the opposite point: you’re using those apps so they were good enough for the people who made it to get to you who would probably never even be able go write an app. Also are you comparing the apps to your average, bug ridden app written before LLMs existed? Maybe they’re not that much worse.
Maybe you use your 2-10 apps and that’s it? Do you even let’s say — for the excercise sake — use those apps fully, each and every screen?
I use dozens of apps, most of functionality from the ones I need is a single flow or function.
I don’t care about setting my avatars or filling „user details” unless it is a delivery app or a shop. Most frameworks have boilerplate for that but there are dozens of such screens that don’t have boilerplate yet those are nice to have even if not used by 90% of users.