1. Куча / Говнокод #26937

    0

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    9. 9
    > https://habr.com/ru/post/518308/
    > Мне надоело, что индустрия зависит от прихоти создателей языков программирования. Сообществу нужно больше власти
    
    > В языках вечно не хватает чего-то простого — лямбда-функций,
    > именованных объединений, кастомных примитивных типов. Я лезу
    > в обсуждения на Stack Overflow, в Github и вижу, как разрабы жалуются
    > — им не хватает того же, чего и мне. Но обсуждения почти всегда
    > заканчиваются одинаково: нужная фича не появится, потому что
    > главный дизайнер языка и члены его команды нужной ее не считают.

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

    Запостил: j123123, 09 Сентября 2020

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

    • > Истинные причины отсутствия дженериков всегда лежали в техническом поле. Если вы заглянете в код компилятора Go, то у вас не останется сомнений — всему виной низкое качество кодовой базы компилятора. Добавить их просто невозможно не переписав компилятор, и, как я понимаю, для Go 2.0 они собираются сделать именно это.

      > Я давно убедился: разработчики языков ничуть не лучше обычных программистов. У них нет никакого уникального знания или экспертизы, которая делала бы их лучше, чем вы. Зачастую они игнорируют базовые практики разработки программного обеспечения, которые известны даже новичкам. Если код компилятора нужно переписать — это вина создателей компилятора, это они не следили за архитектурой и все запустили.

      Бляя... ну что за хуйня... С каких хуев он приравнял разработчиков стандарта языка к разработчикам компилятора/рантайма конкретного языка? Не, ну я понимаю что в каком-то там Go-вне это может быть действительно так, но ведь есть и языки, у которых более одного компилятора
      Ответить
      • > Проблема не в том, что мне не хватает синтаксического сахарка, чтобы сделать "красивенько". Все эти штуки — енамы, рекорды, юнионы — важные промышленные фичи, которые позволяют автоматизировать. Они появились не потому, что кто-то захотел выпендриться, они появились в ответ на конкретные задачи, которые не получалось хорошо решать со старыми инструментами.

        > Без лямбд, которые позволяют передать фильтер в коллекцию одной строкой, кодовая база наших репозиториев разрослась бы кратно. Когда у тебя кодовая база вдвое больше, чем могла бы быть — ты в полном дерьме. Это работает, как снежный ком. Чем больше на проекте необязательного кода, тем сложнее его будет поддерживать — а чем сложнее его поддерживать — тем быстрее качество его кодовой базы будет ухудшаться. В плохом проекте любое изменение делает его ещё хуже.

        Так всё просто. Надо просто сделать язык с ГОМОИКОНАМИ, и пусть каждый как ему вздумается нахуеверчивает там лямбды-хуямбды, рекорды-хуекорды и прочую поебень через метушню.
        Ответить
        • Завезти гомоиконы не так уж сложно. Сложно потом не повеситься на чтении чужого кода и на интеграции разнородного говна из разных либ.

          Обычные языки сейчас дают хуёвый, но базис. С гомоиконами у всех всё будет по-своему.
          Ответить
          • Гомоиконы с сишным синтаксисом это наверное страшно

            В лишпах там как раз всё единообразно и есть базис в виде s-exp. Хотя тот же Рэкет позволяет строить в целом произвольные парсеры

            А какие ещё есть семейства языков с иконностью?
            Ответить
          • > Обычные языки сейчас дают хуёвый, но базис. С гомоиконами у всех всё будет по-своему.

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

              Но сообщество пильнуло три разных реализации, на то оно и сообщество. Теперь читая чужой код ты должен понимать все три варианта. И городить адаптеры между либами, которые завязались на разные.

              Посмотри на те же кресты, сколько там разных реализаций строк нахуевертили...
              Ответить
              • > разных реализаций строк нахуевертили...
                давай теперь их все в стандарт добавим!
                Ответить
              • > Но сообщество пильнуло три разных реализации, на то оно и сообщество.

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

                В том же питоне ж как-то умудряются соблюдать PEP 8 в 99% случаев? Ну вот пусть так же соблюдают правила, что использовать можно только официально одобренные гомоиконы из особого раздела в пакетном менеджере
                Ответить
                • > только официально одобренные

                  Какая диктатура )))

                  Собственно от этого и пытались уйти, не?
                  Ответить
                  • Есть официально одобренные зависимости

                    А есть циркониевые зависимости, которые по тв рекламирует Джигарханян
                    Ответить
                  • Так никто ж не заставляет.

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

                  Форт?
                  Ответить
                  • Форт это стековая хрень с шитым кодом - т.е. нихуя не ассемблер

                    Я о том, что можно ассемблер с s-expr сделать, типа там
                    (mov eax eax)
                    (add eax 1)
                    (cmp eax ebx)
                    Ответить
                    • Схуяли? Там в стандарте вообще ничего о шитом коде. И с конпеляцией в нативный код есть реализации.

                      Ну и "режим" ассемблера часто есть, примерно как твои s-expr'ы только кверху жопой.
                      Ответить
                      • Ну блин, FORTH имеет ненулевой рантайм потому что там хрень для стеков нужна, так что нафиг его
                        Ответить
                        • Ну не закидывай рантайм на таргет, сри туда только асмом, юзай форт как макропроцессор/конпелятор. Ты же это и хотел на s-expr'ах наваять? А на хосте то у тебя хоть как какой-то рантайм будет, и не маленький.
                          Ответить
                          • Ну как бы если FORTH рассматривать как язык, на котором будет запилен некий ассемблер с компилтайм-метапрограммированием через FORTH, то чем LISP хуже? По-моему примерно однохуйственно. Мне просто скобочки больше нравятся, чем обратная польская нотация
                            Ответить
                            • Да однохуйственно, можно и на xslt асм наваять.

                              <instruction>
                                <name>mov</name>
                                <arguments>
                                  <argument type="register">eax</argument>
                                  <argument type="register">ebx</argument>
                                </arguments>
                              </instruction>
                              Ответить
                              • Переведи на «JSON». XML нинужен.
                                Ответить
                                • показать все, что скрытоvanished
                                  Ответить
                                  • > JSON не имеет ни схем
                                    Очевидно, ты не прав. Я всегда могу построить отображение XML -> JSON. Обратно не всегда, т.к. можно нахуевертить невалидную схему, но я могу и просто невалидный XML сделать.

                                    > кроме скриптоблядей
                                    Да даже на плюсах с JSON работать приятнее.
                                    Ответить
                                    • показать все, что скрытоvanished
                                      Ответить
                                      • 1) Я могу любой XML представить в виде JSON.
                                        2) Я могу проверить любой JSON, что он соответствует формату, который я придумал на шаге 1.
                                        3) В итоге могу использовать JSON вместо XML.

                                        На каком пункте ты не согласен?
                                        Ответить
                                        • показать все, что скрытоvanished
                                          Ответить
                                          • Да. Что не так?
                                            Ответить
                                            • показать все, что скрытоvanished
                                              Ответить
                                              • Приведи реальный пример, когда нужен xpath.
                                                Ответить
                                                • показать все, что скрытоvanished
                                                  Ответить
                                                  • Для такой хуйни вроде JSONSelect есть.
                                                    Ответить
                                                  • https://www.postgresql.org/docs/12/functions-json.html#FUNCTIONS-SQLJSON-PATH
                                                    Ответить
                                                    • А что здесь происходит?
                                                      Скармливаем движку БД json и потом можем по нему делать выборки?
                                                      Ответить
                                                      • Пример того, как jsonpath работает даже на постгресе (а так на жс, жабу, пхп и тд все есть).

                                                        Реально же это хуй знает что надо парсить, чтобы по-царски принимать мегабайты текста (хмл или жсон, не критично), но искать в них где-то глубоко в дереве избранные штуки. Какой-то сценарий "прими, загляни, не вздумай десериализовывать, передай дальше".
                                                        Ответить
                                              • Значимость схемы несколько преувеличена и даже вредна. SOAP для динозавров.
                                                В жсон есть и свой жсон-патх, а ну для особых ценителей есть и жсон-схема.

                                                Работать с жсоном даже в постгресе куда приятнее, и уже охуенно эффективно.

                                                Как поможет твоя схема, если клиенту требуется только тот набор полей, который ему понятен, а сервер уже помолодел и присылает что-то дополнительно?
                                                Ответить
                                                • показать все, что скрытоvanished
                                                  Ответить
                                                  • > Статическая валидация структуры вредна?
                                                    ты и так провалидируешь эту структуру, когда соберешься её десериализовать в объект и напорешься на отсутствие поля, которое not null, зачем делать это два раза?

                                                    > SOAP позволяет
                                                    и при этом не очень отличает идемпотентность и неидемпотентность, по крайней мере когда HTTP является транспортом (ну и я навскидку не могу сказать, где там какие могут быть пометки, чтобы отметить, что данный результат RPC можно покешировать)

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

                                                    > Чем приятнее?
                                                    jsonb
                                                    Ответить
                                                    • > jsonb
                                                      - ого. А кстати когда выгодно использовать такой подход?
                                                      Ответить
                                                      • эм
                                                        всегда?
                                                        json вместо jsonb надо выбирать только в одном случае - ты собираешься сохранить оригинальное авторское форматирование
                                                        Ответить
                                                        • Я не про сравнение json и jsonb.

                                                          А про то, когда это вообще надо в реляционной базе держать.
                                                          Ответить
                                                          • Во первых не обязательно держать, это охуенно для того, чтобы относительно динамические объекты на уровне функций уметь (далее ты задашь вопрос нахуя вообще логика в бд - ну так бывает, лишь бы она была инфраструктурной, невидимой для снаружи, а не бизнес).
                                                            Во вторых тебе не всегда нужна 7 нормальная форма, и даже наоборот, после того как база нормализована предельно, ты для ускорения делаешь денормализацию. Чем хуже хранить жсон в постгресе вместо монгодибил? Хранить такое можно в text (CLOB), а можно и в jsonb.

                                                            Ну и наконец всякие составные типы (для записи эн локализованных переводов хранить там же) очень заебись в jsonb (раньше был ещё hstore, сейчас jsonb уже достаточно заебись, чтобы не добавлять экстеншеном негативные типы).
                                                            Ответить
                                          • > Зачем мне JSON вообще?
                                            Его удобно парсить, он удобно ложится на объекты в скриптушне.
                                            Он проще: в нём есть только объекты, массивы, числа, строки и null.

                                            В общем 99% макак c тобой не согласны, и выберут JSON, а XML вызывает рвотный рефлекс.
                                            Ответить
                                          • > XML
                                            > массива с массивами
                                            > на ПХП

                                            Идеальное сочетание.
                                            Ответить
                                      • Именно поэтому я за JSONx
                                        Ответить
                    • > хрень с шитым кодом

                      Как выше сказали, это деталь имплементации. Были стековые процессоры, которые его вообще нативно поддерживали.
                      Ответить
    • Coq не нужен.
      Ответить
    • Напоминает хрюканье леваков, которые сейчас по америкосии бегают:

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


      * Любое сообщество на 80% состоит из идиотов
      * Сообщество популярных языков состоит из идиотов на 98%
      * Если пустить сообщество, то завтра в стандартной библиотеке в глобальном неймспейсе будет mysql_real_escape_string и twitter_tweet.
      * Почти все языки развиваются ровно так, как хочет их создатель (иначе будет еще более неконсистентное говно, см design by committee).
      * Сообщество может форкнуть язык, и сделать его пад сибя. Или пойти нахуй
      Ответить
      • > сообщество может форкнуть язык

        Ага, и получится замечательная история с крестами от борланда, крестами от майкрософта и крестами от гну. Или с джаваскриптом в разных браузерах. Проходили всё это уже...
        Ответить
        • Можно никакому сообществу даже ничего не форкать

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

        Но третий пункт был зря.
        Ответить
    • показать все, что скрытоvanished
      Ответить

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