Comments 118
Хороший язык, что бы про него не говорили.
Докажи, что ты не лама и не баран — программируй на Perl!
dynamic.linexp.ru/Files/2a64ccee-c94e-4f76-8b14-5f6166330716.jpg
Да здравствует Perl 6! P.S. Картинка не вставляется :(
Да здравствует Perl 6! P.S. Картинка не вставляется :(
Хороший, но большие проекты на нем сложно тянуть…
Русский перевод четвертого издания «Верблюда» сейчас в работе.
>Это лёгкий в освоении и использовании язык
вы серьезно? =)
вы серьезно? =)
Вполне. Был первым который я изучил (имеется в виду, для веба), очень простой :). Если, конечно, не залазить в дебри.
>Если, конечно, не залазить в дебри.
Если не залазить в дебри, то почти все ЯП одинаковые.
Perl как раз «дебрями» и славится. (только контексты чего стоят)
PS.
10 лет пишу на Perl
Если не залазить в дебри, то почти все ЯП одинаковые.
Perl как раз «дебрями» и славится. (только контексты чего стоят)
PS.
10 лет пишу на Perl
Ну если залазить, то да. Там ужас. Просто я быстро переполз на питон, и не успел долезть до дебрей.
> Perl как раз «дебрями» и славится. (только контексты чего стоят)
А уж внутренности (C-код) — отдельная песня. В одних только названиях функций запутаться можно.
А уж внутренности (C-код) — отдельная песня. В одних только названиях функций запутаться можно.
Не знаю может мы на разных перлах пишем. По мне очень логичный язык, как только разбираешься в тех самых контекстах (пару часов на самом деле потратить), как всё становится на свои места.
Перл один из немногих языков который манипулирует явными ссылками, что как раз является для многих большим батхертом, чем «встроенные регекспы».
А появление List::Util вообще сделало из языка сказку. Правда сказка, как часто бывает, сильно запоздала и уже не вернёт языку популярность, но… 25 лет таки срок)
Перл один из немногих языков который манипулирует явными ссылками, что как раз является для многих большим батхертом, чем «встроенные регекспы».
А появление List::Util вообще сделало из языка сказку. Правда сказка, как часто бывает, сильно запоздала и уже не вернёт языку популярность, но… 25 лет таки срок)
Ну так про чтение чужого кода ничего и не сказано :)
Чтение чужого кода больше зависит от его автора, чем от языка ;)
Так в том то и дело, что авторы бывают весьма… разные :)
Это правда, но перл не случайно породил мем «write-only language».
Write only славу создали понты типа «смотрите, пацаны, как я умею». Если в языке много идиом, это не значит, что надо использовать их все. Более того, использование некоторых идиом показатель класса программиста. Невысокого. Я сам несколько лет использовал идиому map { ?:() } и очень собой гордился, пока не догадался, что есть grep { } с которым всё читается куда прозрачнее, да и пишется легче;)
PS. Для меня PHP — write_only. После того как в течении 2х недель по 10 часов вычищал из кода сопли и марсианскую логику аффилированных субподрядчиков. Теперь просто видеть пхп код не могу, не то что читать ;)
PS. Для меня PHP — write_only. После того как в течении 2х недель по 10 часов вычищал из кода сопли и марсианскую логику аффилированных субподрядчиков. Теперь просто видеть пхп код не могу, не то что читать ;)
Да, меня не нужно убеждать, я согласен с вами полностью. Ну, кроме того, что и на PHP можно писать нормальный читаемый код (правда, при этом не понятно, зачем выбирать похапе).
Так и я о чем.
Но широко известны как раз таки куски кода на перле, которые выглядят так, будто при их прочтении Ктулху восстанет со дна океана, ибо есть возможность на перле писать и таким образом.
Но широко известны как раз таки куски кода на перле, которые выглядят так, будто при их прочтении Ктулху восстанет со дна океана, ибо есть возможность на перле писать и таким образом.
Это как раз такой язык, которым пользуешься, пользуешься — а потом узнаёшь, что он ещё и ТАК вот может.
Освоить азы и начать пользоваться — легко.
Основить на 100% — нереально практически.
Освоить азы и начать пользоваться — легко.
Основить на 100% — нереально практически.
Очень похоже, что Perl сам себя до сих пор не освоил на 100%.
И у Perl есть фундаментальные теоретические проблемы вида этой: www.perlmonks.org/?node_id=663393
И у Perl есть фундаментальные теоретические проблемы вида этой: www.perlmonks.org/?node_id=663393
TIMTOWTDI!
Это был мой первый язык программирования, на котором я в 2004 году запустил информационный новостной сайт, мне было 18 лет. В журналах за 2000 год он вообще позиционировался по простоте как Basic, именно поэтому я подсел на него :)
Конкретно сейчас я не считаю его таким уже простым. Он примерно наравне с Си.
Конкретно сейчас я не считаю его таким уже простым. Он примерно наравне с Си.
Старый анекдот времен первой «Матрицы»:
ЗЫ: очень люблю Перл и с удовольствием на нем пишу, кто на синтаксис жалуется, тот на sh/bash/tcsh не писал :)
Тэнк сидит в кокпите Навуходоносора уткнувшись в экраны с зелеными кракозябрами. Сзади подходит Нео:
— Вы всегда смотрите Матрицу в коде?
— Это не Матрица, это я свой Перл-скрипт отлаживаю...
ЗЫ: очень люблю Перл и с удовольствием на нем пишу, кто на синтаксис жалуется, тот на sh/bash/tcsh не писал :)
Ну будет вам. Уж bash по синтаксису гораздо проще perl'a. Вот sed ещё может потягаться в читаемости кода, но явно не bash.
Не знаю, bash, с которым мне довольно много приходится работать мне всегда казался неинтуитивным и довольно неудобным. Все эти приколы в пробелами и двойными скобками, пляски с бубном для простейших арифметических операций, одно отсутствие возвращаемым значений у функций чего стоит!
Понятно, что дело вкуса, но практически для любой нетривиальной системной задачи, я предпочту перл башу.
Понятно, что дело вкуса, но практически для любой нетривиальной системной задачи, я предпочту перл башу.
сравнивать Perl c Bash как-то совсем не правильно…
Ага, особенно круто, когда оно ругается на пробелы.
сделайте себе правило, обрабатывайте всегда строки с помощью chop и chomp и бед не будете знать
Говоря про пробелы я имел в виду bash, прошу прощения если моя фраза ввела в заблуждение.
да, согласен, но можно попробовать задействовать typeset (во всяком случае в Korn Shell):
typeset -Ln — Выравнивает по левому краю. Удаляет находящиеся впереди пробелы; если n задано, дополняет пробелами или усекает строку справа до n символов.
typeset -Rn — Выравнивает по правому краю. Удаляет находящиеся в конце пробелы; если n задано, дополняет прбелами или усекает строку слева до n символов
typeset -Ln — Выравнивает по левому краю. Удаляет находящиеся впереди пробелы; если n задано, дополняет пробелами или усекает строку справа до n символов.
typeset -Rn — Выравнивает по правому краю. Удаляет находящиеся в конце пробелы; если n задано, дополняет прбелами или усекает строку слева до n символов
Живи долго и процветай )
Очень благодарен этом языку за его ООП (чистый bless). Когда-то давно сломало мне неправильное понимание ООП и сделало правильным. Для этих целей, наверное, даже лучше языков с ООП на прототипах.
Начинал с этого языка, когда он был ещё подростком =)
С Днем Рождения!
С Днем Рождения!
"'Да это легко', говорят только в двух случаях, в 1м, если за дело еще не взялись, во 2м, если дело уже выполнено" про Perl.
Так и знал что без «знаменитой» книжки не обойдётся.
Захотелось лизнуть шрамы…
Захотелось лизнуть шрамы…
С днюхой! Перл — язык, который не может остаться незамеченным.
Отличный язык, один из моих основных языков программирования (другой Ruby), не собираюсь с него никуда уходить!
Long live, Perl! С днем рождения, и скорейшего выпуска 6-й версии :-)
UFO just landed and posted this here
Ну хорошо, будем буквоедами, с динамической типизацией. Но вы же поняли о чём я говорю.
Вы, скорее всего, не правильно выразили свою мысль.
Большинство современных популярных языков с динамической типизацией реализуют парадигму ООП. Во многих она является доминирующей.
Большинство современных популярных языков с динамической типизацией реализуют парадигму ООП. Во многих она является доминирующей.
Парадигму ООП можно реализовать на чём угодно и как угодно.
Но использование ООП ради парадигмы — удел либо академических исследователей, которые хорошо понимают, что делают, либо недалёких школьников, которые не понимаю смысла используемого инструмента.
ООП полезно, когда оно помогает в разработке и первая помощь — контроль типов. Типы (классы) в ООП — ключевая концепция.
В перле же, нормальная практика, когда конструктор возвращает undef. Вдумайтесь. Конструктор возвращает не объект. И это общепринято!
А почему появилось такое извращение? Да потому, что в перл ООП сделано ради парадигмы, а не чтобы помочь программисту или сделать код более стабильным и предсказуемым.
Но использование ООП ради парадигмы — удел либо академических исследователей, которые хорошо понимают, что делают, либо недалёких школьников, которые не понимаю смысла используемого инструмента.
ООП полезно, когда оно помогает в разработке и первая помощь — контроль типов. Типы (классы) в ООП — ключевая концепция.
В перле же, нормальная практика, когда конструктор возвращает undef. Вдумайтесь. Конструктор возвращает не объект. И это общепринято!
А почему появилось такое извращение? Да потому, что в перл ООП сделано ради парадигмы, а не чтобы помочь программисту или сделать код более стабильным и предсказуемым.
Типы (классы) в ООП — ключевая концепция.
- Инкапсуляция
- Наследование
- Полиморфизм
Где тут типы?
ООП на прототипах — IO(имеете право не знать) и JavaScript.
Ruby и питон… Попытайтесь рассказать про «неправильность» ООП в этих языках программистам, на них пишущим. И про то, что ООП там ради парадигмы.
Статическая типизация и ООП ортогональны.
Есть множество не ООП языков о статической типизацией.
У меня есть подозрение, что вы не понимаете что такое ООП.
> Где тут типы?
Толсто, но отвечу.
Инкапсуляция — сокрытие данных в объектах. Причём не любых данных в любых объектах (как это сделано в Perl), а определённых данных в объектах определённых типов (хорошо, когда язык помогает вылавливать ошибки соответствия данные-тип).
Наследование — механизм описания одного типа на основе другого типа.
Полиморфизм — возможность типов с одинаковой спецификацией иметь различную функциональность.
Вам предстоит открыть ещё очень много нового для себя :-)
Толсто, но отвечу.
Инкапсуляция — сокрытие данных в объектах. Причём не любых данных в любых объектах (как это сделано в Perl), а определённых данных в объектах определённых типов (хорошо, когда язык помогает вылавливать ошибки соответствия данные-тип).
Наследование — механизм описания одного типа на основе другого типа.
Полиморфизм — возможность типов с одинаковой спецификацией иметь различную функциональность.
Вам предстоит открыть ещё очень много нового для себя :-)
Вмешаюсь в спор. Вы приводите удобные для себя варианты определений. Например, в википедии определения несколько другие:
Не в одном определении нет требования строгой типизации.
Encapsulation (object-oriented programming)
In a programming language, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:
A language mechanism for restricting access to some of the object's components.
A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both, depending upon programming language support.
In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface.
Не в одном определении нет требования строгой типизации.
Из каких же, по вашему, соображений происходит restricting access? Кстати, в перле этого нет.
Что это за слово такое вкралось у вас subtype?
И что это за data types?
Вы выбрали эти варианты определений в угоду мне? ,-)
Что это за слово такое вкралось у вас subtype?
И что это за data types?
Вы выбрали эти варианты определений в угоду мне? ,-)
Кстати, в перле этого нет.
Даже в пятом перле есть ограничение доступа к внутреннему состоянию объекта при помощи замыкания.
И что это за data types?
В вики там ссылка.
Обобщенное понятие, зависит от языка.
Что это за слово такое вкралось у вас subtype?
Это один из вариантов. «depending upon programming language support». Если ООП на иерархии классов — то через наследование. Иначе прототип
У вас выборочная слепота?
Вы в одной фразe ухитряетесь опровергнуть собственные утверждения. Вы говорите, что поддержана ООП-парадигма инкапсуляция через замыкания. То есть нет приватности, а инкапсуляция имитируется другими средствами, которые есть и не в ООП-языках и к ООП никакого отношения не имеют. И так далее по пунктам.
Но я с этого и начал, что парадигмы ООП можно реализовать и использовать без поддержки ООП языком. Только толку от этого нет. С таким же успехом можно говорить что Perl/C/AWK — функциональные языки. В них действительно можно использовать функциональный подход, но это не даст вам значительных преимуществ. Точно так же и ООП методология без ООП в языке — пустой фетиш.
Но я с этого и начал, что парадигмы ООП можно реализовать и использовать без поддержки ООП языком. Только толку от этого нет. С таким же успехом можно говорить что Perl/C/AWK — функциональные языки. В них действительно можно использовать функциональный подход, но это не даст вам значительных преимуществ. Точно так же и ООП методология без ООП в языке — пустой фетиш.
инкапсуляция через замыкания. То есть нет приватности
Вы в очередной раз путаете идею с реализацией.
Идея: отделение контракта от реализации через сокрытие (инкапсуляцию) реализации.
Реализация в некоторых, привычных вам, языках: приватные поля и методы.
Это лишь одна из возможных реализаций. Почему вы называете ее единственно верной? Почему все остальные реализации — не ООП?
Что вы подразумеваете под «поддержкой ООП языком»? По моему вы сейчас изобретаете свое, единственно верное понятие «язык с поддержкой ООП».
«Я придумал термин „объектно-ориентированный“, но я вовсе не имел в виду C++.»
Alan Kay. Создатель Smalltalk
Как бы это не выглядело, когда я рекомендовал вам почитать про синдром утенка — это не был сарказм. И я абсолютно точно не хотел вас оскорбить и не ставил под сомнение ваши интеллектуальные способности.
Просто постарайтесь, пожалуйста, отделить ООП (простую концепцию с четко сформулированным набором целей и средств их достижения) от вашего представления о правильной реализации ООП.
Я даже не собираюсь возражать против того, что ваше понимание правильной реализации является лучшим в мире. Просто отделите ваше экспертное (без кавычек) мнение от терминологии.
Инкапсуляция — сокрытие данных в объектах. Причём не любых данных в любых объектах (как это сделано в Perl), а определённых данных в объектах определённых типов
Вы не понимаете что такое инкапсуляция и зачем она нужна.
Инкапсуляция — это сокрытие реализации. Не только и не столько данных, но и методов.
Нужна она для отделения контракта от реализации.
В языках с привычной вам реализацией ООП контракт обычно представляется в виде интерфейса. Интерфейс не определяет какие данные сокрыты в конкретном наследнике. Если интерфейс гарантирует метод получения каких-либо данных, то в наследнике может быть как сокрыты эти данные, так и метод получения этих данных из астрала или расчет их исходя из текущей фазы луны.
Так что ваше утверждение про сокрытие «определенных данных» полностью противоречит идее инкапсуляции. Не определенных данных, а любых, достаточных для реализации публичного контракта.
Наследование — механизм описания одного типа на основе другого типа.
Наследование не требует наличия типов.
Наследование — это определение новой реализации на основе существующей.
Для примера — прототипное наследование не требует классов.
К слову о классах: понятие типа различается от языка к языку.
Полиморфизм — возможность типов с одинаковой спецификацией иметь различную функциональность.
Википедия, откуда вы это скопировали — плохой источник. Читайте хотя бы англоязычную, если уж гуглите определение. Хотя может вы это и не с вики скопировали — безграмотные утверждения разлетаются быстро.
Полиморфизм — возможность работать с объектами (обобщенное понятие) различных типов (см далее) одинаковым образом.
Объекты — абстрактные сущности в зависимости от языка. Это могут быть, например, функции в ФП языке.
Типы здесь — обобщенное понятие. Для общего развития предлагаю посмотреть что такое утиная типизация.
Еще рекомендую посмотреть «синдром утенка». Вы, как и многие другие люди, познакомившиеся с ООП в статически типизированном языке, путаете идеи ООП с его конкретной реализацией.
Например путаете наследование (идею) с иерархией классов (реализация).
Путаете интерфейсы (реализация) и публичным контрактом (идея).
Инкапсуляция — сокрытие данных в объектах.
В вашем комментарии столько не верных утверждений, что все за раз не разгрести.
Инкапсуляция не монопольно принадлежит ООП. Сокрытие данных и реализаций — одна из основ любой модульности. Даже если это сокрытие основано на конвенциях.
Но даже без конвенций, а в явном виде есть несколько вариантов инкапсуляции, не привлекающих объекты.
Ярчайшими примерами являются акторы. например в Erlang.
Так же распространенный способ — лямбды.
Вспомните истоки ООП. Например отправка сообщений как средство коммуникации между объектами в Smalltalk. Похожая идеология в IO, дающая прозрачность благодаря идеологии пересылки не обработанных сообщений прототипу. И, названные выше акторы, идейно схожи в этом отношении со Smalltalk.
Но использование ООП ради парадигмы — удел либо академических исследователей, которые хорошо понимают, что делают, либо недалёких школьников, которые не понимаю смысла используемого инструмента.
Разовью мысль про ваше не понимание ООП.
Используют парадигму ООП для получения плюсов в архитектурном плане.
ООП — это подход к созданию архитектуры, разделению ответственности, сокрытию реализации, etc.
Проверка типов находится на более низком, синтаксическом уровне. И к ней ООП не имеет ни малейшего отношения.
Ликбез по типизации (для тех, кто не видел эту статью)
return undef, к тому-же, в контектсе массива, внезапно, истинен.
Хотя об этом написано и в PBP. Забавно то, какого размера эта книжка.
Хотя об этом написано и в PBP. Забавно то, какого размера эта книжка.
Имел как-то спор с человеком, утверждавшим, что ядро Linux не ООП, поскольку написано на C. Аргументы типа «так же как в C++ реализовано» не действовали.
А питон?
Сложнее найти популярный динамически типизированный язык без ООП.
Python проверяет типы. Вы не можете даже сравнивать разные типы.
В Perl же, конструктор может вернуть не объект, а undef. И, кстати, во всех класса-потомках это надо обязательно проверять, а то без всяких ошибок программа начнёт работать совсем не так. (И где тут, кстати, повторное использование кода?)
В Perl же, конструктор может вернуть не объект, а undef. И, кстати, во всех класса-потомках это надо обязательно проверять, а то без всяких ошибок программа начнёт работать совсем не так. (И где тут, кстати, повторное использование кода?)
Python проверяет типы. Вы не можете даже сравнивать разные типы.
Похоже имеет место не совпадение терминологий. Вот недавняя статья Ликбез по типизации в языках программирования. Ранее вы употребили характеристику «с динамической типизацией». Сейчас говорите о строгой типизации.
Многие, включая меня, с вами согласятся в том, что не строгая типизация менее удобна и приводит к ошибкам.
В Perl же, конструктор может вернуть не объект, а undef.
Почему-то большинство смирились с тем, что почти во всех ЯП любой метод вместо объекта может вернуть null (на мой взгляд это зло). Многие методы не должны возвращать null и такой вариант не проверяют отдельно.
В Perl конструктор не должен возвращать undef и этот вариант можно не проверять. Кстати, почему без ошибок?
Почему-то большинство смирились с тем, что почти во всех ЯП любой метод вместо объекта может вернуть null (на мой взгляд это зло).
Мир вообще несправедлив.
А что должен возвращать метод, что-то внутри сломалось, но ситуация штатная? Исключение бросить?
что-то внутри сломалось
Бросить исключение.
ситуация штатная
Option, Maybe, Nullable, как_бы_это_ни_называлось.
В статически типизированных языках это идеальный способ документирования опциональных значений.
Option, Maybe, Nullable, как_бы_это_ни_называлось
И чем это отличается от nil?
«nil» — из какого языка? Просто в scala Nil — пустой List.
Если вы про null (scala, java, C#), то отличия:
В случае динамической типизации применимы другие подходы.
Если вы про null (scala, java, C#), то отличия:
- Документирование на уровне типов.
- Проверка компилятором. Принципиально исключается NRE.
- Упрощенная запись при использовании преимуществ монад (map, единый способ использования с другими контейнерами).
В случае динамической типизации применимы другие подходы.
Я про null, да, прошу прощение. То ли я слишком отдалился от языков со статической типизацией, то ли я тупой ;-)
1. Какое может быть документирование, если объект не создан? Должен был, но что-то не получилось. Какая разница, null вернулся, или Nullable? Если ситуация штатная, ее отдельно отрабатывать не нужно, иначе — ошибка проектирования. Если нештатная — исключение, сами же говорите.
2. Чем вам так NRE не угодил? Вы все равно ничего хорошего сообщить не сможете.
3. Не вижу проблем унификации с возвращаемым нуллом.
Короче, неубедительно (лично для меня).
1. Какое может быть документирование, если объект не создан? Должен был, но что-то не получилось. Какая разница, null вернулся, или Nullable? Если ситуация штатная, ее отдельно отрабатывать не нужно, иначе — ошибка проектирования. Если нештатная — исключение, сами же говорите.
2. Чем вам так NRE не угодил? Вы все равно ничего хорошего сообщить не сможете.
3. Не вижу проблем унификации с возвращаемым нуллом.
Короче, неубедительно (лично для меня).
- Документирование того, что метод может не упав с ошибкой вернуть результат. Далеко не во всех методах невозможность вернуть результат является штатным поведением, не требующим броска исключения.
Так же это документирование того, что параметр является не обязательным (не путать со значениями по умолчанию). - NRE чаще всего происходит по принципу «забыли проверить». В случае монад такая ситуация исключается.
- Тут можно привести множество примеров кода, показывающих насколько удобны такие конструкции.
Я чаще всего использую map, getOrElse и конкатенацию с коллекцией.
Короче, неубедительно (лично для меня).
Я уже участвовал в обсуждениях на хабре этого вопроса, мне уже не так интересно его снова обсуждать, но, если хотите, могу дать ссылок на обсуждения.
Вот пример.
Кусок кода оттуда:
// with potential nulls
val father = if (person == null) null else person.father
val mother = if (father == null) null else father.mother
val sister = if (mother == null) null else mother.sister
// with options
val fathersMothersSister = for {
father <- person.father
mother <- father.mother
sister <- mother.sister
} yield sister
Все это звучит как «помощь в программировании бухгалтеру». Кусок кода даже комментировать неохота. Так ужасно я смогу и на скале́ написать.
Не хочу, спасибо. Вы не сможете придумать пример полезности возвращения не нулла. Если «метод может не упав с ошибкой вернуть результат» — ну пусть он это сделает. Если не может — пусть вернет null, а не какое-то говно, придуманное программистами, не умеющими работать с ошибками.
Не хочу, спасибо. Вы не сможете придумать пример полезности возвращения не нулла. Если «метод может не упав с ошибкой вернуть результат» — ну пусть он это сделает. Если не может — пусть вернет null, а не какое-то говно, придуманное программистами, не умеющими работать с ошибками.
Аминь!
Остается только добавить, что настоящие программисты не используют Паскаль.
Остается только добавить, что настоящие программисты не используют Паскаль.
Ровно наоборот. Паскаль — тоже прекрасный язык.
Прошу прощения, предполагал источник фразы очевидным.
UFO just landed and posted this here
Хехе, а девелоперам на языке, который задумывался как «перл для бедных» — живется хорошо? :)
Я вот например совсем не перл-девелопер, но знание этого языка позволяют одной строчкой решать задачи, которы практически во всех других языках займут от десятков до сотен строк кода. Так что это спорный вопрос: кому тажело живется :)
Я вот например совсем не перл-девелопер, но знание этого языка позволяют одной строчкой решать задачи, которы практически во всех других языках займут от десятков до сотен строк кода. Так что это спорный вопрос: кому тажело живется :)
UFO just landed and posted this here
Имеете ввиду PHP или Ruby? Или какой-то другой язык?
А вы как думаете?
сомнительно.
То, что вы незнакомы с one-liner'ами говорит только о том, что вы никода не писали на Перле, или как минимум ваше знакомство с языком крайне поверхностное.
UFO just landed and posted this here
Ну вот я, например, с ванлайнерами знаком. Покажите что-нибудь, что нереализуемо в одну строку ни на одном из известных мне языков (я и sed/awk люблю, и шелл умею, и в руби не первый день, и дотнет всегда под рукой).
Перл хорош, спору нет. Но не настолько, как вы тут пытаетесь нам рассказать.
Перл хорош, спору нет. Но не настолько, как вы тут пытаетесь нам рассказать.
На других языках legacy кода уже нет?
UFO just landed and posted this here
Не вижу чтобы тут www.indeed.co.uk/Perl-Developer-jobs-in-London большинство вакансий было поддержкой.
www.indeed.co.uk/viewjob?jk=214d473a5af06c3b&q=Perl+Developer&l=London&tk=17eos89vk146165g&from=web — (первая по ссылке) — поддержка
www.cwjobs.co.uk/JobSearch/JobDetails.aspx?JobId=55354985 — join the team
careers.joelonsoftware.com/jobs/27567/perl-developer-opsview-limited?a=wzlvJBu " capable of delivering new features in our Opsview product suite"
Не знаю, как насчёт большинства, но значительная часть — поддержка.
www.cwjobs.co.uk/JobSearch/JobDetails.aspx?JobId=55354985 — join the team
careers.joelonsoftware.com/jobs/27567/perl-developer-opsview-limited?a=wzlvJBu " capable of delivering new features in our Opsview product suite"
Не знаю, как насчёт большинства, но значительная часть — поддержка.
Вторая ссылка
«You will be given the opportunity to work with the cutting edge of technology»
вообще что мы ищем?
Я искал явные упоминания о том что код старый или о том что нужная его поддержка (багфиксы, минимум новых фич, перевод на новую версию)
Если просят добавить новые фичи или «cutting edge of technology» — это разве поддержка legacy кода?
Если искать только объявления где сказано что продукта (кода) ещё нет и его будем только делать, то таких мало и не только в Perl.
«You will be given the opportunity to work with the cutting edge of technology»
вообще что мы ищем?
Я искал явные упоминания о том что код старый или о том что нужная его поддержка (багфиксы, минимум новых фич, перевод на новую версию)
Если просят добавить новые фичи или «cutting edge of technology» — это разве поддержка legacy кода?
Если искать только объявления где сказано что продукта (кода) ещё нет и его будем только делать, то таких мало и не только в Perl.
Это такой намёк что если кто-то программирует на Perl, то это обязательно старый древний код?
Вот полтора года назад видел как начанался новый проект на Perl, с нуля. Код был и типичный «web 2.0» веб сайт и нечно более сложное. Получили в этом году несколько миллионов евро инвестиций.
Видел проект, где код — ruby, старой версии, документации нет, тестов нет, комментариев нет. Чтобы разобраться с ним у коллектива ушло больше времени чем на написание (с нуля нельзы было писать, т.к. всё было отлаженно юзерами, к тому же не хотелось юзеров переучивать)
Реально тяжело Ruby developer'ам. Написал код, а он через пару лет уже устарел, все библиотеки не совместимы с новой версией языка, разработчиков под старую версию уже не найти (не охота им с этим возиться).
Кстати, скрит на perl 10-летней давности, скорее всего запустится в новой версии интерпретатора без особых проблем.
Вот полтора года назад видел как начанался новый проект на Perl, с нуля. Код был и типичный «web 2.0» веб сайт и нечно более сложное. Получили в этом году несколько миллионов евро инвестиций.
Видел проект, где код — ruby, старой версии, документации нет, тестов нет, комментариев нет. Чтобы разобраться с ним у коллектива ушло больше времени чем на написание (с нуля нельзы было писать, т.к. всё было отлаженно юзерами, к тому же не хотелось юзеров переучивать)
Реально тяжело Ruby developer'ам. Написал код, а он через пару лет уже устарел, все библиотеки не совместимы с новой версией языка, разработчиков под старую версию уже не найти (не охота им с этим возиться).
Кстати, скрит на perl 10-летней давности, скорее всего запустится в новой версии интерпретатора без особых проблем.
Перл развивается медленнее, но всё-таки развивается и это создаёт проблемы, когда, например, надо проапгрейдить или сменить дистрибутив.
А в ruby есть rvm, bundler, с ними можно буквально каждому приложению создать своё замороженное окружение, зафиксировать все версии библиотек и оно не будет мешать остальным и системным библиотекам.
Так что тут всё не так однозначно.
А в ruby есть rvm, bundler, с ними можно буквально каждому приложению создать своё замороженное окружение, зафиксировать все версии библиотек и оно не будет мешать остальным и системным библиотекам.
Так что тут всё не так однозначно.
Создание изолированных окружений это одна проблема, она не отменяет портирование кода в новые версии языка (т.к. просто программистов и библиотек по старые не найти).
У perl так же есть perlbrew, функций там поменьше чем в rvm, зато он не написан на bash/zsh.
Bunlder перлу просто не нужен ИМХО, можно указывать минимальные версии подключаемых библиотек, а как таковой проблемы с gem hell как в ruby просто нет.
Мне кажется это связано с monkey patching в ruby (к этом сила и слабость ruby одновременно) — например, вы подключили gem, а он модифицировал код в каком-то другом (системном) геме, из-за этого проявляется ошибка.
Кстати создавать каждому приложению изолированные окружения — это не такое уж и «бесплатное» решение — усложняется deploy на production, или, например rvm+passenger в случае с разными версиями ruby, или не работал нормально или не был stable, когда я последний раз смотрел.
У perl так же есть perlbrew, функций там поменьше чем в rvm, зато он не написан на bash/zsh.
Bunlder перлу просто не нужен ИМХО, можно указывать минимальные версии подключаемых библиотек, а как таковой проблемы с gem hell как в ruby просто нет.
Мне кажется это связано с monkey patching в ruby (к этом сила и слабость ruby одновременно) — например, вы подключили gem, а он модифицировал код в каком-то другом (системном) геме, из-за этого проявляется ошибка.
Кстати создавать каждому приложению изолированные окружения — это не такое уж и «бесплатное» решение — усложняется deploy на production, или, например rvm+passenger в случае с разными версиями ruby, или не работал нормально или не был stable, когда я последний раз смотрел.
UFO just landed and posted this here
Основные программисты, что это писали, знали, как минимум Java и Perl. Не уверен на счёт других языков.
Но я работал с этим кодом, думаю, например, ruby с rails там бы не прижился, код имел отношение не только в Web, но и к обработке больших массивов данных, так же подход к программированию был творческий, применялось KISS (с элементами отрицания DRY), использовались нестандартные паттерны (опять же многие другие подходы отрицались), был изобретён собственный маленький функциональный язык программирования для одной из маленьких задач.
Но я работал с этим кодом, думаю, например, ruby с rails там бы не прижился, код имел отношение не только в Web, но и к обработке больших массивов данных, так же подход к программированию был творческий, применялось KISS (с элементами отрицания DRY), использовались нестандартные паттерны (опять же многие другие подходы отрицались), был изобретён собственный маленький функциональный язык программирования для одной из маленьких задач.
«Почему вы выбрали БАК, когда вам бы подошёл обычный синхротрон?»
«Ну, у нас были люди, которые знали БАК, поэтому его и выбрали»
Я как-то всегда думал, что ЯП — это инструмент. И инструмент выбирают не из принципа «что знаю то пою» а осваивают новые, при необходимости. И вот не поверю, что «обработку больших массивов данных» Perl умеет хорошо (за исключением текста, конечно).
«Ну, у нас были люди, которые знали БАК, поэтому его и выбрали»
Я как-то всегда думал, что ЯП — это инструмент. И инструмент выбирают не из принципа «что знаю то пою» а осваивают новые, при необходимости. И вот не поверю, что «обработку больших массивов данных» Perl умеет хорошо (за исключением текста, конечно).
Perl как раз умеет это хорошо.
На счёт выбора инструмента — кто будет начинать свой стартап с изучения нового языка (из соображений что кто-то где-то написал что он хорошо подходит к задачи)?
На счёт выбора инструмента — кто будет начинать свой стартап с изучения нового языка (из соображений что кто-то где-то написал что он хорошо подходит к задачи)?
Например: если вы хотите писать многопотоковое и сетевое, то проще выучить Erlang, чем POE (даже зная Perl). Это кроме того, что в POE много ошибок.
Приведите пример Perl'а для обработки «больших массивов данных» (не текстовых).
Я заметил, что когда знаешь 5 ЯП, шестой учится проще. Поэтому для меня не проблема выбирать язык под задачу. Это кроме того что в некоторых местах язык является данностью — например, в ядре Linux.
Приведите пример Perl'а для обработки «больших массивов данных» (не текстовых).
Я заметил, что когда знаешь 5 ЯП, шестой учится проще. Поэтому для меня не проблема выбирать язык под задачу. Это кроме того что в некоторых местах язык является данностью — например, в ядре Linux.
Большие массивы текстовых данные это какие?
1) Большие куски не структурированного текста
2) Структурированные данные, текстовые строки, числа, например всё то что находится в реляционной БД
3) Большие куски бинарных данныех — картинки, архивы, зашифрованные файлы.
Со всем этим perl хорошо справляется, п.3. — естественно native кодом, вызов библиотек для обработки картинок, например. никто же не будет на динамическом языке анализировать каждый пиксель.
Про многопотоковое сетевое — это смотря что это значит. Приведите пример. Обычно сервера отлично пишутся на perl, и нужно там POE или нет зависит от задачи.
1) Большие куски не структурированного текста
2) Структурированные данные, текстовые строки, числа, например всё то что находится в реляционной БД
3) Большие куски бинарных данныех — картинки, архивы, зашифрованные файлы.
Со всем этим perl хорошо справляется, п.3. — естественно native кодом, вызов библиотек для обработки картинок, например. никто же не будет на динамическом языке анализировать каждый пиксель.
Про многопотоковое сетевое — это смотря что это значит. Приведите пример. Обычно сервера отлично пишутся на perl, и нужно там POE или нет зависит от задачи.
Данные бывают ещё и «числовые» и не только бинарные.
И вот тут у Perl начинаются проблемы — поскольку Perl для науки (почти) умер с появлением scipy и numpy.
Perl, если что, разрабатывался для анализа текста. И хорошо служит для этой задачи. Для других задач подходит, на мой взгляд, хуже чем Python.
Про сервера: и много существует многопоточных framework'ов для написания сетевого приложения на Perl? Coro, POE, Any? И какой порог вхождения в эти фреймворки?
И какова цена ошибки в этих фреймворках для пользователя — сколько времени потребуется программисту для отладки ошибки в Coro? (Вообще, Perl изнутри устроен жутко — одни имена функций его коде чего стоят)
И вот тут у Perl начинаются проблемы — поскольку Perl для науки (почти) умер с появлением scipy и numpy.
Perl, если что, разрабатывался для анализа текста. И хорошо служит для этой задачи. Для других задач подходит, на мой взгляд, хуже чем Python.
Про сервера: и много существует многопоточных framework'ов для написания сетевого приложения на Perl? Coro, POE, Any? И какой порог вхождения в эти фреймворки?
И какова цена ошибки в этих фреймворках для пользователя — сколько времени потребуется программисту для отладки ошибки в Coro? (Вообще, Perl изнутри устроен жутко — одни имена функций его коде чего стоят)
И какой порог вхождения в эти фреймворки?perldoc AnyEvent/Coro — можно въехать весьма быстро
И какова цена ошибки в этих фреймворках для пользователяпримерно такая же как для фреймворков других языков )
Вообще говоря внутренности Perl куда хуже, чем внутренности PHP/Python. Если в последних можно разобраться за пару часов, то на внутренности Perl я убил пару недель но так и не смог запомнить всевозможных *v?V*. Поэтому ошибку в stackless (мне кажется) с нуля отследить проще.
А в Erlang так их просто меньше, поскольку весь язык заточен под многопоточный обмен сообщениями.
А в Erlang так их просто меньше, поскольку весь язык заточен под многопоточный обмен сообщениями.
Это все фреймворки не для многопоточных приложений а multiplexing. Я этим не занимался вообще, так что незнаю.
По поводу многопоточных серверов в плане системного программирования:
Есть fork(), в случае perl можно быть уверенным что если собрались писать сервер (веб сервер, прокси сервер — системное программирование), то он заработает. Сигналы, потоки, библиотеки всё хорошо изучено в этом плане. Фреймворк для системного программирования не нужен.
Тоже хорошо подходят для серверов вроде python и java. Ruby — плохо, его без rails не используют.
Настоящих threads в perl нет.
по поводу числовых данных
По поводу многопоточных серверов в плане системного программирования:
Есть fork(), в случае perl можно быть уверенным что если собрались писать сервер (веб сервер, прокси сервер — системное программирование), то он заработает. Сигналы, потоки, библиотеки всё хорошо изучено в этом плане. Фреймворк для системного программирования не нужен.
Тоже хорошо подходят для серверов вроде python и java. Ruby — плохо, его без rails не используют.
Настоящих threads в perl нет.
по поводу числовых данных
perl -Mbignum -le 'print ref(2**255)'
Приведите пример Perl'а для обработки «больших массивов данных»PDL
JIT оно умеет? (Numba)
Поддерживает лёгкое написание кода на C-подобном языке? (Cython)
Есть модули для OpenCL/CUDA? (pyCUDA, copperhead) Есть модули для регрессии? (Theano)
Поддерживает лёгкое написание кода на C-подобном языке? (Cython)
Есть модули для OpenCL/CUDA? (pyCUDA, copperhead) Есть модули для регрессии? (Theano)
PDL::FAQ
metacpan.org/module/OpenCL
github.com/run4flat/perl-CUDA-Minimal
+ есть Inline::C, Inline::CPP
metacpan.org/module/OpenCL
github.com/run4flat/perl-CUDA-Minimal
+ есть Inline::C, Inline::CPP
PDL и Inline::C сравните с ctypes/f2py в Python. Просто берёте фортран код, натравливаете на него f2py и вызываете его этот код из Python. С ctypes немного иначе — описываете аргументы функции и вызываете её прямо из C кода.
Это несравнимо проще, чем:
(Про Cython вообще молчу)
Аналогов Numba (http://numba.pydata.org/), видимо, нет, а жаль.
perl-CUDA не юзабелен и находится в версии 0.01 уже год.
Из всего списка, в общем, есть только OpenCL, а про вещи типа scipy/matplotlib/Theano мечтать и не приходится.
Это несравнимо проще, чем:
use Inline C;
greet('Ingy');
greet(42);
__END__
__C__
void greet(SV* sv_name) {
printf("Hello %s!\n", SvPV(sv_name, PL_na));
}(Про Cython вообще молчу)
Аналогов Numba (http://numba.pydata.org/), видимо, нет, а жаль.
perl-CUDA не юзабелен и находится в версии 0.01 уже год.
Из всего списка, в общем, есть только OpenCL, а про вещи типа scipy/matplotlib/Theano мечтать и не приходится.
Q: 7.2 Can I access my C/FORTRAN library routines in PDL?
есть PDL::Graphics::Gnuplot, PDL::Graphics::PLplot и др.
PDL пока без GPU — это да )
perl-CUDA не юзабеленblogs.perl.org/users/david_mertens/2011/06/perls-first-real-cuda-bindings-released.html
про вещи типа scipy/matplotlib/Theano мечтать и не приходится.scipy это и есть аналог pdl
есть PDL::Graphics::Gnuplot, PDL::Graphics::PLplot и др.
PDL пока без GPU — это да )
но пока можно руками: blogs.perl.org/users/david_mertens/2011/06/cuda-and-the-perl-data-language.html
OnYourLips, можно личный вопрос? Как программист, пишущий на другом языке, объясните причины, почему и зачем вы критикуете этот язык? Спасибо.
Вива, Perl!
print grep($_=pack("c",hex($_)),unpack("A2"x 25,"4a75737420616e6f74686572205065726c206861636b65722 c"))
с днем рождения, Кормилец! =)
А языку программирования Perl сегодня исполнилосьБЫ 25 лет
Мой любимый язык и имхо самый элегантный и дающий наиболее широкий простор для фантазии :)
Sign up to leave a comment.
Языку программирования Perl сегодня исполнилось 25 лет