Ну да, мы же не уверены до конца, там мало что понятно, нужно больше экспериментов, научные наблюдения.
Только вот планета у нас всего одна для экспериментов.
См. конец 2-й страницы работы. Они используют соотношение фунты CO2 на киловатт*час по США (от EPA — U.S. Environmental Protection Agency). У них же в работе на той же странице есть таблица с пропорциями используемых источников энергии для США, Германии и Китая. На ней видно, что США не слишком экологична в этом плане — меньше всего возобновляемых источников энергии, в разы большая доля угля, чем у двух других стран.
Нассим Талеб вывел интересное эмпирическое правило («эффект Линди») согласно которому для оценки времени жизни технологии нужно продлить в будущее то время, что она уже используется. В 99% случаев это будет верно, потому что большинство новинок вытесняются вскоре другими новинками и только очень немногие закрепляются надолго. Поэтому колесо мы будем использовать ещё примерно 6000 лет, язык С — ещё примерно 50 лет, функциональное программирование — ещё примерно 70 лет и т.д.
Поэтому в институтах нужно хорошо учить историю IT (почти как рассказывают Kevlin Henney, Robert Martin и Alan Key) с именами, идеями, концепциями, а также старые технологии, представляющие собой ортогональный базис главных идей. Из языков нужно учить LISP, SmallTalk и какой-нибудь диалект Algol (например C или Pascal). А специфику подтянуть либо по остаточному принципу на старших курсах, либо на факультативах. А то получается (как говорит Алан Кей) поп-культура, аналогичная тому как если бы студенты-физики не знали кто такой Ньютон и Паскаль и что они придумали. И такие студенты не будут изобретать заново микросервисную архитектуру, потому что будут знать, что ей уже лет 60.
Для человека неискушённого любое современное программирование одинаково дико выглядит — говорю как part-time школьный учитель информатики. Попробуйте объяснить что такое присваивание незнакомому с этим человеку, что x = x + 1 это норма и пр. И любой вообще ЯП требует понимания таких вещей как функция хотя бы на каком-то уровне, т.е. люди с тройкой по математике сразу идут лесом.
Согласен насчёт С++. Я читал книгу Сайбеля по Common LISP, язык не больше большинства современных мейнстримовых, например Python (там на самом деле очень много всего) или Java. Но у него есть возможности, которых нет ни у кого, так что лично для меня это адекватная цена. Особенно с учётом того, что нотация для всех этих фич одна и та же — списки и её можно объяснить за минуту человеку с опытом программирования.
Так что в этом смысле LISP (и диалекты) кардинально проще других ЯП (где нужно помнить много хитрых значков, отступов и ключевых слов и что они значат в том или ином контексте). В этом смысле он ближе всех к естественным языкам (русский, английский), где у нас есть очень маленький ортогональный базис (существительное, прилагательное, глагол, ..., грамматика) и множество предметных областей, включая саму лингвистику (как это похоже на мета-возможности LISP !).
насколько я знаю трагедия LISP была как раз в другом — он настолько гибок в смысле изменения синтаксиса (из-за гомоиконности и мощнейшей системы макросов), что люди очень легко начинали делать с нуля (и делали) то, для чего в других языках применили бы чужую библиотеку. В итоге получился зоопарк собственных решений и раздробленность сообщества.
Много можно чего ещё скопировать из Haskell (и раздуться похлеще монстра C++), но задачи такой, как я понимаю, не стоит. Я просто имел в виду, что разработчики Python в сторону Haskell смотрят внимательно и заимствуются фичи оттуда давно, потому что list comprehensions в Python с 2000 года.
Clojure — интерпретируемый язык с динамической типизацией, но там есть библиотека spec, которая позволяет описать «схему» данных примерно как в Python, но в рантайме это всё проверяется на корректность. И также есть аннотации типов, которые позволяют указать тип Java и это влияет на производительность, потому что можно написать алгоритм, который будет работать только со списком Long, не задействуя рефлексию.
Там есть Any, Union (sum type), дженерики и пр. Т.е. можно описать любой тип, даже сложную вложенную структуру или функцию. Можно создать свой кастомный тип.
В общем Python списывает хорошее у Haskell ещё начиная со списковых выражений.
подробнее здесь: docs.python.org/3/library/typing.html
И Алан Кей и Рич Хики говорят, что ещё не видели системы типов, которая бы помогала, а не мешала, и не причиняла бы боль. Очень возможно, что из Haskell/Rust/F# сообщества появится такая система типов. А до тех пор у нас будут void *, interface {} и пр. в языках, которые имеют статическую типизацию.
Только вот планета у нас всего одна для экспериментов.
Поэтому в институтах нужно хорошо учить историю IT (почти как рассказывают Kevlin Henney, Robert Martin и Alan Key) с именами, идеями, концепциями, а также старые технологии, представляющие собой ортогональный базис главных идей. Из языков нужно учить LISP, SmallTalk и какой-нибудь диалект Algol (например C или Pascal). А специфику подтянуть либо по остаточному принципу на старших курсах, либо на факультативах. А то получается (как говорит Алан Кей) поп-культура, аналогичная тому как если бы студенты-физики не знали кто такой Ньютон и Паскаль и что они придумали. И такие студенты не будут изобретать заново микросервисную архитектуру, потому что будут знать, что ей уже лет 60.
Так что в этом смысле LISP (и диалекты) кардинально проще других ЯП (где нужно помнить много хитрых значков, отступов и ключевых слов и что они значат в том или ином контексте). В этом смысле он ближе всех к естественным языкам (русский, английский), где у нас есть очень маленький ортогональный базис (существительное, прилагательное, глагол, ..., грамматика) и множество предметных областей, включая саму лингвистику (как это похоже на мета-возможности LISP !).
Кажется, да.
Много можно чего ещё скопировать из Haskell (и раздуться похлеще монстра C++), но задачи такой, как я понимаю, не стоит. Я просто имел в виду, что разработчики Python в сторону Haskell смотрят внимательно и заимствуются фичи оттуда давно, потому что list comprehensions в Python с 2000 года.
В общем Python списывает хорошее у Haskell ещё начиная со списковых выражений.
подробнее здесь: docs.python.org/3/library/typing.html
А вообще посмотрите на FiraCode
P.S. Извините. Буду обновлять страницу перед тем как отвечать.
Текст выступления? Или перевод на русский?
Насколько я знаю, ни того, ни другого нет.
Самая лучшая апологетика динамической типизации (не с ура-пофигистских позиций типа «а нафига типы?»), которую я видел, здесь:
youtu.be/YR5WdGrpoug
youtu.be/2V1FtfBDsLU?t=1143 (можно даже отсюда начать: youtu.be/2V1FtfBDsLU?t=1639)
Вы в шаге от удивительного открытия.