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

131–140 of 145 posts

Re: Development Environments

#131

Post by bern4444 »

roflyear wrote: post #130
spoils19 wrote: post #123

Earlier quoted context omitted.

I'm able to do all these with a simple text editor, an IDE takes up resources, implements tracking, and real programmers basically have no use for anything aside from a simple text editor.

How's refactoring support and formatting code? Navigating code as in click and go to definition? I say this because I work with someone who uses VIM and these are constant issues working with them.

for neovim with lspconfig:

formatting code: `lua vim.lsp.buf.formatting_sync()`

go to definition: `lua vim.lsp.buf.definition()`

rename variable: `lua vim.lsp.buf.rename()`

type information: `lua vim.lsp.buf.hover()`

find references: `lua vim.lsp.buf.references()`

code actions (add missing import etc): `lua vim.lsp.buf.code_action()`

For more commands `:h vim.lsp.buf`.

There is plenty available through LSP today supported by all editors. IDEs provide a better debugging experience (with breakpoints and variable values) though that too can be done with vim/neovim using the debug adapter protocol and plugins built on it (similar to language server protocol but for debugging).

Re: Development Environments

#132

Post by 9dev »

bern4444 wrote: post #131
roflyear wrote: post #130

Earlier quoted context omitted.

How's refactoring support and formatting code? Navigating code as in click and go to definition? I say this because I work with someone who uses VIM and these are constant issues working with them.

for neovim with lspconfig: formatting code: `lua vim.lsp.buf.formatting_sync()` go to definition: `lua vim.lsp.buf.definition()` rename variable: `lua vim.lsp.buf.rename()` type information: `lua vim.lsp.buf.hover()` find references: `lua vim.lsp.buf.references()` code actions (add missing import etc): `lua vim.lsp.buf.code_action()` For more commands `:h vim.lsp.buf`. There is plenty available through LSP today supp…

So, am I supposed to type all that cruft? Instead of just pressing alt-enter to bring up the suggestions menu, choose the obvious first item by pressing enter again, and have everything you have to remember several arcane incantations for done automatically..? I never got the command line purist crowd. I prefer spending time on solving business domain problems…

Re: Development Environments

#133

Post by CapsAdmin »

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…

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

This reads a little bit like a dynamic language vs a typed language. One argument for writing dynamic language is kinda similar to this.

When I write code in a typed language I have to think far less than if I write it in a dynamic language as the tooling takes care of it for me. But in my experience no matter how much I think about how to solve something in a dynamic language I make far less mistakes in a typed language.

Re: Development Environments

#134

Post by spullara »

anonymoushn wrote: post #72
spullara wrote: post #9

Earlier quoted context omitted.

The only reason Java can even have the most powerful tools is because it is easy to see what is going on. Also, JetBrains does really well with all languages, generally more than any other IDE.

I haven't encountered features in other languages that are pervasively used and work by leaving meaningless markers in the code which some other (typically undocumented, typically in another repository) code will eventually use to do codegen, AST rewriting, and so on. But other than this feature that's like way more difficult than macros in Lisp or C, which makes up like 20% of non-whitespace lines in Java code I hav…

If you mean annotations that are easily traceable to the package that provides them, I suppose. That isn't how I program in Java these days but a lot of people do like that style. Honestly though I don't find it much different than Derive in Rust or extension methods in Swift.

Re: Development Environments

#135

Post by spoils19 »

9dev wrote: post #132
bern4444 wrote: post #131

Earlier quoted context omitted.

for neovim with lspconfig: formatting code: `lua vim.lsp.buf.formatting_sync()` go to definition: `lua vim.lsp.buf.definition()` rename variable: `lua vim.lsp.buf.rename()` type information: `lua vim.lsp.buf.hover()` find references: `lua vim.lsp.buf.references()` code actions (add missing import etc): `lua vim.lsp.buf.code_action()` For more commands `:h vim.lsp.buf`. There is plenty available through LSP today supp…

So, am I supposed to type all that cruft? Instead of just pressing alt-enter to bring up the suggestions menu, choose the obvious first item by pressing enter again, and have everything you have to remember several arcane incantations for done automatically..? I never got the command line purist crowd. I prefer spending time on solving business domain problems…

What if the suggestions menu crashes? Have you considered the extra RAM that is being used that could go further towards solving business problems? What if the curated menu of autosuggestions doesn't contain what you need?

Re: Development Environments

#136

Post by eikenberry »

invalidname wrote: post #101
eikenberry wrote: post #79

Earlier quoted context omitted.

IMO this has 2 issues. #1 If you need an IDE to handle simple things like you list I think the language's development model is designed with IDEs in mind (eg. Java). Better language support and tooling makes all these things trivial without an IDE. #2 There are no good Free Software IDEs and I will not make ethical compromises with my maker tooling.

Java didn't have a decent IDE for the first 10 years of its existence and I hated IntelliJ/NetBeans etc. when I first used them. The tools improved. They work great for all the languages I use. I'm not smart enough to keep an entire code base of every project I ever worked on in my head. Maybe you're a genius of a different level, even then... Wouldn't it make sense to clear the area of your brain that needs to remem…

You don't need an IDE to get, eg. function parameters, all normal programming oriented text editors do this now. IMO all of the 'editor' focused parts of IDEs are done great by the programming oriented text editors. It is the non-editor parts where IDEs differentiate themselves. Integrating testing, debugging, project management, refactoring, etc. Some of these things IDEs do pretty well and would be nice but they are not worth the tradeoffs you give up IMO. I prefer the looser coupling and composition you get with CLI oriented tools and value those aspects over the limited things that IDEs would offer.

And none of this covers the fact that none of the good IDEs are Free Software. Which automatically removes them from consideration.

Re: Development Environments

#137

Post by invalidname »

eikenberry wrote: post #136
invalidname wrote: post #101

Earlier quoted context omitted.

Java didn't have a decent IDE for the first 10 years of its existence and I hated IntelliJ/NetBeans etc. when I first used them. The tools improved. They work great for all the languages I use. I'm not smart enough to keep an entire code base of every project I ever worked on in my head. Maybe you're a genius of a different level, even then... Wouldn't it make sense to clear the area of your brain that needs to remem…

You don't need an IDE to get, eg. function parameters, all normal programming oriented text editors do this now. IMO all of the 'editor' focused parts of IDEs are done great by the programming oriented text editors. It is the non-editor parts where IDEs differentiate themselves. Integrating testing, debugging, project management, refactoring, etc. Some of these things IDEs do pretty well and would be nice but they ar…

Editors get this wrong when there are multiple complex and overriden functions/methods. Furthermore, they can't display things in the same way an IDE displays them. I suggest checking out a modern (admittedly non-free but open source) IDE. JetBrains displays argument names in an ineditable area next to the argument values.

When debugging it shows the values that changed in each line in an area next to the line of code. It's amazing.

Re: Development Environments

#138

Post by rvdginste »

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 think it's a bit naive to think that a given developer will produce better code when using an editor instead of an IDE. I believe that a certain developer will produce the same quality code whether he uses an editor or an IDE.

If you use default templates and don't really care about the structure of your code when using an IDE, you won't suddenly start to care when using an editor. If you don't care about all kinds of shortcuts and specific functionality in your editor, you won't care about learning the shortcuts (and even functionality) in your IDE.

Some people seem to think they will become better developers by learning to do their development with an editor, but I do not believe that is true. Maybe except for one thing: if you do use an editor and don't use something like LSP in your editor, you will be forced to memorise the standard libraries of your programming language; you need to memorise those to stay productive with an editor. And in general, I do believe that the pure text editing part is often more advanced in a good editor than in an IDE.

But, a good IDE is an amazing tool when you have the hardware to run it. Especially with typed languages, an IDE makes it a lot easier to refactor code and change the design of your code. This really lowers the threshold to change the design of your code when requirements change. Since the changes are simple and fast, developers are more confident to do those changes and will consider those changes in more cases. And aside from that, IDEs also often include an analysis part and warn you about fishy things in your code.

I have been an Emacs user for a very long time. I used it for C long time ago, and recently used (limited) it with an LSP server for C# (using the Doom Emacs distribution). And that is working nicely: magit is great, integration with LSP servers is great... you can get a lot of the stuff that is typical for IDEs. But when you do activate all those integrations, you will notice that it is also heavier to run and less responsive. So, in the end, when the hardware can run it, my preference is still the full-blown Rider IDE for C#. The IDE is much more complete out-of-the-box.

Re: Development Environments

#139

Post by namaria »

mid-kid wrote: post #35
namaria wrote: post #17

I understand where the author is coming from and I myself sympathize with the idea of sticking to Unix philosophy of composing small focused tools instead of using complicated tools. That said, I have learned to stick to defaults and start from a clean slate every time. I often say that the main problem in software is containing complexity. When you need to deliver a product that works reliably, you want to remove al…

While I agree that this sort of workflow keeps development environments reproducible, I disagree with freezing editing tools like this. Nothing about your project should require specific IDEs or similar software. Like you said, less complexity is easier to make more reliable, so stick to purely the tools necessary to build and run the software, rather than including the tools to edit it. If I need a VM for things, I…

Absolutely. I am not installing VSCode on production VMs, the step I described is purely for setting up a portable developer environment. Then instead of telling other developers to install a laundry list of tools I can just give them a copy of my VM. Throw in something like Vagrant and it's easy to share a standard work environment. Then to roll things into production it's another game.

Re: Development Environments

#140

Post by _glass »

dragonwriter wrote: post #95
ftlio wrote: post #87

Earlier quoted context omitted.

In my experience, most IDE users don’t know that Emacs is effectively an IDE that can do all of the same things, and even more. When you show them, then the complaint is that it’s a hassle to configure, and I don’t really know what to do with that. I like configuring my text editor. I’ve worked with tools my entire life and the main difference between Emacs / VI and other IDEs is they’re tools you can hone infinitely…

> In my experience, most IDE users don’t know that Emacs is effectively an IDE that can do all of the same things, and even more A programmable editor can, by programming (and in many cases, this means using modules others have programmed) become a Development Environment both more powerful and more adapted to your particular use than any available Integrated Development Environment, but it's not an IDE because no ve…

I program my Emacs for very basic stuff, but very specialized for projects. For other developers (even who use VSCode) it's black magick. I think Emacs has also a culture of tinkering.
Post reply on HN