О бедном Crystal замолвите слово

У меня более фундаментальная позиция: современная доминирующая модель машины тьюринга со строго пошаговым выполнением и бесплатным атомарным состоянием делает недопустимо ненадежными или бесполезными любые попытки многопоточности-многозадачности даже несмотря на всякие Arc и Mutex, Sync и Send.

«Профессор был неправ»

Это видимо максимально допустимая степень нонконформизма в ИТ, круче чем у Столлмана с его GNU.

Для решения проблемы нужны новые методики, заменяющие глобально детерминированное состояние машины тюринга на локально детерминированное,

Которое затем упрется программным рогом в x86 архитектуру, если я правильно понимаю идею.

Но что тут сказать: «пилите Шура, внутри она золотая».

Для таких заявлений одного сотрясания воздуха недостаточно, надо делать что-то. Код там писать, прототипы делать и статьи. Работа на жизнь, но если повезет то можно оказаться в истории.

чё zig реально быстрее быстрого собирает. прям быстрей golang’а?

Скорее всего нет, по той инфе, что я нарыл, там по прежнему порядка 3к строк/секунду. Примерно столько же у golang. Для сравнения, типовая цифра для паскаля — 20к строк/секунду.

разве golang не вернул пиши-компиляй-сообществу прелесть «мгновенной» сборки со своим выкотом?

Что значит «вернул»? Насколько мне известно, на тот момент было только два ЯП с безумно медленной компиляцией — это C и C++. Потом к ним добавился Rust, который доселе остается неоспоримым чемпионом по медленности компиляции. Всё остальное собиралось сильно быстрее.

Серьезно? Наезжать на ООП и классы и считать иделалом процедурный устаревший язык?

Вопрос был про «забытый давным-давно язык». Я ответил. Если ты хочешь спрашивать про новые языки, то спрашивай про новые языки.

Будет иллюстрированное описание с картинками на тему почему паскаль вам не поможет.

Я имею сильно больше тебя опыта в паскале, и могу на основании него подтвердить, что паскаль безнадежно скатился в говно и больше не является никаким значимым ЯП в индустрии. Даже golang ближе к идеям паскаля (умеренная безопасность памяти, локальность данных, платформонезависимость), чем то, что нынче называется паскалем. Еще раз, то, что сегодня называется паскалем — это C/C++ с синтаксисом паскаля.

Я считаю, что C/C++ — это худшее, что произошло с индустрией, оно отбросило развитие лет на десять со своей медленной разработкой и совершенно ненадежным продуктом, и только на фоне тотального провала этой модели Java выглядела как-то минимально привлекательно, хоть и скопировала очень много негатива из C++.

Clojure без Java

Clojure без Java подобна Clojure с Java, только без Java. Ауф.

методики, заменяющие глобально детерминированное состояние машины тюринга на локально детерминированное, которое при помощи описания причинно-следственных связей оперирует глобально недетерминированным состоянием

Папа, это ты с кем сейчас разговаривал? %)

Если для обслуживания интересов «вечного ребенка» жителя крупного мегаполиса надо изобрести вебсокеты и протоколы стиминга - их изобретут.
Но менеджеры крупных корпораций тут лишь посредники.

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

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

Крупным корпорациям, вроде гугла, жизненно важно иметь большие и таинственные софтины, вроде Chromium, которые не то что разработать — даже просто собрать эту хреновину весьма сложно. Или тот же Cobol, который десятилетиями кормил IBM. Есть более простые и эффективные решения, но ОНИ НЕ СОЗДАЮТ ОБОРОТА. Более качественный софт может приносить преимуещство разработчику, если это позволяет создать оборот.

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

Тот проект, в котором я сейчас работаю за денюжку, представляет собой одну сплошную совместимость с совместимостями, и если трезво спросить «а какую прикладную задачу наша софтина решает», то остается лишь истерично посмеяться, поскольку это действительно «хранилище текстовых файликов» для тех, кто за 30 лет прогресса не научился ничему большему, чем башескрипты и сишное open-write-close. И это рынок, потому что те, кто научились современным хранилищам текстовых файликов, больше не являются источником дохода в этой сфере.

К слову, та же история с SAP: для компании намного дешевле нанять собственных разрабов и сделать свою систему, чем покупать решение от SAP, которое точно так же не дает гарантий успеха внедрения. Весьма немаленький завод из моего родного города, который по масштабу примерно как упомянутый выше аэропорт пулково (https://vc.ru/money/843922-600-millionov-za-vnedrenie-1s-v-pulkovo-mnogo-ili-...) потратил 2 млн долларов на собственную системы автоматизации, из которых, я подозреваю, солидная доля приходится только на лицензию Oracle. Пулково потратил 6 млн долларов на 1С. Сколько бы для Пулково стоила интеграция SAP? Я думаю, что $20-30 млн — это нормальная такая цифра. Понимаешь, почему разрабатывать собственную систему автоматизации не выгодно для экономики?

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

Давай рассмотрим идеальный сферический пример постановки на службу обществу — метрическая система. Метрическая система имеет абсолютное преимущество и введена везде, кроме США, Либерии, и Мьяньмы. К слову о том, почему весь мир пользуется пилами, а США — высокоскоростными каменными топорами из оксида тория. Это я образно, конечно.

golang какой то странный... Да и скорость работы у него какая то подозрительная

У голанга мало оптимизаций по нынешним меркам, в основном это escape analysis, инлайн, и ad-hoc оптимизации конкретных операций. Например, автовекторизации в Go просто нет, нужно либо применять всякие gonum, либо самому писать на асме. Если ты не создаешь очень много мелких объектов, то сборщик мусора значительного влияния на производительность не окажет.

Если ты хочешь спрашивать про новые языки, то спрашивай про новые языки.

Вообще-то речь шла о том языке который ты считаешь идеальным, не старым или новым.

Я имею сильно больше тебя опыта в паскале,

Я познакомился с Паскалем в 1996м году в школе, Си тогда уже естественно был, даже в РФ. И Борланд тоже был.

Поэтому ты можешь иметь сильно больше опыта только если начал писать код еще в 80х.

Еще раз, то, что сегодня называется паскалем — это C/C++ с синтаксисом паскаля.

Речь про Borland Delphi или FPC все же?

Но в любом случае, если ты настолько опытный - почему не пробовал что-то исправить? Патчи/коммиты/форки? Прототипы твоих гениальных идей?

Я считаю, что C/C++ — это худшее, что произошло с индустрией,

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

Которое затем упрется программным рогом в x86 архитектуру, если я правильно понимаю идею.

Очень правильно понимаешь. Другое дело, что сама x86 под капотом уже давно реализована именно на описываемых мной механизмах событий и причинно-следственных связей у относительно независимых вычислителей, которые можно было бы представить как очень большое число машин тьюринга, если бы не выраженная событийность. Как я уже писал, массовая индустрия отстала примерно на 20 лет, Intel по-своему использует это отставание для стрижки баранов, создавая красочный миф про «всё развивается, процессоры становятся быстрее, можете еще 50 лет ничему новому не учиться». ARM так-то уже много лет через официальный набор инструкций предоставляет доступ к некогерентному режиму работы кэша.

Clojure без Java подобна Clojure с Java, только без Java. Ауф.

Идея ЯП хорошая, но нынешняя реализация требует создания большого числа мусора, типичного для Java программ. Это делает программы крайне неэффективными, и простой переход на JS с сохранением всего наследия никак не спасает. Нужен полный отказ от промежуточной модели и построение VM на персистентных структурах данных изначально.

Папа, это ты с кем сейчас разговаривал?

Я привел пример map-reduce, как варианта реализации этой методики. Для map не важно, в каком порядке выполнятся отдельные операции, то есть, процесс работы map-based алгоритма неопределен, важны лишь входные аргументы и выходные результаты. Машина Тьюринга и lock-free программирование на ней, в противовес, подразумевает некое наблюдаемое достаточно предсказуемое глобальное состояние. Глобальная сериализация — это основной убийца масштабируемости, будь то многопоток, многозадача, или распределенные вычисления.

Я повторил ЭТО: Почему Rust в 2 раза медленнее Си?

на rust and golang.

Rust: 0m13.177s
Go: 0m44.980s

нынешняя реализация требует создания большого числа мусора, типичного для Java программ. Это делает программы крайне неэффективными

Нужен полный отказ от промежуточной модели и построение VM на персистентных структурах данных изначально

Но при этом мы потеряем интероп с имеющейся проверенной временем платформой и доступ к тысячам человеколет имеющихся для неё решений — одно из главных практических преимуществ кложи. Миллиарды долларов инвестиций придётся просто выкинуть.

Стоят этого смутные опасения о какой-то призрачной «неэффективности»?

Я привел пример map-reduce

Я просто ни хера не понял из того, что ты там наговорил, прости %)

Вообще-то речь шла о том языке который ты считаешь идеальным, не старым или новым.

Речь может быть когда-то и шла про идеальный язык, но отвечал я на вопрос про старый язык. А учитывая то, что применимость ЯП без конкретной задачи или хотя бы спектра не имеет смысла, то и ответы получаются разные.

Поэтому ты можешь иметь сильно больше опыта только если начал писать код еще в 80х.

Может оказаться, что ты кучу лет писал энтерпрайз на делфи, как это делал я. Но я сомневаюсь в этом. На упомянутом мной заводе тоже в значительной степени на делфи делали с ораклом.

Но в любом случае, если ты настолько опытный - почему не пробовал что-то исправить? Патчи/коммиты/форки? Прототипы твоих гениальных идей?

Почему я не попробовал выпрыгнуть из окна? Почему я не попробовал сесть на героин? Стать балериной, уехать работать в штаты — много чего могло бы быть, но в итоге было то, что было, и то, что мне показалось хорошей идеей. Делать маленькие патчи к фундаментально испорченному ЯП — это бесполезная затея.

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

Я просто трезво оцениваю погоду в океане. Я это делаю ровно настолько, насколько это может касаться меня, то есть, я не буду выходить в океан в заранее известный шторм.

Но что тут сказать: «пилите Шура, внутри она золотая».

Может он из этих, которые бороду в качестве закладки в книге по Forth используют.

Я повторил ЭТО: Почему Rust в 2 раза медленнее Си?
на rust and golang.

Это код на разворачивание цикла и/или векторизацию — ни того, ни другого в го нет. Если тебе кровь из носа нужно заоптимизировать этот кусок кода для Go, то это возможно сделать, но делать это придется руками. Дело в том, что официальный компилятор Go не строит промежуточного представления, на котором происходит оптимизация в LLVM и GCC, потому он в принципе не способен такие оптимизации делать. Потому что для 95% кода никто не обнаружит разницы между наличием или отсутствием оптимизаций.

Но при этом мы потеряем интероп с имеющейся проверенной временем платформой и доступ к тысячам человеколет имеющихся для неё решений — одно из главных практических преимуществ кложи. Миллиарды долларов инвестиций придётся просто выкинуть.

Это миллиарды долларов, вложенные на давно сдохшую кошку. Я согласен с тем, что бизнес мыслит категориями экономики и политики, а не техническими аспектами. С технической стороны тратить миллиарды на поддержание дохлой кошки в хорошей форме — это безумие, с экономической — инвестиция.

Или ты очень скучаешь по безмерному потреблению памяти и тормозящему GC? Просто вот никак прожить без этого готового решеняи не можешь.

Дело в том, что в западной экономике не нужна эффективность — нужны лишь обороты,

Это капитализм да, он такой. К счастью на дворе уже не 1920е, есть определенные правила, есть социалочка и регуляторы.

Не важен предмет ­— важны лишь денежные потоки.

Предмет все еще важен, пусть и в раздутом виде. Но честно говоря эта модель уже несколько устарела, так просто уже не работает.

Если вебсокеты может освоить даже школьник — это уничтожит рынок.

Нет не уничтожит. Как не уничтожили рынок услуг по созданию сайтов всякие конструкторы и генераторы.

Если автомобили перестанут ломаться, то это уничтожит автомобильную промышленность.

Мне кажется все эти теории заговора про «искусственное устаревание» сильно далеки от реальности. Я еще помню «Сопромат» достаточно хорошо, чтобы ставить под сомнение гарантированную поломку через 3-5 лет.

В умелых руках почему-то ничего не ломается, что стиралки что холодильники что ноутбуки что машины.

Есть более простые и эффективные решения, но ОНИ НЕ СОЗДАЮТ ОБОРОТА.

Вот есть у тебя утилита, которая «проста и эффективна», делает какую-то одну задачу и делает ее хорошо. Но очень скоро пользователям становится мало ее фукнционала и они хотят еще. Даже готовы заплатить. Ты добавляешь фичу, потом еще и еще. Через пару лет у тебя получается типичный комбайн «все-в-одном».

Можно конечно не слушать пользователей и вообще забить - тогда они просто уйдут и будут пользоваться чем-то еще.

Вообщем зря ты не попробовал свой продукт создать, часть вопросов бы отпали сами собой. Я даже статью написал про то как бывает при разработке продукта.

если трезво спросить «а какую прикладную задачу наша софтина решает»,

Да, конечной прикладной задачи может и не быть. И что? Это нормально если система большая.

На свете существуют кучи закрытых конвертеров, плагинов, каких-то специальных консольных утилит или интеграций, где весь смысл это перекладывание XML из одной системы в другую.

И только где-то далеко наверху будет какой-то видимый для конечного пользователя результат.

Понимаешь, почему разрабатывать собственную систему автоматизации не выгодно для экономики?

Нет не понимаю, потому что это не совсем про экономику. Тут целый спектр вопросов, рисков и решений: ответственность, соотсветствие стандартам, последующая поддержка.

В случае автоматизации аэропорта, проблема не в стоимости а в дальнейшем сопровождении и доработках. С учетом постоянных изменений со стороны регулятора и проверок - это очень непростая задача.

map-filter-reduce

Оно же всё равно при запуске на железе сведётся к циклу for или cmp/jXX, если больше нравится. Уйти от этого очень трудно и непонятно куда, все современные CPU так работают.

С технической стороны тратить миллиарды на поддержание дохлой кошки в хорошей форме — это безумие

Люди уже вложили миллиарды в создание жабной платформы и решений для неё и продолжают вкладывать. Решают свои задачи, имеют с этого профит и даже не догадываются, что у них там что-то сдохло. Есть определённые проблемы (куда без них) — они решаются по мере возможности. Допиливается сама жаба, появляются новые языки, в которых некоторые известные проблемы имеют решение.

Кложа же едет на этом всём (по крайней мере, на опенсурсной его части) верхом совершенно бесплатно, то есть даром. Выкинуть JVM и начать пилить свою нескучную платформу означает отказаться от этого всего великолепия. Понятное дело, это снова потребует миллиардов и человеколет — просто чтобы оказаться в том же самом месте по возможностям, в котором кложа на JVM находится уже сейчас; эти ресурсы, конечно, уже нельзя будет использовать на развитие самой кложи.

Отсюда и вопрос: а стоит ли овчинка выделки?

С их же сайта:

Clojure is a dynamic, general-purpose programming language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language, yet remains completely dynamic – every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

Вообщем суть и смысл существования Clojure это сделать лисп поверх jvm чтобы дергать готовые библиотеки джавы и на них заехать в функциональный рай - когда код выглядит страшно и непонятно но все при этом работает.

суть и смысл существования Clojure это сделать лисп поверх jvm

Типа того — сделать практичный лисп. Запиливать с нуля свою платформу Рич посчитал непрактичным и выбрал JVM как наиболее кошерную по совокупности достоинств. А повёлся бы на камлания господ перфекционистов — и где бы теперь была та кложа? Там же, где Паскаль.

Конечно, платформа и интероп — это ещё не всё. В самом языке тоже должно быть достаточно причин им пользоваться. А то ведь для JVM есть уже и борщелиспа реализация, и схемы — и кто про них слышал.

Я не знаю ни одного полезного массового проекта на FreePascal.

На счёт полезного массового я и не говорил. Но относительно известных могу несколько назвать:

1. «Double Commander».
2. Игровой движок «Hedgewars».
3. Язык программирования «Nim».
4. Какой-то текстовый редактор «CudaText» тут на ЛОРе регулярно рекламируют. По крайней мере, тут он известен и по скриншотам вполне прилично выглядит.

Сам я Паскаль не использую. Для пет-проектов применяю C++. Но он хорош только если мы пишем библиотечки или консольные приложения. Для GUI не очень подходит. Все фреймворки увешаны сырыми указателями и макросами в лучшем случае, а в худшем ещё и свой дополнительный язык с компилятором требуют.

на этом ненужном языке

Понятно, что Питон или C# комфортнее Паскаля для коммерческой разработки. Да и Джава, наверное, тоже. Но Паскаль для опенсорсной разработки приложений с GUI идеологически лучше.

ты можешь натягивать JS на любую задачу

Да, я пытаюсь. Пока что получается именно что «натягивать».

Не важен предмет ­— важны лишь денежные потоки.

Предмет все еще важен, пусть и в раздутом виде. Но честно говоря эта модель уже несколько устарела, так просто уже не работает.

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

Если вебсокеты может освоить даже школьник — это уничтожит рынок.

Нет не уничтожит. Как не уничтожили рынок услуг по созданию сайтов всякие конструкторы и генераторы.

Я утрирую. Например, разработка на MUMPS была кошмарно дорогой и сложной, но теперь этого рынка просто нет, потому что появились намного более эффективные инструменты.

Мне кажется все эти теории заговора про «искусственное устаревание» сильно далеки от реальности. Я еще помню «Сопромат» достаточно хорошо, чтобы ставить под сомнение гарантированную поломку через 3-5 лет.

В реальном мире также нет бинарности «ломается/не ломается». Есть износ, есть степень износа, есть отказы отдельных узлов, в конце-концов есть вопрос ремонтопригодности. Мерседес W124 ремонтировался отверткой и гаечным ключем в дорожный условиях, современные мерседесы не всегда можно починить даже в специализирующейся на мерседесах мастерской.

По поводу 3-5 лет — в самых веселых случаях узлы отказывают уже через 200-500 км пробега. Далее их просто меняют по гарантии, они снова ломаются, их снова меняют по гарантии — и так до конца гарантии. Когда гарантия кончается, то автомобиль остается сдать на разборку и купить новый — так выйдет просто-напросто дешевле.

В умелых руках почему-то ничего не ломается, что стиралки что холодильники что ноутбуки что машины.

Для этого есть условия гарантии, которые запрещают обслуживать автомобиль сверх разрешенного производителем объема.

Ты добавляешь фичу, потом еще и еще. Через пару лет у тебя получается типичный комбайн «все-в-одном».
Можно конечно не слушать пользователей и вообще забить - тогда они просто уйдут и будут пользоваться чем-то еще.

Не надо всех грести под одну гребенку. Добавлять фичи можно по разному — возьми контраст между ранним питоном, в который, как малые дети в рот, тащили всё что лежит на полу и не прибито гвоздями, с поздним питоном, в который даже сам гвидо годами пытался протолкнуть фичи с большим трудом.

Вообщем зря ты не попробовал свой продукт создать, часть вопросов бы отпали сами собой. Я даже статью написал про то как бывает при разработке продукта.

Как это не пробовал, если пробовал? Не столько продукт, сколько пет-проект. На меня оно волнами накатывает: сначала «надо бы сделать прикольную штуку», потом «да оно никому не нужно», потом «программирование не нужно, пойду работать проституткой».

Нет не понимаю, потому что это не совсем про экономику. Тут целый спектр вопросов, рисков и решений: ответственность, соотсветствие стандартам, последующая поддержка.

Даже со всей последующей поддержкой сумма слишком большая.

Оно же всё равно при запуске на железе сведётся к циклу for или cmp/jXX, если больше нравится. Уйти от этого очень трудно и непонятно куда, все современные CPU так работают.

На видеокартах не сводится. На распределенных системах не сводится. x86 безнадежно устарел ­— с этим мы вроде определились.

Кложа же едет на этом всём (по крайней мере, на опенсурсной его части) верхом совершенно бесплатно, то есть даром. Выкинуть JVM и начать пилить свою нескучную платформу означает отказаться от этого всего великолепия.

Ну я привел пример с имперской системой в штатах — ты экономишь миллион сегодня ценой десяти потерянных миллионов в следующие 10 лет. И таки экономическая модель подобные решения поощряет.

Понятное дело, это снова потребует миллиардов и человеколет — просто чтобы оказаться в том же самом месте по возможностям

Я в каком-то из недавних обсуждений уже писал, что многие из этих «возможностей» раздуты на пустом месте, как треснувшие тарелки, которые достались от любимой бабки, и в память о ней их не выбрасывают. И вот ты задаешь вопрос «а где мне взять столько сколотых и треснутых тарелок, чтобы как от бабки были?». А я и ответчаю «а может быть они просто не были нужны изначально?».

А бизнес отвечает «да, тащите сюда все тарелки, и половинки тарелок тащите, всему найдем применение» — это называется «энтерпрайз».

Вообщем суть и смысл существования Clojure это сделать лисп поверх jvm чтобы дергать готовые библиотеки джавы и на них заехать в функциональный рай - когда код выглядит страшно и непонятно но все при этом работает

Лисп там с боку-припёку, можно было брать почти любой сорт ЯП и лепить его поверх персистентных структур данных — суть бы мало поменялась. Так-то лисп не более функциональный, чем JavaScript.

Типа того — сделать практичный лисп. Запиливать с нуля свою платформу Рич посчитал непрактичным и выбрал JVM как наиболее кошерную по совокупности достоинств. А повёлся бы на камлания господ перфекционистов — и где бы теперь была та кложа? Там же, где Паскаль.

При чем тут перфекционизм? Перфекционисты так и пишут на CL. Тут вопрос маркетинга, где целевая аудитория — тупое высшее руководство очередной наперсточной корпорации, для который идеальное решение — это когда ничего не нужно менять и ничего не нужно делать, а при этом все проблемы решаются сами собой.

можно было брать почти любой сорт ЯП и лепить его поверх персистентных структур данных

Макросов не будет, прощай синтаксическая абстракция. Нужна новая управляющая конструкция? Страдай, умоляй, жди релиза. (В котором завезут ещё восемь шматков синтаксиса, которые тебе на хер не облокотились, а учить придётся — здравствуй, жопа, новый скрипт.)

Скажем дружно — нах ненужно! %)

Например, разработка на MUMPS была кошмарно дорогой и сложной,

Стесняюсь спросить а где ты вообще успел до этого дорваться? Это же очень древняя штука, артефакт до SQLных времен.

Я сам видел лишь осовремененный варинант - Cache’ , такая французская система. Использовалась у кого-то из страховщиков крупных.

Есть износ, есть степень износа, есть отказы отдельных узлов, в конце-концов есть вопрос ремонтопригодности.

Все прекрасно понимаю, но подогнать все это под теорию об искусственном устаревании все равно не выходит.

Мерседес W124 ремонтировался отверткой и гаечным ключем в дорожный условиях, современные мерседесы не всегда можно починить даже в специализирующейся на мерседесах мастерской.

То что был (и есть) класс граждан, покупающих S-класс на последние деньги чтобы потом чиниться у кузмичей в гаражах не повод видеть везде подвох и бить тревогу. Даже в нынешних непростых реалиях постоянно вижу абсолютно новые мерсы на дорогах, которые вполне себе чинят и обслуживают.

По поводу 3-5 лет — в самых веселых случаях узлы отказывают уже через 200-500 км пробега.

200км пробега это наверное меньше недели езды, ты ничего не путаешь?

Для этого есть условия гарантии, которые запрещают обслуживать автомобиль сверх разрешенного производителем объема.

Тесла?

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

Видимо история с 2.х и 3.х ветками пошла на пользу. Люди познали смысл стабилизации.

Даже со всей последующей поддержкой сумма слишком большая.

В той статье есть расчеты и обоснование что это практически себестоимость если не вообще минус. Это же государственный тендер, там сложная приемка и факторы соответствия как для космонавта. Ну и ответственность - встанет аэропорт из-за кривого софта, кивнут на подрядчика и будет минимум проверка. Вообщем там правильно обозначили что даже теоретически взяться за такую работу могут компаний 10 в РФ, не больше.

Перфекционисты так и пишут на CL

Я бы ещё понял на хаскелле, но CL и перфекционисты звучит как название песни КиШа.

На видеокартах не сводится. На распределенных системах не сводится. x86 безнадежно устарел ­— с этим мы вроде определились.

И ты решил что стандартные задачи ввода-вывода и отрисовки кнопок внезапно станут идеально ложиться на распределенный кластер или видеокарту?

Проблема твоей идеи в том что ты хочешь предложить некую новую характеристику (ценой слома всего существующего по до основ), под которую просто нет задач.

x86 может еще трижды устареть но он блин идеален для любого софта работающего на обычном десктопе и не решающего расчетные задачи.

что многие из этих «возможностей» раздуты на пустом месте, как треснувшие тарелки, которые достались от любимой бабки, и в память о ней их не выбрасывают.

Пока есть такая штука как «обратная совместимость» - любой популярный язык будет представлять из себя «набор инструментов», где лишь 10% тулов используется типичным пользователем. И это нормально и ожидаемо, потому что на другой стороне весов вопли «не работает» при запуске чего-то непопулярного или нестандартного.

Десяток таких воплей и получаем удар по репутации и отказ от использования.

пример с имперской системой в штатах — ты экономишь миллион сегодня ценой десяти потерянных миллионов в следующие 10 лет.

Вот если бы у тебя вместо имперской JVM уже была готовая метрическая YobaVM со всеми нужными фишечками и наворотами, протестированная миллионами пользователей на протяжении десятилетий, чтобы осталось только перейти… Но ведь у тебя её нет.

Впрочем, даже если бы была — кто будет всё нажабленное за все эти годы переписывать?

А бизнес отвечает «да, тащите сюда все тарелки, и половинки тарелок тащите, всему найдем применение» — это называется «энтерпрайз».

Потому что люди привыкли деньги считать и не привыкли просто так, низачем, выбрасывать то, что работает и решает задачи. Экономика, рациональное использование редких ресурсов и всё такое.

Стесняюсь спросить а где ты вообще успел до этого дорваться? Это же очень древняя штука, артефакт до SQLных времен.

Сам залез для интереса, я все-таки довольно близко к этой сфере крутился много лет. Вообще. это не единственный вариант ЯП, встроенного в БД, но наиболее всратый из известных истории — брейнфак рядом с этой радостью ощущается вполне нормальным ЯП.

Все прекрасно понимаю, но подогнать все это под теорию об искусственном устаревании все равно не выходит.

Что не получается? Не получается понять последствия замены стальной втулки на пластиковую?

Даже в нынешних непростых реалиях постоянно вижу абсолютно новые мерсы на дорогах, которые вполне себе чинят и обслуживают.

Починить и обслужить можно многое — вопрос в том СКОЛЬКО ЭТО БУДЕТ СТОИТЬ. Например, блоки управления двигателем к старым мерседесам просто не продаются. Совсем. Разве что с разобранного авто можно снять. Отдельные умельцы восстанавливаются дорожки, как те челы, ремонтирующие блоки сименса.

200км пробега это наверное меньше недели езды, ты ничего не путаешь?

Да, примерно так. У меня знакомый примерно каждую неделю выгуливал свою вольву в сервис.

Для этого есть условия гарантии, которые запрещают обслуживать автомобиль сверх разрешенного производителем объема.

Тесла?

Нет, обычное бензиновое авто, но помню уже какие производители так делают, но их больше одного.

В той статье есть расчеты и обоснование что это практически себестоимость если не вообще минус.

В той статье есть бред умалишенного и взятые с потолка цифры, я не увидел там никакого обоснования. Причем, комментаторы со мной согласны.

Вообщем там правильно обозначили что даже теоретически взяться за такую работу могут компаний 10 в РФ, не больше.

А потом окажется, что к тендеру допустили только «своих».

Я бы ещё понял на хаскелле, но CL и перфекционисты звучит как название песни КиШа.

Я честно не понимаю психологию людей, пишущих на старых лиспах, потому я тут не специалист — может быть это и не перфекционисты. Но это ты вроде писал про перфекционистов-лисперов — может тогда пояснишь, о чем они думают?

И ты решил что стандартные задачи ввода-вывода и отрисовки кнопок внезапно станут идеально ложиться на распределенный кластер или видеокарту?

Да. Более того, именно эти задачи уже прекрасно ложатся на распределенный кластер и видеокарту соответственно.

x86 может еще трижды устареть но он блин идеален для любого софта работающего на обычном десктопе

Не забывай, что даже AArch64 выполняет те же расчеты на кристалле в 2 раза меньше размера, со всеми вытекающими.

Bell, James R. (1973). «Threaded code». Communications of the ACM.

форт хипстерский хайп

кузья мать шитый код

Пока есть такая штука как «обратная совместимость» - любой популярный язык будет представлять из себя «набор инструментов», где лишь 10% тулов используется типичным пользователем. И это нормально и ожидаемо, потому что на другой стороне весов вопли «не работает» при запуске чего-то непопулярного или нестандартного.

Я попросил объяснить феномен имперской системы. Ладно, не можете, это вроде как далеко от айтишной тематики — тогда я приведу более близкие к айти пример: почему C++ унаследовал всю убогую сишную часть языка почти без изменений (они появились сильно позже)? С технической стороны Си был не нужен в C++, причем, по итогу C++ пришел к несовместимости с Си и необходимостью блоков extern C. Зачем в новый язык включили старый? Еще раз: для интероперабельности с Си не нужно включать Си в состав C++.

А я могу сказать почему — потому что у манагеров начинают труситься коленки, когда они слышат про «что-то менять» или «чему-то обучать сотрудников», потому что они понимают, что в архитекторах сидит дед Мазай, который Рузвельта живым помнит, он всю жизнь писал на Си, и даже на C++ он будет писать только если это будет Си. Я столько видел людей, которые на новом ЯП пишут как на старом, что мне уже даже не смешно и я прекрасно могу понять манагеров. Вопрос, конечно, в том, кто набрал этих манагеров и архитекторов, но вопрос риторический, потому что ответ на него известен — тот, кто во всех технических вопросах разбирается еще меньше.

У меня нет никаких претензий, если кто-то использует рабочую систему на Ada — вопрос был про новые разработки, что, мол, у них нет поддержки старого засохшего говна — как делать чистый унитаз и тащить в него говно из старого.

Вот если бы у тебя вместо имперской JVM уже была готовая метрическая YobaVM со всеми нужными фишечками и наворотами, протестированная миллионами пользователей на протяжении десятилетий, чтобы осталось только перейти

А теперь скажи, как вообще может появиться YobaVM с заданными характеристиками? Да что там YobaVM — как JVM смогла достичь такого состояния?

Потому что люди привыкли деньги считать и не привыкли просто так, низачем, выбрасывать то, что работает и решает задачи.

А также то, что эти деньги пожирает как не в себя, ага. Еще раз: я не против использования старых рабочих решений — я против того, чтобы тащить старое говно в новые решения.

как вообще может появиться YobaVM с заданными характеристиками? Да что там YobaVM — как JVM смогла достичь такого состояния?

• она должна была существовать и работать, чтобы ей можно было пользоваться — бабло и усилия
• она должна была быть привлекательной для пользователей (developers! developers!), помогать им решать насущные проблемы лучше имеющихся платформ, чтобы они ей, собственно, пользовались — писали под неё то, это и ещё вон то. Что там было по платформам в то время? Какие были проблемы — ручное управление памятью? проприетарность?

эти деньги пожирает как не в себя, ага

Чтобы что-то сделать, нужно потратить определённые ресурсы. Не бывает волшебных платформ с бесплатной разработкой и поддержкой.

я против того, чтобы тащить старое говно в новые решения

Колхоз ведь дело добровольное. Не хочешь — не тащи.

... я против того, чтобы тащить старое говно в новые решения.

Рекурсивное суждение.

Например, блоки управления двигателем к старым мерседесам просто не продаются. Совсем.

Спаяй спидуину у себя в гараже. Ты что, не опенсорсник?)

Зачем в новый язык включили старый?

Самое смешное что ответ на этот вопрос будет очевиден любому продажнику: потому что так проще продавать и продвигать.

В который раз ты правильно подмечаешь следствия:

Я столько видел людей, которые на новом ЯП пишут как на старом

Но не понимаешь причину.

что в архитекторах сидит дед Мазай, который Рузвельта живым помнит, он всю жизнь писал на Си

Это называется экспертиза, нельзя быть экспертом сразу во всех областях - банально жизни не хватит. Очевидно что экспертиза в чем-то одном сразу сужает кругозор, поскольку на другие области времени нехватает.

Поэтому абсолютно любой эксперт в чем-то для других людей выглядит как этот самый «дед Мазай», даже ты.

Да. Более того, именно эти задачи уже прекрасно ложатся на распределенный кластер и видеокарту соответственно.

Чето не уверен, от слова совсем. Если что то на десктопе типичная задача - короткая и атомарная, нет долгих вычислений практически. NUMA слабо подходит для такого, по крайней мере исходя из того что я о ней знаю.

Не забывай, что даже AArch64 выполняет те же расчеты на кристалле в 2 раза меньше размера, со всеми вытекающими.

Опять же исходя из моих знаний о Objective-C и Cocoa весь эффект плавности достигается тщательной подгонкой софта, не железом. Сам процессор очевидно медленее чем топовые версии от AMD/Intel.

я против того, чтобы тащить старое говно в новые решения.

Знаешь я делал такую ошибку пару раз: запускал разработку на чем-то действительно новом на тот момент. Заканчивалось это печально, потому что «новое и интересное» брало и сдувалось.

Один из примеров вот этот замечательный css фреймворк, когда-то была отличная перспективная замена для разжиревшему Bootstrap. Видишь дату изменения 9 лет назад?

А дальше у тебя очень простая вилка решений, те самые «два стула»: либо ты тянешь технологию сам своими силами либо сам же за свои деньги и время переводишь на что-то другое.

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

А если бы это был компилятор?

Сам процессор очевидно медленее чем топовые версии от AMD/Intel.

Раскочегарить арм до скоростей x86 наверное можно, и не сомневаюсь, что аппле к этому придёт в мак-про и прочих десктопах. Но оно и жрать будет плюс-минус как x86, физика.

Читаю маководов про поджаривание яиц пользователя при запуске вонючего Ableton на арме и как-то не верится в сказки про супер-эффективность.