Комментарии 227
Глобальные переменные, в которые регулярки записывают разультаты — жутко удобные, так как экономят объём кода и делают поэтому его более читабельным, а программиста — более продуктивным. Ну и опытному программисту на perl они нисколько не мешают, т.к. просто нужно обернуть выражение в блок: "abc" =~ /(b)/; { "xyz" =~ /(y)/; print $1 } print $1
Получится: yb
.
Прагмы программисты на perl не используют (ну максимум use common::sense, который включает use utf8; и удобные стрикты и варнинги, а те, что мешают разработке — нет). Поэтому новые расширения языка создаются для программистов переходящих из python в perl, пока они не научатся таки в perl )
Конечно никто на колбеках (AnyEvent, POE) и не программирует. Программируют на Coro — это легковесные процессы (волокна (fibers) или зелёные потоки (green threads)), которые выполняются внутри одного процесса. Вы, кстати, не разобравшись приписали его к AnyEvent, хотя он может подчинить её событийную машину через Coro::rose_cb и Coro::rose_wait. Там фишка в том, что при создании нового легковесного процесса нужно сразу обернуть код в нём в eval {}, чтобы перехватывать исключения внутри потока и не допустить остановку всей программы. Ну и Coro в perl так же удобен, как легковесные процессы в Erlang, Haskell или Go (один в один просто) )
eval на perl просто прекрасен, а конструкция try ... catch несколько громоздка, как по мне )
Взглянул на передачу параметров в python. def fn(a, b, c=10): а потом: fn(5, c=20, b=30) — удобно. Но, опять же, perl тоже удобен: можно манипулировать всеми параметрами в массиве @_, можно вернуть что-то через параметр: $_[0] = 5.
element in array. Ничего со смартматчингом не наворотили. Используется он легко и просто: 5 ~~ [1,5], ну или с переменными: $element ~~ \@array.
Что касается дат, то каждый может подобрать себе библиотеку по вкусу. Вроде в этом и мощь библиотек _)
Вместо len(s):
* scalar @arr;
* @arr + 0;
* @arr . '';
* $#arr + 1;
* push(@arr, 1) - 1;
* unshift(@arr, 1) - 1;
* my $i = 0; $i++ foreach @arr; return $i;
* @arr = (1) x @arr; return length join('', @arr);
Вообще-то тут массив приводится к скаляру, в результате чего получается его размер. В других языках программирования есть только скаляры, поэтому идею массивов сложно понять. Тем не менее их использование очень удобно. Например, чтобы узнать размер массива не нужна функция len )
Ну и аналогично на python:
scalar @arr; ⇒ len(arr)
@arr + 0; ⇒ len(arr) + 0
@arr . ''; ⇒ str(len(arr)) + ''
$#arr + 1; ⇒ len(arr)-1 + 1
push(@arr, 1) - 1; ⇒ arr.append(1); len(arr) - 1
unshift(@arr, 1) - 1; ⇒ arr[:0] = 1; len(arr) - 1
my $i = 0; $i++ foreach @arr; return $i; ⇒
i = 0
for a in arr:
i += 1
return i@arr = (1) x @arr; return length join('', @arr); ⇒ arr = ["1"] * len(arr); return len("".join(a))
Но главная проблема в том, что сообщество не замечает этих проблем — «мы всегда так делали».
О, так для сообщества это не проблемы )
О, призрак из прошлого! Не буду уже подробно отвечать, машина времени сломана, а сам уже подзабыл, хотя точно помню что в 2007 про Coro ещё говорили, но потом все (судя по докладам на конференциях и опыту знакомых в яндексах, мэйлру и рамблерах) все перешли на anyevent, в том числе потому что Coro были завязан на непубличное апи перла и иногда ломался, да и просто эниэаент был быстрее хоть и уродливее.
Просто это апи из perl убрали, но Марк Лехман - создатель Coro - тогда выпустил свой форк perl-а. Я его перекомпиливал, помню, и менял на фрюхах )
А потом до кодеовнеров официального perl дошло, что их perl никто не скачивает и им пришлось апи вернуть )
Ну, чтобы утверждать, что AnyEvent быстрее Coro, нужно показать нагрузочные тесты )
Ну и что нагрузочные тесты будут тестировать? У Coro есть только хандлер для работы с сокетами. А так Coro - это просто менеджер легковесных процессов. У него просто есть их табличка и он переключается с одного на другой по событию, которое возникает в EnyEvent, IO::AIO или любой другой библиотеке которую ему укажешь (так DB::Mysql умеет быть асинхронным сам по себе, остаётся его только подключить к Coro - и вуаля) ).
События удобны для GUI, где события возникают на виджетах на действия пользователя. Но использовать их чтобы считать файл... Ну это просто увеличивает объём кода с одной строки до 50 - вот и всё )
Такого же уровня и разговоры про смарт матчинг который почти сразу после своего появления был помечен как депрекейтед и думаю давно удалён.
Ну получили вы "корректный интервал" в 1234565 секунд, а толку? Его всё-равно надо представить в виде "столько-то лет, столько-то дней и тд". Сможете привести хоть один пользовательский сценарий, где не важны "все фишки летоисчисления"?
"Математические" сутки и недели никого не интересуют.
Никакого дела мне нет, что этот год будет длиннее на одну секунду чем другие года из-за секунды координации и нет никакого дела что пользователь живёт по календарю майя.
Вас, очевидно, интересуют не 10 минут, а 600 секунд.
По специальному решению Международной службы вращения Земли в конце суток по всемирному времени 30 июня или 31 декабря может добавляться так называемая секунда координации. При такой добавке последняя минута упомянутых суток содержит 61 секунду. Добавка секунды координации осуществляется для согласования всемирного координированного времени со средним солнечным временем UT1.
Ну то есть реальные минуты вас не интересуют, а интересуют некие "математические" минуты. Ваше право, но все остальные прибавляя к "2017-12-31T23:55:00.000Z" 10 минут ожидают получить "2018-01-01T00:05:00.00Z", а не "2018-01-01T00:04:59.00Z".
Никакого дела мне нет, что этот год будет длиннее на одну секунду чем другие года из-за секунды координации и нет никакого дела что пользователь живёт по календарю майя.
А вот и зря нет дела. Потому что эти 10 минут легко могут попасть на момент перевода времени, когда у вас в начале интервала было 2:53 утра, а стало 2:03 утра. Потому что в 3:00 стрелки перевели на час назад. Сколько в результате времени прошло, если одно из другого вычитать: -50 минут?
Core dump вместо бэкапа, и хорошо если только это.
Старая жена, с которой стал человеком, надоела и накопила, а может сразу имела, массу недостатков, и в кризисе среднего возраста возникает искушение найти молодую и привлекательную.
Но проблема в том, что средний возраст означает не молодость, а массу своих собственных проблем, и обычно эти проблемы приводят к печальному результату — старое разрушено, а новое не построено.
И остануться только оправдания типа этого.
Нет.
> язык создавался как замена 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 есть проблемы, но перечисленное вами — это не проблемы, а ханжество и вкусовщина.
Я не очень понимаю, как вы росчерком пера отделили даты от календаря, и сделали их несвязанными сущностями. Из вашей рассылки — «дата — это число единиц времени с начала отсчёта» — это же совершенно неверно. Число единиц времени — это число, а дата — это дата)
как раз потому что считаете — "«дата — это число единиц времени с начала отсчёта» — это же совершенно неверно" и не можете отделить даты от календаря.
но меня другое удивило, неделя — почему? в датах две базовые единицы год и день, так как имеют физическую основу а за остальное (квартал, месяц, неделя, начало отсчета) отвечает календарь, например на венере год меньше дня вот увязка этой ситуации и лежит на календаре.
Дата — запись, включающая в себя число месяца, месяц и год, иногда день недели, номер недели в году и систему летосчисления.
================
Календа́рь — система счисления больших промежутков времени
За исключением того, что исходя из самого популярного календаря, каждый год, чей номер делится на четыре, на день длиннее. За исключением тех, которые делятся на сотню. Они нормальные. Кроме случая когда они делятся на 400. Тогда они не нормальные.
Об этом кто должен знать? Модуль с датами? Или с календарем?
т.е. модуль дат отвечает за физическое воплощение отсчета времени а календарь за логическую трансляцию в заданный календарь, условно говоря — 1ый день 4млрд 7600 какого-то года это 01.01.2017 от Р.Х., вот за эту трансляцию и отвечает календарь (ну и наоборот тоже)
но это в идеале, конечно все в одно мешают.
перечитал про венеру — лажанул, «ситуации и лежит на календаре» на модуле дат конечно.
Високосные года — особенность отдельных календарей. Т.е. нам нужны модули дат для каждого календаря, учитывающие особенности их построения? И даты нужно будет приводить друг к другу?
Может лучше иметь базовый тип времени, который не зависит от календаря? А календарно-зависимые операции переложить на модули соответствующих календарей?
Нет, это именно часть календаря. Этот способ принят в двух календарях, юлианском и грегорианском. Возможно, что были еще другие солнечные календари, в которых были подобные поправки, но я ничего о них не знаю. В лунных и лунно-солнечных месяца (и года) определяются по другому, так что там свои заморочки с отсчетом. В еврейском календаре, например, високосный год отличается не на день, а на месяц.
Возвращаяь к високосным годам, юлианский календарь, по сути, от грегорианского отличается только правилами компенсации. В юлианском високосным считается каждый 4-й год, что дает среднюю продолжительность года в 365,25 дней. В грегорианском же средняя продолжительность 365,2425, что дает меньшую ошибку, особенно на продолжении многих веков.
Даты зависят от календаря.
Пресловутая 61-ая секунда перед НГ.
Реформа Петра Первого 1700 года (год длился 4 месяца).
Так я об архитектурных абстракциях и забочусь, чтобы они были правильные, удобные и не протекали. И если какая-то абстракция в программировании при проверке реальностью оказывается плохой, то нужно отказываться от абстракции, а не от реальности.
Вот где вы проводите границу между этими модулями? Года, например, вы включили в модуль дат, хотя они, очевидно, существенно зависят от календаря. А вот, скажем, недели вас не устроили, хотя они не зависят от календаря.
Более того, как вы определяете дату, если "число единиц времени с начала отсчёта" вас не устраивает? Хотя это единственный способ определить дату так, чтобы не привязаться к какому-то календарю.
Unix time это UTC без високосных секунд, так?
UTC в современной форме определено только с 1 января 1972. С 1961 по 1972 UTC было определено по-другому, с дробными дополнительными секундами в високосных годах, и собственно определение секунды UTC не совпадало со стандартной секундой СИ. Атомные часы появились только в 1958, до этого стандарты СИ были другими и время базировалось на астрономических наблюдениях.
Давайте, переводите в абсолютные цифры и обратно. Если в результате для 23 февраля 1917 днём недели получится "фиолетовый банан", не удивляйтесь. Так всё и было.
некомпетентность?
«Perl was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier.»
как раз вот такая наркомания мне и не нравится, я написал в статье нормальный вариант, сравните
Ничего подобного — всё перечисленное, лишь отражение собственных вкусов и привычек. К примеру, в JavaScript in
используется для итерации по свойствам объекта, а Python почему-то для проверки наличия элемента в массиве. Что-то не вижу тут логичности и привычности. И это не говоря о том, что in
имеет сильно ограниченный функционал по сравнению с any
, по сути in
— лишь один из частных случав any
. Далее, any
, к примеру, есть в Erlang и в JavaScript (как Array#some
), а так же, думаю, и в других функциональных языках. То есть нельзя говорить о специфичности.
в питоне он и так и так используется
> in имеет сильно ограниченный функционал по сравнению с any
так это и хорошо, он делает одну задачу превращая код в почти английский текст
> Далее, any
я против any ничего не имею и не предлагаю его запретить, я говорю что в данной ситуации any не должен использоваться
То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным? Хорошо, да. Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».
А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования. У меня есть в таком случае кандидат в победители этой альтернативной олимпиады — SPL.
Питон — хорошо и понятно, перл — нет. Разве непонятно?
То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным?
Сюрприз, во всех языках есть элементы, которые применяются по-разному в зависимости от контекста. Попробуйте познакомиться с каким-нибудь языком программирования, и эта тайна для вас перестанет быть тайной.
А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования.
Вы любите посложнее, да? Любые упрощения и синтаксический сахар — это не для настоящих мужиков.
Сюрприз, во всех языках есть элементы, которые применяются по-разному в зависимости от контекста.
Ну, и что? Это логично? Это хорошо?
Вы любите посложнее, да?
Нет. А вы точно любите приписывать оппоненту то, чего он не говорил.
Ну, и что? Это логично? Это хорошо?
Слово «что» может применяться по-разному в русском языке, почему нас это не смущает?
Нет
А сказали таким голосом, будто «да».
Неужели эта конструкция читается сложно?
for a in (1, 2, 3):
print a
А эта?
if a in (1, 2, 3):
print a
В питоне есть более непонятные и нелогичные вещи, но вы осуждаете вполне себе выразительную, удобную и интуитивно понятную конструкцию.
Слово «что» может применяться по-разному в русском языке, почему нас это не смущает?
Мы всё ещё о программировании?
А сказали таким голосом, будто «да».
Повторю: вы точно любите приписывать оппоненту то, чего он не говорил.
Мы всё ещё о программировании?
Мы о сложности использовании контекста. Почему в русском языке нам несложно понимать слова в зависимости от контекста, а в программировании должно быть сложно?
Повторю: вы точно любите приписывать оппоненту то, чего он не говорил.
Тогда поясните, что вы хотели сказать этой фразой:
А уж возможность превращения программы в английский текст — это, видимо, теперь фундаментальная основа для любого логичного и хорошего языка программирования. У меня есть в таком случае кандидат в победители этой альтернативной олимпиады — SPL.
А еще я выше задал вопросы с кусочками кода, вы проигнорировали.
Почему в русском языке нам несложно понимать слова в зависимости от контекста, а в программировании должно быть сложно?
А почему мы вообще сравниваем язык программирования с естественным языком? Это что, попытка провернуть подмену предмета обсуждения: типа что верно для русского языка, то верно и для Python?
Тогда поясните, что вы хотели сказать этой фразой
Это был сарказм по поводу утверждения, что близкий к английскому, значит лучший.
А еще я выше задал вопросы с кусочками кода, вы проигнорировали.
Потому что я ничего не осуждаю.
А почему мы вообще сравниваем язык программирования с естественным языком?
А почему язык программирования обязан быть неестественным?
Это был сарказм по поводу утверждения, что близкий к английскому, значит лучший.
А почему язык программирования обязан быть неестественным? (с)
Потому что я ничего не осуждаю.
А это стало быть похвала и восхищения:
То есть один оператор в Python используется для принципиально разных вещей и это названо логичным и понятным? Хорошо, да. Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».
А почему язык программирования обязан быть неестественным?
Не обязан (но фактически должен по многим причинам), но естественным не является.
А это стало быть похвала и восхищения
Это ни похвала, ни осуждение. Это сомнение в утверждении, что именно данный подход логичен и хорош.
А почему язык программирования обязан быть неестественным?
Потому что все языки программирования, даже такие лингвистически продвинутые как Perl, являются выражением математических абстракций. А живые языки от математики крайне далеки.
Поэтому ни один язык программирования естественным языком общения между людьми быть не может. А живые языки только-только начинают использоваться для общения с компьютерами, на совершенно базовом уровне. И это после 70 лет развития, ага.
Потому что все языки программирования, даже такие лингвистически продвинутые как Perl, являются выражением математических абстракций. А живые языки от математики крайне далеки.
Это объяснение, почему так есть, а не почему так должно быть.
лингвистически продвинутые как Perl
Ну то есть лингвистически продвинутый перл — это хорошо, а лингвистически гибкое поведение оператора in в питоне — это плохо? Или что плохо, а что хорошо? Я запутался.
Конечно вы запутались, ведь вопрос звучал так:
А почему язык программирования обязан быть неестественным?
И никаких хорошо и плохо в связи с ним не было.
Вы спросили, почему in (и другие операторы в языках) должен применяться по-разному в зависимости от контекста, если это нелогично и плохо? Дословно так «Ну, и что? Это логично? Это хорошо?». Только не надо соскакивать, делая вид, что этот вопрос был не риторическим.
Я в ответ спросил, что в этом плохого, если в русском языке нас это не смущает.
На что вы спросили, почему же мы сравниваем естественный язык с языком программирования.
После чего я спросил, почему ЯП обязан быть неестественным.
Поэтому далее вы либо отвечаете, почему же он все таки обязан быть неестественным, либо поднимаетесь по стеку, отвечая на мой предыдущий вопрос. Поднявшись к верхушке, мы установим истину.
Поэтому далее вы либо отвечаете, почему же он все таки обязан быть неестественным.
Я уже ответил на этот самый вопрос, но вам же это не интересно.
Раз это ваш окончательный ответ, поднимитесь по стеку и ответьте на предыдущий вопрос. Давайте я помогу наводящими вопросами: раз мы выяснили, что язык не обязан быть неестественным, то что плохого в попытках в каких-то местах приблизить его к естественному? Например поведение оператора, зависящее от ближайшего (на этой же строке) контекста.
Не надо только соскакивать, делая вид, что вы не давали отрицательную оценку, и якобы это я начал рассуждать «хорошо-плохо».
Это объяснение, почему так есть, а не почему так должно быть.
Это объяснение, почему так было, есть и будет. Языки программирования никогда не будут использоваться для общения между людьми, а вот машины вполне возможно что и начнут понимать живые языки достаточно хорошо. Что опять же не сделает ни один живой язык близким к языку программирования, это ортогонально противоположные вещи.
Или что плохо, а что хорошо? Я запутался.
Попробуйте не думать в терминах "хорошо-плохо", лучше "нравится-не нравится". Perl старается быть ближе к живому языку, поддерживая многозначительность и TIMTOWTDI. Python такой подход отвергает и требует однозначности.
Что из этого хорошо? Что плохо? Да всё фигня, если честно. Выбирайте что нравится и не страдайте.
Уровень языка и отражает положение этой точки интерфейса между человеком и машиной. У низкоуровневых языков этот интерфейс ближе к машине, у высокоуровневых — ближе к человеку. Поэтому в высокоуровневых языках программист не заботится о выделении памяти, переключениях контекста, системных вызовах, блокировках (опустим момент, что хороший программист всегда должен это держать в голове).
Поэтому, нет, это ответ, почему так есть, а не почему так должно быть. Я не говорю, что все языки должны внезапно начать понимать человеческую речь, но какие-то определенные высокоуровневые языки в будущем могут себе это позволить.
Попробуйте не думать в терминах «хорошо-плохо»
Направление хорошо-плохо задал наш оппонент dionys где-то еще очень очень сверху:
Первый коммент:
Кажется, я не верно понимаю смысл слов «хорошо» и «понятно».Второй коммент:
Ну, и что? Это логично? Это хорошо?
Если бы он просто сказал «мне так не нравится», я бы не вмешался.
Язык программирования обязан быть формальным, а это очень неестесственно.
в питоне он и так и так используется
Как, впрочем, и в яваскрипте :-)
Что?
var a = [5, 6, 7];
5 in a; // false
1 in a; // true
Вас что смущает-то?
Это не проверка наличия элемента в массиве, а проверка существования индекса.
Нет, это проверка наличия ключа в списке ключей переданного словаря.
'0' in a // true
'length' in a // true
Без разницы, это в любом случае не проверка наличия элемента в массиве.
А никто не обещал проверку наличия элементов в массиве.
Вы написали, что в JS этот оператор работает так же, как и в Python. В статье утверждается, что там он используется для проверки наличия элемента в массиве.
Я такого не писал. Не фантазируйте. В яваскрипте как и в питоне он используется и так и сяк. Со своими особенностями в каждом языке. В яваскрипте, например, долгое время не было массивов как таковых, да и сейчас те, что есть, исключительно числовые.
Давайте освежим вашу память:
dionys: […] в JavaScriptin
используется для итерации по свойствам объекта, а Python почему-то для проверки наличия элемента в массиве […]
worldmind: в питоне он и так и так используется
vintage: Как, впрочем, и в яваскрипте :-)
Может прекратите выкручиваться? Вам уже сказали, что в обоих языках этот оператор используется в разных (однако весьма родственных) значениях: для итерирования по коллекции и для проверки вхождения в эту коллекцию. Всё различите между яваскриптом и питоном в том, что в питоне он может быть применён и к словарям и к массивам, а в яваскрипте только к словарям, так как массивов там попросту нет. Так что ваше противопоставление — полнейшая глупость.
а разве количество способов это какое-то преимущество?
особенно если среди них ни одного логичного (len/length/size)?
Странно, что вы ещё не упомянули, что у вас в глазах рябит от знаков препинания.
length(@arr), @arr.length
).Да, в перле есть понятие контекста, но из него нельзя вывести объяснение почему массив в скалярном контексте возвращает его размер.
А почему бы не возвращать исключение? Ведь массив это не скаляр, это неопределённое поведение.
А может надо возвращать не размер, а последний индекс?
А может надо выдирать первый элемент (как делает shift), ведь в перле список в скалярном контексте возвращает один элемент (правда последний), и это хоть как-то можно понять, раз я требую скаляр от массива, то наверно я хочу извлечь элемент, логично?
Нет, это не логично т.е. это никаким образом не вытекает из логики языка.
Логично и вполне вытекает, если чуть-чуть подумать.
Да, в перле есть понятие контекста, но из него нельзя вывести объяснение почему массив в скалярном контексте возвращает его размер.
Потому что DWIM. Какая самая распространённая операция работы с массивом после взятия элемента по индексу? Вот именно, взятие размера.
А может надо возвращать не размер, а последний индекс?
Последний индекс вообще ни о чём не говорит в случае, когда массив разрозненный. А вот размер это всегда количество элементов, вне зависимости от индексов.
А может надо выдирать первый элемент (как делает shift), ведь в перле список в скалярном контексте возвращает один элемент (правда последний), и это хоть как-то можно понять, раз я требую скаляр от массива, то наверно я хочу извлечь элемент, логично?
Нет, не логично. Между массивами и списками есть разница, и весьма большая. Например, список не имеет индексов и вы не можете извлечь произвольный элемент. Работа со списком идёт только перебором элементов. Разворачивание списка в скалярном контексте даст последний элемент именно потому, что перебор закончился на последнем элементе.
Оператор shift мутирует список или массив, приведение к скаляру этого не делает. Понимаете разницу?
Да, это особенности языка, да, их нужно понимать. Если лично вам эти особенности не нравятся, это не делает их плохими или бесполезными. :)
не очень понял причём тут этот принцип, разверните если не трудно
> Какая самая распространённая операция работы с массивом после взятия элемента по индексу? Вот именно, взятие размера.
В си? Наверное, а в перле зачем нужен размер?
for my $element (@array) {...}
Ну и даже если она частая, при чём тут скалярный контекст? Все частые операции нужно делать в скалярном контексте?
> Оператор shift мутирует список или массив, приведение к скаляру этого не делает. Понимаете разницу?
конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?
конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?
Потому что это проверка значения. Представьте, что при каждой проверке значения переменной это значение меняется.
Хотя я не утверждаю что массив в скалярном контексте должен меняться, я говорю что есть много столь же «логичных» вариантов поведения, можно например возвращать истину если массив не пуст. Да и последний индекс ничем не хуже размера.
Внезапно, мы так и делаем.
Хотя я не утверждаю что массив в скалярном контексте должен меняться, я говорю что есть много столь же «логичных» вариантов поведения,
Вы притягиваете за уши аргументы для подтверждения своей правоты, вот и всё.
Я уже вам советовал: перестаньте, это бессмысленно и бесполезно.
не очень понял причём тут этот принцип, разверните если не трудно
Do What I Mean. Если есть несколько вариантов действия, выбираем наиболее естественный. В данном случае приведение массива к скаляру может давать то или другое значение; Ларри посчитал, что логично будет возвращать размер массива. Я с ним согласен.
Или вот обратный пример: scalar(%foo)
. Я уже не помню, что за белиберду это вернёт, никогда не пользуюсь. С другой стороны, приведение хэша к скаляру вообще смысла не имеет, поэтому логичных вариантов просто нет.
В си? Наверное, а в перле зачем нужен размер?
Затем, что итерацию по массиву можно делать по-разному. Иногда нужно знать текущий индекс, чего foreach
не даст. Или итерацию надо делать с хвоста к голове и мутировать массив по ходу дела. Или итерировать по N смежным массивам одновременно. Или просто показывать пользователю индикатор прогресса. Много для чего, в общем.
Ну и даже если она частая, при чём тут скалярный контекст? Все частые операции нужно делать в скалярном контексте?
конечно я понимаю разницу, я не понимаю почему скалярный контекст не может мутировать массив? Есть какой-то вселенский запрет на это?
Вы мне сейчас напоминаете капризного ребёнка, который уже понял, что неправ, но продолжает капризничать из вредности. У меня таких трое. :)
> Нет.
да, достаточно сравнить с тем, что поменяли разработчики питона когда делали питон 3 без обратной совместимости, т.е. у них была возможность поменять что угодно, но они изменили очень мало, а перл 6 это совсем другой язык
а причём тут именованные буферы? именованный захват тоже кладётся в глобальную переменную, если вы вдруг не в курсе
да, это некая, весьма запоздалая попытка решения и та в 5.20 ещё ругается что она experimental, не знаю как на более новых версиях
вот так выглядит код — YourCompany::Model::Project
> Это проблема языка?
да, дата это вполне стандартный тип и язык должен предоставлять в комплекте лучшую библиотеку для работы с этим типом, а не предлагать перебирать миллион вариантов на cpan
во-вторых, да, си не очень хороший язык, не случайно его пытаются заменить на всякие го и расты
тот же Time::Piece
Правда? Вы мне такую библиотеку для JavaScript покажите. Чтобы одна, и хорошая. 21-й век же на дворе.
Хинт: нету и не будет, потому что JavaScript на голову больное и native Date object в нём примерно как граната в руках у пресловутой обезьяны.
А сколько новых проектов пишется на Node.js? А сколько вообще в мире новых не-Web проектов, чтобы без JavaScript обойтись? Казалось бы...
Спасибо, посмотрю на досуге. Авансом даже понадеюсь, что библиотека окажется неплоха.
Хотя общей пичальки это не отменяет: работа с датами в JavaScript сломана навзничь, так же как и многое другое. И это всё называют нашим светлым будущим. :(
> Ханжество.
Вот тут я бы, наверное, поспорил. То, что у большой части перлового синтаксиса корни растут из Bourne и C shell, отрицать было бы просто глупо. А что фичами оброс, так это тоже как бы факт. :)
С моей точки зрения, это вы странный человек. Я написал ровно то, что написал: Perl действительно создавался как замена shell для решения практических задач в те времена, когда Bourne shell был уже дряхл и неудобен, C shell был уже сломан, Korn shell стоил некислых денег, а bash и его клонов ещё не было в природе. И фичами он тоже обрастал постепенно, пока количество не перевалило в качество и не родился Perl 5, который мы все отлично знаем и нежно любим.
Ну и какие выводы вы здесь видите? Я никаких не вижу.
А для более крупных программ надо использовать языки с развитыми системами типов.
Потом к ним пишут миллиард тестов вида "а что если туба будет передана строка, а не число".
Но вот что мне лично очень принципиально, так это процесс установки приложения на новый сервер (deploy).
После более 7 лет разработки на Perl я, волей случая, был вовлечен в разработку на Go и теперь совсем неохотно берусь за задачи, связанные с Perl. Т.к. установка необходимых пакетов в крупных проектах с Perl — целая песня.
Я учавствовал в довольно крупных проектах, в которых Perl был основным языком (а зачастую и единственным), но по прошествию лет я начинаю понимать, что просто выбор был не так велик, как сейчас.
В любом случае, можно относится к Perl по-разному, но уж точно с уважением.
в этом плане rubygems удобнее. а npm с его модулями в модулях — чересчур.
cpanm Plack~">= 1.2, != 1.5, < 2.0"
в этом плане rubygems удобнее
Это больше говорит о качестве кода в пакетах ruby, чем об удобстве пакетного менеджера. Ставить модуль чётко определённой версии, потому что все остальные сломаны, включая не только прошлые, но и последующие? Это совершенно не нормальная ситуация.
Что в общем и не удивляет, если честно. Мой личный процесс познания Ruby обломился на попытке отдебажить SASS компилятор compass и понять, почему же оно такое тормозное. После нескольких часов утомительной пересборки ruby нужной версии (шаг в сторону — расстрел) и попыток заставить профилировщик заработать я понял, почему им никто не пользуется. А потом я таки заставил его заработать и обнаружил, что 30% времени compass тратит на склеивание путей файлов в системной библиотеке, которая написана просто через жопу.
На этом слёзы у меня кончились и желание трогать Ruby тоже. Тем более что парни из соседнего отдела всё равно уже лабали свой SASS компилятор на JavaScript. (facepalm)
Зачем? Есть же быстрая сишная библиотека.
Не знаю, если честно. Они там в соседнем отделе много чего делают, мне непонятного. Но идея избавиться от compass была мне вполне близка, учитывая, что компиляция одной темы демо-приложения могла легко занимать 30-40 секунд, включая старт ruby и все остальные накладки. А новый компилятор гораздо бОльший объём работы делает за ~3 секунды. На порядок быстрее.
Да и дело было года 3 назад, может этой библиотеки не было ещё, или нестабильная была.
Т.к. установка необходимых пакетов в крупных проектах с Perl — целая песня.
Контейнеризация не поможет? Docker и иже с ними.
Очень многим крупным проектам, написанных на Perl, более 10 лет. Чаще в таких проектах разработчики используют VM (со своими накладными расходами).
Я как-то предложил использовать Docker вместо VM, но бизнес, зачастую, так устроен, что если что-то приносит деньги, то этот процесс очень неохотно разрешают менять.
бизнесы, которы процветают с Perl, как говорят, old school.
Не все. Новые проекты тоже вполне бывают. ;)
Я как-то предложил использовать Docker вместо VM, но бизнес, зачастую, так устроен, что если что-то приносит деньги, то этот процесс очень неохотно разрешают менять.
В случае использования отдельных VM отказ вполне понятен и оправдан — проблем с установкой пакетов в контролируемой среде и так нет, а если ресурсы не жмут, то менять шило на мыло смысла нет.
Вот написал и задумался, а так ли нет проблем. Можете привести примеры ситуаций, когда перловые пакеты стали бы головной болью в контролируемой VM? Интересно.
Лично мои претензии к перлу:
Отсутствие нормального пакетного менеджера (установки завистимосей из git практически нет)
Отсутствие некоторых нормальных фреймворков (Mojolicious далеко позади современных веб фреймворков на других языках) и библиотек (с тех же дат я долго мучался до обнаружения Date::Simple), нет нормальной ORM
Ужасная документация у (почти) всего что не core modules
Concurrency — форки не всегда то, что нужно
Carp или аналоги — отдельные модули, а не инструмент языка
UTF-8
ООП — никто не заставляет его использовать, но почему-то все это делают, и с ним всё здесь плохо. В помощь и в зависимости проекта нам приходит весь огород модулей для этого (Moose, Mouse, Moo… и 100 других)
Сборка CPAN модулей, cpan её не умеет, приходится использовать Minilla, Dist::Zilla и прочее, а нужно просто иметь возможность поставить cpanm'ом модуль, который вот он уже, вроде, готовый.
Да и сам CPAN иногда кажется помойкой, приходится долго искать и смотреть на модули, прежде чем выбрать что-то подходящее, на metacpan есть рейтинг, но не всегда он показателен, пакеты именует кто как хочет.
Отсутствие нормального пакетного менеджера (установки завистимосей из git практически нет)
cpanm git://github.com/plack/Plack.git
И даже так
cpanm git://github.com/plack/Plack.git@0.1
Ух ты! Даже так! Век живи, век учись. Спасибо большое, товарищ. :)
Да, так это работает, но при сборке проекта начинаются неудобства, мы не можем добавить всё в один cpanfile.
Плюс отсутствует возможность добавить гит зависимость в устанавливаемый модуль.
А Миягава только обещает добавить поддержку, но сейчас он пилит carmel и там про гит тоже ничего не понятно.
(https://github.com/miyagawa/cpanminus/issues/381 и, на сколько я знаю, ситуация не поменялась.)
Сейчас я вижу 2 возможности обойти это
1) Скрипт, который отдельно устанавливает гитовые зависимости
2) Поднять свой приватный цпан, приватный бэкпан и всё остальное
В итоге пришел ко второму способу, и это упростило некоторые вещи.
Но можно было бы этого не делать.
Или свой cpanm. :)
У нас такой, с этим PR
https://github.com/miyagawa/cpanminus/pull/490
По факту, всё-равно перешли на деб-пакеты.
Это вы рекламироваться пытаетесь таким извращённым образом, или просто самоутверждаетесь? В первом случае могу пожать плечами, в последнем сочувственно похлопать по плечу опять же. Трудно это, проснуться однажды тёплым весенним утром и понять что вот всё — таки не в сказку попал. Жизнь == боль.
Не хотите программировать на Perl, не программируйте. Зачем такой надрыв? А главное, кому какое дело? :)
Если у вас просто накопились наблюдения, то с чего такая драма? Вас кто-то принуждает писать на Perl? Ну так плюньте им в лицо и пишите на том, что нравится.
В любом случае вы опоздали, пинать Perl уже давным-давно не модно и кармы особо не прибавит. :)
Карма меня не особо интересует, да и о прибавлении речь не идёт — пост еле из минусов выбрался, а карму даже чуток подуменьшили.
Я бы хотел сказать о своих личных наблюдениях, которые привели меня к тому, что работать на перле я пойду только в крайнем случае, несмотря на то, что этой мой основной язык.
Кто-то может сказать, что это мелочи, мол можно привыкнуть и писать рабочий код, да, я долгое время писал, но со временем понимаешь, что нет никаких причин привыкать к плохому, надо выбирать лучшие решения, а не какие-нибудь.
Это ли не шекспировские страсти? :)
А про карму я в переносном смысле. Эти местечковые извращения с плюсиками и минусиками мне всегда смешны были. :) Есть что сказать — скажи, а нажать минусик это типа крикнуть "ты дурак!" в ответ. В детском саду весело было, потом как-то надоело. :))
ну это просто текст, каждый эмоциональную составляющую видит по своему, но наверно да, накипело чуток )
накипело чуток )
Так вот я и говорю: если накипело, то плюнье слюной и не трогайте больше. Нравится вам Python? Ну так и признайтесь себе честно, что он вам больше нравится, чем Perl, и не придумывайте другие оправдания. Просто пишите на Python, за чем дело стало. :)
Другое дело, когда выбора нет. Мне, скажем, JavaScript уже костью поперёк горла стоит. Но деваться некуда, в браузерах больше ничего нет. И за жабы скрипт масса даёт много сладкий батат, поэтому приходится затыкаться и лабать дальше. :)
«Нормальные» языки давно транслируются в JS, но что-то ни к чему это пока не привело.
Угу, со всеми втекающими и вытекающими типа отладки по source maps, пачке Беломора и известной матери. Спасибо, не надо.
Тем более, что открытие доступа к DOM из WebAssembly в ближайшем будущем не предвидится, а без этого толку от WebAssembly чуть менее, чем ноль.
Так что, мыши плачут и колются, а белый масса щёлкает кнутом. :)
Все написано исключительно на Perl, к этому приложили руки очень опытные сотрудники, многие из которых, к моему сожалению, перешли работать в довольно известные компании. Всего за это время через нас прошло более десятка программистов Perl, и мы постоянно готовим для себя новых.
Да, как и у всякого сложного проекта с бородатой историей, у нас накопился технический долг, и мы постепенно обновляем архитектуру сервиса, как служебных систем, так и собственно интернет-магазинов.
И несмотря на это, все что написано, работает на удивление стабильно и надежно. Собственно, в свое время я именно по этой причине и выбрал Perl для реализации проекта. Я считаю, что для интернет-магазинов самое главное — надежность работы, т.к. от нее зависит прибыль предпринимателей. Новые технологии могут выстрелить, а могут и нет.
Например, в одном большом магазине мы использовали кластер MongoDB, и при количестве записей порядка 15 млн. и очень интенсивной нагрузке возникли проблемы, хотя при меньших размерах базы все работало хорошо.
Сейчас для нас не стоит вопрос переписывания систем на других языках.
Во-первых, это нецелесообразно экономически и не принесет никаких особых дивидендов.
Во-вторых, в других языках, а главное, в окружении других языков тоже есть свои проблемы.
В-третьих, если что-то лучше реализуется на других языках, почему бы не сделать подсистему в виде сервиса на чем-то еще? Например, на Питоне есть хорошие библиотеки для работы с нейронными сетями, ну и можно выделить эту часть в отдельный сервис.
это мало связано с ЯП, это вопрос квалификации разработчиков, архитектуры проекта
ну возможно у вас грамотное руководство и вы не только набираете но и удерживаете достаточное число квалифицированных сотрудников, но компании с чуток менее продуманным подходом давно страдают от дефицита перловиков, который вполне может отразится на доходах.
Проблемы с кадрами есть, но ищем, стараемся. И сами готовим, да.
Перл выучить недолго, долго стать хорошим программистом.
Есть технологии для подключения плагинов к магазинам, не волшебные, но работают.
Тестами покрыто не все, но для самых важных модулей тесты составляются. Ядро магазинов почти все покрыто тестами. А при загрузке модулей в Перловку автоматически запускаются тесты для модулей, если они завершаются с ошибкой — загрузка отвергается.
Вообще конечно как язык лично мне больше всего нравится C#, но Microsoft с его ценами — это не наш вариант)
Еще используем активно GitLab, очень помогает. Держим там такие проекты, как магазины, внутренние сервисы и подсистемы.
IMHO, потока новичков в перле не наблюдаются, старичков бы выловить по одному :-)
На предыдущей работе познакомился с другой практикой: нанимают толковых людей, которые могут не знать Perl, но готовы учиться. Такой подход неплохо работает.
При выборе платформы для проекта приходится учитывать очень много факторов. Опять же, я выбирал более 10 лет назад, и у нас не было, и до сих пор нет каких-то уж совсем ужасных проблем с Perl. Так что свой давнишний выбор я считаю удачным.
А что бы я выбирал сейчас начиная подобный бизнес — это сложный вопрос. Может, сейчас я бы занялся другим ИТ-бизнесом, интернетом вещей, например) И критерии для выбора платформы были бы совершенно другими.
Я намеренно говорю не про язык программирования, а про платформу в более широком смысле. Т.к. выбором языка дело в сложном проекте не ограничивается обычно.
Других приходится либо обучать, либо при невозможности обучения — увольнять, а запутанный код — переписывать. Обычно у нас так бывает с некоторыми студентами. Разбираться в зашифрованном коде себе дороже, как правило, в нем еще и полно ошибок.
На каком языке, по-вашему, писать нечитаемый код значительно сложнее, чем на Perl?
Писавший это, особенно третий фрагмент, был новичком, восхитился наличием map, ему показалось, что это красиво и изящно…
Кстати, а как вы предлагаете решать задачу из второго фрагмента? Если не подготавливать аналогичным образом N плейсхолдеров.
Но даже на html можно написать говнокод, а можно включить межушный нервный узел…
Насчет новичков, как я уже говорил, мы подготовили более чем за 10 лет работы десятки программистов Perl, обучая студентов. Многие из них, как я уже говорил, к сожалению, ушли от нас в известные ИТ-компании, где продолжают программировать на Perl.
Так что если старичков не хватает, мы смело готовим новичков)
Почему я больше не хочу програмировать на Perl