Re: А какие технологии сейчас модные?
>грамотно и качественно писать на перле сложно
Сложно, но можно научиться.
Сложно, но можно научиться.
что грамотно и качественно писать на перле сложно
Интересно, чем же это сложнее, чем, например, на C/C++?
По-моему, это зависит от программиста и заточки его рук, а не от инструмента.
ну вот чтобы заточить руки надо потратить много времени и немного порюхать, как работает компилер
Вот, например, почему (изветная статья про перл): http://stingray.nm.ru/rus/research/perl.htm
Скажем, если писать на функциональном языке, то ошибок будет еще меньше чем в джаве, а в джаве - меньше, чем в С++.
Скажем, если писать на функциональном языке, то ошибок будет еще меньше чем в джаве, а в джаве - меньше, чем в С++.
твоя ссылка ведёт сюда
Пардон, поправил.
Начал читать. Странная, надо сказать, статья. Не стоит ее воспринимать всерьез. Ну вот хотя бы:
Автор статьи явно не ознакомился с такими историческими фактами, как: Javadoc является потомком Doxygen; Doxygen младше, чем Perl. Вполне естественно, что в Perl не использовали то, что придумали уже после создания языка.
Update:
дочитать до конца не хватило сил. Впечатление, оставленное первой третью (и его не изменило прочтение заключения) простое: автора в свое время заставляли писать на Perl, и у него это плохо получалось. Либо его не взяли на работу, где нужно было хорошо писать на Perl. Либо у него кто-то из родственников покончил собой от того, что писал на Perl. В любом случае, образцами хорошего программирования на Perl те куски своего кода, которые он приводит, назвать нельзя. И уж что совершенно точно - автор очень сильно завидует автору перла, и очень часто упоминает его имя в тексте статьи.
Короче говоря, не обращайте внимания на этот бред, хотя почитать забавно
Кстати, поддержка документирующего комментария как отдельного синтаксического средства представляется избыточным – при должной реализации соответствующей утилиты выделения документации из исходного модуля (в случае PERL это perldoc) можно было бы обойтись многострочным комментарием с включением в него специальных тегов, распознаваемых этой утилитой.
У любого здорового программиста в связи с этим возникает один вопрос: а что мешало сделать так, как сделано, скажем, в Java? Это вопрос чисто риторический – трюкачество без меры есть стиль программирования, навязываемый языком PERL.
Автор статьи явно не ознакомился с такими историческими фактами, как: Javadoc является потомком Doxygen; Doxygen младше, чем Perl. Вполне естественно, что в Perl не использовали то, что придумали уже после создания языка.
Update:
дочитать до конца не хватило сил. Впечатление, оставленное первой третью (и его не изменило прочтение заключения) простое: автора в свое время заставляли писать на Perl, и у него это плохо получалось. Либо его не взяли на работу, где нужно было хорошо писать на Perl. Либо у него кто-то из родственников покончил собой от того, что писал на Perl. В любом случае, образцами хорошего программирования на Perl те куски своего кода, которые он приводит, назвать нельзя. И уж что совершенно точно - автор очень сильно завидует автору перла, и очень часто упоминает его имя в тексте статьи.
Короче говоря, не обращайте внимания на этот бред, хотя почитать забавно
сломался на половине -- редкий бред. автор явно не знает и не понимает перла, даже ошибки комментировать ломает, уж больно их много
вспоминая незабвенного луговского: эту мразь надо было пристрелить в детстве, как этот ублюдок смеет еще что-то говорить?
вспоминая незабвенного луговского: эту мразь надо было пристрелить в детстве, как этот ублюдок смеет еще что-то говорить?
У меня нет никакого особо предвзятого мнения по отношению к перлу. Однако, имхо 30% того, что написанно в этой статье верно, еще 30% не верно, а над оставшимся стОит подумать.
Интересно, что если выйти в users group на google.com, то там народ, обсуждая эту статью, так и не смог аргументировано ответить ни на одно из серьезных обвинений против перла.
Интересно, что если выйти в users group на google.com, то там народ, обсуждая эту статью, так и не смог аргументировано ответить ни на одно из серьезных обвинений против перла.
Интересно, что если выйти в users group на google.com, то там народ, обсуждая эту статью, так и не смог аргументировано ответить ни на одно из серьезных обвинений против перла.
Конечно же не смог. Да и не смог бы. Но дело не в том, что Перл настолько плох, как утверждает автор статьи, а в самой структуре статьи. Она построена по принципу: приводится пример плохого кода на perl, а потом рассказывается что это плохой код, и что это можно на perl. По такому принципу я могу раскритиковать любой из языков, которые достаточно хорошо знаю. Серьезно к этой статье стоило бы относиться только в том случае, если бы она была построена подругому: приводился бы пример отличного кода на perl, и дальше говорилось бы: "смотрите, это самое лучшее, на что способен perl, и все равно получается плохо". А так... несерьезно. Плохой код можно писать не любом языке.
Нет. Я с тобой не согласен. Но, честно говоря, спорит желания особого нет. Если тебе интересна истина, глубоко задумайся, абсолютно ли (во всех ли аспектах) ты прав, говоря "Плохой код можно писать не любом языке.".
PS а меня тут передумали в ГЗ селить, так что ухожу в радио-молчание, до прояснения обстановки
PS а меня тут передумали в ГЗ селить, так что ухожу в радио-молчание, до прояснения обстановки
Поддерживаю Sardukara.
Замечу, что для новичков (а также тех людей, которые знакомы с языком поверхностно) важнее не то, сколько язык позволяет использовать хороших, удобных, правильных и т.д. способов решения, способов написания программ, а важнее сколько запрещается делать неправильных, кривых и т.д. способов написания кода.
Примеры:
C++ - разрешает работать напрямую работать с памятью, Java - запрещает работать с памятью => следствие большинство программ на Java работают стабильнее, чем большинство программ на C, а также программы на Java пишутся(отлаживаются) много быстрее
C++/Java/C# - запрещают (вернее не приветствуют, не предоставляют удобных инструментов) динамическую типизацию, Smalltalk - пропагандирует => следствие опять же на C++/Java/C# на начальных этапах программы пишутся быстрее и отлаживаются быстрее.
Perl, как раз скорее пропагандирует, все дозволенность: отсутствие типизации, возможность необъявления переменных, работа через CGI, когда не различается откуда переменная пришла (изнутри пришла или от пользователя) и т.д. Вот вся эта вседозволенность и приводит к тому, что очень большая масса программ написано очень плохо, т.к. как человек не умел программировать до того, как сел на perl, так он не умеет и потом, даже не смотря на то, что написал гору кода.
ps
Но замечу, чем опытнее становится разработчик тем больше ему необходима "вседозволенность" для того, чтобы более эффективнее решить встающие перед ним задачи.
Замечу, что для новичков (а также тех людей, которые знакомы с языком поверхностно) важнее не то, сколько язык позволяет использовать хороших, удобных, правильных и т.д. способов решения, способов написания программ, а важнее сколько запрещается делать неправильных, кривых и т.д. способов написания кода.
Примеры:
C++ - разрешает работать напрямую работать с памятью, Java - запрещает работать с памятью => следствие большинство программ на Java работают стабильнее, чем большинство программ на C, а также программы на Java пишутся(отлаживаются) много быстрее
C++/Java/C# - запрещают (вернее не приветствуют, не предоставляют удобных инструментов) динамическую типизацию, Smalltalk - пропагандирует => следствие опять же на C++/Java/C# на начальных этапах программы пишутся быстрее и отлаживаются быстрее.
Perl, как раз скорее пропагандирует, все дозволенность: отсутствие типизации, возможность необъявления переменных, работа через CGI, когда не различается откуда переменная пришла (изнутри пришла или от пользователя) и т.д. Вот вся эта вседозволенность и приводит к тому, что очень большая масса программ написано очень плохо, т.к. как человек не умел программировать до того, как сел на perl, так он не умеет и потом, даже не смотря на то, что написал гору кода.
ps
Но замечу, чем опытнее становится разработчик тем больше ему необходима "вседозволенность" для того, чтобы более эффективнее решить встающие перед ним задачи.
т.е. если взять абстрактного опытного разработчика, то из С++ и С# он всегда выберет С++? для него не существует задач, которые можно решить более эффективно на C#?
По сравнению с C#, в C++ нет многих дополнительных возможностей, поэтому выбор не так однозначен.
ps
Замечу, что, например, запрет, но который можно снять при желании - это еще лучше для опытного разработчика, чем просто отсутствие запретов
Пример:
С# - по умолчанию, напрямую с памятью работать нельзя, но этот запрет можно снять, соответственно это дает еще большую свободу, т.к. на важных задачах такой запрет можно оставлять, на задачах, требующих быстродействия, такой запрет можно снимать.
ps
Замечу, что, например, запрет, но который можно снять при желании - это еще лучше для опытного разработчика, чем просто отсутствие запретов
Пример:
С# - по умолчанию, напрямую с памятью работать нельзя, но этот запрет можно снять, соответственно это дает еще большую свободу, т.к. на важных задачах такой запрет можно оставлять, на задачах, требующих быстродействия, такой запрет можно снимать.
Оставить комментарий
dtrade56
а ты доходчиво объясни, что грамотно и качественно писать на перле сложно