Теперь всё стало понятно, спасибо!)
Эх, получается, передавать информацию быстрее скорости света и вправду нельзя (по крайней мере, используя эффект запутанности), а так хотелось…
А, тогда, кажется, всё становится понятно, спасибо что тратите время на тупые вопросы) Получается, раз поляризацию задать не получится, то и информацию передавать быстрее скорости света таким способом тоже невозможно.
Но про квантовые компьютеры тогда остаётся вопрос: как я понял, надо изначально установить кубиты в детерминированное состояние, например |00000000> (при этом сохранив запутанность), а потом уже, используя преобразования Адамара и всякие CNOT привести к нужному состоянию. Если не задать начальное состояние, то на выходе после преобразований получится состояние, которое при измерении может дать неопределённый ответ. Так я понял)
Но получается, создатели квантовых компьютеров как-то умудряются инициализировать кубиты в нужное состояние, не потеряв запутанность? Что мешает (кроме технических ограничений, связанных с нестабильностью запутывания) взять эти кубиты и разнести на миллиард световых лет и потом проделать действия над кубитами на стороне А так, чтобы при измерении на стороне Б получилась информация, которую закодировали на стороне А?
А как работают квантовые компьютеры? На сколько я понимаю, там внутри набор из нескольких запутанных частиц-кубитов в изначально недетерминированном состоянии, и квантовые гейты применяются в определённой последовательности к некоторым из кубитов, что в итоге даёт состояние, которое при измерении с вероятностью близкой или равной единице даст ответ на поставленную задачу.
Мне правда интересно, как можно поменять у кубита состояние, не нарушив запутанности. Я думал, что пропускание фотона через поляризатор не приводит к схлопыванию волновой функции.
Не совсем понял.
На сколько я знаю, при аннигиляции электрон-позитронной пары рождённые фотоны всегда изначально запутанны. Или не обязательно?
Если да, то меняя квантовое состояние одного фотона на строго определённое (например, придавая ему вертикальную поляризацию), при условии, что фотоны всё ещё запутанны, измерение второго фотона даст горизонтальную поляризацию.
Или меняя поляризацию мы ломаем запутанность?
А правильно ли я понимаю, что если создать два запутанных фотона (например, аннигиляцией электрона и позитрона), разнести их на большое расстояние и затем один фотон пропустить через поляризатор, то и другой фотон станет поляризован?
Согласен, это единственное, что пришло на ум. Но если такого требования нет, то Remote SSH гораздо проще в настройке и поддерживается самими разработчиками VS Code.
Но главный минус, который я вижу — невозможность проброса портов. Для простых веб-сайтов некритично, но если используются фичи, которые не работают без ssh, придётся попрыгать с бубном (или работать с невалидным сертификатом)
У тебя, видимо, юношеский максимализм в попе. Или ты не понимаешь, что времена изменились, и теперь не принято обсирать родину, как это было в 90-е. Если хочешь высказать свою точку зрения так, чтобы тебя не заминусили, надо это делать аккуратно. А может, ты всё понимаешь и хочешь хайпа, но тогда это не для Хабра. Ты тут правда не нужен, уйди, пожалуйста.
Ничего не мешало сделать так без LSP. Почему не делали — другой вопрос.
Планшетные компьютеры тоже появились задолго до выхода iPad, но реальную популярность не завоевали. Думаю, тут вопрос своевременности подачи технологии, и LSP выстрелил в нужное время.
Я упоминал Rider — IDE для C#. На сколько я знаю, там используется свой протокол взаимодействия между IDE, основанной на IntelliJ IDEA и написанной на Java, и анализатором Resharper, написанном на C#. Идея была красивая, но это нестандартизированный протокол, поэтому его ждёт печальная участь.
Так что ничего не ново под Луной, многие удобные вещи существовали и раньше, и для работы им не нужен был «электрон».
Да множество вещей можно сделать по-разному. Электрон — это просто удобное средство отображения информации на экране. На данный момент ни один UI-фреймворк на любом языке программирования (WPF, GTK+, etc.) не сравнится по функционалу и удобству использования с веб-браузером. А учитывая стремление бизнеса к унификации веб- и десктоп-версий приложений, это чуть ли не единственный вариант разработки на данный момент.
Что он дает кроме долгожданного полного взаимосогласия редактора кода и компилятора? Я не подкалываю, действительно интересно.
Во-первых, отзывчивость IDE. Не скажу за всех, но большинство существующих IDE, с которыми я работал, написаны на языках со сборкой мусора (типа C# и Java), а поскольку языковые анализаторы очень любят генерировать много мусорных объектов на каждое нажатие клавиши, GC происходят почти постоянно, и они при этом замораживают весь UI. В случае LSP весь анализ кода происходит в другом процессе. Конечно, там тоже может быть GC, но при этом IDE не замораживается, а просто показывает спиннер или что-то подобное.
Во-вторых, LSP — это открытый протокол. Стандартизация — наше всё. Любой может написать свой LSP для какого-то очень специфичного языка, и его можно будет использовать в любой современной IDE. Это как LLVM, который в своё время стал революцией в области создания компиляторов. Если раньше нужно было писать компилятор под каждый язык под каждую платформу (M*N), то теперь достаточно написать компилятор, который преобразует исходный код в некий intermediate language, который уже может быть скомпилирован под любую платформу.
Не хочу начинать спор про IDE, поскольку пост не об этом, но на мой взгляд, за последнее время VS Code выбился в лидеры как IDE для разработки на JS/TS, а это самые востребованные языки сейчас. Но благодаря поддержке Language Server Protocol (а VS Code стала в этом пионером), задача полноценной поддержки других языков становится только вопросом времени, причём, что важно, это не влияет на производительность IDE в целом, т.к. все задачи по анализу кода выполняются в другом процессе. Справедливости ради, JetBrains тоже идут по этому пути, например, в Rider-е, который мне нравится больше всех IDE для C#. Но, поскольку речь изначально зашла про тормознутость electron-приложений, я здесь выступаю адвокатом Electron-а: он может работать очень шустро. А дурная слава за ним закрепилась скорее из-за прожорливости по памяти (что неудивительно, ведь каждое приложение несет в себе Chromium и Node.js), ну и из-за криворукости программистов, конечно же.
Да всё проще: мода на округлый дизайн раз в несколько лет сменяется на моду на прямоугольный дизайн. Так же, как flat и объёмный дизайн. Считается, что люди устают от однообразного вида элементов, поэтому иногда его надо менять, преподнося это как инновацию. Айфоны, например, недавно начали вторую итерацию в дизайне острых/скруглённых краёв. Следующий этап — возврат к скевоморфизму.
Ну, VS Code написан на электроне, и, на мой взгляд, работает гораздо быстрее других топовых IDE. А для поддержки светлой/тёмной темы в браузерах есть CSS медиа-функция prefers-color-scheme. Так что, в приложениях на электроне достаточно будет поправить CSS (впрочем, учитывая, что на маках это уже поддерживается, скорее всего, все приложения и так уже адаптированы под темы).
С моей колокольни выглядит так, будто можно ускорить процесс в тысячи раз, не изменяя методологию.
Зачем делать такие тонкие срезы — 40 нм? Можно ведь делать слои по несколько микрометров, и они будут прозрачны для оптических микроскопов (размер нейрона — 5-150 мкм, поэтому «мёртвых зон» не будет). Можно было бы автоматически строить карту такого слоя с помощью алгоритма построения 3d-модели на основе стереоскопической пары изображений (для увеличения точности можно сканировать слой под разными углами, так что, не только стерео-, но и «мультископической»).
Эх, получается, передавать информацию быстрее скорости света и вправду нельзя (по крайней мере, используя эффект запутанности), а так хотелось…
Но про квантовые компьютеры тогда остаётся вопрос: как я понял, надо изначально установить кубиты в детерминированное состояние, например |00000000> (при этом сохранив запутанность), а потом уже, используя преобразования Адамара и всякие CNOT привести к нужному состоянию. Если не задать начальное состояние, то на выходе после преобразований получится состояние, которое при измерении может дать неопределённый ответ. Так я понял)
Но получается, создатели квантовых компьютеров как-то умудряются инициализировать кубиты в нужное состояние, не потеряв запутанность? Что мешает (кроме технических ограничений, связанных с нестабильностью запутывания) взять эти кубиты и разнести на миллиард световых лет и потом проделать действия над кубитами на стороне А так, чтобы при измерении на стороне Б получилась информация, которую закодировали на стороне А?
Мне правда интересно, как можно поменять у кубита состояние, не нарушив запутанности. Я думал, что пропускание фотона через поляризатор не приводит к схлопыванию волновой функции.
На сколько я знаю, при аннигиляции электрон-позитронной пары рождённые фотоны всегда изначально запутанны. Или не обязательно?
Если да, то меняя квантовое состояние одного фотона на строго определённое (например, придавая ему вертикальную поляризацию), при условии, что фотоны всё ещё запутанны, измерение второго фотона даст горизонтальную поляризацию.
Или меняя поляризацию мы ломаем запутанность?
А правильно ли я понимаю, что если создать два запутанных фотона (например, аннигиляцией электрона и позитрона), разнести их на большое расстояние и затем один фотон пропустить через поляризатор, то и другой фотон станет поляризован?
Может быть, наведёт на какие-то мысли.
В сгенерированном коде очень много длинных строковых констант типа “unable to decode...”
Это сильно утяжеляет скомпилированные бинарники.
Согласен, это единственное, что пришло на ум. Но если такого требования нет, то Remote SSH гораздо проще в настройке и поддерживается самими разработчиками VS Code.
Но главный минус, который я вижу — невозможность проброса портов. Для простых веб-сайтов некритично, но если используются фичи, которые не работают без ssh, придётся попрыгать с бубном (или работать с невалидным сертификатом)
А какие преимущества у такого подхода по сравнению с https://code.visualstudio.com/docs/remote/ssh?
Планшетные компьютеры тоже появились задолго до выхода iPad, но реальную популярность не завоевали. Думаю, тут вопрос своевременности подачи технологии, и LSP выстрелил в нужное время.
Я упоминал Rider — IDE для C#. На сколько я знаю, там используется свой протокол взаимодействия между IDE, основанной на IntelliJ IDEA и написанной на Java, и анализатором Resharper, написанном на C#. Идея была красивая, но это нестандартизированный протокол, поэтому его ждёт печальная участь.
Да множество вещей можно сделать по-разному. Электрон — это просто удобное средство отображения информации на экране. На данный момент ни один UI-фреймворк на любом языке программирования (WPF, GTK+, etc.) не сравнится по функционалу и удобству использования с веб-браузером. А учитывая стремление бизнеса к унификации веб- и десктоп-версий приложений, это чуть ли не единственный вариант разработки на данный момент.
Во-первых, отзывчивость IDE. Не скажу за всех, но большинство существующих IDE, с которыми я работал, написаны на языках со сборкой мусора (типа C# и Java), а поскольку языковые анализаторы очень любят генерировать много мусорных объектов на каждое нажатие клавиши, GC происходят почти постоянно, и они при этом замораживают весь UI. В случае LSP весь анализ кода происходит в другом процессе. Конечно, там тоже может быть GC, но при этом IDE не замораживается, а просто показывает спиннер или что-то подобное.
Во-вторых, LSP — это открытый протокол. Стандартизация — наше всё. Любой может написать свой LSP для какого-то очень специфичного языка, и его можно будет использовать в любой современной IDE. Это как LLVM, который в своё время стал революцией в области создания компиляторов. Если раньше нужно было писать компилятор под каждый язык под каждую платформу (M*N), то теперь достаточно написать компилятор, который преобразует исходный код в некий intermediate language, который уже может быть скомпилирован под любую платформу.
Да уж, тогда понятно, спасибо.
Зачем делать такие тонкие срезы — 40 нм? Можно ведь делать слои по несколько микрометров, и они будут прозрачны для оптических микроскопов (размер нейрона — 5-150 мкм, поэтому «мёртвых зон» не будет). Можно было бы автоматически строить карту такого слоя с помощью алгоритма построения 3d-модели на основе стереоскопической пары изображений (для увеличения точности можно сканировать слой под разными углами, так что, не только стерео-, но и «мультископической»).