Прекомпилированные файлы работают зачастую криво. Или вот еще — если есть группа связанных проектов («solution» в терминах VC++) и у них есть общие заголовочные файлы, то для каждого проекта из группы придется генерировать свой precompiled header.
Синтаксический же макрос это просто нормальная человеческая реализация того, что на шаблонах С++ реализовано так как оно реализовано. Если мне надо цикл, то я и напишу цикл (и он будет выполнен внутренним интерпретатором компилятора как обычный цикл), а не рекурсивно сгенерирую шаблон из шаблона с отжиранием гигабайтов памяти.
Все очень просто, и с препроцессором тоже (хотя этот препроцессор, т.к. лексические макросы — это не самое лучшее что может быть...). В двоичную структуру модуля точно так же можно ввести ноды условной компиляции, даже ноды циклов и т.п. Да, конечно это будет означать, что модуль внутри будет чем-то вроде кодогенерирующего скрипта, а не просто статической таблицы.
Прекомпилированные заголовочные файлы это костыль. А с модульностью все было бы очень просто: модули (в том числе и с шаблонами) хранились бы в двоичном виде (в виде синтаксического дерева) и весь процесс компиляции (и линковки заодно) состоял бы в загрузке модулей в память в единое синтаксическое дерево и генерации целевого кода из этого единого дерева.
Проблема шаблонов в том, что кому-то очень умному пришла в голову мысль писать на них программы как на функциональном языке (в результате шаблоны раскрываются рекурсивно в какие-то другие шаблоны, что и сжирает всю память); ну так это решается введением нормальных синтакических макросов — как только они появятся, у подавляющего большинства быстро отпадет желание писать метапрограммы на шаблонах.
Я же написал — принципиальные отличия будут в работе компилятора. Почитайте как это устроено в C#, Java, в любом другом языке программирования. Модули это самая ожидаемая фича С++, кто об этом только не пишет.
Сейчас С/С++ работает так. Есть c(pp) файл — в нем в начале десяток инклудов, каждый из которых еще нередко тянет за собой кучу других инклудов. Компилятор рекурсивно раскрывает все эти инклуды и делает в памяти один большой файл, в котором включен код всех инклудов и в конце код собственно с(pp) файла. И все это колмпилирует.
Затем компилятор переходит к другому файлу. А там такая же ситуация (возможно набор инклудов немного другой). Итого, каждый раз(!) компилятор формирует в памяти огромные файлы с кучей всего и их компилирует.
И ладно в Си, там инклуды всего лишь объявления функций и структур. А С++ с его бешеными шаблонами? Когда огромные объемы кода (именно настоящего кода, а не объявлений) приходится держать в заголовочных файлах?
При модульности эта операция делается один раз для всего проекта. Да, разумеется единицей трансляции станет не файл, а проект — но что в этом плохого? Сами по себе концепции пофайловой компиляции и линковки тоже устарели, и их тоже давно пора пересмотреть.
Я в курсе и про printf (то что существует printf это следствие отсутствия в Си синтаксических макросов, которые бы могли распарсить форматную строку на этапе компиляции, да еще и типы аргументов проверить...). Я в курсе как работает strcmp. И про json тоже.
Я не против SAX-подобной идеологии для конфигов (т.е. без «DOM», без хеш-таблиц и деревьев в памяти), и да — в большинстве случаев простого текстового файла типа «ключ-значение» будет достаточно. Просто я хочу чтобы этот формат был стандартизирован и унифицирован, и чтобы тогда уж ничего кроме «ключ-значение» в него вставлять было нельзя.
А что такое «грузить модули динамически со статической типизацией»? Модульность на этапе компиляции лишь означает, что никаких инклудов, а вместо них в проект подключаются модули (файлы в специальном формате — по сути сериализованные синтаксические деревья кода на С/С++), которые компилятор сразу все загружает в единое синтаксическое дерево, а не парсит один инклуд по 100500 раз для каждого *.c и *.cpp файла (precompiled headers это тоже костыли).
Конфиги имеют может и примитивный, но не единый формат. А нередко конфиги имеют еще и скрипты внутри… Вот недавно была статья про GRUB. Там есть grub.cfg. Вроде и расширение «cfg» — но нет, куча скриптового кода на каком-то шелл-подобном языке (кстати, на каком? а понятия не имею, расширение же не «sh»… да и может ли быть «шелл» когда еще ОС не загружена?..)
В общем, хотите текстовые конфиги — пожалуйста, но они должны иметь единый, унифицированный и стандартизированный формат для всей ОС. «Ключ = Значение». Ну еще комментарии. Все, точка.
Далее. XML конечно тяжеловат, а JSON вполне нормален. Особенно предложенный JSON5. Это должна быть не замена «простым текстовым» конфигам (которые просто ключ-значение), а вариант для сложных конфигов, имеющих иерархическую внутреннюю структуру (а большинство таки имеет ее). Собственно, на этом форматами конфигов можно и ограничиться. И еще, одна вещь которая хороша в винде и не свойственна линуксу: расширения. Они должны быть стандартизированы, и для конфигов тоже. Это важно в том числе и для GUI -утилит, которые могли бы просканировать директорию с конфигами и предоставить пользователю унифицированные средства настройки системы из GUI.
Далее, бинарные утилиты. Ну так для текста тоже нужны специальные утилиты — текстовые редакторы. Нужно просто разработать простой и понятный бинарный формат и написать сначала стандарт, а потом и утилиты.
Далее, по языку С (и С++). 15 лет на них пишу, и главная проблема — именно отсутствие модульности и механизм инклудов. Нужно просто принять стандарты С 2.0 и С++ 2.0 в которых выкинуть (да, именно выкинуть, без оглядки на легаси совмесимость) весь этот ужас, и развивать дальше только их. Любые изменения в старый С и С++ заморозить на уровне комитета по стандартизации. Все новые вкусные плюшки добавлять только в 2.0. И все перейдут как миленькие. И легаси код перепишут — благо, в целом языки останутся очень похожими. Заодно в процессе переписывания и кучу багов исправят, т.к. некоторые вещи связанные с типизацией стоит сделать строже.
Язык shell. Я например на нем и не пишу ничего, но приходится вносить изменения в существующие скрипты. И эти скрипты оказываются не такими уж и маленькими.
Винда тоже неидеальна. Некоторые вещи в винде вообще ужасны. Но пост-то не о винде, а о том как сделать юникс (главным образом линукс) лучше.
Статья написана вполне нормально. Для тех кто реально понимает и на практике с этим сталкивался, все понятно и знакомо.
А если писать более подробно, то будет не статья а многотомное собрание сочинений.
К сожалению, какой бы хорошей не была система, она скорее всего не взлетит. Нужно пробить огромную инертную массу в виде существующих и как-то работающих технологий, решений, знаний и специалистов. Это зачастую гораздо сложнее чем придумать что-то новое и гениальное.
Полностью согласен с автором. Я не такой спец по юниксам, но сталкиваться приходилось достаточно. Кривизна make и shell сразу бросается в глаза. Кривизна препроцессора С/С++ и отсутствие в них модульности — тоже (хотя пишу на С/С++ как основном языке уже много лет).
С другой стороны многие концепции в юниксе очень удачны и даже гениальны. Есть фундаментальные вещи из линукса которых очень не хватает в винде. И наоборот.
А проблема — в инертности мышления, да и в инертности общества вообще.
Разработали — работает как-то — а зачем трогать и улучшать? Мозг-то привыкает к любым костылям.
И в результате может и есть где-то системы, лучшие (или хотя-бы потенциально лучшие) чем Unix (да и чем Windows, чего уж там) — но кто о них знает? А проект сдавать завтра, а инфы по этим новым системам кот наплакал — зато по линуксу и винде гигабайты статей и обсуждений на разнообразных сайтах и форумах, куча специалистов в совершенстве знающих любые костыли и готовых помочь…
Увы. Тут нужна какая-то централизация. По идее ветеранам Unix нужно больше прислушиваться к мнениям людей с незамыленным взглядом. Не совсем новичков, но и не тех кто уже привык и не замечает всей этой кривизны. В сообществе должно быть понимание того, что гениально а что костыли. Должны вырабатываться какие-то совместные дорожные карты. Планы по вытеснению и замене кривых и морально устаревших возможностей на новые. Стандартизация всего этого.
Так, вместо make давно бы уже перешли на qbs. Что мешает корпорациям, осуществляющим основной вклад в разработку того же линуса, перейти на эту технологию? Если там чего не хватает — ну так оно и выяснится, сформировали бы консорциум, подумали бы все вместе. И постепенно вытеснили бы make. Но нет — оно же «и так работает»… печально все это.
Проблема в том что для системного программирования кроме С и С++ пока к сожалению ничего нет (ну вот появился Rust но он еще мало распространен… да и с синтаксисом некоторые вопросы к интуитивности, в тех же же C# или Java все гораздо более понятно, причем сходу, без необходимости погружаться в нюансы языка).
Кстати, скажите, а в WIn7 SP1 без каких-либо обновлений вообще ( имеется в виду со службой update, отключенной сразу после установки) есть эта телеметрия или еще нет?
Если все это подтвердится то круто. Вообще кажется, что сверхпроводимость это одна из таких зацепочек, с помощью которых можно от физики обычной материи перейти к физике того что нам недоступно напрямую… Может быть, при наличии математического аппарата удастся рассчитать конфигурации вещества, при которых оно будет приобретать и другие необычные свойства, вплоть до каких-нибудь совсем фантастических.
Ну а с точки зрения применимости в мире какой английский более распространен — британский или американский? Я не знаю, чисто из общих соображений кажется что американский но могу ошибаться…
Неистово плюсую, огромное, огромное вам спасибо! И цена везде «бесплатно»:)
Еще можно указать есть ли текстовые транскрипты к голосовому файлу, чтобы можно было почитать если что-то на слух непонятно.
Мне больше нравится обычная витая пара Ethernet. Главным образом своей универсальностью — проведенная в квартиру один раз, она позволяет подключаться к любому провайдеру, а не долбить стены ради каких-то новых кабелей (PON, а также DOCSIS и прочие коаксиалы). Также она позволяет работать и вообще без роутера (хотя у меня роутер есть, но почему он обязан быть у каждого если из устройств допустим один ноутбук?). Почему Ростелеком не хочет работать по этой технологии?
Синтаксический же макрос это просто нормальная человеческая реализация того, что на шаблонах С++ реализовано так как оно реализовано. Если мне надо цикл, то я и напишу цикл (и он будет выполнен внутренним интерпретатором компилятора как обычный цикл), а не рекурсивно сгенерирую шаблон из шаблона с отжиранием гигабайтов памяти.
Проблема шаблонов в том, что кому-то очень умному пришла в голову мысль писать на них программы как на функциональном языке (в результате шаблоны раскрываются рекурсивно в какие-то другие шаблоны, что и сжирает всю память); ну так это решается введением нормальных синтакических макросов — как только они появятся, у подавляющего большинства быстро отпадет желание писать метапрограммы на шаблонах.
Сейчас С/С++ работает так. Есть c(pp) файл — в нем в начале десяток инклудов, каждый из которых еще нередко тянет за собой кучу других инклудов. Компилятор рекурсивно раскрывает все эти инклуды и делает в памяти один большой файл, в котором включен код всех инклудов и в конце код собственно с(pp) файла. И все это колмпилирует.
Затем компилятор переходит к другому файлу. А там такая же ситуация (возможно набор инклудов немного другой). Итого, каждый раз(!) компилятор формирует в памяти огромные файлы с кучей всего и их компилирует.
И ладно в Си, там инклуды всего лишь объявления функций и структур. А С++ с его бешеными шаблонами? Когда огромные объемы кода (именно настоящего кода, а не объявлений) приходится держать в заголовочных файлах?
При модульности эта операция делается один раз для всего проекта. Да, разумеется единицей трансляции станет не файл, а проект — но что в этом плохого? Сами по себе концепции пофайловой компиляции и линковки тоже устарели, и их тоже давно пора пересмотреть.
Я не против SAX-подобной идеологии для конфигов (т.е. без «DOM», без хеш-таблиц и деревьев в памяти), и да — в большинстве случаев простого текстового файла типа «ключ-значение» будет достаточно. Просто я хочу чтобы этот формат был стандартизирован и унифицирован, и чтобы тогда уж ничего кроме «ключ-значение» в него вставлять было нельзя.
А что такое «грузить модули динамически со статической типизацией»? Модульность на этапе компиляции лишь означает, что никаких инклудов, а вместо них в проект подключаются модули (файлы в специальном формате — по сути сериализованные синтаксические деревья кода на С/С++), которые компилятор сразу все загружает в единое синтаксическое дерево, а не парсит один инклуд по 100500 раз для каждого *.c и *.cpp файла (precompiled headers это тоже костыли).
В общем, хотите текстовые конфиги — пожалуйста, но они должны иметь единый, унифицированный и стандартизированный формат для всей ОС. «Ключ = Значение». Ну еще комментарии. Все, точка.
Далее. XML конечно тяжеловат, а JSON вполне нормален. Особенно предложенный JSON5. Это должна быть не замена «простым текстовым» конфигам (которые просто ключ-значение), а вариант для сложных конфигов, имеющих иерархическую внутреннюю структуру (а большинство таки имеет ее). Собственно, на этом форматами конфигов можно и ограничиться. И еще, одна вещь которая хороша в винде и не свойственна линуксу: расширения. Они должны быть стандартизированы, и для конфигов тоже. Это важно в том числе и для GUI -утилит, которые могли бы просканировать директорию с конфигами и предоставить пользователю унифицированные средства настройки системы из GUI.
Далее, бинарные утилиты. Ну так для текста тоже нужны специальные утилиты — текстовые редакторы. Нужно просто разработать простой и понятный бинарный формат и написать сначала стандарт, а потом и утилиты.
Далее, по языку С (и С++). 15 лет на них пишу, и главная проблема — именно отсутствие модульности и механизм инклудов. Нужно просто принять стандарты С 2.0 и С++ 2.0 в которых выкинуть (да, именно выкинуть, без оглядки на легаси совмесимость) весь этот ужас, и развивать дальше только их. Любые изменения в старый С и С++ заморозить на уровне комитета по стандартизации. Все новые вкусные плюшки добавлять только в 2.0. И все перейдут как миленькие. И легаси код перепишут — благо, в целом языки останутся очень похожими. Заодно в процессе переписывания и кучу багов исправят, т.к. некоторые вещи связанные с типизацией стоит сделать строже.
Язык shell. Я например на нем и не пишу ничего, но приходится вносить изменения в существующие скрипты. И эти скрипты оказываются не такими уж и маленькими.
Винда тоже неидеальна. Некоторые вещи в винде вообще ужасны. Но пост-то не о винде, а о том как сделать юникс (главным образом линукс) лучше.
Вот именно что обернуты а не выкинуты. В этом и суть костылей. ..
А если писать более подробно, то будет не статья а многотомное собрание сочинений.
С другой стороны многие концепции в юниксе очень удачны и даже гениальны. Есть фундаментальные вещи из линукса которых очень не хватает в винде. И наоборот.
А проблема — в инертности мышления, да и в инертности общества вообще.
Разработали — работает как-то — а зачем трогать и улучшать? Мозг-то привыкает к любым костылям.
И в результате может и есть где-то системы, лучшие (или хотя-бы потенциально лучшие) чем Unix (да и чем Windows, чего уж там) — но кто о них знает? А проект сдавать завтра, а инфы по этим новым системам кот наплакал — зато по линуксу и винде гигабайты статей и обсуждений на разнообразных сайтах и форумах, куча специалистов в совершенстве знающих любые костыли и готовых помочь…
Увы. Тут нужна какая-то централизация. По идее ветеранам Unix нужно больше прислушиваться к мнениям людей с незамыленным взглядом. Не совсем новичков, но и не тех кто уже привык и не замечает всей этой кривизны. В сообществе должно быть понимание того, что гениально а что костыли. Должны вырабатываться какие-то совместные дорожные карты. Планы по вытеснению и замене кривых и морально устаревших возможностей на новые. Стандартизация всего этого.
Так, вместо make давно бы уже перешли на qbs. Что мешает корпорациям, осуществляющим основной вклад в разработку того же линуса, перейти на эту технологию? Если там чего не хватает — ну так оно и выяснится, сформировали бы консорциум, подумали бы все вместе. И постепенно вытеснили бы make. Но нет — оно же «и так работает»… печально все это.
Еще можно указать есть ли текстовые транскрипты к голосовому файлу, чтобы можно было почитать если что-то на слух непонятно.