3 ms·

It's difficult to agree with the idea that VB displaced COBOL. Even if this were the case, it certainly wasn't because COBOL compilers were expensive compared t

by garren 7y ago

It's difficult to agree with the idea that VB displaced COBOL. Even if this were the case, it certainly wasn't because COBOL compilers were expensive compared to "a cheap interpreter" that came with the machine. COBOL compilers surely were expensive, but they were also intended for mainframes rather than PCs. Also, I don't remember VB ever coming packaged with Windows for free. VB has been a part of Visual Studio for as long as I can remember and I don't believe there was a free version of until around VS2005. Lisp, it turns out, is a weird and challenging language. It takes a little extra before you start to see the exciting bits. Unfortunately, until you reach that point, it's a matter of struggling with the parts around it - namely the editor. Lisp and Emacs go hand in hand, and while today you can rely on other editors to competently work with Lisp code, 20 years ago I don't think this was the case. So now a user has to pick up Lisp (challenging when viewed through the lenses of either VB and COBOL) and Emacs (positively baroque if your only experience is within a GUI and IDE). I'd venture to guess that getting a functional Lisp environment running on a 286/386 era PC was probably a challenge in itself for most people. Now consider VB or Java, significantly more familiar languages that didn't effectively depend (at the time) on the features of their editor or IDE. Both were a mouse-click away as far as installation, and Java didn't cost anything. Both were backed by large organizations that had a lot of incentive to invest and convince people to use their particular thing. Lisp was this weird, mostly academic, language intended to tackle relatively esoteric rather than business problems, that was Unix only at a time when PCs and Windows were taking off. It doesn't seem unusual to me that it didn't take over the world. Frankly, I'm surprised and thankful that it's still around, actively used, and even sporting a significant community.

kazinator 7y ago
> while today you can rely on other editors to competently work with Lisp code, 20 years ago I don't think this was the case. I've been doing Lisp for just about that many years and have used nothing but Vim. Its Lisp support is built off :set lisp mode which is in the original Unix vi. It does a good job of syntax coloring, indentation and all that. To reindent a block of code in Vim, I just put the cursor on one of the parentheses, then hit =% . The odd time there is a stylistic disagreement (like Vim wanting to align the arguments of something as if it were a function, rather than let-like). My Lisp implementation, TXR Lisp, comes with a comprehensive Vim syntax file. When you browse the sources using CGIT, all the syntax coloring you see is performed by Vim, being used on-the-fly as a back end for HTML generation. E.g.: http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/defset.tl http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/defset...
- ksaj 7y ago
  > =% Yikes. I've been using vi forever and that never occurred to me. I just tried it on my own config and it works just as you say. I hope it is configurable, 'cos it doesn't fully agree with my habits (although maybe that's a fault of my own, and not vi(m)'s!) Best thing about HN comment threads is that these gems keep happening.
  - kazinator 7y ago
    I used that on C code before Lisp: jump from { to } or vice versa, while reindenting. Whether you get this alignment: (oper args blah blah) or this one: (fun arg arg arg arg) depends on one very simple configuration: the lispwords variable. All the identifiers listed in lispwords are given the former treatment. Then there are minor squabbles like what happens with the t clause in cond. A lot of the time I just use visual select and =. Also, in Vim, when you reindent multiple lines, it basically assumes that the first one is indented right; it will not move it relative to it predecessors. You often have to hit == on the first line to get it into alignment, and then %= (or whatever) to reindent the range below it. E.g.: (let ((x y)) (blah ;; here we type == blah blah (foo bar boo)) (let ((x y)) (blah ;; now %= blah blah (foo bar boo)) (let ((x y)) (blah blah blah (foo bar boo))

by garren 7y ago

kazinator 7y ago

> while today you can rely on other editors to competently work with Lisp code, 20 years ago I don't think this was the case. I've been doing Lisp for just about that many years and have used nothing but Vim. Its Lisp support is built off :set lisp mode which is in the original Unix vi. It does a good job of syntax coloring, indentation and all that. To reindent a block of code in Vim, I just put the cursor on one of the parentheses, then hit =% . The odd time there is a stylistic disagreement (like Vim wanting to align the arguments of something as if it were a function, rather than let-like). My Lisp implementation, TXR Lisp, comes with a comprehensive Vim syntax file. When you browse the sources using CGIT, all the syntax coloring you see is performed by Vim, being used on-the-fly as a back end for HTML generation. E.g.: http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/defset.tl http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/defset...

ksaj 7y ago
> =% Yikes. I've been using vi forever and that never occurred to me. I just tried it on my own config and it works just as you say. I hope it is configurable, 'cos it doesn't fully agree with my habits (although maybe that's a fault of my own, and not vi(m)'s!) Best thing about HN comment threads is that these gems keep happening.
- kazinator 7y ago
  I used that on C code before Lisp: jump from { to } or vice versa, while reindenting. Whether you get this alignment: (oper args blah blah) or this one: (fun arg arg arg arg) depends on one very simple configuration: the lispwords variable. All the identifiers listed in lispwords are given the former treatment. Then there are minor squabbles like what happens with the t clause in cond. A lot of the time I just use visual select and =. Also, in Vim, when you reindent multiple lines, it basically assumes that the first one is indented right; it will not move it relative to it predecessors. You often have to hit == on the first line to get it into alignment, and then %= (or whatever) to reindent the range below it. E.g.: (let ((x y)) (blah ;; here we type == blah blah (foo bar boo)) (let ((x y)) (blah ;; now %= blah blah (foo bar boo)) (let ((x y)) (blah blah blah (foo bar boo))