Martin Euredjian via Python-ideas writes: > Another interesting example is had in some of my work with real > time embedded systems. There are plenty of cases where you are > doing things that are very tightly related to, for example, signals > coming into the processor though a pin; by this I mean real-time > operations where every clock cycle counts. One of the most > critical aspects of this for me is the documentation of what one si > doing and thinking. And yet, because we insist on programming in > ASCII we are limited to text-based comments that don't always work > well at all. In my work I would insert a comment directing the > reader to access a PDF file I placed in the same directory often > containing an annotated image of a waveform with notes.
This has nothing to do with representation or input via text, though. Emacs has displayed formatted output along with or instead of code since the mid-90s or so, invariably based on a plain-text protocol and file format. (The point is not that Emacs rulez, although it does. ;-) It's that a program available to anyone on commodity hardware could do it. I imagine the capability goes back to the Xerox Alto in the mid-70s.) > It would be amazing if we could move away from text-only > programming and integrate a rich environment where such > documentation could exist and move with the code. We've been *able* to do so for decades (when was WYSIWYG introduced?), and even if you hate Emacs, there are enough people and enough variation among them that if this were really an important thing, it would be important in Emacs. It's not. Note that I do not deny that it is a *thing*. I just can't agree that it would be amazing -- I would be neither surprised nor particularly overwhelmingly enabled by it, and I don't know anybody else who would find it especially enabling. (Again, I don't deny that *you* would.) > The famous one-liner solutions are not neat because they are > on-liners, they are interesting because they become idioms, words, > with a meaning. Your brain sees that and knows what that line is > doing. This is absolutely true. As you point out earlier, it's also true of *fingers*, and it's really no harder to type the ligature "<-" than it is to type the chord "Alt-Meta-DoubleBucky-<" (unless you're a professional pianist). I agree with those who say that "←" is hard to read, but I think that's a font issue: we should fix the fonts. Keyboards are harder. Labels aren't enough: it really annoys me when I have to look at the keyboard for some rarely typed Japanese characters whose Roman input format I don't know. > Again, this isn't what happens to a newbie, of course. Of course it does. That's exactly why I have always consistently flubbed certain phrases in old hymns translated to Japanese: the use of particles (suffixes equivalent to English prepositions) has changed over time. I don't know how natives handle it, but to me it's really difficult precisely because I have a limited repertoire of idioms, I can't even read the older versions easily, even though they use the modern glyphs. (Bach German lyrics in Fraktur are perversely easier *because* I don't have any German idioms!) Japanese members of my choirs are sympathetic, but they also don't understand why I don't "get better". *They* catch on fast enough, and my Japanese is good enough to occasionally fool people on the phone. :-) > The closest Python example of this I can provide would be list > comprehensions you reach for all the time. I think even closer is the walrus operator itself. But there are Python counterexamples, as well. Some of them are arguably compromises that satisfy nobody (lambdas that can wrap expressions but not suites). Others are debatable (I don't know how he feels now, but there was a time that Guido wrote he wished he could deprecate augmented assignments in favor of a compiler optimization), and Guido has never been able to accept increment operators, though for at least the first decade I participated here they were a frequent request. I would offer the Lisp family as a higher-level counterexample. In Lisp programming, I at least tend to avoid creating idioms in favor of named functions and macros, or flet and labels (their local versions). (Curiously, I guess, I do make liberal use of lambdas as arguments to functionals rather than use a label.) I'm beginning to regret using the words "idiom" and "counterexample" (even though they were introduced by others), but I don't have better ones. By "counterexample", I think that what I'm trying to argue here is that yes, human beings do have the ability, and a very useful ability, to create and use idioms. But these idioms can also be usefully compressed into names in some contexts. The choice of which to use is a matter of style, of course, but also a matter of audience. Use of names is more compact, and among "experts" (ie, those who already know and use those names) they can express great complexity in a form compact enough to hold in one's head. The problem with the word "idiom" is that in natural languages idiomatic expressions need to be explained. They carry meaning beyond the literal words and grammar used. What's different about programming "idioms" is that *they do not need to be explained* -- they carry exactly the meaning the language gives them. They still have the advantage that they're read as "words" by experts, yet they're intelligible to those who have not yet acquired them as idioms. In that sense, computer idioms are more powerful than those of natural language! Python tries to compromise by providing limited vocabulary and syntax with powerful naming facilities, ie, functions and classes. I'm not sure that allowing additional math operators from the Unicode repertoire would be such a bad thing, but such compromises are by nature delicate balances. I think it would be better to create a separate Python-like language with the feature. That's been quite successful in the Lisp family, I think. (FVO of "success" being "allows the community to evolve the language without destroying it", not "corners the market in cool kids who use the language". ;-) Regards, Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ULQL66UEJVFQXKIZGVYSNNZ4MJFNR52J/ Code of Conduct: http://python.org/psf/codeofconduct/
