On 19.01.2025 03:56, Carlos E.R. wrote:
On 2025-01-19 03:50, Carlos E.R. wrote:
On 2025-01-19 01:44, Lawrence D'Oliveiro wrote:
On Sat, 18 Jan 2025 23:29:39 +0100, Carlos E.R. wrote:
On 2025-01-18 21:55, Lawrence D'Oliveiro wrote:
On Sat, 18 Jan 2025 21:19:06 +0100, Carlos E.R. wrote:
>
I know profesional programmers that never used an IDE.
>
IDEs only support limited ways of building things. Far better to
have a
general-purpose editor, like Emacs, that is capable of driving any
build
system.
>
A good IDE can do things like set breakpoints in the source code, start
the application in debug mode, and run a line a time, while examining
the variables (even writing into the variables).
>
Not in the debugger, but in the IDE.
>
Launch the debugger from within an editor window. Simples.
>
That's not it. I don't want to launch the debugger.
Look, I understand that you are happy without a fully featured IDE. But
similarly, I am asking you to accept that I am not happy without a fully
featured IDE.
Yes. And I think you are right. But we should also sort things a bit.
An IDE is something completely different than an editor, of course.
It's a thing where typically tons of different features are combined
and _strongly interconnected_ to offer an integrated user experience.
That's a strength of IDEs, and a weakness. What LDO was implicitly
trying to point out was (I think) that it's good to have tools that
have a clear task (you don't pay for things that you don't want) and
a flexible interface (to make use of _powerful_ components). The tool
or IDE designers, for example, could provide a setting where you can
choose the (integrated) components. An editing interface, for example,
is quite simple and clear, and it would in principle be possible to
use any editor (per user setting) also in an IDE; for the interacting
features you'd just need a (typically small) "adapter layer". In fact
there's quite some well designed tools that allow to use own editors.
The advantages are multifold; it's not only that you can use for the
individual features specialized components - components that do their
respective job much better than any IDE-built-in re-implementation of
a feature (or a "clone"). During the decades of my IT practice I used
IDEs twice. The problems I had with them was, for one, that I had to
use exactly what was supported by the IDE, and use of any powerful
tools to efficiently perform tasks that I was used to was impossible
or overly cumbersome by clumsy workarounds. For someone who is used
to do _arbitrarily complex_ editing functions in an _efficient_ way
(with powerful editors) it's really a pain to work with common IDEs.
But many people I observed were doing quite _primitive editing_; they
don't know better given all the GUI based primitive editors that we
typically often find as inferior ad hoc editing (re-)implementation
and that folks got used to. With IDEs it's often just a mouse orgy of
clicking things together in a mixture of mouse/menu and text input,
no editing any more. The efficiency of keyboard(-only) input (e.g. in
editors) has to be compensated by other means (like auto-completion).
I think that's one reason why the opinions are so strong and why the
permeability from one group/type of users/programmers to the other
is so difficult. I'd only have wished that folks who speak about the
pros and cons [of IDEs and powerful editors] would not be completely
ignorant and full of prejudice; ignorance AND prejudice is a very bad
(and in Real Life topics even dangerous) combination.
Both things are true for many programmers.
Janis
PS (as an aside): While IDEs usually try to increase their feature
set for a yet better support of their dedicated tasks Emacs is often
[humorously] despised (especially by Vi users) as not being an editor
but more of an IDE.