Comments 157
GIL — очевидный и вопиющий дефект во всех отношениях приятного языка. Несмотря на популярность CPython, несмотря на талантливых разработчиков, несмотря на спонсоров, таких как Google, Microsoft и Intel, исправлять GIL даже не планируется.
Мне казалось, там вполне понятно написано — почему. Потому что если его выпилить, то однопоточные программы будут работать еще медленнее. Причем даже есть другие реализации питона, где его так или иначе убирали (у pypy есть режим без gil), но лучше реализация не получалась.
Ядро Линукс, думаю, вполне подходит в качестве контрпримера. Актуальные вещи успешно эволюционируют и переписываются, некоторые и не по одному разу (неоднократная замена реализации файрвола, например)
Ну, если я не ошибаюсь, там уже третий вариант реализации, хотя большинство серверов пока еще используют самую первую. Так что такой себе пример.
Pascal тоже еще жив, но это не говорит о том, что он конкурентоспособен.
В лагере плюсовиков похоже так до сих пор и не поняли, что в современном мире популярность языка определяется не синтаксическим сахаром, а лёгкостью разворачивания/сборки проектов, подгрузки библиотек/модулей, а также интеграцией с IDE. По всем этим пунктам у C++ застой, зато постоянно вводят очередные навороченные конструкции, которыми пользоваться будут полтора кодера.
www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf
Правда, именно в C++17 их не включили, но в C++20 они наверняка появятся. Что же касается «подгрузки библиотек/модулей», то если речь идет именно о легком доступе к какому-то репозиторию, где много всяких модулей, то это тоже скорее вопрос фреймворка, а не языка, например, в Visual Studio для этого есть nuget с обширной библиотекой модулей для всех поддерживаемых Visual Studio языков, для MacOS/iOS есть CocoaPods, который тоже поддерживает сразу несколько языков, и так далее. Пихать это в ЯЗЫК тоже, как минимум, странно. Ну и не вижу я проблем с интеграцией C++ в IDE, хотя бы в том же Visual Studio (в отличие от Visual Studio Code, но тут проблема не в языке, а в… хм… «IDE»).
Пихать такие вещи, как сборка проектов и их разворачивание, в ЯЗЫК — это довольно странно.
Для 60ых годов, когда единственное требование к языку было возможность упихать его на перфокарту — да.
Сейчас, когда сделать свой язык может даже начинающий, хороший ЯП это не что больше чем файлы с текстом, это экосистема, причем киллер-фичи определяет именно она.
Вы сейчас описали связку CLR, MSBuild и Visual Studio. Обеспечивают интероп и единую систему сборки между C++/C#/VB/F#/IronPython/IronRuby/Nemerle. Вменяемый бесшовный интероп C++ с CLI, правда, Windows-only, но это скорее связано с непортабельностью MSVC++ и с некоторым зоопарком компиляторов на других платформах.
В каком месте у C или C++ описанные вами проблемы? Вы случайно не путаете проблемы OS, совместимости с конкретной OS и архитектурой с проблемами языка?
Одно дело когда написал в условном package.json список желаемых библиотек и передёрнул менеджер пакетов, другое — когда у тебя autoconf генерирует cmakefile чтобы cmake потом сделал тебе configure и собрал Makefile из 800-2500 строк чтобы собрать один консольный плеер для музыки.
Поэтому стараюсь как-то подальше держаться от всех этих автоконфигураторов, если проект нельзя собрать одним мейкфайлом — значит сложность уже пересекла все разумные пределы и стоит подумать, как это разрастание пресечь, имхо :-)
Тот же JS, обрастает новыми фичами и разными концепциями, сохраняя все предыдущие неудачные решения. Однажды это выльется в то, что кривая обучения JS превратится в вертикаль.
- typeof null — бред, но терпимо.
- Сложное приведение типов. Терпимо, т. к. обычно ты не смешиваешь типы. Например, никакой человек в здравом уме не станет сравнивать строку и объект. При этом из названия переменной всегда видно, где есть что, поэтому опечататься тоже сложно.
- Отсутствие типов. Не считается, т. к. никто не мешает в будущем добавить типы с сохранением обратной совместимости. Мы ведь говорили о штуках, которые препятствуют развитию языка, которые нельзя исправить с сохранением совместимости.
- Всякий бред, который пофикшен с use strict.
- Отсутствие 64-битных чисел. Вот это обидно, да. Хотя в будущем можно пофиксить. Впрочем, уже сейчас можно использовать BigInt, который в будущем может быть оптимизирован при хранении 64-битных чисел с ограничением до 64 бит.
- Отсутствие настоящих приватных полей класса. Не то, чтобы сильно критично (т. к. есть соглашение по приватности) + они уже запланированы в ближайшее время, правда, к сожалению, только с синтаксисом class xxx { … }.
- Сборщик мусора и соответствующие проблемы. Нельзя считать за недостаток, скорее особенность. Тем более теоретически можно улучшить сборщик до достаточно хороших показателей (да и сейчас он не тот, что был раньше).
- Большой недостаток: В некоторых стандартных API зачем-то обрабатываются пропуски полей в массиве. Это тупо + это просаживает производительность этих API.
- Большой недостаток: Некоторые вещи можно переопределить, которые неплохо бы как-нибудь сделать непеопределяемыми в целях повышения производительности. На память не скажу, что это за вещи, но как минимум это стандартные объекты языка. Хотя, что это в определённых случаях заметно просаживает производительность, я не уверен на 100%
В общем всё из этого — это какие-то мелочи (кроме последних двух). В итоге серьёзных проблем в дизайне Javascript я не назову (хотя раньше они были).
Кстати, Javascript — язык, в котором принято делать всё правильно. Если в других (некоторых) языках считается нормой сделать хрен знает что, то javascript пропагандирует максимальную адекватность. Это касается наименований, ООП, областей видимости, устройств классов, импортов и экспортов и прочего. Кроме того, язык побуждает так делать и самого программиста.
Впрочем, если Вы назовёте неудачные решения, которые я не перечислил (и которые актуальны в данный момент), буду рад. А особенно те из них, которые нельзя пофиксить с сохранением совместимости. Хотя на самом деле всё можно пофиксить с сохранение совместимости, нужно просто добавить специальный модификатор на код.
Ну и сразу на всякий случай отмечу — кто думает, что js медленный или ест много памяти — это неправда. Но браузер да, ест много памяти и иногда медленный, но дело не в js.
Вся эта принудительная асинхронщина — самый большой изъян в JS. По уму, её бы замести под ковёр, чтоб с ней сталкивались только те, кому это реально нужно (а писать синхронный и даже псевдосинхронный код не в пример проще, и выглядит он красивее).
try {
const result = await new Promise(ok => inner(ok));
} catch {
...
}
Стандартный шаблон promisify, что может пойти не так? А вот что. Функция inner может кинуть исключение. Так как на ней самой await не стоит — исключение кидается асинхронно, и блоком try/catch во внешней функции не ловится. Итог — Unhandled promise rejection и досрочное завершение без обработки ошибки.
Поставим внутри
await inner — может, поможет? Нет, потому что тогда мы ждём окончания внутренней функции, а не вызова колбэка.В итоге пришлось переписать внутреннюю функцию таким образом:
const result = await asyncWork();
moreAsyncWork().catch(...) // без await
return result
Что уже выглядит как не очень красивый хак, как по мне.
Если inner выкинет исключение — оно будет завёрнуто в созданный промис, обработано оператором await и управление перейдёт в блок catch.
Если inner «проглотит» ошибку — то вызывающая функция повиснет, но никакого Unhandled promise rejection тоже не случится.
Единственный вариант получить Unhandled promise rejection — использовать промисы внутри inner. Но в таком случае зачем тут вообще колбек?! ЧТо мешает вернуть промис из inner?
Да, проблема именно в том, что функция inner сама асинхронная. Изначально она имела примерно такой вид:
async inner(callback) {
const result = await asyncWork();
callback(result);
await moreAsyncWork();
}Т.е. требовалось передать наружу данные из первого асинхронного процесса и запустить ещё один асинхронный процесс, результат которого здесь уже никого не интересует (этот результат попадёт в БД и будет обработан позже в другом месте). Ждать завершения второго процесса мы не можем, он может оказаться долгим, а вот ждать завершения первого — наоборот, обязаны. Ну и плюс к тому хотелось сохранить это всё одной функцией (потому что логически это единая операция, у которой используется и окончательный результат, и промежуточный) — так-то, конечно, можно было в месте вызова просто сказать const result = await asyncWork(), а moreAsyncWork() вызвать отдельно.
И да, async/await тут вовсе ни при чём, проблема была в самом желании оставить часть работы «на потом», вернув результат прямо сейчас. Такое желание в любом ЯП создаёт проблемы, в том числе и с обработкой ошибок.
const result = await new Promise( (resolve,reject) => inner(resolve).catch(reject) )Автоматически этого не делается, и делать так не совсем правильно. Иногда (как в вашем случае) вы не получите ошибки, если ранее был вызван resolve().
А еще писать нормальный js с зависимостями без бандлеров стало можно едва 2 года назад. И пока нода не поддержит esm мы будем в гениальном комбо из require и import/export явно или через интеропы, что тоже не сглаживает кривую.
А еще, теперь человеку сразу после того, как он понял императивный DOM API, кидают в лицо декларативный VDOM (в 90% случаев, а в оставшихся — монструозный ангуляр), и надо опять идти понимать как строить интерфейсы.
В итоге быстрая эволюция JS это очень круто для тех, кто пришел до ES6 и бабеля, но новичкам во фронте сейчас не позавидуешь.
Я бы сказал, что главный косяк в дизайне — this вне arrow функций.This в js сделан хорошо. Не так, как в других языках, но хорошо. А то, что он может теряться — ну так стрелочные функции никто не отменял. Ну и сохранение в переменную тоже.
А еще писать нормальный js с зависимостями без бандлеровПрограммы на других языках тоже компилируются в один файл, и что? Я бы даже сказал наоборот: в ноде обходятся без компиляции в один файл, т. е. тут даже проще. Да и даже в вебе можно без компиляции, вопрос лишь в производительности.
Это не недостаток языка, это особенности использования. Если взять любой другой язык, и поставить перед ним эти задачи, он не покажет себя лучше, по крайней мере до тех пор, пока мы специально не сделаем что-то для более хорошего решения этих задач.
А еще, теперь человеку сразу после того, как он понял императивный DOM API, кидают в лицо декларативный VDOMЭто к js никакого отношения не имеет.
В итоге быстрая эволюция JS это очень круто для тех, кто пришел до ES6 и бабеля, но новичкам во фронте сейчас не позавидуешь.Вот где новичкам не позавидуешь — это в C++, webgl и т. д. А вот js позволяет начать писать первый код уже практически сразу. В т. ч. и за это я полюбил этот язык. Просто со временем начинаешь достигать профессионального уровня, а вот начать можно сразу. И это плюс.
Не буду сейчас приводить конкретных примеров, чтобы не уйти в полемику. Смысл в том, что в языке появляются новые возможности, которые не сильно отличаются от предыдущих, но при этом вместо замещения они просто соседствуют. Самый наглядный пример – греческий язык, который за 3 тысячи лет натащил в себя со всего Средиземноморья и теперь в нем 3 буквы "и" и при этом никаких правил когда какую использовать нет, нужно просто заучивать.
JS предстоит научиться чистить исторический мусор, но судя по тому что сейчас происходит в TC39, мы просто однажды столкнемся с последствиями.
- Два синтаксиса классов
- Два синтаксиса импортов в вебе и два в ноде
Есть и другие примеры, но во всех них просто принято юзать самый последний синтаксис:
- Промисы/коллбэки — всегда юзаем промисы
- Var/let+const — всегда юзаем let+const
- Let/const — всегда юзаем const по возможности
- Function/=> — всегда юзаем => по возможности
Это как если бы в греческом появилось три «и», и мы бы сказали в новых текстах всегда юзаем «i». Ничего плохого в этом не вижу, естественное развитие языка, новые фичи же тоже надо добавлять.
Самый простой пример из недавнего – исключение в приведении типов. Так можно:
1 + []А так нельзя:
1 + 1nЕсть и другие примеры, но во всех них просто принято юзать самый последний синтаксис
Это никак не отменяет того, что разработчику придется изучить все три let, const и var, оба варианта объявления классов, разные случаи использования Function и => и т.п. При этом изучая каждую новую конструкцию он будет держать в голове, что из нее могут быть исключения, даже, если их нет. Это катастрофически снижает скорость освоения материала.
1 + []Простите, какой человек в здравом уме будет складывать число и массив? На практике таких случаев не встречается в принципе.
А так нельзя 1 + 1nИ правильно, потому что вот число и число вполне могут сложить, и если было бы можно, это привело бы к ошибкам.
Ну конечно встаёт вопрос, зачем вообще тогда разрешили складывать число и не число, но я бы не назвал это каким-то супер-недостатком, т. к. в реальности люди так просто не делают, т. е. это не мешает работе.
Вы цепляетесь за конкретные примеры и игнорируете общую картину, которую они вместе составляют. Просто вернитесь к этому комментраю.
Var/let+const — всегда юзаем let+const
Let/const — всегда юзаем const по возможности
rumkin
Это никак не отменяет того, что разработчику придется изучить все три let, const и var
const и var не нужны. (С)
Один неудачный пример, не является подтверждением ошибочности всей идеи. Это лишь опыт, для поиска оптимального решения.
Например Solidity для Ethereum переваривает поломки обратной совместимости за счет явного указания версии языка в исходном коде программы. Единственное его ограничение в том, что разные версии нельзя использовать в одном проекте. И то, во многом из-за наличия апдейтов безопасности. Но при этом контракты, написанные на первых версиях языка, могут быть собраны и взаимодействуют с контрактами на всех версиях.
Вообще советую провести мысленный эксперимент: создать программу, которая работает бесконечное время, например где-нибудь в далекой-далекой галактике, и периодически получает апдейты на языке, который меняется.
await не работает в .forEach
Вполне себе работает, если пометить функцию как async.
Если же требуется еще и подождать результатов, то есть куча готовых оберток github.com/sindresorhus/promise-fun
для асинхронной обработки элементов массива
Кстати, Javascript — язык, в котором принято делать всё правильно. Если в других (некоторых) языках считается нормой сделать хрен знает что, то javascript пропагандирует максимальную адекватность. Это касается наименований, ООП, областей видимости, устройств классов, импортов и экспортов и прочего. Кроме того, язык побуждает так делать и самого программиста.
Совершенно не понял этот абзац.
Что значит принято делать правильно? Есть только один оптимальный способ, все остальные не оптимальны?
Про наименования тоже непонятно — каким образом сам язык (а не стайлгайд) способствует… не знаю даже чему, единообразной стилистике?
Про наименования тоже непонятно — каким образом сам язык (а не стайлгайд) способствует… не знаю даже чему, единообразной стилистике?Не совсем сам язык, скорее стандартные объекты и API в нём.
Совершенно не понял этот абзац.Ну вот в том же C++ творится какая-то неведомая ***** с именованием функций, областями видимости и прочим. Javascript здесь полная противоположность — в нём фигни вообще нет.
Что значит принято делать правильно?
Не совсем сам язык, скорее стандартные объекты и API в нём
А какие API в js стандартные?
Ну вот в том же C++ творится какая-то неведомая ***** с именованием функций
А можно пример этого неведомого из плюсов? Я пока не понимаю, о чём речь
областями видимости
В общем-то тоже не понимаю, какие там проблемы. Вроде бы всё просто и без загибов. Скобки, или модуль, или неймспейс. Вы про какие именно проблемы?
Javascript здесь полная противоположность — в нём фигни вообще нет
Я как раз думаю что наоборот. Один хойстинг чего стоит. А ещё var можно вспомнить и глобальные переменные.
Раньше были только колбеки со своим хэлом, потом появились промисы, а потом асинк авейты, все круто и замечательно, только в большом проекте вы таки будете использовать все 3 подхода, не смотря на то, что они решают одну и ту же задачу.
Это не увеличение кривой сложности?
Что-то вы путаете. Чем больше разных решений, тем выше сложность освоения. Для примера возьмите Go и сравните его кривую обучения.
Когда к var добавляются let и const, это задирает кривую обучения, потому, что вы не можете пройти мимо этого, а разница в поведении достаточно существенная: var всплывает, let и const – нет, let и const имеют блочную область видимости, var – нет. Различия продолжаются в таких базовых концепциях как объявление функции, создание класса, применение встроенных типов. Нет здесь плавности, о которой вы говорите.
Чем больше разных решений, тем выше сложность освоения.Почему? Вон в перле просто гигантское количество решений, но освоить его не сложно. Сложно поддерживать то, что таким освоившим написано, но именно писать на нем получается просто прекрасно. Мне кажется вам стоит более подробно описать что именно вы понимаете под освоением.
Смысл в том, что в языке появляется много исключений, которые нарушают изначальную логику. И для каждого такого исключения нельзя построить какое-то одно правило, все исключения придется заучивать. Т.е. предсказание поведения на основе полученного опыта становится невозможно. Пример с 1 + 1n уже привел выше.
Я не могу обсуждать Перл, так как не знаком с ним. Я говорил о том, что JS постепенно превращается в два языка в одном. Процесс еще не завершился, но вектор задан и меняться не будет, если судить по TC39/proposals.
Могу сказать, что Go по сравнению со многими языками, которые мне довелось попробовать, более простой и быстрее осваивается (за счет меньшего количества языковых конструкций). Поэтому, вполне вероятно, что в этом плане он выиграет у Перла. Например про Перл я часто слышал, что его легко писать, но тяжело читать.
Но я могу и обобщить: пространство решаемых тьюринг-полными языками задач одинаково, поэтому, если при этом пространства их логических примитивов соразмерны, то остается только синтаксис. И тут выиграет тот, у кого он проще.
научные изыскания также устареваютТеорема Пифагора устаревает?
Всякие естественные и гуманитарные знания вполне устаревают (например геоцентрическая модель мира) или оказываются кривыми(механика Ньютона).
оказываются кривыми(механика Ньютона)Чем эта механика кривая? У нее есть определенные границы применимости, и в этих границах ее успешно применяли, применяют и будут применять. А для квантовых систем — квантовую механику. Одно другому не мешает.
гуманитарные знания вполне устареваютДокументально подтвержденное (многими документами) гуманитарное (историческое) знание, что Бородинская битва произошла в 1812 г. Как это знание может устареть?
- Известно, что ньютоновская механика неверная. В этом плане я имел в виду кривизну — то есть научное знание обычно неполное. И не всегда его неполноту можно терпеть. (Например плоскую землю никто не учитывает, это сильно устаревшая и заброшенная модель. Когда в эту же стадию скатится Ньютонова механика — вопрос времени).
- Ну а в каком-нибудь 5 веке условный Ци Ши Янь описал, как победил условного Жо Ши Меня. И вот, допустим, его табличка, или на чем там писали китайцы в пятом веке, пылится в какой-нибудь библиотеке, и всем на неё наплевать. Общественная значимость любого исторического знания со временем падает. А значит, все меньше и меньше людей к этому знанию стремятся. Вполне устаревание, как по мне.
Известно, что ньютоновская механика неверная.
Как она может быть неверная? Это примерно как сказать, что уравнение состояния идеального газа неверное. Да, идеального газа в природе не существует, но бывают близкие к нему реальные газы, и для них уравнение хорошо работает, приближённо. И оно остаётся верным для теоретического идеального газа. С механикой такое же.
Известно, что ньютоновская механика неверная.Судя по вики никому (кроме Вас) это не известно. Есть ограничения, но это не значит «неверная».
Общественная значимость любого исторического знания со временем падает. А значит, все меньше и меньше людей к этому знанию стремятся.М.б. в 5 веке знание про победу Ци Ши Янь было более востребованным обывателями, потом только специалистами. Но количество спецов возрастает м.б. пропорционально росту населения Земли, т.о. м.б. не меньше. Далеко не все знания нужны всем, а только узким спецам, но это принципиально ничего не меняет. Общественная значимость часто бывает косвенной: так наверное больше 99% людей ничего не знает про технологии получения чистого кремния, но почти 100% пользуются изделиями электроники — продукцией этих технологий.
Я не очень понимаю, что вам не понятно. Идем в гугл, видим что по Эйнштейну сумма скоростей равна не x+y, а (x+y)/(1+xy/cc). Это две разные формулы. Если вы подставите в них одни и те же числа, получите разный результат.
Ну а на Коболе тоже кто-то пишет. И что, Кобол не устарел?
Да, что-то устаревает, но если Кобол устарел, это не значит, что теорема Пифагора устарела.
Так что механику Ньютона из школьной программы уберут нескоро. Это не столько история, сколько несложная и эффективная модель мира.
Известно, что ньютоновская механика неверная.
Ньютоновская механика совершенно верная.
Как уже сказали, она, как и все, имеет область применимости.
Например плоскую землю никто не учитывает, это сильно устаревшаяС точки зрения строителя малоэтажного дома землю совершенно необязательно считать круглой — это ничего не поменяет. Локальный ландшафт внозит на порядки больше чем кривизна земли. Проще забыть что земля круглая и смотреть только на локальные особенности. Прямо так, конечно, никто не думает, но суть примерно такая.
или оказываются кривыми(механика Ньютона)Это с каких пор механика Ньютона стала кривой? :) Отлично работает в известных рамках. Более новая механика ньютоновскую не отменила, но дополнила.
Ну вот в этих рамках и вопрос. То есть модель плоской земли настолько кривая, что ни для каких рассчетов не подходит. А когда-то она была доминирующей и всех устраивала. Логично предположить, что по мере дальнейшего технологического прогресса и ньютоновская механика станет непригодной для большинства применений.
Ну а дополняет или нет — это скорее вопрос в терминологии. Формально, почти любое применение законов Ньютона дает некоторую ненулевую ошибку.
То есть модель плоской земли настолько кривая, что ни для каких рассчетов не подходит. А когда-то она была доминирующей и всех устраивала. Логично предположить, что по мере дальнейшего технологического прогресса и ньютоновская механика станет непригодной для большинства применений.Абсолютно не логично. Классическая механика Ньютона экспериментально подтверждается (в границах применимости), а модель плоской Земли была только гипотезой, и когда ее попробовали экспериментально подтвердить, т.е. дойти до края Земли, оказалось, что у Земли нет края.
То есть модель плоской земли настолько кривая, что ни для каких рассчетов не подходит.Как справедливо отметили выше, эта модель оправдана для многих практических приложений, нпр., в строительстве.
Евклидова геометрия в определенный момент устарела, хотя казалось бы...
Евклидова геометрия в определенный момент устарелаКогда? Я, как и мои коллеги, ее использую постоянно для научных исследований, результаты печатают в ведущих журналах, и ни один рецензент пока не сказал, что Евклидова геометрия устарела ;)
Очевидно, что речь идет про современную физику за пределами случаев когда примнима нюьтоновская физика. Конечно и в мире малых скоростей и больших объектов физикам есть чем заняться. Та же гидродинамика. Но в ОТО и зоне высоких энергий используется неэвклидова геометрия, в которой теорема Пифагора не работает.
Конечно и в мире малых скоростей и больших объектов физикам есть чем заняться. Та же гидродинамика. Но в ОТО и зоне высоких энергий используется неэвклидова геометрия, в которой теорема Пифагора не работает.И почему устарели Ньютон, Евклид и Пифагор? Есть зона высоких энергий и скоростей, но другие зоны не утрачивают актуальность, и подозреваю, что в них задач не меньше, а больше. Конкретных инженерных каждодневных задач. И так будет очень долго, если не всегда. Большинство людей будут продолжать жить в мире Евклида и Ньютона. Современный грамотный физик (речь не о предствителях «альтернативных наук», которые называют себя «физиками») прекрасно знает ОТО, но типовую задачу о 2 пешеходах между пунктами А и Б (расстояние ок. 5 км) он никогда не будет решать в ОТО — смысла нет: разница с классической механикой пренебрежимая и экспериментально не обнаружимая. Скучно это писать — в общеобразовательной средней школе должны были объяснить. А кто пропустил уроки — я дал выше ссылку на вики: там ссылки на авторитетные современные учебники физики, где четко сказано, когда какую модель использовать.
"Устарела" или нет, это просто вопрос формулировок, возможно неудачных. Давайте разговор у физике не превращать в филологию.
А именно её по факту и используют. Просто формулы ОТО на малых скоростях полностью соответствуют тому, что используется со времен Ньютона. Фактически всегда надо начинать с ОТО и только убедившись, что поправка принебрежимо мала, переходить к классике. Яркий пример полет космического корабля к Меркурию. Движение этой планеты не соответствует законам Кеплера из-за близости к Солнцу и без ОТО не обойтись, но отправить корабль, а потом узнать что просчитался как-то не кошерно.
А именно её по факту и используют.Где это сказано? Ссылку на авторитетный источник можете дать? Я говорил о земных задачах с земными расстояниями (нпр., ок. 5 км) и скоростями (нпр., пешеходов), а не про «полет космического корабля к Меркурию».
С такими земными условиями «всегда надо начинать с ОТО и только убедившись, что поправка принебрежимо мала, переходить к классике»?
Абсурд!
Чисто практически: если что-то устарело, то вместо него всегда нужно использовать новое.Какое еще понимание слова «устарела» возможно?
Вот только давайте без передергиваний. Неевклидова геометрия применима в том числе и в играх.
Если люди станут бессмертными, обновление социальной среды станет гораздо дороже обходиться, по аналогии с обновлением ПО, описанном в статье.
Думаю, в сочетании с колонизацией космоса всё должно быть нормально. «Молодые и прогрессивные» улетают строить лунапарк с блекджеком и шлюхами где-то на Марсе или Плутоне (или вообще на автономной космической станции), в то время как старые и довольные стабильностью остаются на месте. Если социальный строй старых будет слишком уступать тому, что построили молодые, то со временем его или вытеснят в результате мирной конкуренции, или… кхм… решат проблему бессмертия бессмертных неприродным путём.
Это и есть дороже.Дороже само по себе не значит плохо. Вы заявили проблему, вам показали что у нее есть естественное решение. Это нормально, что не так то? Ну да, дополнительные ресурсы. Но надо еще посмотреть сколько ресурсов будет получено за счет собственно корня вашей проблемы — бессмертия. Я предполагаю что заметно больше и общий результат по ресурсам будет положительный.
Я думаю, что показанное решение оно слишком упрощенное и не закрывает темы.Конечно нет. Потому что в реальной жизни будут тысячи нюансов. Но ваше описание проблемы также крайне упрощено и ответить на него детальнее не представляется возможным.
И я не очень понимаю где вы тут личное увидели. Я всего лишь искренне удивился что вам не понравилось в решении. Потому что вы никак его не опровергаете, но вас оно очевидно не устроило.
С таким названием идея, что программы должны умирать, не получит поддержки, слишком оно отталкивающее. И плохо отражает суть явления.
Возьмите видеоплеер и откройте современное кино — x265, etc — ничего не работает.
Возьмите старый текстовый редактор и откройте современный текст — вместо улыбающейся какашки там будут просто какашки.
etc, etc.
Старый софт, кажется что, работает как работал, а на самом деле «гниёт» относительно современных стандартов (и входных данных).
Старый софт, кажется что, работает как работал, а на самом деле «гниёт» относительно современных стандартов (и входных данных).Ну это логично. Если софт не обновляются, то его съедят конкуренты. Нужно быть в ногу со временем, чтобы быть на высоте, или даже опережать время.
кажется что, работает как работалНу так он и работает, как работал, просто у Вас появляются новые хотелки. Хочу, к примеру, чтобы открывал H.265.
Старый софт, кажется что, работает как работал, а на самом деле «гниёт» относительно современных стандартовКроме стандартов есть традиции и приемы мастерства, которые почти не меняются. Нпр., не очень давно написал про очень старый софт, содержащий забытую, но полезную для сегодня идею. И софт, который был написан под CPU 286 прекрасно заработал на Intel Core i7, когда мне нужно было делать картинки к статье. Если бы мне нужно было учить школьников информатике (классическим алгоритмам) — взял бы сейчас этот старый софт.
Я пытался найти случаи, которые опровергают гниение ПО, но их, похоже, не существует.
А я думаю существуют — это Tcl/Tk. Я спустя 20 лет вернулся к нему и понял как я много потерял, отодвинув его в сторону.
Какие есть большие проекты на тикле
Навскидку дефолтный Git GUI.
Вот что публиковал habr:
Использование TCL в разработке на FPGA
Использование скриптов TCL для управления проектами Quartus II
Webshell на TCL, для Cisco IOS и не только
А сообще-то сетевики знают, что без Tcl сети трудно представить.
А чего стоит expect
А сколько всего написано и пишется наTk
Питон, пхп, жаваскрипт, гоу — в смысле огромных, не пойми как написанных когда-то, разлагающихся несметных пластов безысходников — это то, что мы заслужили.
Write once, suffer eternally
Да, давайте весь код с Python на Erlang перепишем. А CPython перепишем с C на Rust, и ядро Линукса тоже перепишем на Rust заодно.
Ну, питон уже переписывают на раст (RustPython) =)
В русском языке в научно-популярной терминологии термин «гниение», «гнить» имеет единственную устойчивую ассоциацию с биологическим процессом гниения.
Термин «rot», «rotten» в данном контексте должен переводиться не как «гнить», а как «протухать» или «портиться». Также м.б. «разлагаться», «деградировать». Термин rot может переводиться как «загнивать» но в приложении к обществу, партии, и проч. группам.
в чём причина гнили программного обеспечения?
программное обеспечение гниёт!
Не гнили, а порчи.
Не гниет, а портится.
© «Волны перекатывались через мол и падали вниз стремительным домкратом»
Почти десять лет спустя Mozilla, наконец, выпустила мультипроцессный Firefox на массовую аудиторию. Эта задержка произошла вовсе не от недостатка желания. У Mozilla талантливые и целеустремленные разработчики. Тем не менее, Chrome был написан с нуля за гораздо меньшее время, чем потребовалось Firefox для изменения.Эм, так то мозила целый новый язык под многопроцессорность запилила, после чего по сути переписала части своего движка с нуля. В то же время хром как был на C++ так и остался, плюс у гугла больше ресурсов.
Вы путаете Electrolysis с Quantum CSS.
Тут речь идёт именно об изоляции табов в процессы, что действительно шло долго и плохо
А вот параллелизация обсчета CSS в отдельные потоки в одном процессе — которую сделали на Rust — она довольно бодро прошла. Кстати, это третья попытка, две предыдущие были на C++ и провалились.
Как и аналогичные попытки Хрома.
Тем не менее, Chrome был написан с нуля за гораздо меньшее время, чем потребовалось Firefox для изменения.
Все-таки не с нуля
Как правило, грамотная адаптация программного обеспечения к новым условиям занимает больше времени и усилий, чем написание нового программного обеспечения с нуля. Программисты не любят признавать это, но доказательства очевидны
Я не знаю каких про каких программистов идет речь, но
грамотная адаптация программного обеспечения к новым условиям
в переводе на язык «программистов» обозначает поддержка легаси кода. И звучит это как приговор.
чем написание нового программного обеспечения с нуля
А вот возможность переписать все «правильно, с нуля» — рай для разработчика. Вот только со стороны «заказчика» выглядит не очень (и заказчика тут тоже можно понять)
Правильнее было бы назвать назвать статью Проблемы деградации в bloatware ПО с плохой архитектурой и при использовании неверных подходов к разработке ПО.
Из песни слов не выкинешь:
Пожалуй, трудно найти две более разные культуры программирования, чем те, что образовались вокруг этих двух языков и используют их в качестве единой валюты. Паскаль служит для построения пирамид — впечатляющих, захватывающих статических структур, создаваемых армиями, которые укладывают на места тяжелые плиты. При помощи Лиспа порождаются организмы — впечатляющие, захватывающие динамические структуры, создаваемые командами, которые собирают их из мерцающих мириад более простых организмов. Организующие принципы в обоих случаях остаются одни и те же, за одним существенным исключением: программист, пишущий на Лиспе, располагает на порядок большей творческой свободой в том, что касается функций, которые он создает для использования другими. Программы на Лиспе населяют библиотеки функциями, которые оказываются настолько полезными, что они переживают породившие их приложения. Таким ростом полезности мы во многом обязаны списку — исконной лисповской структуре данных.
Простота структуры списков и естественность их использования отражаются в удивительной общности функций. В Паскале обилие объявляемых структур данных ведет к
специализации функций, которая сдерживает и наказывает случайное взаимодействие
между ними. Лучше иметь 100 функций, которые работают с одной структурой данных, чем 10 функций, работающих с 10 структурами. В результате пирамиде приходится
неподвижно стоять тысячелетиями; организм же будет развиваться или погибнет.
Но есть и другой аспект этой темы. Раздутое Bloatware — обречено на «гниение». В противоположность — программы из арсенала suckless.org — бодры, подтянуты и «вечно молоды», согласно своей природе. Они просты, эффективно решают каждая свою задачу, и главное — отлично работают вместе. Если какая-то из них устаревает или не подходит, она может быть легко заменена на альтернативную, оставив саму инфраструктуру целостной, что будет продолжаться, пока всё это приносит пользу. Сей принцип, конечно имеет прямое отношение к философии UNIX, и… этот подход являет собой полную противоположность первому примеру — EMACS!
В этой дуальности я нахожу загадочный парадокс по-настоящему долговечных систем.
Электромагнитная эпоха
Сами вы электромагнитный. В названии "Age of Em" последнее слово — сокращение от emulated. И "Overcoming bias" — это название блога Хэнсона, а не часть заголовка статьи.
Я пытался найти случаи, которые опровергают гниение ПО, но их, похоже, не существует.
Batch processing DOS за многие годы не сильно изменился, аналогично shell script я в спец. ОС использую.
Деградация программного обеспечения