<div dir="ltr">[Steven D'Aprano]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've just watched it, ... it is a great video. </blockquote><div><br>I'm really glad you did. I don't think many have, which I can't really blame anyone for because it's rather long, but if all this thread accomplishes is a few more people seeing that video, it'll have been worth it.<br><br>[Steven D'Aprano]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don't agree with everything he says, but even where I disagree it is <br>great food for thought.</blockquote><br>Yes, I disagree about his anti-dependency-injection stance.<br><br>[Steven D'Aprano]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">IDEs rot the brain.</blockquote><div><br>He advocates for the use of "extract method" only 12 minutes into the talk. This comes off as Socrates famous warning that written language would, <font face="arial, helvetica, sans-serif">"create forgetfulness in the learners’ souls, because they will not use their memories.” No, IDEs are tools. Tools are generally meant to solve problems. He laments that IDEs can encourage pointless boilerplate, but tools don't have to include "the ghost of Clippy".<br><br>I know this is a jab at my suggestion that an IDE could help communicate what is global (which, yes; is not synonymous w/ constant, though it usually should be) via syntax highlighting. I wonder if you believe that syntax highlighting "rots the brain"?<br><br></font>[Steven D'Aprano]<font face="arial, helvetica, sans-serif"><br></font><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">the speaker makes an excellent point that in Java, you don't need a naming convention for constants <br>because the compiler will give an error if you try to write to a constant.</blockquote><font face="arial, helvetica, sans-serif"><br>That's not the only argument he makes against all caps constants, though I agree that it's the strongest argument</font></div></div><div><font face="arial, helvetica, sans-serif">against all caps in Java.<br><br>I largely agree with the rest of your post. I just don't think we need a naming convention for constants.</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 4, 2019 at 10:21 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jan 04, 2019 at 01:01:51PM -0600, Abe Dillon wrote:<br>
<br>
> I keep coming back to this great video <<a href="https://vimeo.com/74316116" rel="noreferrer" target="_blank">https://vimeo.com/74316116</a>> <br>
<br>
I've just watched it, its a bit slow to start but I agree with Abe that <br>
it is a great video. (And not just because the speaker agrees with me <br>
about 80 columns :-)<br>
<br>
I don't agree with everything he says, but even where I disagree it is <br>
great food for thought. I *strongly* suggest people watch the video, <br>
although you might find (as I did) that the main lessons of it are <br>
that many common Java idioms exist to work around poor language design, <br>
and that IDEs rot the brain.<br>
<br>
*semi-wink*<br>
<br>
Coming back to the ALLCAPS question, the speaker makes an excellent <br>
point that in Java, you don't need a naming convention for constants <br>
because the compiler will give an error if you try to write to a <br>
constant.<br>
<br>
But we don't have that in Python. Even if you run a linter that will <br>
warn on rebinding of constants, you still need a way to tell the linter <br>
that it is a constant.<br>
<br>
The speaker also points out that in programming, we only have a very few <br>
mechanisms for communicating the meaning of our code:<br>
<br>
- names;<br>
- code structure;<br>
- spacing (indentation, grouping).<br>
<br>
Code structure is set by the language and there's not much we can do <br>
about it (unless you're using a language like FORTH where you can create <br>
your own flow control structures). So in practice we only have naming <br>
and spacing.<br>
<br>
That's an excellent point, but he has missed one more:<br>
<br>
* naming conventions.<br>
<br>
In Python, we use leading and trailing underscores to give strong hints <br>
about usage:<br>
<br>
_spam # private implementation detail<br>
<br>
__spam # same, but with name mangling<br>
<br>
__spam__ # overload an operator or other special meaning<br>
<br>
spam_ # avoid name clashes with builtins<br>
<br>
We typically use CamelCase for classes, making it easy to distinguish <br>
classes from instances, modules and functions.<br>
<br>
And we use ALLCAPS for constants. If that's not needed in Java (I have <br>
my doubts...) we should also remember the speaker's very good advice <br>
that just because something is needed (or not needed) in language X, <br>
doesn't mean that language Y should copy it.<br>
<br>
<br>
-- <br>
Steve<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>