Hacker News new | ask | show | jobs
by Geminidog 2011 days ago
>A function is a "thing", you should rather compare it to an entity in the English language.

It's more a verb that does an action on a noun. You can't express the concept with just a word.

   add one to number
>Why do we say washing machine instead of a home appliance powered by electricity used to wash laundry through the use of centrifugal force?

Obviously there's no need to describe the plumbing behind the machine just the purpose of the machine is good enough. Everyone understands what a washing machine does as it's culturally a part of our language. If I lived in a civilization without washing machines and I had to implement it as a variable name in code I would call it "clothes_washing_machine" because of added clarity and no actual harm done with the extra word.

>When naming things you need to balance descriptiveness with conciseness, a name is not a definition.

Sure and I'm saying most people are wrong about where this "balance" actually lies. People place too much emphasis on conciseness.

>As a rule of thumb, avoid specifying things that can be easily guessed, especially if they are right there in your function signature (!):

I don't like readers to do any guessing at all. It's wrong to make assumptions that a guess that comes easily to me will come easily to my audience such is the nature of documentation and documentation as code. I want people to read my code like they read english. But that's just my opinion.

    def find_animals_in_pic(picture: Picture) -> List[XYCoordinates]:
I mean what's the benefit of shortening this. I'm looking at this function and I'm feeling nothing happened. You just did extra work.

If I want to be nit, XYCoordinates should not be plural, List should contain many Types each called XYCoodinate. XYCoordinate(s) is better used as an alias for the entire list.

Additionally my function only operates on cats, dogs and baboons. It does not operate on all animals. Someone can mistakenly use this function to try to find lions and tigers and bears Oh my!

But that's besides my point. You attempted to shorten my function name while preserving meaning for which I totally understand the point you were trying to convey. What I'm saying is your changes are logically negligible. They do nothing to improve understanding of the program while trivially shortening things. Nothing practical occurred here. It's simply the scratching of an OCD need for more poetic names.

1 comments

NB: I'm answering to the claim that we behave differently when naming things in programming languages vs natural languages. Otherwise I think it's mostly a matter of preferences.

I understand you prefer to be more detailed in your naming, that's fine, but in natural languages your names would sound unusual/verbose as much as they do sound unusual/verbose in Python.

You say everybody understands what a "washing machine" is therefore a short name.

Are you saying that when washing machines were still a novelty they should have been called "clothes-washing machines" instead? Unusual naming right? People do seem to have a distaste for long and overly-detailed names in spoken languages as well, don't you think?

And what's the point of a dictionary if names embed a full definition that leaves nothing to be guessed?

> Sure and I'm saying most people are wrong about where this "balance" actually lies. People place too much emphasis on conciseness.

Where to draw the line can be a matter of preferences, no intention of debating that, but people do tend to draw the line the same way whether they speak English or Python. No incoherent behaviour there.

> NB: I'm answering to the claim that we behave differently when naming things in programming languages vs natural languages. Otherwise I think it's mostly a matter of preferences.

And I am saying this behavior is attributed to an irrational instinct. There is no practical logic to it even though are instincts push us to behave this way.

>I understand you prefer to be more detailed in your naming, that's fine, but in natural languages your names would sound unusual/verbose as much as they do sound unusual/verbose in Python.

The purpose of an action is to serve practical purpose. Something sounding unusual has nothing to do with whether the associated action was practical or impractical.

A name may sound unusual in python and suddenly sound perfectly fine in english. How this name sounds has nothing to do with the actual practical significance of the name.

If the name is informative then it is practical. Place that name in python, place it in english. How you feel about the name and how you think it sounds is irrelevant to your purpose of practicality.

The practical goal here is maximum clarity with zero ambiguity.

Your instincts and feelings are lying to you. You are subconsciously reacting to a purely aesthetic attribute. A poetic and elegant name does not serve an actual purpose. Only an informative name serves an actual practical purpose of being informative.

We program to make things work, not to come up with function names that are poetic/brief/unreadable. An aesthetically pleasing name does assist us in achieving the actual goal of our program but an informative name does.

>You say everybody understands what a "washing machine" is therefore a short name.

I'm saying anyone in our culture who speaks english.

>Are you saying that when washing machines were still a novelty they should have been called "clothes-washing machines" instead? Unusual naming right? People do seem to have a distaste for long and overly-detailed names in spoken languages as well, don't you think?

I'm saying in a hypothetical culture where we didn't have context on what a "washing machine" was "clothes-washing-machine" would properly communicate the intent and meaning about what that machine actually does. I am able to throw away any preconceived biases I have and not assume that a machine that washes things only washes clothes. Keep in mind I prefixed my entire point with a hypothetical culture that didn't know about "washing machines"... you seemed to have missed the fact that I did that.

>And what's the point of a dictionary if names embed a full definition that leaves nothing to be guessed?

There would be no point to a dictionary. But clearly the things we define in most functions aren't defined in the dictionary so rather then make up names no one can understand you can combine english words that everyone understands into sentences and phrases and use those to Name your functions.

>Where to draw the line can be a matter of preferences, no intention of debating that, but people do tend to draw the line the same way whether they speak English or Python. No incoherent behavior there.

Everything is a matter of preferences. Even believing in 1+1=1 is a preference you can choose to believe in.

I am saying in terms of of the set of attributes people hold to qualitatively describe whether or not something is practical, most people mistakenly believe that poetic and terse function names possesses the very same attributes they hold as "practical." TLDR: I am saying once people understand my point, most peoples preference are in full alignment with my preference.

I am saying when you ignore your inner OCD, you will see that aesthetic/poetic/elegant naming serves zero practical purpose and short and brief names have negligible practicality when compared with long names.

Thus a slightly longer function name that is ugly but very very informative and similar in grammar to the english language is the most practical and logical way to name your functions. It doesn't matter how "unusual/verbose" you feel that it looks/sounds as that feeling is orthogonal to the logical purpose of your naming in programming: to communicate and inform.

See past your bias and ignore pointless aesthetics.

You're mostly arguing on why your naming preferences are better. You're missing the point, I'm not addressing that.

Instead you seem to agree people name things in the same (irrational according to you) way both in English and Python. Which is exactly my point and what you previously claimed not to be the case.

Once again I am addressing this comment:

    A function that finds the x y coordinates of dogs cats and baboons in a picture.
> This is perfectly ok, but only because it's english.

No, it's not ok only because it's English. It's ok because it's a definition, it is not a name. In English as in Python we tend to prefer more concise names.

A function's name is...a name (duh), the comparison to prose makes no sense. Once you actually compare English and Python names you'll see they both tend to be more concise.

> See past your bias and ignore pointless aesthetics.

Ironically I find your style more poetic (we really have opposite tastes :P). But as you saw we both keep the same preferences independently of the language. No incoherence/bias there. That's the only point I'm making.

> You're mostly arguing on why your naming preferences are better. You're missing the point, I'm not addressing that.

No I am not arguing for that. I am saying your style is objectively LESS practical and harder to read. You missed the point repeatedly.

>Instead you seem to agree people name things in the same (irrational according to you) way both in English and Python.

When did I claim this? You seem to be misreading everything. Functions in "python" or programming in general are by most people named by trying to find some word or hybrid mangling of the english language to find an elegant but less informative name. Similar to how poetry is a mangling of English grammar.

I am saying that it is more practical to NAME a function in programming with a longer phrase or sentence. Whether you "feel" that's ok or not is irrelevant to the actual practicality of that name. You didn't even read my post.

>No, it's not ok only because it's English. It's ok because it's a definition, it is not a name. In English as in Python we tend to prefer more concise names.

Your just getting semantics mixed up. We call function names a "name" but it can also be called a function "sentence" or "function phrase"

Here's a more clear way to get it through your head:

"Function phrases" are more practical and informative then "function names" aka "function abbreviations/poetic words"

I am saying what you "prefer" or how you feel about the above statement is completely irrelevant to the fact that logically "function phrases" are more informative with the cost of being slightly longer.

My claim is your preferences are totally irrational and you are missing the point. Read it more carefully.

>A function's name is...a name (duh), the comparison to prose makes no sense.

It makes no sense to you because your brain is limited by the words "function name" you think because we call the naming of a function a "function name" your brain is unable to wrap around the fact that you can use a collection of words in the naming of a function. That's why I renamed "function name" into "function phrase" to help kick start your brain into gear and get on my level.

>Once you actually compare English and Python names you'll see they both tend to be more concise.

Again, missing the point repeatedly. Stop letting the word "name" block your creativity. Whatever we call something in the universe, a title a name or whatever, I can choose to be not concise, concise, put an entire sentence into the title, put an entire novel into the title. There are no actual rules on what we want to do and can do. The argument is simply for what is actually practically better to put into this "title" for programming.

This is the playing field we're operating in, You are letting your personal vocabulary and definition of "name" to delude your thinking.

So I am saying I want to use longer phrases/sentences or "function phrases" as the title of a function and you are saying that you want to use shorter/briefer names and that is a "preference" Then you say that my "preference" is not a "name"

My counter to your above is that whatever you want to call "naming" is completely irrelevant, my "preference" is categorically, objectivity and logically more practical and informative then your "naming" style. It is better because it communicates more information get it?

The thing that's missing here is that you haven't objectively told me why your style is better. It conveys less information and is thus logically worse. I'm betting that you have no reason. You just irrationally "feel" it's better to use "function names" or "function phrases"

>Ironically I find your style more poetic (we really have opposite tastes :P).

This is where your thinking is cloudy. First off this has nothing to do with taste. I am literally saying your "preference" is objectively less informative and therefore worse.

The other part of your thinking that is cloudy is your misinterpretation of the word "poetic." Poetry is a mangling of English vocabulary and grammar that is more Concise. My proposal is to move away from mangled English and grammatically incorrect "function names" and write "function phrases" that are grammatically closer to correct English. Your proposal is to make it shorter and more like poetry as per the exact definition given above.

People who can't think straight tend to think anything goes in poetry and that either naming scheme (yours vs. mine) can be poetry as a matter of taste. Wrong. There are hard rules that separate poetry from written English. Again, my style is to make programming closer to grammatically correct english, your style is to create poetry as per the definition of poetry above.

>But as you saw we both keep the same preferences independently of the language.

What same preferences? Our preferences are objectively different. And my preference for "function phrases" is objectively better and more informative then your "preference." We never reached an agreement I don't know how your imagination is cooking this up.

>No incoherence/bias there. That's the only point I'm making.

Again I am saying my "preference" is logically BETTER then your preference because it saves the reader time from guessing context and is more informative.

Look man, stop. This is a typical argumentative strategy to turn hard facts into muddy "opinions" and "preferences." In your world nothing is better or worse and everything is just a preference and anything goes. This is weak.

I have a "preference" that is different from your preference and I am stating my preference is better then your preference and your response is that everyone can have their own opinion? Come on.

> We call function names a "name" but it can also be called a function "sentence" or "function phrase"

I mean...we can also say that pigs are birds if you wish, everything is possible XD

Who in English would ever name anything as "A function that finds the x y coordinates of dogs cats and baboons in a picture". Does that sound like a name to you?

Do you actually speak like this in your daily life? "Please can you turn on the device for remotely visualising entertainment shows, news and sport events?"

Ah I forgot names don't exist: a name is a phrase, a definition is a phrase, a question is a phrase, an assertion is a phrase...can all be used interchangeably, they all serve the same purpose...ssure.

I think at this point you're lost in your own sophism. Good luck getting out of it!

>I mean...we can also say that pigs are birds if you wish, everything is possible XD

That's right we can. What you're failing to see here is that this naming is arbitrary. It truly seperate from structure.

>Who in English would ever name anything as "A function that finds the x y coordinates of dogs cats and baboons in a picture". Does that sound like a name to you?

That's why your thinking is limited. Whatever we call a function or a thing doesn't have to be limited by your definition of what is a "name" the limit is placed by you not reality.

>Do you actually speak like this in your daily life?

Can you get it through your head? You speak in sentences do you not? You don't ONLY use names to describe things, you use sentences. So we CAN use a sentence to DESCRIBE a function definition. Just because we call this description a "function name" doesn't mean we should be limited by the concept of what you define as a "name"

>"Please can you turn on the device for remotely visualising entertainment shows, news and sport events?"

Fortunately unlike speaking our editors assist us with auto complete.

If such a primitive existed in your program and you just called it "remote" and left the reader to guess what the hell it does by looking at context... you'd be a really bad coder.

Call it:

    "controller_that_changes_television_channels" 
And auto complete assists us with the length of the name. So really length isn't even that big of a factor here.

>Ah I forgot names don't exist: a name is a phrase, a definition is a phrase, a question is a phrase, an assertion is a phrase...can all be used interchangeably, they all serve the same purpose...ssure.

They actually do serve the same purpose. The purpose is communication. The problem with you is that you think the only form of communication in programming is names and context. I am saying you can use english sentences as well. It's that simple.

>I think at this point you're lost in your own sophism. Good luck getting out of it!

My argument? This isn't my argument. I'm not smart enough to invent this concept.

You ever heard of a guy named Donald Knuth? The guy who basically turned programming and algorithms into a science? Wrote the books "The Art of Computer Programming"? Well he invented something called literate programming:

https://en.wikipedia.org/wiki/Literate_programming

Take a look because in Literate programming people create "macros" and name those Macros after Entire essays or paragraphs. Donald does not restrict the "naming" of macros into pathetic little snippets of poetic words. His mind does not restrict what you can "name" something, not like your mind.

Don't let the word "macro" confuse your brain... macros are the same thing as functions, just a bit more advanced. The primary difference is that functions are resolved at run time, Macros are resolved pre-compile time.

This is my point.

You're not trying to debate my argument. You're debating an entire style of programming created by Donald Knuth.

I deliberately hid the official name of this technique because dropping the name Donald Knuth would just get people to agree with his reputation rather then reason and logic behind his thinking. Given that reason and logic doesn't work with you I think a name drop is relevant here.

It's not my sophism. It's Donald Knuth. Good luck trying to resolve your sophism with a concept invented by Donald Knuth.