Oberon space
General Category => Общий раздел => Тема начата: valexey от Март 03, 2011, 01:37:05 pm
-
Я тут, по работе, все больше глубже и сильнее погружаюсь в Objective-C. В процессе погружения возникают всякие разные мысли странные. Недавно вот родился следующий тезис:
"Относительно языка Оберон, язык Компонентный Паскаль с его средой исполненя это то же, что язык Objective-C, с его рантаймом, относительно языка Си."
-
У меня такого ощущения не возникло. С одной стороны в КП по сравнению с Обероном добавлено намного меньше, чем в Obj-C по сравнении с C, а с другой стороны КП не является надмножеством предка, а Obj-C - является.
-
У меня такого ощущения не возникло. С одной стороны в КП по сравнению с Обероном добавлено намного меньше, чем в Obj-C по сравнении с C, а с другой стороны КП не является надмножеством предка, а Obj-C - является.
Добавлено очень много по сравнению с Oberon'ом: например добавлена обязательная сборка мусора, добавлена метаинформация и возможности метапрограммирования. Добавлены методы у записей (виртуальные, да), добавлен общий предок для всех записей, добавлен контроль за расширябельностью записей и так далее.
У меня впечатление складывается, что ObjC добавил к Си меньше чем КП к Оберону. Но в ObjC добавлено было более аккуратно в том смысле, что обратную совместимость не сломали.
-
Да, правда даже КП не ввел в язык обязательную проверку переполнений и выхода за пределы массивов.
-
Что значит "не ввёл"?
Всё с точностью до наоборот - это если выход возможен, то это надо явно оговаривать: "при обращении по индексу за пределами размера массива поведение не определено".
Поскольку такого не сказано, подразумевается, что операция не имеет смысла. И будет проверяться.
-
Что значит "не ввёл"?
Всё с точностью до наоборот - это если выход возможен, то это надо явно оговаривать: "при обращении по индексу за пределами размера массива поведение не определено".
Поскольку такого не сказано, подразумевается, что операция не имеет смысла. И будет проверяться.
И что же произойдет если проверка покажет, что мы вышли за пределы массива? Где собственно в спеке указание на то, что в этом случае будет?
-
Поясню -- если в спеке не указано что в этом случае будет, это и есть undefined behaviour. Потому, что оно в разных случаях, в разных окружениях, будет (может быть) разным.
Поэтому в спеке на плюсы об этом честно пишут. А в спеке на КП об этом скромно умалчивают.
-
Я не буду с Вами спорить однозначно, но вопрос интересный.
Что понимать под behavior? Behavior - это всё-таки продолжение работы программы (хотя бы с некоторой вероятностью). А если behaviour, даже undefined-ный, на глупую операцию не задан, то подразумевается, что никакого behavior-а не будет, вычисления будут прерваны. Ведь не пишется же в стандарте языка, как именно ведёт себя компилятор при обнаружении синт. ошибки. Просто очевидно, что несоответствие синтаксису не ведёт ни к какому результату, компиляция оканчивается. А уж как там после ошибок восстанавливается каждый компилятор - не фиксировать же в стандарте.
-
Я не буду с Вами спорить однозначно, но вопрос интересный.
Что понимать под behavior? Behavior - это всё-таки продолжение работы программы (хотя бы с некоторой вероятностью). А если behaviour, даже undefined-ный, на глупую операцию не задан, то подразумевается, что никакого behavior-а не будет, вычисления будут прерваны.
Ну да, можно пофилософствовать, что такое выполнение программы и что такое обрыв вычислений и т.д. Итог все равно один - undefined behavior это то, что вы точно не хотите в своей программе. И хорошо, если об этом undefined behavior говорится честно и во всех возможных местах, а не жертвуют, чтобы уложиться в 16 страниц. Ну и, конечно, существование undefined behavior однозначно говорит об изъяне в дизайне языка. Либо по причине сознательного компромисса с железкой, либо недодуманности, либо еще чего.
-
И всё-таки конкретный жизненный вопрос: кому это жить помешало?
Если в подробно стандартизированных языках вещей, "жить мешающих", пруд пруди, а тут при ряде второстепенных опущений никому ещё это не помешало, то чего огород городить.
Усилия надо инвестировать разумно и экономно. Это если много лишней энергии, которую некуда девать, то можно сидеть и строчить подробные, большие тома :) В том числе для самоудовлетворения.
-
Это тоже та ещё "замануха": лидеры-гиганты строчат внушительные такие тома, стандарты, на реализацию которых уйдёт не один год, и как бы приглашают "делайте так же, если хотите, чтобы вас воспринимали всерьёз".
И народ даже из академической среды, из open-source и т.п. начинает втягиваться в эту гонку - "чтоб всё было солидно".
Тратит несколько лет жизни на какой-нибудь ОДИН такой "чинный и солидный" проект. И, разумеется, о какой-то конкуренции можно просто забыть.
Вместо того, чтобы развязать руки от второстепенных мелочей и пройти по грани "необходимого и достаточного", решив за то же время целый ряд задач. Как Вирт с ПК, ОС и прикладными пакетами, или новосибирцы с Кроносом. Да и многие коллективы, сталкивающиеся с "особыми задачами", таким же путём идут. У них выбора нет просто. Как у многих наших оборонных контор, которые разрабатывают свои CASE-решения.
-
Вместо того, чтобы развязать руки от второстепенных мелочей и пройти по грани "необходимого и достаточного", решив за то же время целый ряд задач.
Нет. Мелочи важны. Особенно в языках программирования.
-
И всё-таки конкретный жизненный вопрос: кому это жить помешало?
Да любому, кому приходилось иметь дело с более чем одной аппаратной платформой и более чем одной реализацией ЯП. Например мне ;)
Если в подробно стандартизированных языках вещей, "жить мешающих", пруд пруди, а тут при ряде второстепенных опущений никому ещё это не помешало, то чего огород городить.
Ну вот представьте, что вам досталось портировать на ББ код с "оберон платформы", в которой обращение к несуществующему элементу массива возвращало 0, а запись туда игнорировалась. Да, разработчики "того" рантайма сделали не очень умно (но по спеке, хе-хе). А писатели, использующие тот компилятор, посчитали такое поведение "само собой разумеющимся" и вовсю использовали эту особенности при разработке софта. Ну и что вы будете делать? Ну допилите ББ'ый рантайм до такого же поведения, да. Будет ощущение, что сделали какашку, ну что ж поделаешь, если оно какашка и его надо заставить работать. А потом вам надо будет взять код еще с одной платформы, где более умные разработчики рантайма делают ASSERT при обращении к несуществующему элементу. Но вот такие же неумные писатели софта обрабатывают такой ASSERT и строят на этом какую-то логику. Ну да, вы и эту проблему обойдете, не сомневаюсь. Однако "опущения" в описании языка вам уже не будут казаться настолько второстепенными.
-
Вместо того, чтобы развязать руки от второстепенных мелочей и пройти по грани "необходимого и достаточного", решив за то же время целый ряд задач.
Я очень хорошо понимаю ваше желание "сэкономить" и недовольство большими спеками. Никто их не любит, все хотят быстро, качественно и дешево. Проблема в том, что это не работает "в большом" - в больших системах, с большим количеством разработчиков, с большим временем жизни.
Как Вирт с ПК, ОС и прикладными пакетами, или новосибирцы с Кроносом.
И опыт Вирта с его оберон-ОС'ом лишнее тому подтверждение. Где эта оберон-ОС? Кто ее будет тащить на новое железо? Не, напишут с нуля новую, еще более правильную. Но такую же невостребованную.
-
Вот тут большое недопонимание касательно невостребованности.
Это иллюзия.
Огромный спектр задач, который касается штучной автоматизации нестандартных предприятий (производство и т.п.), может успешно решаться по схеме, принятой в Оберон-проектах. Решаться быстро, "для себя" и независимо от того, кто там и что вокруг творит.
Просто нужно такой опыт доносить, популяризовать, вселять уверенность в автоматизаторов этой сферы, что у них всё получится сделать самостоятельно, без оглядок на ИТ-мейнстрим. А мейнстрим, конечно, этого не хочет - ему тоже кушать хочется, приходить с надутыми щеками на такие "объекты" и доказывать, что без "профессионального подхода" ничего не выйдет.
И жизнь это подтверждает - в той же пром. автоматизации народ, помыкавшись со стандартными решениями, принятыми для бизнес-автоматизации, плюет часто на это дело и делает свои CASE-системы "под задачу", примеров масса. Кстати, и Дельфа дольше всего выживала именно в этой сфере.
-
Вот тут большое недопонимание касательно невостребованности.
Это иллюзия.
Огромный спектр задач, который касается штучной автоматизации нестандартных предприятий (производство и т.п.), может успешно решаться по схеме, принятой в Оберон-проектах.
Ну да. Может. Только Виртов мало, а задач много. Поэтому штучная "оберон система с нуля" быстро, качественно и дешево - это иллюзия. Поэтому побеждает обычно более мэнйстримное "быстро и дешево". Что, конечно, не исключает исключений...
-
Ну да. Может. Только Виртов мало, а задач много. Поэтому штучная "оберон система с нуля" быстро, качественно и дешево - это иллюзия. Поэтому побеждает обычно более мэнйстримное "быстро и дешево". Что, конечно, не исключает исключений...
Да нет, не иллюзия... а рекламная агитка, для тех кто хочет обмануться... но таких мало, и слава богу...
-
Я не буду с Вами спорить однозначно, но вопрос интересный.
Что понимать под behavior? Behavior - это всё-таки продолжение работы программы (хотя бы с некоторой вероятностью). А если behaviour, даже undefined-ный, на глупую операцию не задан, то подразумевается, что никакого behavior-а не будет, вычисления будут прерваны.
Полное прерывание вычислений – это аварийный останов ЭВМ. Например как это случилось на Ариане. Любое иное – это не полное прерывание вычислений, по сути это вообще не прерывание вычислений, а просто вычисления пойдут по другой ветке. Так вот, я ни разу не видел, чтобы по выходу за границу массива у меня в ББ были бы вычисления действительно прерваны. Таким образом behaviour таки имеет место. Причем он там неявно undefined :-) По моему, хуже ситуацию придумать довольно сложно.
-
Какая-то тупая софистика.
Идёт прерывание выполняемого алгоритма. В понятиях системы ББ (и некоторых других Оберон-систем) - инициированной команды. С какого перепуга нужно в описании языка разжёвывать, как именно будет происходить нештатное прерывание алгоритма в конкретной среде.
Высосанные из пальца проблемы (при том у тех, у кого вообще нет практики в обсуждаемых технологиях) и ещё более надуманное их обсасывание.
Как же скучно.
-
И всё-таки конкретный жизненный вопрос: кому это жить помешало?
Если в подробно стандартизированных языках вещей, "жить мешающих", пруд пруди, а тут при ряде второстепенных опущений никому ещё это не помешало, то чего огород городить.
Оно мешает жить когда язык становится достаточно широко употребимым. Сейчас использование Оберона и его производных примерно эквивалентно использованию С++ в 1985-1986 годах. Это если считать по числу разработчиков, если же считать по рыночной доле, то, как понимаешь, еще печальней. Тогда, в 1985 году, никто о стандартизации языка ( C++ ) в общем то и не заикался даже. Оно и понятно – в таких масштабах не зачем он. Но спека таки писалась и довольно подробная (то есть малая популярность языка (и малая динамика его роста) служит причиной отсутствия процесса стандартизации оного языка, но не является достаточным оправданием для недостаточно четкой спецификации обсуждаемых моментов, если язык позиционируется как безопасный).
-
Ну да. Может. Только Виртов мало, а задач много.
Только не решаются оне... задачи энти.
Что-то маловато довольных пользователей в сфере той же автоматизации предприятий. "Большие решения" (типа ERP от серьёзных поставщиков) работают и хорошо интегрируются, но люди недовольны, потому что они не решают именно их задач, несмотря ни на какую customization. Более мелкие решения работают плохо, плохо интегрируются, их пробуют и меняют один за одним... Под себя разработанные решения во многих случаях вообще толком не работают в силу невозможности найти адекватных исполнителей.
Но если уж повезло с исполнителями, то обычно работают лучше всего.
Отсюда разумно и "человеколюбиво" по отношению к страждущим нормальной автоматизации организациям - выращивать как можно больше таких адекватных исполнителей или вооружать их подходом, практиками, инструментами для такой штучной автоматизации.
-
Оно мешает жить когда язык становится достаточно широко употребимым
Вот тогда и следует доуточнять вопросы, по мере их актуальности.
Неужели неясен совершенно очевидный факт, что действовать иначе - это плодить мертворожденный мусор...
Инварианты, инварианты - вот ключевое слово. Ловить и фиксировать сегодня ровно то, что уже очевидно из опыта, что не "поплывёт" год или два спустя.
Остальным пусть занимаются, кому делать нечего.
-
Это тоже та ещё "замануха": лидеры-гиганты строчат внушительные такие тома, стандарты, на реализацию которых уйдёт не один год, и как бы приглашают "делайте так же, если хотите, чтобы вас воспринимали всерьёз".
И народ даже из академической среды, из open-source и т.п. начинает втягиваться в эту гонку - "чтоб всё было солидно".
Тратит несколько лет жизни на какой-нибудь ОДИН такой "чинный и солидный" проект. И, разумеется, о какой-то конкуренции можно просто забыть.
Вместо того, чтобы развязать руки от второстепенных мелочей и пройти по грани "необходимого и достаточного", решив за то же время целый ряд задач. Как Вирт с ПК, ОС и прикладными пакетами, или новосибирцы с Кроносом. Да и многие коллективы, сталкивающиеся с "особыми задачами", таким же путём идут. У них выбора нет просто. Как у многих наших оборонных контор, которые разрабатывают свои CASE-решения.
Про какие стандарты идет речь? На средствах разработки давно никто не зарабатывает из гигантов и даже не гигантов (ну, разве что как-то живет этим JetBrains, да и то…).
Стандарты/спецификации максимально подробные производителю софтверной продукции (любого размера) не нужны категорически. Они всегда мешают. Стандарты и спецификации нужны прежде всего заказчику, чтобы избежать явления известного как vendor lock in. Поэтому они и появляются, эти стандарты. В интересах заказчика не зависеть от данного конкретного решения данного конкретного вендора, иметь возможность спокойно его заменить, в случае необходимости на другое решение другого вендора. Интересы вендоров прямо противоположны.
Я занимался скадами и автоматизацией. У нас таки как раз было гм… не стандартное решение, в качестве протокола (как это обычно бывает в таких решениях) использовался fpp. Так вот, заказчик стал неописуемо счастлив (и отвалил деньгу немалую) когда мы прикрутили гейт для передачи наших данных по OPC. Просто потому, что в случае чего теперь нас хоть как-то можно было заменить, и хоть как-то можно было интегрироваться со внешним миром. Между прочим, всякий разный сименс тоже не слищком рад требованиям поддержки OPC, ибо это сильно мешает намертво завязать заказчика на себя.
Но мы говорили про языки, там давным давно никто серьезно денег на компиляторах и прочих тулзах не зарабатывает, так что совершенно непонятно какие гиганты и что тут могут выгадать.
-
Оно мешает жить когда язык становится достаточно широко употребимым
Вот тогда и следует доуточнять вопросы, по мере их актуальности.
Неужели неясен совершенно очевидный факт, что действовать иначе - это плодить мертворожденный мусор...
Инварианты, инварианты - вот ключевое слово. Ловить и фиксировать сегодня ровно то, что уже очевидно из опыта, что не "поплывёт" год или два спустя.
Остальным пусть занимаются, кому делать нечего.
Еще раз: если КП позиционируется как язык надежный, то обсуждаемый вопрос должен явно быть отражен в спеке на язык. Иначе совершенно непонятно как с этим бороться. Также следует учесть, что реализаций КП уже больше одной. И возможно будут еще.
-
Идёт прерывание выполняемого алгоритма. В понятиях системы ББ (и некоторых других Оберон-систем) - инициированной команды. С какого перепуга нужно в описании языка разжёвывать, как именно будет происходить нештатное прерывание алгоритма в конкретной среде.
Прерывание КАКОГО алгоритма?
Допустим идем в цикле по массиву. Бац. вышли за пределы массива, я правильно понимаю что по этому определению у нас управление просто должно передаться оператору следующему за этим циклом? Или эта операция будет просто проигнорирована (как неправомерная) и цикл побежит дальше? Или передастся управление некому хендлеру внештатных ситуаций? Или комп прекратит работу? Что-то еще?
В описании языка должен быть описан механизм обработки таких ситуаций, либо явно сказано, что хз что будет (undefined behaviour – означает именно то самое, что то, что произойдет зависит от конкретной реализации языка и среды, железа и так далее).
Но если язык позиционируется надежным, то подобные ситуации должны максимально четко быть рассмотрены в спеке на язык.
Да, а софистику не я первый начал. Кто к нам с мячом придет, тому и в воротах стоять :-)
-
Высосанные из пальца проблемы (при том у тех, у кого вообще нет практики в обсуждаемых технологиях) и ещё более надуманное их обсасывание.
Как же скучно.
Расскажите про ваш опыт портирования систем на КП на нескольких платформ. В смысле есть он или нет. Если же подобной практики у вас нет, то расскажите почему вы так уверены, что в случае КП подобные "высосанные" проблемы не актуальны (может быть портирование вообще не предусматривается, просто каждый раз создаем с нуля)?
-
Кстати, да, было бы интересно услышать про опыт портирования чего-нибудь например из ББ в GPCP и обратно.
-
Только не решаются оне... задачи энти.
Что-то маловато довольных пользователей в сфере той же автоматизации предприятий.
Ну хорошо. Есть такая проблема. Казалось бы, причем тут оберон? Потому что Вирт смог соорудить такую систему с нуля? Еще раз: откуда уверенность, что на такое способен каждый "производственник на месте" в свободное от основной деятельности время?
-
Вообще, как я понял из обсуждения, притензий к самому тезису нет, он верен и его можно пускать в народ :-)
-
Отсюда разумно и "человеколюбиво" по отношению к страждущим нормальной автоматизации организациям - выращивать как можно больше таких адекватных исполнителей или вооружать их подходом, практиками, инструментами для такой штучной автоматизации.
Вообще моя деятельность непосредственно связана с сопровождением системы, цель которой в том, чтобы позволить легко сделать "штучную" автоматизацию "на месте". Так что я крайне заинтересован, чтобы мы тут до чего-то качественного договорились.
-
Вообще, как я понял из обсуждения, притензий к самому тезису нет, он верен и его можно пускать в народ :-)
Пускать можно любой тезис, заинтересованный народ разберется... Проблема в другом - тезисы которые не соприкасаются с реальностью вызывают негативную реакцию у пользователя по отношению к его "распространителям" ( это четко прослеживается, но и бог бы им судья) и инструменту (а вот это - много , много хуже...), и не дай бог если заинтересованное лицо потратило время и ресурсы... тогда "распространителям"-летят в лицо какашки (в качестве моральной компенсации)- и энто справедливо ИМХО.
-
Ну вот и хотелось бы минимизировать число какашек в сторону инструмента из за оного тезиса :-)
-
Ну вот и хотелось бы минимизировать число какашек в сторону инструмента из за оного тезиса :-)
А может ну его , с этим тезисом -у меня лично к людям которые его выдвигают нет доверия (одна трепотня "в общем"), да и в массах сиськовертство не очень приживается...
На мой взгляд, важнее 1. Определиться с тем, тема оберона и ББ окончательно "засрана" фанатиками - или есть еще какие - то резервы. 2. Определиться с портретом пользователя - мне до сих пор лично не понятно кому это может быть интересно (кроме Инфо21 с его специфическими задачами, и паре контор, которые "повязаны" на "теме" им раздутие ее просто помогает выколачивать с заказчика бабло и парить мозги своим сотрудникам).
-
А может ну его , с этим тезисом -у меня лично к людям которые его выдвигают нет доверия (одна трепотня "в общем"), да и в массах сиськовертство не очень приживается...
Этта… Тезис, который в начале данного топика – выдвинут мною, и он таки довольно конкретно-технический.
На мой взгляд, важнее 1. Определиться с тем, тема оберона и ББ окончательно "засрана" фанатиками - или есть еще какие - то резервы.
Ну, фанатиков я по большей части отечественных наблюдаю, на прогнившем западе все тихо мирно, спокойно, разрабатывают компиляторы, инструментарий, решают задачи. Вон тот же Astrobe например, или Amadeus. Ну и вообще: https://groups.google.com/forum/?fromgroups#!forum/comp.lang.oberon
2. Определиться с портретом пользователя - мне до сих пор лично не понятно кому это может быть интересно (кроме Инфо21 с его специфическими задачами, и паре контор, которые "повязаны" на "теме" им раздутие ее просто помогает выколачивать с заказчика бабло и парить мозги своим сотрудникам).
Оберон хорош, как я уже говорил, во встроенке (программирование микроконтроллеров, он тут хорош тем, что его можно относительно легко допилить под свои задачи), в исследованиях языков программирования – оберон является отличной лабораторной крысой, хорош в обучении азам императивщины, хорош для обучения азам построения компиляторов и вообще средств разработки, ББ хорош как заготовка для лепки специализированных сред. Вроде бы все. А, нет, одну область забыл – Оберон хорош как тема для очередного холивора :-)
-
Этта… Тезис, который в начале данного топика – выдвинут мною, и он таки довольно конкретно-технический.
Он уже мутировал , фиг знает во что...
Ну, фанатиков я по большей части отечественных наблюдаю, на прогнившем западе все тихо мирно, спокойно, разрабатывают компиляторы, инструментарий, решают задачи. Вон тот же Astrobe например, или Amadeus. Ну и вообще: https://groups.google.com/forum/?fromgroups#!forum/comp.lang.oberon
Амадеус, пример разработки под конкретного заказчика - Ильин похоже единственный человек, которой додумалься вложить в библиотеку свои деньги (да и то во имя сотрудничества с создателем ее). Кроме того, ничего особенного, по сравнению с другими БЕСПЛАТНЫМИ фреймворками я в документации по нему не увидел... Астробе - не понятно, насколько востребован... но на заметку микроконтроллерное направление взять конечно стоит...
Оберон хорош, как я уже говорил, во встроенке (программирование микроконтроллеров, он тут хорош тем, что его можно относительно легко допилить под свои задачи), в исследованиях языков программирования – оберон является отличной лабораторной крысой, хорош в обучении азам императивщины, хорош для обучения азам построения компиляторов и вообще средств разработки, ББ хорош как заготовка для лепки специализированных сред. Вроде бы все. А, нет, одну область забыл – Оберон хорош как тема для очередного холивора :-)
1. Что конкретно имеется ввиду, и какие задачи?
2. Не понятно - о чем? что там можно исследовать?
3. В силу простоты - да, но тут Вирт с оной переборщил - засрал простоту артефактами...
4. В теории...
5. Это бесспорное достоинство Оберонов. в силу его простоты холиворить может и стар и млад...
-
Он уже мутировал , фиг знает во что...
Ну, я таки предлагаю обсудить оригинальный тезис, без мутаций. Тот который вот тут: http://oberon.talk4fun.net/index.php?topic=25.msg707#msg707
1. Что конкретно имеется ввиду, и какие задачи?
Например часто нужно добавлять в язык такие сущности, как например указания компилятору в какие сегменты памяти какие куски кода пихать. Если язык простой, компилятор простой и написан так. что его просто изменять, то проблем не будет.
2. Не понятно - о чем? что там можно исследовать?
Например исследование стохастических грамматик.
3. В силу простоты - да, но тут Вирт с оной переборщил - засрал простоту артефактами...
Например какими?
-
Ну, я таки предлагаю обсудить оригинальный тезис, без мутаций. Тот который вот тут: http://oberon.talk4fun.net/index.php?topic=25.msg707#msg707
Зачем ? Какие вопросы там остались открытыми? Что дасть дальнейшее рассусолевание этой темы? Не понимаю...
Например часто нужно добавлять в язык такие сущности, как например указания компилятору в какие сегменты памяти какие куски кода пихать. Если язык простой, компилятор простой и написан так. что его просто изменять, то проблем не будет.
Зачем(добавлять в язык сущности если текущей горстке его пользователей это нафиг не нужно)? Для привлечения новых пользователей? Вы это серьезно?
Например исследование стохастических грамматик.
Это как то повлияет на популярность языка?
[quote ]
Например какими?
[/quote] А я их перечислил в образовательной ветке этого форума....
-
Зачем ? Какие вопросы там остались открытыми? Что дасть дальнейшее рассусолевание этой темы? Не понимаю...
Откровенно говоря, я не нашел ни одного ответа по самому тезису, только холивор по втостепенному замечанию в скобках (про рантайм-контроль выхода за пределы массива).
Зачем(добавлять в язык сущности если текущей горстке его пользователей это нафиг не нужно)? Для привлечения новых пользователей? Вы это серьезно?
Да, серьезно. Но не совсем то, что ты имеешь ввиду :-) Смотри: есть язык, Оберон. Для прикладного пользователя он неюзабелен абсолютно. По сути это заготовка. Нам нужно написать нечто под микроконтроллер. У нас есть компилятор Оберона, по сути тоже заготовка. Берем Оберон, добавляем туда то, что нам нужно для данной микроконтроллерной задачи, реализуем это в компиляторе. Решаем задачу. В случае программирования микроконтроллеров это вполне реальный сценарий использования, там собственно и сишные компиляторы подобным образом допиливаются (равно как и язык). Оберон допилить будет проще.
Например исследование стохастических грамматик.
Это как то повлияет на популярность языка?
Понятия не имею. Я просто очертил области применения Оберона. Конкретно для данной задачи оберон реально используется. Основной минус его для данной задачи – малая его популярность, то есть слишком мало исходников на нем. Поэтому сейчас рассматривается вариант анализа других языков. Того же питона например.
-
Откровенно говоря, я не нашел ни одного ответа по самому тезису, только холивор по втостепенному замечанию в скобках (про рантайм-контроль выхода за пределы массива).
Почему... нашли :) Вы просто не хотите его замечать (признавать) - для текущего контингента форума эта тема не является стоящей внимания (по крайней мере для того чтобы разбираться с ней серьезно) - а это очень конкретный результат...
Да, серьезно. Но не совсем то, что ты имеешь ввиду :-) Смотри: есть язык, Оберон. Для прикладного пользователя он неюзабелен абсолютно. По сути это заготовка. Нам нужно написать нечто под микроконтроллер. У нас есть компилятор Оберона, по сути тоже заготовка. Берем Оберон, добавляем туда то, что нам нужно для данной микроконтроллерной задачи, реализуем это в компиляторе. Решаем задачу. В случае программирования микроконтроллеров это вполне реальный сценарий использования, там собственно и сишные компиляторы подобным образом допиливаются (равно как и язык). Оберон допилить будет проще.
Смотрю , ;) но серьезного анализа (как задачи общего вида) не вижу.... да и вообще анализа - может стоит эту тему вывести в отдельную ветку...
-
Расскажите про ваш опыт портирования систем на КП на нескольких платформ. В смысле есть он или нет. Если же подобной практики у вас нет, то расскажите почему вы так уверены, что в случае КП подобные "высосанные" проблемы не актуальны (может быть портирование вообще не предусматривается, просто каждый раз создаем с нуля)?
Про различные аппаратные платформы - опыта нет. Про портирование компилятора - также.
Какой опыт есть - это создание серверного middleware, который работает под Windows и Linux, большинство модулей которого являются платформенно-независимыми. Одно приложение запускается и под Windows, и под Linux без перекомпиляции (т.е. большая часть системы оказывается бинарно идентичной для обоих платформ), в зависимости от выбранного пускача (exe или elf).
-
Оберон хорош, как я уже говорил, во встроенке (программирование микроконтроллеров, он тут хорош тем, что его можно относительно легко допилить под свои задачи), в исследованиях языков программирования – оберон является отличной лабораторной крысой, хорош в обучении азам императивщины, хорош для обучения азам построения компиляторов и вообще средств разработки, ББ хорош как заготовка для лепки специализированных сред. Вроде бы все. А, нет, одну область забыл – Оберон хорош как тема для очередного холивора :-)
Оберон, притом в варианте КП, хорош в той нише, в которую метят Google Go, Node.JS и подобные им новинки области системного ПО.
-
Ну хорошо. Есть такая проблема. Казалось бы, причем тут оберон? Потому что Вирт смог соорудить такую систему с нуля? Еще раз: откуда уверенность, что на такое способен каждый "производственник на месте" в свободное от основной деятельности время?
У меня есть уверенность, что таких производственников "для мест" можно и нужно готовить. Вот в этом есть уверенность.
-
Оберон, притом в варианте КП, хорош в той нише, в которую метят Google Go, Node.JS и подобные им новинки области системного ПО.
Что в данном случае подразумевается под системным ПО?
Google Go хорош прежде всего своей моделью многопоточности. В каком месте у КП многопоточность?
NodeJS хорош тем, что это жабаскрипт и его уже знают разработчики которые ближе к браузеру работают, например Яндекс переписывает модуль генерирующий страницу выдачи результатов поиска на JS (серверная сторона конечно, скорее всего там NodeJS). Сейчас оно там реализовано на перле.
-
По поводу совместимости и т.п.
Я не настаиваю 100% на какой-то крайней позиции.
Просто моё мнение, мои наблюдения говорят о том, что наибольшую (пиковую) эффективность в автоматизации дают как раз "эксклюзивные" среды, "сами себе стандарты". Например, тот же Cache. Когда-то в ряде вещей - Clarion, FoxPro. И т.п.
Я не собираюсь оправдывать их недостатки и неподходящесть для многих применений в силу как раз этой "экслюзивности". Но зато ведь в тех случаях, когда применимы - эффективность решения задач действительно пиковая, в сравнении с "тягомотиной" каких-нибудь общепринятых инструментов. Я предлагаю просто задуматься над этим. Над тем, в частности, что нужно быть осторожнее с нагромождением "солидности, как у всех".
Пример такой "солидности", на который я не устаю жаловаться - XML-технологии. Были бы плохи - не жаловался, но так очень ведь неплохи, реально решаются реальные задачи. И мы применяем. Но невозможно за вменяемое время реализовать самостоятельно полноценную поддержку. Опять условия для возникновения какой-то "паразитической прослойки" вендоров, у которых есть время только этим и заниматься - и никакой уверенности в том, что реализуют они "по уму" и так, как нужно мне, нет.
Конкретная претензия - XML Schema. Меня вполне устраивает РБНФ и его выразительное богатство. Их - не устраивает, нагромоздили совершенно сомнительный огород. Читать XML Schema человеку - невозможно, пробовали спеки на нём писать, отказались в пользу РБНФ. На валидацию тоже плюнули.
-
Что в данном случае подразумевается под системным ПО?
Google Go хорош прежде всего своей моделью многопоточности. В каком месте у КП многопоточность?
Серверное ПО и middleware.
Параллелизм у меня лично есть.
И то, что опубликовал как новинку Google при выходе Go (в декабре 2009 г.), у меня как раз в том же декабре тоже уже было. Мне было приятно видеть аналог.
Node.JS хорош тем, что это framework с объектами-кубиками для серверных приложений. "Кубиковый подход" в серверном ПО только-только начинается. И будет распространятся всё шире. Опять же, я имел это на КП ещё осенью 2009-го.
-
Если можно позволить себе роскошь использовать такие вот направленные средства, безусловно этим стоит пользоваться. К сожалению очень частно это не так. То есть сейчас кажется, что да, можно. Черен некоторое время оказывается, что нужно еще вот это и вот это, и сложность (время доработки) становится просто не реальным.
Одна из областей где можно себе позволить все или почти все – программирование микроконтроллеров. Там да… Там оберон при грамотном пиаре может возрулить. (кстати, в отличае от всего остального мира, в мире микроконтроллеров до сих пор принято продавать среды разработки). Ну, в общем то в любой из перечисленных мною где-то выше областей можно себе позволить такую специализированную штуку.
Замечу, что никто ни разу тут не сказал "Оберон нинужен!" :-) Нужен, но не везде.
PS. А доспецифицировать, хотя бы отдельным Annex'ом (пусть опциональным) что и как должно быть при выходе за границы массива и прочих радостях, было бы неплохо.
-
Да никто не говорит, что плохо.
Чтобы что-то нормально доспецифицировать, нужен реальный прецедент. Прецедент создания ещё одной реализации. И т.п. Тогда будет реальный опыт от задачи, а что нужно.
Иначе - только высасывать из пальца.
-
Серверное ПО и middleware.
Параллелизм у меня лично есть.
И то, что опубликовал как новинку Google при выходе Go (в декабре 2009 г.), у меня как раз в том же декабре тоже уже было. Мне было приятно видеть аналог.
Только в Go это есть у всех, а в КП это есть только у вашей конторы. К чему бы это? :-) Вообще штука не новая совершенно. Не слишком понятно, почему именно Go выделяете из общей массы. Язык забавный, но не более того. Тот же гугл на нем например не пишет.
Если уж на то пошло, то более гугловским сейчас является python. Google python :-)
Node.JS хорош тем, что это framework с объектами-кубиками для серверных приложений. "Кубиковый подход" в серверном ПО только-только начинается. И будет распространятся всё шире. Опять же, я имел это на КП ещё осенью 2009-го.
Эта кубиковость на серверном ПО была давно на java, erlang'e и много чем еще. А в тех масштабах, которые имют место на КП сейчас, думаю оно и лет 20-25 назад было :-)
-
Про различные аппаратные платформы - опыта нет. Про портирование компилятора - также.
Какой опыт есть - это создание серверного middleware, который работает под Windows и Linux, большинство модулей которого являются платформенно-независимыми. Одно приложение запускается и под Windows, и под Linux без перекомпиляции (т.е. большая часть системы оказывается бинарно идентичной для обоих платформ), в зависимости от выбранного пускача (exe или elf).
Это ровно одна платформа. И рантайм один и железка одна и та же.
-
Да никто не говорит, что плохо.
Чтобы что-то нормально доспецифицировать, нужен реальный прецедент. Прецедент создания ещё одной реализации. И т.п. Тогда будет реальный опыт от задачи, а что нужно.
Иначе - только высасывать из пальца.
Я бы сказал, что вначале нужен опыт портирования с одной реализации на другую. Возможность приобрести таковой опыт имеется у каждого – есть GPCP (аж под две платформы разные), есть ББ – просто море потенциальных граблей :-)
-
Нет практического интереса в таком сидении "на двух стульях". Не могу пока представить, для чего это стало бы нам нужно.
И хотелось бы избегать такого "сидения" любыми другими методами.
Если я контролирую некоторую реализацию (она в открытых исходниках и настолько компактна, что может обслуживаться самостоятельно), то какой мне интерес в других? Обслуживать две уже сложнее :)
-
Эта кубиковость на серверном ПО была давно на java, erlang'e и много чем еще. А в тех масштабах, которые имют место на КП сейчас, думаю оно и лет 20-25 назад было :-)
Про Эрланг не буду спорить. Это интересная очень штука, хотя и специфичная.
На Яве вменяемой кубиковости не наблюдалось, в частности, по причине недостаточной вменяемости проектировщиков :)
Мелкий конкретный индикатор "недостаточной вменяемости" - применение наследования реализации и негомогенных иерархий классов. Если я это вижу, сразу ставлю у себя в голове галочку "не первого сорта архитектура".
Наследования и "мейнстримовое ООП" просто не позволяют достичь той "кубиковости", которая имеется в виду.
-
А в тех масштабах, которые имют место на КП сейчас, думаю оно и лет 20-25 назад было :-)
Всё время пытаюсь донести до общественности один простой факт:
"в тех масштабах, которые имют место на КП сейчас" практически никто и никогда не ставил задачу оставаться. Ну оглянитесь вокруг: практически любой проектировщик-разработчик при первой возможности (время, трудовые ресурсы, спрос) стремится надувать проект до "солидности, масштабности" и т.п.
Сама постановка задачи - сохранять предельную, "фанатичную" компактность, аскетизм - нигде систематически за рамками Оберон-направления ещё не ставилась. Такой эксперимент идёт в единственном экземпляре. И причина повышенной конфликтности вокруг Оберон-темы часто как раз в этом непонимании - в том, что приходящие со стороны начинают требовать чего-нибудь, что не согласуется с чистотой этого эксперимента.
-
На Яве вменяемой кубиковости не наблюдалось, в частности, по причине недостаточной вменяемости проектировщиков :)
Мелкий конкретный индикатор "недостаточной вменяемости" - применение наследования реализации и негомогенных иерархий классов. Если я это вижу, сразу ставлю у себя в голове галочку "не первого сорта архитектура".
Наследования и "мейнстримовое ООП" просто не позволяют достичь той "кубиковости", которая имеется в виду.
Кубиковость в яве совершенно ортогональна длинным цепочкам наследования. Предлагаю покурить про IoC контейнеры и так далее.
-
Всё время пытаюсь донести до общественности один простой факт:
"в тех масштабах, которые имют место на КП сейчас" практически никто и никогда не ставил задачу оставаться. Ну оглянитесь вокруг: практически любой проектировщик-разработчик при первой возможности (время, трудовые ресурсы, спрос) стремится надувать проект до "солидности, масштабности" и т.п.
Сама постановка задачи - сохранять предельную, "фанатичную" компактность, аскетизм - нигде систематически за рамками Оберон-направления ещё не ставилась. Такой эксперимент идёт в единственном экземпляре. И причина повышенной конфликтности вокруг Оберон-темы часто как раз в этом непонимании - в том, что приходящие со стороны начинают требовать чего-нибудь, что не согласуется с чистотой этого эксперимента.
Не стремится. С чего бы? По возможности все лишнее всегда выкидывается. Взять скажем наши проекты – иногда после рефакторинга код уменьшается в несколько раз. Выкидываются в том числе лишние общности и так далее. Это нужно сильно мозгом повредиться, чтобы переусложнять задачу. И кто этим занимается, тот обычно вылетает в трубу.
Попыток не тащить лишнее в продукт всегда было море. Взять ту же BeOS например. Взять тот же iPhone (это уже пример из юзвериных интерфейсов). Взять юникс/posix. И так далее.
В мире винды я понимаю, да, там все сложнее, там куда ни плюнь отовсюду жир сочится. Но опять же если взять WinPhone7 – там опять упростили.
-
Попыток не тащить лишнее в продукт всегда было море. Взять ту же BeOS например. Взять тот же iPhone (это уже пример из юзвериных интерфейсов). Взять юникс/posix. И так далее.
В мире винды я понимаю, да, там все сложнее, там куда ни плюнь отовсюду жир сочится. Но опять же если взять WinPhone7 – там опять упростили.
Согласен. Но Юникс/Позикс хороши были 20 и более лет назад.
Я не вижу в мире опен-соурс-юниксов на должном уровне понимания современных проблем, приближающегося к пониманию у той же MS с её экспериментами с Сингулярностью и некоторыми другими работами MS Research (Axum и др.).
-
Попыток не тащить лишнее в продукт всегда было море. Взять ту же BeOS например. Взять тот же iPhone (это уже пример из юзвериных интерфейсов). Взять юникс/posix. И так далее.
В мире винды я понимаю, да, там все сложнее, там куда ни плюнь отовсюду жир сочится. Но опять же если взять WinPhone7 – там опять упростили.
Согласен. Но Юникс/Позикс хороши были 20 и более лет назад.
Я не вижу в мире опен-соурс-юниксов на должном уровне понимания современных проблем, приближающегося к пониманию у той же MS с её экспериментами с Сингулярностью и некоторыми другими работами MS Research (Axum и др.).
А чем юникс/позиск не хороши сейчас? :-)
У меня ощущение, что ты смотришь немного не в ту сторону. Начнем с основной ошибки: MS Research занимается опенсорс-проектами и является частью опенсорс сообщества. Внезапно, так сказать. В отличае от Microsoft.
Во-вторых посмотри например Plan B (http://ru.wikipedia.org/wiki/Plan_B_(%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0)), тот же House, Minix, и кучи других экспериментальных систем и языков, в том числе реалтаймовые, в том числе и для микроконтроллеров. Про Inferno и Plan 9 я таки молчу, ибо про это знают все. Ответвлением от этого всего является Google Go.
Linux, BSD, Solaris – это current production systems, и сравнивать их с Сингулярити не корректно абсолютно, сравнивать их надо с текущей продакшн-осью от MS – Windows 7.
Нужно очень четко понимать, что на production системе ставить эксперименты, отрабатывать новые технологии и идеи крайне глупо, хотя бы вследствие толщины и количества исторических наслоений, массы функциональности, которая в реальной работе абсолютно необходима, но для отработки концепции и поиске решений только мешает (мешает до степени полной невозможности что-либо исследовать). Поэтому революционных прорывов в linux/bsd мы не увидим, и опенсорс сообщество ими не ограничено.
Короче, я делаю вывод что с пиаром у MS все хорошо, коль они столь качественно смогли вправить мозги даже тебе :-)
-
Да, про Plan 9 и Inferno, конечно, я в курсе.
В Plan 9 интересна демонстрация того, как возможно ООП на базе процессов-сообщений вместо объектов-методов. Явные аналогии - Эрланг и ETH Composita.
Но в массовом юникс-коммюнити таки наблюдается... раздолбайское презрение к "высокоуровневым штучкам", согласитесь :)
Занятно было бы провести опрос хотя бы по реакции на понятие "сборка мусора" - сколько процентов среди юникс-программистов охарактеризуют его как отрицательное и сколько - среди Windows-программистов :) Скриптовых программистов не опрашивать (ну а функциональные особо не дадут значения :) ).
-
Идёт прерывание выполняемого алгоритма. В понятиях системы ББ (и некоторых других Оберон-систем) - инициированной команды. С какого перепуга нужно в описании языка разжёвывать, как именно будет происходить нештатное прерывание алгоритма в конкретной среде.
Прерывание КАКОГО алгоритма?
Допустим идем в цикле по массиву. Бац. вышли за пределы массива, я правильно понимаю что по этому определению у нас управление просто должно передаться оператору следующему за этим циклом? Или эта операция будет просто проигнорирована (как неправомерная) и цикл побежит дальше? Или передастся управление некому хендлеру внештатных ситуаций? Или комп прекратит работу? Что-то еще?
В описании языка должен быть описан механизм обработки таких ситуаций, либо явно сказано, что хз что будет (undefined behaviour – означает именно то самое, что то, что произойдет зависит от конкретной реализации языка и среды, железа и так далее).
Но если язык позиционируется надежным, то подобные ситуации должны максимально четко быть рассмотрены в спеке на язык.
Да, а софистику не я первый начал. Кто к нам с мячом придет, тому и в воротах стоять :-)
Что должно произойти при выходе индекса за пределы массива - можно посмотреть в исходном коде модуля обеспечения времени исполнения, Kernel (для КП): http://oberon.talk4fun.net/WeBB//System/Mod/Kernel.html (http://oberon.talk4fun.net/WeBB//System/Mod/Kernel.html) ( PROCEDURE DefaultTrapViewer, см. ошибку №135 )
Разумеется, в описании языка можно обнаружить отсутствие таких элементарных вещей, как механизма оповещения пользователя об обнаруженной компилятором ошибке. Мне кажется, что не нужно смешивать техническое описание языка и техническое описание компилятора того же языка. Описание языка не должно включать в себя описание реализации самого языка. Так что, на самом деле, проблема высосана из пальца.
-
Что должно произойти при выходе индекса за пределы массива - можно посмотреть в исходном коде модуля обеспечения времени исполнения, Kernel (для КП):
Вы там увидите только то, в чем именно заключается неописанный в языке undefuned behavior. Все описанные проблемы (vendor lock, переносимость) - остаются в силе. Да, эти проблемы могут быть неактуальными для вас (или казаться неактуальными).
-
Что касается необходимости наличия тех. описания компилятора - я не отрицаю. Надо тем, кто разрабатывает компилятор. Но к языку это не относится.
-
При чем тут потроха компилятора вообще?
Выход за границу массива, деление на нуль и так далее – это семантика языка, это много важнее чем скажем синтаксис (который, кстати, можно выкинуть чуть менее чем полностью без особых потерь). На данный момент в описании языка КП семантика языка описана не полностью, следовательно язык определен не полностью.
-
valexey, приведи, пожалуйста, пример предлагаемого тобою уточнения.
-
valexey, приведи, пожалуйста, пример предлагаемого тобою уточнения.
Например как это определено в Модуле-2
5.3.8.4 Run-time Bounds Checking
Access to the indeterminate array field of a record of indeterminate type is bounds checked at run- time in the same manner as access to a determinate array is checked. The compiler automatically inserts the code to check array indices against the determinant field. Any attempt to access the array with a subscript that is out of bounds results in a run-time error.
В реалиях КП (именно КП а не ББ!) можно сказать, что в случае выхода за пределы массива будет выполнен HALT(). Аналогично с делением на ноль целых чисел (для вещественных чисел это, очевидно не так, ибо их поведение описано в соответствующем стандарте от IEEE).
-
Ах, да, еще неплохо бы знать что случится при арифметическом переполнении.
-
Насколько я помню, без включённых особо доп. проверок ничего. Приводился пример с переполнением в цикле FOR и байтовым счётчиком.
-
Насколько я помню, без включённых особо доп. проверок ничего. Приводился пример с переполнением в цикле FOR и байтовым счётчиком.
Это "ничего" сильно зависит от железки. Т.е., все тот же undefined behavior. А где пример приводился?
-
Насколько я помню, без включённых особо доп. проверок ничего. Приводился пример с переполнением в цикле FOR и байтовым счётчиком.
Я не понимаю что значит "ничего". Вот у меня 8ми битная переменная. Значение у нее текущее 255, я инкрементирую её на единицу -- что значит "ничего"? То есть 255 и останется? Ибо если оно вдруг обнулится, это будет очень даже чего.
-
Но в массовом юникс-коммюнити таки наблюдается... раздолбайское презрение к "высокоуровневым штучкам", согласитесь :)
Занятно было бы провести опрос хотя бы по реакции на понятие "сборка мусора" - сколько процентов среди юникс-программистов охарактеризуют его как отрицательное и сколько - среди Windows-программистов :) Скриптовых программистов не опрашивать (ну а функциональные особо не дадут значения :) ).
Не, не соглашусь. Как-то резко все под одну гребенку. Давайте делить на мух и котлет оную субстанцию.
Итак, что мы имеем? Во-первых мы имеем разработчиков пишущих драйвера, куски ядра, системные сервисы, вообще вещи критические как по быстродействию так и по памяти. Тут, очевидно, соборщику мусора не место, тут не место даже просто жирному рантайму и стандартным либам. Поэтому это в основном Си (именно Си еще и потому, что posix на си завязян, кстати, я настолько уверен что позикс завязан на си, что уже начинаю в этом сомневаться, надо бы доки внимательно зачесть).
Далее мы имеем скриптинг. То есть автоматизацию рутинных операций пользователя ЭВМ. Не важно кто этот пользователь – программист, домохозяйка или доктор физмат наук. Важно что он сам автоматизирует оную рутину посредством написания так называемых скриптов. Тут важна хорошая интеграция языка с шелом (оболочкой в которой пользователь обычно работает) системы, посему тут рулят языки которые умеют легко и просто работать со стандартными потоками ввода-вывода и строками. А также не грузят пользователя-скриптопрограммиста своими мегапарадигмами навроде ООП там, строгой типизации и прочими артефактами программинга, ручное управление памятью сюда тоже входит. Соответственно тут рулят такие языки как shell, python, perl. У некоторых из них есть сборщик мусора, у некоторых нет. Но память в любом случае там управляется не руками.
Далее имеем разработку всякого прикладного софта, который с одной стороны пишется один раз, а используется многими и при этом достаточно сложен (посему это не скриптинг), с другой стороны он должен быть достаточно технологичен, то есть дешев в производстве и при этом там нет таких жестких ограничений на память и проц как в системных сервисах, но они все равно есть. Поскольку он сложен, тут уже без программерских артефактов, вроде того же ООП не обойтись, ибо нужно как-то со сложностью бороться. Поскольку он должен быть достаточно дешев, тут автоматическое управление памятью желательно, хотя и не обязательно (ряд задач например все равно требует таки реалтайма, например те же игры). Да, и при этом он должен быть легко скомпилирован на большенстве машин потенциальных пользователей оными пользователями не программистами. То есть инструментарий должен быть легко доступен во всех смыслах этого слова. Тут рулит сонма языков. Это: vala, java, c#, c++, ObjC, C, python, erlang, ruby, js, lua и так далее. Причем часто используются сочетания языков. Например C + Python. Подавляющее большенство этих языков имеют автоматическое управление памятью в том или ином виде, большенство из них имеют сборщик мусора.
-
Я не понимаю что значит "ничего". Вот у меня 8ми битная переменная. Значение у нее текущее 255, я инкрементирую её на единицу -- что значит "ничего"? То есть 255 и останется? Ибо если оно вдруг обнулится, это будет очень даже чего.
Пример был на oberoncore.ru. Сейчас уже не найду. Происходит, естественно, переполнение в 0.
-
Я не понимаю что значит "ничего". Вот у меня 8ми битная переменная. Значение у нее текущее 255, я инкрементирую её на единицу -- что значит "ничего"? То есть 255 и останется? Ибо если оно вдруг обнулится, это будет очень даже чего.
Пример был на oberoncore.ru. Сейчас уже не найду. Происходит, естественно, переполнение в 0.
В сообщении о языке поведение в этом случае никак не специфицировано, следовательно там может быть все что угодно. Например HALT() или некий аналог ему. Или может вылезти -1, а может внезапно испортиться память в соседней ячейке. Это типичный ub, который к тому же таковым в спеке на язык не обозначен, что как бэ усугубляет.
-
Я не понимаю что значит "ничего". Вот у меня 8ми битная переменная. Значение у нее текущее 255, я инкрементирую её на единицу -- что значит "ничего"? То есть 255 и останется? Ибо если оно вдруг обнулится, это будет очень даже чего.
Пример был на oberoncore.ru. Сейчас уже не найду. Происходит, естественно, переполнение в 0.
Вот это как раз НЕ естественно. Вообще, если исходить из того, что описание языка - это есть спецификация некоторой виртуальной машины (а по Вирту вроде именно так и есть), то спецификация должна описывать ВСЕ.В том числе и все операции в деталях.
Либо должно быть явное указание на то, что данная операция отображается на реальную операцию "железа".
Ведь с памяться в описании КП написано совершенно явно - должна быть сборка мусора, иначе это - не КП.
При сертификации компиляторов Ады поступили так же: компилятор ДОЛЖЕН удовлетворять определеннным свойствам-качествам, иначе это - не компилятор Ады.
-
А мне думается, что стандартизация КП на данный момент - лишнее. Во-первых, отсутствие ISO-стандарта характерно для множетсва языков. Даже Педивикия в курсе:
A programming language is usually split into the two components of syntax (form) and semantics (meaning) and many programming languages have some kind of written specification of their syntax and/or semantics. Some languages are defined by a specification document, for example, the C programming language is specified by an ISO Standard, while other languages, such as Perl, have a dominant implementation that is used as a reference.
Или тот же Python. Есть референсная реализация CPython. Во всяких там Jython'ах и IronPyton'ах есть отличия. Так что покамест можно отталкиваться от ББ, как референсной реализации. Пока, потому что на данный момент популярность КП мала. Мала настолько, что стандартизация бессмысленна. А может даже и опасна, так как "заморозит" язык и в потенциале родит проблемы, связанные с поддержкой обратной совместимости. Для того же С++ стандартизация была проведена по острой необходимости. Когда популярность стала высока, а различие между реализациями велико. К этому моменту был накоплен неплохой опыт использования С++ и стандартизация была делом тривиальным. По сути были закреплены best implementation practices. Для КП время ещё не подошло. То есть стандартизация должна следовать за широкой распространённостью языка, а не служит средством её достижения.
-
Вот это как раз НЕ естественно. Вообще, если исходить из того, что описание языка - это есть спецификация некоторой виртуальной машины (а по Вирту вроде именно так и есть), то спецификация должна описывать ВСЕ.В том числе и все операции в деталях...
Порочный и бессмысленный путь (в лучшем случае результатом будет "удачное" описание ЯП) ..... Изходить НУЖНО из того ЯП является описанием - 1. одной из моделей коцепции алгоритма (как метода решения задач, описания систем). 2 Модели исполнителя . 3 .Модели восприятия синтаксических конструкций человеком... Короче... у меня хандра :-\\
-
А мне думается, что стандартизация КП на данный момент - лишнее. Во-первых, отсутствие ISO-стандарта характерно для множетсва языков. Даже Педивикия в курсе:
За ISO-стандартизацию КП никто не ратует, мы ратуем лишь за полноту описания языка, с чем в том же Python'e много лучше.