Достаточно того, что авторы языка, задумывая новые версию, по сути создали новый язык мало похожий на исходный (Perl 6), тем самым признали что текущий перл вышел не очень удачным, что в принципе понятно т.к. язык создавался как замена shell'у, а потом оброс фичами.
Я бы хотел сказать о своих личных наблюдениях, которые привели меня к тому, что работать на перле я пойду только в крайнем случае, несмотря на то, что этой мой основной язык.
- Обратная совместимость — перл старается её поддерживать, с одной стороны это хорошо, с другой стороны для того чтобы писать на современном перле надо явно включать прагмы использования новых фич т.е. написав код по умолчанию в 21 веке вы можете получить код в котором компилятор не отлавливает даже опечатки и именах переменных и не поддерживает никаких новых конструкций. Мне кажется те, кто хотят обратной совместимости должны включать прагмы таковой, а по умолчанию язык должны быть актуальным.
- Параллельное программирование — с тредами в перле изначально было плохо, их как-то всегда не рекомендовали использовать, форкать процессы можно, но до определённого порога, а потом люди начинают думать как это оптимизировать и конечно перл не исключение — история этого вопроса примерно такая, сначала был POE, потом его заменил Coro, а потом пришёл и всех победил AnyEvent. И долгое время я не понимал суть проблемы, но когда узнал как эти вопросы решаются в Erlang или Haskell понял что асинхронное программирование на коллбэках это низкий уровень, по сути шаг назад. Перл когда-то выстрелил именно как высокоуровневый язык, а тут получилось наоборот.
- Глобальные переменные — грамотные программисты конечно используют use strict и my, но многие конструкции языка, такие как регулярные выражения или eval, используют глобальные переменные для возвращения результата, это уродство о котором нужно всегда помнить, например в $1 может оказаться результат предыдущего матчинга, поэтому надо проверять не наличие значения, а результат матчинга. В питоне, в том числе для регексов, обошлись без глобальных переменных и всё получилось нормально.
- eval — это пример странности в синтаксисе, на самом деле eval в перл, если передать ему строку, ведёт себя как ожидается от функции с таким именем, а вот если ему передать блок кода, то он по сути реализует оператор try, хотя и убого (поэтому на cpan есть много «фиксов» try).
- Передача параметров в функцию — опять же, предлагается какой-то низкоуровневый механизм, параметры приходят виде массива и нужно его явно превращать в что-то удобочитаемое, некоторые варианты в принципе невозможно реализовать, например нельзя передать два хеша по значению, только по ссылке. Есть конечно костыли вроде этого, но костыли есть костыли, достаточно посмотреть на то как реализована передача параметров в Python, чтобы понять как должен выглядеть продуманные высокоуровневый синтаксис передачи параметров.
- Оператор in — стандартная задача — проверить входит ли элемент в массив, в питоне это делается единственно правильным способом
element in array, в перле такого нет, одно время вводили smart matching, но наворотили там такого, что быстро решили его выпилить, а остальные варианты выглядят просто жутко.
- Работа с датами — к сожалению почти все книги по перлу рекомендуют модуль Datetime, автор которого смешал в один модуль, то что должно быть двумя (арифметика дат и календарь) и ещё и рассказывает всем как это оказывается сложно делать такую ерунду, а ещё у этого модуля жуткий объектный синтаксис. Относительно нормальный в перле это Class::Date, но почему-то его мало кто знает, а эталон снова в питоне, почему-то там люди понимают, что максимальная единица в арифметике дат это неделя, а месяц это уже понятие календаря. Кому интересны подробности может почитать переписку тут.
- И это можно продолжать бесконечно, вот ещё пример, когда вместо одной нормальной функции, есть куча непонятно чего.
- Но главная проблема в том, что сообщество не замечает этих проблем — «мы всегда так делали».
Кто-то может сказать, что это мелочи, мол можно привыкнуть и писать рабочий код, да, я долгое время писал, но со временем понимаешь, что нет никаких причин привыкать к плохому, надо выбирать лучшие решения, а не какие-нибудь.
Помимо этого, раньше у перла было преимущество в количестве модулей, но сейчас оно утеряно, уже несколько раз приходилось из перла использовать питонные модули, спасибо автору Inline::Python за такую возможность.
Комментарии (220)
vintage
26.04.2017 12:21Я так и не понял по какому принципу вы отделяете "даты" и "календарь". Посмотрите реализацию $jin.time, правда она на JS, но портировать её на что бы то ни было не составит труда.
worldmind
26.04.2017 16:00под датой я подразумеваю число секунд с начала времён, такие даты можно, например, вычитать по сути как числа и получать корректный интервал, а календарь это уже все фишки летоисчисления — високосные года и всякие дополнительные секунды
vintage
26.04.2017 18:55Ну получили вы "корректный интервал" в 1234565 секунд, а толку? Его всё-равно надо представить в виде "столько-то лет, столько-то дней и тд". Сможете привести хоть один пользовательский сценарий, где не важны "все фишки летоисчисления"?
alexeykuzmin0
27.04.2017 15:52Например, при замерах производительности. Вполне нормально написать, что программа работала 1 неделю, 2 дня, 3 часа, 4 минуты и 5.67890123 секунд, и никакие месяцы переменной длины, високосные годы и тд тут не нужны.
vintage
27.04.2017 16:43+1alexeykuzmin0
27.04.2017 16:55+1Казалось бы, эта ссылка лишь подтверждает мои слова: нужна отдельная библиотека для работы с датами (поддерживающая все эти тонкости, а также тонкости, которые там не указаны: например, тот факт, что политика перевода летнее/зимнее время могла меняться в течение истории), и отдельная библиотека для замера интервалов времени, работающая с равномерными монотонными часами и использующая лишь промежутки времени фиксированной длины (секунда, минута = 60 секунд, час = 3600 секунд, сутки (математические, а не астрономические) = 86400 секунд, неделя (опять же, математическая) = 604800 секунд).
vintage
27.04.2017 20:14"Математические" сутки и недели никого не интересуют.
alexeykuzmin0
27.04.2017 22:37Как это никого не интересуют? Если я смотрю, как долго вычисляется факториал из 100000, мне плевать, был ли в день вычисления перевод часов. Мне важно получить время вычисления в абсолютных единицах.
Eldhenn
28.04.2017 07:33Всё, что приближается к суткам, и тем более, к неделе, уже зависит от календаря. А библиотеки для часов-минут-секунд есть и всегда были.
worldmind
27.04.2017 17:06+1Зависит от задачи, например мне нужно сделать какое-то действие раз в 10 минут (например обновить кеш, сделать бекап) или запретить совершать какие-то действия если прошло сколько-то времени (например запретить редактировать комментарий), мне нет никакого дела до календаря, я просто беру текущую дату, вычитаю из неё предыдущую и сравниваю результат с интервалом из конфига (10 минут).
Никакого дела мне нет, что этот год будет длиннее на одну секунду чем другие года из-за секунды координации и нет никакого дела что пользователь живёт по календарю майя.vintage
27.04.2017 20:19Вас, очевидно, интересуют не 10 минут, а 600 секунд.
По специальному решению Международной службы вращения Земли в конце суток по всемирному времени 30 июня или 31 декабря может добавляться так называемая секунда координации. При такой добавке последняя минута упомянутых суток содержит 61 секунду. Добавка секунды координации осуществляется для согласования всемирного координированного времени со средним солнечным временем UT1.
worldmind
27.04.2017 20:23Да, но для этой задачи можно считать что минута это 60 секунд
vintage
27.04.2017 20:30Ну то есть реальные минуты вас не интересуют, а интересуют некие "математические" минуты. Ваше право, но все остальные прибавляя к "2017-12-31T23:55:00.000Z" 10 минут ожидают получить "2018-01-01T00:05:00.00Z", а не "2018-01-01T00:04:59.00Z".
worldmind
27.04.2017 21:46это зависит от задачи, если вам надо выполнять что-то каждый год в первый понедельник, то конечно надо использовать модуль для работы с календарём, а если просто нужно узнать что прошло 10 «математических» минут, то календарь избыточен.
nohuhu
28.04.2017 02:09Никакого дела мне нет, что этот год будет длиннее на одну секунду чем другие года из-за секунды координации и нет никакого дела что пользователь живёт по календарю майя.
А вот и зря нет дела. Потому что эти 10 минут легко могут попасть на момент перевода времени, когда у вас в начале интервала было 2:53 утра, а стало 2:03 утра. Потому что в 3:00 стрелки перевели на час назад. Сколько в результате времени прошло, если одно из другого вычитать: -50 минут?
Core dump вместо бэкапа, и хорошо если только это.
worldmind
28.04.2017 09:16+1Так я буду вычитать не даты по календарю, а число секунд минус другое число секунд с начала времени
nohuhu
29.04.2017 06:47+1Вычитайте, просто держите в уме, что это работает только в тривиальных случаях. А если, скажем, время нужно брать из внешних источников типа логов, то можно очень легко напороться.
sbnur
26.04.2017 12:51-1Старая жена, с которой стал человеком, надоела и накопила, а может сразу имела, массу недостатков, и в кризисе среднего возраста возникает искушение найти молодую и привлекательную.
Но проблема в том, что средний возраст означает не молодость, а массу своих собственных проблем, и обычно эти проблемы приводят к печальному результату — старое разрушено, а новое не построено.
И остануться только оправдания типа этого.
Eldhenn
26.04.2017 13:25+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 есть проблемы, но перечисленное вами — это не проблемы, а ханжество и вкусовщина.
msts2017
26.04.2017 15:08Я не очень понимаю, как вы росчерком пера отделили даты от календаря, и сделали их несвязанными сущностями. Из вашей рассылки — «дата — это число единиц времени с начала отсчёта» — это же совершенно неверно. Число единиц времени — это число, а дата — это дата)
как раз потому что считаете — "«дата — это число единиц времени с начала отсчёта» — это же совершенно неверно" и не можете отделить даты от календаря.
но меня другое удивило, неделя — почему? в датах две базовые единицы год и день, так как имеют физическую основу а за остальное (квартал, месяц, неделя, начало отсчета) отвечает календарь, например на венере год меньше дня вот увязка этой ситуации и лежит на календаре.Eldhenn
26.04.2017 15:16Календарная дата — порядковый номер календарного дня, порядковый номер или наименование календарного месяца и порядковый номер календарного года (Федеральный закон Российской Федерации от 3 июня 2011 г. № 107-ФЗ «Об исчислении времени»).
Дата — запись, включающая в себя число месяца, месяц и год, иногда день недели, номер недели в году и систему летосчисления.
================
Календа?рь — система счисления больших промежутков времени
Azoh
26.04.2017 15:18За исключением того, что исходя из самого популярного календаря, каждый год, чей номер делится на четыре, на день длиннее. За исключением тех, которые делятся на сотню. Они нормальные. Кроме случая когда они делятся на 400. Тогда они не нормальные.
Об этом кто должен знать? Модуль с датами? Или с календарем?
msts2017
26.04.2017 15:39за високосные года должен отвечать модуль дат
т.е. модуль дат отвечает за физическое воплощение отсчета времени а календарь за логическую трансляцию в заданный календарь, условно говоря — 1ый день 4млрд 7600 какого-то года это 01.01.2017 от Р.Х., вот за эту трансляцию и отвечает календарь (ну и наоборот тоже)
но это в идеале, конечно все в одно мешают.
перечитал про венеру — лажанул, «ситуации и лежит на календаре» на модуле дат конечно.Azoh
26.04.2017 15:59Високосные года — особенность отдельных календарей. Т.е. нам нужны модули дат для каждого календаря, учитывающие особенности их построения? И даты нужно будет приводить друг к другу?
Может лучше иметь базовый тип времени, который не зависит от календаря? А календарно-зависимые операции переложить на модули соответствующих календарей?
msts2017
26.04.2017 16:35«Високосные года — особенность отдельных календарей», насколько я понимаю не совсем так, високосные года это механизм компенсации принятый к исполнению в отдельных календарях, но он существует «параллельно» им, как те же модули.
Azoh
27.04.2017 07:08+2Нет, это именно часть календаря. Этот способ принят в двух календарях, юлианском и грегорианском. Возможно, что были еще другие солнечные календари, в которых были подобные поправки, но я ничего о них не знаю. В лунных и лунно-солнечных месяца (и года) определяются по другому, так что там свои заморочки с отсчетом. В еврейском календаре, например, високосный год отличается не на день, а на месяц.
Возвращаяь к високосным годам, юлианский календарь, по сути, от грегорианского отличается только правилами компенсации. В юлианском високосным считается каждый 4-й год, что дает среднюю продолжительность года в 365,25 дней. В грегорианском же средняя продолжительность 365,2425, что дает меньшую ошибку, особенно на продолжении многих веков.
msts2017
27.04.2017 22:17еще раз, в этой ветке обсуждают архитектурные абстракции в программировании, вы же ссылаетесь на реальный календарь, так вот это календарь состоит из двух частей модель даты\времени и логическая их организация в месяцы недели и т.п., поэтому ваше нет не имеет смысла — то что вы рассматриваете как календарь я рассматриваю как два модуля — даты и календарь, согласно контекста обсуждения.
MikailBag
27.04.2017 22:46Даты зависят от календаря.
Пресловутая 61-ая секунда перед НГ.
Реформа Петра Первого 1700 года (год длился 4 месяца).
Azoh
28.04.2017 10:42Так я об архитектурных абстракциях и забочусь, чтобы они были правильные, удобные и не протекали. И если какая-то абстракция в программировании при проверке реальностью оказывается плохой, то нужно отказываться от абстракции, а не от реальности.
Вот где вы проводите границу между этими модулями? Года, например, вы включили в модуль дат, хотя они, очевидно, существенно зависят от календаря. А вот, скажем, недели вас не устроили, хотя они не зависят от календаря.
Более того, как вы определяете дату, если "число единиц времени с начала отсчёта" вас не устраивает? Хотя это единственный способ определить дату так, чтобы не привязаться к какому-то календарю.
Eldhenn
26.04.2017 15:39Это как раз мелочи. Куда интереснее вопрос, сколько дней было в 1917 году.
msts2017
26.04.2017 15:49ну дык транслируем дату из старого календаря в (условно) абсолютную — год.день а из нее в новый календарь, все нормально.
Eldhenn
26.04.2017 15:53Абсолютная дата?! Дожили.
worldmind
26.04.2017 16:03юникстайм?
nohuhu
28.04.2017 03:13Unix time это UTC без високосных секунд, так?
UTC в современной форме определено только с 1 января 1972. С 1961 по 1972 UTC было определено по-другому, с дробными дополнительными секундами в високосных годах, и собственно определение секунды UTC не совпадало со стандартной секундой СИ. Атомные часы появились только в 1958, до этого стандарты СИ были другими и время базировалось на астрономических наблюдениях.
Давайте, переводите в абсолютные цифры и обратно. Если в результате для 23 февраля 1917 днём недели получится "фиолетовый банан", не удивляйтесь. Так всё и было.
worldmind
28.04.2017 09:17не очень понял какую проблему вы пытаетесь продемонстрировать
nohuhu
29.04.2017 03:49+1Очень простую: нет никаких абсолютных дат и быть не может. И переводить даты из одного календаря в другой гораздо сложнее, чем кажется.
Используя наивные варианты решения, отдавайте себе в этом отчёт. А то потом из-за излишней самоуверенности спутники падают или улетают чёрти куда.
Eldhenn
26.04.2017 15:58И вы не поняли особенности вопроса. Во Франции и в России длительность 1918 (прошу прощения) года была различной. И даже ещё интереснее, см. пункты 2, 3, 4 декрета о времени.
msts2017
26.04.2017 16:12насколько я понимаю это разные календари, да календарные года в них разной длины, а (условно) абсолютный год (забыл как это по нормальному называется, астрономическое время?) то один.
worldmind
26.04.2017 16:13+1> any {$a eq $_} @x
как раз вот такая наркомания мне и не нравится, я написал в статье нормальный вариант, сравните
dionys
27.04.2017 11:04Почему он нормальный?
worldmind
27.04.2017 17:29Потому что он радикально проще читается, он логичен, он понятен исходя не только из знаний программирования, а даже исходя из знания английского языка, а приведённый вариант специфичен для перла, хотя и основывается на функциональной парадигме.
dionys
27.04.2017 17:51Ничего подобного — всё перечисленное, лишь отражение собственных вкусов и привычек. К примеру, в JavaScript
inиспользуется для итерации по свойствам объекта, а Python почему-то для проверки наличия элемента в массиве. Что-то не вижу тут логичности и привычности. И это не говоря о том, чтоinимеет сильно ограниченный функционал по сравнению сany, по сутиin— лишь один из частных случавany. Далее,any, к примеру, есть в Erlang и в JavaScript (какArray#some), а так же, думаю, и в других функциональных языках. То есть нельзя говорить о специфичности.worldmind
27.04.2017 18:11+1> JavaScript in используется для итерации по свойствам объекта
в питоне он и так и так используется
> in имеет сильно ограниченный функционал по сравнению с any
так это и хорошо, он делает одну задачу превращая код в почти английский текст
> Далее, any
я против any ничего не имею и не предлагаю его запретить, я говорю что в данной ситуации any не должен использоватьсяdionys
27.04.2017 18:28-1То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным? Хорошо, да. Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».
А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования. У меня есть в таком случае кандидат в победители этой альтернативной олимпиады — SPL.
worldmind
27.04.2017 20:16+1я говорил хорошо и логично пока только про один вариант, про проверку наличия элемента в массиве: ЕСЛИ элемент В массиве ТО…
AlexBin
27.04.2017 21:59То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным?
Сюрприз, во всех языках есть элементы, которые применяются по-разному в зависимости от контекста. Попробуйте познакомиться с каким-нибудь языком программирования, и эта тайна для вас перестанет быть тайной.
А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования.
Вы любите посложнее, да? Любые упрощения и синтаксический сахар — это не для настоящих мужиков.
dionys
27.04.2017 22:14-1Сюрприз, во всех языках есть элементы, которые применяются по-разному в зависимости от контекста.
Ну, и что? Это логично? Это хорошо?
Вы любите посложнее, да?
Нет. А вы точно любите приписывать оппоненту то, чего он не говорил.
AlexBin
27.04.2017 22:36+1Ну, и что? Это логично? Это хорошо?
Слово «что» может применяться по-разному в русском языке, почему нас это не смущает?
Нет
А сказали таким голосом, будто «да».
Неужели эта конструкция читается сложно?
for a in (1, 2, 3): print a
А эта?
if a in (1, 2, 3): print a
В питоне есть более непонятные и нелогичные вещи, но вы осуждаете вполне себе выразительную, удобную и интуитивно понятную конструкцию.dionys
27.04.2017 22:55Слово «что» может применяться по-разному в русском языке, почему нас это не смущает?
Мы всё ещё о программировании?
А сказали таким голосом, будто «да».
Повторю: вы точно любите приписывать оппоненту то, чего он не говорил.
AlexBin
28.04.2017 00:21Мы всё ещё о программировании?
Мы о сложности использовании контекста. Почему в русском языке нам несложно понимать слова в зависимости от контекста, а в программировании должно быть сложно?
Повторю: вы точно любите приписывать оппоненту то, чего он не говорил.
Тогда поясните, что вы хотели сказать этой фразой:
А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования. У меня есть в таком случае кандидат в победители этой альтернативной олимпиады — SPL.
А еще я выше задал вопросы с кусочками кода, вы проигнорировали.dionys
28.04.2017 00:33Почему в русском языке нам несложно понимать слова в зависимости от контекста, а в программировании должно быть сложно?
А почему мы вообще сравниваем язык программирования с естественным языком? Это что, попытка провернуть подмену предмета обсуждения: типа что верно для русского языка, то верно и для Python?
Тогда поясните, что вы хотели сказать этой фразой
Это был сарказм по поводу утверждения, что близкий к английскому, значит лучший.
А еще я выше задал вопросы с кусочками кода, вы проигнорировали.
Потому что я ничего не осуждаю.
AlexBin
28.04.2017 00:46-1А почему мы вообще сравниваем язык программирования с естественным языком?
А почему язык программирования обязан быть неестественным?
Это был сарказм по поводу утверждения, что близкий к английскому, значит лучший.
А почему язык программирования обязан быть неестественным? (с)
Потому что я ничего не осуждаю.
А это стало быть похвала и восхищения:
То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным? Хорошо, да. Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».
dionys
28.04.2017 01:00А почему язык программирования обязан быть неестественным?
Не обязан (но фактически должен по многим причинам), но естественным не является.
А это стало быть похвала и восхищения
Это ни похвала, ни осуждение. Это сомнение в утверждении, что именно данный подход логичен и хорош.
nohuhu
28.04.2017 03:22А почему язык программирования обязан быть неестественным?
Потому что все языки программирования, даже такие лингвистически продвинутые как Perl, являются выражением математических абстракций. А живые языки от математики крайне далеки.
Поэтому ни один язык программирования естественным языком общения между людьми быть не может. А живые языки только-только начинают использоваться для общения с компьютерами, на совершенно базовом уровне. И это после 70 лет развития, ага.
AlexBin
28.04.2017 13:43Потому что все языки программирования, даже такие лингвистически продвинутые как Perl, являются выражением математических абстракций. А живые языки от математики крайне далеки.
Это объяснение, почему так есть, а не почему так должно быть.
лингвистически продвинутые как Perl
Ну то есть лингвистически продвинутый перл — это хорошо, а лингвистически гибкое поведение оператора in в питоне — это плохо? Или что плохо, а что хорошо? Я запутался.dionys
28.04.2017 15:19-1Конечно вы запутались, ведь вопрос звучал так:
А почему язык программирования обязан быть неестественным?
И никаких хорошо и плохо в связи с ним не было.
AlexBin
29.04.2017 09:55Давайте я освежу вашу память (с)
Вы спросили, почему in (и другие операторы в языках) должен применяться по-разному в зависимости от контекста, если это нелогично и плохо? Дословно так «Ну, и что? Это логично? Это хорошо?». Только не надо соскакивать, делая вид, что этот вопрос был не риторическим.
Я в ответ спросил, что в этом плохого, если в русском языке нас это не смущает.
На что вы спросили, почему же мы сравниваем естественный язык с языком программирования.
После чего я спросил, почему ЯП обязан быть неестественным.
Поэтому далее вы либо отвечаете, почему же он все таки обязан быть неестественным, либо поднимаетесь по стеку, отвечая на мой предыдущий вопрос. Поднявшись к верхушке, мы установим истину.dionys
29.04.2017 10:22Поэтому далее вы либо отвечаете, почему же он все таки обязан быть неестественным.
Я уже ответил на этот самый вопрос, но вам же это не интересно.
AlexBin
29.04.2017 10:37Ну вам же тоже неинтересно подняться до верхушки стека обсуждения, вы же пытаетесь углубиться подальше, потому что понимаете, что ошиблись.
Раз это ваш окончательный ответ, поднимитесь по стеку и ответьте на предыдущий вопрос. Давайте я помогу наводящими вопросами: раз мы выяснили, что язык не обязан быть неестественным, то что плохого в попытках в каких-то местах приблизить его к естественному? Например поведение оператора, зависящее от ближайшего (на этой же строке) контекста.
Не надо только соскакивать, делая вид, что вы не давали отрицательную оценку, и якобы это я начал рассуждать «хорошо-плохо».dionys
29.04.2017 11:43И на этот вопрос я уже отвечал. Теперь ваша очередь показать, что именно этот подход в отличие от остальных: а) логичен б) хорош.
nohuhu
29.04.2017 03:42Это объяснение, почему так есть, а не почему так должно быть.
Это объяснение, почему так было, есть и будет. Языки программирования никогда не будут использоваться для общения между людьми, а вот машины вполне возможно что и начнут понимать живые языки достаточно хорошо. Что опять же не сделает ни один живой язык близким к языку программирования, это ортогонально противоположные вещи.
Или что плохо, а что хорошо? Я запутался.
Попробуйте не думать в терминах "хорошо-плохо", лучше "нравится-не нравится". Perl старается быть ближе к живому языку, поддерживая многозначительность и TIMTOWTDI. Python такой подход отвергает и требует однозначности.
Что из этого хорошо? Что плохо? Да всё фигня, если честно. Выбирайте что нравится и не страдайте.
AlexBin
29.04.2017 10:28+1Да будет вам. Вся информатика напротив постоянно двигается в сторону очеловечивания. Всё IT построено на том, чтобы создавать эти самые уровни абстракции, которые позволяют пользователю/программисту/художнику/музыканту/бухгалтеру как можно эффективнее и быстрее решать поставленную задачу, и как можно меньше тратить времени и сил на информатику.
Уровень языка и отражает положение этой точки интерфейса между человеком и машиной. У низкоуровневых языков этот интерфейс ближе к машине, у высокоуровневых — ближе к человеку. Поэтому в высокоуровневых языках программист не заботится о выделении памяти, переключениях контекста, системных вызовах, блокировках (опустим момент, что хороший программист всегда должен это держать в голове).
Поэтому, нет, это ответ, почему так есть, а не почему так должно быть. Я не говорю, что все языки должны внезапно начать понимать человеческую речь, но какие-то определенные высокоуровневые языки в будущем могут себе это позволить.
Попробуйте не думать в терминах «хорошо-плохо»
Направление хорошо-плохо задал наш оппонент dionys где-то еще очень очень сверху:
Первый коммент:Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».
Второй коммент:Ну, и что? Это логично? Это хорошо?
Если бы он просто сказал «мне так не нравится», я бы не вмешался.
vintage
27.04.2017 20:21в питоне он и так и так используется
Как, впрочем, и в яваскрипте :-)
dionys
27.04.2017 20:29Что?
var a = [5, 6, 7]; 5 in a; // false 1 in a; // truevintage
27.04.2017 20:33Вас что смущает-то?
dionys
27.04.2017 20:43+1Это не проверка наличия элемента в массиве, а проверка существования индекса.
vintage
27.04.2017 21:37Нет, это проверка наличия ключа в списке ключей переданного словаря.
'0' in a // true 'length' in a // truedionys
27.04.2017 21:52Без разницы, это в любом случае не проверка наличия элемента в массиве.
vintage
27.04.2017 21:56+1А никто не обещал проверку наличия элементов в массиве.
dionys
27.04.2017 22:09Вы написали, что в JS этот оператор работает так же, как и в Python. В статье утверждается, что там он используется для проверки наличия элемента в массиве.
AlexBin
27.04.2017 22:39В питоне, если это словарь, то проверяется наличие ключа. Если это список (значения без ключей), то проверяется наличие значения.
dionys
27.04.2017 23:06Ох, подойдём с другой стороны. Как с помощью
inпроверить наличие элемента в массиве в JS? Вот код на Python для типаlist:
a = [3, 4, 5] 5 in a # True
Напишите аналогичный код на JS для «типа»
Array.AlexBin
28.04.2017 00:00Как с помощью in проверить наличие элемента в массиве в JS?
Не знаю. А я такое говорил?
Я просто внес уточнения, что в питоне в случае со списком, in проверяет значение, а в случае со словарем — ключ.
vintage
27.04.2017 23:29Я такого не писал. Не фантазируйте. В яваскрипте как и в питоне он используется и так и сяк. Со своими особенностями в каждом языке. В яваскрипте, например, долгое время не было массивов как таковых, да и сейчас те, что есть, исключительно числовые.
dionys
27.04.2017 23:38Давайте освежим вашу память:
dionys: […] в JavaScript
inиспользуется для итерации по свойствам объекта, а Python почему-то для проверки наличия элемента в массиве […]
worldmind: в питоне он и так и так используется
vintage: Как, впрочем, и в яваскрипте :-)vintage
27.04.2017 23:55Может прекратите выкручиваться? Вам уже сказали, что в обоих языках этот оператор используется в разных (однако весьма родственных) значениях: для итерирования по коллекции и для проверки вхождения в эту коллекцию. Всё различите между яваскриптом и питоном в том, что в питоне он может быть применён и к словарям и к массивам, а в яваскрипте только к словарям, так как массивов там попросту нет. Так что ваше противопоставление — полнейшая глупость.
dionys
28.04.2017 00:13-1Я привёл выше весь разговор. В нём нет того, что вы сейчас написали. Я так понимаю, вы отказываетесь от своих слов? Принято.
worldmind
26.04.2017 16:36+2> Perl дал вам десяток способов (на самом деле, два), как узнать размер массива.
а разве количество способов это какое-то преимущество?
особенно если среди них ни одного логичного (len/length/size)?Eldhenn
26.04.2017 18:34-1Есть целых два логичных. $#a+1 и @a в скалярном контексте. Это куда логичнее, чем отдельная функция. За отдельными функциями вам в php.
Странно, что вы ещё не упомянули, что у вас в глазах рябит от знаков препинания.worldmind
26.04.2017 18:39+1И что в этих вариантах логичного? Это соглашения, условности, которые нужно заучить, а логично это когда исходя из общих знаний (например других языков программирования) можно предположить, догадаться как оно делается (
).length(@arr), @arr.length
akzhan
26.04.2017 21:50scalar(@ary) — единственно расово верный способ, между прочим. или вас имя смущает?
worldmind
27.04.2017 11:55да, почему scalar(@arr)?
dimm_ddr
27.04.2017 14:23Это несколько необычно по сравнению с другими языками, но когда знаешь логику построения языка, то это вполне логично. Уж вы то должны это понимать после стольких лет разработки на нем.
worldmind
27.04.2017 17:36Нет, это не логично т.е. это никаким образом не вытекает из логики языка.
Да, в перле есть понятие контекста, но из него нельзя вывести объяснение почему массив в скалярном контексте возвращает его размер.
А почему бы не возвращать исключение? Ведь массив это не скаляр, это неопределённое поведение.
А может надо возвращать не размер, а последний индекс?
А может надо выдирать первый элемент (как делает shift), ведь в перле список в скалярном контексте возвращает один элемент (правда последний), и это хоть как-то можно понять, раз я требую скаляр от массива, то наверно я хочу извлечь элемент, логично?nohuhu
27.04.2017 23:32+2Нет, это не логично т.е. это никаким образом не вытекает из логики языка.
Логично и вполне вытекает, если чуть-чуть подумать.
Да, в перле есть понятие контекста, но из него нельзя вывести объяснение почему массив в скалярном контексте возвращает его размер.
Потому что DWIM. Какая самая распространённая операция работы с массивом после взятия элемента по индексу? Вот именно, взятие размера.
А может надо возвращать не размер, а последний индекс?
Последний индекс вообще ни о чём не говорит в случае, когда массив разрозненный. А вот размер это всегда количество элементов, вне зависимости от индексов.
А может надо выдирать первый элемент (как делает shift), ведь в перле список в скалярном контексте возвращает один элемент (правда последний), и это хоть как-то можно понять, раз я требую скаляр от массива, то наверно я хочу извлечь элемент, логично?
Нет, не логично. Между массивами и списками есть разница, и весьма большая. Например, список не имеет индексов и вы не можете извлечь произвольный элемент. Работа со списком идёт только перебором элементов. Разворачивание списка в скалярном контексте даст последний элемент именно потому, что перебор закончился на последнем элементе.
Оператор shift мутирует список или массив, приведение к скаляру этого не делает. Понимаете разницу?
Да, это особенности языка, да, их нужно понимать. Если лично вам эти особенности не нравятся, это не делает их плохими или бесполезными. :)
worldmind
28.04.2017 09:31> Потому что DWIM
не очень понял причём тут этот принцип, разверните если не трудно
> Какая самая распространённая операция работы с массивом после взятия элемента по индексу? Вот именно, взятие размера.
В си? Наверное, а в перле зачем нужен размер?
for my $element (@array) {...}
Ну и даже если она частая, при чём тут скалярный контекст? Все частые операции нужно делать в скалярном контексте?
> Оператор shift мутирует список или массив, приведение к скаляру этого не делает. Понимаете разницу?
конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?dionys
28.04.2017 10:57конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?
Потому что это проверка значения. Представьте, что при каждой проверке значения переменной это значение меняется.
worldmind
28.04.2017 16:02Контекст != проверка, контекст это ожидание значение определённого типа.
Хотя я не утверждаю что массив в скалярном контексте должен меняться, я говорю что есть много столь же «логичных» вариантов поведения, можно например возвращать истину если массив не пуст. Да и последний индекс ничем не хуже размера.nohuhu
29.04.2017 03:36Хотя я не утверждаю что массив в скалярном контексте должен меняться, я говорю что есть много столь же «логичных» вариантов поведения,
Вы притягиваете за уши аргументы для подтверждения своей правоты, вот и всё.
Я уже вам советовал: перестаньте, это бессмысленно и бесполезно.
nohuhu
29.04.2017 07:03+2не очень понял причём тут этот принцип, разверните если не трудно
Do What I Mean. Если есть несколько вариантов действия, выбираем наиболее естественный. В данном случае приведение массива к скаляру может давать то или другое значение; Ларри посчитал, что логично будет возвращать размер массива. Я с ним согласен.
Или вот обратный пример:
scalar(%foo). Я уже не помню, что за белиберду это вернёт, никогда не пользуюсь. С другой стороны, приведение хэша к скаляру вообще смысла не имеет, поэтому логичных вариантов просто нет.
В си? Наверное, а в перле зачем нужен размер?
Затем, что итерацию по массиву можно делать по-разному. Иногда нужно знать текущий индекс, чего
foreachне даст. Или итерацию надо делать с хвоста к голове и мутировать массив по ходу дела. Или итерировать по N смежным массивам одновременно. Или просто показывать пользователю индикатор прогресса. Много для чего, в общем.
Ну и даже если она частая, при чём тут скалярный контекст? Все частые операции нужно делать в скалярном контексте?
конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?Вы мне сейчас напоминаете капризного ребёнка, который уже понял, что неправ, но продолжает капризничать из вредности. У меня таких трое. :)
worldmind
29.04.2017 23:39> Вы мне сейчас напоминаете капризного ребёнка
это ваше право, но это не аргументnohuhu
01.05.2017 02:21Когда я стараюсь приводить убедительные аргументы, а мне в ответ брюзжат что-то типа "а у питона хвост длиннее, бе-бе-бе!", то желание аргументировать дальше у меня пропадает, извините.
worldmind
26.04.2017 16:45> > тем самым признали что текущий перл вышел не очень удачным
> Нет.
да, достаточно сравнить с тем, что поменяли разработчики питона когда делали питон 3 без обратной совместимости, т.е. у них была возможность поменять что угодно, но они изменили очень мало, а перл 6 это совсем другой язык
worldmind
26.04.2017 17:20> Именованные буферы введены в 5.10, десять лет назад.
а причём тут именованные буферы? именованный захват тоже кладётся в глобальную переменную, если вы вдруг не в курсе
worldmind
26.04.2017 17:26> В 5.20 введены сингнатуры.
да, это некая, весьма запоздалая попытка решения и та в 5.20 ещё ругается что она experimental, не знаю как на более новых версияхakzhan
26.04.2017 21:52я просто пишу use YourCompany::Perl, и получаю в одном флаконе современный Perl, включая сигнатуры.
вот так выглядит код — YourCompany::Model::Projectworldmind
27.04.2017 17:09+1Перл он такой, можно сделать почти всё (жаль инфиксные операторы нельзя), но это будет какой-то свой кастомный перл, а хорошая технология по умолчанию предлагает хорошие решения.
akzhan
29.04.2017 16:57Суть в том, что Perl
а) имеет две задачи — однострочники, и скрипты по сути. Умолчания сделаны для однострочников исторически.
б) хорошие решения для кода меняются со временем. поэтому желаемый набор умолчаний надо устанавливать явно. аналог в C++ `--std=c++14`
worldmind
26.04.2017 17:29+1>> почти все книги по перлу рекомендуют модуль Datetime
> Это проблема языка?
да, дата это вполне стандартный тип и язык должен предоставлять в комплекте лучшую библиотеку для работы с этим типом, а не предлагать перебирать миллион вариантов на cpanEldhenn
26.04.2017 18:27Ну то есть C — плохой, негодный язык.
worldmind
26.04.2017 18:29во-первых, си не очень тут подходит для сравнения, это системный язык, а я о прикладных языках
во-вторых, да, си не очень хороший язык, не случайно его пытаются заменить на всякие го и растыEldhenn
26.04.2017 18:33Да ради бога. Идеальных языков не существует, через 30 лет и питон, и го, и раст
, и JSтоже будут историей.worldmind
26.04.2017 18:35+2Конечно, но некоторые лучше других: перл, пхп и js мне кажутся ощутимо хуже чем например питон
Eldhenn
27.04.2017 07:02Так и напишите — я не пишу на Perl, потому что питон мне больше нравится. Вместо этого вы начали выискивать существенные недостатки вроде отсутствия не то функции, не то свойства, не то оператора length.
worldmind
27.04.2017 17:23+1Я пытаюсь говорить о логичности синтаксиса языка, о читаемости и писяемости
akzhan
26.04.2017 23:06вот тут вы правы, один тип данных удобнее кучи. с другой стороны, в ядре Perl (core modules, аналог в C++ — stdlib) множество вариантов работы с датой и временем. доступны, грубо говоря, из коробки. так что плюс на минус.
тот же Time::Pieceworldmind
27.04.2017 17:15+1Множество вариантов хороши когда сфера новая и ещё никто не знает как делать правильно, тогда конкуренция между модулями может помочь найти правильное решение, но такие вещи как работа с датами точно к этому не относятся, в 21 веке уже можно поставлять в поставке одну, хорошую библиотеку для дат.
nohuhu
27.04.2017 23:48Правда? Вы мне такую библиотеку для JavaScript покажите. Чтобы одна, и хорошая. 21-й век же на дворе.
Хинт: нету и не будет, потому что JavaScript на голову больное и native Date object в нём примерно как граната в руках у пресловутой обезьяны.
А сколько новых проектов пишется на Node.js? А сколько вообще в мире новых не-Web проектов, чтобы без JavaScript обойтись? Казалось бы...
nohuhu
28.04.2017 01:53>> язык создавался как замена shell'у, а потом оброс фичами
> Ханжество.
Вот тут я бы, наверное, поспорил. То, что у большой части перлового синтаксиса корни растут из Bourne и C shell, отрицать было бы просто глупо. А что фичами оброс, так это тоже как бы факт. :)Eldhenn
28.04.2017 07:21+1Вот странные вы люди. Кто бы спорил с фактами, но делать на их основе далеко идущие выводы… Perl — замена шеллу с регекспами, Java — язык для умных кофеварок и стиральных машин, что там, да, php — недоязычок для гостевых книг, js — недоязычок для моргающих строк на веб-странице.
nohuhu
29.04.2017 03:13С моей точки зрения, это вы странный человек. Я написал ровно то, что написал: Perl действительно создавался как замена shell для решения практических задач в те времена, когда Bourne shell был уже дряхл и неудобен, C shell был уже сломан, Korn shell стоил некислых денег, а bash и его клонов ещё не было в природе. И фичами он тоже обрастал постепенно, пока количество не перевалило в качество и не родился Perl 5, который мы все отлично знаем и нежно любим.
Ну и какие выводы вы здесь видите? Я никаких не вижу.
Eldhenn
29.04.2017 09:12Выводы сделал автор. «Раз perl — это sh с регекспами, то это и есть sh с регекспами, недоязычок, писать на котором просто несерьёзно». Именно это я назвал ханжеством.
potan
26.04.2017 13:49Perl очень хорош для коротких программ, а пределах пары экранов. Или вообще однострочников, скажем запускаемых из vim.
А для более крупных программ надо использовать языки с развитыми системами типов.Eldhenn
26.04.2017 13:50А мужики-то не знают, и пишут на скриптовых языках миллионы строк кода…
vintage
26.04.2017 14:01+1Потом к ним пишут миллиард тестов вида "а что если туба будет передана строка, а не число".
nohuhu
28.04.2017 02:00Ройт, а в Правильных Языках поцоны могут не гадать, что будет, а использовать соответствующие операторы и точно знать заранее безо всякой кофейной гущи.
Здесь вам тут не жаваскрипт. ;)
helgihabr
26.04.2017 15:50+2Если многие недостатки Perl можно причесать, как, например, непонятный синтаксис можно сделать довольно строгим при наличии процесса code review (т.к., действительно, если бросить это на самотек, то будет как в мультфильме «Простоквашино», когда они письмо писали). Что в будущем определит легкость/трудность в поддержке кода.
Но вот что мне лично очень принципиально, так это процесс установки приложения на новый сервер (deploy).
После более 7 лет разработки на Perl я, волей случая, был вовлечен в разработку на Go и теперь совсем неохотно берусь за задачи, связанные с Perl. Т.к. установка необходимых пакетов в крупных проектах с Perl — целая песня.
Я учавствовал в довольно крупных проектах, в которых Perl был основным языком (а зачастую и единственным), но по прошествию лет я начинаю понимать, что просто выбор был не так велик, как сейчас.
В любом случае, можно относится к Perl по-разному, но уж точно с уважением.potan
26.04.2017 17:18+2Я очень давно не писал на Perl (кроме однострочников), но когда писал мне очень нравился его пакетный менеджер. Сейчас пишу на Scala и меня очень расстраивает необходимость следить за версиями зависимостей в разных проектах.
akzhan
26.04.2017 23:11Я люблю Perl, но пакетный менеджер у него не очень — неудобно сказать — ставь мне модуль версии 1.8.x, но не включая 1.8.4, точно не используя 1.7.x или 1.9.x, и не младше 1.8.1.
в этом плане rubygems удобнее. а npm с его модулями в модулях — чересчур.nohuhu
27.04.2017 22:37в этом плане rubygems удобнее
Это больше говорит о качестве кода в пакетах ruby, чем об удобстве пакетного менеджера. Ставить модуль чётко определённой версии, потому что все остальные сломаны, включая не только прошлые, но и последующие? Это совершенно не нормальная ситуация.
Что в общем и не удивляет, если честно. Мой личный процесс познания Ruby обломился на попытке отдебажить SASS компилятор compass и понять, почему же оно такое тормозное. После нескольких часов утомительной пересборки ruby нужной версии (шаг в сторону — расстрел) и попыток заставить профилировщик заработать я понял, почему им никто не пользуется. А потом я таки заставил его заработать и обнаружил, что 30% времени compass тратит на склеивание путей файлов в системной библиотеке, которая написана просто через жопу.
На этом слёзы у меня кончились и желание трогать Ruby тоже. Тем более что парни из соседнего отдела всё равно уже лабали свой SASS компилятор на JavaScript. (facepalm)
vintage
27.04.2017 23:32Зачем? Есть же быстрая сишная библиотека.
nohuhu
27.04.2017 23:43Не знаю, если честно. Они там в соседнем отделе много чего делают, мне непонятного. Но идея избавиться от compass была мне вполне близка, учитывая, что компиляция одной темы демо-приложения могла легко занимать 30-40 секунд, включая старт ruby и все остальные накладки. А новый компилятор гораздо бОльший объём работы делает за ~3 секунды. На порядок быстрее.
Да и дело было года 3 назад, может этой библиотеки не было ещё, или нестабильная была.
vintage
27.04.2017 23:59Была. Мы её под нодой использовали. Работала очень шустро. Потом пересели на более нативный для ноды и фичастый stylus.
nohuhu
27.04.2017 17:07Т.к. установка необходимых пакетов в крупных проектах с Perl — целая песня.
Контейнеризация не поможет? Docker и иже с ними.
helgihabr
27.04.2017 17:29Docker довольно молодая технология, а бизнесы, которы процветают с Perl, как говорят, old school.
Очень многим крупным проектам, написанных на Perl, более 10 лет. Чаще в таких проектах разработчики используют VM (со своими накладными расходами).
Я как-то предложил использовать Docker вместо VM, но бизнес, зачастую, так устроен, что если что-то приносит деньги, то этот процесс очень неохотно разрешают менять.nohuhu
27.04.2017 20:52бизнесы, которы процветают с Perl, как говорят, old school.
Не все. Новые проекты тоже вполне бывают. ;)
Я как-то предложил использовать Docker вместо VM, но бизнес, зачастую, так устроен, что если что-то приносит деньги, то этот процесс очень неохотно разрешают менять.
В случае использования отдельных VM отказ вполне понятен и оправдан — проблем с установкой пакетов в контролируемой среде и так нет, а если ресурсы не жмут, то менять шило на мыло смысла нет.
Вот написал и задумался, а так ли нет проблем. Можете привести примеры ситуаций, когда перловые пакеты стали бы головной болью в контролируемой VM? Интересно.
AkaiUsagi
27.04.2017 20:23Лично мои претензии к перлу:
Отсутствие нормального пакетного менеджера (установки завистимосей из git практически нет)
Отсутствие некоторых нормальных фреймворков (Mojolicious далеко позади современных веб фреймворков на других языках) и библиотек (с тех же дат я долго мучался до обнаружения Date::Simple), нет нормальной ORM
Ужасная документация у (почти) всего что не core modules
Concurrency — форки не всегда то, что нужно
Carp или аналоги — отдельные модули, а не инструмент языка
UTF-8
ООП — никто не заставляет его использовать, но почему-то все это делают, и с ним всё здесь плохо. В помощь и в зависимости проекта нам приходит весь огород модулей для этого (Moose, Mouse, Moo… и 100 других)
Сборка CPAN модулей, cpan её не умеет, приходится использовать Minilla, Dist::Zilla и прочее, а нужно просто иметь возможность поставить cpanm'ом модуль, который вот он уже, вроде, готовый.
Да и сам CPAN иногда кажется помойкой, приходится долго искать и смотреть на модули, прежде чем выбрать что-то подходящее, на metacpan есть рейтинг, но не всегда он показателен, пакеты именует кто как хочет.dionys
27.04.2017 22:28Отсутствие нормального пакетного менеджера (установки завистимосей из git практически нет)
cpanm git://github.com/plack/Plack.gitAkaiUsagi
27.04.2017 23:22Да, так это работает, но при сборке проекта начинаются неудобства, мы не можем добавить всё в один cpanfile.
Плюс отсутствует возможность добавить гит зависимость в устанавливаемый модуль.
А Миягава только обещает добавить поддержку, но сейчас он пилит carmel и там про гит тоже ничего не понятно.
(https://github.com/miyagawa/cpanminus/issues/381 и, на сколько я знаю, ситуация не поменялась.)
Сейчас я вижу 2 возможности обойти это
1) Скрипт, который отдельно устанавливает гитовые зависимости
2) Поднять свой приватный цпан, приватный бэкпан и всё остальное
В итоге пришел ко второму способу, и это упростило некоторые вещи.
Но можно было бы этого не делать.neenik
27.04.2017 23:47Или свой cpanm. :)
У нас такой, с этим PR
https://github.com/miyagawa/cpanminus/pull/490
По факту, всё-равно перешли на деб-пакеты.
nohuhu
27.04.2017 20:40-1Это вы рекламироваться пытаетесь таким извращённым образом, или просто самоутверждаетесь? В первом случае могу пожать плечами, в последнем сочувственно похлопать по плечу опять же. Трудно это, проснуться однажды тёплым весенним утром и понять что вот всё — таки не в сказку попал. Жизнь == боль.
Не хотите программировать на Perl, не программируйте. Зачем такой надрыв? А главное, кому какое дело? :)
worldmind
27.04.2017 21:42-1Просто накопились наблюдения, решил вдруг кому интересно.
nohuhu
27.04.2017 22:27Если у вас просто накопились наблюдения, то с чего такая драма? Вас кто-то принуждает писать на Perl? Ну так плюньте им в лицо и пишите на том, что нравится.
В любом случае вы опоздали, пинать Perl уже давным-давно не модно и кармы особо не прибавит. :)
worldmind
27.04.2017 22:37+1Да вроде драмы нет.
Карма меня не особо интересует, да и о прибавлении речь не идёт — пост еле из минусов выбрался, а карму даже чуток подуменьшили.nohuhu
27.04.2017 22:46Я бы хотел сказать о своих личных наблюдениях, которые привели меня к тому, что работать на перле я пойду только в крайнем случае, несмотря на то, что этой мой основной язык.
Кто-то может сказать, что это мелочи, мол можно привыкнуть и писать рабочий код, да, я долгое время писал, но со временем понимаешь, что нет никаких причин привыкать к плохому, надо выбирать лучшие решения, а не какие-нибудь.Это ли не шекспировские страсти? :)
А про карму я в переносном смысле. Эти местечковые извращения с плюсиками и минусиками мне всегда смешны были. :) Есть что сказать — скажи, а нажать минусик это типа крикнуть "ты дурак!" в ответ. В детском саду весело было, потом как-то надоело. :))
worldmind
27.04.2017 22:51> Это ли не шекспировские страсти? :)
ну это просто текст, каждый эмоциональную составляющую видит по своему, но наверно да, накипело чуток )nohuhu
27.04.2017 22:58накипело чуток )
Так вот я и говорю: если накипело, то плюнье слюной и не трогайте больше. Нравится вам Python? Ну так и признайтесь себе честно, что он вам больше нравится, чем Perl, и не придумывайте другие оправдания. Просто пишите на Python, за чем дело стало. :)
Другое дело, когда выбора нет. Мне, скажем, JavaScript уже костью поперёк горла стоит. Но деваться некуда, в браузерах больше ничего нет. И за жабы скрипт масса даёт много сладкий батат, поэтому приходится затыкаться и лабать дальше. :)
worldmind
27.04.2017 23:04Я надеюсь что внедрение WebAssemby в браузеры приведёт к тому что нормальные языки типа питона научатся в него компилироваться.
nohuhu
28.04.2017 00:33Угу, со всеми втекающими и вытекающими типа отладки по source maps, пачке Беломора и известной матери. Спасибо, не надо.
Тем более, что открытие доступа к DOM из WebAssembly в ближайшем будущем не предвидится, а без этого толку от WebAssembly чуть менее, чем ноль.
Так что, мыши плачут и колются, а белый масса щёлкает кнутом. :)
AlexandreFrolov
27.04.2017 22:43+1Уже более 10 лет наша компания пишет на Perl сервис интернет-магазинов. Там есть свой биллинг, своя учетная система, система обработки заявок клиентов, свой деплой новых версий ядра и модулей магазинов на серверы, свой аналог CPAN (называем Перловкой) с возможностью установки модулей Перла на наши серверы, MailProxy — система рассылок почты с общей очередью и фильтрацией невалидных адресов получателей, база знаний Клондайк, модули мониторинга для Zabbix, да и много еще чего.
Все написано исключительно на Perl, к этому приложили руки очень опытные сотрудники, многие из которых, к моему сожалению, перешли работать в довольно известные компании. Всего за это время через нас прошло более десятка программистов Perl, и мы постоянно готовим для себя новых.
Да, как и у всякого сложного проекта с бородатой историей, у нас накопился технический долг, и мы постепенно обновляем архитектуру сервиса, как служебных систем, так и собственно интернет-магазинов.
И несмотря на это, все что написано, работает на удивление стабильно и надежно. Собственно, в свое время я именно по этой причине и выбрал Perl для реализации проекта. Я считаю, что для интернет-магазинов самое главное — надежность работы, т.к. от нее зависит прибыль предпринимателей. Новые технологии могут выстрелить, а могут и нет.
Например, в одном большом магазине мы использовали кластер MongoDB, и при количестве записей порядка 15 млн. и очень интенсивной нагрузке возникли проблемы, хотя при меньших размерах базы все работало хорошо.
Сейчас для нас не стоит вопрос переписывания систем на других языках.
Во-первых, это нецелесообразно экономически и не принесет никаких особых дивидендов.
Во-вторых, в других языках, а главное, в окружении других языков тоже есть свои проблемы.
В-третьих, если что-то лучше реализуется на других языках, почему бы не сделать подсистему в виде сервиса на чем-то еще? Например, на Питоне есть хорошие библиотеки для работы с нейронными сетями, ну и можно выделить эту часть в отдельный сервис.worldmind
27.04.2017 22:52> И несмотря на это, все что написано, работает на удивление стабильно и надежно
это мало связано с ЯП, это вопрос квалификации разработчиков, архитектуры проектаAlexandreFrolov
27.04.2017 23:05Во многом да, но платформа тоже имеет значение. В свое время отказался от PHP из-за отсутствия обратной совместимости, отсутствия единого репозитория, такого как CPAN, наличие уязвимостей, особенно в разных CMS, да и самим языком остался недоволен. Но другие используют PHP, и ничего)
worldmind
27.04.2017 22:54> Сейчас для нас не стоит вопрос переписывания систем на других языках.
ну возможно у вас грамотное руководство и вы не только набираете но и удерживаете достаточное число квалифицированных сотрудников, но компании с чуток менее продуманным подходом давно страдают от дефицита перловиков, который вполне может отразится на доходах.AlexandreFrolov
27.04.2017 23:07Да вот я сам и есть руководство, так что кивать мне не на кого)
Проблемы с кадрами есть, но ищем, стараемся. И сами готовим, да.
Перл выучить недолго, долго стать хорошим программистом.worldmind
27.04.2017 23:20+1> Перл выучить недолго, долго стать хорошим программистом.
редко кто это понимает: язык программирования, это всего лишь письменность, но если в мыслях бардак, знание письменности не поможет написать связный текст.
P.S. мне кажется удачная аналогия подобралась прямо сейчас
AlexBin
27.04.2017 23:53Похвастайте и ссылкой на ваш сервис
AlexandreFrolov
28.04.2017 00:16+1AlexBin
28.04.2017 00:34Спасибо.
Если не секрет, поделитесь опытом, какое ООП вы используете — штатное или батарейки? Тот же вопрос про систему обработки исключений и юниттесты.
AlexandreFrolov
28.04.2017 00:46+1Все ООП пишем руками, да. На некоторых проектах подключаем внешние модули для имитации try-catch, а так все больше eval. При возникновении проблем, ошибок, исключений, попыток взлома — админу идут письма. Видим, что больше всего пытаются сломать так, как будто у нас PHP. Также непрерывно пробуют инъекции.
Есть технологии для подключения плагинов к магазинам, не волшебные, но работают.
Тестами покрыто не все, но для самых важных модулей тесты составляются. Ядро магазинов почти все покрыто тестами. А при загрузке модулей в Перловку автоматически запускаются тесты для модулей, если они завершаются с ошибкой — загрузка отвергается.
Вообще конечно как язык лично мне больше всего нравится C#, но Microsoft с его ценами — это не наш вариант)
AlexandreFrolov
28.04.2017 01:38Да, у нас есть корпоративное руководство по стилю, выдаем всем новичкам. Стараемся, чтобы по коду нельзя было понять, кто из программистов писал тот или иной модуль) Все равно читать придется потом другим программистам. Но, конечно, в старых проектах встречается всякое, и ужасы тоже бывают. По возможности постепенно рефакторим.
Еще используем активно GitLab, очень помогает. Держим там такие проекты, как магазины, внутренние сервисы и подсистемы.
kloppspb
29.04.2017 00:40Да, у нас есть корпоративное руководство по стилю
Интересно. Оно как-то похоже на REG-рушное? Что с соглашениями о передаче параметров, etc?
выдаем всем новичкам
IMHO, потока новичков в перле не наблюдаются, старичков бы выловить по одному :-)nohuhu
29.04.2017 06:34IMHO, потока новичков в перле не наблюдаются, старичков бы выловить по одному :-)
На предыдущей работе познакомился с другой практикой: нанимают толковых людей, которые могут не знать Perl, но готовы учиться. Такой подход неплохо работает.
AlexandreFrolov
29.04.2017 08:51Да, вот и мы так делаем. Perl выучить легко, хватит пары недель для действительного хорошего программиста. А тех, кто раньше вообще ни на чем не программировал и ничего интересного не создал, брать не можем — слишком велики затраты на обучение и риск, что ничего не получится. Хотя в самом начале работы нашей компании я брал и таких.
kloppspb
29.04.2017 17:28Perl выучить легко
В каком-то смысле да. Но писать на нём так, чтобы это не напоминало кошмар а-ля Matt's Script Archive прошлого века издания…AlexandreFrolov
30.04.2017 07:26Это во многом зависит от программиста. В свое время мне рассказывали об исходниках на Паскале, выровненных по 8 колонке — работа бывшего программиста на Фортране) Т.е. на любом языке можно писать ужасный код.
При выборе платформы для проекта приходится учитывать очень много факторов. Опять же, я выбирал более 10 лет назад, и у нас не было, и до сих пор нет каких-то уж совсем ужасных проблем с Perl. Так что свой давнишний выбор я считаю удачным.
А что бы я выбирал сейчас начиная подобный бизнес — это сложный вопрос. Может, сейчас я бы занялся другим ИТ-бизнесом, интернетом вещей, например) И критерии для выбора платформы были бы совершенно другими.
Я намеренно говорю не про язык программирования, а про платформу в более широком смысле. Т.к. выбором языка дело в сложном проекте не ограничивается обычно.kloppspb
30.04.2017 16:34Понятно, что выбор платформы и технологий вообще — отдельный вопрос. Но что касается перла, часто TMTOWTDI ставится чуть ли не претензией к языку. И, к сожалению, часто приходится сталкиваться с тем, что среди многих путей выбирается самый непонятный. Например, сейчас разбираю код, где писавший его очень полюбил *_array из DBI. Выть хочется от попыток понять, что имеется в виду под $c[15] уже через десяток строк после селекта… И 50 тысяч (!) SLOC в таком стиле.
В общем, для меня загадка, почему так. В конце концов есть же PBP, есть критик, есть голова не только для «в неё есть» :-)
на любом языке можно писать ужасный код.
Ну да. Просто какие-то языки ограничивают в этом, а какие-то дают полную свободу. И тут законы Мерфи срабатывают на ура :)AlexandreFrolov
01.05.2017 09:29Конечно! Но тем и выделяются опытные программисты, что они на любом языке смогут написать понятно, если понимают, что участвуют в коллективной разработке, а не пишут что-то только для себя. И наличие корпоративного стиля, а главное, следование ему упрощает жизнь всем.
Других приходится либо обучать, либо при невозможности обучения — увольнять, а запутанный код — переписывать. Обычно у нас так бывает с некоторыми студентами. Разбираться в зашифрованном коде себе дороже, как правило, в нем еще и полно ошибок.
Eldhenn
05.05.2017 11:48> какие-то языки ограничивают в этом
На каком языке, по-вашему, писать нечитаемый код значительно сложнее, чем на Perl?kloppspb
05.05.2017 14:49Дело не в читаемости как таковой, обфусцировать можно код на любом языке :) А в TMTOWTDI в принципе. Наличие многих путей приводит некоторых в полное замешательство и заставляет выбирать самые кривые. Попробуйте догадаться что делают эти фрагменты:
for my $r ( 0, map { int( rand(@lines) ) } ( 1 .. 5 ) ) {
$sql .= " and f_name not in (" . join( ',', map { $self->{dbh}->quote($_) } @some ) . ')';
map { Encode::from_to( $_, "utf8", "cp1251" ) } @strings;
Видимо, автор этого кода однажды узнал про существование map и начал пихать её везде, совершенно не думая зачем и почему… Причём замечу, что во втором фрагменте речь вообще о postgres.Eldhenn
05.05.2017 14:58В любом языке есть выбор. Даже в ассемблере. Везде, где есть выбор, его можно сделать неправильно. Perl — мощный инструмент, позволяет с прямыми руками сделать многое — да, при попадании в кривые руки он превращает ноги в огнестрельные щупальца.
Писавший это, особенно третий фрагмент, был новичком, восхитился наличием map, ему показалось, что это красиво и изящно…
Кстати, а как вы предлагаете решать задачу из второго фрагмента? Если не подготавливать аналогичным образом N плейсхолдеров.kloppspb
05.05.2017 15:08Не зря упомянул postgres (про другие не скажу, давно не работал): конструкция IN прекрасно заменяется на ANY, а в ней DBD::Pg может принимать один плейсхолдер, который инициализируется ссылкой на массив сырых данных :) Который, в свою очередь, уже и так имеется.
Eldhenn
05.05.2017 15:12Ну не знал человек про ANY. Я вот тоже умудрился пропустить, хотя я плотно с постгресом очень давно работал.
kloppspb
05.05.2017 17:05Ну не знал человек про ANY
Так даже в случае IN есть другой путь с тем же map :)
' and f_name not in (' .join( ',', map { '?' } @some ) . ')';
И он всё-таки выглядит более правильным. Вообще, первое что нужно знать про map — эта функция создаёт массив. Зачем создавать новый массив для обычной итерации «по-простому», для меня загадка :)
bar($_) for @foo;
Но, тем не менее, даже для такой простой штуки можно напридумывать кучу путей…Eldhenn
05.05.2017 17:16Я уверен, даже в IBM BASIC можно выстрелить себе в ногу. И уж тем более, в любом из современных сложных языков.
kloppspb
05.05.2017 18:54Тут не себе, и не в ногу :) А в голову тому, кому такой код достался… Впрочем, насчёт везде можно — согласен. Но в перле, как ни странно, есть стандартные конструкции, стандартные подходы ко мнгоим вещам, и заменять их на какую-то отсебятину левой ногой через правое ухо совсем не нужно. Даже если можно и очень хочется :)
Eldhenn
05.05.2017 18:59Так опять же, везде есть хорошие практики. Но для них требуется некоторый опыт, ну и чутьё. Я сам работаю сейчас с легаси-кодом, там много интересных инженерно-технических решений применено, и выборка десяти колонок из БД в массив — далеко не самое страшное, самое страшное — это «интересное» понимание бизнес-процессов.
Но даже на html можно написать говнокод, а можно включить межушный нервный узел…kloppspb
05.05.2017 23:04можно включить межушный нервный узел
О чём и речь. Но, видимо, для многих (включая автора статьи) это слишком сложно :)
kloppspb
06.05.2017 01:43Да, и если человек сосредоточен на решении частных проблем, это говорит именно и об отсутствии опыта работы с языком, да и об опыте работы вообще. Ну а «чутьё» с этим самым опытом и нарабатывается :) На разных задачах, на разных языках. И это не зависит от языка, IMHO.
BTW, я тут вчера прокосячил: всё-таки взял стандартную для перла реализацию ip2int, ручную, без Socket. Первый косяк всплыл, когда выяснилось, что оно не вползает в постгресовский int. Изменил в базе тип на bigint. Нуачо? И это был второй косяк. Потому что:
во-первых, встаёт «бизнес-задача» превратить потом этот бигинт в читаемый для саппорта вид. Во-вторых, если взять всё-таки родной тип INET (несмотря на всего его кажущуюся тяжесть, включая индексацию), да прогнать тесты с EXPLAIN и Devel::NYTProf на нескольких миллионах записей, вместе и по отдельности.
Но если бы следовал стенаниям из статьи: делать хреново потому что «сообщество так делает» — и именно так оно и советует в данном случае, наверное, так бы и плакал на то что Perl плохой.
AlexandreFrolov
29.04.2017 08:48Похоже, да. По передаче параметров ничего особенно строго нет. В зависимости от контекста передаем либо списком, либо хешом.
Насчет новичков, как я уже говорил, мы подготовили более чем за 10 лет работы десятки программистов Perl, обучая студентов. Многие из них, как я уже говорил, к сожалению, ушли от нас в известные ИТ-компании, где продолжают программировать на Perl.
Так что если старичков не хватает, мы смело готовим новичков)
Fogger
поверхностное мнение дилетанта… Perl еще нас с вами переживет и многие языки типа суррогаты типа python.
neenik
Если не ошибаюсь, worldmind пишет на перле лет 10. Так что про дилетанта — не поддержу вас.
alaska332
судя по проблемам, которые он описал — он программит на перле 10 дней, а не лет.
worldmind
на самом деле даже не важно сколько я пишу, я высказал конкретные замечания и разумный человек, если уже взялся отвечать, ответит конкретными контраргументами
Singaporian
Он ответил минусами в карму. Чем больше минусов, тем более качественные аргументы они заменяют :-D