Вытачивать шарики долго и сложно, можно упростить до цилиндров (т.е. просто напилить круглую палку [от швабры] на кусочки и приклеить к кубикам)
Вместо крестообразных слонов (для изготовления которых нужен станок) проще взять брусок треугольного сечения и также напилить. По смыслу будет то же - "что-то диагональное".
Не отличается: вот пример, обращение к локальной переменной (аргументу функции) и к полю соврешенно одинаковое (хотя мы знаем что на низком уровне в первом случае работа через указатель this, во втором - просто доступ к стеку). Чтобы отличить, нужно смотреть место объявления. А это может быть где-то далеко в коде (хорошо современные IDE выводят подсказки по наведению мыши на переменную).
class Foo {
int x;
void bar(int y) {
x = 10;
y = 10;
}
}
Ну слияние, а что такого? Вот за счет гравитации две ЧД приблизились друг к другу вплотную, горизонты событий соприкоснулись и пересеклись. Чем не слияние? Это ничем не отличается от падения в ЧД любой материи.
Тут интересно другое. ЧД - это такой идеальный шарик. А при слиянии на очень короткий промежуток времени мы получаем "кривую" ЧД, не в форме шара. Можно даже пофантазировать о более сложных конфигурациях слияния, когда некая сверхцивилизация ради безумного эксперимента одномоментно сливает сотни и тысячи черных дыр, к примеру в форме сферы, образуя на короткое время некую область нормального пространства внутри сплошного кокона из черных дыр, Что будет с таким пространством?
Т.е. вы предлагаете все переменные (в том числе те которые "по значению") признать ссылками и использовать унифицированный синтаксис? Как уже заметили, в таком коде будет слишком много разыменований (звездочек). А любые попытки что-то упростить и срезать углы нарушат заявляемую стройность концепции (хотя я не уверен в стройности концепции изначально).
Вообще существуют два подхода: высокоуровневый и низкоуровневый. При высокоуровневом нам все равно как хранится объект - по значению или по ссылке, мы абстрагируемся от способа хранения и работаем просто с объектами. Так устроены Java и C#. Единый синтаксис доступа, никаких звездочек и стрелочек - только прямой доступ и доступ к полям через точку. Наверное, для специальных операций (таких как манипуляции с самими указателями, а не с объектами) можно придумать специальный синтаксис, или даже специальные встроенные в язык функции.
Второй подход - низкоуровневый, в нем в программе явно задается способ хранения объекта. Лучший представитель этого подхода - язык Си. Явные указатели, явное разыменование, явное взятие адреса, всё тоже просто и понятно, но явно. Иногда чуть больше звездочек, но это цена явности и прозрачности кода. В Rust тоже вроде бы все кодируется в явном виде. Где-то рядом Go, хотя там чуть срезали некоторые некритические углы.
А иногда делаются попытки совместить. Как в С++, где есть и явные указатели, и неявные ссылки. Иногда это удобно, иногда кажется избыточным. Посмотрите еще как забавно и в то же время мозгодробительно сделано в языке CForAll - они в дополнение к сишным указателям взяли концепцию ссылок из с++ и вывернули ее наизнанку, построив аналогию указателей на указатели.
ИМХО, пример того, когда сделали чисто для языковой симметрии в ущерб читаемости и практической применимости. Я считаю, что указатель и ссылка, при всей внутренней схожести, на уровне языкового дизайна все-же разные конструкции: указатель - мощный низкоуровневый инструмент для построения явных связей на уровне адресов; ссылка - высокоуровневая абстракция, предназначенная как раз для того чтобы уйти от адресов, явных размыменований и прочего.
Я про тетраэдр давно предлагал здесь на Хабре в комментариях к какой-то статье, мне ответили что так нельзя из-за особенностей орбиты. Хотя это первое что приходит в голову - начать с тетраэдра, и дальше наращивать такую трехмерную структуру в космосе, постепенно добавляя новые спутники.
То есть по сути это вывод типов. Но тип строится из того, что возвращает функция. И тип, как я понимаю, номинативный, а не структурный. Интересная фича.
Можно в функции вернуть структуру, как тип, и это станет новым типом. И за счёт этого механизма по сути и создаются новые типы. Невероятно мощная штука. Практически киллер-фитча.
Да, это очень интересный проект! Мне кажется что в гравитационном спектре скрывается немало тайн и загадок Вселенной:)
А возможно ли в перспективе создание "антенной решетки" из таких интерферометров, чтобы не просто регистрировать события, а именно видеть гравитацию, как матрица фотокамеры видит электомагнитное излучение?
чтобы при объединении в ячейки с одинаково заряженными чёрными дырами их электромагнитное отталкивание компенсировало гравитационное притяжение
Объясните мне, каким образом черные дыры могут электромагнитно отталкиваться, если они по определению не выпускают из себя никакие кванты электромагнитного излучения?
Приятный внешний вид, никогда не стареющая классика. Хотя то что на скриншоте вместо пиктограмм закрытия, минимизации и максимизации сделали какие-то однотипные цветные кружочки - не одобряю, но там же наверняка есть и другие темы оформления.
Жду когда же начнут создавать полноценные антенные решетки из гравитационных интерферометров, да это наверное дико дорого - сейчас в мире их вроде всего 5 штук, но зато какая шикарная возможность не просто запеленговать событие, а напрямую увидеть гравитацию Вселенной...
a = "Hello, World" // > Hello, World, ему все равно на такие манипуляции
Это еще что. Вот например, если в Python написать
variable = 42
а затем
varibale = "Hello world"
то язык тоже все проглотит, но переменная variable останется равной 42! Потому что во второй строчке опечатка:) В Go оператор := предназначен специально для объявления переменной (введения нового имени), и такой ситуации просто не может возникнуть. В Python, как ни странно, оператор := тоже ввели, но у него другая семантика, причем на мой взгляд совершенно невразумительная. В этом месте питонисты наверняка скажут - ну и что, каждый язык уникален, художники авторы языка так видят и т.п. Но я не соглашусь: все-же во всем должен быть смысл. В Python := используется для создания и изменения переменных внутри выражений. Т.е. с одной стороны хорошо - в некоторых случаях код становится компактнее, удается избежать дублирования вычислений, но с другой, а что мешает использовать := не внутри, а просто для создания переменной? Ведь очевидно что это просто частный случай. А нельзя! Точно так же нельзя использовать обычное присваивание внутри выражений - оно может быть только на "верхнем уровне".
Таким образом, я считаю что применение = и для объявления новых имен, и для присваивания - ошибка дизайна языка, но исправлять ее поздно в силу огромного количества написанного кода. И какой смысл в отличии контекста "внутри выражений" от контекста "верхнего уровня" тоже непонятно.
Не знал что DECT еще не ушел в прошлое... С другой стороны, если это более-менее распространенный стандарт, но почему модули DECT в смартфоны не ставят (по крайней мере массово)?
Все-же не раскрыта тема FAR vs TotalCommander. Я с уважением отношусь ко всем двухпанельным файловым менеждерам, но так сложилось что с Нортона перешал именно на Тотал (тогда еще Windows Commander) - наверное потому что он графический а не консольный. В графическом приложении чисто по ощущениям лучше интеграция с виндой - те же иконки, контекстное меню, перетаскивание, более плотная компоновка окна. Что касается плагинов, то они есть и для тотала, кроме того с некоторых пор пишу небольшие утилитки на Go и вешаю их на пользовательское меню.
Сама "консольность" это просто незаменимая фича если к системе есть удаленный доступ по ssh. Для линукса есть Midnight Commander, а вот для винды сама концепция такого доступа к сожалению не прижилась.
В классической дисциплине "алгоритмы и структуры данных" списки это все-же не массивы, под списками обычно понимаются двусвязные или односвязные списки, когда каждый элемент содержит указатели на предыдущий и/или следующий, а сами элементы располагаются не в непрерывной памяти, а в произвольном порядке.
Не, не ждем. Сижу пока на семерке, но если сильно припрет - следующей системой будет линукс с виндой в виртуалке без доступа к инету. Весь инет только на Линуксе (браузеры, мессенджеры, файлообмен и т.п.), а в винде только уникальный для винды софт (Visual Studio, Photoshop и т.п.). Для гостевой винды вроде даже есть бесшовная интеграция на уровне оконного менеджера. Пока только неясны некоторые вопросы с использованием NTFS дисков с данными для двух систем одновременно, очевидное - использовать "общие папки" и ntfs-3g, который вроде бы достаточно безопасен и ничего не ломает в файловой системе.
Нейролинковский чип торчит из головы, что существенно ограничивает владельца такого чипа в возможностях. То что предлагаю я - чип полностью внутри черепа, что исключает попадание инфекции в мозг. Кроме беспроводной связи - беспроводная передача энергии на чип внутри черепа, что требует близкого расположения второй части, т.е. нужен шлем.
Вытачивать шарики долго и сложно, можно упростить до цилиндров (т.е. просто напилить круглую палку [от швабры] на кусочки и приклеить к кубикам)
Вместо крестообразных слонов (для изготовления которых нужен станок) проще взять брусок треугольного сечения и также напилить. По смыслу будет то же - "что-то диагональное".
Не отличается: вот пример, обращение к локальной переменной (аргументу функции) и к полю соврешенно одинаковое (хотя мы знаем что на низком уровне в первом случае работа через указатель this, во втором - просто доступ к стеку). Чтобы отличить, нужно смотреть место объявления. А это может быть где-то далеко в коде (хорошо современные IDE выводят подсказки по наведению мыши на переменную).
Ну слияние, а что такого? Вот за счет гравитации две ЧД приблизились друг к другу вплотную, горизонты событий соприкоснулись и пересеклись. Чем не слияние? Это ничем не отличается от падения в ЧД любой материи.
Тут интересно другое. ЧД - это такой идеальный шарик. А при слиянии на очень короткий промежуток времени мы получаем "кривую" ЧД, не в форме шара. Можно даже пофантазировать о более сложных конфигурациях слияния, когда некая сверхцивилизация ради безумного эксперимента одномоментно сливает сотни и тысячи черных дыр, к примеру в форме сферы, образуя на короткое время некую область нормального пространства внутри сплошного кокона из черных дыр, Что будет с таким пространством?
Т.е. вы предлагаете все переменные (в том числе те которые "по значению") признать ссылками и использовать унифицированный синтаксис? Как уже заметили, в таком коде будет слишком много разыменований (звездочек). А любые попытки что-то упростить и срезать углы нарушат заявляемую стройность концепции (хотя я не уверен в стройности концепции изначально).
Вообще существуют два подхода: высокоуровневый и низкоуровневый. При высокоуровневом нам все равно как хранится объект - по значению или по ссылке, мы абстрагируемся от способа хранения и работаем просто с объектами. Так устроены Java и C#. Единый синтаксис доступа, никаких звездочек и стрелочек - только прямой доступ и доступ к полям через точку. Наверное, для специальных операций (таких как манипуляции с самими указателями, а не с объектами) можно придумать специальный синтаксис, или даже специальные встроенные в язык функции.
Второй подход - низкоуровневый, в нем в программе явно задается способ хранения объекта. Лучший представитель этого подхода - язык Си. Явные указатели, явное разыменование, явное взятие адреса, всё тоже просто и понятно, но явно. Иногда чуть больше звездочек, но это цена явности и прозрачности кода. В Rust тоже вроде бы все кодируется в явном виде. Где-то рядом Go, хотя там чуть срезали некоторые некритические углы.
А иногда делаются попытки совместить. Как в С++, где есть и явные указатели, и неявные ссылки. Иногда это удобно, иногда кажется избыточным. Посмотрите еще как забавно и в то же время мозгодробительно сделано в языке CForAll - они в дополнение к сишным указателям взяли концепцию ссылок из с++ и вывернули ее наизнанку, построив аналогию указателей на указатели.
ИМХО, пример того, когда сделали чисто для языковой симметрии в ущерб читаемости и практической применимости. Я считаю, что указатель и ссылка, при всей внутренней схожести, на уровне языкового дизайна все-же разные конструкции: указатель - мощный низкоуровневый инструмент для построения явных связей на уровне адресов; ссылка - высокоуровневая абстракция, предназначенная как раз для того чтобы уйти от адресов, явных размыменований и прочего.
Я про тетраэдр давно предлагал здесь на Хабре в комментариях к какой-то статье, мне ответили что так нельзя из-за особенностей орбиты. Хотя это первое что приходит в голову - начать с тетраэдра, и дальше наращивать такую трехмерную структуру в космосе, постепенно добавляя новые спутники.
То есть по сути это вывод типов. Но тип строится из того, что возвращает функция. И тип, как я понимаю, номинативный, а не структурный. Интересная фича.
А можно здесь поподробнее?
Да, это очень интересный проект! Мне кажется что в гравитационном спектре скрывается немало тайн и загадок Вселенной:)
А возможно ли в перспективе создание "антенной решетки" из таких интерферометров, чтобы не просто регистрировать события, а именно видеть гравитацию, как матрица фотокамеры видит электомагнитное излучение?
Объясните мне, каким образом черные дыры могут электромагнитно отталкиваться, если они по определению не выпускают из себя никакие кванты электромагнитного излучения?
Приятный внешний вид, никогда не стареющая классика. Хотя то что на скриншоте вместо пиктограмм закрытия, минимизации и максимизации сделали какие-то однотипные цветные кружочки - не одобряю, но там же наверняка есть и другие темы оформления.
Не знаю зачем это, уж лучше ReactOS.
Жду когда же начнут создавать полноценные антенные решетки из гравитационных интерферометров, да это наверное дико дорого - сейчас в мире их вроде всего 5 штук, но зато какая шикарная возможность не просто запеленговать событие, а напрямую увидеть гравитацию Вселенной...
Ну не знаю... судя по вики, место то еще.
Это еще что. Вот например, если в Python написать
а затем
то язык тоже все проглотит, но переменная variable останется равной 42! Потому что во второй строчке опечатка:) В Go оператор := предназначен специально для объявления переменной (введения нового имени), и такой ситуации просто не может возникнуть. В Python, как ни странно, оператор := тоже ввели, но у него другая семантика, причем на мой взгляд совершенно невразумительная. В этом месте питонисты наверняка скажут - ну и что, каждый язык уникален,
художникиавторы языка так видят и т.п. Но я не соглашусь: все-же во всем должен быть смысл. В Python := используется для создания и изменения переменных внутри выражений. Т.е. с одной стороны хорошо - в некоторых случаях код становится компактнее, удается избежать дублирования вычислений, но с другой, а что мешает использовать := не внутри, а просто для создания переменной? Ведь очевидно что это просто частный случай. А нельзя! Точно так же нельзя использовать обычное присваивание внутри выражений - оно может быть только на "верхнем уровне".Таким образом, я считаю что применение = и для объявления новых имен, и для присваивания - ошибка дизайна языка, но исправлять ее поздно в силу огромного количества написанного кода. И какой смысл в отличии контекста "внутри выражений" от контекста "верхнего уровня" тоже непонятно.
Не знал что DECT еще не ушел в прошлое... С другой стороны, если это более-менее распространенный стандарт, но почему модули DECT в смартфоны не ставят (по крайней мере массово)?
Все-же не раскрыта тема FAR vs TotalCommander. Я с уважением отношусь ко всем двухпанельным файловым менеждерам, но так сложилось что с Нортона перешал именно на Тотал (тогда еще Windows Commander) - наверное потому что он графический а не консольный. В графическом приложении чисто по ощущениям лучше интеграция с виндой - те же иконки, контекстное меню, перетаскивание, более плотная компоновка окна. Что касается плагинов, то они есть и для тотала, кроме того с некоторых пор пишу небольшие утилитки на Go и вешаю их на пользовательское меню.
Сама "консольность" это просто незаменимая фича если к системе есть удаленный доступ по ssh. Для линукса есть Midnight Commander, а вот для винды сама концепция такого доступа к сожалению не прижилась.
В классической дисциплине "алгоритмы и структуры данных" списки это все-же не массивы, под списками обычно понимаются двусвязные или односвязные списки, когда каждый элемент содержит указатели на предыдущий и/или следующий, а сами элементы располагаются не в непрерывной памяти, а в произвольном порядке.
Не, не ждем. Сижу пока на семерке, но если сильно припрет - следующей системой будет линукс с виндой в виртуалке без доступа к инету. Весь инет только на Линуксе (браузеры, мессенджеры, файлообмен и т.п.), а в винде только уникальный для винды софт (Visual Studio, Photoshop и т.п.). Для гостевой винды вроде даже есть бесшовная интеграция на уровне оконного менеджера. Пока только неясны некоторые вопросы с использованием NTFS дисков с данными для двух систем одновременно, очевидное - использовать "общие папки" и ntfs-3g, который вроде бы достаточно безопасен и ничего не ломает в файловой системе.
До этого еще далеко. Думаю, нужно на многие порядки(!) увеличивать число контактных площадок в таких чипах, чтобы добраться до такого уровня.
Нейролинковский чип торчит из головы, что существенно ограничивает владельца такого чипа в возможностях. То что предлагаю я - чип полностью внутри черепа, что исключает попадание инфекции в мозг. Кроме беспроводной связи - беспроводная передача энергии на чип внутри черепа, что требует близкого расположения второй части, т.е. нужен шлем.