|
Using a simple vocabulary is not inherently better. It's a trade-off. What it does, is reach a wider audience, at the expense of clear, concise communication. All communication has this same trade-off, whether it's between people, or between a person and a compiler or virtual machine. For example, when speaking in a domain, such as computer science and programming, there are certain words we use that are specific to that domain which help us express ideas efficiently. The assumption is that the people receiving the communication know those words, or at least know how to quickly find out what they are referring to, in context. For example, type system. The layperson may have wildly different expectations for what that means, if they even want to hazard a guess. Replacing "type system" with ten to thirty words describing what we mean instead of using type system does make the communication more approachable (if longer) to the layperson, but at some small inconvenience to the writer and to readers who are already familiar with the concept. I don't want to read a few sentences to just come to the conclusion that the writer is describing what we already both have efficiently categorized in our minds as a type system. There is, in this, quite a bit in common with programming languages, and how we communicate with computers and later programmers using them. Perl, for example, often labelled as a write-only language. Some of this is due to quite a bit of historical programming dating to the early web, when there was less thought to maintainability and not abusing the flexibility of the language, and some of this is due to the rich syntax and expressions allowed in the language. Perl comes with a larger vocabulary than many other languages, and the syntax is complex (expressive) enough that the learning curve is a bit longer. The benefit is that people well versed in the language can express themselves clearly, concisely and quickly. Python, on the other hand, as a smaller vocabulary, and more constrained syntax. This emphasizes clarity over conciseness and quickness. This constraint allows programmers that are amateurs to still write code in a way that does not appear extremely different than the code an expert writes (although I believe there is an underlying complexity in the code that this masks). The important thing to note here is that there's a trade-off in language design, and in the use of languages. I believe that a group of five expert Perl programmers will achieve more in the same time period than a group of five expert Python programmers, all other things being equal (including module ecosystems). I don't think this is a a controversial statement, just as I don't think five expert QBASIC programmers will be as efficient as five Python programmers, or that five expert Perl programmers will be as efficient as five expert APL programmers. The key point here is that if they are all experts, whatever your trade-off for accessibility was is now a liability. The other key point is that people rarely become experts, so optimizing for some lower level of skill, whether it be amateur or professional, is often a more useful strategy, because it trade of quality (efficiency) for quantity is often a good one to make at this level. Conversely, I would argue going too far the other way, to the level of QBASIC, constrains people past the amateur level far too much and hurts efficiency as well. I guess that's really just a long-winded way of saying you should write to your audience.:) P.S. I often find I use wordier expressions when I could have used something simpler. I like to think that's because I'm trying to be concise, and convey a specific meaning, and I value my time and the time of those that read what I write. In the end, I use words like "inherently" because it accurately captures exactly what I was trying to express. Hopefully for the audience at HN, and the many non-native English speakers we have, that's not problematic. I don't think I'm too wordy, but I have a feeling I'm unable to accurately assess myself on this subject. |