Сегодня на запрос по ключевому слову «perl»:
Почему же так? Почему никто не хочет писать на perl’е? На этом прекрасном языке, где код творится как поэзия, где каждая строка пропитана творческим виденьем мира её автора!
Неужели виной всему чума, которую так сильно распространяет выкидыш PHP?
Похоже, что никто не разделяет горя по поводу отсутствия работы на Perl’е...
“И снова здравствуйте”:
jobs.dou.ua/...s/portaone/vacancies/699
На этом прекрасном языке, где код творится как поэзияРазве только как поэзия вогонов.
На PHP пишешь, да ?
искренний вопрос:
когда-то писал по мелочи на perl. сейчас по мелочи на php.
не вижу между ними принципиальной разницы.
Не посылая в гугл, к большим сравнительным обзорам, ваше мнение в пару абзацев:
чем же плох php в сравнении с perl. именно — субъективно, а не сравнения грамматик и фич языков.
что именно воротит в php опытного perloвика?
PHP в сравнении с Perl’ом — это будто недоделанный язык, который по-быстрому склепали на коленке, абы работало. В то время как Perl вылизан до мелочей, все можно написать с наименьшими затратами усилий. Perl как старый друг, он понимает с полуслова, но всегда вовремя остановит тебя, если попросить.
PHP в сравнении с Perl’ом — это будто недоделанный языкэтого я и не понял. для меня они одинаково -тяп-ляп сделанные языки.
те отличия что описаны в этой теме — мелочи, а не важные отличия. имхо, ессно.
вот и интересно, что же такого притягательного в perl в сравнении с php...
ну кроме «старый друг» :)
Вопрос был о субъективной точке зрения не привязанной к фичам языка — так и постарался ответить.
Говорить о чем-то конкретном — нет смысла, потому что это всегда приводит к холиварам и перекидыванием взаимными комплиментами. Ведь на сравнение всех преимуществ уйдет бесконечное количество времени, так как создаются они быстрее, чем необходимо на их описание, а указать только часть — значит оставить пространство для спора.
ну, из того читал, Perl 6 да, на порядок мощнее php. где-то как Scala и Java :) по моим субъективным ощущениям.
ниже Valentin Nechayev дал хорошую ссылку. почитаю на досуге.
просто я слышу с самого начала что некий ЯП недоделанный язык
от всех — в адрес Basic и Cobol
от Сишников в адрес классического Паскаля
от Clipper-истов в адрес FoxPro
от всех хором в адрес Perl
когда его сменил PHP — хором теперь в его адрес
от всех не из мира ERP систем — в адрес 1C, MS Dynamics, SAP R/3, ..., ..., то есть ERP систем
от всех не из мира Java — в адрес Java
и т.д.
просто с Perlом, когда он применялся много чаще чем PHP — я помню все те же аргументы в его адрес. Вот и интересно стало — перлушники что выжили теперь поливают так же пых, как когда-то поливался Perl...
Perl, до пришествия PHP, ругали все остальные точно так же, как сейчас PHP
Всё относительно. Грязный рабочий после смены в забое будет чище пожизненного бомжа.
чем же плох php в сравнении с perl.
nuclight.livejournal.com/107170.html можно разбирать на цитаты. Вот немного избранного:
===
* Сортировка:
* PHP: (16)
sort, arsort, asort, krsort, ksort,
natsort, natcasesort, rsort, usort,
array_multisort, uasort, uksort, dbx_sort,
imap_sort, ldap_sort, yaz_sort
* Perl: (1)
sort
* Обработка списков
* PHP: (10)
array_filter, preg_grep, array_search,
array_unique, in_array, array_map, array_walk,
array_count_values, array_change_key_case, array_sum
* Perl: (2)
map, grep
* Разбиение строк:
* PHP: (8)
split, explode, strtok, spliti, chunk_split, mb_split, preg_split,
str_split
* Perl: (1)
split
* Замена подстроки:
* PHP: (12)
ereg_replace, eregi_replace, mb_ereg_replace, mb_eregi_replace,
preg_replace, str_ireplace, str_replace, ltrim, rtrim, trim, nl2br
* Perl: (1)
s///
* Печать/вывод:
* PHP: (14)
print, echo, printf, fprintf, vprintf, dio_write, fwrite, fputs,
gzwrite[2], socket_send, socket_sendmsg, socket_sendto, socket_write,
socket_writev
* Perl: (5)
print, printf, syswrite, send, write
Perl часто обвиняют в том, что он провоцируют на написание несопровождаемых скриптов, в которых трудно разобраться, причем это даже возведено в девиз — однако, с такой кашей функций PHP выглядит куда более соответствующим принципу TIMTOWTDI, т.е. несомненно более худшим в этом отношении.
===
===
Вот, к примеру, массивы в PHP. Многие языки имеют как обычные массивы с числовыми индексами, так и массивы, индексируемые строками (хэши в Perl). PHP комбинирует оба в единый тип. С одной стороны, неопытному программисту не приходится заботиться о лишних типах (как в Бейсике когда-то, ага). С другой стороны — посмотрим на вот такой код:
$a1 = Array(10, ’Anne’ => 32, 11, ’Bob’ => 28, 12);
$a2 = Array(1 => 21, 2 => 22, 3 => 23);
$a2[0] = 20;
Сразу же возникает куча вопросов:
По какому индексу доставать значение 11 из $a1 ?
Каков порядок итерации по $a2 ? Он нумеруемый или хэшируемый?
Что будет, если попытаться добавить элементы в «конец» массива конструкцией $a2[] = ... ?
Могут ли в нумеруемых массивах отсутствовать элементы? А если да, можно ли простым способом пройтись по массиву в порядке индексов?
===
nuclight.livejournal.com/107170.html можно разбирать на цитаты.
Но лучше просто не постить, потому что уровень критики крайне невысокий.
Ну и если уже запостили, то практически то же самое можно повторить про Perl. CPAN — свалка мусора, эволюция вместо дизайна, тяжёлое наследие проекта awk++, пригодность узкоспециализированного языка к разработке «серьёзных приложений» (это мне особенно нравится).
Языки очень близкие на самом деле, с похожей историей и похожими проблемами.
Но лучше просто не постить, потому что уровень критики крайне невысокий.
Подробнее, пожалуйста, чем это он «невысокий».
А про fopen на URL что скажете?
практически то же самое можно повторить про Perl.
Не настолько, в этом и дело. Шкала качества средств неограниченна в обе стороны, но на ней вполне можно объективно отпозиционировать.
Подробнее, пожалуйста, чем это он «невысокий».
1. Непонимание границы между модулем и языком.
egrep*, mb*, preg* — это модули. DBD, mysql_*, всё это реализовано практически одинаково в PHP и в Perl’е.
CPAN, в массе, ещё больший зоопарк чем PHP модули.
2. Выдача альтернативных решений за недостатки.
В PHP global / using и явные имена аргументов.
В Perl my, автозахват переменных уровнем выше и @_.
Два разных подхода. Преимущества и недостатки есть у обоих.
Массивы и хэши, что в PHP, что в Perl, «альтернативные» по сравнению с другими языками (Python, JS, Ruby).
Подобный PHP подход используется в Lua, а вот такого как в Perl наверное нет больше нигде.
3. Пропущены действительно важные проблемы.
PHP это template engine на котором пишут template engines просто чтобы не пользоваться встроенным. Fail. Но об этом ни слова.
А про fopen на URL что скажете?Ничего?
Не настолько, в этом и дело.Ну это субьективно во многом, но я скажем не вижу так принципиальной пропасти между этими двумя языками. Те же яйца, только в профиль.
1. Непонимание границы между модулем и языком.
egrep*, mb*, preg* — это модули.
Это модули стандартной поставки, значит, должны соответствовать разумной общей полиси, и их кривизна — такая же проблема языка, как и чистого core.
DBD, mysql_*, всё это реализовано практически одинаково в PHP и в Perl’е.
То, что я видел — неодинаково. У Perl входной модуль DBI для всех. У Python «утиная типизация» за счёт одинаковых названий основных полей. У PHP — бардак.
PHP это template engine на котором пишут template engines просто чтобы не пользоваться встроенным.
«П-переведи» ©
Ничего?
А почему?
Это модули стандартной поставки, значит, должны соответствовать разумной общей полисиКому должны, лол? One python way это питонизм. У линукса системные вызовы называются как прийдётся, и я промолчу про libc.
У Perl входной модуль DBI для всехУ PHP это называется PDO.
П-переведиПроще показать: laravel.com/docs/5.0/templates, первый пример.
А почему?И не такое видел.
Кому должны, лол? One python way это питонизм.
One python way, очевидно, питонизм. Это тавтология, не требующая доказательства. Но зачем вы ввернули слово «python» перед way?
А в нормальном мире единообразие именования — путь к облегчению запоминания и, как естественное следствие, сокращению ошибок всех видов.
У линукса системные вызовы называются как прийдётся, и я промолчу про libc.
Например?
И, предположим, в libc это не соблюдается. Это причина делать ещё хуже?
Автор не понимает, как PHP грузит модули
По-моему, всё он понимает. Про общее пространство имён, зависимость его от состава подключаемых модулей — написано явно.
Это по сути PHP-дубль-два, написанный на PHP.
И какая доля всех установок на PHP делает такое?
И не такое видел.
То есть там в языке есть и бо́льшие кошмарики? Хочу это увидеть.
Но зачем вы ввернули слово «python» перед way?Питон-комьюнити хорошо постаралось в популяризации идеи.
Например?
open/close/fork/exec/exit — просто глаголы;
mmap/flock/fcntl — без пробелов, объект-префикс;
getuid/getpid/chdir — без пробелов, объект-суффикс;
epoll_*/io_*/mq_* — подчерк, объект-префикс;
exit_group/pivot_root/create_module/delete_module — подчерк, объект-суффикс;
openat но open_by_handle_at
Это не касаясь семантики, deprecated имён, и пар типа fork/clone, open/openat.
PHP в этом смысле не уникален. Особенно по модулям. Плохо сделаны array_*, но только не в сравнении с perl’ом.
Пусть у libc 30 лет истории. Но даже у PHP есть выбор, взять имена из C (strcmp, mysql_connect), или переименовать всё под одну схему, и они видимо выбрали совместимость. Это главная проблема языка?
И какая доля всех установок на PHP делает такое?
В установках не знаю, но практически всё, что php-сты считают современными фреймворками, идёт со своим template engine.
Единственное хорошо известное исключение — Wordpress. И это не очень новая идея, Smarty появилась лет 10 назад.
То есть там в языке есть и бо́льшие кошмарики?
А чего кошмарики? Дань моде. Было время когда KDE такое делало. Все браузеры так делают, file:/// и т.д. Опера одно время не могла принять «file name» аргументом, только «file%20name». В коммандной строке. Ну и //share/filename.txt тоже не забудем.
Реальный кошмар там include(http://...). Тут даже у меня комментариев нет, одни матюки. Но опять же, сказать, что они уникальны — нет. pip, cpan, npm, composer.
Ой. DOU сожрал пример.
@yield(’title’) и < ?=$title? >
Так, але якже ж довго до нього йшли :(
У PHP это называется PDO.
Ні, не так.
Аналог mysql_* в Perl называется DBD::mysql. Полностью одинаковый подход, только PHP иначе грузит XS модули.
А про fopen на URL что скажете?А зачем о нём говорить? Ну есть и есть.
dou.ua/...orums/topic/13794/#708274
Вы считаете нормальным такое поведение функции?
А Вы считаете нормальным использовать функцию fopen с URL? Процитирую сам себя:
Если язык позволяет сделать какую-то глупость, то программист должен проявить свои знания, опыт и глупость не делать.Это как раз один из таких моментов. Используйте cURL, и будет Вам счастье.
А Вы считаете нормальным использовать функцию fopen с URL?
Во-первых, да, считаю нормальным, но только в том случае, если я могу явно указать, что используется расширенный режим, в котором открывается произвольный ресурс (по URL, файловому пути или вообще как-то иначе); по умолчанию же — тем более, через название, аналогичное сишному — это не должно выполняться ни в каком режиме компиляции и запуска. Сама по себе возможность такого исполнения без запроса — уже преступление.
Иными словами: если fopen(x, 'r') может открывать только файлы, а fopen(x, "r;+url") открывает ещё и URL, это нормально.
Если функция всегда отрабатывает URL, а для локального файла ей надо добавлять "file://" перед путём и это документировано — это нормально (хоть и затратнее из-за парсинга).
Если же она может понять путь как локальный, а может — как URL, из-за слабоформализуемых признаков — это ненормально. Что я должен сделать, чтобы эта функция всегда, при любых настройках и в любом окружении, открывала только файл?
Далее, Вы игнорируете:
Документация не говорит, что означает «не будет работать»; вернёт null, бросит исключение?
Пусть, предположим, открытие URL внешнего ресурса этой функцией запрещено (хотя определение, что это URL внешнего ресурса, не имеет права быть зависящим от настроек и должно делаться предельно простым и ясным образом, типа детекта URL scheme). Как именно этот запрет будет отражён в программу? Это уже документировали или нет? Если да, то почему тянули с этим много лет?
Это как раз один из таких моментов. Используйте cURL, и будет Вам счастье.
Включение cURL позволит гарантировать, что URL в fopen не будет отрабатываться, независимо от настроек места исполнения? Если нет — совет не годится.
Возможность открыть файл по URL — это ненужная фича, которая по непонятным причинам существует. Эту возможность не следует использовать. И чтобы её не использовать — нужен мозг. А не бог или компилятор, который запретит.
Программист должен уметь думать и применять правильно те инструменты, которые есть. А не молиться на несуществующие идеальные.
Эту возможность не следует использовать. И чтобы её не использовать — нужен мозг.
Есть фатальная разница между просто «не использовать» потенциально вредную фичу и возможностью нарваться на неё, даже если, вроде бы, приняты все меры против использования.
Программист должен уметь думать и применять правильно те инструменты, которые есть.
Вот потому я применяю те, у которых нет таких проблем :)
Если же она может понять путь как локальный, а может — как URL, из-за слабоформализуемых признаков — это ненормально.
В html тот же принцип.
p.s. напомнить, как двухаргументная open работает в perl-е, и зачем они ввели трёхаргументную?
В html тот же принцип.
Не понял.
В html — это в a href? Там без схемы всегда получается путь с модификацией URL страницы, то есть принцип однозначно чёток и прямолинеен.
p.s. напомнить, как двухаргументная open работает в perl-е, и зачем они ввели трёхаргументную?
Ну ведь ввели же? И явно рекомендуют не использовать старую форму.
Да
Спасибо, вопросов больше не имею.
, с такой кашей функций PHP выглядит куда более соответствующим принципу TIMTOWTDIНу если количество функций, помогающих решать различные проблемы — это минус, то стоит писать только на брейнфаке или асме. Там точно ничего лишнего.
$a1 = Array(10, ’Anne’ => 32, 11, ’Bob’ => 28, 12);А у меня возникает лишь один вопрос: нахрена так писать? Если язык позволяет сделать какую-то глупость, то программист должен проявить свои знания, опыт и глупость не делать. Вроде не в детсаде, чтобы воспитательница за каждым ходила.
$a2 = Array(1 => 21, 2 => 22, 3 => 23);
$a2[0] = 20;
Сразу же возникает куча вопросов:
А у меня возникает лишь один вопрос: нахрена так писать?критика Джавы строится по тому же принципу:
А у меня возникает лишь один вопрос: нахрена так писать?
Может быть естественным последствием ошибки, когда инициализированное в одном стиле применяется в другом.
Если язык позволяет сделать какую-то глупость, то программист должен проявить свои знания, опыт и глупость не делать. Вроде не в детсаде, чтобы воспитательница за каждым ходила.
Качество языка высокого уровня в наше время определяется уже не тем, что язык позволяет, а тем, что он не позволяет.
Данная ситуация — такого же уровня, как если бы на C или Pascal присвоили целое значение вещественной переменной и компилятор записал бы в неё целочисленное представление без конверсии.
Качество языка высокого уровня в наше время определяется уже не тем, что язык позволяет, а тем, что он не позволяет.У кого как. У меня качество языка определяется тем, как быстро и эффективно он позволяет решать задачи, и насколько лаконично выглядит решение. А вообще, среди веб-программистов в наше время принято обсуждать уже фреймворки, а не языки. Глупо писать на голом php и обсуждать его функции, когда есть целые классы и наборы классов для решения типовых задач.
Данная ситуация — такого же уровня, как если бы на C или Pascal присвоили целое значение вещественной переменной и компилятор записал бы в неё целочисленное представление без конверсииУ C и Pascal статическая типизация, у PHP — динамическая. Если Вы не понимаете, что это 2 разных равноценных подхода или не хотите принимать один из них — никто Вас не насилует.
У кого как. У меня качество языка определяется тем, как быстро и эффективно он позволяет решать задачи, и насколько лаконично выглядит решение.
А ещё — какие затраты на поддержку, причём много лет вперёд и в сложных условиях. Вы же напрашиваетесь на цитирование основного принципа веб-разработки из анекдота :)
Глупо писать на голом php и обсуждать его функции, когда есть целые классы и наборы классов для решения типовых задач.
Написанные в ещё более кошмарном стиле?
У C и Pascal статическая типизация, у PHP — динамическая. Если Вы не понимаете, что это 2 разных равноценных подхода или не хотите принимать один из них — никто Вас не насилует.
Я принимаю обе. Но Вы даже не пытались подумать, что я имею в виду. Попробуйте ещё раз.
Я принимаю обе. Но Вы даже не пытались подумать, что я имею в виду. Попробуйте ещё раз.Тогда я делаю вывод, что Вам лишь бы поспорить и общение с Вами в этой ветке прекращаю. Мой вечер не для того, чтобы уговаривать кого-то, что тот или иной язык плох или хорош.
что Вам лишь бы поспорить
false.
Мой вечер не для того, чтобы уговаривать кого-то, что тот или иной язык плох или хорош.
Немедленного ответа никто и не требовал (наоборот, я несколько раз в этой ветке предлагал сначала подумать, а потом уже писать). Если этот режим Вам не подходит — что ж, действительно, лучше не продолжать.
Поясніть будь ласка різницю в затратах на підтримку сферичного проекту в вакуумі написаного на ПХП, Перлі, Джаві, и будь якій іншій мові? Імхо, є лише три складові, рейт програміста, якість коду і кількість коду. Що з цього, крім рейтів, відноситья до вибраної мови?
Аналогичная по функционалу и сферическая в вакууме веб разработка на пхп быстрее, чем на джаве, а значит дешевле. Поиск пхп программистов гораздо проще чем поиск перл программистов, а значит быстрее, а значит дешевле.
ну власне я про це і писав
Що з цього, крім рейтів, відноситья до вибраної мови?
Много лет пишу на Perl так, чтобы следующий пришедший на проект человек не стал первым делом выискивать мой адрес для нанесения ядерного удара.
А также для того, люди из соседних отделов (как правило, С++) могли открыть написанный код и понять происходящее без моего онлайн/оффлайн присутствия.
Что я делаю не так с «нечитаемостью перл»?
Disclaimer: есть куски, нечитаемые не-перловиками, но они или непубличны, или короткие и выполняют простую функцию, в которую вникать помимо описания смысла не имеет, как, например, тут (на к-л другом, даже скриптовом, языке кода было бы больше)
Gregory Oganesyan
Sergii Voloshyn
Blitz
Igor Shipunov
Nikita Podgorbunskyi
undefined pointer
Valentin Nechayev
Jorzchyk Pushysty
Sergiy Borodych
Александр Ерин
Вадим
Maksym Iemelianov
# Allow intermixing of options and arguments. For this we need to disallow
# space as options value separator, otherwise it's hard to distinguish
# optional values from commands. For that I insert -- before first non-option.
{
my $pos = 0;
my $cmd_pos = [map {$_->[1]} grep {$_->[0]} map { [/^\w/ ? 1 : 0, $pos++] } @ARGV]->[0];
splice @ARGV, $cmd_pos, 0, '--' if defined $cmd_pos;
}
таких кусков единицы на сотни строк кода.А что в этом куске особенного? Ну map, ну grep. Как раз «обычный» перловый код часто менее понятен.
этот кусок не совсем лоялен к кавычкам же, не? Почему б не заюзать getopt::long, например?
Лоялен, потому что кавычками занимается шелл и отдает мне правильный @ARGV. GetOptions юзается как раз после указанного куска. Проблема, как всегда в программировании, в сочетании условий. Скрипт имеет 2 формата вызова:
script [options] profile-command profile
script [options] storage-command
а опции могут иметь опциональные значения: --print[=format], -p[=format]
Поэтому вопрос, как трактовать вызов
script --print A BGetopt::Long трактует как
Serge Ribalchenko
--print=A B, в то время, как, возможно, пользователь имел в виду --print -- A B.--print=A.Так там же (во всех вариантах getopt_long) есть явное различение случаев mandatory_argument и optional_argument. В первом случае, если аргумент не задан после ’=’ в том же argv[i], он ищется в argv[i+1]; для пустого аргумента надо явно написать--opt=. Во втором, если значение задано, оно может присутствовать только в том же argv[i] после ’=’. И автор вызова должен видеть по документации, какой режим у опции.
Пишу на perl c
Завтра можешь не найти жирную работу. Но еще больше попадет твой заказчик, которому останется гора трудноподдерживаемого г-кода и фиг программистов найдешь для разгребания завалов.
Я работу не ищу с
Да, сказки про программы которые не нужно расширять и которые не содержат багов, это тоже тренд среди ерланг булшитеров.
Я даже не знаю как тебе объяснить, что не все люди следят за модой, а кому-то она вообще противна. И вообще есть люди, которые мыслят нестандартно. Поэтому предлагаю просто перестать хамить.
А я тебе предлагаю не рассказывать сказки про то что решения на ерланге «просто работают», не содержат багов и не требуют развития.
Я в отличие от тебя никому ничего доказывать не собирался и не собираюсь. И мне пофиг на чьё-либо мнение. Своё я зарабатываю и буду зарабатывать, а всякие «желающие доказать, что я делаю неправильно» пусть идут в... на... и магнитики не забудьте.
Может ты и находишься в топ 0.1% эрлангеров урвавших свою унылую копейку, но мир ерланга в целом от этого унылей не становится.
Ну и твое мнение о том кому ты там что собираешься/не собираешься доказывать мне тоже мало интересно.
Чому ви так не любите людей, що пишуть на Erlang? Людина просто написала, що пише на Erlang, а її вже записали в «сказочники» і сказали, що її думка нікого не цікавить. Геніально.
Разжую по словам если ты не читал дискуссию прежде чем делать свои суждения:
человек спросил: что он делает не так, я ему обьяснил.
В сказочники он был записан потому что утверждал что его божественный код «просто работает», типа не содержит багов и не требует доработки.
Ерланг я не люблю потому что среди всех унылых языков не имеющих права на жизнь из-за ненужности, его адепты самые словоблудливые балаболы.
Поки він пише код, а йому за це платять — він все робить правильно. Змиріться.
Психология улитки живущей только сегодняшним днем и игнорирующей окружающий красивый и бурно развивающийся мир.
Це бізнес, капіталізм, ринкова економіка — називай як завгодно.
Наш код, який ми пишемо, нікому нафіг не треба. Всі хочуть зароболяти гроші. Не розуміти це — ось що є
Психология улитки живущей только сегодняшним днем и игнорирующей окружающий красивый и бурно развивающийся мир.
Це бізнес, капіталізм, ринкова економіка — називай як завгодно.Как раз экономика, бизнес и капитализм выбирают джаву: www.indeed.com/...obtrends?q=java,erlang&l=
Наш код, який ми пишемо, інкому нафіг не треба. Всі хочуть зароболяти гроші. Не розуміти це — ось що є
кажется кто-то в этом не уверен
кто здесь с этим спорит?
успокойся и работай, ты правильно выбрал джаву, все будет ок, не волнуйся так.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
потому что утверждал что его божественный код «просто работает», типа не содержит багов и не требует доработки.
Это твои домыслы, которые включаются каждый раз, как только ты видишь слово Erlang не в ругательном контексте. После чего всё превращается вместо топика в обсуждение твоих личных п/с проблем.
Предлагаю быть конструктивным и перестать обсуждать твои проблемы вообще на данном форумeю
Это твои домыслы, которые включаются каждый раз, как только ты видишь слово Erlang не в ругательном контекстеТа нет, я написал что проекты на ерланге испытывают проблемы с поддержкой из за дефицита программистов, на что чел написал что его проекты просто работают, а на личности здесь перешел в том числе ты, поэтому перенаправляю твою критику тебе самому.
Смотрим в историю:
его божественный код
Это уже переход на личности с твоей стороны.
Надо же, почти все вороны слетелись.
и ещё один.
А я тебе предлагаю не рассказывать сказки про то что решения на ерланге «просто работают», не содержат багов и не требуют развития.
Второй и третий пункт дописан твоей бурной фантазией.
Можно продолжать — но такое возникает везде, где ты видишь слово Erlang.
поэтому перенаправляю твою критику тебе самому.
Смешно, если бы не грустно.
Это уже переход на личности с твоей стороны.Я перехожу на личности в том числе когда чел выдвигает бредовые аргументы(программы на эрланге не требуют багофиксинга) и борется за них количеством текста а не качеством аргументов, этим он просто не уважает опонента. Не вижу ничего постыдного назвать человека дураком если он действительно дурак.
Второй и третий пункт дописан твоей бурной фантазией.Та нет, это чистый контекст дискуссии.
Я не занимаюсь систематическим обсиранием в ответ на простое «у меня оно работает».Ты занимаешься систематическим обсиранием в других областях, так что следи все таки за собой, иначе твоя критика просто смешна.
Я перехожу на личности в том числе когда чел выдвигает бредовые аргументы
В том и дело, что эти аргументы существуют только в твоём воспалённом воображении. Самое минимально неприятное для тебя объяснение — что ты вообще не видишь разницы между людьми, которые работают на том же Erlang, для тебя они все сливаются в один абстрактный образ. Остальные ещё хуже.
так что следи все таки за собой,
Слежу. Успешно и без твоих советов (в которых ты опять меня явно с кем-то спутал).
В том и дело, что эти аргументы существуют только в твоём воспалённом воображении. Самое минимально неприятное для тебя объяснение — что ты вообще не видишь разницы между людьми, которые работают на том же Erlang, для тебя они все сливаются в один абстрактный образ. Остальные ещё хуже.Ну или вижу, а бредишь как раз ты. Такое ведь тоже может быть?
Слежу. Успешно и без твоих советов (в которых ты опять меня явно с кем-то спутал).Значит плохо стараешься.
Чому ви так не любите людей, що пишуть на Erlang?та ви ще не знаєте що кул_хацкер не любить людей взагалі, а не за Erlang :)
Надо же, почти все вороны слетелись.
Дружище, я просто офигеваю от того, как у тебя подгорает от Erlang-а.
Признайся честно, тебя покусал программист на Erlang-е?
Может, тебе нужна психологическая помощь? У тебя проявляются психосоматические высыпки и зуд?
А ты когда успел понюхать что там у меня подгорает?
Да тут на весь форум коптит, и нюхать не надо.
Ну и, я так понимаю, насчет покусов и высыпок возражений нет? понятно
Да тут на весь форум коптит, и нюхать не надо.Ну вот ты например сюда счас зашел покоптеть со своими высыпками.
Ну и, я так понимаю, насчет покусов и высыпок возражений нет? понятноЯ где то подписывался на любую твою хрень отвечать?
Ну вот ты например сюда счас зашел покоптеть со своими высыпками.Исключительно, чтобы отвлечь тебя от расчесывания Ерланга. Судя по всему, получилось.
Я где то подписывался на любую твою хрень отвечать?Ты это и делаешь сейчас.
В общем, понятно, вопросов больше не имею.
Оставляю за тобой право оставить послений комментарий в этой ветке.
Исключительно, чтобы отвлечь тебя от расчесывания Ерланга. Судя по всему, получилось.Ты тут не причем, опоненты ретировались.
Ты это и делаешь сейчас.Я это делаю очень избирательно.
Всё-таки не кобол, работы на перл ещё достаточно, особенно если не влом поддерживать легаси крупных банков и пр. С т.з. жирности — процентное распределение жирности проектов для разных языков примерно то же. Но чем уже ниша, тем проще с этим проектом встретиться лично, особенно если таки развиваться. И опять-таки, если развиваться, можно найти интересные проекты на стыке языков/технологий.
Меня с перлом в NASA звали, только линкедин не показывает, что гражданство не то, хе-хе.
полсе перла пайтон для меня как свежий воздух (его можно читать после того как написал=)))
Perl тоже можно нормально читать, если нормально написано.
На любом языке можно написать такое говно, что не будет читаться.
Неужели виной всему чума, которую так сильно распространяет выкидыш PHP?
НА САМОМ ДЕЛЕ :) виной тому питон, руби с рельсами и node.js, куда мигрируют те, кому надоел пхп, но не хотят вникать в премудрости перла))
А вот я обязательно его подучу. Хотя бы чуть-чуть :)
> Почему же так? Почему никто не хочет писать на perl’е?
Примерно десять лет слушаю про «Perl мёртв» от фанатиков самых разных языков программирования. Уже становится похоже на заклинание.
Совсем недавно попадалась вакансия Perl-программиста в Амстердаме. Причем готовы брать специалистов в других языках и обучать.
Букинг? Она постоянно висит, вроде. Уже года три.
У Букинга ~3.2M LOC на Perl (via), так что наверное нужно довольно много разработчиков постоянно.
нужно довольно много разработчиков постоянноони их в жертву приносят?
Разжалуют в рум-сервис!
Ну разве что... на перле без дури не пишут))
Почему никто не хочет писать на perl’е?
Ну я успешно съехал с него на Python и считаю, что сделал правильно. Надоело бороться с проблемами того, что бывший «лучший шелл, чем шелл» превращают в язык общего назначения, не ликвидировав последствия такого прошлого.
Неужели виной всему чума, которую так сильно распространяет выкидыш PHP?
Почему надо было сравнивать именно с PHP? По-моему, это немного не та ниша.
А когда язык скриптования веб-страниц превращают в язык общего назначения, не ликвидировав последствия такого прошлого, это разве лучше?
Какой именно язык имеется в виду?
js же.
Честно говоря, я не увидел у JS именно особенностей, связанных с вебом. Динамические типы данных — да. Отсутствие целых чисел, неявные конверсии типов сильно больше, чем хочется (как между числом и строкой) — да. Но при чём тут веб? Такие конверсии есть в том же перле, а в Tcl вообще, считаем, один тип скаляра — строка, но они не связаны с внутренностями веб-страниц.
Вот кстати интересно. В Перле конверсии как раз явные — там всегда 5 * 5 даёт 25, а 5×5 даёт 55555. И 5.0 == 5, но не «5.0» eq «5».
Почему идея не пошла «в народ»? Казалось бы, если у нас динамическая типизация, логично сделать, чтобы семантика оператора зависела от оператора, а не от операндов? Или нет?
Да-да, так и есть, в Перле полно таких приятных и логичных моментов, после которых другие языки, типа js и php — выглядят уродливыми и глупыми.
Почему, блин, в php обращение к несуществующему ключу массива убивает скрипт, а чтобы сделать strict мод для переменных — нужно руками писать костыль, который перехватывает ворнинг и вызывает die?
Потому что PHP это PHP, а Perl это Perl
Попробуйте вместо того, чтобы ныть о
чуманаучится программировать и использовать для этого наявные инструменты (читай языки), а не расхваливать один вам удобный.
5 — целое, 5.0 — float с фиксированной относительной точностью, и там есть определенный ее предел (точности). Почему они должны быть равны — для меня неочевидно. Видимо, не только для меня.
Потому что при сравнении чисел целое станет флоатом, а не наоборот. Так и в Си, и в джаве, и, что характерно, в JS.
Так и в Си, и в джаве, и, что характерно, в JS.
В JS вообще нет целых. Там number — всегда double. Отдельные операции типа битовых, которые работают с
Потому что при сравнении чисел целое станет флоатом, а не наоборот.
По умолчанию — именно так. Причём в C нет правила «если точность целого больше, чем у float, оно конвертируется в double». Работая с
Почему они должны быть равны — для меня неочевидно.
Потому что сравнивается значение, а не представление. А то так можно договориться, что 0 в int16 не должно быть равно 0 в uint32 :)
Сравнения значений разных типов — это всегда компромисс между полным игнорированием типов и возведением их в абсолют. На этом пути есть множество промежуточных твёрдых состояний. Например, C ой не сразу пришёл к нынешнему набору правил со сравнением рангов разных целых для выбора направления конверсии, и некоторые его правила типа «unsigned конвертится в более широкое signed, а не unsigned» таки могут дать неожиданные подводные грабли.
В Перле конверсии как раз явные —
Что ты называешь явными конверсиями?
Oleksii Radetskyi
reality_hacker
Oleksii Radetskyi
Andy W
Alex Danilov
Maksym Mospanenko
Ihor Dvoretskyi
minodvesP Vasya
Sergiy Borodych
Egon Schiele
Roman Liskovenko
anonymous
Egon Schiele
Sergii Voloshyn
Maksym Mospanenko
Valentin Nechayev
Sergei Epatov
Rustam Kyrychenko
$ perl -e 'print "5"-"3","\n";'
2
$ perl -e 'print "5"+"3","\n";'
8
Вот тебе сразу два контрпримера.
Да, это не случай Javascript, который на второе выдаст «53», но само по себе молчаливое преобразование — уже то, что Питон, например, запрещает. Потому что число из строки может быть получено множеством разных методов. Например, что будет с таким:
$ perl -e 'print "5x"-"3","\n";'
2
На каком основании он при конверсии в число проигнорировал нечисловой хвост данного? Я ему такого не разрешал. Может, мне тут крайне важно, что число записано корректно без лишних символов, а писать полную грамматику на все случаи типа «-0×1.234p+300» — почему я должен делать работу за транслятор?
И без залезания на низкий уровень через модуль B и аналоги ты никак не узнаешь, как реально хранится скаляр — как число или как строка.
Поэтому утверждение про «явные конверсии в Перле» прямо неверно. Их эффекты частично сглажены, да, но не более того.
там всегда 5 * 5 даёт 25, а 5×5 даёт 55555.
Важно не то, что язык формально требует в документации для конверсий, а то, что он не запрещает. Даже молчаливые преобразования из целого в вещественные где-то могут давать потерю точности, и по-нормальному это диверсия.
Казалось бы, если у нас динамическая типизация, логично сделать, чтобы семантика оператора зависела от оператора, а не от операндов? Или нет?
Ну это примерно где-то тот путь, по которому пустили Perl6. Разделить ту же строковую конкатенацию и числовое сложение — это банальность, но само по себе такое разделение означает, что есть возможность их смешивать. Если бы операция «+» между числом и строкой была в принципе незаконной, то разделять не нужно было бы, и «+» работал бы в каждой паре по-своему. Это путь C++, Python и множества прочих.
Другой пример — деление. Начиная с Фортрана по всему майнстриму идёт правило: если при делении хоть один участник — вещественное, то деление выполняется с получением дробного результата; если оба целые, то деление идёт нацело. Это много где пытались менять (Вирт в своей цепочке языков, начиная с Паскаля — / и div; Python3 — / и //; и ещё много где), но в клонах Сишной логики, включая Java и C#, сохраняется старая бредятина. Сохранять тут один и тот же знак для двух разных в принципе операций? Если неявное преобразование int->float разрешено, то сохранять. Если нет, и все конверсии только явные, то можно обойтись одним «/».
семантика оператора зависела от оператора,
А ты операторов на всех напасёшься? В C++, например, их количество тупо ограничено. Есть места, где можно плодить свои, лишь бы они грамматику не нарушали (Perl6, Postgresql), но таких мест крайне мало. Да и в случае возможности определения своих будут массово предпочитать переопределить существующие, лишь бы не умничать со странными знаками.
Дело совсем не в вебе, веб это частности. А в том, что язык изначально заточен на (а)дергание древовидной структуры документа и урлов на сервере (б)в ответ на события (в)без лишних низкоуровневых заморочек. А древовидной структурой может быть и DOM—дерево веб-сайта, и PDF-документ, и серверные endpoint-ы в ноде, и кастомный UI в любой другой системе. Как пример QtQuick: Qt с привязкой js. И нет в этом подходе ничего плохого. Если бы не одно но: каким-то умникам пришла в голову мысль, что js это полноценный язык общего назначения, и теперь его пытаются пихать даже в микроконтроллеры. В то время как без пункта (в) попытки эти смехотворны. Без трединга, кешей, атомиков, lock—free, системных вызовов, SIMD, выравнивания по памяти, управления ресурсами, управляемой укладки структур данных в памяти, векторизации, условной компиляции, инлайнинга, явно специфицированной линковки, четко заданных стандартов бинарной совместимости и т.д. и т.п. можно, конечно, создать кое-как кое-что в некоторых нишах(далеко не только в вебе), но крутой софт мирового уровня за пределами веба вы не получите, как не старайтесь. Facebook и VK тому пример: наигрались с js на мобилках, перешли на натив. А Evernote так вообще остался недоволен js даже на ПК, и зафигачил десктопный нативный клиент, оставив web-версию как fallback.
А в том, что язык изначально заточен на (а)дергание древовидной структуры документа и урлов на сервере (б)в ответ на события (в)без лишних низкоуровневых заморочек.
Язык, заточенный под (а), (б) и (в), выглядел бы как помесь jQuery с perl’ом.
А голый js это скриптовый язык общего назначения. В одном ряду с lua и guile.
Без трединга, кешей, атомиков, lock—free, системных вызовов, SIMD, выравнивания по памяти, управления ресурсами, управляемой укладки структур данных в памяти, векторизации, условной компиляции, инлайнинга, явно специфицированной линковки, четко заданных стандартов бинарной совместимости
Java спокойно живёт без большей части этого списка.
Начиналась, напоминаю, как язык для embedded приложений.
В Java детальнейшая стандартизация всего на свете. Явно специфицированы бинарный формат, линкинг, виртуальная машина, работа с памятью, далее по всем остановкам. Не хватает на самом деле совсем немногого из джентльменского набора, но на то с первых дней Java существует JNI. Дико архаичный и неудобный по нынешним меркам, в том же шарпе интероп к системщине продуман куда лучше. Но это совсем не то, на чем стоило бы заострять внимание.
И да, на чистой Java без толстого слоя нативного кода, вызываемого через JNI, на мобилках и в embedded далеко не уедешь. Впрочем как и на десктопе во многих предметных областях.
Хороший был язык. Но слишком мало внимания уделялось созданию всевозможных удобств и их продвижению. А когда они захотели запилить Perl 6, то делали всё слишком медленно.
Результат предсказуем: Perl был вытеснен более удобным (для публикации и шаблонизации) PHP.
А потом уже и PHP потеснили, но это уже другая история. А Perl тем временем всё продолжал жить в своём отдельном мире, продолжал жить мечтами и светлом будущем с прекрасным Perl 6.
Как-то так.
P.S.:
Интересно, есть ли в Ruby или в Python аналог «use strict»...
не знаю, как в Ruby, а в Python он встроен по умолчанию, поскольку является частью языка, и бросается ексепшенами, когда что-то не так
в Python он встроен по умолчанию
Это, к сожалению, не касается переменных. Предварительное называние всех переменных уже достаточно неплохо избавляет от странных граблей.
В остальном да — значительно лучше для качества итогового продукта получить исключение при доступе по несуществующему ключу или невозможной конверсии, чем получить undef, который молча будет расползаться по данным.
Я как раз это и имел в виду.
В Python есть возможность потребовать объявления переменных (с одновременной или дальнейшей инициализацией) до их использования?
Чтобы избежать такого:
undef, который молча будет расползаться по данным
P.S.:
Также про Ruby интересно такое.
В Python есть возможность потребовать объявления переменных (с одновременной или дальнейшей инициализацией) до их использования?нельзя
undef, который молча будет расползаться по даннымпитон просто бьет по рукам в рантайме, когда обращаешься к несуществующей переменной — бросает исключение NameError, которое, кстати, можно перехватить
когда обращаешься к несуществующей переменной — бросает исключение NameError
Ну, хотя бы так. Значит, жить можно.
В Python есть возможность потребовать объявления переменных (с одновременной или дальнейшей инициализацией) до их использования?
Да, если считать этим собственно присвоение начального значения.
Нет, если требуется сделать, чтобы далее не допускались необъявленные имена.
Чтобы избежать такого:
А от этого undef не будет, в Питоне чтение необъявленной переменной вызовет исключение. От необъявления будут другие проблемы — например, присвоение варианту с опечаткой и от этого сохранение старого значения там, где оно должно было обновиться.
Это, к сожалению, не касается переменных. Предварительное называние всех переменных уже достаточно неплохо избавляет от странных граблей.это да
Perl слишком созвучен с перловкой, поэтому у многих вызывает отвращение на подсознательном уровне.
В ucoz постійно треба perl. Правда, у них деви в Черкасах сидять, але готові брати будь-кого на перекваліфікацію. Так було ще 4 роки тому, зараз не знаю.
Похоже, что никто не разделяет горя по поводу отсутствия работы на Perl’е...
главное — вовремя спрыгнуть )
А если серьезно, не вызывало подозрений в последние годы отставание языка от аналогичных? Я, помню, слез с него, когда потребовалось exceptions обрабатывать, я тогда оглянулся и бежал ;)
Спрыгнуть на другой подобный язык — это, конечно, можно. Но проблема в том, что задачи, для которых идеально подошел бы Perl — берутся решать на чем-то другом, только потому что последний перестал быть популярен, а не потому, что перестал справляться с ними.
последний перестал быть популяренЭто же не первопричина, его перестали выбирать почему-то.
А до чого букінг? Він був на перлі?
Он есть на перле и слезать с него не собирается. Даже занимался развитием языка.
И до сих пор занимаемся.
я наверно неправильно выразился,
Ну и на примере booking.com видно, что это тенденция.хотел сказать что тенденция падения среднего количества разработчиков прослеживается на примере подьема спроса в отдельных компаниях, которых немного.
И вот через полтора года, судя по сообщениям, началась миграция на Java в самых существенных областях.
Часто решение выбирается не архитектором из-за технических характеристик, а нетехническим менеджером из-за раскрученности названия. Perl никто не раскручивал в отличие от Ruby или Python (перевод курса MIT CS 101 с лиспа на пайтон — неслабый маркетинговый ход для языка, не так ли?).
о том, что причин много, я и говорил. Одна из них неактивное комьюнити.
Одна из главных проблем языка была, кстати.
На нём почему-то писали люди, не умевшие думать иначе как в терминах тогдашней около-C++ тусовки. Исключения, классы, «корректность», много кода, «мы пишем на perl’е значит мы пишем на perl’е *всё*».
Язык был достаточно гибкий чтобы это кое-как работало, но именно что кое-как.
Любой более подходящий язык (python, java) и такой стиль работал гораздо лучше.
Сейчас интересно, как ветер поменялся. Новые языки отказываются от исключений и это не считается проблемой.
Тоже интересно, но уже с другой стороны, как PHP повторяет ошибки perl-коммьюнити.
Проблем было больше — комьюнити, фрейморки, ИДЕ. Потом вроде частично начали решать, но приток новичков уже упал.
Ык. Желание видеть IDE, фреймворки — это как раз то, что я имел в виду.
IDE помогает решать специфические проблемы тяжёлых языков типа Java.
Языков, где большая унитарная программа является нормой.
Perl это язык маленьких фильтров. Он работает хорошо ровно до тех пор, пока программисту удаётся держать отдельные программы маленькими.
Это просто другой подход к декомпозиции, не-ОО, и инструменты там нужны другие.
Если человек пишет так, что ему нужна IDE, фреймворки, ему нет смысла писать на perl’е.
С таким стилем Java или даже Python будут заведомо удобней.
Коммьюнити этого не поняло, и CPAN оказался завален кодом, который подчёркивал худшие стороны perl’а. Для
Другие проблемы тоже были, это само собой. На исходники языка без валерьянки лучше не смотреть. Но основной imho было желание коммьюнити (в широком смысле) забивать гвозди лопатой.
А что плохого в исключениях?
Некоторые авторы их ниасиливают.
Новые языки отказываются от исключений и это не считается проблемой.
Наверное, от checked исключений, а не от исключений как таковых.
Новые языки отказываются от исключений и это не считается проблемой.
Это «не считается проблемой» только у разработчиков этнических локальных языков типа Go. Остальные используют средства для сокращения громоздкости и рутины, включая исключения.
Perl был именно таким локальным языком. И они это посчитали проблемой.
Да, отстаём, надо навёрстывать. Даже если получается не очень красиво.
Сходите в коммьюнити по Go или Rust’у, скажите им, что они «отстают от аналогичных языков» т.к. у них нет исключений. Вам наверняка расскажут, где они видели исключения и как туда пройти.
Можно ещё в Гугле поспрашивать, с их гайдами по C++. Или у функциональщиков.
Perl-комьюнити этого сделать не (с)могли.
Perl был именно таким локальным языком. И они это посчитали проблемой.
Вы хотите сказать, что в Perl нет исключений?
Сходите в коммьюнити по Go или Rust’у, скажите им, что они «отстают от аналогичных языков» т.к. у них нет исключений. Вам наверняка расскажут, где они видели исключения и как туда пройти.
Ну я на это отвечу, где я их видел с их недоязыками. Причём если Rust ещё только-только зародился, то разработчики Go уже доказали свою невменяемость по целой массе параметров.
Можно ещё в Гугле поспрашивать, с их гайдами по C++.
Гугл писал свои гайды тогда, когда исключения ещё не были нормально сделаны. Сейчас этой проблемы нет.
Или у функциональщиков.
Erlang: исключения есть. Что мы не так делаем? (tm)
Вы хотите сказать, что в Perl нет исключений?Наоборот. Всем говорят, что они есть, но лучше бы об этом молчали.
Ну я на это отвечу, где я их видел с их недоязыками.Правильно. И вы пойдёте каждый своей дорогой, будете каждый писать в своём стиле и не будете друг другу мешать.
Erlang: исключения есть. Что мы не так делаем? (tm)И шо, и вам не говорят, что правильно использовать вариантные типы с паттерн матчингом?
Всем говорят, что они есть, но лучше бы об этом молчали.
Почему? Не любят слышать про них, или неправильно используют?
И шо, и вам не говорят, что правильно использовать вариантные типы с паттерн матчингом?
Вы вообще в курсе, когда и против каких ситуаций появились исключения?
И какая каша была в обработке ошибок до них, неважно, с pattern matching или без оного?
Про Go: бггг.
Да уж. Тейлор с Ритчи на щите это супертандем, все ушли и откусили.
Почему? Не любят слышать про них, или неправильно используют?
Мысли неправильные провоцируют.
Типичный писатель на Java (C++, что там ещё было популярно в те годы) слышал про скриптовый язык perl, начинал разбираться. Классы есть? Perl-комьюнити: ну вот так. Исключения есть? Perl-комьюнити: ну вот так сделать можно. Разбивка на файлы/модули? Неймспейсы? Perl-комьюнити: ну да, @inc, use, Exporter. Круто, я буду писать так же, как я писал на Java (C++, ...), только на perl’е! Потому что так правильно/круто/ООП-рулит/best-practices/как-можно-по-другому.
Только для этого всегда лучше подходил Python. Или Java. Или Ruby. А Perl — не очень. Как и что лучше писать на perl’е, комьюнити объяснять не хотело.
Вы вообще в курсе, когда и против каких ситуаций появились исключения?
Вот подумал и говорю: не знаю. Зато знаю, до чего они дошли в Python’е.
Не, ну я видел как в Python создают класс с одним методом чтоб сделать, образно говоря, print. Но это джаверские зарубки и такое быстро потом вычищают, т.к. не pythonic code. А кстати, есть стиль перловый? perldoc.perl.org/perlstyle.html
P.S. все еще считаю что перл ушел в бекграунд из-за комюнити, а не из-за exceptions.
все еще считаю что перл ушел в бекграунд из-за комюнити, а не из-за exceptions.
Согласен. Тред просто начался с фразы про исключения, но исключения сами по себе к проблеме относятся очень опосредованно.
Комьюнити не смогло решить, что делать с языком.
P.S. все еще считаю что перл ушел в бекграунд из-за комюнити,
Из-за того, что он нецельный.
Цельным языком, хоть и очень ограниченным, был Perl4. Это был один из вариантов «замкнуть шелл до полной логичности». Но и нишей его было — скрипты до трёх страниц.
Для объёмов в тысячу страниц, сотню тысяч строк и приложение размера «средний сайт без изысков» он уже проигрывал конкурентам, и вышел вперёд только за счёт того, что отдельные фичи отрабатывал быстрее. Но PHP его подбил быстрее остальных.
Как и что лучше писать на perl’е, комьюнити объяснять не хотело.
Я вообще считаю, что ответа на этот вопрос для случая кода больше чем на несколько страниц — нет в принципе.
Вот подумал и говорю: не знаю.
Исключения возникли тогда, когда задолбались с любым мельчайшим вызовом подпрограммы (функции) получать от неё результат признака успешности, складывать её ответ в переменную и разбирать результат.
Грубо говоря, если у тебя есть операция сложения строк, то её лучше писать в виде c=a+b, чем в виде
Вадим
Michael P
Oleh Korotkov
Sergii Kudriavtsev
Olexandr Vovchok
int r;
string c;
r = c.set(a);
if (r == ENOMEM) abort_with_msg("всё совсем плохо");
else if (r != 0) goto всё_плохо_но_ещё_терпимо;
r = c.append(b);
if (r == ENOMEM) abort_with_msg("всё всем плохо");
else if (r != 0) goto всё_плохо_но_ещё_не_очень;
Когда таких простыней обработки по каждому чиху становится слишком много, они переполнены идентичным кодом, за которым не видно целевых операций, и кодеры начинают шумно тосковать по языку, где таких проблем нет — возникает проблема, а как же лечить? И вот тут и возникла идея не вышибать в этом случае, например, всю программу, а сделать вариант типа «аварийный выход, не предусмотренный обычным потоком выполнения». И как только это было совмещено со второй идеей сделать 1) указание типа ошибки (пока что не в виде типизированного объекта, а просто «тип» без уточнения), 2) ловлю в зависимости от этого типа — тогда исключения сформировались в нынешнем виде (явная генерация с указанием типа, размотка стека, ловля в зависимости от типа, начиная с более детальных; а тут и иерархия типов объектов подключилась как естественное облегчение).
Так вот, к чему это я — паттерн-матчинг, который Вы упомянули как замену исключениям, тут не помогает ничем. Потому что при нём всё равно или пишешь:
{ok, Result} = do_something();
тем самым вызывая ошибку в случае возврата чего-то другого (а эта ошибка в нынешнем Erlang таки проецируется на систему исключений);
или же пишешь:
case do_something() of
{ok, Result} -> process_result(Result),
continue_work();
{error, Error} ->
report_error(Error, do_something)
end.
в котором всё те же простыни разборов «если не пошло как в идеале, то начать творить свои обработки».
И результат отсутствия обработки такого исключения такой же, как в случае процедурных языков, с той разницей, что вышибается не вся программа, а один Erlang-процесс (позволяя супервизору перезапустить его). Но это можно сделать и в своём движке событий, определяя факт вылета по любому исключению, кроме глобальных проблем типа bad_alloc, и регистрируя по-своему.
Зато знаю, до чего они дошли в Python’е.
И до чего же? Я в его системе исключений не вижу грубых проблем. Разве что то, что мне периодически приходится писать враппер вокруг генерации EAGAIN или EINPROGRESS из сетевых функций, вот тут немного обидно:)
Я вообще считаю, что ответа на этот вопрос для случая кода больше чем на несколько страниц — нет в принципе.
Да, и это можно считать ответом. На perl’е надо держать скрипты маленькими. Почему и реакция на вопрос об исключениях — в маленькой программе они не нужны.
Писать что-то большое на perl’е можно только если код удаётся разбить на много небольших независимых скриптов. Это то, что имелось в виду под другой декомпозицией.
Наверное можно. Я не пробовал, и успешных решений в таком стиле не видел.
сделать вариант типа «аварийный выход, не предусмотренный обычным потоком выполнения»
Вот не соглашусь. Идея исключений — catch в произвольном месте, с возможностью продолжить там же.
То есть не «выход», а что-то вроде «множественный control flow».
И даже на сам по себе, а то, что это можно делать направо и налево.
Выход это abort(3) из libc, это то, что было до исключений.
Множественный control flow скорее всего тоже был. Мне сложно сказать, что появилось раньше, исключения или setjmp.
Но принципиально то, что это считалось ненормальным.
И результат отсутствия обработки такого исключения такой же, как в случае процедурных языков, с той разницей, что вышибается не вся программа, а один Erlang-процесс (позволяя супервизору перезапустить его).
Если я правильно понял, это аналог abort(), а не исключений. Обработка только в специально отведённом месте.
Исключения это когда любая функция может быть (args) -> Return(type) | Throw(exception), причём вторую часть (Throw) не нужно объявлять, но можно обрабатывать. Не проблема, python живёт и ничего, но насколько я знаю, функциональщики к такому относятся не очень хорошо.
И до чего же?
open возвращает открытый поток, или выбрасывает исключение если файл не открылся.
Это функция типа Stream | IOError. Но один тип возвращается как результат, а второй как исключение.
Да, и это можно считать ответом. На perl’е надо держать скрипты маленькими. Почему и реакция на вопрос об исключениях — в маленькой программе они не нужны.
Но в предыдущих сериях шла речь о том, что в языках, таких, как Go, Rust, исключения тоже не вводятся. И что в таком случае — они тоже предназначены для мелких скриптов? ;)
Вот не соглашусь. Идея исключений — catch в произвольном месте, с возможностью продолжить там же.
Я не знаю, с чего это по-Вашему это идея исключений. Я рассказал реальную историю, как исключения возникли. Например, одна из ранних стадий описана в этой книге. (Обратите внимание на имя автора.)
catch в произвольном месте — нет такого, есть catch по выходу из блока try (именно в таком виде оно устоялось).
То есть не «выход», а что-то вроде «множественный control flow».
Этого не понял.
Выход это abort(3) из libc, это то, что было до исключений.
При чём тут abort? abort это спецсредство для вариантов, когда продолжать вообще уже нельзя или не имеет смысла, или просто не хочется заморачиваться обработкой. И почему останавливаемся только на C? Например, on error goto в BASIC это обработка исключений, хоть и не структурированная.
Мне сложно сказать, что появилось раньше, исключения или setjmp.
Я точно знаю, что исключения вообще были до setjmp, но структурированная обработка исключений — после setjmp.
В очень ранних формах исключения были даже в Фортране IV середины
Если я правильно понял, это аналог abort(), а не исключений. Обработка только в специально отведённом месте.
В Erlang Вы можете в любом месте написать:
try
некоторые действия
catch C:E ->
обработка
end
и вместо C можно подставлять указание конкретного класса исключения: exit, error или throw. Throw соответствует явному throw() некоторого выражения — это исключение как таковое. error генерируется соответствующим BIF и используется для стандартных ситуаций типа badarg, function_clause и так далее. exit — это из exit/1.
Если такое исключение не поймано до конца размотки стека текущего процесса, процесс завершается, но от класса и значения исключения зависят подробности его передачи слинкованным процессам, мониторам и штатным репортерам типа SASL. Можно это считать как три базовых класса исключений (в понятиях ООП).
Исключения это когда любая функция может быть (args) -> Return(type) | Throw(exception), причём вторую часть (Throw) не нужно объявлять, но можно обрабатывать.
Ну предположим.
Не проблема, python живёт и ничего, но насколько я знаю, функциональщики к такому относятся не очень хорошо.
Я продолжаю недоумевать, где тут по-Вашему Python отличается от других языков, типа C++ или Java. Я пока что не учитываю объявление набора возможных исключений в типах функций, checked exceptions в Java и т.д.; но в остальном ситуация в нём не отличается от того, что Вы описали: или обычный возврат значения, или генерация исключения. Переформулируйте, если считаете, что я Вас не понял.
open возвращает открытый поток, или выбрасывает исключение если файл не открылся.
OK, и что с того? Так себя ведёт огромное количество интерфейсов, которое предназначено обычным образом вернуть некоторый ответ. Поэтому для уточнения своей мысли сформулируйте, с чем именно Вы сравниваете. Тут есть два варианта.
Если это обычные процедурные языки, то у них или такая же генерация исключения по неудаче, или возврат спец-значения с уточнением ошибки где-то в псевдоглобальном статусе (как errno), или побочный эффект, который надо проверять явно.
Если функциональные и заточка на паттерн-матчинг, то:
1. Паттерн-матчинг требует, чтобы его часть явно забиндили. То есть мы не можем писать, например, g(f(x)), если f(x) возвращает что-то вроде {ok, Result}; мы должны явно писать
{ok, Result} = f(x),
g(Result)
что в общем-то тоже приводит к громоздкости и накоплению усталости.
Если же кто-то попытается это обойти (например, для Erlang напишет g(element(2, f(x))), то он потеряет часть проверки и точно так же применит g() к Error вместо Result.
2. В том же Erlang множество функций имеет сигнатуру не {ok,Result} | {error, Error}, а результат без всяких {ok,} или исключение. Например, быстрым проходом по манам находим: dict:fetch, dict:update, gb_trees:get, db_trees:insert, lists:nth, lists:tail, erlang:register... а все математические функции? даже не говоря про смысл 'a'+"b", попробуйте-ка round({1.3}) вместо round(1.3)...
Разумеется, там есть какая-то логика, в каких случаях возвращается error, {error, Error}, false, none или другая явная индикация ошибки, а в каких — генерируется исключение. В общем, можно сказать, что явная ошибка генерируется для действий внешнего мира, для поисковых действий при возможном отсутствии объекта. Но при этом имеем параллельные gb_trees:get и gb_trees:lookup, первое даёт исключение при отсутствии значения по ключу, а второе — значение none. Это уже явно следы оптимизации под конкретные юзкейсы.
И единственное, что тут можно сурово поставить в упрёк Питону — это повышенная «агрессивность» в сторону генерации исключений вместо спец-значений ошибки (я её уже вспоминал в случае модуля socket). Да, для некоторых действий это малоэффективно. Но на нём такие вещи таки обычно и не пишут.
Это функция типа Stream | IOError. Но один тип возвращается как результат, а второй как исключение.
Именно. Имеем логику типа «предпочтение возврата ошибки как исключения» как общее правило, и поправки уже для этого правила для частых вариантов типа socket.connect_ex(). И снова: разве это только Python? Сплошь и рядом начиная с Java.
оце б такі коментарі та й в кожну тему ;)
вначале года, кто то постил здесь, что в данию (или где то рядом) нужны программеры на перле, готовы были взять нулевого на обучение. поищи, может не все так хреново
я думала, тема — сарказм )
А что, есть отсутствие работы?
Есть отсутствие вакансий, что усложняет гипотетический поиск работы.
А когда то было все наоборот sites.google.com/...teveyegge2/anti-anti-hype
вроде как booking.com постоянов перловщиков с Украины стягивает в Амстер.
Насколько помню они даже готовы были переобучить желающих.
Будто переехать в другую страну ради работы — это вообще обычное дело и ничего не стоит.
Те, кто хотят писать не перле и не так ещё раскорячиваются.
Кто-то переходит на перл чтобы уехать, а кому-то придется уехать чтобы остаться на перле. Селяви.
Кстати букинг помогает переехать и по материальным затратам это пракически ничего стоить не будет.
Все правильно помните) И сейчас готовы.
У вас прямо якась бзезсрочна акція. :)
Акція не тільки безсрочна, а і дуже крута — можете попрацювати з людьми, які пишуть Perl.
Ну це так, я ж то більше по JS частині.
Наверно пришло время меняться. И не обязательно учить PHP, есть трушный Python
А в чем, собственно, заключается «трушность» Python’a ?
В наличии стандартов. Собственно в том, чем продукт изготовленный любителями отличается от продукта изготовленного профессионалами. Вроде оба исполняют свою функцию, но приятнее иметь второй.
Вы хотите сказать, что в Perl’e нет стандартов ??
Честно говоря я не знаю, а сравнивал я PHP and Python только
PHP кривой, и можно хоть 100 ссылок приводить какие они крутые какая у них компания, но факт остается фактом
Теперь перечитайте свой пост dou.ua/...orums/topic/13794/#707784
PHP делают профессионалы. Python и особенно Ruby — любители.
Судя по его кривости, его делают индусы. Кстати, в PHP 6 не смогли.
Яке PHP6? Шотимелеш? Буде PHP7. І над стандартами там зараз працюють достатньо. Інша справа, що їх не обов’язково дотримуватися і всякі бездарі цим користуються.
Подивися на код Symfony2 і Laravel, а потім розказуй як все тут погано.
Хоча про що можна говорити з людиною, яка, навіть, не знає як працює в php autoload.
Судя по его кривости, его делают индусы.*facepalm*
Ага, бачив я частково що там буде: можливість задання типу вихідних даних в методі, типу як у Java(public STRING methodName). Тільки от проблемка: там можна буде лише деякі типи даних задавати: array і ще щось, а boolean, string і т.д. не вийде. Коротше ще одна обрізана синтаксична конструкція, яку ніхто не буде використовувати. А все чому? Тому що щоб PHP став нормальним, йому треба перетворитися в Java. А стати Java вын не стане, бо тоді типовий пхп бидлокодер(для якого і створювалася ця мова) — стане неосилятором.
яка, навіть, не знає як працює в php autoload.
function __autoload($name)
{
include_once($name.".php");
}
Якось так, якщо память не підводить
Якось так, якщо память не підводитьБез PSR-4 (Стандарт! All of a sudden!) ця функція нічого не варта.
типовий пхп бидлокодер(для якого і створювалася ця мова)Зніми німб і опустися на землю.
Без PSR-4 (Стандарт! All of a sudden!) ця функція нічого не варта.
Мій код то на хвилинку практично точна копія прикладу у оф доках пехопе. Ти не очікував що я відповім, а тепер перидумовуєш як би інакше наїхати.
Зніми німб і опустися на землю.
А я на землі. Думаєш я не бачив код інши програмістів пхп? Навіть у великому проекті(формування вітальних листівок на льоту на будь який смак) був повний піпець.
Зрозумій, я не пишу що ти бидлокодер. Просто та область така і водяться там в БІЛЬШОСТІ ті які плювали на будь які стандарти. Не приймай на свій рахунок.
Зрозумій. Не треба гнати на всіх, якщо сам ти — ніхто і звати тебе Ніяк.
Ти вже другий молодець який перейшов на особистості за сьогодні, переписуючись зі мною. Оце у вас підгоріло.
П.С. Хоча у мене теж було підгоріло в іншій переписці, але я не опустився до рівня образ, навідміну від декого.
спорнём что я на любом языке могу наговнокодить?) Как и на любом можно сделать красивый код. Говнокод — следствие не языка, а человека который его пишет. А потому твои нападки на язык — бред олигофрена.
Не забудь расплакаться и написать, что я перешел на личности. Только вот мне покс :D
Там будь-який код гарний за замовчуванням ^_^
Как и на любом можно сделать красивый код.
1. Вопрос не в красоте, а в качестве (и только потом о красоте).
2. В одних языках это в разы легче, чем в других.
А особенно когда идёт речь про фишки вроде:
@fopen(’example.com/not-existing-file, ’r’);Что он будет делать?
* Если PHP скомпилирован с —disable-url-fopen-wrapper, он не будет работать. (Документация не говорит, что означает «не будет работать»; вернёт null, бросит исключение?) Заметьте, что этот флаг убрали в PHP 5.2.5.
* Если allow_url_fopen выключен в php.ini, он тоже не будет работать. (Как не будет? Нет идей.)
* Из-за @, предупреждение о несуществующем файле не будет выведено.
* Но будет выведено, если scream.enabled установлен в php.ini.
* Или если scream.enabled вручную установлен через ini_set.
* Но не в том случае, если не установлен корректный error_reporting.
* Если оно будет выведено, куда оно будет выведено зависит от display_errors, снова в php.ini. Или ini_set.Я не могу сказать как такой безобидный вызов функции будет себя вести без проверки флагов времени компиляции, глобальной конфигурации сервера и конфигурации в моей программе. И это всё встроенное поведение.
— усилия для создания качественного кода становятся неподъёмными.
В Perl этого на порядки меньше. В Python — ещё меньше. Для меня выбор для их общей ниши — очевиден. Даже если при этом какие-то очень простые задачи потребуют в 2 раза больше написания.
Вот это у вас пригорело, сударь.
Уявіть, що ви досвідчений рубіст, а потім якийсь пацан бере книжку по пітону і через 2 місяці заявляє, що рубі — гавно. Це нормально?
Но ведь вы можете игнорировать. Или не можете? Что заставляет вас пылать праведным гневом?
Из всех скриптовых языков, именно разработчики на php оказываются наиболее тонкими и чувствительными натурами и постоянно кому-то доказывают, что язык не столь плох, как принято считать. Занятное наблюдение. То ли язык все-таки говно, то ли люди очень нежные (может потому, что в душе сомневаются в своих аргументах?), наука еще не выяснила.
Зате у джавістів найбільше ЧСВ.
По ділу нічого не написав. Справа не в php. Якби були інші мови, я б відредагував так само.
Запрос «php говно» выдает 1 150 000 результатов, запрос «python говно» выдает 45 600 результатов, запрос «ruby говно» выдает 73 400 результатов ...
why php is sucks — 29 600 000
why python is sucks — 832 000
why ruby is sucks — 1 710 000
Все-таки что-то с ним не то :)
Бо він найпопулярніший. Apple всі хвалять, а тем про «гріється air» або «не вмикається iPhone» в сотні разів більше, ніж аналогічних для Nokia lumia.
iphone doesn’t turn on — 31.5 мільйон
screencloud.net/v/wv8j
lumia doesn’t turn on — 1.04 мільйоів
screencloud.net/v/8FYQ
І що? Не думав, що серед java девів можуть бути настільки недалекі. Ну, або ви мене тролите — тоді я повівся.
Каждая лягушка хвалит свое болото ©
Где вы во мне Java-разработчика нашли? Или это все php-программисты видят только то, что хотят видеть?
этот аргумент был бы допустим, если бы популярность упомянутых языков была распределена равномерно. Я тут подумал, что можно примерно прикинуть популярность, запросив что-то нейтральное о языке, например, «php programming language». И у меня получаются немного другие цифры.
тот же гугль, запрос ’why (php|perl|python|ruby) sucks’:
> gsucks python perl php ruby 967000 336000 66900000 1670000
запрос ’(php|perl|python|ruby) programming language’:
> gpop python perl php ruby 19900000 3460000 60900000 3250000
смотрим соотношение хейтерских комментариев к количеству упоминаний вообще, сортируем:
> sort(gsucks/gpop) python perl ruby php 0.04859296 0.09710983 0.51384615 1.09852217
получается, что пхп дейсвительно хейтят больше всего. Почему хейтерских комментов больше упоминаний ’php programming language’ - для меня загадка.
Метод, наверняка, называется: гадание на поисковой выдаче.
Но он как-то ближе к экстрасенсорике, чем к аналитике...
я заглянул в ваш профиль — вы давно на пхп пишете?
думал будет перлосрач, а нет, традиционно перешел в пехапе ))
Это плохо что его нет, ведь срач устраивается только между популярными языками. Делаем выводы :/
У меня к перлу теплые чувства. Может и у остальных?
Конечно количество хейтеров любого языка не сравнится с количеством хейтеров PHP, но я сомневаюсь что будь перл хоть как то популярен, то его бы тут не задели.
Количество хейтеров — это показатель уровня зомбоящика. Если отнестись к этому чуть критичней и взять хотя бы простое отношение хейтер-ссылок к зебестовским в том же гугле, то для php получим что-то в диапазоне
Хотя даже не так: будь перл популярен, то тут бы уже набрасывали обиженные пехапешники
Вернись в наше время. Уже все по другому, никто так автолоад не пишет. Не нужно сравнивать PHP , который был 5 лет назад и текущую реализацию.
Ще додам: які б хороші стандарти в ПХП не вводили — там завжди будуть какокодити. І те що ти, можливо придержуєшся і пишеш як треба — не змінює загальну ситуацію, яка плачевна.
’Учусь на Android Developer’))) я передумал аргументированно отвечать :D
И вы решили ответить пустословием, и от этого ваше мнение стало более много весить. Я понял :)
Ви б на Google play зайшли і подивились скільки там каки. І як би добре ви не вивчились — ситуації ви не зміните
[mode=баян]Титаник тоже построили профессионалы.[/mode]
Проблема была не в Титанике, а в тех, кто им управлял...
Я бы даже поверил, если бы не то, что: «Титаник» утонул; «Британник» через пару лет утонул; «Олимпик» всю свою службу имел тяжёлые проблемы, пока не был списан к чертям.
В наличии стандартов.Вообще, стандарты есть во всех перечисленных языках.
В ПХП функции именуются как попало — факт(один из многочисленных). А теперь расскажите мне про стандарты :)
В ПХП функции именуются как попало — факт(один из многочисленных)а, ну-ка, озвучьте.
а, ну-ка, озвучьте.Ссылочку на РТ?) Цирк просто
Ссылочку на РТ?) Цирк простосоло поверхность бетономешалка
байзевей, его ответ звучал так «я разрабатывал РНР как инструмент для людей, пишущих на С под CGI. большинство функций ядра повторяют сигнатуры Сишных аналогов — это вопрос к разработчикам функций в Си, почему такая мешанина из подходов в именовании и порядка аргументов».
я хз, насколько это близко к реальности.
что я точно знаю — обратная совместимость всегда была во главе угла с РНР, потому, раз уж РНР внезапно вырос и на версии 4 стал широко использоваться,уже точно было поздно приводить в порядок зоопарк.
Лучше ли делать фунцкии-дубликаты с «упорядоченными сигнатурами», выкидывая на вызове старых вариантов «deprecated warning»?
по-моему, нет.
Реально близко. Я начинал на пхп писать в конце
import this
Выучить другой язык с той же среды, например Python, не так и тяжело. А просто это в супермаркете на кассе работать, там не надо ничего учить.
Ой, блин. Простите, невнимательно прочел :)
да Бог с Вами, это была шутка и ТС это понял
Evgeniya Pervushina
Mykhailo Lienivov
Lyova Zi
Olexandr Vovchok
Oleksandr Kucher
Максим Бублик
Євген Козлов
Владимир Чернышев
Alex Danilov
Найкращі коментарі пропустити