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

21–30 of 106 posts

Re: Unix as IDE (2012)

#21

Post by brachi »

glouwbug wrote: post #6
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.

Keep your declarations on a single line: int fun(void*); And grep -r fun *.h Will tell you everything you need

also, you could use ctags.

Re: Unix as IDE (2012)

#22

Post by jrockway »

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, there's some technology to be shared or extracted here from desktop IDEs.

I use "bazel test ..." to build stuff on the command line and my CI system runs "bazel test ..." to build stuff in CI. They can even share the same cache, and the cache actually works. (I admit for that 90% of go stuff I just use their build tool, though.)

I think IDE-integrated build systems are an artifact of times where people didn't write multi-language projects and there weren't good open source build systems. Things have changed a little, and now you can have your cake and eat it too.

(Autocompletion has also moved out of IDEs and into things maintained by languages themselves.)

Re: Unix as IDE (2012)

#23

Post by RcouF1uZ4gsC »

socialdemocrat wrote: post #20
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 th…

> My experience as a C++ developer for many years on Linux is that debuggers just don't work that well.

That has been my experience on Linux. On Windows, Visual C++ debugger works amazingly well.

Re: Unix as IDE (2012)

#24

Post by [deleted] »

socialdemocrat wrote: post #15

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…

[deleted]

Re: Unix as IDE (2012)

#25

Post by Aperocky »

socialdemocrat wrote: post #16
Aperocky wrote: post #12

Earlier quoted context omitted.

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 ;-)

More trouble than ctrl-B though

Re: Unix as IDE (2012)

#26

Post by fourmyle »

IntelliJ Editors just straight up not working on Wayland right now has driven me insane. I really like Sway (i3) and Wayland is a must for mixed DPI setups. Now I have started using Kakoune and LSP for Go and Python and it works great. I tried Neovim for a while but having another window manager inside of Sway is too much of a burden. Kakoune opens new windows in Sway (or tmux). Combined with a plugin to make Firefox open tabs in a new window always I found my dream setup.

Re: Unix as IDE (2012)

#28

Post by istjohn »

socialdemocrat wrote: post #16
Aperocky wrote: post #12

Earlier quoted context omitted.

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 ;-)

Which terminal lets you do that?

Re: Unix as IDE (2012)

#29

Post by EdwardDiego »

fourmyle wrote: post #26

IntelliJ Editors just straight up not working on Wayland right now has driven me insane. I really like Sway (i3) and Wayland is a must for mixed DPI setups. Now I have started using Kakoune and LSP for Go and Python and it works great. I tried Neovim for a while but having another window manager inside of Sway is too much of a burden. Kakoune opens new windows in Sway (or tmux). Combined with a plugin to make Firefox…

> IntelliJ Editors just straight up not working on Wayland right now has driven me insane

Maybe don't use Wayland then. Or, at least, suffer the slings and arrows of outrageous fortune with some grace. You chose to use Wayland, making you a minority (Wayland users) of a minority (Linux users). All power to you to make your own choices, but to paraphrase an old favourite - "Freedom may be mankind’s natural state, but so is sitting in a tree eating your dinner while it is still wriggling."

TL;DR - you choose to use tech not supported by Jetbrains, so please feel free to eat your dinner while it's still wriggling.

Re: Unix as IDE (2012)

#30

Post by EdwardDiego »

socialdemocrat wrote: post #15

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…

> My editor of choice TextMate is usually launched from the terminal.

My issue is, I need an editor that knows that a field annotated with @Resource with a type and name of SomeService foo is injected by a DI framework and makes it easy for me to navigate to implementations of SomeService with a name of `foo`.

Sure, I could put hundreds of hours into half-way replicating what an IDE does. Or, I could just use an IDE that was written by people who've felt the same pain as me. TextMate might be good for the occasional Ruby or Python script, but even then - do I have to manually manage virtualenvs while working on this script, or can my IDE do it for me? (Spoilers: Intellij can)

Post reply on HN