Программное обеспечение изначально было разработано для одного набора задач, инструментов и ситуаций. Но оно медленно изменяется, чтобы справиться с постоянным потоком новых задач, инструментов и ситуаций. Такой софт становится более сложным, хрупким, в него труднее вносить полезные изменения (Леман и Биледи, 1985)1. В конце концов, лучше начать всё сначала и написать с нуля новые подсистемы, а иногда и полностью новые системы.
Я уверен, что это правда. Как правило, грамотная адаптация программного обеспечения к новым условиям занимает больше времени и усилий, чем написание нового программного обеспечения с нуля. Программисты не любят признавать это, но доказательства очевидны. В проектах open source есть несколько известных примеров.
Многопроцессный Firefox
Изначально Mozilla Firefox запускал все задачи в одном процессе. После выхода Google Chrome стало ясно, что модель с несколькими процессами повышает безопасность и производительность. Вскоре разработчики Mozilla начали планировать, как реализовать в Firefox многопроцессность. Это было в 2007 году.
Почти десять лет спустя Mozilla, наконец, выпустила мультипроцессный Firefox на массовую аудиторию. Эта задержка произошла вовсе не от недостатка желания. У Mozilla талантливые и целеустремленные разработчики. Тем не менее, Chrome был написан с нуля за гораздо меньшее время, чем потребовалось Firefox для изменения. У этого две основные причины:
- Переделка однопроцессной архитектуры в многопроцессную предполагает множество мелких изменений. Некоторые вызовы функций нужно заменить межпроцессными коммуникациями. Общее состояние нужно обернуть в мьютексы. Кэши и локальные БД должны поддерживать параллельный доступ.
- Firefox должен сохранить совместимость с существующими расширениями (или заставить разработчиков их обновить). Chrome создавал API для расширений с нуля, не имея таких ограничений.
Но ситуация ещё хуже. Ограничения противоречат друг другу: нужно перестроить внутреннюю архитектуру, но оставить почти без изменений общедоступные API. Неудивительно, что Mozilla понадобилось десять лет на такой подвиг.
Событийно-ориентированный Apache
Изначально Apache httpd работал по модели «один процесс на соединение». Один процесс прослушивал порт 80, затем делал
accept() и fork(). Дочерний процесс потом выполнял read() и write() на сокете. Когда запрос завершён, дочерний процесс закрывал сокет close() и выполнял exit().Такая архитектура простая, лёгкая в реализации на многих платформах и… всё. Она абсолютно ужасна для производительности, особенно при обработке долгоживущих соединений. Справедливости ради: это был 1995 год. И вскоре Apache перешёл на потоковую модель, которая улучшила производительность. Тем не менее, он не мог обрабатывать 10 000 одновременных соединений. Архитектура «один поток на соединение» требует 1000 потоков для обслуживания 1000 одновременных подключений. У каждого потока собственный стек и состояние, его должен запланировать и запустить шедулер операционной системы. Это отнимает время.
Напротив, Nginx с самого начала использовал шаблон реактора. Это позволило обрабатывать больше одновременных соединений и сделало его невосприимчивым к атакам Slowloris.
Nginx вышел в 2007 году, и его преимущество в производительности было очевидным. За несколько лет до выхода Nginx разработчики Apache начали перепроектировать httpd для улучшения производительности. Многопроцессный модуль event вышел с Apache 2.2 в 2005 году. Но обнаружились проблемы совместимости. Хуже всего, что он сломал совместимость с популярными модулями, такими как mod_php. Проблему не могли исправить до 2012 года, когда Apache 2.4 вышел с этим модулем (MPM) по умолчанию. Хотя он работал гораздо лучше, чем предыдущий prefork и MPM-воркер, но так и не смог сравняться по производительности с Nginx. Вместо шаблона реактора Apache использовал отдельные пулы потоков для прослушивания/приёма соединений и обработки запросов. Архитектура примерно эквивалентна запуску балансировщика нагрузки или обратного прокси перед воркером MPM httpd2.
CPython GIL
Python — хороший язык программирования. Он выразителен, прост в освоении (по крайней мере, для языка программирования) и поддерживается на разных платформах. Но в течение последних двух десятилетий у самой популярной реализации Python была серьёзная проблема: она не могла легко воспользоваться преимуществами нескольких процессорных ядер.
Причина в глобальной блокировке интерпретатора или GIL. Из питоновского вики:
В CPython глобальная блокировка интерпретатора — это мьютекс, который блокирует одновременное выполнение нескольких потоков кода. Такая блокировка необходима главным образом потому, что управление памятью CPython не является потокобезопасным. (Но поскольку GIL существует, другие функции стали зависеть от него).
Первоначально GIL не представлял особой проблемы. При создании Python многоядерные системы встречались редко. А GIL было легко написать и это простая, логичная система. Но сегодня многоядерные процессоры работают даже в наручных часах. GIL — очевидный и вопиющий дефект во всех отношениях приятного языка. Несмотря на популярность CPython, несмотря на талантливых разработчиков, несмотря на спонсоров, таких как Google, Microsoft и Intel, исправлять GIL даже не планируется.
Заключение
Даже при наличии талантливых инженеров, большого количества денег и чёткого плана зрелое программное обеспечение чрезвычайно трудно изменить. Я пытался найти случаи, которые опровергают деградацию ПО, но их, похоже, не существует. Робин Хэнсон попросил привести контрпримеры, но никто не предложил ничего убедительного. Есть много старых программных проектов, но им не пришлось особо адаптироваться. Я реально хочу найти хорошие контрпримеры, потому что без них создаётся слишком мрачная картина перспектив программного обеспечения.
Дополнительные материалы
- Преодоление предвзятости: в чём причина деградации программного обеспечения?
- Сюрприз: программное обеспечение деградирует!
- Википедия: деградация программного обеспечения
1. Цитата из статьи «Эволюция программ: процессы изменения программного обеспечения». Работа старше меня, и я не могу найти онлайн-версию. Я купил физическую копию и с трудом осилил её. Терминология странная, но выводы не слишком удивительны. ^
2. Любой, кто знает устройство httpd, возразит против такого сравнения, но здесь мы жертвуем точностью ради краткости. Прошу прощения за это. ^
Комментарии (143)
zuborg
28.02.2019 14:31Ядро Линукс, думаю, вполне подходит в качестве контрпримера. Актуальные вещи успешно эволюционируют и переписываются, некоторые и не по одному разу (неоднократная замена реализации файрвола, например)
SirEdvin
28.02.2019 15:06Ядро Линукс, думаю, вполне подходит в качестве контрпримера. Актуальные вещи успешно эволюционируют и переписываются, некоторые и не по одному разу (неоднократная замена реализации файрвола, например)
Ну, если я не ошибаюсь, там уже третий вариант реализации, хотя большинство серверов пока еще используют самую первую. Так что такой себе пример.
sena
28.02.2019 14:40+1Такую же статью можно написать про языки программирования. Когда цепи совместимости не дают двигаться вперёд и язык потихоньку умирает, либо сначала превращается в монстра и тоже умирает.
nikbond
28.02.2019 15:31С++ тащит за собой много всякого, обрастает новыми фичами и пока что умирать не собирается.
rumkin
28.02.2019 17:03Pascal тоже еще жив, но это не говорит о том, что он конкурентоспособен.
Groramar
28.02.2019 23:24+3Pascal, в реализации Delphi к счастью, был очень хорошо спроектирован. Настолько, что не имеет фатальных недостатков как тот же Питон. И отлично работает до сих пор. История ещё не закончилась, посмотрим как дальше пойдёт.
Alexey2005
28.02.2019 17:25+1Проблема в том, что обрастает не с той стороны.
В лагере плюсовиков похоже так до сих пор и не поняли, что в современном мире популярность языка определяется не синтаксическим сахаром, а лёгкостью разворачивания/сборки проектов, подгрузки библиотек/модулей, а также интеграцией с IDE. По всем этим пунктам у C++ застой, зато постоянно вводят очередные навороченные конструкции, которыми пользоваться будут полтора кодера.
KanuTaH
28.02.2019 22:59Пихать такие вещи, как сборка проектов и их разворачивание, в ЯЗЫК — это довольно странно. Обычно для этого все-таки используются такие вещи, как фреймворки и системы сборки, зачастую к тому же поддерживающие несколько языков сразу. ЯП — он все-таки несколько про другое. С «подключением» (не подгрузкой) библиотек/модулей — да, можно отчасти согласиться в том плане, что до сих пор по историческим причинам, как правило, используются заголовочные файлы, что не очень удобно, так как их приходится фактически каждый раз заново обрабатывать в каждом файле, в который они включаются. Но есть и в этом плане подвижки, в C++17 предлагали включить модули:
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»).MechanicZelenyy
01.03.2019 00:17+1Пихать такие вещи, как сборка проектов и их разворачивание, в ЯЗЫК — это довольно странно.
Для 60ых годов, когда единственное требование к языку было возможность упихать его на перфокарту — да.
Сейчас, когда сделать свой язык может даже начинающий, хороший ЯП это не что больше чем файлы с текстом, это экосистема, причем киллер-фичи определяет именно она.KanuTaH
01.03.2019 00:23Как по мне, фреймворк, в котором несколько зрелых и устоявшихся языков могут, скажем так, бесшовно интегрироваться в единое приложение (причем каждый может быть использован для своей цели в соответствии со своими плюсами), который обеспечивает для них единую систему сборки, единый IDE и единую библиотеку модулей — это куда лучшее решение, чем очередной сляпанный на коленке недоязычок ad hoc, для которого нет ничего, который не может воспользоваться никакими уже существующими наработками без их тотального переписывания «на себе» (естественно, с внесением новых ошибок в процессе этого дела, а как же) и так далее.
kekekeks
01.03.2019 12:01Вы сейчас описали связку CLR, MSBuild и Visual Studio. Обеспечивают интероп и единую систему сборки между C++/C#/VB/F#/IronPython/IronRuby/Nemerle. Вменяемый бесшовный интероп C++ с CLI, правда, Windows-only, но это скорее связано с непортабельностью MSVC++ и с некоторым зоопарком компиляторов на других платформах.
KanuTaH
01.03.2019 12:05Да, именно на нее в данном конкретном случае я и намекал. В принципе, это и по треду в целом должно быть понятно :)
mayorovp
01.03.2019 09:45С одной стороны, вы правы — язык не про сборку пакетов. С другой — в экосистеме C++ удобных систем пакетов и сборки так и не появилось.
f1inx
01.03.2019 02:19В каком месте у C или C++ описанные вами проблемы? Вы случайно не путаете проблемы OS, совместимости с конкретной OS и архитектурой с проблемами языка?
vladkorotnev
01.03.2019 04:42Это скорее проблемы не языка, а инфраструктуры вокруг языка.
Одно дело когда написал в условном package.json список желаемых библиотек и передёрнул менеджер пакетов, другое — когда у тебя autoconf генерирует cmakefile чтобы cmake потом сделал тебе configure и собрал Makefile из 800-2500 строк чтобы собрать один консольный плеер для музыки.
Поэтому стараюсь как-то подальше держаться от всех этих автоконфигураторов, если проект нельзя собрать одним мейкфайлом — значит сложность уже пересекла все разумные пределы и стоит подумать, как это разрастание пресечь, имхо :-)
rumkin
28.02.2019 17:02Тот же JS, обрастает новыми фичами и разными концепциями, сохраняя все предыдущие неудачные решения. Однажды это выльется в то, что кривая обучения JS превратится в вертикаль.
vitaliy2
28.02.2019 18:55+2Какие именно неудачные решения? Могу попытаться повспоминать:
- typeof null — бред, но терпимо.
- Сложное приведение типов. Терпимо, т.?к. обычно ты не смешиваешь типы. Например, никакой человек в здравом уме не станет сравнивать строку и объект. При этом из названия переменной всегда видно, где есть что, поэтому опечататься тоже сложно.
- Отсутствие типов. Не считается, т.?к. никто не мешает в будущем добавить типы с сохранением обратной совместимости. Мы ведь говорили о штуках, которые препятствуют развитию языка, которые нельзя исправить с сохранением совместимости.
- Всякий бред, который пофикшен с use strict.
- Отсутствие 64-битных чисел. Вот это обидно, да. Хотя в будущем можно пофиксить. Впрочем, уже сейчас можно использовать BigInt, который в будущем может быть оптимизирован при хранении 64-битных чисел с ограничением до 64 бит.
- Отсутствие настоящих приватных полей класса. Не то, чтобы сильно критично (т.?к. есть соглашение по приватности) + они уже запланированы в ближайшее время, правда, к сожалению, только с синтаксисом class xxx { … }.
- Сборщик мусора и соответствующие проблемы. Нельзя считать за недостаток, скорее особенность. Тем более теоретически можно улучшить сборщик до достаточно хороших показателей (да и сейчас он не тот, что был раньше).
- Большой недостаток: В некоторых стандартных API зачем-то обрабатываются пропуски полей в массиве. Это тупо + это просаживает производительность этих API.
- Большой недостаток: Некоторые вещи можно переопределить, которые неплохо бы как-нибудь сделать непеопределяемыми в целях повышения производительности. На память не скажу, что это за вещи, но как минимум это стандартные объекты языка. Хотя, что это в определённых случаях заметно просаживает производительность, я не уверен на 100%
В общем всё из этого — это какие-то мелочи (кроме последних двух). В итоге серьёзных проблем в дизайне Javascript я не назову (хотя раньше они были).
Кстати, Javascript — язык, в котором принято делать всё правильно. Если в других (некоторых) языках считается нормой сделать хрен знает что, то javascript пропагандирует максимальную адекватность. Это касается наименований, ООП, областей видимости, устройств классов, импортов и экспортов и прочего. Кроме того, язык побуждает так делать и самого программиста.
Впрочем, если Вы назовёте неудачные решения, которые я не перечислил (и которые актуальны в данный момент), буду рад. А особенно те из них, которые нельзя пофиксить с сохранением совместимости. Хотя на самом деле всё можно пофиксить с сохранение совместимости, нужно просто добавить специальный модификатор на код.
Ну и сразу на всякий случай отмечу — кто думает, что js медленный или ест много памяти — это неправда. Но браузер да, ест много памяти и иногда медленный, но дело не в js.Alexey2005
28.02.2019 19:28Первое, обо что спотыкается новичок при изучении js — это промисы. Слшком уж абстрактная концепция. По моим наблюдениям, новичкам понять что это такое и научиться уверенно им оперировать, даже сложнее, чем переварить понятие указателя на указатель при изучении C++.
Вся эта принудительная асинхронщина — самый большой изъян в JS. По уму, её бы замести под ковёр, чтоб с ней сталкивались только те, кому это реально нужно (а писать синхронный и даже псевдосинхронный код не в пример проще, и выглядит он красивее).
defaultvoice
28.02.2019 23:01+1Ну вот не знаю, что в промисах такого сложного. Цепочку Promise -> then -> then освоить вполне несложно, а с async/await всё становится совсем уж простым, аж до безобразия. Дальше с Promise.all, отменой и прочими штуками уже сложнее, но вопросы обычно начинаются раньше.
Главная проблема новичков в JS это то, что они даже MDN ленятся почитать (волею случая модерирую js-чатик в телеграме и могу сказать, что львиная доля вопросов от новичков как раз из этой серии).Cerberuser
01.03.2019 05:08+1async/await любит подсовывать гадости там, где их, на первый взгляд, быть не должно. Пример из практики: есть функция inner, которая асинхронно выполняет операцию, дёргает колбэк и асинхронно выполняет следующую операцию. Нужно в другой асинхронной функции получить результат, проброшенный в колбэк. Кажется, это должно быть просто?
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
Что уже выглядит как не очень красивый хак, как по мне.mayorovp
01.03.2019 09:55Погодите, откуда у вас в такой схеме возьмется Unhandled promise rejection?
Если inner выкинет исключение — оно будет завёрнуто в созданный промис, обработано оператором await и управление перейдёт в блок catch.
Если inner «проглотит» ошибку — то вызывающая функция повиснет, но никакого Unhandled promise rejection тоже не случится.
Единственный вариант получить Unhandled promise rejection — использовать промисы внутри inner. Но в таком случае зачем тут вообще колбек?! ЧТо мешает вернуть промис из inner?Cerberuser
01.03.2019 10:38Да, проблема именно в том, что функция inner сама асинхронная. Изначально она имела примерно такой вид:
async inner(callback) { const result = await asyncWork(); callback(result); await moreAsyncWork(); }
Т.е. требовалось передать наружу данные из первого асинхронного процесса и запустить ещё один асинхронный процесс, результат которого здесь уже никого не интересует (этот результат попадёт в БД и будет обработан позже в другом месте). Ждать завершения второго процесса мы не можем, он может оказаться долгим, а вот ждать завершения первого — наоборот, обязаны. Ну и плюс к тому хотелось сохранить это всё одной функцией (потому что логически это единая операция, у которой используется и окончательный результат, и промежуточный) — так-то, конечно, можно было в месте вызова просто сказать
const result = await asyncWork(), аmoreAsyncWork()вызвать отдельно.mayorovp
01.03.2019 10:50Ну вы её в итоге переписали правильно, только надо было писать её таким образом с самого начала.
И да, async/await тут вовсе ни при чём, проблема была в самом желании оставить часть работы «на потом», вернув результат прямо сейчас. Такое желание в любом ЯП создаёт проблемы, в том числе и с обработкой ошибок.dimm_ddr
01.03.2019 15:11Но ведь достаточно логичное желание. И для него можно придумать массу случаев когда это разумно. Если язык не дает сделать что-то логичное и рациональное, то это недостаток языка. Даже если таким образом предотвращаются большие проблемы.
1x1
01.03.2019 15:13Если вы вызываете асинхронную функцию без await, то получаете промис, на который вам необходимо повесить обработчик ошибок:
const result = await new Promise( (resolve,reject) => inner(resolve).catch(reject) )
Автоматически этого не делается, и делать так не совсем правильно. Иногда (как в вашем случае) вы не получите ошибки, если ранее был вызван resolve().Cerberuser
01.03.2019 16:16Да, спасибо, такой вариант я упустил. Так-то у нас вся цепочка функций асинхронная, и ошибки по большей части ловятся на внешнем уровне, но здесь это без Вашего уточнения по понятным причинам не прокатывало.
KanuTaH
28.02.2019 23:34+2Знаете, программировать вообще сложно, и тут ничего не поделать. Любые абстракции, которые создаются для «упрощения» этого процесса, имеют свойство рано или поздно протекать. Асинхронность в JS и так прошла довольно долгий путь от обычных коллбеков через промисы до async/await, где стала выглядеть практически как «псевдосинхронный код». А замести асинхронность под ковер в однопоточном языке, который, будучи рассчитан преимущественно на фронтенд-применение, вынужден постоянно взаимодействовать как с GUI, так и с сетью, и при этом обязан обеспечивать достаточную отзывчивость с точки зрения пользователя, не так-то просто. Чем быстрее новичок поймет все это, тем быстрее он перестанет быть новичком. Ему же лучше.
Kuorell
28.02.2019 23:36+1Я бы сказал, что главный косяк в дизайне — this вне arrow функций.
А еще писать нормальный js с зависимостями без бандлеров стало можно едва 2 года назад. И пока нода не поддержит esm мы будем в гениальном комбо из require и import/export явно или через интеропы, что тоже не сглаживает кривую.
А еще, теперь человеку сразу после того, как он понял императивный DOM API, кидают в лицо декларативный VDOM (в 90% случаев, а в оставшихся — монструозный ангуляр), и надо опять идти понимать как строить интерфейсы.
В итоге быстрая эволюция JS это очень круто для тех, кто пришел до ES6 и бабеля, но новичкам во фронте сейчас не позавидуешь.vitaliy2
01.03.2019 14:56Я бы сказал, что главный косяк в дизайне — this вне arrow функций.
This в js сделан хорошо. Не так, как в других языках, но хорошо. А то, что он может теряться — ну так стрелочные функции никто не отменял. Ну и сохранение в переменную тоже.
А еще писать нормальный js с зависимостями без бандлеров
Программы на других языках тоже компилируются в один файл, и что? Я бы даже сказал наоборот: в ноде обходятся без компиляции в один файл, т.?е. тут даже проще. Да и даже в вебе можно без компиляции, вопрос лишь в производительности.
Это не недостаток языка, это особенности использования. Если взять любой другой язык, и поставить перед ним эти задачи, он не покажет себя лучше, по крайней мере до тех пор, пока мы специально не сделаем что-то для более хорошего решения этих задач.
А еще, теперь человеку сразу после того, как он понял императивный DOM API, кидают в лицо декларативный VDOM
Это к js никакого отношения не имеет.
В итоге быстрая эволюция JS это очень круто для тех, кто пришел до ES6 и бабеля, но новичкам во фронте сейчас не позавидуешь.
Вот где новичкам не позавидуешь — это в C++, webgl и т.?д. А вот js позволяет начать писать первый код уже практически сразу. В т.?ч. и за это я полюбил этот язык. Просто со временем начинаешь достигать профессионального уровня, а вот начать можно сразу. И это плюс.
rumkin
01.03.2019 13:03Не буду сейчас приводить конкретных примеров, чтобы не уйти в полемику. Смысл в том, что в языке появляются новые возможности, которые не сильно отличаются от предыдущих, но при этом вместо замещения они просто соседствуют. Самый наглядный пример – греческий язык, который за 3 тысячи лет натащил в себя со всего Средиземноморья и теперь в нем 3 буквы "и" и при этом никаких правил когда какую использовать нет, нужно просто заучивать.
JS предстоит научиться чистить исторический мусор, но судя по тому что сейчас происходит в TC39, мы просто однажды столкнемся с последствиями.
vitaliy2
01.03.2019 15:03Я на память назову только несколько примеров:
- Два синтаксиса классов
- Два синтаксиса импортов в вебе и два в ноде
Есть и другие примеры, но во всех них просто принято юзать самый последний синтаксис:
- Промисы/коллбэки — всегда юзаем промисы
- Var/let+const — всегда юзаем let+const
- Let/const — всегда юзаем const по возможности
- Function/=> — всегда юзаем => по возможности
Это как если бы в греческом появилось три «и», и мы бы сказали в новых текстах всегда юзаем «i». Ничего плохого в этом не вижу, естественное развитие языка, новые фичи же тоже надо добавлять.rumkin
01.03.2019 16:44Самый простой пример из недавнего – исключение в приведении типов. Так можно:
1 + []
А так нельзя:
1 + 1n
Есть и другие примеры, но во всех них просто принято юзать самый последний синтаксис
Это никак не отменяет того, что разработчику придется изучить все три let, const и var, оба варианта объявления классов, разные случаи использования Function и => и т.п. При этом изучая каждую новую конструкцию он будет держать в голове, что из нее могут быть исключения, даже, если их нет. Это катастрофически снижает скорость освоения материала.
vitaliy2
01.03.2019 17:02-11 + []
Простите, какой человек в здравом уме будет складывать число и массив? На практике таких случаев не встречается в принципе.
А так нельзя 1 + 1n
И правильно, потому что вот число и число вполне могут сложить, и если было бы можно, это привело бы к ошибкам.
Ну конечно встаёт вопрос, зачем вообще тогда разрешили складывать число и не число, но я бы не назвал это каким-то супер-недостатком, т.?к. в реальности люди так просто не делают, т.?е. это не мешает работе.rumkin
01.03.2019 17:46Вы цепляетесь за конкретные примеры и игнорируете общую картину, которую они вместе составляют. Просто вернитесь к этому комментраю.
taujavarob
01.03.2019 20:57Var/let+const — всегда юзаем let+const
Let/const — всегда юзаем const по возможности
rumkinЭто никак не отменяет того, что разработчику придется изучить все три let, const и var
const и var не нужны. (С)rumkin
01.03.2019 21:00Это никак не отменяет того, что разработчику придется изучить все три let, const и var
taujavarob
03.03.2019 03:10придется изучить все три let, const и var
Не придётся.
var забыть вообще.
const забыть как недоразумение.
всюду ставить (заменять на ) let
dimm_ddr
01.03.2019 15:14Что получается если чистить исторический мусор можно посмотреть на примере python 2 vs 3. Я могу понять почему разработчикам JS не очень хочется идти по этому пути.
rumkin
01.03.2019 16:49Один неудачный пример, не является подтверждением ошибочности всей идеи. Это лишь опыт, для поиска оптимального решения.
dimm_ddr
01.03.2019 21:48Ну других примеров подобного масштаба у меня нет. Я подозреваю что в том числе потому что есть этот и никто не рискует получить схожий результат. Хотя был еще Windows Phone, по слухам там тоже с каждой версией ломалась обратная совместимость. Теоретически это тоже может быть примером неудачной сборки исторического мусора, но тут очень спорно, так как детали мне неизвестны совсем, а вся суть в них.
rumkin
01.03.2019 22:20Например Solidity для Ethereum переваривает поломки обратной совместимости за счет явного указания версии языка в исходном коде программы. Единственное его ограничение в том, что разные версии нельзя использовать в одном проекте. И то, во многом из-за наличия апдейтов безопасности. Но при этом контракты, написанные на первых версиях языка, могут быть собраны и взаимодействуют с контрактами на всех версиях.
Вообще советую провести мысленный эксперимент: создать программу, которая работает бесконечное время, например где-нибудь в далекой-далекой галактике, и периодически получает апдейты на языке, который меняется.
alec_kalinin
01.03.2019 16:27Ох… Много странного в JavaScript. Например, await не работает в .forEach. И таких мест, где разные концепции пересекаются со странными side эффектам, слишком много.
Taraflex
01.03.2019 22:43await не работает в .forEach
Вполне себе работает, если пометить функцию как async.
Если же требуется еще и подождать результатов, то есть куча готовых оберток github.com/sindresorhus/promise-fun
для асинхронной обработки элементов массива
murzilka
01.03.2019 16:41+1Кстати, Javascript — язык, в котором принято делать всё правильно. Если в других (некоторых) языках считается нормой сделать хрен знает что, то javascript пропагандирует максимальную адекватность. Это касается наименований, ООП, областей видимости, устройств классов, импортов и экспортов и прочего. Кроме того, язык побуждает так делать и самого программиста.
Совершенно не понял этот абзац.
Что значит принято делать правильно? Есть только один оптимальный способ, все остальные не оптимальны?
Про наименования тоже непонятно — каким образом сам язык (а не стайлгайд) способствует… не знаю даже чему, единообразной стилистике?vitaliy2
01.03.2019 17:05Про наименования тоже непонятно — каким образом сам язык (а не стайлгайд) способствует… не знаю даже чему, единообразной стилистике?
Не совсем сам язык, скорее стандартные объекты и API в нём.
Совершенно не понял этот абзац.
Ну вот в том же C++ творится какая-то неведомая ***** с именованием функций, областями видимости и прочим. Javascript здесь полная противоположность — в нём фигни вообще нет.
Что значит принято делать правильно?murzilka
01.03.2019 18:12+1Не совсем сам язык, скорее стандартные объекты и API в нём
А какие API в js стандартные?
Ну вот в том же C++ творится какая-то неведомая ***** с именованием функций
А можно пример этого неведомого из плюсов? Я пока не понимаю, о чём речь
областями видимости
В общем-то тоже не понимаю, какие там проблемы. Вроде бы всё просто и без загибов. Скобки, или модуль, или неймспейс. Вы про какие именно проблемы?
Javascript здесь полная противоположность — в нём фигни вообще нет
Я как раз думаю что наоборот. Один хойстинг чего стоит. А ещё var можно вспомнить и глобальные переменные.
sumanai
01.03.2019 19:56Кстати, Javascript — язык, в котором принято делать всё правильно.
Ой поспорил бы. Сколько жуткого кода на JS видел, да и чего скрывать, сам писал вещи, за которые сейчас стыдно.
Grox
28.02.2019 19:07Наоборот. Именно поддержка всех решений позволяет держать эту кривую в тех рамках, которые удобны вам. И не делает бесполезными все созданные учебники.
index0h
01.03.2019 00:30Раньше были только колбеки со своим хэлом, потом появились промисы, а потом асинк авейты, все круто и замечательно, только в большом проекте вы таки будете использовать все 3 подхода, не смотря на то, что они решают одну и ту же задачу.
Это не увеличение кривой сложности?
rumkin
01.03.2019 13:09Что-то вы путаете. Чем больше разных решений, тем выше сложность освоения. Для примера возьмите Go и сравните его кривую обучения.
Grox
01.03.2019 13:20+1Выше сложность в целом значит, что кривая обучения заканчивается выше. Но не значит, что она круто идёт вверх. Т.е. вход в язык достаточно плавный и можно двигаться по кривой повышая свой уровень более многогранно.
rumkin
01.03.2019 17:33-1Когда к var добавляются let и const, это задирает кривую обучения, потому, что вы не можете пройти мимо этого, а разница в поведении достаточно существенная: var всплывает, let и const – нет, let и const имеют блочную область видимости, var – нет. Различия продолжаются в таких базовых концепциях как объявление функции, создание класса, применение встроенных типов. Нет здесь плавности, о которой вы говорите.
dimm_ddr
01.03.2019 15:17Чем больше разных решений, тем выше сложность освоения.
Почему? Вон в перле просто гигантское количество решений, но освоить его не сложно. Сложно поддерживать то, что таким освоившим написано, но именно писать на нем получается просто прекрасно. Мне кажется вам стоит более подробно описать что именно вы понимаете под освоением.rumkin
01.03.2019 17:00Смысл в том, что в языке появляется много исключений, которые нарушают изначальную логику. И для каждого такого исключения нельзя построить какое-то одно правило, все исключения придется заучивать. Т.е. предсказание поведения на основе полученного опыта становится невозможно. Пример с
1 + 1nуже привел выше.dimm_ddr
01.03.2019 21:52Так есть же перл все еще — мне неизвестно там большое количество исключений. Тем более тех, что нарушают изначальную логику. Это, естественно, не значит что вы неправы абсолютно всегда, только что есть примеры вам противоречащие и, значит, такое правило без каких-то оговорок построить нельзя.
rumkin
01.03.2019 22:33Я не могу обсуждать Перл, так как не знаком с ним. Я говорил о том, что JS постепенно превращается в два языка в одном. Процесс еще не завершился, но вектор задан и меняться не будет, если судить по TC39/proposals.
dimm_ddr
02.03.2019 21:32Если вы только о JS, то никаких претензий. Мне не понравилась именно категоричность заявления. А что оно категорично и общо я решил потому что вы привели в пример Go как бы показывая что говорите не об одном языке, а вообще.
rumkin
03.03.2019 00:34Могу сказать, что Go по сравнению со многими языками, которые мне довелось попробовать, более простой и быстрее осваивается (за счет меньшего количества языковых конструкций). Поэтому, вполне вероятно, что в этом плане он выиграет у Перла. Например про Перл я часто слышал, что его легко писать, но тяжело читать.
Но я могу и обобщить: пространство решаемых тьюринг-полными языками задач одинаково, поэтому, если при этом пространства их логических примитивов соразмерны, то остается только синтаксис. И тут выиграет тот, у кого он проще.
Ztare
28.02.2019 15:52Все созданное человеком рано или поздно уничтожается. Идеи — устаревают и забываются, физические вещи будут сломаны, научные изыскания также устаревают ввиду новых открытий так или иначе. Это основополагающая как мне кажется вещь.
third112
28.02.2019 20:12+1научные изыскания также устаревают
Теорема Пифагора устаревает?MikailBag
28.02.2019 20:39-1Всякие естественные и гуманитарные знания вполне устаревают (например геоцентрическая модель мира) или оказываются кривыми(механика Ньютона).
third112
28.02.2019 21:27+4оказываются кривыми(механика Ньютона)
Чем эта механика кривая? У нее есть определенные границы применимости, и в этих границах ее успешно применяли, применяют и будут применять. А для квантовых систем — квантовую механику. Одно другому не мешает.
гуманитарные знания вполне устаревают
Документально подтвержденное (многими документами) гуманитарное (историческое) знание, что Бородинская битва произошла в 1812 г. Как это знание может устареть?Ded_Banzai
28.02.2019 22:15-2А вы посмотрите на современные учебники истории. Уже столько переврали, что скоро и Бородинское сражение будет частью какой-нибудь войны за независимость.
MikailBag
28.02.2019 23:17-1- Известно, что ньютоновская механика неверная. В этом плане я имел в виду кривизну — то есть научное знание обычно неполное. И не всегда его неполноту можно терпеть. (Например плоскую землю никто не учитывает, это сильно устаревшая и заброшенная модель. Когда в эту же стадию скатится Ньютонова механика — вопрос времени).
- Ну а в каком-нибудь 5 веке условный Ци Ши Янь описал, как победил условного Жо Ши Меня. И вот, допустим, его табличка, или на чем там писали китайцы в пятом веке, пылится в какой-нибудь библиотеке, и всем на неё наплевать. Общественная значимость любого исторического знания со временем падает. А значит, все меньше и меньше людей к этому знанию стремятся. Вполне устаревание, как по мне.
Groramar
28.02.2019 23:31+2Ньютоновская — никогда никуда не скатится. Так же как большинство из нас кривизну Земли не учитывает измеряя площади. То есть даже модель плоской Земли вполне применима и удобна в быту.
gohan
01.03.2019 05:46Известно, что ньютоновская механика неверная.
Как она может быть неверная? Это примерно как сказать, что уравнение состояния идеального газа неверное. Да, идеального газа в природе не существует, но бывают близкие к нему реальные газы, и для них уравнение хорошо работает, приближённо. И оно остаётся верным для теоретического идеального газа. С механикой такое же.
third112
01.03.2019 08:06Известно, что ньютоновская механика неверная.
Судя по вики никому (кроме Вас) это не известно. Есть ограничения, но это не значит «неверная».
Общественная значимость любого исторического знания со временем падает. А значит, все меньше и меньше людей к этому знанию стремятся.
М.б. в 5 веке знание про победу Ци Ши Янь было более востребованным обывателями, потом только специалистами. Но количество спецов возрастает м.б. пропорционально росту населения Земли, т.о. м.б. не меньше. Далеко не все знания нужны всем, а только узким спецам, но это принципиально ничего не меняет. Общественная значимость часто бывает косвенной: так наверное больше 99% людей ничего не знает про технологии получения чистого кремния, но почти 100% пользуются изделиями электроники — продукцией этих технологий.MikailBag
01.03.2019 08:22-1Я не очень понимаю, что вам не понятно. Идем в гугл, видим что по Эйнштейну сумма скоростей равна не x+y, а (x+y)/(1+xy/cc). Это две разные формулы. Если вы подставите в них одни и те же числа, получите разный результат.
Ну а на Коболе тоже кто-то пишет. И что, Кобол не устарел?
third112
01.03.2019 08:58Типовую школьную задачку «из пункта А в пункт Б вышел один человек...» Вы предлагаете решать по Эйнштейну?
Да, что-то устаревает, но если Кобол устарел, это не значит, что теорема Пифагора устарела.
AN3333
01.03.2019 12:05Известно, что ньютоновская механика неверная.
Ньютоновская механика совершенно верная.
Как уже сказали, она, как и все, имеет область применимости.
dimm_ddr
01.03.2019 15:19Например плоскую землю никто не учитывает, это сильно устаревшая
С точки зрения строителя малоэтажного дома землю совершенно необязательно считать круглой — это ничего не поменяет. Локальный ландшафт внозит на порядки больше чем кривизна земли. Проще забыть что земля круглая и смотреть только на локальные особенности. Прямо так, конечно, никто не думает, но суть примерно такая.
Groramar
28.02.2019 23:28+1или оказываются кривыми(механика Ньютона)
Это с каких пор механика Ньютона стала кривой? :) Отлично работает в известных рамках. Более новая механика ньютоновскую не отменила, но дополнила.MikailBag
28.02.2019 23:55Ну вот в этих рамках и вопрос. То есть модель плоской земли настолько кривая, что ни для каких рассчетов не подходит. А когда-то она была доминирующей и всех устраивала. Логично предположить, что по мере дальнейшего технологического прогресса и ньютоновская механика станет непригодной для большинства применений.
Ну а дополняет или нет — это скорее вопрос в терминологии. Формально, почти любое применение законов Ньютона дает некоторую ненулевую ошибку.
oracle_and_delphi
01.03.2019 01:31+1А разве при проектировании и постройке зданий учитывают кривизну Земли?
iliyesku
01.03.2019 12:36При строительстве мостов используют
en.wikipedia.org/wiki/Verrazzano-Narrows_Bridge#Descriptiondimm_ddr
01.03.2019 15:21При строительстве любых мостов? Или только в особых случаях? Я сомневаюсь что это имеет смысл при строительстве моста из пары бревен через ручей.
third112
01.03.2019 11:43То есть модель плоской земли настолько кривая, что ни для каких рассчетов не подходит. А когда-то она была доминирующей и всех устраивала. Логично предположить, что по мере дальнейшего технологического прогресса и ньютоновская механика станет непригодной для большинства применений.
Абсолютно не логично. Классическая механика Ньютона экспериментально подтверждается (в границах применимости), а модель плоской Земли была только гипотезой, и когда ее попробовали экспериментально подтвердить, т.е. дойти до края Земли, оказалось, что у Земли нет края.
То есть модель плоской земли настолько кривая, что ни для каких рассчетов не подходит.
Как справедливо отметили выше, эта модель оправдана для многих практических приложений, нпр., в строительстве.
immaculate
01.03.2019 03:33Евклидова геометрия в определенный момент устарела, хотя казалось бы...
third112
01.03.2019 08:52Евклидова геометрия в определенный момент устарела
Когда? Я, как и мои коллеги, ее использую постоянно для научных исследований, результаты печатают в ведущих журналах, и ни один рецензент пока не сказал, что Евклидова геометрия устарела ;)acmnu
01.03.2019 10:46Очевидно, что речь идет про современную физику за пределами случаев когда примнима нюьтоновская физика. Конечно и в мире малых скоростей и больших объектов физикам есть чем заняться. Та же гидродинамика. Но в ОТО и зоне высоких энергий используется неэвклидова геометрия, в которой теорема Пифагора не работает.
third112
01.03.2019 11:31Конечно и в мире малых скоростей и больших объектов физикам есть чем заняться. Та же гидродинамика. Но в ОТО и зоне высоких энергий используется неэвклидова геометрия, в которой теорема Пифагора не работает.
И почему устарели Ньютон, Евклид и Пифагор? Есть зона высоких энергий и скоростей, но другие зоны не утрачивают актуальность, и подозреваю, что в них задач не меньше, а больше. Конкретных инженерных каждодневных задач. И так будет очень долго, если не всегда. Большинство людей будут продолжать жить в мире Евклида и Ньютона. Современный грамотный физик (речь не о предствителях «альтернативных наук», которые называют себя «физиками») прекрасно знает ОТО, но типовую задачу о 2 пешеходах между пунктами А и Б (расстояние ок. 5 км) он никогда не будет решать в ОТО — смысла нет: разница с классической механикой пренебрежимая и экспериментально не обнаружимая. Скучно это писать — в общеобразовательной средней школе должны были объяснить. А кто пропустил уроки — я дал выше ссылку на вики: там ссылки на авторитетные современные учебники физики, где четко сказано, когда какую модель использовать.acmnu
01.03.2019 11:42"Устарела" или нет, это просто вопрос формулировок, возможно неудачных. Давайте разговор у физике не превращать в филологию.
third112
01.03.2019 11:48Нет, не только вопрос формулировок. Чисто практически: если что-то устарело, то вместо него всегда нужно использовать новое. Т.е. если Ньютон устарел, то всегда вместо него нужно использовать ОТО. Получим абсурд, не филологический, а чисто физический.
acmnu
01.03.2019 12:02А именно её по факту и используют. Просто формулы ОТО на малых скоростях полностью соответствуют тому, что используется со времен Ньютона. Фактически всегда надо начинать с ОТО и только убедившись, что поправка принебрежимо мала, переходить к классике. Яркий пример полет космического корабля к Меркурию. Движение этой планеты не соответствует законам Кеплера из-за близости к Солнцу и без ОТО не обойтись, но отправить корабль, а потом узнать что просчитался как-то не кошерно.
third112
01.03.2019 12:18А именно её по факту и используют.
Где это сказано? Ссылку на авторитетный источник можете дать? Я говорил о земных задачах с земными расстояниями (нпр., ок. 5 км) и скоростями (нпр., пешеходов), а не про «полет космического корабля к Меркурию».
С такими земными условиями «всегда надо начинать с ОТО и только убедившись, что поправка принебрежимо мала, переходить к классике»?
Абсурд!acmnu
01.03.2019 12:43Где это сказано? Ссылку на авторитетный источник можете дать?
Эм. В формулах это сказано. Преобразования Галлилея это частный случай преобразований Лоренца, для малых скоростей, например.
third112
01.03.2019 12:53+1Из этого не следует, что решая земные задачи (5 км и скорость пешеходов) «всегда надо начинать с ОТО и только убедившись, что поправка принебрежимо мала, переходить к классике».
domix32
01.03.2019 12:36Появляются всякие пространства с ненулевой кривизной и пифагор уже не торт без генерализации, так-что да, даже она устарела.
third112
01.03.2019 12:49+1Где появляются всякие пространства? Когда я игрушку-шутер пишу или дачный домик проектирую, у меня ничего такого не появляется. Да, я уже где-то читал, что у кого-то появились торсионные поля, поэтому вся наука устарела.
dayllenger
01.03.2019 13:00Это холиварная тема, из-за того, что у всех разное понимание слова «устарела». Я, например, могу сказать, что теорема Пифагора устарела, потому что в современной математике вначале на линейном пространстве определяют скалярное произведение, из него получается метрика, а из неё следует, что сумма квадратов катетов равна квадрату гипотенузы. Пустая болтовня, на самом деле.
third112
01.03.2019 18:13Вы сказали не про теорему, а про возможное ее доказательство. Я уже здесь сказал:
Чисто практически: если что-то устарело, то вместо него всегда нужно использовать новое.
Какое еще понимание слова «устарела» возможно?
domix32
02.03.2019 01:16Вот только давайте без передергиваний. Неевклидова геометрия применима в том числе и в играх.
third112
02.03.2019 09:54Вот и не передергивайте. Важно ни что можно применить, а важно, что я могу в играх без нее обойтись используя «устаревшую» теорему Пифагора.
VMichael
28.02.2019 16:15Интересно.
Сами люди вырастают, развиваются и становятся носителями мыслей, обновить которые еще сложнее, чем программы. И они умирают, а на их место приходят новые люди.
Почти полная налогия с программами.
И встает проблема бессмертия. Если люди станут бессмертными, обновление социальной среды станет гораздо дороже обходиться, по аналогии с обновлением ПО, описанном в статье.vchslv13
28.02.2019 19:29Если люди станут бессмертными, обновление социальной среды станет гораздо дороже обходиться, по аналогии с обновлением ПО, описанном в статье.
Думаю, в сочетании с колонизацией космоса всё должно быть нормально. «Молодые и прогрессивные» улетают строить лунапарк с блекджеком и шлюхами где-то на Марсе или Плутоне (или вообще на автономной космической станции), в то время как старые и довольные стабильностью остаются на месте. Если социальный строй старых будет слишком уступать тому, что построили молодые, то со временем его или вытеснят в результате мирной конкуренции, или… кхм… решат проблему бессмертия бессмертных неприродным путём.VMichael
01.03.2019 11:54Это и есть дороже.
В текущих условиях старое поколение само уходит, автоматически.
В вашем примере нужно затратить дополнительные ресурсы, что бы «решить проблему бессмертия бессмертных».
Еще вопрос в том, что волна молодых, через время n (точное число не важно в категории бессмертия, т.е. бесконечной жизни) сама переходит в категорию консерваторов. И цикл пошел заново.
Сейчас существует автоочистка, а в случае бессмертия этот механизм перестает работать. А если делать искусственные (читай насильственные) механизмы очистки приходим в противоречие с постулатом, что жизнь бесценна и является некоей священной коровой (иначе смысл в бессмертии, если его можно прекратить по неким условиям?).
Замечу, что я не против бессмертия, просто интересно обсудить вопросы, возникающие при этом.
Механизм деградации ПО похож на механизм деградации людей при изменчивой внешней среде.dimm_ddr
01.03.2019 15:26Это и есть дороже.
Дороже само по себе не значит плохо. Вы заявили проблему, вам показали что у нее есть естественное решение. Это нормально, что не так то? Ну да, дополнительные ресурсы. Но надо еще посмотреть сколько ресурсов будет получено за счет собственно корня вашей проблемы — бессмертия. Я предполагаю что заметно больше и общий результат по ресурсам будет положительный.VMichael
01.03.2019 16:45У любой проблемы всегда есть быстрое, простое и неправильное решение.
Я думаю, что показанное решение оно слишком упрощенное и не закрывает темы.
Кроме того в нем было неявно высказано, что бессмертие можно искусственно сделать достаточно коротким.
Есть еще вопросы:
Например, а что вдруг, если экспансия в космос не удастся?
Или что консервативная часть «бессмертных» сконцентрирует у себя ресурсы и не даст продыху «инноваторам»?
Ну и вопрос, что «инноваторы» через достаточно небольшое время сами переходят в стан консерваторов тоже не снимается с повестки.
Сейчас это решается простой сменой поколений в 100 летних, условных интервалах.
P/S:Это нормально, что не так то?
Вы как то очень лично подходите к обсуждению проблемы. Просто попробуйте беспристрастно и холодно рассмотреть со стороны.dimm_ddr
01.03.2019 21:55Я думаю, что показанное решение оно слишком упрощенное и не закрывает темы.
Конечно нет. Потому что в реальной жизни будут тысячи нюансов. Но ваше описание проблемы также крайне упрощено и ответить на него детальнее не представляется возможным.
И я не очень понимаю где вы тут личное увидели. Я всего лишь искренне удивился что вам не понравилось в решении. Потому что вы никак его не опровергаете, но вас оно очевидно не устроило.
perfect_genius
01.03.2019 22:18Старый или не старый — всё-равно все всё перепробуют в жизни и уснут от скуки на тысячи-миллионы лет в ожидании данных от космических зондов, отправленных во все стороны от Земли. Не беспокойтесь.
rumkin
28.02.2019 17:08С таким названием идея, что программы должны умирать, не получит поддержки, слишком оно отталкивающее. И плохо отражает суть явления.
amarao
28.02.2019 17:22+1Понятие software rots немного о другом. Из-за изменения стандартов вокруг, старый софт перестаёт работать. Возьмите IE6 и откройте интернет. Вы даже кривой вёрстки не увидите, потому что все протоколы SSL IE6 уже выпилены и не поддерживаются.
Возьмите видеоплеер и откройте современное кино — x265, etc — ничего не работает.
Возьмите старый текстовый редактор и откройте современный текст — вместо улыбающейся какашки там будут просто какашки.
etc, etc.
Старый софт, кажется что, работает как работал, а на самом деле «гниёт» относительно современных стандартов (и входных данных).vitaliy2
28.02.2019 19:19Не знаю, как IE6, а вот IE11 и Edge 44 всё открывают.
Старый софт, кажется что, работает как работал, а на самом деле «гниёт» относительно современных стандартов (и входных данных).
Ну это логично. Если софт не обновляются, то его съедят конкуренты. Нужно быть в ногу со временем, чтобы быть на высоте, или даже опережать время.
кажется что, работает как работал
Ну так он и работает, как работал, просто у Вас появляются новые хотелки. Хочу, к примеру, чтобы открывал H.265.sumanai
01.03.2019 20:05Не знаю, как IE6, а вот IE11 и Edge 44 всё открывают.
IE11 не умеет в короткий синтаксис функций, и автоматически ломается на любой странице, их использующих. А Edge закопал сам МС.
Mykola_Von_Raybokobylko
28.02.2019 17:24Эволюция и интеграция программам жизненно необходимо. Теже браузеры. Многопроцессные или монопроцессные в отдельности особого интереса не представляют. Но вот возможность браузера корректно работать с разными службами опираясь на то с какими задачами чаще сталкиваются пользователи сейчас в данный момент, это важнее. Или возьмем например фичи в браузерах. Как самый быстрый на старте или как самый менее прожорливый. По отдельности они не интересны, но в комплексе это имеет существенное преимущество перед выбором. Самый быстрый на старте может быстро открывает только пустую стартовую страницу и не способен открывать больше 50 вкладок или вообще создан как клон интернет эксплорера 6. Так же и с менеепрожорливым.
saipr
28.02.2019 18:13Я пытался найти случаи, которые опровергают гниение ПО, но их, похоже, не существует.
А я думаю существуют — это Tcl/Tk. Я спустя 20 лет вернулся к нему и понял как я много потерял, отодвинув его в сторону.
dimm_ddr
01.03.2019 15:34Смотря что понимать под живой и здоровый (не сгнивший если брать термины поста) проект. Я бы предположил что это должно быть что-то что достаточно активно используется в своей сфере. Какие есть большие проекты на тикле и сколько проектов на нем стартуется сейчас? Я не сильно в теме, возможно что и есть. Но если нет, то я бы сказал что он и не жил особо никогда. Так, еще один язык для развлечений. «Что мертво — умереть не может»
saipr
01.03.2019 23:02Вот что публиковал habr:
Использование TCL в разработке на FPGA
Использование скриптов TCL для управления проектами Quartus II
Webshell на TCL, для Cisco IOS и не только
А сообще-то сетевики знают, что без Tcl сети трудно представить.
А чего стоит expect
А сколько всего написано и пишется наTk
akurilov
28.02.2019 19:23Питон, пхп, жаваскрипт, гоу — в смысле огромных, не пойми как написанных когда-то, разлагающихся несметных пластов безысходников — это то, что мы заслужили.
Write once, suffer eternally
StriganovSergey
28.02.2019 19:26А поскольку GIL существует, то может быть лучше использовать Erlang, а не Python?
geoolekom
28.02.2019 22:52+2Да, давайте весь код с Python на Erlang перепишем. А CPython перепишем с C на Rust, и ядро Линукса тоже перепишем на Rust заодно.
StriganovSergey
01.03.2019 08:34Мой коммент был в контексте разбора серверных архитектур, он о том, что если нужна высокая производительность в многопоточности, то инструмент (язык) выбирается такой, который специально для этого и разрабатывался. Хороший пример выбора: WhatsApp писали на Erlang.
Whuthering
01.03.2019 11:04Насколько я помню, Erlang был выбран только потому, что у них изначально глубоко под капотом был XMPP-протокол, самая лучшая реализация сервера которого (ejabberd) уже была написана на Erlang.
F376
28.02.2019 20:21+8Переводчику. m1rko
В русском языке в научно-популярной терминологии термин «гниение», «гнить» имеет единственную устойчивую ассоциацию с биологическим процессом гниения.
Термин «rot», «rotten» в данном контексте должен переводиться не как «гнить», а как «протухать» или «портиться». Также м.б. «разлагаться», «деградировать». Термин rot может переводиться как «загнивать» но в приложении к обществу, партии, и проч. группам.
в чём причина гнили программного обеспечения?
программное обеспечение гниёт!
Не гнили, а порчи.
Не гниет, а портится.
© «Волны перекатывались через мол и падали вниз стремительным домкратом»Dr_Faksov
01.03.2019 03:51То есть «гнилой человек» — это типа зомби?
prospero78su
01.03.2019 08:35Гнилой — есть состояние моральных качеств. Т. е. их просто нет. Человек-слизь, без костей, без позвоночника. Вроде есть, но прикасаться к его душе отвратительно.
Dr_Faksov
03.03.2019 06:53Это понятно. Просто выше утверждалось — «В русском языке в научно-популярной терминологии термин «гниение», «гнить» имеет единственную устойчивую ассоциацию с биологическим процессом гниения.» Поскольку душа не гниёт биологически…
Fedcomp
28.02.2019 21:42+1Почти десять лет спустя Mozilla, наконец, выпустила мультипроцессный Firefox на массовую аудиторию. Эта задержка произошла вовсе не от недостатка желания. У Mozilla талантливые и целеустремленные разработчики. Тем не менее, Chrome был написан с нуля за гораздо меньшее время, чем потребовалось Firefox для изменения.
Эм, так то мозила целый новый язык под многопроцессорность запилила, после чего по сути переписала части своего движка с нуля. В то же время хром как был на C++ так и остался, плюс у гугла больше ресурсов.
sentyaev
28.02.2019 23:01+1Эм, так то мозила целый новый язык под многопроцессорность запилила,
Ну это, «лучше день потерять, зато потом за 5 минут долететь»
leotsarev
01.03.2019 09:04Вы путаете Electrolysis с Quantum CSS.
Тут речь идёт именно об изоляции табов в процессы, что действительно шло долго и плохо
А вот параллелизация обсчета CSS в отдельные потоки в одном процессе — которую сделали на Rust — она довольно бодро прошла. Кстати, это третья попытка, две предыдущие были на C++ и провалились.
Как и аналогичные попытки Хрома.
Error1024
28.02.2019 22:09+3Тем не менее, Chrome был написан с нуля за гораздо меньшее время, чем потребовалось Firefox для изменения.
Все-таки не с нуля
i8008
01.03.2019 01:28Как правило, грамотная адаптация программного обеспечения к новым условиям занимает больше времени и усилий, чем написание нового программного обеспечения с нуля. Программисты не любят признавать это, но доказательства очевидны
Я не знаю каких про каких программистов идет речь, но
грамотная адаптация программного обеспечения к новым условиям
в переводе на язык «программистов» обозначает поддержка легаси кода. И звучит это как приговор.
чем написание нового программного обеспечения с нуля
А вот возможность переписать все «правильно, с нуля» — рай для разработчика. Вот только со стороны «заказчика» выглядит не очень (и заказчика тут тоже можно понять)
f1inx
01.03.2019 02:23Правильнее было бы назвать назвать статью Проблемы деградации в bloatware ПО с плохой архитектурой и при использовании неверных подходов к разработке ПО.
iroln
01.03.2019 11:40А что, бывает другое ПО? Я пока не видел :)
Ладно, это скорее шутка, а если серьёзно, то с проблемами деградации сталкиваются почти все проекты, потому как с ростом кодовой базы сложность кода так же растёт и растёт сложность его сопровождения и развития в любой архитектуре.
fimble
01.03.2019 04:29… Тем временем, EMACS например «гниёт» уже 35 лет. И до сих пор от этой реакции тепло, несмотря на все ужасные недостатки Elisp (наследника древнейшего MACLisp) и его виртуальной машины. Осмелюсь предположить, что именно природа языка с синтаксической абстракцией и возможностью расширения «вглубь» — позволила настолько компенсировать подобные недостатки.
Из песни слов не выкинешь:
Пожалуй, трудно найти две более разные культуры программирования, чем те, что образовались вокруг этих двух языков и используют их в качестве единой валюты. Паскаль служит для построения пирамид — впечатляющих, захватывающих статических структур, создаваемых армиями, которые укладывают на места тяжелые плиты. При помощи Лиспа порождаются организмы — впечатляющие, захватывающие динамические структуры, создаваемые командами, которые собирают их из мерцающих мириад более простых организмов. Организующие принципы в обоих случаях остаются одни и те же, за одним существенным исключением: программист, пишущий на Лиспе, располагает на порядок большей творческой свободой в том, что касается функций, которые он создает для использования другими. Программы на Лиспе населяют библиотеки функциями, которые оказываются настолько полезными, что они переживают породившие их приложения. Таким ростом полезности мы во многом обязаны списку — исконной лисповской структуре данных.
Простота структуры списков и естественность их использования отражаются в удивительной общности функций. В Паскале обилие объявляемых структур данных ведет к
специализации функций, которая сдерживает и наказывает случайное взаимодействие
между ними. Лучше иметь 100 функций, которые работают с одной структурой данных, чем 10 функций, работающих с 10 структурами. В результате пирамиде приходится
неподвижно стоять тысячелетиями; организм же будет развиваться или погибнет.
synedra
01.03.2019 15:16Электромагнитная эпоха
Сами вы электромагнитный. В названии "Age of Em" последнее слово — сокращение от emulated. И "Overcoming bias" — это название блога Хэнсона, а не часть заголовка статьи.
sumanai
01.03.2019 19:50Firefox должен сохранить совместимость с существующими расширениями
Но не сохранил.
И да, многопроцессоность никак не связана с высокой производительностью. Наоборот, многопроцессность снижает производительность, так как появляются расходы на межпроцессное взаимодействие.
Производительность повысила бы многопоточность.
SirEdvin
Мне казалось, там вполне понятно написано — почему. Потому что если его выпилить, то однопоточные программы будут работать еще медленнее. Причем даже есть другие реализации питона, где его так или иначе убирали (у pypy есть режим без gil), но лучше реализация не получалась.