Почему я больше не хочу програмировать на Perl

    Про недостатки перла как языка и платформы сказано многое, например, про то, что нет спецификации языка, про то, что странный синтаксис к которому нужно долго привыкать и т.д.

    Достаточно того, что авторы языка, задумывая новые версию, по сути создали новый язык мало похожий на исходный (Perl 6), тем самым признали что текущий перл вышел не очень удачным, что в принципе понятно т.к. язык создавался как замена shell'у, а потом оброс фичами.

    Я бы хотел сказать о своих личных наблюдениях, которые привели меня к тому, что работать на перле я пойду только в крайнем случае, несмотря на то, что этой мой основной язык.

    1. Обратная совместимость — перл старается её поддерживать, с одной стороны это хорошо, с другой стороны для того чтобы писать на современном перле надо явно включать прагмы использования новых фич т.е. написав код по умолчанию в 21 веке вы можете получить код в котором компилятор не отлавливает даже опечатки и именах переменных и не поддерживает никаких новых конструкций. Мне кажется те, кто хотят обратной совместимости должны включать прагмы таковой, а по умолчанию язык должны быть актуальным.

    2. Параллельное программирование — с тредами в перле изначально было плохо, их как-то всегда не рекомендовали использовать, форкать процессы можно, но до определённого порога, а потом люди начинают думать как это оптимизировать и конечно перл не исключение — история этого вопроса примерно такая, сначала был POE, потом его заменил Coro, а потом пришёл и всех победил AnyEvent. И долгое время я не понимал суть проблемы, но когда узнал как эти вопросы решаются в Erlang или Haskell понял что асинхронное программирование на коллбэках это низкий уровень, по сути шаг назад. Перл когда-то выстрелил именно как высокоуровневый язык, а тут получилось наоборот.

    3. Глобальные переменные — грамотные программисты конечно используют use strict и my, но многие конструкции языка, такие как регулярные выражения или eval, используют глобальные переменные для возвращения результата, это уродство о котором нужно всегда помнить, например в $1 может оказаться результат предыдущего матчинга, поэтому надо проверять не наличие значения, а результат матчинга. В питоне, в том числе для регексов, обошлись без глобальных переменных и всё получилось нормально.

    4. eval — это пример странности в синтаксисе, на самом деле eval в перл, если передать ему строку, ведёт себя как ожидается от функции с таким именем, а вот если ему передать блок кода, то он по сути реализует оператор try, хотя и убого (поэтому на cpan есть много «фиксов» try).

    5. Передача параметров в функцию — опять же, предлагается какой-то низкоуровневый механизм, параметры приходят виде массива и нужно его явно превращать в что-то удобочитаемое, некоторые варианты в принципе невозможно реализовать, например нельзя передать два хеша по значению, только по ссылке. Есть конечно костыли вроде этого, но костыли есть костыли, достаточно посмотреть на то как реализована передача параметров в Python, чтобы понять как должен выглядеть продуманные высокоуровневый синтаксис передачи параметров.

    6. Оператор in — стандартная задача — проверить входит ли элемент в массив, в питоне это делается единственно правильным способом element in array, в перле такого нет, одно время вводили smart matching, но наворотили там такого, что быстро решили его выпилить, а остальные варианты выглядят просто жутко.

    7. Работа с датами — к сожалению почти все книги по перлу рекомендуют модуль Datetime, автор которого смешал в один модуль, то что должно быть двумя (арифметика дат и календарь) и ещё и рассказывает всем как это оказывается сложно делать такую ерунду, а ещё у этого модуля жуткий объектный синтаксис. Относительно нормальный в перле это Class::Date, но почему-то его мало кто знает, а эталон снова в питоне, почему-то там люди понимают, что максимальная единица в арифметике дат это неделя, а месяц это уже понятие календаря. Кому интересны подробности может почитать переписку тут.

    8. И это можно продолжать бесконечно, вот ещё пример, когда вместо одной нормальной функции, есть куча непонятно чего.

    9. Но главная проблема в том, что сообщество не замечает этих проблем — «мы всегда так делали».

    Кто-то может сказать, что это мелочи, мол можно привыкнуть и писать рабочий код, да, я долгое время писал, но со временем понимаешь, что нет никаких причин привыкать к плохому, надо выбирать лучшие решения, а не какие-нибудь.

    Помимо этого, раньше у перла было преимущество в количестве модулей, но сейчас оно утеряно, уже несколько раз приходилось из перла использовать питонные модули, спасибо автору Inline::Python за такую возможность.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 220
    • –10
      поверхностное мнение дилетанта… Perl еще нас с вами переживет и многие языки типа суррогаты типа python.
      • +3
        Если не ошибаюсь, worldmind пишет на перле лет 10. Так что про дилетанта — не поддержу вас.
        • +1
          судя по проблемам, которые он описал — он программит на перле 10 дней, а не лет.
        • 0
          на самом деле даже не важно сколько я пишу, я высказал конкретные замечания и разумный человек, если уже взялся отвечать, ответит конкретными контраргументами
          • –1
            Он ответил минусами в карму. Чем больше минусов, тем более качественные аргументы они заменяют :-D
        • 0

          Я так и не понял по какому принципу вы отделяете "даты" и "календарь". Посмотрите реализацию $jin.time, правда она на JS, но портировать её на что бы то ни было не составит труда.

          • 0
            под датой я подразумеваю число секунд с начала времён, такие даты можно, например, вычитать по сути как числа и получать корректный интервал, а календарь это уже все фишки летоисчисления — високосные года и всякие дополнительные секунды
            • 0

              Ну получили вы "корректный интервал" в 1234565 секунд, а толку? Его всё-равно надо представить в виде "столько-то лет, столько-то дней и тд". Сможете привести хоть один пользовательский сценарий, где не важны "все фишки летоисчисления"?

              • 0
                Например, при замерах производительности. Вполне нормально написать, что программа работала 1 неделю, 2 дня, 3 часа, 4 минуты и 5.67890123 секунд, и никакие месяцы переменной длины, високосные годы и тд тут не нужны.
                  • +1
                    Казалось бы, эта ссылка лишь подтверждает мои слова: нужна отдельная библиотека для работы с датами (поддерживающая все эти тонкости, а также тонкости, которые там не указаны: например, тот факт, что политика перевода летнее/зимнее время могла меняться в течение истории), и отдельная библиотека для замера интервалов времени, работающая с равномерными монотонными часами и использующая лишь промежутки времени фиксированной длины (секунда, минута = 60 секунд, час = 3600 секунд, сутки (математические, а не астрономические) = 86400 секунд, неделя (опять же, математическая) = 604800 секунд).
                    • 0

                      "Математические" сутки и недели никого не интересуют.

                      • 0
                        Как это никого не интересуют? Если я смотрю, как долго вычисляется факториал из 100000, мне плевать, был ли в день вычисления перевод часов. Мне важно получить время вычисления в абсолютных единицах.
                        • –1

                          Именно, и единственная такая единица — секунда. Остальные все привязаны к календарю.

                          • 0

                            Глас разума посреди пустоши уныния и безнадёжности! Люто, бешено плюсую.

                      • 0
                        Всё, что приближается к суткам, и тем более, к неделе, уже зависит от календаря. А библиотеки для часов-минут-секунд есть и всегда были.
                  • +1
                    Зависит от задачи, например мне нужно сделать какое-то действие раз в 10 минут (например обновить кеш, сделать бекап) или запретить совершать какие-то действия если прошло сколько-то времени (например запретить редактировать комментарий), мне нет никакого дела до календаря, я просто беру текущую дату, вычитаю из неё предыдущую и сравниваю результат с интервалом из конфига (10 минут).
                    Никакого дела мне нет, что этот год будет длиннее на одну секунду чем другие года из-за секунды координации и нет никакого дела что пользователь живёт по календарю майя.
                    • –1
                      Вам нет дела, а плохой почему-то язык.
                      • 0

                        Вас, очевидно, интересуют не 10 минут, а 600 секунд.


                        По специальному решению Международной службы вращения Земли в конце суток по всемирному времени 30 июня или 31 декабря может добавляться так называемая секунда координации. При такой добавке последняя минута упомянутых суток содержит 61 секунду. Добавка секунды координации осуществляется для согласования всемирного координированного времени со средним солнечным временем UT1.
                        • 0
                          Да, но для этой задачи можно считать что минута это 60 секунд
                          • 0

                            Ну то есть реальные минуты вас не интересуют, а интересуют некие "математические" минуты. Ваше право, но все остальные прибавляя к "2017-12-31T23:55:00.000Z" 10 минут ожидают получить "2018-01-01T00:05:00.00Z", а не "2018-01-01T00:04:59.00Z".

                            • 0
                              это зависит от задачи, если вам надо выполнять что-то каждый год в первый понедельник, то конечно надо использовать модуль для работы с календарём, а если просто нужно узнать что прошло 10 «математических» минут, то календарь избыточен.
                        • 0
                          Никакого дела мне нет, что этот год будет длиннее на одну секунду чем другие года из-за секунды координации и нет никакого дела что пользователь живёт по календарю майя.

                          А вот и зря нет дела. Потому что эти 10 минут легко могут попасть на момент перевода времени, когда у вас в начале интервала было 2:53 утра, а стало 2:03 утра. Потому что в 3:00 стрелки перевели на час назад. Сколько в результате времени прошло, если одно из другого вычитать: -50 минут?


                          Core dump вместо бэкапа, и хорошо если только это.

                          • +1
                            Так я буду вычитать не даты по календарю, а число секунд минус другое число секунд с начала времени
                            • +1

                              Вычитайте, просто держите в уме, что это работает только в тривиальных случаях. А если, скажем, время нужно брать из внешних источников типа логов, то можно очень легко напороться.

                  • –1

                    Старая жена, с которой стал человеком, надоела и накопила, а может сразу имела, массу недостатков, и в кризисе среднего возраста возникает искушение найти молодую и привлекательную.
                    Но проблема в том, что средний возраст означает не молодость, а массу своих собственных проблем, и обычно эти проблемы приводят к печальному результату — старое разрушено, а новое не построено.
                    И остануться только оправдания типа этого.

                    • +5
                      К счастью, язык программиование — это не жена. Надоел — бросай и пользуйся другим.
                      • 0
                        А все окружения позволяют такую свободную замену? Отнюдь. Выбрасывание не выход.
                      • +1
                        аналогии это всего лишь аналогии
                      • +3
                        Интересно, что точно такую же статью можно написать про абсолютно любой язык )
                      • +3
                        > тем самым признали что текущий перл вышел не очень удачным

                        Нет.

                        > язык создавался как замена shell'у, а потом оброс фичами

                        Ханжество.

                        > Мне кажется, что обратная совместимость ненужна, я хочу писать на языке, который каждый год новый

                        Если вам очень сложно написать «use strict» — пусть это делает за вас ваша среда разработки.

                        > регулярные выражения используют глобальные переменные

                        Вы отстали от жизни. Именованные буферы введены в 5.10, десять лет назад.

                        > eval — это пример странности в синтаксисе

                        А * — пример странности в синтаксисе C. Один и тот же символ является операцией умножения и операцией разыменования указателя! С — плохой, негодный язык!

                        > параметры приходят виде массива и нужно его явно превращать в что-то удобочитаемое

                        В 5.20 введены сингнатуры. Правда, для их использования нужно сделать невозможное — написать «use feature».

                        > например нельзя передать два хеша по значению, только по ссылке

                        А в Java нельзя передать объект по значению. По настоящему значению. Да и дело не в параметрах функций perl, а в синтаксисе языка, (%a, %b) — это один (sic!) список (sic!). Да, вот такой у нас язык, вот такой у него синтаксис. Часто это удобно, иногда — не очень, как и с любым другим синтаксисом любого другого языка. Если вам очень нужно передать сложный объект по значению (а хэш, да и массив, может быть сложным), для есть способ его склонировать (это Perl, здесь почти всегда «есть способ»).

                        > стандартная задача — проверить входит ли элемент в массив

                        Не особенно она стандартная. Почти всегда, если вам нужно найти элемент, упорядоченное множество не лучший выбор структуры данных. Впрочем, any {$a eq $_} @x, если вам очень нужно.

                        > почти все книги по перлу рекомендуют модуль Datetime

                        Это проблема языка? Вы сами найдете все CPAN-модули работы с датами, или вам помочь?

                        > максимальная единица в арифметике дат это неделя, а месяц это уже понятие календаря

                        Я не очень понимаю, как вы росчерком пера отделили даты от календаря, и сделали их несвязанными сущностями. Из вашей рассылки — «дата — это число единиц времени с начала отсчёта» — это же совершенно неверно. Число единиц времени — это число, а дата — это дата. Их можно перевести друг в друга по определённым правилам, не всегда очевидным (таймзоны и их история, 29 февраля и 60 секунда, 7 ноября — день октябрьской революции и т.д.)

                        > вот ещё пример, когда вместо одной нормальной функции, есть куча непонятно чего.

                        Facepalm. Perl дал вам десяток способов (на самом деле, два), как узнать размер массива. Вы же говорите, что эти способы совершенно неправильные, а правильный — функция, обязательно с именем len.

                        У Perl есть проблемы, но перечисленное вами — это не проблемы, а ханжество и вкусовщина.
                        • 0
                          Я не очень понимаю, как вы росчерком пера отделили даты от календаря, и сделали их несвязанными сущностями. Из вашей рассылки — «дата — это число единиц времени с начала отсчёта» — это же совершенно неверно. Число единиц времени — это число, а дата — это дата)

                          как раз потому что считаете — "«дата — это число единиц времени с начала отсчёта» — это же совершенно неверно" и не можете отделить даты от календаря.

                          но меня другое удивило, неделя — почему? в датах две базовые единицы год и день, так как имеют физическую основу а за остальное (квартал, месяц, неделя, начало отсчета) отвечает календарь, например на венере год меньше дня вот увязка этой ситуации и лежит на календаре.
                          • 0
                            Календарная дата — порядковый номер календарного дня, порядковый номер или наименование календарного месяца и порядковый номер календарного года (Федеральный закон Российской Федерации от 3 июня 2011 г. № 107-ФЗ «Об исчислении времени»).

                            Дата — запись, включающая в себя число месяца, месяц и год, иногда день недели, номер недели в году и систему летосчисления.
                            ================
                            Календа́рь — система счисления больших промежутков времени
                            • 0

                              За исключением того, что исходя из самого популярного календаря, каждый год, чей номер делится на четыре, на день длиннее. За исключением тех, которые делятся на сотню. Они нормальные. Кроме случая когда они делятся на 400. Тогда они не нормальные.


                              Об этом кто должен знать? Модуль с датами? Или с календарем?

                              • 0
                                за високосные года должен отвечать модуль дат
                                т.е. модуль дат отвечает за физическое воплощение отсчета времени а календарь за логическую трансляцию в заданный календарь, условно говоря — 1ый день 4млрд 7600 какого-то года это 01.01.2017 от Р.Х., вот за эту трансляцию и отвечает календарь (ну и наоборот тоже)
                                но это в идеале, конечно все в одно мешают.

                                перечитал про венеру — лажанул, «ситуации и лежит на календаре» на модуле дат конечно.
                                • 0

                                  Високосные года — особенность отдельных календарей. Т.е. нам нужны модули дат для каждого календаря, учитывающие особенности их построения? И даты нужно будет приводить друг к другу?


                                  Может лучше иметь базовый тип времени, который не зависит от календаря? А календарно-зависимые операции переложить на модули соответствующих календарей?

                                  • 0
                                    «Високосные года — особенность отдельных календарей», насколько я понимаю не совсем так, високосные года это механизм компенсации принятый к исполнению в отдельных календарях, но он существует «параллельно» им, как те же модули.
                                    • +2

                                      Нет, это именно часть календаря. Этот способ принят в двух календарях, юлианском и грегорианском. Возможно, что были еще другие солнечные календари, в которых были подобные поправки, но я ничего о них не знаю. В лунных и лунно-солнечных месяца (и года) определяются по другому, так что там свои заморочки с отсчетом. В еврейском календаре, например, високосный год отличается не на день, а на месяц.


                                      Возвращаяь к високосным годам, юлианский календарь, по сути, от грегорианского отличается только правилами компенсации. В юлианском високосным считается каждый 4-й год, что дает среднюю продолжительность года в 365,25 дней. В грегорианском же средняя продолжительность 365,2425, что дает меньшую ошибку, особенно на продолжении многих веков.

                                      • 0
                                        еще раз, в этой ветке обсуждают архитектурные абстракции в программировании, вы же ссылаетесь на реальный календарь, так вот это календарь состоит из двух частей модель даты\времени и логическая их организация в месяцы недели и т.п., поэтому ваше нет не имеет смысла — то что вы рассматриваете как календарь я рассматриваю как два модуля — даты и календарь, согласно контекста обсуждения.
                                        • 0

                                          Даты зависят от календаря.
                                          Пресловутая 61-ая секунда перед НГ.
                                          Реформа Петра Первого 1700 года (год длился 4 месяца).

                                          • 0

                                            Так я об архитектурных абстракциях и забочусь, чтобы они были правильные, удобные и не протекали. И если какая-то абстракция в программировании при проверке реальностью оказывается плохой, то нужно отказываться от абстракции, а не от реальности.


                                            Вот где вы проводите границу между этими модулями? Года, например, вы включили в модуль дат, хотя они, очевидно, существенно зависят от календаря. А вот, скажем, недели вас не устроили, хотя они не зависят от календаря.


                                            Более того, как вы определяете дату, если "число единиц времени с начала отсчёта" вас не устраивает? Хотя это единственный способ определить дату так, чтобы не привязаться к какому-то календарю.

                                            • 0
                                              вы как-то не так читаете
                                              " если «число единиц времени с начала отсчёта» вас не устраивает?"
                                              я такого не говорил
                                              • 0

                                                Перечитал ваш комментарий, признаю, неправильно вас понял

                                  • 0
                                    Это как раз мелочи. Куда интереснее вопрос, сколько дней было в 1917 году.
                                    • 0
                                      ну дык транслируем дату из старого календаря в (условно) абсолютную — год.день а из нее в новый календарь, все нормально.
                                      • 0
                                        Абсолютная дата?! Дожили.
                                        • 0
                                          юникстайм?
                                          • –1
                                            MS Excel не знает и знать не хочет про юникстайм. К примеру.
                                          • 0

                                            Unix time это UTC без високосных секунд, так?


                                            UTC в современной форме определено только с 1 января 1972. С 1961 по 1972 UTC было определено по-другому, с дробными дополнительными секундами в високосных годах, и собственно определение секунды UTC не совпадало со стандартной секундой СИ. Атомные часы появились только в 1958, до этого стандарты СИ были другими и время базировалось на астрономических наблюдениях.


                                            Давайте, переводите в абсолютные цифры и обратно. Если в результате для 23 февраля 1917 днём недели получится "фиолетовый банан", не удивляйтесь. Так всё и было.

                                            • 0
                                              не очень понял какую проблему вы пытаетесь продемонстрировать
                                              • +1

                                                Очень простую: нет никаких абсолютных дат и быть не может. И переводить даты из одного календаря в другой гораздо сложнее, чем кажется.


                                                Используя наивные варианты решения, отдавайте себе в этом отчёт. А то потом из-за излишней самоуверенности спутники падают или улетают чёрти куда.

                                        • 0
                                          И вы не поняли особенности вопроса. Во Франции и в России длительность 1918 (прошу прощения) года была различной. И даже ещё интереснее, см. пункты 2, 3, 4 декрета о времени.
                                          • 0
                                            насколько я понимаю это разные календари, да календарные года в них разной длины, а (условно) абсолютный год (забыл как это по нормальному называется, астрономическое время?) то один.
                                            • 0
                                              Так абсолютный или всё-таки условно?
                                              • 0
                                                условно абсолютный год — в том смысле что реальный абсолютный год нам неизвестен, когда там земля зародилась..., а вот взять 100млн2017 можно
                                  • +3
                                    > Ханжество.

                                    некомпетентность?
                                    «Perl was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier.»
                                    • 0
                                      Таки ханжество. Мало ли, кто с чего начинал. x86 вырос из чипов для калькуляторов.
                                      • 0
                                        Изначальная цель порождает определённые решения от которых потом трудно избавиться, x86 это хорошая архитектура?
                                        • –3
                                          x86 это рабочая архитектура.
                                          • 0
                                            так и перл рабочий язык, я это явно указал
                                    • +1
                                      > any {$a eq $_} @x

                                      как раз вот такая наркомания мне и не нравится, я написал в статье нормальный вариант, сравните
                                      • 0
                                        Почему он нормальный?
                                        • 0
                                          Потому что он радикально проще читается, он логичен, он понятен исходя не только из знаний программирования, а даже исходя из знания английского языка, а приведённый вариант специфичен для перла, хотя и основывается на функциональной парадигме.
                                          • 0

                                            Ничего подобного — всё перечисленное, лишь отражение собственных вкусов и привычек. К примеру, в JavaScript in используется для итерации по свойствам объекта, а Python почему-то для проверки наличия элемента в массиве. Что-то не вижу тут логичности и привычности. И это не говоря о том, что in имеет сильно ограниченный функционал по сравнению с any, по сути in — лишь один из частных случав any. Далее, any, к примеру, есть в Erlang и в JavaScript (как Array#some), а так же, думаю, и в других функциональных языках. То есть нельзя говорить о специфичности.

                                            • +1
                                              > JavaScript in используется для итерации по свойствам объекта

                                              в питоне он и так и так используется

                                              > in имеет сильно ограниченный функционал по сравнению с any

                                              так это и хорошо, он делает одну задачу превращая код в почти английский текст

                                              > Далее, any

                                              я против any ничего не имею и не предлагаю его запретить, я говорю что в данной ситуации any не должен использоваться
                                              • –1

                                                То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным? Хорошо, да. Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».


                                                А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования. У меня есть в таком случае кандидат в победители этой альтернативной олимпиады — SPL.

                                                • –1
                                                  > Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».

                                                  Питон — хорошо и понятно, перл — нет. Разве непонятно?
                                                  • –1

                                                    Спасибо! Теперь всё встало на свои места.

                                                  • +1
                                                    я говорил хорошо и логично пока только про один вариант, про проверку наличия элемента в массиве: ЕСЛИ элемент В массиве ТО…
                                                    • 0
                                                      То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным?


                                                      Сюрприз, во всех языках есть элементы, которые применяются по-разному в зависимости от контекста. Попробуйте познакомиться с каким-нибудь языком программирования, и эта тайна для вас перестанет быть тайной.

                                                      А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования.

                                                      Вы любите посложнее, да? Любые упрощения и синтаксический сахар — это не для настоящих мужиков.

                                                      • –1
                                                        Сюрприз, во всех языках есть элементы, которые применяются по-разному в зависимости от контекста.

                                                        Ну, и что? Это логично? Это хорошо?


                                                        Вы любите посложнее, да?

                                                        Нет. А вы точно любите приписывать оппоненту то, чего он не говорил.

                                                        • +1
                                                          Ну, и что? Это логично? Это хорошо?

                                                          Слово «что» может применяться по-разному в русском языке, почему нас это не смущает?

                                                          Нет

                                                          А сказали таким голосом, будто «да».

                                                          Неужели эта конструкция читается сложно?
                                                          for a in (1, 2, 3):
                                                              print a
                                                          


                                                          А эта?
                                                          if a in (1, 2, 3):
                                                              print a
                                                          


                                                          В питоне есть более непонятные и нелогичные вещи, но вы осуждаете вполне себе выразительную, удобную и интуитивно понятную конструкцию.
                                                          • 0
                                                            Слово «что» может применяться по-разному в русском языке, почему нас это не смущает?

                                                            Мы всё ещё о программировании?


                                                            А сказали таким голосом, будто «да».

                                                            Повторю: вы точно любите приписывать оппоненту то, чего он не говорил.

                                                            • 0
                                                              Мы всё ещё о программировании?

                                                              Мы о сложности использовании контекста. Почему в русском языке нам несложно понимать слова в зависимости от контекста, а в программировании должно быть сложно?

                                                              Повторю: вы точно любите приписывать оппоненту то, чего он не говорил.

                                                              Тогда поясните, что вы хотели сказать этой фразой:
                                                              А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования. У меня есть в таком случае кандидат в победители этой альтернативной олимпиады — SPL.


                                                              А еще я выше задал вопросы с кусочками кода, вы проигнорировали.
                                                              • 0
                                                                Почему в русском языке нам несложно понимать слова в зависимости от контекста, а в программировании должно быть сложно?

                                                                А почему мы вообще сравниваем язык программирования с естественным языком? Это что, попытка провернуть подмену предмета обсуждения: типа что верно для русского языка, то верно и для Python?


                                                                Тогда поясните, что вы хотели сказать этой фразой

                                                                Это был сарказм по поводу утверждения, что близкий к английскому, значит лучший.


                                                                А еще я выше задал вопросы с кусочками кода, вы проигнорировали.

                                                                Потому что я ничего не осуждаю.

                                                                • –1
                                                                  А почему мы вообще сравниваем язык программирования с естественным языком?

                                                                  А почему язык программирования обязан быть неестественным?

                                                                  Это был сарказм по поводу утверждения, что близкий к английскому, значит лучший.

                                                                  А почему язык программирования обязан быть неестественным? (с)

                                                                  Потому что я ничего не осуждаю.


                                                                  А это стало быть похвала и восхищения:
                                                                  То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным? Хорошо, да. Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».
                                                                  • 0
                                                                    А почему язык программирования обязан быть неестественным?

                                                                    Не обязан (но фактически должен по многим причинам), но естественным не является.


                                                                    А это стало быть похвала и восхищения

                                                                    Это ни похвала, ни осуждение. Это сомнение в утверждении, что именно данный подход логичен и хорош.

                                                                    • 0
                                                                      А почему язык программирования обязан быть неестественным?

                                                                      Потому что все языки программирования, даже такие лингвистически продвинутые как Perl, являются выражением математических абстракций. А живые языки от математики крайне далеки.


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

                                                                      • 0
                                                                        Потому что все языки программирования, даже такие лингвистически продвинутые как Perl, являются выражением математических абстракций. А живые языки от математики крайне далеки.


                                                                        Это объяснение, почему так есть, а не почему так должно быть.

                                                                        лингвистически продвинутые как Perl

                                                                        Ну то есть лингвистически продвинутый перл — это хорошо, а лингвистически гибкое поведение оператора in в питоне — это плохо? Или что плохо, а что хорошо? Я запутался.
                                                                        • –1

                                                                          Конечно вы запутались, ведь вопрос звучал так:


                                                                          А почему язык программирования обязан быть неестественным?

                                                                          И никаких хорошо и плохо в связи с ним не было.

                                                                          • 0
                                                                            Давайте я освежу вашу память (с)

                                                                            Вы спросили, почему in (и другие операторы в языках) должен применяться по-разному в зависимости от контекста, если это нелогично и плохо? Дословно так «Ну, и что? Это логично? Это хорошо?». Только не надо соскакивать, делая вид, что этот вопрос был не риторическим.

                                                                            Я в ответ спросил, что в этом плохого, если в русском языке нас это не смущает.

                                                                            На что вы спросили, почему же мы сравниваем естественный язык с языком программирования.

                                                                            После чего я спросил, почему ЯП обязан быть неестественным.

                                                                            Поэтому далее вы либо отвечаете, почему же он все таки обязан быть неестественным, либо поднимаетесь по стеку, отвечая на мой предыдущий вопрос. Поднявшись к верхушке, мы установим истину.
                                                                            • 0
                                                                              Поэтому далее вы либо отвечаете, почему же он все таки обязан быть неестественным.

                                                                              Я уже ответил на этот самый вопрос, но вам же это не интересно.

                                                                              • 0
                                                                                Ну вам же тоже неинтересно подняться до верхушки стека обсуждения, вы же пытаетесь углубиться подальше, потому что понимаете, что ошиблись.

                                                                                Раз это ваш окончательный ответ, поднимитесь по стеку и ответьте на предыдущий вопрос. Давайте я помогу наводящими вопросами: раз мы выяснили, что язык не обязан быть неестественным, то что плохого в попытках в каких-то местах приблизить его к естественному? Например поведение оператора, зависящее от ближайшего (на этой же строке) контекста.

                                                                                Не надо только соскакивать, делая вид, что вы не давали отрицательную оценку, и якобы это я начал рассуждать «хорошо-плохо».
                                                                                • 0

                                                                                  И на этот вопрос я уже отвечал. Теперь ваша очередь показать, что именно этот подход в отличие от остальных: а) логичен б) хорош.

                                                                          • 0
                                                                            Это объяснение, почему так есть, а не почему так должно быть.

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


                                                                            Или что плохо, а что хорошо? Я запутался.

                                                                            Попробуйте не думать в терминах "хорошо-плохо", лучше "нравится-не нравится". Perl старается быть ближе к живому языку, поддерживая многозначительность и TIMTOWTDI. Python такой подход отвергает и требует однозначности.


                                                                            Что из этого хорошо? Что плохо? Да всё фигня, если честно. Выбирайте что нравится и не страдайте.

                                                                            • +1
                                                                              Да будет вам. Вся информатика напротив постоянно двигается в сторону очеловечивания. Всё IT построено на том, чтобы создавать эти самые уровни абстракции, которые позволяют пользователю/программисту/художнику/музыканту/бухгалтеру как можно эффективнее и быстрее решать поставленную задачу, и как можно меньше тратить времени и сил на информатику.

                                                                              Уровень языка и отражает положение этой точки интерфейса между человеком и машиной. У низкоуровневых языков этот интерфейс ближе к машине, у высокоуровневых — ближе к человеку. Поэтому в высокоуровневых языках программист не заботится о выделении памяти, переключениях контекста, системных вызовах, блокировках (опустим момент, что хороший программист всегда должен это держать в голове).

                                                                              Поэтому, нет, это ответ, почему так есть, а не почему так должно быть. Я не говорю, что все языки должны внезапно начать понимать человеческую речь, но какие-то определенные высокоуровневые языки в будущем могут себе это позволить.

                                                                              Попробуйте не думать в терминах «хорошо-плохо»

                                                                              Направление хорошо-плохо задал наш оппонент dionys где-то еще очень очень сверху:

                                                                              Первый коммент:
                                                                              Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».
                                                                              Второй коммент:
                                                                              Ну, и что? Это логично? Это хорошо?

                                                                              Если бы он просто сказал «мне так не нравится», я бы не вмешался.
                                                                        • 0

                                                                          Язык программирования обязан быть формальным, а это очень неестесственно.

                                                          • 0
                                                            в питоне он и так и так используется

                                                            Как, впрочем, и в яваскрипте :-)

                                                            • 0

                                                              Что?


                                                              var a = [5, 6, 7];
                                                              5 in a;  // false
                                                              1 in a;  // true
                                                              • 0

                                                                Вас что смущает-то?

                                                                • +1

                                                                  Это не проверка наличия элемента в массиве, а проверка существования индекса.

                                                                  • 0

                                                                    Нет, это проверка наличия ключа в списке ключей переданного словаря.


                                                                    '0' in a // true
                                                                    'length' in a // true
                                                                    • 0

                                                                      Без разницы, это в любом случае не проверка наличия элемента в массиве.

                                                                      • +1

                                                                        А никто не обещал проверку наличия элементов в массиве.

                                                                        • 0

                                                                          Вы написали, что в JS этот оператор работает так же, как и в Python. В статье утверждается, что там он используется для проверки наличия элемента в массиве.

                                                                          • 0
                                                                            В питоне, если это словарь, то проверяется наличие ключа. Если это список (значения без ключей), то проверяется наличие значения.
                                                                            • 0

                                                                              Ох, подойдём с другой стороны. Как с помощью in проверить наличие элемента в массиве в JS? Вот код на Python для типа list:


                                                                              a = [3, 4, 5]
                                                                              5 in a  # True

                                                                              Напишите аналогичный код на JS для «типа» Array.

                                                                              • 0
                                                                                Как с помощью in проверить наличие элемента в массиве в JS?

                                                                                Не знаю. А я такое говорил?

                                                                                Я просто внес уточнения, что в питоне в случае со списком, in проверяет значение, а в случае со словарем — ключ.
                                                                                • 0
                                                                                  let a = [3,4,5]
                                                                                  a.includes(3) //-> true
                                                                                  a.includes(1) //-> false
                                                                              • 0

                                                                                Я такого не писал. Не фантазируйте. В яваскрипте как и в питоне он используется и так и сяк. Со своими особенностями в каждом языке. В яваскрипте, например, долгое время не было массивов как таковых, да и сейчас те, что есть, исключительно числовые.

                                                                                • 0

                                                                                  Давайте освежим вашу память:


                                                                                  dionys: […] в JavaScript in используется для итерации по свойствам объекта, а Python почему-то для проверки наличия элемента в массиве […]
                                                                                  worldmind: в питоне он и так и так используется
                                                                                  vintage: Как, впрочем, и в яваскрипте :-)
                                                                                  • 0

                                                                                    Может прекратите выкручиваться? Вам уже сказали, что в обоих языках этот оператор используется в разных (однако весьма родственных) значениях: для итерирования по коллекции и для проверки вхождения в эту коллекцию. Всё различите между яваскриптом и питоном в том, что в питоне он может быть применён и к словарям и к массивам, а в яваскрипте только к словарям, так как массивов там попросту нет. Так что ваше противопоставление — полнейшая глупость.

                                                                                    • –1

                                                                                      Я привёл выше весь разговор. В нём нет того, что вы сейчас написали. Я так понимаю, вы отказываетесь от своих слов? Принято.

                                                      • +2
                                                        > Perl дал вам десяток способов (на самом деле, два), как узнать размер массива.

                                                        а разве количество способов это какое-то преимущество?
                                                        особенно если среди них ни одного логичного (len/length/size)?
                                                        • –1
                                                          Есть целых два логичных. $#a+1 и @a в скалярном контексте. Это куда логичнее, чем отдельная функция. За отдельными функциями вам в php.
                                                          Странно, что вы ещё не упомянули, что у вас в глазах рябит от знаков препинания.
                                                          • +1
                                                            И что в этих вариантах логичного? Это соглашения, условности, которые нужно заучить, а логично это когда исходя из общих знаний (например других языков программирования) можно предположить, догадаться как оно делается (
                                                            length(@arr), @arr.length
                                                            ).
                                                            • 0
                                                              Так len(@a) — функция, @a.len — свойство, или len @a — оператор? Это соглашение, условность, которую надо заучить.
                                                              • 0
                                                                Да, но это общие для практически всех языков концепции, разумно их использовать, а не изобретать своё просто ради того чтобы отличаться
                                                              • 0
                                                                scalar(@ary) — единственно расово верный способ, между прочим. или вас имя смущает?
                                                                • 0
                                                                  да, почему scalar(@arr)?
                                                                  • 0
                                                                    Это несколько необычно по сравнению с другими языками, но когда знаешь логику построения языка, то это вполне логично. Уж вы то должны это понимать после стольких лет разработки на нем.
                                                                    • 0
                                                                      Нет, это не логично т.е. это никаким образом не вытекает из логики языка.
                                                                      Да, в перле есть понятие контекста, но из него нельзя вывести объяснение почему массив в скалярном контексте возвращает его размер.
                                                                      А почему бы не возвращать исключение? Ведь массив это не скаляр, это неопределённое поведение.
                                                                      А может надо возвращать не размер, а последний индекс?
                                                                      А может надо выдирать первый элемент (как делает shift), ведь в перле список в скалярном контексте возвращает один элемент (правда последний), и это хоть как-то можно понять, раз я требую скаляр от массива, то наверно я хочу извлечь элемент, логично?
                                                                      • +2
                                                                        Нет, это не логично т.е. это никаким образом не вытекает из логики языка.

                                                                        Логично и вполне вытекает, если чуть-чуть подумать.


                                                                        Да, в перле есть понятие контекста, но из него нельзя вывести объяснение почему массив в скалярном контексте возвращает его размер.

                                                                        Потому что DWIM. Какая самая распространённая операция работы с массивом после взятия элемента по индексу? Вот именно, взятие размера.


                                                                        А может надо возвращать не размер, а последний индекс?

                                                                        Последний индекс вообще ни о чём не говорит в случае, когда массив разрозненный. А вот размер это всегда количество элементов, вне зависимости от индексов.


                                                                        А может надо выдирать первый элемент (как делает shift), ведь в перле список в скалярном контексте возвращает один элемент (правда последний), и это хоть как-то можно понять, раз я требую скаляр от массива, то наверно я хочу извлечь элемент, логично?

                                                                        Нет, не логично. Между массивами и списками есть разница, и весьма большая. Например, список не имеет индексов и вы не можете извлечь произвольный элемент. Работа со списком идёт только перебором элементов. Разворачивание списка в скалярном контексте даст последний элемент именно потому, что перебор закончился на последнем элементе.


                                                                        Оператор shift мутирует список или массив, приведение к скаляру этого не делает. Понимаете разницу?


                                                                        Да, это особенности языка, да, их нужно понимать. Если лично вам эти особенности не нравятся, это не делает их плохими или бесполезными. :)

                                                                        • 0
                                                                          > Потому что DWIM

                                                                          не очень понял причём тут этот принцип, разверните если не трудно

                                                                          > Какая самая распространённая операция работы с массивом после взятия элемента по индексу? Вот именно, взятие размера.

                                                                          В си? Наверное, а в перле зачем нужен размер?
                                                                          for my $element (@array) {...}
                                                                          

                                                                          Ну и даже если она частая, при чём тут скалярный контекст? Все частые операции нужно делать в скалярном контексте?

                                                                          > Оператор shift мутирует список или массив, приведение к скаляру этого не делает. Понимаете разницу?

                                                                          конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?
                                                                          • 0
                                                                            конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?

                                                                            Потому что это проверка значения. Представьте, что при каждой проверке значения переменной это значение меняется.

                                                                            • 0
                                                                              Контекст != проверка, контекст это ожидание значение определённого типа.
                                                                              Хотя я не утверждаю что массив в скалярном контексте должен меняться, я говорю что есть много столь же «логичных» вариантов поведения, можно например возвращать истину если массив не пуст. Да и последний индекс ничем не хуже размера.
                                                                              • 0
                                                                                > можно например возвращать истину если массив не пуст

                                                                                Внезапно, мы так и делаем.
                                                                                • 0
                                                                                  почти, истина и значение трактуемое как истина не совсем одно и то же
                                                                                • 0
                                                                                  Хотя я не утверждаю что массив в скалярном контексте должен меняться, я говорю что есть много столь же «логичных» вариантов поведения,

                                                                                  Вы притягиваете за уши аргументы для подтверждения своей правоты, вот и всё.


                                                                                  Я уже вам советовал: перестаньте, это бессмысленно и бесполезно.

                                                                              • +2
                                                                                не очень понял причём тут этот принцип, разверните если не трудно

                                                                                Do What I Mean. Если есть несколько вариантов действия, выбираем наиболее естественный. В данном случае приведение массива к скаляру может давать то или другое значение; Ларри посчитал, что логично будет возвращать размер массива. Я с ним согласен.


                                                                                Или вот обратный пример: scalar(%foo). Я уже не помню, что за белиберду это вернёт, никогда не пользуюсь. С другой стороны, приведение хэша к скаляру вообще смысла не имеет, поэтому логичных вариантов просто нет.


                                                                                В си? Наверное, а в перле зачем нужен размер?

                                                                                Затем, что итерацию по массиву можно делать по-разному. Иногда нужно знать текущий индекс, чего foreach не даст. Или итерацию надо делать с хвоста к голове и мутировать массив по ходу дела. Или итерировать по N смежным массивам одновременно. Или просто показывать пользователю индикатор прогресса. Много для чего, в общем.


                                                                                Ну и даже если она частая, при чём тут скалярный контекст? Все частые операции нужно делать в скалярном контексте?
                                                                                конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?

                                                                                Вы мне сейчас напоминаете капризного ребёнка, который уже понял, что неправ, но продолжает капризничать из вредности. У меня таких трое. :)

                                                                                • 0
                                                                                  > Вы мне сейчас напоминаете капризного ребёнка

                                                                                  это ваше право, но это не аргумент
                                                                                  • 0

                                                                                    Когда я стараюсь приводить убедительные аргументы, а мне в ответ брюзжат что-то типа "а у питона хвост длиннее, бе-бе-бе!", то желание аргументировать дальше у меня пропадает, извините.

                                                              • 0
                                                                > > тем самым признали что текущий перл вышел не очень удачным
                                                                > Нет.

                                                                да, достаточно сравнить с тем, что поменяли разработчики питона когда делали питон 3 без обратной совместимости, т.е. у них была возможность поменять что угодно, но они изменили очень мало, а перл 6 это совсем другой язык
                                                                • 0
                                                                  Perl 6 — это неудачное название. Примерно как C++. Это другой язык, напоминающий оригинал. С совершенно другой концепцией.
                                                                  • 0
                                                                    Эта другая концепция есть работа над ошибками
                                                                • 0
                                                                  > Именованные буферы введены в 5.10, десять лет назад.

                                                                  а причём тут именованные буферы? именованный захват тоже кладётся в глобальную переменную, если вы вдруг не в курсе
                                                                  • 0
                                                                    > В 5.20 введены сингнатуры.

                                                                    да, это некая, весьма запоздалая попытка решения и та в 5.20 ещё ругается что она experimental, не знаю как на более новых версиях
                                                                    • 0
                                                                      я просто пишу use YourCompany::Perl, и получаю в одном флаконе современный Perl, включая сигнатуры.

                                                                      вот так выглядит код — YourCompany::Model::Project
                                                                      • +1
                                                                        Перл он такой, можно сделать почти всё (жаль инфиксные операторы нельзя), но это будет какой-то свой кастомный перл, а хорошая технология по умолчанию предлагает хорошие решения.
                                                                        • 0
                                                                          Суть в том, что Perl

                                                                          а) имеет две задачи — однострочники, и скрипты по сути. Умолчания сделаны для однострочников исторически.

                                                                          б) хорошие решения для кода меняются со временем. поэтому желаемый набор умолчаний надо устанавливать явно. аналог в C++ `--std=c++14`
                                                                    • +1
                                                                      >> почти все книги по перлу рекомендуют модуль Datetime
                                                                      > Это проблема языка?

                                                                      да, дата это вполне стандартный тип и язык должен предоставлять в комплекте лучшую библиотеку для работы с этим типом, а не предлагать перебирать миллион вариантов на cpan
                                                                      • 0
                                                                        Ну то есть C — плохой, негодный язык.
                                                                        • 0
                                                                          во-первых, си не очень тут подходит для сравнения, это системный язык, а я о прикладных языках
                                                                          во-вторых, да, си не очень хороший язык, не случайно его пытаются заменить на всякие го и расты
                                                                          • 0
                                                                            Да ради бога. Идеальных языков не существует, через 30 лет и питон, и го, и раст, и JS тоже будут историей.
                                                                            • +2
                                                                              Конечно, но некоторые лучше других: перл, пхп и js мне кажутся ощутимо хуже чем например питон
                                                                              • 0
                                                                                Так и напишите — я не пишу на Perl, потому что питон мне больше нравится. Вместо этого вы начали выискивать существенные недостатки вроде отсутствия не то функции, не то свойства, не то оператора length.
                                                                                • +1
                                                                                  Я пытаюсь говорить о логичности синтаксиса языка, о читаемости и писяемости
                                                                        • 0
                                                                          вот тут вы правы, один тип данных удобнее кучи. с другой стороны, в ядре Perl (core modules, аналог в C++ — stdlib) множество вариантов работы с датой и временем. доступны, грубо говоря, из коробки. так что плюс на минус.

                                                                          тот же Time::Piece
                                                                          • +1
                                                                            Множество вариантов хороши когда сфера новая и ещё никто не знает как делать правильно, тогда конкуренция между модулями может помочь найти правильное решение, но такие вещи как работа с датами точно к этому не относятся, в 21 веке уже можно поставлять в поставке одну, хорошую библиотеку для дат.
                                                                            • 0

                                                                              Правда? Вы мне такую библиотеку для JavaScript покажите. Чтобы одна, и хорошая. 21-й век же на дворе.


                                                                              Хинт: нету и не будет, потому что JavaScript на голову больное и native Date object в нём примерно как граната в руках у пресловутой обезьяны.


                                                                              А сколько новых проектов пишется на Node.js? А сколько вообще в мире новых не-Web проектов, чтобы без JavaScript обойтись? Казалось бы...

                                                                                • 0

                                                                                  Спасибо, посмотрю на досуге. Авансом даже понадеюсь, что библиотека окажется неплоха.


                                                                                  Хотя общей пичальки это не отменяет: работа с датами в JavaScript сломана навзничь, так же как и многое другое. И это всё называют нашим светлым будущим. :(

                                                                                  • 0

                                                                                    JS — совершенно не тот язык, где стоит искать хорошее проектирование.

                                                                        • 0
                                                                          >> язык создавался как замена shell'у, а потом оброс фичами

                                                                          > Ханжество.

                                                                          Вот тут я бы, наверное, поспорил. То, что у большой части перлового синтаксиса корни растут из Bourne и C shell, отрицать было бы просто глупо. А что фичами оброс, так это тоже как бы факт. :)