Интересно, а никому не приходило в голову как-то стандартизировать иконки? Сделать что-то типа консорциума Unicode… ведь по сути иконки в программах (а также множество значков в реальной жизни, начиная от М и Ж на туалетах и заканчивая дорожными знаками и научными/техническими символами) это что-то вроде современной версии иероглифов, и в общем было бы не плохо все это дело стандартизировать.
Известно что-либо о дальшейшей судьбе проекта? Кто-нибудь будет его поддерживать и развивать? Будут ли исправлены выявленные потенциально нехорошие места?
Слова — фигня, их вполне можно выучить в нужном количестве. А вот когда эти 1000 (да даже хоть 100) слов завернуты в хитровывернутые сложносоставные предложения с разными оборотами и идиоматикой, да еще все это сказано с высокой скоростью (как в жизни) — вот тут туши свет.
В такой ситуации маленькое количество слов даже хуже большого — слова повторяются и фиг поймешь о чем речь.
Ну это разумеется не объяснение, а просто аналогия, возникшая при попытке найти аналогичное поведение среди известных нам явлений.
По поводу двух видов темной материи — ну поскольку мы о ней ничего не знаем, то может там и больше видов. Хотя минимально достаточно предположить, что обычная материя — «гравитационно заряженная», а темная — «гравитационно нейтральная» (но при этом все равно участвующая в гравитационном взаимодействии). В гравитации все «заряды» притягиваются (в отличие от электромагнетизма, где есть отталкивание), мы ничего не знаем ни о гравитационно-нейтральных объектах, ни об антигравитации, есть ли такое или нет…
Хотя с другой стороны — обычный свет, фотоны — они вроде как с нулевой массой (и сами вроде бы(?) ничего не притягивают к себе), но тем ни менее прекрасно притягиваются гравитацией звезд и черных дыр.
Даже больше скажу… это чем-то очень похоже на электричество (электростатику). Есть электрически заряженные шарики — они взаимодействуют друг с другом. Есть незаряженные — они притягиваются к заряженным. А два незаряженных (нейтральных) шарика никак не притягиваются и не отталкиваются.
Есть куча шариков, из них 10% липкие и 90% нелипкие. Липкие липнут друг к другу и к нелипким, нелипкие друг к другу не липнут (т.е. в терминах прилипания между собой не «взаимодействуют»). Как-то так:)
Ну если вспомнить ОТО и то что гравитация искривляет пространство, то можно предположить, что темная материя — нечто, существующее в пространстве (и, следовательно, кривизна пространства также влияет и на темную материю); но сама темная материя не искривляет пространство, а только вносит какой-то вклад в уже существующую кривизну (типа катализатора в химии).
Скрытая масса, которая проявляется только при взаимодействии с обычной массой — возможно материя, существующая за пределами трехмерного пространства и связанная с нашим пространством только за счет искривлений… или что-то такое, именно такие ассоцииации приходят в голову :)
Вообще интересно конечно, что это за темная материя. Взаимодействующая с обычной материей только гравитационно, и — возможно — не взаимодействующая сама с собой вообще никак, даже гравитационо?
Тут вы говорите, что Standard Template Library никакой библиотекой на самом деле не является — несколько необычное определение.
Формально она является частью языка, а не библиотекой (и, кстати, давно уже называется не «STL» а просто «стандартаная библиотека»). То есть разработчики компиляторов вообще могут включить весь код стандартной библиотеки внутрь компилятора, и даже заголовочные файлы типа vector не будут открываться как файлы, а будут чем-то вроде ключевых слов. Хотя конечно это странно (и для меня тоже), но что поделаешь — С++ сам по себе старый язык, а еще наследие Си тащить надо…
Собственно, библиотека уже сильно переплетена с компиляторами. Например, для std::initializer_list на самом деле жестко прошито, как такое компилировать. Если вы скопируете стандартный код заголовочного файла initializer_list и просто переименуете класс (скажем в std::initializer_list2) то ничего работать не будет, несмотря на полную идентичность остального кода.
Что касается json — то я бы сказал, что общей частью должна быть концепция иерархического представления данных, а не конкретно json (есть еще и xml, и yaml, и куча других аналогичных средств). В С++ с этим тоже не очень, даже массивы не являются полностью first-class objects.
А json — это как раз библиотека. Конечно, крайне желательно, чтобы в официальной библиотеке языка была стандартная реализация «из коробки» чтения и записи файлов json (равно как и xml). Но у программиста всегда должна быть возможность написать свою реализацию и подключить ее к языковой абстракции «иерархическое представление данных».
Тонкость в том, что «фреймворк» подразумевает группу библиотек, имеющих как правило некую общую часть. То есть из фреймворка невозможно вытащить одну библиотеку с гарантией того, что она не потянет за собой что-то еще.
А вот если бы эта «общая часть» была в стандарте языка, то вместо «фреймворков» были бы «наборы библиотек» — уже никак не связанных между собой.
Вывод — в ядро языка нужно добавлять все то, что потенциально может быть «связующим кодом» между различными библиотеками. В том же boost к этой группе относятся как библиотеки, явно отмеченные «language feature emulation», так и некоторые другие — но концептуально являющиеся скорее языковыми фичами, чем сторонними библиотеками (функциональное программирование, сигналы и слоты, некоторые вещи из метапрограммирования, сопрограммы. рефлексия (которой еще нет) и т.д.). А библиотека — это то, что решает не общеязыковую задачу, а прикладную — например, сетевой протокол, формат данных (тот же json), прикладная математика, криптография и т.п.
В такой ситуации маленькое количество слов даже хуже большого — слова повторяются и фиг поймешь о чем речь.
В общем, интересно все это…
По поводу двух видов темной материи — ну поскольку мы о ней ничего не знаем, то может там и больше видов. Хотя минимально достаточно предположить, что обычная материя — «гравитационно заряженная», а темная — «гравитационно нейтральная» (но при этом все равно участвующая в гравитационном взаимодействии). В гравитации все «заряды» притягиваются (в отличие от электромагнетизма, где есть отталкивание), мы ничего не знаем ни о гравитационно-нейтральных объектах, ни об антигравитации, есть ли такое или нет…
Хотя с другой стороны — обычный свет, фотоны — они вроде как с нулевой массой (и сами вроде бы(?) ничего не притягивают к себе), но тем ни менее прекрасно притягиваются гравитацией звезд и черных дыр.
Скрытая масса, которая проявляется только при взаимодействии с обычной массой — возможно материя, существующая за пределами трехмерного пространства и связанная с нашим пространством только за счет искривлений… или что-то такое, именно такие ассоцииации приходят в голову :)
Формально она является частью языка, а не библиотекой (и, кстати, давно уже называется не «STL» а просто «стандартаная библиотека»). То есть разработчики компиляторов вообще могут включить весь код стандартной библиотеки внутрь компилятора, и даже заголовочные файлы типа vector не будут открываться как файлы, а будут чем-то вроде ключевых слов. Хотя конечно это странно (и для меня тоже), но что поделаешь — С++ сам по себе старый язык, а еще наследие Си тащить надо…
Собственно, библиотека уже сильно переплетена с компиляторами. Например, для std::initializer_list на самом деле жестко прошито, как такое компилировать. Если вы скопируете стандартный код заголовочного файла initializer_list и просто переименуете класс (скажем в std::initializer_list2) то ничего работать не будет, несмотря на полную идентичность остального кода.
Что касается json — то я бы сказал, что общей частью должна быть концепция иерархического представления данных, а не конкретно json (есть еще и xml, и yaml, и куча других аналогичных средств). В С++ с этим тоже не очень, даже массивы не являются полностью first-class objects.
А json — это как раз библиотека. Конечно, крайне желательно, чтобы в официальной библиотеке языка была стандартная реализация «из коробки» чтения и записи файлов json (равно как и xml). Но у программиста всегда должна быть возможность написать свою реализацию и подключить ее к языковой абстракции «иерархическое представление данных».
А вот если бы эта «общая часть» была в стандарте языка, то вместо «фреймворков» были бы «наборы библиотек» — уже никак не связанных между собой.
Вывод — в ядро языка нужно добавлять все то, что потенциально может быть «связующим кодом» между различными библиотеками. В том же boost к этой группе относятся как библиотеки, явно отмеченные «language feature emulation», так и некоторые другие — но концептуально являющиеся скорее языковыми фичами, чем сторонними библиотеками (функциональное программирование, сигналы и слоты, некоторые вещи из метапрограммирования, сопрограммы. рефлексия (которой еще нет) и т.д.). А библиотека — это то, что решает не общеязыковую задачу, а прикладную — например, сетевой протокол, формат данных (тот же json), прикладная математика, криптография и т.п.