Am Fr., 19. Aug. 2022 um 22:07 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>: > > >>> locative > >>> ephemeron > >>> assertion > >>> violation > >>> reference > > I like these more than loc, eph, ass, vio, ref. > > > > Or what do you have in mind? > > E.g. place, weak pair, check, error. A place is not a locative, an weak pair is not an ephemeron. An error is not a violation (using R6RS semantics). If you fuse the names, you confound previously well-defined and separate concepts. > I don't mean to suggest we can adopt these specific words, merely to > point out that these sound sensible and the longer ones sound obtuse. That's probably a matter of opinion. And then there's the question of whether it is really a problem that the longer names sound obtuse for some. > > PS I am not a native speaker of English, but I have never had a > > problem with these "big" (by whatever metric) words. At least to me, > > precision in wording is more important than brevity, so better use two > > not-so-short words for two different things than to name the two > > different things by the same short word. Personally, I think the > > existing traditions in naming should also be respected if it makes > > sense. E.g., R6RS makes the distinction between "errors" and > > "violations" (in its condition hierarchy). When future Scheme > > standards adopt this division, there are good reasons for sticking to > > these established terms instead of calling these types, say, "user > > error" and "programmer error", just to get rid of the "big" word > > "violation". > Having to make fine distinctions between similar concepts means we have > too many concepts. Over the long term, most software projects morph into > the Titanic. Scheme is getting there. There's nothing we can do in the > short term about the existing conceptual bloat in RnRS but we should be > cautious about adding new stuff. There are few subjects where you have to learn as much terminology and vocabulary per week as when you study maths. Nevertheless, students successfully cope with this amount of (sometimes only subtly different) concepts. And the existence of this sheer volume of concepts does not mean mathematics is bloated. Things we want to talk about all have some inherent complexity. One cannot cope with complexity by glossing over it. Besides, complexity doesn't necessarily make things harder to understand or use. One needs far fewer concepts to describe assembler language precisely than to describe Scheme. But understanding and writing Scheme is much simpler than what it is for assembler code. Also, modularity comes to the rescue. For example, the beginner doesn't have to understand call/cc to write their first successful programs in Scheme. Marc -- * Unfortunately, I can't recall the exact number of new (mathematical) words per week a survey found, but it was astonishingly high, much higher than when you study languages, for example.
