Чего я никак не могу понять, это каким образом из вероятностного состояния кубитов в результате вычислений получается точный результат? Где про это можно прочитать?
Да, появляется много чего... Однако опыт как раз и нужен для того, чтобы сравнительно быстро понять, для чего эта штука придумана и стоит ли тратить время на её изучение? И вдруг выяснится, что в интересующей Вас области не так много и происходит...
Автор, уважаю! Программировал много на чем, и знаю, что такое абстрактные классы и преобразование Фурье, но тем не менее, считаю Вас программистом с бОльшей буквы "П", чем я сам. Именно программистом, а не кодировщиком.
Показательно, что автор много рассуждает о выборе и постижении инструментария, и крайне мало - о принципах построения программ. Это, на мой взгляд, и есть самая большая проблема современного изучения программирования. Базы данных без представления о реляционной алгебре. Веб-приложения без знаний 2х и 3х звенной архитектуры. Общий смысл: выучи язык, разберись с библиотеками поддержки, и ты - программист! Таки-нет. Ты в этом случае максимум кодировщик, да и то не всегда.
Не прекращайте стараний! Без опыта найти работу непросто, если только вы не гуями занимаетесь. Найдёте. И будьте морально готовы к тому, что вам никто ничего не должен - даже быть вежливым, увы, не обязан.
Спасибо за статью! Последний раз я слышал о доказательствах корректности алгоритма где-то в 1985м году. Тогда проблема считалась нерешаемой на практике...
Справедливости для надо сказать, что хорошие индийские программеры есть, и их немало. Ну и стоят они нормальных денег. Проблема в том, что минимальная цена за индуса очень низкая, и их по этому часто берут, не думая, что цена в данном случае полностью соответствует качеству.
К сожалению, это не так. Индусы встречаются на участке любой сложности, как только менеджмент решает поэкономить на разработке. Ну а квалифицированные программеры потом чистят, правят и переписывают. Плюс изнурительные code review.
Насколько возможно применение квантовых компьютеров для решения задач типа системы массового обслуживания? Т.е. насколько с их помощью можно будет решать стандартные задачи, например, реализации сервера? Или всё это - только для задач с вероятностными исходами?
Очень художественно и проникновенно! Вот только по моим понятиям тот, кто просто пишет код, это кодер. А программист умеет также кое-что ещё. А именно, декомпозировать задачу, встраивать новое, своё в легаси код, писать детальную постановку, ... И получается, что кодирование как таковое занимает не более 50% всего времени.
По поводу использования линейной алгебры о см. телрему Тихонова и многое другое из той же области. Вспомнился анекдот про прапора, у которого синус в военное время достигал 5ти :-)
Мне кажется, что глпвное, это не технология, которых за мою практику было много, и не ЯП, а правильное усторйство мозга. Если оно есть, то хорошие курсы помогут. Нсли нет, то требуется базовое образование для переустройства мозга нп нужный лад. Т.е. помимо риска нарваться на плохие курсы, у полного ноаичка есть риск, что мозги не так отформатированы. И это - более серьёзная проблема, как мне кажется.
Зная реализацию вектора в плюсаз, можно утверждать, что при чтении из вектора разными потоками гонки не будет. Но. В документации по С++ об этом не говорится. По этому формально воспринимая класс vector как чёрный ящик, читать разными тредами не защищаясь тоже нельзя.
Идея правильная, но с примерами - не очень здорово. Я собирал несколько групп разработки, и всегда главным вопросом было: "как ты это будешь решать"? В процессе такого общения можно очень быстро понять: кто перед тобой.
Чего я никак не могу понять, это каким образом из вероятностного состояния кубитов в результате вычислений получается точный результат? Где про это можно прочитать?
Мне показалось, что автор описывает ситуацию распила монолитной системы... Ну, грубо говоря, Ансамбль на ходу переделывается в Энейблер ;-)
Да, появляется много чего... Однако опыт как раз и нужен для того, чтобы сравнительно быстро понять, для чего эта штука придумана и стоит ли тратить время на её изучение? И вдруг выяснится, что в интересующей Вас области не так много и происходит...
Автор, уважаю! Программировал много на чем, и знаю, что такое абстрактные классы и преобразование Фурье, но тем не менее, считаю Вас программистом с бОльшей буквы "П", чем я сам. Именно программистом, а не кодировщиком.
Показательно, что автор много рассуждает о выборе и постижении инструментария, и крайне мало - о принципах построения программ. Это, на мой взгляд, и есть самая большая проблема современного изучения программирования. Базы данных без представления о реляционной алгебре. Веб-приложения без знаний 2х и 3х звенной архитектуры. Общий смысл: выучи язык, разберись с библиотеками поддержки, и ты - программист! Таки-нет. Ты в этом случае максимум кодировщик, да и то не всегда.
Сравнивать карьерный самосвал, УАЗ и Феррари - это сильный ход!
Не прекращайте стараний! Без опыта найти работу непросто, если только вы не гуями занимаетесь. Найдёте. И будьте морально готовы к тому, что вам никто ничего не должен - даже быть вежливым, увы, не обязан.
Спасибо за статью! Последний раз я слышал о доказательствах корректности алгоритма где-то в 1985м году. Тогда проблема считалась нерешаемой на практике...
Анти в современном итальянским имеет смысл "перед". Т.е. антипаста - это закуска перед основным блюдом, т.е. пастой.
Справедливости для надо сказать, что хорошие индийские программеры есть, и их немало. Ну и стоят они нормальных денег. Проблема в том, что минимальная цена за индуса очень низкая, и их по этому часто берут, не думая, что цена в данном случае полностью соответствует качеству.
К сожалению, это не так. Индусы встречаются на участке любой сложности, как только менеджмент решает поэкономить на разработке. Ну а квалифицированные программеры потом чистят, правят и переписывают. Плюс изнурительные code review.
Насколько возможно применение квантовых компьютеров для решения задач типа системы массового обслуживания? Т.е. насколько с их помощью можно будет решать стандартные задачи, например, реализации сервера? Или всё это - только для задач с вероятностными исходами?
Была беда с индусами. Похоже, их теперь импортозамещают на отечественных недотык :-(
Очень художественно и проникновенно! Вот только по моим понятиям тот, кто просто пишет код, это кодер. А программист умеет также кое-что ещё. А именно, декомпозировать задачу, встраивать новое, своё в легаси код, писать детальную постановку, ... И получается, что кодирование как таковое занимает не более 50% всего времени.
Написано доходчиво, ну и немного оскорбительно для местной публики. Т.е. статья хорошая, но не там опубликована :-)
Самое интересное, ИМХО, обеспечение hot swap и распределённых транзакций, осталось за бортом.
По поводу использования линейной алгебры о см. телрему Тихонова и многое другое из той же области. Вспомнился анекдот про прапора, у которого синус в военное время достигал 5ти :-)
Мне кажется, что глпвное, это не технология, которых за мою практику было много, и не ЯП, а правильное усторйство мозга. Если оно есть, то хорошие курсы помогут. Нсли нет, то требуется базовое образование для переустройства мозга нп нужный лад. Т.е. помимо риска нарваться на плохие курсы, у полного ноаичка есть риск, что мозги не так отформатированы. И это - более серьёзная проблема, как мне кажется.
Я много собеседовал джунов и подход был совсем другим.
Попросить описать "так, чтобы дурак понял" наиболее интересную задачу из тех, что он решал
Ковырнуть поглубже именно в той области, где он считает себя спецом.
Всегда исходил из того, что джун должен быть умным и готовым учиться. А знаний, нужных мне, у него априори нет.
Зная реализацию вектора в плюсаз, можно утверждать, что при чтении из вектора разными потоками гонки не будет. Но. В документации по С++ об этом не говорится. По этому формально воспринимая класс vector как чёрный ящик, читать разными тредами не защищаясь тоже нельзя.
Идея правильная, но с примерами - не очень здорово. Я собирал несколько групп разработки, и всегда главным вопросом было: "как ты это будешь решать"? В процессе такого общения можно очень быстро понять: кто перед тобой.