Comments 25
По-моему это пока полная хрень. Очень неудобно. Некоторые короткие и популярные термы так вообще голосом гораздо труднее выговаривать. Да и чёткость распознания в ряде случае будет хромать. Придётся многократно исправлять. А если ещё и акцент будет… Не — ну для тех, у кого есть физические ограничения — это бесспорно да — хорошее решение — но именно в таком ключе не хотелось бы, чтобы это было мейнстримом. А для обычного программирования — получается очень медленно, и с очень большим количеством 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!
Но… я не исключаю, что в более отдалённом будущем — это станет мейнстримом (но вряд ли даже относительно скоро мейнстримом у профессионалов). Современные языки программирования просто не созданы для этого. Да что там языки программирования — сейчас ввод текста то со слов часто ошибается (так что длинные тексты писать голосом почти невозможно). Даже на английском — где наработано очень много. А ведь есть такие языки, как скажем, китайский — там вообще голосом очень сложно вводить текст (а программирование на английском языке не на много проще) — ну не создавались языки для этого.
Ещё добавлю, что крайне редко (тем более серьёзный алгоритм) набирается линейно — слово за словом, команда за командой. Программисты бегают по коду туда-сюда и постоянно его модифицируют. И пока делать это голосом очень и очень сложно!
Но, в будущем возможно ситуация изменится за счёт:
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!
Я вспоминаю старые публикации, когда только появился Windows, его ругали и говорили профессионалы, что графический интерфейс не нужен. Но, это удобство. И новое поколение людей, которе будут писать код сразу таким способом уже не сядут за клавиатуру (не буквально, конечно). Так что ругать такой подход не стоит.
Я вроде бы не ругал — наоборот — я написал, что для убогих — сгодится (хотя трудно мне предположить сколько кода они так натрендят, но, Стивен Хокинг же вполне себе мог много натрендеть хоть и не кода, а научного текста — это ещё когда он говорить мог, а голосовое распознавание тогда ещё было куда более ущербным — эх… где ты «Горыныч» и «Говорящая мышь»).
А для остальных — тоже весьма подробно изложил своё виденье того, какие проблемы есть (не освещённые в статье), и как голосовое кодирование программ может развиваться — и обозначил временнЫе перспективы — я не ставлю на этом крест — но и в то, что сейчас тут в статье продемонстрировано, я не верю — пока это бред — будущее есть — но оно отдалённое.
Кстати, вон, более 30 лет назад говорили о радужных перспективах ЯП 4-го поколения — с графическим управлением — где вообще не нужно писать код текстом (изначально так, потом ослабили — писать можно — но гораздо меньше и восприниматься результат графически будет лучше) — даже появились Двухмерные языки (например советский ДРАКОН — на нём даже программу для Бурана писали) и даже многомерные языки (4DL). Но практически все они канули в лету, не то, чтобы стали хоть как-то популярны — а вообще ничем не стали.
Правда сейчас понятие 4-го поколения языков программирования стало очень размытым — к нему стали относить не столько графические языки — сколько обычные ЯП прикладного уровня — ограниченно ориентированные на выполнение прикладных задач. Например, продвинутые диалекты языка SQL больших СУБД можно отнести к языкам 4-го поколения. Или некоторые языки баз noSQL, или, скажем RegEX.
Не всё что воспринимается в штыки — потом так и остаётся в стороне — но что-то остаётся! А что-то уж очень сильно видоизменяется. Именно об этом я и пишу — ЯП и IDE нынешнем виде крайне плохо приспособлены к речевому вводу. А программисты пока ещё тоже не умеют эффективно этим пользоваться. Но со временем — ситуация изменится. И я написал в каких направлениях нужно двигаться для этого
А для остальных — тоже весьма подробно изложил своё виденье того, какие проблемы есть (не освещённые в статье), и как голосовое кодирование программ может развиваться — и обозначил временнЫе перспективы — я не ставлю на этом крест — но и в то, что сейчас тут в статье продемонстрировано, я не верю — пока это бред — будущее есть — но оно отдалённое.
Кстати, вон, более 30 лет назад говорили о радужных перспективах ЯП 4-го поколения — с графическим управлением — где вообще не нужно писать код текстом (изначально так, потом ослабили — писать можно — но гораздо меньше и восприниматься результат графически будет лучше) — даже появились Двухмерные языки (например советский ДРАКОН — на нём даже программу для Бурана писали) и даже многомерные языки (4DL). Но практически все они канули в лету, не то, чтобы стали хоть как-то популярны — а вообще ничем не стали.
Правда сейчас понятие 4-го поколения языков программирования стало очень размытым — к нему стали относить не столько графические языки — сколько обычные ЯП прикладного уровня — ограниченно ориентированные на выполнение прикладных задач. Например, продвинутые диалекты языка SQL больших СУБД можно отнести к языкам 4-го поколения. Или некоторые языки баз noSQL, или, скажем RegEX.
Не всё что воспринимается в штыки — потом так и остаётся в стороне — но что-то остаётся! А что-то уж очень сильно видоизменяется. Именно об этом я и пишу — ЯП и IDE нынешнем виде крайне плохо приспособлены к речевому вводу. А программисты пока ещё тоже не умеют эффективно этим пользоваться. Но со временем — ситуация изменится. И я написал в каких направлениях нужно двигаться для этого
Графический интерфейс появился до Windows
Да, на Эплах ещё в конец 70-х (если не ошибаюсь) были окна — если Вы о них.
Но именно Windows 95 сделал их массовыми (а до него ещё был Windows 1.0… 3.11) и удобными настолько, что за 25 лет по сути в оконной системе ничего толком не изменилось — и даже Linux всеми силами старается её воспроизводить так как она была представлена в Windows 95 (про Unix Solaris ничего сказать не могу — но окна и там есть). А вместе с окнами в массы пошло и визуальное программирование (как минимум оконного интерфейса, и как отдельная ветвь — возникло визуальное кодирование (хоть и не ставшее мейнстримом), даже раньше, чем появились модные UML диаграммы)
Но именно Windows 95 сделал их массовыми (а до него ещё был Windows 1.0… 3.11) и удобными настолько, что за 25 лет по сути в оконной системе ничего толком не изменилось — и даже Linux всеми силами старается её воспроизводить так как она была представлена в Windows 95 (про Unix Solaris ничего сказать не могу — но окна и там есть). А вместе с окнами в массы пошло и визуальное программирование (как минимум оконного интерфейса, и как отдельная ветвь — возникло визуальное кодирование (хоть и не ставшее мейнстримом), даже раньше, чем появились модные UML диаграммы)
Графический интерфейс хорош, когда надо сделать делать какое то действие пару раз и забыть об этом. То, что приходится делать регулярно и по многу раз удобнее делать без ГУИ, консольными командами. Но подавляющее большинство Windows пользователей об этом не знают и продолжают тыкать мышкой одни и те же последовательности нажатий кнопок в ГУИ изо дня в день, долгими годами и даже десятилетиями.
Графический интерфейс обычно удобнее большинству — он лучше воспринимается — он более естественен чем консольный ввод. Но да — некоторые люди в силу разных причин осваивают консольный ввод — и это действительно может ускорять процесс. Но освоение — это процесс глубокого обучения командам — он априори ограничен. А грамотный графический интерфейс — априори широко понятен без длинного вникания — позволяет управлять всем почти без предварительного освоения. Но не хочу превращать эту тему в холивор на тему что лучше гуи или консоль — тут каждому своё. Замечу, что все консоли нынче в окнах — и часто работают сразу с несколькими окнами — в досе с этим были бы сложности
И, кстати, в рамках сабжа статьи. Сделать голосовое управление для консольного ввода несколько проще, чем для грамотного графического интерфейса, и чем хуже проработан графический интерфейс, тем больше будет выигрывать голосовой ввод на консоль, для которой проработка синтаксиса, хоть и важна, но совсем не так сильно, как графического интерфейса — для голосового ввода. Так что консоль — это, конечно сила, и, вероятно, в будущем первичной будет консоль, а к ней уже будет прокручивать гуи и звуковое управление — основанное на консольных командах
Добавлю, что были ссылки на исследование (которому лет 20 уже), что голосом набирать текст на порядок более энергозатратно, чем на клавиатуре. Об этом вам любой лектор может рассказать. Но в целом идея интересная и со всеми пунктами вашего комментария согласен.
Вот именно об этом я написал. Но, тем не менее — такой вариант ввода вполне возможен в будущем, и возможно, вполне эффективен — тем более, что много операций при программировании по факту не связаны с вводом текста — а это в лучшем случае горячие клавиши и последующие манипуляции на клавиатуре без прямого потока текста, либо щёлканья мышкой с постоянными переключениями на клавиатуру и на мышь — а это всё очень медленно и энергозатратно. Вот отсюда должны расти ноги голосового управлении и лишь затем — ввод длинных программных текстов.
Добавлю ещё то, что со временем (наверное уже не ранее XXII века) голосовой ввод вполне может перейти ввод силой мысли — но там свои нюансы, зато в идеале у натренированных программистов(+ натренированный AI-ассистент) — скорость ввода может стать на порядок выше — чем сейчас (при рядовом размеренном программировании, а не на скорость), при незначительно (а то и вовсе без) снижении первичного качества (надёжно повышаемого, условно, на «втором» проходе). Но тут свои нюансы, проблемы и недостатки, конечно, обсуждать которые ещё очень и очень рано. Зато энергозатраты будут куда ниже, чем при печатанье на клавиатуре
Добавлю ещё то, что со временем (наверное уже не ранее XXII века) голосовой ввод вполне может перейти ввод силой мысли — но там свои нюансы, зато в идеале у натренированных программистов(+ натренированный AI-ассистент) — скорость ввода может стать на порядок выше — чем сейчас (при рядовом размеренном программировании, а не на скорость), при незначительно (а то и вовсе без) снижении первичного качества (надёжно повышаемого, условно, на «втором» проходе). Но тут свои нюансы, проблемы и недостатки, конечно, обсуждать которые ещё очень и очень рано. Зато энергозатраты будут куда ниже, чем при печатанье на клавиатуре
На мой взгляд, тема не особо актуальна и имеет скорее академический интерес, чем практический. Основные причины:
— набор кода в программировании — далеко не самый затратный по времени процесс и голосовой ввод не приведет к заметному выигрышу по времени в целом;
— голосовой ввод может выглядеть привлекательно в плане ускорения для простых конструкций языка уровня «hello world», а вот для более-менее сложных эффект может быть противоположным;
— синтаксис современных языков программирования довольно сложен, чтобы описывать его голосом и при этом еще и выигрывать по времени;
— хоткеи, интеллектуальные помощники и сниппеты кода в современных IDE в большинстве случаев позволяют писать код на порядок быстрее чем вы расскажете компьютеру что вы от него хотите
— набор кода в программировании — далеко не самый затратный по времени процесс и голосовой ввод не приведет к заметному выигрышу по времени в целом;
— голосовой ввод может выглядеть привлекательно в плане ускорения для простых конструкций языка уровня «hello world», а вот для более-менее сложных эффект может быть противоположным;
— синтаксис современных языков программирования довольно сложен, чтобы описывать его голосом и при этом еще и выигрывать по времени;
— хоткеи, интеллектуальные помощники и сниппеты кода в современных IDE в большинстве случаев позволяют писать код на порядок быстрее чем вы расскажете компьютеру что вы от него хотите
Если Вы прочитали мои комментарии выше — а там написано как я себе представляю голосовой ввод — то Вам было должно быть понятно — что я как раз описал вариант, когда голосовой ввод это не столько ввод текста, сктолько отдача целеуказаний IDE и AI-Ассистенту — которые и будут выполнять основную когенерацию, анализ и изменение текста алгоритмов и определений. И жда, все горячие клавиши (и тем более инструменты без них) — так вообще пековые в очереди на привязку к голосовому управлению (поначалу, конечно длинные комбинации, а потом и одноклавишные подтянутся).
И про синтаксис я тоже там написал — что его нужно упрощать и адаптировать в новых ЯП, создаваемых специально с прицелом на голосовой ввод + последующая контекстная обработка искусственным интеллектом с когенерацией уже кода в терминах машинных инструкций (я не про низкий уровень, я про код уровня Java или или C# или C++ или Python, или, скажем, Q#).
И про сниппеты и гисты я написал — что ими голосом управлять будет проще, чем вызывать горячими клавишами и делать не голосовой поиск
У голосового программирования есть будущее — но не близкое.
И ещё — это хороший вариант, не только для ограниченных физически людей, а просто для расслабления после ручного кодирования.
Приведите, пожалуйста сложный пример, который голосом будет дольше набираться?
И про синтаксис я тоже там написал — что его нужно упрощать и адаптировать в новых ЯП, создаваемых специально с прицелом на голосовой ввод + последующая контекстная обработка искусственным интеллектом с когенерацией уже кода в терминах машинных инструкций (я не про низкий уровень, я про код уровня Java или или C# или C++ или Python, или, скажем, Q#).
И про сниппеты и гисты я написал — что ими голосом управлять будет проще, чем вызывать горячими клавишами и делать не голосовой поиск
У голосового программирования есть будущее — но не близкое.
И ещё — это хороший вариант, не только для ограниченных физически людей, а просто для расслабления после ручного кодирования.
Приведите, пожалуйста сложный пример, который голосом будет дольше набираться?
И жда, все горячие клавиши (и тем более инструменты без них) — так вообще пековые в очереди на привязку к голосовому управлению (поначалу, конечно длинные комбинации, а потом и одноклавишные подтянутся).Любой хоткей, даже составной, вроде 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}";
Я не против голосового программирования как такового, оно должно развиваться, ибо даст возможность полноценно работать парализованным людям. Но в Вашем виденье оно выступает серебряной пулей и заменой ввода с клавиатуры с голословными утверждениями что это будет быстрее. Мало того, Вы предлагаете подстраивать ЯП под голосовой ввод в ущерб синтаксису.
Любой хоткей, даже составной, вроде 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 адаптируется – либо Вы просто выберите другие сокращения.
В-четвётых, вводить сложные неразговорные тексты голосом бесспорно сложно – тут я не спорю. Но какую часть программирования занимает такой ввод*?
Итого голосовые команды (для синтаксиса данного ЯП, хотя он не особо дружественен)
— перем
— типа строка //хотя тип можно было бы и вывести
— рек пас
— присв
— ввод путь к файлу начать
— диск дэ слэш тэмп
— ввод путь к файлу конец
— туду
— гэт рекорд файл пас
— завершить
— перем
— типа строка
— рек фаил
— равно
— ввод текста начать
— прописными
— тэст
— с заглавной
— рекорд
— строчными по буквам
— а бэ цэ
— ввод текста конец
— туду
— гэт рекорд файл нэйм
— перем
— типа строка
— хедэр
— присв
— ввод формат строки начать
— в ка скобках
— снипет фэдэвэ //тут сниппет поможет для вставки форматированной даты
— нар //вышли из скобок наружу
— пробел
— перем
— рек пас
— слэш
— перем
— рек фаил
— ввод формат строки конец
Не знаю, что быстрее – будет набить указанный Вами текст руками или продиктовать. Наверное набить на клаве. Но это особенность голосового ввода неразговорных строк текста – с ними да, всё кисло. Особенно когда нужен изощрённый формат
Не жизнеспособно. Разработчик не сидит все время печатая текст кода, он постоянно взаимодействует с IDE, использует горячие клавиши (тоже автодополнение), постоянно куда-то переключается, перепрыгивает в другое окно чтобы подглядеть как что-то реализовано.
А что, голосом управлять IDE нельзя что-ли? Как я выше заметил — это даже проще реализуемо и удобнее, чем горячие клавиши или дёрганье мышки туда-сюда — но нужно привыкание, конечно. Переключаться, скажем, между окнами (и закладками) можно присваивая имена и номера — и потом просто говоря «перейт'и к' пр'имеру» или «показат' окно номер три, или „иди к' переменным“, даже порой проще — если слово уникально „техзадание“ — и отобразится окно техзадания. Часто это проще — чем рыться в открытых окнах, да ещё и мышкой (когда только что активно набира текст и сразу после перехода продолжишь набирать). А ведь некоторые из вышеназванных команд ещё и по-разному могут работать — одни будут показывать и активизировать окно, другие только показывать, сохраняя старый фокус ввода — на всё про всё коротких горячих калишь не напасёшься — а слова выучить проще.
Добавлю ещё — что и при работе с текстом можно применять разные голосовые короткие команды пусть и для элементарных действий (но они могут быть и не элементарными) — но сильно сокращая затраты времени. Например, находясь в контексте какого-то метода какого-то класса можно сказать „добав' функцыю расчитат' маршрут“ — и тут же произойдёт переход в контекст определения этого класса и будет создана новая функция с заданным именем. А закончим с ней работу сказать „верн'ис' назад“ — и тут же произойдёт обратный переход в исходную точку-функция (и никаких закладок). Далее можно сказать „вызвать последнюю“ — и будет вставлен вызов последней функцию с обязательными аргументами в именованной форме (это даже проще, чем набирать её имя — даже если оно короткое, просто тут думать ни о чём не надо — быстрые заученные фразу в ходу — как голосовые горячие клавиши, но проще). Это всё можно было бы и макросами на горячих клавишах настроить (если IDE позволит такие финты), но — мало кто это сделает (это сложно, а при голосовом управление такие вещи будут „из коробки“), да и горячие клавиши запоминать придётся — да и вообще — в другом месте в другой IDE их не будет (кастомщина же) — так что мало кто этим будет заморачиваться.
И это я простой пример привёл. Если подумать — можно и более сложный пример придумать — с большим числом действий и с более сложным позиционированием в коде, выполняемым несколькими голосовыми командами за 5 секунд или менее
Добавлю ещё — что и при работе с текстом можно применять разные голосовые короткие команды пусть и для элементарных действий (но они могут быть и не элементарными) — но сильно сокращая затраты времени. Например, находясь в контексте какого-то метода какого-то класса можно сказать „добав' функцыю расчитат' маршрут“ — и тут же произойдёт переход в контекст определения этого класса и будет создана новая функция с заданным именем. А закончим с ней работу сказать „верн'ис' назад“ — и тут же произойдёт обратный переход в исходную точку-функция (и никаких закладок). Далее можно сказать „вызвать последнюю“ — и будет вставлен вызов последней функцию с обязательными аргументами в именованной форме (это даже проще, чем набирать её имя — даже если оно короткое, просто тут думать ни о чём не надо — быстрые заученные фразу в ходу — как голосовые горячие клавиши, но проще). Это всё можно было бы и макросами на горячих клавишах настроить (если IDE позволит такие финты), но — мало кто это сделает (это сложно, а при голосовом управление такие вещи будут „из коробки“), да и горячие клавиши запоминать придётся — да и вообще — в другом месте в другой IDE их не будет (кастомщина же) — так что мало кто этим будет заморачиваться.
И это я простой пример привёл. Если подумать — можно и более сложный пример придумать — с большим числом действий и с более сложным позиционированием в коде, выполняемым несколькими голосовыми командами за 5 секунд или менее
дело не в «жизнеспособно или нет»
дело в том, что для некоторых — это единственный возможный для них способ писать код. У них выбор не между «писать код постоянно куда-то переключаясь» и «диктовать код медленно и печально», у них выбор между «не написать ни одной строчки кода» и «диктовать код медленно и печально»…
дело в том, что для некоторых — это единственный возможный для них способ писать код. У них выбор не между «писать код постоянно куда-то переключаясь» и «диктовать код медленно и печально», у них выбор между «не написать ни одной строчки кода» и «диктовать код медленно и печально»…
Зачем «диктовать код медленно и печально», когда систему голосового управления можно было бы развить до «управлять кодом быстро и эффективно». Понятно, что сейчас это всё создаётся для людей с ограниченными возможностями — и для них это здорово, и ничего против не имею. Но Конечно, же, все программисты сразу же начинают примерять новые фишки «на себя», а некоторые ещё и пытаются заглянуть в будущее и уловить ещё призрачный далёкий тренд — ведь именно из таких обсуждений и рождается это будущее
Никто с этим не спорит, и голосовой ввод должен развиваться, чтобы дать возможность таким людям полноценно программировать. Но в статье и в некоторых комментариях речь идет не об альтернативном варианте для людей с физическими проблемами, а о замене ввода с клавиатуры на голосовой в целом, мол это будет быстрее.
Голосовое написание очень хорошо можно положить на функциональное программирование. Обычные циклы/процедуры голосом описывать — только мучатся, а придумывать функции по мере надобности и надиктовывать их вполне вариант.
Sign up to leave a comment.
Программирование голосом. Передовые рубежи разработки ПО