Python

[arilou]

Первое беглое знакомство с Python оставило ощущение непонимания, нафига там сделан такой прокрустов синтаксис. Никаких разумных причин сходу не увидел, в книжках объяснений внятных тоже не нашёл. В чём смысл7 (кроме "а вот такой у автора был способ самовыражения!")

И вот уже неделю рою питона пристально, пишу на нём уже что-то, в чужом коде копаюсь. И синтаксис его продолжает не радовать. Нагородили ограничений с непонятно какой радости...

Чего тогда все с него так прутся? В чём он настолько лучше Perl'а?

Comments

[besm6.livejournal.com]

Да, при паскалевских обозначениях путаницы было бы меньше. Но сама по себе идея присвоить одно другому и результат сразу же использовать в if - так же порочна, как выделенный инкремент на 1. Для части присваиваний (по уму - только булевских) работает, для другой - нет. Это все было понятно в те времена, когда памяти у машин было настолько мало, что лишних сто байтов в теле программы - и ее уже некуда записать. И оптимизирущий компилятор, который мог бы i+=1 перевести в ассемблерную inc, i+=2 - в два inc, а i+=5 оставил бы сложением, тоже некуда было бы засунуть. Обрати, кстати, внимание, что арифметика с указателями даже в C такова, что инкремент в ассемблерную inc не очень-то преобразуется - делается смещение на размер объекта.

А в языке, который был создан тогда, когда это все уже было неактуально... У тебя в комментах кто-то уже говорил, что ЯВУ созданы для передачи своих мыслей не машине, а другому программисту. Это не вполне так, но в немалой степени. И Питон - язык, который сделан в первую очередь для этого. Что, говорят, не мешает ему при этом еще и работать быстрее перла...

И там, где машине-то пофигу, как ты записал инкремент, она железная, человеку не все равно. Инструкция i+=1 явно читается понятнее, чем выражение ++i, а то и, не приведи Великий Вычислитель, i++. Каковое, будучи выражением, еще и засунуто куда-то в еще более забористое выражение.

Постинкремент провоцирует ошибки именно тем, что им невозможно правильно воспользоваться, не уделив внимание именно ему, а не решаемой задаче. Программист либо вынужден выныривать из своего размышления о задаче и внимательно думать про постинкремент, чего организму делать не хочется, либо на автопилоте ошибается с вероятностью 1/2. Чего стоит один только шаблон for (i=0; i

[Error: Irreparable invalid markup ('<n;>') in entry. Owner must fix manually. Raw contents below.]

Да, при паскалевских обозначениях путаницы было бы меньше. Но сама по себе идея присвоить одно другому и результат сразу же использовать в if - так же порочна, как выделенный инкремент на 1. Для части присваиваний (по уму - только булевских) работает, для другой - нет. Это все было понятно в те времена, когда памяти у машин было настолько мало, что лишних сто байтов в теле программы - и ее уже некуда записать. И оптимизирущий компилятор, который мог бы i+=1 перевести в ассемблерную inc, i+=2 - в два inc, а i+=5 оставил бы сложением, тоже некуда было бы засунуть. Обрати, кстати, внимание, что арифметика с указателями даже в C такова, что инкремент в ассемблерную inc не очень-то преобразуется - делается смещение на размер объекта.

А в языке, который был создан тогда, когда это все уже было неактуально... У тебя в комментах кто-то уже говорил, что ЯВУ созданы для передачи своих мыслей не машине, а другому программисту. Это не вполне так, но в немалой степени. И Питон - язык, который сделан в первую очередь для этого. Что, говорят, не мешает ему при этом еще и работать быстрее перла...

И там, где машине-то пофигу, как ты записал инкремент, она железная, человеку не все равно. Инструкция i+=1 явно читается понятнее, чем выражение ++i, а то и, не приведи Великий Вычислитель, i++. Каковое, будучи выражением, еще и засунуто куда-то в еще более забористое выражение.

Постинкремент провоцирует ошибки именно тем, что им невозможно правильно воспользоваться, не уделив внимание именно ему, а не решаемой задаче. Программист либо вынужден выныривать из своего размышления о задаче и внимательно думать про постинкремент, чего организму делать не хочется, либо на автопилоте ошибается с вероятностью 1/2. Чего стоит один только шаблон for (i=0; i<n; i++). Спрашивается вопрос: накойхер (фамилие такое) в этом шаблоне _пост_инкремент, который, если забыть его оттуда соптимизировать, в несколько раз медленнее _пре_инкремента? Однако ж, шаблон именно таков. Я думаю, что если там написать просто инкремент (который, собственно, будет эквивалентен преинкременту) i+=1, то это удлиннение кода аж на 1 символ сэкономит пяток байтов скомпилированного кода и соответствующее количество тактов процессора прямо вот сходу. Ну, конечно, -O2 и даже -O1 догадается само, но зачем сразу-то лажу писать? (Да, я еще умею написать for (i=n-1; i>=0; --i), если i у нас signed, и это реально даст выигрыш, потому что gcc не догадается развернуть цикл в обратную сторону - но при этом надо не забыть проследить за знаком i, и зачастую в теле цикла еще явно откастить его в unsigned.)

От char в качестве byte все ЯВУ действительно отошли, ибо иначе оставалось только лечь и сдохнуть. Но проблемы до сих пор. А int-bool и постинкременты таки расползлись по ним. Их нету только в языках с прицелом на обучение программированию (питон) и суровых математических языках типа хаскела. Ну и лиспа в силу его специфического синтаксиса и простой, но строгой семантики, куда постинкремент засунуть можно, но будет сразу видно, что это черезжопное действие. И то... Из всех лиспов только в схеме, построенной специально для обучения, nil в качестве булевского false не используется. В остальных используется.