As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Throughout the history of software development, it sometimes happens that some person (usually unknown, probably unwittingly) made what, at the time, seemed a trivial, short-term decision that changed the world of programming. What events of this nature come to mind, and what have been our industry's response to mitigate the pain?
Illustration (the biggest one I can think of): When IBM designed the original PC, and decided to save a couple dollars in manufacturing costs by choosing the half-brain-dead 8088 with 8-bit-addressable memory, instead of one of the 16-bit options (8086, 680n, etc.), dooming us to 20 years of address offset calculations.
(In response, a lot of careers in unix platform development were begun.)
Somewhere toward the other end of the scale lies the decision someone made to have a monster Shift Lock key at the left end of the keyboard, instead of a Ctrl key.
Paul Allen deciding to use the / character for command line options in MS DOS.
Allocating only 2 digits for the year field.
And the mitigation was to spend huge amounts of money and time just before the fields overflowed to extend them and fix the code.
Ending Alan Turing's career when he was only 42.
Microsoft deciding to use backslash rather than forwardslash as the path delimiter. And failing to virtualize the drive letter.
Actually the 8088 & 8086 have same memory model and same number of address bits (20). Only difference is width of external data bus which is 8 bit for 8088 & 16 bit for 8086.
I would say that use of inconsistent line endings by different operating systems (\n - UNIX, \r\n - DOS, \r - Mac) was a bad decision. Eventually Apple relented by making \n default for OS-X but Microsoft is stubbornly sticking to \r\n. Even in Vista, Notepad can not properly display a text file using \n as line ending.
Best example of this problem is the ASCII mode of FTP which just adds /r to each /n in a file transferred from a UNIX server to Windows client even though the file originally contained /r/n.
There were a lot of suboptimal decisions in the design of C (operator precedence, the silly case statement, etc.), that are embedded in a whole lot of software in many languages (C, C++, Java, Objective-C, maybe C# - not familiar with that one).
I believe Dennis Ritchie remarked that he rethought precedence fairly soon, but wasn't going to change it. Not with a whole three installations and hundreds of thousands of lines of source code in the world.
Deciding that HTML should be used for anything other than marking up hypertext documents.
Microsoft's decision to use "C:\Program Files" as the standard folder name where programs should be installed in Windows. Suddenly working from a command prompt became much more complicated because of that wordy location with an embedded space. You couldn't just type:
cd \program files\MyCompany\MyProgram
Anytime you have a space in a directory name, you have to encase the entire thing in quotes, like this:
cd "\program files\MyCompany\MyProgram"
Why couldn't they have just called it c:\programs or something like that?
Apple ousting Steve Jobs (the first time) to be led by a succession of sugar-water salemen and uninspired and uninspiring bean counters.
Gary Kildall not making a deal with IBM to license CP/M 86 to them, so they wouldn't use MS-DOS.
HTML as a browser display language.
HTML was originally designed a content markup language, whose goal was to describe the contents of a document without making too many judgments about how that document should be displayed. Which was great except that appearance is very important for most web pages and especially important for web applications.
So, we've been patching HTML ever since with CSS, XHTML, Javascript, Flash, Silverlight and Ajax all in order to provide consistent cross-browser display rendering, dynamic content and the client-side intelligence that web applications demand.
How many times have you wished that browser control languages had been done right in the first place?
Microsoft's decision not to add *NIX-like execute/noexecute file permissions and security in MS-DOS. I'd say that ninety percent of the windows viruses (and spyware) that we have today would be eliminated if every executable file needed to be marked as executable before it can even execute (and much less wreak havoc) on a system.
That one decision alone gave rise to the birth of the Antivirus industry.
Using 4 bytes for time_t and in the internet protocols' timestamps.
This has not bitten us yet - give it a bit more time.
Important web sites like banks still using "security questions" as secondary security for people who forget their passwords. Ask Sarah Palin how well that works when everybody can look up your mother's maiden name on Wikipedia. Or better yet, find the blog post that Bruce Schneier wrote about it.
EBCDIC, the IBM "standard" character set for mainframes. The collation sequence was "insane" (the letters of the alphabet are not contiguous).
Lisp's use of the names "CAR" and "CDR" instead of something reasonable for those basic functions.
Null References - a billion dollar mistake.
Netscape's decision to rewrite their browser from scratch. This is arguably one of the factors that contributed to Internet Explorer running away with browser market share between Netscape 4.0 and Netscape 6.0.
DOS's 8Dot3 file names, and Windows' adoption of using the file extension to determine what application to launch.
Using the qwerty keyboard on computers instead of dvorak.
Thinking that a password would be a neat way to control access.
Every language designer who has made their syntax different when the only reason was "just to be different". I'm thinking of S and R, where comments start with #, and _ is an assignment operator.
Microsoft copying the shortcut keys from the original Mac but using Ctrl instead of a Command key for Undo, Cut, Copy, Paste, etc. (Z, X, C, V, etc.), and adding a near worthless Windows key in the thumb position that does almost nothing compared to the pinky's numerous Ctrl key duties. (Modern Macs get a useful Ctrl key (for terminal commands), and a Command key in the thumb position (for program or system shortcuts) and an Alt (Option) key for typing weird characters.)
(See this article.)
Null-terminated strings
7-bits for text. And then "fixing" this with code pages. Encoding issues will kill me some day.
Deciding that "network order" for multi-byte numbers in the Internet Protocol would be high order byte first.
(At the time the heterogenous nature of the net meant this was a coin toss decision. Thirty years later, Intel-derived processors so completely dominate the marketplace it seems lower-order-byte first would have been a better choice).
Netscape's decision to support Java in their browser.
Microsoft's decision to base Window NT on DEC VMS instead of Unix.
The term Translation Lookaside Buffer (which should be called something along the lines of Page Cache or Address Cache).
Having a key for Caps Lock instead of for Shift Lock, in effect it's a Caps Reverse key, but with Shift Lock it could have been controllable.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
There are many alternative keyboards to the standard US keyboard layout (called QWERTY).
Some examples include Dvorak, (and variants like Programmer Dvorak), Colemak, AZERTY, Workman layout, etc.
Do any of these confer a benefit to typing speed, accuracy or hand/wrist-health?
And, if so, which one of these should I choose as a touch typist if I am regularly programming?
Short answer:
If you are happy with your keyboard layout, stick with it.
Long answer:
I will try and aim to make this as definitive and explanatory an answer as possible. To understand a bit where I am coming from, allow me to express my own journey through this jungle:
I am a computer science student who started out with the German QWERTZ keyboard, typing at about 100 WPM (words per minute). When that turned out to be horrendous for programming, I moved to QWERTY. Then, I got taken in by the hype and turned to Colemak. After mastering it, I discovered there was a layout optimized for programming, and switched to Programmer Dvorak. Finally, still not happy, I tried to design my own keyboard layout semi-scientifically. And finally, now, I am typing these lines on QWERTY. (To save others the trouble and pain I went through).
Therefore, I will try to argue in my answer both from personal experience as well as from scientific published data.
The main arguments for all the alternative keyboard layout hype can be summarized to three major points:
The QWERTY keyboard is slow and was designed to slow typists down.
Excessive use of QWERTY causes Carpal Tunnel syndrome and is bad for your health.
Dvorak/Colemak/< Insert alternative layout here > was optimized to increase speed/accuracy/health
Let's go through this one by one:
First, the argument that the QWERTY keyboard was designed to slow typists down is simply not true. It was nicely debunked in this question. The QWERTY keyboard was designed to stop the keys from a certain model of typewriter to stop jamming. Rest assured, we will discuss the "QWERTY is slow" myth in a minute.
Second, the ultimate argument that advocates of alternative keyboards love to use is that QWERTY causes Carpal Tunnel syndrome, because it strains the fingers.
What's amazing here is that this is actually an Urban legend which has persisted despite it being discredited. See this question here. To quote from the answer by Graeme Perrow: "It seems that using computers in general does not cause carpal tunnel syndrome, regardless of the type of keyboard."
Finally: If QWERTY wasn't made to slow typists down and doesn't cause any illness, why use another keyboard? The answer usually offered is because other layouts are faster and have the keys aligned in a "smarter" way.
We are told how much faster typists can be when they use Dvorak instead of QWERTY and how the home row of colemak offers great benefits to productivity and speed.
We are treated to an avalanche of impressive-looking percentages, of how much faster and accurate you can be on an alternate keyboard, rather than a humble QWERTY.
However, if you look at hard, scientific evidence, you find... nothing worth writing home about. Indeed, there are two very interesting posts here and here: It turns out that the (very hard to objectively measure) speed gains are a measly 2% to 4%.
This mimics what I myself have experienced: If you are a trained typist, then switching doesn't give much of an improvement. After I had finally finished my switch to Dvorak, I was still typing at roughly 100WPM. If you want to go beyond that, you have to type a lot during your day.
I believe that the reason people observe a speed-boost when they switch is that they have to retrain their muscle memory from scratch. Which, if they do diligently, is rewarded with a faster typing speed. The irony is: I conjecture that if they had "retrained" QWERTY from scratch, they would have obtained the same speed increase.
Additionally, my own error rate didn't go down with Dvorak or Colemak. It stayed around the same level. Which, again, is not dictated by the layout but by the accuracy with which one has trained their muscle memory.
Lastly, on the note of programming: It is true that for programming languages, on QWERTY the keys used often, such as {}, [], ', =, +, -, _, etc., are all to be reached with the right pinky, which drags performance down. This still is not worth the switch to something like Programmer Dvorak, however, since, especially in programming, the limiting factor is rarely typing speed (once you get above 60WPM, that is).
So given all this, there are also a few downsides to switching that I wish to elaborate:
Dvorak suffers from the huge disadvantage that all computers use shortcuts (such as the famous CTRL+C and CTRL+V) which, on the Dvorak, are in different and hard-to-reach positions. Colemak doesn't suffer from this as much, since it kept the C, V and B key positions from QWERTY. However, even with Colemak, using programs which rely heavily on shortcut use (the most notorious of these being software like vim and emacs), has to be relearned from scratch.
Switching takes a very long time. Let nobody fool you. If you were typing at >80WPM, I can tell you from personal experience that it takes months to achieve this speed again. Even if you swap only a few keys (like Colemak), it is still a painful and long process.
When you successfully switch, you will be unable to type fast on regular QWERTY keyboards anymore (take my word for it). You will still be faster than someone who doesn't use touch typing, but if you ever have to type on a QWERTY computer as an alternative typist, you will be in for some embarrassment. This can get especially hairy if it is work related.
Many alternative layouts are not nearly as standardized as QWERTY. In other words: If you use an older machine, for instance, you may find your preferred layout not installed. This is a further hassle, because then you have to get around that problem by downloading and installing the layout you chose, meanwhile having to work in a layout you can no longer use.
Thus, in conclusion, my advice is: If you are happy with your current layout, keep it. The benefits of changing are much too small to consider. Especially if you are a QWERTY typist, I recommend staying with it. It will save you a lot of hassle and annoyances.
Long story short: QWERTY was not designed for touch typing. When compared with nine other layouts, QWERTY comes in dead last in typing effort. Give other layouts a try and experience the difference.
Whether the QWERTY layout was intentionally designed to slow typists is irrelevant. QWERTY is inherently slow by design.
The ultimate argument made by alternative keyboard advocates is that QWERTY is an inefficient, sub-optimal keyboard layout and that better layouts exist that suit modern touch typing technique. Whether one subscribes to the belief that QWERTY is a contributor to carpal tunnel is another story, yet many anecdotal stories exist of people who have reduced RSI by switching.
You should use a non-QWERTY keyboard layout because a non-QWERTY keyboard layout is easier to use. Switching to Dvorak or Colemak reduces distance traveled, reduces same finger typing, increases hand alternation, increases hand balance, and optimizes performance according to finger strength. Switching to Dvorak alone reduces effort by 30% (i.e not 4% as suggested, see first link). Note that these benefits accrue over time with use. The idea that there is no benefit to switching is simply untrue. And with newer layouts such as Colemak, typists don’t have to relearn to type. 48% of the Colemak keyboard layout is identical to QWERTY. Even if one’s error rate doesn’t fall (highly unlikely), alternative keyboard layouts like Colemak remap backspace to an easier to reach spot.
Regarding said downsides:
Windows and Mac offer the ability to use familiar QWERTY shortcuts while pressing Ctrl/Cmd. Many people have devised ways for using emacs/vim while switching.
Switching can be very painless and easy considering there are websites such as keybr.com that teach how to master touch typing using Dvorak or Colemak.
Whether you can type as fast with QWERTY after switching is irrelevant. Once you switch, you are set and won't have to go back to QWERTY on your own device. Dvorak and Colemak are standards or can be easily installed on to all major operating platforms. If you are going to use others keyboards and aren’t able to switch the layouts, there are numerous online keyboard simulators.
The hassle of switching the layout on the computer is very minimal if nonexistent compared to the hassle of typing on QWERTY.
Advice: The benefits of switching are too large not to consider. You have nothing to lose by trying; if it doesn’t work out, you will always have QWERTY to fall back on. Let your keyboard work for you, not the other way around.
My two cents worth...
I switched from QWERTY to Colemak a few years back, mostly because I like to try out new things but also because I was getting a bit of RSI from all the typing I do.
I found the transition took a few months, with the first few weeks being most painful -- I took a lot of handwritten notes in meetings in this period! But perseverance paid off, I'm now typing at about 60-70 wpm, which is faster than my old QWERTY speed, and I can touch type properly, plus I don't get the RSI pains any more.
Now, much of this might be because I learned to type properly in Colemak (using programs such as GNU Typist) whereas I don't recall ever learning QWERTY properly. But I would say that Colemak definitely feels nicer on the fingers, with less movement around the keyboard for most words.
I'd also add that Colemak is supported as part of the base OS on Mac and popular GNU/Linuxs (e.g. Debian and Ubuntu), and easy to install on Windows, so would consider it fairly mainstream.
I agree with #mark-anderson I am typing on dvorak and the worst part is that shortcut keys are a pain - I use a tool for that (see my answer at https://stackoverflow.com/a/22945703/18132). Using someone else's keyboard is also a pain.
On the plus side, I can touch type and never have to look at the keyboard. actually if I look at the keyboard I get confused since the keys are in the wrong place.
Was it worth it? Not really sure. I like that I can touch type. I like that I can use qwerty shortcuts but my hand still hurts and I think I might be faster - not really sure. But I am considering switching back to qwerty - I have been dvorak for 2+ years now, so I don't really have a good reason to switch back other than to "conform" :)
I recently broke my finger and can now only type with my right hand. This has seriously impacted my typing speed. Since I write software for a living, this is a serious problem.
I have been doing some research, but haven't found a great solution yet. Here's what I've come up with:
Wacom tablet + hand writing recognition software. Is it possible to write code with hand writing recognition software?
one handed keyboards -- I have only found expensive (> $100) keyboards. These look like they have a steep learning curve.
one handed typing instructions: http://www.aboutonehandtyping.com/manualcompare.html. Does this really work?
What do the one handed coders out there use?
If you're a two-hand touch typist, the answer is a "mirrored" layout.
Mirroring lets you begin touch-typing with one hand almost immediately. Pretty crazy how easy it is. Based on the muscle memory you already have.
If you're typing with your right hand:
Type all right-hand keys normally.
Don't type left hand keys. Instead type the same motion (but mirrored) with your right hand.
So if you want to type:
"D" -> type "K" instead.
"W" -> type "O" instead.
"S" -> type "L" instead.
Same row of keyboard, same finger, same motion. Your muscle memory can already do this... kind of like how you're unable to pat your head and rub your belly at the same time. The wires in your brain are crossing somewhere.
Software to mirror the keyboard as described above:
Hold Spacebar to mirror:
Linux - MirrorBoard
Mac - Mirror-QWERTY
Windows - AutoHotkey version of Half-QWERTY Half-Keyboard
Predictive Text; Automatic Mirroring
Mac - One-Hand Keyboard
Windows - One-Hand Keyboard
Regarding one-handed keyboards, I've tried using a frogpad and found it ok for typing text, but unusable for coding. The symbols require several consecutive key presses and I found it impossible to use shortcuts reliably. It was too easy to hit the wrong key and get it stuck in the wrong mode.
Nobody has mentioned ENTI-key aka Coffee++ Layout yet? It is exactly designed for programming with one hand (left). And unlike qwerty, it is even optimized for speed and ergonomics. I used it some years ago for a short while and I don't know if it still works on newer systems. I think I used it for writing CSS: Typing the words with left, typing all those numbers on the numpad with right.
I can not recommend pen+handwriting. I usually use a tablet PC and handwriting code is terrible. I tried it on Windows 8 and Linux with Cellwriter, and both are not bad programs, but I still switch to onscreen keyboard whenever I can. But maybe the problem is my scratchy writing :)
I also can tell from experience that learning a new layout is not as complicated as it sounds. Especially if the layout is more logical than qwerty. I use Neo Layout since 10 years and getting the hang of it went smoothly, I was able to write a blog article after an evening of training.
"But what if you have to use qwerty on another PC?" This, also, is no problem, really. My simple trick is to never look at the keyboard when using Neo, but glimpse at it when qwerty-ing.
Good luck to anyone who wants to or has to use one hand for typing!
Now, the time to heal a broken finger will be shorter than it takes to adapt to one handed coding, not to mention the time it takes afterwards to get back to two-handed coding
Also, the time it takes to learn the methods is time you could've spend on coding (read: making a living).
Knowing this, we need a quick-fix, short term solution.
First of all, A good IDE, with code completion and similar functionality will help you a lot.
Secondly, use the shortcuts of the IDE, remember, there are Shift, Altand Ctrl keys on both sides of your keyboard.
(you might want to create a cheatsheet for those shortcuts)
In addition to helping you during your time with your injury, learning the shortcuts will also improve your coding speed when you're back up again.
Now, my comments on your proposals:
Don't, simply, Don't, it'll take even more time to fix writos (typos) beacause recognition will be flaky.
That learing curve will slow you down even more.
Won't even comment on that one...
Mirrorboard
A friend of mine broke his wrist snowboarding, and he had reasonable luck using speech recognition software (Nuance Dragon Naturally Speaking). It worked quite well for email and documentation, which would solve a part of your problem.
Another colleague, Nils Klarlund of AT&T, developed a version of emacs hooked into speech recognition. He even had a home-brewed set of foot pedals for doing shift, control, etc. He used this exclusively for years (due to bad carpal tunnel syndrome).
And maybe your feet can take up some of the burden. This is part of a parallel discussion going on in this question.
And off-topic, but extremely interesting, T.V. Raman, who's been blind since the age of 14, wrote a version of emacs that works with keyboard input and audio output. There's a chapter on it in Beautiful Code. I've seen him use it, and it's completely awesome. And of course emacs is a great interface for more than just text editing.
If you anticipate that your left hand will be out of commission for a long while, and if it's worthwhile for you to learn a new layout, then there exist one-handed Dvorak layouts.
There's some information at PC Guide: Single-Handed Dvorak Alphanumeric Layouts.
There also once was software for Qwerty Half Keyboards that used the space bar as an extra shift key that reversed the keyboard.
Good luck with your injury!
We have a developer in the office that lost mobility in his right hand and probably won't gain back full use of it. He has mainly learned to type well with his left hand and kind of fill in for his right hand. Although he lets his right hand kind of peck for things. He has gained enough speed back for it not to affect his day too greatly from what i can tell.
Only thing i can think of that might let you speed up some while typing with one hand and maybe being able to get a key or two with the other hand might be to use an IDE instead of text editor if you already don't, so you can use tab completion. Kind of a lame solution if you don't like IDEs or just don't have that option in your work environment but might help out a bit.
The same thing happened to me (I destroyed my left pinky). At the time, I didn't touch type, so my only use for my pinky was left-control, left-shift, and caps-lock.
This sounds as if it just happened to you. I promise you'll quickly learn to compensate. Remember, it's quality, not speed, that counts most.
Perhaps you should seize the opportunity and read to improve yourself as a programmer. Or spend some time debugging.
I consider myself somewhat familiar with Vim,
hate the arrow keys (let alone the mouse),
regularly look up tips and plugins to get the most out of this tool,
use it daily to manage my cloud servers, etc.
However, I always find myself doing the same mistakes probably inherited from the GUI-world:
too often switching to visual mode to see what piece of code I'm about to manipulate,
undoing changes to retrieve lost statements because I forget to utilize registers (and pasting code on temporary lines just to grab it after other edits),
relying on Ctrl-C & Ctrl-V when working with operating system's clipboard,
keep pressing j button to browse through lengthy files to find certain functions.
Probably my Hungarian keyboard layout prevents me from being faster as most of the special characters (/, [, etc.) are only available as a key combination (with Shift or Alt Gr).
Given this specific situation, what pieces of advice could you give me? Have you faced similar bad habits when you were a Vim-novice? I'd like to see my productivity skyrocket (who wouldn't?). Thanks in advance.
I've found a simple, effective strategy. Choose one action, one task or one set of keys that you think is unnecessarily slow. Figure out a better way of doing this using the vim manual or googling or a plugin etc. Force yourself to use this every time. Rinse, and repeat. The path to efficiency is one-by-one elimination of the slow parts.
I'd also recommend just reading the vim manual from time to time - even if you don't remember everything, knowing something's out there is very helpful.
This probably applies well beyond vim, but
something that worked for me was finding a specific feature that I knew would
be more efficient and concentrate on using that for a week or two.
Just one feature at a time, and possibly using it excessively.
After a couple of weeks it becomes automatic and you can move on to the
next thing.
I learn programming tricks the same way. eg. I'll have a month of using lambda expressions for everything, then a month of mapping and filtering.
(not on production code though)
Probably my Hungarian keyboard layout prevents me from being faster as most of the special > characters (/, [, etc.) are only available as a key combination (with Shift or Alt Gr).
I'm sitting in front of german keyboards all day long and know this problem very well. Some keyboard layouts are simply not very suited for programming / using vim. I think its safe to assume that most programming languages and keyboard shortcuts were designed with the us-layout in mind.
My advice: reset your keyboard layout to us-english and practive touch-typing on that layout (typing without looking at the keys). It won't matter that the keyboard labels are wrong and you'll be much more comfortable using vim hotkeys.
The only problem that still remains for me is to produce language specific characters (german umlauts such as ä,ö,ü) wich i assume will also be a problem for hungarian. For that I use a combination of vim-digraphs, linux window manager digraph-key and windows layout-switching hotkeys.
just keep using it. The more you use it, the better you become at it. VIM isn't too bad. The main thing is you just have to remember that it isn't always in edit mode.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
When you write something in BASIC, you are required to use line numbers. Like:
10 PRINT "HOME"
20 PRINT "SWEET"
30 GOTO 10
But I wonder: who came up with the idea to use line numbers at all? It is such a nuisance, and left quite an "echo" in the developing (pun intended) world!
The idea back then was that you could easily add code everywhere in your program by using the appropriate line number. That's why everybody uses line numbers 10, 20, 30.. so there is room left:
10 PRINT "HOME"
20 PRINT "SWEET"
30 GOTO 10
25 PRINT "HOME"
On the first interfaces BASIC was available for, there was no shiny editor, not even something like vi or emacs (or DOS edit, heh). You could only print out your program on the console and then you would add new lines or replace them, by giving the appropriate line number first. You could not navigate through the "file" (the program was kept in memory, although you could save a copy on disk) with the cursor like you are used to nowadays.
Therefore the line numbers weren't only needed as labels for the infamous GOTO, but indeed needed to tell the interpreter at what position in the program flow you are editing.
It has a loong-loong history.
Line numbering actually comes from Dartmouth BASIC, which was the original version of the BASIC programming language and was the integral part of a so called Dartmouth Time Sharing System. That DTSS had a rudimentary IDE, which was nothing more than an interactive command line.
So every line typed inside this "IDE", and beginning with a line number, was added to the program, replacing any previously stored line with the same number; anything else was assumed to be a DTSS command and immediately executed.
Before there was such a thing as a VDT (video display terminal), we old-timers programmed on punch cards. Punch cards reserved columns 72-80 for sequence numbers - if you dropped your card deck and they all got out of order, you could put the deck in a card sorter that would order the cards based on those sequence numbers. In many ways, the BASIC line numbers were similar to those sequence numbers.
Another advantage in the BASIC world is that in the old days BASIC was interpreted as it was run. Using labels rather than sequential line numbers for branches would require a first pass to pick up all the labels and their locations, where as if you use line numbers the interpreter knows whether it needs to start scanning forwards or backwards for the destination.
Back in the day you didn't have a 2 dimensional editor like emacs or vi. All you had was the command line.
Your program was stored in memory and you would type in single line commands to edit single lines.
If you were a Unix god you could do it with ed or something, but for BASIC on a C-64, VIC-20, or TRS-80 you'd just overwrite the line.
So a session might look like:
$10 PRINT "Hellow World"
$20 GOTO 10
$10 PRINT "Hello World"
And now the program would work correctly.
Some older mainframes even had line terminals without a screen. Your whole session was printed on paper in ink!
The "Who?" would be the inventors, Kemeney and Kurtz.
After reading the replies, I checked the Wikipedia entry for "Dartmouth BASIC", and was surprised to learn
The first compiler was produced before the time-sharing system was ready. Known as CardBASIC, it was intended for the standard card-reader based batch processing system.
So, it looks like Paul Tomblin "gets the square".
Paul Tomblin's answer is the most comprehensive, but I'm surprised no one has mentioned that a big part of the BASIC project's initial goal was to provide a beginner-friendly interactive environment using timesharing. (Kurtz and Kemeny's vision for "universal access for all students" was far ahead of its time in this regard.)
The BASIC system that was developed to fulfill this goal featured Teletype ASR-33 (and later other) printing terminals. When connected to a timesharing-capable OS, these allowed editing and running BASIC programs in an interactive mode (unlike working with punched cards), but they are not cursor-addressable. Line numbers were a beginner-friendly way to both specify the order of program statements and allow unambiguous editing in the absence of a screen editor. The Wikipedia entry for "line editor" explains further, and anyone who's ever tried to use a line editor (such as the Un*x 'ed') can appreciate why Kurtz and Kemeny should be thanked for sparing the beginner having to learn the cryptic command sequences required for editing text in this manner.
They originated in FORTRAN, from which BASIC was derived. However, in FORTRAN only lines referenced by other lines (like GOTO targets) needed numbers. In BASIC they had a secondary use, which was to allow editing of specific lines.
Back in the fifties, when high programming languages were in their early beginnings, there were no terminals, no editors, no monitors (yes, no monitors), just card punchers and readers (for writing and reading the contents of cards into memory of a computer) and printers (for printing results, naturally).
Later, tape was introduced, but that's another story.
Each punch card had its own number. There were several reasons for that; from purely keeping them in order, to determining the sequence of execution. Each card was one line of code (in today's terms). Since, at that time, there were no constructs like if..then..else, or whatever variant of the like, the sequence of execution had to be determined somehow. So GOTO statements were introduced. They were the basis of loops. The term "spaghetti code" comes from that time period also, since badly written code was relatively hard to follow, like spaghetti on a plate :)
I'd guess it comes from assembler, where each instruction has an address which may be jumped to by another instruction.
Additionally, the first computers didn't have much memory, and storing a line number only takes two bytes (if done properly). Writing a label takes more memory, first in the location, where that label is defined, then in any jump command.
Finally in the good old days there weren't any fancy editors. The only "editor" was a simple command line interface, which treated everything starting with a number being part of a program and everything else as commands to be executed immediately. Most prominent example should be the Commodore 64.
Newer dialects of Basic don't have the need for line numbers any longer.
in Basic, if you didn't have a line number, how can you preform a
GOTO 10
that was a way to jump lines, a good way that was found ... more than 20 years ago!
today, the lines help us catching errors/exceptions because the debug engines are made to send us in the message that we got an exception on line xxx and we jump right away to it!
imagine a world without line numbers... how can a reporter be paid without the lines?
"Now that you know the novel, you have to write a summary with no more than 50 lines"
remember this? Even at the school we learn about line numbers!
if it wasn't invented, someone will already invented again so we could use it nicely :)
Not all versions of BASIC required line numbers. QBasic, for instance, supported labels. You could then jump to those with GOTO (ignoring Dijkstra's "Go To Statement Considered Harmful," for the moment).
The answer is already above. Paul Tomblin wrote it (with a caveat to zabzonk). Actually, I would argue that any answer which does not mention "punch cards" is incomplete, if it mentions neither punch cards nor FORTRAN, it is wrong. I can say that this is definitively right because my parents both used punch cards on a regular basis (they started with FORTRAN 66 and 77), then migrated to Basic and COBOL in the 80's.
In the early days, most programs were entered with punch cards. The punch cards were usually entered in sequence, usually one instruction per card, with labels (JMP/JSR targets) being a separate instruction card.
To edit your program, you replaced the card.
Later implementations added an optional sequence number on the right end of the line, so that when/if they got out of order, they could be resequenced by an automated reader.
Fortran used both numeric target labels on the left (col 1-5) and left a reserved block on the right (73-80) for sequence or comment.
When BASIC was initially written, it was decided to move the sequence numbers to the left, into FORTRAN's label field, and to allow overwriting prior cards' memory footprint... as an editing mode. This was intended for the interactive dev environment, but worked just as well with cards. And cards were used in some early implementations for a variety of reasons.
Keep in mind: Many computers were card-reader and printer interface right through the late 1970's. Even tho' interactive mode basics were available, card punched basic programs were frequently used. Since many simply were feeding into the IDE, they worked exactly the same way. Including needing a "Run" card at the end. In such cases, one could simply tack a correction card and another Run card to rerun with a variation on some variable; likewise, in complex programs, simply adding a corrected line of a card before the run was adequate to edit out problems without spending precious time finding the errant card itself.
I like the robot church on Futurama, on the walls were written stuff like
10 SIN
20 GOTO HELL
On the Speccy you couldn't edit a line without the line number.
I find them very helpful when pairing. I don't have to point at a line when my pair has the keyboard, I can just say, "on line 74, shouldn't that really be getMoreBeer()?"
The original editor for DOS was a wonderful utility called edlin. You could only edit a single line. To make life even more interesting in many versions of BASIC you could type lines out of order, line 10, 20, 30, 25, 5, The execution would be by line line number not by the order of appearance.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Pretty much every other editor that isn't a vi descendant (vim, cream, vi-emu) seems to use the emacs shortcuts (ctrl+w to delete back a word and so on)
Early software was often modal, but usability took a turn at some point, away from this style.
VI-based editors are total enigmas -- they're the only real surviving members of that order of software.
Modes are a no-no in usability and interaction design because we humans are fickle mammals who cannot be trusted to remember what mode the application is in.
If you think you are in one "mode" when you are actually in another, then all sorts of badness can ensue. What you believe to be a series of harmless keystrokes can (in the wrong mode) cause unlimited catastrophe. This is known as a "mode error".
To learn more, search for the term "modeless" (and "usability")
As mentioned in the comments below, a Modal interface in the hands of an experienced and non-fickle person can be extremely efficient.
Um... maybe there isn't much of a need for one, given that Vi/Vim is pretty much available everywhere and got the whole modal thing right? :)
I think that it's because vi (and its ilk) already occupies the ecological niche of modal editors.
The number of people who prefer modal and haven't yet been attracted to vi is probably 0, so the hypothetical vi competitor would have to be so great as to make a significant number of vi users switch. This isn't likely. The cost of switching editors is huge and the vi-s are probably already as good as modal editors go. Well, maybe a significant breakthrough could improve upon them, but I find this unlikely.
#Leon: Great answer.
#dbr: Modal editing is something that takes a while to get used to. If you were to build a new editor that fits this paradigm, how would you improve on VI/VIM/Emacs? I think that is, in part, an answer to the question. Getting it "right" is hard enough, competing agains the likes of VI/VIM/Emacs would be extremely tough -- most people who use these editors are "die hard" fans, and you'd have to give them a compelling reason to move to another editor. Those people who don't use them already are most likely going to stay in a non-modal editor. IMHO of course ;)
Modal editors have the huge advantage to touch typists that you can navigate around the screen without taking your hands off the home row. My wrists only hurt when I'm doing stuff that requires me to move my hand off the keyboard and onto the mouse or arrow keys and back constantly.
Remember that Notepad is a modal editor!
To see this, try typing E, D, I, T; now try typing Alt, E, D, I, T. In the second case the Alt key activates the "menu mode" so the results are different. :oP People seem to cope with that.
(Yes, this is a feature of Windows rather than specifically of Notepad. I think it's a bad feature because it is easy to hit Alt by mistake and I don't think you can turn it off.)
VIM and emacs make about as much user interface design sense as qwerty. We now have available modern computer optimized key layouts (see the colemak layout and the carpalx project); it's only a matter of time before someone does the same for text editors.
I believe Eclipse has Vi bindings and there is a Visual Studio plugin/extension, too (which is called Vi-Emu, or something).
It's worth noting that the vi input models survival is in part due it's adoption in the POSIX standard, so investing time in learning would mean your guarenteed to be able to work on any system complying to these standards. So, like English, theres power in ubiquity.
As far as alternatives go, I doubt an alternate model editor would survive a 30 day free trial period, so its the same reason more people drive automatics than fly jets.
Since this is a question already at odds with the "no subjective issues" mantra, allow me to face that head on in kind.
Non-Modal editing seeks to solve the problem caused by non-modal editing in the first place.
Simply put, with Modal editing I can do nearly everything without my hands leaving the keyboard, and without even tormenting my pinky with reaching for the control, or interrupting my finger placement by hunting for the arrow keys.
Reaching for mouse completely interrupts the train of thought. I have hated the intense reliance upon this with Intellij IDEA and Netbeans for many years. Even with vim-style addons.
Most of what you do has to do with fine-tuning with very small increments and changes within the same paragraph of code. Move up, move over, change character, etc., etc. These things are interrupted with control keys and arrows and mouse.
Though not really answering your question, there used to be a "modal like" way to write Japanese on cell phones before :
The first letter you hit was a conson let's say K, and then, and then the next key you would hit would have the role of a conson. (Having two conson in a row is impossible in Japanese)
Though it was main a few years ago, today it's only used by people who really want to hit fast.
I think the answer to the question is actually there are quite a few modal text editors that aren't forks of vi/vim. However they all use the vi key bindings. Vi users get the key bindings into their muscle memory so relearning a different set of key bindings would be really hard, so no-one would create a different set of key bindings.
But lots of different editors have re-implemented the vi key bindings from scratch. Just look at this question about IDEs with vi key bindings. At least half of the answers are editors built from scratch that implement vi key bindings, not versions of vi embedded.
I recently came across divascheme - an alternative set of key bindings for DrScheme. This is modal, and part of the justification is to do with RSI - specifically avoiding lots of wrist twisting to hit Ctrl-Alt-Shift-something. The coder has done an informal survey of fellow coders and found that emacs users suffered from more wrist pain than vi coders.
You can see him doing a short talk at LugRadio Live USA. (The video is a series of 5 minute talks and I can't remember how far through it is, sorry - if someone watches it and posts that here I'll edit this post to say when in the video it is).
Note I have not used divascheme.
The invention of the mouse took one mode and moved it to an input device, and context menus took another mode and moved it to a button. Ironically, the advent of touch devices has had the reverse effect, producing multi-modal interfaces:
aware multi-modal - touch and speech are aware of each other and intersect
unaware multi-modal - touch and speech are unaware of each other and conflict
The traditional WIMP interfaces have the basic premise that the information can flow in and out of the system through a single channel or an event stream. This event stream can be in the form of input (mouse, keyboard etc) where the user enters data to the system and expects feedback in the form of output (voice, vibration, visual, etc) when the system responds. But the channel maintains its singularity and can process information one source at a time. For example, in today’s interaction, the computer ignores typed information (through a keyboard) when a mouse button is depressed.
This is very much different from a multimodal interaction where the system has multiple event streams and channels and can process information coming through various input modes acting in parallel, such as those described above. For example, in an IVR system a user can either type or speak to navigate through the menu.
References
User Agent Accessibility Guidelines working group (UAWG): Keyboard Interface use cases
W3C Multimodal Standard Brings Web to More People, More Ways
Next steps for W3C work on Multimodal Standards
The Future of Interaction is Multimodal
Beyond Mouse and Keyboard: Expanding Design Considerations for Information Visualization Interactions - naturalinfovis_infovis2012.pdf
Setting the scope for light-weight Web-based applications
Jan. 26, 1983: Spreadsheet as Easy as 1-2-3
Multi-modal design: Gesture, Touch and Mobile devices...next big thing? | Experience Dynamics