
Myths programmers believe - ohjeez
https://atilanevesoncode.wordpress.com/2018/06/12/myths-programmers-believe/
======
mlthoughts2018
I've worked on some really large cross-cutting codebases, probably the largest
of which are these two:

\- an integrated aircraft and radar simulator that was originally written in
the 80s and has code from multiple languages, added and morphed over time by
many generations of different staff, and still in heavy use at least as late
as when I worked on it in the 00s.

\- a suite of different search engine services for a large (Alexa top 400)
ecommerce product search engine and online store.

My experience after working on these huge, legacy, complex codebases is that
if you need a "go to definition" feature in your editor or IDE, it's a symptom
of a notably bad codebase (not just regular bad with all the usual
suboptimalities that come up in corporate software, but notably worse than
that).

It's particularly bad when you have to use it to chase down an eventual base
implementation in a hopelessly convoluted stack of inheritance.

The pieces of software I've seen have the longest shelf life have been written
with exacting and unforgiving focus on simplicity and separating units of
code, in such a way that the details of an implementation are never far.

It's sort of like the code's design is a conceptual KD-tree, so conditioned on
being in a sub-section of the code, you know for sure anything you depend on
is nearby and not far away, and _certainly_ not hidden in a stack of
inheritance.

This is not an argument against "go to definition" capabilities in editing
tools. I just take a little issue when the author says,

> "Text editors can’t and don’t have features like autocomplete, go to
> definition, …"

> "This usually shows up in the same discussions where Emacs is a terminal
> program. It also usually comes up when someone says an IDE is needed because
> of the features above. I don’t program without them, I think it’d be crazy
> to."

I use Emacs and I never want autocomplete or "go to definition" features. I
hate them. In the cases when I unfortunately _need them_ it's a symptom of
exceptionally bad software, not an endorsement that these features are
themselves good things generally, except in so far as they offer help in
exceptionally bad codebases.

Insecticide is not a good thing generally. It's a good thing in bad cases when
there's an insect problem, but if you find yourself in that situation really
often, and you need insecticide so often that it becomes as familiar to you as
your morning coffee, then it's a sign of a much bigger problem.

~~~
girzel
> I use Emacs and I never want autocomplete or "go to definition" features. I
> hate them. In the cases when I unfortunately need them it's a symptom of
> exceptionally bad software

I can understand wanting to be able to code without these features, but I
can't understand "hating" them. I use "go to definition" not because I can't
find a function definition, but because it gets me there faster. What's the
moral advantage of opening a file and searching, vs hitting "M-."?

~~~
mlthoughts2018
If you're just talking about the first time you need to open the file, then
sure, who cares.

But I'm talking about the typical way of working when I have multiple files
open and move between them or place them into multiple Emacs windows. In that
case, it is SO much faster to jump based on knowing which file I intend to
move to, rather than moving to a file because it happened to be the file that
contained a given definition.

If I have to think, "go to wherever function X is defined" that's a drastic
mental slowdown compared with "C-x b <file where I already totally know where
function X is because of the code structure>".

It's similar with autocomplete, even for very long names. I am fast at typing,
so the little disruption of needing to enter a visual scan mode to select the
right entry from e.g. some JEDI autocomplete option is a huge time cost for me
added up over all the times I would write out e.g. function or class names in
my code.

They are both the sort of thing that superficially sounds like it would save
you time or cognitive load, but they don't, unless you happen to be in the
pathological codebase scenario I was describing and you _need_ the tools
because the project's code organization does not permit being able to reason
efficiently about it from local mental caches.

~~~
DatBear
I'm not sure what code completion you're using, but if it's contextual, I'm
very lost as to how typing a ridiculously long name would be faster than auto
completing it. Especially since once you're used to the auto complete, you can
basically use shortcuts for specific things you're using in that context a
lot. "BindingOperations.EnableCollectionSynchronization()?" oh, that's
"bop.ecs". There should be very few options to pick from unless everything is
very similarly named...

~~~
seandougall
I also find autocompletion invaluable when I'm working with an API I don't
interact with regularly enough to have everything memorized, mere mortal that
I am. I might not remember exactly what naming convention the methods conform
to, or what order the arguments need to be in, and autocompletion gets me both
of those essentially for free, without having to pull up the docs for every
method call.

~~~
mlthoughts2018
I can agree with this — if you’re really working on a codebase that you rarely
interact with, then sure, “jump to” and autocomplete features are helpful.

Over my career, the relative amount of time spent doing that is really tiny
though. It doesn’t invalidate the value of autocomplete or “jump to” features
for this use case, but for me it’s not common enough to matter a whole lot.
Other forms of searching work just fine too.

My other comments are written regarding the case when you’re hopping around an
in-house codebase, and beyond some initial burn-in, you should have a lot of
working knowledge of the details.

------
aequitas
> I mean that the inherent complexity of the task at hand doesn’t go away and
> might even be harder to solve with a simple language.

I see this so often everywhere. "Yes, but with this simple
framework/database/language you don't have that complex problem anymore!". No,
it just ignores the problem completely so eventually it will bite you and you
now have to solve the complex underlying problem in the wrong domain.

Problems never go away, you just move them to a different place. The trick is
which place to move them to.

------
RickJWagner
Hacker News paydirt!

