Все неверно.
Единственный технически возможный вариант бессмертия — периодическое клеточное омоложение организма.
1 это не настоящее бессмертие "однократного действия" (принял пилюлю и бессмертен навсегда) — это медицинская процедура, достаточно сложная. И делать ее надо будет периодически.
2 как следствие это не бесплатно. Таким образом возникает естественный барьер на пути перенаселения.
3 это не вечная молодость и не вечная старость в прямом смысле. Биохимия человека омолаживается и человек биологически реально становится моложе. Но знания и опыт никуда не исчезают. Получится новая формация людей.
Сейчас главное — приблизить момент реализации этой давней мечты человечества.
Сейчас уже символы по сути генерировать можно. Цвета уже судя по всему есть в ограниченном виде (цвета кожи). А потом захотят анимацию и чего нибудь еще…
Вангую, что через пару десятков лет это все закончится появлением в Юникоде специальных невидимых символов для условий, циклов, объявления переменных, внутренних арифметических операций и в конечном итоге будет какой нибудь UnicodeScript.
Это прекрасно, побольше таких статей на Хабре и Гиктаймс!.. Очень интересная тема, и очень не хватает информации — по современным исследованиям в области продления жизни, особенно в области генетики и микробиологии (здоровое питание это конечно тоже важно, но ключ к реальному, клеточному омоложению лежит таки именно в области микробиологии и генной инженерии). Также интересны различные трансгуманистические направления и движения, стартапы, люди и фонды которые вкладывают в это деньги…
Нужно всячески популяризировать это направление, особенно среди «технологической элиты», в нашем случае IT-специалистов и гиков. Ну и вообще очень хочется как-то помочь. Возможно наивное желание, но вот так… а для того чтобы это сделать, надо знать как можно больше.
Мне вот что интересно — если бы язык С++ можно было проектировать с нуля, не оглядываясь на «обратную совместимость», то как бы следовало спроектировать rvalue references? Так как сделано сейчас или как-то иначе?
Ну так в итоге-то, почему разбросы? Зачем калибровать, если простые ртутные калибровать не надо (или это делается как-то на заводе в процессе производства).
Я мог предположить, что наиболее интересный юзкейс инфракрасного термометра — измерение температуры в разных частях тела (своеобразный тепловизор) с тем чтобы определить локальное повышение температуры в конкретном месте, что может дать дополнительную информацию о том какой орган может быть не в порядке. Но для этого нужна даже повышенная по сравнению со ртутными точность… а получается что этой возможности нет?
Неплохо бы к обзору добавить популярные сайты, использующие тот или иной фреймворк.
Например, по моей личной классификации один из самых тормознутых сайтов это Твиттер, один из самых бестолковых (да и тоже не без тормозов) это Фейсбук. Чтобы знать что не нужно использовать, чтобы не уподобляться этим сайтам.
А вот например ВКонтакте и Хабр — очень даже шустрые. Полезно знать какие фреймворки там применяются и применяются ли вообще.
Я вообще считаю, что если возникает такая потребность как «эти файлы несмотря на расширение не трогай» то тут что-то не то. Да и генерить файлы… ну не всегда это нужно. Я писал проекты с тысячами файлов исходного кода, и нигде такое не требовалось. Хотя я понимаю что это может быть необходимо в каких-то случаях.
Но вот сейчас я скажу такую вещь… 99% всех потребностей должны покрывать не make-файлы, а декларативные(!) файлы проектов. То есть просто файл с перечислением файлов исходников, опций компиляции проекта в целом (и возможно опций компиляции конкретных файлов)… и все! Да, те редкие случаи когда нужно запустить какую-то внешнюю программу, должны быть предусмотрены — но они должны быть тщательно огорожены и рассматриваться скорее как исключение, чем как правило.
Ну, дьявол, как известно, в деталях. Да автор и сам пишет, что «Есть идеи в UNIX, которые мне реально нравятся». Идеи Юникс в целом прекрасны и замечательны, а вот все проблемы именно в частных недоработках. Причем эти частные недоработки расползлись и размазались тонким слоем по всему Юниксу, так что иногда даже сформулировать бывает сложно… но автор попытался, за что ему честь и хвала, я бы так не смог (хотя наталкивался на все это тоже).
Бизнесу надо в основном «быстрее чем у конкурентов». Лучше там или не лучше — в определенных пределах пофиг; главное ввязаться, заявить о себе, а пипл все равно схвавает.
То есть конечно откровенно не работающие программы в продакшен не попадают, но вот ради перфекционизма и внутренней архитектурной красоты никто заморачиваться не будет.
Я бы и сам не отказался от хорошей статьи (возможно на английском) по правильному объяснению модулей. Может другие хабровчане подкинут ссылок?
Я как-то набрался информации из разных источников, в голове она сложилась в более-менее единую картинку, но раз вы не поняли то значит я не могу нормально объяснить:)
1. Бага в коде для обхода костылей исправляется сложнее:) Чем чище и прозрачнее архитектура решаемой задачи, тем меньше там возможностей допустить ошибки.
2. Да, мне не нравится синтаксис; мне не нравится то, что шаблоны используются для того, для его они изначально не были спроектированы. Я не против функционального программирования, а когда оно интегрировано с императивным это вообще супер. А то что мы имеем с шаблонами это не проктировалось а было открыто случайно… поэтому сами понимаете о какой архитектуре там может идти речь. Ни о какой.
Все взаимосвязано. Простота и ясность синтаксиса языка приводят к простоте и ясности кода компилятора, значит в нем будет меньше ошибок, он будет потреблять меньше памяти и работать быстрее. И наоборот, когда в синтаксисе языка черт ногу сломит, в коде компилятора будет то же самое.
Прекомпилированные файлы работают зачастую криво. Или вот еще — если есть группа связанных проектов («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. Я например на нем и не пишу ничего, но приходится вносить изменения в существующие скрипты. И эти скрипты оказываются не такими уж и маленькими.
Винда тоже неидеальна. Некоторые вещи в винде вообще ужасны. Но пост-то не о винде, а о том как сделать юникс (главным образом линукс) лучше.
Все неверно.
Единственный технически возможный вариант бессмертия — периодическое клеточное омоложение организма.
1 это не настоящее бессмертие "однократного действия" (принял пилюлю и бессмертен навсегда) — это медицинская процедура, достаточно сложная. И делать ее надо будет периодически.
2 как следствие это не бесплатно. Таким образом возникает естественный барьер на пути перенаселения.
3 это не вечная молодость и не вечная старость в прямом смысле. Биохимия человека омолаживается и человек биологически реально становится моложе. Но знания и опыт никуда не исчезают. Получится новая формация людей.
Сейчас главное — приблизить момент реализации этой давней мечты человечества.
Вангую, что через пару десятков лет это все закончится появлением в Юникоде специальных невидимых символов для условий, циклов, объявления переменных, внутренних арифметических операций и в конечном итоге будет какой нибудь UnicodeScript.
Нужно всячески популяризировать это направление, особенно среди «технологической элиты», в нашем случае IT-специалистов и гиков. Ну и вообще очень хочется как-то помочь. Возможно наивное желание, но вот так… а для того чтобы это сделать, надо знать как можно больше.
Я мог предположить, что наиболее интересный юзкейс инфракрасного термометра — измерение температуры в разных частях тела (своеобразный тепловизор) с тем чтобы определить локальное повышение температуры в конкретном месте, что может дать дополнительную информацию о том какой орган может быть не в порядке. Но для этого нужна даже повышенная по сравнению со ртутными точность… а получается что этой возможности нет?
Например, по моей личной классификации один из самых тормознутых сайтов это Твиттер, один из самых бестолковых (да и тоже не без тормозов) это Фейсбук. Чтобы знать что не нужно использовать, чтобы не уподобляться этим сайтам.
А вот например ВКонтакте и Хабр — очень даже шустрые. Полезно знать какие фреймворки там применяются и применяются ли вообще.
Но вот сейчас я скажу такую вещь… 99% всех потребностей должны покрывать не make-файлы, а декларативные(!) файлы проектов. То есть просто файл с перечислением файлов исходников, опций компиляции проекта в целом (и возможно опций компиляции конкретных файлов)… и все! Да, те редкие случаи когда нужно запустить какую-то внешнюю программу, должны быть предусмотрены — но они должны быть тщательно огорожены и рассматриваться скорее как исключение, чем как правило.
То есть конечно откровенно не работающие программы в продакшен не попадают, но вот ради перфекционизма и внутренней архитектурной красоты никто заморачиваться не будет.
Я как-то набрался информации из разных источников, в голове она сложилась в более-менее единую картинку, но раз вы не поняли то значит я не могу нормально объяснить:)
2. Да, мне не нравится синтаксис; мне не нравится то, что шаблоны используются для того, для его они изначально не были спроектированы. Я не против функционального программирования, а когда оно интегрировано с императивным это вообще супер. А то что мы имеем с шаблонами это не проктировалось а было открыто случайно… поэтому сами понимаете о какой архитектуре там может идти речь. Ни о какой.
Все взаимосвязано. Простота и ясность синтаксиса языка приводят к простоте и ясности кода компилятора, значит в нем будет меньше ошибок, он будет потреблять меньше памяти и работать быстрее. И наоборот, когда в синтаксисе языка черт ногу сломит, в коде компилятора будет то же самое.
Синтаксический же макрос это просто нормальная человеческая реализация того, что на шаблонах С++ реализовано так как оно реализовано. Если мне надо цикл, то я и напишу цикл (и он будет выполнен внутренним интерпретатором компилятора как обычный цикл), а не рекурсивно сгенерирую шаблон из шаблона с отжиранием гигабайтов памяти.
Проблема шаблонов в том, что кому-то очень умному пришла в голову мысль писать на них программы как на функциональном языке (в результате шаблоны раскрываются рекурсивно в какие-то другие шаблоны, что и сжирает всю память); ну так это решается введением нормальных синтакических макросов — как только они появятся, у подавляющего большинства быстро отпадет желание писать метапрограммы на шаблонах.
Сейчас С/С++ работает так. Есть c(pp) файл — в нем в начале десяток инклудов, каждый из которых еще нередко тянет за собой кучу других инклудов. Компилятор рекурсивно раскрывает все эти инклуды и делает в памяти один большой файл, в котором включен код всех инклудов и в конце код собственно с(pp) файла. И все это колмпилирует.
Затем компилятор переходит к другому файлу. А там такая же ситуация (возможно набор инклудов немного другой). Итого, каждый раз(!) компилятор формирует в памяти огромные файлы с кучей всего и их компилирует.
И ладно в Си, там инклуды всего лишь объявления функций и структур. А С++ с его бешеными шаблонами? Когда огромные объемы кода (именно настоящего кода, а не объявлений) приходится держать в заголовочных файлах?
При модульности эта операция делается один раз для всего проекта. Да, разумеется единицей трансляции станет не файл, а проект — но что в этом плохого? Сами по себе концепции пофайловой компиляции и линковки тоже устарели, и их тоже давно пора пересмотреть.
Я не против SAX-подобной идеологии для конфигов (т.е. без «DOM», без хеш-таблиц и деревьев в памяти), и да — в большинстве случаев простого текстового файла типа «ключ-значение» будет достаточно. Просто я хочу чтобы этот формат был стандартизирован и унифицирован, и чтобы тогда уж ничего кроме «ключ-значение» в него вставлять было нельзя.
А что такое «грузить модули динамически со статической типизацией»? Модульность на этапе компиляции лишь означает, что никаких инклудов, а вместо них в проект подключаются модули (файлы в специальном формате — по сути сериализованные синтаксические деревья кода на С/С++), которые компилятор сразу все загружает в единое синтаксическое дерево, а не парсит один инклуд по 100500 раз для каждого *.c и *.cpp файла (precompiled headers это тоже костыли).
В общем, хотите текстовые конфиги — пожалуйста, но они должны иметь единый, унифицированный и стандартизированный формат для всей ОС. «Ключ = Значение». Ну еще комментарии. Все, точка.
Далее. XML конечно тяжеловат, а JSON вполне нормален. Особенно предложенный JSON5. Это должна быть не замена «простым текстовым» конфигам (которые просто ключ-значение), а вариант для сложных конфигов, имеющих иерархическую внутреннюю структуру (а большинство таки имеет ее). Собственно, на этом форматами конфигов можно и ограничиться. И еще, одна вещь которая хороша в винде и не свойственна линуксу: расширения. Они должны быть стандартизированы, и для конфигов тоже. Это важно в том числе и для GUI -утилит, которые могли бы просканировать директорию с конфигами и предоставить пользователю унифицированные средства настройки системы из GUI.
Далее, бинарные утилиты. Ну так для текста тоже нужны специальные утилиты — текстовые редакторы. Нужно просто разработать простой и понятный бинарный формат и написать сначала стандарт, а потом и утилиты.
Далее, по языку С (и С++). 15 лет на них пишу, и главная проблема — именно отсутствие модульности и механизм инклудов. Нужно просто принять стандарты С 2.0 и С++ 2.0 в которых выкинуть (да, именно выкинуть, без оглядки на легаси совмесимость) весь этот ужас, и развивать дальше только их. Любые изменения в старый С и С++ заморозить на уровне комитета по стандартизации. Все новые вкусные плюшки добавлять только в 2.0. И все перейдут как миленькие. И легаси код перепишут — благо, в целом языки останутся очень похожими. Заодно в процессе переписывания и кучу багов исправят, т.к. некоторые вещи связанные с типизацией стоит сделать строже.
Язык shell. Я например на нем и не пишу ничего, но приходится вносить изменения в существующие скрипты. И эти скрипты оказываются не такими уж и маленькими.
Винда тоже неидеальна. Некоторые вещи в винде вообще ужасны. Но пост-то не о винде, а о том как сделать юникс (главным образом линукс) лучше.