О глупости «программирования на естественном языке»От переводчиков. Хотя Эдсгер Дейкстра — одна из главных личностей в истории IT, эта его коротенькая публикация ранее не попадала на Хабр, да и сами мы узнали о ней лишь благодаря докладу на нашей конференции. Но при этом она выглядит очень любопытным документом эпохи, показывая, что ещё несколько десятилетий назад люди думали о перспективе писать программы на «обычном языке». Поэтому мы решили восполнить пробел и перевести.
С первых же дней появления автоматических вычислительных машин были люди, которые считали недостатком тот факт, что программирование требует внимательности и точности, свойственных любому формального символизму. Они критиковали механического слугу за то неукоснительное выполнение данных ему инструкций, когда достаточно было бы поразмышлять мгновение, чтобы заметить, что в этих инструкциях есть очевидная ошибка. «Но мгновение — это долго, а размышлять — болезненный процесс». (А. Э. Хаусман). Они страстно надеялись и ждали появления более разумных машин, которые отказались бы приступать к таким бессмысленным действиям, какие в то время вызывались банальной опечаткой. Машинный код, лишенный практически всех форм избыточности, вскоре сочли слишком рискованным интерфейсом между человеком и машиной. Отчасти ответом на это признание стала разработка так называемых «высокоуровневых языков программирования», и со временем мы научились до определенной степени усиливать защиту от глупых ошибок. Значительным улучшением стало то, что теперь многие глупые ошибки приводили к сообщению об ошибке, а не к ошибочному ответу. (И даже это улучшение оценили не все: некоторые люди больше раздражались на сообщения об ошибках, которые нельзя игнорировать, чем на неверные результаты; и при оценке относительных достоинств языков программирования некоторые, кажется до сих пор, приравнивают «простоту программирования» к простоте допущения незамеченных ошибок). И тем не менее (абстрактная) машина при взаимодействии с языком программирования оставалась верным слугой, то есть бездумным автоматом, способным безупречно выполнять нелепые инструкции. Программирование так и осталось работой с формальным символизмом и, будучи таковым, сохранило те требования к внимательности и точности, что были необходимы раньше. Чтобы значительно облегчить использование машин, было предложено (попытаться) разработать машины, которые мы могли бы инструктировать на своем родном языке. Безусловно, машины стали бы намного сложнее, но, как утверждалось: перенести большую часть бремени на машину — значит упростить жизнь для нас. Звучит разумно, если источником трудностей вы считаете необходимость использовать формальный символизм. Но обоснованно ли это утверждение? Сомневаюсь. Между тем мы знаем, что выбор интерфейса — это не просто перераспределение (фиксированного количества) труда: здесь добавляется работа по обмену данными и взаимодействию через интерфейс. По горькому опыту мы знаем, что смена интерфейса может запросто увеличить (порой радикально) объем работы, которую необходимо производить по обе стороны от него. Потому все большее предпочтение отдается тому, что сейчас называется «узкими интерфейсами». Поэтому, хотя переход к взаимодействию между машиной и человеком на родном языке значительно увеличил бы нагрузку именно на машину, мы должны критически оспорить то допущение, что это облегчило бы жизнь человека. Краткий взгляд на историю математики показывает, насколько оправдана эта критика. Греческая математика зашла в тупик, потому что оставалась словесной, наглядной деятельностью. Мусульманская «алгебра», после робкой попытки обратиться к символизму, зачахла, вновь вернувшись к риторическому стилю. А современный цивилизованный мир смог возникнуть — к лучшему или к худшему — только тогда, когда Западная Европа смогла освободиться от оков средневековой схоластики (безуспешной попытки добиться словесной точности) благодаря тщательно или, по крайней мере, сознательно разработанным формальным символизмам, которыми мы обязаны таким людям, как Виет, Декарт, Лейбниц и (позднее) Буль. Достоинство формальных текстов заключается в том, что для разумного обращения с ними достаточно следовать нескольким простым правилам; если подумать, это удивительно эффективный инструмент по избавлению от всевозможной ерунды, которой практически не избежать при общении на родном языке. Вместо того чтобы считать обязательство пользоваться формальными символами бременем, следует относиться к удобству их использования как к преимуществу: благодаря им школьники могут освоить то, что в прежние времена удавалось только гениям. (Этого, очевидно, не понимал автор, который в 1977 году написал в предисловии к техническому докладу, что «даже базовые символы, используемые в логических функциях, опущены ради ясности». Само появление этого предложения говорит о том, что непонимание автора свойственно не ему одному). После всего сказанного понятно, что «естественность» использования наших родных языков сводится к легкости, с которой мы можем использовать их для утверждений, бессмысленность которых не очевидна. Может быть поучительным помыслить, что было бы, если с самого начала наш родной язык был бы единственным средством ввода и вывода для нашего оборудования по обработке информации. Полагаю, что история в некотором смысле повторилась бы, и компьютерная наука преимущественно выражалась бы в чернокнижных стараниях пробиться от этого языка к достаточно хорошо определенной формальной системе. Понадобился бы весь интеллект мира, чтобы сделать этот интерфейс достаточно узким, чтобы быть пригодным, а, учитывая историю человечества, не будет слишком пессимистичным допустить, что для того, чтобы сделать эту работу достаточно хорошо, потребовалось бы еще несколько тысяч лет. Примечание. Как результат тенденции в образовании к уходу от интеллектуальной дисциплины, последние десятилетия показали резкое снижение в западном мире уровня владения людьми своим родным языком: многие люди, которые по меркам предыдущего поколения должны были владеть языком лучше, больше не в состоянии эффективно использовать свой родной язык, даже для целей, которым он вполне соответствует. (Достаточно взглянуть на и впрямь тревожащий объем бесцельного пустословия в научных статьях, технических докладах, правительственных публикациях и т. д.) Это явление, известное как «новая неграмотность», должно оттолкнуть тех сторонников программирования на естественном языке, которым не хватает технической проницательности предвидеть его провал. (Конец примечания.) Одна мысль меня очень утешает: я полагаю, что машины, которые могут программироваться на наших родных языках, будь то голландский, английский, американский, французский, немецкий или суахили, будет так же чертовски трудно создать, как и использовать. профессор, доктор Эдсгер В. Дейкстра, научный сотрудник компании BurroughsСсылка на первоисточник. ОтсебятинаПрограммирование на естественном языке — весьма обязывающее понятие. Если кому-то удастся написать компилятор для какого-то подмножества естественного языка, то эта попытка — незачёт. Входным языком компилятора должен быть весь язык целиком, а не какое-то узкое и удобное для разработки подмножество. Любой человек, разговаривающий на своём родном языке, будет в недоумении, если столкнётся с ограниченностью этого языка и компилятора для него. Ведь разработчику, программирующему на естественном языке, придётся учить подмножество родного языка, который окажется сложнее искусственного. Сложность будет связана с неясностью, где пролегает граница между той частью языка, которая поддаются компиляции и той, которая не поддаётся. Человеку будет трудно почувствовать эту границу. С искусственными же языками такой трудности нет. У них есть чёткое формальное описание. Но даже чёткий формализм языка всё равно не уберегает разработчиков от ошибок (читаем блог «PVS-Studio»). Что ж тогда говорить о программах на естественном языке? Если же естественный язык будет полностью поддаваться компиляции, то компилятор будет обладать просто чудовищной сложностью. Будет очень трудоёмко его и написать, и отладить, и поддерживать. Пока что куда более перспективным видится применение нейросетей в качестве помощников в написании кода. Читая техническое задание на естественном языке, они пишут код на языке программирования. Ниже показан код на Питоне, написанный нейросетью.
Знаю, что ведутся хобби-проекты разработки компиляторов или интерпретаторов, где входным языком будет русский. Но вряд ли уместно кого-то предостерегать от ошибки, у каждого своё мнение и видение. Опубликовано: 2022.03.27, последняя правка: 2022.03.28 14:21
Отзывы
Ежели икс будет поболее игрека, да не менее, чем на сотню, то пусть зет будет такой же, как и икс. А ежели он будет поболее только на дюжину, то быть зету одинаковому с игреком. Но зет ещё может быть, как икс вместе с игреком, но это только тогда, когда икс будет тютелька в тютельку с игреком. И не дай бог иксу быть меньше игрека, ибо в зет вообще ничего не будет. На каком языке написано? На русском? Компилятор с русского языка в машинный это должен щелкать, как семечки. А вот то же самое на буржуйском Си:if (x > y + 100) z = x;Нет, буржуйский мы не так хорошо понимаем. То ли дело по-нашенски.
Нет, буржуйский мы не так хорошо понимаем В данном случае "буржуйская запись" нарушает два правила хорошего программирования:1. Операторы управления можно использовать только тогда, когда нельзя ни вычислить, ни составить таблицу. 2. Число строк не должно быть больше, чем различий в них. (Напомнило старый FORTRAN-овский анекдот: длинный-длинный листинг IF-ов, вроде приведенных, который завершается комментарием: "Z УШЛО В <нецензурно>". И для исправления этого следует начать понимать "по-нашенски".
Входным языком компилятора должен быть весь язык целиком, а не какое-то узкое и удобное для разработки подмножество. Любой человек, разговаривающий на своём родном языке, будет в недоумении, если столкнётся с ограниченностью этого языка и компилятора для него. Ведь разработчику, программирующему на естественном языке, придётся учить подмножество родного языка, который окажется сложнее искусственного. В действительности-то все наоборот. Любой человек сильно удивится мату или каким-то эмоциальным междометиям в финансовой, юридической или инженерной документации, даже написанной на естественном языке.Хоть общевойсковой устав (который даже прям для совсем срочников без спец. образования), хоть конституция, хоть уголовный кодекс — ну нет там большой части естественного языка и она была бы там странной. Аналогично для точной машины будут просто бессмысленными выражения человеческих эмоций и люди в целом вполне справляются писать тексты без них. Если кому-то удастся написать компилятор для какого-то подмножества естественного языка, то эта попытка — незачёт. Никакой технической информации такие эмоции по поводу признания чего-то не передают. Некоторые, например, не признают короновирус или ВИЧ, в то время как другие их изучают, разрабатывая вакцины и лекарства.
Если кому-то удастся написать компилятор для какого-то подмножества естественного языка, то эта попытка — незачёт Кстати, да. Согласно заразе Гёделю, полная компиляция даже неестественных языков невозможна.
Хоть общевойсковой устав (который даже прям для совсем срочников без спец. образования), хоть конституция, хоть уголовный кодекс — ну нет там большой части естественного языка и она была бы там странной. Срочникам не приходится писать устав, а только читать. А программистам надо будет именно писать. Им всё время надо будет определять, входит некая словесная конструкция в «программистское» подмножество языка или нет. Надо будет либо полагаться на интуицию, либо на знание этого подмножества, которое само по себе не маленькое — гораздо больше, чем какой-либо искусственный язык. И выходит, что изучить и применять искусственный язык проще.полная компиляция даже неестественных языков невозможна А никто не ставит такой задачи — компилировать все языки. Достаточно компилировать такие, которые ограничены какими-то правилами.
Им всё время надо будет определять, входит некая словесная конструкция в «программистское» подмножество языка или нет Среды разработки это давно умеют.Надо будет либо полагаться на интуицию, либо на знание этого подмножества Но программисты этим занимаются, читая документацию и всевозможные подсказки. Никто не учит все множества библиотек наизусть — используется поиск и среда разработки.которое само по себе не маленькое — гораздо больше, чем какой-либо искусственный язык. Количество служебных слов в естественных языках невелико и сопоставимо с количеством ключевых в языках программирования. А там ещё и синонимов среди них немало, т.е. даже все они не нужны для описания полноценного ЯП. По сути разница будет зависеть лишь от набора функциональности и дублирования синонимами.Срочникам не приходится писать устав, а только читать. Программистам приходится намного чаще читать чужой код, а не писать свой.изучить и применять искусственный язык проще Для простых задач, особенно решаемых одним единственным человеком. Ключевая ошибка Дейкстры — ошибка в масштабировании. Пока задача мелкая — можно именовать идентификаторы x,y,z... Когда она становится большой — нужны понятные названия, иначе производительность коллектива катастрофически падает, а документация внезапно оказывается неполной.Вот для производительности и наглядности на бумаге критически важны были короткие символьные обозначения. Но далеко не всегда догадывались даже прикладывать к таблицам шапки, чтобы не перепечатывать их на каждом листе. Помню также на одной из математических дисциплин в алгоритме решения задачи таблица перерисовывалась по сути дела с одними и теме же данными, а можно было просто добавить дополнительный индекс в ячейки. В целом же математика — почти сплошь работа одиночками, в отличие от современного программирования.
Ключевая ошибка Дейкстры — ошибка в масштабировании Это ошибка не Дейкстры, а его толкователей. Структурное программирование и программирование масштабированием — это разные вещи.В целом же математика — почти сплошь работа одиночками, в отличие от современного программирования Это опять про "Теорему о бесконечных обезьянах". Замена в "современном программировании" одного программиста сотней ИТ-шнников, это как замена одного кассира сотней операторов.
Если нейросети уже сейчас по словесному описанию (человек сформулировал ТЗ на естественном языке) выдают вполне приемлемый код, то почему бы это не считать программированием? Может потому что это не программирование, а максимум быстрый поиск подготовленного ранее решения для шаблонной задачи?Или потому что возникает некоторые лукавство с понятием "естественного языка", который также должен быть жестко ограниченным для НС, или с приемлемостью решения? Это может быть частью процесса программирования, конечно, но будет ли оно полноценным? Многие программные задачи могут быть решены без непосредственного написания кода. Но их класс либо ограничен, либо содержит вставку шаблонных конструкций обычных ЯП в том или ином виде. Какое подмножество естественного языка при этом используется — уже не особо важно, нейросеть натаскивается на любой язык. Нейросеть не натаскивается на язык, она натаскивается на соответствия м/у шаблонами. Также как с поиском в интернете — если ясно, что вопрос решаем и наверняка задавался уже много раз — поиск почти наверняка будет успешен.
Это опять про "Теорему о бесконечных обезьянах". Замена в "современном программировании" одного программиста сотней ИТ-шнников, это как замена одного кассира сотней операторов. И тем не менее в "языке обезьян" за миллионы лет эволюции выработались более развитые конструкции, а вот программисты ничего нового добавить к ним не смогли и даже существующие пока не все реализовали.
Я так думаю, что если взять и реализовать морфологию упрощённого русского Если он упрощенный, то естественный язык теряет свою естественность.Что именно программировать? А вот это самое -- модели предметной области, модели данных, базу данных и отношений домена Т.е. то, что никому не надо программировать, а можно взять готовое из коробки.
Лисп-версии выигрывают везде Только в задачах, решаемых путем обратной цепочки рассуждений. Для постепенного сбора решения от частного к общему функциональные языки не годятся.
а какие годятся? Зависит от метода программирования (см. последний пост в теме Форт). Но всяко полезно наличие как развитого механизма данных (для прямого рассуждения), так и настраиваемого механизма вызова функций (для обратного). Самое главное в программировании — удачный баланс одного с другим для решения конкретной задачи. И, наоборот, фиксация на определенных парадигмах данных и процедур — признак быдло-кодирования.всё это программирование шаблонами без осмысления -- оно того, второй свежести Однако, ничего другого уже полвека мы не видим.
"программирование масштабированием" — это ещё куда? Смотри последний пост в теме Форт
а я видел. Дональд Кнут, Literate Programming Это как раз "масштабирование".Кстати, Лео Броуди Броуди просто не смог перейти к чему-то сложному. Что дает "фортерам" основания считать, что FORTH только и годится на что-то очень простое. Мур все-таки по-началу смотрел дальше.
и почему бы эдакий поиск вот и не делать полуавтомаГически Потому, что в этом и состоит искусство программирования. Автоматическим можно сделать остальное, но не это.
искусство, ремесло, технология или наука? "Искусство" здесь только синоним "человеческого решения".Ремесло? Ремесло — это сначала уметь сделать что-то руками, и только потом, для облегчения жизни, уметь это запрограммировать. Технология? Технология только определяет "окно" в котором программирование чего-то — полезного самого по себе — окупается. Наука? Тогда Вы не с того начали. Выбросьте все эти абстракции и тупо начинайте с Машины Тьюринга.
ок, значит, бывают и нечеловеческие Нет. Не в этом смысле.в моём понимании... я понимаю, так: исскусство там, где творчество Попробуйте что-нибудь сделать руками.можно, но зачем? Чтобы начать понимать.
Что же касается самого языка… Вот примерчик на нём: After taking the trophy:Или по-русски: После взятия трофея:То есть ещё многословнее Кобола. Что ещё раз подтверждает правильность заголовка статьи.
То есть ещё многословнее Кобола А как бы Вы написали это по-русски, если бы, допустим, издавали правила настольной игры?
В приведённом выше примере — инструкция для компьютера, а не для человека. Но странно её писать так, как будто между человеком и компьютером нет разницы.
Но странно её писать так, как будто между человеком и компьютером нет разницы Во-первых, до того, как начата отладка, Вы пишете, в основном, для себя.Во-вторых, другим тоже может понадобится прочесть Ваш код. Иначе мы бы до сих пор писали в маш.кодах. Но я не об этом. Разве не естественно хотеть, чтобы была возможность не просто констатировать Трофей(5,"Молодец"), а описать контекст этого действия: от: "Тоже самое на 5" до: "Брезгливо потыкав разлагающийся труп носком лакированного ботинка... <еще два абзаца>... — Ну, и? Пять грошей? Не прогадал!" Именно для этого нужен естественный язык, а не для "обучения англофобов".
Во-первых, до того, как начата отладка, Вы пишете, в основном, для себя. Для себя информация должна быть оптимальной: как избыточность, так и недостаточность вредят.Во-вторых, другим тоже может понадобится прочесть Ваш код. Поэтому мой код не должен быть замусорен комментариями. Они там должны появляться в крайних случаях, когда что-то недостаточно прозрачно. В идеале комментарий к, допустим, функции должен содержать описание входных и выходных параметров. Язык программирования сам по себе должен быть «говорящим». Если написатьсчёт += 5то какие могут быть вопросы? А в увеличить счет на 5;слишком много мусора. описать контекст этого действия Контекст передаётся внутрь функций через параметры. Иначе нарушается принцип «чёрного ящика» для функции. Она не должна зависеть от контекста иначе, чем через параметры.Именно для этого нужен естественный язык Он нужен для написания ТЗ. А после написания нестрогие и неформальные словеса начинают втискивать в строгие формальные рамки. После написания программы опять наступает очередь естественного языка — на нём пишут инструкции для пользователей.
счёт += 5... какие могут быть вопросы? Например, почему на 5? В играх, о которых идет речь, константы обычно подгоняются по результатам тестирования. Возможна и приписка, типа: "В проклятой долине сила всех врагов увеличивается на 2".Контекст передаётся внутрь функций через параметры. Иначе нарушается принцип «чёрного ящика» для функции. Она не должна зависеть от контекста иначе, чем через параметры Это только в вакууме. Вчера я, например, пару минут тупо смотрел на не желающую компилироваться константу, пока меня не осенило, что она определена в ресурсах диалога, о котором я давно забыл.Он нужен для написания ТЗ И если язык программирования подобран удачно, более ничего и писать не надо.
https://ring-lang.github.io/doc1.17/naturallibrary.html https://ring-lang.github.io/doc1.17/natural.html По первой и второй ссылке видны примеры "программирования на естественном языке", Natural Language Programming https://ring-lang.github.io/doc1.17/faq.html https://ring-lang.github.io/ https://rosettacode.org/wiki/Category:Ring https://en.wikipedia.org/wiki/PWCT Programming Without Coding Technology (PWCT) is designed to be a general-purpose visual programming language that can be used for applications and systems development. реализация Ring (компилятор+VM) выполнена на PWCT:https://en.wikipedia.org/wiki/Ring_(programming_language) The Compiler and the Virtual Machine are designed using Visual Programming through the Programming Without Coding Technology software then the C code is generated. In 2009, Mahmoud Samir Fayed created a minor domain-specific language called Supernova that focuses on User interface (UI) creation and uses some ideas related to Natural Language Programming, then he realized the need for a new language that is general-purpose and can increase the productivity of natural language creation. Ring aims to offer a language focused on helping the developer with building natural interfaces and declarative DSLs.
Была на Хабре статья «Доказательное программирование», где автор требует от разработчиков новых языков доказывать превосходство своего языка, основываясь на фактах его применения. Мои вопросы выше — в том же духе.
Может потому что это не программирование, а максимум быстрый поиск подготовленного ранее решения для шаблонной задачи? Перекликается с этой темой:Плагин изначально обучен на миллионах репозиториев GitHub’а (ну, они так утверждают) для пары десятков популярных языков программирования (C++, Java, Python, Bash и т.д.). Но также может обучаться и на открытом в IDE проекте.
пользовались своей собственной машиной, «Наири». Машина была армянского происхождения, и позволяла вводить программы не только в кодах, а и на внутреннем языке программирования — кириллическом, но с соответствующим акцентом. Вот из-за этого акцента и произошла следующая история. Написанные и отлаженные программы обсчета элементов собирали воедино и издавали в виде печатных брошюр, которыми пользовались для переноса программ на другие машины или для последующей работы. К изданию брошюр подходили ответственно, и перед публикацией тщательно их вычитывали. Однажды сборник программ для «Наири» попал в руки корректора, который не очень представлял себе её язык программирования, но очень болел душой за чистоту русского языка в рядах программистов. Результат? «Вычитанные» программы, идеально правильные с грамматической точки зрения, напрочь перестали работать на языке «Наири».
Однажды сборник программ для «Наири» попал в руки корректора, который не очень представлял себе её язык программирования, но очень болел душой за чистоту русского языка в рядах программистов. Результат? «Вычитанные» программы, идеально правильные с грамматической точки зрения, напрочь перестали работать на языке «Наири». Вы действительно думаете, что после правки англоговорящим литературным корректором программы на любом из современных и не очень языке программирования она сможет хоть как-то продолжить работать, или быть оттранслирована без ошибок? ;)
В пределах идентификатора соблюдать правила языка можно и нужно, а вот согласовывать между идентификаторами склонения, спряжения да падежи — это глупая затея. Например: int число_просмотренных_элементов_массива;Кто будет следить за соблюдением правил русского языка? Компилятор?
В пределах идентификатора соблюдать правила языка можно и нужно, а вот согласовывать между идентификаторами склонения, спряжения да падежи — это глупая затея. Прописывать несогласованные окончания тоже умной не назовёшь.
прописывать несогласованные окончания тоже умной не назовёшь Во-первых, нет ответа, кто будет следить за согласованностью окончаний. Критиковать несогласованность легко. Но есть ли где-то софт, который эту проблему решает?Во-вторых, в рамках идентификаторов окончания согласованы вручную. Это сделал разработчик, а не инструменты: int число_просмотренных_элементов_массива;В рамках условного выражения несогласованные окончания конечно же нарушают правила русского языка. Но эти правила нарушаются ещё и операцией проверки равенства «=» — этого символа нет среди знаков пунктуации русского языка. Если не можем обеспечить точного соблюдения правил в одном месте, то какой смысл в их соблюдении в другом? В языках программирования обычно в скобки берут список параметров. Но это противоречит правилам русского языка! Скобки в русском языке предназначены для другого. Программирование ступеньками даёт возможность визуально оформлять конструкции в программе. Но такие ступеньки мы не увидим ни у Толстого, ни у Чехова. Есть ступеньки у Маяковского, но у них другое назначение. В русском языке нет символов ` ~ @ # $ ^ & _ = + | \ < >А те, что есть, часто употребляются в языках программирования по иным правилам. Но поскольку языки программирования являются искусственными языками, то мы имеем право в рамках компромисса использовать все символы клавиатуры. И не делать идентификаторы видоизменчивыми, чтобы не усложнять компиляцию.
Вы радеете, чтоб в языке программирования комар носа не подточил, а сами пишете тяп-ляп. Могу сказать, что если появится безупречный с Вашей точки зрения русский Алгол, то Вам придётся исправлять за собой много ошибок: там пунктуация страдает, сям Вы не любите писать с большой буквы имена собственные или начало предложения и т.д. Вы будете несовместимы с таким совершенным инструментом.
Но поскольку языки программирования являются искусственными языками, то мы имеем право в рамках компромисса использовать все символы клавиатуры. И не делать идентификаторы видоизменчивыми, чтобы не усложнять компиляцию. Т.е. хотя самая простая компиляция достигается скобочной парой, усложнять её кучей символов с клавиатуры можно, а видоизменением слов нельзя?Тут Лис мог бы написать, что это другое, и мы чего-то не понимаем в рамках идентификаторов окончания согласованы вручную. Это сделал разработчик, а не инструменты Вот у людей в жизни одна выдуманная проблема — понаписать ненужного и рассуждать что же с этим делать. А ведь есть и Delete и Backspace.
int общее_число_элементов_массива;то он внесёт «общее_число_элементов_массива» в таблицу идентификаторов. Но дальше, когда он встретит условное выражение если число_просмотренных_элементов_массива = общему_числу_элементов_массивато поймёт, что идентификатор «общему_числу_элементов_массива» в таблице идентификаторов отсутствует. То есть налицо ошибка, поскольку в мире нет ни одного компилятора, который умеет работать со спряжениями, склонениями и прочими падежами. Хорошо, допустим, мы сделали такой компилятор. Но как он поймёт, в каком падеже должен быть идентификатор справа от операции проверки равенства? Как он должен истолковать знак «=», какое значение ему приписать? Его можно заменить как словом «равно», так и словами «такой же как». В первом случае после знака «=» должны употребить родительный падеж, а во втором — именительный. Или взять знак «<». Его можно заменить на «меньше» и на «меньше чем». После них опять разные падежи — родительный и именительный. А компилятору что делать? Назовите хотя бы одну разумную стратегию. Знаков «=» и «<» нет в русском языке и нет для них правил. Если мы придумываем для них правила, то мы придумаем искусственный язык «а-ля рюс», который вовсе не русский. Для которого нет ни правил, ни учебников. Как его изучить? Написать автору можно на электронную почту |
2022/04/27 23:03, Неслучайный читатель