Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix as IDE

sanctum.geek.nz

Post reply on HN
Print view View original

31–40 of 214 posts

Re: Unix as IDE

#31

Post by TeMPOraL »

jcoffland wrote: post #19
_vya7 wrote: post #4

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.

> 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.

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.

Re: Unix as IDE

#32

Post by __jal »

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.

Re: Unix as IDE

#33

Post by the8472 »

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.

Re: Unix as IDE

#34

Post by amelius »

the8472 wrote: post #33

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 c…

If you can't debug with just print statements, you're doing it wrong :)

Re: Unix as IDE

#35

Post by AceJohnny2 »

amelius wrote: post #34
the8472 wrote: post #33

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 c…

If you can't debug with just print statements, you're doing it wrong :)

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 -_-

Re: Unix as IDE

#36

Post by the8472 »

amelius wrote: post #34
the8472 wrote: post #33

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 c…

If you can't debug with just print statements, you're doing it wrong :)

you can do that too, just use hot code replace to put print statements into the running code. you don't even have to suspend threads for that

Re: Unix as IDE

#37

Post by unhammer »

dozzie wrote: post #9
pmiller2 wrote: post #6

Earlier quoted context omitted.

Yeah, the other way around seems to work better: IDE as OS (really IDE as OS shell) a la emacs.

But as the old saying goes, it will still need a decent editor.

There are several. I prefer evil – see https://bling.github.io/blog/2015/01/06/emacs-as-my-leader-1... for some intro.

Re: Unix as IDE

#38

Post by coldtea »

__jal wrote: post #32

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 popu…

>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.

Re: Unix as IDE

#39

Post by joelthelion »

coldtea wrote: post #38
__jal wrote: post #32

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 popu…

> 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…

> 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.

Re: Unix as IDE

#40

Post by qwertyuiop924 »

npsimons wrote: post #23
qwertyuiop924 wrote: post #11

>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.

http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em... "It was all just text. Why did you need another application for it? Why should only the shell prompt be editable? Why can’t I move my cursor up a few lines to where the last command spewed out its results? All these problems simply disappear when your shell (or shells) simply becomes another Emacs buffer, upon which all of the text manipulation power of…

This is Atom's great failing: it's trying to do the emacs thing, but it doesn't treat all buffers uniformly: your settings window, your terminal window, and the various text windows are fundamentally different. Until this is fixed, it's not even in the running as a usable editor for me.
Post reply on HN