Hacker News new | comments | show | ask | jobs | submit login

When programming, variables should be self-explanatory. However, things you re-type constantly (copy -> cp, remove -> rm, variable data -> /var) are fine to abbreviate with logical abbreviations.

I don't have trouble understanding dev, /svc and /pkg because they're already common abbreviations. The gn and PA_VMAR_ROOT I'd have to look up, but if I'm using it constantly, I don't mind needing to learn. I mean, I needed to learn to use Vim, too, and now I'd never want anything else.

I'd rather have typing assist than abbreviated names. To be self-explanatory, it's called ISingletonComponentFactory, but that doesn't mean I type all of that out.

Typing assistants mostly suck. And it's not only about the typing. You still have to read the names or process them otherwise.

"Self-explanatory": That doesn't exist. You always need context. The art is to use just enough verbosity. Say the interesting and distinctive things. Not the boring things that can be easily figured out (Singleton, Factory, boring. What kind of component?)

> You still have to read the names or process them otherwise.

And how long does it take you to parse "svc" vs. "service" in average microseconds per day? With old unix there was at least a need to keep memory use low, today we are only limited by Microsofts MAX_PATH.

What I said was about typing assistants and about efficient naming. But after reading the article, I would make a point for svc being not a bad decision. Ask any otherwise uninitiated programmer what meaning she would associate with "svc" or "service". You don't get anything useful out of either without additional context. Even

    /svc, which is a bundle of services from the environment in which the application runs.
is not really enough for me to understand what this is about.

Now, since this is a distinctive concept that comes with a learning cost, why not make a short name like "svc" for it? That is actually more distinctive than "service". And you save 4 characters every time you read or write it.

Wait so you think "svc" is easier to read & process than "service"? What planet are you on?

It is, depending on how often it's used and how cohesive the implementation is. Anyway "service" is one of these terrible non-descriptive names. Is this some kind of abstract datatype? A reference to a system daemon? Or just a data value processed by business logic? You need context anyway.

I'm hoping Fuchsia isn't being designed as an OS where you constantly have to type file paths.

Also you rarely need to type full paths even on Linux. I'm nearly all shells you can press tab to autocomplete them. I.e. you press "/d<tab>" and it will change it to /dev. That's exactly the same for dev and devices.

There's really no reason for short confusing names other than laziness and jargon-based egotism.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact