Why not allow empty code blocks?

Chris Angelico rosuav at gmail.com
Sun Jul 24 15:00:28 EDT 2016


On Mon, Jul 25, 2016 at 4:14 AM, BartC <bc at freeuk.com> wrote:
> OK. I understand that it is not possible to point out any kind of weakness
> of a language (any language not just Python!) because the counter-argument
> is always going to be about:
>
> Use syntax highlighting, use a smart editor, use a version control system,
> use a linter, use 'tabnanny', use tool X, Y or Z to get around the problems,
> use obscure language options..

Obscure? I guess - it's not like it's listed in the --help screen. Oh
wait. And of course, all you need to do is upgrade to Python 3 and it
becomes the default.

Wait, you lump "use a VCS" into the category of "stuff people tell you
that you're not really willing to do"? Are you saying you don't use
git, Mercurial, etc, etc, to track your projects? Then start using
one. Now. "Now-now", as Princess Anna says in the Italian dub.

> The thing is, if everyone does depend more on such tools, then it really
> doesn't matter exactly what the language does - the tools will take care of
> such details. So the language could delimit blocks using any scheme it
> likes, including use 'end', 'else' and so on.
>
> It only becomes important to people like me who use plain editors.

Yes, that's exactly right. Tell me, is this part of a linter or a
language compiler/interpreter?

rosuav at sikorsky:~$ cat 1.c
#include <stdio.h>
int main()
{
    int months[12] = {31,28,31,30,31,30,31,31,30,31,30,31};
    printf("The array is at %p.\n", months);
    printf("There are %d days in December.\n", months[12]);
    printf("And this is what 28 looks like: %s\n", months[1]);
}

rosuav at sikorsky:~$ gcc -Wall -O2 1.c
1.c: In function ‘main’:
1.c:7:9: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 2 has type ‘int’ [-Wformat=]
  printf("And this is what 28 looks like: %s\n", months[1]);
         ^
1.c:6:2: warning: array subscript is above array bounds [-Warray-bounds]
  printf("There are %d days in December.\n", months[12]);
  ^
rosuav at sikorsky:~$


Today's C compilers emit warnings for things that yesterday's
third-party linters did. Is there virtue in running gcc with all
warnings disabled? Equally, is there a valid reason for choosing to
use a "plain editor" when you could use one that helps you?

A skilled craftsman in any field will choose to use quality tools.
They save time, and time is money. Are there any carpenters who
restrict themselves to hand tools? (Stylistic choice aside.
KirkwoodWorking has "hand tools Sunday" where he avoids all power
tools, and it's taking him months and months to finish one cabinet.
But the rest of the week, power tools win.) Would you, if given the
choice, use an ancient 80386 running MS-DOS in 4MB of RAM, or a modern
system running a modern OS in 16GB? Would you type your code on a
tablet computer or something with a real keyboard? So why do you use
"dumb editor" as a line of argument, rather than getting a smarter
editor?

I don't have a lot of sympathy for people who use suboptimal tools and
expect everything to work for them. Sure, sometimes you're forced to
use something less than ideal (maybe you're stuck on someone else's
Windows box and good tools simply aren't there, and you can't go
installing a ton of stuff just to get started), but then you KNOW
you're working in bad conditions. You don't make that your normal
life.

ChrisA



More information about the Python-list mailing list