Bill Joy's greatest gift to man – the vi editor
theregister.co.uk
theregister.co.uk
> "So you didn't really write vi in one weekend like everybody says?"
> No. It took a long time.
Nearly every day I come to this site and skim past headlines resembling "Check out my weekend project!" or "Look at the awesome business idea I put together in 12 hours!!"
While I understand there can be a great sense of accomplishment to come up with an idea and pull it together in a short amount of time, I far more appreciate projects that people have dedicated months and years of their lives to.
Forget weekend whims. Dedicate yourself to an interesting project for 6 months or a year and then tell me what you've learned. You may suddenly find yourself in high enough demand that you're no longer able to spare the weekends to waste on something to show off on HN.
To me at least, they seem like people taking a shotgun approach to starting projects and hoping that one of them will stick and become popular without having had to expend much effort on it. Interesting problems take more than a weekend to solve.
They take a weekend to discover.
Edit: For an example, see Gumroad, which was launched on HN as a weekend project[1], then improved and got Techcrunch coverage months later[2].
Six months is nice if you have the time, but what if you suddenly run out of it halfway through? What can you deliver? A broken mess or only a subset of the functionality?
http://www.whitemagicsoftware.com/software/climate/guru.shtm...
*Lessons learned: R is a phenomenal language for statistical analysis. Do not underestimate the power of StackOverflow to help solve complex problems. The PostgreSQL database has superb language support. Integrating third-party data sources takes longer than you think; inserting 270 million records into a database takes a lot of preparation to execute correctly.
Whenever I hear that someone whipped up an impressive piece of code in a weekend or in an hour, I am skeptical.
Time passes quickly when you're doing work that you love. Since you're not tracking the time, what seemed like a brilliant 10-minute hack may have taken an hour.
My rule of thumb--based on personal observation--is to multiply by 5 to get a truer estimate of how long an impressive programming project must have taken. And when speaking to a lawyer or bureaucrat, I need to divide by 8.
When I make something really new, I don't consume time, I consume a mix of energy, enthusiasm, slowly built mind patterns and ideas, diverse epiphanies and cultural chocks, all of which took much more time to grow that the hours or days that I spent typing.
Most of my interesting software were born from a few weeks of unfocalized and undedicated thinking, a few hours (usually at nights) of precise writing in my head, followed by days or weeks (sometimes months of a 5 devs teams) of coding which, while it was hard work, seemed to be simply the transfer of an initially complete program from head to disk.
Of course this is somewhat an excessive view but it's really hard to link time (especially "working" time) to the produced software. I'm sure a lot of people here were sometimes in the impression that there were a few hours or days in their coding life that were worth years.
> Many of the ideas in ex's visual mode (a.k.a. vi) were taken from other software that existed at the time. According to Bill Joy,[2] inspiration for vi's visual mode came from the Bravo editor, which was a bimodal editor. In an interview about vi's origins, Joy said:[2]
> > A lot of the ideas for the screen editing mode were stolen from a Bravo manual I surreptitiously looked at and copied. Dot is really the double-escape from Bravo, the redo command. Most of the stuff was stolen. There were some things stolen from ed—we got a manual page for the Toronto version of ed, which I think Rob Pike had something to do with. We took some of the regular expression extensions out of that.
And fortunately for those of us in the modern world, we have vim.
* Yes, I know this is a bit of an oversimplification.
That said, I am sorry for bringing up software patents, cause usually the topic generates more heat than light, and I hate reading the inevitable screeds, too. It was early, I'd had no coffee, and the brain wasn't working.
As for BSD a search of my (partial) ports tree finds 19326 Makefiles of which 102 contain the string github. Thats 0.5 percent, which tends to argue against your claim.
That's just the easiest measure I have at hand. Would be interested in others and their findings.
I don't mean my mom, but I do mean to imply (without evidence) ordinary non-Norvig coders who aren't steeped in Unix lore.
Does ports really do what Github does, or does it do what apt/rpm/yum/pacman/etc do?
The ports tree is for handling distribution of compilable/installable software for the platform, and you synch it from a server, then build. It's not really intended to promote the branching and modification, and social aspects that github does.
Stealing, for me, is taking someone else's _stuff_, and arguments about IP law come down to arguments over the definition of "stuff" and who "owns" it.
Which is absurd and obviously something that shouldn't be patentable, but in my view, so is 1-click shopping on a website.
Don't forget teco. I believe teco was the most popular editor, in unix, before vi.
Edit: I was under the impression that 1 baud = 2bps because I saw this wikipedia page http://en.wikipedia.org/wiki/List_of_device_bit_rates . I was wrong.
Back in The Day, 300 baud translated to 300 bits per second, but "as modem technology advanced, compression and other techniques were able to get higher bit per second transfer rates without a corresponding linear increase in state changes. Baud became an outdated term because it wasn’t able to accurately and proportionately express transfer rates, so bps became the standard."[0]
There is some more in-depth information about what "as modem technology advanced" means on Wikipedia[1]. Interesting stuff.
_____
So each baud carried one bit, and we got used to equating 300 baud with 300 bps. Then came 1200 bps modems, which sent two bits per symbol (four discrete tones, IIRC); they were technically 600 baud modems. It got more complex from there. And thus the confusion began; trying to tell people they had a 600 baud modem was about as useful as trying to tell them it's really called GNU/Linux.
Nooo, then came 1200-75 asymetric modems - 1200 baud down, 75 baud up - sez the fellie that used to use edlin on the DEC Vax :(
Baudot is also the 5-bit code you see on some paper tapes.
I wanted to use Emacs on my guest account on the MIT PDP-10s to do my editing of school projects, so I could FTP and compile them on NBS-10's Pascal compiler, print out the results in the machine room at NBS, drive 20 miles, and hand in the work.
Rather than use punchcards. /Now/ you understand. Anything but that.
To make Emacs usable at 300 baud, I wrote a SUPDUP terminal emulator. SUPDUP was an abstract terminal type that MIT Emacs understood internally. It sported character and line insert/delete, and region scrolling, and it made the screen update tolerable.
It's hard to convey the electric sense of an editor that self-inserted characters. The productivity boost was amazing. It was worth all the effort, and I'm sure I was having a lot more fun than the other poor sots at the U who were having to line up for keypunch machines and deal with two-hour job turnarounds.
Ironically, 130K is tiny todya, but more than half the address space of a PDP-10 :-)
Are you kidding me? Only vi is much faster than I can think. I still have to wait for Eclipse. Hence, I use vi, because there's too much friction in waiting for my editor. I find that I miss lots of the convenience features of Eclipse, but when I can alrady get productive in vim by the time Eclipse has loaded, it's too easy to just work in vim.
I picked up vi because I was stuck doing development over SSH from my college's public computer lab when my PC died. I stayed because once I'd learned the keystrokes, it really was a pretty decent editor. I think that Eclipse/TextMate/Gedit/etc. have some nice points and are definitely better in some respects (like, say, visual presentation), but vi is Good Enough and available basically everywhere.
I probably should learn a bit more.
I could name a very long list of things that are ubiquitous, yet are not nice at all.
However, when developing locally on a relatively modern machine it does not feel any faster at performing basic tasks than other text editors. vim being optimized to run over 300 baud connections is not an advantage in what many consider normal, daily use.
The sky is the limit with programmable editors like Emacs and vim. Like general purpose hardware and OSs, neither can do anything that the other cannot do. Emacs does have an edge but in practice people have been able to make vim do just about anything.
http://www.marksanborn.net/software/modify-remote-files-with...
Seems a good example of how constraints can produce innovation.
I have several clients with which I connect to remotely via Windows Terminal Server or VNC. I usually have to connect to via the webbrowser by opening a link and then the session is opened. I usually have no option to change the performance or quality options.
We have a fast connection here but our clients have ADSL. Yes that's right, the A stands for really slow uploads.
I don't know about you but have you ever tried using Notepad/Notepad++/UltraEdit via a slow internet connection with all the options on full blast (32-bit color, themes, etc ..)?
I'm so glad that I can download PortableVim and run it off the "My Documents" folder and quickly do my editing without being too bothered by the refresh rate.
So the "world that doen't exists anymore" is very much alive if you ask me!
However, I don't think "news" means what it used to any more. Since there are so many sources of information it doesn't mean "new to the world" any more, it instead means "new to the reader".
In that sense, that it is from another year is fairly irrelevant.
In our office 3/10 engineers are using vim as primary tool.
His retort, "I wrote that when I didn't know how to program."
He uses Textedit (on a Mac) these days. (Emacs bindings, if you didn't know.)
He hasn't used vi in years.
I think you use the TCP/IP stack (or one inspired by his) even more often -- but it's not an end user thing.
I have made some key mappings in Vim to get my non-US native keyboards keys that are normally not used in coding do something meaningful. I have ö and ä mapped to curly/square brackets, å is another escape and 0 and + (next to each other on the number row) are home and end. This makes it pretty convenient to write code on a qwerty keyboard and it also works nicely with a laggy phone internet connection over ssh.
Now I have an Android device that's 5x faster and 10 more usable as a phone but I've only written about 10 lines of code in total on it's virtual keyboard. Hoping my next phone combines the best of both worlds.
Wait, what?
Vi is actually the only editor that is bearable on a smartphone because most other editors depend on key-combinations (e.g. Control + X) that are painful to type on a touchscreen.
For vim you only need qwerty + escape and you're set.
Now if only the sc spreadsheet could be retrofitted with Lotus 123 menus. With that, vi, and screen I'd be nearly as efficient as 15 years ago with 123, MKS vi, and Desqview.
Sad that today's software interfaces have so little to do with efficiency (and that includes the 'pc' keyboard layout).
> By the way, 'em' stands for 'editor for mortals' - I christened it that after Ken Thompson visited our lab at QMC while I was developing it and said something like: "yeah, I've seen editors like that, but I don't feel a need for them, I don't want to see the state of the file when I'm editing".
It both has lots of features other editor's don't have, and implements most features differently, so it's not like it's a subset of any other editor.
Vi is only the lowest common denominator of the vi-clones family of editors (Vim et al).
But almost any system is going to have ed installed.
As an intern working for Nortel we had HPUX machines, and vi was frequently used. These days at my current job it's an all-Windows stack, so I'm in VS all the time and don't really have a need for vi.
It doesn't mean I don't miss it, though.
It's a pretty impressive emulation, even has some vim features. That package was the only thing keeping me sane during a year spent in VS.
http://en.wikipedia.org/wiki/George_Coulouris_(computer_scie...
"""He was instrumental in the development of ICL's Content Addressable File Store (CAFS) and he developed em, the Unix editor, which inspired Bill Joy to write vi."""
If that means I don't exist anymore, there's only one ascii art I can think of for Mr Bill Joy.
.i. (o.o) .i.
"Manual screwdrivers were invented for a world that doesn't exist anymore"
"Chisels were invented for a world that doesn't exist anymore".
Etc.
The mere fact that people are still using vi[m] is evidence that this author is wrong.