Pull to refresh

Comments 60

Да уж. А некоторый связывают говнокод с каким-то конкретным языком.
Говнокод можно писать на любом языке. Просто в какие-то из этих языков выше порог вхождения, и, как мне кажется, из-за этого снижается процент говнокода. Интересно, проводил кто-нибудь такие исследования?
Все вы верно пишите, я удивляюсь тому, что многие просто однозначно связываю язык с качеством кода :).

Интересно, проводил кто-нибудь такие исследования?
Для этого надо написать автоматический говнокод-детектор. :)
Связывать язык с качеством кода, это почти то же самое что ругать качество ткани в криво пошитом костюме.
Где порог выше — народу меньше, соответственно кричат тише :)
Хороший говнокод еще попробуй напиши.
Написать говнокод на Perl проще, чем на других языках. И в первую очередь потому, что язык весьма гибкий и почти не ограничивает программиста.
К сожалению, мало кто осознаёт, что это в полной мере относится и к Javascript — он очень похож на перл и возможностями и избыточной гибкостью. Так что, боюсь, через года три нас ждёт море нового говнокода на js. :(
Ну зачем же ждать три года… Его и сейчас в избытке )
Говнокод головного мозга обычно не связан с конкретным языком.
Я вот не могу понять зачем кому-то нужно покупать эти коммерческие CMS если есть бесплатные CMS выполненные на высоком уровне? Например, та же Joomla. Как показывает практика, лейбл «коммерческий» далеко не всегда гарант качественности продукта.
Покупают чтобы был кто-то, кто оперативно займётся решением именно вашей проблемы.
Мне за просто так допишут нужные мне модули и компоненты? Что-то сомневаюсь. Все равно придется выкладывать за это деньги разработчику или фрилансерам. Так зачем платить дважды? Взять бесплатный движок, нанять фрилансера, он допилит движок под нужный функционал. Хотя под ту же джумлу уже столько всяких скриптов понаклепали, что 90% запросов заказчика они могут удовлетворить.
Если ты программист, то конечно же проще самому докручивать бесплатную систему.
А если у вас целая контора, которая не хочет держать программиста в штате, то выгоднее купить коммерческую ЦМС. Нужный модуль вам не докрутят, но всегда подскажут, как и где нажать ту или иную кнопку по звонку в службу поддержки, или по письму.
Так же и со скриптиками: они есть как под джумлу, так и под коммерческие ЦМС.
В первом случае вы платите неизвестно кому (опять же, если нет своего программиста в штате), а во втором платите разработчику этого самого скриптика, который в курсе малейших его бяк.

И главное не забывать, что время — прежде всего деньги. Коммерческие ЦМС экономят время людей, у которых оно стоит гораздо дороже, чем у программистов.
UFO just landed and posted this here
Джумла явно не самый лучший пример в данном случае.
Тоже попадался в работе. Недавно хотел перечитать товарищам красивые словища на их сайте, словно они не CMS, а космический корабль сделали, но не мог вспомнить как называется. Спасибо что напомнили о нем.
А, да — забыл про их сайт написать. Там вёрстка так «разъежается», что любо-дорого смотреть.
О говнокоде можно было догадаться уже по cgi-bin. 21й век за окном, давно все если не на psgi, то хотя бы на fcgi перешли.
Не всё так просто. А если есть только виртуальный хостинг именно с cgi-bin каталогом? Оно конечно нищебродство жуткое, но и такие клиенты не редкость.
Ну это как минимум странно, покупать коммерческую цмс и экономить на хостинге.
Платность CMS и ущербный хостинг — это непересекающиеся категории.
Я могу с использованием Dancer сделать открытую CMS и запускать его через CGI на виртуальном хостинге или через PSGI на собственном — это нормально. А могу сделать платную кучу навоза, которая, тем не менее, сможет работать подо всем, кроме CGI.
Таким образом, наличие возможности запуска через CGI не говорит о низком качестве продукта.
Да, но тем не менее, в данном случае, насколько я понимаю, не «наличие возможности запуска через CGI », а «невозможность запуска под чем либо еще, кроме CGI»
Не есть хорошо, но излечимо малой кровью и ничего таки не говорит о качестве продукта.
ни одна другая система была не способна обрабатывать требуемые объемы с требуемым быстродействием, требуемой надежностью и требуемым удобством обслуживания
Может у них требования такие, мы же не знаем
У всех такие требования кого ни спроси.
Судя по «в качестве БД используются плоские файлы» они когда-то на Perl Mova в Киеве выступали, этим и запомнились. Говорили что это один из ключевых моментов — запуститься на любом хостинге.
Фраза «производится с 1998 года» многое объясняет :) Код на Perl, написанный года так до 2005, вообще довольно страшен, а переписывать его зачастую нет ни времени, ни сил.
Но вот за отсутствие use strict нужно бить по рукам. Как эта CMS вообще работает?
Perl вообще для сайтов умирает, успупая PHP
Mail.ru, Yandex, IMDB, Bugzilla, Shashdot… дальше продолжать?
Я до того как появился node.js писал серверсайд исключительно на Perl. Не фанатизм, просто так сложилась судьба. Но работы из года в год меньше не становится. Предсмертных конвульсий пока не наблюдал.
Не советую, гражданин… Мнэ-э… Не советую. Съедят.
CMS прекрасна. Могучие технологии и ноу-хау…

Цитаты с сайта:
Технология X-intelligence: Интеллектуальное ядро системы […] Интеллектуальное ядро нашей системы определит необходимость показа на «первой странице категории» списка подкатегорий, и, если список товаров мал, то система покажет сам список товаров, минуя лишние страницы. Посетителю будет максимально удобно.


Технология X-unlimit: Сверхбольшие каталоги (свыше миллиона товарных позиций) […] Данная технология до сих пор является уникальной и аналогов в коммерческих Интернет-системах России не имеет.


И т.д.
может их ядро еще и блины печь умеет? )
А можно специально для летчиков и общего развития пояснить в чем говнистость приведенного фрагмента и как с точки зрения автора следовало бы его написать?
Только пожалуйста не надо отсылать меня к мануалам и рекомендациям для этого языка. Интересует чисто этот фрагмент и правильный вариант его.
my $fii=0, @FIL=(), $FIS=0, $pat, $file_text="";
Посмотрев на этот фрагмент, можно было бы ожидать, что все переменные создадутся в локальной области видимости. Ведь мы же написали «my»! Но на самом деле в локальной области видимости создастся только переменная $fii. Все остальные переменные будут глобальными.
С включенным use strict такого кода не могло бы быть — он выдаст ошибку при выполнении.
В общем, правильнее будет написать как-то так:
my ($fii, @FIL, $FIS, $pat, $file_text) = (0, (), 0, undef, "");
Постойте, разве 0, undef, "" не попадут также в @FIL вместо $FIS, $pat, $file_text?
Попадут. Правильнее @FIL в конец списка поставить.
Подобные фрагменты встречаются в большом количестве, что говорит о намеренном написании «именно так».
Если бы всё было сделано правильно (с use strict), то этот именно фрагмент выглядел бы так:
my ($fii, @FIL, $FIS, $pat, $file_text = (0, (), 0, undef, "");
Основная проблема в том, что локальной становится только первая переменная, а не всё перечисленное.
Древность неправленая… Поди, с четверки ещё тянется
" сам код взят из свободного источника (я и сам им пользовался — потому и узнал)"

Случайно не CPAN?
За давностью лет не помню откуда я тот код брал, возможно просто наальтавистил. Но узнать его я в состоянии.
Посмешило многое на сайте горе-цмс, а особенно вот это:

«Памятка системному администратору по вопросам профилактики от вирусов и паразитического софта:

— Обязательное отключение поддержки PHP на Ваших серверах и зонах хост-провайдеров.
Помните, что только при поддержке PHP можно извне завести Вам зловредный код без Вашей воли при неизвестных злоумышленику параметрах доступа по FTP»
Пойду-ка я у всех клиентов PHP отключу на хостингах, от греха подальше.
Ага, не безопасно же)
Интересно, а у себя то они его отключили, а то я смотрю такие настройки апача www.xforge.ru/images/ они не считают опасными )
Пишу на perl уже более 14 лет. Такими колбасообразными конструкциями не пользуюсь — куча переменных в строке, затем куча значений для инициализации. Во-первых, error prone, во-вторых, не видно ж нифига, кому какое значение присваивается. Одну переменную добавишь, а значение забудешь — и привет, ищи потом жука.
Пусть там 5 строк будет, зато всё сразу видно.
Полностью согласен — компилятору то пофиг, одна там строка или 10.
«Знатная» система!
Знакомые попросили помочь перенести магазин.
Стал расспрашивать что, куда, почему переносите.
Житья говорят нет. Общение с сапортом просто пипец. По записи, заранее, причём время назначали они.
А само общение проходит в единственно возможном ключе, что разработчик(он же, на тот момент, саппорт дизайнер, и владелец) живой бог, а клиент всегда не прав и сам во всём виноват.
Любые упрёки в сторону недостатков системы расцениваются как ересь, с неминуемым отлучением от церкви.

Система размещается на хитро настроенных серверах конторы ихнего партнёра.
Чтобы самому забекапить систему нужно извращаться. Тупо скопировав а потом восстановив все файлы по FTP система не обратно не заведётся. Глубоко не копал, (с перлом знаком на столько на сколько он похож на PHP. но по ходу в двигле встроена защита… если меняется дата определённых файлов система перестаёт работать.
Шаблоны по началу лежали в открытом виде, потом их от жадности «закодировали».
Старые шаблоны можно нагуглить по «powered by» просто феерический пипец даже для того времени.

А баг фича с куками это у них такая защита от ушлых клиентов которые не хотят платить деньги за тех.поддержку непонятно за что. Сайт (вы только вдумайтесь) после установленной разработчиком даты перестаёт работать. Точнее (там ещё более подлая ситуация) перестаёт работать форма оформления заказа.
А когда клиент понимает что с магазином что-то не так, бабло не течёт, и звонит разработчикам.
С вопросом: — какого хера!?..
Те, с понтом дела «у вас вирусы» попросту принуждают заново подписываться на саппорт.
Хочется спросить, это через какие-такие дыры в вашей системе за килотонны денег вирусы пролазят?
Кстати да, что-то клиент вещал про читстку вирусов. Уж не по наводке ли того самого саппорта?
Ну и хвалёное быстродействие строится на очень быстрой отдаче файлов хостингом и тотальном полном кешировании страниц.
Супер мега разработанная база данных — это куча текстовых файл CSV.
А был ещё такой легендарный чувак, Matt Wright, может кто его еще помнит. В 90х его перловые скрипты были весьма популярны. Чем-то напомнило :-)
loginadm как подтверждение логина — это какой-то феерический ад, простите. Сам не очень люблю Perl, но это ИМХО выше конкретики языка.
А при чём тут Perl, простите?

Про любовь. Языки не надо любить/не любить. Надо писать на тех, которые наиболее полно решают стоящие перед вами задачи.
Я же вроде написал, что «это ИМХО выше конкретики языка»… а про любовь — о вкусах не спорят, естественно, и я последний, кто стал бы начинать холивары. А то пытались мне тут недавно доказать преимущества Glock над Walther… главное — чтобы в руке хорошо лежало, остальное неважно. То же самое применимо к языкам — важен не язык, а способность решать проблемы.
Побольше ничем не подкрепленного пафоса, видимо залог успешных продаж подобных продуктов. Полно таких историй, когда продают идею/альфа версию, а потом на коленке добивают.
Sign up to leave a comment.

Articles