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

Development Environments

phaazon.net

Post reply on HN
Print view View original

61–70 of 145 posts

Re: Development Environments

#61

Post by dhzhzjsbevs »

eklavya wrote: post #31
dhzhzjsbevs wrote: post #20

Earlier quoted context omitted.

Yea but you only need all that junk because you use Java. The rest of us just don't have that many files to refactor when we change things. I don't really hate ide's, I get the appeal, and sometimes it works out useful. It's just that most of the time it comes back to enterprisey software being the source of your problems, not the lack of features in your editor.

Calling IntelliJ and Java junk is probably an indication that you are inhibiting your professional growth.

I was calling ide features in general junk but sure, project away.

Re: Development Environments

#62

Post by soggybutter »

parentheses wrote: post #13
invalidname wrote: post #2

I've been programming since well before we had IDEs... I love them. Proper modern IDEs provide a level of insight and tooling that the anti-IDE crowd just don't get. A couple of decades ago they were problematic. But today's unified toolchains and improvements made them far better. The one semi legitimate problem people have is performance. I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultima…

I’ve yet to give VSCode a fair shake. I used IntelliJ a lot back in the day. IntelliJ is special. Last I had seen they employ their own language tooling for almost everything. Nowadays the CLI (TUI) experience is capable of a LOT. CLI editors have fantastic integration with languages via LSP. You end up with similarly fat but more modular tooling. They offer a modularity and options that give you more choice in build…

This has been my experience. I'm by no means an IDE power user, but the only things I really missed while using vim were finding references and going to definition. Nowadays I can do that in vim for every language I care about without much configuration or effort, and there's a bunch of additional features available I still leave on the table

Re: Development Environments

#63

Post by eadmund »

invalidname wrote: post #47
eadmund wrote: post #44

Earlier quoted context omitted.

> Modern IDEs really improved since then and I haven't seen a feature that emacs can do that they can't. Easy extensibility. Read email. Run a calculator. Run Lisp … Meanwhile, there is literally no feature any IDE has which Emacs cannot do. It's just a simple matter of programming.

Everything is "just programming" but deep semantic heuristics from an IDE can't be done reasonably in Emacs. Most of the big features require keeping a full AST model of the project in RAM. That would make emacs/vi really slow. IDEs are 100% extensible via plugins. Wrote a few of those myself.

> Most of the big features require keeping a full AST model of the project in RAM. That would make emacs/vi really slow.

That's what LSP does, and emacs supports LSP. Heck, it even has two packages implementing support for LSP.

For that matter, I don't see any reason why Emacs would be any worse at keeping a full AST in RAM that is an IDE. Emacs Lisp is not the most efficient runtime out there, but it's acceptable.

> IDEs are 100% extensible via plugins.

Plugins are not 100% extensibility: they only enable one to extend the IDE in the ways the plugin system was designed to allow. Emacs, OTOH, enables one to extend or replace all editor functionality implemented in Lisp. I am not aware of any other IDE which offers, for example, all of the following: multiple email clients, a net news client, an IRC client, a Slack client, multiple web browsers, a Git UI, a spreadsheet, a personal organiser, multiple calendaring systems, a computer algebra system, multiple file managers, multiple shells and terminal emulators, an RSS client, a music player and Tetris.

Re: Development Environments

#64

Post by soggybutter »

bandrami wrote: post #46
invalidname wrote: post #33

Earlier quoted context omitted.

This is like saying the problem with using my hands is that I never know when my next job will be a football (soccer) player. I get that it's a muscle you need to practice. But limiting yourself to fit a potential restriction makes no sense.

There's something to that argument, though. You probably shouldn't use an IDE when you're learning a language. You should at least understand what it's doing behind the scenes and why.

100% agree with this. I've seen plenty of devs who type a couple dozen characters in a session and spend the rest of their time clicking around on IDE prompts. This isn't necessarily a bad thing, but I've seen newer devs become completely crippled if their IDE misbehaves. And it's not uncommon for them to have very little understanding of the project structure because their IDE abstracts most of it away.

It also promotes a pet peeve of mine, which is programmers that can barely type. I know plenty of people will yell at me saying that doesn't actually matter, but it's wild to me in a profession where typing is the primary way you interact with your work that so many folks can barely manage a typo-ridden 60wpm

Re: Development Environments

#65

Post by imaltont »

invalidname wrote: post #15
pech0rin wrote: post #12

Earlier quoted context omitted.

I dunno. I have used a lot of IDEs in my day but I always go back to emacs. I know its not for everyone but I can still have a running python, ruby, etc process and send bits of code to the process and interactively iterate on ideas smoothly. Also with the advent of language servers jump to definition, large refactoring of symbols, etc are pretty straightforward. The number 1 thing I hate about IDEs and will always h…

A lot of my friends used emacs back at Sun. Modern IDEs really improved since then and I haven't seen a feature that emacs can do that they can't. Yes a JetBrains IDEs will take longer to build the AST model in RAM but once you have it they do amazing things with it. E.g semantic search and replace, etc. The debugger capabilities are spectacular, they literally show the values of variables on the side of the line you…

> Yes a JetBrains IDEs will take longer to build the AST model in RAM but once you have it they do amazing things with it. E.g semantic search and replace, etc. The debugger capabilities are spectacular, they literally show the values of variables on the side of the line you stepped over. Another cool thing, inferred types just show next to the variable definition, parameter names appear in the method call, etc. These are small things that add up to a lot on the day to day.

Emacs has all of the things mentioned, either through plugins (LSP, Tree sitter, DAP) or built in (tags, GUD). Especially LSP-mode has over the last few years made sure you can integrate your favorite text editor into pretty much any language, for certain languages/technologies it still makes sense to pull up the specialized tools for e.g. debugging, deploying, building, publishing etc, but you can do a lot with the more general tools too.

Re: Development Environments

#66

Post by the_gipsy »

eklavya wrote: post #31
dhzhzjsbevs wrote: post #20

Earlier quoted context omitted.

Yea but you only need all that junk because you use Java. The rest of us just don't have that many files to refactor when we change things. I don't really hate ide's, I get the appeal, and sometimes it works out useful. It's just that most of the time it comes back to enterprisey software being the source of your problems, not the lack of features in your editor.

Calling IntelliJ and Java junk is probably an indication that you are inhibiting your professional growth.

Ah yes Java and IntelliJ are clearly enterprise professional, the rest is amateur hippy toys.

Re: Development Environments

#67

Post by the_gipsy »

tsujp wrote: post #23
invalidname wrote: post #2

I've been programming since well before we had IDEs... I love them. Proper modern IDEs provide a level of insight and tooling that the anti-IDE crowd just don't get. A couple of decades ago they were problematic. But today's unified toolchains and improvements made them far better. The one semi legitimate problem people have is performance. I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultima…

What happens when you now want to work in say.. Crystal, or Shell, or Rust, or Zig, or any other language for which there is not an IDE (even those also by JetBrains) which is 1:1 feature compatible to IntelliJ? Not all JetBrains IDEs have the same features. Rider (for .NET) only recently got remote editing support which IntelliJ already had for instance. Now you're only as good as your tool (IntelliJ) and you cannot…

That's the neat part, you don't.

Re: Development Environments

#68

Post by yesbabyyes »

jrop wrote: post #53
annowiki wrote: post #43

Earlier quoted context omitted.

I consider myself quite adept at cli, I can sed, grep, find, vim, and git quite well. However, what I never found convenient in cli was debugging. I was a print debugger for years until my job convinced me to try PyCharm. I've always thought the reason I never found a suitable debugger in cli was just because I was either too dumb to figure out integrating something like vimspector, or too lazy to get used to gdb/pdb…

I use NeoVim for everything except debugging. For that I (frequently) open up VSCode or Chrome to debug (NodeJS). I haven't figured out a good debug workflow for Rust, though, because I hate print debugging.

I'm similar to you (but with vim instead of neovim - I have to say VSCode with the vim extension is winning me over though).

VSCode with rust-analyzer (edit: and CodeLLDB) provides a very nice environment for Rust development in my experience, including debugging.

Re: Development Environments

#69

Post by invalidname »

tpoacher wrote: post #50
invalidname wrote: post #2

I've been programming since well before we had IDEs... I love them. Proper modern IDEs provide a level of insight and tooling that the anti-IDE crowd just don't get. A couple of decades ago they were problematic. But today's unified toolchains and improvements made them far better. The one semi legitimate problem people have is performance. I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultima…

I realise I'm probably alone in this, but this "depth of insight" is exactly one of the curses of IDEs for me. When you write on a terminal, you are encouraged to make good choices so that your code is clean, with a well-thought-out structure and conventions that allow it to be read and processed by a number of tools as painlessly as possible. When you're on the IDE, your code structure invariably reflects whatever w…

I worked on the mess of make file and C dependencies created on Emacs in Sun Microsystems back in the day. You can make a mess with any tooling.

It was impossible to navigate and I spent most of my time constructing complex regexes for grep just to follow the flow. In an IDE I can right click an element to find usages/dependencies, etc. Some of them are just highlighted.

Re: Development Environments

#70

Post by invalidname »

eadmund wrote: post #63
invalidname wrote: post #47

Earlier quoted context omitted.

Everything is "just programming" but deep semantic heuristics from an IDE can't be done reasonably in Emacs. Most of the big features require keeping a full AST model of the project in RAM. That would make emacs/vi really slow. IDEs are 100% extensible via plugins. Wrote a few of those myself.

> Most of the big features require keeping a full AST model of the project in RAM. That would make emacs/vi really slow. That's what LSP does, and emacs supports LSP. Heck, it even has two packages implementing support for LSP. For that matter, I don't see any reason why Emacs would be any worse at keeping a full AST in RAM that is an IDE. Emacs Lisp is not the most efficient runtime out there, but it's acceptable. >…

I haven't written LSP so I'll reserve the opinion at that. What I understood about emacs is that it doesn't have a concept of a project so I don't see how it can form dependencies that are more sophisticated. But maybe I don't understand something about that.

I can totally write these sort of plugins for any IDE I worked with. Notice that all of these capabilities are symbols of a bygone time where you stuck everything into an editor. There's no motivation for a plugin developer to do these sort of things. Instead we have plugins like Lightrun, TabNine/Copilot, etc. Stuff that's actually useful for development.

JetBrains (and some other IDEs) have a builtin file manager, terminal, etc. These make some sense for development.

Post reply on HN