company_banner

Программирование голосом. Передовые рубежи разработки ПО

Автор оригинала: Rina Diane Caballar
  • Перевод

Очередной виток эволюции в области программирования — это написание кода посредством голоса. Данная возможность пока находится на ранних этапах развития, но уже привлекает к себе многих разработчиков, особенно людей, испытывающих те или иные физические ограничения. Какие же технологические решения предлагает рынок на сегодня, и что именно послужило триггером к их развитию?


Работа в Serenade

Технологическая основа


Мы все больше и больше взаимодействуем с гаджетами через речь. Наши старые виртуальные помощники вроде Alexa и Siri теперь объединяются с автомобильными ассистентами, например Apple CarPlay и Android Auto, а также с приложениями, работающими с голосовой биометрикой и командами. Но что, если саму технологию можно было бы создавать при помощи голоса?

Этот замысел и лег в основу программирования речью, техники разработки ПО, подразумевающей ввод кода не посредством клавиатуры и мыши, а с помощью голосовых команд. Для этого используются соответствующие платформы, где программисты могут не только применять встроенные команды, но также создавать их собственные варианты, упрощая и автоматизируя весь рабочий процесс.

Однако программирование голосом оказывается не столь простым и кроет в себе несколько слоев сложной технологии. К примеру, в Serenade используется движок преобразования речи в текст, созданный специально для работы с кодом, в отличие от аналогичного API Speech-to-text, спроектированного Google для разговорной речи. После того, как инженер проговаривает код, движок Serenade передает его в слой обработки естественного языка, в котором специально обученные модели машинного обучения (МО) распознают и переводят стандартные программные конструкции в синтаксически верный код.

Существует две основных платформы, предлагающих различные подходы к задачам рецитирования кода компьютеру. Одна из них, Serenade, выступает в качестве цифрового помощника, позволяя описывать вводимые в коде команды без необходимости проговаривать каждую инструкцию дословно. Другой инструмент, Talon, предоставляет более тонкий контроль над каждой строкой, что также требует более тщательного понимания каждой программируемой в машину задачи. Ниже вы видите простой пример пошагового руководства в Serenade и Talon по генерации кода Python, выводящего на экран слово “hello”.




Технология против «офисного синдрома»


Компания Serenade, собравшая $2.1 миллиона на этапе начального финансирования в 2020 году, родилась в силу необходимости, после того, как одному из ее основателей, Мэтту Уитхоффу, в 2019 году бы поставлен диагноз «хроническая травма от повторяющегося напряжения». «Я бросил работу разработчиком ПО в Quora, потому что просто перестал с ней справляться, — говорит Мэтт. – В качестве альтернативы оставалось либо заняться деятельностью, не требующей такого количества набора текста, либо искать другой выход».

Тем же путем в 2017 году пошел Райан Хайлман, оставив свое постоянное место работы программистом, после того как годом ранее у него возникли сильные боли в руке. Тогда Тайлман занялся разработкой Talon, платформы для написания кода без использования рук. Он говорил: «Задача Talon – полностью заменить клавиатуру и мышь для любого человека».

С этой целью в ней реализовано три программных компонента: распознавание речи, отслеживание глаз и распознавание звука. Движок распознавания речи основан на разработанной Facebook автоматической системе Wav2letter, которую Тайлман расширил командами для программирования. При этом функция отслеживания глаз и распознавания звука симулирует управление с помощью мыши. Курсор перемещается по экрану вслед за перемещением взгляда, а клики совершаются в ответ на издаваемый ртом звук, напоминающий откупоривание шампанского. Как говорит Райан: «Издать такой звук легко. Он не требует особых усилий и распознается очень быстро, что представляет более быстрый невербальный способ реализации щелчков мыши, не вызывающий голосового напряжения».

Написание кода с помощью Talon звучит подобно инопланетному языку, как это продемонстрировала Эмили Ши, инженер и практик данной техники, выступавшая на конференции в 2019 году. Предложенное ей видео наполнено командами типа “slap” (Ввод), “undo”, “spring 3” (перейти к третьей строке файла) и “phrase name op equals snake extract word paren mad” (создает строку: name = extract_word(m)).

С другой стороны, при написании кода с помощью Serenade, команды проговариваются более естественным образом. Можно сказать «delete import”, чтобы удалить инструкцию импорта в начале файла или “build”, чтобы выполнить пользовательскую команду сборки. Также можно сказать “add function factorial” для создания функции, вычисляющей факториал, например, в JavaScript. В этом случае приложение полностью возьмет на себя синтаксис, включая ключевое слово “function”, скобки и фигурные скобки, избавив вас от необходимости явно проговаривать каждый элемент.

Для программирования голосом требуется хороший микрофон, особенно если вы хотите устранить фоновый шум. Тем не менее модели Serenade обучены на аудио, получаемом с микрофонов ноутбуков. Если же вы хотите использовать Talon с функцией отслеживания движения глаз, то также потребуется соответствующее оборудование. Хотя Talon отлично работает и без него. Открытые платформы для написания кода голосом, такие как Aenea и Caster, хоть и бесплатны, но обе опираются на движок распознавания речи Dragon, который пользователь должен приобретать отдельно. При этом Caster предлагает поддержку Kaldi, открытого набора инструментов для распознавания речи, а также Windows Speech Recognition, поставляемого с ОС Windows по умолчанию.

По словам сооснователя Serenade Labs, Томми МакУилльям, результаты говорят сами за себя: «Описать желаемое действие становится намного проще. Ведь куда легче просто сказать “move these three lines down” или “duplicate this method” вместо того, чтобы печатать все эти инстуркции или даже использовать горячие клавиши.»

Программирование голосом также позволяет людям с травмами или хроническими болями продолжить свою карьеру. Как говорит Эмили: «Способность использовать голос, исключая из процесса участие рук, открыла для меня гораздо более широкий спектр возможностей взаимодействия с компьютером».

Написание кода с помощью речи, помимо прочего, снижает барьер входа в разработку ПО. МакУилльям по этому поводу говорит так: «Если человек сможет представить код, который он хочет написать, логически и структурированно, то остальное можно будет поручить алгоритму МО, который переведет мысли разработчика в синтаксически правильный код».

Программирование голосом по-прежнему находится на начальной стадии развития, и возможность его широкого распространения зависит от степени привязанности разработчиков ПО к традиционной модели написания кода с помощью клавиатуры и мыши. Как бы то ни было, данная технология открывает широкие возможности, например, тропу в будущее, где интегрированные в мозг нейроинтерфейсы смогут напрямую преобразовывать мысли в код, или даже готовые программы.

RUVDS.com
VDS/VPS-хостинг. Скидка 10% по коду HABR

Комментарии 25

    +3
    По-моему это пока полная хрень. Очень неудобно. Некоторые короткие и популярные термы так вообще голосом гораздо труднее выговаривать. Да и чёткость распознания в ряде случае будет хромать. Придётся многократно исправлять. А если ещё и акцент будет… Не — ну для тех, у кого есть физические ограничения — это бесспорно да — хорошее решение — но именно в таком ключе не хотелось бы, чтобы это было мейнстримом. А для обычного программирования — получается очень медленно, и с очень большим количеством WTF будет писаться код. По крайней мере так — как это показано в статье.
    Но… я не исключаю, что в более отдалённом будущем — это станет мейнстримом (но вряд ли даже относительно скоро мейнстримом у профессионалов). Современные языки программирования просто не созданы для этого. Да что там языки программирования — сейчас ввод текста то со слов часто ошибается (так что длинные тексты писать голосом почти невозможно). Даже на английском — где наработано очень много. А ведь есть такие языки, как скажем, китайский — там вообще голосом очень сложно вводить текст (а программирование на английском языке не на много проще) — ну не создавались языки для этого.
    Ещё добавлю, что крайне редко (тем более серьёзный алгоритм) набирается линейно — слово за словом, команда за командой. Программисты бегают по коду туда-сюда и постоянно его модифицируют. И пока делать это голосом очень и очень сложно!
    Но, в будущем возможно ситуация изменится за счёт:
    1. Будут созданы новые языки программирования (возможно даже промежуточные), лингвистический синтаксис которых будет более адаптирован для ввода на слух, а сам их синтаксис будет более простым (и чем проще — тем лучше)
    2. IDE будут более адаптированы для ввода на слух- заранее просчитывая оптимальные варианты продолжения, предлагая их на выбор, и готовясь заменять ими уже написанную предварительную часть код (она должна быть помечена для программиста — как предварительная, чтобы он понимал, что его не нужно сейчас править, а нужно продолжить ввод и IDE сама поймёт что и как нужно будет поправить)
    3. ЯП и IDE должны задействовать самообучаемый AI, который будет подстраиваться под манеру программирования конкретного программиста (не только правильно по текущему контексту распознавать текст на слух, но и более эффективно и осознанно сразу писать код). При этом синтаксис ЯП должен быть упрощён, а AI должен уметь его правильно интерпретировать, понимая, что в более простых терминах, реально требуется — генерируя на выходе уже более сложный код (это уже при трансляции/компиляции).
    4. IDE и IDE так же нужно больше освоить помощь в поиске и устранению ошибок, отладке и оптимизаци — т.к. бОльшую часть времени программист тратит на это, а не на ввод текста. И именно тут управление голосом и возможности AI-анализа кода могут сыграть главную роль в ускорении создания программ
    5. Ну а программистам нужно осваивать новые подходы к написанию программ. Больше задействую интеллектуальны команды AI, в основном команды, рефакторинга и вставки (с AI адаптацией под контекст) готовых сниппетов и гистов (и их быстрый поиск). А AI быть дружелюбной к пистонным переходам по алгоритму, и его постмодификации, а не просто к линейному набору текста.

    То есть, в итоге — голосовой ввод должен как можно менее уделять внимания деталям ввода разных управляющих конструкций. И как можно более — управлению рефакторингом и умным аналитическим инструментарием, поиску, адаптации и изменению уже существующего кода (в т.ч. вставляемого чужого но под текущий контекст). В идеале же — голосовые команды ввода новых алгоритмов должны быть сведены как можно более декларативным — то есть программист не должен голосом прорабатывать весь алгоритм — он должен указать AI-ассистенту что ему нужно сделать — а он уже должен это реализовать сам (по адаптивной базе знаний) на описанном выше упрощённом языке программирования, чтобы программисту было проще понять и поправить результат (как уже было написано мной выше — а далее уже этот же AI-ассистент будет транслировать этот промежуточный ЯП в более строгий «машинный» код для последующей компиляции уже обычным компилятором (причём, возможно, уже для платформы квантовых компьютеров) или интерпретации). Кончено, по началу это будут простые небольшие куски кода (или не сложные задачи над большими кусками кода), но со временем AI-ассистент научится писать всё более и более ёмкий и точный программный код (под чутким надзором программиста), а само программирование начнёт смещаться в сторону постановки ТЗ для AI-ассистента, и контроль результата. Вот тогда — да — голосовой ввод станет популярен. Но это будет уже эпоха 5-го поколения языков программирования! И, настанет она не ранее второй половины, а скорее конца XXI века.

    А пока — в IDE нужно внедрять больше аналитических и инструментальных средств автоматизации ввода и анализа программного кода. И внедрять AI-ассистента, который помогал бы вводить, анализировать и изменять программный код без голосовых команд, а потом прикручивать к IDE голосовые команды управления (вместо горячих клавиш), и только потом переходить к голосовому вводу программного кода — как раз середине века можно до этого добраться новым версиям IDE!
      0
      Я вспоминаю старые публикации, когда только появился Windows, его ругали и говорили профессионалы, что графический интерфейс не нужен. Но, это удобство. И новое поколение людей, которе будут писать код сразу таким способом уже не сядут за клавиатуру (не буквально, конечно). Так что ругать такой подход не стоит.
        +1
        Я вроде бы не ругал — наоборот — я написал, что для убогих — сгодится (хотя трудно мне предположить сколько кода они так натрендят, но, Стивен Хокинг же вполне себе мог много натрендеть хоть и не кода, а научного текста — это ещё когда он говорить мог, а голосовое распознавание тогда ещё было куда более ущербным — эх… где ты «Горыныч» и «Говорящая мышь»).
        А для остальных — тоже весьма подробно изложил своё виденье того, какие проблемы есть (не освещённые в статье), и как голосовое кодирование программ может развиваться — и обозначил временнЫе перспективы — я не ставлю на этом крест — но и в то, что сейчас тут в статье продемонстрировано, я не верю — пока это бред — будущее есть — но оно отдалённое.
        Кстати, вон, более 30 лет назад говорили о радужных перспективах ЯП 4-го поколения — с графическим управлением — где вообще не нужно писать код текстом (изначально так, потом ослабили — писать можно — но гораздо меньше и восприниматься результат графически будет лучше) — даже появились Двухмерные языки (например советский ДРАКОН — на нём даже программу для Бурана писали) и даже многомерные языки (4DL). Но практически все они канули в лету, не то, чтобы стали хоть как-то популярны — а вообще ничем не стали.
        Правда сейчас понятие 4-го поколения языков программирования стало очень размытым — к нему стали относить не столько графические языки — сколько обычные ЯП прикладного уровня — ограниченно ориентированные на выполнение прикладных задач. Например, продвинутые диалекты языка SQL больших СУБД можно отнести к языкам 4-го поколения. Или некоторые языки баз noSQL, или, скажем RegEX.
        Не всё что воспринимается в штыки — потом так и остаётся в стороне — но что-то остаётся! А что-то уж очень сильно видоизменяется. Именно об этом я и пишу — ЯП и IDE нынешнем виде крайне плохо приспособлены к речевому вводу. А программисты пока ещё тоже не умеют эффективно этим пользоваться. Но со временем — ситуация изменится. И я написал в каких направлениях нужно двигаться для этого
          0
          А какие есть удобные системы контроля версий для графических ЯП?
            0
            Беспонятия, но не вижу тут никаких проблем — ведь в итоге то хранится всё в текстовых файлах
              0
              Ну так вы и сравниваете тогда текстовые файлы, правда же? И честно говоря, все что я видел подобного рода, реальной разницы между двумя графами показывать не умеет.
          +1
          Графический интерфейс появился до Windows
            +1
            Да, на Эплах ещё в конец 70-х (если не ошибаюсь) были окна — если Вы о них.
            Но именно Windows 95 сделал их массовыми (а до него ещё был Windows 1.0… 3.11) и удобными настолько, что за 25 лет по сути в оконной системе ничего толком не изменилось — и даже Linux всеми силами старается её воспроизводить так как она была представлена в Windows 95 (про Unix Solaris ничего сказать не могу — но окна и там есть). А вместе с окнами в массы пошло и визуальное программирование (как минимум оконного интерфейса, и как отдельная ветвь — возникло визуальное кодирование (хоть и не ставшее мейнстримом), даже раньше, чем появились модные UML диаграммы)
            0
            Графический интерфейс хорош, когда надо сделать делать какое то действие пару раз и забыть об этом. То, что приходится делать регулярно и по многу раз удобнее делать без ГУИ, консольными командами. Но подавляющее большинство Windows пользователей об этом не знают и продолжают тыкать мышкой одни и те же последовательности нажатий кнопок в ГУИ изо дня в день, долгими годами и даже десятилетиями.
              +1
              Графический интерфейс обычно удобнее большинству — он лучше воспринимается — он более естественен чем консольный ввод. Но да — некоторые люди в силу разных причин осваивают консольный ввод — и это действительно может ускорять процесс. Но освоение — это процесс глубокого обучения командам — он априори ограничен. А грамотный графический интерфейс — априори широко понятен без длинного вникания — позволяет управлять всем почти без предварительного освоения. Но не хочу превращать эту тему в холивор на тему что лучше гуи или консоль — тут каждому своё. Замечу, что все консоли нынче в окнах — и часто работают сразу с несколькими окнами — в досе с этим были бы сложности
                0
                И, кстати, в рамках сабжа статьи. Сделать голосовое управление для консольного ввода несколько проще, чем для грамотного графического интерфейса, и чем хуже проработан графический интерфейс, тем больше будет выигрывать голосовой ввод на консоль, для которой проработка синтаксиса, хоть и важна, но совсем не так сильно, как графического интерфейса — для голосового ввода. Так что консоль — это, конечно сила, и, вероятно, в будущем первичной будет консоль, а к ней уже будет прокручивать гуи и звуковое управление — основанное на консольных командах
            +2
            Добавлю, что были ссылки на исследование (которому лет 20 уже), что голосом набирать текст на порядок более энергозатратно, чем на клавиатуре. Об этом вам любой лектор может рассказать. Но в целом идея интересная и со всеми пунктами вашего комментария согласен.
              +1
              Вот именно об этом я написал. Но, тем не менее — такой вариант ввода вполне возможен в будущем, и возможно, вполне эффективен — тем более, что много операций при программировании по факту не связаны с вводом текста — а это в лучшем случае горячие клавиши и последующие манипуляции на клавиатуре без прямого потока текста, либо щёлканья мышкой с постоянными переключениями на клавиатуру и на мышь — а это всё очень медленно и энергозатратно. Вот отсюда должны расти ноги голосового управлении и лишь затем — ввод длинных программных текстов.

              Добавлю ещё то, что со временем (наверное уже не ранее XXII века) голосовой ввод вполне может перейти ввод силой мысли — но там свои нюансы, зато в идеале у натренированных программистов(+ натренированный AI-ассистент) — скорость ввода может стать на порядок выше — чем сейчас (при рядовом размеренном программировании, а не на скорость), при незначительно (а то и вовсе без) снижении первичного качества (надёжно повышаемого, условно, на «втором» проходе). Но тут свои нюансы, проблемы и недостатки, конечно, обсуждать которые ещё очень и очень рано. Зато энергозатраты будут куда ниже, чем при печатанье на клавиатуре
            +2
            На мой взгляд, тема не особо актуальна и имеет скорее академический интерес, чем практический. Основные причины:
            — набор кода в программировании — далеко не самый затратный по времени процесс и голосовой ввод не приведет к заметному выигрышу по времени в целом;
            — голосовой ввод может выглядеть привлекательно в плане ускорения для простых конструкций языка уровня «hello world», а вот для более-менее сложных эффект может быть противоположным;
            — синтаксис современных языков программирования довольно сложен, чтобы описывать его голосом и при этом еще и выигрывать по времени;
            — хоткеи, интеллектуальные помощники и сниппеты кода в современных IDE в большинстве случаев позволяют писать код на порядок быстрее чем вы расскажете компьютеру что вы от него хотите
              0
              Если Вы прочитали мои комментарии выше — а там написано как я себе представляю голосовой ввод — то Вам было должно быть понятно — что я как раз описал вариант, когда голосовой ввод это не столько ввод текста, сктолько отдача целеуказаний IDE и AI-Ассистенту — которые и будут выполнять основную когенерацию, анализ и изменение текста алгоритмов и определений. И жда, все горячие клавиши (и тем более инструменты без них) — так вообще пековые в очереди на привязку к голосовому управлению (поначалу, конечно длинные комбинации, а потом и одноклавишные подтянутся).
              И про синтаксис я тоже там написал — что его нужно упрощать и адаптировать в новых ЯП, создаваемых специально с прицелом на голосовой ввод + последующая контекстная обработка искусственным интеллектом с когенерацией уже кода в терминах машинных инструкций (я не про низкий уровень, я про код уровня Java или или C# или C++ или Python, или, скажем, Q#).
              И про сниппеты и гисты я написал — что ими голосом управлять будет проще, чем вызывать горячими клавишами и делать не голосовой поиск
              У голосового программирования есть будущее — но не близкое.
              И ещё — это хороший вариант, не только для ограниченных физически людей, а просто для расслабления после ручного кодирования.

              Приведите, пожалуйста сложный пример, который голосом будет дольше набираться?
                0
                И жда, все горячие клавиши (и тем более инструменты без них) — так вообще пековые в очереди на привязку к голосовому управлению (поначалу, конечно длинные комбинации, а потом и одноклавишные подтянутся).
                Любой хоткей, даже составной, вроде Ctrl+R Ctrl+S, прожимается меньше чем за секунду, я уже не говорю об одиночных. Какой выигрыш может дать замена их на голосовые команды?

                И про синтаксис я тоже там написал — что его нужно упрощать и адаптировать в новых ЯП
                Вы ведь понимаете, что в современных ЯП синтаксис сложный не потому, что это программистам нравится? Синтаксис языков развивается и эволюционирует, и основные приоритеты при этом — это функциональность, компактность, лаконичность и читаемость кода. Упрощая синтаксис вы будете терять что-то из этих показателей. В итоге голосовой ввод из инструмента превращается в самоцель, получая приоритет выше чем сам язык программирования.

                И про сниппеты и гисты я написал — что ими голосом управлять будет проще, чем вызывать горячими клавишами
                Возьмем простейший пример, надо создать класс данных для общения c Web API. Я копирую в буфер обмена имя поля со страницы документации API, в студии набираю «ps», прожимаю Tab — получаю заготовку public string Name { get; set; } с выделенным именем, далее Crtl+v, и снова Tab. В итоге на создание поля уходит около двух секунд. Предложите, пожалуйста, набор голосовых команд для данного сценария, которые вы внятно произнесете хотя бы за те же 2 секунды.

                а просто для расслабления после ручного кодирования.
                Да не набирает программист за день столько кода, чтобы была необходимость расслаблять руки.

                Приведите, пожалуйста сложный пример, который голосом будет дольше набираться?
                Зачем сложный? Как Вы предлагаете озвучить следующие три простых строки (с сохранением регистра символов)? Обратите внимание, что recPath и recFile не распознаются как слова. И как быть с сокращениями? Посимвольно озвучивать?
                string recPath = @"d:\Temp"; // TODO: Get record file path
                string recFile = "TESTRecordABC.dat"; // TODO: Get record file name
                string header = $@"[{DateTime.Now:HH:mm:ss.fff}] {recPath}\{recFile}";
                

                Я не против голосового программирования как такового, оно должно развиваться, ибо даст возможность полноценно работать парализованным людям. Но в Вашем виденье оно выступает серебряной пулей и заменой ввода с клавиатуры с голословными утверждениями что это будет быстрее. Мало того, Вы предлагаете подстраивать ЯП под голосовой ввод в ущерб синтаксису.
                  0
                  Любой хоткей, даже составной, вроде Ctrl+R Ctrl+S, прожимается меньше чем за секунду, я уже не говорю об одиночных. Какой выигрыш может дать замена их на голосовые команды?

                  Не знаю как другие — лично я, терпеть не могу составные хоткеи — где нужно последовательно наживать клавиши, так же не любою хоткеи где есть пара «shift+alt+» или «ctrl+alt+» уж очень неудобно нажимать. Да и c двумя клавишами бывает тоже очень неудобно тянуться за второй клавишей. Голосом было бы проще командовать. И да, мне, скажем, сказать команду «андо» куда быстрее чем нажать «Ctrl+z» — конечно, если нужно сделать много отмен — то пулемётить «Ctrl+z» быстрее чем говорить. Но голосом же можно говорить более сложные команды — типа «андо тэн», «андо фифти», «редо файв». Не говоря уже о командах открытия/перехода всяких инструментальных окон и выполнения операций в них.
                  Если Вы эффективно управляете более 100 таких хоткеев — я искренне рад за Вас.
                  Если Вы готовы назначить ещё 1000 хоткеев, и управлять ими, на разного рода команды, которые сейчас в IDE никак не обслуживаются (потому что даже разработчикам IDE их влом туда внести), но могли бы сильно повысить эффективность управления программным кодом — я рад за Вас
                  Если Вы не хотите вообще повышать эффективность работы в IDE — мне искренне пофиг на это.
                  Но, бОльшая часть программистов хоткееями пользуется не часто и в лучшем случае 10-20 составных хоткеев (и знает ещё столько же — им мышкой проще кликнуть) — я не говорю, что это эффективно — я говорю, что с голосовым управлением эти программисты бы быстрее освоили бы и сотни и тысячи интуитивно понятных голосовых команда, которые существенно бы повысили их эффективность. Не говоря уже о том, что профессионалы бы навострились отдавать голосовые команды параллельно, не отрывая пальцев от набора текста или тех же хоткее-в для команд, исполняемых в «параллельном потоке действий».

                  Вы ведь понимаете, что в современных ЯП синтаксис сложный не потому, что это программистам нравится? Синтаксис языков развивается и эволюционирует, и основные приоритеты при этом — это функциональность, компактность, лаконичность и читаемость кода. Упрощая синтаксис вы будете терять что-то из этих показателей. В итоге голосовой ввод из инструмента превращается в самоцель, получая приоритет выше чем сам язык программирования

                  Не согласен – синтаксис языка может быть простым и мощным (пример тот же Python по сравнению с C++) или Kotlin по сравнению с Java и C# (возможно немного высланные из пальца сравнения, т.к. может и разница не велика и не такие уж простые эти языки; ну сравните тогда Kotlin Native и С++ или Swift и Objective C; да хоть Алгол 86 (или тем более С++) и Turbo Pascal и Object Pascal; Erlnag vs Elixir) – проще и мощнее создать ЯП вполне можно.
                  Но – вот, есть T-SQL – он куда проще, чем С++ в команды которого (условно) превращается (да, он более ограниченный – но со своей задачей справляется – может не нужно искать универсальный язык для всех задач), и то T-SQL можно было бы заменить более простым и мощным языком.
                  Ну а в будущем – идея в том, чтобы сместить программирование больше в строну декларативности — а уже AI будет контекстно и с глубоким анализом обрабатывать эти команды – и генерировать уже более машинный и сложный код для компиляции под платформу исполнения.
                  Просто, видимо пока ещё не пришло (время для такого языка – ибо это будет уже язык 5-го поколения (6-го – смотря как считать поколения).
                  Я, вот, уже года два прорабатываю идею таких ЯП (сразу двух – один ближе к 4-тому поколению, второй – чисто уже 5-ое) – минимальный синтаксис – максимальная красота и расширяемая мощь обработки синтаксических конструкций и данных! С сохранением высокой читаемости и понятности кода. Ключевых слов не более 20 десятков (основных чуть более 10; не считая табуляторов и математических операторов), примерно столько же ключевых понятий – кирпичиков алгоритмов. А мощь – сильнее C#, Python, Swift, TypeScript, Kotlin вместе взятых! Но ЯП пока только в разработке лексики, обсуждать его не буду.
                  И тем не менее, говоря о простоте языка – я, всё-таки, в данном контексте, имел в виду именно изначальную его адаптивность к голосовому набору – его синтаксис должен быть к этому предрасположен – поменьше ключевых слов и трудно/длинно произносимых слов. Попроще конструкции.

                  Возьмем простейший пример, надо создать класс данных для общения c Web API. Я копирую в буфер обмена имя поля со страницы документации API, в студии набираю «ps», прожимаю Tab — получаю заготовку public string Name { get; set; } с выделенным именем, далее Crtl+v, и снова Tab. В итоге на создание поля уходит около двух секунд. Предложите, пожалуйста, набор голосовых команд для данного сценария, которые вы внятно произнесете хотя бы за те же 2 секунды

                  Возможно Ваш пример не полон. Ибо в постановке речь шла о создании целого класса, а Вы создали одно поле. Но даже на него, я не уверен, что Вы затратите не более 2-х секунд – разве что уже всё будет найдено и выделено, а может и скопировано в буфер. В идеале голосовые команды следующие (опускаю — что слово «документация» уже связано с нужным источником документации в проекте:
                  — Найди в документации класс такойто
                  — Экспортируй в проект
                  — Операция удаление членов начать
                  — <перечисление членов к удалению>
                  — Применить операцию удаления
                  <или>
                  — Операция удаление членов от обратного начать
                  — <перечисление членов, которые нужно оставить>
                  — Применить операцию удаления

                  Заодно и описания свойств из документации вставятся
                  Но если нужно в готовый класс перенести один член из документаци – то кто мешает сделать голосом тоже самое (считаем что всё уже спозиционировано – т.к. этот процесс Вы не описываете):
                  — Слово в буфер //Копирование в текущей позиции слова из документации, в фокусе
                  — Вернуться //Возвращение в точку проекта
                  — Снипет пис //адаптивное распознрвание голоса со временем поймёт – что это ps
                  — Вствить из буфера

                  Или так (активно окно проекта, уже ранее документация подключена к словарю голосового анализатора) – думаю даже более популярный вариант
                  — Снипет пис
                  — <говорите имя свойства> //с вероятностью близкой к 100% оно удачно распознается – учитывая подключенный текст документации, на крайняк, гворите «нет» -и будет предложен другой вариант – тут уже почти 100% попадание будет. Ну или «взад» и повторяете имя чётче
                  По времени, конечно будет больше 2-х секунд, но не на много. Но я по-прежнему думаю, у Вас это займёт больше 2 сек – особенно, когда нужно будет переносить не одно свойство, а несколько членов – мышкой просто дольше ёрзать будете, чем 2 сек на член.

                  Хотя на моём бы языке было бы вот так (предыдущий вариант) для одного свойства (для массового ввода чуть попроще):
                  — деф
                  — <говорите имя свойства>
                  — Строка
                  Просто я за паблик свойства по умолчанию ;-) Думаю в 2 сек уложиться можно даже с длинными именами свойств
                  А последующие свойства, отличающиеся только именами можно было бы так вводить
                  — ещё
                  — <говорите имя свойства>
                  — ещё
                  — <говорите имя свойства>
                  — ещё
                  — <говорите имя свойства> Число //Поменяли тип на число
                  Думаю тут и 1.5 сек можно уложиться.
                  Уверен, что большинство программистов предпочтут проговаривать имена свойств (если они будут хорошо распознаваться), ну или массово переносить всё.
                  Очень длинные имена, возможно, захотят скопипастить голосом (или руками – пока целы) в виде исключения.
                  А так – для массового выборочной переноса (класс найден в документации)
                  — Обработка класса //Класс считывается в документации и анализируется
                  — Операция перенос членов в проект списком начать //Члены поочерёдно выбираются в классе из документации
                  — Да //для переноса
                  — Не //для пропуска
                  — Завершить
                  Лукавлю я тут, конечно, ведь описание документации может не быть совместимым с ЯП проекта (хотя продвинутые AI-ассистенты в будущем наверняка научатся читать структуру классов на (условно) любых ЯП).

                  Да не набирает программист за день столько кода, чтобы была необходимость расслаблять руки

                  Код, документация, дерганье рук туда-сюда. У меня бывает и устают. Говорят с возрастом это становится актуальнее. Но даже если не устали руки – бывает желание просто откинуться немного назад и потрындеть с компом (а не с колегой) – и на пользу дела

                  Зачем сложный? Как Вы предлагаете озвучить следующие три простых строки (с сохранением регистра символов)? Обратите внимание, что recPath и recFile не распознаются как слова. И как быть с сокращениями? Посимвольно озвучивать?


                  string recPath = @"d:\Temp"; // TODO: Get record file path
                  string recFile = "TESTRecordABC.dat"; // TODO: Get record file name
                  string header = $@"[{DateTime.Now:HH:mm:ss.fff}] {recPath}\{recFile}";


                  Во-первых голосовой набор против регистра символов! Это никак не совместимо! Увы! Это самое слабое место. Поэтому – в идеале адаптированные языки программирования должны быть регистронезависимыми. И я всегда был против регистрозависимости. Но остаются текстовые строки. Если это пути к данным – то тут тот же совет – никакой регистрозавимости(!) тиха линуксойды и маковды – ТИХО(!) не бузим! Но если без этого никак (увы) – то со строками на помощь прёт и AI-ассистент — который будет выявлять строки типа «d:\temp» и заменять их на «d:\Temp» – потому что так как-минимум красивее. Либо, просто готовые команды – как «Ввести путь к файлу» — и будет задан особый режим ввода. Да и на крайняя всегда можно сказать «С большой» — и следующее слово начнётся с большой буквы – ну на смартфонных клавиатурах выкрутились – и тут выкрутиться можно.
                  Во-вторых, не вижу проблем с «recPath» и «recFile» — ну произнесите их голосом «рек пас соединить слова» и «рек фаил соединить слова» — а со временем AI сам адаптируется. Хотя я думаю, что голосом Вы бы набрали «рекорд пас» и «рекорд файл» без сокращений. Да и думаю если в уже выбранном режиме обвяленные переменной сказать «рек файл», то AI разберётся – что это составное слово идентификатора переменной.
                  Один нюанс – «рек» скорее всего будет распознан как «rek» (хотя можно натренировать на «рес») – ну можно сказать тогда «рец» — уже зная об этом – оставлю ниже этот нюанс в стороне.
                  В-третьих, сокращения набираются как слышатся – позже либо AI адаптируется – либо Вы просто выберите другие сокращения.

                  В-четвётых, вводить сложные неразговорные тексты голосом бесспорно сложно – тут я не спорю. Но какую часть программирования занимает такой ввод*?

                  Итого голосовые команды (для синтаксиса данного ЯП, хотя он не особо дружественен)
                  — перем
                  — типа строка //хотя тип можно было бы и вывести
                  — рек пас
                  — присв
                  — ввод путь к файлу начать
                  — диск дэ слэш тэмп
                  — ввод путь к файлу конец
                  — туду
                  — гэт рекорд файл пас
                  — завершить
                  — перем
                  — типа строка
                  — рек фаил
                  — равно
                  — ввод текста начать
                  — прописными
                  — тэст
                  — с заглавной
                  — рекорд
                  — строчными по буквам
                  — а бэ цэ
                  — ввод текста конец
                  — туду
                  — гэт рекорд файл нэйм
                  — перем
                  — типа строка
                  — хедэр
                  — присв
                  — ввод формат строки начать
                  — в ка скобках
                  — снипет фэдэвэ //тут сниппет поможет для вставки форматированной даты
                  — нар //вышли из скобок наружу
                  — пробел
                  — перем
                  — рек пас
                  — слэш
                  — перем
                  — рек фаил
                  — ввод формат строки конец
                  Не знаю, что быстрее – будет набить указанный Вами текст руками или продиктовать. Наверное набить на клаве. Но это особенность голосового ввода неразговорных строк текста – с ними да, всё кисло. Особенно когда нужен изощрённый формат
              0
              Не жизнеспособно. Разработчик не сидит все время печатая текст кода, он постоянно взаимодействует с IDE, использует горячие клавиши (тоже автодополнение), постоянно куда-то переключается, перепрыгивает в другое окно чтобы подглядеть как что-то реализовано.
                0
                А что, голосом управлять IDE нельзя что-ли? Как я выше заметил — это даже проще реализуемо и удобнее, чем горячие клавиши или дёрганье мышки туда-сюда — но нужно привыкание, конечно. Переключаться, скажем, между окнами (и закладками) можно присваивая имена и номера — и потом просто говоря «перейт'и к' пр'имеру» или «показат' окно номер три, или „иди к' переменным“, даже порой проще — если слово уникально „техзадание“ — и отобразится окно техзадания. Часто это проще — чем рыться в открытых окнах, да ещё и мышкой (когда только что активно набира текст и сразу после перехода продолжишь набирать). А ведь некоторые из вышеназванных команд ещё и по-разному могут работать — одни будут показывать и активизировать окно, другие только показывать, сохраняя старый фокус ввода — на всё про всё коротких горячих калишь не напасёшься — а слова выучить проще.

                Добавлю ещё — что и при работе с текстом можно применять разные голосовые короткие команды пусть и для элементарных действий (но они могут быть и не элементарными) — но сильно сокращая затраты времени. Например, находясь в контексте какого-то метода какого-то класса можно сказать „добав' функцыю расчитат' маршрут“ — и тут же произойдёт переход в контекст определения этого класса и будет создана новая функция с заданным именем. А закончим с ней работу сказать „верн'ис' назад“ — и тут же произойдёт обратный переход в исходную точку-функция (и никаких закладок). Далее можно сказать „вызвать последнюю“ — и будет вставлен вызов последней функцию с обязательными аргументами в именованной форме (это даже проще, чем набирать её имя — даже если оно короткое, просто тут думать ни о чём не надо — быстрые заученные фразу в ходу — как голосовые горячие клавиши, но проще). Это всё можно было бы и макросами на горячих клавишах настроить (если IDE позволит такие финты), но — мало кто это сделает (это сложно, а при голосовом управление такие вещи будут „из коробки“), да и горячие клавиши запоминать придётся — да и вообще — в другом месте в другой IDE их не будет (кастомщина же) — так что мало кто этим будет заморачиваться.
                И это я простой пример привёл. Если подумать — можно и более сложный пример придумать — с большим числом действий и с более сложным позиционированием в коде, выполняемым несколькими голосовыми командами за 5 секунд или менее
                  0
                  дело не в «жизнеспособно или нет»
                  дело в том, что для некоторых — это единственный возможный для них способ писать код. У них выбор не между «писать код постоянно куда-то переключаясь» и «диктовать код медленно и печально», у них выбор между «не написать ни одной строчки кода» и «диктовать код медленно и печально»…
                    0
                    Зачем «диктовать код медленно и печально», когда систему голосового управления можно было бы развить до «управлять кодом быстро и эффективно». Понятно, что сейчас это всё создаётся для людей с ограниченными возможностями — и для них это здорово, и ничего против не имею. Но Конечно, же, все программисты сразу же начинают примерять новые фишки «на себя», а некоторые ещё и пытаются заглянуть в будущее и уловить ещё призрачный далёкий тренд — ведь именно из таких обсуждений и рождается это будущее
                      0
                      Никто с этим не спорит, и голосовой ввод должен развиваться, чтобы дать возможность таким людям полноценно программировать. Но в статье и в некоторых комментариях речь идет не об альтернативном варианте для людей с физическими проблемами, а о замене ввода с клавиатуры на голосовой в целом, мол это будет быстрее.
                        0
                        И я о том, что это может развиться до замены — но не скоро. А как подспорье для работы с клавиатуры — голосовое управление вполне скоро уже могло бы помогать
                    0
                    Голосовое написание очень хорошо можно положить на функциональное программирование. Обычные циклы/процедуры голосом описывать — только мучатся, а придумывать функции по мере надобности и надиктовывать их вполне вариант.
                      0
                      Циклы голосом не сложно диктовать — в чём могут быть затруднения? Наоборот по циклам и всяким прочим ветвлениям очень удобно делать голосовую навигацию, сворачивать/разворачивать блоки и т.д.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое