News for hackers. Stuff that matters.
Re:What's the Future of IDEs? by spacechild1 on Wednesday November 24, 2021 @12:00PM (#29332145)
> get rid of the toys and learn the tools

A good IDE is not a toy, it is a very powerful tool.

How do you work in a large C++ code base using only a text editor? You will certainly need a couple of plugins, e.g. for linting, definitions/implementation look up, auto complete, etc. Then what is the actual difference to an IDE?

Re:What's the Future of IDEs? by fho on Thursday November 25, 2021 @03:34AM (#29339411)
Not OP, but I guess his point is that all those things are either accessible from the command line (linting) or available as plugins from vim.

As an additional point: I've been working on a "polyglot" project for some years now, most of it is in Python (data-analysis) and C# (Unity), but there is also C/C++ (real-time components) and even some Haskell (some small "scripts") in there.

I do all my programming in vim with basically just syntax highlighting, relying on the web for "definition look up" and typing fast instead of "auto complete".

Code lookup (i.e. "where did that function go") is handled by RipGrep, continuous builds are handled from the command-line (with fsnotify), etc.

=> Definitely just "my 2 cents", but I've been using Vim for so long that every IDE text editing feels very sluggish in comparison.

Re:What's the Future of IDEs? by iio7 on Wednesday November 24, 2021 @01:43PM (#29333545)
> How do you work in a large C++ code base using only a text editor? You will certainly need a couple of plugins, e.g. for linting, definitions/implementation look up, auto complete, etc. Then what is the actual difference to an IDE?

In the beginning I felt I needed linting, definitions, etc, so I began by stuffing Vim with plugins. Then I discovered that I was much more productive when I didn't use any of that, but actually kept the documentation close by.

Now I just remember most of the definitions or quickly look them up and combine the usage of console applications like grep, find, sed, etc. with Vim. I have about 3 custom made Vim functions that serve as shortcuts for at few of the things I need often.

Personally it's the most productive for me and the tool gets out of the way.

Re:What's the Future of IDEs? by spacechild1 on Wednesday November 24, 2021 @02:12PM (#29333889)
> Now I just remember most of the definitions or quickly look them up and combine the usage of console applications like grep, find, sed, etc.

This sounds strictly worse than what IDEs have to offer (I am thinking specifically about C++).

> Now I just remember most of the definitions or quickly look them up

May I ask with which languages you work and how large the code bases are?

Personally, I work with what I'd call medium-sized C or C++ code bases (100k - 200k LOC) with hundreds of functions/methods. There is no way I can remember their signatures. When I start typing a method, my IDE will immediately show all the possible overloads with their parameters. When I hit F2, it immediately jumps to the definition. I seriously can't imagine how abandoning these features could make me more productive.

I'm always stumped when I hear people saying they are more productive in a text editor, even if they had already tried IDEs. I honestly like to understand how this is possible.

Re:What's the Future of IDEs? by z3t4 on Wednesday November 24, 2021 @01:59PM (#29333728)
Remembering the core syntax and api's are like magic for productivity, you no longer think in words or variables, you think in data structures and how different endpoints and functions interact, your hands type the code via muscle memory.

Only problem is that the code can sometimes become a bit terse if you do not have an autocomplete, a dumb autocomplete is often enough though.

Re:What's the Future of IDEs? by spacechild1 on Wednesday November 24, 2021 @02:13PM (#29333919)
Does this also work for large code bases? In my experience it doesn't, but maybe my memory is just not very good :-)
Re:What's the Future of IDEs? by z3t4 on Wednesday November 24, 2021 @02:35PM (#29334171)
It depends how you manage scope. When there are thousands of global variables it will be impossible, but if the language (like Dlang) allows local scoping of imports it's manageable... If you are very strict about what is an actual dependency or just a magic global. The rule is that if the import can be used in other programs/code-bases you can import it. But if it's just a way to get around using global variables you should rethink the architecture. ... Yes IDE's will find the definitions in your spaghetti code-base, but then they become part of a problem loop where the code-base would be unmanageable without the IDE.

Namespaces are also a good solution to use instead of globals or magic globals. But it might become a category theory problem like where in the hierarchical structure you should put something.

The best solution of course is to keep the code base small :)

Re:What's the Future of IDEs? by spacechild1 on Wednesday November 24, 2021 @03:00PM (#29334417)
Hmmm, the whole program still consists of hundreds of functions and I would have to memorize all of them... I don't just work on a single module, I work on the whole code base (open source development).

> The best solution of course is to keep the code base small :)

Hehe, that's the trick. Unfortunately, I came late to the party.

Re:What's the Future of IDEs? by iostream23 on Wednesday November 24, 2021 @03:24PM (#29334701)
Well. Typically I review the code and say “what kind of twisted sadistic prick wrote this” and then realize that it was me 5 months ago. It’s amazing the level a detail a person can drill into when it’s the locus of focus, and amazing how quickly context is forgotten. Stream of consciousness audio notes would arguably be more useful in such settings than code completion, as the muscle memory is still there, it’s merely the “why” that disappears
Re:What's the Future of IDEs? by iostream23 on Wednesday November 24, 2021 @03:20PM (#29334659)
Kiel has some tools I’ve not found an integrated easy way of replicating in emacs etc. Mind you, a simple make file suffices for most smaller projects