OberonCore

Послушайте, я привёл в пример возможность DEP. А вы вызвалсь показать, что это такое(сам я только теоретически представляю себе сабж). А теперь вы показали оказывается не то, но по прежнему оберон виноват. Странно это.Про базовые типы я тут уже наговорил столько всякого, что трудно описать. Разве наличие хотя бы минимального предсказания поведения системы - это минус? Я знаю, что вот под этим указателем точно вот этот тип данных. Это плохо? Я знаю, что есть минимальный описательный базис, который останется строго таким, каким он описан в документации. Это плохо? Я знаю, что таким макаром можно описать всё что угодно, если над этим подумать. Это плохо?Не понял, извините.Метод тыка против вдумчивого(ну, более-менее) анализа. Кстати в ББ можно легко передавать указатели как результат функции, причём безопасно(насколько я знаю). Это тоже решение для устранения вашего бага(в ББ).

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

Я показал, что DEP возможен и на обероне, и следовательно "фокусы" C++ отношения к DEP не имеют.



Ага. Наговорили много чего. Все теми же аналогиями и метафорами. Покажите технически и практически - чем плох i.ToString(). Теория мне интересна только если она находит отражение в практике.



Не подменяйте понятия. Я сказал именно то, что сказал. Необходимость скакать по модулями без необходимости никак не признак "вдумчивости", а признак хренового кода.



Это ставит крест на использовании стэковых объектов (предмет гордости оберонщиков перед всякими жабами). А ошибки куда возвращать? Эксепшинов-то нету...

Да, он не гарантирует правильность. Но он гарантирует большую наглядность, потому что написать откровенную лажу уже труднее:


А если еще совместить инициализацию и объявление (что опять таки невозможно в обероне):


то даже лажу написать не получится.

Дак вы же не DEP показали, сами же сказали.
Не перегибайте, я объяснил и абстракции и примеры. Не один раз.
Проведите исследовательскую работу. Определите статистические показатели. Только вот показатели чего? Я не знаю. Вы - тоже. Никто пока не сказал. Мерялки нет, как тут уже выяснили. Я вам сейчас могу сказать только то, что метод целого числа - это неверное отражение реальности, и неверная реализация математического понятия числа. конечно, объект i похож на целое число, его можно складывать, умножать и прочее. Но это лишь результат перегрузки операторов. Итог: вы мыслите не реальным понятием "число", а мнимым "uint". Хотя может вам всё равно.Я и не подменяю. Вы ищете аналогии, пытаетесь найти похожие вызовы. Надеюсь, вам не надо рассказывать про опасность аналогий. Хреновость кода не измерить, это выяснено было ранее. Если я увидел процедуру первый раз, то без подглядываний в интерфейс или документацию я не могу даже предугадать, что эта процедура из себя представляет(если вы можете, то вы - бог). Поэтому я так не делаю. Я вдумчиво гляжу в интерфейс и доку.Предмет гордости? Ммм. А где такое написано? А как же ASSERT и HALT? Чем не эксепшены? Суть одна. А что мешает сделать функцию с параметрами? Типа:
где в res будет записан код ошибки.Это субъективно.А ещё можно в гамаке стоя. Это синтаксический сахар. Без него можно обойтись.Вопрос квалификации.

Я показал возможность DEP. Чтобы получить рабочий пример (исполнение вредоносного кода) вам придется заполнить массив "правильными" значениями. Если вы этого не сделаете, то получите банальный SEH (и в C/C++ тоже). Правильные значения можно поискать по хакерским форумам (я никогда неинтересовался).

Какие примеры? Примеры кода? Абстрактные примеры, основанные на аналогиях - ничего не показывают, кроме ораторских способностей автора.



Почему??? В реальности вообще нет "методов". И что?



Все предугадать - не могу. Но хочу иметь возможность предугадывать по максимуму. Об чем и речь. Для приведенных мной примеров оберон такой возможности не предоставляет. В отличие от других языков. Можете оправдывать его как угодно (простота языка, простота компилятора и т.д.), но это объективный недостаток.



Ну почитайте критику жабы оберонщиками...



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



А что будет в y? Мусор?



Вы лукавите. Или не хотите видеть очевидного в силу своей веры в оберон.



В гамаке стоя - это объявлять буфер для преобразования числа в строку. А совмещение объявления и инициализации позволяет избежать вполне конкретных ошибок. А в качестве бонуса - нагляднее и короче.



Можно. Но ради чего?



Нет. Вопрос квалификации - это не только писать код без багов. Высокая квалификация - это понятный код. Очень высокая квалификация - это код, который трудно неправильно использовать.

Особой понятливостью выделяется код устоявшихся библиотек на С++.
80% препроцессора, помноженное на шаблонное представление -
просто верх понятного кода.

1. Плюсовый код не самый приятный для восприятия. Чисто синтаксически. Особенно в части шаблонов. Тут трудно поспорить. Хотя по мне - обероновский еще хуже Но это все не так принципиально. Я говорил не про синтаксис сам по себе, а про выразительность (ну нельзя на обероне выразить то, что можно на шаблонах в C++).
2. Стандартные библиотеки - это отдельная песня. Они должны работать на всем и везде. И при этом работать максимально эффективно. Покажите мне подобную библиотеку для оберона, тогда сравним Вот тут товарищ XML-парсер портировал с одного оберона на другой. У него получилась отдельная реализация. Я считаю, что лучше с препроцессором, но одна.
3. К счастью стандартные библиотеки хорошо документированы и их интерфейс очень редко меняется. Так что реально смотреть в код приходится очень редко.



У нас всего две платформы и три компилятора. Препроцессор для разделения кода по платформам/компиляторам используется крайне редко (ну может одна директива на сотню файлов). Разделение кода по платформам идет по всем правилом ООП - через интерфейсы. Так что препроцессор - удел библиотек. Шаблонный код тоже тяготеет к библиотечному использованию (далеко не 80%).

Кстати, в том же C# такая процедура будет определена примерно так:
А вызываться будет соответственно так:Сразу видно, что эта процедура что-то пишет в параметр x2.

Не, что вы, какой код. Код тут вообще не причём. Я пытался наглядно показать схему использования базовых типов и преобразователей(тип в тип). Это ваше замечание можно списать на поверхностное прочтение...
Я ведь не про ООП говорил. Я говорил про целое число. У которого есть довольно устоявшаяся математическая модель, которую вбивают в ваш мозг 16 лет к ряду.Я вообще не хочу гадать. Поэтому юзаю доку и браузер интерфейсов. И это не только в Обероне, во всех других ЯП(fpc, c++) я делал точно так же.Их можно использовать для выявления, на самой ранней стадии разработки. Что лучше, самому наткнуться на ассерт, или сотню клиентов заставить "Отправить отчёт какой-то там матери"? Оборонительный стиль, кажется так.Значение. Значение будет. Типа Y. Если у функции f() корявая реализация и не все поля инитятся - это программист дурак, а не язык плохой.Да субъективно это. Субъективно. Ваш уровень профессионализма позволит вам "предугадать" только за счёт тех шишек которые вы набили ранее, за счёт везения, и удачных аналогий, не более.Решайте сами. Я плохо вижу ОГРОМНЫЕ преимущества совмещения объявления и инициализации. Ну да, типа удобно, типаКак и в Оберонах. СРАЗУ видно.

1. Индусы (условные) пишут индусский код.
2. IBM выпускает автоматический "баго-фиксер".
3. Здесь приведён пример индусского кода, использующего "тонкости" языка для ухудшения понятливости программы и повышения багливости.
4. Высказывается мысль, что при отсутствии "тонкостей" в ЯП, код станет менее багливым (понятно, при прочих равных условиях).
5. На это выдаётся возражение, что при наличии замечательной квалификации, "тонкости" не страшны, а даже нужны, т.к. повышают читабельность.

Корпорация IBM путём выпуска RSA не ищет способы поднять квалификацию, что нужно Vlad'у, а борется с конкретными багами. Парсеров XML в природе далеко не один штук, как хочется Vlad'у. Реальные программы глючные и непонятные, несмотря на наличие высококвалифицированных кадров где-то поблизости.

Как обычно, реальность немного не такая, как её представляет себе Vlad

У нас разное восприятие (чисто психологически) текстов на С-подобных и Pascal-подобных языках.
Мне всегда казалось, что текст на Pascal гораздо понятнее, чем сишный. Даже, если он плохо написан.
Потому как плохой Pascal код еще как-то можно понять, а вот С-подобный. Сам черт, ногу сломит.

По мне критерий хорошего кода - это когда почти сразу можно понять как оно все работает. (Практически) Без комментариев и документации.


P.S. Аллергию на С-подобный синтаксис я в в свое время получил от MFC. Вот где "индусы" прошлись.
OWL от Borland была гораздо лучше устроена. А на работе на java приходится писать.

А не могли бы Вы продемонстрировать? На Оберонах... Желательно разных... :о)

Берём самый близкий, БлэкБокс(КП соответсвтвенно).
А просьба была написать пример вызова. Не углядел. Да, решение.
В Обероне и Active Oberon - есть только VAR параметры. Суть та же. Доку смотрите сами.

Это не то, о чём говорил Geniepro. При объявлении процедуры всё понятно, но при использовании нужно посмотреть интерфейс, потому что можно не догадаться, в какую из трёх переменных ведётся запись, и вообще непонятно, там в одну переменную пишется, в две или вообще в три. Дублирование out в объявлении и использовании процедуры, кончечно улучшает читаемость, но это, всё же, дублирование, что само по себе утомительно. Но приверженцы Си-подобного синтаксиса вообще должны впадать от этого в кому: почти каждая конструкция этого языка - пример сверхминимализма. А здесь не просто расточительство - здесь дублирование.

Но с out читается, всё же, лучше, чем без out.

Предположения. Это стиль программирования такой?
Это не для "лучше читается". Это для определения логики поведения процедуры. Идеальный программист использовав VAR(OUT)-определённый параметр предполагает его использование в качестве переменной. Поэтому другой программист, должен преполагать то же. Частичная инициализация, или полная, или ещё что-то, неважно. VAR определяет возможность изменения, это надо учитывать. А использование функций, вместо замены процедур с VAR-параметрами, мягко говоря не даёт тех же возможностей. Неравнозначная замена, ущербное решение проблемы человеческого фактора на уровне языка.

Ну и что такое Вы тут процитировали? Где вызов процедуры в стиле Modify (VAR n); или ReadInt (OUT x); ? Ась?

О, сорри.
P.S. Хотя мне кажется, что это ещё одно решение человеческой ошибки на уровне языка.

Да напишите-ж им quicksort алгоритм на Хаскелле и шоб работал, а то выглядит не иначе как обфускация
http://www.haskell.org/haskellwiki/Intr ... ranslationНа Обероне так точно написать нельзя!