ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
40% Positive
Analyzed from 848 words in the discussion.
Trending Topics
#relevant#write#language#understand#program#programming#level#someone#once#irrelevant

Discussion (24 Comments)Read Original on HackerNews
This one stood out to me. I'd say it's a favorite.
These others are interesting in the age of LLMs:
> 93. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
> 114. Within a computer natural language is unnatural.
> 115. Most people find the concept of programming obvious, but the doing impossible.
> 27. Once you understand how to write a program get someone else to write it.
> 113. The only constructive theory connecting neuroscience and psychology will arise from the study of software.
This one remains worth thinking about in terms of the consequences and costs of automation and computerization, LLM-powered or not:
> 99. In man-machine symbiosis, it is man who must adjust: The machines can't.
>
Great definition actually
If something requires attention, it’s by definition relevant
Obviously, it's relevant if the language itself forces the user to worry about some pointless minutia. The problem is that the language created that relevance, when it is otherwise irrelevant to the problem the user is trying to solve.
Forward declarations are relevant in C because the program won't compile without them. But they aren't relevant in any meaningful way to any domain a user might be writing C programs for.
Not really. Consider an assembly language for a processor with a very orthogonal register set. The number of registers used by a block of code is relevant, but the identity of those registers isn't. That is, if the code can be written without spilling with six distinct, uniform registers, the choice of one of the 6! possible assignments of those six registers are irrelevant. But when writing that code, you still need to make the choice. And in real assembly languages, it's not necessarily obvious whether the choice here is arbitrary and unconstrained, or externally constrained (e.g. when choosing a mapping that avoids a move instruction by forcing the caller to pass a certain value in an agreed register; or when using an almost-orthogonal register set where it's unclear if later code cares that the value is left in a register that is also the possible target of a div instruction or something), so this requires attention at both write-time and read-time, even when irrelevant.
Maybe "high-level"" low level" should be understood in terms relative to the task and its goals.
Also, many stupid or nonsensical statements can often yield wisdom if you meditate on them enough. Indeed, many (most?) zen koans are so simplistic that to get any usefulness out of them you have to insert you own assumptions and try to determine how it might apply.
https://youtu.be/0jK0ytvjv-E?t=43
https://youtu.be/xE9W9Ghe4Jk?t=238
I think many of those are pretty subjective, and maybe not always right for everyone or for all time. But there are certainly going to be some universal pearls of wisdom, and neither of us can - by ourselves - tell which ones they are.
[0] https://medium.com/gitconnected/you-are-bugs-improving-your-...
Seems to be a strike against LLM-based programming systems like Claude.
A good way to enforce this is to encrypt the data at the beginning of the process.
Then any function that returns structured data is clearly foolish and can be marked for removal.
Pretty relevant with LLMs and coding agents.
Did you ever have one of those days when variables didn't and constants weren't?