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

Unix as IDE (2012)

sanctum.geek.nz

Post reply on HN
Print view View original

11–20 of 106 posts

Re: Unix as IDE (2012)

#11

Post by dntbnmpls »

tombert wrote: post #8

I've gotten made fun of because I've said my "IDE" is `tmux` in the past; my typical development environment is a tmux split, where an editor (usually NeoVim, sometimes Emacs) does editing, and the bottom half is a terminal running either a dev server or just the compiler command. It's not perfect, but I like how I can basically swap any component out (except tmux itself).

You could throw an extra layer of fun and use a windows manager with multiple workspaces/screens that serves as your IDE. One workspace could be for coding/debugging, another workspace could be for servers/system diagnostics/etc. Another could be for multimedia/distraction/etc.

Re: Unix as IDE (2012)

#12

Post by Aperocky »

samsquire wrote: post #10

What is it about an IDE that you need? a) The ability to do an end-to-end build with one click (we've lost that with cloud being part of the equation) b) Guranteed buildability c) Intellisense/autocomplete d) Widgets that can be moved into any which way. I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click, there's some technology to be shared or extracted here from desktop ID…

c)

Not much else, the ability to jump to code is the primary benefit.

Re: Unix as IDE (2012)

#13

Post by threatofrain »

samsquire wrote: post #10

What is it about an IDE that you need? a) The ability to do an end-to-end build with one click (we've lost that with cloud being part of the equation) b) Guranteed buildability c) Intellisense/autocomplete d) Widgets that can be moved into any which way. I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click, there's some technology to be shared or extracted here from desktop ID…

e) Some kind of debugging or program introspection.

Re: Unix as IDE (2012)

#14

Post by tombert »

dntbnmpls wrote: post #11
tombert wrote: post #8

I've gotten made fun of because I've said my "IDE" is `tmux` in the past; my typical development environment is a tmux split, where an editor (usually NeoVim, sometimes Emacs) does editing, and the bottom half is a terminal running either a dev server or just the compiler command. It's not perfect, but I like how I can basically swap any component out (except tmux itself).

You could throw an extra layer of fun and use a windows manager with multiple workspaces/screens that serves as your IDE. One workspace could be for coding/debugging, another workspace could be for servers/system diagnostics/etc. Another could be for multimedia/distraction/etc.

I actually do something similar to that when doing any kind of GUI apps; usually I have a workspace for my browser, another workspace for VLC, etc.

Re: Unix as IDE (2012)

#15

Post by socialdemocrat »

I don't like either extremes. I quite hate working in big bloated IDEs. But I don't like trying to accomplish everything at the terminal. I always use GUI and shell tools together.

My editor of choice TextMate is usually launched from the terminal. I work a lot in a REPL environment and when I get a stack backtrace my terminal program iTerm2 automatically identifies paths in the stack backtrace, so I can mouse click them and open in TextMate at the correct line.

I use a separate git GUI client called Tower a lot, but I also use the git command line. I mix and match a lot.

I really dislike monolithic tools. If you try to do absolutely everything from the CLI you get many of the same problems as in a IDE GUI: You get too much complexity in your interaction. Too many special keystrokes and commands to remember.

I quite like the old NeXT idea of an IDE, kind of how the old xCode was when interface builder was a separate program. As you integrate more tools complexity just grows.

We already have a multitasking OS with windows. We where meant to use multiple tools and not just sit in one big maximized monolithic program.

Re: Unix as IDE (2012)

#16

Post by socialdemocrat »

Aperocky wrote: post #12
samsquire wrote: post #10

What is it about an IDE that you need? a) The ability to do an end-to-end build with one click (we've lost that with cloud being part of the equation) b) Guranteed buildability c) Intellisense/autocomplete d) Widgets that can be moved into any which way. I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click, there's some technology to be shared or extracted here from desktop ID…

c) Not much else, the ability to jump to code is the primary benefit.

Pretty much every programmer editor lets you jump to code. I can even do that from my Terminal program. If I run a program and it produces and error my terminal interprets paths in the error message and let me click them to open my code editor at that file and line number. No IDE needed ;-)

Re: Unix as IDE (2012)

#17

Post by _jal »

tombert wrote: post #8

I've gotten made fun of because I've said my "IDE" is `tmux` in the past; my typical development environment is a tmux split, where an editor (usually NeoVim, sometimes Emacs) does editing, and the bottom half is a terminal running either a dev server or just the compiler command. It's not perfect, but I like how I can basically swap any component out (except tmux itself).

That's what I do, too. Vim and a couple shells and I'm happy.

I despise autocomplete and will not use things that force it on me. IntelliJ has options to make it not aggressively, in-your-face annoying, so I can live with it, and do use it for access to some tooling we built at $dayjob.

But after spending a day turning off all the bullshit, installing vim bindings, etc. I get... a slow, memory-pig semi-substitute for my shell environment that still is less flexible.

Progress.

Re: Unix as IDE (2012)

#18

Post by zozbot234 »

samsquire wrote: post #10

What is it about an IDE that you need? a) The ability to do an end-to-end build with one click (we've lost that with cloud being part of the equation) b) Guranteed buildability c) Intellisense/autocomplete d) Widgets that can be moved into any which way. I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click, there's some technology to be shared or extracted here from desktop ID…

> I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click

Isn't that what "make" is for? A Makefile and an IDE project file are quite similar in structure.

Re: Unix as IDE (2012)

#19

Post by quicklime »

RcouF1uZ4gsC wrote: post #3

I think code completion is missing. Sure you can always try to grep your function call, but seeing the parameters and return type of a function you are calling as you are coding is really nice. Also a real IDE does much better debugging. Using Visual Studio for debugging your program is much easier than using GDB, which is probably why the more Unix programmers use printf debugging rather than try to fire up GDB.

Now that language servers (https://microsoft.github.io/language-server-protocol/) are a thing, the code completion in terminal-based editors like vim and emacs can be just as good as what you'd get in an IDE.

Re: Unix as IDE (2012)

#20

Post by socialdemocrat »

RcouF1uZ4gsC wrote: post #3

I think code completion is missing. Sure you can always try to grep your function call, but seeing the parameters and return type of a function you are calling as you are coding is really nice. Also a real IDE does much better debugging. Using Visual Studio for debugging your program is much easier than using GDB, which is probably why the more Unix programmers use printf debugging rather than try to fire up GDB.

You can do that in a lot of editors. Don't need an IDE for that. You got standardized language servers now which are often easy to integrate in a multitude of editors.

But personally I don't like IDE style completions that much. In editors I often prefer completions based on what is in the file I am editing. But I also work a lot in a REPL environment.

I personally think a good REPL is a much better debugging tool than most IDE debuggers.

> Using Visual Studio for debugging your program is much easier than using GDB, which is probably why the more Unix programmers use printf debugging rather than try to fire up GDB.

That does not really have anything to do with IDE vs command line. My experience as a C++ developer for many years on Linux is that debuggers just don't work that well. Many of the issues has to do with the complexities of C++ and how gcc stores debug information.

Most IDE style debuggers on Linux are quite crappy, because they are slow and undependable. Printf is faster, more dependable and gives more flexibility in how you display data you are interested in.

Post reply on HN