Какой язык программирования учить в 2018 году и почему именно его?

    Если Вы настойчиво хотите попасть в команду разработчиков компилятора или в «мир Дикого Запада» — то смело выбирайте и учите топовый язык программирования из TIOBE и лучше всего: на уровне его спецификации. А если серьезно, то сейчас в отрасли все так запутанно с логикой и выводами, столько маркетинга и воды, что самая выигрышная стратегия — включить свои собственные мозги и сделать экспресс-переоценку технических ценностей, к которым мы так привыкли. В посте я постараюсь максимально ясно сориентировать начинающих свою карьеру разработчиков по рискам выбора технологий и сделать правильные и далеко (далеко-далеко) идущие выводы.

    Вы уже повзрослели или пока еще нет?


    Дети отличаются от взрослых пониманием слова «ответственность». К сожалению, далеко не все дети — взрослеют вовремя, а некоторые — так и умирают в памперсе. Ничего страшного тут нет — кроме одного: дети в команде программистов заставляют других очень сильно страдать, особенно когда сроки горят и релиз близко: либо внезапно обделываются посреди опенспейса, либо требуют соску во время мозгового штурма предметной области с представителями клиента.



    Взрослые отличаются от детей пониманием ключевого принципа IT-менеджмента: «программирование — это привилегия». Среди опытных и успешных коллег-разработчиков наиболее адекватные и кодят хорошо и «двигают компанию вперед» одновременно.

    IT-индустрия — сошла с ума


    Да, мы — люди и склонны к эмоциям. Но до сих пор никто не знает, как правильно нужно программировать, хотя прошло уже больше 50 лет с момента изобретения компьютера. Никто! Все только истерят и пытаются привлечь в свой лагерь все больше сторонников, одновременно соблазняя бизнес создать на «себе» проект :-) Поясню на примере.



    Скорость «головного мозга»


    Дело в том, что первые компьютеры работали действительно медленно, очень медленно, и были очень дорогими. Поэтому первые программы писали на очень низкоуровневых языках, а иногда прямо на машинном коде. Сейчас подобные «доисторические» технологии иногда применяются, но точечно: для создания операционных систем и их компонентов (близких к «железу»), для игровых движков, для высокопроизводительных библиотек и серверов, для криптовалют и, конечно, для создания языков программирования.

    И если C, несмотря на его тотальную дырявость и высокую опасность для разработчика, получился действительно хорошим и завоевал сердца ценителей, то C++ получился на редкость уродливым и противоречивым созданием — но что делать, это жизнь. Может Rust, с правильными идеями относительно безопасной работы с памятью, повлияет на ситуацию в лучшую сторону, но по уродству синтаксиса и нечитаемости он, похоже, оставил C++ далеко позади.

    Ситуацию еще больше усугубляет появление Golang. С одной стороны — ничего нового в нем нет, дембельский аккорд великого Кена Томпсона: лишь жалкие остатки от возможностей Java. С другой — стало действительно проще писать «относительно» системный и многопоточный софт и это факт, который оценили многие компании :-)

    В этом лагере Вы встретите преимущественно глубоко знающих низкоуровневые технологии и железо «настоящих» хардкорных бородатых программистов, которые учили, как правило, один язык программирования — зато всю жизнь и засыпают со спецификацией компилятора вместо жены. Воистину — в этом лагере крутые люди. И если Вы не знаете, на какие команды x86 процессора раскладывается yield в python — стыд Вам и позор. Поэтому совет — избегайте этого лагеря, пока не дочитаете до конца поста.

    Но есть и обратная сторона медали. Проекты тут делаются не то что долго, а… десятилетиями. Низкоуровневые языки программирования не то, что помогают, а наоборот — мешают. Постоянно происходят нарушения в работе с памятью, требуются десятки и сотни тестировщиков (либо можно выложить на github и тестировать будем мы с вами коллективно) и тысячи unit и других видов тестов, чтобы «оно взлетело». Многие разработчики, которые влились в команду на старте проектов, не доживают до релиза и умирают от старости, помогая до последнего вздоха бета-тестерам. Но эти мужественные люди, до кровоточения из глаз, до появления стигматов делают все возможное и… рождаются шедевры.



    Архитектура и энтерпрайз «головного мозга»


    Т.к. никто до сих пор не знает, как нужно правильно программировать, методом естественного отбора образовался лагерь «грамотного проектирования и надежности». Вы с ума сошли программировать на языках, допускающих небезопасные операции с памятью через указатели — так же можно мир довести до апокалипсиса: «segmentation fault в софте ядерного реактора». Как можно начинать вообще делать проект без поддержки строгой типизации в языке?? И придумали очередные правильные языки программирования: Java и C#. Но в Java забыли о вреде null-значений, а в C# — не до конца продумали обратную совместимость. В результате образовался огромный корпоративный, относительно безопасный и относительно обратно совместимый мир. В этом мире цель измеряется строками кода в день (обычно не больше нескольких десятков, ибо пальцы растираются в кровь) и толстыми философско-религиозными книжками про шаблоны проектирования и, о да, чуть не забыл, про способ зарыть себя, проект, клиента и окружающий мир в код и утонуть в нем, вспоминая в агонии 20 уровневую иерархию наследования — про ООП. Один из основных девизов лагеря — «зачем делать просто, если можно… сложно и надежно, надолго, на века!». Причем некоторая часть умеет писать таки быстро и элегантно, стирая руки в кровь и собирая в голове каждое утро структуру проекта, смотря одновременно на 3 монитора. Но некоторые так увлекаются, что продолжают создавать иерархии иерархий внутри иерархий иерархий до бесконечности — и цель уже давно потеряна, а глаза продолжают гореть и руки чесаться.

    На самом деле, в областях, где предметная область хорошо устаканилась и укладывается в «объекты со статусом и сообщения между ними» — подобный подход работает очень хорошо.



    Особенно радует при «строгой» (кавычки, потому-что дальше будет про haskell) статической типизации (это когда заранее известны типы сущностей, они проверяются компилятором и к числу нельзя прибавить строку) легкость и удовольствие при проведении рефакторинга и улучшения кода и высокое, если не сказать великолепное, качество сред разработки. Коллеги в этом лагере часто очень образованы в архитектуре софта, много читают (порог входа — высок), разбираются в возможностях многочисленных библиотек платформ, шаблонах проектирования, техниках написания тонн документации и создания автоматизированных тестов, тестах этих тестов и могут месяцами писать mock, который окажется ненужен. Опять таки — часто проекты делаются и запускаются весьма долго, большими командами, требуются многочисленные тестировщики, но характер ошибок на порядок менее фатален, что вдохновляет. Попасть в эту «касту» энтерпрайз-разработки — очень непросто. Если вы продемонстрируете, как на PHP можно решить задачу в 5 строк, которую коллеги на java решат за 5 дней — вас заживо сожгут в микроволновке :-)

    Надежность «головного мозга»


    В академической среде образовался еще один, очень интересный и рекомендуемый к пониманию лагерь и набор функциональных языков программирования (Lisp, Haskell, Erlang и другие). Вы что, с ума сошли программировать с использованием переменных и циклов — так же можно натворить много ошибок! Программа это — набор вызовов функций, а вместо циклов — используйте рекурсию, господа! ООП? Нет, не слышали — typeclasses и алгебраические типы данных. Не знаете об аппликативных функторах и не листали теорию категорий — да вы не развиваете собственный мозг, батенька.

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



    Результат и эффективность «головного мозга»


    К черту архитектуру и ООП, брат! Ктулху любит тебя, а утиная типизация — ключ к успеху! Строгая типизация? А кто в здравом уме будет присваивать к числу строку?? Статическая типизация и компиляция — трата времени, ибо код пишется один раз и если его не успеть написать к релизу, его выбросят (да и так выбросят, но чуть позже). Рефакторинг? Сразу пиши правильно :-) Инкапсуляция? Поставил черточку перед именем переменной и все дела. ООП — переусложнение без нужды. Какая к черту компиляция — F5 и видишь результат. Шаблоны проектирования — нет, не слышали: скриптинг наше все… Хочешь «травки»?

    Самое интересное, что когда вникаешь в языки с динамической типизацией (строгой в python, нестрогой в php и javascript) то постепенно открываются глаза на реальную картину вещей, ибо:

    • код становится очень ясным и кратким и не нужно лазать по 20 классам (если дело не касается системных библиотек)
    • можно быстро проверить идею через REPL
    • языки просты, часто минималистичны, содержат необходимые и мощные примитивы (списки, словари), которые, что самое главное — помещаются в голове!
    • имеется туча библиотек и всегда можно в 5 строк решить любую задачу

    И черт с ним, с рефакторингом :-) Жить-то веселее стало (я надеюсь разработчик, поддерживающий мой код, не узнает, где я живу). В этом лагере вы часто встретите множество жизнерадостных людей совершенно разных специальностей, кроме «программирования на ассемблере», умеющих, тем не менее, очень быстро и эффективно, в 5 строк решать задачи и долго и успешно поддерживать код и веб-проекты.

    Посмотрите на последние тенденции в этом лагере и проникнитесь этой философией счастья. Простая и понятная среда программирования в браузере, ну что может быть сексуальнее?



    А как просто можно сейчас поднять неблокирующий веб-сервер, обслуживающий тысячи соединений в 10 строк на node.js и комьюнити растет как на дрожжах?

    И никаких «Eclipse XML Soap Entiny beans энтерпрайз ООП...» — json и csv и улыбка (и запах неизвестного растения). И код при этом читается, и помещается в мозг и поэтому долго и счастливо работает и поддерживается с той же легкостью долгие годы.

    И оказывается, что «так» тоже можно успешно программировать и потраченные в «промышленных языках программирования» годы — прожиты зря (зато пальцы стали крепче).

    Выбор технологии


    Вы в шоке? Я тоже. А представьте в каком изумлении пребывают клиенты, выбирающие технологию для реализации бизнес-проекта! :-)

    Я думаю Вы в данный момент хорошо поняли, что IT-мир действительно сошел с ума и потерялся (шутка). Некоторые языки программирования, типа Scala, пытаются усидеть на всех стульях, но это у них пока не очень получается — код становится сложно понимать простым смертным. А если серьезно, то конкуренция парадигм программирования будет только усиливаться ибо… задачи в проектах существуют совершенно разные и именно от задач и нужно «плясать»! В устаканенной предметной области (серверы, библиотеки) лучше подойдет номинальная типизация (С++, Java, C#...), где-то лучше будет со структурной типизацией (Golang, Haskell...), а в скриптинге веба или задачах машинного обучения придет настоящее счастье с утиной (python, php, javascript...). Не нужно думать, что статическая типизация, особенно строгая, это прямо «must have» — вы провалите сроки и код с удовлетворенной параноидальной мыслью о «возможных ошибках» будет выброшен на помойку. В вебе, скриптинге и машинном обучении можно уверенно двигаться с большой скоростью вперед и с динамической утиной типизацией и php и python с огромным количеством прекрасных и мощных библиотек этому хороший пример.

    Поэтому забудьте про «какой выучить язык программирования в 2018 году» к чертовой матери:

    • разберитесь в парадигмах программирования (ООП может быть могилой, а может спасти Вам проект)
    • поймите тонкости типизации и связанные с этим риски и возможности (Вы можете проклянуть динамическую типизацию в финансовой библиотеки, а можете принести в жертву Ктулху java-программиста и переписать его 100 классов на 100 строках в понятном даже детям скриптике)
    • на уровне интуиции разберитесь в алгоритмах (нужно отличать поиск от сортировки, а нейронную сеть от логистической регрессии — а чтобы понять дальше, придется учиться… всю жизнь, но оно стоит того)
    • поймите, что опытные разработчики (правда никто не знает, где их найти на рынке) реализуют проект в срок практически на любой технологии (даже на brainfuck) и сделают это хорошо, а вот неопытным придется подбирать язык программирования с самым комфортным уровнем вхождения и риски коллапса все равно велики

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

    • посмотрите, на чем люди решают эти задачи
    • раскидайте по критериям выше риски и возможности каждого инструмента
    • посидите пару выходных с 1-3 конкретных инструментов, но не в коем случае не до фанатизма или спецификаций
    • быстрее беритесь за дело и накапливайте опыт применения инструментов на практике — это самое главное
    • не нужно учить язык программирования «до конца» — лучше выучите способ решения Вашей задачи в 5 самых популярных инструментах в 10-15 строк и вы поступите на самом деле в высшей степени адекватно!

    Конкретный пример — ML


    Допустим, Вам интересно машинное обучение… Поздравляю! С одной стороны находится академическая теория — но из нее Вы должны вытащить суть по матстатистике и линейной алгебре и ни в коем случае не зависать на многомесячных курсах (сойдете, поверьте мне, с ума, если вы не математик, а гуманитарий — причем незаметно для себя). С другой стороны нужно научиться быстро писать полезный код и решать задачку в 5-15 строк. Да, можно все написать на C лет через 10 000, поэтому Вы смотрите на опыт коллег и выбираете, правильно, python, в котором на данную тему море библиотек и готовых решений. Вы посвящаете изучению python пару выходных — больше там нечего учить, язык очень прост (а в дебри мы договорились не лезть, ибо время-деньги).

    Дополнительно еще почитайте про суть numpy, pandas, scikit-learn и, если прямо глаза горят, то Keras и вперед, делать проекты. Но можно пойти по другому пути, долгому, трудному и ведущему к личной святости и социальной бедности (поймете через 3 года суть алгоритма, продавая газеты в электричке, но может это такой, особый путь) — начать реализовывать алгоритмы самостоятельно, с ручным управлением памятью, или внедрить более тяжеловесное решение и зарыться в коде на месяцы. Неправильно выбранный инструмент — ключ к бессонным ночам и бесцельно потраченному времени — избегайте сложности всеми способами.

    Неправильно выбранный инструмент, даже самый распиаренный, даже бесплатно в подарок, пускай даже теоретически все умеющий в перспективе — может угробить вам проект, провалив все сроки. Минимизируйте этот риск как только можете и не можете.

    Выводы


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

    • избежать залипания и погружения в излишние технологические детали, число которых экспоненциально растет
    • выбрать интересную область задач, в которой вам интересно решать задачи клиентов
    • научиться извлекать из инструментов и языков программирования короткую и эротичную суть
    • писать как можно меньше, но ясного и понятного вам и окружающим людям кода
    • научиться решать задачи в 5-15 строк, а не 20-50 классов
    • если и хочется куда нибудь углубиться, то пусть это будут фундаментальные вещи типа математики, haskell или rfc по tcp/ip
    • получать от программирования удовольствие и согревать им ваших коллег!



    И всегда помните, что время, особенно свободное — ценный ресурс и от нас самих зависит, куда его инвестировать. Удачи всем и хорошего настроения!
    1С-Битрикс
    73,00
    Компания
    Поделиться публикацией

    Комментарии 311

    • НЛО прилетело и опубликовало эту надпись здесь
        –8
        Представь, ребята выбирают сейчас какой язык программирования учить. А нужно-то совсем не об этом думать :-)
        • НЛО прилетело и опубликовало эту надпись здесь
            +1

            Без знания хоть каких-то языков думать-то будет особо не о чем. Или надо думать как собеседование пройти, что учить — покажут?

              –2
              Собеседования — отдельная тема. Часто спрашивают отвлеченную ерунду, которая не нужна в реальных проектах.
                0

                "Хоть какие-то языки" — это месяц на первый и по неделе на каждый последующий (во всяком случае, в рамках императивной парадигмы). Это если никуда не спешить, конечно.

                  –3
                  В php, python, js можно прямо быстро въехать и даже писать что-то полезное очень стремительно. А вот с C++, java там, конечно, месяцы… Но стоит ли оно того?
                    –1

                    Не всем надо быть Александреску. А до уровня "C с классами" — та самая неделя, и это покрывает бОльшую часть потребностей (лично мне не хотелось бы разгребать ко за джуниором, увлёкшимся метапрограммированием на темплейтах).

                      –4
                      Но в крестиках та же дилемма что в java — куча классов и абстракций, вот пишешь пишешь, тесты пишешь пишешь (если время дают), бац и отвлекся. Потом открываешь — вау, вау, столько кода. Блин, ничего не понятно, страшно запускать. А так открыл скриптик на 1000 строк и в нем вся бизнес-логика с комментариями.
                        +2
                        Так абстракции предназначены именно для борьбы со сложностью.
                          –5
                          Да. И ООП — методика борьбы со сложностью. Но получается, что… ты как-бы теряешь контроль, контекст, не помнишь что внутри что вызывает. Вот сделал ты объект, определил для него операции, вызываешь их, затем еще и еще. А можно было скриптом и обычным встроенным словарем это решить и более наглядно и читаемо. Пост как раз про это — про то, что никто пока не знает, что делать.
                            +4
                            Не нужно смотреть внутрь без острой на то необходимости. Оно просто будет работать. А статические проверки компилятора еще и проверят, что по пути не вкралась гнусная очепятка.

                            Невероятную ерунду можно сделать и в скрипте. А оправдывать преимущество скриптов меньшим количеством логики — это… достаточно странный аргумент) Мне кажется, тут стоило бы добавить какой-то конкретики.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Вот именно, в Symfony настоящее ООП головного мозга. В Битрикс-движке все гораздо лучше же
                              +1
                              Чем же там лучше?
                              Пока дочитал до 100(где наконец то встретил else) строки в файле из 1000 строк, уже забыл с чего начал.
                        +3

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

                          0
                          Ну на питоне тоже можно операторы попереопределять и запутать людей к чертовой матери. Но философия скриптинга учит обратному — простоте, читаемости
                          0
                          Не путайте языки, стандартную библиотеку и всю экосистему.
                            –1
                            не понял, что я путаю?
                              +1
                              Языки как праивло изучить легко (C++ на уровне С с классами), сложнее со стандартной библиотекой, а ещ' сложнее со всей єкосистемой разобраться, например Spring в Java сложнее самой Java :)
                                0
                                :-) мне с библиотеками обычно проще. А спринг да, это песня
                                  +1
                                  Не надо изучать С++ на уровне С с классами, пожалуйста.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Нет, сразу не надо, просто останавливаться на уровне C с классами тоже не стоит.

                                      Популярным C с классами, думается, сделало не это, но это отдельный долгий разговор.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0

                                          Не в темплейтах дело. Если вы используете std::unique_ptr вместо голых new/delete, std::string_view вместо const char*, понимаете, что такое move-семантика, зачем она нужна и как она вам может быть полезна в ваших задачах, что такое лямбды, зачем они нужны и как они могут быть полезны в ваших задачах, как constexpr-функции позволяют писать более надёжный, поддерживаемый и эффективный код, и тому подобные вещи, то это точно уже не С с классами.


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


                                          У меня знакомый чувак есть, кстати, эмбеддщину всякую делает. Он сначала тоже говорил, что нафиг эти плюсы не нужны, темплейты, фу, С наше всё. А потом как-то проникся.

                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              +1
                                              Неа.
                                              1. new/delete нужен потому, что malloc/free не вызывают конструктор и деструктор соответственно. Более того, malloc'у тупо никак не вызвать конструктор, имеющий более нуля параметров.
                                              2. Умные поинтеры нужны потому, что требовать от программиста ручного управления памятью в 2011 году несколько несерьёзно. Да даже в 2000-м тоже несерьёзно, на самом деле, но auto_ptr действительно говно, а move-семантики тогда не было.
                                              3. Классы вообще ортогональны лямбдам. Я не понимаю, что они у вас делают в одном предложении.
                                              4. Шаблоны тоже не сказать чтоб замещают классы.

                                              Ну и стоит сказать, что есть крупные проекты, где нет malloc/free, и где от голых new/delete избавились, даже если они были.
                                                0

                                                Да, так эволюционирует язык. И то, что в каком-то дремучем легаси используется new и delete и всё работает — это прекрасно, ведь можно прийти и малой кровью это переписать.


                                                В новом коде их использовать почти никогда не надо, за исключением специфических случаев, типа Qt, где другая модель управления памятью, чем в современном C++.

                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    Стрелять в руки и ноги вам никто не запрещает и с шаред_поинтерами какими-нибудь. А на уровень байтиков и ручного управления, чего там куда, всегда спуститься можно.

                                                    А вот в Rust какой-нибудь там dlib пока так и не завезли, увы.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                        0
                                                        Там темплейты какие-то ещё.

                                                        Ну и я не приводил эту библиотеку как образец современного C++17-кода. Скорее как пример, почему люди не уходят на Rust (потому что там таких библиотек нет).
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                            0
                                                            Так себе и представил, как пара сотен непосредственно участвующих в стандартизации людей бросает всё и переписывает все библиотеки, нужные хоть кому-то, на расте.
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                0
                                                                Потому что сегодня в 2018 году я могу обмазываться темплейтами, констекспрами и make_shared, при этом вполне используя библиотеки из 2005-го года, у которых весь этот голый ужас на голых указателях скрыт от моих глаз.
                                        0
                                        Я учил по 2-му изданию Страуструппа. Кажется сейчас это называется «С с классами».
                                          –1
                                          Страуструп для первого прочтения — это не для слабых духом.
                                            –1
                                            Я ещё и ООП по нему изучал. :) Больше ничего в областной библиотеке не было.
                                    0
                                    Не путайте языки, стандартную библиотеку и всю экосистему.
                                    Многие так говорят, как будто язык в вакууме существует. Всегда стоит оценивать всю экосистему.
                                      0
                                      Я не про оценку, а про учение с целью получить первую работу или стажировку на выбранном языке.
                          +12
                          Слишком много теста! Нужно больше картиночек!
                            0
                            Я и так писал и плакал :-)
                              +3
                              Да вот чувак пару дней назад про гопников на хабр запостил. текста ноль, зато картинок пруд пруди. Заминусовали, однако.
                                +2
                                Судя по «сухому счету» эстафету принял битрикс)
                              +13
                              Картинки, не критически важные для основного смысла статьи, надо запретить к чертовой матери. Максимум — КПДВ. Ну это же не Пикабу, в самом деле-то, а?
                                –9
                                А что я не по теме поставил? :-)
                                  +3
                                  А зачем они? Это-же не комикс.
                                    +1
                                    Статю не читал, решил сразу окунуться в трэш — нажал на комменты. По Вашей подаче поднялся до кдпв и ниже. Вот это трэш. Короче, так нельзя — я не про картинки, а про посыл статьи (я сразу понял что все будет не так или наоборот именно так). Я даже комменты читать не хочу — ну холивар же будет, хотя, захоти я скоротать время отличное чтиво, готов поспорить. Автор ну тролль что-ли, хороший ход, а чё. Столкнуть лбами миллион программистов дорогого стоит.
                                      0
                                      Да погоди :-) Пост лучше прочитай. Дело не в троллинге — я проблему описал, свое видение отрасли. Никакого холивара, просто трезвый взгляд.
                                        0
                                        Увидел только щас — 1с-битрикс, Вас заставили это сделать? Готов поспорить, везде ведь вменяемые в целом люди работают, ну почему так то?
                                          0
                                          Заставили? Нет, мы регулярно смотрим вокруг, анализируем и думаем.
                                        0
                                        Я вот тоже наткнулся на картинки — и не стал читать, потом почитал коменты и тогда уже и статью =) Дурацкая мода последние годы — пихать картинки куда ни попадя, по теме или нет.
                                        А статья, в целом, нормальная.
                                    +1
                                    КДВП КДПВ рознь. Помнится одним моментов, которые отбили желание ходить на почивший Мегамозг, это были абсолютно дурацкие КДПВ, причём в большинстве случаев.
                                      +4
                                      Да пожалуй уже Пикабу.
                                      +1
                                      А как же www.1cpp.ru/index.php/Main — 1С++?
                                        –3
                                        Это тема для отдельного поста :-)
                                        –3
                                        Парни, вы просто не слышали выступления Александра на HL++ и т.д. У него всегда полный зал, картинки на слайдах на самой тонкой грани и огонь-контент. Это очень привлекает аудиторию и позволяет спикеру втолкнуть в голову аудитории сложные вещи в нетрадиционной форме. Здесь та же история — и, конечно, картинки в тему (с поправкой на темный юмор) и сами тезисы заслуживают внимания. Не знаю, как вы, мне по кайфу было прочитать и в офисе обсудить. Мы ставим на бессмертные С++ и Java — зоопарк энтерпрайзных проектов поддерживать и допиливать предстоит ещё оооочень долго. И JavaScript c PHP — на них столько говнокода и годнокода, что жить и жить.
                                          +6
                                          А без смищьных картиночек смысл статьи уже не донести? Человек вроде неглупый, пишет какие-то важные вещи, зачем это петросянство этот цирк с лабутенами и памперсами? Все эти смешнявки только отвлекают от тезисов и вызывают раздражение. Статью тупо неудобно читать. И неприятную ассоциацию с более другим сайтом, где хайрейтовые персонажи творят все, что угодно, не опасаясь быть слитыми.
                                          +2
                                          Ну вот, кстати, что веб-ерунду, что серверы-библиотеки вполне неплохо пилить с хаскелевской типизацией, утиная и, соответственно, C++-style-типизация там не даёт какого-то выигрыша, ИМХО.
                                            –3
                                            Ну в хаскеле у нас структурная типизация: typescasses, с «а ля» множественным наследованием, хотя формально так нельзя говорить. Спасут конечно алгебраические типы данных, да. Но представь, сколько лет нужно учить людей писать на haskell? ;-)
                                              +4
                                              Меньше, чем на плюсах. Там хотя бы всё логично, а понять проще, чем запомнить.

                                              Какой из этих вариантов скомпилируется для какого T? В каком из стандартов?
                                              template<typename T>
                                              T mkT1() { return {}; }
                                              
                                              template<typename T>
                                              T mkT2() { return T {}; }
                                              


                                              Скомпилируется ли этот код? Правильно ли это?
                                              struct Foo
                                              {
                                                  Foo() = delete;
                                              };
                                              Foo fuckYouCpp {};
                                              


                                              Скомпилируется ли этот код?
                                              auto [foo, bar] = GetSomethingDecomposable();
                                              auto lambda = [&foo] {};
                                              
                                                0
                                                Какая жесть! :-)
                                                  0
                                                  А в чем проблема в первом примере? Кроме того, что return {} не может вызывать explicit конструкторы
                                                    0

                                                    Подставьте вместо T, скажем, std::mutex и включите, скажем, стандарт C++14. Дело там совсем не в expliict-конструкторах.

                                                      0
                                                      gcc8 для обеих функций жалуется на удаленный конструктор. Должен быть какой-то другой результат?
                                                        0
                                                          0
                                                          Да, так не жалуется. Я проверял на таком коде wandbox.org/permlink/opifRXDEydaAqd2i
                                                            0
                                                            О, вы сами вышли на следующий вопрос. Как изменить строку с mkT1, чтобы оно собиралось, работало и не было UB?
                                                              0
                                                              А это возможно в c++14? В 17, насколько я понимаю, будет работать за счет обязательного copy elision
                                                                0
                                                                Возможно. auto&& t1 = mkt1<std::mutex>();. Temporary bound reference, lifetime extension, все дела.
                                                  0
                                                  Это такой способ написать GADT? Ну там как бы этим все не ограничивается.
                                                    +1

                                                    Но ведь в хаскеле номинальная типизация, это не OCaml и не Elm.

                                                        0

                                                        Там ошибка, а приведённый сниппет в хаскеле невозможен. Ну вот же простой пример:


                                                        data Foo = Foo Int
                                                        data Bar = Bar Int

                                                        Foo и Bar несовместимы, хотя имеют одинаковую структуру.

                                                          0
                                                          Между строк нужно читать, суть
                                                            0
                                                            en.wikipedia.org/wiki/Structural_type_system
                                                            A distinction exists between structural substitution for inferred and non-inferred polymorphism. Some languages, such as Haskell, do not substitute structurally in the case where an expected type is declared (i.e., not inferred), e.g., only substitute for functions that are signature-based polymorphic via type inference.[1] Then it is not possible to accidentally subtype a non-inferred type, although it may still be possible to provide an explicit conversion to a non-inferred type, which is invoked implicitly.
                                                              0

                                                              Не нужно техническую документацию "между строк" читать, это вам не худлит. По ссылке из вашей же цитаты:


                                                              Signature-based polymorphism? Yes.
                                                              Structural subtyping? No.

                                                              И вообще, если вы так настаиваете на структурной типизации в хаскеле, просто покажите соответствующий определению пример.

                                                    +10
                                                    >Может Rust, с правильными идеями относительно безопасной работы с памятью, повлияет на ситуацию в лучшую сторону, но по уродству синтаксиса и нечитаемости он, похоже, оставил C++ далеко позади.

                                                    О, макаронный монстр! Раст и плюсы не похожи синтаксисом на мой любимый динамически типизированный язык программирования со сборщиком мусора! В утиль не думая и не разбираясь!
                                                      –7
                                                      Ну посмотри на его синтаксис, кошмарный же, в глазах режет.
                                                        +8
                                                        C++/C Режет глаза больше.
                                                          –4
                                                          Согласен
                                                            +2
                                                            Отступы в Python режут глаза! Макросы перерезают горловину, а точки с запятыми бьют в печень. И нет в мире совершенства.
                                                              0
                                                              Да не :-) Проблема многословности и нечитаемости языков лишь. Почему питон читается и помещается на экран, а java — гораздо хуже.
                                                                0
                                                                Если у тебя хороший отдел тестирования, а не «кликеры без понимания смысла» — то в принципе можно не волноваться. А вот если команда небольшая, а цена ошибки очень высока — то понимать код становится все сложнее
                                                              +2
                                                              Ну посмотри на ручку этого молотка! Фу, как можно работать с этим чёрным обрезиненным ребристым покрытием? Мне нужна обязательно глянцевая красная ручка в блёстках! Иначе кошмарно! В глазах режет!
                                                                –3
                                                                Ну погоди, я серьезно. Зачем скобочки и точка с запятой нужны? В питоне и хаскеле их давно нет :-)
                                                                  +5
                                                                  Серьёзно??? Точка с запятой для вас «кошмарно» и «глаза вытекают»? На этом в принципе можно было и заканчивать, но так и быть, вот достаточно старая статья, но которая неплохо разжёвывает зачем в Расте точка с запятой:

                                                                  lucumr.pocoo.org/2012/10/18/such-a-little-thing
                                                                    0
                                                                    Нет, это было только начало :-) В генериках java аналогичный кошмар с угловыми скобочками и стрелочками творится — это я так, просто под вечер, не воспринимайте близко к сердцу :-) Просто сравните с питоном.
                                                                      +3
                                                                      Я как вижу x for x in x, сразу всё.

                                                                      Знакомые питонисты говорят, у них правило выработалось: видишь @ — готовься к лапше.
                                                                        –1
                                                                        А йелды? Ну блин можно же без них все в ООП сделать через итераторы — нет, придумали их, чтобы было еще покороче.
                                                                          +1
                                                                          А на деле-то достаточно ленивых списков.
                                                                            +1
                                                                            Итераторы придумали, например, что бы не складывать в память из базы 100500 значений в массив, а обработать и взять следующие данные, при этом минимально кода используется (особенно когда сперва напортачили с пачками и надо рефакторить что бы память всю не съедало, при этом не сломать всё при рефакторинге).
                                                                              –1
                                                                              Да, они прекрасны
                                                                          +4
                                                                          Ещё раз, см. комментарий про ручку молотка…

                                                                          В Расте по определению нужно сообщать языку больше информации о программе по сравнению с языками имеющими утиную типизацию и сборщик мусора. Жаловаться на синтаксис не потратив хотя бы недельки на изучение языка, а просто поглядев листинги это где-то на уровне «Пастернака не читал, но осуждаю». Плюс стоит понимать, что если не брать совсем патологические случае, то к синтаксису работая на языке очень быстро привыкаешь, так что использовать подобную вкусовщину для оценки языка, мягко говоря странно.
                                                                            0
                                                                            Скала выглядит опрятней же, разве нет? Хотя сборщик мусора конечно большое подспорье, соглашусь. Проблема в том, что избыточный синтаксис нужен компилятору, но затрудняет понимание кода — что случилось в java и вот что с этим делать…
                                                                              +3
                                                                              Да и хороший код на том же Питоне выглядит опрятней разумеется, но это инструменты совершенно разного уровня и областей применения. И сравнивать «чистоту» их синтаксиса не очень корректно.

                                                                              Я, как можно догадаться, весьма плотно работаю с Растом, и могу заверить, что лично у меня никаких сложностей с пониманием основной части кода не возникает, как и у множества других людей, которые хоть немного поработали на данном языке.
                                                                                0
                                                                                Я через 2 года тоже haskell стал понимать, а кто-то и perl понимает до первого отпуска.
                                                                                  0
                                                                                  По отзывам, что бы свыкнуться с синтаксисом и borrow checker'ом (последнее вносит наибольший вклад), у людей уходит от 1 до 3 месяцев. Тем не менее, достаточно большое количество людей изучивших Раст приходит из высокоуровневых языков вроде Питона, что говорить в пользу того, что для многих синтаксис не так уж и страшен. Возможно в вашем случае сказываются травматический опыт c Джавой, который и проецируется на Раст.
                                                                                    0
                                                                                    Может быть, не спорю. Поставил в планчик себе Rust покопать поглубже. Может все и правда не так плохо с избыточностью и многословностью, как выглядит со стороны. Буду рад, если так.
                                                                                      +2
                                                                                      Рекомендую начать с книги, после прочтения попробовать написать небольшое консольное приложение или библиотеку. В случае вопросов, непоняток или предложений, можно писать на реддит или форум. Сообщество весьма дружелюбное и активно помогает новичкам.
                                                                          +1
                                                                          Сейчас бы сравнивать питон с языками программирования.
                                                                  +5

                                                                  Синтаксис-то ещё ладно, а вот с неопределённым поведением в C++ — туши свет.

                                                                    –7
                                                                    Я все понять не могу. Вот придумали java, где с синтаксисом попроще и стандарт проще. Пиши на здоровье! И чего написали толкового кроме minecraft и lucene и eclipse?
                                                                      +2
                                                                      Куча тырпрайза на джаве пишется, например.
                                                                        –1
                                                                        Это да. Я тоже в основном на java пишу миссиан-критикал код — надежно, ясно, и работает годами потом и спишь спокойно.
                                                                          +4
                                                                          У меня, увы, в среднем такие мишн-критикал-штуки, что на джаве их писать не получится из соображений производительности.

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

                                                                          А в резюме у меня вообще всего два языка упомянуто.
                                                                            0
                                                                            Искренне завидую Вам. Хочу лет 20 писать на C что-то для юникса системное и полезное — времени не хватает.
                                                                              +2
                                                                              Не стоит. Последнее время меня начинает немножко задалбывать состояние экосистемы и, как бы это помягче сказать, среднее качество кода на языке.
                                                                                –1
                                                                                Может Golang вытащит системную разработку таки? Хотя он настолько имхо примитивен и пока еще смущает скорость сборки мусора и может его перестанут развивать.
                                                                                  +5
                                                                                  Тогда уж таки Rust. Go решает несколько другую задачу (откуда и растёт упомянутая вами примитивность).
                                                                                    –1
                                                                                    Rust кажется таким же вендорским проектом, как и Golang. Вот пропадет у Mozilla интерес и что тогда… Хотя более достойных кандидатов, похоже, нет на горизонте.
                                                                                      +1
                                                                                      А как насчет D?
                                                                                        +1
                                                                                        У mozilla пропадет интерес только если они бросят firefox, что выглядит пока что малореалистичным. А к тому моменту язык уже должен быть более менее самостоятельным.
                                                                          +1

                                                                          s/eclipse/IDEA/

                                                                            –3
                                                                            Пытался несколько раз на IDEA с Eclipse перейти — чувству отторжение, видимо недорос еще.
                                                                              +2

                                                                              Удивлен, первый раз слышу такое мнение об Eclipse. Что ж, на вкус на цвет, как говорится...

                                                                            +3
                                                                            Слишком толсто.
                                                                              –1
                                                                              Я серьезно. Spring — философское кладбище. Camel — сами знаете. Сервера приложений — LAMP работает не хуже. Я пытаюсь найти, java мой любимый ЯП. В чем причина, понять не могу.
                                                                                +1
                                                                                Apache Cassandra? JPC? MATLAB частично.
                                                                                  +1
                                                                                  Да, и еще думаю почти весь стек Amazon Web Services тоже на java. Но их текущее SDK4java с дырявыми объектами полубилдерами удручает. Хотя в sdk2, хотя оно сырое и пререлиз — гораздо лучше: аналог реактивных потоков, хорошие билдеры, все стройненько. Я в прод даже потащил.
                                                                            +4
                                                                            Полностью согласен! Основная претензия к автору в том, что он даже не пытается вдаваться в технические подробности, ограничиваясь вкусовщиной (причём весьма похоже услышанной из третьих уст) для обоснования своего Важного Мнения.
                                                                              0
                                                                              Я целый день в течении многих лет в технических деталях с утра и до поздней ночи — давайте хоть тут про них не писать :-)
                                                                                +2
                                                                                Может для вас Хабр это хиханьки и хаханьки, но, на мой взгляд, для большинства читателей он интересен в первую очередь качественными техническими постами, к которым вашу статью нельзя отнести даже с натяжкой.

                                                                                И завязывайте с засильем смайликов, а то возникает ощущение, что переписка ведётся с условной блондинкой в чатике.
                                                                                  –1
                                                                                  Понимаете в чем проблема. Погружаясь в технические детали, можно потерять суть, что часто и происходит. Пост про то, как за деревьями лес увидеть.
                                                                                    +2
                                                                                    Как ваша вкусовщина и мимопроходил-мимоглядел подход может каким-то образом помочь в нахождении сути? Вы сейчас пишите с позиции дилетанта в данном вопросе, пытающимся весьма с ограниченным опытом в данной области делать выводы космического масштаба, ну и далее по цитате.

                                                                                    P.S.: Да, этот комментарий практически ad hominem, но по сути дела тут обсуждать, к сожалению, нечего.
                                                                                      0
                                                                                      Почему дилетанта?
                                                                                        +1
                                                                                        Написал недостаточно ясно, подразумевалось дилетанта в Расте (что очевидно по вашим сообщениям), а не в программировании вообще.
                                                                                          –1
                                                                                          Я не пишу на rust и не скрываю и не вникал глубоко в детали реализации. Много пишу на java. Оцениваю снаружи по ясности листинга, который «очень» на что-то похож.
                                                                                            0
                                                                                            Java такой же многословный.
                                                                          +3
                                                                          Вы скажите что в 2019 учить, надо в будущее смотреть а не в настоящем топтаться.
                                                                            –3
                                                                            А Вы уверены, что будущее наступит? :-)
                                                                              +3
                                                                              А если оно не наступит то чего в 2018 что то учить? ;)
                                                                                +2

                                                                                Шить сарафаны и легкие платья из ситца.
                                                                                — Вы полагаете, всё это будет носиться?
                                                                                — Я полагаю, что всё это следует шить!
                                                                                ...
                                                                                  +1

                                                                                  вас — тупит

                                                                                –4
                                                                                Спасибо, на удивление хороший пост про выбор языка :)
                                                                                  +2

                                                                                  А чего Swift и Objective-C не добавили? Те, кто с самого начала сидел на экосистеме Apple, вполне себе стабильно в шоколаде чувствуют — в отличии от тех же перловодов, например.

                                                                                    –2
                                                                                    Забыл :-)
                                                                                      +1

                                                                                      А чего их учить-то особо? Пересесть на них с C++ (особенно если его используешь в рамках "C с классами") — плёвое дело, а инфраструктура (фреймворки и т.п.) довольно-таки понятна, неплохо спроектирована (после win api, mfc и иже с ними — отдыхаешь душой) и прилично описана (хотя в этом вопросе у меня и к MS претензий нет), так что переход на неё, если уже привык к reference counting (например, использовал COM с его IUnknown или std::shared_ptr) не напряжёт вообще.

                                                                                        +1

                                                                                        Я к тому, что можно со Swift и начать, тем более что у него ещё и playgrounds.

                                                                                    0
                                                                                    > Но в Java забыли о вреде null-значений, а в C# — не до конца продумали обратную совместимость.

                                                                                    Так гoвoрите, будтo бы в C# не забыли o вреде null-значений.
                                                                                    (хoтя уже стараются этo исправить)

                                                                                    > O да, чуть не забыл, про способ зарыть себя, проект, клиента и окружающий мир в код и утонуть в нем, вспоминая в агонии 20 уровневую иерархию наследования — про ООП.

                                                                                    20-урoвневая иерархия наследoвания — этo прoблема архитектуры, а не парадигмы прoграммирoвания. Недарoм существует принцип prefer composition over inheritance.

                                                                                    > Не нужно думать, что статическая типизация, особенно строгая, это прямо «must have» — вы провалите сроки и код с удовлетворенной параноидальной мыслью о «возможных ошибках» будет выброшен на помойку.

                                                                                    А между тем в нoвый Python дoбавили аннoтации типoв, IT-гиганты разрабoтали Typescript и Flow и даже PHP не oтстаёт. Дoвoльнo спoрный тезис!
                                                                                      0
                                                                                      Вот не согласен по поводу композиции и наследования. Трейты и AOP же не от хорошей жизни придумали — не все ложиться только в композицию и наследование, есть еще странные проникновения тем друг в друга. В ФП так вообще отказались от этих идей практически и работает же.
                                                                                        +3
                                                                                        Можно ещё начать задавать вопросы о том, является квадрат прямоугольником или же прямоугольник — квадрат, должна ли функция printShape(const Rectangle&) уметь принимать квадрат (да, почему б и нет?) и должна ли функция multiplyWidthByTwo(Rectangle&) уметь принимать квадрат (вопрос читателю).

                                                                                        Ой, ковариантность и контравариантность. Ой, матан попёр без всякого ФП и профункторов. ФП, кстати, даёт любопытный и, если подумать, естественный ответ.
                                                                                          –1
                                                                                          да да да
                                                                                            0
                                                                                            После haskell задумываешься, а не ошибкой ли стало появление императивного программирования в принципе?
                                                                                              +2

                                                                                              Железо с аппаратными бета-редукциями и эта-преобразованиями пока никто не придумал, а при трансляции на существующие архитектуры возникают забавные проблемы вроде отжирания огромных объемов памяти под thunk'и.

                                                                                                0

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


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

                                                                                          0
                                                                                          Так аннотации типов в python приведут его к… java. Философия питона — утиная типизация: не ограничивать типы, не тратить на это время, принимать все на вход и чекать уже внутри.
                                                                                            +1
                                                                                            В "The Zen of Python" про утиную типизацию ничего нет. Похоже, это еще одна область, в которой Вы не являетесь экспертом.
                                                                                              –2
                                                                                              Правильно, а вы сами давно перечитывали эту поэзию? :-) Зато тут написано: en.wikipedia.org/wiki/Duck_typing. А все потому, что питон язык — любительский, для скриптиков.
                                                                                                +2
                                                                                                Ну так это статья про утиную типизацию, потому там про нее и написано. А Python приведен просто как общеизвестный пример. И еще, Python — это язык для быстрого изготовления прототипов реальных продуктов (почему его и используют всякие ресерчеры в Data Science и ML). «Любительский, для скриптиков» — это Ваше очередное личное безосновательное мнение.
                                                                                                  0
                                                                                                  Я очень люблю python и много на нем пишу, как и на php — они похожи, хотя первый с гораздо более строгой типизацией.
                                                                                          +2
                                                                                          Вы бы написали, что статья опубликована лишь для того, что бы холиваров разжечь. А то вдруг какой-то новичек ее всерьез воспримет.
                                                                                            –2
                                                                                            Какой холивар, зачем? Наоборот дать обзор, максимально объективный, насколько получится. И пусть уже выбирает.
                                                                                              +3
                                                                                              Ну, не сказать что бы у Вас очень получилось. Объективный обзор должен включать в себя сравнение технических особенностей, а не хайпа и воплей хейтеров.
                                                                                                –1
                                                                                                Ну так каждый может самостоятельно сравнить, при желании. Да и времени на это нужно море.
                                                                                                  +4
                                                                                                  Действительно, зачем тратить время на создание годного контента, если можно сделать холиварный вбросик. Тем более что технические детали ведь любой сравнить может, а похайповать — только избранные.
                                                                                                    0
                                                                                                    Жаль, посыл был совсем другой.
                                                                                            0
                                                                                            Scala? ;-)
                                                                                              0
                                                                                              Я так тоже думал, что Scala, пока не прочитал книжку Одерски несколько раз и не увидел особых преимуществ :-)
                                                                                                0
                                                                                                Преимущества, конечно, вещь сугубо индивидуальная… Смотря для чего… Просто, в статье столько всего намешано, как и в Scala :-)
                                                                                                0
                                                                                                Frege. Жаль, пост не в пятницу.
                                                                                                  0
                                                                                                  IronHaskell в мире JVM. «Learning Frege essentially means that you will also learn Haskell...» — тогда уж лучше сразу Haskell учить. А применять… У Haskell под капотом движок, заточенный на производительность именно для программирования в функциональном стиле. Здесь же… работать оно будет, но как?
                                                                                                    0

                                                                                                    Ну, вдруг вам жизненно необходимо быть в JVM-экосистеме, а хаскель хочется.

                                                                                                +1

                                                                                                Ну я думаю что можно еще вспомнить Котлин.
                                                                                                Хорошее продолжение Java, и если все будет хорошо то его ждет разумный успех.

                                                                                                  0
                                                                                                  Полностью согласен.
                                                                                                  +1
                                                                                                  Мне кажется, ТС зарылся в своем любимом ЯП и не хочет познавать другие ЯП т.к. вызывает отторжение.

                                                                                                  Имхо — язык это всего лишь инструмент, к которому надо знать подход.
                                                                                                  Понял более-менее один язык — поймешь и другие. От языка уже зависит, сколько времени на его изучение придётся потратить.
                                                                                                    0
                                                                                                    Этот подход хорошо заметен в питоне, в частности. Если ты будешь пытаться до сути вникать в каждую библиотеку, например в тонкости pandas, то потратишь месяцы. И рекомендуют быстро понять идею, выучить 2-5 сценариев и при необходимости просто гуглить. Аналогично в машинном обучении — схватил и погнали. В вебе тоже аналогично — понял php, принципы верстки и вперед.
                                                                                                    +1

                                                                                                    Не холивара ради, но про Java ходит множество слухов, которые порождаются от незнания или уходят корнями в древние версии (например что Java медленная, что она жрет тонны памяти и все в таком духе). То же самое можно сказать и про "кровавый-энтерпрайз-простой-веб-вервер-за-5-дней". В текущих реалиях даже самый распространенный Spring Boot позволяет сделать веб сервер за ~10 строк кода, а ведь есть и более минималистичные фреймворки


                                                                                                    Что до типизации — я лично считаю, что динамическая типизация замечательно подходит для создания прототипов или небольших проектов в духе "сделал и забыл". Если предполагается продолжительная разработка (а главное поддержка) в команде разработчиков, то лучше выбрать статическую типизацию

                                                                                                      0
                                                                                                      Я искренне фанат java, до чертиков и вдоль и поперек ее перелюбил в разных проектах, но для веба много лет использую только php — так кажется быстрее. Да, есть еще утверждение, что динамические языки позволяют много быстро написать и это сложнее в поддержке потом и наоборот — на статически типизированных пишешь медленнее, зато в поддержке проще. Но это касается все больших проектов. А никто в начале не знает какой у тебя проект.
                                                                                                        +1
                                                                                                        А от чего сложилось впечатление, что статически типизированные языки требуют больше времени на разработку? Для Вас программирование эквивалентно набору бессмысленного текста? Просто лично у меня большая часть времени уходит на мыслительный процесс.
                                                                                                          –1
                                                                                                          А на каких статически типизированных языках Вы обычно проводите свой мыслительный процесс?
                                                                                                            +1
                                                                                                            Мыслительный процесс провожу в голове, а из языков больше всего использую C++. Да и какая вообще разница? Думать ведь всегда надо, и не только в программировании.
                                                                                                              0
                                                                                                              Согласен, что нужно думать. Статическая типизация кажется очень важной, и я так тоже много лет считал, но… Нужно описать типы, описать функции/методы принимающие типы, возможно абстрактные классы — т.е. принять решение и ограничить этим себя. А можно, в утиной типизации, принять все, что пришло, и дернуть метод у этого нечто. Зачем лишние ограничения? Идем дальше — статическая типизация подразумевает компиляцию. Но всегда ли это нужно если мы делаем прототип и меняем код 10 раз в минуту?
                                                                                                                0
                                                                                                                меняем код 10 раз в минуту

                                                                                                                Что нужно такого делать с кодом, чтобы иметь ощутимый результат каждые 6 секунд?
                                                                                                                  +1
                                                                                                                  Идем дальше — статическая типизация подразумевает компиляцию.

                                                                                                                  Статическая типизация подразумевает тайпчекер, не более.


                                                                                                                  Меняю содержимое модуля, жму Ctrl+A Ctrl+A для переключения в соседний экран screen, жму :r<Enter>, чтобы перезагрузить модуль в REPL, и менее чем через секунду получаю результат.


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


                                                                                                                  Даже переключаться в REPL не надо, ты просто пишешь код, а он там просто в фоне проверяется.

                                                                                                                    +2
                                                                                                                    А можно, в утиной типизации, принять все, что пришло, и дернуть метод у этого нечто.
                                                                                                                    Ай как замечательно, только вот веселье начинается когда на вход передается объект такого типа, который на вход не ожидали. Хорошо еще, если соответствующего метода у данного типа нет — тогда просто получим ошибку (ну, или не получим), а что, если соответствующий метод вытирает диск или взрывает атомные бомбы? Так что строгая типизация — это не про ограничения, это про дисциплину и быстрое вылавливание элементарных, но неприятных ошибок.
                                                                                                                    статическая типизация подразумевает компиляцию
                                                                                                                    Нет, с чего это вдруг? Чем статическая типизация мешает использовать язык в режиме интерпретации?
                                                                                                                      0
                                                                                                                      Описывать типы нужно и при динамической типизации в том же PHP. Не везде, не всегда, но это может быть требованием к коду.
                                                                                                                        0
                                                                                                                        Ну это же костыль, согласитесь. В питоне тоже аннотации недавно придумали. Компилятор/интерпретатор в этом не поможет, будет хаос. Т.е. никто не понимает что лучше и внедряют идеи методом копирования друг у друга не думая
                                                                                                                          0
                                                                                                                          Разница в том когда будет ошибка — при компиляции или при исполнении.
                                                                                                                            0
                                                                                                                            Еще разница в том, что если жестко задать типы — нужно будет заглянуть в будущее и заведомо усложнить все. А иногда принимать решение заранее — неправильно. Утиная типизация как раз в этом помогает.
                                                                                                                              +2
                                                                                                                              Как по мне, то ровно наоборот: описывая только те типы, которые сейчас нужны, мы не заглядываем в будущем с предположениями о том, что будет ожидать кто-то кто вызовет функцию sum(a, b) с текстовыми параметрами или объектами класса Rectangle.
                                                                                                                                0
                                                                                                                                Вот задумайся на секунду — почему живет до сих пор питон с огромным количеством сложных библиотек? Там же нет строгой типизации, как оно ваще может быть и еще активно развиваться?
                                                                                                                                  0
                                                                                                                                  В Питоне как раз строгая типизация. Попробуйте в нём сложить число со строкой.
                                                                                                                                    0
                                                                                                                                    Строгая динамическая. Да, строгая и к числу строку не добавишь. Я про «динамическую». Это означает, что проверки типов нет вообще и что в сигнаруре метода ты не укажешь интерфейс и он дернет все, что пришло, в рантайме — и ему пофиг, объект А это или объект Б. Да, они начали сбоку прикручивать метатэги типов и в php тоже начали — но это не тренд.
                                                                                                                                  +1
                                                                                                                                  Почему? Наоборот. Я пишу функцию
                                                                                                                                  sumTwo :: Monoid a => a -> a -> a
                                                                                                                                  

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

                                                                                                                                  Более того, в случае прямоугольников вы сможете иметь несколько разных вариантов сложения для них (ну там, ширину, или начальную точку, я не знаю), и они все будут внешними что для непосредственного определения Rectangle, что для определения функции. Это ли не чудеса расширяемости и взглядов в будущее?
                                                                                                                                    0
                                                                                                                                    Полиморфизм в хаскеле просто поражает.
                                                                                                                                      0
                                                                                                                                      А где тут типы?
                                                                                                                                        0

                                                                                                                                        a — это тип. Monoid a => a -> a -> a — это тоже тип.

                                                                                                                                          0
                                                                                                                                          Не знаю хаскеля, но как функция сложения это не выглядит, выглядит как обобщенный интерфейс sumTwo без реализации.
                                                                                                                                            0
                                                                                                                                            Ну, так как моноид — это и есть сложение, то реализация была бы тривиальной. Давайте функцию интереснее, сложить первое с удвоенным вторым:
                                                                                                                                            sumTwice :: Monoid a => a -> a -> a
                                                                                                                                            sumTwice a b = a <> b <> b
                                                                                                                                            
                                                                                                                                              0
                                                                                                                                              Прочитал в вики про мононид — там говорится об умножении. В целом не понимаю эту запись, не могу понять где имя типа, а где имя аргумента. Специально используете одинаковые имена в разных «неймспейсах»?

                                                                                                                                              В общем мне кажется дискусия зашла куда-то не туда. Я имел в виду, что если я пишу функцию для сложения двух целых чисел(псевдокод): `sum = (int a, int b): int => a + b` то я ни в какое будущее не заглядываю, а если пишу `sum = (int a, any b): int => typeOf(b) === 'int'? a + b: typeOf(b) === 'string'? a + (int)b: typeOf(b) === 'object'? a + (int)b.toString(): undefined;` когда мне только числа надо складывать, то делаю лишнюю работу никому не нужную на данный момент, при этом пытаюсь заглянуть в будущее и угадать что ожидают пользователи передавшие строку или объект в мою функцию для сложния чисел.
                                                                                                                                                0
                                                                                                                                                Да, я согласен с тобой, если убрать про моноид, то получаем в хаскеле обобщенную функцию. Лучше пока не нырять в детали: моноиды и монады, там пипец. Достаточно на первое время понять алгебраические типы, паттерн-матчинг, caseclasses и базовые методы работы со списками и вводом-выводом.
                                                                                                                                                  +1
                                                                                                                                                  «Делаешь пандорический захват, лифтишь в монаду, потом строишь рекурсивную схему (здесь подойдёт зигохистоморфный препроморфизм) как монадический трансформер из категории эндофункторов, и метациклически вычисляешь результат. Любой второкурсник справится. А если делать на анафорических лямбдах — так задачка вообще на пять минут.» (С)
                                                                                                                                                    +1
                                                                                                                                                    Точно, спасибо за подсказку… что-то до меня сразу и не дошло))
                                                                                                                                                      –1
                                                                                                                                                      :-) Слушай, но пишут же хороший надежный софт и без монад. Даже во вводе-выводе можно не разбираться, использовать IO monad как есть. Хаскель в первую очередь исследовательский язык, там заглядывают в будущее
                                                                                                                                                        +1
                                                                                                                                                        Слушай, но пишут же хороший надежный софт и без монад.


                                                                                                                                                        Да разве я спорю? Вот тот же Erlang взять.
                                                                                                                                                      0
                                                                                                                                                      Не получаем, потому что в хаскеле, в отличие от какого-нибудь С++, тайпчекинг происходит до мономорфизации, а не после.

                                                                                                                                                      Единственная тотальная функция с типом a -> a — функция, возвращающая свой аргумент (если у вас в языке выполняется parametricity, конечно, а в хаскеле оно выполняется). Единственные две тотальных функции с типом a -> a -> a — возвращающие первый или второй аргумент соответственно. Вы не можете написать других тотальных функций с такой сигнатурой.
                                                                                                                                                      +1

                                                                                                                                                      Сложение от умножения ничем не отличается, если у вас в алгебре всего одна операция. Просто единичку на нолик меняете, и всё, да и это скорее из соображений общепринятой нотации.


                                                                                                                                                      В первой строке говорится, что sumTwice — это функция, принимающая два объекта типа a и возвращающая объект типа a, если объект a реализует тайпкласс (считайте, интерфейс на стероидах) Monoid. В принципе, эту строку можно даже опустить, компилятор в данном случае выведет точно такой же тип.


                                                                                                                                                      Во второй строке можете переименовать a и b как угодно, с a из первой строки оно не связано никак.


                                                                                                                                                      В итоге одни сплошные профиты:


                                                                                                                                                      1. Есть тайпчекинг. Вы можете выполнить только те операции, которые предоставляются моноидом. Например, написать функцию, возвращающую строковое представление суммы, вы не сможете:
                                                                                                                                                        sumTwice :: Monoid a => a -> a -> String
                                                                                                                                                        sumTwice s1 s2 = show (s1 <> s2 <> s2)

                                                                                                                                                        Так нельзя, компилятор ругнётся, что он не умеет показывать тип a. Надо добавить констрейнт:

                                                                                                                                                        sumTwice :: (Show a, Monoid a) => a -> a -> String
                                                                                                                                                        sumTwice s1 s2 = show (s1 <> s2 <> s2)

                                                                                                                                                        Теперь функция работает с любым типом a, который реализует тайпклассы Show и Monoid.


                                                                                                                                                        Смотреть в будущее всё равно не нужно. Эта функция работает с любым типом, для которого определены эти тайпклассы. Всё, опять же, предельно расширяемо.
                                                                                                                                                        0

                                                                                                                                                        То есть, если переводить это на абстрактный ООП-язык, то для сложения двух числе мы пишем что-то вроде:


                                                                                                                                                        interface Addable<T> {
                                                                                                                                                          add(T a): T
                                                                                                                                                        }
                                                                                                                                                        
                                                                                                                                                        Addable<Int> {
                                                                                                                                                          add(Int b): Int => this + b
                                                                                                                                                        }
                                                                                                                                                        
                                                                                                                                                        sumTwice = (Addable<T> a, Addable<T> b) : T => a.add(b).add(b)

                                                                                                                                                        ?

                                                                                                                                                          0

                                                                                                                                                          Типа того. Если ООП-язык позволяет создавать новые интерфейсы и указывать их реализации для уже имеющихся типов, и проверяет код в момент тайпчекинга функции, а не тайпчекинга мест её вызова (т. е. не как в плюсах). Собственно, в Idris, в отличие от хаскеля, тайпклассы и называются интерфейсами.


                                                                                                                                                          При этом тайпклассы могут связывать несколько типов. Скажем, в том же Idris в стандартной библиотеке есть тайпкласс Cast a b, говорящий, что тип a можно преобразовать в тип b, и у него есть функция cast типа a -> b. И есть инстанс (реализация) Cast Int String — число вы можете преобразовать в строку. Или Cast Int Double.


                                                                                                                                                          Или другой классический пример — тайпкласс для монад, представляющих некое хранилище, куда можно добавлять новые данные (например, лог выполнения процедуры). Объявляется как


                                                                                                                                                          class (Monoid w, Monad m) => MonadWriter w m | m -> w where
                                                                                                                                                              ...

                                                                                                                                                          что означает, что тайпкласс имеет два параметра: тип монады m и тип записей w, которое она содержит. При этом штука слева от => говорит, что m должно реализовывать тайпкласс монады, а w — быть моноидом (где моноид определяет, как комбинировать несколько записей, скажем, естественная моноидальная структура на списках — это просто их конкатенация). Кроме того, если подумать, тип монады однозначно определяет тип записей, которые она несёт, и эту информацию неплохо дать тайпчекеру, чтобы он выводить иначе неоднозначные типы, да и лишний раз проверить, что вы не написали ерунды, и ровно это и указывает | m -> w.


                                                                                                                                                          И тогда оказывается, например, что «частично применённый» тип пары (w, ) с незафиксированным вторым аргументом, где w — моноид, реализует MonadWriter. Действительно, для любого типа Monoid w пара (w, ) реализует тайпкласс монады (а монада — это да, тайпкласс), а дописывание тривиально: вы просто берёте новый элемент, который надо дописать, берёте имеющуюся у вас пару и объединяете этот элемент с её первым значением, используя моноидальную структуру.


                                                                                                                                                          При этом когда вы писали пару, вы ничего не знали ни о каких моноидах и MonadWriter. Равно как и все остальные участвующие типы.

                                                                                                                                    0

                                                                                                                                    Завтипы или хотя бы GADT там есть?

                                                                                                                                      0
                                                                                                                                      Нету
                                                                                                                          0
                                                                                                                          Проблема когда нужно сделать не модную поделку, а расширить что-нибудь энтерпрайзное, где версия 16го года (а новее у заказчика нет, хорошо ещё хоть на эту перешли) использует жабу 1.7 со всеми её «особенностями». А ещё (к теме какой язык учить) там могуть быть модули на всё подряд — от Python и js до C и asm разных архитектур и задача «принести то, чаво не может быть». Вот это действительно весело, а не сайтики на php.
                                                                                                                            0
                                                                                                                            А в сайтиках тоже не всегда все просто
                                                                                                                              +1
                                                                                                                              на самом деле согласен, иначе не было бы хайлоада и потребности в сеньорах очень высокой квалификации, на всё хватало бы студента, засунувшего на ночь книжку про PHP под подушку. Но там и простыни кода встречаеются не чаще, чем во всяких энтерпрайзах. И это даже если не считать за сайты веб-приложения руления чем-нибудь производственным.
                                                                                                                                0
                                                                                                                                Я часто переключаюсь между js, php, java и python, постоянно сравниваю и поэтому пост и написал — каждый ЯП хорош в своей нише, не нужно микроскопом гвозди забивать, как иногда пытаются.
                                                                                                                                  0
                                                                                                                                  Увы, но часто от разработчика не зависит на каком языке писать. Ну, инициировать введение нового языка в инфраструктуру он может, но очень сильно надо стараться доказать начальству что оно того стоит, прежде всего в плане затрат на разворачивание и поддержку решения.
                                                                                                                                    0
                                                                                                                                    Согласен полностью. И это большая проблема, да.
                                                                                                                          +2
                                                                                                                          После забавной критики языков, очень надеялся увидеть в конце статьи выход языка 1С в белом, сыграть на контрасте так сказать…
                                                                                                                            –3
                                                                                                                            Не уж, режем правду-матку до конца :-)