Тогда будем гнать сразу на более перспективную планету — что там есть в меню — Венера, Европа, Титан (Марс к тому моменту тоже может успеть завершиться)
Да, надо начинать с малого:
— Построить космический лифт
— Разработать наноботов: майнеров и сборщиков
— По частям (доставляя с Земли) собрать на орбите приёмную станцию
— Там же на орбите собрать станцию для отправки на луну
— На луне начать добычу природных ископаемых
— Построить на орбите луны приёмно-передаточную станцию и космический лифт
— Собрать на орбите луны более серьёзный промышленный комплекс для добычи и утилизации ископаемых в космосе
— Отправить его к астероиду
— Начать добычу
— Начать постройку на орбите астероида полуфабрикатов а затем готовых изделий
— Начать транспортировку
— Построить на орбите астероида ещё более продвинутую космическую станцию
— Строить дальше и лучше
Но каждый этап это где-то лет по 25-50 будет занимать (в масштабах XXII века, и явно не текущего) + время на космические полёты надо учесть (в среднем по 50 лет надо на каждый этап заложить для итогового подсчёта — то есть к XXIX веку уложимся — хотя, конечно, прогресс будет более быстрым (чтобы подсократить через сотню другую лет продолжительность реализации этапов) но насколько — не знаю).
Другой вопрос — а что делать с таким количеством железа и никеля — ведь там особо-то больше ничего нет — ведь для постройки полезных вещей нужны и другие материалы — причём сейчас органика (нефть) даже больше востребована, чем железо. А в будущем вероятно и другая органика
Циклы голосом не сложно диктовать — в чём могут быть затруднения? Наоборот по циклам и всяким прочим ветвлениям очень удобно делать голосовую навигацию, сворачивать/разворачивать блоки и т.д.
И я о том, что это может развиться до замены — но не скоро. А как подспорье для работы с клавиатуры — голосовое управление вполне скоро уже могло бы помогать
Любой хоткей, даже составной, вроде 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 их не будет (кастомщина же) — так что мало кто этим будет заморачиваться.
И это я простой пример привёл. Если подумать — можно и более сложный пример придумать — с большим числом действий и с более сложным позиционированием в коде, выполняемым несколькими голосовыми командами за 5 секунд или менее
Если Вы прочитали мои комментарии выше — а там написано как я себе представляю голосовой ввод — то Вам было должно быть понятно — что я как раз описал вариант, когда голосовой ввод это не столько ввод текста, сктолько отдача целеуказаний IDE и AI-Ассистенту — которые и будут выполнять основную когенерацию, анализ и изменение текста алгоритмов и определений. И жда, все горячие клавиши (и тем более инструменты без них) — так вообще пековые в очереди на привязку к голосовому управлению (поначалу, конечно длинные комбинации, а потом и одноклавишные подтянутся).
И про синтаксис я тоже там написал — что его нужно упрощать и адаптировать в новых ЯП, создаваемых специально с прицелом на голосовой ввод + последующая контекстная обработка искусственным интеллектом с когенерацией уже кода в терминах машинных инструкций (я не про низкий уровень, я про код уровня Java или или C# или C++ или Python, или, скажем, Q#).
И про сниппеты и гисты я написал — что ими голосом управлять будет проще, чем вызывать горячими клавишами и делать не голосовой поиск
У голосового программирования есть будущее — но не близкое.
И ещё — это хороший вариант, не только для ограниченных физически людей, а просто для расслабления после ручного кодирования.
Приведите, пожалуйста сложный пример, который голосом будет дольше набираться?
А почему до сих пор не осваивают технологию сборки аппарата (для дальних следований) прямо на орбите (как собирали МКС, только уже в почти четверть XXI века минула — новые материалы и новые технологии же, которые как раз развить нужно) — ведь это не что-то трансцендентное, зато какой профит — можно выводить модули по частям относительно небольшими ракетами. Или им для этого шаттлы нужны — чтобы сборкой с применением космонавтов с выходом в открытый космос заниматься?
Да, на Эплах ещё в конец 70-х (если не ошибаюсь) были окна — если Вы о них.
Но именно Windows 95 сделал их массовыми (а до него ещё был Windows 1.0… 3.11) и удобными настолько, что за 25 лет по сути в оконной системе ничего толком не изменилось — и даже Linux всеми силами старается её воспроизводить так как она была представлена в Windows 95 (про Unix Solaris ничего сказать не могу — но окна и там есть). А вместе с окнами в массы пошло и визуальное программирование (как минимум оконного интерфейса, и как отдельная ветвь — возникло визуальное кодирование (хоть и не ставшее мейнстримом), даже раньше, чем появились модные UML диаграммы)
Вот именно об этом я написал. Но, тем не менее — такой вариант ввода вполне возможен в будущем, и возможно, вполне эффективен — тем более, что много операций при программировании по факту не связаны с вводом текста — а это в лучшем случае горячие клавиши и последующие манипуляции на клавиатуре без прямого потока текста, либо щёлканья мышкой с постоянными переключениями на клавиатуру и на мышь — а это всё очень медленно и энергозатратно. Вот отсюда должны расти ноги голосового управлении и лишь затем — ввод длинных программных текстов.
Добавлю ещё то, что со временем (наверное уже не ранее XXII века) голосовой ввод вполне может перейти ввод силой мысли — но там свои нюансы, зато в идеале у натренированных программистов(+ натренированный AI-ассистент) — скорость ввода может стать на порядок выше — чем сейчас (при рядовом размеренном программировании, а не на скорость), при незначительно (а то и вовсе без) снижении первичного качества (надёжно повышаемого, условно, на «втором» проходе). Но тут свои нюансы, проблемы и недостатки, конечно, обсуждать которые ещё очень и очень рано. Зато энергозатраты будут куда ниже, чем при печатанье на клавиатуре
Я вроде бы не ругал — наоборот — я написал, что для убогих — сгодится (хотя трудно мне предположить сколько кода они так натрендят, но, Стивен Хокинг же вполне себе мог много натрендеть хоть и не кода, а научного текста — это ещё когда он говорить мог, а голосовое распознавание тогда ещё было куда более ущербным — эх… где ты «Горыныч» и «Говорящая мышь»).
А для остальных — тоже весьма подробно изложил своё виденье того, какие проблемы есть (не освещённые в статье), и как голосовое кодирование программ может развиваться — и обозначил временнЫе перспективы — я не ставлю на этом крест — но и в то, что сейчас тут в статье продемонстрировано, я не верю — пока это бред — будущее есть — но оно отдалённое.
Кстати, вон, более 30 лет назад говорили о радужных перспективах ЯП 4-го поколения — с графическим управлением — где вообще не нужно писать код текстом (изначально так, потом ослабили — писать можно — но гораздо меньше и восприниматься результат графически будет лучше) — даже появились Двухмерные языки (например советский ДРАКОН — на нём даже программу для Бурана писали) и даже многомерные языки (4DL). Но практически все они канули в лету, не то, чтобы стали хоть как-то популярны — а вообще ничем не стали.
Правда сейчас понятие 4-го поколения языков программирования стало очень размытым — к нему стали относить не столько графические языки — сколько обычные ЯП прикладного уровня — ограниченно ориентированные на выполнение прикладных задач. Например, продвинутые диалекты языка SQL больших СУБД можно отнести к языкам 4-го поколения. Или некоторые языки баз noSQL, или, скажем RegEX.
Не всё что воспринимается в штыки — потом так и остаётся в стороне — но что-то остаётся! А что-то уж очень сильно видоизменяется. Именно об этом я и пишу — ЯП и IDE нынешнем виде крайне плохо приспособлены к речевому вводу. А программисты пока ещё тоже не умеют эффективно этим пользоваться. Но со временем — ситуация изменится. И я написал в каких направлениях нужно двигаться для этого
Всем куда-то надо. Марс — оказался уже не интересным. Луна — была под негласным запретом, но, вот, снова вроде бы можно и туда. Но Америке пока срочно понадобилось на Европу. А России срочно приспичило на Венеру. Но история Фобос-Грунта ещё свежа в памяти, а лэндроверны продолжают успешно бороздить красную планету…
— Построить космический лифт
— Разработать наноботов: майнеров и сборщиков
— По частям (доставляя с Земли) собрать на орбите приёмную станцию
— Там же на орбите собрать станцию для отправки на луну
— На луне начать добычу природных ископаемых
— Построить на орбите луны приёмно-передаточную станцию и космический лифт
— Собрать на орбите луны более серьёзный промышленный комплекс для добычи и утилизации ископаемых в космосе
— Отправить его к астероиду
— Начать добычу
— Начать постройку на орбите астероида полуфабрикатов а затем готовых изделий
— Начать транспортировку
— Построить на орбите астероида ещё более продвинутую космическую станцию
— Строить дальше и лучше
Но каждый этап это где-то лет по 25-50 будет занимать (в масштабах XXII века, и явно не текущего) + время на космические полёты надо учесть (в среднем по 50 лет надо на каждый этап заложить для итогового подсчёта — то есть к XXIX веку уложимся — хотя, конечно, прогресс будет более быстрым (чтобы подсократить через сотню другую лет продолжительность реализации этапов) но насколько — не знаю).
Другой вопрос — а что делать с таким количеством железа и никеля — ведь там особо-то больше ничего нет — ведь для постройки полезных вещей нужны и другие материалы — причём сейчас органика (нефть) даже больше востребована, чем железо. А в будущем вероятно и другая органика
Не знаю как другие — лично я, терпеть не могу составные хоткеи — где нужно последовательно наживать клавиши, так же не любою хоткеи где есть пара «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 вместе взятых! Но ЯП пока только в разработке лексики, обсуждать его не буду.
И тем не менее, говоря о простоте языка – я, всё-таки, в данном контексте, имел в виду именно изначальную его адаптивность к голосовому набору – его синтаксис должен быть к этому предрасположен – поменьше ключевых слов и трудно/длинно произносимых слов. Попроще конструкции.
Возможно Ваш пример не полон. Ибо в постановке речь шла о создании целого класса, а Вы создали одно поле. Но даже на него, я не уверен, что Вы затратите не более 2-х секунд – разве что уже всё будет найдено и выделено, а может и скопировано в буфер. В идеале голосовые команды следующие (опускаю — что слово «документация» уже связано с нужным источником документации в проекте:
— Найди в документации класс такойто
— Экспортируй в проект
— Операция удаление членов начать
— <перечисление членов к удалению>
— Применить операцию удаления
<или>
— Операция удаление членов от обратного начать
— <перечисление членов, которые нужно оставить>
— Применить операцию удаления
Заодно и описания свойств из документации вставятся
Но если нужно в готовый класс перенести один член из документаци – то кто мешает сделать голосом тоже самое (считаем что всё уже спозиционировано – т.к. этот процесс Вы не описываете):
— Слово в буфер //Копирование в текущей позиции слова из документации, в фокусе
— Вернуться //Возвращение в точку проекта
— Снипет пис //адаптивное распознрвание голоса со временем поймёт – что это ps
— Вствить из буфера
Или так (активно окно проекта, уже ранее документация подключена к словарю голосового анализатора) – думаю даже более популярный вариант
— Снипет пис
— <говорите имя свойства> //с вероятностью близкой к 100% оно удачно распознается – учитывая подключенный текст документации, на крайняк, гворите «нет» -и будет предложен другой вариант – тут уже почти 100% попадание будет. Ну или «взад» и повторяете имя чётче
По времени, конечно будет больше 2-х секунд, но не на много. Но я по-прежнему думаю, у Вас это займёт больше 2 сек – особенно, когда нужно будет переносить не одно свойство, а несколько членов – мышкой просто дольше ёрзать будете, чем 2 сек на член.
Хотя на моём бы языке было бы вот так (предыдущий вариант) для одного свойства (для массового ввода чуть попроще):
— деф
— <говорите имя свойства>
— Строка
Просто я за паблик свойства по умолчанию ;-) Думаю в 2 сек уложиться можно даже с длинными именами свойств
А последующие свойства, отличающиеся только именами можно было бы так вводить
— ещё
— <говорите имя свойства>
— ещё
— <говорите имя свойства>
— ещё
— <говорите имя свойства> Число //Поменяли тип на число
Думаю тут и 1.5 сек можно уложиться.
Уверен, что большинство программистов предпочтут проговаривать имена свойств (если они будут хорошо распознаваться), ну или массово переносить всё.
Очень длинные имена, возможно, захотят скопипастить голосом (или руками – пока целы) в виде исключения.
А так – для массового выборочной переноса (класс найден в документации)
— Обработка класса //Класс считывается в документации и анализируется
— Операция перенос членов в проект списком начать //Члены поочерёдно выбираются в классе из документации
— Да //для переноса
— Не //для пропуска
— Завершить
Лукавлю я тут, конечно, ведь описание документации может не быть совместимым с ЯП проекта (хотя продвинутые AI-ассистенты в будущем наверняка научатся читать структуру классов на (условно) любых ЯП).
Код, документация, дерганье рук туда-сюда. У меня бывает и устают. Говорят с возрастом это становится актуальнее. Но даже если не устали руки – бывает желание просто откинуться немного назад и потрындеть с компом (а не с колегой) – и на пользу дела
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 их не будет (кастомщина же) — так что мало кто этим будет заморачиваться.
И это я простой пример привёл. Если подумать — можно и более сложный пример придумать — с большим числом действий и с более сложным позиционированием в коде, выполняемым несколькими голосовыми командами за 5 секунд или менее
И про синтаксис я тоже там написал — что его нужно упрощать и адаптировать в новых ЯП, создаваемых специально с прицелом на голосовой ввод + последующая контекстная обработка искусственным интеллектом с когенерацией уже кода в терминах машинных инструкций (я не про низкий уровень, я про код уровня Java или или C# или C++ или Python, или, скажем, Q#).
И про сниппеты и гисты я написал — что ими голосом управлять будет проще, чем вызывать горячими клавишами и делать не голосовой поиск
У голосового программирования есть будущее — но не близкое.
И ещё — это хороший вариант, не только для ограниченных физически людей, а просто для расслабления после ручного кодирования.
Приведите, пожалуйста сложный пример, который голосом будет дольше набираться?
Но именно Windows 95 сделал их массовыми (а до него ещё был Windows 1.0… 3.11) и удобными настолько, что за 25 лет по сути в оконной системе ничего толком не изменилось — и даже Linux всеми силами старается её воспроизводить так как она была представлена в Windows 95 (про Unix Solaris ничего сказать не могу — но окна и там есть). А вместе с окнами в массы пошло и визуальное программирование (как минимум оконного интерфейса, и как отдельная ветвь — возникло визуальное кодирование (хоть и не ставшее мейнстримом), даже раньше, чем появились модные UML диаграммы)
Добавлю ещё то, что со временем (наверное уже не ранее XXII века) голосовой ввод вполне может перейти ввод силой мысли — но там свои нюансы, зато в идеале у натренированных программистов(+ натренированный AI-ассистент) — скорость ввода может стать на порядок выше — чем сейчас (при рядовом размеренном программировании, а не на скорость), при незначительно (а то и вовсе без) снижении первичного качества (надёжно повышаемого, условно, на «втором» проходе). Но тут свои нюансы, проблемы и недостатки, конечно, обсуждать которые ещё очень и очень рано. Зато энергозатраты будут куда ниже, чем при печатанье на клавиатуре
А для остальных — тоже весьма подробно изложил своё виденье того, какие проблемы есть (не освещённые в статье), и как голосовое кодирование программ может развиваться — и обозначил временнЫе перспективы — я не ставлю на этом крест — но и в то, что сейчас тут в статье продемонстрировано, я не верю — пока это бред — будущее есть — но оно отдалённое.
Кстати, вон, более 30 лет назад говорили о радужных перспективах ЯП 4-го поколения — с графическим управлением — где вообще не нужно писать код текстом (изначально так, потом ослабили — писать можно — но гораздо меньше и восприниматься результат графически будет лучше) — даже появились Двухмерные языки (например советский ДРАКОН — на нём даже программу для Бурана писали) и даже многомерные языки (4DL). Но практически все они канули в лету, не то, чтобы стали хоть как-то популярны — а вообще ничем не стали.
Правда сейчас понятие 4-го поколения языков программирования стало очень размытым — к нему стали относить не столько графические языки — сколько обычные ЯП прикладного уровня — ограниченно ориентированные на выполнение прикладных задач. Например, продвинутые диалекты языка SQL больших СУБД можно отнести к языкам 4-го поколения. Или некоторые языки баз noSQL, или, скажем RegEX.
Не всё что воспринимается в штыки — потом так и остаётся в стороне — но что-то остаётся! А что-то уж очень сильно видоизменяется. Именно об этом я и пишу — ЯП и IDE нынешнем виде крайне плохо приспособлены к речевому вводу. А программисты пока ещё тоже не умеют эффективно этим пользоваться. Но со временем — ситуация изменится. И я написал в каких направлениях нужно двигаться для этого