Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, eao197, Вы писали:
E>>Если язык ставит в затруднение анализаторы, то он определенно затруднит и человека. Многие языки были бы более понятными и чистыми, если бы разработчики вынуждались использовать более простой метод синтаксического анализа. Д>Чушь, чушь и еще раз — чушь! У человека нет в голове ни LL, ни LR парсера. Он распознает конструкции языка с помощью механизмов распознавания образов, которые пока толком никому не понятны. Ясно только одно — они не имеют абсолютно ничего общего с последовательным чтением текста буква за буквой.
Это правда, но я бы не был столь категоричен Помимо всего прочего, при работе за компьютером для меня важно знать, как компьютер будет выполнять мои команды. Особеннно в том случае, когда получаемый результат не совпадает с ожидаемым. Выражение vector<vector<int>> для меня интуитивно понятно, но моя задача исправить ошибку.
Д>как всё-таки удивительно узнать, что возможность переложить часть работы по распараллеливанию программ на компилятор — это "минимальное преимущество", а вот возможность делать всё самому и вручную — это "более эффективный способ хорошего использования параллелизма"
Возможно следует понять как: " в случае, когда параллелилизм нужен как кровь из носу, то, что может предложить компилятор редко когда оказывается удовлетворительным результатом. А вот человеку выполнить эту работу не сложно и с большим эффектом".
Здравствуйте, McSeem2, Вы писали:
MS>Ему просто обидно. Как же так — он академик всея академий проиграл каким-то двоешникам — Кернигану Томпсоновичу Ричи. Причем с треском — с языка C делают синтаксические реинкарнации, а Паскаль пытается реанимировать только сам Вирт с апостолами.
Ну думаю... Скорее всего истина в другом. Вирт имеет академическое образование, зарекомендовал себя также и как практик (реализовать с нуля систему Оберон за год сможет не каждый посетитель форума). Тоном фанатика, узрившего божий свет, он пытается донести его искру в массы. Но к его мнению не прислушиваются в IT индустрии.
Некоторые замечания:
1. Допустим в наше время некая фирма решила разработать систему, подобную Oberon. Думаю, что на базе тех же Java и C# ресурсы проекта будут гораздо больше, чем три человеко-года.
2. Язык Oberon имеет своих фанатиков, но в то же время это результат работы двух человек. Сейчас Oberon сравнивается с Java, C#. Интересно, какие команды разработчиков делает эти языки?
3. Вирт рекомендует свой путь основываясь на своем опыте. Совсем не факт, что его опыт можно будет перенести на коммандную разработку. Да и надо ли? Сейчас проекты в IT индустрии требуют больших команд и приносят больших денег. Что будет, если для выполнения проектов понадобится 2-3 грамотных человека??? Куда прихлебников девать???
Здравствуйте, mefrill, Вы писали:
M>Здравствуйте, VladD2, Вы писали:
VD>>Грамматика регекспов не LL(1). Это нерекурсивная грамматика. Так что она куда проще.
M>Ну как же не рекурсивная? Ведь операторы РВ применяют к самим РВ. Напрмиер, постфиксный оператор Клини "*" имеет в качестве аргумента именно регулярное выражение.
Ну, скажем так. Это концевая рекурсия, или цикл. Главное, что нельзя сделать правило которое мызвать рекурсивно.
M> Т.о. имея атомарное выражение a мы затем конструируем последовательность вложенных выражений (((a*)*)*)*...
Дык это не рекурсия — это просто именно что "вложенные вызвоы".
Если бы была рекурсия, то можно было бы, например, распозновать вложенные скобки. А так нельзя.
M> Это рекурсия в чистом виде. Доказать, что язык РВ сам не является регулярным языком очень просто, достаточно воспользоваться леммой о накачке. Являетс ли язык РВ LL(1)-языком? Уверен что да. Пару месяцев назад построил как раз такую грамматику и написал распознаватель, работающий методом рекурсивного спуска и выбирающий альтернативу на основе просмотра следующего символа. А значит, это именно LL(1)-грамматика.
Негулярные выражения несомненно можно распозновать LL(1)-парсерами. Но в приципе они для этого несколько избыточны. Можено жить проще.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Слушай, Влад, ты в последнее время так часто поминаешь Scala и Nemerle, что я не понимаю: C# -- он что, уже отстойный язык? Будущее за Nemerle?
За чем реально будущее я тебе не скажу, так как не являюсь телепатом. Несоненно Scala и Nemerle во многом более перспективные языки. C# вроде бы развивается в нужном направлении и возможно догонит их по основным позициям.
Приемущество C# на сегодня слишком велики, чтобы Scala и Nemerle были ему конкурентами. Для C# есть рефакторинг, отличная интеграция с IDE, поддержка MS и пиар. Без всего этого успех языка не мыслим.
С другой стороны Scala и Nemerle обладают тем, что мне действительно нехватает в C#. Неьзя сказать, что без этого нельзя жить, но с этим было бы жить намного приятнее.
Как ты понимашь, дотнет мне в приципе ближе. А Scala больше ориентирована на Яву. Так что Nemerle для меня ближе, хотя надо признать, что некоторые вещи в Scala-е сделаны просто здорово (например, ковариантность для дженерик-коллекций). С другой стороны Nemerle больше заточен на получение всокопроизводитешьного кода, что делает его отличным притендентом на место убийцы С++ .
В общем, я не знаю способен ли я сейчас перепрыгнуть на Scala или Nemerle, но пожалуй, что это те языки которые заставили меня всерьез задуматься над этим. Ведь у того же С++ вообще нет шансово в конкуренции с ними.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Формула E=mc^2 (как и любая другая) читается как "Энергия равна произведению массы на квадрат скорости света". Но ни в коем слуае не "Энергии следует присвоить произведение..." То есть это равенство уже существует, а формула лишь описывает его.
Ага. И читать ее как "E == mc^2" это просто полный бред. Так что Вирт как всегда выдает желаемое за действительное.
Рельно "=" в математике и в императивных языках это совсем разные вещи. Похоже у них только начертание. Оно и не мудренно. Матетатика дераративна по своей сути, а ИЯ императивны по орпделению.
Если уж говорить о схожести, то ближе всго "=" используется в ФЯ.
K_O>В С++ же выражение K_O>x = y; K_O>означает действие по приведению значения х в состояние, когда оно будет равным у.
А в Обероне сравнение, что тоже не отражает исходной сути знакка "=".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MShura, Вы писали:
MS>Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда
Оно не более логично, и не менее логично. Это просто соглашение языка. С++ != математике! Вот и все!
А слова Вирта — это просто оправдание своей "хорошей идеи" которая не была принята практическими программистами.
Большинство современных языков используют именно "=" и их пользователи решительно не испытывают от этого проблем.
Проблемы от "=" есть только в С и С++ авторы которых были не соль дальновидны, чтобы предвидеть тот факт, что люди будут опечатываться в операторе if и писать вместо "==" "=".
Данная проблема устраняется двумя путями:
1. Введением более строкой типизации. Так сделано в C#. В нем никакое выражение отличное от булева не может приводиться к bool, а if всгда проверяет только булевы выражения. При этом проблемы все же возможны если оператор присвоения использовать для булевых переменных, но это не встречается на практике, так как сравнение с булевыми константами редко бывает осмысленно.
2. Запретом присвоений внутри выражений. Собственно Вирт и пользуется этим способом только зачем-то еще и синтаксически отделяет присвоение от сравнения. Между тем это не обязательно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mystic, Вы писали:
MS>>Ему просто обидно. Как же так — он академик всея академий проиграл каким-то двоешникам — Кернигану Томпсоновичу Ричи. Причем с треском — с языка C делают синтаксические реинкарнации, а Паскаль пытается реанимировать только сам Вирт с апостолами. M>Ну думаю... Скорее всего истина в другом. Вирт имеет академическое образование, зарекомендовал себя также и как практик (реализовать с нуля систему Оберон за год сможет не каждый посетитель форума).
Знаем мы как пишут Оберон системы... читай Священная корова Оберона (специально для СГ).
до просветления. M>Тоном фанатика, узрившего божий свет, он пытается донести его искру в массы. Но к его мнению не прислушиваются в IT индустрии.
Индустрия рубит бабло. И индустрии наплевать на все что не помогает рубить бабло.
M>1. Допустим в наше время некая фирма решила разработать систему, подобную Oberon. Думаю, что на базе тех же Java и C# ресурсы проекта будут гораздо больше, чем три человеко-года.
Ну ни одна вменяемая контора не станит разрабатывать клон Оберон системы. Ибо это просто пустая трата денег.
А если делать все как следут то действительно нужно гораздо больше ресурсов. M>2. Язык Oberon имеет своих фанатиков, но в то же время это результат работы двух человек. Сейчас Oberon сравнивается с Java, C#. Интересно, какие команды разработчиков делает эти языки?
Про жабу ничего не знаю но есть слухи что C# делают 4 человека. M>3. Вирт рекомендует свой путь основываясь на своем опыте. Совсем не факт, что его опыт можно будет перенести на коммандную разработку. Да и надо ли? Сейчас проекты в IT индустрии требуют больших команд и приносят больших денег. Что будет, если для выполнения проектов понадобится 2-3 грамотных человека??? Куда прихлебников девать???
Если ты думаешь что бизнес найдя технологию которая в место 100 человек позволит задействовать 2-3 пусть и болие дорогих хоть секунду будет колебатся перед тем как выкинуть на улицу кучу нахлебников которым нужно платить деньги то поверь мне ты очень сильно заблуждаешься. От сюда вывод что опыт Вирта не дает никаких преймуществ по сравнению с тойже Жабой или C#.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
M>> Т.о. имея атомарное выражение a мы затем конструируем последовательность вложенных выражений (((a*)*)*)*... VD>Дык это не рекурсия — это просто именно что "вложенные вызвоы". VD>Если бы была рекурсия, то можно было бы, например, распозновать вложенные скобки. А так нельзя.
Ты не понял. Регулярные выражения не имеют рекурсии на то они и ругулярные выражения.
Но само регулярное выражение(а не ту строку которое оно описывает)без рекурсии в общем случае распознать не возможно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Проблемы от "=" есть только в С и С++ авторы которых были не соль дальновидны, чтобы предвидеть тот факт, что люди будут опечатываться в операторе if и писать вместо "==" "=".
И компиляторы тут же выдают при этом warning, который обычно приравнивается к error. Так что не вижу здесь проблемы, равно как и осуждаю практику в виде:
if (2 == x) ;
VD>1. Введением более строкой типизации. Так сделано в C#. В нем никакое выражение отличное от булева не может приводиться к bool, а if всгда проверяет только булевы выражения. При этом проблемы все же возможны если оператор присвоения использовать для булевых переменных, но это не встречается на практике, так как сравнение с булевыми константами редко бывает осмысленно.
А вот это, честно говоря, достаточно сильно напрягает. Почему бы не ввести соглашения о приведении базовых типов к bool? Меня напрягает писать очевидные вещи типа
Object o = null;
if (o <> null) ;
Гораздо быстрее и без потери понятности (при наличии соглашений) можно писать
Здравствуйте, WolfHound, Вы писали:
WH>Ты не понял. Регулярные выражения не имеют рекурсии на то они и ругулярные выражения. WH>Но само регулярное выражение(а не ту строку которое оно описывает)без рекурсии в общем случае распознать не возможно.
А причем, кстати, тут само РВ?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Такое ощущение, что вы не в курсе, что представляет собой язык со встроенной поддержкой многозадачности. Это тоже самое, что язык с GC на фоне языка с ручным управлением памятью. Когда такая поддержка есть на уровне языка, то многие вещи становятся значительно проще, многие проблемы исчезают, а многие дополнительные возможности появляются.
Согласен, но это только если решаемые задачи требуют этой многопоточности. А большинство их не требует. Или требует мало.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
MS>Общеизвестным плохим примером является выбор знака равенства для обозначения присваивания, восходящий к языку Fortran в 1957 г. и слепо повторяемый до сих пор массой разработчиков языков. Эта плохая идея низвергает вековую традицию использования знака "=" для обозначения сравнения на равенство, предиката, принимающего значения true или false.
MS>Я не понял выделенного, что значит вековая традиция в его понимании? Сколько лет coputer science (ну или хотя бы слову предикат)? MS>На мой взгляд знак "=" как раз понятен. MS>Например: MS>E=mc^2 MS>F=ma
Что-то примеры ты явно не из Computer Science привёл А в физике это явно не присваивание букве E значения mc^2 ... В математике и физике знак '=' используется в качестве тождественности выражений. Скорее всего здесь хромает перевод и 'сравнение на равенство' = 'тождественность', что и подтверждает продолжение фразы.
Кстати очень сложно привыкать к этому различию, так что я склонен считать что Вирт тут прав, а также правы те кто ввели оператор :=.
Здравствуйте, Mystic, Вы писали:
M>Это правда, но я бы не был столь категоричен Помимо всего прочего, при работе за компьютером для меня важно знать, как компьютер будет выполнять мои команды. Особеннно в том случае, когда получаемый результат не совпадает с ожидаемым. Выражение vector<vector<int>> для меня интуитивно понятно, но моя задача исправить ошибку.
это уж задача компилятора — правильно понимать, что ты ему хочешь сказать. Но никак не наоборот
M>Возможно следует понять как: " в случае, когда параллелилизм нужен как кровь из носу, то, что может предложить компилятор редко когда оказывается удовлетворительным M> результатом. А вот человеку выполнить эту работу не сложно и с большим эффектом".
не сложно? если речь идет о реальном распараллеливании задачи, а не простом "сделать фоновый поток, чтобы он чего-нибудь обновлял", то совсем наоборот — сложно, очень сложно!
в любом случае, иметь хоть какую-то помощь от компилятора — это намного лучше, чем делать всё только вручную
Здравствуйте, VladD2, Вы писали:
VD>Ну, скажем так. Это концевая рекурсия, или цикл. Главное, что нельзя сделать правило которое мызвать рекурсивно.
Разве здесь концевая рекурсия? Ведь сначала мы должны распознать регулярное выражение, а только затем посмотреть, применяется ли к нему постфиксный оператор *. Или другой постфиксный оператор, + например. Или префиксный оператор. Рекурсия в языке регулярных выражений — это свойство самого языка безотносительно того, каким формализмом мы это свойство описываем. Свойство таково, приведу здесь часть индуктивного (читай рекурсивного) определения регулярного выражения:
1. РВ есть атомарное РВ, т.е. символ является РВ.
2. РВ есть РВ *, РВ +, РВ ? n и т.д.
Вот это свойство языка, где бы мы его не описывали, всегда будет обрабатываться циклическим процессом. Т.е. анализируя РВ мы снова должны будем прийти к этому анализу, но с другими параметрами. Вообще, это отличительное свойство формальных языков от естественных, повторяющиеся процессы. Или можно сказать так: отличие неживого от живого. Итак, мы имеем циклический процесс как свойство синтаксиса языка РВ. Причем я здесь совсем не говорю о семантике языка РВ, т.е. о том .что выражения этого языка значат. На сейчас важны только его синтаксические конструкции. Существуют разного рода формализмы для описания формальных языков, в частности, для описания КС-языков, таких как язык РВ. Наиболее популярны среди программистов те, которые описывают язык как вычислительный процесс, так как задача программиста — это построение вычислительного процесса, моделирующего логику программной модели. Для анализа РВ, в частности, можно применить два подхода:
1. Построить КС-грамматику, описывающую данный язык и все его свойства.
2. Построить распознаватель на основе магазинного автомата, распознающий РВ и только их.
В обоих случаях мы должны учитывать свойство языка РВ — индуктивность определений его синтаксических сущностей. В грамматике такую индукцию, в силу специфики языка порождающих грамматик, можно выразить одной конструкцией — рекурсивными правилами переписывания. В частности, имеем:
РВ --> РВ *
РВ --> РВ +
РВ --> РВ ?
и т.д.
При построении магазииного автомата — рапознавателя мы построим множество состояний этого автомата и магазин, кторый обязательно должен быть, так как определения синтаксических конструкций языка РВ индуктивны. Как его построить я здесь описывать не буду, то отдельная песня. Замечу только, что на сегодняшний денб это самый популярный способ построения анализатора РВ, в силу его временной эффективности. Если кому-нибудь будет интересно, т омогу описать в отдельном сообщении.
M>> Т.о. имея атомарное выражение a мы затем конструируем последовательность вложенных выражений (((a*)*)*)*... VD>Дык это не рекурсия — это просто именно что "вложенные вызвоы". VD>Если бы была рекурсия, то можно было бы, например, распозновать вложенные скобки. А так нельзя.
Честно говоря, совсем не понял, что здесь имелось ввиду. Вложенные скобки — часть синтаксиса языка РВ, например (((a)b*)).
Здравствуйте, VladD2, Вы писали:
MS>>Я по-прежнему считаю, что использование = вместо := более логично (к тому-же меньше синтаксического оверхеда VD>Оно не более логично, и не менее логично. Это просто соглашение языка. С++ != математике! Вот и все!
Согласен, но тем не менее изучение языка это легче не делает. Ведь человек интуитивно воспринимает семантику символа = так, как его учили с детства. А учили его математике, а не программирвоания. А там вообще при записи подразумевается именно равенство. Поэтому изучающему трудно перестроится. Тем самым создаются дополнительные барьеры на пути неофита. Что по мне, так мне и := не нравится тоже. Логично было бы использовать кнтовскую нотацию <-. Вот здесь как раз все кажется понятно.
Здравствуйте, Дарней, Вы писали:
Д>это уж задача компилятора — правильно понимать, что ты ему хочешь сказать. Но никак не наоборот
Мир несовершенен К тому же компиляторов, понимающих текст программы на уровне человека пока нет, и я не знаю, к сожалению или к счастью. Потому в жизни часто часто встречается непонимание из серии "а я подумал, что ты подумал, ..." И если это перенести на программирование, то ловить такие ошибки будет ужасно.
Д>не сложно? если речь идет о реальном распараллеливании задачи, а не простом "сделать фоновый поток, чтобы он чего-нибудь обновлял", то совсем наоборот — сложно, очень сложно!
Ну... реальный пример: Fritz и Deep Fritz. Распараллеливание в данном случае не сложно.
Д>в любом случае, иметь хоть какую-то помощь от компилятора — это намного лучше, чем делать всё только вручную
А можешь кинуть ссылку на результаты исследований, что это приводит к выигрышу производительности. Или выигрыш только в "теории"?
Помимо всего прочего, при работе за компьютером для меня важно знать, как компьютер будет выполнять мои команды. Особеннно в том случае, когда получаемый результат не совпадает с ожидаемым. Выражение vector<vector<int>> для меня интуитивно понятно, но моя задача исправить ошибку.
.
А в физике это явно не присваивание букве E значения mc^2 ... В математике и физике знак '=' используется в качестве тождественности выражений. Скорее всего здесь хромает перевод и 'сравнение на равенство' = 'тождественность', что и подтверждает продолжение фразы.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
