> "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.
> "So you didn't really write vi in one weekend like everybody says?"
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.
A project I've been working on recently arrived at a good milestone, so I shelved it for a bit. I was very surprised to see github's 52 week participation graph showing me I had been working on it for 3 months. If someone asked me how long it took me, I very honestly would have said 1 month. Not trying to dupe anyone, not even myself, it just felt that way to me.
*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.
Many of these "weekend" projects turn into long-term projects. The thing that gets launched initially helps the developer guage interest before he spends too much time on the project.
I'd have a hard time believing that 'many' of these weekend projects go on to become a long-term project.
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.
It's hard to really track, define (or even understand) the consumed time on innovative projects. Because time is not the essence.
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.
There's a lot to be said about condensing a project into a minimum set of requirements, delivering that, and then iterating, adding all the surplus, mite-be-cool features in the near future, and pivoting.
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?
It doesn't have to be said about it's done in a weekend. The emphasis should be on the MVP feature and idea of the product if that's the main draw. The weekend thing is an ego show and a distraction.
> 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.
What I find sad about that anecdote is that he fully and freely admits stealing software features from other places to make a more serviceable piece of software, and that doing so now and owning up to it would get you an automatic loss in a patent suit.*
* Yes, I know this is a bit of an oversimplification.
To me, stealing is taking someone else's brand, renaming it, and selling it as your own. By that definition, this case is not stealing. It reminds me of the saying "everything that can be invented, has been invented" (I do not remotely believe this) BUT, the man looked at all the best features of the existing inventions and bundled them up into one, and made the best one yet. In fact, he did such a swell job, we still debate, discuss, and use his invention today. /Think stackoverflow's about page...
Surely that's trademark infringement, which is a variety of FRAUD, a completely different thing.
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.
Nothing of course, but if you are young and dont know about sourceforge or any code search engines what else are you going to think? Today's github boosters will be shaking their heads 10 years from now when they hear someone make the same claims about thenextnewforgehub.
Real, normal people? I wish it were true but in my experience github is just another source code repository.
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.
It's been a few years since I've been a regular (Free)BSD user, but I think github has a very different use case.
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.
I largely agree with your points about branching but less so about modification. It's easy to submit patches though they do go through a sometimes rigorous code review. Does github have a formal mechanism for code reviews? Does that differ from Sourceforge, Google Code or other source repositories <http://en.wikipedia.org/wiki/Comparison_of_open_source_softw...?
Unless he was stealing actual source code from ed or bravo, or literally reprinting the manuals themselves, nothing described would run afoul of copyright.
Right, my point was more along the lines of a hypothetical patent on the idea of "an method for editing text on a computer in a text oriented way," and that admitting that you'd seen and borrowed from another program would be a huge mistake today, rather than just acknowledging he did what good programmers do.
Quite a bit of a simplification, since 1) Lotus v. Borland established that this sort of copying was legitimate and 2) this would be a copyright issue, and not a patent one.
...and this is why we can't have nice things: an article about a part of computing history immediately turns into ideologically-inspired dead horse flogging, complete with an admission that the argument made actually bullshit - but hey, let's post anyway.
... and this is why we can't have nice things: when people point out how the computing world's ability to innovate is being destroyed it is immediately attacked as supposed ideology. This attitude, that we can't talk about controversial topics among nice company, is what allows our rights to be stolen.
Nobody said you can't talk about controversial topics. They merely pointed out that this thread is not about a controversial topic, and that off-topic controversy tends to derail otherwise interesting threads. If you insist on trying to tie barely-related threads into a particular topic, that's called having an axe to grind, and it is an ideological thing. (Not that I mean to accuse meepmorp of this. He/she has agreed that it's not germane.)
I think it's fair to point out that a part of computing history might never of happened today, owing to the current legal situation w.r.t. software patents. And owning up to stealing is unthinkable, despite the fact that we all do it.
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.
But that world does still exist: I often find myself ssh'd into a desktop tmux session, via my laptop tethered to my phone's internet connection. In that situation, I am highly appreciative of vi's 300 baud history.
In 1979 I needed a terminal, so I wired-in a UART to my homebrew Z-80 system and hooked it up to a Cat acoustic (300 baud) modem.
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.
There are a number of small Emacs clones (I wrote one for the 6502-based Atari 800 back in the day). They are certainly better than nothing. None of them existed until the mid 80s.
Ironically, 130K is tiny todya, but more than half the address space of a PDP-10 :-)
Yes, bandwidth is always better, but latency spikes are real, even when sitting in your office you can get routing issues or congestion or who knows what making things very frustrating for anything that needs rapid visual feedback.
HN is also an interesting community because of the fact that we all have relatively fast connections. Bungie (guys who made Halo) found out that if you want to be accessible to 99% of connections you need to design around 8kb/s speeds which from what I understand is about 4000baud (see edit).
I just took a couple of minutes to figure out how baud translates to kbps. Turns out, it doesn't.
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.
rbanffy and ordinary are both right. "Baud" is the number of symbols per second; a symbol can be a specific frequency, or a phase shift, or Complex Electronic Magic. Up through 300 baud, each end used a tone for 0 and a tone for 1, and that was it. One bit = one symbol. (You could hear zeros and ones go by if you listened, and for Commodore owners, it was critical to be able to whistle the answer tone so you could trick the modem into hanging up - it auto-answered every call.)
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.
IIRC, baud rate is the number of states you push down the line per second. If you have 1200 baud and 4 different states, you have 2400 bps. IIRC, phone line modems never got much past 9600 baud - what increased was the number of states (I think they were called symbols) you could pass through the line and hence the number of bits per state.
Baudot is also the 5-bit code you see on some paper tapes.
> Now that computers are so much faster than you can think, nobody understands this anymore.
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.
Well, it's faster than Eclipse by many orders of magnitude, so I hope that makes it a bit better :P Vi is instant, Eclipse far from it, as you well know.
Eclipse is a dog. If you compare vim to other text editors such as BBEdit, TextMate, Emacs, Gedit, Sublime Text 2, e, etc. then your argument falls flat on its face.
The nice thing about vi is its ubiquity. I can ssh into basically every UNIX system in the world and be reasonably certain that vi will be available. The same can't be said for BBEdit, TextMate, EMacs, Gedit, etc.
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 like vim, use it daily for editing configs and such, and used to use gvim as my main text editor. Its ubiquity or usefulness is not disputed by anyone. I don't think that modes are stupid (though I don't prefer modes myself).
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.
Yeah I've been am emacs user for decades but I know just enough vi to be able to navigate and edit config files, for this very reason. You always have vi.
That depends on the language support for the editor in question. Emacs can check C and related languages on the fly with flymake. Emacs can also check JavaScript on the fly with js2-mode. Editors such as BBEdit and TextMate cannot do that as far as I know. I'm not sure about the others that I mentioned.
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.
That world is not completely gone! I use VI to connect to amazon AWS servers over a satellite link. It is faster than 1200 baud but with horrible latency. VI is the only editor that works.
Tomorrow I will swim with fish. Today it is stormy and we are safely tucked in a protected harbor. I program when the weather is bad and swim when it is good.
Maybe he did? Maybe he has been enjoying the sea for the past 12 hours? Jesus, you really don't have better things to do than making assumptions and sharing them with people?
I tried working from an RV via satellite link years ago. Very frustrating -- life is too short to deal with the latency. Nowadays with git and puppet this might actually work -- make changes and edits locally and deploy over the low-bandwidth, high-latency link.
...I was trying to make it usable over a 300 baud modem. ...the editor was optimized so that you could edit and feel productive when it was painting slower than you could think.
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.
Actually, it's from 2003 but the entirety of the interview is from 1999. I had that issue of Linux Magazine and I remember reading the interview back then. Sad that it took me over 10 years to really dig into vim after reading about the history of vi.
As I read the article, "Joy leaves a lasting legacy " gave me a small shock, causing me to fire up Bill Joy's wikipedia page to ensure myself that he hasn't passed away. Phew, thankfully he's fine. Too many great people are dying these last few years.
You aren't imagining that. With the increase in population and the number of people classified as celebrities, in the future, we'll see what Kottke called "An abundance of death"[0].
It's been pointed out that world -does- exist (just not as pervasively distributed as it was): people are using slow satellite connections, or low-powered devices where vi is the perfect fit. Regardless, whether vi was written "for a world which doesn't exist anymore", vi still works perfectly well in the world we live in, and a lot of people produce a lot of value with it, and enjoy using it. vi was written for a world that doesn't exist anymore; welcome vi to the world in which we live today.
As someone who was limited to 300 baud for learning UNIX and C, I actually preferred Joy's ex over vi. I found that I could type ahead very quickly and just let the edits scroll in as they were echoed from the mainframe. Watching the edits cascade in a scroll made much more sense to me than a slowly updating vi screen.
Understandable why it's the most fond of his achievements, i spend more time thinking about it more than any of his other inventions. You get a glimpse of that old world he's talking about when you use it over a slow data connection on your smartphone.
I love vim, but I think it would be excruciating without a full keyboard.
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.
I have been using Vim over ssh with my Nokia N900 not-so-smart-phone, and it works great compared to anything else I can think of. The phone has a physical qwerty keyboard but it does not have all the non-alphabetic keys you'd want and esc, ctrl and some other keys are accessed via touchscreen.
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.
I had a N900 and used to write lots of code in nano. It had python, ruby and PHP and was a great tool for quickly coding ideas or scraping and grepping web APIs. It ran vi and emacs too but I never really used them.
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.
My last three phones have had qwerty keyboards. The Nokia E90, a G1 and now a HTC Desire Z. Typing on them is so much easier than using a touch screen. I regularly tap out emails and use ssh and vi on mine.
Still my most used piece of software ever. No other text editor comes close in efficiency. Let those who can't learn vi remain tethered by the mouse, they'll never be able to write or edit text as quickly.
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 depends on where you work and what stack you worked on.
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.
"""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."""
> "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.