Здравствуйте, netch80, Вы писали:
N>Регэкспы — давно не вкладываются в регулярные грамматики.
Что значит не укладываются? 90% языков вполне укладываются, а еще 9% вполне себе покрываются простеньким хаком с переключением контекста лексера из парсера. Изобретать DSL, которому этого недостаточно — должна быть очень веская причина.
N>PEG используется каждым вторым.
Да ну нафик. PEG в чистом виде имеет совершенно непотребное O, а всякие вариации на тему packrat я пока не заметил чтобы стали прям так уж распространенными.
Вобщем, классические лексеры на регулярке пока вполне работают и дают очень неплохие результаты. Там проблема больше не с выразительностью, а с честной поддержкой юникода, не говоря уж о 32 битных вариациях. Старые алгоритмы сильно замедляются на 16 битах (я уж не говорю про 32), замена автомата на if (в antlr вроде так) заметно замедляет (хотя в сравнении с PEG разницы нет), а переход на диапазоны работает, но повышенный риск взрывного роста состояний ДКА остается проблемой.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>При чём тут шелл?
НС>При том что эта фича в основном на запуск из шелла заточена.
С чего такой вывод? Shebang ещё с 80-х универсальный формат пометки "тип содержимого".
N>>соответственно "формат foo, версия 3". Транслятор видит пометку и переключается в соответствующий режим, редактор на них реагирует, и всё такое. НС>Ну вот о том и речь, что совершенно служебные вещи тащим в исходник.
Что в этом служебного?
НС>>>Что значит организовать весь проект N>>Как в C, один файл с main() и ссылками на прочие декларации и/или исходники. НС>Зачем? Почему не сделать файл проекта отдельным, не создавая ненужного шума в исходниках?
Что такое "файл проекта" и какое отношение он имеет к такому исходнику?
НС>>> и при чем тут дизайн DSL? Чем больше ты всякой ерунды напихаешь в DSL, тем менее удобным он будет. N>>Это верно ровно до тех пор, пока это действительно "ерунда", а не необходимые вещи.
НС>
НС>Главный критерий языка — удобство его использования человеком.
Абсолютно верно. Вот и ставится пометка типа содержимого, которая понятна человеку не меньше, чем автосредствам.
НС>Вещам, необходимым трансляторам и редакторам, в исходниках, которые пишет и читает человек, не место
Здравствуйте, netch80, Вы писали:
N>Что в этом служебного?
Эта информация не имеет никакого отношения к domain.
НС>>Зачем? Почему не сделать файл проекта отдельным, не создавая ненужного шума в исходниках? N>Что такое "файл проекта" и какое отношение он имеет к такому исходнику?
Это такой специальный файл,. в который выносится вся информация, которая нужна для сборки или дизайн-тайма, и не нужна для семантики исходников, связанной с целевым доменом.
N>Абсолютно верно. Вот и ставится пометка типа содержимого, которая понятна человеку не меньше, чем автосредствам.
ПОнятна не означает что нужна.
НС>>Вещам, необходимым трансляторам и редакторам, в исходниках, которые пишет и читает человек, не место N>И строгой грамматике — тоже?
Если сможешь написать тулу, которая сможет обходится без нее — конечно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, netch80, Вы писали:
N>>Регэкспы — давно не вкладываются в регулярные грамматики.
НС>Что значит не укладываются? 90% языков вполне укладываются,
Большинство движков регэкспов давно содержат фичи типа negative lookahead или ссылок типа \1.
НС> а еще 9% вполне себе покрываются простеньким хаком с переключением контекста лексера из парсера. Изобретать DSL, которому этого недостаточно — должна быть очень веская причина.
Если вы _внимательно_ прочитаете моё сообщение, то увидите, что оно было в контексте классификации Хомского, а не темы данного DSL или DSL вообще.
N>>PEG используется каждым вторым.
НС>Да ну нафик. PEG в чистом виде имеет совершенно непотребное O, а всякие вариации на тему packrat я пока не заметил чтобы стали прям так уж распространенными.
Вот именно что тех случаев, когда PEG уходит в высокие выси по времени работы, практиками систематически и достаточно интуитивно избегаются. Зато их привлекают принципы оформления правил.
И packrat в движках вокруг меня уже типовой вариант (вон недавно гонял tatsu... не пошёл, но причина не связана с грамматикой).
НС>Вобщем, классические лексеры на регулярке пока вполне работают и дают очень неплохие результаты. Там проблема больше не с выразительностью, а с честной поддержкой юникода, не говоря уж о 32 битных вариациях. Старые алгоритмы сильно замедляются на 16 битах (я уж не говорю про 32), замена автомата на if (в antlr вроде так) заметно замедляет (хотя в сравнении с PEG разницы нет), а переход на диапазоны работает, но повышенный риск взрывного роста состояний ДКА остается проблемой.
Видимо, это проблема средств вокруг вас (C# и прочее, да?)
Всё, что я в пару последних лет смотрел, этим не страдает — юникод это просто факт нижнего уровня, std::u32string в C++, unicode (str) в Python и так далее. Главное — не забывать вовремя вызывать нормализацию идентификаторов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, netch80, Вы писали:
N>>Что в этом служебного?
НС>Эта информация не имеет никакого отношения к domain.
Расшифруйте, что именно из N+1 смыслов этого слова имеете в виду именно тут.
НС>>>Зачем? Почему не сделать файл проекта отдельным, не создавая ненужного шума в исходниках? N>>Что такое "файл проекта" и какое отношение он имеет к такому исходнику? НС>Это такой специальный файл,. в который выносится вся информация, которая нужна для сборки или дизайн-тайма, и не нужна для семантики исходников, связанной с целевым доменом.
Тогда вам следовало бы прочитать с самого начала, что речь идёт не о "файле проекта" в этом смысле, а о главном исходнике проекта.
N>>Абсолютно верно. Вот и ставится пометка типа содержимого, которая понятна человеку не меньше, чем автосредствам. НС>ПОнятна не означает что нужна.
Ваше предложение по альтернативе? Имя файла, как уже говорил, подходит далеко не всегда.
НС>>>Вещам, необходимым трансляторам и редакторам, в исходниках, которые пишет и читает человек, не место N>>И строгой грамматике — тоже? НС>Если сможешь написать тулу, которая сможет обходится без нее — конечно.
Здравствуйте, netch80, Вы писали:
НС>>Что значит не укладываются? 90% языков вполне укладываются, N>Большинство движков регэкспов давно содержат фичи типа negative lookahead или ссылок типа \1.
И? Насколько эти фичи востребованны для лексического анализа DSL?
N>Если вы _внимательно_ прочитаете моё сообщение, то увидите, что оно было в контексте классификации Хомского, а не темы данного DSL или DSL вообще.
Ну и зачем оно в топике про DSL?
N>Видимо, это проблема средств вокруг вас (C# и прочее, да?)
Ну да, если аргументов нет то надо искать проблемы в собеседнике.
N>Всё, что я в пару последних лет смотрел, этим не страдает — юникод это просто факт нижнего уровня
Вопрос в том как устроен его анализ. Если внутри лексера не копаться то да, просто факт.
N>, std::u32string в C++, unicode (str) в Python и так далее.
И? Дальше то что? Оставаться на НКА и не строить ДКА, как большинство движков для регексов делают? Для парсеров языков это не очень хорошая стратегия часто.
Здравствуйте, netch80, Вы писали:
НС>>Эта информация не имеет никакого отношения к domain. N>Расшифруйте, что именно из N+1 смыслов этого слова имеете в виду именно тут.
Ну пипец. Название темы прочти.
N>Тогда вам следовало бы прочитать с самого начала, что речь идёт не о "файле проекта" в этом смысле, а о главном исходнике проекта.
Да понимаю я о чем ты тут пишешь. А вот ты меня — нет. Вопрос не в том что это за исходник, а в том насколько это удобно по сравнению с вариантом, когда нет никакого главного файла, а вся информация о сборке находится отдельно, а не в целевом DSL.
НС>>>>Вещам, необходимым трансляторам и редакторам, в исходниках, которые пишет и читает человек, не место N>>>И строгой грамматике — тоже? НС>>Если сможешь написать тулу, которая сможет обходится без нее — конечно. N>"Мышки, станьте ёжиками" ™.
Можно расшифровать суть твоей претензии и как она стыкуется с разговором?
Здравствуйте, Marty, Вы писали:
M>Точнее — парсинг и построение AST
M>Хочу понять, как таки это делать правильно и быстро.
Я бы на antlr делал. У него даже сообщения об ошибках не самые плохие.
ИМХО построение AST это самое скучное. А вот что дальше с этим AST делать уже интересно. В тот же байткод его откомпилировать. Да ещё если система типов есть.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Если вы _внимательно_ прочитаете моё сообщение, то увидите, что оно было в контексте классификации Хомского, а не темы данного DSL или DSL вообще.
НС>Ну и зачем оно в топике про DSL?
Почему нет? Тут нормально, что тема локального разговора мигрирует в широких пределах вокруг исходной.
А вот не понять, что разговор ушёл на более общую тему — вот это точно неуместно.
НС>>>Что значит не укладываются? 90% языков вполне укладываются, N>>Большинство движков регэкспов давно содержат фичи типа negative lookahead или ссылок типа \1. НС>И? Насколько эти фичи востребованны для лексического анализа DSL?
Сильно зависит от того, какой DSL. Новые, да, лучше так не писать, но есть до чёрта всякого наследия.
N>>Видимо, это проблема средств вокруг вас (C# и прочее, да?) НС>Ну да, если аргументов нет то надо искать проблемы в собеседнике.
Ещё не начинал. Хотя давно удивляюсь специфике вашего взгляда.
N>>Всё, что я в пару последних лет смотрел, этим не страдает — юникод это просто факт нижнего уровня НС>Вопрос в том как устроен его анализ. Если внутри лексера не копаться то да, просто факт.
Мне достаточно того, что лексер умеет определять границы кодпунктов в том, что поступает на вход (в >99% случаев это utf-8). Проблемы с алгоритмами движения по тексту в utf-8 были решены ещё лет 15 назад.
Если вы знаете какие-то интересные проблемы на этом, расскажите, но только если они не специфичны для дотнета.
N>>, std::u32string в C++, unicode (str) в Python и так далее. НС>И? Дальше то что? Оставаться на НКА и не строить ДКА, как большинство движков для регексов делают? Для парсеров языков это не очень хорошая стратегия часто.
Не совсем понял связь. По-вашему ДКА предполагает построение полной таблицы символов для лукапа, то есть 256 при восьмибитке и 64K при 16-битке?
Ну взгляните тогда хотя бы на re2c, он делает ДКА и любой юникод принимает без проблем. А вообще "кто хочет, ищет метод, а кто не хочет, ищет причину" — варианты всяких деревьев лукапов с оптимизацией для характерных диапазонов значений известны ещё со времён, когда Кнут был молодым.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Эта информация не имеет никакого отношения к domain. N>>Расшифруйте, что именно из N+1 смыслов этого слова имеете в виду именно тут. НС>Ну пипец. Название темы прочти.
Ну пусть не имеет. Откуда идея, что весь файл целиком должен представлять только то, что "имеет отношение к domain"?
N>>Тогда вам следовало бы прочитать с самого начала, что речь идёт не о "файле проекта" в этом смысле, а о главном исходнике проекта. НС>Да понимаю я о чем ты тут пишешь. А вот ты меня — нет. Вопрос не в том что это за исходник, а в том насколько это удобно по сравнению с вариантом, когда нет никакого главного файла, а вся информация о сборке находится отдельно, а не в целевом DSL.
Так мы этого просто не знаем без подробного знания как о специфике его задачи, так и об исполнителях. Может, там опрос показал, что им лучше так.
Типовые решения типа "правило интерпретации в имени, конфигурация сборки в выделенных файлах, каталоги src/ doc/ и т.п.", пригодные программистам, могут быть неудобны специалистам со специфическим бэкграундом. Завтра придут такие, кому вообще нужен один XLS на 100 страниц, и чтобы проект строился как UML схема включения между другими страницами (потому что им нужно быстро менять связи).
НС>>>>>Вещам, необходимым трансляторам и редакторам, в исходниках, которые пишет и читает человек, не место N>>>>И строгой грамматике — тоже? НС>>>Если сможешь написать тулу, которая сможет обходится без нее — конечно. N>>"Мышки, станьте ёжиками" ™. НС>Можно расшифровать суть твоей претензии и как она стыкуется с разговором?
Обычно не окупается. И ещё и имеет тяжёлые проблемы с развитием языка.
Здравствуйте, Marty, Вы писали:
M>Хочу понять, как таки это делать правильно и быстро.
Тебе очень не хватает хоть минимального понимания теории вопроса.
Синтаксический анализ формальных языков — очень хорошо исследованнаа область знаний. Тут надо просто взять хорошую книжку, и ее прочитать. И немного попрактиковаться. Написать самому несколько парсеров, без помощи lex/yacc, или их более современных аналогов, чтобы осознать, что вообще происходит.
Следует понимать, что с тех пор, как синтаксический анализ получил свою теоретическую базу, современные языки программирования стали проектироваться с учетом удобства их синтаксического разбора.
Реально есть некоторый баланс между удобством синтаксического разбора и удобством использования языка человеком. Например, LISP очень удобно синтаксически разбирать, но пользоваться неудобно. C++ — пример неудачного во всех смыслах языка, и парсить тяжело, и писать/читать тяжело. Go, Pascal — легко парсится, легко читается. Ну и т.д.
Далее, AST — это способ внутреннего представления результата синтаксического анализа. Собственно, синтаксический анализ и AST — ортогональные в определенном смысле вещи. Можно представить себе вполне полезный парсер, который не строит AST. Например, если единственное назначение парсера — проверить синтаксис на отсутствие ошибок и подкрасить текст в разные цвета, AST не нужен. Но если с текстом предполагается делать более серьезную обработку, AST — удобная структура.
Здесь тоже имеется баланс между удобством содержательной обработки и удобством диагностики. Чтобы сделать кодогенерацию для языка типа C, достаточно разбить программу на операторы, а выражения — на операции и операнды, сгруппировав их по порядку вычисления с учетом приоритетов операций. Но чтобы правильно высказаться, когда у тебя в глубине выражения выявилась смысловая ошибка (скажем, типы операндов не сошлись), надо до самого последнего момента хранить информацию о том, что пришло из какого файла и из какой строки (а желательно и положение в строке). Необходимость сохранения этой информации усложняет структуру AST, но делает диагностику куда как более вменяемой.
Что до инструментов, типа lex/yacc. lex — штука простая и удобная. Что до yacc, с одной стороны, очень удобно писать грамматику в виде варианта нормальной формы Бэкуса-Наура, и горя себе не знать. С другой стороны, практически полезный парсер должен разумно себя вести, наткнувшись на синтаксическую ошибку. Скажем, пропустили закрывающую скобку — с формальной точки зрения, это невалидный текст, достаточно сказать "syntax error", и завершиться. Если продолжать, наивно написанный парсер на yacc потеряет синхронизацию с текстом, и выдаст тебе еще по ошибке на каждую строку. Хорошо написанный парсер пропустит кусок текста, восстановит синхронизацию и дальше будет выдавать только новые ошибки, а не кучу "наведенных". Как это сделать — это искусство, а не наука, универсального ответа тут, к сожалению, нет. Но для человека это очень удобно, поскольку выдает разумную диагностику. Если посмотреть, многие широко используемые компиляторы начинали с парсера, написанного на инструменте типа yacc, но потом в какой-то момент парсер переписывался руками.
По моему опыту, написать с нуля вменяемый парсер руками и на yacc'е требует сравнимых усилий. Но если на момент написания парсера синтаксис до конца не устаканился, и возможны изменения в языке, парсер на yacc'е проще поддерживать, внося небольшие изменения в язык.
Далее, кроме синтаксического анализа, есть еще и семантический (смысловой). Когда программист пытается засунуть строку в целочисленную переменную, или описать переменную несуществуещего типа, такие ошибки ловятся уже после синтаксического разбора (а в некоторых альтернативно одаренных языках программирования вообще во время исполнения). Но есть неудачные языки, типа того же C++, в которых синтаксический анализатор вынужден взаимодействовать с семантическим анализатором, чтобы понять, например, слово asshole в данном контексте, это вообще что — название типа, название функции, название метода класса или что-то еще. Создателям компиляторов таких языков не позавидуешь, их семантический анализатор должен уметь отвечать на вопросы, касающиеся еще недоразобранного до конца текста.
Теперь, всегда ли нам нужен вообще парсер? С задачей, типа раскраски кода программы во все цвета радуги, можно справиться без полного синтаксического анализа, и обычно так и делают (хотя иногда такой "парсер на регулярных выражениях" и ошибается, но в большинстве случаев он работает хорошо).
Что до кодогенерации. О ней имеет смысл говорить, если мы делаем компилятор из языка программирования, грубо говоря, в ассемблер. Это очень обширная тематика, и в этой области ведется очень много исследований прямо сейчас, и современное состояние этой "науки" существенно отличается от того, что было, скажем, всего несколько лет назад. В общем, тут надо читать серьезную литературу, и по большей части она существует в виде статей на английском языйе, а не фундаментальных книг.
Однако для DSL серьезная кодогенерация вряд ли применима. Задача DSL — породить код на каком-нибудь C/C++, и дальше пусть уж настоящий компилятор сам с ним разбирается. Общее представление о кодогенерации иметь при этом невредно, чтобы хоть понимать, какой код компилятор C/C++ сумеет "улучшить", а где он ничего не поймет, и скомпилирует самым наивным образом. Кстати, для просто писания на C/C++ тоже невредно иметь такое понимание.
Здравствуйте, Marty, Вы писали:
M>Мне интересно, есть ли та волшебная пуля, которая за меня построит AST, опиши я язык в BNF или ещё каком виде.
Да, есть. Называется "наемные сотрудники".
M>Или вся эта шляпа с LL(X)/LR(X)б контекстно свободными/зависимыми грамматиками — просто псевдонаучно обоснованный развод для лохов, чтобы платили за то, что им вливают в уши?
Программисты — несчастные люди, потому что работать зачастую приходится с вещами, которые трудно осознать, да еще и отвечать за результат, нередко материально, а в некоторых областях вплоть до уголовной ответственности.
Казалось бы, если для какого-то куска работы есть стройная математическая теория (что равносильно тому, что этот кусок работы кто-то полностью осознал и разложил по полочкам), надо радоваться и с удовольствием пользоваться этим теоретическим знанием. Но нет, привычка все делать на коленке побеждает, а усилия по пониманию десятка незнакомых терминов оказываются непомерными.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>А сейчас есть системы грамматик, покрывающие натуральные языки (со сложностью разбора O(N^6)) ЭФ>- вот это нынешняя практика.
Суда по поведению автоматических переводчиков, скорее этих систем грамматик нет, чем они есть.
Здравствуйте, netch80, Вы писали:
N>Если смотреть на правила какого-нибудь C#, в каком случае > будет считаться знаком сравнения, а в каких — закрывающей скобкой шаблона, то это уже заметно напоминает естественные языки. А C++ так вообще превращается в один из них со своей зависимостью от контекста, который ещё не задан
Язык, на котором нельзя сказать обидную гадость, не может считаться естественным
Здравствуйте, netch80, Вы писали:
N>А вот не понять, что разговор ушёл на более общую тему — вот это точно неуместно.
А, ну то есть было из разряда "у рыб шерсти нет ...". Сорри, думал раз ник не Serginio, то можно не сильно опасаться что собеседник на своей волне.
НС>>И? Насколько эти фичи востребованны для лексического анализа DSL? N>Сильно зависит от того, какой DSL. Новые, да, лучше так не писать, но есть до чёрта всякого наследия.
Так топик то про создание DSL, а не про написания парсера для готовых.
N>>>Видимо, это проблема средств вокруг вас (C# и прочее, да?) НС>>Ну да, если аргументов нет то надо искать проблемы в собеседнике. N>Ещё не начинал.
Именно это ты и сделал и продолжаешь в том же духе. Ну ок, тогда можно и тебя пообсуждать.
N>>>Всё, что я в пару последних лет смотрел, этим не страдает — юникод это просто факт нижнего уровня НС>>Вопрос в том как устроен его анализ. Если внутри лексера не копаться то да, просто факт. N>Мне достаточно того, что лексер умеет определять
Я именно это и написал. Я же писал про то как это внутри устроено и какие проблемы бывают при написании собственных лексеров.
НС>>И? Дальше то что? Оставаться на НКА и не строить ДКА, как большинство движков для регексов делают? Для парсеров языков это не очень хорошая стратегия часто. N>Не совсем понял связь. По-вашему ДКА предполагает построение полной таблицы символов для лукапа, то есть 256 при восьмибитке и 64K при 16-битке?
Нет, это наивный подход, который плохо работает.
N>Ну взгляните тогда хотя бы на re2c, он делает ДКА и любой юникод принимает без проблем.
Я смотрел, не переживай. И от того что там намного чаще натыкаешься на проблему экспоненциального роста количества состояний он не спасает.
Здравствуйте, netch80, Вы писали:
N>Ну пусть не имеет. Откуда идея, что весь файл целиком должен представлять только то, что "имеет отношение к domain"?
Потому что это упрощает чтение и понимание написанного.
N>Так мы этого просто не знаем без подробного знания как о специфике его задачи, так и об исполнителях.
И именно это я написал в самом начале.
НС>>>>>>Вещам, необходимым трансляторам и редакторам, в исходниках, которые пишет и читает человек, не место N>>>>>И строгой грамматике — тоже? НС>>>>Если сможешь написать тулу, которая сможет обходится без нее — конечно. N>>>"Мышки, станьте ёжиками" ™. НС>>Можно расшифровать суть твоей претензии и как она стыкуется с разговором? N>Обычно не окупается. И ещё и имеет тяжёлые проблемы с развитием языка.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Ну пусть не имеет. Откуда идея, что весь файл целиком должен представлять только то, что "имеет отношение к domain"? НС>Потому что это упрощает чтение и понимание написанного.
Не вижу причин к такому выводу.
Кому-то крайне критично наличие шапки типа "Одобрено ГРУ ВАСХНИЛ" и без этого документ просто не воспринимается. На то он и домен.
N>>Обычно не окупается. И ещё и имеет тяжёлые проблемы с развитием языка. НС>Ну вот и ответ тогда на заданный тобой вопрос.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>А вот не понять, что разговор ушёл на более общую тему — вот это точно неуместно. НС>А, ну то есть было из разряда "у рыб шерсти нет ...". Сорри, думал раз ник не Serginio, то можно не сильно опасаться что собеседник на своей волне.
Достаточно всего лишь было прочитать моё сообщение и то, на которое я отвечал.
НС>>>И? Насколько эти фичи востребованны для лексического анализа DSL? N>>Сильно зависит от того, какой DSL. Новые, да, лучше так не писать, но есть до чёрта всякого наследия. НС>Так топик то про создание DSL, а не про написания парсера для готовых.
Так теперь уже ты не ограничиваешь только созданием DSL. Сказано же — для лексического анализа.
N>>>>Всё, что я в пару последних лет смотрел, этим не страдает — юникод это просто факт нижнего уровня НС>>>Вопрос в том как устроен его анализ. Если внутри лексера не копаться то да, просто факт. N>>Мне достаточно того, что лексер умеет определять НС>Я именно это и написал. Я же писал про то как это внутри устроено и какие проблемы бывают при написании собственных лексеров.
Никакой конкретики, чем юникод тут мешает, пока не поступило. Если писал где-то ещё — давай ссылку, я как-то не веду досье на собеседников.
НС>>>И? Дальше то что? Оставаться на НКА и не строить ДКА, как большинство движков для регексов делают? Для парсеров языков это не очень хорошая стратегия часто. N>>Не совсем понял связь. По-вашему ДКА предполагает построение полной таблицы символов для лукапа, то есть 256 при восьмибитке и 64K при 16-битке? НС>Нет, это наивный подход, который плохо работает.
То есть конкретики по-прежнему нет. Oook...
N>>Ну взгляните тогда хотя бы на re2c, он делает ДКА и любой юникод принимает без проблем. НС>Я смотрел, не переживай. И от того что там намного чаще натыкаешься на проблему экспоненциального роста количества состояний он не спасает.
Экспоненциальный-то откуда?
N>>>>Видимо, это проблема средств вокруг вас (C# и прочее, да?) НС>>>Ну да, если аргументов нет то надо искать проблемы в собеседнике. N>>Ещё не начинал. НС>Именно это ты и сделал и продолжаешь в том же духе.
НС>Главный критерий языка — удобство его использования человеком.
И не только языка, кстати. А вообще, чего угодно. Но только пониманию, что мы работаем для людей (а не для компьютеров, науки, мира во всем мире и т.п.), в учебных заведениях, увы, не учат.
НС>>Главный критерий языка — удобство его использования человеком.
Pzz>И не только языка, кстати. А вообще, чего угодно.
Если говорить о программировании, для языка это особенно важно. И если для библиотеки еще можно как то пережить кривой API, то в случае с языком это фактически уничтожает его целевую функцию.
