Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Chris Angelico <rosuav@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Why not allow empty code blocks?
Date: Mon, 25 Jul 2016 07:08:46 +1000
Lines: 92
Message-ID: <mailman.100.1469394529.22221.python-list@python.org>
References: <b80ae0ca-d8b2-4430-96a1-7a6768b177ef@googlegroups.com> <5792cd34$0$1587$c3e8da3$5496439d@news.astraweb.com> <87vazwppxx.fsf@elektro.pacujo.net> <20160723082947.7cae8bd1@imp> <mailman.77.1469276992.22221.python-list@python.org> <87fur0a44p.fsf@elektro.pacujo.net> <20160723095441.29562c54@imp> <mailman.79.1469282085.22221.python-list@python.org> <nmvtlu$oqu$1@dont-email.me> <57939373$0$1586$c3e8da3$5496439d@news.astraweb.com> <nn25m4$4d1$1@dont-email.me> <5794b1d7$0$1620$c3e8da3$5496439d@news.astraweb.com> <nn2k8m$hkf$1@dont-email.me> <CAPTjJmp+adwRoeB24yaHLDMnd++SYs3KT1DvEHupr0919-ivqw@mail.gmail.com> <mailman.93.1469371871.22221.python-list@python.org> <nn30hj$sgn$1@dont-email.me> <CAPTjJmrxP86yObeuG+8BG197fazFrNE3FCJQ6VmXMmH7mb=mrA@mail.gmail.com> <mailman.96.1469386837.22221.python-list@python.org> <nn36uo$k0r$1@dont-email.me> <CAPTjJmobXB2k+GF_HK-96ZYWHxxXEPg9vcFXyf1WkpKdZjRo6w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <nn36uo$k0r$1@dont-email.me>
Precedence: list
Xref: csiph.com comp.lang.python:111838

On Mon, Jul 25, 2016 at 6:03 AM, BartC <bc@freeuk.com> wrote:
> On 24/07/2016 20:00, Chris Angelico wrote:
>>
>> On Mon, Jul 25, 2016 at 4:14 AM, BartC <bc@freeuk.com> wrote:
>
>
>> A skilled craftsman in any field will choose to use quality tools.
>
> Materials (ie. languages) are important too.

Materials, tools, same difference. (Not sure I could even draw the
line in software, and ultimately, my line of argument applies equally
to both.)

>> So why do you use
>> "dumb editor" as a line of argument, rather than getting a smarter
>> editor?
>
>
> Perhaps because I prefer to use my own languages and I don't have anyone
> writing the specialist tools for me that would be necessary.

So because you've chosen to use your own languages, you are frustrated
at Python because you're not using a decent editor? Get yourself
something nice and configurable, so that when you open a Python file
it gives you the features you need. I use SciTE, and it quite happily
is currently working with text, Pike, Pike Module, reStructuredText,
HTML, SRT, and Python files, and that's counting only the ones that I
have loaded in it right at this instant. Had some C files up recently
(both .c and .h - was editing CPython), and various other things.
SciTE doesn't recognize .srt files, so it treats them as plain text -
as in, like a dumb editor would. Even if your own language can't be
parsed using any existing parser (adding language support usually
isn't that hard, if the same parser can be reused), you can still make
use of smart editor features for all other languages you work with.
Why is this such a problem? Why is it so hard?

>> 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.
>
> Some of us are used to working with minimalist tools and can be extremely
> productive with them.

And then you complain that the language is "fragile" or in some way
frustrating to you. Because you've restricted yourself to minimalist
tools. Go ahead! Be productive. I'm sure there are people out there
saying "I'm used to working with C and can be extremely productive
with it". Let 'em. Me, I'll use high level languages and be even more
productive. Thanks.

> But since you used some C, let me give an example of poor design from that
> language (there are plenty; I've written up quite a big collection of them).
>
> You might know that type declarations in C, as soon as you go beyond the
> basics, become completely impossible and convoluted. I've never managed to
> get my head around them.
>
> There are utilities such as 'Cdecl' that are used to convert a C declaration
> to English, and vice versa. That's how good a feature they are!
>
> So what would have been a better solution here: to have fixed the language,
> or to have grafted on a simpler type declaration scheme that could co-exist
> with the old one; or to have ignored the problem and depended on using
> external tools?
>
> Or just insisted that everyone learns that arcane aspect of C, despite it
> being unreadable and error-prone.

When do you get those uber-convoluted declarations in C? Sure, they
come up in C++ (which is why the language grew some features to manage
that complexity), but outside of demonstration code, when do you get
actual declarations of massively-nested constructs? I've literally
*never* seen them - not rarely, NEVER - in production code.

> (My own solution is that I use a home-made language in place of C, which has
> fixed most such problems. So my main 'tool' is a custom-made language.
>
> And for block delimiting, it uses neither tabbed indents or braces!)

Sure. You're most welcome to use that. But it doesn't mean that Python
is unusable.

Plus, I'd much rather trust Python in production than something
custom-made, even by me. The performance, reliability, and security of
a well-respected language far outstrip anything I could build.

ChrisA