> Do you find the resulting natural language description is easier to reason about?
An example from an different field - aviation weather forecasts and notices are published in a strongly abbreviated and codified form. For example, the weather at Sydney Australia now is:
METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0
It's almost universal that new pilots ask "why isn't this in words?". And, indeed, most flight planning apps will convert the code to prose.But professional pilots (and ATC, etc) universally prefer the coded format. Is is compact (one line instead of a whole paragraph), the format well defined (I know exactly where to look for the one piece I need), and it's unambiguous and well defined.
Same for maths and coding - once you reach a certain level of expertise, the complexity and redundancy of natural language is a greater cost than benefit. This seems to apply to all fields of expertise.
An interesting perspective on this is that language is just another tool on the job. Like any other tool, you use the kind of language that is most applicable and efficient. When you need to describe or understand weather conditions quickly and unambiguously, you use METAR. Sure, you could use English or another natural language, but it's like using a multitool instead of a chef knife. It'll work in a pinch, but a tool designed to solve your specific problem will work much better.
Not to slight multitools or natural languages, of course - there is tremendous value in a tool that can basically do everything. Natural languages have the difficult job of describing the entire world (or, the experience of existing in the world as a human), which is pretty awesome.
And different natural languages give you different perspectives on the world, e.g., Japanese describes the world from the perspective of a Japanese person, with dedicated words for Japanese traditions that don't exist in other cultures. You could roughly translate "kabuki" into English as "Japanese play", but you lose a lot of what makes kabuki "kabuki", as opposed to "noh". You can use lots of English words to describe exactly what kabuki is, but if you're going to be talking about it a lot, operating solely in English is going to become burdensome, and it's better to borrow the Japanese word "kabuki".
All languages are domain specific languages!
> Same for maths and coding - once you reach a certain level of expertise, the complexity and redundancy of natural language is a greater cost than benefit. This seems to apply to all fields of expertise.
And as well as these points, ambiguity. A formal specification of communication can avoid ambiguity by being absolute and precise regardless of who is speaking and who is interpreting. Natural languages are riddled wth inconsistencies, colloquialisms, and imprecisions that can lead to misinterpretations by even the most fluent of speakers simply by nature of natural languages being human language - different people learn these languages differently and ascribe different meanings or interpretations to different wordings, which are inconsistent because of the cultural backgrounds of those involved and the lack of a strict formal specification.
you guys are not wrong. explain any semi complez program, you will instantly resort to diagrams, tables, flow charts etc. etc.
ofcourse, you can get your LLM to be bit evil in its replies, to help you truly. rather than to spoon feed you an unhealthy diet.
i forbid my LLM to send me code and tell it to be harsh to me if i ask stupid things. stupid as in, lazy questions. send me the link to the manual/specs with an RTFM or something i can digest and better my undertanding. send links not mazes of words.
now i can feel myself grow again as a programmer.
as you said. you need to build expertise, not try to find ways around it.
with that expertise you can find _better_ ways. but for this, firstly, you need the expertise.
You can see the same phenomenon playing a roguelike game.
They traditionally have ASCII graphics, and you can easily determine what an enemy is by looking at its ASCII representation.
For many decades now graphical tilesets have been available for people who hate the idea of ASCII graphics. But they have to fit in the same space, and it turns out that it's very difficult to tell what those tiny graphics represent. It isn't difficult at all to identify an ASCII character rendered in one of 16 (?) colors.
Exactly. Within a given field, there is always a shorthand for things, understood only by those in the field. Nobody describes things in natural language because why would you?
And to this point - the English language has far more ambiguity than most programming languages.
What do I need to google in order to learn about this format?
> prefer the coded format. Is is compact...
On the other hand "a folder that syncs files between devices and a server" is probably a lot more compact than the code behind Dropbox. I guess you can have both in parallel - prompts and code.
The point of LLM is to enable "ordinary people" to write software. This movement is along with "zero code platform", for example. Creating algorithms by drawing block-schemes, by dragging rectangles and arrows. This is old discussion and there are many successful applications of this nature. LLM is just another attempt to tackle this beast.
Professional developers don't need this ability indeed. Most professional developers, who had to deal with zero code platforms, probably would prefer to just work with ordinary code.
Reading up on the history of mathematics really makes that clear as shown in
https://www.goodreads.com/book/show/1098132.Thomas_Harriot_s...
(ob. discl., I did the typesetting for that)
It shows at least one lengthy and quite wordy example of how an equation would have been stated, then contrasts it in the "new" symbolic representation (this was one of the first major works to make use of Robert Recorde's development of the equals sign).