Plus, do those 50% of the people tend to get lost going from place to place in their daily lives? And do members of the other 50% have a need to be able to precisely locate any of those people without maps, addresses, or street names?
I humbly submit that this is a very nice solution in desperate and ultimately fruitless search for a problem.
Do you mean to tell me that those crates of my dad's 78 rpm records sitting in my basement might actually be worth something? I was thinking about playing them on a 33.3 rpm turntable into my PC, then using Audacity to speed them up to 78, just to be able to hear the music again, and by association, remember my dad. Geeze, there must be at least a hundred of 'em down there, at least!
Google the work of philip jeck (samples on youtube) for hugely emotional use of the old sounds.
Try and get hold of an actual 78 rpm turntable, the old dansettes could do those speeds as could the cheaper separate turntables that had ceramic cartridges with two 'sides' (78/33).
Hmmmmm... I have a knee-jerk reaction to initiatives with names like "Everyone can <fill in the blank>." Everyone may benefit from being exposed to the rudiments of whatever activity you're promoting, but it is clearly, objectively, undeniably the case that no, not everyone can program, or dance, or sing, or build a curio cabinet for any personally or professionally meaningful definition of the term.
Now, it is certainly true that any fool can use a computer... Many do! But using one--or even learning by rote how to craft a Hello World program--is a far cry from being able to look at a problem and mentally break it down into computational steps, then build the program up from those steps. Until you get to the point where you're thinking computationally, I'm not convinced you can really call whatever it is your doing "programming."
Maybe I just need to adjust the onion on my belt and go yell at a cloud or two.
When I'm grinding out Cobol or Algol code (yes, I am a dinosaur), I stick with 80 columns per line. Because, for better or worse, that's all my compiler sees. One compiler squawks when a line extends beyond Col 80, another allows the use of Col 81-90 for a markid, but the standard editor doesn't grant access to those columns easily, so it's infrequently used. But if I'm using a more freely-formatted language, you can bet I'm ignoring the 80-column limit. But I'm still keeping my lines as short as possible, and even wrapping in some cases, because my code needs to be easy to read, and side-scrolling is the antithesis of reading easiness.
Also, when I was coding in PascalVS at the University of Pangaea, I distinctly recall becoming incensed one day over the fact that, while the Hollerith card provided 80 columns, the PascalVS compiler stopped reading earlier than that--maybe it only accepted 72 characters per line. That was irritating. And costly--we had to provide our own cards, and on a student budget, they weren't cheap!
FORTRAN is well known to have a 72 column limit. The reason is that the IBM 704 had a 36-bit word, and the card reader supplied only two words per row.
I looked at the nightly order-processing workflow for the regional retailer I worked for one time. I was gobsmacked to find that one section of it consisted of launching the same suite of 5-6 programs one time for each of our 25 locations. And "launching" meant setting a handful of run-time variables, executing the object, waiting for it to finish running, and examining the result.
It was fairly easy to see why this happened. That workflow was the heart and soul of the company's revenue processing, and no one wanted to touch it any more than absolutely necessary, to avoid breaking anything. So when they expanded from one warehouse to two, it made more sense to simply re-iterate the existing code with the new location id. When they added another location, re-iterate it again, and so forth.
I created a Launch subroutine, then replaced all those hundreds of lines of code with a for loop that simply called the Launch subroutine for each object needed. Then I went through the rest of the workflow and swapped in Launch calls where appropriate. Overnight, that workflow became much shorter, more readable, and most importantly, significantly more maintainable. Previously, if you wanted to change what programs were run per branch, you had to insert the launching logic in twenty-five separate spots. Now? Once.
That, my friends, is why we build functions, rather than copypasta-ing the same code over and over.
I would further refine this to, "Learning to code is like learning to write prose: Easy to learn, and easy to do, but not so easy to do well. Especially since 'well' is at least a little bit subjective." There are plenty of people who can write well, who are not commercially successful. And there are people who are commercially successful who do not write very well at all. Cough-DanBrown-Cough.
I found doing tech support for my software to be a very valuable experience. It wasn't nearly as disruptive to my coding process as some of my brethren seem to find it; perhaps because when I'm puzzling out a thorny issue, I tend to take copious notes--and let the phone go to voice mail if I think I'm on the verge of a breakthrough. And being the first person to speak to the users who have issues, you can very quickly sort out the user-education issues from the UI/UX problems.
It was also always good for a smile when a caller would ask if I was familiar with the system. I was, I would say, reasonably familiar with it. Then they'd start explaining to me how it was supposed to work. I let them, because hearing their interpretation of the system narrative gave me valuable insight into how my users' minds approached the problems that my software was intended to solve.
I also wrote my own User Guides, reference manuals, and training material. Who had better understanding of the system than I did?
I make extensive use of e-books and audio books. I especially like audio books because they make my commute bearable. But some books, which may be great stories in the dead-tree edition, are downright aggravating in the recycled-electrons edition. I'm currently listening to a story that keeps jumping back and forth between the present and the recent past, and whatever visual clues the author might have left for that, the reader is failing to convey.
eBooks have issues of their own. Most of these seem to be due to the interface, though, rather than to the format itself. 3M Cloud, for example, seems dedicated to making it as difficult as possible for me to be able to pick up my eBook and continue reading where I left off. My current book drops me at the beginning of Chapter 2 every time I open in. It has a "bookmark" capability, by which I mean I can create a bookmark--I just can't ever find it later, much less return to the spot in the book that it supposedly marks. Frustrating. But I can download and start reading a book in the middle of the night, far from home, and when my checkout period expires, the local copy automatically disappears without my having to return to the library or pay a fine for failure to return the book.
I humbly submit that this is a very nice solution in desperate and ultimately fruitless search for a problem.