Hacker News Reader

Comment by Jun8 | Hacker News Reader

Obligatory list of some good quotes that are not included:

Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. - M.A. Jackson

Never test for an error condition you don't know how to handle. - Steinbach

Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. - perldoc perlstyle

Every program has (at least) two purposes: the one for which it was written, and another for which it wasn't. - Alan Perlis

Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. - Stan Kelly-Bootle

View on HN

"All code is technical debt; some code just has a higher interest rate." Paul McMahon

Stroustrup’s Rule: "For new features, people insist on LOUD explicit syntax. For established features, people want terse notation."

"Le meilleur moment du programmation, c'est quand on télécharge le compilateur." Georges Clemenceau

The Clemenceau quote is not grammaticaly correct, it should be: "Le meilleur moment _de la_ programmation". Also I've seen "développement" used more often than "programmation", even if both terms are valid.

Still where does it come from? The only George Clemenceau I've heard of died in 1929.

Thanks for the correction! I made it up as a joke. He really said, "Le meilleur moment de l'amour, c'est quand on monte l'escalier."

Ok, I didn't know that quote

He was really looking forward to downloading the compiler.

>Rules of Optimization: Rule 1: Don't do it.

Well that explains the modern web, and a great deal of modern software.

There is a huge difference between not optimizing (say, purge formatting white space from HTML) and putting out five megabyte of JavaScript junk for static website.

Well, optimization could also mean to remove unnecessary JS.

I think removing unnecessary code and generalizing redundant parts should be a given. On the other hand, early optimizations such as caching or in-lining should be avoided unless needed.

I remember someone saying simple code implementing well selected algorithms beat optimized code implementing poor algorithms.

Although, I would have to agree with your statement.

Selecting algorithms well is not trivial. How many people think about the difference between linear search in a small array versus just passing maps around without calling it optimization?

It also doesn't matter as much if your design is a mess of abstraction and indirection that spends 95% of its time chasing pointers and inspecting maps.

No, its not. Frankly, I haven't seen any tools to help which is an amazing shame. Its something that as a profession we need to be better at.

> It also doesn't matter as much if your design is a mess of abstraction and indirection that spends 95% of its time chasing pointers and inspecting maps.

Well, that's the other side of the problem of picking decent algorithms is picking a reasonable structure for your program.

I think this rule only applies in situations where the runtime is smart and fast enough that the naive approach is fast enough for whatever you need to do.

There was a surprising lack of Alan Perlis on the original list! His "epigrams on programming" should be required reading for every programmer, even if some are a little dated now:

http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html

> Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. - perldoc perlstyle

From that source it should rather be a joke. What is the meaning of `@` again?

> What is the meaning of `@` again?

@rray (just like `$` is for $calar, and `%` is for … uhm …). Everything is mnemonic if you have a sufficient amount of context. :-)

The `@` symbol is a variable by itself, what is very clear from it's name, even more because `$` certainly isn't and I also don't think `%` is one (that last is for dictionaries, by the way).

Another system defined variable is `$_`, that is as well named as the one I cited.

There are many more of those in Perl, but I can't remember them for some reason.

> The `@` symbol is a variable by itself, what is very clear from it's name

I'm almost certain that this is false, at least in Perl 5. (Sigils are dramatically overhauled in Perl 6, and I haven't kept up.)

<plug>

This blog post could be of interest: https://opensource.com/article/18/9/using-sigils-perl-6

</plug>

In "What they have in common is that they consume the Callable role.", shouldn't 'consume' be 'perform' for consistency with your useage elsewhere?

"@" is for an array variable or pulling something in array context. You can have variables declared with $, @, or % depending on whether it is a scalar, array, or hash structure.

Right. At least, the first two are right:

'@' is a stylized 'a' (for 'array') and '$' is a stylized 's' (for 'scalar').

And '%' is a stylized key-value pair, so used for a Perl hash. IIRC.

Whatever else you may think of Larry Wall, you can't accuse him of not being ingenious :)

>sufficient amount of context.

nice('perl pun') unless not intended;

https://www.google.co.in/search?q=perl+scalar+and+list+conte...

https://perldoc.perl.org/functions/unless.html

> nice('perl pun') unless not intended;

Lovely catch! I wish that it had been intentional.

Heh. Thanks :)

Reply on news.ycombinator.com