Как стать автором
Обновить

Интернациональное программирование на естественных языках

Время на прочтение 7 мин
Количество просмотров 5K
Всего голосов 8: ↑7 и ↓1 +6
Комментарии 95

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

IMHO не так важен ваш план, как его реализация.
В современном языке программирования синтаксис самого языка — 10% от языка. Основное это его окружение — библиотеки, компиляторы, интерпретаторы, IDE, отладчики, поддержка ООП и куча другого.
Таким образом — у вашего языка какая ниша предполагается?
Сейчас я писал только про основные особенности, которыми должен обладать язык. Естественно, должны быть и библиотеки и IDE. И если сразу ориентироваться на реализацию в виде транспилера, а так же на возможность включения программных вставок на других языках, то с библиотеками не должно быть особых проблем.

А из основных применений видится следующие:
— Предметно ориентированное программирование за счет написания программ «не программистами». Фактически, это стирание грани между постановкой задачи (её текстовым описанием) и непосредственно написанием программного кода.
— Расширение и интернационализация открытых программных проектов за счет привлечения обычных пользователей, которые хотели бы внести свой вклад в развитие проекта, но не являются программистами или не знают используемого языка.
Предметно ориентированное программирование

Что это означает?
Это означает, что если предмет был заранее не запрограммирован, то ваш язык ничего не сможет с этим сделать?
А стирание грани между постановкой задачи — означает, что кто-то (программист), заранее должен написать кучу разных готовых программ, а ваш язык должен по словам непрограммиста просто догадаться какую из них поставить?

Не будет работать еще долго.

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

Нет таких. Обычные пользователи не будут вносить вклад. Они будут вносить свои хотелки, но не пошевелят жопу, чтобы сделать хоть что-нибудь формальное, и тут уже не так важно на языке программирования или вашем псевдоязыке — ведь нужно прилагать усилия, а обычные пользователи не готовы это делать по отношению к программам.
за счет написания программ «не программистами»

Не программист: -Мне надо вывести на экран отчет.
Программист: -В каком он файле?
Не программист: -Кто?
Программист: -Отчет.
Не программист: А! Докикс.
Программист: -Его надо открыть и распарсить, докикс — это зип, надо вначале разархивировать.
Не программист: -Не надо всего этого! Его надо просто вывести на экран!
«не программист» != «полный ноль»
В вашем примере, замените «Программист» на «Аналитик» или продвинутый пользователь, тогда будет все правильно.
В принципе возможно даже в таком варианте:
Начать программу.
Вывести на 1 экран файл «C:\Мои документы\отчет.docx».
Подождать нажатия любой клавиши.
Завершить программу.

Но вот что-то сложнее — давайте попробуем.
Решение квадратного уравнения через ввод коэффициентов.
Начало программы.
Нарисовать окно программы во весь экран.
Нарисовать окна ввода с именем «Окно1».
Нарисовать окна ввода с именем «Окно2».
Нарисовать окна ввода с именем «Окно3».
Нарисовать окна вывода с именем «Окно вывода 1», «Окно вывода 2».
Взять значение из «Окно1», присвоить переменной «A».
Взять значение из «Окно2», присвоить переменной «B».
Взять значение из «Окно3», присвоить переменной «C».
Переменной C1 присвоить (-B+sqrt(B^2-4*A*C))/(2*A).
Переменной C2 присвоить (-B-sqrt(B^2-4*A*C))/(2*A).
Вывести С1 в «Окно вывода 1».
Вывести С2 в «Окно вывода 2».

Что-то мне это напоминает… главное — возможность использования синонимов.
Но самое сложное — это концепция — что-куда присваиваем и выводим — и почему. Т.е. нужно программисткое мышление. «Программа», что я написал это по сути вариант программы на Билдере/Дельфи, но по-русски и без специфичного синтаксиса.
P.S. Это как-то низкоуровнево — думать об окнах и переменных. Но вот кто сделает эту работу?
Замените «программистское» на «алгоритмическое».
Тогда вашу программу может сопровождать и дорабатывать не только программист на Билдере/Дельфи, а домохозяйка, которая объясняет сыну математику.
Причем не обязательно по русски, но и после преобразования на английском или эсперанто.
Не совсем. Мне понадобились значительные усилия, чтобы воспринять концепцию ООП. Я читал Страуструпа (после K&R), ноне понимал — зачем это всё нужно, и только когда стал писать на BCB6 — вчитываясь в книжку Архангельского — тогда и произошло озарение.
Я с вами согласен, что для реальной разработки знаний условной домохозяйки будет мало, независимо от используемого языка (хоть родной, хоть C++). И это специально уточнили в одном из предыдущих комментариев про «не программиста».
Но если говорить не про полноценное программирование, а про приведенный вами пример с решением квадратного уравнения, то там школьных знаний будет вполне достаточно.
Когда-то разработал формальный язык, близкий к ЕЯ. Примеры
всемогущество
иметь все доступные способности // ЕЯ
иметь(@ = $$; $ = *способность) // Селанг

органолептика
наука, чьим предметом является восприятие человека // ЕЯ
наука -> предмет^ = восприятие^человек // Селанг


очень X
если интенсивность понятия ($) $ >= 0.500, то результат $ + (1.00 — $) / 2 иначе $ — $ / 2 // ЕЯ
=> $ >= 0.500? $ + (1.00 — $) / 2, $ — $ / 2 // Селанг

Подробности docs.google.com/document/d/1lkqVj4YhzJAwpkphKXymOYb5KpQfoYI5-95DueRKTp0/edit?usp=sharing

Пунктуация тоже не интернациональна. Есть языки с совершенно другой структурой и знаками препинания, да хотя бы с другой грамматикой, просто заменить слова на их перевод получается далеко не всегда. Степень владения любым человеческим языком напрямую зависит от возраста, опыта, количества прочитанного текста и т.д.: не каждая домохозяйка сможет адекватно описать что ней нужно от компьютера. К тому же язык литературный, устный и напечатанный онлайн сильно отличаются и служат разным целям. Выучить какой-нибудь традиционный язык программирования или нанять программиста намного проще и продуктивнее, чем учить какой-то новый язык, косящий под человеческий.
Тем не менее, простые фразы и предложения компьютер уже может воспринимать, распознавать грамматику (благо для человеческих языков есть правила), вычленять значащие объекты и слова, но это уже абсолютно другой путь.
Представьте себе обрыв, на одной стороне которого стоит человек, а на другой — компьютер. Человек может выучить совершенно новый способ взаимодействия и стать программистом (более или менее низкоуровневым), либо компьютер по принципу работы максимально приблизится к человеческому мозгу с распознаванием устной и письменной речи (между ними все равно останется приличный такой обрыв, так как люди даже друг друга не всегда верно понимают).
Многие языки закономерно имеют много общего, языки программирования тоже. Попытки их объединять и так и сяк в поиске идеального языка программирования похвальны, но по моему сугубо личному мнению язык, который предлагается в статье (пример в комментариях выше) — не очень удачный пример. Можно развить идею некой обобщенной пунктуации и грамматики, но тогда это ни чем не будет отличаться от обычного нового языка программирования, и домохозяйке его всё равно придётся учить, а некоторым даже придётся привыкать к новой грамматике.
Вот мои наблюдения по данной теме:
1) Большинство мне известных языков на глобальном уровне структурированы линейно, отступы почти никак не используются в грамматике. А в некоторых языках программирования — используются, потому что древовидная структура выразительнее линейной и вообще-то, включает её. Тогда почему бы не включить её в убер-язык?
2) Идея с использованием устоявшихся значений разных скобок и кавычек мне очень нравится. Разве что пусть {} всё-таки служат для блоков (древовидная структура, минификация). А для вставок кода других языков традиционно можно использовать обратные кавычки ``.
3), и; для разделения элементов списка — очевидное решение, но как же перевод строки? Даже языки программирования нечасто разрешают опустить эти знаки пунктуации на конце строки, а некоторые даже ругаются на лишний знак пунктуации после последнего элемента (trailing comma), что меня лично очень печалит. Кстати,: я хочу тоже опустить, раз уж на следующей строке всё равно будет отступ (меня бесит бесполезность: в питоне)
4) Динамическая грамматика. Язык должен либо иметь очень много ключевых слов и сложную грамматику для каждого ключевого слова, либо преобразовывать предложение (слова разделенные пробелами) в дерево на основе самих слов и их значений. Насколько я знаю, хаскель умеет что-то подобное.
5) (математические) операторы с приоритетом делают язык выразительнее, организуя его опять же древовидной структурой. Нет никаких причин их выбрасывать, ведь их так же учат чуть ли не с детсада (включая смысл оператора). Приоритет и смысл операторов иногда разнятся у самих математиков, поэтому не вижу смысла их "замораживать", если грамматика динамическая. К слову, можно тогда и пробел между словами сделать оператором перечисления и назначить ему приоритет.
6) Переменные и методы. Не вижу смысла их отмечать каким-то символом. Ведь что это такое по сути? Псевдоним или сокращение для какого-то другого слова или грамматической конструкции, мы же всё равно вычисляем значение того или иного слова во время разбора.
7) Раз уж закатили такую пьянку с динамической грамматикой и разрешенными очепятками, то почему бы не разрешить склонения и спряжения слов, в том числе "переменных"?
8) X@Y логически работает по другому, а именно: X at Y, то есть Y.X, если угодно. Мне нравится идея использовать @ вместо точки, так как его смысл подразумевает принадлежность, но левый приоритет напрочь убивает возможность умного автодополнения, а использование X@Y как Y at X вызовет путаницу.
В общем, предложенный в статье язык для меня не более чем ещё один язык программирования с некоторыми неудачными решениями в плане грамматики. В процессе дизайна такого языка не помешал бы опыт использования не только языков программирования, но и различных естественных языков, в том числе с интересной грамматикой. К тому же существуют другие не менее продуктивные способы взаимодействия человека с компьютером, а дальше будут появляться новые и новые. Мне лично визуальное программирование в кухонной сфере кажется более привлекательным чем текстовое, так как оно позволяет строить более сложные структуры, и, соответственно, является более выразительным и естественным.

Большущее спасибо за развернутый комментарий!
Безусловно, пунктуация тоже не интернациональна, однако требуется выбрать какую нибудь точку отсчета.
Попробую ответить на высказанные замечания.
1. Отступы планируется использовать для форматирования списков (но реализация этого может быть сделана не с самого начала).
2. Фигурные скобки или обратные кавычки, это дело привычки. Может быть вы и правы, но данный момент не принципиальный и решается заменой двух символов в лексере.
3. Перевод строки используется для форматированных списков в несколько строк, а запятая для списков или разделения частей в одном предложении.
4. Динамическая грамматика — определенно! Причем грамматика рекурсивная с возможностью вложенного разбора.
5. Использование математических операторов сильно зависит от контекста. Минус как дефис, *- маркер списка и т. д.
6. Отмечать требуется для исключения неоднозначности с поиском псевдонимов и сокращений. Особенно с функциональностью игнорирования опечаток.
7. Нужно определить синоним системной переменной и склонять его как угодно.
8. Насчет приоритетов у символа @, незнаю, не обращал внимания на этот момент.

Что касается визуального программирования, то мне кажется, что его результат сложно сохранять в текстовом человекочитаемом виде.
основой такого языка должны стать только правила пунктуации, но никак не лексика или грамматика
Логическое следствие: все слова, относящиеся к естественным языкам, представляем в виде знаков препинания, чтобы носитель любого естественного языка понял их однозначно.
Проблема: знаков препинания мало и на всех их не хватает.
Решение: добавляем знаков, то есть пиктограмм.
Вывод: мы переизобрели APL.
Со следствием не согласен. Это один из возможных вариантов решения, но не единственный, да и не самый лучший
...(большинство операций обозначается 1—2 символами специального алфавита), что делает программы на APL крайне непонятными для непосвящённых.
Но для того, чтобы однозначно понимать разноязычные «синонимы» (то есть слова-переводы друг друга), компилятору языка всё равно придётся переводить их во что-то APL-подобное (то есть в промежуточный язык).
То же самое делает при переводе Google Translate, просто у него в качестве промежуточного языка использован наименее для этого подходящий, чем и объясняется большинство его ляпов при переводе.
Но у нас-то намечается язык программирования, а не просто переводчик, так что однозначность символов обязательна.
Промежуточные значения терминов безусловно придется использовать в том или ином виде.
Но мне кажется для этих целей не нужно придумывать отдельный язык символов или иероглифов. Будет достаточно использование уникального маркера, наличие бы которого и сигнализировало о том, что слово относится к внутренним терминам и его не нужно «переводить».
А к чему именно цеплять маркер? К слову естественного языка? Тогда очень надеюсь, что не того, что у Гугла.
Сейчас думаю, что имеет смысл использовать английские термины, как самые международные. Но использовать их как своего рода естественный ключ, что в данном случае будет гораздо удобнее, чем какой нибудь GIUD или число.
Минус прошу переадресовать парсеру Хабра, который при редактировании и сохранении показывает глифы высших плоскостей Unicode, но на сервер пересылает битое сообщение.

Повторяю сообщение: «Понимаете, сочетание „знак «курица»“ (_1F414;) + „знак «мужской род»“ (♀) поймёт любой человек (и назовёт на своём языке).
А вот догадайтесь, через что переведено вот это

Возражение против использования естественных языков можно выразить одним словом: AppleScript.


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


Естественные языки не очень хороши в плане однозначности высказываний: контекстная зависимость (причём контекст огромный, включая общий культурный код – вплоть до неявных отсылок к книгам и фильмам), многозначные слова, игра интонациями...


Может, лучше двигаться в другую сторону? Создавать естественный язык, который понимается однозначно? (Логлан, хе-хе)

AppleScript никогда не использовал, но может быть Эсперанто подойдет? ;-)

Вы ничего не потеряли :-)
Эсперанто – не знаю, интуитивно кажется, что с ним должно быть проще, чем с русским/английском, но всё же это далеко не логлан/ложбан, не было таких усилий для устранения неоднозначности.

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

Когда-то в IBM решили сделать ЯП, близкий к естественному, чтобы на нём писали не-программисты. Получился SQL, и мало какие из ЯП столь же успешны.

Точно "близкий к естественному"?
SQL понимается однозначно, он очень простой.

Думаете, они и вправду решили сделать язык, близкий к естественному? Есть этому какое-то подтверждение?

В исходной статье 1974 года сказано «there is also a large class of users who, while they are
not computer specialists, would be willing to learn to interact with a computer in a reasonably high-level, non-procedural query language. <...> It is for this class of users that SEQUEL is intended. For this reason, SEQUEL emphasizes simple data structures and operations.»

Собственно, эта ситуация противопоставляется естественному языку. В предыдущем абзаце пишут про «других пользователей»: «There are some users whose interaction with a computer is so infrequent or unstructured that the user is unwilling to learn a query language. For these users, natural language or menu selection (3,4) seem to be the most viable alternative».

А для других, стало быть, SQL.
Дейкстра многократно предостерегал от попыток превратить разработку программ в некий тривиальный процесс; по его мнению, программирование, в сути своей — чрезвычайно сложная научная и инженерная деятельность, и никакие новые методы и инструменты не смогут кардинально изменить это положение — они лишь освобождают программиста от части рутинной работы. Попытки же превратить программирование в простое занятие, доступное каждому, обречены на провал.
«В американских условиях на подобные устройства есть спрос, тогда как у нас здесь предостаточно посыльных» — главный инженер британской почтовой службы о телефоне, 1879

«Лошади никуда не денутся, а автомобили — всего лишь модное баловство» — президент “Michigan Savings Bank” об инвестициях в “Ford Motor Company”, 1905

«Кого, черт возьми, интересуют разговоры актеров?» — сооснователь и президент “Warner Brothers” о звуковом кино, 1925

«Если кто-то ищет в расщеплении атома источник дешёвой энергии, он несёт чушь. Мы не ожидаем ничего подобного.» — нобелевский лауреат, президент британского Института физики, 1933

«Никому не нужен компьютер дома» — сооснователь и президент “Digital Equipment Corporation”, 1977

Вероятно, ещё при нашей жизни цитата Дейкстры пополнит этот список.

Сходство лексики некоторого языка программирования с лексикой некоторого естественного языка делает очень неудобным поиск в интернете информации о ключевых словах этого языка программирования на этом естественном языка. Особенно, если ключевое слово совпадает с предлогом, например "with". Гугл находит черти что.

Согласен. Поэтому и предлагается отказаться от фиксированной лексики и зарезервированных слов, а выбирать их в зависимости от естественного языка пользователя.

Чтобы по этому языку вообще нельзя было ничего найти?

А что значит «найти по этому языку»? Указывайте при поиске название языка.
В противном случае у вас и сейчас будет мешанина из кода Python, PHP, C\C++, если вы ищите не специфическую библиотечную функцию.

Ещё раз: предположим, мне надо найти для вашего языка, как он работает с оператором "с" (русский предлог).
Что бы я ни ввёл, гугл будет выдавать мне хрень — слово "с" встречается в русском языке повсеместно. И ввод названия языка тут не поможет.


Теперь Вы предлагаете выбирать ключевые слова в зависимости от лексики языка. Но ищу-то я в интернете. В статье (на Хабре, например) эти слова не будут автоматически переводиться, т.е. к описанной проблеме добавится ещё и то, что я не знаю, какой локализованный вариант этого оператора искать.

Наверно мы по разному понимаем проблему, давайте я попробую по другому.
К примеру есть оператор логическое И, т.е. && на C++.
По русски это И, по английски and, по немецки und и т.д.
Естественно поиск этих предлогов будет выдавать все, что угодно кроме нужного (в отличие от оператора на C++)
А естественный ключ для данного термина будет "@and", т.е. английское написание с префиксом. И тогда его поиск, в особенности точный поиск, выдаст вполне ревалентные ответы.
И тогда его поиск, в особенности точный поиск, выдаст вполне ревалентные ответы.

Если автор статьи перевёл свои листинги в естественные ключи.

Если каждый листинг перед публикацией надо «англифицировать», то что даёт «интернациональный» язык по сравнению с традиционными?
Т.е. пользователю вашего языка всё равно надо знать английские варианты ключевых слов, чтобы смочь найти о них информацию?
По русски это И, по английски and, по немецки und и т.д.

Как быть с языками, в которых нет прямых соответствий выбранным вами ключевым словам?
journals.linguisticsociety.org/proceedings/index.php/SALT/article/viewFile/24.137/2157
Программирование на естественном языке — это достаточно странная цель, которая опирается на предположение о том, что именно изучение языка программирования является каким-то существенным барьером для новичка. Но это примерно то же самое, что утверждать, что самое сложное в английском языке — это изучение алфавита. В действительности изучить синтаксис — это меньшая из проблем, и несмотря на наличие всякого рода CASE-средств, UML-компиляторов и прочих подобных инструментов, заменить программистов аналитиками не получается. Куда большая проблема состоит в приобретении навыков формализованного изложения. На естественном языке примерами такого изложения являются всякого рода договоры, законы и прочая бюрократия, которую тоже надо уметь изложить (и даже уметь прочесть, если на то пошло). Обычный нормальный человек, даже аналитик-специалист не имеет навыков детализированного, технически точного изложения алгоритма. А если имеет, то писать на чём-нибудь вроде Visual Basic для него не должно составить труда.
Есть такое выражение «любая аналогия ложна».
Я не утверждал, а наоборот опровергал тезис, что на естественном языке может программировать любой, только нужно выучить алфавит.
В данном случае речь идет как раз о человеке, который умеет формализовать алгоритмы, но не знает языка. И вот в этом случае предложенный подход будет отличным выходом. Пусть пишет алгоритм на естественном языке, а с реализацией на конкретном языке можно не заморачиваться.
Если человек умеет формализовывать алгоритмы, выучить основы Питона для него будет вопросом нескольких дней (никто же не ожидает знания всех тонкостей).

А программирование «на естественном языке» абсолютно всегда и везде вырождается в тот же Бейсик/Питон/whatever, только со словами вроде ЦИКЛ и КЦ вместо FOR… NEXT.

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

Дисциплины за пределами computer science, если их интересует точность, пытались и пытаются как раз идти к формальности. Юриспруденция, математика — даже есть возможность писать «неформально», всё равно предпочтение отдаётся стандартному синтаксису и шаблонным оборотам, потому что цель состоит в снятии разночтений.

Аааааа! «коммуникации с компьютером без строгого формального синтаксиса» – за что?! Зачем вы так?
Это ж ад – когда ты не можешь быть уверен, как компьютер поймёт твою программу.

Так ведь уже сейчас толкование программ на С/С++ — чёрная магия, и споры между специалистами по поводу того, как компьютер должен трактовать какую-нибудь необычную конструкцию — обычное дело.
Добавлю, что для использования вашего языка недостаточно уметь формализовать алгоритмы. Классический пример — «для двух данных чисел последовательно отнимать меньшее от большего, пока они не станут равны». Сколько человеку потребуется изучить, чтобы смочь перевести этот алгоритм на ваш язык?
Вы не представляете, насколько сложно новичкам понять, что значит «переменная», «массив» и «функция», — намного сложнее, чем выучить пару десятков ключевых слов. Между прочим, в традиционном ФП не используются ни переменные, ни массивы, ни функции в смысле «последовательность операций», так что новичкам было бы проще, если бы вы «интернационализировали» какой-нибудь Лисп.
Вы не представляете, насколько сложно новичкам понять, что значит «переменная», «массив» и «функция»,

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

1) в математике, когда написано «положим x=3», это значит, что всюду до конца рассуждения вместо x используется значение 3. В программировании — совсем не так.

2) сложность не в «кусочке кода», а в том, что присваивание переменной x внутри функции никак не влияет на переменную x в основной программе и на переменную x в рекурсивных вызовах той же самой функции. Как это — одно и то же имя, в одном и том же месте программы, соответствует разным значениям одновременно?

3) если массив — это таблица соответствия между числами, то почему я не могу задать a[2.5]? Вот же тупой компьютер!
присваивание переменной x внутри функции никак не влияет на переменную x в основной программе
Это если Вы объявите переменную x внутри функции. А если забудете: здравствуй, изменение глобальной переменной! Ну, не во всех языках, конечно.

если массив — это таблица соответствия между числами, то почему я не могу задать a[2.5]?
Странно, а я могу (в JS, например). Ключ, конечно, не находится между «2» и «3», но этого в условии и не было.
Это если Вы объявите переменную x внутри функции. А если забудете:

И это дополнительный WTF, потому что в математике задание значения переменной — это и есть её объявление.

Странно, а я могу (в JS, например).

> let a = [1,2,3,4]
< undefined
> a[2.5] = 3.14
< 3.14
> a.reduce((a,x)=>a+x)
< 10

Почему сумма элементов массива сосчиталась без учёта a[2.5]?? Вот же тупой компьютер!

(На мой взгляд, такое поведение выносит мозг ещё жёстче, чем ошибка при попытке задать a[2.5])

1) В математике можно в следующем абзаце положить другой x, и повторить рассуждения для него. "Положим теперь, что x=3.1, тогда ..." — "А если мы возьмём x=3.14, то ..."


2) После того, как функция написана — она превращается в чёрный ящик. Можно уже не думать, что за неонка у неё внутре. Новичок вряд ли


3) Тупой, то поделаешь. Приходится выкручиваться, писать не a[x], а a[x/2]. Или ещё какое преобразование.
Моей первой функцией, которую я реализовал массивом было отображение сигнумов координат на номер направления (от 1 до 8 по часовой стрелке, и 0 — для нулей). Мне приходилось использовать a[x+1].

1) для таких двух переменных можно без ущерба рассуждению выбрать разные обозначения — что обычно и делается, чтобы не путать читателя. В программировании редко когда возможно заменить два присваивания x на присваивания двум разным переменным.

2) затруднения возникают во время написания функции — до того, как она превратится в чёрный ящик.
два присваивания x на присваивания двум разным переменным

Но тогда придётся дублировать всю работу с этими переменными.


затруднения возникают во время написания функции

Не припомню подобных затруднений. При том, что я начинал с QBASIC, где вообще переменные не объявляются.

Такой человек сможет написать реальзацию на псевдокоде. Тогда програмист (вернее кодер) с лёгкостью переведет псевдокод в код на реальном ЯП. Это уже будет шаг вперёд по сравнению с нынешними компетенциями аналитиков.


Пока же псевдокод чаще всего пишут сами программисты...

Поэтому, цель максимум — приблизить язык программирования к естественному человеческому языку.

Извините, но это довольно упрощённое представление дел в сфере программирования. Если позволите, то я сформулирую свои принципы (их будет несколько, а не один).
1. Языка программирования должно быть два. Один — для компилятора, другой для человека. Между языками — автоматический транслятор.
2. Язык программирования на стороне компилятора (компилируемый язык) — это те самые ЯП, к которым мы привыкли, но в силу разделения языков допускается значительное усложнение компилируемого языка.
3. Язык программирования на стороне программиста (язык разработчика) — эта штука потребует долгого объяснения. Вы должны перевернуть собственные представления о языках программирования, чтобы понять, о чем я. Язык разработчика — это его интерфейс со всеми деталями. Даже в существующих IDE вместо листинга кода, соответствующего стандарту языка, мы видим нечто препарированное: подсветка кода, помощь при вводе, возможность сворачивания, отображение на экране части кода (а не всего сразу). Вы можете заметить, что имеет место не до конца осознанная идея — стремиться ограничить количество информации, отображаемой информации до размера весьма ограниченной «оперативной памяти» разработчика. С одной стороны, код крайне сложен, с другой стороны, разработчик может анализировать код по частям. Попытка достичь максимальной естественности языка позволит помещать на экран более сложные конструкции, но надо понимать, что весь код со всеми своими детальными подробностями сразу никогда на экран никогда не получится поместить.
4. Автоматизация программирования. Сейчас разработчик регулирует загрузку своей «оперативной памяти» в крайней степени вручную. Он вынужден самостоятельно решать, в каких местах кода скрыть детали реализации под абстракцией. Абстракции — это один из основных методов регуляции разбиения кода на части и определяет последующий интерфейс программы, который будет отображаться на экране. Эта работа на сегодняшний момент совершается в основном на 100% вручную. И пока не осознана необходимость автоматизации этого процесса.
5. Третий язык — язык общения команды разработчиков. Те два языка, о которых говорилось выше, оба строгие, и они должны иметь взаимно однозначное соответствие друг другу (разработчик — компилятору, компилятор — разработчику). Язык общения команды разработчиков (ЯОКР) в отличие от первых двух языков нестрогий. Самое интересное, в нынешних ЯП основным элементом, реализующим данный язык, являются комментарии. В комментариях можно писать любую неформальную информацию, которая игнорируется компилятором. Казалось бы, ну вот тебе комментарии, что тебе ещё нужно для нестрогого общения??? А нет! Для составления комментариев написаны целые талмуды правил, то есть ЯОКР достаточно сильно формализован. Однако, все что мы имеем на сегодняшний момент — это комментарии «пиши, как тебе вздумается». В двух словах, я предлагаю ввести спецкомментарии, которые будут проверяться анализатором на правильность. Помимо тех правил ЯОКР (правил комментирования программ), которые можно найти в литературе, существует ещё информация, которую на сегодняшний момент не принято включать в комментарии в связи с ее нестрогостью (вероятностный характер). В этом направлении у меня имеются инновационные идеи. Двумя словами, ЯОКР — это не только комментарии!
Язык разработчика — это его интерфейс со всеми деталями.
Мне кажется, что интерфейс к деталям, это структура классов и API объектов. А язык, это способ однозначной коммуникации между программистом и этим интерфейсом.

А про комментарии немного не согласен. Они имеют значение только в двух случаях, либо нужно изучить код с целью поиска бага, либо нужно изучить код понимания интерфейса к деталям реализации, если API отсутствует документация.
Для первого случая комментарии помогают редко. Конечно, если проблема не в выборе алгоритма реализации, когда в комментарии написано, что-то типа «сортировка пузырьковая и может тормозить на больших объемах данных». Ну а без документированного API действительно тяжело.
И как оценивать «правильность» комментария?
Ответил вам в коренной ветке ниже.
Мне кажется, что интерфейс к деталям, это структура классов и API объектов. А язык, это способ однозначной коммуникации между программистом и этим интерфейсом.

В посте выше моей целью была стратегия, а не тактика (помните анекдот про сову-стратега?). То есть я объяснил, что понимаю под языком разработчика, а какой он должен быть — решайте сами. Отметил лишь крайнюю важность возможности сокрытия ненужных [в данный момент] подробностей для разгрузки этого самого интерфейса.
И как оценивать «правильность» комментария?

1. Имеются идеи на уровне конкретных предложений для спецкомментариев для списков todo, которые нынче прячутся под обычные комментарии. Тут должна родиться дополнительная спецификация языка так мною называемого незавершенного кода.
2. Спецкомментарии для закомментированных кусков кода. Пора и тут навести порядок.
3. О чем я выше писал: добавление в ЯОКР дополнительной информации вероятностного характера. Пока тут одни расплывчатые идеи. В двух словах — в ЯОКР потенциально могут использоваться данные о характере входных данных. Например, на пульте телевизора нажимаются чаще всего пять кнопок: power, vol+, vol-, ch+ и ch-. Это очень важная информация! В ЯОКР такая информация циркулирует, как правило, только при вербальном общении или может даже усваивается с детства. Для чего эту информацию формализовать? Для выделения важных деталей кода (см. п.4 про автоматизацию программирования в моем посте выше).

Upd. Блин, не в ту ветку прокомментировал(
Сейчас практически все языки программирования, кроме языка 1С пожалуй.
Основаны на английском естественном языке.

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

Это вполне просто, достаточно включить полноценную поддержку UTF8, для ЯП.
На современном Дельфи у меня вполне получалось писать, используя для функций, классов и переменных — для идентификаторов, имена на русском. С предопределенными именами не проверял возможно нужен предпроцесор.
Всё в порядке: собачка и хрюшка — имена переменных, кусочек пиццы — имя функции.
Вот в расте такое жаль не прошло.
А вроде язык современный =)
Вот тогда, еще проще, стандартизовать библиотечки с именами преопределенных операторов, на нужных естественных языках. И все.
По моему даже 1С имеет английские варианты ключевых слов
Сейчас да, но изначально язык 1С был на русском.
И популярен кстати в том числе и поэтому.
Я тоже за то, чтобы избавить программиста от запоминания «ненужной» пунктуации, ключевых слов и совершения лишних кликов, которые не относятся к самой сути программирования.

Для реализации подобных идей уже придуманы так называемые «плейсхолдеры» (термин взят из Маткада). Вставляешь плейсхолдер «if then else endif» (заметьте, достаточно одного драг-энд-дропа), вставляются все ключевые слова автоматически и среда разработки следит, чтобы поля плейсхолдера были правильно заполнены (в условии if — предикат, в действиях then и else — только инструкции). Я уж не говорю про дурацкие знаки препинания (действительно, знаки запинания), они тоже автоматом проставляются. Помимо Маткада как минимум одна специальная среда разработки такое поддерживает, не знаю про универсальные IDE.
То есть к кускам кода надо относиться не как к набору букв (боже мой, 1990-е и старше!), а как к объекту. Программист должен единожды одним кликом создать объект и среда разработки должна следить за целостностью объекта и удалять его части только в том случае, когда программист передумает и удалит весь объект. Ау, программисты, андерстенд???

Только не кликом, а с клавиатуры (обычно – вбить первые несколько букв и выбрать сниппет из меню – что-то типа Enter, или Down-Enter, или Down-Down-Enter), это быстрее. Ну а потом табом пройтись по незаполненным полям и вписать туда недостающий код.
Чисто мышью из тулбара – это совсем уж для новичков, жертвуем скоростью и удобством в пользу возможности начать работу, не изучая язык.

Программирование мышкой, как в LabVIEW?

Листинг в виде набора букв я могу запостить на хабр или скопипастить из браузера в IDE, а с «куском кода в форме объекта» такое не получится — приходится на глаз перечерчивать со скриншота, выискивая похожие значки в «палитре инструментов».
Фигня вопрос. Можно дублировать графику xml-кодом, но вообще я не об этом.
По мне так, несколько утопичненько :) Скорее всего, будет сильно упрощено ради того, чтобы хоть как-то работало. Что не понравится ни обычным пользователям, ни программистам. Как говорится, за двумя зайцами погонишься,…
Добавочно смущает наличие слова «естественном» в кавычках при описании языка. То есть, он будет квази-естественнным. Опять же не ясно до какой степени, и для какого контингента это будет интересно.

Так как каждый пользователь является носителем своего родного естественного языка (или даже нескольких), то жестко задавать ключевые слова невозможно, из чего следует, что основой такого языка должны стать только правила пунктуации, но никак не лексика или грамматика.

Что насчёт языков, что крайне скупо используют знаки препинания? Этим часто страдают агглютинативные языки, в которых, например(реальная ситуация при переводе из такого языка), фраза визуально из двух слов, оканчивающая точкой, в русском разворачивается в такую штуку с кучкой запятых: «в то время, когда он читал, она спала». Эдакое описание параллельных вычислений на «живом» языке :)
Кстати, дополнительный вопрос: «Как на человеческом языке описывать многопоточное программирование и всякую асинхронщину?»

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

Общий смысл высказанного мне видится, как «Надо бы сделать google translate», только чтобы он еще и из текста мог программу сваять, причём, чтобы она делала то, что хочу.
фраза визуально из двух слов, оканчивающая точкой, в русском разворачивается в такую штуку с кучкой запятых: «в то время, когда он читал, она спала»

Парсинг «ключевых слов» в агглютинативном языке не слишком сильно осложняется отсутствием между ними пробелов.
Например, в ассемблере ARM ко мнемонике каждой команды можно дописать (без пробела) двухбуквенный код условия, и ассемблер умеет дробить такое «агглютинативное слово» на части.
Про парсинг я и не спорю. Визуально-то оно понятно. Но в ключе обсуждения:
основой такого языка должны стать только правила пунктуации

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

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

Вообще есть сразу 3 разных задачи который автор пытается решить. Я опишу какие этапы нужны для решения каждой и сразу скажу места где автор соснет.

1. Программирование на реальном естественном языке. То есть я говорю компьютеру на русском че ему делать и он пишет программу.
2. Создать квази-естественный универсальный язык, назовем его 1С общего назначения. Чтобы можно было его выучить только его и решать на нем большинство программистких задач.
3. Сделать так чтобы не-программисты могли программировать.

Начнем с того что языки программирования и естественные языки это вообще разные сущности. Автор видимо решил что если например php и английский называются языками, то это одно и тоже. Программирование — это проектирование механизма, системы, а не написание текста. Язык программирования эквивалентен чертежу в автокаде, а не писанине из художественной литературы. Никто же не пытается описывать чертежи или математические формулы на естественном языке? Хотя и то и другое в общем случае — формализованные языки. Наверное потому что в названии математики нет слова «язык»?

Задача номер один.

Чтобы ее решить нужны следующие этапы: универсальный язык программирования, который покрывает большую часть задач. И супер-умный гугл-переводчик из человеческой речи в этот язык программирования.

Тут можно даже до темы этого умного гугл-переводчика не доходить (пока гугл-перводчик даже на английский грамотно вашу речь перевести не может), потому что автор всасывает уже на постановке задачи. Попробуйте своему прошаренному коллеге объяснить детали реализации например какойто своей программы на словах, офигеете на сколько это сложно. Проще код показать. Это целая проблема. И для нее давно придумано решение — формальные языки. Получается что программирование на естественных языках это не решение, это проблема.

А теперь представьте что объясняете не прошаренному коллеге, а Siri. Или представьте как менеджер вам объясняет что нужно сделать. А теперь как менеджер без профильного бекграунда объяснет тоже самое вам. А теперь как он же объясняет Siri. Лол.

Второй этап этой задачи — обычный универсальный язык программирования, где можно будет выбрать между ARC, gc и возможностью писать все управление памятью самому, между компиляцией в нативный код, в managed код для vm и интерпретацией как в скриптовых языках, между статической типизацией со структурками и динамической типизацией и объектами на хештейблах. И чтобы это был один универсальный язык. Про функциональщину и прочее даже не говорю.

Теоретически это реально, но никому не надо — потому что проще сделать несколько разных языков, и… разные языки для разных задач уже есть. Универсиализировать их синтаксис тоже никому не сделось, даже объяснять не хочу почему. Выучить синтаксис того же питона если ты уже знаешь какой-нибудь си-подобный язык проблема наверное только для автора.

Теперь задача номер два.

Делаем некий универсальный формальный язык, но с кейвордами\синтаксическими конструкциями похожими на нужный язык. И разный набор кейвордов\конструкций для разных языков. Тут автора мог ждать успех, но он тоже всасывает, потому что такой язык уже есть, называется 1C. Можно сделать 1С общего назначения, но это не решает вообще никаких проблем, кроме той когда вы прочитали все мемы за сегодняшний день, а рофлить вам больше не с чего.

Программировать на 1С куда менее удобно и понятно чем на любом другом нормальном языке, вещи вроде замены
array[0] = "text"
на
массив array, ячейка 0, присвой значение "text"
понятнее язык ни для кого вообще не сделает.

Обучиться такому синтаксису ровно настолько же сложно, как синтаксису той же джавы. Только зная синтаксис джавы, можно лего понять синтаксис шарпа, питона и js. А после 1С синтаксис любого другого языка будет ломать мозг. И зачем например казаху учить 1С с кейвордами на казахском, если проще выучить ту же джаву и спокойно решать задачи?

И исходники на джаве универсальные, а исходники на кахахском 1С никто кроме казахов не поймет. Тут либо надо делать транслятор в обычный универсальный язык из первой задачи и тогда 1С вообще теряет смысл, ведь можно выучить сразу универсальный язык. Либо делать транслятор между разными диалектами 1С, только это все вообще привнесение проблемы несовместимости естественных языков в программирование на ровном месте.

Третья задача самая простая.

Просто включаем питон в школьную программу.

Итого.

Автор не особо понимает че он хочет и максимум что у него получится сделать это Common 1C. Либо вся статья какой-то несмешной рофл или попытка похайпить. Надеюсь если статья наберет много лайков автор запилит Common 1C, хочу на это посмотреть.
Язык программирования эквивалентен чертежу в автокаде, а не писанине из художественной литературы.

А писанине с доказательством математической теоремы?
А юридической писанине из первого попавшегося EULA?

Просто включаем питон в школьную программу.

Английский в школьной программе уже есть.
Многие ли выпускники умеют им пользоваться?
А писанине с доказательством математической теоремы?

Не понимаю с чем вы пытаетесь спорить. Мой комент про про чертеж в автокаде — это иллюстрация к тезису о том, что понимание синтаксиса это не программирование.

Задача конструктора который рисует в автокаде чертеж самолета не нарисовать линии и подписи, и не понимать что на чертеже нарисован самолет. А сделать так чтобы самолет построенный по этому чертежу взлетел.

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

Можете докопаться что hello world написать сможет, но на это я отвечу что кусок железа в форме самолета с детского рисунка принятого за чертеж, тоже полетит — вниз.

Автор статьи думает что если упростить понимание синтаксиса, то людям станет проще программировать, но это вообще не так, потому что программирование и написание буковок в IDE — разные процессы. То что на чертеже нарисован самолет кто угодно поймет, только констуктором от этого не станет.

Как вы к этому примеру EULA притягиваете — мне непонятно.

Английский в школьной программе уже есть.
Многие ли выпускники умеют им пользоваться?

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

Юристы и математики пользуются естественными языками (вернее, их подмножествами) с той же формальностью, как самолётостроитель автокадом. Почему программисты не пошли по пути юристов и математиков, а выдумали себе птичьи языки из закорючек?

С тем, что понимание синтаксиса — это не программирование, я не спорю. Но я согласен с автором в том, что если упростить понимание синтаксиса, то людям станет проще программировать — хоть это и будет всегда требовать специальных умений, наравне с математикой и юриспруденцией.

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

Математику вы наверное только по телевизору видели, если утверждаете что математики не выдумали птичьих закорючек (языки программирования во многом используют математическую нотацию), а юридические тексты так офигенно формализованы, что чтобы их трактовать требуется образование похлеще программисткого, а некоторые вообще не имеют однозначной трактовки.

Вы не понимаете того, что упрощать синтаксис уже некуда. Вы же не упрощаете синтаксис 2+2=4 когда считаете? Хотя, судя по вашему предыдущему утверждению вы пишите два плюс два будет четыре. Вот и запись array[0]=«text» настолько же простая как и 2+2=4. От того что вы запишете ее на естественном языке станет только сложнее.

нет никаких фундаментальных причин
В таком случае хочу услышать фундаментальные причины, по которым за тыщи лет в математических формулах так и остался специфический синтаксис и препядствие в освоении математики в виде птичьих значков +- и т.п. никуда не ушло.
Возьмите любую математическую статью на ваш выбор и сравните, какую часть её объёма занимают формулы, и какую — текст на естественном языке.

(Ну и про «тыщи лет» вы, конечно, загнули: плюс и минус изобрели в 16 веке)
То что вы написали это не ответ, возьмите любую статью про программирование (например эту) и посчитайте сколько там строчек кода. Или возьмите любое решение математической задачи из своей школьной тетради и посчитайте сколько там предложений на русском языке.

Все еще жду ответ на свой вопрос про фундаментальные причины, которые мешают убрать плюс и минус из математики.

Хотя ладно, и так понятно что по сути вопроса вам изначально сказать нечего
Имей вы хоть какое-то представление о профессиональной деятельности математиков, вы бы сравнивали математические статьи не с публицистическими, а с ентерпрайзным кодом.
Было бы вам что сказать, вы бы спорили по сути, а не на серьезных щах отвечали на мое передразнивание вашей смешной манеры ответов
Раз вы осознаёте несостоятельность своего аргумента и запостили его только ради троллинга, то мне, действительно, добавить нечего.
мне, действительно, добавить нечего
Вам стоило понять это еще несколько коментов назад
'+' и '-' в математике — это знаки.
А слово array — это не знак массива, а именно слово английского языка.
И вместо записи слов 'array[0]=«text» ', запись слов 'массив[0]=«текст» ', гораздо понятнее.
Ведь никто не требует менять знаки квадратных скобок [] или знаки кавычек " "
И вместо записи слов 'array[0]=«text» ', запись слов 'массив[0]=«текст» ', гораздо понятнее.
Кому понятнее? Удачи объяснить что значит слово «массив» тем кто не понимает что такое array
Русское слово — Массив прекрасно объясняется словом из математики Матрица тоже по-русски.
Одномерный массив — одномерная матрица — вектор.
array есть в английском, а в русском так и не появилось «аррау», в отличие от матрицы или вектора. Значит в нем нет необходимости.
Русское слово — Массив прекрасно объясняется словом из математики Матрица тоже по-русски.
Одномерный массив — одномерная матрица — вектор.
Многомерный массив как объяснить?
Многомерных матриц не бывает.

array есть в английском, а в русском так и не появилось «аррау», в отличие от матрицы или вектора. Значит в нем нет необходимости.
В русском появилось слово «массив», значит в нём есть необходимость.
А вот яндекс с вами не согласен.
«yandex.ru/search/?text=%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D0%BC%D0%B5%D1%80%D0%BD%D1%8B%D1%85%20%D0%BC%D0%B0%D1%82%D1%80%D0%B8%D1%86&from=os&clid=1836587&lr=968»
Алгебра многомерных матриц
Случайные дискретные многомерные матрицы


Массив это слово не из бытового обихода, и массив в программировании это концепция с которой в обычной жизни люди почти не сталкиваются.

Поэтому чтобы человек понял что такое array[0]\массив[0] ему надо объяснить концепцию, а каким кейвордом ее называть это дело вообще пятнадцатое.

Для человека, далекого от программирования или математки что array[0], что массив[0] выглядят как «олфыавр[0]». А для человека который понимает концепцию массива не так важно как эту концепцию называть.

А вообще лучше перечитайте мой первый коммент, максимум что может дать ваш подход это Common 1C
А вообще лучше перечитайте мой первый коммент, максимум что может дать ваш подход это Common 1C

И это хорошо.
Потому что слово массив понятен носителю русского языка.
Оно вообще произошло от слова масса.
На моем столе масса сосновых щепок — на моем столе неупорядоченное множество, куча сосновых щепок.
На моем столе массив сосновых щепок — упорядоченное множество сосновых щепок — по какому то признаку, например на каждой щепке я написал цифру, или сложил щепки в пирамидку.
То есть со словом массив, мне, как носителю русского языка, понятнее создать правильный образ.
А слово array — невообразимо, разве что как магическое слово, которое нужно использовать по правилам синтаксиса конкретного ЯП.
Особенно это часто выражется в придумывании англоязычных названий классов, функций, процедур, методов, интерфейсов.
1C
И это хорошо.
Простите, сначала показалось что с адекватным человеком разговариваю.

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

На моем столе масса сосновых щепок — на моем столе неупорядоченное множество, куча сосновых щепок.

Ваше описание массива больше подходит под set чем под array.
Дополню. срок редактирования пропустил.
В данном случае слово Массив можно объяснить без терминов математики, оно используется и в других сферах, но аналогично.
Плита из массива сосны, плита из нескольких натуральных досок, частей сосны. Плита из массива сосны = несколько элементов типа сосна

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

К тому-же простые предложения, по крайней мере в русском языке, имеют достаточно простую структуру: субъект(сущ.) действие(глагол) объект(сущ.) обстоятельство1 (предлог+...) обстоятельство2 (предлог+...) обстоятельствоN... И всё это достаточно просто парситься. Я когда делал свой первый алгоритм разбора рецепта горохового супа, заранее привёл рецепт к последовательности таких предложений и успешно распарсил. И это был алгоритм парсинга "в лоб". Т.е. последовательно слово за словом, строго по приведённому шаблону.

Потом конечно я начал усложнять алгоритм и добавил союзы "и" и "или" и всё как-то стало очень сложно. В лоб уже дальше не прокатывало)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории