Когда появится следующий большой язык программирования с точки зрения Дарвина

    Good news everyone!
    Futurama


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

    Эволюция работает не только в животном мире, но и в любой подходящей среде. Впервые эта идея получила широкое распространение с выходом книги Ричарда Докинза «Эгоистичный ген» в 1976 году. В ней был введен знакомый каждому термин «мем», как пример эволюции в социальной и культурной среде. Языки программирования тоже эволюционируют. А значит их развитие подчиняется принципам эволюции, на основании которых можно сделать предположение о будущем их развитии.

    image

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

    image

    Можно было бы возразить, что создание нового языка программирования — это исключительно заслуга творца. Джеймс Гослинг создал Java, Гвидо Ван Россум — Python, а Керниган и Ричи — C. Однако, на практике они лишь реализуют механизм изменчивости собирая из “генов” языков программирования что-то новое. Никто не в состоянии сам заставить весь мир разрабатывать, например, на ABAP, что, впрочем, не умаляет заслуг авторов.

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

    Вымирание и гены


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

    Все знают, что предками языков C (1972) и Pascal (1970) были B (1969) и Algol (1958-68), которые смело можно считать вымершими. Утверждать что язык B забыли, потому что он “старый” — неправильно. Lisp (1958) старше, а его диалекты в ходу до сих пор, как и само название языка. Да и C, несмотря на то что уже не молод, будет с упорством отстаиваться как лучший язык программирования миллионами разработчиков по всему миру.

    Посмотрим на пример кода на B из оригинального руководства по языку. Согласитесь, он не так уж и далек от современного C:

    main() {
       extrn putchar, n, v;
       auto i, c, col, a;
    
       i = col = 0;
       while(i<n)
          v[i++] = 1;
       while(col<2*n) {
          a = n+1 ;
          c = i = 0;
          while (i<n) {
             c =+ v[i] *10;
             v[i++]  = c%a;
             c =/ a--;
          }
    
          putchar(c+'0');
          if(!(++col%5))
             putchar(col%50?' ': '*n');
       }
       putchar('*n*n');
    }
    
    v[2000];
    n 2000;

    Есть причина, по которой B и подобные ему языки забыты, — это “ген” структур данных. Единственное что отличает C и Pascal от своих предшественников — наличие конструкций “struct” и “record”. Почему это, казалось бы, небольшое изменение обеспечило живучесть C и Pascal на десятилетия, а их предшественники лишь вскользь упоминаются в университетских курсах? Просто изменилась среда.

    Проект «Манхэттен» показал, что возможностей электромеханических табуляторов недостаточно для проведения физических расчетов: необходимых для разработки атомного оружия. О том, как проводились такие вычисления рассказывается в одной из глав книги «Вы, конечно, шутите, мистер Фейнман!». Конечно, именно Пентагон стал заказчиком нового инструмента для проведения вычислений — компьютера, первый из которых увидел свет в 1946 году (ENIAC).

    Что нужно для проведения физических расчетов — скаляры, векторы, матрицы и нехитрая программа. Долгое время такого инструментария было достаточно для решения всех насущных задач. Именно это и было реализовано в языке Fortran (1957), и даже в редакции 1977 структуры данных в нем не появились. По тем же принципам строились и другие языки того времени.

    Появлению C мы обязаны возникновением нового класса задач — системного программирования. Необходимость создавать операционные системы, в разработке которых требуются “не математические” структуры данных, привела к тому, что язык закрепился и здравствует. Оказалось, что иметь возможность оперировать произвольными структурами — это очень удобно и позволяет решать любые классы задач, в то время, как языки B или Algol показали свою ограниченность и были забыты. Пожалуй только Fortran сохранил свою актуальность по сей день, и то в 1990 году структуры данных в него все таки добавили.

    Конвергентная эволюция


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

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

    Аналогичную ситуацию можно проследить между Windows 1.0 (1985) и node.js (2009). В случае Windows 1.0 решалась задача обеспечения одновременной асинхронной работы одного пользователя со многими приложениями, в node.js — многих пользователей с одним приложением использующим асинхронные операции ввода-вывода. Поскольку обе системы основываются на однопоточной модели исполнения, в них были придуманы одинаковые решения — цикл обработки очереди сообщений. Не удивительно что и та, и другая реализации склонны “зависать” и требовать “ребута”. В node.js концепция watchdog вообще считается нормой и самой собой разумеющейся.

    При этом решение той же проблемы на основе вытесняющей многозадачности, лишенное детских проблем “зависаний” всей системы, было реализовано как в операционных системах UNIX (1969) так и в программировании — Erlang (1986). Причины, по которым авторы node.js решили изобрести свой велосипед, возможно были теми же, по которым C появился после Pascal — несовместимость американской и европейской школ программирования.

    К слову, в том же 2009 году появился язык программирования Go, которые решает проблему массовой многозадачности гораздо более надежным способом — ”go routines”. Фактически, в нем реализован тот же принцип легковесной многозадачности, что и в Erlang.

    Слепая эволюция


    Эволюция слепа, и процесс эволюционного развития не предполагает построения “идеальной архитектуры” или проведения “полного рефакторинга”. Человеческий глаз имеет слепое пятно, из-за чего мозг вынужден достраивать недостающие части картинки, и это не обусловлено каким-то разумными ограничениями. Все можно было сделать гораздо лучше, если бы эволюция “пересмотрела” архитектуру глаза. Однако, эволюция так не работает — она никогда не перерабатывает имеющиеся решения с нуля, но лишь улучшает то, что есть. Подробнее о процессе эволюции зрения рассказано, например, в книге «Что, как и почему мы видим на самом деле».

    Так же и язык C. С момента своего появления он изменяется и расширяется, но никогда не перерабатывается полностью. Сейчас мы имеем дело с монстром C/C++. Он содержит все врожденные проблемы управления памятью, неприлично обширный синтаксис, огромное количество библиотек и процесс компиляции, требующий отдельной вычислительной фермы. При этом он полон сил, активно развивается и вообще пышет здоровьем.

    Другой пример — Java. Начиная с первой версии, в язык были включены примитивы многопоточного программирования. Конструкция “synchronized”, поддержка блокировок на уровне любого объекта и, простите, “Hashtable”. И вот это представили как решение проблем многопоточного программирования, объявили что Java — “concurrent” и выпустили в свет. Сейчас очевидно, что разработку многопоточного кода нужно основывать на принципах “stateless” и “immutability”, что для “concurrency” нужные специализированные структуры данных — “ConcurrentHashMap”, а блокировки стоит использовать только в крайних или специфичных ситуациях. Увы, фарш невозможно провернуть назад. “Hashtable” останется в Java навсегда, а необходимость рассказывать каждому новому разработчику, почему нужно использовать “StringBuilder”, а не “StringBuffer” — это крест, который несет все Java-сообщество.

    В примере с Java важно, что такие “атавизмы” на самом деле никак не влияют на “живучесть” языка программирования. Все перечисленные проблемы были устранены в .Net изначально, и кому какое до этого дело.

    Принцип острова


    Новые виды наиболее активно появляются в новой изолированной среде. Такой средой может быть как остров в буквальном смысле, — Ява и ее малый оленёк или Мадагаскар с лемурами, так и озеро — например, Байкал и его прозрачная голомянка. Континент Австралия с населяющими его сумчатыми также является островом в эволюционном смысле.

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

    Рассмотрим островное происхождение языка Java. То, что Java стал мейнстримным языком программирования, — по большому счету, случайность. Для этого не было никаких разумных предпосылок. Разработка Java началась в 1991 году (тогда язык назывался Oak). По легенде, основной платформой для исполнения Java-приложений должны были стать кофемолки. В целом это неудивительно, поскольку Java разрабатывалась в недрах Sun Microsystems — “железной” компании, так что разработка языка для встраиваемых систем там была вполне логичной. Но в 1993 году появился первый браузер Mosaic, и это все изменило.

    Появилась совершенно новая, никем не занятая и не освоенная среда, полностью свободная от багажа предыдущего опыта и технологий. Никто не знал что и как в ней делать. И вот в 1995 году технологию Java представили миру. Правда, по нынешним стандартам, технология была так себе. Ирония состоит в том, что Java изначально позиционировалась как клиентский язык программирования, отсюда Applet — технология встраивания в браузеры, окончательно уничтоженный только в 2015, и обреченный с рождения браузер HotJava. Java стал одним из основных языков серверного программирования скорее вопреки задумке авторов. Справедливости ради, на то были разумные основания. В 1990-х, выбирая, на чем разрабатывать серверную логику — на C++ или Perl, любая альтернатива этим двум казалась бы лучшим выбором. А как серверная технология Java оказалась настолько хороша, что уже в 2002 году ее скопировал Microsoft.

    Тем временем, в том же 1995 году появился JavaScript. Пользуясь полнейшим провалом Java на стороне клиента, он стал доминирующей технологией разработки клиентских приложения для веба.

    Справедливости ради следует добавить что тогда же, в 1995 году появился PHP и занял экологическую нишу быстрой разработки. Вообще, эра веба крайне благоприятно сказалась на развитии языков на букву “P”.

    Острова не только для языков программирования


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

    Хорошим шансом для появления нового массового языка программирования стало появление смартфонов. Но не случилось. Apple по инерции использовала в iPhone (2007) Objective-C (1984), а Google — Java в Android (2008). Становление нового рынка было слишком горячим фронтом противостояния, чтобы отвлекаться на эксперименты (см. «Как поссорились Apple и Google»). Да, конечно есть Swift, но о нем вспомним чуть позже.

    Другой островок появился где-то в районе 2009 года, когда все начали добавлять в веб-приложения поддержку WebSocket для обновления данных на странице в реальном времени. Так появились Node.js и Go, и вновь показался на радарах Erlang. Но несмотря на технологическое превосходство Go над Node.js и привычную семантику по сравнению с вычурным Erlang, Go не стал лидером, как, впрочем, и никто из его “коллег”. Островок оказался слишком маленьким и на базу для дальнейшей экспансии не потянул. А совсем недавно там добавился еще один обитатель-конкурент — Elixir (2012), адекватный синтаксис и исполнение в среде Erlang.

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

    Остров машинного обучения в основном населяют C++ и Python, немного Java, иногда Lua (1993) и конечно R (1993). В целом машинное обучение — больше про алгоритмы и специфичные способы обработки данных.

    Генная инженерия языков программирования


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

    Apple выпустила Swift на замену Objective-C в 2014. Похоже что дела в этом направлении идут неплохо, но нет причин ждать чего то большего.

    В JetBrains устроили локальную революцию с Kotlin в 2011, решив переписать на него IDEA а заодно избавить весь мир от NullPointerException. Пока не помогло.

    Google громко анонсировал Dart как “убийцу JavaScript” в том же 2011. Криминала, впрочем, не случилось, как и нативной поддержки Dart в браузерах. В целом Dart и TypeScript (2012) неплохо живут и компилируются в JavaScript, но свергнуть короля веба они оказались не в состоянии, хотя и существенно потеснили его в рамках разработки крупных проектов.

    Mozilla решила переписать Firefox на Rust (2010). Распространение системы типов на многопоточность — это интересно, да и все остальное в Rust выглядит основательно. Есть одна загвоздка — на Go худо-бедно уже можно найти живые приложения, а вот от Rust выхлопа пока нет.

    Мажорное обновление Python 3, ломающее обратную совместимость, сформировалось в 2006 и называется Python 3000. Первый релиз вышел в 2008. Судя по тому что Python 2 бодр, весел, и все еще с нами, изначальные оценки по внедрению третьей версии к 3000 году были недалеки от истины.

    Если с Python дела обстоят более-менее серьезно, то инициативу Perl 6 уже можно рассматривать как анекдот. Начав разработки в 2000, с целью заменить Perl 5 (1994), Perl 6, похоже, все-таки зарелизили в 2015.

    Следующего большого языка программирования не предвидится


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

    Отсутствие новостей — хорошие новости. Если вы планируете начать изучать JavaScript, Java, C#, Python или PHP, это стоит сделать. Мейнстримные языки с нами всерьез и надолго, и их знание всегда пригодится. При этом, новые языки вроде Rust или Go тоже имеют перспективу, возможно, не как замена всего и вся, но как инструмент для решения интересных задач.

    Дмитрий Мамонов

    Департамент разработки,
    Подразделение мержа в мастер,
    Отдел работы с гит,
    Оператор баш консоли с “пробегом”
    Метки:
    Wrike 98,00
    Wrike делает совместную работу над проектами проще
    Поделиться публикацией
    Комментарии 221
    • +10
      Новых естественных островов, на которых мог бы закрепиться свежий лидер, похоже не планируется

      Почему? На данный момент, новых перспективных "островов" много: интернет вещей, виртуальная реальность, дополненная реальность, слабый специализированный ИИ (автономные машины, боты-секретари и т.п.). Другое дело сколько дадут нам новые языки.


      Вообще, на мой взгляд через лет 10-15 должны появится языки в комбинации со слабым ИИ, где основное шаблонное кодирование будет делать ИИ, а программист будет исправлять ошибки и задавать условия на почти естественном языке, "аля сделай мне Rest сервис со следующими параметрами". Полностью автономный сильный ИИ появится не скоро, а вот ИИ для парного программирования с человеком — вполне уже возможен при текущих технологиях. Собственно современные IDE к этому все более идут. ИМХО, конечно.

      • +3
        — Вот это больше не делай!
        — Что вот это?
        — Вот это, когда вот это и это!

        — А куда делись мои деньги\моя работа\etc?
        — Но ты же сказал вот это не делать >_<

        Мечтать не вредно, но правильное обучение ИИ приблизительно равно обучению человека. Быстрее, но не дешевле.
        • +4
          Мечтать не вредно, но правильное обучение ИИ приблизительно равно обучению человека. Быстрее, но не дешевле.

          Естественно, но я говорил о шаблонных вещах, вроде верстки обычных страниц, реализации типовых вебсервисов (вот честно, сделать типой сайт с Rest, web. беком, который тупо делает CRUD сущностей с проверкой прав пользователей). Естественно, программиста они не заменять, но позволят ускорить его работу в разы, как современные IDE ускоряют работу программистов по сравнению с 80-ми.


          Да потребуется долгое обучение ИИ, но один раз для миллионов клиентов, а потом их можно штамповать и продавать, как приложение к IDE. Сейчас статические анализаторы, IDE, анализаторы покрытия тестами и т.п. достаточно умны, чтобы поправлять программиста, если тот делает явные и не очень явные ошибки. Даже могут в теории делать рефакторинг почти в автоматическом режиме. Я не вижу никаких особых преград, чтобы связка "умная IDE + программист" не превратилась в связку "IDE со слабым ИИ + программист". Но, конечно, программиста ИИ в ближайшие десятилетия полностью не заменит, если не появится полноценный сильный ИИ (к тому же экономически более выгодный, чем человек, что тоже важно).

          • +1
            мимо.
            • +1
              вот честно, сделать типой сайт с Rest, web. беком, который тупо делает CRUD сущностей с проверкой прав пользователей

              Так это и так делается на автомате. Не скажу за все платформы, но на .NET это есть, а если вам не REST, а просто достаточно сайта с CRUD, он вам еще и стандартные формы нагенерит. Все что останется сделать это — сделать модельки данных и расставить аттрибуты валидации.
              Уверен то же и для Rails есть и для Node.js (sails.js очень близко к этому).
              • +3

                Это scaffolding называется, собственно в Rails 1.x он и появился (в Rails 1.2 его с REST подружили), а потом уже все остальные скопировали.

                • 0
                  Справедливости ради, визардов в своей Визуал-Студии для скафолдинга шаблона проекта Микрософт придумал задолго до хипстеров из веба (и наверняка эта идея ещё раньше была реализована в промышленных системах разработки других производителей).
                  • 0
                    Еще в '99 на Delphi можно было практически без написания кода накидать на форму контролов и получть вполне себе сносный CRUD.
                    • 0
                      MFC с визардами появился у Микррсофта раньше таки лет на 5 — 10. Конкурентом от Борланда тогда была не VCL, а OWL.
                      • 0

                        Можно скриншотик компонента для сносного CRUD? Почему-то я не помню в Delphi 6 ничего подобного…

                        • 0
                          Скриншотика нет, но помню был там TSQLClientDataSet.
                          Но могу конечно и ошибаться, у меня все что с Delphi 3 как в тумане, и только про D7 еще что-то помню.
                          • 0

                            Ну, это не то… DataSet, насколько я помню, предполагал редактирование и создание записей прямо в табличном представлении, даже без визарда.

                      • 0

                        Так причём тут визарды в VisualStudio? Или они позволяли REST-сервисы создавать ещё до появления такого понятия как REST? xD

                        • 0
                          Принципиальным в вопросе был именно REST? Нет, тогда архитектурный подход веба и HTTP-протокол ещё не успели объединить этим баззвордом, придуманным чуть позже, но у Микррсофта был CRUD поверх HTTP в том числе (RPC, SOAP), помимо бинарных COM/DCOM.
                          • 0
                            Да это же как раз история последних 20 лет в разработке. Мы постоянно переизобретаем языки и фреймворки, причем они не решают ни одной новой задачи. А переизобретаем по одной простой причине — «Not invented here».
                            • –1
                              Самый толковый комментарий.
                            • 0

                              В данной ветке да. Обсуждались конкретно типовые веб-сервисы, которые делают CRUD на базе REST. И "визарды" для них MS скопировала уже с Rails в рамках ASP.NET MVC.

                              • 0
                                Да не нужно было ей ничего копировать, достаточно было добавить в визарде вариант «HATEOAS/REST/ODATA» к имевшимся «WSDL/SOAP», прикладной программист даже разницы может не заметить, переключая эти варианты. Не защищаю Микрософт, не дискредитирую Рэйлз, а всего лишь уличаю вас в синдроме утёнка. Конструктива в этом не так много, потому, пожалуй, на этом завершу свою компульсию.

                                (А WebComponents, если присмотреться, оказывается развитием концепции ActiveX, и именно Микрософтовцы продвигали компонентную философию в промышленность, и они сейчас входят в W3C.)
                                • 0

                                  Хм, я программировал на C# до Ruby… И довольно странно спорить о том, что ASP.NET MVC — это калька с Rails. Имхо, это очевидный факт для любого, кто видел классический ASP.NET. Естественно, MS не переписывала ради этого Visual Studio и использовала свои наработки в плане интерфейсов. Но концептуально всё скопировали и это хорошо, потому что до этого ASP.NET был ужасен (это я постарался наиболее мягкий эпитет подобрать).

                                  • –3
                                    А почему, по-вашему, именно с Рэилз, а не с Джанго? Или почему не со Смалтолка, например? (Очевидно, потому, что вы как утёнок знаете только о Рэйлз.)
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                    • 0

                                      Потому что тогда был взлёт Rails и все с него копировали, не только MS.
                                      Становление ASP.NET MVC я наблюдал ещё с момента бета-версий 1.0.
                                      Если бы Вы были знакомы с Django и Seaside, то знали бы, что там есть весьма принципиальные отличия от Rails. В ASP.NET MVC 1.0 единственным "принципиальным" отличием было то, что они не успели весь функционал с Rails скопировать.
                                      P.S. Пока по вашим коментам складывается ощущение, что Вы лично знаете про утёнка, но ни один из вышеназванных фреймворков в глаза не видели.

                                      • –3
                                        Тогда же взлетала Джанго (и даже чуть раньше).
                                        P.S.: Моё впечатление о вас аналогичное, не смущайтесь сильно.
                  • +1
                    Дешевле, по скольку плохо обученные экземпляры утилизируются практически бесплатно.
                    • +2
                      «правильное обучение ИИ приблизительно равно обучению человека. Быстрее, но не дешевле.» есть инфа о стоимости обучения ИИ?
                      • 0
                        Можно прикинуть. Для обучения ИИ нужны размеченные данные. Не знаю насколько точно можно оценить необходимое количество данных для еще не решенной задачи, может быть что и нельзя, но можно взять уже известные примеры и посмотреть на количество данных которыми обучали их. После оценки количества можно посчитать стоимость получения самих данных (тоже не всегда просто) и стоимость разметки оценив час работы специалиста и его производительность. Оценка будет грубая, но сделать можно.
                        Теоретически, чем больше слабых ИИ решающих определенную задачу, тем дешевле каждый новый — данные уже есть. Но нужно учесть что, во-первых, данные могут устаревать (для каких то задач, леопард будет и через десять лет также выглядеть скорее всего), во-вторых, данные могут быть закрытыми, в-третьих, каждый новый ИИ в уже освоенной области приносит все меньше и меньше пользы, либо требует все больше и больше данных для получения хоть какого-то преимущества.
                      • 0
                        Да пусть даже и дороже(если не порядки, конечно). ИИ можно неограниченно тиражировать, а это очень многое меняет.
                      • +2
                        аля сделай мне Rest сервис со следующими параметрами

                        Вот вам пример: Есть корзина с товарами.
                        Задача: получить размер скидки.
                        Расчет скидки:
                        1) Каждый 5 товар бесплатно.
                        2) В полнолуние в високосный год на «группу товаров А» условие #1 не действует.
                        3) По средам, если идет дождь скидка 10% на «группу товаров А», кроме Петербурга. Для Петербурга действует условие #1, но не действует условие #2.

                        А вот другая задача. Допустим у нас простой CRUD и десятки миллионов пользователей.

                        Я все это к тому, что результат работы программиста это не «код», а «решение задачи». Написание кода — рутина.
                        • 0
                          Приведенная вами задача уже лет 15 решается несколькими строчками на Prolog.
                          • +6

                            Запустили 15 лет назад и все ещё ждем распечатку этой задачи? :)))

                            • +3
                              «Программа разрабатывает способ этого достичь, но синтаксис языка не позволяет объяснить этот способ вам.»
                          • 0
                            Это понятно. Но я не про количество строк кода.
                            Если обобщить то, первая задача — это бизнес логика, вторая — архитектура.
                            И суть в том, что Prolog (или любой другой язык) не поможет вам создать алгоритм решения задачи, также как и не поможет вам спроектировать хорошую архитектуру.
                            Все упирается в то, что «Войну и мир» пишет не язык, а человек.
                            • 0
                              Подразумеваемые вами языки — императивные-алгоритмические. В них программист сочиняет и излагает в коде алгоритмы решения. Однако задача, которую вы привели выше, как невозможно сложную для написания императивного алгоритма, тем не менее очень легко решается прологом; программисту придется лишь изложить для программы правила задачи, «декларировать» их. Пролог решит задачу сам, без какого-либо переданного ему алгоритма. Приведенная вами задача — типичная задача для пролога на уровне букваря, пятой главы учебника. На хабре приличное число статей об этом ЯП.
                              • 0
                                Я ничего не подразумеваю. Задача не сложная, а стандартная.

                                Однако задача, которую вы привели выше, как невозможно сложную для написания императивного алгоритма, тем не менее очень легко решается прологом; программисту придется лишь изложить для программы правила задачи, «декларировать» их.

                                Декларировать кто будет, Пролог?
                                Ну как вам Пролог архитектуру системы спроектирует? (это вторая задача)
                                • +1
                                  Пролог решит задачу сам, без какого-либо переданного ему алгоритма.
                                  Не надо только рассказывать сказки про Пролог, а? Пролог — это всего-навсего DFS с хитрым синтаксисом. Не более того.

                                  И не нужно нам тут рассказывать про то, что всё на свете можно свести к DFS с отрезаниями, пожалуйста: да, это правда — но ровно в том же смысле в каком любой алгоритм можно свести к программе на Malbolge с лентой. Да, это правда, но… зачем?
                        • +3
                          Есть ниша логических языков — прогресс в них медленный, но с ростом мощности компьютеров и объема оперативной памяти можно ожидать его ускорения.
                          К тому же нельзя исключать катастроф, вроде появления на порядок превосходящего традиционные компьютера с троичной системой счисления или появление доступных квантовых вычислений.
                          • +1
                            С чего бы это троичный компьютер будет «на порядок превосходящий»?

                            А в квантовые вычисления я как-то не верю. Квантовый компьютер может одновременно решать много задач — но вот на выходе будет суперпозиция из всех этих решений. А разделение результата будет занимать много времени.
                            • +1
                              В квантовый компьютер не нужно верить. Уже есть задачи, которые он решает лучше обычного, известны требования к таким задачам. Он не заменит стандартного, но дополнит его, как дополняют видеокарты например. Сейчас уже не стоит вопрос что можно с ним делать, сейчас стоит вопрос только как сделать достаточно дешевый и стабильный квантовый компьютер.
                              • +1
                                С чего бы и нет? Откроют новый физический принцип, позволяющий сделать очень эффективную тристабильную ячейку, а бистабильную только игнорированием одного из состояний. Или ты знаешь почему это принципиально невозможно?

                                Ну все, надо сообщить в IBM и Google, что бы работы сворачивали.
                                • 0
                                  Ну хорошо, тристабильная ячейка — ничего принципиально сложного я не вижу, чисто инженерная задача. Но как это может повысить скорость вычислений и/или ёмкость памяти сильнее, чем в полтора раза?

                                  Что-то мне кажется, в IBM и Google кто-то пилит бюджет по грантам…
                            • 0
                              А я ставлю на то, что Nim (nim-lang.org) все же выстрелить, возможно еще в этом году. Гибкая система типов, мултипарадигма, приятный а-ля Python синтаксис и скорость выполнения как в C — это совсем как появление млекопитающих в мире динозавров: стильно, интересно и молодежно :)

                              Но почему ни слова о Haskell?
                              • +6
                                Но почему ни слова о Haskell?

                                На данный момент в мире есть примерно 7 (семь!!!) коммерческих вакансий на Хаскеле: https://wiki.haskell.org/Jobs

                                • +7

                                  На самом деле больше, не все вакансии публикуются на Haskell Wiki, большая часть закрывается через twitter, reddit, тематические сайты и чаты.

                                  • +5
                                    Поищите вакансии математиков-теоретиков, их в сети будет не больше :) Но это не значит, что они не нужны и неконкурентноспособны.
                                    • 0

                                      Предположим на секунду, что это так. И что?

                                      • –1
                                        Тогда, по определению из статьи:
                                        вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент

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


                                          Глупости. Я практически каждый день пишу на Haskell, можно пойти пособирать статистику коммитов по github-у какому-нибудь, из чего будет явно очевидно что на нём таки ежедневно пишет куча людей. Или сходите для разнообразия на #haskell на freenode, который обычно не замолкает более чем на несколько минут (ну ещё на ряд haskell-ориентированных более узко специализированных каналов вроде #haskell-lens, #haskell-beginners, #haskell-game, #haskell-infrastructure, etc). Один приятель ведёт стримы, где пишет на Haskell: и т.д. и т.п. Мне известна компания в городе, где я раньше жил, которая использует Haskell для критически важных частей своей системы. В настоящий момент на нём-таки разрабатывают, и не полтора анонимуса.
                                          • 0
                                            Я и не утверждаю что это именно так. Но «я каждый день пишу» не попадает под данное определение живого языка. Компания с критической частью написанной на хаскеле — уже да, попадает. Вопрос в том, сколько всего таких компаний и как это оценить. Самый простой способ оценки, хоть и естественно крайне ненадежный — по количеству открытых вакансий, этот способ используется часто. Честно говоря навскидку сказать как еще можно объективно оценить количество разработчиков на хаскеле я не знаю. Опрос мог бы сработать, но это надо очень заморочиться. Можно оценивать по коммитам в гитхабе, но, во-первых, здесь есть свои недостатки — так можно оценить только опенсурс, а, во-вторых, таким образом мы не оценим большую часть разработки для продакшена — там до сих пор далеко не все пишут код в открытую. А именно код для реальных продуктов и является критерием живости языка по определению автора статьи.
                                            Поэтому, хотя ваш опыт безусловно имеет некоторую ценность, нельзя сказать что это объективный показатель. Собственно как и мой, как и чей либо еще. Это только слабое свидетельство в пользу, но никак не доказательство.
                                            Каналы на фриноде тоже не могут таким доказательством считаться — они точно также никак не отображают количества людей разрабатывающих на хаскеле профессионально.
                                            Тут ключевое — это то, как автор определил живость языка. У вас, как мне кажется, несколько другое понимание этого термина и в таком понимании хаскель безусловно жив.
                                            • 0
                                              Я и не утверждаю что это именно так. Но «я каждый день пишу» не попадает под данное определение живого языка. Компания с критической частью написанной на хаскеле — уже да, попадает.

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

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

                                              А личные критерии «о живости/мёртвости» языка программирования, — это такая разношёрстная и отнюдь не единогласная солянка, что я бы не стал придавать отдельным частностям какое-либо значение, если только критерии чётко и стройно не сформулированы. Я вот например вообще не связываю понятие «живости» языка с деятельностью коммерческих компаний, что видимо входит в прямое противоречие с вашим видением, но это моё личное и сюда я не вплетал.

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

                                              В том всё и дело, что я зацепился за авторское определение:
                                              Используя аналогию с устной речью, вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент. Даже если компиляторы этих языков существуют, программы на них написанные можно запустить, а некоторые “историки программирования” все еще могут написать на них новый код.

                                              Понимая его буквально, без каких-то особых личных «додумок» за кулисами, не добавляя ничего своего. В рамках этого определения Haskell бесспорно — жив.
                                              • +1
                                                Да, вы правы, это я неправильно прочитал авторское определение. Претензий нет, в данном варианте все мои размышления не имеют смысла.
                                              • 0
                                                Вот чисто ради эксперимента, как по-вашему, жив ли сейчас ЯП Cobol?
                                              • 0
                                                Честно говоря навскидку сказать как еще можно объективно оценить количество разработчиков на хаскеле я не знаю.

                                                Есть же рейтинги популярности ЯП. Например, по данным Redmonk он занимает 16-е место (между Go и Swift). Да, он только по данным Github и StackOverflow, но это даёт представление о размере сообщества.


                                                Самый простой способ оценки, хоть и естественно крайне ненадежный — по количеству открытых вакансий

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

                                                • 0
                                                  В целом я неправильно понял авторское определение, так что вы правы конечно. Но если считать живыми языки на которых разрабатывают коммерческие продукты, то гитхаб уже не может являться адекватной метрикой. СО впрочем будет относительно актуален и в этом случае, да.
                                                  Насчет открытых вакансий. В общем случае вы тут тоже правы, но можно учесть большую текучку кадров и частую смену работы программистами — сейчас это очень распространенное явление. А раз это явление распространено, то, при миллионе работающих программистов вакансий будет тоже много просто из-за текучки. С другой стороны я не могу утверждать, что это верно для любого языка. В среде людей пишущих на коболе или фортране, например, текучка может быть (и скорее всего есть) гораздо меньше.
                                      • +2

                                        Скорость выполнения — как в C, и при этом — со сборщиком мусора? Любопытно...

                                        • 0
                                          Я даже так скажу, можно писать на C, при этом писать на Haskell.

                                          А вообще нужно иметь в виду что раскладывать и оптимизировать чисто-функциональный код на порядок проще, чем завязаный на последовательность действий и постоянные мутации состояния, эдакое педалирование регистров ручным приводом, не говоря уже о том, что чисто-функциональный код пустить в плеяду тредов ничего не стоит, чего отнюдь нельзя сказать об C например. Haskell помимо всего прочего по-настоящему «ленив», он не станет маппать весь список из 9000 элементов, если в итоге из него понадобилось только 3, замаппится только 3 элемента из 9000. Суммируя все особенности, можно зачастую получать больший перформанс, чем эквивалентная по смыслу реализация на С, но есть различные нюансы, которые нужно понимать и иметь в виду. Но основная соль-то даже не в этом, вот взять систему типов, тайпклассы, настоящий лаконичный полиморфизм, не перегруженный необходимостью писать полотна мета-манускриптов, чтобы сделать код действительно абстрактным, как это происходит с случае с C++ каким-нибудь, C даже рядом поставить не получится.
                                          • 0

                                            А можно ли наоборот — писать на Haskell, при этом писать на C (или чём-то таком же низкоуровневом)? В принципе сущности всё те же — функции, константы, массивы и структуры, всё вроде как должно поддерживаться.

                                      • +3
                                        Честно говоря, не сказал бы, что у Python такой уж и приятный синтаксис.
                                        • 0

                                          Тогда есть Crystal с приятным синтаксисом в стиле Ruby. Он и постабильнее, чем Nim, будет… сравните кол-во открытых issues на Github. По быстродействию в среднем где-то между C и Go.

                                          • +3

                                            Не сказал бы, что и у Ruby приятный синтаксис (4 года работы с).


                                            UPD: у Elixir приятный синтаксис, да и DSL легче отлаживать (за счёт гигиеничных макросов).

                                            • НЛО прилетело и опубликовало эту надпись здесь
                                          • 0
                                            Не холивара ради, можно парочку примеров? Интересно узнать мнение.
                                        • +6

                                          Есть старая, но почему-то плохо заполненная ниша языка описания аппаратуры. Есть Verilog и VHDL, несущие дух своей эпохи 80-х. Новое пока зарождается только в виде экспериментальных языков, которым пока не удается пробиться в промышленность.

                                          • 0

                                            Почему-то на картинке у o'reilly ISWIM и ML не имеют ничего общего, хотя читая статью (http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf) у меня было ощущение, что таки ML прямое развитие.


                                            И communicating sequential processes и actorы это фактически две разные модели.

                                            • +4
                                              И еще об эволюции. Есть такое учение «трансгуманизм», которое утверждает, что эволюция человека продолжается, только уже не методом отбора, а разработкой кибернетических имплантантов, генной и тканевой инженерии и тп.
                                              Так и в языках программирования пора уходить от естественного отбора в сторону «разумного дизайна».
                                              • 0
                                                что и происходит исходя из статьи, только в статье говорится о том что в целом это не сильно работает. Но путь в тысячи ли начинается с шага. И конечно привет H+
                                                • 0

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

                                                  • 0
                                                    Сам Хокинг предложил создать мировое провительство. Надеюсь, в его компетенцию войдет разработка языков программирования. :-)
                                                    • +2
                                                      Я надеюсь что не войдет. Страшно представить каким будет язык, разработанный в правительстве. Да еще и в условиях монополии правительства…
                                                      • 0
                                                        Если понаблюдать за «правительством», то можно предположить, что это будет в лучшем случае PHP. Но сдаётся мне что с задачей вообще не справятся, тут ведь нужен какой-никакой интеллект, а не букетик условных рефлексов.
                                                  • +1

                                                    <xkcd-14-конкурирующих стандартов.jpg>

                                                  • +6
                                                    >Следующего большого языка программирования не предвидится. По крайней мере, на то нет причин с точки зрения теории эволюции.
                                                    Совершенно неверный вывод из верных посылок.

                                                    Эволюция идёт во многом балгодаря изменичивости окружающей среды, а в нашей отрасли она крайне изменчивая.

                                                    Есть увеличение сроков изменений, но оно обусловлено взрослением индустрии и ни в коем случае не свидетельствует о конце времён.
                                                    • +2
                                                      +1. Например, языки программирования для квантовых компьютеров.
                                                      • +3

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

                                                        • 0
                                                          А почему не как FPGA например? Их тоже можно подключать к обычному компьютеру, но пишут для них на специфичных языках.
                                                          • +3
                                                            Для видеокарт есть языки шейдеров, которые несмотря на сходство с С все-таки имеют несколько самобытных особенностей. С квантовыми «приставками» будет аналогичная история — несколько языков для квантового программирования уже написано.
                                                      • –2
                                                        Следующий язык будет включать прямую работу с нейросетевыми структурами и многопоточность в смысле работы таких структур. Так же как С включал структуры как наборы «однопоточных» данных.
                                                        • +1

                                                          Хорошая статья, мне понравилось.


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

                                                          • +1
                                                            Распространение кроликов (в австралии) стало самым быстрым распространением млекопитающего вида в известной истории.


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

                                                            Однако большинство новых видов появилось в обычных условиях

                                                            Да, и сейчас мы наблюдаем расцвет языков программирования. Их много, много новых, и многие из новых хороши.
                                                            С разнообразием, как раз, все в порядке.
                                                            Просто никто из новичков не станет лидером.
                                                            • 0

                                                              Так может при разнообразии уже нельзя быть лидером? То есть, с — популярен. Но сколько процентов он занимает? Растут ли эти проценты или падают?

                                                          • 0
                                                            Значит новый язык возникнет тогда, когда нормально научатся писать в мозг или читать.
                                                            • +3

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

                                                              • +3
                                                                Мне кажется что в ближайшие лет 10-15 квантовые компьютеры будут все еще большой редкостью и языки для их программирования будут распространены на уровне нынешних эзотерических. В таком ключе посыл статьи вполне адекватен — в ближайшем будущем нового языка не предвидится. Это не значит что их не будет, это значит что они будут очень сырыми и на них почти никто не будет писать. Более того, весьма вероятно что, когда квантовые компьютеры таки войдут в повседневную жизнь, эти языки уже будут вполне себе мертвыми а жить будет нечто построенное на их костях.
                                                                • 0
                                                                  • 0

                                                                    В статье не увидел

                                                                  • +5
                                                                    Хорошее замечание, но!

                                                                    Даже если квантовые вычисления случатся — они будут крайне ограниченными.
                                                                    Для них будут использовать специальные микропрограммы, как для шейдеров в графике,
                                                                    которые будут встраивать в программы на обычных языках программирования.
                                                                  • +5
                                                                    Какое-то очень смелое заявление, как-будто все человеку известно наперед.Очень сомневаюсь, что вообще грамотно, делать подобные заявления…

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

                                                                    Я бы представил программирование завтрашнего дня в терминах распределенных вычислений…
                                                                    • +1
                                                                      Не обязательны низкоуровневые нейросетевые структуры. Скорее речь может пойти о гетерархических онтологиях, когда над ними появятся внятные формальные операции вывода.

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

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

                                                                      И в этом смысле, конечно же, есть предпосылки для множества новых языков. Огромного множества.

                                                                      Просто пока об этом рассуждают люди не понимающие глубины «трендообразования», они не способны такие гены разглядеть.

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

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

                                                                      Казалось бы, все идет по пути синтаксического сахара и новых онтологий, но если посмотреть на платформенный ландшафт, то очевидно, что идет только заполнение лакун. Так и работает естественный отбор. Как только некая фича оказывается достаточно значимой для организма или системы, она начинает трансформировать генотип или мемотип.
                                                                      • +4
                                                                        К слову, в том же 2009 году появился язык программирования Go, которые решает проблему массовой многозадачности гораздо более надежным способом — ”go routines”. Фактически, в нем реализован тот же принцип легковесной многозадачности, что и в Erlang.

                                                                        Go уже научился прерывать работу зацикленной горутины, считать редукции?
                                                                        • –4
                                                                          простите, но зачем ему это? Вы должны сами следить за этим.
                                                                          • +6
                                                                            Для вытесняющей многозадачности. В данном случае легковесной. Чтобы всем легковесным процессам гарантированно выделять процессорное время. Если процесс по какой-либо причине «зависнет», то Go приложение потеряет один из своих thread'ов выполнения? Приложение Go научилось как-то контролировать зависшие корутины и как-то решать этот вопрос?

                                                                            Я именно спрашиваю, а не утверждаю. Потому что, очевидно, Golang развивается. И может быть там эти решения появляются. И я бы хотел об этом узнать, если так.

                                                                            Моя критика тут в том, что утверждение в выделенной мной цитате, ИМХО не соответствует действительности. Ни первое, ни второе:
                                                                            К слову, в том же 2009 году появился язык программирования Go, которые решает проблему массовой многозадачности гораздо более надежным способом — ”go routines”.

                                                                            Более надежным способом, чем где? Чем в windows 1? Принцип тот же: процесс завис — система зависла. В Go приложении корутина зависла — приложение зависло. Спасает только то, что Go приложение берет gomaxprocs по умолчанию больше, чем 1. Если выставите 1, то приложение зависнет на горутине. Никаких средств переключения на другую корутину нет. Никаких средств прибить зависшую корутину нет. А проблема массовой многозадачности — ну да, решается. Только переключения между горутинами происходит в момент вызова функций внешних библиотек.

                                                                            Фактически, в нем реализован тот же принцип легковесной многозадачности, что и в Erlang.

                                                                            Даже рядом нет. Потому что у ерланга виртуальная машина интерпретирует код, поэтому может легко в любой момент переключаться между процессами. В го нет никакого интерпретатора или виртуальной машины.
                                                                            • –3
                                                                              В Go приложении корутина зависла — приложение зависло. Спасает только то, что Go приложение берет gomaxprocs по умолчанию больше, чем 1. Если выставите 1, то приложение зависнет на горутине.

                                                                              In prior releases, a goroutine that was looping forever could starve out other goroutines on the same thread, a serious problem when GOMAXPROCS provided only one user thread. In Go 1.2, this is partially addressed: The scheduler is invoked occasionally upon entry to a function. This means that any loop that includes a (non-inlined) function call can be pre-empted, allowing other goroutines to run on the same thread.

                                                                              Вполне себе завершается
                                                                              package main
                                                                              
                                                                              import (
                                                                              	"fmt"
                                                                              	"runtime"
                                                                              	"time"
                                                                              )
                                                                              
                                                                              func main() {
                                                                              	runtime.GOMAXPROCS(1)
                                                                              
                                                                              	go func() {
                                                                              		for {
                                                                              			fmt.Println("Endless loop...")
                                                                              		}
                                                                              	}()
                                                                              
                                                                              	time.Sleep(300 * time.Millisecond)
                                                                              	fmt.Println("Exiting main program..")
                                                                              }
                                                                              
                                                                              

                                                                              • +3
                                                                                А если в цикле без вызова fmt? Например, какой-нибудь i=i+10, а Print уже за пределами цикла?
                                                                                Ну то есть, как будто бы в цикле какой-то сложный расчет, который залип.
                                                                                Внешний вызов — он да, как раз позволит прервать эту корутину. Я об этом и писал.
                                                                                Может какой-то есть аналог yield или Application.ProcessMessages?
                                                                                • +1
                                                                                  • +2

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

                                                                                    • 0
                                                                                      Да.
                                                                                      Кстати, а когда может понадобиться ограничивать приложение одним потоком, ну разве кроме редких случаев жесткой оптимизации?
                                                                        • +12
                                                                          Рождение нового вида в экосистеме — это событие класса «чёрный лебедь», событие фазового перехода в хаотической (квазистабильной открытой динамической) системе. Невозможность предсказать «лебедя» вы же сами и показали, рассказав о «случайном» становлении Джавы или Ноды. Так что от предвидения или непредвидения, похоже, появление новых массовых ЯП не зависит, и когда они появятся, мы так же сможем ретроспективно пытаться понять причины их появления, но следующий ЯП возникнет по совершенно другой причине.
                                                                          • +1
                                                                            В действительности инновации не происходят внезапно, они тщательно готовятся.
                                                                            На 1995 пришелся «массовый старт» интернета, при том Dial Up соединения были доступны и ранее.

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

                                                                            Возможно я скептик, но сомневаюсь что за углом нас ждет новый, не открытый, континент.
                                                                            • +1
                                                                              У вас просто ещё недостаточно опыта для футурологических прогнозов. Опыт придёт, когда на вашем веку из-за угла появится несколько неожиданных континентов (о которых вы потом почитаете, насколько они долго и тщательно готовились). Несколько континентов в комментариях уже попробовали примерить — это и языки для распределённых приложений поверх блокчейнов, и языки для выразительного описания нейросетей и их обучения, и языки для квантовых вычислений. На ваш век ещё хватит инноваций в сфере ИТ точно (если метеорит не упадёт или ядерным грибом не накроет раньше).
                                                                              • 0
                                                                                если метеорит не упадёт или ядерным грибом не накроет раньше

                                                                                Если после такого в живых останется хоть сколько-то много людей, то инноваций в ИТ будет море — знания во многом есть, а рук для выполнения работ хватать не будет — автоматизация будет крайне необходимой и, скорее всего, сложно настраиваемой. Только полное уничтожение человечества может спасти ИТ от инноваций.
                                                                                • 0
                                                                                  И это только вершина айсберга всех возможностей для появления нового ЯП. Столько случайности в человеческой жизни, ужас.
                                                                          • +2
                                                                            А как же островок блокчейна с его Этириум смарт-контрактами и тому подобными? Среда похоже довольно изолированная, благодаря новой архитектуре, и благоприятная, так как деньги вливаются, Там вполне может вырости что-то джаваскрипт-подобное с заточкой под транзакции, безопасность, или какие-то ещё нужды финтеха.
                                                                            • –1
                                                                              Существуют десятки и сотни островков где живут разные диковинные виды типа того же форта или Scheme. Однако чтобы стать новым «большим» языком ниша должна «захватить индустрию».

                                                                              Android этого не сделал, следующая надежда — на IoT. Но там вначале должна произойти крупная катастрофа, возможно, с человеческими жертвами, для того чтобы люди отказались от подхода «тяп-ляп и в продакшн».
                                                                            • 0

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

                                                                              • +3
                                                                                Фреймворки кишат, в основном, потому, что в стандартной веб-платформе многого «взрослого» из мира разработки не хватает. Но с WebComponents и WebAssembly «системные» фреймворки вымрут, мне кажется, а место их экосистемы займут каталоги готовых компонентов и библиотек компонентов. (Комментарий следует читать с придыханием, как о светлом коммунистическом будущем.)
                                                                                • 0
                                                                                  Лет десять назад казалось, что таким фреймворком станет jQuery. Многие начинающие разработчики считали ее и сам язык javascript синонимами, поэтому вопросы вида «как сложить два числа на jquery» (sic!) встречались довольно часто. Однако сейчас она все чаще встречается как основа для более высокоуровневых фреймворков.
                                                                                  • 0
                                                                                    jQuery выстрелила и закрепилась потому, что она соединила две абстракции: DOM-элемент и CSS-селектор. Это на самом деле математика. Выживает та абстракция, которая обобщает существующие красиво, логично и востребованно.
                                                                                  • 0
                                                                                    Мм… Это как Zend Engine и php? Было бы неплохо за этим понаблюдать, может и язык лучше станет.
                                                                                  • 0

                                                                                    За последние 30 лет принципы работы компьютеров не изменились, как и не изменились основные концепции программирования. Я считаю, что нужно делать больший упор на создании и развитии фреймворков под конкретные задачи для существующих относительно низкоуровневых языков программирования, а не изобретать каждый раз велосипед.


                                                                                    Хорошие примеры расширения существующих языков фрейморками: JavaScript (Angular, Ember, React), PHP (Laravel), Java (Spring), C и C++ (Macintosh Toolbox, Qt, Gtk).

                                                                                    • 0
                                                                                      > как и не изменились основные концепции программирования
                                                                                      Изменились задачи и способы (или, скорее, масштабы) их реализации. Фреймворки и ЯП ведь не только «математические» новые принципы и фичи несут, они так же упрощают в проекте взаимодействие людей с очень разными ролями. Написать что угодно можно и на ассемблере, а вот чтобы написать это быстро, с миниумом багов и задействовав сразу кучу программистов, а потом ещё чтобы это поддерживалось много лет, — вот это уже нужно покумекать, какой инструмент выбрать. Я считаю, что нужно делать больший упор на экономику ИТ-отрасли, а не на идеалистические представления о том, каким должен быть сферический ЯП в вакууме.
                                                                                    • 0

                                                                                      Статья забывает про массовые вымирания. Нечто может поменяться и целая ветка очень быстро отправится на мороз. Вот тут нишевые языки могут внезапно стать мейнстримом.
                                                                                      Плюс старые языки уже не могут быстро адаптироваться к изменениям. А новые могут наследовать их лучшие свойства, убирая слабые. Рано или поздно старый яп внезапно может умереть, например, вместе со своим островом.
                                                                                      А вообще, если понимать программирование на уровне "генов", то можно легко адаптироваться к тому, как все течет и меняется

                                                                                      • –2
                                                                                        Хорошим примером массового вымирания является LISP.
                                                                                        В 1980-х были очень популярна концепция экспертных систем построенных на LISP,
                                                                                        дело дошло до того что выпускали компьютеры исполняющие его непосредственно (lisp machines).

                                                                                        Но в какой то момент стало понятно что идея тупиковая, и и все довольно быстро прекратилось.
                                                                                        • +2

                                                                                          А не рано вы лисп хороните? Умерли машины, идеи и лисп остались.

                                                                                          • 0
                                                                                            Не лисп как таковой, его аппаратную реализацию и концепцию экспертных систем.
                                                                                            • 0

                                                                                              Окей, но оригинальный комментарий сформулирован довольно двузначно.

                                                                                          • +3
                                                                                            Боюсь, что опыт Closure и Emacs вы не учитываете. Попытки построить рефлексию в современных языках показывают, что Лисп нужен и нужен, похоже, будет всегда, как нужна математика.

                                                                                            Вот если бы Брендан Эйх выполнил требования спецификации к языку для Netscape и написал Scheme-подобный язык (да с макросами, и с оптимизацией хвостовой рекурсии...) то масса новичков-программистов не удивлялась бы скобочкам, а бодро изучала SCIP и это, правда, пошло бы им и всем нам на пользу.

                                                                                            Уверяю вас, о Лиспе в том или ином виде, вы будете слышать всегда. Он невероятно живуч. Это ли не победа в эволюционной борьбе?
                                                                                            • +6
                                                                                              Лисп в этом смысле похож на крокодила — существует давно, уходить не собирается и в определенном месте сожрет кого угодно, но вот яблоки им собирать все-таки неудобно.
                                                                                            • 0
                                                                                              Ясно не стало. Более того, Clojure сейчас достаточно популярный язык.
                                                                                              Просто обралось слишком большое комьюнити, очень чувствительных к тому, где писать знак операции — если он не между операндами у них начиналась паника.
                                                                                              • +5
                                                                                                Скорее уж примером вымирания можно назвать Delphi. В России на нём было написано просто чудовищное количество софта, он был невероятно популярным. Его интеграция с БД, возможность быстрого прототипирования и компонентный подход (не знаешь как решить задачу — скачай компонент, который её решает) обеспечили ему громадное преимущество.
                                                                                                Но вымер. Вымер резко, внезапно и без каких-либо предпосылок к этому. Наверное, историки до сих пор гадают, как так получилось.
                                                                                            • +2
                                                                                              В начале статьи автором допущена серьёзная логическая ошибка — неоправданное расширение законов эволюции на другую область.
                                                                                              Эволюция работает не только в животном мире, но и в любой подходящей среде.
                                                                                              Это не аксиома, а утверждение, которое нужно сначала доказать, но автор почему-то принимает его за истину и строит на нём все дальнейшие рассуждения. А так как это утверждение ложно, то дальнейшие рассуждения не имеют смысла.
                                                                                              Думаю, что многим будет полезно ознакомиться с учебником логики, чтобы самим не делать подобных ошибок и сразу видеть их у других.
                                                                                              • +2
                                                                                                Думаю, вам будет полезно хотя бы Докинза почитать, на которого автор сослался. Эволюционные принципы уже очень давно вылезли за пределы биологии, и ни у кого нет сомнений в том, что эти принципы математические, а не следствие какой-то божественной природы живой материи. Эволюция проявляется в очень широком классе естественных и неестественных систем, состоящих из множества однородных элементов, во взаимодействии которых можно сформулировать репликацию, изменчивость и отбор. Так же как и термодинамические модели не обязательно применять к физическим задачам, они хорошо себя показывают и в социологии, например. Ограниченность кругозора не всегда возможно компенсировать логикой.
                                                                                                • +2
                                                                                                  Ваш комментарий очень показателен, поэтому считаю нужным разобрать его подробно.
                                                                                                  Думаю, вам будет полезно хотя бы Докинза почитать, на которого автор сослался.
                                                                                                  Откуда вы знаете, что я его не читал? Например, совершенно очевидно, что вы не читали учебник логики, но то что я не читал Докинза ниоткуда не следует.
                                                                                                  У Докинза та же самая проблема, что и у автора — неправомерное расширение законов на другую область. Но даже если мы на минуту допустим, что Докинз прав, то это вообще никак не доказывает правоту автора статьи, потому что это три совершенно разных области, поэтому любые выводы и законы одной области совершенно неправомерно применять к другой без доказательств.

                                                                                                  Эволюционные принципы уже очень давно вылезли за пределы биологии
                                                                                                  Что значит «вылезли за пределы»? Развитие (эволюция) происходит в совершенно разных областях, но из этого не следует, что всё и везде развивается по одним и тем же законам.

                                                                                                  и ни у кого нет сомнений в том,
                                                                                                  Это классическая манипуляция. У меня есть сомнения, поэтому ваше утверждение ложно. Более того, у меня есть не только сомнения, но и доказательства ложности этого утверждения.

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

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

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

                                                                                                  Так же как и термодинамические модели не обязательно применять к физическим задачам, они хорошо себя показывают и в социологии, например
                                                                                                  Где доказательства? Возможно, какие-то модели и действуют, и что с того? Если доказана применимость модели к другой области — то всё отлично, но если доказательства нет — то это всё что угодно, но не наука. Это может быть религия или обычное балабольство, но чаще всего этим пользуется лженаука.

                                                                                                  Ограниченность кругозора не всегда возможно компенсировать логикой
                                                                                                  А какой смысл в кругозоре, если он практически целиком состоит из заблуждений и логических противоречий? К сожалению, такое сейчас не редкость.
                                                                                                  • 0
                                                                                                    Это называется не логика, а демагогия. Разбирать по частям не считаю нужным, уж простите.
                                                                                                • 0
                                                                                                  Вы несправедливы.
                                                                                                  Кажется, что выполнение этих требований для языков программирования достаточно очевидно.

                                                                                                  Я игнорируют только доказательство утверждения непосредственно, но не необходимость доказательства.

                                                                                                  Есть тонкая разница.

                                                                                                  Было бы куда правильнее привести существенную аргументационную базу в подтверждение базового предположения,
                                                                                                  но и безумно занудно, при том.
                                                                                                  • 0
                                                                                                    Вам в целом уже все сказали другие комментаторы, но я не удержусь и все-таки тоже немного позанудствую.

                                                                                                    Ваше утверждение что утверждение автора ложно тоже не аксиома и требует доказательства. Пока же такого доказательства нет автор вполне вправе делать предположения и выводы из них. Если его начальное утверждение окажется верным — все его утверждения (если в них нет самостоятельных логических ошибок) будут верны. Если не верным, то, в общем случае, выводы не будут иметь смысла. Но в данном конкретном частном случае, возможно, может получиться скорректировать первоначальное утверждение и выводы из него так, чтобы рассуждения остались корректными.
                                                                                                    В математике это достаточно распространенный случай, когда на недоказанных утверждения строятся новые конструкции и делаются выводы. Не имеет смысла работать только с уже доказанно ложными утверждениями.
                                                                                                  • +1
                                                                                                    вилами по воде.
                                                                                                    насколько язык должен распространиться, чтобы называться «большим» языком программирования?
                                                                                                    P.S.
                                                                                                    Если даже подвести статистику появления новых ЯП за последние 10 лет — статья уже кажется абсурдной.
                                                                                                    • +1
                                                                                                      На самом деле «островов» хватает, а вот языков для них мало. Раз, два — и обчелся…

                                                                                                      • FPGA. Verilog? VHDL?
                                                                                                      • Сверхмалый embeded. FORTH?
                                                                                                      • SIMD. APL?
                                                                                                      • Транспьютеры и графические сопроцессоры. Occam?
                                                                                                      • ПЛК. Ladder?
                                                                                                      • DSP.???


                                                                                                      Думаю, что на стыке verilog, matlab и apl появится язык для массового проектирования FPGA
                                                                                                      • +1
                                                                                                        Ну попытки сделать язык заметно более высокого уровня чем Verilog или VHDL предпринимаются регулярно. Проблема в инертности отрасли и недостаточной массовости самих FPGA — это все еще слишком дорогое решение для многих задач. Часто дешевле арендовать часть времени обычного сервера и производить вычисления на нем.
                                                                                                      • +7
                                                                                                        Полезно помнить, что отношение порядка определено не на всех множествах. Нельзя сказать, что одна точка в пространстве больше другой, нельзя сравнивать комплексные числа. Когда об этом забывают начинаются священные войны — все правы и никто не прав.

                                                                                                        Сравнивая эволюционные ветви, можно обратить внимание на численность представителей вида, семейства или отряда. В этом смысле Земля — планета жуков, а не людей. Мы построили города, а поселились в них тараканы и голуби. В IT-сфере в этом смысле победят не С, не Haskell и не Ruby, а HTML, CSS и плохие программисты, их просто много и они постоянно откуда-то появляются, хватают самый простой для пищеварения язык, что непонятно выплёвывают и пишут, пишут… :) Новые успешные в этом смысле языки появляются вместе с новыми технологиями и новыми потребностями (например, веяниями моды).

                                                                                                        Можно сравнить кто кого победит в схватке. Тут на Земле человеку с автоматом нет равных. В программировании во время соревнований сильнейший язык выбрать трудно. Я бы, если мне нужно было выбирать язык для себя, выбрал Haskell или Mathematica :) в первом можно быстро написать мощную и корректную программу, во втором — воспользоваться гигантской базой знаний и гибкостью, унаследованной от Лиспа. Python и R — тоже подходят, но мне они не практически нужны были в моей работе. Новый сильный язык родится тогда, например, когда параллельные вычисления станут формализованы до такой степени, чтобы об этом мог позаботиться компилятор. Мы наблюдали такое, когда родились сборщики мусора — классная история!

                                                                                                        Можно сравнивать живучесть. Бактерии термофилы заняли нишу экстремальных температур и ни с кем не конкурируют. Их никто не съест — сварится, а они съедят кого угодно, варёного. Ледяные черви научились жить в снегу, а человек на вездеходе есть повсюду. В программировании такие экстремальные ниши будут появляться всегда. И всегда будут рождаться разновидности FORTH или того же Лиспа, просто в силу простоты реализации и интерпретации. И человек с С (или, возможно, с Rust) тоже будет повсюду.

                                                                                                        Наконец, есть долгожители. Это тоже эволюционный успех! Хрящевые рыбы, гаттерии, гинкго и другие представители живой природы, хоть и немногочисленны, пережили массовые вымирания и населяют планету миллионы лет. Лямбда-исчисление, насление Дональда Кнута, а также Лисп, с нами надолго и, похоже, навсегда. И они не просто существуют, они развиваются! Mascyma, Wolfram Mathematica, Maple — это достижения Лиспа и филигранно отточенных алгоритмов! Haskell развивается медленно, и каждый свой шаг обмозговывает, обсуждает, но при этом рьяно ощупывает множество перспективных направлений. Может быть, он эволюционирует и изменится, но идеи, родившиеся благодаря ему, никуда уже не денутся. Именно на Haskell реализованы языки для формального доказательства теорем: Agda, Coq и Idris. Это тоже кусочек будущего.

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

                                                                                                        • +2

                                                                                                          Пусть медленно, зато Haskell может позволить себе breaking changes, это дорогого стоит.
                                                                                                          Coq написан на OCaml.

                                                                                                          • +1
                                                                                                            Упс! Точно. Но с точки зрения суровых практиков-императивщиков, что Haskell, что OCaml всё одна «модная хипстерская функциональщина» :)
                                                                                                        • –1
                                                                                                          Эволюционное развитие по определению не предполагает революционных изменений. Но это не доказывает, что их не может быть вовсе. Как раз наоборот. Вообще то раньше в высших заведениях изучали философию и даже заставляли по ней сдавать экзамены. Так вот там написано, что эволюционное развитие время от времени прерывается революционными изменениями. И этот закон философии назывался переход количественных изменений в качественные. Как только количественных изменений будет достаточно они перейдут в качественные и эволюционное развитие перейдет на другой уровень. Так что вопрос о появлении качественно нового языка следует не из теории эволюционного развития. Вопрос в том накопилось ли достаточно новых эволюционных идей для качественно нового языка. Я считаю что да. И в ближайшее время возможно появление качественно нового языка, который сотрет со сцены все предыдущие языки программирования.
                                                                                                          • +1
                                                                                                            Вообще то раньше в высших заведениях изучали философию и даже заставляли по ней сдавать экзамены.

                                                                                                            И сейчас учат и заставляют, вопрос только в том, какой именно части философии учат. Нам например рассказывали исключительно о первых древнегреческих философах, половина из которых даже не удосуживалась доказывать свои утверждения. Интересно, но практического применения никакого. Разве что как база для дальнейшего изучения.
                                                                                                          • +2

                                                                                                            А ещё странно, что ни автор, ни комментаторы не упоминают лекцию Роберта Мартина "The last programming language", в которой эта тема подробнейшим образом освещается. Очень рекомендую её всем интересующимся историей ЯП.

                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                              • +1
                                                                                                                1. ЯП создавали люди-создатели. Если ЯП свойственна эволюция как и животным, то животных создавали «создатели».
                                                                                                                Эволюция — это непрерывный процесс проектирования и постройки создателями новых сущностей, от животных до языков программирования.

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

                                                                                                                То есть правильная красивая программа, похожая на человека — это один поток исполнения в трёхмерной памяти. А то, что есть сейчас — многопоточные программы в одномерной памяти — это ад и чудовище.
                                                                                                                • 0
                                                                                                                  Языки не рождаются сами по себе, как животные. Их создают люди. И ничто не мешает создать новый язык, если существующий не достаточно хорош.
                                                                                                                  Но на сегодняшний день, дешевле улучшать существующие языки. Но когда то наступит момент когда из-за принципа обратной совместимости уже будет невозможно улучшать существующий язык.
                                                                                                                  Если считать новую версию языка, новым языком. То можно сказать что новые языки появляются постоянно, просто под тем же названием.
                                                                                                                  • 0
                                                                                                                    Некорректно сравнивать эволюцию языков программирования с эволюцией в живой природе. Там отбор естественный и слепой. У нас же вполне себе разумный.
                                                                                                                    Новые языки не так быстро распространяются по причине легаси и того, что сильно много фичей добавить уже сложно, почти всё из нужного уже было в их предшественниках.
                                                                                                                    И особенно никому не нужны новые языки, которые не пытаются пофиксить ВСЕ известные проблемы предшественников, а так, рюшечки добавляют. И не нужны те, которые привносят изменения туда, куда не надо, где и так всё было нормально и привычно.
                                                                                                                    И единственный язык, разрабы которого это понимают (и про который мне известно, конечно), — это Цейлон. Именно стремится дать максимум фичей, чтоб его имело смысл внедрять (в отличие, например, от котлина, который всё еще тащит багаж явы), и не портят привычные вещи (как скала со своими спейсшип-операторами и прочей наркоманией)
                                                                                                                    Ну еще D, хотя многие считают, что ему не стоило налегать на сборку мусора.
                                                                                                                    • 0

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


                                                                                                                      • проблемы с платформами (такими как JVM)
                                                                                                                      • недостаток производительности (упираемся в кремний)
                                                                                                                      • высокая сложность текущих языков
                                                                                                                      • проблемы с эволюцией текущий языков (неудачная модель развития Python и неудачная модель развития Java).
                                                                                                                      • параллельность на уровне языка
                                                                                                                      • возможность составлять dsl, при максимальной простоте грамматики языка.
                                                                                                                      • +1
                                                                                                                        проблемы с платформами (такими как JVM)

                                                                                                                        Например? Какая есть такая проблема в JVM, которую есть у любого провайдера JVM и которую нельзя обойти своей реализацией JVM?


                                                                                                                        неудачная модель развития Java

                                                                                                                        Например? С точки зрения бизнеса Java (и, скажем, PHP) вполне удачны, они относительно просты и стоимость разработчиков нижнего уровня (манкикодеров) относительно невысока при том что производительность таких разработчиков достаточно приемлемая. То что Java достаточно консервативна, большому бизнесу тоже на руку, он сам обычно весьма консервативен. В своей нише энтерпрайза Java вполне себе неплохо чувствует.

                                                                                                                        • +1

                                                                                                                          Начнем пожалуй с неудачной модели. Вы понимаете на что создатели обрекают язык, декларируя обратную совместимость? Java исчерпала свой бюджет сложности (для манкикодеров) когда вышла версия 5.0 Tiger. И это не я сказал, а Джошуа Блох. Java сложный язык. И те, кто считает Java простой не знают Java. Дальше будет тоже что и в случае с С++. И, поправочка, Java была консервативной, когда ей рулил Sun.


                                                                                                                          Т.е. по вашему мнению платформа идеальна?
                                                                                                                          Сторонние вендоры вам type-erasure починят? И unsigned типы добавят? и добавят большие массивы? И числовые типы заданной длины (как это сделано например в LLVM)? Там знаете можно сделать Int_256 или Int_128 (уже не помню как типы называются, знающие люди простят). И Java все-равно будет медленной.
                                                                                                                          Конечно же производительность Java адекватна решаемым ею задачам, однако сейчас мы упираемся в не только в тактовую частоту процессоров (которая не растет), но и в количество ядер, которое… тоже не очень то и растет.
                                                                                                                          И софт придется оптимизировать. И тут на сцену выйдут языки, с бекендом на LLVM. И, возможно, будут достаточно долго доминировать.

                                                                                                                          • –2

                                                                                                                            В принципе беззнаковые числовые типы не особо нужны, ведь поведение знаковых при переполнении определено. Разве что как синтаксический сахар для Integer#<op>Unsigned и Long#<op>Unsigned.

                                                                                                                            • +2

                                                                                                                              Беззнаковые типы нужны языку для низкоуровневых задач, а ля разбор бинарных форматов и упакованных структур данных, без UInt-ов это может оказаться предельно неоптимально.


                                                                                                                              А ещё беззнаковые целые ведут себя куда предсказуемей при операциях сдвига — что как раз и важно при разборе бинарных данных, где важное значение имеют отдельные биты