I have a basic understanding of Rust.. and this maybe off target - read that as a warning of errors below!
Would Rust be more intuitive and a lot simpler to understand, if it was just formed around the language objects that it's actioning, rather than the traditional programming language names? For all that "structs" and "impl" etc suggest, would using natural language encourage better programming by reflecting the reality that Rust is looking to achieve?
I wonder that these Rust objects relate to these language items:
For example, why talk of "structs" when instead we could just suggest Noun?; why talk of impl when we could suggest Adverb?..
Off topic: I don't know lifetimes well enough yet to know how to articulate those. It seems several instances where those are challenged, can be formed in ways that do not need explicit lifetimes stated - when[=in what form of problem] are lifetimes required and when are they not?
I'm not sure what you're suggesting. What I'm interpreting it as is:
// So we create a noun called `Foo` with no elements
struct Foo;
// and then ...
Also, I know I'm not great with grammar terms (and I'm fairly certain I'm not alone). I learned them when required when a school topic required them but as they don't matter in real life, I quickly forgot them. As such, I don't know what the bottom 4 items in the right column mean and if I did, I'd quickly forget the meaning. I would probably find them very very unhelpful in documentation.
I am sorry, but I believe your analogy does not work at all. If we employ terms for natural languages for Rust or any computer language, then this:
let a = b + 5;
… would be a sentence, there is definitely no doubt about it. But according with your analogy, it would be a sentence without noun, pronouns, verbs or adjectives.
If you really want to make that kind of analogy, let = is the verb, a and b are pronouns, 5 is a noun and + would probably be a conjunction. But that is just clumsy and IMHO brings no benefit.
and yet, you are programming with a language that is likely already doing exactly that.
If it's possible to acknowledge a link, then certain types of problem might become simpler to understand. I'm just wondering that Rust2.0 could be more like a well structured rational sentence.
So,
would remain as that, as it's just symbolic of "let a equal b plus five", which is how a non programmer would request that.
I don't know but I wonder that a programming evolves it becomes closer to language.. Rust is the closest I've seen to something that could be made easy to talk to. Such a next step, would perhaps need an intermediary function to convert what are adverbs into impl and nouns into struct but still maybe that's the future? For now, I was just wondering that understanding that programming is in essence language, might help those who are familiar with both programming and grammar.
Coming at it from the other direction.. what's the benefit to suggesting "struct" rather than "Noun"; or "impl" rather than "Adverb" etc..
If there is no difference between the Rust element and the language element, then there is value in understanding that - at least for those who appreciate that language concept; if there is difference, then it's worth noting that. For all people's ignorance of language structure, it can often be the route they take to solving problems.
It's not important perhaps but interesting if you understand why language is formed in the way it is and then how programming is actioned. Creating an abstract that is a programming language and not noting the similarity, would be odd.
In everyday speech, people do not use the words “noun” or “verb”, they only do when speaking about grammar., when speaking about the language. When you write a Rust program, you are not writing about Rust, so you do not have to use that kind of words.
Of course, you can decide to replace the language keywords by words from a random lexical field, but your original analogy bears no more advantages than calling structs dogs, enums cats and traits tricks.
struct can be likened to structure which can be thought of as something physical such as a building which is composed of beams, nails, and whatever else it was built from; that is, struct is something which can house other things and so in a physical sense the name can be likened to something real in reality. Likewise, implementation of some plan (such as fabricating a building) could be likened to the impl in the sense related to using or doing something.
Do not confuse fluency with understanding of the grammatical underpinnings of that language. Even a 4 year old child should be able to speak well for their age without knowing anything about grammar. A adult foreigner in contrast might study the language with grammar for years and still not be able to have a full speed conversation with a local that the 4 year old would be able to have.
Even where grammar makes the most sense, in a written and/or spoken language, requiring that someone learn it may only be a hindrance. The reason being, the grammar actually isn't important. What is important is using the spoken phrases in the correct sequences and fashion. Once this is learned by practice and repetition, the rules have little relevance.
What you are suggesting may be helpful and make sense to you but I would be very wary of trying to insert grammatical terms into documentation. Unless you're already versed in grammar, I wouldn't expect it to help and documentation is already difficult enough as it is.
Clearly it wouldn't catch on as it's not immediately obvious.
Your reply is more from the user's perspective, I was thinking more about what Rust understands. It's ability might be likened to a 4 year old that insists on a particular phrasing and syntax but if that can become more fluid and still retain an unambiguous delivery, then perhaps that makes it more useful to adult foreigners..
Perhaps 'talking' aka programming, unambiguously, necessarily will be a different language type to what is normal conversation. The normal conversational languages we use, spawn alsorts of confusions, despite the grammar and syntax; so, the detail required to remove ambiguity, will be the difference that makes programming what it is.
You might be interested in a Larry Wall interview. He's well known as a linguist who tries to approach language design from the linguistic perspective (as opposed to say the mathematical perspective Python tries to take). He'll clearly be talking about Perl 6 in that link as well because he's been working on it for years and it's pretty close to release I think. He seems to be discussing things which would probably track with your suggestion.
Trying to bolt on this analogy onto a language not designed with the analogy in mind feels like it's destined to fail. There is a lot of nuance that it missed by the analogy, it it only fits very loosely (compared to J, where the analogy is core to the semantics).
It's not too much of a stretch to see that a concept articulated in programming, can be understood; and the understanding of that then can be communicated in some different language; and that there is some difference there, which may vary abstractly between the 'languages' used but might also be an allusion to what is necessarily similar. Obj orientated programming always seemed, to me at a distance, to be trying to acknowledge classes that are nouns - which is the simplest link to common tongue; and Rust I wonder is more focused on what are Adverbs - but then I've a lot still to learn about Rust.
Changing perspectives midway solving any problem will always spawn complexity but it's perhaps useful at times to pause and reflect and wonder then about what they future holds.. even if it's not planned, perhaps there will be a tendency towards programming understanding concepts in the same way that humans do.
Do we have, or can computers ever have, the imagination to think differently?..