Интересно, но я бы не назвал данный материал «введением в способы конверсии классических алгоритмов для их выполнения на квантовых вычислителях». Именно способ конверсии делает абсолютно недоступным подавляющему большинству использование квантовых компьютеров.
Частный случай компонентов — классы. Но в более общем (и часто используемом) виде это набор классов, слабо связанных с другими наборами. Слабость связи обычно реализуется на интерфейсах (чего нет в JS), а за интерфейсом может стоять тот самый набор классов, ничего не знающий о других наборах, то есть явно выделенный компонент, хоть и разбитый на несколько классов.
>> Она не подразумевает хранение значений, а свойство — подразумевает
Функция, возвращающая всегда одно и то же значение, как раз выполняет то, что вы считаете невыполнимым. Это по сути константа, но для чистоты функционального подхода все константы определены именно в виде функций, возвращающих одно и то же значение.
>> вы до сайта не добрались
Да, не посмотрел сразу. Но исправился :) Там в части «Разрабатывайте просто» такой аргумент «против всех»:
>> Одна парадигма. Один язык
Или вот такое (в «Разрабатывайте быстро»):
>> Завершенная ERP-система среднего уровня сложности всего в 25K строках кода
Здесь на самом деле «всё не так просто (с)». Один язык и одна парадигма появились начиная с машинных кодов. Да, машинные коды позволяют написать и OLTP и OLAP, но вы же понимаете, что реальность внесёт здесь некоторые коррективы.
Ну а размер «средней ERP» — это вообще нечто абсолютно произвольное. Под такое определение подойдёт, например, 1С-Управление, требующее для написания ноль строк, ибо «всё украдено до нас (с)». И вы, получается, опять в проигрыше.
Я бы рекомендовал вам, хотя бы примерно, вспомнить — а зачем вы придумали ту или иную фичу в вашем языке? И от этого вам станет яснее, какие конкретно преимущества вы ожидали, изобретая данный кусок языка. Ну а поняв, вы сможете указать другим — вот так вот делается быстрее потому что…
Ну и в целом сам язык тоже не на пустом месте появился. Точнее — идея нового языка. Во введении вы его сравнили с SQL, и в целом очевидно, что раньше писали системы преимущественно на хранимых процедурах, так вот и покажите, что в сравнении с хранимками вы увидели вот такое-то преимущество, вот так-то облегчающее работу программиста. Хотя здесь стоит заметить, что хранимки — это обычно довольно убогий процедурный язык, не позволяющий гибко работать со сложными абстракциями, а потому даже небольшое повышение уровня абстракции языка даёт ту самую важную гибкость, ну и поэтому (весьма вероятно) вам понравилась идея нового языка. Только ведь в таком разрезе есть альтернатива — изучить другой, более мощный при работе с абстракциями язык. Вы сравнивали свой язык в этом отношении с более универсальными? И что вас не устроило? То есть, часто люди поддерживают нечто своё не потому, что оно лучше других вариантов, а просто потому, что оно понятнее этим людям, ведь они написали это нечто с нуля и знают много важных деталей, которые помогают им наращивать эффективность в отдельных местах. Только эти «отдельные места» быстро заканчиваются. То есть писать по шаблону формочки для ERP — это одно, а вот если потребуется усложнение алгоритма — здесь могут быть страшные засады.
В общем — я бы сказал, что хотелось бы увидеть некую теоретическую базу, показывающую, что вы действительно сдвинули с места ту или иную проблему программирования, а не, в общем-то, рекламные слова про «среднюю ERP».
Для примера — в функциональных языках привычной является функции типа fold, zip, которые агрегируют переданные в них данные, примерно как ваша конструкция GROUP, но отличие такое — эти функции можно написать самому, а не использовать библиотечные. То есть гибкость здесь в том, что не нужен новый язык для реализации важного алгоритма агрегирования данных. А у вас нужна новая конструкция, которую нельзя написать средствами языка. У вас гибкость, получается, заметно меньше.
А у JS-фанов нет выбора. Компоненты в других языках программирования давно и прочно стали эффективным способом понижения сложности. И вот этот общепризнанный подход в его весьма скромной части нашёл путь в мир JS. В результате понижать сложность захотелось с помощью тех инструментов, которые показали JS-кодерам, как можно писать программы гораздо проще. Ну и далее пошло по стандартному пути — теперь у нас есть молоток, значит мы можем забить даже ломик в совершенно неподходящее для него отверстие! И не беда, что долго, сложно, неудобно, ведь главное — у нас есть молоток!
В целом в мире JS нет инструментов с вменяемой гибкостью. Гибкость же даётся не за красивые глаза (броскую рекламу), а за изучение более зрелых языков и способов разработки. И пока сообщество JS будет продолжать игнорировать давно существующий опыт, он так и будет забивать своим молотком тот самый неудобный ломик. Просто потому, что ломик в проекте должен быть, а из способов его включения в проект — лишь молоток.
Альтернативный путь сложен — надо изучать другие языки и их экосистему. В итоге можно будет использовать, например, GWT, дающую возможность очень гибко моделировать реальность при помощи гораздо более подходящего для этого языка и с использованием всех накопленных для этого языка архитектурных подходов. Но да, при этом нужно уходить от привычного JS и учить что-то новое…
Когда сочиняли Хаскель, именно так и думали. Но потом «что-то пошло не так (с)».
>> само слово “свойство” короче, чем «чистая функция», плюс не имеет ненужных ассоциаций.
Зря вы заменили привычные названия на вам приятный новояз. Это мешает тем, кто знает о чём речь. Хотя да, обычно продвижение языков начинают с полностью некомпетентной части разработчиков, что даёт большое количество участников, но если при этом заранее исключать грамотных участников — вы быстро выйдете из моды, ибо некомпетентная часть очень скоро перескочит на очередной «тренд».
>> SQL большинство из них недолюбливают, слишком уж там много магии под капотом
Здесь опять уход в сторону примитива. Не «недолюбливают», а просто не понимают. Хотя опять же — повысить ЧСВ недостаточно грамотных разработчиков в рекламных целях — это работающий рекламный ход.
>> в глобальной перспективе lsFusion под силу полностью заменить ERP, RAD и SQL платформы
В целом наблюдаю картину стандартной эйфории из серии «мы строили, строили, и вот — построили!». Понятно, что в такие моменты возникает желание срочно слетать на Марс и именно на только что построенном Запорожце. И не беда, что к старому запору придётся прикрутить космическую ракету, ведь главное — как нам нравится наш великий замах!
Конструктивно же — выход «на рынок» с новым инструментом есть дело затратное. Затраты, обычно, мало кто считает. Поэтому мало кто реально выходит на рынок.
Большие конторы, у которых денег немеряно, обычно продумывают стратегию использования новых инструментов. Сначала они спрашивают себя — а что мы можем поиметь с вывода на рынок вот такой вот тулзы? И просто некие абстрактные толпы поклонников в данном случае им мало интересны. Потому что им нужно окупить затраты на вывод системы в массы. А теперь сравним с вами — что вы намереваетесь получить? Если ответ привычный «много денег», то возникает вопрос — как? Вы думали? Сильно подозреваю, что нет. Точнее «в общих чертах мне всё понятно» как раз на самом деле является ответом типа «не думал». Бывает ещё ответ «хочу увидеть рост популярности моего любимого зайчика (инструмента)». Но здесь возникает второй вопрос — а вы знаете, сколько денег стоит вывести инструмент в разряд «популярных»? Подозреваю, что ответ опять — нет.
Ладно, это всё лирика, так, на будущее, может вас заинтересует.
По языку же скажу одно — заимствование давно известных подходов в новом инструменте никогда не являлось созданием нового подхода. Хотя да, для целей маркетинга и не такое подходит.
Новый язык должен дать нечто ранее не использованное в других языках. Ваша задача — указать это нечто и тем заманить массы в ваш лагерь. Из выше приведённого текста суть преимущества вашего языка не очевидна. В основе — функциональный подход, скрещенный с процедурным с надеждой на декларативность получившихся SQL-like конструкций. При этом основной нишей изначально была явно работа с БД, хотя в дальнейшем «Остапа понесло» и набор ниш быстро расширился. В целом получаем просто новый язык, который просто нравится автору, который считает, что создал нечто небывалое, а потому всем это будет интересно и все быстро станут это всё учить, использовать, ну и далее близится happy end.
Не хочу сильно бить по самолюбию, тем более, что вижу интересный подход, но тем не менее хочу повторить — сделать чудо в современных реалия сложно. И боюсь, у вас не получилось. Хотя если вы настаиваете — было бы неплохо понять преимущества, которые позволят, например, тем же разработчикам ERP, делать продукт быстрее, качественнее, дешевле и т.д.
>> Как симулятор поможет в дебаге на 100+ кубитов — вопрос открытый
Вообще, если есть понимание, как конвертируется обычный алгоритм в его квантовую версию, то таких вопросов быть не должно. То есть на обычных алгоритмах просто запускают задачу меньшей размерности, чем обеспечивают обход всех ветвей алгоритма, не требуя при этом перемалывать много данных.
Собственно для понимания процесса конверсии было бы прекрасно увидеть ещё одну статью в таком же стиле, как и представленная сегодня. Как я (по своей неграмотности) понимаю, алгоритмы в квантовые не конвертируются. То есть (упрощённо) нужны такие люди, которых очень-очень мало и при этом они ещё и очень-очень умные. Значит без таких людей квантовый компьютер — абсолютно бесполезная штуковина. А сами эти шаманы каким-то хитро-мудрым математическим аппаратом переводят уравнения квантовой физики в некую надежду на получение состояния квантовой системы, близкого к решению задачи при огромном количестве запусков. При этом — что там между задачей и готовым сбором статистики по результатам решения — никто не знает (ну кроме шаманов, понятно). В статье даже парочка шаманов упомянута — Гровер и Шор. Они, видимо, какую-то удачную конверсию относительно общего алгоритма сочинили? Типа факторизации.
И вот с таким представлением о алгоритмах квантовых компьютеров вы ещё получаете надежду на развитие, но в реальности у подавляющего большинства даже такого представления нет. Поэтому статья именно об алгоритмах очень нужна. Без неё — квантовый компьютер есть просто безумная идея, абсолютно недоступная для не знакомых с бездной формул из квантовой физики и ещё хрен знает откуда.
>> У пирамиды, перевернутой с ног на голову, фундамент разрушается вместе с вершиной, а тело приходит в совершенный беспорядок
В принципе правильно, но только фундамент не разрушается, а так же приходит в беспорядок вместе с телом. И потому становится бесполезен. Но сами знания сохраняются. Хотя для их объединения и упорядочивания теперь будут нужны гораздо большие усилия.
>> Отличие «фундаментальной» науки от «прикладной» с практической точки зрения состоит в том, что на исследования нужно время, которое 1) очень трудно предсказать, 2) потенциально очень большое.
Вот эти все «очень» говорят о том, что наукой просто не занимаются серьёзно.
>> На развитие теории чисел от записи на полях диофантовой арифметики до изобретения RSA понадобилось ~300 лет
Берите больше — от древних греков. Но и здесь та же закономерность — увлечённые одиночки творили исключительно для себя, и так все 2000+ лет. То есть сегодня хочу почесать левую пятку, а завтра — хочу мороженое, а когда захочу подумать — ну не знаю, может когда-нибудь…
Для примера, тот же RSA испарится как дым после целенаправленного развития теории целочисленных вычислений, а жив он лишь потому, что одиночки чешут пятки вместо целенаправленной работы. Ну а задать стимул для объединённых усилий коллективов — некому.
Что-то не пойму, кто статью перевёл и здесь разместил? Я что-ли? Так с чего претензии ко мне, а не к себе? Можно было элементарно более грамотную статью перевести, или от себя что-то дополнить, но выбор был сделан именно в пользу данного «материала», и выбор был сделан не мной, а тобой, так с чего друг претензии ко мне?
А когда я сделаю выбор и напишу статью, вот тогда можно будет мне предъявлять какие-то претензии. Хотя непонятно, почему такие элементарные вещи мне приходится объяснять переводчику статьи о квантовых компьютерах. Как-то совсем не сходится уровень замаха (квантовые компьютеры) и уровень непонимания реальности (банальные вещи из повседневной жизни).
>> И тогда наступает время героических историй о восхождении.
Восторженно и сладко о чём-то непонятном и недоступном посетителям детского сада.
Мне вот интересно, а кому могут быть полезны такие статьи? Что полезное вы приобрели прочитав все эти слова? Неужели вас купил весь это сладкий пряник, которого автор здесь накрошил просто немеярно? И теперь вы станете математиком? Или?
Логика — это как раз pure язык ХХХ. То есть чистая логика (чистые алгоритмы) пишутся на чистых языках (без библиотек и прочего).
>> А еще же фронт надо будет писать.
Есть GWT.
>> Допустим вам нужно написать какой-то простой процесс
Простой обычно означает — надо дёшево и быстро. Поэтому просто использую то, что знаю.
Функция, возвращающая всегда одно и то же значение, как раз выполняет то, что вы считаете невыполнимым. Это по сути константа, но для чистоты функционального подхода все константы определены именно в виде функций, возвращающих одно и то же значение.
>> вы до сайта не добрались
Да, не посмотрел сразу. Но исправился :) Там в части «Разрабатывайте просто» такой аргумент «против всех»:
>> Одна парадигма. Один язык
Или вот такое (в «Разрабатывайте быстро»):
>> Завершенная ERP-система среднего уровня сложности всего в 25K строках кода
Здесь на самом деле «всё не так просто (с)». Один язык и одна парадигма появились начиная с машинных кодов. Да, машинные коды позволяют написать и OLTP и OLAP, но вы же понимаете, что реальность внесёт здесь некоторые коррективы.
Ну а размер «средней ERP» — это вообще нечто абсолютно произвольное. Под такое определение подойдёт, например, 1С-Управление, требующее для написания ноль строк, ибо «всё украдено до нас (с)». И вы, получается, опять в проигрыше.
Я бы рекомендовал вам, хотя бы примерно, вспомнить — а зачем вы придумали ту или иную фичу в вашем языке? И от этого вам станет яснее, какие конкретно преимущества вы ожидали, изобретая данный кусок языка. Ну а поняв, вы сможете указать другим — вот так вот делается быстрее потому что…
Ну и в целом сам язык тоже не на пустом месте появился. Точнее — идея нового языка. Во введении вы его сравнили с SQL, и в целом очевидно, что раньше писали системы преимущественно на хранимых процедурах, так вот и покажите, что в сравнении с хранимками вы увидели вот такое-то преимущество, вот так-то облегчающее работу программиста. Хотя здесь стоит заметить, что хранимки — это обычно довольно убогий процедурный язык, не позволяющий гибко работать со сложными абстракциями, а потому даже небольшое повышение уровня абстракции языка даёт ту самую важную гибкость, ну и поэтому (весьма вероятно) вам понравилась идея нового языка. Только ведь в таком разрезе есть альтернатива — изучить другой, более мощный при работе с абстракциями язык. Вы сравнивали свой язык в этом отношении с более универсальными? И что вас не устроило? То есть, часто люди поддерживают нечто своё не потому, что оно лучше других вариантов, а просто потому, что оно понятнее этим людям, ведь они написали это нечто с нуля и знают много важных деталей, которые помогают им наращивать эффективность в отдельных местах. Только эти «отдельные места» быстро заканчиваются. То есть писать по шаблону формочки для ERP — это одно, а вот если потребуется усложнение алгоритма — здесь могут быть страшные засады.
В общем — я бы сказал, что хотелось бы увидеть некую теоретическую базу, показывающую, что вы действительно сдвинули с места ту или иную проблему программирования, а не, в общем-то, рекламные слова про «среднюю ERP».
Для примера — в функциональных языках привычной является функции типа fold, zip, которые агрегируют переданные в них данные, примерно как ваша конструкция GROUP, но отличие такое — эти функции можно написать самому, а не использовать библиотечные. То есть гибкость здесь в том, что не нужен новый язык для реализации важного алгоритма агрегирования данных. А у вас нужна новая конструкция, которую нельзя написать средствами языка. У вас гибкость, получается, заметно меньше.
Для «качественно» — при помощи средств, позволяющих гибко оперировать абстракциями. Например — Java. Хотя и Java ещё есть куда расти.
Для автора же важно понять хотя бы одну область, где его детище окажется явно лучше других. Ну и показать эту область остальным.
А у JS-фанов нет выбора. Компоненты в других языках программирования давно и прочно стали эффективным способом понижения сложности. И вот этот общепризнанный подход в его весьма скромной части нашёл путь в мир JS. В результате понижать сложность захотелось с помощью тех инструментов, которые показали JS-кодерам, как можно писать программы гораздо проще. Ну и далее пошло по стандартному пути — теперь у нас есть молоток, значит мы можем забить даже ломик в совершенно неподходящее для него отверстие! И не беда, что долго, сложно, неудобно, ведь главное — у нас есть молоток!
В целом в мире JS нет инструментов с вменяемой гибкостью. Гибкость же даётся не за красивые глаза (броскую рекламу), а за изучение более зрелых языков и способов разработки. И пока сообщество JS будет продолжать игнорировать давно существующий опыт, он так и будет забивать своим молотком тот самый неудобный ломик. Просто потому, что ломик в проекте должен быть, а из способов его включения в проект — лишь молоток.
Альтернативный путь сложен — надо изучать другие языки и их экосистему. В итоге можно будет использовать, например, GWT, дающую возможность очень гибко моделировать реальность при помощи гораздо более подходящего для этого языка и с использованием всех накопленных для этого языка архитектурных подходов. Но да, при этом нужно уходить от привычного JS и учить что-то новое…
Когда сочиняли Хаскель, именно так и думали. Но потом «что-то пошло не так (с)».
>> само слово “свойство” короче, чем «чистая функция», плюс не имеет ненужных ассоциаций.
Зря вы заменили привычные названия на вам приятный новояз. Это мешает тем, кто знает о чём речь. Хотя да, обычно продвижение языков начинают с полностью некомпетентной части разработчиков, что даёт большое количество участников, но если при этом заранее исключать грамотных участников — вы быстро выйдете из моды, ибо некомпетентная часть очень скоро перескочит на очередной «тренд».
>> SQL большинство из них недолюбливают, слишком уж там много магии под капотом
Здесь опять уход в сторону примитива. Не «недолюбливают», а просто не понимают. Хотя опять же — повысить ЧСВ недостаточно грамотных разработчиков в рекламных целях — это работающий рекламный ход.
>> в глобальной перспективе lsFusion под силу полностью заменить ERP, RAD и SQL платформы
В целом наблюдаю картину стандартной эйфории из серии «мы строили, строили, и вот — построили!». Понятно, что в такие моменты возникает желание срочно слетать на Марс и именно на только что построенном Запорожце. И не беда, что к старому запору придётся прикрутить космическую ракету, ведь главное — как нам нравится наш великий замах!
Конструктивно же — выход «на рынок» с новым инструментом есть дело затратное. Затраты, обычно, мало кто считает. Поэтому мало кто реально выходит на рынок.
Большие конторы, у которых денег немеряно, обычно продумывают стратегию использования новых инструментов. Сначала они спрашивают себя — а что мы можем поиметь с вывода на рынок вот такой вот тулзы? И просто некие абстрактные толпы поклонников в данном случае им мало интересны. Потому что им нужно окупить затраты на вывод системы в массы. А теперь сравним с вами — что вы намереваетесь получить? Если ответ привычный «много денег», то возникает вопрос — как? Вы думали? Сильно подозреваю, что нет. Точнее «в общих чертах мне всё понятно» как раз на самом деле является ответом типа «не думал». Бывает ещё ответ «хочу увидеть рост популярности моего любимого зайчика (инструмента)». Но здесь возникает второй вопрос — а вы знаете, сколько денег стоит вывести инструмент в разряд «популярных»? Подозреваю, что ответ опять — нет.
Ладно, это всё лирика, так, на будущее, может вас заинтересует.
По языку же скажу одно — заимствование давно известных подходов в новом инструменте никогда не являлось созданием нового подхода. Хотя да, для целей маркетинга и не такое подходит.
Новый язык должен дать нечто ранее не использованное в других языках. Ваша задача — указать это нечто и тем заманить массы в ваш лагерь. Из выше приведённого текста суть преимущества вашего языка не очевидна. В основе — функциональный подход, скрещенный с процедурным с надеждой на декларативность получившихся SQL-like конструкций. При этом основной нишей изначально была явно работа с БД, хотя в дальнейшем «Остапа понесло» и набор ниш быстро расширился. В целом получаем просто новый язык, который просто нравится автору, который считает, что создал нечто небывалое, а потому всем это будет интересно и все быстро станут это всё учить, использовать, ну и далее близится happy end.
Не хочу сильно бить по самолюбию, тем более, что вижу интересный подход, но тем не менее хочу повторить — сделать чудо в современных реалия сложно. И боюсь, у вас не получилось. Хотя если вы настаиваете — было бы неплохо понять преимущества, которые позволят, например, тем же разработчикам ERP, делать продукт быстрее, качественнее, дешевле и т.д.
Вообще, если есть понимание, как конвертируется обычный алгоритм в его квантовую версию, то таких вопросов быть не должно. То есть на обычных алгоритмах просто запускают задачу меньшей размерности, чем обеспечивают обход всех ветвей алгоритма, не требуя при этом перемалывать много данных.
Собственно для понимания процесса конверсии было бы прекрасно увидеть ещё одну статью в таком же стиле, как и представленная сегодня. Как я (по своей неграмотности) понимаю, алгоритмы в квантовые не конвертируются. То есть (упрощённо) нужны такие люди, которых очень-очень мало и при этом они ещё и очень-очень умные. Значит без таких людей квантовый компьютер — абсолютно бесполезная штуковина. А сами эти шаманы каким-то хитро-мудрым математическим аппаратом переводят уравнения квантовой физики в некую надежду на получение состояния квантовой системы, близкого к решению задачи при огромном количестве запусков. При этом — что там между задачей и готовым сбором статистики по результатам решения — никто не знает (ну кроме шаманов, понятно). В статье даже парочка шаманов упомянута — Гровер и Шор. Они, видимо, какую-то удачную конверсию относительно общего алгоритма сочинили? Типа факторизации.
И вот с таким представлением о алгоритмах квантовых компьютеров вы ещё получаете надежду на развитие, но в реальности у подавляющего большинства даже такого представления нет. Поэтому статья именно об алгоритмах очень нужна. Без неё — квантовый компьютер есть просто безумная идея, абсолютно недоступная для не знакомых с бездной формул из квантовой физики и ещё хрен знает откуда.
Когда-то про умножение думали, что дальше уже увеличивать скорость вычислений нельзя, но тут выстрелил некто Карацуба…
Нет, вся проблема в одном месте — в управлении. Специалисты же лишь выполняют приказ.
В принципе правильно, но только фундамент не разрушается, а так же приходит в беспорядок вместе с телом. И потому становится бесполезен. Но сами знания сохраняются. Хотя для их объединения и упорядочивания теперь будут нужны гораздо большие усилия.
Вот эти все «очень» говорят о том, что наукой просто не занимаются серьёзно.
>> На развитие теории чисел от записи на полях диофантовой арифметики до изобретения RSA понадобилось ~300 лет
Берите больше — от древних греков. Но и здесь та же закономерность — увлечённые одиночки творили исключительно для себя, и так все 2000+ лет. То есть сегодня хочу почесать левую пятку, а завтра — хочу мороженое, а когда захочу подумать — ну не знаю, может когда-нибудь…
Для примера, тот же RSA испарится как дым после целенаправленного развития теории целочисленных вычислений, а жив он лишь потому, что одиночки чешут пятки вместо целенаправленной работы. Ну а задать стимул для объединённых усилий коллективов — некому.
На самом деле она говорит, что:
В одной плоскости с заданной прямой через точку, не лежащую на этой прямой, можно провести только одну прямую, параллельную заданной прямой
А когда я сделаю выбор и напишу статью, вот тогда можно будет мне предъявлять какие-то претензии. Хотя непонятно, почему такие элементарные вещи мне приходится объяснять переводчику статьи о квантовых компьютерах. Как-то совсем не сходится уровень замаха (квантовые компьютеры) и уровень непонимания реальности (банальные вещи из повседневной жизни).
Ну да, не извращенец. Понял, что народ осознал низкий уровень качества и продаж больше не будет, ну и даже на этом опять создал себе рекламу.
Восторженно и сладко о чём-то непонятном и недоступном посетителям детского сада.
Мне вот интересно, а кому могут быть полезны такие статьи? Что полезное вы приобрели прочитав все эти слова? Неужели вас купил весь это сладкий пряник, которого автор здесь накрошил просто немеярно? И теперь вы станете математиком? Или?
Вы можете кратко изложить способ адаптации произвольного алгоритма для исполнения на том, что «очень круто»? Если нет, то в чём крутость?