1. JavaScript / Говнокод #17425

    +169

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    for (var i = 0; i < result.Results.length; i++) {
        data = result.Results;
        if (i == 0) {
            $calendarPins = jQuery.parseJSON(data[i].Markers);
            GoogleMapsInitialization();
        }
    }

    Аж за душу взяло...

    Запостил: zloynightmare, 09 Января 2015

    Комментарии (47) RSS

    • Больше циклов для трона циклов!
      Ответить
    • У JS низкий порог входа ...
      Ответить
      • > низкий порог входа
        Даёт всем подряд?

        Простите, не удержался.
        Ответить
        • Ах вот, кто из-под гостя тут так шутит!
          Ответить
        • Если по любви - почему бы и нет?.. Вы жертва глупых стереотипов, или спида боитесь? ВИЧ - это сказка, бойся не вич, а гепатита.
          Ответить
          • Не стереотипов, а шаблонов.
            http://4.bp.blogspot.com/_YtxGNf8GgRA/TOXLQN3-j0I/AAAAAAAAFUI/e1g0DOEKhv8/s1600/make_tea_not_love.png
            Ответить
        • нет, просто карликам удобней
          Ответить
      • У всех популярных языков низкий порог входа.
        Надо что бы статический анализатор шел сразу в комплекте с компилятором/интерпретатором. Так же кроме Error, Warning, Notice ввести уровень сообщений KillItWithTheFire как раз для таких случаев. После вывода сообщения - удалять файл с исходниками.
        Ответить
        • Какой ты острый, я ажно порезался.
          Ответить
        • Да, но не все популярные языки такое дерьмо как джс.
          Ответить
          • >джс
            ECMA-script
            Ответить
            • Да, но не все популярные языки такое дерьмо как экмаскрипт.
              Ответить
              • Плюсанул.
                Более того, из современных языков ECMA-скрипт самое дерьмовое дерьмо. Даже пыхпых в сравнении с ним кажется просто шедевром архитектуры.
                Ответить
                • Пых, конечно, тоже говно. Но там хотя бы переменные по-умолчанию локальные, а не вываливаются в global object.
                  Ответить
                  • Покажите мне еще один популярный интерпретируемый язык, где есть внятные интерфейсы, неймспейсы и абстрактные классы.
                    Ответить
                    • Пайтон, например. И в отличии от пхп они там правда используются
                      Ответить
                      • Наследование от хуй пойми чего - это внятные интерфейсы и абстрактные классы? Интерфейс, который на самом деле не интерфейс, а класс - это нормально? В питоне нет ни интерфейсов, ни неймспейсов, ни абстрактных классов, это надстройки библиотеки, к которым еще надо обращаться, чтобы убедиться, что к тебе реально пришел тот интерфейс, который ты хотел.
                        Ответить
                        • Интересно, а что ты хотел от языка с динамической типизацией? Более того, там пышным цветом буяет утиная типизация, так что интерфейсы как отдельная сущность вообще не нужны.
                          Ответить
                          • - в PHP есть нормальные неймспейсы, интерфейсы и абстрактные классы
                            - И ЧТО И ЧТО В ПИТОНЕ ТОЖЕ ЕСТЬ И ИМИ ДАЖЕ ПОЛЬЗУЮТСЯ!
                            - В питоне есть какая-то пародия, сделанная через жопу
                            - А ЧТО ТЫ ХОТЕЛ ОТ ЯЗЫКА С ДИНАМИЧЕСКОЙ ТИПИЗАЦИЕЙ? ИНТЕРФЕЙСЫ НЕ НУЖНЫ!

                            у меня другой вопрос: вы-то вдвоем что хотели доказать?
                            Ответить
                        • >>В питоне нет ни интерфейсов,
                          Есть. ABCMeta.
                          >> ни неймспейсов
                          Есть. Пекеджи и модули..

                          >> ни абстрактных классо
                          Есть. ABCMeta.

                          >>это надстройки библиотеки, к которым еще надо обращаться
                          Разумеется. Как и в любом языке без *статической* проверки типов.

                          Хорошо или плохо не иметь статическую проверку -- вопрос для дискуссии.

                          Но в пайтоне это сделано честно и внятно. А в ПХП через жопу и местами.
                          Потому что у пайтновца в голове ясная картина (хотя и спорная конечно), а у ПХПиста каша. Как в языке, каша в голове, каша в библиотеке.
                          Ответить
                          • > Но в пайтоне это сделано честно и внятно. А в ПХП через жопу и местами.

                            Потому что ты так сказал, ага.
                            Ответить
                    • А какой смысл в интерфейсе в том виде в котором он есть, скажем, в Яве, в языке без статической проверки типов? В Яве - понятно, нужно на этапе компиляции пообещать компилятору, что вызываемый метод будет, даже если мы не знаем, у кого конкретно его вызываем. В Питоне просто такой необходимости нет. Аналогично - абстрактные классы. Это все механизмы борьбы Явы с ее достоинствами. Нормальным языкам это не нужно.
                      Ответить
                      • Бля, да вы серьезно что ли? Интерфейс - это в первую очередь контракт, это вообще не про язык на самом деле. Библиотека предоставляет интерфейс -> ты можешь предоставить ей любую реализацию. PHPExcel медленно работает? Хорошо, заворачиваем во враппер, делаем интерфейс, при обнаружении нормального аналога просто подменяем реализацию.

                        Это вообще нихуя не про конкретный язык. Это про модульность, совместимость, тестирование и все прочее веселье, от которого большинство добровольно отказывается.
                        Ответить
                        • Специально для сразу отвечающих без прочтения, напомню: интерфейсе в том виде в котором он есть, скажем, в Яве.
                          А в чем проблема с модульностью в Питоне? Там контракты можно выразить по-другому. Более того, изначально речь шла не об интерфейсах, как механизме взаимодействия, а как элементе языка. В чем проблема в Питное предоставить свою реализацию с тем же интерфейсом?
                          Ответить
                          • > интерфейсе в том виде в котором он есть, скажем, в Яве.

                            Оох блядь.
                            Еще раз: мне нужно просто, легко и из коробки задавать контракты для реализаций, не трогая реализации вообще.
                            Это и есть интерфейс, откуда ты яву взял - я хуй знает, я понял бы если бы мы про аннотации говорили, которые в пыхе сделаны так же, как интерфейсы и абстрактные классы в питоне.
                            Да пусть он хоть валяется рядом текстовым файлом с аналогичным названием, но иным расширением.

                            > А в чем проблема с модульностью в Питоне?

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

                            > Там контракты можно выразить по-другому.

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

                            > Более того, изначально речь шла не об интерфейсах, как механизме взаимодействия

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

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

                              При чем тут клоака стандартной библиотеки? Сама по себе возможность отложить проверку типов, в любом языке, позволяет элементарно решить задачу контрактов. Это на столько тривиально, что обычно никто себя не утруждает объяснениями очевидных вещей.
                              Ответить
                              • Уточня́ть — втирать какую-то хуйню, которая только похожа на то, что ты говорил раньше, но на самом деле не имеет к этому отношения. [править]

                                Последнее изменение этой страницы: 01:03, 30 октября 2014.
                                Текст доступен по лицензии Creative Commons Attribution-ShareAlike, в отдельных случаях могут действовать дополнительные условия. Подробнее см. Условия использования.
                                Ответить
                              • Господи, интерфейсы пишутся не для того, чтобы компилятор проверил типы, а для программистов, которые их реализуют. Пойми уже наконец.
                                Ответить
                              • Ну на самом деле я понял, о чём говорит Fike. Он говорит о том, что требования к интерфейсу собраны в одном месте, обладающим именем. И это отчасти уменьшает вероятность сломать код других людей случайным переименованием или опечаткой.

                                Аналогичная проблема есть в крестах - там типы в шаблонах ничем не ограничены, у них "компайл-тайм утиная типизация". Это с одной стороны гибко, с другой - большая проблема, т.к. требования к интерфейсу можно описать только в документации, и в случае проблем компилятор выдаст ошибку где-то в кишках чужого кода.
                                Для решения этой проблемы, собственно, и продвигают "концепты".
                                Ответить
                                • Ну так опять же, есть две главные проблемы: кто будет охранять сторожей, и как внести в интерфейс именно нужную информацию. То, что формально в файле-интерфейсе будет описано какие типы у каких функций - не помогает решить ни первую ни вторую проблему. Ну описал я в одном файле интерфейс, а потом передумал и выпустил версию два-ноль, с совсем другими функциями, но с тем же названием. Или, еще веселее - поменялся тип функции - очень жизненная проблема, стотыщ раз с этим сталкивался. И формальный интерфейс только ухудшил ситуацию, за счет того, что придирался к типам.

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

                                  То, что решение о соответствии интерфейсу можно отложить до момента когда это взаимодействие понадобится - это плюс, ради этого все и делалось, ради этого объекты, например, и задумывались - чтобы можно было во время выполнения кода принять более правильное решение, а не опираться на устаревшие данные.
                                  Ответить
                                  • Говно ваши "языки во всякими там интерфейсами и динамической тупизацией", то ли дело "Brainfuck"...
                                    Ответить
                                    • > Говно ваши "языки во всякими там интерфейсами и динамической тупизацией"

                                      тогда регистрируй ник ТупизатионГовно и больше не тупи
                                      Ответить
                          • > В чем проблема в Питное предоставить свою реализацию с тем же интерфейсом?

                            Что мне блядь придется лезть куда-то и читать этот ебаный интерфейс, вместо того чтобы написать implements XXX и смотреть в подсказки IDEшки.
                            Изоляция, single responsibility principle, отделение интерфейса от реализации, слышал о чем-нибудь таком? Все _нормальное_ программирование построено на атомарности и убийстве взаимосвязей между разными кусками кода, и сам программист тоже не должен думать о разнице между urllib, urllib2 и urllib3 (к слову о модульности в питоне), пока я пишу какой-то кусок кода, у меня должен быть просто HTTP-транспорт, который принимает на вход Х, а на выходе дает Y. Я не должен сверяться с какой-то спекой, пока пишу реализацию, мне не нужно лезть в какой-то охуевший браузер, мне нужно здесь и сейчас, прямо в этом файле видеть то, что я реализую, и если я охуенный программист, у меня все должно работать при первом же подключении модуля.

                            Каким образом типизация запрещает задать требования к чему-либо на уровне языка - я не знаю.
                            Ответить
                            • Ты просто умеешь лучше пользоваться одним инструментом, и практически не умеешь пользоваться другим - поэтому тебе кажется, что один способ проще. На самом деле никто не может тебе гарантировать, что если ты реализовал интерфейс так, как тебе редактор показал в подсказке, то он действительно совпадет с реальным кодом, с которым он будет работать. Другой код обращающийся к твоему коду, пусть даже реализующему интерфейс может:
                              1. предполагать, что реализован интерфейс с тем же именем, но другими методами.
                              2. предполагать вещи никак не связаные с интерфейсом. (Пример - сериализация в Яве, другой пример: укажи в интерфейсе необходимость того, чтобы передаваемый список был отсортированым, или чтобы функция всегда завершалась).

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

                              Хуйню про ХТТП транспорт читать не стал: много буков и ноль смысла.
                              Ответить
                              • > предполагать, что реализован интерфейс с тем же именем, но другими методами.

                                ой пиздец
                                Ответить
                                • Пиздец, это когда такая програма уходит заказчику, и у него этот интерфейс - часть другой установленой програмы, и потом у него "не работает", менеджера имеют в разных позах, а программиста лишают премии.
                                  Ответить
                                  • А это реальная проблема, кстати, зря wvxvw минуснули.

                                    Возникает она очень просто - кто-то решил улучшить интерфейс и что-то в него добавил (менять и удалять мало кто решится, а вот добавить - решаются).
                                    Ответить
                                    • обратно несовместимые улучшения просто откладываются до следующей major-версии.
                                      Ответить
                            • А как вы предполагаете использовать интерфейсы в динамически типизованных языках? Через Type Hinting? Так по логике _нормального_ программирования, если аргумент в динамике не соответствует хинту мы можем только бросить исключение (в PHP - Fatal Error, хаха). Ну Duck Typing тоже самое дает - только в Python вы получите не TypeError а AttributeError, вот и вся разница.

                              К слову urllib2.urlopen вполне себе интерфейс - он возвращает "file-like object" - это универсальный интефейс к любому потоку - то же самое при вызове file() или использовании stringio. В PHP gzopen и fwrite несовместимы между собой (это конечно решаемая проблема, но никакими интефейсами не пахнет)
                              Ответить
                            • >> Что мне блядь придется лезть куда-то и читать этот ебаный интерфейс,
                              >> вместо того чтобы написать implements XXX и смотреть в подсказки
                              >> IDEшки.

                              ну откройте же для себя ABCMeta и @abstractmethod наконец!

                              Вам PyCharm подстветит если Вы не реализовали нужный метод, и даже поможет реализовать его!
                              Ответить
                              • 1. Я вряд ли вернусь к питону, его парадигма мне не очень близка
                                2. Jetbrains, конечно, молодцы, но это а) абстрактный класс, а не интерфейс и б) нахуй мне писать что-то длинее, чем слово abstract перед объявлением класса?
                                Ответить
                                • ну и я там выше писал, что это все ебаные надстройки.
                                  Ответить
                                • >> Я вряд ли вернусь к питону, его парадигма мне не очень близка
                                  А что близко, кстати,

                                  >> абстрактный класс, а не интерфейс
                                  Никакой разницы нет совершенно в данном случае. Абстрактный класс позволяет задать проверяемый статически контракт, равно как и интерфейс.

                                  >> нахуй мне писать что-то длинее, чем слово abstract
                                  А нахуй в других языках скобочки писать? Или слово function вместо def?

                                  В Python и правда с ООП не всё хорошо, но так ведь у других скриптовых языков еще хужее (ну разве что руби у него выигрывает, не знаю).
                                  Ответить
            • бездефиса
              Ответить
        • "The" - лишний.
          Ответить
          • А вдруг у него для этой цели особый Огонь есть?)))
            Ответить

    Добавить комментарий