Есть куча шариков, из них 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), прикладная математика, криптография и т.п.
И не только внешность. Должна быть возможность менять все.
Правда, не очень понятно как менять ДНК у живого организма — путем создания специальных вирусов разве что…
Новость интересная, надеюсь увидеть живого мамонта.
Но такое впечатление, что пока отстают технологии извлечения ДНК и РНК из тканей… по идее, нужно отсканировать миллиадры молекул (которые, естественно, все повреждены), загрузить это в суперкомпьютер и попытаться восстановить оригинальный генетический материал.
Давно интересно вот что: существует теория электрослабого взаимодействия. Официальная, хорошо проработанная. Электромагнитное взаимодействие используется в технике повсеместно… а слабое? Есть ли практическое применение «электрослабого» взаимодействия в технике, именно с использованием «слабой» составляющей? Возможно где-нибудь в полупроводниковых приборах и т.п.? Или у него настолько маленький радиус действия, что применить до сих пор не удалось?
Ну вот уменьшение размеров оборудования приводит как правило к необходимости отказаться от части оборудования. Или к снижению надежности. Так не проще ли слетать на орбиту несколько раз, доставив туда все что нужно, и затем оттуда спокойно запустить корабль к планетам-гигантам?
Вообще конечно напрашивается сборка большой ракеты на орбите (например на МКС), сразу с несколькими аппаратами-планетоходами и спутниками на борту (по идее для как можно большего числа спутников планет-гигантов, там же не только Титан интересный...) и отправка ее непосредственно из космоса. К Юпитеру, Сатурну, Урану…
Интересно, возможно ли это сейчас технически? Удешевило бы это проект?
Интересная новость… предвижу, как взвоют адепты олдскульной сишечки:)
На самом деле действительно есть С++ (в том числе и для низкоуровневого кодинга, для микроконтроллеров и т.п.)
Но если уж вводить — можно еще вместо наследования взять «embedding» из Go — для низкоуровневого языка самое то. Можно включать одну структуру в произвольную позицию другой, при этом позицию программист определяет явно (в отличие от наследования). А какие хаки можно будет на этом делать…
Скрытая масса, которая проявляется только при взаимодействии с обычной массой — возможно материя, существующая за пределами трехмерного пространства и связанная с нашим пространством только за счет искривлений… или что-то такое, именно такие ассоцииации приходят в голову :)
Формально она является частью языка, а не библиотекой (и, кстати, давно уже называется не «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), прикладная математика, криптография и т.п.
Правда, не очень понятно как менять ДНК у живого организма — путем создания специальных вирусов разве что…
— Ну, это же элементарно! Представьте N-мерную и положите N = 7.
Но такое впечатление, что пока отстают технологии извлечения ДНК и РНК из тканей… по идее, нужно отсканировать миллиадры молекул (которые, естественно, все повреждены), загрузить это в суперкомпьютер и попытаться восстановить оригинальный генетический материал.
Интересно, возможно ли это сейчас технически? Удешевило бы это проект?
Не понял, это ведь не исходники компилятора С++ msvc? Или и они тоже?
На самом деле действительно есть С++ (в том числе и для низкоуровневого кодинга, для микроконтроллеров и т.п.)
Но если уж вводить — можно еще вместо наследования взять «embedding» из Go — для низкоуровневого языка самое то. Можно включать одну структуру в произвольную позицию другой, при этом позицию программист определяет явно (в отличие от наследования). А какие хаки можно будет на этом делать…