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

    −1

    1. 1
    https://habr.com/post/417047/

    Гвидо уходит напитон из питона

    Запостил: guestinxo, 13 Июля 2018

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

    • О, нет! Страна Питония осталась без правителя!

      Если уж при Гвидо туда пропихнули хуиту (:=), то без него, думаю, преврятят Питонию в какой-нибудь Перл или Руби.
      Ответить
      • скорее наоборот: окукляца и не буду в язык ничего нового привносить

        зы: руби охуенен, братан
        не кроши на него батон
        да и перл не так уж плох для своего времяни и области применення
        Ответить
        • > да и перл не так уж плох для своего времяни и области применення

          Да и Perl не так уж плох для любого времени и любой области примнения.

          // fixed
          Ответить
          • бля
            я писал комментарий, а он удалялился
            ох, пхп

            так вот: Perl был создан чтобы легко и просто парсить текстовые файлы и крутить их как нужно. И чтобы делать это в небольших скриптах. Он для этого идеален.

            А когда на нем пишут сложную бизнес-логику с кучей классов и кучей файлов то он превращается в ад. И он не виноват: он НЕ для этого.

            Practical extranction and report language.
            Ответить
            • Процитирую Ларри:

              Благодаря своему происхождению Perl был богатым языком даже тогда, когда служил «просто» языком преобразования данных, предназначенным для перемещения по файлам, просмотра больших объемов текста, создания и получения динамических данных и вывода легко форматируемых отчетов, основанных на этих данных. Но в какой-то момент начался расцвет Perl. Он стал также и языком для работы с файловой системой, управления процессами, администрирования баз данных, программирования в архитектуре клиент-сервер, создания безопасных программ, управления данными в Сети и даже для объектно-ориентированного и функционального программирования. Эти возможности не были просто механически присоединены к Perl — каждая новая синергически работает с остальными, поскольку с самого начала Perl проектировался как интегрирующий язык.

              <...>

              Хотя Perl особенно популярен среди системных программистов и разработчиков для Интернета, это связано лишь с тем, что они первыми его открыли; аудитория Perl значительно шире. Получивший при создании скромный статус языка обработки текста, Perl превратился в сложный язык программирования общего назначения с богатой средой разработки программ, укомплектованной отладчиками, профайлерами, формировщиками перекрестных ссылок, компиляторами, библиотеками, синтаксически ориентированными редакторами и всеми остальными атрибутами «настоящего» языка программирования — если они вам требуются. Но все они относятся к поддержке возможностей решения сложных задач, с чем справляются многие другие языки. Уникальность Perl в том, что он никогда не терял из виду возможность легко решать задачи простые.
              Ответить
              • >>Perl превратился в сложный язык программирования общего назначения
                В том-то и проблема.

                ЯПу лучше бы сразу же проектироваться и использоваться так, как спроектировался. Дикорастущий сад приводит к хаосу.

                Перл хороший, но
                1) в нем дохуя операторов, некоторые лучше бы было реализовать функциями (https://perldoc.perl.org/perlop.html)
                2) мне не нравится что все функции varargs по умолчанию. Это почти никогда не надо. Хак с хешем, превращающмимся в named parameters тоже не очень (от перла эта болезнь передалась в Ruby)
                3) доллар не нужен. Это мусор семантический, чтобы не выглядеть чужаком в шелпрограмминге
                4) blessed, new и стрелочка мало того что тоже мусор, так еще и мозговзрыв. Вы или не умейте ООП вообще (как си) или умейте его в нормальных терминах.
                5) -s и use strict надо быть по умолчанию
                6) один факт наличия "use English;" много говорит о языке

                В целом же Perl крут, имеет кучу отличных модулей на CPAN, и маленькое, но сильное сообщество.
                Если ты берешь программиста на Perl на работу то он почти никогда не мудак-скрипткидди (а, например, с питонистом такое может случиться)
                Ответить
                • показать все, что скрытоКакой багор)))
                  Ответить
                • показать все, что скрытоvanished
                  Ответить
                  • Порог вхождения имеет весьма слабую связь со стоимостью разработчика.
                    Если С++снику платят больше, чем PHPшнику то это не потому что С++ сложнее, а потому что сложнее задача, и ее может решить только более крутой программист, ну а язык это просто инструмент.

                    С остальным, в принципе, согласен.
                    Ответить
                    • > Если С++снику платят больше, чем PHPшнику то это не потому что С++ сложнее, а потому что сложнее задача

                      Вот это сомнительно. А если вдруг наоборот пхп-шнику платят больше? Что это значит, что у него задача сложнее или он более крутой программист? Я думаю, это значит, что какой-то из бизнесов просто приносит больше денег или что-то в этом роде.
                      Ответить
                      • 1C больше всех, потому что надо еще уметь не утонуть в говне.
                        Ответить
        • показать все, что скрытоvanished
          Ответить
          • да
            https://railsware.com/blog/wp-content/uploads/2017/06/Ruby-Universe.png


            Видишь, педоматик какой-то использует
            Ответить
            • показать все, что скрытоvanished
              Ответить
              • ну ты спросил -- я ответил
                используют люди, да


                рубийное соощество, кстати, очень много сделало для

                1) DSLей
                2) веб-фреймворков
                3) configuration as code
                4) BDD

                Зато PHP сообщество изобрело правку .php файлов на продакшене через тотал коммандер по ftp
                Ответить
                • > BDD
                  - "ой, мы сделали непонятную херню, а давайте её присобачим всюду, куда дотянутся наши потные ручки"
                  Ответить
                  • Gherkin отличная штука для крупного энтерпрайза с бизнес-аналитиками. Она перекочевала уже давно в Python и Java, и там популярна. Достатчно посмотреть на https://github.com/behave/behave

                    Без словестного описания фич их невозможно ни тестировать, но синхронизировать свое понимание с бизнес-оунером (см "Specification by Example" Аджича)
                    Ответить
                • показать все, что скрытоvanished
                  Ответить
                  • Да, люди это больше одного. Ну еще можно конечно умножать их на коэфициент полезности)

                    >>но сам язык, похоже, не нужен
                    толи дело пхп, да?
                    Ответить
        • Лучше иметь дочь-проститутку, чем сына-рубиста.
          Ответить
      • показать все, что скрытоvanished
        Ответить
        • Теперь сможешь присваивать этим оператором в любом выражении, даже в условии цикла, даже внутри лямды(?) и ловить разные интересные ашиппке.
          Ответить
          • А вообще, надо бы весь пеп прочитать, можь там еще чего интыресного завезли.
            Ответить
      • показать все, что скрытоvanished
        Ответить
      • показать все, что скрытоvanished
        Ответить
      • >Если уж при Гвидо туда пропихнули хуиту (:=)

        Хахаха. Они даже FAQ не удосужились поправить
        https://docs.python.org/3.8/faq/design.html#why-can-t-i-use-an-assignment-in-an-expression


        Why can’t I use an assignment in an expression?

        Many people used to C or Perl complain that they want to use this C idiom:
        while (line = readline(f)) {
            // do something with line
        }

        The reason for not allowing assignment in Python expressions is a common, hard-to-find bug in those other languages, caused by this construct:
        if (x = 0) {
            // error handling
        }
        else {
            // code that only works for nonzero x
        }
        Ответить
      • показать все, что скрытоvanished
        Ответить
      • показать все, что скрытоvanished
        Ответить
    • В "Python"-е нет необходимости вообще, а в Гвидо, о котором я впервые читаю - тем паче.
      Ответить
      • в чем нет необходмости так это в тебе, в mysql и в php
        во всем остальном необходимость есть
        Ответить
        • > во всем остальном необходимость есть

          Ну не знаю, я уже джвадцать джва года жду, когда всё это недотипизированное скриптоговно уже сдохнет.
          Ответить
          • Скоро везде будет JavaScript, и ты еще будешь вспоминать питон с теплотой.

            Хотя я, пожалуй, соглашусь что в 1993 году смысла в скриптовых языках было куда больше чем сейчас
            Ответить
          • Какие альтернативы?
            Ответить
            • go? kotlin? swift?
              Ответить
              • Та тут надо было всё зелёным, чо уж
                Ответить
                • Почему?

                  Мне 90% того что пишется на скриптах действительно легче и приятнее написать на котлине, например. И у меня будет стат. типизация, комплишен, рефакторинг, файнд юзадж итд
                  А Роману, наверняка, на го


                  На скриптовых хорошо писать скрипты. В один экран. Из двух файлов. Или несложный сайтик.
                  Ответить
                  • Ну, во-первых, для swift'а и вправду есть https://github.com/yonaskolb/Mint, но это полноценное ненужно и под винду его нет, то есть в сраку такой скриптовый язык.

                    Как писать скрипты на go, я представляю слабо, это же мунспик для 99% программистов (хотя учитывая местные нежные чувства к перлу, неудивительно, что ты его упомянул).

                    Котлин действительно лишён вышеуказанных недостатков. И в общем тебе прямо сегодня ничто не мешает писать 90% того, что пишется на скриптах, на котлине. Ты готов?
                    Ответить
                    • >>то же мунспик
                      Как и руби
                      Как и перл

                      >> Ты готов?
                      Не всегда.

                      1) в некоторых окружениях может не быть JVM
                      2) у меня есть проекты на джанге и фласке. Джанга на котлине не реализуема.
                      Ответить
                      • > Как и руби
                        - absolutely. Кроме макожобсов, сидящих на герыче, никто на этой шняге не будет писать в здравом уме.

                        > в некоторых окружениях может не быть JVM
                        - в некоторых окружениях может не быть python. Или будет python, но не будет python3. И в каких таких окружениях не будет JVM? На винде разве что, где нужно будет next -> next -> next -> finish.

                        > Джанга на котлине не реализуема
                        - джанга нет, но какой-то сервак должен быть реализуем, нет?
                        Ответить
                        • >>оме макожобсов, сидящих на герыче, никто на этой шняге не будет писать в здравом уме.
                          ну нет, RoR еще сущестует. Мне руби нра, но я признаю что без предварительной подготовки не прочитать код
                          event :crash do
                                transition all - [:parked, :stalled] => :stalled, :if => lambda {|vehicle| !vehicle.passed_inspection?}
                          end


                          >> в некоторых окружениях может не быть python
                          Тоже верно, но обычно он там есть в каком-то виде, если тебе надо на серваке скриптец то лянотно ставить JVM.

                          >> но какой-то сервак должен быть реализуем, нет?
                          Разумеется, они даже есть. Но в Django много магии, которая на ЯПах со стат. типизацией не реализуема. Зато она сохраняет кучу бойлерплейта.

                          Это трейдофф всегда. Но в целом писать что-то огрмное, сложное, над которым будет работать 20 человек, где будет 300 концепций, писать такое на скриптовом языке в 2018 году я бы не стал
                          Ответить
                          • > Но в целом писать что-то огрмное, сложное, над которым будет работать 20 человек, где будет 300 концепций, писать такое на скриптовом языке в 2018 году я бы не стал
                            - ну вот галера, которая лабает kabanchik.ua, prom.ua (и возможно их аналоги для российского рынка), содержит около сотни питонорабов, пока не потонула. Да, это не гугл, да, это не хайлоад, но who cares
                            Ответить
                            • показать все, что скрытоvanished
                              Ответить
                            • ну это совсем не значит что им хорошо и кузяво)

                              не дай бог кому переименовать поле user в huuser в проекте где 100 разрабов на питоне
                              Ответить
                              • показать все, что скрытоvanished
                                Ответить
                              • показать все, что скрытоvanished
                                Ответить
                              • показать все, что скрытоvanished
                                Ответить
                              • Хорошо ли им и кузяво зависит не от питона или жабы, а от погонщика. Я не думаю, что там все 100 разрабов сидят над одним проектом в одном репозитории и друг другу поля переименовывают ради лулзов и merge conflict.

                                Кстати, это ж вроде задача devops'а, накатить такую миграцию?
                                Ответить
                                • >>Кстати, это ж вроде задача devops'а, накатить такую миграцию?

                                  Ты до такой степени не понял о чем я, что мне даже стало страшно. Давай я попробую снова:


                                  В языках со статической типизацией вроде Java, Kotlin или C# ты (при условии неиспользования рефлексии конечно) про каждый метод можешь сказать где он объявлен.

                                  Для каждого метода, филда и пр. всегда можно легко дойти до его объявления.

                                  Этим пользуются IDE чтобы поддерживать рефакторинги вроде "rename method".

                                  Ты переименовал поле user в owner, и IDE сама нашла все его вхождения и переименовала, а другие user она не тронула.

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

                                  Потому ты легко можешь сломать код таким рефакторингом.

                                  В компилируемых ЯПах ты узнал бы об этом на этапе компилации, но в питоне -- нет. Остается уповать на тесты.

                                  Всё это не имеет проблемы кода
                                  1) каждый разработчик понимает ВСЮ систему (про каждый "user" он может сказать тот это самый user или другой)
                                  2) весь код покрыт тестами и такие проблемы сразу же всплывут

                                  К сожалению, так бывает только в кино. В жизни приходится ковыряться в недокументированном дерьме на 800 строк без единого теста и пытаться что-то там понять (кстати, CTRL+click в Java перенесет тебя на декларацию/дефиницию, а в питоне далеко не всегда ибо IDE может и не знать).

                                  Потому мне и кажется что большой проект с обычными (а не супергениальными) программистами на питоне поддерживать сложнее, чем аналогичный на Java.
                                  Ответить
                                  • показать все, что скрытоvanished
                                    Ответить
                                    • >>А где используется рефлексия, например?
                                      В DI, сериализаторах (в json например), в ORM. Но обычно она поддерживается IDE боль-мень.

                                      пример: Spring (DI контейнер) позволяет в XML описывать бины (пишу по памяти, не видел 10 лет, синтаксис может быть и не такой, но смысль понятен)
                                      <bean scope="Singleton" class="foo.Kurochka" id="koko"/>
                                      <bean class="foo.Pitishoh">
                                         <property name="kurochka"  value-ref="koko"/>
                                      </bean>


                                      Мы создали синглтон курочки и установили ее в одноименное свойство питушка.
                                      По сути вызвался метод "setKurochka" у класса Pitushok (всё это мутабельно и вообще говно, но речь не о том сейчас). Ну вот тут мы использовали рефлексию, но Idea это поймет и будет статически проверять.

                                      >>Но где ты видел проект на питоне где работает большое количество проггеров?


                                      Так Desktop писал же про 100 разрабов:)

                                      В идеальном мире конечно проект надо разбивать на маленькие, независимые сервисы и делать команды на 5-6 человек максимум (и скрам так учит) но не всегда так бывает
                                      Ответить
                                  • > В жизни приходится ковыряться в недокументированном дерьме на 800 строк без единого теста и пытаться что-то там понять
                                    - ковыряться в недокументированном дерьме на 800 строк одинаково приятно что в Питоне, что в крестах, что в перле (ну ок, тут вдвойне приятнее).

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

                                    Ну и конечно я более, чем уверен, что питонячья макака обходится большому папке дешевле жабового гамадрила. Шах и мат, идеалисты
                                    Ответить
                                    • >>одинаково приятно
                                      Не совсем. Быстро что-то найти все таки проще когда у тебя работает find usage в Idea. Но с другой стороны чтобы реально ПОНЯТЬ как что-то работает тебе всё равно придется читать код: что на питоне, что на жаве.

                                      Но прыг-прыг-фикс-хуяк на джаве сделать проще. Ну и хотя бы копеляция тебе даст хоть какую-то слабую уверенность что ты вообще не разнёс все к хуям.

                                      >> питонячья макака обходится большому папке дешевле жабового гамадрила

                                      Это не всегда так, если судить по hh (как ни странно!).

                                      В жавке есть еще всякие ништяки. Например есть омуденные профилировщики, даже обычный YourKit и тот хорош (это примерно как ваши Apple Instruments/dtrace, но по проще).

                                      В питонячьем сообществе многие вообще не знают что можно профилировать (там даже про дебагер не все знают!) и похожих инструментов, увы, нет.

                                      Ну и так, по мелочи хуйня всякая типа многопоточности нормальной (которая конечно не так важна в мире микросервисов и облаков)
                                      Ответить
                                      • Я понял. Просто есть идеальный мир сеньоров, в котором код документирован, покрыт тестами и автотестами, так что никак футер на сайте пропасть не сможет (нафига вообще люди тогда придумали селениумы и протракторы?), у хлопцев CI, DevOps и всё такое. Им шо Питон, шо Жаба, везде будет хорошо.

                                        Есть реальный мир джунов, где народ не сильно в курсе, что можно делать dev, stage и prod, а не хуячить всё в одном окружении на боевом серваке; слово Swagger тут никому ни о чём не говорит. Тут тоже разницы, на чём писать, нет, всё равно получится треш

                                        Ну а у тебя мир вечных мидлов, которые умные слова уже знают, а что с ними делать нет.
                                        Ответить
                                  • > Потому ты легко можешь сломать код таким рефакторингом.

                                    И узнать об этом далеко не сразу, и, возможно от недовольного заказчика.
                                    Ответить
                                    • >>И узнать об этом далеко не сразу, и, возможно от недовольного заказчика.


                                      Ну вроде как в современном вебе это считается хорошей практикой.

                                      Попробуй спросить вебщика почему вместо XHTML теперь HTML5 в котором можно не закрывать таги, и он тебе объяснит что если ты случайно забыл закрыть таг в XHTML (при верном контент тайпе) браузер покажет ошибку, в HTML5 все равно отрендерит страницу, просто кусочек ее не покажет.

                                      Бывает так, что верстун напутал с тагами и footer страницы не виден, и этого долго никто не замечает, а с XHTML сразу бы заметили.

                                      Те же самые аругменты они используют когда я спрашиваю почему xml-based шаблонизаторов больше не делают.

                                      Ну и когда речь про выбор языка со стат типизацией то, вероятно, они руководствуются тем же:
                                      а зачем мне узнавать про ошибку в CI сервере, если можно узнать от нее от заказчика случайно через пол года?
                                      Ответить
                                      • показать все, что скрытоvanished
                                        Ответить
                                        • >>Что это?
                                          в начале нулевых было дофига шаблонизаторов на xml (и xslt конечно же).

                                          Они имели отличную поддержку от IDE (потому что их легко парсить) и были защищены от перепутанных и незакрытых тагов.

                                          Потом все сказали что это сложно и нипанятна, и стали использовать НЕ xmlные шаблонизаторы.

                                          Стало можно писать вот так:
                                          {% if foo.bar.baz == "pitux" %} 
                                          <a href="pithux">
                                          {% else %}
                                          <a href="kuritsa">
                                          {% end %}
                                          foo
                                          </a>
                                          .
                                          Разумеется никакие IDE нормально это не хендлят и проверить что все таги закрыты тоже статически никак нельзя.

                                          И все страшно радуются: ах, как теперь стало удобно.

                                          Держится более-ли-менее разве что JSPX: остальные слились

                                          >>А xhtml руками писать не очень удобно.
                                          а html5 удобно? В чем разница?

                                          Алсо, в XSLT можно было наматчить шаблон на какую-то ноду: например если у тебя есть хотя бы один элемент в коллекции то шаблон вызовится, а если нет от не вызовится. Во всех совремменных надо явно писать if, и это оцтой.
                                          Ответить
                                          • показать все, что скрытоvanished
                                            Ответить
                                            • показать все, что скрытоvanished
                                              Ответить
                                            • >>Зя. Берешь и проверяешь.
                                              как проверяешь то?

                                              >>Ну html был изначально сделан под ручное написание жи.

                                              xhtml это тоже html

                                              >>xml - переусложненное говно и ненужно.
                                              как и статическая типизация, как и IDE как и SOAP. Надо писать на JavaScript в Notepad++ и всё будет хорошо
                                              Ответить
                                              • > как проверяешь то?
                                                Пессимистично, как джавка делает с final. Будет ругаться на некоторые вполне валидные конструкции, но в целом сойдёт.
                                                Ответить
                                                • >> как проверяешь то?
                                                  > Пессимистично…

                                                  Что такое «проверять пессимистично»?
                                                  Ответить
                                              • показать все, что скрытоvanished
                                                Ответить
                                                • показать все, что скрытоvanished
                                                  Ответить
                                                  • показать все, что скрытоvanished
                                                    Ответить
                                                    • Чтобы валидатор это сделал, надо сгенерировать эту страницу и показать ее валидатору.

                                                      Уход от XML-based шаблонизаторов в хипстоту это, суть, уход от статической проверки шаблонов на велл-форменность (и даже, о ужас, на валидность если есть схема!).

                                                      Это ровно так же самая проблема что и с уходом от стат типизированных ЯПов.

                                                      Тобишь чтобы получить гарантию отсутствия незакрытых или перепутанных тегов, которую ты получал статически за 2 секунды в xml, тебе надо покрыть 100% кейсов тестами.

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

                                                      Чуваки взяли, и выкинули на помойку огромный пласт работы, который делал компьютер, и стали делать его сами.
                                                      Ответить
                                                • >>Берешь шаблон и проверяешь валидатором. Разве нельзя?

                                                  Для этого тебе надо запустить приложение, и тестами проверить все его состояния.

                                                  проблема точно такая же как и с отсутствием стат типизации:

                                                  в xml ты статически, Без запуска приложения поймаешь
                                                  "<b></b></b></b"
                                                  Точно так же как в Java ты поймаешь 2 +"petux".

                                                  А в сраных джановых, например, шобланизаторах ты этого не поймаеешь.

                                                  >>А html это не xhtml
                                                  и? В каком месте xml сложнее htmlя?

                                                  >>Ну дай нормальный юз кейс xml.
                                                  Мне кажется я уже тыщу раз приводил, ну ок.

                                                  Я делаю сервис с SOAP: я описываю интерфейс, делаю какие-то структуры, пишу джавадоки, жму волшебную кнопку и получаю .wsdl файл./

                                                  На другом конце земли сидит программист на C#: он тоже жмет кнопку и получает скелеты для клиента к моему сервису.
                                                  У него те же самые структуры и даже доки в них есть!
                                                  То-есть если у меня есть структура Rooster с полем age типа int и комментарием "how many birthdays this rooster celebrated" то чувак на ДРУГОМ языке получит тоже самое. С типом и комментом.

                                                  Теперь представим себе питушков с REST/JSON.
                                                  формальной спецификации у них нет: есть только человекочитаемые описания .json форматов. Синхронизировать ее с кодом надо вручную потому что ничто там типы не проверяет, и доки тоже.

                                                  Доходит до того что если на клиенте чел со статтипизированным япом то он ВРУЧНУЮ создает датаклассы чтобы в них удобно сериализовывать json.

                                                  Вот в первых юниксах не было .h файлов и надо было структуры вручную собирать по мануалам.
                                                  Но к середине 70х уже поняли что если я делаю API то неплохо бы дать его структуры.

                                                  А теперь вот опять откатились в каменный век.
                                                  Ответить
                                                  • показать все, что скрытоvanished
                                                    Ответить
                                                    • чем шаблон от приложения то отличаеца?
                                                      и то и то тюринг полный язык
                                                      Ответить
                                                    • > Шаблон проверяешь! Блядь!

                                                      Вы троллите, или упорно не хотите понять роскомговна, или не знакомы с порблемой останова.

                                                      Представьте себе шаблон:
                                                      {% if lunar_phase > random() %}
                                                      {% render opening_tag1 %}  # какой-нибудь <div class="a">
                                                      {% else %}
                                                      {% render opening_tag2 %} # <div class="b">
                                                      {% endif %}
                                                      </div>
                                                      Такой код уже никак не провалидировать без проверки всех вариантов ветвления.

                                                      А теперь представьте, например, такой код, и попробуйте придумать алгоритм, которым его можно было бы проверить статически:
                                                      {% if lunar_phase > random() then tag = 'span' else tag = 'div' %}
                                                      <{% tag %}></div>
                                                      Ответить
                                                      • показать все, что скрытоvanished
                                                        Ответить
                                                        • >>охуеть пиздец важная проблема
                                                          Это вполне себе проблема, особенно в больших шаблонах с глубокой вложенностью.

                                                          >> Каждый день отстреливаешь
                                                          Не отстреливаю. Следует-ли из этого что проблему не надо решать?

                                                          Я так же не допускаю багов _каждый_ день, значит-ли это что я могу не писать тестов?

                                                          У меня достаточно редко (ну раз в месяц где-то) бывают конфликты мерджа, значит я могу отказаться от VCS?

                                                          >> и это сразу заметно по разъёбаной верстке.
                                                          Совершенно не всегда. Я видел примеры верстки которая едет на конкретных резолюшенах, или у которой незаметно отваливается футер или проблема взлетает только при определенном поведении пользователя (ибо много клиент сайда)

                                                          Кроме того в случае XML IDE может построить дерево статически и буквально подсказать тебе какие таги ты можешь где использовать.

                                                          Anyway, если какую-то проблему можно бесплатно решать с помощью компьютера, то зачем её решать вручную?

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

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

                                                          Во-вторых, разговор идёт не о важности незакрытых тегов, а о дисциплине веб-программирования в целом. Например, нам известно, что легко было бы сделать так, чтобы все теги гарантированно были закрыты. Средства для этого давно существуют и их назвал роскомговно. Но почему-то настойчиво и во всех пунктах сообщество выбирает в пользу решений, в которых статическая проверка невозможна ни в какой мере. Так же поступает и стандарт: разрешает разработчикам так поступать, попуская незакрытые теги и так далее. В чем профит — сказать трудно, видимо всем важно, чтобы валидировалось вообще что угодно, набранное на клавиатуре, и писать сайт могли даже шимпанзе, которых я очень люблю. Если речь идёт действительно о компьютеризации приматов, я — за.
                                                          Ответить
                          • показать все, что скрытоvanished
                            Ответить
                    • > мунспик для 99% программистов

                      Лолчто

                      Язык тупой до безобразия, в либе полно всякого добра, для всяких скриптов норм подходит (уж лучше это говно, чем Python).
                      Ответить
                      • ок, не буду спорить с любителями устриц.

                        Мне тоже в Питонии не нравится излишняя динамичность, runtime-errors driven development и может что ещё, но для скриптов/тулзей это ок.

                        А по поводу серваков я в соседнем треде скинул ссылки три на бэкенд-фреймворки на Swift'е. На убунту взлетит
                        Ответить
                      • Попробовал - понравилось
                        Ответить
                  • показать все, что скрытоvanished
                    Ответить
                    • котлин чуть по-чище, но и c# хорош

                      ну и jvm под линуксы от оралка, кмк, более серьезна чем core.net
                      Ответить
                  • показать все, что скрыто>>>"И у меня будет стат. типизация"

                    Так сложно при случае воспользоваться "intval" в "PHP" или "*1" (даже не "ParseInt") в "JavaScript"?...
                    Ответить
              • показать все, что скрытоvanished
                Ответить
                • во-первых найдешь, во-вторых 90% вопросов на SO задают люди, которые не умеют читать документацию.

                  Если у тебя больше одного года опыта то ты почти никогда не нуждаешься в SO
                  Ответить
                  • показать все, что скрытоvanished
                    Ответить
                  • Это, мягко говоря, преувеличение, про больше года опыта.

                    Иногда официальные доки куцы и не покрывают всех нюансов, примеры не полностью документированы, а все туториалы дальше этих самых примеров носа не суют. Это случай фирмы Эппл (см., например, CallKit)
                    Ответить
                    • Стоп, мы про языки или про фреймворки?

                      Фреймворк может быть непонятен даже тому, у кого 25 лет опыта писания на этом языке.
                      Речь же шла о том, что если возникнет тупой вопрос по go то на него сложнее найти ответ чем на PHP./
                      Ответить
                      • Как ты понял, что именно об этом шла речь в комментарии guest8? :)

                        Ну, разве что именно ты его и написал! Файка Борманда
                        Ответить
                        • >> т.к. эти языки ещё не заслужили популярности.

                          Если у меня проблема со Spring, но мне пофиг на Kotlin я или на Java.
                          Если у меня проблема с UIKit, но разве важно пишу на свифте или на objc?
                          Ответить
                          • > важно пишу на свифте или на objc?
                            - на SO это обычно две разных категории ответов (т.е. тегов), или же в ответах есть и про то, и про другое, в самых модных случаях авторы ответов указывают варианты для обоих языков. Потому что иногда реально есть разница, ведь это же разные языки, верно?
                            Ответить
                            • а фреймворк они указывают?

                              >>разные языки

                              работа с CallKit отличается для objc и swift?
                              Ответить
                              • > а фреймворк они указывают?
                                - если вопрос про фреймворк, то да.

                                > работа с CallKit отличается для objc и swift?
                                - честно не ебу, в целом API, понятное дело, одинаковый, но осознавать те же enum'ы иногда мучительно больно.

                                А, если говорить про фреймворки не от Apple, то там вообще иногда отдельные версии под ObjC и под Swift, в Realm вроде так.
                                Ответить
                      • показать все, что скрытоvanished
                        Ответить
                  • Попадалась либа, вся документация к которой состояла из... ответов на SO. Типа спрашивайте, мы вам ответим.

                    З.Ы. По тем же крестам иногда приходится смотреть т.к. тонкие моменты в стандарте сложно отыскать.
                    Ответить
                    • Кресты -- ок, это отдельная песня.

                      зы:попадалась либа вообще не документирвоанная. Никак. Максимум пара примеров. В последнее время таких все больше. Думаю, надо за такие либы пиздить.
                      Ответить
                    • Так это много у кого так.
                      Ответить
                  • > больше одного года опыта

                    Больше одного опыта в чём? В 80% процентов случаев я нахожу ответ пока пытаюсь сформулировать хороший вопрос на SO.

                    У нас ещё есть аналог SO внутри компании, я им постоянно пользуюсь, когда нужно нетривиальные вещи о работе или дизайне внутренних сервисов узнать.
                    Ответить
                    • показать все, что скрытоvanished
                      Ответить
                    • >>Больше одного опыта в чём?
                      в программировании.

                      Вы все как-то умудрились не понять что я говорю.

                      Собесеник сообщил что писать на go сложнее чем писать на PHP потому что ответов на вопросы по языку на SO будет меньше.

                      На что я сказал что обычно хорошему программисту достаточно книжки и референса по языку чтобы с ним разобраться.

                      Если такой программист задает вопрос на SO, то обычно он связан алгоритмами или API фреймворков, ОС итд, но не самим языком.

                      То-есть вопросы "как проитерироваться по такой-то коллекции" сеньёры обычно не задают.

                      Борманд правда отметил что с С++ это не так, ну окей: наверное в с++ можно что-то не понять в стандарте и с 10 годами опыта

                      >> В 80%
                      Ну так это же rubber duck debugging. Хороший вопрос -- половина ответа.

                      >>аналог SO внутри компании,
                      Вам везет:) У нас есть какие-то статьи на конфлюенсе, какие-то видео со внутренних выступлений и канальчик в слаке, но самое распостраненное решение это "подойти к Васе и спросить как пользоваться его сревисом". И это дико расстраивает
                      Ответить
                • > "Huiotlin"
                  - прочитал как guillotine
                  Ответить
              • показать все, что скрытоvanished
                Ответить
          • >джвадцать джва года жду, когда всё это недотипизированное скриптоговно уже сдохнет.

            https://embedy.cc/movies/c0lkbEhCOWlUTzhpSUI0TFQrVlV5YU5hYjIvb1FF eGxLZEc1ZEE2blp1RT0=

            Правда я не совсем понял, о питоне ты или о рнр.
            Ответить
            • показать все, что скрытоvanished
              Ответить
              • Почему когда я скомпилировал .kt файл в .class файл и запустил его в JVM вы говорите что я пишу на компилируемом языке, а когда я скомпилировал .lua файл с помощью luac и запустил его через виртуальную машину lua, вы говорите что я пишу на интерпретируемом язуке?
                Ответить
                • показать все, что скрытоvanished
                  Ответить
                  • я покрыл весь кол на питоне тайпхинтингом и скомпилировал его в .pyc
                    или я сделал тоже самое с php (там вроде можно явно указывать типы) и с помощью zend скопилировал его

                    ну, я все еще программист на интерпретируемых япах?

                    кстати, у Kotlin есть repl консоль. А уж про груви я и вовсе молчу: она как-бы скриптовая но компилируетс яна лету
                    Ответить
                    • Программы на lua, php, python, распространяются в исходных кодах. Во что там они компилируются для выполнения — хуй пойми, это всё непереносимо и не существенно. Никакая другая технология не стремится, например, компилироваться в .pyc (или, не дай Бог, в пхп-байткод) для какой-нибудь совместимости или переносимости.

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

                      Такая мысль меня посетила, вкинул для дискуссии. Рушится вроде как об JS. Тот нихуя не переносим, и считается компилируемым при этом.
                      Ответить
                      • Многие программы на си тоже распостраняются в исходниках, и конечно же они не переносимы в бинарном виде между разными ОС и уж тем более между разными архитектурами.

                        В юниксах это вообще классический путь. Большинство юниксов сейчас имеет предкомпилированные пакеты для большинства программ, но есть же gentoo и arch, да и бздуны делают пекеджи не из всех портов, есть слаковые slackbuilds которые тоже тянут исходники.
                        Ответить
                    • > я покрыл весь кол на питоне тайпхинтингом
                      Как эротично звучит...
                      Ответить
                • показать все, что скрытоТы заебал со своей луёй.
                  Ответить
          • Ну как, дождался?
            Ответить
    • Вообще конечно забавно смотреть на их кривлянья: мы не такие, There should be one—and preferably only one—obvious way to do it.

      И в 2к18 лет тащить сайд-эффектные фичи сишкоязыков. В целом конечно насрать, поскольку питон дальше калькулятора не использовал.
      Ответить
      • показать все, что скрыто>>>"питон дальше калькулятора не использовал"

        И то клеймо...
        Ответить
      • >>тащить сайд-эффектные фичи сишкоязыков
        можно подробнее?

        >>and preferably only one—obvious way to do it
        compared to ruby and perl -- yep
        Ответить
      • показать все, что скрытоvanished
        Ответить
      • Я раньше тоже питон как цальцулятор юзал, пока не познал J. На нём с массивами удобно работать, и кобенаторику он умеет:
        NB. я дрочу на этот язык
           (i.@!@#A.])7 u: 'хуй'
        хуй
        хйу
        ухй
        уйх
        йху
        йух
           
           NB. матрица с рандомными числами [0, 10)
           ] a =: ? 3 3 $ 10
        2 7 9
        3 2 1
        2 9 5
           
           NB. оперделяем оперделитель
           (-/ . *) a
        118
        Спасибо, я кончел.
        Ответить
        • показать все, что скрытоvanished
          Ответить
          • guest8, ты уже совсем поехал со своим асмом.
            Ответить
            • показать все, что скрытоvanished
              Ответить
            • > guest8, ты уже совсем поехал со своим асмом.

              Особенно удивительно слышать такое от Борманда…
              Ответить
              • >…
                horizontal ellipsis? Серьезно? Ты это вручную делаешь или у тебя автозамена?
                Ответить
                • Compose key же, недавно обсуждали.
                  Ответить
                  • да, но для отточия..
                    Ответить
                    • ComposeKey+.+. = …
                      Я тоже всегда так делаю…
                      Ответить
                      • Тёма лебядев утверждал что так делать для отточия не надо, но он мог и напесдеть.

                        А вот за правильные тире и кавычки вы достойны всяческих респектов. Вы еще может и ёшки ставите?
                        Ответить
                        • Односимвольное отточие в большинстве шрифтов выглядит не так, как три точки подряд. Сравни:

                          ...

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

                          Ёшки — ты имеешь ввиду буквы «ё»? Ну, у меня уже рефлекс после клавиатурных тренажёров. Я если даже захочу, с трудом получится везде «е» ставить.
                          Ответить
                          • https://tema.livejournal.com/107311.html

                            Но, повторюсь: он мог и спиздеть.

                            Забавно: символ "..." используется для обозначения varargs в Java и Lua.

                            Лень проверять, но уверен что … там не сработает
                            Ответить
                            • > Лень проверять

                              Я тебе и без проверки скажу: не сработает, и хорошо, что не сработает. Не хватало ещё такую дрянь жрать.
                              Ответить
          • Месим мусор в памети :D
            Ответить
        • >>как цальцулятор юзал, пока не познал J
          юзай dc(1)
          Ответить
    • https://i.redditmedia.com/Wh90_LDQhtx1gTRSdfbF-2RzpG-wPhgqW-uvuQDr19U.jpg?fit=crop&crop=faces%2Centr opy&arh=2&w=640&s=c25bcdf16d95304cbcdd63 83323dd27e
      Ответить

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