Как стать автором
Обновить

Комментарии 227

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

Глобальные переменные, в которые регулярки записывают разультаты — жутко удобные, так как экономят объём кода и делают поэтому его более читабельным, а программиста — более продуктивным. Ну и опытному программисту на 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 - вот и всё )

Для меня это было так давно, никаких тестов не найду.

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

Живее всех живых: уже 6 лет им пользуюсь довольно регулярно )

https://stackoverflow.com/questions/16927024/perl-5-20-and-the-fate-of-smart-matching-and-given-when да, похоже пометили experimental и могут не удалить, а изменить.

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

Кроме Brainfuck)

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

Нет.

> язык создавался как замена 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 есть проблемы, но перечисленное вами — это не проблемы, а ханжество и вкусовщина.
Я не очень понимаю, как вы росчерком пера отделили даты от календаря, и сделали их несвязанными сущностями. Из вашей рассылки — «дата — это число единиц времени с начала отсчёта» — это же совершенно неверно. Число единиц времени — это число, а дата — это дата)

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

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

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

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


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

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

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

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


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

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

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


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

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

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

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


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


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

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

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

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

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


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


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

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

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


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

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

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

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

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

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

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

> 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 такой подход отвергает и требует однозначности.


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

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

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

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

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

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

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

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

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

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

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

Что?


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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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


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

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


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

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


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

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


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


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

> Потому что DWIM

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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

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


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

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

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

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

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

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

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

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

да, это некая, весьма запоздалая попытка решения и та в 5.20 ещё ругается что она experimental, не знаю как на более новых версиях
Перл он такой, можно сделать почти всё (жаль инфиксные операторы нельзя), но это будет какой-то свой кастомный перл, а хорошая технология по умолчанию предлагает хорошие решения.
Суть в том, что Perl

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

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

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

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

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


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


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

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


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

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

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

> Ханжество.

Вот тут я бы, наверное, поспорил. То, что у большой части перлового синтаксиса корни растут из Bourne и C shell, отрицать было бы просто глупо. А что фичами оброс, так это тоже как бы факт. :)
Вот странные вы люди. Кто бы спорил с фактами, но делать на их основе далеко идущие выводы… Perl — замена шеллу с регекспами, Java — язык для умных кофеварок и стиральных машин, что там, да, php — недоязычок для гостевых книг, js — недоязычок для моргающих строк на веб-странице.

С моей точки зрения, это вы странный человек. Я написал ровно то, что написал: Perl действительно создавался как замена shell для решения практических задач в те времена, когда Bourne shell был уже дряхл и неудобен, C shell был уже сломан, Korn shell стоил некислых денег, а bash и его клонов ещё не было в природе. И фичами он тоже обрастал постепенно, пока количество не перевалило в качество и не родился Perl 5, который мы все отлично знаем и нежно любим.


Ну и какие выводы вы здесь видите? Я никаких не вижу.

Выводы сделал автор. «Раз perl — это sh с регекспами, то это и есть sh с регекспами, недоязычок, писать на котором просто несерьёзно». Именно это я назвал ханжеством.
Perl очень хорош для коротких программ, а пределах пары экранов. Или вообще однострочников, скажем запускаемых из vim.
А для более крупных программ надо использовать языки с развитыми системами типов.
А мужики-то не знают, и пишут на скриптовых языках миллионы строк кода…

Потом к ним пишут миллиард тестов вида "а что если туба будет передана строка, а не число".

Ройт, а в Правильных Языках поцоны могут не гадать, что будет, а использовать соответствующие операторы и точно знать заранее безо всякой кофейной гущи.

Здесь вам тут не жаваскрипт. ;)
Ну от сюда и такое количество глючного труднополлерживаемого софта.
Если многие недостатки Perl можно причесать, как, например, непонятный синтаксис можно сделать довольно строгим при наличии процесса code review (т.к., действительно, если бросить это на самотек, то будет как в мультфильме «Простоквашино», когда они письмо писали). Что в будущем определит легкость/трудность в поддержке кода.
Но вот что мне лично очень принципиально, так это процесс установки приложения на новый сервер (deploy).
После более 7 лет разработки на Perl я, волей случая, был вовлечен в разработку на Go и теперь совсем неохотно берусь за задачи, связанные с Perl. Т.к. установка необходимых пакетов в крупных проектах с Perl — целая песня.
Я учавствовал в довольно крупных проектах, в которых Perl был основным языком (а зачастую и единственным), но по прошествию лет я начинаю понимать, что просто выбор был не так велик, как сейчас.
В любом случае, можно относится к Perl по-разному, но уж точно с уважением.
Я очень давно не писал на Perl (кроме однострочников), но когда писал мне очень нравился его пакетный менеджер. Сейчас пишу на Scala и меня очень расстраивает необходимость следить за версиями зависимостей в разных проектах.
Я люблю Perl, но пакетный менеджер у него не очень — неудобно сказать — ставь мне модуль версии 1.8.x, но не включая 1.8.4, точно не используя 1.7.x или 1.9.x, и не младше 1.8.1.

в этом плане 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 назад, может этой библиотеки не было ещё, или нестабильная была.

Была. Мы её под нодой использовали. Работала очень шустро. Потом пересели на более нативный для ноды и фичастый stylus.

Т.к. установка необходимых пакетов в крупных проектах с Perl — целая песня.

Контейнеризация не поможет? Docker и иже с ними.

Docker довольно молодая технология, а бизнесы, которы процветают с Perl, как говорят, old school.
Очень многим крупным проектам, написанных на Perl, более 10 лет. Чаще в таких проектах разработчики используют VM (со своими накладными расходами).
Я как-то предложил использовать Docker вместо VM, но бизнес, зачастую, так устроен, что если что-то приносит деньги, то этот процесс очень неохотно разрешают менять.
бизнесы, которы процветают с Perl, как говорят, old school.

Не все. Новые проекты тоже вполне бывают. ;)


Я как-то предложил использовать Docker вместо VM, но бизнес, зачастую, так устроен, что если что-то приносит деньги, то этот процесс очень неохотно разрешают менять.

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


Вот написал и задумался, а так ли нет проблем. Можете привести примеры ситуаций, когда перловые пакеты стали бы головной болью в контролируемой VM? Интересно.

Оказывается, кто то ещё по собственной воле пишет на perl
язык позволяет очень многое, и платят хорошо.
Хочется
Ещё больше
Любить
Перл
Да писать то на нем одно удовольствие. Вот читать потом — не всегда.
И с удовольствием! )))

Только самые мудрые. Таких всегда мало. :)

Лично мои претензии к перлу:
Отсутствие нормального пакетного менеджера (установки завистимосей из 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


По факту, всё-равно перешли на деб-пакеты.

Или свой cpanm. :(
Деб или rpm, в целом, тоже звучит не очень хорошо.

Это вы рекламироваться пытаетесь таким извращённым образом, или просто самоутверждаетесь? В первом случае могу пожать плечами, в последнем сочувственно похлопать по плечу опять же. Трудно это, проснуться однажды тёплым весенним утром и понять что вот всё — таки не в сказку попал. Жизнь == боль.


Не хотите программировать на Perl, не программируйте. Зачем такой надрыв? А главное, кому какое дело? :)

Просто накопились наблюдения, решил вдруг кому интересно.

Если у вас просто накопились наблюдения, то с чего такая драма? Вас кто-то принуждает писать на Perl? Ну так плюньте им в лицо и пишите на том, что нравится.


В любом случае вы опоздали, пинать Perl уже давным-давно не модно и кармы особо не прибавит. :)

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

Это ли не шекспировские страсти? :)


А про карму я в переносном смысле. Эти местечковые извращения с плюсиками и минусиками мне всегда смешны были. :) Есть что сказать — скажи, а нажать минусик это типа крикнуть "ты дурак!" в ответ. В детском саду весело было, потом как-то надоело. :))

> Это ли не шекспировские страсти? :)

ну это просто текст, каждый эмоциональную составляющую видит по своему, но наверно да, накипело чуток )
накипело чуток )

Так вот я и говорю: если накипело, то плюнье слюной и не трогайте больше. Нравится вам Python? Ну так и признайтесь себе честно, что он вам больше нравится, чем Perl, и не придумывайте другие оправдания. Просто пишите на Python, за чем дело стало. :)


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

Я надеюсь что внедрение WebAssemby в браузеры приведёт к тому что нормальные языки типа питона научатся в него компилироваться.

«Нормальные» языки давно транслируются в JS, но что-то ни к чему это пока не привело.

но я надеюсь

Угу, со всеми втекающими и вытекающими типа отладки по source maps, пачке Беломора и известной матери. Спасибо, не надо.


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


Так что, мыши плачут и колются, а белый масса щёлкает кнутом. :)

Уже более 10 лет наша компания пишет на Perl сервис интернет-магазинов. Там есть свой биллинг, своя учетная система, система обработки заявок клиентов, свой деплой новых версий ядра и модулей магазинов на серверы, свой аналог CPAN (называем Перловкой) с возможностью установки модулей Перла на наши серверы, MailProxy — система рассылок почты с общей очередью и фильтрацией невалидных адресов получателей, база знаний Клондайк, модули мониторинга для Zabbix, да и много еще чего.

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

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

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

Например, в одном большом магазине мы использовали кластер MongoDB, и при количестве записей порядка 15 млн. и очень интенсивной нагрузке возникли проблемы, хотя при меньших размерах базы все работало хорошо.

Сейчас для нас не стоит вопрос переписывания систем на других языках.

Во-первых, это нецелесообразно экономически и не принесет никаких особых дивидендов.
Во-вторых, в других языках, а главное, в окружении других языков тоже есть свои проблемы.
В-третьих, если что-то лучше реализуется на других языках, почему бы не сделать подсистему в виде сервиса на чем-то еще? Например, на Питоне есть хорошие библиотеки для работы с нейронными сетями, ну и можно выделить эту часть в отдельный сервис.
> И несмотря на это, все что написано, работает на удивление стабильно и надежно

это мало связано с ЯП, это вопрос квалификации разработчиков, архитектуры проекта
Во многом да, но платформа тоже имеет значение. В свое время отказался от PHP из-за отсутствия обратной совместимости, отсутствия единого репозитория, такого как CPAN, наличие уязвимостей, особенно в разных CMS, да и самим языком остался недоволен. Но другие используют PHP, и ничего)
> Сейчас для нас не стоит вопрос переписывания систем на других языках.

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

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

P.S. мне кажется удачная аналогия подобралась прямо сейчас
Похвастайте и ссылкой на ваш сервис
Спасибо.

Если не секрет, поделитесь опытом, какое ООП вы используете — штатное или батарейки? Тот же вопрос про систему обработки исключений и юниттесты.
Все ООП пишем руками, да. На некоторых проектах подключаем внешние модули для имитации try-catch, а так все больше eval. При возникновении проблем, ошибок, исключений, попыток взлома — админу идут письма. Видим, что больше всего пытаются сломать так, как будто у нас PHP. Также непрерывно пробуют инъекции.
Есть технологии для подключения плагинов к магазинам, не волшебные, но работают.

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

Вообще конечно как язык лично мне больше всего нравится C#, но Microsoft с его ценами — это не наш вариант)
Вы используете какой-то стайл-гайд?
Да, у нас есть корпоративное руководство по стилю, выдаем всем новичкам. Стараемся, чтобы по коду нельзя было понять, кто из программистов писал тот или иной модуль) Все равно читать придется потом другим программистам. Но, конечно, в старых проектах встречается всякое, и ужасы тоже бывают. По возможности постепенно рефакторим.

Еще используем активно GitLab, очень помогает. Держим там такие проекты, как магазины, внутренние сервисы и подсистемы.
НЛО прилетело и опубликовало эту надпись здесь
IMHO, потока новичков в перле не наблюдаются, старичков бы выловить по одному :-)

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

Да, вот и мы так делаем. Perl выучить легко, хватит пары недель для действительного хорошего программиста. А тех, кто раньше вообще ни на чем не программировал и ничего интересного не создал, брать не можем — слишком велики затраты на обучение и риск, что ничего не получится. Хотя в самом начале работы нашей компании я брал и таких.
НЛО прилетело и опубликовало эту надпись здесь
Это во многом зависит от программиста. В свое время мне рассказывали об исходниках на Паскале, выровненных по 8 колонке — работа бывшего программиста на Фортране) Т.е. на любом языке можно писать ужасный код.

При выборе платформы для проекта приходится учитывать очень много факторов. Опять же, я выбирал более 10 лет назад, и у нас не было, и до сих пор нет каких-то уж совсем ужасных проблем с Perl. Так что свой давнишний выбор я считаю удачным.

А что бы я выбирал сейчас начиная подобный бизнес — это сложный вопрос. Может, сейчас я бы занялся другим ИТ-бизнесом, интернетом вещей, например) И критерии для выбора платформы были бы совершенно другими.

Я намеренно говорю не про язык программирования, а про платформу в более широком смысле. Т.к. выбором языка дело в сложном проекте не ограничивается обычно.
НЛО прилетело и опубликовало эту надпись здесь
Конечно! Но тем и выделяются опытные программисты, что они на любом языке смогут написать понятно, если понимают, что участвуют в коллективной разработке, а не пишут что-то только для себя. И наличие корпоративного стиля, а главное, следование ему упрощает жизнь всем.

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

На каком языке, по-вашему, писать нечитаемый код значительно сложнее, чем на Perl?
НЛО прилетело и опубликовало эту надпись здесь
В любом языке есть выбор. Даже в ассемблере. Везде, где есть выбор, его можно сделать неправильно. Perl — мощный инструмент, позволяет с прямыми руками сделать многое — да, при попадании в кривые руки он превращает ноги в огнестрельные щупальца.
Писавший это, особенно третий фрагмент, был новичком, восхитился наличием map, ему показалось, что это красиво и изящно…
Кстати, а как вы предлагаете решать задачу из второго фрагмента? Если не подготавливать аналогичным образом N плейсхолдеров.
НЛО прилетело и опубликовало эту надпись здесь
Ну не знал человек про ANY. Я вот тоже умудрился пропустить, хотя я плотно с постгресом очень давно работал.
НЛО прилетело и опубликовало эту надпись здесь
Я уверен, даже в IBM BASIC можно выстрелить себе в ногу. И уж тем более, в любом из современных сложных языков.
НЛО прилетело и опубликовало эту надпись здесь
Так опять же, везде есть хорошие практики. Но для них требуется некоторый опыт, ну и чутьё. Я сам работаю сейчас с легаси-кодом, там много интересных инженерно-технических решений применено, и выборка десяти колонок из БД в массив — далеко не самое страшное, самое страшное — это «интересное» понимание бизнес-процессов.
Но даже на html можно написать говнокод, а можно включить межушный нервный узел…
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Похоже, да. По передаче параметров ничего особенно строго нет. В зависимости от контекста передаем либо списком, либо хешом.

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

Так что если старичков не хватает, мы смело готовим новичков)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории