On Thu, 19 Mar 2015 12:04:01 -0700, Don Y <this@is.not.me.com> wrote:>On 3/18/2015 11:09 PM, George Neuner wrote: > >> I wouldn't expect a blind user - or ANY user for that matter - to be >> reading code. At most I would expect to be read some error messages. >> *Those* should be able to be pronounced by a screen reader. > >So, they should *hire* folks to customize things to their needs?No. For the vast overwhelming majority of users, customization should *not* require manually writing (or even editing) a script. See below.>>> Or, do you just exclude them from that technology? >> >> No. I expect blind and deaf to be abe to use things, but I don't >> expect any non-technical person (~95% of the population) to be >> programming them. > >I think that is changing. Things are getting too complex for a >"one size fits all" approach to all users.I didn't say anything about "one size fits all". I said the vast majority of people should not be programming - an understatement to be sure. The best way I have seen has been "menu" [includes icons] driven UIs that let people select functions and point out data to operate on, and then generate the script. They can't guarantee the script will do what the user wants, but they can guarantee that it is free from stupid errors. Combined with operations that are intrinsically safe, this is a good way to allow user customization. It is, however, more heavyweight than a telnet session with a line editor.>"Non-programmers" already write macros in Excel, Word, etc. >And, even write VB scripts "without formal training". I don't >think it a stretch to assume they'll be able to "code" these >sorts of things -- esp if there are very high level abstractions >at their disposal.Actually, the ability to write a Word or Excel macro says absolutely nothing about the ability to write, e.g., a correct shell or Python (or whatever) script. When a macro barfs, you can reload the file and try again. When a script barfs, it may destroy the data it was manipulating. Every day businesses suffer lost data and lost productive hours due to amateurs writing "programs". *Your* scripting language may be intrinsically safe, but that doesn't invalidate my point. George
Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions?
Started by ●March 13, 2015
Reply by ●March 19, 20152015-03-19
Reply by ●March 19, 20152015-03-19
On 3/19/2015 2:52 PM, George Neuner wrote:> On Thu, 19 Mar 2015 12:04:01 -0700, Don Y <this@is.not.me.com> wrote: >> On 3/18/2015 11:09 PM, George Neuner wrote: >> >>> I wouldn't expect a blind user - or ANY user for that matter - to be >>> reading code. At most I would expect to be read some error messages. >>> *Those* should be able to be pronounced by a screen reader. >> >> So, they should *hire* folks to customize things to their needs? > > No. For the vast overwhelming majority of users, customization should > *not* require manually writing (or even editing) a script. See below.That only makes sense for "trivial" systems where the only things a user would want to change are "drop in" items (e.g., a ring-tone on a phone). When you want to program *behaviors*, you can't expect the way one person (or even one *class*/group of people) to behave to bear any relationship to some other group. Unless you try to build a "be all" system with umpteen "configuration options" that you grill the user about. wakeup() { #if USER_DRINKS_COFFEE power_up(coffeepot); #endif #if USER_DISLIKES_BRIGHT_LIGHT_ON_AWAKENING lights(kitchen, dim); #else lights(kitchen, bright); #endif #if USER_LISTENS_TO_NEWS_WHILE_SHAVING audio(bathroom, radio(news_channel)); #endif #if USER_SHOWERS_IN_MORNING hot_water_heater(on); #endif ...>>>> Or, do you just exclude them from that technology? >>> >>> No. I expect blind and deaf to be abe to use things, but I don't >>> expect any non-technical person (~95% of the population) to be >>> programming them. >> >> I think that is changing. Things are getting too complex for a >> "one size fits all" approach to all users. > > I didn't say anything about "one size fits all". I said the vast > majority of people should not be programming - an understatement to be > sure.I don't think that's the case, anymore. How many appliances require some sort of "customization"? How does a blind user configure his wireless router? Firewall? "Program" his TV/cable box/DVR/XM radio? (do they even *have* provisions to present data in a non-visual form?) We were looking at refrigerators the other night. How would I know the current temperature setting -- *buy* a talking thermometer and leave it in the frig for a while?? How would I know if the "extra compartment" was currently configured as a freezer, refrigerator or "soft freezer"? Everything is getting more "customizable". And those customizations are becoming more *dynamic* in nature. It's not just a "set and forget" sort of thing.> The best way I have seen has been "menu" [includes icons] driven UIs > that let people select functions and point out data to operate on, and > then generate the script.Yes, that's how my *interactive* user interface works. Because menus can be easily presented in various output modalities (speech, haptic, visual, etc.).> They can't guarantee the script will do > what the user wants, but they can guarantee that it is free from > stupid errors. Combined with operations that are intrinsically safe, > this is a good way to allow user customization. > > It is, however, more heavyweight than a telnet session with a line > editor. > >> "Non-programmers" already write macros in Excel, Word, etc. >> And, even write VB scripts "without formal training". I don't >> think it a stretch to assume they'll be able to "code" these >> sorts of things -- esp if there are very high level abstractions >> at their disposal. > > Actually, the ability to write a Word or Excel macro says absolutely > nothing about the ability to write, e.g., a correct shell or Python > (or whatever) script.Of course! But, PREVENTING them from writing a script -- or, typing in a script that is read to them over the phone by one of their friends/colleagues/etc. -- isn't a solution. And, relying on a "language" that is prone to casual errors (e.g., "==" vs. "=" bites "experienced programmers"!) just makes the problem worse. When you discuss a piece of code with a colleague, do you pronounce every punctuation mark? Chances are, you adapt your presentation (discussion) style to your expectations of the other party's capabilities. Limbo, for example, forces me to distinguish between ':', ':=' and '=' far too often. Even when the person I'm talking too can *see* what I've just described ("Hmmm... where did you *declare* x? I guess this 'x =' should really have been an 'x :=') In the past, I would often "proof" PCB layouts against schematics with colleagues (in the days when we did this sort of stuff by hand -- with tape and rubilyth). One of us would trace signals on the schematic while the other traced foils on the layout. If I was confident in the abilities of my "counterpart", I'd say something like: "D1 to C5 to J1 pin 3" for a particular signal/foil path. If I *wasn't* confident in their abilities, I'd be far more explicit: "cathode of D1 to anode of C5 and on to pin 3 of J1" When you're dealing with a "casual user", you have to be more explicit -- OR, use a language that doesn't introduce "unspoken" items into the dialog (e.g., punctuation, whitespace, etc.).> When a macro barfs, you can reload the file and > try again. When a script barfs, it may destroy the data it was > manipulating. Every day businesses suffer lost data and lost > productive hours due to amateurs writing "programs".Sure! But that's usually because they don't have the ability (and inclination) to easily and thoroughly *test* what they've written! Or, do so in a "safe" manner. And, is compounded by folks trying to do too much *in* a "program" (contrast this with my "bedtime()" script).> *Your* scripting language may be intrinsically safe, but that doesn't > invalidate my point.The whole move towards the "safer" programming environments (and those are really only intended for "REAL" programmers) indicates that programs can't continue to be intricate, error prone creations. The system designer/implementer(s) have to consider the abstractions that they present to the "user" (programmer?) to maximize the chances of the user "getting it right". E.g., I don't expect folks to write SQL to extract the information they require from my DBMS. Rather, I provide a more abstract interface that focuses on what the user (of that particular dataset) is likely to want to do to/with that data. answer_phone() { result = lookup(phone_book, calling_number); case result { "friend" => reply("Don's not home, right now. Leave a message.") "employer" => reply("Don's on the can! Could he call you back?") "SO" => reply("I'm on my way! See you soon!") "police" => reply("No habla ingles") * => play(Disconnected_Pipe_tones) voice(Generic_Telephone_Operator_Lady) reply("We're sorry. The number you have dialed is no longer in service. Please check the number and dial again." log(phone_log, calling_number, time) } } By way of example, there should be no need to specify a "time" argument in the log() invocation; it should automatically stamp each message with the time the function was invoked (as that's *probably* of interest to anyone using the facility). Note that this code fragment has lots hiding *behind* it. But, none of that stuff should be of concern to the person writing it! Nor is it an unusual desire for a typical user (though his choices of categories and associated actions may vary). It's no different than someone posting a message here (or in a forum) asking "how do I configure my FOOMATIC2000?" Or, "How do I fix this problem with that piece of equipment?" etc. You don't have to (necessarily) *know* how the code works -- and certainly don't have to know how to write it "from scratch" (many "programmers" can't work from a blank sheet of paper!). But, you should be able to "type it in" without stumbling over "invisible" symbols/punctuation...
Reply by ●March 20, 20152015-03-20
On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <this@is.not.me.com> wrote:>On 3/19/2015 2:52 PM, George Neuner wrote: > >When you want to program *behaviors*, you can't expect the way one person >(or even one *class*/group of people) to behave to bear any relationship >to some other group. > >Unless you try to build a "be all" system with umpteen "configuration >options" that you grill the user about.That's why there are AI systems that learn by doing. You don't ask anything, just monitor and see what repetitious behavior falls out.>>> ... Things are getting too complex for a >>> "one size fits all" approach to all users. >> >> I didn't say anything about "one size fits all". I said the vast >> majority of people should not be programming - an understatement to be >> sure. > >I don't think that's the case, anymore. > >How many appliances require some sort of "customization"? How does >a blind user configure his wireless router? Firewall? "Program" >his TV/cable box/DVR/XM radio? (do they even *have* provisions to >present data in a non-visual form?)This may sound insensitive, but I rather doubt many blind users configure these things much at all. I have a very good friend who is almost completely blind ... he perceives only light and dark ... and I see where he adapts the surroundings and where he adapts *to* the surroundings. My brother-in-law teaches at a school for the disabled. Some of his students are blind, some are deaf and most have other disabilities as well. I have seen much the same behaviors there ... they learn to deal with things as they are introduced to them and don't mess around too much. Despite that, they accomplish a great deal. Might they accomplish more if their surroundings were more individually friendly? Probably. OTOH, if they walk into something because it was "customized" for someone else, they might get hurt. And if they sit down to a computer that is customized for someone else, they might be unable to do anything at all. So it's a trade-off: standardize the environment and everyone can do something. Customize it and perhaps nobody can do anything.>We were looking at refrigerators the other night. How would I know >the current temperature setting -- *buy* a talking thermometer and >leave it in the frig for a while?? How would I know if the "extra >compartment" was currently configured as a freezer, refrigerator or >"soft freezer"? > >Everything is getting more "customizable". And those customizations are >becoming more *dynamic* in nature. It's not just a "set and forget" >sort of thing.And my question to that is "who the hell needs that?" For 250 years [the "refrigerator" was invented in 1755], the refrigerator was a dumb box and it worked just fine. Despite what some people think, every goddamn thing does not need a computer brain, and for most people the majority of things need very little in the way of customization.>When you discuss a piece of code with a colleague, do you pronounce >every punctuation mark? Chances are, you adapt your presentation >(discussion) style to your expectations of the other party's capabilities.I don't recite a piece of code to anyone - they look at it themselves. Likewise no one recites code to me - I look at it myself. I used to know a vision impaired programmer who used a braille reader and keyboard. I never worked directly with him, but he worked very much like I did (and do): when he collaborated with other people they would pass code back and forth with markup and comment. I doubt there are even a handful of people who could successfully write a non-trivial program via voice reader: it is too much context to hold onto. It is said that Stephen Hawking could hold and manipulate all the equations in his head. But he is a genius - most people are not.>When you're dealing with a "casual user", you have to be more >explicit -- OR, use a language that doesn't introduce "unspoken" >items into the dialog (e.g., punctuation, whitespace, etc.).Show me a language with no (equivalent of) whitespace. It's a fallacy to think that you somehow are reducing complexity by renaming what you consider to be "cryptic" symbols. It doesn't matter whether the symbol is represented by the character '=>*' or the word 'arrow-star' ... the person using it still has to understand what it means. And to repeat myself - why are you reciting it over the phone? Send a goddamn fax, or an email, or a tweet, or a text message and let them "read" it (for some definition of "read") for themselves.>The whole move towards the "safer" programming environments (and those >are really only intended for "REAL" programmers) indicates that programs >can't continue to be intricate, error prone creations. The system >designer/implementer(s) have to consider the abstractions that they >present to the "user" (programmer?) to maximize the chances of the >user "getting it right".That's one way to look at it. The other way is there are a whole lot of people who are charitably called "programmers" and who would be doing the world a favor if they did something else. This isn't going anywhere. We should just agree to disagree. George
Reply by ●March 20, 20152015-03-20
On 20/03/15 07:38, George Neuner wrote:> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <this@is.not.me.com> wrote: > >> On 3/19/2015 2:52 PM, George Neuner wrote: >> >> When you want to program *behaviors*, you can't expect the way one person >> (or even one *class*/group of people) to behave to bear any relationship >> to some other group. >> >> Unless you try to build a "be all" system with umpteen "configuration >> options" that you grill the user about. > > That's why there are AI systems that learn by doing. You don't ask > anything, just monitor and see what repetitious behavior falls out. > > >>>> ... Things are getting too complex for a >>>> "one size fits all" approach to all users. >>> >>> I didn't say anything about "one size fits all". I said the vast >>> majority of people should not be programming - an understatement to be >>> sure. >> >> I don't think that's the case, anymore. >> >> How many appliances require some sort of "customization"? How does >> a blind user configure his wireless router? Firewall? "Program" >> his TV/cable box/DVR/XM radio? (do they even *have* provisions to >> present data in a non-visual form?) > > This may sound insensitive, but I rather doubt many blind users > configure these things much at all. >The reality is that very few users of any sort configure these things. I'd guess that something like 95% of households in developed countries have a firewall/router device. And I would guess that 90% of these have never configured or customised anything on them beyond the bare minimum of picking a wireless SSID and password by following the "getting started" instructions. And well more than half of /those/ will have been set up by a friend, other family member, or the neighbour's teenager. The great majority of people don't need "customisation" - they need things to work out of the box. And for the little that needs done, such as setting the time on the VCR, why would you need a special interface for blind people or other disabled users? They can do what most other people do - ask someone for help. (This is not being callous - we all have things we can do ourselves, and things we need help for. I can configure firewalls, but if something goes wrong with the car I ask my car-enthusiast neighbour or take it to the mechanic.) (I've snipped the rest of your post, because I only wanted to add this one comment. But it was a very interesting and informative post - I'm glad Usenet has no "like" or "+1" button, but if it did, it would have got one from me.)
Reply by ●March 20, 20152015-03-20
Hi George, On 3/19/2015 11:38 PM, George Neuner wrote:> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <this@is.not.me.com> wrote: > >> On 3/19/2015 2:52 PM, George Neuner wrote: >> >> When you want to program *behaviors*, you can't expect the way one person >> (or even one *class*/group of people) to behave to bear any relationship >> to some other group. >> >> Unless you try to build a "be all" system with umpteen "configuration >> options" that you grill the user about. > > That's why there are AI systems that learn by doing. You don't ask > anything, just monitor and see what repetitious behavior falls out.So, release a product that assumes *nothing* and let EVERYONE deal with the learning issue? (i.e., why tailor a "default release" to one group over another? Do you canvas the entire market and figure out what the "best" group to target is *likely* to be? What if they don't end up being the *actual* customers?)>>>> ... Things are getting too complex for a >>>> "one size fits all" approach to all users. >>> >>> I didn't say anything about "one size fits all". I said the vast >>> majority of people should not be programming - an understatement to be >>> sure. >> >> I don't think that's the case, anymore. >> >> How many appliances require some sort of "customization"? How does >> a blind user configure his wireless router? Firewall? "Program" >> his TV/cable box/DVR/XM radio? (do they even *have* provisions to >> present data in a non-visual form?) > > This may sound insensitive, but I rather doubt many blind users > configure these things much at all.Because they *can't*. A "display reader" (i.e., decode N-digit 7-segment displays) has been high on the wish-list of many blind/VI folks for many years. What's that digital clock say? How much time is remaining on the count-down timer on the microwave oven? (when will my biscotti be ready to come out of the oven?)> I have a very good friend who is almost completely blind ... he > perceives only light and dark ... and I see where he adapts the > surroundings and where he adapts *to* the surroundings.I'm sure he doesn't let others arrange *his* surroundings and then learns what they are! Anything he has control over he undoubtedly opts to arrange himself.> My brother-in-law teaches at a school for the disabled. Some of his > students are blind, some are deaf and most have other disabilities as > well. I have seen much the same behaviors there ... they learn to > deal with things as they are introduced to them and don't mess around > too much.Again, because they are *forced* to do so! Look at how long it has taken to get *money* that can be resolved without visual cues: all paper money here is the same size, same basic color. And that's something that's essential to "living"! You will also see that people address disabilities differently depending on when they encounter them in their life. E.g., blind from birth is different that losing vision to diabetic retinopathy, macular degeneration, etc. Folks who lose their vision later in life tend to have no real recourse: too late to learn braille (and neuropathy from e.g., diabetes, can make it too difficult to gain the tactile sensitivity to resolve braille) to any effective degree. If you lost your vision *today*, would you suddenly be incompetent as a programmer? Could you not "visualize" code fragments in enough detail to compose a working script *if* you could see what you were "writing"? People losing their (central) vision later in life end up "dealing with" the loss -- by simply realizing it *is* a loss; gone along with the things that relied upon it (reading, driving, setting the household thermostat, etc.)> Despite that, they accomplish a great deal. Might they accomplish > more if their surroundings were more individually friendly? Probably. > OTOH, if they walk into something because it was "customized" for > someone else, they might get hurt. And if they sit down to a computer > that is customized for someone else, they might be unable to do > anything at all. So it's a trade-off: standardize the environment and > everyone can do something. Customize it and perhaps nobody can do > anything.So, all computers should be standardized? Anything that *could* be customized *shouldn't* -- because it wouldn't be a uniform interface for *all*? Perhaps the seats in cars should all have their adjustment disabled? Or, at least forced to be located in a particular location so folks can access them "universally"? Perhaps automatically returning to some "default" position when they sense the occupant getting off? That's just silly. What you want is to tailor customizations to individuals. E.g., *my* house should be set up for *my* needs; not those of some "nominal occupant". When we have house guests, we don't expect them to *know* where the clean linens are located. Or, where the trash basket in the *kitchen* is located (is it behind *this* cabinet? Or, *that* one? Or, perhaps somewhere else entirely??) or the clean glassware/dinnerware, etc. Yet, no one has ever died of thirst, here, for want of a drinking glass. Or, come wandering out of the shower au naturel because they couldn't find fresh towels. My solution is to tie the customizations *to* the individual. So when *I* interact with it, it behaves as *I* expect it to behave. Yet, when another person standing beside me interacts, it reacts *differently* -- as *they* expect.>> We were looking at refrigerators the other night. How would I know >> the current temperature setting -- *buy* a talking thermometer and >> leave it in the frig for a while?? How would I know if the "extra >> compartment" was currently configured as a freezer, refrigerator or >> "soft freezer"? >> >> Everything is getting more "customizable". And those customizations are >> becoming more *dynamic* in nature. It's not just a "set and forget" >> sort of thing. > > And my question to that is "who the hell needs that?" For 250 years > [the "refrigerator" was invented in 1755], the refrigerator was a dumb > box and it worked just fine.Then why aren't we all waiting for routine deliveries of *ice* (for our "ice boxes")? Refrigerators have, for years, allowed the temperature of the freezer and refrigeration compartments to be independently set (within reason). I've owned refrigerators that allowed the butter compartment to have yet another setting! Newer refrigerators add a third compartment that can be used as additional freezer space, refrigerator space or something between the two extremes. (i.e., an extra evaporator is added along with another set of controls for it) The *coming* refrigerators (as well as other appliances) go beyond this and actually try to track *consumption*: "You're out of milk!" How much of this is toy vs. utility? <shrug> How much is carrying a phone in your pocket a "toy" vs. "utility"? While I don't need an appliance to prepare my weekly shopping list, it sure would be nice if, on an unexpected stop at the grocery store, I could check to see if I had any broccoli on hand so I could exploit the unannounced sale on flank steak (sure don't want to buy *more* broccoli if I don't need it! OTOH, would be chagrined to return home and discover I had none and now need to make another trip out if I want to prepare "beef with broccoli") Should I, instead, discipline myself to ALWAYS carry a list of my "foodstuffs inventory" on hand just in case the need arises? Or, shrug it off and just resolve myself to making another (avoidable) trip back to the store?> Despite what some people think, every goddamn thing does not need a > computer brain, and for most people the majority of things need very > little in the way of customization.Sure! We can settle on a standard layout for furnishings in our homes, a standard placement of items in kitchen cupboards/drawers, a standard set of TV channels on all sets, ditto for radio stations, etc. Imagine how much easier it would be to know you just had to hit "next station" 7 times to get to the station you *prefered* -- instead of having a "favorite" -- REGARDLESS OF WHOSE HOME YOU WERE IN! Homes should all be heated to 70F and cooled to 80F. These temperatures should be in place over the period M-F7A-10P and allowed to drift lower/higher by no more than 5 degrees during the "sleep hours". Everyone should work 9A-5P lest they find themselves working when the HVAC assumes they are asleep. We should all listen to the same music and in the same sequence. Heck, maybe at the same *times* (so you would know what time to tune in when you want to hear a particular song). All phones should be black. No need for wallpaper on computer screens. All text should be displayed in courier -- and the same size! Newspapers (electronic or otherwise) should all be read in a fixed sequence. All articles should be read in their entirety (no need for bookmarks).>> When you discuss a piece of code with a colleague, do you pronounce >> every punctuation mark? Chances are, you adapt your presentation >> (discussion) style to your expectations of the other party's capabilities. > > I don't recite a piece of code to anyone - they look at it themselves. > Likewise no one recites code to me - I look at it myself.Then you're dealing with sighted people who are "connected" to your source code in some way. You;ve never had to dictate a code fragment to someone on a field service call across the country.> I used to know a vision impaired programmer who used a braille reader > and keyboard. I never worked directly with him, but he worked very > much like I did (and do): when he collaborated with other people they > would pass code back and forth with markup and comment.Did you ever *look* at his "display"? Ever ask him what he would change *if* he could change it? I.e., if he wasn't "forced" to "adapt to it"? A standard braille line is 40 cells. For *text*, this can be comparable to a written line of text -- Grade 2 braille supports lots of contractions that economize on space (along with reading and writing effort). Grade 1 braille would mean you have LESS THAN 40 "(text) characters" available as a character maps to one (or two) cells. A '[' requires 2 cells to represent. Amusingly, the *same* 2 cells are used to represent ']'. The same applies for '(' and ')'! OTOH, open and close single quotes have different representations. As is the case for open/close *double* quotes. Curiously, single quotes take 2 cells while double quotes take *one*. And "ditto" marks differ from each of the above (though require 2 cells). Apostrophe and "accent" differ from all of the above. Decimal point is not the same as "period". Numbers are introduced with a special "number follows" sign (which eats a cell). *Individual* uppercase letters are preceded with an "uppercase" sign (another cell). Strings of uppercase letters are introduced with a different sign (two cells). So, mixed case identifiers get long, fast. Expressions with parenthesized subexpressions and array references? <frown> There's no '_' representation. And, forget about "indent level"! Waste a cell on each layer of indent?? (actually, the rule is to indent *two* cells per level) :< "Math braille", "Computer braille", "Grade 2 braille", etc. Then, we can address 8-dot cells -- which use a different set of rules for encodings (and, which might not be available on all braille displays -- unless designed with that in mind!). The following: /* This is one comment */ struct alist *xp, *findit(); EACH fill an entire braille "line" (ignoring the indent). Most braille displays are *one* line! This: www.cbsnews.com/VIDEO/TV/1503/10/newsitem/some_silly_video.mov takes *6* lines to represent! (in "print", a braille "page" consists of 25, 40-cell lines on SINGLE SIDED -- think about it -- 11x11.5 paper) The point of all this "silly detail" is to show you the consequences of "adapting to" an existing "system" that was conceived without its impact on this form of representation. Creating a scripting language with the same ARBITRARY ignorance of these issues leads to results that are just as clumsy! You may want to *candidly* inquire of your blind programmer friend just what its like dealing with the limitations of his output device. And, ask him to think about what he *wished* he could impose on the writers of any code that he's had to read/modify over the years. If he thinks about it AS IF he really *had* that capability, you'll be surprised at what issues come up! [I did this with blind, deaf, physically handicapped, etc. users many years ago. The biggest problem with those interviews was getting folks to shed the "I have to adapt" mentality that has been bred into them -- because they *have* no choice! Ask them what things would be like if *they* could write the "rules" and you end up with an entirely different set of criteria! E.g., one that surprised me from a blind user was wanting products that don't "look blind"... i.e., look like they were assembled from off-the-shelf components -- a consequence of low production volumes and avoidance of high tooling costs -- in someone's GARAGE! "Make it look sexxy!" "Make it easy to clean (because it's going to be in my hands a lot and get dirty/greasy from all that handling... AND, I am unlikely to SEE just how 'disgusting' it LOOKS -- to sighted folks around me!"]> I doubt there are even a handful of people who could successfully > write a non-trivial program via voice reader: it is too much context > to hold onto.You can't be serious? *You* couldn't write one of the scripts that I've described, here? I imagine it would take you just a few minutes... even dealing with the "audio navigation" issues!> It is said that Stephen Hawking could hold and manipulate all the > equations in his head. But he is a genius - most people are not.Actually, what you learn to value most (with blindness) is MEMORY! You can't "verify" something "on inspection" so have to REMEMBER how you left it. And, discipline yourself to leave it the same way each time (to reduce the number of things that you have to remember). "Which is the blue shirt that goes best with those black slacks? And, where the hell *are* those slacks??" This makes blindness late in life doubly troublesome -- memory tends to get worse with age; esp STM. (i.e., where you kept the scissors when you were a CHILD doesn't help you remember where you left them YESTERDAY!)>> When you're dealing with a "casual user", you have to be more >> explicit -- OR, use a language that doesn't introduce "unspoken" >> items into the dialog (e.g., punctuation, whitespace, etc.). > > Show me a language with no (equivalent of) whitespace.I meant the *significance* of whitespace. So, " " means something notably different than "\t\t" or "\t ". If someone was reading *this* to you, would you be aware of the locations of the line breaks? The dual spaces (or not!) after each "full stop"? The paragraph breaks?> It's a fallacy to think that you somehow are reducing complexity by > renaming what you consider to be "cryptic" symbols. It doesn't matter > whether the symbol is represented by the character '=>*' or the word > 'arrow-star' ... the person using it still has to understand what it > means.Of course you can reduce complexity! Information gets encoded in data in a variety of ways. For example, a language that implicitly terminates each statement/line at the '\n' doesn't ALSO need an explicit line termination (e.g., ';'). A language that doesn't allow expressions like: A = B = C = D = 4 + 3 means the "reader" need not be prepared for a second (third, fourth, etc.) '=' after encountering the first. A language that encodes data type in the (required) identifier itself omits the need for explicit type declarations (e.g., FORTRAN i,j,k). The statement: A := 3; "reads" with a lot more complexity than: A gets 3 yet encodes the same information.> And to repeat myself - why are you reciting it over the phone? Send a > goddamn fax, or an email, or a tweet, or a text message and let them > "read" it (for some definition of "read") for themselves.I bump into you in the store. You ask how *you* could configure *your* phone answering system to behave *like* mine. I can recite the pseudo-code I described (upstream) and, chances are, it will "make sense" to you (if you've written any code in that language). No need for me to write it down. No risk that you'll forget that I said "colon equals" instead of "equals" in some places. For an effective language, you can "visualize" the algorithm: "Yeah, that makes sense! Lookup the caller's phone number in a database (I'll sort out how to build that database as a separate project). Determine the 'contact category' for the caller. Then, conditionally execute one of several different types of actions based on that information. Maybe I'll use an if-tree... or, perhaps a 'case' (switch) statement." If the language is cluttered with lots of "magic" that the user has to remember, then there is far less chance of him getting it right "quickly".>> The whole move towards the "safer" programming environments (and those >> are really only intended for "REAL" programmers) indicates that programs >> can't continue to be intricate, error prone creations. The system >> designer/implementer(s) have to consider the abstractions that they >> present to the "user" (programmer?) to maximize the chances of the >> user "getting it right". > > That's one way to look at it. The other way is there are a whole lot > of people who are charitably called "programmers" and who would be > doing the world a favor if they did something else.No argument, there! But, that's not what's happening. You don't see employers dismissing lots of candidates and raising payscales to compete for The Good Ones. Rather, you see them trying to make use of The NotGood Ones to keep their costs low, reliance on "key" staff minimized, etc. I started this project with a bottom-feeding hardware approach: make the hardware *dirt* cheap. Compensate with cleverer software -- within the capabilities of that cheap hardware. But, the reality of the cost differential between "dirt cheap" and "cheap" made that criterion silly. With "cheap" I can make the software a lot more capable, extensible and robust. I.e., more suited to letting others extend it without breaking everything in the process. (design of OS, complexity of comms, features in scripting language, etc.)> This isn't going anywhere. We should just agree to disagree.Agreed. My goal is to show that systems *can* be accessible in more than just superficial ways. *And*, to document the costs of that accessibility in the design process! (it's not "free" as those adherents would like to believe) Or, should that be "disagreed"? :> Time for C's biscotti -- else The Big Frown come morning! :-/
Reply by ●March 20, 20152015-03-20
On 3/20/2015 2:05 AM, David Brown wrote:> On 20/03/15 07:38, George Neuner wrote: >> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <this@is.not.me.com> wrote:>>> How many appliances require some sort of "customization"? How does >>> a blind user configure his wireless router? Firewall? "Program" >>> his TV/cable box/DVR/XM radio? (do they even *have* provisions to >>> present data in a non-visual form?) >> >> This may sound insensitive, but I rather doubt many blind users >> configure these things much at all. > > The reality is that very few users of any sort configure these things.That's not the same thing as saying that there is no *need* for them to be configured/customized.> I'd > guess that something like 95% of households in developed countries have a > firewall/router device. And I would guess that 90% of these have never > configured or customised anything on them beyond the bare minimum of picking a > wireless SSID and password by following the "getting started" instructions.That speaks to a lack of education on the part of the user. And, a poor design from the manufacturer that *necessitates* such education; coupled with the realization that sxposing the user to all that complexity would PROBABLY intimidate the user (and cost the manufacturer the "sale")> And well more than half of /those/ will have been set up by a friend, other > family member, or the neighbour's teenager. > > The great majority of people don't need "customisation" - they need things to > work out of the box.No, they *want* things to work "out of the box". But, they want them to work the way *they* want them to work! E.g., the TV should receive the channels *I* want to watch (and not be cluttered up with all those extra channels in which I have no interest). But, they don't want to *pay* (much) for this -- thinking it *should* be "simple". When it (frequently) turns out that this is not the case (often because the interface was poorly designed), they either live with the "inconvenience" (and some level of "disappointment") *or* return the product and search for something more suitable (or "none") -- see below. [My first TV had a mute feature -- but one that wasn't "independent"; any other operation would unmute the audio -- so, you couldn't hit mute and browse channels. My only remedy would have been to replace the set with one that behaved as better suited *my* intended usage]> And for the little that needs done, such as setting the > time on the VCR, why would you need a special interface for blind people or > other disabled users? They can do what most other people do - ask someone for > help.(sigh) In reality, they just "do without". Do *you* LIKE asking people for help? Esp if it draws attention to your "inability/disability"? IME, people (handicapped or otherwise) are more prone to hide their ignorance/inabilities than expose them. How often do folks NOT ask *their* M.D. for clarification of those "big words" he's using to describe *their* medical condition?? Or, the side-effects/consequences of the treatment regimen being indicated? Or, alternatives?? Do they not care? "Ha! You mean you couldn't figure out how to change the wallpaper on your monitor?" [I have a neighbor whose monitor is set to a much lower resolution than it is capable -- because he didn't KNOW that there was even an adjustment available and didn't think to ask: "Gee, I've got this huge monitor but there's never enough 'room' on the screen for everything!"] Estimates (self-reported by folks in the consumer electronics industry) suggest that a *huge* portion of product returns boil down to "I can't figure out how to make this thing do what I *think* it should do". People will fidget with a device for 15 or 20 minutes and then throw up their hands in disgust: "Let's just get our money back..." [Think about that. It approaches the cost of most GENUINE *warranty* costs!] People *know* not to use the same password in more than one place; not to pick an "easy to guess" password; not to write it down anywhere; etc. And, often, the things that are "at risk" in these cases are their own *personal* property, information, etc. Yet, *setting* (or changing!) a password has got to be one of the easiest things (conceptually) to do! So, why don't people do it? Would they rather the password be picked *for* them ahead of time? Or, STANDARDIZED?? (Hey, how about "admin" or "password"?) OK, maybe they're just SUPER LAZY and can't bother to take the time to figure out how to change their password. Yet, when FORCED to change it ("password expired") -- and thus saved the effort of having to figure out HOW to do this -- they simply type in the SAME PASSWORD, again. Despite all the education AND MECHANISM telling them not to do this!> (This is not being callous - we all have things we can do ourselves, and things > we need help for. I can configure firewalls, but if something goes wrong with > the car I ask my car-enthusiast neighbour or take it to the mechanic.)Do you live with whatever station presets were set on the radio when you purchased the vehicle? Do you keep the seats in the same position as the previous driver? Surely, neither of these things poses an insurmountable issue that would prevent you from using the vehicle! Why do people insist on picking a paint/interior color for a vehicle? Or a cell phone *case*? Or, "wallpaper" for their monitor? (what's wrong with "root weave"?) Or, big icons vs. small? (Do you really think all the mechanism to support these changes/customizations was "invested" without reason?) People always want to tailor things to THEIR needs. The problem is making sure it is easy for them to do so. E.g., some DTP tools present a "fonts (typefaces)" menu as just a list of "font names". Others present the list as *samples* of each of those fonts! Both approaches allow the user to adjust the "font" to their desires ("perceived needs"). But, the first makes the task considerably more difficult (esp for a casual/infrequent user!) than the second. Devices (in this case, languages) have to be intuitive and not needlessly complicated (why do I need a semicolon here but not there?). Doing simple things should be simple. At the same time, you don't want to cripple folks who are interested and motivated in doing more.> (I've snipped the rest of your post, because I only wanted to add this one > comment. But it was a very interesting and informative post - I'm glad Usenet > has no "like" or "+1" button, but if it did, it would have got one from me.) >
Reply by ●March 20, 20152015-03-20
On 20/03/15 10:51, Don Y wrote:> On 3/20/2015 2:05 AM, David Brown wrote: >> On 20/03/15 07:38, George Neuner wrote: >>> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <this@is.not.me.com> wrote: > >>>> How many appliances require some sort of "customization"? How does >>>> a blind user configure his wireless router? Firewall? "Program" >>>> his TV/cable box/DVR/XM radio? (do they even *have* provisions to >>>> present data in a non-visual form?) >>> >>> This may sound insensitive, but I rather doubt many blind users >>> configure these things much at all. >> >> The reality is that very few users of any sort configure these things. > > That's not the same thing as saying that there is no *need* for them > to be configured/customized.True, but it means that you don't need to make it easy to configure them. And you don't need to go out of your way to make it possible to configure for those that can't do it the "normal" way (such as for blind people) - that just makes everything more costly and more difficult for everyone else. If you are making something where it is /realistic/ to expect blind people to want to configure the system, then by all means make a version that can be configured by voice or Braille. But only where it makes sense.> >> I'd >> guess that something like 95% of households in developed countries have a >> firewall/router device. And I would guess that 90% of these have never >> configured or customised anything on them beyond the bare minimum of >> picking a >> wireless SSID and password by following the "getting started" >> instructions. > > That speaks to a lack of education on the part of the user. And, a > poor design from the manufacturer that *necessitates* such education; > coupled with the realization that sxposing the user to all that > complexity would PROBABLY intimidate the user (and cost the manufacturer > the "sale")No, it shows quite clearly that the out-of-the-box defaults are fine for most people, except for setting their SSID name and password. Everything else is "advanced", for people who have extra requirements.> >> And well more than half of /those/ will have been set up by a friend, >> other >> family member, or the neighbour's teenager. >> >> The great majority of people don't need "customisation" - they need >> things to >> work out of the box. > > No, they *want* things to work "out of the box". But, they want them to > work the way *they* want them to work! E.g., the TV should receive the > channels *I* want to watch (and not be cluttered up with all those > extra channels in which I have no interest).And most people are fairly happy with the "out of the box" experience - or they fiddle with a few basic settings (like channel selection).> > But, they don't want to *pay* (much) for this -- thinking it *should* be > "simple". When it (frequently) turns out that this is not the case > (often because the interface was poorly designed), they either live with > the "inconvenience" (and some level of "disappointment") *or* return > the product and search for something more suitable (or "none") -- see > below. > > [My first TV had a mute feature -- but one that wasn't "independent"; > any other operation would unmute the audio -- so, you couldn't hit mute > and browse channels. My only remedy would have been to replace the > set with one that behaved as better suited *my* intended usage] > >> And for the little that needs done, such as setting the >> time on the VCR, why would you need a special interface for blind >> people or >> other disabled users? They can do what most other people do - ask >> someone for >> help. > > (sigh) In reality, they just "do without". Do *you* LIKE asking people > for help? Esp if it draws attention to your "inability/disability"?Either you do without if it doesn't matter, or you ask for help when it /does/ matter. Or someone else will just fix things when they are there anyway. If a person is blind or disabled, and doesn't have able-bodied visitors who are happy to sort out these small issues, then they have vastly bigger problems than the time on their VCR! You can argue all you want about how the world /should/ be, or how it is a terrible thing that people don't configure their devices. But in the real world, for the most part, people don't do much setup or configuration - they do as little as they can get away with. That applies to most "normal", able-bodied people - and doubly so for the elderly, blind, disabled, etc. Thus any time or effort spent on making it easier is mostly wasted, because the fiddlers and geeks will make changes no matter how difficult it is, and the normal people will leave it on default settings no matter how easy it is.
Reply by ●March 20, 20152015-03-20
On 3/20/2015 3:49 AM, David Brown wrote:> On 20/03/15 10:51, Don Y wrote: >> On 3/20/2015 2:05 AM, David Brown wrote: >>> On 20/03/15 07:38, George Neuner wrote: >>>> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <this@is.not.me.com> wrote: >> >>>>> How many appliances require some sort of "customization"? How does >>>>> a blind user configure his wireless router? Firewall? "Program" >>>>> his TV/cable box/DVR/XM radio? (do they even *have* provisions to >>>>> present data in a non-visual form?) >>>> >>>> This may sound insensitive, but I rather doubt many blind users >>>> configure these things much at all. >>> >>> The reality is that very few users of any sort configure these things. >> >> That's not the same thing as saying that there is no *need* for them >> to be configured/customized. > > True, but it means that you don't need to make it easy to configure them. AndThen why don't I do it the *easiest* way for me? Make everything "closed" and sell "configuration services"?> you don't need to go out of your way to make it possible to configure for those > that can't do it the "normal" way (such as for blind people) - that just makes > everything more costly and more difficult for everyone else.How does the choice of how you represent "assignment", conditionals, etc. in a scripting language make it more difficult for everyone else? Do you *care* if I say: Y = 3 instead of: Y := 3; or: Y <- 3 or: Y gets 3> If you are making something where it is /realistic/ to expect blind people to > want to configure the system, then by all means make a version that can be > configured by voice or Braille. But only where it makes sense.Only trivial things don't require configuration. How would you set up an irrigation system if you wanted it to be "zero configuration"? Put a moisture sensor at each plant? Sell those moisture sensors in different "flavors": use a cactus sensor for cacti because they have different water needs than embodied in the "tomato plant sensor"? (Isn't that just moving "configuration" to "time of purchase"?) You can make a set-back thermostat "learn" your *weekly* (not daily!) sleep/wake, home/away schedule. But, how do you tell (configure) it how to handle holidays? Days when you are home sick/vacation? Or, do you just accept the INconvenience that comes from it's "smarts" at those times? (Hmmm... it thinks I am at work so it has turned off the hot water heater. I guess I won't be showering as soon as I expected!) You can design a telephone answering system to automatically discard/inhibit incoming calls from folks whose previous calls you have (apparently) ignored. But, how do you then tell it to "forget" that fact?>>> I'd >>> guess that something like 95% of households in developed countries have a >>> firewall/router device. And I would guess that 90% of these have never >>> configured or customised anything on them beyond the bare minimum of >>> picking a >>> wireless SSID and password by following the "getting started" >>> instructions. >> >> That speaks to a lack of education on the part of the user. And, a >> poor design from the manufacturer that *necessitates* such education; >> coupled with the realization that sxposing the user to all that >> complexity would PROBABLY intimidate the user (and cost the manufacturer >> the "sale") > > No, it shows quite clearly that the out-of-the-box defaults are fine for most > people, except for setting their SSID name and password.Yet they can't seem to *do* those "simple" things? Why not design the product so it doesn't work *until* you have set these parameters? (Ah, but then you are forcing people to "do something").> Everything else is "advanced", for people who have extra requirements.Companies offer "concierge" services for items that they consider too costly to risk "getting back" (because the user couldn't figure out how to set it up as expected). These companies are effectively saying "the product was designed poorly -- but we want to ensure we can make a sale *stick*". C'mon, how hard is it to set the time on a VCR? Or, in your car? Is it really *that* much harder to plug some video cables into a TV and your cable box? Is anything beyond the power cord considered too difficult?? Products are designed with too much *apparent* complexity. So, it intimidates users before they even make their initial attempt. Complexity should expose itself only to intentional "probes"; you shouldn't be aware of it unless (and until) you *need* to be exposed to it. E.g., the irrigation controller in my system is "naively" configured like most COTS controllers: Ni minutes at time Ti on days Di for zone Zi. As such, if you already own a COTS controller, the "setup" is simply a matter of noting the times/days associated with each zone on your current controller and transcribing those values to mine. Doing this gives you *no* (added, immediate) benefit. But, it sets the "price/complexity of admission" very low. In the future, I'll be able to tell you when one of your valves is defective (stuck, open, shorted) -- which your current COTS controller can't (?) do. If you opt to also include a weather station in your deployment, then I can *save* you money (water) by noting when it's rained (or raining) and inhibiting/postponing the watering cycle. Now, Di and Ti may have changed (all the Monday events have now moved to Tuesday because of rain on Sunday, etc.). So, you can't expect the user model to remain identical to that of the (dumb) COTS controller. Yet, it's relatively easy to relate to what has happened and why. Spend some extra effort (e.g., an institution having considerable monies tied up in "landscaping") and tell me *what* is serviced in each zone and I can get even cleverer in scheduling the resource! Again, more complex -- yet still "makes sense" (to someone savvy enough to *have* this information to provide). *FORCING* all users to buy in at that level of commitment would undoubtedly intimidate many. OTOH, *not* having that capability ("you need a software/hardware upgrade") is a disservice to those folks who "started simply" and grow in their appreciation of your capabilities.>>> And well more than half of /those/ will have been set up by a friend, >>> other >>> family member, or the neighbour's teenager. >>> >>> The great majority of people don't need "customisation" - they need >>> things to >>> work out of the box. >> >> No, they *want* things to work "out of the box". But, they want them to >> work the way *they* want them to work! E.g., the TV should receive the >> channels *I* want to watch (and not be cluttered up with all those >> extra channels in which I have no interest). > > And most people are fairly happy with the "out of the box" experience - or they > fiddle with a few basic settings (like channel selection).But a TV has few "settings". The "TV" function is relatively simple and has a long history. When I was interviewing "users" before I started on this, one (blind) gentleman complained about the inadequacy of his "address book". (Cripes! It's an address book. What the hell could be wrong with something as simple as THAT??) He asked about having multiple address books. (Huh?) Turns out, he had *5,000* contacts recorded, there. (imagine sorting through 5000 names with a braille/audio interface for a particular contact!) In his case, he was servicing "clients" for his 9-to-5 and had all of their contact information recorded in this database. Splitting it into N address books would be *less* efficient than giving him a mechanism to condition which contacts are "visible" at any given time. E.g., if he happened to be in TownA servicing clients, then it would be silly to even acknowledge any contacts NOT in TownA! Additionally, he would *manually* make annotations for each client visited (or contacted via phone) to track his most recent contact date (so he would know which clients hadn't been contacted recently and could make extra effort to reach them). Of course, the "content" of each of those contacts was (manually) tracked, elsewhere. So, he spent a lot of his "work time" just navigating to the data that he needed and updating his "records". Wouldn't it be *so* much easier if he could place a call, send an email, etc. *from* that address book; have the address book record the date/time/duration of the contact; whether it was "completed" successfully or not (no one home, etc.); provide an automatic mechanism for him to add notes about the contact "then and there" (instead of having to remember/record this "elsewhere" and do the data entry at a later time) as well as leave instructions to himself as to any followup required: "Gee, it's been a busy day! Who did I visit? Did I accomplish everything that I intended to? Are there any activities that I need to schedule as a result of these contacts?" Do you provide this sort of "built-in" capability for *every* user? Do you "sell" it as a custom add-on (and spend your time customizing products one-off for your customers)? Or, do you provide a mechanism whereby the user (or someone HE selects) can implement his requirements?>>> And for the little that needs done, such as setting the >>> time on the VCR, why would you need a special interface for blind >>> people or >>> other disabled users? They can do what most other people do - ask >>> someone for >>> help. >> >> (sigh) In reality, they just "do without". Do *you* LIKE asking people >> for help? Esp if it draws attention to your "inability/disability"? > > Either you do without if it doesn't matter, or you ask for help when it /does/What happens is people convince themselves that "it doesn't matter" -- simply because they have no choice (or, no applicable help). Imagine if I took the approach of closing the design, entirely. Or, forced folks to write code in C? ASM?? Would you *ever* think the ability to *read* "wouldn't matter"? Yet, chances are, if you lose your vision *now*, you will have no choice but to rely on "talking books" or "screen readers" (you aren't going to get access to your "home owner's association newsletter" in any "accessible" form!). You might want to try playing with a screen reader some day to see just how *bad* this experience is! And, then realize how *wonderful* it is given the alternative (of being cut off from "print", news, etc.). Here: <http://www.freedomscientific.com/Downloads/> No cost -- other than your *time*. JAWS is probably the most widely recognized (highly developed?) product in use. Install it in a sandbox (if you don't trust it), turn off your monitor. And see how much you can do with it -- on websites, email, news, etc. that you would typically indulge.> matter. Or someone else will just fix things when they are there anyway. If a > person is blind or disabled, and doesn't have able-bodied visitors who are > happy to sort out these small issues, then they have vastly bigger problems > than the time on their VCR!You think these are the *only* things that these people "need help with"? Do you think they will ask their caregiver to spend what limited time they have available (due to cost for paid service or imposition on friends/family) instead of: weekly grocery shopping, trips to doctor, "companionship", etc. Increasingly, "blind" means "old". Not seeing is just one of many "issues" they face. Many have no remaining family -- or, families that have families of their own (or far away), limited/fixed income (unemployed), etc. Instead, they'll just learn to "live without"; "adapt".> You can argue all you want about how the world /should/ be, or how it is a > terrible thing that people don't configure their devices. But in the real > world, for the most part, people don't do much setup or configuration - they do > as little as they can get away with. That applies to most "normal", > able-bodied people - and doubly so for the elderly, blind, disabled, etc. Thus > any time or effort spent on making it easier is mostly wasted, because the > fiddlers and geeks will make changes no matter how difficult it is, and the > normal people will leave it on default settings no matter how easy it is.That speaks contrary to all the effort that is currently expended in most products, software, etc. Do you have a ~/.profile or ~/.cshrc? Why don't you just live with profile(5)? Why even support a system-wide profile(5) instead of hard-coding those behaviors in the shell, itself? Why have more than one choice of shells? Why have different ringtones, wallpapers, display fonts, "annunciators", etc.? Why allow a user to pick his own login name -- what's wrong with User1, User2, etc.? Yes, they do as little as they can get away with. But, they also get annoyed if they *can't* change something that they *want* to change! As I said previously, they all want it to work out-of-the-box... BUT, the way *they* want that to be, not the way some developer decided it should be! (especially when experience has taught them that developers are clueless)
Reply by ●March 20, 20152015-03-20
On Fri, 20 Mar 2015 02:38:24 -0400, George Neuner wrote:> I used to know a vision impaired programmer who used a braille reader > and keyboard. I never worked directly with him, but he worked very much > like I did (and do): when he collaborated with other people they would > pass code back and forth with markup and comment.Same here. There was a senior programmer in the department who was totally blind. He once asked somebody to teach him the light switches so he could tell by touch to turn the lights on when he was first one in, and not terrify later people when they found out they weren't alone. For fun at home he raised goats and rebuilt auto engines. He had dual braille readers and could read one text with each hand at the same time. Apparently eyes are trained to work in lock-step, but hands aren't. The point, I think, is that blind people can do excellent work if they have tools they can use. Whether the rest of us are wise enough and rich enough to create tools like those is the question. Mel.
Reply by ●March 20, 20152015-03-20
On 20/03/15 13:12, Don Y wrote:> How does the choice of how you represent "assignment", conditionals, etc. > in a scripting language make it more difficult for everyone else? Do you > *care* if I say: > Y = 3 > instead of: > Y := 3; > or: > Y <- 3 > or: > Y gets 3 >I care that it is convenient, unambiguous, and clear. I don't care if it is pronounceable. Symbols are better than letters because they stand out better in comparison to the rest of the code - thus "Y gets 3" is the only option here that does not work well as an assignment operator. (I know you like writing long posts, but most of it seemed to be rhetoric, so I snipped it.)
