Комментарии 66
О глупости «программирования на естественном языке»
Это как на этот вопрос посмотреть, с каких позиций и с какого уровня обобщения (абстрагирования).
В самом общем случае, любой язык, используемый в процессе коммуникации и управления, является языком программирования, который задает алгоритм действия объекта управления. При этом сущность объекта управления значения не имеет.
Но, даже если сузить понятие "программирование" до программирования вычислительных машин, то и здесь столь категоричный вывод неоднозначен и сомнителен. Так, как существует мнение, что использование в качестве ключевых слов элементов естественного языка общения, используемого в данном обществе, имеет свои преимущества. Тем более, что использования англоязычных терминов, в качестве ключевых слов, это дань традиции и принципа "кто успел тот и съел".
С точки зрения вывода автора, наиболее "правилен" машинный код. Но мы знаем, что развитие пошло по пути рождения ЯП высокого уровня, т.е. по пути приближения ЯП к языкам человеческого общения.
Вместо того, чтобы кидать демагогическое «существует мнение», вы бы ознакомились с реальной историей языков программирования, однозначно опровергающей ваш тезис о приближении ЯВУ к языкам человеческого общения. Ни один получивший распространение язык программирования не позволяет записать алгоритм текстом, близким по грамматике к языку человеческого общения.
P.S. Среди языков, ставших популярными, самым приближённым к «человеческому общению», является COBOL, но даже в нём текст программы, записываемый английскими словами, не имеет никакого отношения к грамматике английского языка.
вы правы, Turing и Wittgenstein оказали влияние на всех, кроме прочего, если не смотрели, операционная система "THE" очень интересный ранний проект был (1965-66)
Очевидно, вы не поняли смысл статьи. Речь не про то, чтобы не использовать в языках программирования слова «человеческого» языка — об этом в статье ни слова нет. Речь про то, что алгоритм, передаваемый вычислительной системе, должен записываться не посредством текста, созданного по правилам языка человеческого общения, а посредством специально разработанной для этого формальной системы. Именно такими формальными системами являются абсолютно все промышленные языки программирования — независимо от того, какие слова «человеческого» языка они используют в записи своих конструкций.
...
Лично я наблюдаю, что именно Вы не поняли существа моей критики статьи. :)
Если бы Вы знали теорию познания, то Вы бы понимали, что любой язык является формальной системой, вне зависимости от его происхождения и области применения.
Вы явно не понимаете, что все языки существуют и развиваются по единым объективным законам, отражающим процесс познания - от частного к общему.
А, это значит, что развитие любого языка идет в сторону максимизации абстрактности понятий, стоящих за каждым словом (термином), из которых состоит каждый язык.
Этот процесс постоянно идет, как в языках межчеловеческого общения, та к и в языках программирования вычислительных машин. Например в ЯП, это появление и применения процедур, функций, объектов, классов и т.д. и т.п. Т.е. программист начинает оперировать не конкретными состояниями конкретных аппаратных ресурсов, как это происходит при написании программы с использованием машинных кодов, а некими абстракциями, которые отражают и обобщают некое состояние программно-аппаратного комплекса, в целом.
В настоящее время процесс, абстрагирования ЯП и приближения их к языкам человеческого общения, сдерживается множеством факторов, одним из которых является незавершенность стандартизации аппаратных средств.
Но, тенденция, стремления в сторону приближения ЯП к языкам межчеловеческого общения, очевидно просматривается, в развитии теории и практике систем искусственного интеллекта, прикладное программирование которых в будущем явно будет осуществляться на языках межчеловеческого общения.
Высокоуровневые языки недалеко ушли от машинного кода. Реализация одного алгоритьма на разных ЯП приведет к генерации идентичного машинного кода, возможно с некоторвми вариациями/оптимизациями.
А попытка программирования на естественном языке хорошо описан в анекдоте про цыпочку с длинными ногами и влажной киской.
Автор явно указал, какое свойство высокоуровневых языков он считает ценным. Это свойство - невозможность (хотя бы сложность) выразить заведомо неправильные/бессмысленные действия. По этой характеристики ассемблер как раз не далек от естественных языков, только проще в обработке. Многие современные ЯП, такие как питон или джаваскрипт - тоже. Идеальным языком был бы какой-нибудь Idris2.
На мой вкус отличная статья, конечно лучше читать в оригинале, невольно вспоминаются слова John von Neumann о том что наиболее важный вклад который можно ожидать от использования компьютеров это не результаты научных вычислений, а опыт общения с иной формой мышления (по памяти)
Вся статья в одной картинке
Я лично работаю над возможностью писать программы на родном языке вместо специальных компьютерный языков программирования уже несколько лет. И считаю, что это вполне возможно.
Сейчас я вижу, что для успешного разбора алгоритма, т.е. последовательности действий на человеческом языке требуется от системы понимать сложившуюся ситуацию, какие действия что делают и к чему приводят и, вообще, как устроен мир вокруг. Большинство текущих компиляторов и интерпретаторов не понимают ни контекст, ни смысл. А требуют чтоб программист сам указывал всё, что нужно для успешного выполнения каждого действия.
Всё так, нужна модель окружающей реальности и хранение контекста. А ещё их надо регулярно обновлять - например, банально для того, чтобы созданные машиной вещи попали в модель реальности. Значит, идут в лес все подходы на базе долго "обучаемых" нейронок, например.
Далее, даже если хоть что-то получится сделать, неизбежно возникнет вопрос специализации. Чем больше и подробнее модель мира, тем тяжелее её построить и тем медленнее она будет работать. А маленькая модель будет страдать от неточности предсказаний. И возникает сложный выбор: или мы делаем убер-модель реальности (с реальным риском никогда не закончить или получить тормозного монстра), или делаем модель только для части мира (т.е., для домена). И получаем программатор, который умеет в естественный язык, но только если вопрос касается его доменной области. А если вдруг нужна интеграция с соседней - извиняйте. Подождите N времени, тогда что-нибудь слепим.
Да, вобщем-то так оно и вырисовывается сейчас. Я работаю над разборкой и выполнением кулинарных рецептов сейчас. Точнее над рецептом приготовления горохового супа. Но на разных языках: русском, английском, испанском, немецком. И уже много кулинарно-специфических вещей всплыло)
Но я верю, что есть нечто универсальное, базовое во всех сферах, предметных областях или доменах как Вы их называете. И после того, как я это выведу, дальше станет легче.
А что будет делать программа когда встретит в рецепте строку "Посолить по вкусу"?
Очевидно солить по вкусу. Вкус берется в настройках или выводится по предыдущим лайкам конкретного пользователя или обобщенного профиля целевой аудитории. См. как рекомендательные фичи работают.
Рекомендательные фичи и не работают!
Если я вчера поискал коньяк, то сегодня, скорее всего, он мне не нужен - я же вчера уже посмотрел. А сегодня все баннеры мне показывают коньяк...
Смотрите, во-первых, странно видеть утверждение, что что-то не работает на основании одного примера. Это как сказать, что отвертка не работает потому, что она бесполезна, когда надо забить гвоздь. Я могу привести пример, когда рекомендательные сервисы работают. Например навигатор достаточно часто угадывает куда я хочу ехать.
Во-вторых, в самом примере логика достаточно странная. Если я что-от посмотрел вчера оно мне может быть нужно сегодня. Кроме того случая, когда оно потребляется смотрением типа фильма. Коньяк вроде пьют а не смотрят обычно.
В-третьих, любой рандомный товар мне тоже "скорее всего" не нужен. И вопрос - насколько это "скорее всего" больше или меньше чем "скорее всего" у коньяка. Например, я посморел но не выбрал. Или я регулярный покупатель коньяков и он мне нужен будет завтра. Или я регулярный покупатель коньяков и запомню марку до следующего раза. Короче надо сравнивать вероятность успешность продажи у коньяка и у случайной рекламы.
В-четвертых, странно, что все делают рекомендательные сервисы. Вряд ли они все дурачки.
По мне, работа этих сервисов показатель ограниченности пользователей. Если я вчера посмотрел боевик, то сегодня мне, скорее всего, захочется чего-нибудь другого.
Коньяк вроде пьют а не смотрят обычно.
А это в огород естественного языка, даже человек сходу не разобрал.
Я вчера искал, нашел, посмотрел, узнал что хотел.
По мне, работа этих сервисов показатель ограниченности пользователей. Если я вчера посмотрел боевик, то сегодня мне, скорее всего, захочется чего-нибудь другого.
Теперь вернемся к степени солености пищи. Как вы считаете, один и тот же человек предпочитает одну и ту же соленость или разную для одного и того же блюда? У кого больше возможностей учесть предпочтения - у повара, который солит по своему вкусу или у киберповара с загруженным профилем пользователя?
Свалиться с ошибкой: Встречен неизвестный токен "по вкусу"!)))
Шутка конечно.
Если серьёзно, то наверное полезит в специальный справочник, где указано для какой массы, объёма и с какими ингредиентами какое количество соли оптимальное. Потом поищет по истории сколько он клал в последний раз для этого конкретного человека в эти блюдо и какой был отзыв и примет оптимальное решение.
Я уже когда несколько лет назад писал первый алгоритм разбора и выполнения рецепта горохового супа встретил фразу "...откройте крышку и, если необходимо, снимите пенку" и это вызвало ряд глубоких раздумий. А потом ещё встретил "Немного измельчите суп в блендере, кухонном комбайне или воспользуйтесь толкушкой..." что уже было весьма расплывчато и непонятно как выполнять. Сейчас уже конечно я думаю, что специальные справочники помогут это успешно порешать, преодолеть. А так поначалу, это было конечно очень непонятно, что с этим делать)
Есть ли Гитхаб вашего проекта? Посмотреть или покритиковать, или помочь :) любопытно однозначно
Или вот такой подход https://habr.com/ru/company/timeweb/blog/651999/, который, кстати, тоже начинался с разработки языка программирования на естественном языке https://habr.com/ru/post/531400/
А какие причины отказаться от естественного языка были описанного в https://habr.com/ru/post/531400/ ? сложность распознавать языковые конструкции? Получилось хоть какую то идею в виде кода или спецификации оформить?
Да смысл выкладывать. Я уже третий вариант делаю. 1ый так и лежит поломанный на javascript. Второй уже делался частично на php, частично на smalltalk. Третий текущий уже полностью на smalltalk-e. Критиковать там много что есть: код сложный и не оформленный, очень много костылей. Это же наука. Тут главное провести эксперимент, получить результат, ценную информацию, а потом всё это можно выкинуть в мусорку)
Я бы немного покритиковал беапелляционую позицию статьи.
Да, формальные определения алгоритмов нужны, но предположение, что формальным может быть язык только со спец-символами, я бы рассматривал как гипотезу, которая имеет большое эмпирическое подтверждение.
Сразу оговорюсь, даже если будет техническое демо, подтверждающее обратное, и можно будет писать на английском языке программы, то экономические причины переписать все что есть на "английский" не появятся. Никто не будет выбрасвать колоссальные инвестиции. Но это практический аспект, а я бы хотел обсудить для начала только теоретический.
Второе неявное предположение, раз написано на человеческом языке, значит любой сможет писать программы. Если предположить что существует подмножество языка, на котором можно точно описывать алгоритм, то писать на нем смогут все равно только люди со специальной подготовкой. Но читать смогут больше людей, без специальной подготовки. Косвенное подтверждение это законотворчество, юриспруденция и отчасти технические задания. Избыточность в описании процессов, присущая языкам программирования присутсвует, и которая крайне важна для подробного описания алгоритма, в трех примерах присуствует, но в гораздо меньшей форме чем в ЯП.
Одной из причин, как мне кажется, по которым естественные языки не взлетают, это потому что однозначный разбор грамматики пока не решенная проблема, и если лингвисты найдут на нее положительный ответ, то может быть ситуация поменяется. Примеры исследований в подобном направлении - http://attempto.ifi.uzh.ch/site/resources/ . Этот проект использует ограниченное и контролируемое подмножество английского языка для представления знаний. Я понимаю что это намного более простая задача. Посмотреть примеры можно по ссылке ACE in a Nutshell на вышеупомянутой страница. Для меня подобные исследования говорят о том что вердикт не вынесен и люди хотят иметь более удобный для "чтения" формат кода. Опять таки, для чтения, а писать мучаться надо будет также.
Кроме Дейкстры, есть еще Кнут с концепцией Literate Programming. Также есть математика, которая использует вставки спец-языка в естественный язык, может быть также возможно с программированием.
Одной из причин, как мне кажется, по которым естественные языки не взлетают,
Потому что это по факту это оказывается ненужным. Использование естественного языка вынужденно ограничивает пользователей только носителями данного языка с относительно сложной грамматикой. И выгода от такого использования отсутствует. Носителям языка все равно придется учитывать ограничения реализации, а остальным - учить более сложный естественный язык, вместо формализованной грамматики какого нибудь Python.
Потому что это по факту это оказывается ненужным
Мы сейчас обсуждаем насколько я знаю сугубо исследовательские вещи, которые еще и крайне нишевые.Я сходу вспомню только китайский язык который недавно был в новостях. Я китайский не знаю, потому судить о сложности не могу и попробовать тоже не могу.
Не соглашусь что не нужно. Социальный запрос судя по всему огромный. Copilot не просто так шороху навел. Людям нравится эта идея, они хотят ее. Если конечно это сейчас не рабочая схема, это уже другой вопрос. Такого же ажиотажа от Haskell я не видел.
Использование естественного языка вынужденно ограничивает пользователей только носителями данного языка с относительно сложной грамматикой.
я и не пытался сказать что весь язык можно использовать. Это действительно выглядит тупиковым направлением. Но контролируемые языки, где есть как раз упрощенная грамматика, есть. И они применяюся, но только в крупных компаниях, например для масштабирования усилий по автоматическому переводу. Для меня это говорит что технические писатели осилили и как раз основные усилия по тому чтобы наоборот упростить грамматику и сделать ее максимально широко доступной.
И выгода от такого использования отсутствует.
Да, конечно сейчас отсутсвует. Но также стоит оговориться что у нас даже игрушечных пседо-промышленных примеров раз два и обчелся. Академики показывают идею, и до того чтобы она была выгодной еще шагать и шагать. Серьезные работы и деньги в НИОКР в данном направлении насколько я понимаю велись в районе 60х-70х, а потом все бабки рубили на том что уже работало и реинвестировали в существующие технологии.
Я бы хотел конечно посмотреть на попытки сделать именно полноценный язык на основании английского/русского, что получилось, и почему не взлетело.
. Косвенное подтверждение это законотворчество, юриспруденция
А так же подтверждение того, что "не надо так". Если бы эти товарищи перестали делать вид, что используют "человеческий язык, который не нужно учить, чтобы понять, что от тебя закон требует", а разработали какой-нибудь формальный, достаточно однозначный и требующий небольшого изучения язык - то всем было бы сильно проще.
Ну или хотя бы, наконец, скобки бы в своих логических выражениях начали использовать и однозначные логические операторы. Т.к. даже 'и/или', если я правильно помню, могут означать не одно и то же в разных контекстах.
Здесь дело не в грамматике, а в том, что высказывания на естественных языках часто неоднозначны или не полны, так что для понимания того, что сказано, необходимо привлекать широкий контекст. При этом контекст (например, жизненный опыт) у разных людей может бытьразным, поэтому одно и то же слово может интерпретироваться по-разному. В науке, математике и программировании это свойство языка крайне нежелательно. Именно поэтому во всех этих областях мы и пользуемся не естественными языками, а более или менее формализованными искусственными конструктами. Понятно ведь, что научная терминология - это не естественный язык, а формальная система, даже если граматически она напоминает естественный. В биологии формализация меньше (к сожалению), в физике больше, в математике она максимальна. То есть во всех случаях, когда нам нужна однозначность, мы отходим от естественных языков в сторону формализма, и чем сильнее потребность в однозначности, тем более жесткую и, следовательно, непохожую на естественны язык, систему мы используем.
Я с всеми тезисами согласен. Я могу высказывать свои оговорки, но они не меняют картину того что
Для программирования требуется дициплина.
Для дисциплины нужен свой язык.
Каждая домохозяйка не может писать программы
Одновременно с этим, в ходе подобных дискуссий я не вижу ответов на вопросы
Можно ли придумать контролируемый естественный язык который был бы пригоден как для программирования, так и для чтения?
Каковы механизмы которые делают один социолект языка более формальным чем другой? Но это конечно уведет нас в дебри лингвистики и я так понимаю мы как общество даже близко не можем этими понятиями оперрировать.
Почему не учитывается изменившаяся демография программистов? Сейчас намного более широкий спектр людей прграммируют, и может быть этой демографии лучше будут другие вещи, чем те которые были полезны первоначальной демографии?
Наверное у меня вопросов побольше будет, просто мне их тяжело артикулировать пока связно.
Проблема, я думаю, не в сложности разбора текста на естественном языке, а в его неоднозначности. Если же из языка убрать неоднозначности, то мы получим еще один ЯП со своими ограничениями и правилами!
Да, конечно это будет не обычная повседневная разговорная речь. Именно потому я привожу примеры контролируемых естественных языков. Они "выглядят" как естественный язык, одновременно с этим они могут быть проверены на соответствие грамматике.
В первую очередь это не должно быть просто калька с текущих языков программирования, иначе это действительно есть пример Паскаля и продолжения. В вышеупомянутом ACE проблема с неоднозначным использованием И и ИЛИ решается ограничениями на шаблоны использования фраз.
The screen blinks and John waits.
The screen blinks or John waits.
The screen blinks or John waits, and Mary enters a card.Небольшое отступление почему мне любопытно это направление.
Вот пример статьи 1964г. где говорится про то что "отрицание" и пассивная форма имеют задержки при обработке читаемого текста и предположительно активная утвердительная форма является основным механизмом мышления, и пассивная форма и форма отрицания являются дополнительными процессами которые выполняются последовательно и независимо. В практике как мне кажеся это выливается в следующие эвристики.
Мне это дает почву спекулировать о том что "языки программирования" и конструкции в них основаны на некоих особенностях психики и возможно исследования в данном направлении помогут улучшить эргономику языков программирования.
Было бы круто, если бы кто-то из психолингвистов прокомментировал актуальность данной статьи, и что нового есть в данном вопросе.
Естественный язык появился как способ записывать звук. Даже если мы его формализуем то в нум останется легаси вот этой последовательной одномерности.
Имхо плюс может быть только в пороге входа. А минус - эта последовательная одномерность (конечно есть костыли в виде всякого форматирования, но все равно если порог входа и так большой - как в математике - то лучше уж переориентировать систему обозначений на визуальную).
Возможно так же сама похожесть на естестенный язык будет не только помогать но и мешать. Разные неформальные оттенки значений которые присутствуют в естестенном языке будут накладываться на на формализованные значения. Я думаю, именно поэтому даже для обычных слов в науке вводят какие-то специальные термины
Естественный язык появился как способ записывать звук. Даже если мы его формализуем то в нум останется легаси вот этой последовательной одномерности.
Пожалуй да, но сейчас кажется что чтение попало в свой отдельный кусок мозга. Насколько он близок программированию, хз. Ну и если мы формализуем, то это будет прорыв в лингвистике насколько я знаю.
Имхо плюс может быть только в пороге входа. А минус - эта последовательная одномерность (конечно есть костыли в виде всякого форматирования, но все равно если порог входа и так большой - как в математике - то лучше уж переориентировать систему обозначений на визуальную).
Да, я согласен и с плюсом и с минусом. Но было бы хорошо получить на руки тушканчика, и посмотреть где он сломался. Пока я так понимаю его нет.
Возможно так же сама похожесть на естестенный язык будет не только помогать но и мешать.
Очень вероятно.
Я думаю, именно поэтому даже для обычных слов в науке вводят какие-то специальные термины
Да, это тоже проблема. Но выглядит так что мы как отрасль справляемся как-то с этим. Всякие контроллеры, энтити, медиаторы(посредники) и так далее, это пример введения новых слов в том числе и в "код". Выглядит что это естественный процесс и его можно будет применить и в "языке".
А чем эти языки отличаются от ЯП? В них просто больше слов, правил и ограничений!
Проблема программирования не в количестве слов, а в умении составить алгоритм решения задачи.
И, скорее всего, один алгоритм будет сформулирован одними и теми же словами и их синонимами. Не думаю, что количество слов упростить составление алгоритма, скорее наоборот!
В Паскале около шестидесяти зарезервированных слов.
В естественном языке на порядки больше. Программисту надо будет выучить значения всех слов, или же программировать как на Паскале, некоторым ограниченным набором слов.
А чем эти языки отличаются от ЯП? В них просто больше слов, правил и ограничений!
Я исхожу из предположений что именно ЯП обладают более строгим набором органичений. В то время как естественные языки наоборот более всеядны. Контролирумые естественные языки с моей точки зрения могут обладать следующим интересным свойством - они лучше будут "читаться", и это само по себе может сделать алгоритмы и процессы более прозрачными. "читабельность" никак не улучшить "писабельность" и мучаться очевидно с этим прийдется.
Проблема программирования не в количестве слов, а в умении составить алгоритм решения задачи.
Это известный факт. Но кроме написания кода, сейчас остро стоит вопрос, тренировки новых сотрудников в понимании того что написано, или прозрачности ключевых программ для общественности. Что если "сухой и формальный язык" облегчит жизнь не программистам, а всем сопутствующим профессиям? Сереьезно обсуждать "улучшения" процесса я не могу, так как непонятно что за фрукт будет этот "язык", если он будет.
И, скорее всего, один алгоритм будет сформулирован одними и теми же словами и их синонимами. Не думаю, что количество слов упростить составление алгоритма, скорее наоборот!
Думаю мы и сейчас как программисты дублируем алгоритмы и шаблоны в большом количестве. Потому что как и в жизни нужно "так же как тут, но чуток по другому".
Программисту надо будет выучить значения всех слов, или же программировать как на Паскале, некоторым ограниченным набором слов.
Для меня это не очевидно. Когда мы говорим про языки программирования в современном понимании, то если я не ошибаюсь, они состоят из
вспомогательной среды исполнения для компилятора, помогающей ему писать код
базовой библиотеки функций/классов
экосистемы общеизвестных библиотек для данного языка
И еще в приложении у вас может быть свой DSL в виде бизнес-логики.
Все это достиглось годами работы в данном направлении. Если даже сейчас придумать "язык", то врядли он покроет что-то кроме пунктов 1 и 2. Это будет не честное сравнение как мне кажется. И да, если даже "язык" возможен, то он выглядит затратным предприятием.
Также сейчас очень много кода который просто служит склейкой для разных слоев, вдруг там бы подобный простой вариант "языка" применился бы. При условии что это не калька с языка программирования разумеется.
Всем мои придирки также основаны на том, что было бы не плохо опиратсья на конкретный пример "естественного языка программирования" который был хреновым, и были понятные проблемы. Сейчас обсуждается сферический конь в вакууме. Разумеется то что "предки" не смогли сделать этот язык, хоть и сильно старались, это аргумент в пользу того что попытки тщетны, но это не гаранированный аргумент, учитывая сколько путей даже не рассматривалось.
Возможно я не прав, но, то что вы описываете это еще один ЯП.
Не думаю, что понятность алгоритма измениться от языка на котором он написан.
но, то что вы описываете это еще один ЯП
Для меня это выглядит как градация "языков" с очень не четкими границами. Даже сами "контролируемые естественные языки" деляются на две группы, Одна это языки которые программно верифицируемы, и вторые это языки нацеленные на снижение ошибок у людей. Т.е. выглдит что "контролируемые естественные языки" это пока еще не удавшаяся попытка найти в какой момент "формальный язык" становится "естественным языком".
Не думаю, что понятность алгоритма измениться от языка на котором он написан.
В целом да. У меня просто есть надежда, что подобные эксперименты помогут найти педагогические методики которые будут помогать писать более "понятные" алгоритмы, или просто оценить что есть более понятно. Но это так, фантазии конечно.
Дело в том, что ни один естественный язык не является однозначным и не может являться таковым. Я не специалист в лингвистике, поэтому не могу точно сослаться на исследования на эту тему, но они точно были, надо погуглить на досуге.
Возможно, можно будет писать на естественном языке программы для квантовых компьютеров, они не подчиняются булевой алгебре.
Писать программы сложно не потому, что они пишутся какими-то чуждыми нечеловеческими закорючками, а потому что люди, в большинстве, даже на своем родном языке не очень хорошо могут выразить, чего они на самом деле хотят. Эта мысль мне приходит в голову каждый раз, когда я вижу словосочетание "программирование на естественном языке".
Ну использование операторов &&, ! и || в противовес легко воспринимаемых и абсолютно аналогичных and, not и or я бы поставил под сомнение.
А ведь некоторые извращенцы вообще любят по классике: ∧ ¬ ∨
Может поэтому питон и взлетел и до сих пор популярен, ну хотя бы в том числе поэтому?...
Навскидку у них есть преимущество: эти символы не могут использоваться в названиях переменных и функций, и логические конструкции легче сканируются взглядом, т.е. быстрее заметны границы между названиями переменных и логическими операторами. Тогда как если используются and, not, or, то при таком сканировании приходится подключать свой "лингвистический анализатор" более высокого уровня - отличать одни слова от других.
по классике: ∧ ¬ ∨
А что не так? Если бы они были на основной клавиатуре, я бы тоже их с удовольствием использовала. Хотя встает вопрос как обозначать не short-circuit операции. Хоть они и не очень часто нужны. Даже я бы сказала вообще не нужны (уменьшают читаемость и привносят хаос).
Весь вопрос не про вас конкретно, а про среднестатистического разработчика, которому чем меньше рунических символов, тем лучше.
Тогда почему SML не популярен? Там даже при вызове функции спецсимволы, вроде скобок и запятых не требуются.
Ну скобки и запятые годами вбивались в школе, поэтому именно они не помеха. Насчёт SML не знаю. Почему он не популярен в СНГ более менее понятно, его не так много где преподают, а вот почему он не популярен в остальном мире, где его преподают не совсем понятно. Может потому что функциональная парадигма является непреодолимым порогом для среднего программиста.
Чем меньше непривычных. А это уже зависит от того, к чему привык
На мой взгляд, программирование на естественном языке имеет большие перспективы, но это программирование не на уровне алгоритмов, а на уровне технических заданий. Фиксация алгоритма должна выполняться на формальном языке, но сами алгоритмы могут частично генерироваться компьютером на основе ТЗ и контекста (проектов, взятых за основу). Другая часть алгоритмов при этом по-прежнему будет писаться людьми на формальных языках, и распространяться как библиотеки и фреймворки. Процесс постановки ТЗ и получения программы при этом обязательно должен быть интерактивным и диалоговым. То есть изначально среде разработки ставится задача вида: "Берём этот функционал из этой программы, этот - из этой, добавляем новые функции с применением вот этих алгоритмов". После этого среда разработки задаёт уточняющие вопросы, и выдает черновой результат, который оценивается разработчиком, и корректируется по помощи изменения и дополнения требований, до тех пор, пока не удовлетворит ожиданиям. При этом, из базовых проектов берется не только алгоритм, но и контекст - способ интерпретации требований на естественном языке,например, в виде обученной нейросети.
Вот те шизофренические хотелки, которые наивный заказчик нам высказывает, -- ЭТО программирование на естественном языке. А даже строгий язык ТЗ или язык, которым аналитик пишет задачу разработчику, уже не вполне естественный, он недоступен людям по умолчанию, ему надо обучаться
строгий язык ТЗ, замудрёный Юридический или канцелярский язык бухгалтера... похоже, это как раз человеку предстоит подстроиться под машинный язык, с отсутствием исключений, окончаний и предлогов. (почему-то статья напомнила о Сетуни и перуанском языке Аймара, основанные на троичной логике)
ООП наиболее близко к человеческому языку. Например, код ниже можно описать так: "Возьмем человека, его зовут Иван, 23 лет), сейчас он работает дизайнером"
class Man:
def __init__ (self, name="Некто", age):
self.name = name
self.age = age
def work(profession):
pass
ivan = Man('Иван', 23)
ivan.work('Дизайнер')
Например на «человеческом» языке это будет выглядеть так.
Возьми переменную и положи в аккумулятор a
Возьми переменную и положи в аккумулятор b
Сложи аккумулятор a и b
И т.д.
Собственно современные языки программирования недалеко ушли от этого текста. Просто люди которые не писали код не совсем представляют сколько инструкций нужно для описания поведения простейших ситуаций.
А вот если люди хотят что то типа — компьютер задай мне сцену древнего замка. Ага — так. Добавь мне героя. Ага так. Дракона туда на задний фон. То тут это просто сильный ИИ. Который должен понять что человек имеет ввиду — и воссоздать в программе.
Программирование на родном языке возможно, если родной язык - ложбан...
Естественный язык кроме распоряжений слушателю выражает ещё и внутреннее состояние говорящего. Калькулятору пока нечего сообщить человеку о своём внутреннем состоянии. Отсюда и кажущаяся ущербность языка программирования, забавно формулируемая как глупость программирования на естественном языке.
Это очень правильно вспоминать отцов основателей, особенно сейчас, когда в отрасли расплодилось множество средств формализации алгоритмов для выполнения их всевозможными автоматами. Порой язык, простите тавтологию, не поворачивается назвать некоторые из них языками программирования.
Мне кажется, что пришло время наконец определиться, что мы называем программированием и какие задачи оно должно решать. Является ли наконец программирование инженерной дисциплиной сродни инженеру строителю, который на основании проектно-сметной документации возводит здание и подводит все необходимые коммуникации. И является ли фронтенд разработка программированием или это уже давно нечто совершенно другая деятельность сродни отделки здания, которая доводит здание до совершенства, до состояния пригодного для человеческого обиталища.
Определившись с этим вопросом можно вырабатывать требования к средствам, которые используются при проведении строительно-монтажных и отделочных работ.
Поменьше багов, коллеги, и мира на Земле!
Высказывание:
I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras.
подтверждается :D
О глупости «программирования на естественном языке»