Спасём детей от программирования!

[fgh]

0. Результирующий исполняемый код не будет меньше кода на Ассемблере/бинарном коде.

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

[DrBeer]

0. Результирующий исполняемый код не будет меньше кода на Ассемблере/бинарном коде.

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

Не так к сожалению тоже не будет. Это как про "человеческие языки" - для создания сложных и крупных произведений необходим выразительный и многогранный язык. На языке  условного племени "Тумба-Юмба", с 2000 слов в языке, не напишешь , например "Трое в одной лодке", т.к не хватит выразительности языка. Точно также и в программировании. А чтоыбы сократить количество исходного кода, надо иметь языковые команды, типа индейских имен с таким же набором "свойств" - "тот кто носит большую шляпу, в дождлвую погоду, держа в руке лук и стрелы, а нож спрятав в сапог, где также лежит платок вышитой его женой которая является дочерью друга отца из селения которое находится за самым больших холмом который скрывается туманом  осенью" 
Одним словом - достичь такого можно только за счет усложнения самого языка, увеличения количества и сложности ключевых слов. ЧТо ломает идею "гибкости и универсальности"


 

[fgh]

0. Результирующий исполняемый код не будет меньше кода на Ассемблере/бинарном коде.

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

Не так к сожалению тоже не будет. Это как про "человеческие языки" - для создания сложных и крупных произведений необходим выразительный и многогранный язык. На языке  условного племени "Тумба-Юмба", с 2000 слов в языке, не напишешь , например "Трое в одной лодке", т.к не хватит выразительности языка. Точно также и в программировании. А чтоыбы сократить количество исходного кода, надо иметь языковые команды, типа индейских имен с таким же набором "свойств" - "тот кто носит большую шляпу, в дождлвую погоду, держа в руке лук и стрелы, а нож спрятав в сапог, где также лежит платок вышитой его женой которая является дочерью друга отца из селения которое находится за самым больших холмом который скрывается туманом  осенью" 
Одним словом - достичь такого можно только за счет усложнения самого языка, увеличения количества и сложности ключевых слов. ЧТо ломает идею "гибкости и универсальности"

Но ведь раньше, когда шли от Ассемблера  к Бейсику и Паскалю, а потом к Питону и всякоим прочим Руби и Хаскелям такую проблему легко ведь решали? Почему на современном паскале возник блок дальнейшего движения вверх? Тут придётся от слов переходить  к своеобразным предложениям. Лаконичность и выразительность языка придётся компенсировать чуть большей внутренней сложностью, это поняттно.

[DrBeer]

0. Результирующий исполняемый код не будет меньше кода на Ассемблере/бинарном коде.

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

Не так к сожалению тоже не будет. Это как про "человеческие языки" - для создания сложных и крупных произведений необходим выразительный и многогранный язык. На языке  условного племени "Тумба-Юмба", с 2000 слов в языке, не напишешь , например "Трое в одной лодке", т.к не хватит выразительности языка. Точно также и в программировании. А чтоыбы сократить количество исходного кода, надо иметь языковые команды, типа индейских имен с таким же набором "свойств" - "тот кто носит большую шляпу, в дождлвую погоду, держа в руке лук и стрелы, а нож спрятав в сапог, где также лежит платок вышитой его женой которая является дочерью друга отца из селения которое находится за самым больших холмом который скрывается туманом  осенью" 
Одним словом - достичь такого можно только за счет усложнения самого языка, увеличения количества и сложности ключевых слов. ЧТо ломает идею "гибкости и универсальности"

Но ведь раньше, когда шли от Ассемблера  к Бейсику и Паскалю, а потом к Питону и всякоим прочим Руби и Хаскелям такую проблему легко ведь решали? Почему на современном паскале возник блок дальнейшего движения вверх? Тут придётся от слов переходить  к своеобразным предложениям. Лаконичность и выразительность языка придётся компенсировать чуть большей внутренней сложностью, это поняттно.

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

Для примера рекомендую почитать код, например на языке 1С - Фактически то о чем ты говоришь, но.. почитай, и расскажи - легко ли с таким языком и  конструкциями работать ? И это узкопрофильный язык

[Etranger]

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

Так абсолютно "человеческого языка" просто не существует. Мало сказать, что языков огромное количество и они отличаются между собой и структурой, и последовательностью изложения мысли, и временами, падежами, родами, и еще много чем. Так еще и внутри одного языка носители по-разному им пользуются. Так что все это автоматизировать, структурировать и загнать в код просто невозможно. Да и не нужно, на мой взгляд. Язык программирования точно не требует такого разнообразия и синонимического ряда, на которые способны естественные языки.

[DrBeer]

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

Так абсолютно "человеческого языка" просто не существует. Мало сказать, что языков огромное количество и они отличаются между собой и структурой, и последовательностью изложения мысли, и временами, падежами, родами, и еще много чем. Так еще и внутри одного языка носители по-разному им пользуются. Так что все это автоматизировать, структурировать и загнать в код просто невозможно. Да и не нужно, на мой взгляд. Язык программирования точно не требует такого разнообразия и синонимического ряда, на которые способны естественные языки.

Абсолютно согласен, и даже поясню почему
У любой задачи для программирования очень ограниченный круг задач. По сути - "здесь взять, туда передать, обработать по алгоритму,  получить результат, проверить, передать туда". Это на самом деле ОБЩИЙ сценарий ЛЮБОЙ программы. По этому в языках программирования вы не найдете языков, например со 150 ключевыми словами. А давайте возьмём любой, самый примитивный язык людей, даже из самого изолированного сообщества (влияет на количество слов), и сколько там будет слов ?

[Etranger]

Абсолютно согласен, и даже поясню почему
У любой задачи для программирования очень ограниченный круг задач. По сути - "здесь взять, туда передать, обработать по алгоритму,  получить результат, проверить, передать туда". Это на самом деле ОБЩИЙ сценарий ЛЮБОЙ программы. По этому в языках программирования вы не найдете языков, например со 150 ключевыми словами. А давайте возьмём любой, самый примитивный язык людей, даже из самого изолированного сообщества (влияет на количество слов), и сколько там будет слов ?

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

[fgh]

 

Для примера рекомендую почитать код, например на языке 1С - Фактически то о чем ты говоришь, но.. почитай, и расскажи - легко ли с таким языком и  конструкциями работать ?   

Почитал, посмотрел. Складывается впечатление, что вообще синтаксис запутывающий. Я как -то ради интереса изучал синтаксис разных языков программирования через приложение. И сформировал для себя небольшую теорию, как, на мой взгляд, должна выглядеть синтаксис, порождающий идеально читабельную программу… Дело не в количестве ключевых слов, а именно в организации сематического пространства.
   В 1с это: Страница кода не структурирована на модули. Наугад открытая страница кода — мы не понимаем в какой части программы находимся и где встроенная навигация, чтобы это понять.
   В моём представлении хорошая программа должна быть похожа на план здания и с пометкой «Мы находимся здесь». На более высоком уровне — это сборник таких планов с единой навигацией по ним.

Абсолютно согласен, и даже поясню почему
У любой задачи для программирования очень ограниченный круг задач. По сути - "здесь взять, туда передать, обработать по алгоритму,  получить результат, проверить, передать туда". Это на самом деле ОБЩИЙ сценарий ЛЮБОЙ программы. По этому в языках программирования вы не найдете языков, например со 150 ключевыми словами. А давайте возьмём любой, самый примитивный язык людей, даже из самого изолированного сообщества (влияет на количество слов), и сколько там будет слов ?

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

[DrBeer]

Для примера рекомендую почитать код, например на языке 1С - Фактически то о чем ты говоришь, но.. почитай, и расскажи - легко ли с таким языком и  конструкциями работать ?   

Почитал, посмотрел. Складывается впечатление, что вообще синтаксис запутывающий. Я как -то ради интереса изучал синтаксис разных языков программирования через приложение. И сформировал для себя небольшую теорию, как, на мой взгляд, должна выглядеть синтаксис, порождающий идеально читабельную программу… Дело не в количестве ключевых слов, а именно в организации сематического пространства.
   В 1с это: Страница кода не структурирована на модули. Наугад открытая страница кода — мы не понимаем в какой части программы находимся и где встроенная навигация, чтобы это понять.
   В моём представлении хорошая программа должна быть похожа на план здания и с пометкой «Мы находимся здесь». На более высоком уровне — это сборник таких планов с единой навигацией по ним.

Абсолютно согласен, и даже поясню почему
У любой задачи для программирования очень ограниченный круг задач. По сути - "здесь взять, туда передать, обработать по алгоритму,  получить результат, проверить, передать туда". Это на самом деле ОБЩИЙ сценарий ЛЮБОЙ программы. По этому в языках программирования вы не найдете языков, например со 150 ключевыми словами. А давайте возьмём любой, самый примитивный язык людей, даже из самого изолированного сообщества (влияет на количество слов), и сколько там будет слов ?

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

1. Язык 1С - более "человекоподобный", даже из серии " а скажите что то на бухгалтерском"  Универсален - хоть учет, хоть АПИ, хоть игру в шахматы можно написать, и кучу другого бесполезного... Цена "универсальности и человоекоподобности" - очень медленный и тяжелый код, с кучей "готовых" конструкций, что не дает преимуществ для универсального применения. И это я еще не предлагал залезть посмотреть на структуру данных в БД... вот там "дикий оскал  универсальности" виден в полной мере ! Если хочется пощекотать нервы - для начала изучить SQL и правила нормализации данных, а потом заглянуть в структуру БД в 1С ! Гарантирую незабываемые ощущения
2. Это всего лишь вариация на тему того что я писал, но поверь - "под капотом" всё  легко и полностью опишется моей моделью :)То что ты описал -это высокоуровневые абстракции, можно даже к 1С вернуться, прастихопаде    Там "на верху" - счета, проводки, документы, балансы, а "под капотом" - берет отсюда, по алгоритму обрабатываем, передаем туда

[fgh]

1. Язык 1С - более "человекоподобный", даже из серии " а скажите что то на бухгалтерском"  Универсален - хоть учет, хоть АПИ, хоть игру в шахматы можно написать, и кучу другого бесполезного... Цена "универсальности и человоекоподобности" - очень медленный и тяжелый код, с кучей "готовых" конструкций, что не дает преимуществ для универсального применения. И это я еще не предлагал залезть посмотреть на структуру данных в БД... вот там "дикий оскал  универсальности" виден в полной мере ! Если хочется пощекотать нервы - для начала изучить SQL и правила нормализации данных, а потом заглянуть в структуру БД в 1С ! Гарантирую незабываемые ощущения
2. Это всего лишь вариация на тему того что я писал, но поверь - "под капотом" всё  легко и полностью опишется моей моделью :)То что ты описал -это высокоуровневые абстракции, можно даже к 1С вернуться, прастихопаде    Там "на верху" - счета, проводки, документы, балансы, а "под капотом" - берет отсюда, по алгоритму обрабатываем, передаем туда

Я думаю, там проблема не в универсальности. Зря ты на универсальность грешишь. Универсальность разная бывает. Там на мой пусть сугубо дилетантский взгляд, но те не менее в синтаксисе и общей организации кода. Синтаксис там ужасный. Плюс моя идея была во фрактальной организации программ... Но это сейчас, чувствую, бесполезно обсуждать...
   Проще обсудить качество отдельных элементов языка. О чём я?
 Как-то давно залипал на блок создателя своего языка программирования. Может найду его даже в инте. Тот подошёл к делу основательно. И обдумывал каждый элемент языка на предмет его рациональности.
   Помню, он обсуждал в блоге такой феномен: языки имеют положительный тип данных, который можно записать по-разному, отсюда путаница и баги.
К примеру, цифру 5 можно записать как 5 и как +5. Для нас это одно и то же, а прога может воспринять их как разные сущности и это может быть источником фейлов. Вопрос - как быть? Оставить в языке только 5, только +5 или допустимо и то и другое?

[DrBeer]

1. Язык 1С - более "человекоподобный", даже из серии " а скажите что то на бухгалтерском"  Универсален - хоть учет, хоть АПИ, хоть игру в шахматы можно написать, и кучу другого бесполезного... Цена "универсальности и человоекоподобности" - очень медленный и тяжелый код, с кучей "готовых" конструкций, что не дает преимуществ для универсального применения. И это я еще не предлагал залезть посмотреть на структуру данных в БД... вот там "дикий оскал  универсальности" виден в полной мере ! Если хочется пощекотать нервы - для начала изучить SQL и правила нормализации данных, а потом заглянуть в структуру БД в 1С ! Гарантирую незабываемые ощущения
2. Это всего лишь вариация на тему того что я писал, но поверь - "под капотом" всё  легко и полностью опишется моей моделью :)То что ты описал -это высокоуровневые абстракции, можно даже к 1С вернуться, прастихопаде    Там "на верху" - счета, проводки, документы, балансы, а "под капотом" - берет отсюда, по алгоритму обрабатываем, передаем туда

Я думаю, там проблема не в универсальности. Зря ты на универсальность грешишь. Универсальность разная бывает. Там на мой пусть сугубо дилетантский взгляд, но те не менее в синтаксисе и общей организации кода. Синтаксис там ужасный. Плюс моя идея была во фрактальной организации программ... Но это сейчас, чувствую, бесполезно обсуждать...
   Проще обсудить качество отдельных элементов языка. О чём я?
 Как-то давно залипал на блок создателя своего языка программирования. Может найду его даже в инте. Тот подошёл к делу основательно. И обдумывал каждый элемент языка на предмет его рациональности.
   Помню, он обсуждал в блоге такой феномен: языки имеют положительный тип данных, который можно записать по-разному, отсюда путаница и баги.
К примеру, цифру 5 можно записать как 5 и как +5. Для нас это одно и то же, а прога может воспринять их как разные сущности и это может быть источником фейлов. Вопрос - как быть? Оставить в языке только 5, только +5 или допустимо и то и другое?

У нас несколько разные взгляды на языки ! Но это нормально !
Давай еще удивлю - самый универсальный язык, если откинуть машинный код - это ассемблер !
Именно УНИВЕРСАЛЬНЫЙ но низкоуровневый. Итого - СЛОЖНЫЙ и ДОРОГОЙ для разработки

Языки ВЫСОКОГО УРОВНЯ.
Не абсолютно универсальные, но несоизмеримо более УДОБНЫЕ, и более выгодные с точки зрения стоимости разработки и развития продукта. Но УНИВЕРСАЛЬНОСТЬ у языков высокого уровня достигается не за счет большого количеств "слов", а за счет гибкости языка/компилятора/транслятора, а также наличия библиотек расширяющих возможности языка.

Есть языки высокого уровня специализированные, например что то типа ФОРТРАН-а, но на нем очень удобно вести математические расчеты, с удобной языковой моделью, но узкопрофильный... Например движок сайта на ФОРТРАН-е врядли можно написать.
А есть языки общего применения - например тот же любимый мой Питон Хочешь - пиши свою GUI-вую аппликуху, хочешь - компилятор, хочешь нейросеть, а хочешь  - сайт ! Но вот например вычисления будут скорее всего медленнее чем в фортран. Хотя есть масса библиотек, написанных на С и прекрасно оптимизированных для обработки данных

Относительно 5, +5 - это всего лишь механизм представления данных но не более того. Скорее всего некая обратная совместимость и историческая привычка. Но это возможность акцентировать внимание, вероятно комуто надо было. Как в питоне: можно написать число 42180982049287, вроде ок, чо там. А вот так 42_180_982_049_287 удобнее и ты видишь уже сколько там тысячмиллионовмиллиардов. Просто УДОБНОЕ написание.
Или вот сокращенная запись инкремента  x += 1 , выглядит дико для обывателя, но.. так решили что будет удобно, чтобы не писать  x = х + 1  И транслятор или компилятор не ошибется, т.к. это языковая конструкцияили особенность языка, о которой он точно знает.

[fgh]

Давай еще удивлю - самый универсальный язык, если откинуть машинный код - это ассемблер !
Именно УНИВЕРСАЛЬНЫЙ но низкоуровневый. Итого - СЛОЖНЫЙ и ДОРОГОЙ для разработки

Вот как же ты заколебал со свои ассемблером! Неужели ты думаешь, что про него нужно столько раз упоминать?)

Языки ВЫСОКОГО УРОВНЯ.
Не абсолютно универсальные, но несоизмеримо более УДОБНЫЕ, и более выгодные с точки зрения стоимости разработки и развития продукта. Но УНИВЕРСАЛЬНОСТЬ у языков высокого уровня достигается не за счет большого количеств "слов", а за счет гибкости языка/компилятора/транслятора, а также наличия библиотек расширяющих возможности языка.

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

[DrBeer]

Давай еще удивлю - самый универсальный язык, если откинуть машинный код - это ассемблер !
Именно УНИВЕРСАЛЬНЫЙ но низкоуровневый. Итого - СЛОЖНЫЙ и ДОРОГОЙ для разработки

Вот как же ты заколебал со свои ассемблером! Неужели ты думаешь, что про него нужно столько раз упоминать?)

Языки ВЫСОКОГО УРОВНЯ.
Не абсолютно универсальные, но несоизмеримо более УДОБНЫЕ, и более выгодные с точки зрения стоимости разработки и развития продукта. Но УНИВЕРСАЛЬНОСТЬ у языков высокого уровня достигается не за счет большого количеств "слов", а за счет гибкости языка/компилятора/транслятора, а также наличия библиотек расширяющих возможности языка.

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

1.  ...но он реально универсальный !
2. ВОт именно - именно возможность писать удобные библиотеки, расширяющие базовую функциональность, и наличие широкого круга библиотек, и делает язык более востребованным и более универсальным, с точки зрения широты применения. Смотрим на ассемблер Питон 
3. "Сокращённая запись инкремента..." - это просто надо признать и смириться Я думаю что в текущих, новых версиях языков это сделано для поддержки старого кода и "исторических приколов".

[fgh]

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

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

[DrBeer]

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

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

Да, подход с подключаемыми библиотеками дает непревзойдённую гибкость и эффективный код. Если не использовать библиотеки, тогда все придётся засовывать в сам язык, и весь этот гамуз тащить в ЛЮБОМ проекте. Идея работы с библиотеками предельно простая и удобная - есть МИНИМАЛИСТИЕСКОЕ ядро для запуска приложения, Это значит мало места и мало ресурсов (оптимально), если надо работать например с запросами - вот тебе request, а надо тебе данными крутить анализировать и быстро - вот получите  pandas.
У Питона например примерно 130000+ библиотек НА ЛЮБОЙ ВКУС ! Ты можешь выбрать разработку как от именитых так и новичков, каждая библиотека развивается или производителем или сообществом. Представь реализовать и поддерживать такой обьем на стороне разработчиков того же Питона ?  Да это никаких ресурсов не хватит. Вообще-то мою правоту доказывает и факт того что все языки высокого уровня имеют ипическое количество библиотек (этакая децентрализация кстати ) причем производимых как "владельцами языков" так и сторонними компаниями. Это реальная гибкость , удобство и возможности выбора наиболее оптимального решения. Если ничто не подходит - напиши свою библиотеку