Например, щёлкая кнопочки и заполняя поля в соответствующем веб-интерфейсе настройки внешнего вида сайта и его разделов? При установке новых компонентов? При покупке и смене «темы» сайта? Все эти действия пользователь может прекрасно выполнить средствами интерфейса не привлекая разработчиков, которые пересоберут ему сайт и выкатят в продакшен статичную версию.
Тут в чём фишка — это не отдельный тернарный оператор (выражение), альтернативный обычному оператору (набор инструкций).
Это общая форма, не нуждающаяся в отдельном представлении.
Ну вот немного с потолка пример, но наглядно иллюстрирующий
let y = if x >= 5 { let b = 3; x * b } else { let b = 100; b / x };
А внутри можно и цикл прокрутить, если надо, и флаг какой-нибудь установить.
В языках не поддерживающих такое смешение короткий тернарный оператор сразу рассыпается на несколько строчек.
Там же — habrahabr.ru/company/wargaming/blog/221035/#comment_8327961
В принципе неплохо рассмотрены достоинства полуоткрытых интервалов.
А насчёт то правильно, это не правильно и там-то эталон — имхо, это уже от лукавого. Так можно дойти и до эпического сражения «крестовые отвёртки vs плоские».
Есть разные инструменты для разных случаев — все должны быть доступны и под рукой.
Я думаю главный затык в развитии питона последние годы произошёл из-за того, что товарищ Ван Россум немного оторвался от сообщества. Python 3 уже больше 10 лет, но только пару лет назад с версии 3.3 вяло начался процесс миграции. И всё из-за чего? Из языка выкинули несколько базовых возможностей, которые действительно были нужны и лишь годы спустя их наличие было нехотя признано необходимостью, когда стало очевидно, что народ остаётся на 2.7 и машет ручкой разработчикам.
Подобное отношение — неприятный симптом, заставляющий беспокоиться о будущем языка.
А короткая форма для задания range была бы в высшей степени уместна, раз уж появились такие вещи как list comprehension.
InnoDB — изначально K-V, а всё остальное уже поверх.
Есть несколько реализаций NoSQL протокола для InnoDB, позволяющие добиться повышения производительности на порядок за счёт существенного урезания функциональности.
«статическая типизация ни Python'у, ни Ruby не нужны»
Пример RPython и такого великолепного продукта на нём как PyPy ставит под сомнение это утверждение.
И такое может быть нужно и полезно. Просто это — уже немного другой язык.
Наконец, не всё ведь сводится к «числодробилкам». Здесь просто очередной компромисс между скоростью работы и скоростью разработки. Немного потеряв в скорости разработки можно получить хороший прирост в скорости работы на некоторых задачах.
«я знаю что range такой из-за того что он был добавлен на самой заре появления питона»
Тут Вы заблуждаетесь. Просто посмотрите на реализации range в других языках. У такой реализации есть причины, мало соотносящиеся с эпохой. Равно как есть альтернативные реализации с включением правой границы в диапазон.
«Это несложная задача, но лично мне было приятно что я увидел это в stdlib»
Так действительно ведь не сложная — несколько строк кода, которые легко адаптировать под собственную задачу. Ну ок, это скорее эстетический вопрос, не вижу причины спорить. Вряд ли этот отдельный пункт повлиял бы на выбор языка в целом, но Ruby — действительно язык для тех, кто ценит эстетический подход.
О какой выкатке идёт речь?
К выкатке это не имеет никакого отношения.
Просто попытайтесь представить, что сайты не статичны и на их состояние могут влиять пользователи ;-)
Поведение range — вполне документированная особенность. И вполне логичная, если мы представляем, что range заменяет нам внутренности C-подобной конструкции for(i=1; i < 4; i++).
Точно так же и join — объединение списка в строку — это не задача списка. Любой конечный итерируемый объект может быть объединён одним единственным методом строки. Или использован ещё как-то, если нам не строка нужна. А в каждом итерируемом классе подцеплять функцию объединения в строку — как раз не логично.
Точно так же и работа с CSV ( docs.python.org/3.4/library/csv.html ) и сортировка — всё это есть в Python «из коробки». Не понятно, почему Вы приводите этот пример в качестве нежданного превосходства Ruby. Python известен именно своей мощной библиотекой.
Точно так же про «меньшим количеством кода» — не понятно, Python достаточно лаконичный язык.
Когда я начинал изучать питон, мне тоже много вещей казались нелогичными и сбивающими с толку, потому что в других языках, которые я использовал до этого, всё делалось не так. Но это лишь вопрос привычки и знания — узнав как всё это использовать, обнаруживаешь логичность и продуманность. Питон, конечно, не идеальный язык, есть за что его ругать, но вот вышеперечисленное — явно не повод.
Конечно, языки не похожи, но это не значит, что один резко хуже другого, потому что стандарты другого — нравятся. Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
А pypy.js, насколько я понял, пока всё же на сильно ранней стадии. Но уже сам факт наличия Python, работающего в браузере не медленнее Python в консоли — очень даже воодушевляет. Осталось скрестить его с WebGL и начать новую эпоху браузерных приложений. Если же ещё портируют Qt…
Есть, но это уже альтернативные реализации, кое-что от CPython теряющие, особенно в плане написанных на C библиотек и это головная боль и самая, что ни на есть наглядная иллюстрация невозможности «серебрянной пули».
Jython — это интеграция в экосистему энтерпрайз-софта, живущего чуть больше чем полностью во вселенной Java, но там всё своё, и «батарейки» свои, и гуру, пишущие обёртки над сишным кодом — тоже свои.
PyPy — это уже что-то вроде выхода в открытый космос — нечто грандиозное и впечатляющее, нечто большее, чем Python, особенно с того момента, когда он приютил у себя Stackless, но вот именно PyPy — и испытывает тяготы сложности интеграции с сишными либами, а по производительности, несмотря на применяющиеся техники компиляции — он до сишного кода таки не дотягивает. Свой особый мир со своими сверхвозможностями и недостатками.
На самом деле я не дошёл ещё до того, чтобы использовать PyPy, поэтому про недостатки пишу лишь понаслышке. Но думаю, тут без меня хватит тех, кто истоптал вокруг него все грабли.
Кстати, вот буквально вчера мне подбросили вот это: pypyjs.org — pypy с бэкэндом в javascript с asm.js.
Полноценный Python 2.7.8 (PyPy 2.5.0) в браузере.
По производительности на моей машине сопоставимо с CPython2 в консоли — в чём-то медленнее, в чём-то даже быстрее.
А на чём реализован рендеринг?
Неужели никто не озаботился оптимизировать столь существенную просадку в производительности?
Или львиная доля процессорного времени уходит на работу десятков строчек контроллеров, дёргающих библиотеки и скармливающих им данные и шаблоны?
На самом деле я с Ruby и его проблемами не знаком, я сейчас работаю с Python, много лет перед этим посвятив PHP, а данная статья меня заинтересовала в плане расширения кругозора. Но мне очень странно слышать некоторые вещи, особенно учитывая что много хорошего ушло в мир именно из экосистемы Ruby, вот тот же SASS, который я сейчас использую в оригинальной реализации и на чёрный день поглядываю в сторону libsass, переписанной на C.
«если два языка решают одну и ту же задачу»
Все языки решают ту же задачу, что и ассемблер. Да и ассемблер — это лишь примочка к машинному коду.
Я правильно понимаю, что «бессмысленный новодел» Python существенно не отличаясь от ABC, безуспешно пытается у последнего отбить хоть какую-то долю рынка?
— «Появившись сравнительно поздно, Python создавался под влиянием множества языков программирования:
ABC — отступы для группировки операторов, высокоуровневые структуры данных (map)[15][16] (Python фактически создавался как попытка исправить ошибки, допущенные при проектировании ABC);
Modula-3 — пакеты, модули, использование else совместно с try и except, именованные аргументы функций (на это также повлиял Common Lisp);
С, C++ — некоторые синтаксические конструкции (как пишет сам Гвидо ван Россум — он использовал наиболее непротиворечивые конструкции из С, чтобы не вызвать неприязнь у С-программистов к Python[15]);
Smalltalk — объектно-ориентированное программирование;
Lisp — отдельные черты функционального программирования (lambda, map, reduce, filter и другие);
Fortran — срезы массивов, комплексная арифметика;
Miranda — списочные выражения;
Java — модули logging, unittest, threading (часть возможностей оригинального модуля не реализована), xml.sax стандартной библиотеки, совместное использование finally и except при обработке исключений, использование @ для декораторов;
Icon — генераторы.»
Возможности Python на порядок шире возможностей ABC или Icon.
Но не нужен именно Python, а вместо него лучше либо ABC, либо Icon?
Странная логика. Почему действительно не ассемблер в таком случае?
Честно, я не понимаю. Это выглядит как чья-то злая воля, заставившая сообщество поддерживать именно «худший Python», а не «лучший ABC». Но может быть на самом деле всё с точностью до наоборот? И история просто всё расставила по своим местам?
В конце концов сюда можно вспомнить и PHP, который много и справедливо критикуют как очень слабый в плане архитектуры язык, который вообще появился как шаблонизатор для Perl, но быстро своими особенностями и популярностью переросший и погрёбший Perl в Web под собой.
А c языками шелл всё просто. Они нужны только в шелл. Не в веб разработке, не в научной работе, не в разработке прикладных или системных приложений. Они создавались и оптимизировались как языки упрощающие автоматизацию работы с файловой системой и некоторыми особенностями os. Они во многом не самодостаточны, а всю работу выполняют отдельные утилиты, частью shell не являющиеся.
Хотя я лично видел сайты сделанные на bash и знаком с людьми, которые их делали. Просто этот инструмент не самый лучший для этой и многих других целей. Это возможно, но это большинству не нужно. А то, что нужно — мы видим как лидеров индустрии.
Список систем, на которые портирован Ruby впечатляет:
«Официальный интерпретатор портирован под большинство платформ, включая Unix, Microsoft Windows (в том числе Windows CE), DOS, Mac OS X, OS/2, Amiga, BeOS, Syllable, Acorn RISC OS и другие»
Кстати, никто ничего не написал по поводу производительности, а это, имхо, самый существенный вопрос из всех поднятых. И при этом самый комплексный. На самом деле я тут покапитанствую немного на тему.
С одной стороны — странно использовать интерпретируемый язык для математических вычислений, для которых хотелось бы выжимать каждый такт из процессора. Но даже этот вопрос давно обошли созданием обёрток над библиотеками, написанными на соответствующих языках.
С другой стороны — достоинство интерпретируемых языков это не скорость их непосредственной работы, а скорость разработки. Весь круг задач, где программа пишется дольше, чем она вообще работает, где основную работу выполняет внешний по отношению к интерпретатору код — это сфера где интерпретаторы будут безраздельно царствовать ещё очень долго.
В самом деле, в жизни типичного веб-приложения большую часть времени работает база данных, а скрипты лишь переводят ей веб-запросы, и переводят от неё ответы в веб. При этом как только дело касается хоть сколько-нибудь затратных операций — парсинг json, html, отрисовка шаблона, обработка изображений, звука, видео, шифрование — в дело вступают оптимизированные библиотеки. Сам же интерпретируемый язык предоставляет удобный интерфейс для применения этих библиотек в разработке.
Удобство и скорость разработки — вот два козыря, которые никто не может перебить, приводящие к тому что веб вообще держится на интерпретируемых языках, которые ни один не сильны в дисциплине «числодробления». Но даже тут ищутся и находятся компромиссы: JIT (как родной — v8, так и поверх JVM/.NET — JRuby/IronRuby, Jython/IronPython, JPHP/Phalanger), транслирование в код на Си/Си++. Это возможно, если это нужно проекту и интерпретатор стал узким местом. Но обычно узким местом является НЕ интерпретатор.
В результате поднимается вопрос — насколько вообще существенно, что Ruby в вычислительных задачах медленней других интерпретируемых языков? Насколько это важно на фоне синтаксических особенностей языка, удобства разработки и т.п.? Где это делает язык слабым звеном?
> скромно добавляли, что узкие места они всё равно дописывали на Си
Мне кажется странным стесняться подобных подробностей, поскольку весь язык написан на Си, львиная доля библиотек — это обёртки вокруг сишных (а проще говоря универсальных), сама возможность оптимизировать язык за счёт переписывания узких мест на Си преподносится как достоинство языка (и вообще отсутствие такой возможности для интерпретируемого языка вызвала бы минимум удивление).
Таки это так же моё имхо, возможно гуру воспринимают это как-то иначе, но я с Вами соглашусь — «серебрянных пуль» не бывает.
Вы действительно между этими языками видите разницу только «новомодные табы»?
Языки шелла — я искренне удивлён, что они появились в ряду универсальных языков, а тем более как аргумент против необходимости одного из них, на фоне аргумента «Windows же!».
Кроссплатформенность:
Windows хоть сколько-то популярен становится во времена Windows 3.1, но ещё является всего-лишь необязательной надстройкой над DOS.
Windows 9x завоёвывает сердца во второй половине 90-х, но это очень нестабильная система.
Windows NT — появляется примерно в то же время, но малопопулярен и требователен к ресурсам, не совместима с Windows-9x.
Windows XP — начало 2000-х, первая система которая стабильно работает у пользователей.
Зачем всем этим языкам на раннем этапе существования могла понадобиться поддержка Windows, если они все появились до того, как Windows вообще что-то стал значить? Уже во времена 9x все обсуждаемые языки так или иначе были адаптированы под Windows и аргумент «не кроссплатформенно» спустя почти 20 лет звучит странно.
Это общая форма, не нуждающаяся в отдельном представлении.
Ну вот немного с потолка пример, но наглядно иллюстрирующий
let y = if x >= 5 { let b = 3; x * b } else { let b = 100; b / x };
А внутри можно и цикл прокрутить, если надо, и флаг какой-нибудь установить.
В языках не поддерживающих такое смешение короткий тернарный оператор сразу рассыпается на несколько строчек.
>>> r
range(0, 10)
>>> r[:5]
range(0, 5)
>>> r[5:]
range(5, 10)
В принципе неплохо рассмотрены достоинства полуоткрытых интервалов.
А насчёт то правильно, это не правильно и там-то эталон — имхо, это уже от лукавого. Так можно дойти и до эпического сражения «крестовые отвёртки vs плоские».
Есть разные инструменты для разных случаев — все должны быть доступны и под рукой.
Подобное отношение — неприятный симптом, заставляющий беспокоиться о будущем языка.
А короткая форма для задания range была бы в высшей степени уместна, раз уж появились такие вещи как list comprehension.
Не поверите: 2ndquadrant.com/en/resources/bdr
И bytea не синоним BLOB.
Есть несколько реализаций NoSQL протокола для InnoDB, позволяющие добиться повышения производительности на порядок за счёт существенного урезания функциональности.
Пример RPython и такого великолепного продукта на нём как PyPy ставит под сомнение это утверждение.
И такое может быть нужно и полезно. Просто это — уже немного другой язык.
Наконец, не всё ведь сводится к «числодробилкам». Здесь просто очередной компромисс между скоростью работы и скоростью разработки. Немного потеряв в скорости разработки можно получить хороший прирост в скорости работы на некоторых задачах.
Возвращаемся к разнообразию.
Тут Вы заблуждаетесь. Просто посмотрите на реализации range в других языках. У такой реализации есть причины, мало соотносящиеся с эпохой. Равно как есть альтернативные реализации с включением правой границы в диапазон.
«Это несложная задача, но лично мне было приятно что я увидел это в stdlib»
Так действительно ведь не сложная — несколько строк кода, которые легко адаптировать под собственную задачу. Ну ок, это скорее эстетический вопрос, не вижу причины спорить. Вряд ли этот отдельный пункт повлиял бы на выбор языка в целом, но Ruby — действительно язык для тех, кто ценит эстетический подход.
К выкатке это не имеет никакого отношения.
Просто попытайтесь представить, что сайты не статичны и на их состояние могут влиять пользователи ;-)
Точно так же и join — объединение списка в строку — это не задача списка. Любой конечный итерируемый объект может быть объединён одним единственным методом строки. Или использован ещё как-то, если нам не строка нужна. А в каждом итерируемом классе подцеплять функцию объединения в строку — как раз не логично.
Точно так же и работа с CSV ( docs.python.org/3.4/library/csv.html ) и сортировка — всё это есть в Python «из коробки». Не понятно, почему Вы приводите этот пример в качестве нежданного превосходства Ruby. Python известен именно своей мощной библиотекой.
Точно так же про «меньшим количеством кода» — не понятно, Python достаточно лаконичный язык.
Когда я начинал изучать питон, мне тоже много вещей казались нелогичными и сбивающими с толку, потому что в других языках, которые я использовал до этого, всё делалось не так. Но это лишь вопрос привычки и знания — узнав как всё это использовать, обнаруживаешь логичность и продуманность. Питон, конечно, не идеальный язык, есть за что его ругать, но вот вышеперечисленное — явно не повод.
Конечно, языки не похожи, но это не значит, что один резко хуже другого, потому что стандарты другого — нравятся. Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
Устоявшееся, но крепкое как любой стереотип заблуждение. Взять тот же Android, который совсем из другой оперы.
А pypy.js, насколько я понял, пока всё же на сильно ранней стадии. Но уже сам факт наличия Python, работающего в браузере не медленнее Python в консоли — очень даже воодушевляет. Осталось скрестить его с WebGL и начать новую эпоху браузерных приложений. Если же ещё портируют Qt…
Jython — это интеграция в экосистему энтерпрайз-софта, живущего чуть больше чем полностью во вселенной Java, но там всё своё, и «батарейки» свои, и гуру, пишущие обёртки над сишным кодом — тоже свои.
PyPy — это уже что-то вроде выхода в открытый космос — нечто грандиозное и впечатляющее, нечто большее, чем Python, особенно с того момента, когда он приютил у себя Stackless, но вот именно PyPy — и испытывает тяготы сложности интеграции с сишными либами, а по производительности, несмотря на применяющиеся техники компиляции — он до сишного кода таки не дотягивает. Свой особый мир со своими сверхвозможностями и недостатками.
На самом деле я не дошёл ещё до того, чтобы использовать PyPy, поэтому про недостатки пишу лишь понаслышке. Но думаю, тут без меня хватит тех, кто истоптал вокруг него все грабли.
Кстати, вот буквально вчера мне подбросили вот это: pypyjs.org — pypy с бэкэндом в javascript с asm.js.
Полноценный Python 2.7.8 (PyPy 2.5.0) в браузере.
По производительности на моей машине сопоставимо с CPython2 в консоли — в чём-то медленнее, в чём-то даже быстрее.
Неужели никто не озаботился оптимизировать столь существенную просадку в производительности?
Или львиная доля процессорного времени уходит на работу десятков строчек контроллеров, дёргающих библиотеки и скармливающих им данные и шаблоны?
На самом деле я с Ruby и его проблемами не знаком, я сейчас работаю с Python, много лет перед этим посвятив PHP, а данная статья меня заинтересовала в плане расширения кругозора. Но мне очень странно слышать некоторые вещи, особенно учитывая что много хорошего ушло в мир именно из экосистемы Ruby, вот тот же SASS, который я сейчас использую в оригинальной реализации и на чёрный день поглядываю в сторону libsass, переписанной на C.
Все языки решают ту же задачу, что и ассемблер. Да и ассемблер — это лишь примочка к машинному коду.
Я правильно понимаю, что «бессмысленный новодел» Python существенно не отличаясь от ABC, безуспешно пытается у последнего отбить хоть какую-то долю рынка?
— «Появившись сравнительно поздно, Python создавался под влиянием множества языков программирования:
ABC — отступы для группировки операторов, высокоуровневые структуры данных (map)[15][16] (Python фактически создавался как попытка исправить ошибки, допущенные при проектировании ABC);
Modula-3 — пакеты, модули, использование else совместно с try и except, именованные аргументы функций (на это также повлиял Common Lisp);
С, C++ — некоторые синтаксические конструкции (как пишет сам Гвидо ван Россум — он использовал наиболее непротиворечивые конструкции из С, чтобы не вызвать неприязнь у С-программистов к Python[15]);
Smalltalk — объектно-ориентированное программирование;
Lisp — отдельные черты функционального программирования (lambda, map, reduce, filter и другие);
Fortran — срезы массивов, комплексная арифметика;
Miranda — списочные выражения;
Java — модули logging, unittest, threading (часть возможностей оригинального модуля не реализована), xml.sax стандартной библиотеки, совместное использование finally и except при обработке исключений, использование @ для декораторов;
Icon — генераторы.»
* ABC — императивный, процедурный, структурный;
* Python: объектно-ориентированный, рефлективный, императивный, функциональный, аспектно-ориентированный, динамический;
Возможности Python на порядок шире возможностей ABC или Icon.
Но не нужен именно Python, а вместо него лучше либо ABC, либо Icon?
Странная логика. Почему действительно не ассемблер в таком случае?
Честно, я не понимаю. Это выглядит как чья-то злая воля, заставившая сообщество поддерживать именно «худший Python», а не «лучший ABC». Но может быть на самом деле всё с точностью до наоборот? И история просто всё расставила по своим местам?
В конце концов сюда можно вспомнить и PHP, который много и справедливо критикуют как очень слабый в плане архитектуры язык, который вообще появился как шаблонизатор для Perl, но быстро своими особенностями и популярностью переросший и погрёбший Perl в Web под собой.
А c языками шелл всё просто. Они нужны только в шелл. Не в веб разработке, не в научной работе, не в разработке прикладных или системных приложений. Они создавались и оптимизировались как языки упрощающие автоматизацию работы с файловой системой и некоторыми особенностями os. Они во многом не самодостаточны, а всю работу выполняют отдельные утилиты, частью shell не являющиеся.
Хотя я лично видел сайты сделанные на bash и знаком с людьми, которые их делали. Просто этот инструмент не самый лучший для этой и многих других целей. Это возможно, но это большинству не нужно. А то, что нужно — мы видим как лидеров индустрии.
«Официальный интерпретатор портирован под большинство платформ, включая Unix, Microsoft Windows (в том числе Windows CE), DOS, Mac OS X, OS/2, Amiga, BeOS, Syllable, Acorn RISC OS и другие»
Кстати, никто ничего не написал по поводу производительности, а это, имхо, самый существенный вопрос из всех поднятых. И при этом самый комплексный. На самом деле я тут покапитанствую немного на тему.
С одной стороны — странно использовать интерпретируемый язык для математических вычислений, для которых хотелось бы выжимать каждый такт из процессора. Но даже этот вопрос давно обошли созданием обёрток над библиотеками, написанными на соответствующих языках.
С другой стороны — достоинство интерпретируемых языков это не скорость их непосредственной работы, а скорость разработки. Весь круг задач, где программа пишется дольше, чем она вообще работает, где основную работу выполняет внешний по отношению к интерпретатору код — это сфера где интерпретаторы будут безраздельно царствовать ещё очень долго.
В самом деле, в жизни типичного веб-приложения большую часть времени работает база данных, а скрипты лишь переводят ей веб-запросы, и переводят от неё ответы в веб. При этом как только дело касается хоть сколько-нибудь затратных операций — парсинг json, html, отрисовка шаблона, обработка изображений, звука, видео, шифрование — в дело вступают оптимизированные библиотеки. Сам же интерпретируемый язык предоставляет удобный интерфейс для применения этих библиотек в разработке.
Удобство и скорость разработки — вот два козыря, которые никто не может перебить, приводящие к тому что веб вообще держится на интерпретируемых языках, которые ни один не сильны в дисциплине «числодробления». Но даже тут ищутся и находятся компромиссы: JIT (как родной — v8, так и поверх JVM/.NET — JRuby/IronRuby, Jython/IronPython, JPHP/Phalanger), транслирование в код на Си/Си++. Это возможно, если это нужно проекту и интерпретатор стал узким местом. Но обычно узким местом является НЕ интерпретатор.
В результате поднимается вопрос — насколько вообще существенно, что Ruby в вычислительных задачах медленней других интерпретируемых языков? Насколько это важно на фоне синтаксических особенностей языка, удобства разработки и т.п.? Где это делает язык слабым звеном?
> скромно добавляли, что узкие места они всё равно дописывали на Си
Мне кажется странным стесняться подобных подробностей, поскольку весь язык написан на Си, львиная доля библиотек — это обёртки вокруг сишных (а проще говоря универсальных), сама возможность оптимизировать язык за счёт переписывания узких мест на Си преподносится как достоинство языка (и вообще отсутствие такой возможности для интерпретируемого языка вызвала бы минимум удивление).
Таки это так же моё имхо, возможно гуру воспринимают это как-то иначе, но я с Вами соглашусь — «серебрянных пуль» не бывает.
Система типов: строгая, полиморфная
* Icon (1975): императивный, логический;
Система типов: динамическая
* Perl (1987): императивный, объектно-ориентированный, функциональный;
Система типов: слабая динамическая
* Python (1991): объектно-ориентированный, рефлективный, императивный, функциональный, аспектно-ориентированный, динамический;
Система типов: строгая, динамическая
Вы действительно между этими языками видите разницу только «новомодные табы»?
Языки шелла — я искренне удивлён, что они появились в ряду универсальных языков, а тем более как аргумент против необходимости одного из них, на фоне аргумента «Windows же!».
Кроссплатформенность:
Windows хоть сколько-то популярен становится во времена Windows 3.1, но ещё является всего-лишь необязательной надстройкой над DOS.
Windows 9x завоёвывает сердца во второй половине 90-х, но это очень нестабильная система.
Windows NT — появляется примерно в то же время, но малопопулярен и требователен к ресурсам, не совместима с Windows-9x.
Windows XP — начало 2000-х, первая система которая стабильно работает у пользователей.
Зачем всем этим языкам на раннем этапе существования могла понадобиться поддержка Windows, если они все появились до того, как Windows вообще что-то стал значить? Уже во времена 9x все обсуждаемые языки так или иначе были адаптированы под Windows и аргумент «не кроссплатформенно» спустя почти 20 лет звучит странно.