--- On Fri, 2012/3/23, Bryn M. Reeves <b...@redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/23/2012 07:38 AM, Reindl Harald wrote:
> > "systemctl restart httpd.service" is a joke compared with "service
> > httpd restart" - a msart developer would have made .service as
> > default-fallback and only "httpd.socket" as example would need full
> > qualified input
> 
> That would be optimisation. A very smart programmer once taught us
> that "premature optimisation is the root of all evil". Perhaps the
> author felt that other work was of higher priority at the time?

That is not optimization, that is interface design. The two are entirely 
different. The "premature optimization" bit is about choosing implementation 
clarity (expression) at the expense of execution speed over potentially 
confusing code that increases performance at runtime (optimization).

The difference between .service being a permitted implication VS a mandatory 
explication is one of interface and does not impact the implementation of the 
subsystem. Its the same argument as requiring that everyone actually type 
"self" in 'def foo(self):' in Python. I think its silly, others think it is 
more clear to be explicit to that degree when programming.

But pushing systemd around from the command line is not programming unless its 
part of a script, and then the explicit .service extension is entirely 
appropriate. And speaking of scripting the shell, we've had this debate before 
a very long time ago. It resulted in the tradition of providing GNU flag 
extensions in addition to the old-style terse single-dash switches for the vast 
majority of command line tools. In scripts it can be polite (well, used to be 
considered polite, if anyone would remember today...) to write 'cut 
--delimiter="-" --fields=2,3 foo.txt' instead of 'cut -d "-" -f 2,3', but both 
are perfectly acceptable and this provides a way to be explicit for posterity 
yet terse for practical reasons.

I'm sure more people around here than me spent their early years watching the 
flame wars of the late 80's and early 90's unfold over all this stuff (or in 
the case of JZ he was probably directly involved instead of being a youngster 
on the sidelines). Anyway, I think we should learn from those discussions and 
how the command line evolved instead of trying to reinvent things that are 
difficult (but that does not mean the status quo rules the day in the face of 
clearly better alternatives).

Have we forgotten that CLI *is* an interface and hence worth discussing? The 
"I" is there for a reason. And how on earth is it possible that we've forgotten 
what a cultural rule-of-thumb as important as "premature optimization is the 
root of all evil" actually means?
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Reply via email to