Странная логика. Ведётся обсуждение, что имя метода надо называть make_coffee, а не coffee_machine. И не объясняется, почему. Просто потому что "так принято".
Тем временем, пайтон - вполне себе объектно-ориентированный язык.
Вот смотрите: моя кофемашина не требует подачи электричества, воды и кофе на каждый вызов "делайкофе". Я один раз включаю в розетку, один раз с утра заливаю воду, один раз засыпаю кофе. Потом хожу, нажимаю кнопку - только успевай чашку подставлять.
Можно же было сделать класс coffee_machine, передать ему кофе и воду и воткнуть в розетку? А make_coffee будет уже без аргуменов. Тогда почему наименование класса - это существительное, а имя метода - глагол становится понятнее, правда?
Ещё можно кидаться эксепшенами, если запас кофе или воды в машинке закончился, но это уже другая история.
p.s. sparkling water - это газированная вода, а не проточная.
А как тогда работает эффект потери энергии при попадании в гравитационную яму?
Никак. Фотон не теряет энергию. Его энергия - константа, зависит только от длины волны. Он вообще не может меняться, т.к. у него нет времени на это. Фотон испускается и поглощается в одно и то же время и просто не успевает существовать.
Красное смещение относится к испускаемым фотонам вблизи массивных объектов и является следствием замедления времени гравитацией.
удаление дальних галактик от нас.
Это расширение ткани самого пространства. Не считается.
Можно, я думаю над этим. Пока в приоритете постгрес, но когда его осилю, с остальными будет проще. Уже будет запилена возможность работы с несколькими базами данных
А вот так. Искажение пространства. Фотон не умеет реагировать на гравитацию, он тупо летит прямо, куда и летел. По искажённому пространству. Он ни на что не реагирует, он фотон, он без массы.
Я же не про корабль, а про сам принцип. Откуда нам знать что нет частиц, которые могут летать так используя этот принцип?
Откуда нам знать, что бога нет? Что за вопросы такие?
Пока что известные механизмы прямо запрещают распространение чего-либо быстрее скорости света. Сам принцип пространства-времени подразумевает, что 4 световых года - это 4 года минимум. И за 4 года можно пролететь только 4 световых года. Расстояние пространства приравнивается ко времени, понятие "одновременно" на удалённых точках теряет смысл.
С точки зрения фотона ему вообще не надо быть в варпе. В его системе координат он слетает до альфа центавры и обратно за ноль минут и ноль секунд. Это не считается.
Искривление пространства не отменяет фундаментальных ограничений. Мы знаем, что фотон летит только прямо, а то, что мы видим гравитационное линзирование - это нам кажется, что фотон огибает чёрную дыру. На самом деле он летит прямо.
К самому варпу у меня куча вопросов. Да, теоретически он возможен. Правда осталось всего ничего - найти отрицательную массу. А вот тут уже проблемки. Отрицательная масса не может летать со скоростью, ниже скорости света.
И как вообще этот бутерброд собирать? Как с этим лететь? Вот впереди обычная сверхмасса, сзади отрицательная, посередине корабль. Как это всё заставить вместе лететь?
На мой дилетантский взгляд, при измерении спина частицы детектор входит в запутанность частиц а-б. Не просто входит, а входит в запутанность с одним лишь только вариантом. Если спины были у а +-, у б -+ (взаимно полярные), то запутанность детектора с а+ позволит ему видеть только б- и наоборот. Далее запутанность от детектора распространяется по цепочке до наблюдателя. С частицей ничего не происходит. Она не умеет думать, она не умеет видеть измерения, она ничего не передаёт.
Мы просто перестаём видеть ту часть вселенной, где у а был минус, а у б плюс. Просто потому что вошли в запутанность с а+.
Да, это означает бесконечное количество бесконечных вселенных, но в это мне гораздо легче поверить, чем в разумность частиц.
Другой вопрос, что такое запутанность. Я на него ответить не могу. Да и не должен. Есть утверждение от автора, что частицы обмениваются информацией, хотя нет никаких доказательств этому, а в научной среде, простите, бремя доказательства лежит на утверждающем. Я могу просто сказать "нет" и это будет научно просто потому что нет доказательств.
приложения на WPF такие же тормозные, как на электроне
Да кто же виноват в вашей выборке? ) Посмотрите вот на моё поделие, там правда не впф, а авалония. Но всё равно замл. Работает с такими объёмами данных и с такой скоростью, какие просто невозможны на электроне.
Странные выводы. Вся ветка про то, что надо делать нативные приложения вместо кучи обёрток в виде электрона и интерпретируемого HTML (тоже подвид XML). Я вот и напомнил про компилируемый язык. А вы предлагаете пойти по пути электрона - опять использовать интерпретацию.
Хранить разметку в виде кода, и декомпилировать перед каждым редактированием - странная идея.
Во-первых это работает. Во вторых не обязательно в винформс упираться. Есть axaml, например, на который я очень толсто намекаю. Там хранится модель разметки, а при компиляции приложения из модели генерируется код.
Не находите, что где-то здесь находится корреляция? Тормозить оно может, тормозить может что угодно вообще. Зависит от того, как это использовать. Возвращаясь к теме нативности, замл намного ближе к железу, чем HTML. И работает быстрее на тех же задачах. Хотя бы в силу компилированности в рантайме и прямой связке с языком. Впрочем, я не хотел бы, чтобы спор упирался в замл. У того же дотнета есть и веб-решения. Классический разор и фактически стриминговый блазор.
Я говорил про C#. На нём можно писать близко к железу, причём с небывалым удобством. Change my mind.
Нет wysiwyg-дизайнера в Visual Studio
Скрытый текст
Разработчики WinForms не код пишут, а контролы перетаскивают мышкой с тулбаров и меняют им свойства в редактилках
Я забыл предупредить, я с винформс уже как 15 лет работаю ) Там да, есть привычка в визуальном редакторе редактировать. Но это не имеет никакого отношения к декларативности.
При сохранении это уже сериализуется в императивный код, при загрузке снова парсится - кринж.
Никуда оно не парсится при загрузке. Оно один раз компилируется в исполняемый код и всё. Дальше выполняется. И не ясно, что для вас кринж. Что wysiwyg в конечном итоге превращается в набор команд? А как иначе может быть?
Честно говоря никогда не пробовал. У меня не было задачи сделать шарп быстрее, он и так достаточно хорош. Но я знаю, что AvaloniaUI поддерживает Native AOT.
XAML это не HTML. Он выглядит, как HTML, но это компилируемый язык со всеми вытекающими. Вообще странно их сравнивать. XAML это не только разметка, но и биндинги.
Для создания UI нужна специальная подсистема (WinForms или WPF)
UWP, MAUI. Есть кроссплатформенная AvaloniaUI, которая, кстати, умеет в AOT. Авалония НЕ работает с нативным API, а рисует сама. Есть экзотика вроде Qt/.NET или ImGui.NET.
Есть Unity и Godot для игр. Есть OpenTK для работы с OpenGL/CL.
декларативное описание UI сериализуется в императивный код
Не понял пассажа. Когда у винформс было декларативное описание?
У вас в самом вопросе указана марка ракет. Это предвзятость. Если расширить вопрос до "люди, накидывающие ракетами по застройке с гражданским населением", то предвзятость исчезнет. Но суть вопроса останется.
Тепмература ОЖ ДВС - около 90 градусов. То, что радиатор кондея поднимет температуру воздуха на десяток градусов погоды не сделает. Тут ключевой момент - включенный обдув вентилятором. Сброс тепла намного быстрее происходит.
А ещё помню, у меня клинил термостат, и ОЖ гонялась по внутреннему кругу. Движку было горячевато. Чтобы до сервиса доехать, врубил кондей на полную и печку. Печка сбрасывала тепло в воздуховоды, кондей отводил на радиатор под капотом. Так и доехал)
У меня когда-то был профи с аж целым мегабайтом на борту. И для меня осталось без ответа два вопроса к экрану:
Зачем такую сложную адресацию сделали? Это же реально неудобно. Для рисования графики сделали систему адресации спектрума ещё сложнее, ещё неудобнее, а с другой стороны, поломали удобство рисования символов 8х8. Зачем?
Сделали аттрибут для линии 8х1 вместо 8х8. С одной стороны увеличили объём аттрибутов в восемь раз, сравняв с bitfield, а с другой так и не сделали индивидуальные цвета в пикселях. Ну почему? Всего вдвое увеличить объём видеопамяти и были бы полноценные картинки. Уж профик 512 (тем более мегабайт) мог бы себе позволить.
В итоге экран профика оказался такой "ни рыба ни мясо". Для демомейкинга слишком толстый и неповоротливый, для работы с текстом впрочем тоже. Для графики слишком сложный и геморройный из-за неоправданных цветовых аттрибутов. Три цвета в линии 8х1 не нарисуешь.
Странная логика. Ведётся обсуждение, что имя метода надо называть make_coffee, а не coffee_machine. И не объясняется, почему. Просто потому что "так принято".
Тем временем, пайтон - вполне себе объектно-ориентированный язык.
Вот смотрите: моя кофемашина не требует подачи электричества, воды и кофе на каждый вызов "делайкофе". Я один раз включаю в розетку, один раз с утра заливаю воду, один раз засыпаю кофе. Потом хожу, нажимаю кнопку - только успевай чашку подставлять.
Можно же было сделать класс coffee_machine, передать ему кофе и воду и воткнуть в розетку? А make_coffee будет уже без аргуменов. Тогда почему наименование класса - это существительное, а имя метода - глагол становится понятнее, правда?
Ещё можно кидаться эксепшенами, если запас кофе или воды в машинке закончился, но это уже другая история.
p.s. sparkling water - это газированная вода, а не проточная.
Никак. Фотон не теряет энергию. Его энергия - константа, зависит только от длины волны. Он вообще не может меняться, т.к. у него нет времени на это. Фотон испускается и поглощается в одно и то же время и просто не успевает существовать.
Красное смещение относится к испускаемым фотонам вблизи массивных объектов и является следствием замедления времени гравитацией.
Это расширение ткани самого пространства. Не считается.
Можно, я думаю над этим. Пока в приоритете постгрес, но когда его осилю, с остальными будет проще. Уже будет запилена возможность работы с несколькими базами данных
А вот так. Искажение пространства. Фотон не умеет реагировать на гравитацию, он тупо летит прямо, куда и летел. По искажённому пространству. Он ни на что не реагирует, он фотон, он без массы.
Откуда нам знать, что бога нет? Что за вопросы такие?
Пока что известные механизмы прямо запрещают распространение чего-либо быстрее скорости света. Сам принцип пространства-времени подразумевает, что 4 световых года - это 4 года минимум. И за 4 года можно пролететь только 4 световых года. Расстояние пространства приравнивается ко времени, понятие "одновременно" на удалённых точках теряет смысл.
С точки зрения фотона ему вообще не надо быть в варпе. В его системе координат он слетает до альфа центавры и обратно за ноль минут и ноль секунд. Это не считается.
Искривление пространства не отменяет фундаментальных ограничений. Мы знаем, что фотон летит только прямо, а то, что мы видим гравитационное линзирование - это нам кажется, что фотон огибает чёрную дыру. На самом деле он летит прямо.
К самому варпу у меня куча вопросов. Да, теоретически он возможен. Правда осталось всего ничего - найти отрицательную массу. А вот тут уже проблемки. Отрицательная масса не может летать со скоростью, ниже скорости света.
И как вообще этот бутерброд собирать? Как с этим лететь? Вот впереди обычная сверхмасса, сзади отрицательная, посередине корабль. Как это всё заставить вместе лететь?
Не важно, сторонник какой я интерпретации. Ни одна интерпретация не позволяет передачу информации быстрее скорости света.
На мой дилетантский взгляд, при измерении спина частицы детектор входит в запутанность частиц а-б. Не просто входит, а входит в запутанность с одним лишь только вариантом. Если спины были у а +-, у б -+ (взаимно полярные), то запутанность детектора с а+ позволит ему видеть только б- и наоборот. Далее запутанность от детектора распространяется по цепочке до наблюдателя. С частицей ничего не происходит. Она не умеет думать, она не умеет видеть измерения, она ничего не передаёт.
Мы просто перестаём видеть ту часть вселенной, где у а был минус, а у б плюс. Просто потому что вошли в запутанность с а+.
Да, это означает бесконечное количество бесконечных вселенных, но в это мне гораздо легче поверить, чем в разумность частиц.
Другой вопрос, что такое запутанность. Я на него ответить не могу. Да и не должен. Есть утверждение от автора, что частицы обмениваются информацией, хотя нет никаких доказательств этому, а в научной среде, простите, бремя доказательства лежит на утверждающем. Я могу просто сказать "нет" и это будет научно просто потому что нет доказательств.
Нет
Нет
Да кто же виноват в вашей выборке? ) Посмотрите вот на моё поделие, там правда не впф, а авалония. Но всё равно замл. Работает с такими объёмами данных и с такой скоростью, какие просто невозможны на электроне.
Странные выводы. Вся ветка про то, что надо делать нативные приложения вместо кучи обёрток в виде электрона и интерпретируемого HTML (тоже подвид XML). Я вот и напомнил про компилируемый язык. А вы предлагаете пойти по пути электрона - опять использовать интерпретацию.
Во-первых это работает. Во вторых не обязательно в винформс упираться. Есть axaml, например, на который я очень толсто намекаю. Там хранится модель разметки, а при компиляции приложения из модели генерируется код.
XAML - это подвид XML. Дальше что процессору делать с этим XML?
Мне понятно. Даже понятно, переживёт или нет. Во всех *.designer.cs большими буквами написано "ничего не пхать сюдой - перезапишется"
Не находите, что где-то здесь находится корреляция? Тормозить оно может, тормозить может что угодно вообще. Зависит от того, как это использовать. Возвращаясь к теме нативности, замл намного ближе к железу, чем HTML. И работает быстрее на тех же задачах. Хотя бы в силу компилированности в рантайме и прямой связке с языком. Впрочем, я не хотел бы, чтобы спор упирался в замл. У того же дотнета есть и веб-решения. Классический разор и фактически стриминговый блазор.
Я говорил про C#. На нём можно писать близко к железу, причём с небывалым удобством. Change my mind.
Скрытый текст
Я забыл предупредить, я с винформс уже как 15 лет работаю ) Там да, есть привычка в визуальном редакторе редактировать. Но это не имеет никакого отношения к декларативности.
Никуда оно не парсится при загрузке. Оно один раз компилируется в исполняемый код и всё. Дальше выполняется. И не ясно, что для вас кринж. Что wysiwyg в конечном итоге превращается в набор команд? А как иначе может быть?
Честно говоря никогда не пробовал. У меня не было задачи сделать шарп быстрее, он и так достаточно хорош. Но я знаю, что AvaloniaUI поддерживает Native AOT.
XAML это не HTML. Он выглядит, как HTML, но это компилируемый язык со всеми вытекающими. Вообще странно их сравнивать. XAML это не только разметка, но и биндинги.
UWP, MAUI. Есть кроссплатформенная AvaloniaUI, которая, кстати, умеет в AOT. Авалония НЕ работает с нативным API, а рисует сама. Есть экзотика вроде Qt/.NET или ImGui.NET.
Есть Unity и Godot для игр. Есть OpenTK для работы с OpenGL/CL.
Не понял пассажа. Когда у винформс было декларативное описание?
Ещё какое! Если взять C#, то у него очень развитые инструменты, очень большое коммьюнити, гигантское количество библиотек.
Если считаете, что IL - это недостаточно нативно, то существует Native AOT.
У вас в самом вопросе указана марка ракет. Это предвзятость. Если расширить вопрос до "люди, накидывающие ракетами по застройке с гражданским населением", то предвзятость исчезнет. Но суть вопроса останется.
И при этом вопрос заиграет новыми красками.
Тепмература ОЖ ДВС - около 90 градусов. То, что радиатор кондея поднимет температуру воздуха на десяток градусов погоды не сделает. Тут ключевой момент - включенный обдув вентилятором. Сброс тепла намного быстрее происходит.
А ещё помню, у меня клинил термостат, и ОЖ гонялась по внутреннему кругу. Движку было горячевато. Чтобы до сервиса доехать, врубил кондей на полную и печку. Печка сбрасывала тепло в воздуховоды, кондей отводил на радиатор под капотом. Так и доехал)
Тут самый главный вопрос: на какие форс-мажоры и сколько.
Так удобнее )
Скрин IDE в 4К
У меня когда-то был профи с аж целым мегабайтом на борту. И для меня осталось без ответа два вопроса к экрану:
Зачем такую сложную адресацию сделали? Это же реально неудобно. Для рисования графики сделали систему адресации спектрума ещё сложнее, ещё неудобнее, а с другой стороны, поломали удобство рисования символов 8х8. Зачем?
Сделали аттрибут для линии 8х1 вместо 8х8. С одной стороны увеличили объём аттрибутов в восемь раз, сравняв с bitfield, а с другой так и не сделали индивидуальные цвета в пикселях. Ну почему? Всего вдвое увеличить объём видеопамяти и были бы полноценные картинки. Уж профик 512 (тем более мегабайт) мог бы себе позволить.
В итоге экран профика оказался такой "ни рыба ни мясо". Для демомейкинга слишком толстый и неповоротливый, для работы с текстом впрочем тоже. Для графики слишком сложный и геморройный из-за неоправданных цветовых аттрибутов. Три цвета в линии 8х1 не нарисуешь.