Live data from Hacker News

Development Environments

phaazon.net

91–100 of 145 posts

Re: Development Environments

#91
post #82

Earlier quoted context omitted.

> 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 And then you realize you have to refactor 25% of it, or the requirements change, or a newly incorporated library suggests a naming convention change would be wise... IDEs not only show the code, you can pick a function argument, rename it, and get it renamed across all…

You don't even need a terminal editor to do that; sed will do it fine. If you want to be pedantic about the mechanism by which you achieve the result, you can just use ctags, which even plain vi and emacs support. What really set IDEs apart from text editors was integrated build tools and the ability to directly consume (and act on) build errors and the like. Search-and-replace long predates IDEs, as does 'code compr…

An IDE is aware of the structure/meaning of the code, giving in much more power.

sed absolutely cannot rename all the occurrences of something like a class method, since it would require deep dependency graphs to find all the class instances.

In an IDE, I can do something like this:

    # All three classes have a do_thing() method.
    my_instances = {
        1: Class1(),
        2: Class2(),
        3: Class3(),
    }

    my_instances[1].do_thing()
    my_instances[2].do_thing()  
    my_instances[3].do_thing()
In the IDE, I can rename the do_thing method for Class2, and it will correctly change the line "my_instance[2].do_thing()" to reflect the new name, leaving the others alone. This is not possible without something mostly indistinguishable from an IDE.

Re: Development Environments

#92
post #87

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…

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…

> is effectively an IDE

If it's a text editor with an understanding of the code, that also allows debugging, then it's an IDE by definition.

Re: Development Environments

#93

Many people seem to think using a commercial proprietary IDE means you somehow forget how to use the CLI or other editors to get the job done. Like they're junk food that makes you dumb. This is as ridiculous as saying an electrician will forget how to correctly wire because their wire cutters are too good. I used to be a build-my-own IDE person via VIM. After using PyCharm and realising an IDE is more than an editor…

And, in case anyone wasn't aware, PyCharm has vim plugin, for the editor: https://www.jetbrains.com/help/pycharm/using-product-as-the-...

Re: Development Environments

#94
There are four things which IDEs typically provide which I find invaluable. It's probable that some or maybe even all of them could be wedged into Vim or Emacs, but then you'd have basically an IDE.

1. Quick go to _anything_. In IntelliJ IDEs, it's double-shift, and then start typing some of what you want. Usually you can find the class or module or file you want easily, if not automatically.

2. Interactive debugging. This is so very useful. Usually it's just the fastest way for me to inspect a data structure at a certain point in time, or even find out what's going on in a framework that uses a lot of metaprogramming.

3. Jump to definition of thing (function, constant, etc.), and conversely show usages. In a well designed system of composable single responsibility functions, one can almost forget about files and navigate only with these (and (1)).

4. Git diff my branch to branch X. Lots of extra goodies can be included in this, such as interactive merge conflict tooling, etc.

Re: Development Environments

#95
post #87

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…

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 vendor integrated it for you (though sometimes, rather than collecting small modules of your own, you can get a pre-integrated set of modules for a particular use for a programmable editor, and that is exactly an IDE.)

> Emacs still feels 1000x more modern to me than any IDE, especially VS Code

VS Code, like Emacs, is a programmable editor, not an IDE. (though I guess it's built-in, first party tooling for certain languages makes it a very light IDE for them.)

Re: Development Environments

#96

My experience is quite different: I feel extremely productive working in the terminal, and what is described in the article as "The frozen world" is for me a virtue of the UNIX philosophy: the structure is not embedded in the data, but the programs can project a structure on it. That allows programs to be filters, and text to be the only format for exchanging information. What the article describes as "The nightmare…

> the terminal provides a very fast feedback loop where I can iteratively examine the output of a command and refine the filters I apply

An IDE would be used to develop those commands, more than compose them.

> text to be the only format for exchanging information

For this to work, with non-text data, you end up using the file system as a buffer, then passing filepaths between commands. For many contexts, this isn't performant enough.

Re: Development Environments

#97
post #49

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…

> The number 1 thing I hate about IDEs and will always hate about IDEs is that you open a "workspace" you cannot access all of your files at once. So often I am working with multiple git repos or various things scattered around my computer. In emacs I can simply open the file and have all the syntax highlighting, linting, etc just work. Instead of waiting for 10s for a whole new IDE workspace to open. And then not ev…

I sometimes find myself using neovim _in_ the VS Code terminal when I need to quickly jump out and edit a non-project file like a ssh config or something

Re: Development Environments

#98

Earlier quoted context omitted.

It seems like Java is in a pretty unique place in terms of the quality of the tools and the frequent need to use complex tools to get even a vague idea what's going on.

True. But Idea Ultimate works surprisingly well with JavaScript and very well with Typescript including react code, etc. It's so much easier than going through NPM noise. Just auto fix and in 95% of the cases it's just what I need. The JetBrains IDEs for other platforms have almost the same level of capabilities. I also worked a lot with xcode, its not nearly as good as AppCode but it's still an improvement over tryi…

I should give it another go I guess. My last serious shake of Jetbrains for JS was on an angular 1 + gulp project a few years ago and it just couldn't do anything helpful.

Re: Development Environments

#99

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…

If you need an IDE to manage the complexity in large, complex software projects, then you need an IDE for the kernel -- one of the largest, most complex single software projects around. IDEs are written for this purpose -- modern CodeWarrior, for one. The fact that many kernel devs including Linus himself get along fine without one suggests that IDEs are not the universal good you seem to think they are.

In particular, they are great if you follow the happy path anticipated by the IDE developers, but when things get weird, the IDE won't help you. So I tend to see a lot of IDE users alt-tabbing between their IDE, terminals, Postman, DBVisualizer, and what else have you which plays havoc with my brain and would only slow me down if that were my workflow.

There's a perspective dependency to whatever the best tool for the job is. Some people can't live without a bell- and whistle-laden IDE; I can't live without a code editing tool that I can shape to my needs while I'm using it

Which is why I won't be giving up Emacs any time soon.

Re: Development Environments

#100

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…

> to choose salad when there's [...] pizza

to that extent which everything ends up philosophical, why not both?

Post reply on HN