21 ms·

Unix as IDE

237 points by yarapavan 10y ago

signa11 10y ago
iirc (very vaguely) this has been discussed on hn before. the entire series is available as an ebook here: https://github.com/mrzool/unix-as-ide https://github.com/mrzool/unix-as-ide
- shunyaloop 10y ago
  Thank you. The ebook is helpful
_vya7 10y ago
At some point I realized Unix is basically a long-running IDE + REPL, and thought that was just so cool. And then I realized how horribly inefficient it is at being that. So I started longing for the days when we had some kind of OS where it actually is a IDE + REPL, like an OS based on Lisp. And then I learned that that already was done and didn't turn out as cool as people had hoped. Oh well.
- cathexis 10y ago
  By all accounts, LispM's were awesome systems to use but lost out due to heavy marketing from unix vendor companies.
  - qwertyuiop924 10y ago
    They were also really expensive, and there have always been people who hated Lisp for the syntax.
    - DonaldFisk 10y ago
      On Symbolics Genera they had the option of using C, Pascal, Ada, Fortran, or Prolog.
    - deleted 10y ago
      [deleted]
    - catnaroek 10y ago
      Lisp's syntax is okay, but its semantics is absolutely horrendous. Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems language was to run it on hardware explicitly designed to run Lisp. Of course, hardware support for features like dynamic typing and efficient dynamic allocation of lots of small objects doesn't come for free - this is what made Lisp machines expensive.
      - qwertyuiop924 10y ago
        Well, some of us like Dynamic Typing. Just because you don't doesn't make it horrendous. Given, it can be unpleaseant in certain contexts, but Lisp has really good metaprogramming support, so you can add syntax for a runtime type system relatively simply. It's not optimal, and it certaibly isn't the fastest thing, but it works if you want it. And nowadays, CL (and several of the Schemes) provide more powerful type systems, and sometimes even compile-time typing. All optional, of course.
        catnaroek 10y ago
        I don't have anything against the presence of dynamic typing - it's in fact very useful. What's annoying is the absence of meaningful static typing: parametric polymorphism and exhaustive pattern matching help me prove things about what my code does and how it can be used by others, but their usefulness is reduced to zero when dynamically typed code is allowed to break the proofs' assumptions. To be perfectly clear: it doesn't bother me in the slightest that a dynamically typed module can break the internal state of another dynamically typed module, since in most likelihood I'm the author of neither, and I respect other people's right to write their code however they wish. So I'd be fine with a Racket-like contract system, where well-typed modules can't be blamed. But, if I understand correctly, what Common Lisp has is nothing like this.
        qwertyuiop924 10y ago
  - rbc 10y ago
    I had a couple of them, a 3620 and a MacIvory. With all the focus on AI, maybe Lisp optimized hardware will return in some form, perhaps a bit like GPUs have become a trend. There was a lot of clever code written on top of Genera. It would be a shame for it to get re-written due to the loss of the Lisp machine platforms.
- pmiller2 10y ago
  Yeah, the other way around seems to work better: IDE as OS (really IDE as OS shell) a la emacs.
  - dozzie 10y ago
    But as the old saying goes, it will still need a decent editor.
    - unhammer 10y ago
      There are several. I prefer evil – see https://bling.github.io/blog/2015/01/06/emacs-as-my-leader-1-year-later/ https://bling.github.io/blog/2015/01/06/emacs-as-my-leader-1... for some intro.
- BjoernKW 10y ago
  The C64 was like that. Not Lisp but it booted right into a BASIC REPL. BASIC was the C64's operating system. I still think there is a niche for such a system today (mainly for developing rapidly changing business applications you'd nowadays use Excel for, as well as education).
  - clifanatic 10y ago
    > I still think there is a niche for such a system today In Polish auto repair, if nowhere else: http://www.popularmechanics.com/technology/gadgets/a23139/commodore-64-repair-shop/ http://www.popularmechanics.com/technology/gadgets/a23139/co...
  - jjrh 10y ago
    Javascript and a browser is essentially that.
  - wott 10y ago
    Almost all 8-bit computer were like that. I was so glad when I left REPLs and then debuggers and IDEs, to compiled languages and text-editor + command-line compilation and open source-code. I just cannot fathom the trend of the last 5 years where I hear and read people who cannot live without an IDE, a debugger and a REPL. It feels like living in a jail cell for me; a cell I left 20-25 years ago. Incidentally, I just had to install an IDE today, for HDL development. I urgently have to find a way to turn the process into a Makefile or I will throw the computer through the window before the week-end comes.
- DonaldFisk 10y ago
  Systems such as Genera were a lot better as development environments than the Unices which replaced them.
- jcoffland 10y ago
  > And then I realized how horribly inefficient it is at being that. This depends a lot on the user. In the right hands it's extremely efficient.
  - TeMPOraL 10y ago
    It's a powerful lever, yes, but if we talk efficiency, then it very much sucks. You get a crappy pseudo-programming language (shell) that spawns a new process (!) for almost every function call, and communicates with unstructured text that has to be parsed and reparsed every step of the way. The only benefits of this system are that it's already there with batteries included, and that it became a de-facto standard.
    - sdegutis 10y ago
      Well also that it's entirely dynamic. You can create and edit "functions" on the fly, which will exist immediately, and are persisted across "sessions". But despite how convenient this is, there's basically no way to make it a whole lot more efficient. Especially the automatic "persisting" feature, there's no other way to do that than writing to disk. That said, you get a lot of similar behavior to this in things like Clojure + CIDER, but due to the nature of the underlying JVM, you still have to restart it every once in a while. Part of me still wonders what we could come up with if we took the principles behind a true interactive IDE + REPL (like Emacs + CIDER) but removed the concept of "wrapping" a VM that was designed for a "programming language", and added the concept of a longer-lived "VM". Not quite what LispMs were, nor even Smalltalk (which relied too heavily on a GUI and a monolithic "image state" rather than individual persist-able files).
      - imtringued 10y ago
        >but due to the nature of the underlying JVM, you still have to restart it every once in a while. The DCEVM project almost removed any limitations on hotswapping code in the JVM until oracle hired the people behind it and then never integrated it into their JVM.
  - 10y ago
deleted 10y ago
[deleted]
julbaxter 10y ago
Previous discussion https://news.ycombinator.com/item?id=4105768 https://news.ycombinator.com/item?id=4105768 and https://news.ycombinator.com/item?id=3594098 https://news.ycombinator.com/item?id=3594098
qwertyuiop924 10y ago
>But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way. ...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.
- clifanatic 10y ago
  Yeah, emacs would be a great operating system, if only it came with a decent text editor. (ducks)
  - emidln 10y ago
    Someone fixed that. My emacs came with good modal editing out of the box. Maybe your emacs is broken. Try spacemacs.org. (runs)
    - qwertyuiop924 10y ago
      And if you don't want to deal with hellish complexity, and have a DIY mindset, you can grab evil, and build the modal system you want. (dodges)
    - gkya 10y ago
      Spacemacs is a whole bunch of things, nobody needs it for a simple (evil-mode +1) (not that I call it useless, but Vi emulation is part of base Emacs).
    - nerdponx 10y ago
      Modal? I want composable.
      - qwertyuiop924 10y ago
        With evil-mode, which is what spacemacs is based on, you get it.
rbc 10y ago
I recently contributed an awk filter for doing text transformation. I think it was some kind of code for converting POSIX attributes to LDIF or something like that. I was kind of surprised when one of the replies that I received was a request to re-implement it as a Python API. They didn't seem interested in using piplelines as a way to glue utilities together into something bigger. I don't have anything against Python, I just like the idea of being able to integrate wildly different implementations (C, perl, awk, sed, m4, Perl, Python, etc...) to solve problems. It's a kind of component based approach that the Unix/Linux/BSD shell makes really easy.
__jal 10y ago
This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popular, I didn't get it, at all. Put aside tool tips (which annoy me far more than is rational); it seemed to me that the idea was to build a toy model workshop on the work bench of a fully outfitted workshop. Why would anyone want to use that? Why bother in the first place? I mean, I do get it. And who knows, maybe if I used one of those long enough to break muscle memory and the conceptual assumptions that don't map, I'd change my mind. But so far, vi + shell + standard utilities + what I build have served me just fine, and if for some reason I were to need "more power", whatever that means, I'd probably move to emacs. And I still maintain that tool tips/balloon help/obscuring the very thing you're pointing at is a stupidly rude anti-pattern. Even worse is not making it possible to turn off.
- coldtea 10y ago
  >This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions.
  - joelthelion 10y ago
    > The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions. I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. Which is why no one has succeeded yet. There is still a lot of innovation, though. 10 years ago, we didn't have git, or ag, or autojump. Gdb has improved A LOT in the past few years, even if it's not immediately obvious when you open it.
the8472 10y ago
It lacks the I in IDE. Those different tools are not integrated. In a java IDE the debugger steps through your source in the same editor view that you just used for editing. You can hover over each identifier while you code or debug to get the docs in a floating panel. Editing incrementally computes compilation errors while you type. Content assist has complete knowledge of the types at your caret position and thus can make accurate suggestions what can be inserted there. Saving the file while debugging automatically compiles the code, runs tests and splices it into the running VM so you can continue debugging the running process with the new code while also showing you which lines you changed relative to the most recent VCS commit. And of course there's more.
- amelius 10y ago
  If you can't debug with just print statements, you're doing it wrong :)
  - AceJohnny2 10y ago
    It's funny but, in the embedded world, it's scary how archaic things are. For example, just a few hours ago I convinced a colleague to try using the debugger. Our hardware has had a functional JTAG-based debugging toolchain for years, but people still haven't picked up on it. I'm the new guy who spearheaded it in the team -_-
    - david-given 10y ago
      Back when I was working on embedded, I typically wouldn't even bother looking at the debugger. They never helped. The general workflow, when presented with a new system, was something like: (a) Board would arrive. Admire it for a bit. (b) Look suspiciously at the supplied CD. Gingerly insert it into computer. Oh, look, a Windows install.exe. Insert it into the Windows computer next to mine (with its screen and keyboard slaved to mine with x2vnc, which is great). Install. (c) Load the terrifying, buggy, proprietary IDE. Close it again. (This was in the pre-Eclipse days. You really had no idea what you were going to get here.) (d) Search through the vast pile of useless guff which it had installed for the embedded copy of gcc. Find it. Also find the BSP libraries, and link scripts. (e) Realise it's a terrifying, buggy, proprietary-patched version of gcc where the source package doesn't match the binary. (f) Attempt to find whatever terrifying, buggy, proprietary tool actually downloads images onto the board. (g) From the command line, write a tiny makefile which uses everything found in (c) plus (f) plus the terrifyingly misspelt quote documentation unquote (supplied in a PDF on the CD) and attempt to produce and run a 'Hello world' image. Download and run it. (h) Assuming (g) worked, bolt it on to our existing gcc-and-make based built automation and actually start work. Any debugger was usually so tightly integrated to the IDE, which was always set up to assume a particular project layout which didn't match our source layout, that it was usually more trouble than it was worth; particular as our product had a lot of JIT stuff in it, which a source debugger couldn't help with much anyway. The very best boards had an on-board monitor which gave you a Commodore PET-style assembler debugger. One even had hardware watch and breakpoints! The ability to single step through stuff, via a serial terminal, with no prior setup required, was amazing. It was sufficiently robust that even when the board really crashed badly it would drop into the monitor and you could examine what had gone wrong. I have a particular hatred for the debuggers which required a slave task running on the board itself. (a) sucks to be you if you were running a different OS; (b) oddly enough, if your app crashed and scribbled all over memory, it tended to stop working... </rant> Edit: Oh, I forgot to say --- this was mostly before JTAG was ubiquitous, so debugging options were either a terrible, proprietary serial monitor or a terrifyingly expensive ICE unit. JTAG did come along later, and it was miraculous; you could even single-step through interrupt handlers with it! But it wasn't standardised and each board typically had its own interface, which wasn't supplied, plus its own software. Then not long after I got out of the game. ...I'm having flashbacks now. Downloading Java images onto an M-Core development board at 100-200 bytes per second with a 1 in 10 chance of a failed download for every megabyte. You think I'm exaggerating. I'm not. I still have the CPU from that board somewhere; I ripped it off once we were finished to make sure that nobody would ever have to use it again.
cdevs 10y ago
I've tried for the past couple of years to get into vim but I can't force myself to remember the odd short cuts I can't seem to ever match up with the action it's doing. I could if I rewrote them butttttt then that blows when I want to jump into a new server without my config. So it's always been nano for one liners and sublime through sftp mounted filesystem.
- beachstartup 10y ago
  you've probably never: 1. been forced to use a system with nothing but vi, ed, and ex, which was common for commercial unixes until the 90's 2. had to make thousands of edits to thousands of files in minutes without access to a scripting environment or other more advanced tools 3. had to edit and debug a program under the above conditions on a super laggy dialup internet connection vi is a force multiplier for operating a terminal under duress in adverse network conditions. that's literally why it was developed. i say it does an even better job of it under good, modern conditions and unless you look at it through that lens, it's never going to make much sense to you. and those adverse conditions still pop up now and then, especially with wireless networks and public cloud shitstorms. "[Bill] Joy explained that the terse, single character commands and the ability to type ahead of the display were a result of the slow 300 baud modem he used when developing the software and that he wanted to be productive when the screen was painting slower than he could think." https://en.wikipedia.org/wiki/Vi https://en.wikipedia.org/wiki/Vi
  - justinlardinois 10y ago
    To be honest vi and vim are different enough that as someone who was taught on vim, I get lost when I have to do anything beyond opening a file in vi.
    - beachstartup 10y ago
      yeah, it's pretty awful.
- lucb1e 10y ago
  Note that Vim is pretty much identical to nano when you press the letter i. Then hit escape and use :wq to write to disk and quit. Over time you'll probably start using more and more Vim features to do text editing quicker. It took me two years to learn Vim well enough that I could objectively say it works better than standard text editors. I'm not surprised you didn't succeed in learning it all at once. It's like using a mouse for the first time ever that comes with 50 buttons. I don't think anyone could learn that and put it to use from muscle memory (that's where it really starts to pay off) in one sitting.
leonardinius 10y ago
Shouldn't there be (2012) in the title?
- justinlardinois 10y ago
  Yes.
polpo 10y ago
This instantly brought to mind the classic 1984 book, The Unix Programming Environment, by Brian Kernighan and Rob Pike [1]. Note that they call Unix a programming environment, not an operating system. This book shows that the original purpose of Unix is to be a tool for writing software. [1] https://en.wikipedia.org/wiki/The_Unix_Programming_Environment https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
- sedachv 10y ago
  Do you (or anyone else) know of a book in the same spirit covering the more recent Unix tools?
- pvg 10y ago
  They're not calling Unix a programming environment instead of an operating system. The title of the book refers to the programming environment of the Unix operating system.
emmelaich 10y ago
A early variant of UNIX was explicitly that. But it was called Programmer's Workbench. https://en.wikipedia.org/wiki/PWB/UNIX https://en.wikipedia.org/wiki/PWB/UNIX It introduced version control (SCCS), make, lex, yacc and more.
jxy 10y ago
I thought this is another acme post. Oh NO~~~, you don't even use a mouse?!
imtringued 10y ago
Unix as IDE is an oxymoron simply because it's not integrated. How about we swap the "I" with something else? Maybe Universal Development Environment?

237 points by yarapavan 10y ago

iirc (very vaguely) this has been discussed on hn before. the entire series is available as an ebook here: https://github.com/mrzool/unix-as-ide https://github.com/mrzool/unix-as-ide

shunyaloop 10y ago
Thank you. The ebook is helpful

_vya7 10y ago

At some point I realized Unix is basically a long-running IDE + REPL, and thought that was just so cool. And then I realized how horribly inefficient it is at being that. So I started longing for the days when we had some kind of OS where it actually is a IDE + REPL, like an OS based on Lisp. And then I learned that that already was done and didn't turn out as cool as people had hoped. Oh well.

cathexis 10y ago
By all accounts, LispM's were awesome systems to use but lost out due to heavy marketing from unix vendor companies.
- qwertyuiop924 10y ago
  They were also really expensive, and there have always been people who hated Lisp for the syntax.
  - DonaldFisk 10y ago
    On Symbolics Genera they had the option of using C, Pascal, Ada, Fortran, or Prolog.
  - deleted 10y ago
    [deleted]
  - catnaroek 10y ago
    Lisp's syntax is okay, but its semantics is absolutely horrendous. Even ignoring the features that make it not so great a high-level language (such as the lack of a workable static semantics, forcing programmers to dynamically test what can be taken for granted in more civilized languages), Lisp is an even worse low-level systems language. In the 80's, the only way one could reasonably hope to use Lisp as a systems language was to run it on hardware explicitly designed to run Lisp. Of course, hardware support for features like dynamic typing and efficient dynamic allocation of lots of small objects doesn't come for free - this is what made Lisp machines expensive.
    - qwertyuiop924 10y ago
      Well, some of us like Dynamic Typing. Just because you don't doesn't make it horrendous. Given, it can be unpleaseant in certain contexts, but Lisp has really good metaprogramming support, so you can add syntax for a runtime type system relatively simply. It's not optimal, and it certaibly isn't the fastest thing, but it works if you want it. And nowadays, CL (and several of the Schemes) provide more powerful type systems, and sometimes even compile-time typing. All optional, of course.
      - catnaroek 10y ago
        I don't have anything against the presence of dynamic typing - it's in fact very useful. What's annoying is the absence of meaningful static typing: parametric polymorphism and exhaustive pattern matching help me prove things about what my code does and how it can be used by others, but their usefulness is reduced to zero when dynamically typed code is allowed to break the proofs' assumptions. To be perfectly clear: it doesn't bother me in the slightest that a dynamically typed module can break the internal state of another dynamically typed module, since in most likelihood I'm the author of neither, and I respect other people's right to write their code however they wish. So I'd be fine with a Racket-like contract system, where well-typed modules can't be blamed. But, if I understand correctly, what Common Lisp has is nothing like this.
        qwertyuiop924 10y ago
- rbc 10y ago
  I had a couple of them, a 3620 and a MacIvory. With all the focus on AI, maybe Lisp optimized hardware will return in some form, perhaps a bit like GPUs have become a trend. There was a lot of clever code written on top of Genera. It would be a shame for it to get re-written due to the loss of the Lisp machine platforms.
pmiller2 10y ago
Yeah, the other way around seems to work better: IDE as OS (really IDE as OS shell) a la emacs.
- dozzie 10y ago
  But as the old saying goes, it will still need a decent editor.
  - unhammer 10y ago
    There are several. I prefer evil – see https://bling.github.io/blog/2015/01/06/emacs-as-my-leader-1-year-later/ https://bling.github.io/blog/2015/01/06/emacs-as-my-leader-1... for some intro.
BjoernKW 10y ago
The C64 was like that. Not Lisp but it booted right into a BASIC REPL. BASIC was the C64's operating system. I still think there is a niche for such a system today (mainly for developing rapidly changing business applications you'd nowadays use Excel for, as well as education).
- clifanatic 10y ago
  > I still think there is a niche for such a system today In Polish auto repair, if nowhere else: http://www.popularmechanics.com/technology/gadgets/a23139/commodore-64-repair-shop/ http://www.popularmechanics.com/technology/gadgets/a23139/co...
- jjrh 10y ago
  Javascript and a browser is essentially that.
- wott 10y ago
  Almost all 8-bit computer were like that. I was so glad when I left REPLs and then debuggers and IDEs, to compiled languages and text-editor + command-line compilation and open source-code. I just cannot fathom the trend of the last 5 years where I hear and read people who cannot live without an IDE, a debugger and a REPL. It feels like living in a jail cell for me; a cell I left 20-25 years ago. Incidentally, I just had to install an IDE today, for HDL development. I urgently have to find a way to turn the process into a Makefile or I will throw the computer through the window before the week-end comes.
DonaldFisk 10y ago
Systems such as Genera were a lot better as development environments than the Unices which replaced them.
jcoffland 10y ago
> And then I realized how horribly inefficient it is at being that. This depends a lot on the user. In the right hands it's extremely efficient.
- TeMPOraL 10y ago
  It's a powerful lever, yes, but if we talk efficiency, then it very much sucks. You get a crappy pseudo-programming language (shell) that spawns a new process (!) for almost every function call, and communicates with unstructured text that has to be parsed and reparsed every step of the way. The only benefits of this system are that it's already there with batteries included, and that it became a de-facto standard.
  - sdegutis 10y ago
    Well also that it's entirely dynamic. You can create and edit "functions" on the fly, which will exist immediately, and are persisted across "sessions". But despite how convenient this is, there's basically no way to make it a whole lot more efficient. Especially the automatic "persisting" feature, there's no other way to do that than writing to disk. That said, you get a lot of similar behavior to this in things like Clojure + CIDER, but due to the nature of the underlying JVM, you still have to restart it every once in a while. Part of me still wonders what we could come up with if we took the principles behind a true interactive IDE + REPL (like Emacs + CIDER) but removed the concept of "wrapping" a VM that was designed for a "programming language", and added the concept of a longer-lived "VM". Not quite what LispMs were, nor even Smalltalk (which relied too heavily on a GUI and a monolithic "image state" rather than individual persist-able files).
    - imtringued 10y ago
      >but due to the nature of the underlying JVM, you still have to restart it every once in a while. The DCEVM project almost removed any limitations on hotswapping code in the JVM until oracle hired the people behind it and then never integrated it into their JVM.
- 10y ago

deleted 10y ago

[deleted]

julbaxter 10y ago

Previous discussion https://news.ycombinator.com/item?id=4105768 https://news.ycombinator.com/item?id=4105768 and https://news.ycombinator.com/item?id=3594098 https://news.ycombinator.com/item?id=3594098

qwertyuiop924 10y ago

>But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way. ...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.

clifanatic 10y ago
Yeah, emacs would be a great operating system, if only it came with a decent text editor. (ducks)
- emidln 10y ago
  Someone fixed that. My emacs came with good modal editing out of the box. Maybe your emacs is broken. Try spacemacs.org. (runs)
  - qwertyuiop924 10y ago
    And if you don't want to deal with hellish complexity, and have a DIY mindset, you can grab evil, and build the modal system you want. (dodges)
  - gkya 10y ago
    Spacemacs is a whole bunch of things, nobody needs it for a simple (evil-mode +1) (not that I call it useless, but Vi emulation is part of base Emacs).
  - nerdponx 10y ago
    Modal? I want composable.
    - qwertyuiop924 10y ago
      With evil-mode, which is what spacemacs is based on, you get it.

rbc 10y ago

I recently contributed an awk filter for doing text transformation. I think it was some kind of code for converting POSIX attributes to LDIF or something like that. I was kind of surprised when one of the replies that I received was a request to re-implement it as a Python API. They didn't seem interested in using piplelines as a way to glue utilities together into something bigger. I don't have anything against Python, I just like the idea of being able to integrate wildly different implementations (C, perl, awk, sed, m4, Perl, Python, etc...) to solve problems. It's a kind of component based approach that the Unix/Linux/BSD shell makes really easy.

__jal 10y ago

This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popular, I didn't get it, at all. Put aside tool tips (which annoy me far more than is rational); it seemed to me that the idea was to build a toy model workshop on the work bench of a fully outfitted workshop. Why would anyone want to use that? Why bother in the first place? I mean, I do get it. And who knows, maybe if I used one of those long enough to break muscle memory and the conceptual assumptions that don't map, I'd change my mind. But so far, vi + shell + standard utilities + what I build have served me just fine, and if for some reason I were to need "more power", whatever that means, I'd probably move to emacs. And I still maintain that tool tips/balloon help/obscuring the very thing you're pointing at is a stupidly rude anti-pattern. Even worse is not making it possible to turn off.

coldtea 10y ago
>This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions.
- joelthelion 10y ago
  > The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness, and plain bad decisions. I don't think the problem is cargo culting. Replacing things with better solutions is hard. Take the venerable ANSI terminal. It's archaic and cryptic, I think most people would agree on that. Yet proposing a better, widely useful and backwards compatible alternative is extremely hard. Which is why no one has succeeded yet. There is still a lot of innovation, though. 10 years ago, we didn't have git, or ag, or autojump. Gdb has improved A LOT in the past few years, even if it's not immediately obvious when you open it.

the8472 10y ago

It lacks the I in IDE. Those different tools are not integrated. In a java IDE the debugger steps through your source in the same editor view that you just used for editing. You can hover over each identifier while you code or debug to get the docs in a floating panel. Editing incrementally computes compilation errors while you type. Content assist has complete knowledge of the types at your caret position and thus can make accurate suggestions what can be inserted there. Saving the file while debugging automatically compiles the code, runs tests and splices it into the running VM so you can continue debugging the running process with the new code while also showing you which lines you changed relative to the most recent VCS commit. And of course there's more.

amelius 10y ago
If you can't debug with just print statements, you're doing it wrong :)
- AceJohnny2 10y ago
  It's funny but, in the embedded world, it's scary how archaic things are. For example, just a few hours ago I convinced a colleague to try using the debugger. Our hardware has had a functional JTAG-based debugging toolchain for years, but people still haven't picked up on it. I'm the new guy who spearheaded it in the team -_-
  - david-given 10y ago
    Back when I was working on embedded, I typically wouldn't even bother looking at the debugger. They never helped. The general workflow, when presented with a new system, was something like: (a) Board would arrive. Admire it for a bit. (b) Look suspiciously at the supplied CD. Gingerly insert it into computer. Oh, look, a Windows install.exe. Insert it into the Windows computer next to mine (with its screen and keyboard slaved to mine with x2vnc, which is great). Install. (c) Load the terrifying, buggy, proprietary IDE. Close it again. (This was in the pre-Eclipse days. You really had no idea what you were going to get here.) (d) Search through the vast pile of useless guff which it had installed for the embedded copy of gcc. Find it. Also find the BSP libraries, and link scripts. (e) Realise it's a terrifying, buggy, proprietary-patched version of gcc where the source package doesn't match the binary. (f) Attempt to find whatever terrifying, buggy, proprietary tool actually downloads images onto the board. (g) From the command line, write a tiny makefile which uses everything found in (c) plus (f) plus the terrifyingly misspelt quote documentation unquote (supplied in a PDF on the CD) and attempt to produce and run a 'Hello world' image. Download and run it. (h) Assuming (g) worked, bolt it on to our existing gcc-and-make based built automation and actually start work. Any debugger was usually so tightly integrated to the IDE, which was always set up to assume a particular project layout which didn't match our source layout, that it was usually more trouble than it was worth; particular as our product had a lot of JIT stuff in it, which a source debugger couldn't help with much anyway. The very best boards had an on-board monitor which gave you a Commodore PET-style assembler debugger. One even had hardware watch and breakpoints! The ability to single step through stuff, via a serial terminal, with no prior setup required, was amazing. It was sufficiently robust that even when the board really crashed badly it would drop into the monitor and you could examine what had gone wrong. I have a particular hatred for the debuggers which required a slave task running on the board itself. (a) sucks to be you if you were running a different OS; (b) oddly enough, if your app crashed and scribbled all over memory, it tended to stop working... </rant> Edit: Oh, I forgot to say --- this was mostly before JTAG was ubiquitous, so debugging options were either a terrible, proprietary serial monitor or a terrifyingly expensive ICE unit. JTAG did come along later, and it was miraculous; you could even single-step through interrupt handlers with it! But it wasn't standardised and each board typically had its own interface, which wasn't supplied, plus its own software. Then not long after I got out of the game. ...I'm having flashbacks now. Downloading Java images onto an M-Core development board at 100-200 bytes per second with a 1 in 10 chance of a failed download for every megabyte. You think I'm exaggerating. I'm not. I still have the CPU from that board somewhere; I ripped it off once we were finished to make sure that nobody would ever have to use it again.

cdevs 10y ago

I've tried for the past couple of years to get into vim but I can't force myself to remember the odd short cuts I can't seem to ever match up with the action it's doing. I could if I rewrote them butttttt then that blows when I want to jump into a new server without my config. So it's always been nano for one liners and sublime through sftp mounted filesystem.

beachstartup 10y ago
you've probably never: 1. been forced to use a system with nothing but vi, ed, and ex, which was common for commercial unixes until the 90's 2. had to make thousands of edits to thousands of files in minutes without access to a scripting environment or other more advanced tools 3. had to edit and debug a program under the above conditions on a super laggy dialup internet connection vi is a force multiplier for operating a terminal under duress in adverse network conditions. that's literally why it was developed. i say it does an even better job of it under good, modern conditions and unless you look at it through that lens, it's never going to make much sense to you. and those adverse conditions still pop up now and then, especially with wireless networks and public cloud shitstorms. "[Bill] Joy explained that the terse, single character commands and the ability to type ahead of the display were a result of the slow 300 baud modem he used when developing the software and that he wanted to be productive when the screen was painting slower than he could think." https://en.wikipedia.org/wiki/Vi https://en.wikipedia.org/wiki/Vi
- justinlardinois 10y ago
  To be honest vi and vim are different enough that as someone who was taught on vim, I get lost when I have to do anything beyond opening a file in vi.
  - beachstartup 10y ago
    yeah, it's pretty awful.
lucb1e 10y ago
Note that Vim is pretty much identical to nano when you press the letter i. Then hit escape and use :wq to write to disk and quit. Over time you'll probably start using more and more Vim features to do text editing quicker. It took me two years to learn Vim well enough that I could objectively say it works better than standard text editors. I'm not surprised you didn't succeed in learning it all at once. It's like using a mouse for the first time ever that comes with 50 buttons. I don't think anyone could learn that and put it to use from muscle memory (that's where it really starts to pay off) in one sitting.

leonardinius 10y ago

Shouldn't there be (2012) in the title?

justinlardinois 10y ago
Yes.

polpo 10y ago

This instantly brought to mind the classic 1984 book, The Unix Programming Environment, by Brian Kernighan and Rob Pike [1]. Note that they call Unix a programming environment, not an operating system. This book shows that the original purpose of Unix is to be a tool for writing software. [1] https://en.wikipedia.org/wiki/The_Unix_Programming_Environment https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...

sedachv 10y ago
Do you (or anyone else) know of a book in the same spirit covering the more recent Unix tools?
pvg 10y ago
They're not calling Unix a programming environment instead of an operating system. The title of the book refers to the programming environment of the Unix operating system.

emmelaich 10y ago

A early variant of UNIX was explicitly that. But it was called Programmer's Workbench. https://en.wikipedia.org/wiki/PWB/UNIX https://en.wikipedia.org/wiki/PWB/UNIX It introduced version control (SCCS), make, lex, yacc and more.

jxy 10y ago

I thought this is another acme post. Oh NO~~~, you don't even use a mouse?!

imtringued 10y ago

Unix as IDE is an oxymoron simply because it's not integrated. How about we swap the "I" with something else? Maybe Universal Development Environment?