Новые языки программирования незаметно убивают нашу связь с реальностью



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

    Что там будет под капотом, ни одна живая душа уже не поймет. Команда «хреновина» интерпретируется в абзац с описанием, который интерпретируется в ключевые слова, который интерпретируется в набор векторных обозначений, который интерпретируется в какой-нибудь С, который скомпилируется в…

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

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

    Просто я задумался — а не стали ли наши ЯПы уже чем-то таким? Чуть более умным эквивалентом фразы «компьютер, сделай хреновину». Кучей формализованных протоколов для электричества, про которое мы уже забыть забыли. Штукой, которая все сильнее рвет нашу связь с механической реальностью.

    Я часто слышу фразу: «Фил, отступись, хватит думать обо всякой чепухе». Но блин, будь проклят тот день, когда на Хабре напишут «хватит думать».



    У меня на работе много небольших проектов, и мы используем разные стеки — .net, React.ts, c++, Java. В чем ты хоть немного прошарен, то на тебя и повесят. Я пришел как дотнетчик, но таски на доске есть на все приложения, доступ к репозиториям — тоже.

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

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

    Я просто делал одно и то же на разных языках программирования. Этот код был очень похожим, за исключением деталей, которые никак не влияют на решаемую задачу. Ведь бизнес не приходит ко мне со словами: «Эй Фил! Нам нужно использовать абстрактные классы, чтобы отобразить клиенту состояние впн соединения». Бизнес и пользователи хотят, чтобы девайс показал им картинку. Да и я на самом деле тоже просто хочу показать им эту картинку.

    Но я не могу. Нельзя просто сказать машине: делай то, что мне нужно. Пока еще я тот самый промежуточный интерпретатор, который превращает фразу «сделай хреновину» в команды, пока еще мне приходится детально и пошагово разъяснять процессору, куда и как класть долбаные байты.

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

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

    Дотнетный компиль превращает мой сишарп в промежуточный язык (IL), который едет на машину к клиенту, где в свою очередь другой дотнетный компиль (который just-in-time) на лету превращает мой IL в платформоспецифичный код, который в свою очередь скармливается процессору…

    И где-то там все мои формальные описания, все различия между ЯПами стираются, и делают одно и то же. На пальцах:

    Я знаю, что процессор знает команду O1. Получив ее, он пульнет электричеством во встроенный микродинамик, у того что-то где-то перемкнет и раздастся писк.

    И вот я на сишарпе пишу:

    using System;
    Console.Beep(500,500);

    Эта строка у меня превратится в О1

    Я пишу на плюсах:

    #include <windows.h>
    
    Beep(500,500);

    И она тоже превратится в О1.

    Я что, должен думать, почему здесь System.Console, а там windows.h? Но мой мозг это запоминает, а таких специфичных деталей дофига, они совсем разные. Рано или поздно деталей становится так много, что мой выбор ЯПа становится не логическим, а просто потому что мне так больше нравится.

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

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

    И вот сидя над дизайном очередного модуля, я подумал — а что бы сказал старина фон Нейман и его команда, когда услышали о моих проблемах? Те самые парни, которые конструировали свои принципы хранения данных и доказывали идиотам, что двоичная система для машин лучше, чем десятичная.

    Они бы не офигели от нашего количества абстракций ради абстракций? Смогли бы принять, что в 2019 все чаще выбирают абстракции чисто эстетически и этим размывают связь с выполнением на машине.

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

    Каждый раз, когда очередной стартапер думает «да че там случится с моей нодой, когда я все перевезу с x86 на ARM. Вся эта низкоуровневая фигня меня не касается», мы все дальше и дальше от реального контроля над задачами. Язык общения с машиной стал почти человеческим. Но похоже, это не работает так, как задумано.



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

    Один мой друг-гуманитарий (эй, уберите револьверы, мы же все с вами притворяемся, что с гуманитариями можно дружить, я — не исключение) написал рассказ. Заявил мне, что я, как друг, должен его прочитать. Я долго отлынивал. Но он меня достал, и я прочитал. И это оказался один из тех случаев, когда гуманитарные знания улучшили мои навыки разработчика. Смотрите.

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

    Когда бизнес приносит мне задачу «Эй, Фил, сделай хреновину», что вообще происходит у меня в мозгу? Сколько ступенек интерпретации проходит, пока звуковая волна, отскакивая от моих ушей, превращается в сигналы и пробегает по нейронам мозга куда надо. Я об этом вообще не думаю, это происходит само.

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

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

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

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

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

    Но еще больше я боюсь другого. Высокоуровневые ЯПы настолько изменят мое мышление, что мысль «все плохо» просто физически не сможет зародиться в моей голове. Я точно уверен, что естественный язык, на котором я говорю, очень серьезно влияет на мое сознание. Если я русский, то десять поколений моих предков диктуют мне, как я должен думать с помощью языка, который я от них унаследовал. Языка, который устроен, например, так, что в любом предложении о случившейся проблеме — должен быть виноватый. Даже если я говорю «случилась херня» — виновата все равно херня. А, например, в испанском такого нет. Случилось и случилось (и даже сейчас по-русски подразумевается, что случилось «что-то»).

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

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

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

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

    Похожие публикации

    Комментарии 757

      +40
      Вся компьютерная индустрия, начиная со второго поколения компьютеров — бесконечная попытка забыть тот ужас, который нас ждёт с initial orders и осцилографом. Попытка забыть этот ужас порождает новый ужас (обычно меньшего размера), и идёт ещё одна попытка забыть ужас.

      Если серьёзно — задача всего компьютерного — абстрагирование и уменьшение сложности. Каждый раз, когда сложность уменьшается, мы можем сделать больше (чем раньше) всего лишь восстановив уровень сложности. А потом ещё раз его уменьшить.

      … Проблема начинается в тот момент, когда нижележащий уровень перестаёт прятать сложность и оно взрывается как пружина. Обычно люди просто стараются увернуться (включить/выключить, попробовать ещё раз), а не выяснять что именно там случилось.
        +7
        Я хорошо помню, как году в 2009 смотрел на Rails.
        Когда смотришь на готовый проект (что пример, что просто хороший чужой код) и всё очевидно. Начинаешь делать что-то сам — и упираешься в дикие ограничения, при решении которых натыкаешься либо на готовые сниппеты (магия!), либо городишь дикий код.
        Потом начинаешь оборачивать дикий код в магию.

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

              Замените рельсу на SQL — ничего не изменилось.

                +5
                Рекорд, который я не знаю, будет ли побит когда-либо установил Пролог.

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

                Но при этом достаточно в первой же нетривиальной программе из любого учебника по Прологу поменять две строки местами (а это, как понятно, «информацию о предметной области» не меняет) — и привет: программа зациклится и упадёт, сожрав предварительно всю память.

                Блеск!
                  +1
                  Вроде бы должно быть каждому понятно, что из описания нетривиальной задачи её эффективное решение не следует. Или, например, что связки И/ИЛИ на практике не коммутативны.
                    0
                    Пробел пропустил. Имеется в виду «не тривиальная» задача, а не «нетривиальная».

                    Как правило первая не тривиальная задача в учебниках — это набор фактов из Библии (пролог ещё до эпохи толерантности появился, там на Библию ещё можно ссылаться). Набор фактов вида «Исаак родил Иакова» и правила вывода (два):
                    1. Если A родитель B, то A — предок B.
                    2. Если A родитель B, а B — предок C, то A — предок C.
                    Так вот если эти правила поменять местами, то программа «рассыплется».

                    Восхитительная «декларативность».
                      +1
                      Подождите, но тут всё достаточно логично (как для человека, который никогда не видел пролог). В правиле №2 должно быть известно что такое «предок», т.к. это нужно для интерпретации части условия («а B — предок C»). Или пролог даёт какие-то гарантии того, что порядок задания правил не важен?
                        +2
                        Оба правила вместе описывают что такое предок.

                        Но с точки зрения человека последовательность этих правил — неважна. Такое определение: «предок твоего папы — это твой предок… ну и твой папа — тоже твой предок» — человек поймёт.

                        А с точки зрения Пролога — важна. «Предок твоего папы — это твой предок… ну и твой папа — тоже твой предок» — Пролог не поймёт. Зациклится. Где декларативность?
                          –2
                          Может быть она просто не абсолютная декларативность?

                          Как человек понимает эту фразу? Он считывает, входит в цикл, пытается найти определение предка, находит его, возвращается в цикл и разрешает его.

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

                          Думаю можно сделать язык который все не явные противоречия разрешает, но возможно просто не достаточно вычислительных мощностей.
                            0
                            Я прекрасно понимаю почему Пролог не декларативен. Но это уже второй вопрос. Первый — это описываем ли мы задачу в терминах предметной области или «в порядке, в котором машине будет легче понимать». И тут — Пролог «проваливается» по полной. У нас в проекте много разных декларативных описаний (не универсальных, конечно) и ментальная проверка «а что будет, если мы это описания случайным образом перемещаем» — первое, что делается, когда DSL разрабатывается.

                            И да, то, что Пролог — не декларативен неделает его бесполезным. Но я не понимаю почему его все пытаются «продавать» как декларативный язык — притом что он таким ни разу не является.
                        0
                        Это пример практической некоммутативности связки ИЛИ. Например, выбор на дороге: 1) налево — потеряешь голову, 2) направо — получишь приз. От того какой путь выбрать первым зависит как пойдут дела. :) Так и и пролог. Проблема не в нем, а в природе логики.
                          +4
                          Это пример практической некоммутативности связки ИЛИ.
                          Извините, но это бред. Эти два правила для любой пары объектов дают ровно один ответ на вопрос «является ли Исаак предком Иакова» — независимо от порядка.

                          Например, выбор на дороге: 1) налево — потеряешь голову, 2) направо — получишь приз. От того какой путь выбрать первым зависит как пойдут дела. :)
                          Это называется — императи́вное программи́рование

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

                          Пролог просто является классической подменой понятий: вначале нам объясняется, что Prolog является декларативным языком программирования, а потом — объясняется как работает Prolog-машина и оказывается, что мы должны не писать декларативное описание этой задачи, а программировать вот эту вот, вполне императивную, машину…
                            –1
                            Если вы хотите сделать что-то с практическими результатами, вам придется разбираться с порядком применения правил — равноправия на практике обычно не получится. Перепишите мой пример в виде «налево — потеряешь голову» ИЛИ «направо — получишь приз» — какая тут императивность, 100% декларативность, но от того, за что вы возьметесь в первую очередь, зависит результат.
                              0
                              Какая разница для связки, что вы делаете в первую очередь?

                              В этой нашей теории типов A V B кодируется как ∀C: *. (A → C) → (B → C) → C. То есть, для любого действия, выполняемого и при походе налево, и при походе направо, разницы таки нет совсем.
                                –1
                                Если вам нужна теория для её самой, то разницы о очередности нет, а если вы что-то хотите от теoрии практического, то есть. Это и отражается в прологе, как в практическом инструменте. Если кто-то останется без головы, то приз получать уже будет никому. Декларативность предполагает обычно слишком много вариантов и зацикливание — это тоже вариант. От перемены местами дизъюнктов в вашем примере вы его и получаете. В 90-е кто-то предлагал вариант пролога с со случайным выбором — интересный подход, но, полагаю, что он сильно понижает производительность работы. Кому нужен ответ, полученный через 100 лет? Получается выбор: 1) изобретать замысловатые системы логики, конкурировать с Аристотелем; 2) пытаться сделать эффективные машины логического вывода — это пролог, SQL, скорее неудачный и несостоявшийся меркурий,…
                                  +1
                                  Ещё раз, для идиотов. Цитирую:

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

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

                                  Так вот спецификация — не должна превращаться в тыкву при перестановке двух строк местами. Это уже не «описание проблемы», а бог-знает что.

                                  Можно сколько угодно рассказывать про сложности работы со спецификациями, но практически — вы либо умеете с ними работать, либо нет. Пролог — не умеет. Он умеет работать только со специцикациями заточенными под Пролог-машину и учитывающими то, что у неё «под капотом». Какая тут, нафиг, декларативность?
                                    +2
                                    Исключительно ради занудства, а не для того чтобы с кем-то о чем-то поспорить:
                                    Какая тут, нафиг, декларативность?
                                    Ответ — ограниченная. У пролога декларативность ограничена тем что у него под капотом. Но это не делает его не декларативным, это делает его «всего лишь» бесполезным на практике.
                                      0
                                      3ря вы так. Пролог или какое-то его удачное расширение — это будущее программирования. Пролог это почти 100% математика, тогда как другие языки — это смесь математики и отсебятены.
                                      Вы похоже склоняетесь к точке зрения оппонента, что декларативность гарантирует поиск результата. Но это так только в случае действительно 100% точного описания задачи. Порядок дизъюнктов — это один из элементов такой точности.
                                        0
                                        Пролог или какое-то его удачное расширение — это будущее программирования
                                        Он может быть и будущее, но на данный момент он все равно бесполезен на практике. Одно никак не противоречит другому.
                                        Вы похоже склоняетесь к точке зрения оппонента, что декларативность гарантирует поиск результата.
                                        Мой комментарий был вообще не об этом. Мой комментарий был о двух вещах — о том, что пролог крайне ограничен в множестве задач на которых его можно применять и, следовательно, не помогает в решении практических задач. Но при этом он остается декларативным, ограниченность принципу декларативности не мешает насколько я понимаю. Даже математически не мешает.
                                          0
                                          Он может быть и будущее, но на данный момент он все равно бесполезен на практике.

                                          Не могу с таким согласиться. Существует достаточно много перспективных проектов вокруг пролога. Пролог — универсальный язык и на нём можно делать всё, что, например, на питоне. Может просто нужен кто-нибудь типа Гвидо, который сделает популярный вариант пролога. Скорость работы хороших прологов на уровне языков сценариев. Мне кажется полезность-перспективность и текущая массовая популярность — это разные вещи. Мое мнение — пролог это один из самых простых и близких к естественному языков программирования. К сожалению, приходится до сих пор больше работать сo скорее с потомками фортрана. :(
                                            +1
                                            Существует достаточно много перспективных проектов вокруг пролога.
                                            Только перспективных или уже реально широко используемых? Если первое, то с его возрастом это диагноз на мой взгляд. Если второе, то интересно было бы посмотреть на пример.
                                            Понимаете, это же достаточно объективно — если инструмент полезен и достаточно стар чтобы его успели попробовать, то на нем будут что-то делать. Если инструменту много лет, о нем много кто знает, но при этом ничего практического на нем нет — значит он бесполезен.
                                              0
                                              Не всегда это говорит о бесперспективности. Нейронные сети исследуются полвека, но активно использоваться стали лет 10 назад, не больше. Но там понятно чего не хватало: скорости. Традиционные подходы сложнее в программировании, но требуют на порядки меньшие ресурсы.

                                              А чего Прологу не хватает, интересно? У меня есть ощущение, что как раз декларативности: современные системы многопоточны (а GPU — так сильно многопоточны), но как раз декларативно описанные задачи параллелятся «в лёгкую», а вся семантика Пролога завязана на его однопоточную машину…
                                                0
                                                Не всегда это говорит о бесперспективности.
                                                Я и не говорил «бесперспективный», я говорил «бесполезный», что предполагает выгоду от его использования сейчас, а не когда его наконец-то допилят. Допилят ли, и может ли оно взлететь тогда — отдельный вопрос.
                                                0
                                                Довольно много проектов, связанных с машинным обучением с использованием обучаемых сетей. Также есть проекты для работы с естественным языком. Всего тут довольно много и меньше не становится. Почему процент пролог-проектов в целом небольшой? Возможно потому, что сложилась некая культура программирования на С-подобных языках (возьмем, например, APL, оберон, аду или эйфель — их тоже не больше, а скорее меньше, чем пролога), к которой привыкли и которая пока адекватна решаемым задачам. Пролог требует специальной подготовки, которой нет у многих топовых специалистов. В самом прологе не хватает многих отточенных на типовые задачи механизмов, которые появятся только, если сделать его очень популярным. Вокруг специального железа для пролога какой-то туман, возможно секретности. И, могу предположить, что широкое внедрение пролога сделает большинство ЯП устаревшими, к этому пока не готовы.
                                                  0
                                                  Примеры проектов покажете? Интересны именно проекты, которые можно использовать.
                                                    0
                                                    К сожалению, прологом сейчас практически не занимаюсь. Но посмотрите страничку в википедии: Watson — очень серьёзная система и работает в штатном Линуксе. Там же приводится цитата: «We required a language in which we could conveniently express pattern matching rules over the parse trees and other annotations (such as named entity recognition results), and a technology that could execute these rules very efficiently. We found that Prolog was the ideal choice for the language due to its simplicity and expressiveness.» Pазработка компиляторов с использованием пролога имеет несколько неоспоримых достоинств. Погуглите prolog projects и обнаружите десятки развивающихся систем программирования, основанных на идеях пролога. Аналогично, prolog deep learning. Если вы проведете подобные изыскания по аде, коболу, эйфелю и др. не самым распиаренным языкам, то найдёте, что у пролога всё относительно неплохо. Предположу, если кто ищет себе комфортабельный вагончик, то пролог пока ещё до этого не созрел. А тому кто хочет быть локомотивом, пролог предоставляет огромное и очень перспективное поле для деятельности.
                                        –2
                                        Вам привели пример, что описание задачи может приводить к разным результатам. И ваш пример о том же. А вы что хотите, чтобы машина ещё и знала, что Вам нужны предки библейских персонажей немедленно, а не её усердная работа по их поиску на миллионы лет? Хотеть не вредно. Но лучше давать машине уточнения в таких случаях. В прологе такие уточнения — это, в частности, порядок дизъюнктов и предикатов в них. Предлагаю учить пролог и yчить тщательно!
                        –2
                        SQL вполне себе императивен, если вы освоили концепцию «вложенных циклов»
                          +2
                          Ну, можно и суп палочками есть…
                      +5
                      Да ну, перешёл с джавы на си для своих проектов — наоборот, всё стало гораздо проще. Не нужно писать ненужный бойлерплейт в угоду ООПшным шаблонам проектирования, питать надежды, что всё это влезет в память, а не упадёт с OOM, профилировать перформанс — и так ясно, что всё предельно быстро будет и без задержек на GC, не нужно думать о том, откуда на клиентском устройстве JVM возьмётся, почти не нужен рефакторинг, т.к. без классов функции никак друг с другом не связаны.
                      Отличный язык для быстрого прототипирования) Просто фигачишь функции и они просто работают)
                        +15
                        всё предельно быстро будет

                        Аллокатор, я надеюсь, у вас тоже не требует синхронизации между потоками? И программа работает на x84/x64/arm/aarch64 без компиляции? И векторизация инструкций тоже будет использоваться, да? И порядок инструкций поменяется на лету, ради скорости, да?


                        без задержек на GC

                        Аллокатор не фрагментарнтирует память, да? И free у Вас работает в отдельном потоке, как на Java, да?


                        не упадёт с OOM

                        Модель памяти у Вас простая, сама память не течёт, грязную память вы не используете, да?


                        Отличный язык для быстрого прототипирования)

                        А для боевого применения?


                        на клиентском устройстве

                        А отладку сможете делать на нем, если у Вас на рабочей машине другая ОС/архитектура процессора?


                        Если подытожить: Ваши аргументы крайне спорные. И далеко не так очевидно, что С быстрее, удобнее и т.д.

                          +4
                          Аллокатор, я надеюсь, у вас тоже не требует синхронизации между потоками?
                          Не требует.
                          И программа работает на x84/x64/arm/aarch64 без компиляции?
                          Какая разница, +1 архитектура — всего лишь строчку в мейфайл добавить и поставить компилятор, что куда проще и симпатичнее, чем например, jvm под iOS запихнуть в дистрибутив приложения.
                          И векторизация инструкций тоже будет использоваться, да?
                          Да, автовекторизация и прочие оптимизации весьма недурно производительность поднимают.
                          И порядок инструкций поменяется на лету, ради скорости, да?
                          Если порядок меняет результат вычисления, и при этом нет грубых нарушений правил языка, ничего не поменяется.
                          Аллокатор не фрагментарнтирует память, да? И free у Вас работает в отдельном потоке, как на Java, да?
                          На практике вклад malloc/free во время исполнения с лупой искать надо.
                          Модель памяти у Вас простая, сама память не течёт, грязную память вы не используете, да?
                          Да вроде не течёт, тем более сама)
                          А для боевого применения?
                          Проще 1 раз на 1 языке написать, чем писать на # под венду, java на андроид, swift на ios и js для веба. Для этого не так много языков годится.
                          А отладку сможете делать на нем, если у Вас на рабочей машине другая ОС/архитектура процессора?
                          Для отладки компилятор зашивает в бинарник всё необходимое, при чём здесь ОС и процессор. В С я могу включить в отладочных целях проверки обращения к памяти например, как в той же Java, в релизе могу выключить и получить прирост производительности, а в Java — нет, не доверяет она разработчику.
                            +5
                            всего лишь строчку в мейфайл добавить и поставить компилятор
                            Это так просто не работает.
                            +3
                            Проще 1 раз на 1 языке написать, чем писать на # под венду, java на андроид, swift на ios и js для веба. Для этого не так много языков годится.

                            Покажите ваш проект на си, чтобы один раз, да сразу для iOS и для веба и для винды.
                              –1
                              Пока рано что-то показывать, однако не вижу, что мне помешает OpenGL приложение собрать под разные платформы. Схема «пишу под десктоп — иногда поглядываю, что там на андроид» уже работает, хотя конечно под андроид отдельная обёртка и шейдеры отличаются и OpenGL ES вместо обычного OpenGL, и отдельный проект в Android Studio, но сишное ядро приложения одно.
                                +6
                                Между «теоретически возможно» и «устоявшаяся технология, экономящая время» огромная пропасть. И она, с огромной долей вероятности, для Си не будет преодолена.

                                Схема «пишу под десктоп — иногда поглядываю, что там на андроид» уже работает, хотя конечно под андроид отдельная обёртка и шейдеры отличаются и OpenGL ES вместо обычного OpenGL, и отдельный проект в Android Studio, но сишное ядро приложения одно.

                                Получается не один раз, а под каждую платформу придётся писать что-то, а переиспользуется только какая-то небольшая часть? Я вам подскажу, таким занимается куча людей из устоявшихся технологий, и пока даже просто между iOS и Android настолько большая разница, что всё чаще возникают вопросы имеют ли смысл все эти Xamarin и React Native, если приложение больше пары простых скринов.
                                  0
                                  Си как-то странно причислять к неустоявшимся технологиям, языку ~50 лет, инструментов и кейсов применения для него наработано огромное количество, множество платформ имеют официальную поддержку, есть стандарты, при соблюдении которых эта поддержка гарантирована.
                                  Получается не один раз, а под каждую платформу придётся писать что-то, а переиспользуется только какая-то небольшая часть?
                                  Переиспользуется как раз почти всё, написание чего требовало каких-то усилий. Обёртка под андриод — уровня хэлловорлда, причём даже не написанная, а тупо позаимствованная из NDKшных примеров.
                                  Я вам подскажу, таким занимается куча людей из устоявшихся технологий, и пока даже просто между iOS и Android настолько большая разница, что всё чаще возникают вопросы имеют ли смысл все эти Xamarin и React Native, если приложение больше пары простых скринов.
                                  Ну если есть деньги на N команд разработки, то почему бы и не писать под каждую платформу отдельно. У меня нет)
                                    +2
                                    Си как-то странно причислять к неустоявшимся технологиям, языку ~50 лет, инструментов и кейсов применения для него наработано огромное количество, множество платформ имеют официальную поддержку, есть стандарты, при соблюдении которых эта поддержка гарантирована.

                                    Вот только использование Си для написания приложений сразу под веб и все остальные платформы — не устоявшийся кейс. Можете показать какие-то инструменты для этого, сравнимые с React Native?

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

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

                                    Ну если есть деньги на N команд разработки, то почему бы и не писать под каждую платформу отдельно. У меня нет)

                                    Я вам ещё раз повторю написанное: компании, использующие инструменты с огромным комьюнити, покрывающие гораздо более простые кейсы (iOS+Android), сомневаются в целесообразности этого. Именно с денежной точки зрения.
                                      0
                                      Зачем вам именно мой код, есть известные игровые движки Unreal Engine / Unity с большим сообществом, и некоторые другие, позволяющие собирать игры на Windows/Mac/Linux/Web/Android/iOS.
                                      И есть простые примеры типа такого github.com/redblobgames/helloworld-sdl2-opengl-emscripten

                                      Себе я запилил удобный фреймворк, на котором приятно работать, вот например разметка + внешний вид + добавление кнопки:
                                      static LayoutsParams lbPersNew = {.width = 320, .height = 96, .gravity = CENTER_HORIZONTAL | TOP, .marginTop = 8, .marginTopPercent = .333};
                                      static TextureParams tbPersNew = {.texLeft = 225, .texTop = 249, .texRight = 263, .texBottom = 287};
                                      static NinePathParams nbPersNew = {.vertTop = 16, .vertBottom = 16, .horLeft = 16, .horRight = 16};
                                      //...
                                      void initGui() {
                                          bPersNew = BUTTON(0, &onPersNewPressed, &lbPersNew, &tbPersNew, &nbPersNew, VISIBLE);

                                      //…

                                      Вы видите здесь что-то платформоспецифичное? Разметку и другие параметры я могу объявить в другом файле, если захочется разный вид приложения на разных платофрмах сделать, могу как есть оставить.
                                        +3
                                        Зачем вам именно мой код, есть известные игровые движки Unreal Engine / Unity с большим сообществом, и некоторые другие, позволяющие собирать игры на Windows/Mac/Linux/Web/Android/iOS.

                                        Во-первых, что под UE нужно писать на плюсах, под юнити на C# или UnityScript. Во-вторых, вы же в курсе что люди не только игры пишут, да?

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

                                        .width = 320

                                        320 чего?
                                          0
                                          320 чего?

                                          Масштабируемых единиц, конечно же)
                                          вы же в курсе что люди не только игры пишут, да?
                                          У меня приложение, и есть все нужные для него виджеты, аналоги андроидных ImageView, TextView, ListView с линейным списком и сеткой, скроббары, прогрессбар, кнопки. Всё, к чему привык на андроид, в облегченном варианте и кроссплатформенно.
                                          Во-первых, что под UE нужно писать на плюсах, под юнити на C# или UnityScript.
                                          Я уже писал, что по моим ощущениям, С уменьшает сложность по сравнению с C++ или C#. На С++ код иногда без боли не взглянуть.
                                            0
                                            Масштабируемых единиц, конечно же)

                                            Вы же в курсе, что в браузере их не существует?
                                            У меня приложение, и есть все нужные для него виджеты, аналоги андроидных ImageView, TextView, ListView с линейным списком и сеткой, скроббары, прогрессбар, кнопки. Всё, к чему привык на андроид, в облегченном варианте и кроссплатформенно.

                                            Как думаете, ваше приложение пройдёт ревью в App Store?
                                              0
                                              Как думаете, в AppStore есть игры с виджетами на 3д графике и непонятно какой логикой мастшабирования?
                                              Вы же в курсе, что в браузере их не существует?
                                              выбор коэффициента масштабирования — задача платоформозависимой обёртки, можно положить =1, если лучшего решения не найдётся.
                                                0
                                                Всё ещё не понимаю что вы хотите сказать.

                                                Что на Си можно написать на движке игру и она будет работать на всех платформах? Нет, нельзя. Зато можно сделать на C# или C++.

                                                Что можно написать на Си кроссплатформенное приложение? Нет, нельзя. Как минимум, вам придётся создавать UI на OpenGL с нуля. Чем вы и занимаетесь.

                                                Что вы можете написать велосипед и добавлять в него платформы со временем? Ну удачи. Наберёте когда сделаете 3-4. Как раз с точки зрения финансов это просто выброшенные на ветер деньги. Только какие тут преимущества у Си?
                                                  –2
                                                  Благодарю за комплимент, очень приятно слышать, что я делаю невозможное. У меня сложность не в UI, он уже есть и работает на 2х платформах как минимум (Android + Linux + Mac (?) Windows(?)), где (?) — не протестировано, но должно работать без изменений. Профит для меня как разработчика самый прямой — если раньше я просто шлёпал формочки, то сейчас в резюме могу дописать больше интересных вещей и продать своё время дороже, + 50%...100% — это более чем окупит потраченное время, если пересчитать на стандартную оплату труда. Это минимум. Цель — запустить крутой продукт и заработать о***лиарды)

                                                  Только какие тут преимущества у Си?
                                                  Вы видели эти божественные скобочки, которые я выше привёл? Я могу частично инициализировать структуру! Да это же как JSON! Я могу на си описывать UI с такой же лёгкостью, как JSON написать! В С++ такого нет, в джаве нет, в андроид блеклая эмуляция декларативного описания через XML, в iOS муки и матюки на StoryBoard или как там их инструмент разметки называется, несовместимый с git, в котлин чуть удобнее сделали, но всё равно не то.

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

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

                                                  Си замечательно дружит со многими другими языками. Я могу просто закинуть сишные файлы в проект на С++/objective-C/D, вроде Swift тоже, могу подключить к проекту на Java через jni, могу сишную либу слинковать с любым другим компилируемым языком. У С++ тут уже начинаются проблемы.

                                                  Далее, Си — простой для чтения и написания язык. Я могу показать код программисту на Java/C++/JS/C# и пр., и он гарантированно поймёт, что тут проиходит. Можно смотреть его в плейнтекст и не ломать голову, что это за auto.

                                                  Си программы быстро компилируются и быстро запускаются, за 1 секунду я могу собрать (инкрементально) проект и запустить приложение, полная пересборка всего ~4c, а в Java я успею попить кофе, пока всё соберётся, в С++ и подавно.
                                                    0
                                                    В С++ такого нет
                                                    Чего нет? Designated initializers? Поддерживаются уже лет 10 clang'ом и GCC, включены в C++20. В MSVC, да, беда — ну так там их с в C нет, ибо C99 MSVC не поддерживает.
                                                      0
                                                      На Си можно писать в функциональном стиле, с функциями можно обращаться как с переменными, надеюсь вы не станете отказывать функциональному программированию в праве на существование?

                                                      Можете map и foldr на С написать?


                                                      Желательно, чтобы foldr по ленивой структуре данных вычислялся лениво.


                                                      Си — это как Хаскель на минималках, достаточно функциональный для практического применения, но всё ещё с ручным контролем памяти.

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


                                                      Я вообще не понимаю этого восторга от функционального программирования как от банального STLC. В типах всё счастье-то, а не в том, что фукнции можно передавать в функции.

                                                        0
                                                        Map написал уже, синтксис другой немного, суть та же: берём список элементов одного типа, создаём из него список элементов другого типа по коду в скобках.
                                                        image
                                                        Использование:
                                                        image
                                                          0
                                                          Что-то это не очень на С.

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

                                                          Ну если охота о препроцессоре думать — давайте всё равно рассуждать гомоиконно и делать map на препроцессоре, который принимает макру и список на препроцессоре и применяет макру к каждому элементу списка.

                                                          Если что, в Boost.PP такое есть. Получается, препроцессор годнее сишечки!
                                                            0
                                                            А давайте сравним перформанс и читабельность кода? В бусте я Map в смысле преобразования списков не нашёл, так что через std::transform
                                                            C:
                                                            image
                                                            time ./cppapplication_4
                                                            el = 1
                                                            el = 11
                                                            el = 21
                                                            el = 31
                                                            el = 41
                                                            el = 51
                                                            el = 61
                                                            el = 71
                                                            el = 81
                                                            el = 91

                                                            real 0m0,583s
                                                            user 0m0,486s
                                                            sys 0m0,097s

                                                            с++:
                                                            image
                                                            time ./cppapplication_3
                                                            foo contains: 11 21 31 41 51 61 71 81 91 101

                                                            real 0m3,828s
                                                            user 0m3,734s
                                                            sys 0m0,092s

                                                            Разница по времени не в пользу С++, да и читаемость так себе.
                                                              +4

                                                              А давайте сравним с Rust:


                                                              vec.rs:


                                                              fn main() {
                                                                  let vec = vec![0; 100000000];
                                                                  vec.into_iter().enumerate()
                                                                      .map(|(idx, _el)| idx * 10)
                                                                      .map(|x| x + 1)
                                                                      .take(10)
                                                                      .for_each(|x| {
                                                                          println!("el = {}", x);
                                                                      });
                                                              }

                                                              Компиляция:


                                                              $ rustc vec.rs -O

                                                              $ time ./vec 
                                                              el = 1
                                                              el = 11
                                                              el = 21
                                                              el = 31
                                                              el = 41
                                                              el = 51
                                                              el = 61
                                                              el = 71
                                                              el = 81
                                                              el = 91
                                                              
                                                              real    0m0.003s
                                                              user    0m0.003s
                                                              sys 0m0.000s

                                                              Поиграться с кодом на playground


                                                              OMG пыщ-пыщ РАСТ БЫСТРЕЕ С в 200 раз и быстрее С++ в 1200 раз!!!111

                                                              Сомнительный бенчмарк, сэр. Тем не менее, этот сомнительный бенчмарк показывает, на что способен оптимизатор Раста =)

                                                                +2

                                                                На самом деле это было на ленивых вычислениях. Тем не менее, без ленивых вычислений:


                                                                fn main() {
                                                                    let vec = vec![0; 100000000];
                                                                    let vec: Vec<_> = vec.into_iter().enumerate()
                                                                        .map(|(idx, _el)| idx * 10)
                                                                        .map(|x| x + 1).collect();
                                                                    vec.into_iter()
                                                                        .take(10)
                                                                        .for_each(|x| {
                                                                            println!("el = {}", x);
                                                                        });
                                                                }

                                                                real    0m0.281s
                                                                user    0m0.072s
                                                                sys 0m0.208s

                                                                А в C++ версии вы сделали инициализацию массива из 100000000 элементов с помощью push_back, не удивительно, что оно так тормозит. Вы-то себе пачкой выделили память.


                                                                Читайте про амортизированную стоимость.

                                                                  0
                                                                  То с дебажным флагом компилятора было, с -03
                                                                  real 0m0,133s
                                                                  user 0m0,072s
                                                                  sys 0m0,061s
                                                                  И это я ещё OpenMP не подключил для автопараллелизации циклов)
                                                                  Раст прикольная конечно штука, но пока экзотика)
                                                                    0

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


                                                                    ArrayListTest.c:


                                                                    real    0m0.497s
                                                                    user    0m0.292s
                                                                    sys 0m0.205s

                                                                    cpp:


                                                                    int op_increase(int i) { return ++i; }
                                                                    
                                                                    int main() {
                                                                        std::vector<int> foo;
                                                                        foo.reserve(100000000);
                                                                    
                                                                        for (int i=0; i<100000000; ++i) foo.push_back(i*10);
                                                                        std::transform (foo.begin(), foo.end(), foo.begin(), op_increase);
                                                                    
                                                                        for(size_t i = 0; i<10; ++i) {
                                                                            std::cout << foo[i] << std::endl;
                                                                        }
                                                                    }

                                                                    real    0m0.254s
                                                                    user    0m0.148s
                                                                    sys 0m0.108s

                                                                    rust (вариант выше):


                                                                    fn main() {
                                                                        let vec = vec![0; 100000000];
                                                                        let vec: Vec<_> = vec.into_iter().enumerate()
                                                                            .map(|(idx, _el)| idx * 10)
                                                                            .map(|x| x + 1).collect();
                                                                        vec.into_iter()
                                                                            .take(10)
                                                                            .for_each(|x| {
                                                                                println!("el = {}", x);
                                                                            });
                                                                    }

                                                                    real    0m0.286s
                                                                    user    0m0.097s
                                                                    sys 0m0.189s

                                                                    rust (параллельные итераторы):


                                                                    use rayon::prelude::*;
                                                                    fn main() {
                                                                        let vec = vec![0; 100000000];
                                                                        let vec: Vec<_> = vec.into_iter().enumerate()
                                                                            .map(|(idx, _el)| idx * 10)
                                                                            .map(|x| x + 1).collect();
                                                                        vec.into_iter()
                                                                            .take(10)
                                                                            .for_each(|x| {
                                                                                println!("el = {}", x);
                                                                            });
                                                                    }

                                                                    real    0m0.112s
                                                                    user    0m0.302s
                                                                    sys 0m0.314s

                                                                    Пока что лидирует Rust =)


                                                                    И это я ещё OpenMP не подключил для автопараллелизации циклов)

                                                                    Только код скиньте.

                                                                0

                                                                У меня нет ArrayList, поэтому не могу воспроизвести. С какими опциями вы собирали код?


                                                                Кроме того, это немножко читерство: в плюсах вы не выделили всё место сразу, а в С — выделили.


                                                                Ну и, кроме того, как-то мы резко сменили тему с написания сишного map на микробенчмарки.

                                                                  0
                                                                  github.com/yarston/ArrayListTest выложил сюда. собиралось c gcc -g в прошлом посте.
                                                                  Сделал вариант бенчмарка с пушем в список по 1 элементу.
                                                                  Вариант с пушем с -O3:
                                                                  make && time ./a.out
                                                                  real 0m0,394s
                                                                  user 0m0,321s
                                                                  sys 0m0,073s

                                                                  С единоразовым выделением памяти gcc -O3:
                                                                  make && time ./a.out
                                                                  real 0m0,133s
                                                                  user 0m0,072s
                                                                  sys 0m0,061s

                                                                  Проц i73630QM 2.2 ГГц
                                                                  Ну и, кроме того, как-то мы резко сменили тему с написания сишного map на микробенчмарки
                                                                  Ну он написан же, что там ещё обсуждать. Перформанс вроде как важен для сишников.
                                                                  void* add2ArrayList(ArrayList *list) работает несколько не так как в C++, он не добавляет элемент сам, а только увеличивает счётчик, если надо, реаллоцирует и возвращает указатель, по которому уже можно писать данные. Например, указатель на структуру.

                                                                  Кроме того, это немножко читерство: в плюсах вы не выделили всё место сразу, а в С — выделили.
                                                                  На самом деле я скопипастил плюсовый код с какого-то сайта. Ну вот пишут они так.
                                                                    0
                                                                    github.com/yarston/ArrayListTest выложил сюда.

                                                                    Спасибо. ХЗ, у меня сишка чего-то тормозит:
                                                                    0.53 с для вашего варианта (только я ещё -march=native добавил).
                                                                    0.36 с для плюсового варианта с reserve + push_back.
                                                                    0.31 с для плюсового варианта с resize + operator[], чтобы не проверять capacity на каждой вставке.


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


                                                                    gcc 8.3.0, i7 3930k.


                                                                    PS. Поигрался ещё.


                                                                    Если убрать bar и писать сразу в тот же foo, то получаем 0.18 с.


                                                                    Кроме того, заметил, что у вас там Slow вместо Fast. Заменил в вашем коде на getFast ­— да, стало работать быстрее, та же 0.31 с, что и для плюсового кода.


                                                                    Теперь можно сравнить, насколько универсальны std::transform и этот ваш макрос соответственно.


                                                                    Ну он написан же, что там ещё обсуждать.

                                                                    Нет, там написан не он. Там написаны инструкции для кодогенератора (сишного препроцессора), как сделать сишный map для каждой конкретной функции (да и то в виде блока кода, а не произвольного указателя на функцию).


                                                                    Так мы с вами дойдём и до того, что в Go дженерики есть, потому что их можно кодогенерировать.

                                                                      0
                                                                      у меня сишка чего-то тормозит:
                                                                      странно, у меня
                                                                      gcc --version
                                                                      gcc (SUSE Linux) 8.2.1 20190204 [gcc-8-branch revision 268513]
                                                                      Правда у меня ещё патчи против спектр отключены. Там getSlow() по умолчанию стоит, его можно закомментить и собрать с единоразовым выделением памяти.
                                                                      Нет, там написан не он.
                                                                      Звучит как повод для дискусси, но лень спорить) Да и ладно, списки крутятся, работа мутится.
                                                                      Если убрать bar и писать сразу в тот же foo, то получаем 0.18 с.
                                                                      это уже другая задача.
                                                                        0
                                                                        У меня патчей против всех этих спектров тоже нет, зачем они мне на десктопе.

                                                                        Кстати, к слову о функциональщине — если вам будет охота, предлагаю написать две функции, map и foldr, и сделать по вашему списку, например, map с увеличением на единичку (как сейчас), а потом свертку с суммированием, и посмотреть, сколько времени это займёт. Потом можно будет сравнить с Ъ функциональщиной.
                                                                          0
                                                                          Нет наверно, спать охота, и тут запрос на webassembly порт поступил. Почему у вас такие цифры времени исполнения — для меня загадка, на вашем процессоре быстрее должно же быть по идее.
                                                                            0
                                                                            Оно в память всё упирается, думаю (а запускать vtune лень). Надо суммарно почти гигабайт через шину прогнать, что даёт оценку снизу на время выполнения где-то в 100-150 мс на моей машине. Повод обновиться на DDR4, на самом деле.

                                                                            Но, в любом случае, важны не абсолютные цифры, а сравнение с плюсовой версией (которое я таки дал).
                                                                              0
                                                                              Замена
                                                                              CONVERT_VEC_TYPE(unsigned, in, list, unsigned, out, list2) *out = *in + 1;
                                                                              на
                                                                               FOR(unsigned, el, list) (*el++)++;
                                                                              :
                                                                              make && time ./a.out
                                                                              gcc -O3 list.c main.c
                                                                              el = 1
                                                                              el = 10
                                                                              el = 21
                                                                              el = 30
                                                                              el = 41
                                                                              el = 50
                                                                              el = 61
                                                                              el = 70
                                                                              el = 81
                                                                              el = 90

                                                                              real 0m0,090s
                                                                              user 0m0,070s
                                                                              sys 0m0,020s
                                                                                0
                                                                                Что-то, судя по выводу, это неэквивалентная замена.
                                                                                  0
                                                                                  Да, спать пора) Инкремент указателя внутри макроса же делается.
                                                                                  FOR(unsigned, el, list) (*el)++;

                                                                                  gcc -O3 list.c main.c
                                                                                  el = 1
                                                                                  el = 11
                                                                                  el = 21
                                                                                  el = 31
                                                                                  el = 41
                                                                                  el = 51
                                                                                  el = 61
                                                                                  el = 71
                                                                                  el = 81
                                                                                  el = 91

                                                                                  real 0m0,089s
                                                                                  user 0m0,060s
                                                                                  sys 0m0,028s
                                                                                    +2

                                                                                    Тут, кстати, отлично видно, зачем на самом деле нужен map. Все эти функциональные map, filter и foldr нужны не для того, чтобы циклы на них переписывать, а для того, чтобы ограничить доступные вам действия. Хаскелевский мап не передаёт функции ничего, кроме текущего элемента — значит, у него нет никакого состояния, и преобразование действительно зависит только от текущего элемента (в отличие от foldr, например, для которого это не так, но через который можно выразить map). Плюсовый трансформ не передаёт указатель на элемент или итератор, а только сам элемент. Все эти функции хороши тем, что они связывают вам руки.

                                                                                0
                                                                                Ну у меня DDR3, ноут 13года что ли.
                                                                                  0

                                                                                  Страннота. Я эту машину тоже в 13-м году собирал.

                                                              0
                                                              Ехал this через this, сунул this в this auto, this this this this this this this this)
                                                              0
                                                              Ты в золотой середине. Можно дрова писать и приложения для людей. Мы спрыгнули в начале 90-х с С и подобных языков в погоне за баблом. Тогда нужны были бухгалтерско-банковские десктопно-локально-сетевые проги. Брали Clipper, написанный на С, и за месяц рисовали то, что на С создавали бы год. Поэтому, если С есть наработка и не происходит отставания по времени исполнения проектов от конкурирующих языков, то жаба — это ничто по сравнению с С, тем более, что на кофеварке крест ларри поставил, но никак не может сдать в утиль. Вторая сторона луны — это где найти команду сишников, которая гребет не меньше жабокодеров. Т.е., сравниваем, сколько бабла дает С по сравнению с другими.
                                                            0
                                                            Вот это вы понаписали! Встану ка и я на защиту Си. В общем, будущее идёт к тому, что для платформы браузеров (я имею в виду JS-виртмашину, что в браузерах) скоро web-приложений написанных на Си (точнее включающих исходники на Си) будет больше и больше. Сейчас Emscripten набирает обороты. Скоро подправят WebAssembler и будет неплохая браузерная виртмашина для Си. Многие Си-шные вещи уже в браузере есть или подцепляются с некоторыми доработками. Прирост скорости ощутимый. А если рисовать всё на OpenGL то хоть под десктоп пиши хоть под браузер. Страницы могут перейти с html на JS-байткод, грузится быстрее, не парсится, не компилируется, и… прощай стандартный html и JS-скрипты, здравствуй Си! Скоро Linux под браузером запустят…
                                                              0
                                                              Скоро Linux под браузером запустят…

                                                              Будущее настало
                                                                0
                                                                Уот это поворот! Я всё проспал.
                                                                Винда 2000 в браузере тоже порадовала.
                                                                Значит и динамическая кодогенерация на Си с Tiny C Compiler тоже появится. Во время то пошло.
                                                                +1
                                                                А чем тут С особенный? Под WebAssembly можно писать хоть на С, хоть на расте, хоть на идрисе.
                                                                  0
                                                                  Если в смысле динамической компиляции, то Cи тут не особенный. Но Си становится особенным в смысле своего более раннего происхождения и как следствие довольно большой кодовой базы которая была наработана и отлажена за всё время существования языка.
                                                                    0
                                                                    довольно большой кодовой базы которая была наработана и отлажена за всё время существования языка
                                                                    Кодовой базы которая наработана, но не отлажена в нем также больше. Поиски работающего кода для своей конкретной задачи — отдельная проблема которая далеко не всегда проще чем собственно написание своего решения. А уж поддержка кода который написали не вы…
                                                          0
                                                          Кстати, например, Flutter (скорее всего и другие аналоги) пошел по этому пути. Он есть ничто иное, как 2d движок по типу игрового, но отрисовывает только виджеты и тп) Гениально!) Сишные бинарики просто идут в комплекте с приложением
                                                            0
                                                            Да, вот гугл тоже в этом направлении думает.
                                                          +1
                                                          Вы видите здесь что-то платформоспецифичное?

                                                          Да. 9-patch это андроидовская тема.
                                                          В чём у вас измеряются все магические константы — непонятно.
                                                            0
                                                            У меня кроссплатформенная реализация. 320 dp.
                                                            0
                                                            В кроссплатформенных движках есть свои библиотеки и методы работы с конкретной платформой. Но что бы разработчикам игр было проще, разработчики движка стараются унифицировать внутренние функции под каждую платформу. К примеру, некоторое время назад для UE4 я собирал доступные в Marketplace технодемки, пробовал комбинировать и с DX11, и с OpenGL 4, и с Vulkan (хотя он в экспериментальном варианте). В практически большинстве случаев демки идут так как и должны, выглядят как должны, хоть на Windows, хоть на Linux. Это и есть та самая кроссплатформенность и удобство сборки, о чём выше вы и сказали.
                                                      0
                                                      На iOS без плясок с бубном уже не взлетит.
                                                        0
                                                        Потому что Metal? Переписать вызовы OpenGL на Metal должно быть несложно, суть-то одна, названия методов только отличаются.
                                                    +2
                                                    Да, автовекторизация и прочие оптимизации весьма недурно производительность поднимают.

                                                    И компиляторы уже такие умные стали, что автоматически векторизуют всё, что можно векторизовать?


                                                    Может, оно вам и AoS в SoA само конвертирует?


                                                    На практике вклад malloc/free во время исполнения с лупой искать надо.

                                                    Везёт вам там. У меня бывают проекты, где приходится писать свои аллокаторы, с аренами и вот этим всем.

                                                      0
                                                      И компиляторы уже такие умные стали, что автоматически векторизуют всё, что можно векторизовать?

                                                      Ну у меня например, софтварный растеризатор треугольников на Си без интрисинков с опцией -O3 ~180мс на отрисовку сцены 8к полигонов в 4к (3840*2160) в 1поток на ноутбучном CPU, а с интрисинками (SSE4.2), оптимизацией размещения данных в структуре и выравниванием в памяти ~160мс. Пожалуй под неон забью на ручную векторизацию.
                                                      Может, оно вам и AoS в SoA само конвертирует?
                                                      А зачем? Я сразу пишу как надо.
                                                      У меня бывают проекты, где приходится писать свои аллокаторы, с аренами и вот этим всем.
                                                      В линуксовой libc аллокатор с аренами как раз. Если что, можно её статически линковать, не уверен правда, позволяет ли лицензия.
                                                        +1
                                                        Ну у меня например, софтварный растеризатор треугольников на Си без интрисинков с опцией -O3 ~180мс на отрисовку сцены 8к полигонов в 4к (3840*2160) в 1поток на ноутбучном CPU, а с интрисинками (SSE4.2), оптимизацией размещения данных в структуре и выравниванием в памяти ~160мс.

                                                        А у меня есть код, у которого производительность отличается на порядок. И при этом я далеко не спец в SIMD, так, мимо проходил.


                                                        А про разницу всяких dlib'ов или eigen'ов с ручными операциями с матрицами против MKL я и говорить не хочу.


                                                        А зачем? Я сразу пишу как надо.

                                                        Ну а чего б и нет? В терминах AoS таки чуть удобнее размышлять.


                                                        В линуксовой libc аллокатор с аренами как раз. Если что, можно её статически линковать, не уверен правда, позволяет ли лицензия.

                                                        У меня как у программиста чуть больше информации о времени жизни объектов. Например, я знаю, что по условиям задачи я могу выделять память из арены, не освобождая её до окончания обработки запроса вообще никогда, и одним махом всё уничтожить в самом конце. Компиляторы пока не такие умные, к сожалению.

                                                          0
                                                          Кто лучше решение может предложить? Java? .NET? У них ещё меньше информации.
                                                            0
                                                            Решения чего? По памяти?

                                                            Языки с элементами субструктурных систем типов могут, например. Но да, не джава и не .NET.

                                                            Правда, и в этом случае будут проблемы — оптимизации во многом зависят от ожидаемых объёмов, времен жизни и тому подобного, которые непонятно как передать компилятору, кроме как через PGO.
                                                              0
                                                              Растовые лайтфайфы не подойдут?
                                                                0

                                                                Нет, потому что проблему из последнего абзаца они не решают.

                                                                  0
                                                                  Ну вот мы знаем размеры объектов, времена жизни. Что еще надо? Просто проблему не понимаю.
                                                                    +1

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

                                                                      0
                                                                      Ну сделать это локально не очень трудно.

                                                                      А глобально да, в голову ничего не приходит.
                                                    0
                                                    С быстрее

                                                    Очевидно. Удобнее — уже очень сомнительно.

                                                    +2
                                                    профилировать перформанс — и так ясно, что всё предельно быстро будет

                                                    А люди, дураки, зачем-то всё равно тяжёлый вычислительный код под профайлерами гоняют. А можно-то просто писать на сях, оказывается!


                                                    Отличный язык для быстрого прототипирования)

                                                    И код реюзабельный, и в языке все средства для этой реюзабельности есть, ага.


                                                    И да, это сарказм. И нет, это не про торжество ООП.

                                                      0
                                                      Реюзать функцию без ссылок на this проще, чем с. Нет ООП — нет this. Чистые функции как они есть.
                                                        +1

                                                        Мне ООП не нравится по другим причинам.


                                                        this — это всего лишь ещё одна ссылка, ничем не отличающаяся от любой другой.

                                                    0
                                                    Обычно люди просто стараются увернуться (включить/выключить, попробовать ещё раз), а не выяснять что именно там случилось.

                                                    Так ещё Чарльз Беббидж говорил, что выгоднее (по времени) пересчитать заново всю ошибочную страницу, чем искать в ней ошибочные значения.
                                                      0
                                                      Всякая абстракция имеет дыры. Целые «числа» имеют максимально возможные значения. Вещественные переменные на самом деле имеют ограниченный набор дискретных значений.
                                                      Вычитание из большого числа маленького может не приводить к изменению значения. И т.д.
                                                      Но стек абстракций уже слишком велик, чтобы кто-то мог его весь знать в подробностях.
                                                      Мы не чиним двигатель через выхлопную трубу. Мы едем на СТО и просим специалиста залезть пд капот.
                                                        0
                                                        задача всего компьютерного — абстрагирование и уменьшение сложности.


                                                        Иногда программисты старшего поколения, глядя на сегодняшние реалии начинают всерьез в этом сомневаться… Я вполне знавал людей, которые считали, что ассемблер гораздо ПРОЩЕ всех этих ваших «высокоуровневых» ЯП. И где-то они правы… Пока сложность собственно самого кода не выходит за определенный порог, когда без абстракция уже невозможно охватить сознанием логику решения в целом.

                                                        Но все равно — текущий уровень абстракции многих современных ЯП даже мне кажется слишком перегруженным! Ощущение такое, что уже пошли абстракции, ради абстракций, размывающие основы. Согласен во многом с автором.
                                                          0
                                                          Тот странный момент, когда осознаёшь что ты уже относишься к «программистам старшего поколения»… :)
                                                            0
                                                            Проще понять как оно устроено. Да, старые системы устроены проще с точки зрения нижележащего уровня.

                                                            Но я реально не понимаю, сколько строк кода на ассемблере нужно для того, чтобы скачать файл. tcp, DNSsec, TLS, http…
                                                              0
                                                              Если не писать все самому, а дергать уже готовые библиотеки, то вряд ли так уж много. Все равно на порядок (если не на два) больше, конечно, чем на каком-нибудь питоне, но не запредельное количество вроде бы. Впрочем я ассемблером занимался последний раз давно и на память не вспомню что там есть из доступного что можно дергать чтобы скачать файл. Может быть я ошибаюсь и нет ничего.
                                                                0
                                                                Ну да… Если include 'win32a.inc', то дальше почти как на высокоуровневом:

                                                                ; Открыть интернет-соединение
                                                                invoke InternetOpen,user_agent,\
                                                                INTERNET_OPEN_TYPE_PRECONFIG,NULL,NULL,0
                                                                mov [hInet],eax

                                                                ; Открыть FTP-соединение
                                                                invoke InternetConnect,[hInet],server,[port],login,password,\
                                                                INTERNET_SERVICE_FTP,INTERNET_FLAG_PASSIVE,0
                                                                mov [hConnection],eax

                                                                И тп…
                                                                  0
                                                                  А где тут TLS?
                                                                    0
                                                                    Там, где «и тп...» )))

                                                                    Это был просто пример подхода к вопросу «скачать файл», если есть библиотека.

                                                                    Так-то tls Гуглится на раз.
                                                              +1
                                                              Я вполне знавал людей, которые считали, что ассемблер гораздо ПРОЩЕ всех этих ваших «высокоуровневых» ЯП.

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

                                                                +1
                                                                Хорошая аналогия… Ее же можно развивать? ;)

                                                                Например лопатой можно делать гораздо более точные и аккуратные вещи, в быту нужна лопата, а не экскаватор, порог вхождения у лопаты… Тонкий момент — у лопаты ниже, а ассемблера — не факт… ;)

                                                                Потом опять же — лопата, она и есть лопата, а сложность современных экскаваторов ЯП уже как-то слабо коррелирует со сложностью решаемых задач! Современный Hello world запросто может потянуть на пару десятков килобайт, и примерно никто 90% тех, кто его использует НЕ ЗНАЕТ, что там в этих килобайтах!

                                                                Львиная доля усложнения самих ЯП (я имею ввиду не банальный синтаксис, а совокупность код/ide/продукт на выходе) идет на сокрытие реальной сложности от разработчика. А многократный запас по производительности позволяет не парится из избыточностью и не рациональностью в угоду универсальности.

                                                                Это, наверное неплохо, но… Иногда мне тоже кажется, что мы пройдем какую-то точку, после которой все это превратится в магию, потому, что никто не будет знать, как оно работает!
                                                                  0
                                                                  Кстати, о сложности — ниже рабочая программа на OpenGL

                                                                  #include <GL/glut.h>

                                                                  int main()
                                                                  {
                                                                  glutCreateWindow(«Small program»);
                                                                  glutDisplayFunc([]{});
                                                                  glutMainLoop();
                                                                  }

                                                                    0
                                                                    Лопата при кажущейся простоте ушатает руки в первый же день работы, и вообще копать ей — адское занятие.
                                                                      0
                                                                      Потом опять же — лопата, она и есть лопата, а сложность современных экскаваторов ЯП уже как-то слабо коррелирует со сложностью решаемых задач! Современный Hello world запросто может потянуть на пару десятков килобайт, и примерно никто 90% тех, кто его использует НЕ ЗНАЕТ, что там в этих килобайтах!

                                                                      Экскаватор тоже тянет на несколько тонн. И 90% тех, кто им управляет, не знает, что там внутри :)


                                                                      Львиная доля усложнения самих ЯП (я имею ввиду не банальный синтаксис, а совокупность код/ide/продукт на выходе) идет на сокрытие реальной сложности от разработчика.

                                                                      Ну так да, уменьшение сложности. В этом смысл и состоит.

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

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

                                                                          0
                                                                          А разве это проблема только программирования? Нучно-технический прогресс вообще приводит к узкой специализации.
                                                                        0
                                                                        Недавно вспоминал, как в стройотряде нашу бригаду прикрепили к комунхозу.
                                                                        Срочно привозят на место происшествия: стоит экскаватор, на ковше вытянутый из земли высоковольтный кабель, изоляция уже лопнула и металл блестит. Экскаваторщик сидит в сторонке белый как бумага. В результате мы траншею копали лопатами.
                                                                        Очень актуальная аналогия :)
                                                                    +7
                                                                    Не готовы потерять контроль? Как было сказано: «Принеси ведро электронов!»
                                                                      +19
                                                                      > Все эти картинки у тебя на мониторе, циферки, библиотеки, анимации — они не настоящие. Настоящее только электричество.
                                                                      Так и мысли в голове не настоящие. Это несвязной бормотание внутри головы — это только тень от того, что происходит за пределами сознания. В каком-то смысле, сознание и есть то, что мы можем сказать. Чтобы сделать тривиальное действие, например, выделить немного слюны — мы должны очень напрячься, воображая лимон.
                                                                      И этот же подход мы перенесли на программирование. Чтобы отправлять тривиальные сигналы, мы создали какие-то абстракции, которые нашему сознанию более близки, которые проще вообразить. Мы, условно говоря, мыслим «лимонами», а наше тело и компьютер управляется условным электричеством. И наши ЯПы — тем для нас лучше, чем они ближе к «лимонам». А что они там под капотом делают — дело уже давно десятое. И в принципе, оно хорошо. Если завтра у нас компьютеры будут основаны на других принципах, то нам достаточно будет переписать наши интерпретаторы лимонов в это новое и оно будет как-то там работать. Это тоже контроль. Но другого типа.
                                                                        +4
                                                                        Электричество тоже не настоящее. Оно течет в ненастоящих кристаллических решетках, которые сделаны из ненастоящих атомов, которые сделаны из ненастоящих электронов и ядер, которые сделаны из ненастоящих кварков, которые…
                                                                          0
                                                                          По-моему, все от мало до велика виртуально)
                                                                            0
                                                                            и ваще, мы с вами сейчас находимся в Матрице
                                                                            Заголовок спойлера
                                                                            Wake up, Neo…
                                                                          0
                                                                          Читаем теорию электромагнитного поля (3-я, завершающая часть электротехники). Это, самое, электричество — оно даже не течет. Это поле. Технология эл.проводов — это древность, но бизнес, как нефть, перегаром которой нас вынуждают дышать.
                                                                            0
                                                                            Скорее здесь уместнее будет аналогия с естественным языком и речью. По-началу речь проста и незамысловата, ее цель — донести суть. По мере развития человека (человечества?) суть донести все сложнее и речь усложняется. Узких специалистов зачастую понять может уже только такой же специалист…

                                                                            Однако есть, условно, наука, а есть наукообразность. Есть области, где просто нельзя без усложнений, а есть люди крайне витиевато и сложно выражающие ЛЮБУЮ мысль — даже ту, которую можно донести трехлетнему ребенку десятком простых слов.

                                                                            Есть канцеляризмы, есть сленг, арго и тп.

                                                                            Вот и не понятно где усложнения были необходимы, а где кого-то просто перло от нагромождения абстракций!
                                                                            +1

                                                                            А если серьёзно, то проблема построения абстракций над абстракциями (и так до бесконечности) очень-очень серьёзная. Хорошо, если хоть четверть веб-разработчиков знают и понимают, что под капотом у V8, сишарперы — у IL. И как только мы встречаемся с проблемой уровня ниже нашего предела понимания этих абстракций, мы бессильны.
                                                                            Ещё Азимов в своей книжке "Основание" описал, а Артур Кларк сказал, что любая достаточно развитая технология неотличима от магии. А разве мы можем понять магию? Нет. Не можем. Значит рано или поздно, при появлении таких технологий, мы будем жить в мире компьютерной магии, и ни один человек не будет ей управлять.


                                                                            А теперь представьте, если магия перестанет работать. Что будет? Полная разруха...

                                                                              +3
                                                                              Если магия перестанет работать то прилетят Рептилоиды и все починят.
                                                                              P.S. Машу табличкой «сарказм». Ссылка на рассказ Гарри Гаррисона.
                                                                                +1

                                                                                Как жаль, с одной стороны, что нет инопланетян, и никакое НЛО не починит… Но с другой стороны, хорошо, что никто не может нас шантажировать в плане контроля и починки этой "магии".

                                                                                  +1
                                                                                  Вы не совсем уловили что я хотел сказать. Я к тому веду что кто-то этим управлять в любом случае должен. Если не инопланетяне то сами люди, те кто эту технологию разработал или их наследники. Чтобы некая технология работала но при этом никто не знал как — нужны весьма специфичные условия. Это в глобальном смысле, само собой.
                                                                                    +2
                                                                                    Вы знаете, вот это вот Всё мне частенько напоминает о книге Герберта Уэллса — Машина времени (посмотрев кино версию этого не ощутить). Хоть я и читал её лет 20 назад. Но иногда сталкиваюсь с тем во что оно может «интерпретироваться» и нахожу параллели. Как бы мне не хотелось чтобы мы не создали случайно эти самые специфичные условия. Гуманитарии там тоже по своему интерпретированы=)) они живут под землей и чинят механизм какой-та, а по ночам выходят и хавают илиту, живущих на поверхности, безвольных
                                                                                      0
                                                                                      Вы знаете, мне иногда кажется, что в современном мире достаточно уничтожить 15-20 тысяч человек, чтобы цивилизация встала в своём развитии. Пугает…
                                                                                        +4
                                                                                        Даже если предположить что предположение верно, вы правда не считаете специфичными условиями внезапное уничтожение 15-20 тысяч конкретных людей?
                                                                                          0
                                                                                          Да все эти конкретные люди географически в одном месте сосредоточены, к тому ж сейчас отдельные, даже очень образованные и знающие, люди не смогут восстановить технологию если ее утерять, технология на команды и оборудование завязана, уничтожь большую часть команды и оборудования и технологию не восстановить.
                                                                                          Сколько мест в мире где скажем жесткие диски делают или еще чего там более продвинутого? А если их 1-2 таких мест на весь мир останется, глобализация экономики это же диктует, а потом какой локальный кабздец на это место свалится типа эпидемии или военного конфликта. Т.ч. специфичность условий тут скорее в локализации технологий, а не сами условия, о чем мне думается предыдущий оратор и говорил.
                                                                                            0
                                                                                            Сколько мест в мире где скажем жесткие диски делают или еще чего там более продвинутого?
                                                                                            Жёсткие диски ладно. А вот сканеры для литографии — это штучная работа и всего три фирмы: ASML и Canon и Nikon их делают (вернее практически ASML только делает, Canon/Nikon всё грозятся победить EUV, но пока поставок нет).
                                                                                            0
                                                                                            Вы знаете, мне иногда кажется, что в современном мире достаточно уничтожить 15-20 тысяч человек, чтобы цивилизация встала в своём развитии. Пугает…

                                                                                            американцы вон уже список в санкциях начали заполнять=)) осталось ещё сотню таких составить, и заживём
                                                                                            0
                                                                                            Вы заблуждаетесь. Локальные технологии могут держаться на маленькой группке людей, глобальные — нет.
                                                                                            Предположим некоторые рептилоиды с помощью наноботов взяли и уничтожили весь интел и амд. Ну и производственные их мощности заодно и складские запасы, так уж, чтобы наверняка. Что произойдёт?
                                                                                            Ну экономику поколбасит, да. Цены полезут вверх на железо как на дрожжах, стартапов поуменьшится.
                                                                                            Но
                                                                                            1) останутся сотни мелких производителей
                                                                                            2) Новые процессоры х86 выпустят в течение двух, максимум пяти лет
                                                                                            3) технологии на фабах откатятся ну скажем на десять лет назад
                                                                                            4) станут востребованны более быстрые стеки ПО

                                                                                            В целом эффект на прогресс это окажет не очень сильный.
                                                                                              0
                                                                                              Так надо не компании уничто жать, а специалистов. Если уничтожить всех разработчкиов и все чертежи, человечество не сможет востановить архетектуру. Максимум через несколько десятелетий сможет создать совместимый аналог
                                                                                                0
                                                                                                Чтобы уничтожить всех причастных разработчиков нужно уничтожить весьма немаленькое количество людей. Причем конкретных и в совершенно разных географически местах. чтобы при этом еще и все чертежи уничтожить так, чтобы вообще нельзя было восстановить — это нужно уничтожить пол интернета и какое-то количество бумажных распечаток — последнее вообще не представляется возможным. Это что должно произойти чтобы такое в принципе могло случится? Ну и в мире где есть кто-то, для кого такое действие возможно — у нас будут проблемы посерьезнее потери группы инженеров.
                                                                                                  0
                                                                                                  При чём тут интернет? Это ведь комерческая информация — разве эти чертежи есть в открытом доступе? Разве только старые версии
                                                                                                    0
                                                                                                    Ну значит нужно уничтожить не интернет, а кроме разработчиков еще и тех, у кого есть доступ к серверам. Ну либо сервера. В любом случае случайно такое событие не произойдет до тепловой смерти вселенной, а если кто-то организует такое специально, то нам вряд ли что-то поможет.
                                                                                                  0
                                                                                                  Посмотрите пожалуйста на Dolphin или на RPCS3. Это проекты разрабатываемые горсткой энтузиастов в свободное время без исходных документов. Знания размазаны по культуре и восстанавливаются по поведению образцов, от этого никуда не деться.
                                                                                                    +1
                                                                                                    В этом случае достаточно будет знать, что «такое точно возможно сделать». А значит тысячи энтузиастов ломанутся заполнять внезапно освободившуюся нишу. Человечество заново пробежит вековую историю IT за десятилетие, и кто знает, куда «взлетит» по инерции…
                                                                                                      –1
                                                                                                      ключевой момент — за десятилетие
                                                                                                      возмут люди книжки и начнут изучать с азов, через пару лет появится группа специалистов которая будет востанавливать технологию…
                                                                                                        +1
                                                                                                        Ну да десятилетие — вместо столетия. Разумеется это будет откат назад, но недолгий и не фатальный. Кроме того многие вещи просто не станут изобретать заново, грубо говоря вместо LPT изобретут сразу USB.
                                                                                                    0
                                                                                                    1 и 2 сомнительно.
                                                                                                    СССРовсский x86 собственной разработки был или все же в основе интел лежал?
                                                                                                    И сколько мелких производителей имеют культуру разработки и как изделий так и технологий, они уже всем готовым скорее пользуются чем собственное разрабатывают.
                                                                                                      0
                                                                                                      СССРовсский x86 собственной разработки был или все же в основе интел лежал?
                                                                                                      Он был копией — но это было политическое решение. Так же, как и пресловутый Ту-4.
                                                                                                        0
                                                                                                        Так же, как и пресловутый Ту-4.

                                                                                                        Это Вы зря. Эта машина — самый настоящий реверс-инжиниринг.
                                                                                                          0
                                                                                                          Ровно как в случае с К1810ВМ86. Поступил заказ на создание копии — и копию сделали.

                                                                                                          Из чего не следует, что ничего своего создать не могут. В конце-концов и Ан-225 и E2K существуют и точно не являются копиями западных аналогов.
                                                                                                            0
                                                                                                            Да, все компы мы копировали. Так быстрее врага догонять с меньшими затратами. На заводе Кварц слой за слоем снимали с западных микросхем и потом делали свои побольше, и с 6 ручками, чтобы переносить (юмор такой был тогда).
                                                                                              +2
                                                                                              Прилетят ретролойды, достанут спектрумы, ассемблеры и т.п. и все починят)
                                                                                                +1
                                                                                                Джон Тайтор? IBM 5100?
                                                                                              +1
                                                                                              Будут люди, которые её будут понимать. Только их будет не так уж много…
                                                                                              Кто то же эту «магию» должен поддерживать на всех уровнях )

                                                                                              Просто это будет совсем другой уровень. Сейчас уже есть неплохой разрыв между теми кто пишет ядро технологии и тех, кто ими пользуется ) Со временем он просто будет расти или количество слоёв будет увеличиваться.
                                                                                                +1

                                                                                                Да, разрыв будет увеличиваться. И да, будут люди, поддерживающие всё это. Но рано или поздно это кончится. Либо это будет как в "Матрице", когда машины вытеснили людей и заставляют их жить по своим правилам, либо это будет, как тот случай с криптовалютной биржей и холодным кошельком, владелец которого умер.
                                                                                                Это всё к чему. Если (ну вдруг) происходит форс-мажор и людей-"богов" (продолжая образ магии = технологии), которые держали всё на своих двоих, не станет, то мы приедем в тупик цивилизации. Как только мы забудем, если отвлечься от темы технологий, рецепт Кока-Колы, которую знают единицы, то мы никогда не сможем её воспроизвести, лишь пользоваться уже настроенным оборудованием, пока его не придется заменить и забыть программу производства. Так и здесь, не стань пары ключевых людей в Intel, и архитектура процессора для нас — тайна. Тайна, правду о которой мы никогда не узнаем.

                                                                                                  +1
                                                                                                  То, что для многих «магия», для кого-то просто рутина. Если бы бизнес Intel был так завязан на знания пары людей, то она не протянула бы столько времени. Чтобы защититься от Bus factor люди давно уже применяют разные штуки типа управления знаниями.
                                                                                                    0
                                                                                                    Но рано или поздно это кончится.
                                                                                                    Совсем не факт. Помимо людей, которые сейчас эту магию умеют есть масса учебных курсов. Из-за роста количества людей которым эту магию нужно чинить — людей владеющих магией тоже становится больше (количественно, не в процентах). Как они могут все внезапно куда-то деться, да еще и всю литературу по теме прихватить — непонятно совершенно. Разве что апокалипсис случится, но там проблемы побольше будут чем непонимание что там под капотом у V8.
                                                                                                      +4
                                                                                                      Апокалипсиса не надо. Оно встречается постоянно.

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

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

                                                                                                      Ну хорошо, про «так и задумано» иногда сказать можно — на этот счет тест есть. А вот для чего оно так — это задокументировать забыли. Тут вот чуть выше про управление знаниями вспомнили. Но речь как раз про то и идет, что на самом деле этого самого управления практически никогда нет.
                                                                                                        +2
                                                                                                        Апокалипсиса не надо. Оно встречается постоянно
                                                                                                        И что — постоянно случаются катастрофы? Вроде бы нет, человечество как жило так и живет. Я к тому, что либо то, что вы описываете — апокалипсис и его скорее всего не случится, либо это достаточно незначительные события не играющие большой роли. Зависит от того, какой смысл вы вкладываете в слово «это».
                                                                                                        Ну забросили в какой-то компании самодельную систему, ну и что? Да, компания что-то теряет из-за невозможности модификации и вынуждена будет потратить сколько-то денег на либо переделывание, либо покупку готового. Но это штатная ситуация, ничего страшного не произошло. Да, какие-то более глобальные решения забрасываются и есть люди которые остаются с магией. Но и это не происходит в один день и без появления альтернатив зачастую. Популярное решение не умрет если пропадет единственный его разработчик, потому что он не будет единственным. Ну а в таком случае те, кто остался на умершей системе в общем-то сами виноваты, могли бы и озаботится миграцией на что-то живое.
                                                                                                          +1
                                                                                                          И через несколько лет имеем черный ящик, про который не только никто не знает, как он работает, но и никто не знает, что именно от ящика ожидается. Т.е. когда на постукивание в левом верхнем углу ящик выплевывает комок зеленых соплей — никто не может сказать, «это так и задумано и сделано для того-то и того-то крайнего случая», или «ящик сломался».

                                                                                                          Это вы сейчас прям точно в саму природу человека и попали. Сколько тайн хранит не изученный потенциал человеческого мозга. Сколько интересных исследований я вчера почитал по раздвоению личности, после просмотра фильма «стекло». А не потеряли ли мы инструкцию к самим себе. И не это ли хотели нам сказать все предыдущие пророки. Но в силу скудности ума, мы так и не научились читать и слушать. И каждый народ интерпретировал или перевёл это на свой лад.
                                                                                                            0
                                                                                                            Так если ТЗ было создать ящик, который при постукивании выдавал кучку зеленых соплей, может и не нужно его сопровождать? Работает и не трогает, что-то сбилось — перезагрузи. Всегда есть системы, которые просто работают и всех это усраивает, ничего менять не надо, допиливать тоже. Да, если нужно будет поменять цвет соплей на синий, наверно, начнутся проблемы и проще будем написать заново. Но ведь скорее всего не понадобится.
                                                                                                              +1
                                                                                                              Сопровождать нужно. Потому что 'работает и не трогай' не очень-то работает, так как внешние условия меняются. И если они поменялись после того, как мы забыли почему ящик что-то делает — то мы не можем даже сказать, нужно ли его выкидывать, или еще можно использовать. И что еще сломается, если мы его все же выкинем. Это как в известном примере с ракетой. Алгоритм перетащили на новую модель, забыв проверить его применимость, в нем произошло переполнение — ой, ракеты больше нет.
                                                                                                            +4
                                                                                                            Не соглашусь с вами. Проблема есть уже сейчас. Есть такая вещь как утеря технологического наследия. Если коротко — сейчас НЕВОЗМОЖНО воспроизвести многие вещи произведённые 20-40 лет назад.
                                                                                                            Вы скажете — а зачем это надо? Ну, к примеру, возобновление производства оружейного плутония. Там всё задокументированно и понятно, для химика, получившего образование в 40-х годах прошлого века. У современного специалиста, фраза " довести концентрацию вещества до 7" вызовет немой вопрос в глазах. Потому что кардинально поменялись методы анализа веществ.
                                                                                                            Или совсем простой пример, лет 10 назад надо было слегка модернизировать крупный нефтеперерабатывающий завод в США. Есть некая документация, живы люди, которые её разрабатывали, и методы перегонки вроде не поменялись, вот только реальная схема завода СОВСЕМ не соответствует чертежам. И зачем так было сделано — никто не помнит. Причём видно, что сначала делали по чертежам, а потом переделывали. Результат — небольшая модернизация вылилась в полную перестройку, «с нуля».
                                                                                                            Так что это дело не будущего, а настоящего. Мы уже не понимаем что, и почему именно так, делали наши родители.
                                                                                                            И управление знаниями не панацея. Бумажная документация — считайте что её нет. Как показывает опыт, она не полная и перепутана. Да и выкидывают её с большим удовольствием. Особенно при банкротстве\ поглощении. Найти что либо в бумажных архивах можно при большой доле везения. Как с нефтеперегонным заводом. Понятно что была документация на все переделки. Вполне вероятно что она даже сохранилась. Вот только ГДЕ?
                                                                                                              +1
                                                                                                              Вы путаете локальную технологию и глобальную. Вот тот же нефтезавод — он один. Был бы их хотя бы десяток по миру — с документацией было бы гораздо легче и лучше.
                                                                                                                +1
                                                                                                                Я все еще не понимаю зачем воспроизводить именно прикладные технологии 20-40 летней давности. Они умерли потому что есть что-то более современное, что пришло им на замену. Если где-то решили не модернизироваться и дотянули до момента когда модернизация невозможна, но необходима — ну сами виноваты. В чем трагедия то? Человечество не пострадало, даже на уровне отдельного государства такие случаи редко заметны.
                                                                                                                Так что это дело не будущего, а настоящего. Мы уже не понимаем что, и почему именно так, делали наши родители.
                                                                                                                Так а нам и не надо. Частный случай провала планирования не в счет — это провал планирования модернизации, а не необходимость восстановления никому больше не нужных тех процессов.
                                                                                                                  0
                                                                                                                  Зайдем с другого края. Американская лунная программа состоялась (или нет) благодоря УНИКАЛЬНОМУ ракетному двигателю ( уникальный по соотношению тяга\собственный вес, там 100 тонн тяги на ОДНУ КАМЕРУ вроде было). Такого двигателя ни у кого не было и сейчас нет ни у кого в мире, включая сами США. Несколько лет назад США пытались снова сделать похожий двигатель, но упёрлись, как и все остальные в пульсации пламени и нестабильность факела.
                                                                                                                  И возникает вопрос — если двигатель С ТАКИМИ ПАРАМЕТРАМИ был (сам двигатель в музее стоит) то почему его не использовали потом и не могут воссоздать сейчас?
                                                                                                                    0
                                                                                                                    Ну, его с переменным успехом пытаются. Думаю вы читали, раз интересуетесь, скажем вот это.
                                                                                                                      0
                                                                                                                      если двигатель С ТАКИМИ ПАРАМЕТРАМИ был (сам двигатель в музее стоит) то почему его не использовали потом
                                                                                                                      Не использовали потому, что по другим характеристикам не устраивал. В частности отношение тяги к весу лучше и у двигаталей, на которых Союз летает и у пресловутого Falcon-9.

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

                                                                                                                      Но вообще все эти самые-самые достижения «теряются» обычно потому, что ну очень дорого это: делать самую большую ракету, самый большой самолёт, самый большой экскаватор и прочее. Потому когда, через много лет, снова появляются потребности и деньги — всё с нуля приходится изобретать…
                                                                                                                        0
                                                                                                                        И возникает вопрос — если двигатель С ТАКИМИ ПАРАМЕТРАМИ был (сам двигатель в музее стоит) то почему его не использовали потом и не могут воссоздать сейчас?
                                                                                                                        Потому что это не единственные его параметры. Есть еще цена и технологический стек у производителя как минимум. И с включением этих параметров создавать точно такой же двигатель не имеет смысла. А еще есть цель, то есть ее как раз нет. Такой же двигатель банально никому не нужен. Вообще спасибо, это прекрасная каноничная иллюстрация того о чем я говорю — появилась необходимость и сделали лучше на современных технологиях. Да, если бы этот двигатель модернизировали непрерывно с момента его создания, то сейчас не приишлось бы тратить столько времени на создание современного аналога. Но это просто вопрос цены — что нам жалко больше ресурсы на модернизацию того, что не нужно или время на создание более совершенного аналога когда таки станет нужно.
                                                                                                                        0
                                                                                                                        Они умерли потому что есть что-то более современное, что пришло им на замену
                                                                                                                        Причина не в этом. В случае с СССР после прекращения его существования, было до 800 технологий утрачено. Я не уверен в точности цифры. Но в официальном видео от РосАтома (или кто там главный у нас по реакторам) после развала с трудом нашли человека способного запустить какой-то тип ядерного реактора, и это у государства которое является одним из лидеров в ядерной энергетике. Знания размываются, связующие знания теряются. С ТУ-160 та же история, чуть не проимели титановую сварку в вакууме, но вроде нашлись знатоки. Что-то более современное иногда не приходит.
                                                                                                                          0
                                                                                                                          Нет, несомненно иногда из-за катаклизмов знания реально могут потеряться. Но насколько я понял в предыдущих комментариях речь шла именно о естественном процессе безо всяких катаклизмов. В таком случае если какие-то знания потеряны, значит либо кто-то облажался с планированием, либо они реально были не нужны. Ну и насчет:
                                                                                                                          Что-то более современное иногда не приходит.
                                                                                                                          Другие страны же это как-то делают. В РФ не так уж много технологий нужных кому-то еще и которых ни у кого больше нет. Ну может кроме военки, но я тут не силен. Или я ошибаюсь и весь мир страдает без титановой сварки в вакууме?
                                                                                                                            0
                                                                                                                            По поводу страданий всего мира без титановой сварки, я не в курсе. Он в общем то прекрасно существовал и без неё, в те времена когда её ещё не было. Потому тут это и правда вопрос к тем кому это было нужно и почему вдруг оно могло не сохраниться. А вот «естественный процесс» у меня вызывает другие вопросы. Винты ломаются, процессоры выходят из строя, помехи в радиоэфире существуют. Потому называть процесс, из которого исключено что-то что в нём имеется и в нём это что-то случается — «естественным процессом» у меня не получается.
                                                                                                                              0
                                                                                                                              По поводу страданий всего мира без титановой сварки, я не в курсе.
                                                                                                                              Ну то есть было не очень корректно на примере этого случая говорить что «Что-то более современное иногда не приходит.», так как вы просто не знаете пришло ли или нет. Конкретно в РФ — нет, потому что дешевле было не потерять технологию. Где-то еще — может быть и пришло. Либо где-то еще эта технология и не терялась даже. Я не говорю что вывод неверен, я тольо говорю что для такого вывода у вас не достаточно оснований. Он при этом вполне может быть и верен.

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

                                                                                                                          это вы сейчас так хитро тендер в хабр впихнули? или кто та там на верху забыл как плутоний обогащать=)) headhunter не
                                                                                                                            0
                                                                                                                            Не забыли, все записано. Вопрос только — понять. Если вы определяли концентрацию чего-то титрованием при помощи реактива К-1228, то в документации у вас, для быстроты, записана концентрация по этому реактиву. И это нормально, потому что реактива на складе стоит бочка, а если кончится, то позвоним в фирму «Кемикал систерс» и они еще бочку привезут. Вот только склада уже лет 50 нет. А фирма обанкротилась и архивы бесследно исчезли. И как готовить реактив К-1228 никто не знает.

                                                                                                                            Это образно говоря. Но вполне возможно наткнутся на измерения уникальными приборами, с записью результатов в единицах шкал этих приборов. Или реакции которые тогда шли, а сейчас не идут, потому что степень очистки вещества поменялась, а примеси работали как катализаторы.
                                                                                                                            0
                                                                                                                            > сейчас НЕВОЗМОЖНО воспроизвести многие вещи произведённые 20-40 лет назад

                                                                                                                            Невозможно сделать это ДЁШЕВО. Если это будет вопрос выживания — воспроизведут. Дорого, за десять тысяч человеко-лет, скажем, но воспроизведут. Да и пример ваш не очень — КНДР, вон, справилась с плутонием.
                                                                                                                            Пример с нефтезаводом тоже не очень. Построили же! Ну с нуля, но построили. Вот, скажем, в 18 веке не построили бы, вот никак, что с документацией, что без, потому что знаний в культуре не было, и весь завод был непонятная магия.
                                                                                                                            +1
                                                                                                                            В одном городе, в 2000-ом, один человек сделал web-gis на MapGuide, а потом эмигрировал. Через 15 лет ко мне обратились люди которых просили это модернизировать, они не понимали как это устроенно. Сайт за это время, пережил несколько перездов и продолжал работать — при том, что никто не понимал как…
                                                                                                                              0
                                                                                                                              та ладно вам, вон выше у кремлеботов химик ядерщик кажется в праотцам эмигрировал=) гугл на запрост о смерти ядерщика подсказывает Владимир Дмитриевич Фёдоров (5 сентября 1930 — 3 июня 2017). У китайских соседей тоже кажется беда. В Пекине 16 января в возрасте 93 лет скончался известный физик-ядерщик, изобретатель китайской водородной бомбы Юй Минь. Как известно, водородная бомба в Китае была создана в 1966 году. При этом Юй Минь смог решить ряд ключевых проблем при ее разработке, за что в дальнейшем его прозвали отцом китайского аналога этого вида оружия массового поражения. К тому же, ученый считается единственным авторитетным китайским специалистом-ядерщиком, который никогда не учился за границей.
                                                                                                                            +2
                                                                                                                            Рецепт булата и дамасской стали был в своё время утерян. И что?
                                                                                                                          +1
                                                                                                                          Не согласен с пониманием магии(видимо это уже занудство, но все же). Почему не можем понять магию? Есть вещи, которые когда-то были просто волшебством — фантастикой в чьих-то воображениях и мечтах, например, смартфон, сто лет назад это было бы воспринято чистым волшебством(у некоторых людей, не думаю что у всех), телевизор тоже самое. Да я знаю суть на самом деле не в этом и я вообще свернул куда-то в другие дебри. Тем не менее для строгости ради высказался. Магия относительна. Относительна времени и культуры.
                                                                                                                            0

                                                                                                                            Здесь понимание магии как таковой не в том, что она для кого-то — фантастика, а для кого-то — реальность, а в том, что никто её не может объяснить толком. Вот лично я, разбираясь в достаточно простой (на первый взгляд) технологии — техниках рендеринга 3д игр, увяз в тоннах деталей, потонул как раз в той самой "магии" не потому, что это эпоха такая, или я плохой, а потому лишь, что тысячи последовательно возникавших идей создали многоуровневую сложность, пониманием (имею ввиду виду простоту и лёгкость осознания, Simple is better than complex — Python Zen) которой часто жертвуют ради других целей: эффективности, красочности и так далее.
                                                                                                                            Всё это приводит к тому, что если раньше, будучи энтузиастом, можно было легко покорять геймдев с минимальными знаниями, то сейчас есть шанс вообще не постигнуть этот дар богов.

                                                                                                                              0
                                                                                                                              Вы просто пытаетесь охватить больше чем нужно. Все эти слои абстракции как раз и создавались чтобы не было необходимости понимать все от самого верха до самого низа.
                                                                                                                                0
                                                                                                                                … разделение труда — основа прогресса.
                                                                                                                                  0
                                                                                                                                  Ну собственно именно об этом я и говорю, да. Вроде бы принципу тысячи лет, буквально, но все равно находятся люди которые его не понимают.
                                                                                                                                0
                                                                                                                                Здесь понимание магии как таковой не в том, что она для кого-то — фантастика, а для кого-то — реальность, а в том, что никто её не может объяснить толком. Вот лично я, разбираясь в достаточно простой (на первый взгляд) технологии — техниках рендеринга 3д игр, увяз в тоннах деталей, потонул как раз в той самой «магии» не потому, что это эпоха такая, или я плохой, а потому лишь, что тысячи последовательно возникавших идей создали многоуровневую сложность, пониманием (имею ввиду виду простоту и лёгкость осознания, Simple is better than complex — Python Zen) которой часто жертвуют ради других целей: эффективности, красочности и так далее.
                                                                                                                                Всё это приводит к тому, что если раньше, будучи энтузиастом, можно было легко покорять геймдев с минимальными знаниями, то сейчас есть шанс вообще не постигнуть этот дар богов.
                                                                                                                                С магией точно так же. Просто многое утрачено. инквизиций, церкви. Сколько литературы созжено. Люди боятся того что не понимают.
                                                                                                                                Техпроцесс основан на самопознаний, на силе разума и чем та там еще. Типа человек может контроливать на атомном уровне силой мысли.
                                                                                                                              +2
                                                                                                                              если хоть четверть веб-разработчиков знают и понимают, что под капотом у V8

                                                                                                                              Если много знать о внутренностях V8, то и код получится заточенный под Google Chrome, а пользователи Firefox расстроятся. Поэтому лучше опираться на стандарт языка, а не на конкретную реализацию.

                                                                                                                              +3
                                                                                                                              Прямо сейчас вы можете позвонить мебельщику, сказать:«сделай мне тумбочку» и получить завтра «что-то», этот результат определенно будет тумбочкой.
                                                                                                                              Но можете немного вникнуть в детали, и сказать:«мне нужна тумбочка размерами x-y-z», что уже лучше.
                                                                                                                              Можете еще глубже погрузиться в детали, описать цвет, текстуру, материалы, фурнитуру, способ установки, разбивку внутреннего пространства и даже способы скрепления отдельных частей дуг с другом.

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

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