Автор Тема: Тезис про Oberon, C, CP и ObjC.  (Прочитано 42891 раз)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #15 : Март 07, 2011, 08:40:07 pm »
Вот тут большое недопонимание касательно невостребованности.

Это иллюзия.

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

Ну да. Может. Только Виртов мало, а задач много. Поэтому штучная "оберон система с нуля" быстро, качественно и дешево - это иллюзия. Поэтому побеждает обычно более мэнйстримное "быстро и дешево". Что, конечно, не исключает исключений...

DIzer

  • Гость
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #16 : Март 08, 2011, 03:23:38 pm »


Ну да. Может. Только Виртов мало, а задач много. Поэтому штучная "оберон система с нуля" быстро, качественно и дешево - это иллюзия. Поэтому побеждает обычно более мэнйстримное "быстро и дешево". Что, конечно, не исключает исключений...

Да нет, не иллюзия... а рекламная агитка, для тех кто хочет обмануться... но таких мало, и слава богу...

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #17 : Март 08, 2011, 07:22:10 pm »
Я не буду с Вами спорить однозначно, но вопрос интересный.

Что понимать под behavior? Behavior - это всё-таки продолжение работы программы (хотя бы с некоторой вероятностью). А если behaviour, даже undefined-ный, на глупую операцию не задан, то подразумевается, что никакого behavior-а не будет, вычисления будут прерваны.
Полное прерывание вычислений – это аварийный останов ЭВМ. Например как это случилось на Ариане. Любое иное – это не полное прерывание вычислений, по сути это вообще не прерывание вычислений, а просто вычисления пойдут по другой ветке. Так вот, я ни разу не видел, чтобы по выходу за границу массива у меня в ББ были бы вычисления действительно прерваны. Таким образом behaviour таки имеет место. Причем он там неявно undefined :-) По моему, хуже ситуацию придумать довольно сложно.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #18 : Март 08, 2011, 07:41:37 pm »
Какая-то тупая софистика.

Идёт прерывание выполняемого алгоритма. В понятиях системы ББ (и некоторых других Оберон-систем) - инициированной команды. С какого перепуга нужно в описании языка разжёвывать, как именно будет происходить нештатное прерывание алгоритма в конкретной среде.

Высосанные из пальца проблемы (при том у тех, у кого вообще нет практики в обсуждаемых технологиях) и ещё более надуманное их обсасывание.
Как же скучно.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #19 : Март 08, 2011, 07:45:51 pm »
И всё-таки конкретный жизненный вопрос: кому это жить помешало?

Если в подробно стандартизированных языках вещей, "жить мешающих", пруд пруди, а тут при ряде второстепенных опущений никому ещё это не помешало, то чего огород городить.
Оно мешает жить когда язык становится достаточно широко употребимым. Сейчас использование Оберона и его производных примерно эквивалентно использованию С++ в 1985-1986 годах. Это если считать по числу разработчиков, если же считать по рыночной доле, то, как понимаешь, еще печальней. Тогда, в 1985 году, никто о стандартизации языка ( C++ ) в общем то и не заикался даже. Оно и понятно – в таких масштабах не зачем он. Но спека таки писалась и довольно подробная (то есть малая популярность языка (и малая динамика его роста) служит причиной отсутствия процесса стандартизации оного языка, но не является достаточным оправданием для недостаточно четкой спецификации обсуждаемых моментов, если язык позиционируется как безопасный).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #20 : Март 08, 2011, 07:47:46 pm »
Цитировать
Ну да. Может. Только Виртов мало, а задач много.

Только не решаются оне... задачи энти.
Что-то маловато довольных пользователей в сфере той же автоматизации предприятий. "Большие решения" (типа ERP от серьёзных поставщиков) работают и хорошо интегрируются, но люди недовольны, потому что они не решают именно их задач, несмотря ни на какую customization. Более мелкие решения работают плохо, плохо интегрируются, их пробуют и меняют один за одним... Под себя разработанные решения во многих случаях вообще толком не работают в силу невозможности найти адекватных исполнителей.
Но если уж повезло с исполнителями, то обычно работают лучше всего.

Отсюда разумно и "человеколюбиво" по отношению к страждущим нормальной автоматизации организациям - выращивать как можно больше таких адекватных исполнителей или вооружать их подходом, практиками, инструментами для такой штучной автоматизации.

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #21 : Март 08, 2011, 07:50:48 pm »
Цитировать
Оно мешает жить когда язык становится достаточно широко употребимым

Вот тогда и следует доуточнять вопросы, по мере их актуальности.

Неужели неясен совершенно очевидный факт, что действовать иначе - это плодить мертворожденный мусор...

Инварианты, инварианты - вот ключевое слово. Ловить и фиксировать сегодня ровно то, что уже очевидно из опыта, что не "поплывёт" год или два спустя.
Остальным пусть занимаются, кому делать нечего.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #22 : Март 08, 2011, 07:53:36 pm »
Это тоже та ещё "замануха": лидеры-гиганты строчат внушительные такие тома, стандарты, на реализацию которых уйдёт не один год, и как бы приглашают "делайте так же, если хотите, чтобы вас воспринимали всерьёз".
И народ даже из академической среды, из open-source и т.п. начинает втягиваться в эту гонку - "чтоб всё было солидно".
Тратит несколько лет жизни на какой-нибудь ОДИН такой "чинный и солидный" проект. И, разумеется, о какой-то конкуренции можно просто забыть.

Вместо того, чтобы развязать руки от второстепенных мелочей и пройти по грани "необходимого и достаточного", решив за то же время целый ряд задач. Как Вирт с ПК, ОС и прикладными пакетами, или новосибирцы с Кроносом. Да и многие коллективы, сталкивающиеся с "особыми задачами", таким же путём идут. У них выбора нет просто. Как у многих наших оборонных контор, которые разрабатывают свои CASE-решения.

Про какие стандарты идет речь? На средствах разработки давно никто не зарабатывает из гигантов и даже не гигантов (ну, разве что как-то живет этим JetBrains, да и то…).

Стандарты/спецификации максимально подробные производителю софтверной продукции (любого размера) не нужны категорически. Они всегда мешают. Стандарты и спецификации нужны прежде всего заказчику, чтобы избежать явления известного как vendor lock in. Поэтому они и появляются, эти стандарты. В интересах заказчика не зависеть от данного конкретного решения данного конкретного вендора, иметь возможность спокойно его заменить, в случае необходимости на другое решение другого вендора. Интересы вендоров прямо противоположны.

Я занимался скадами и автоматизацией. У нас таки как раз было гм… не стандартное решение, в качестве протокола (как это обычно бывает в таких решениях) использовался fpp. Так вот, заказчик стал неописуемо счастлив (и отвалил деньгу немалую) когда мы прикрутили гейт для передачи наших данных по OPC. Просто потому, что в случае чего теперь нас хоть как-то можно было заменить, и хоть как-то можно было интегрироваться со внешним миром. Между прочим, всякий разный сименс тоже не слищком рад требованиям поддержки OPC, ибо это сильно мешает намертво завязать заказчика на себя.

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #23 : Март 08, 2011, 07:55:27 pm »
Цитировать
Оно мешает жить когда язык становится достаточно широко употребимым

Вот тогда и следует доуточнять вопросы, по мере их актуальности.

Неужели неясен совершенно очевидный факт, что действовать иначе - это плодить мертворожденный мусор...

Инварианты, инварианты - вот ключевое слово. Ловить и фиксировать сегодня ровно то, что уже очевидно из опыта, что не "поплывёт" год или два спустя.
Остальным пусть занимаются, кому делать нечего.

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #24 : Март 08, 2011, 08:02:04 pm »
Идёт прерывание выполняемого алгоритма. В понятиях системы ББ (и некоторых других Оберон-систем) - инициированной команды. С какого перепуга нужно в описании языка разжёвывать, как именно будет происходить нештатное прерывание алгоритма в конкретной среде.
Прерывание КАКОГО алгоритма?
Допустим идем в цикле по массиву. Бац. вышли за пределы массива, я правильно понимаю что по этому определению у нас управление просто должно передаться оператору следующему за этим циклом? Или эта операция будет просто проигнорирована (как неправомерная) и цикл побежит дальше? Или передастся управление некому хендлеру внештатных ситуаций? Или комп прекратит работу? Что-то еще?

В описании языка должен быть описан механизм обработки таких ситуаций, либо явно сказано, что хз что будет (undefined behaviour – означает именно то самое, что то, что произойдет зависит от конкретной реализации языка и среды, железа и так далее).

Но если язык позиционируется надежным, то подобные ситуации должны максимально четко быть рассмотрены в спеке на язык.

Да, а софистику не я первый начал. Кто к нам с мячом придет, тому и в воротах стоять :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #25 : Март 08, 2011, 08:09:28 pm »
Высосанные из пальца проблемы (при том у тех, у кого вообще нет практики в обсуждаемых технологиях) и ещё более надуманное их обсасывание.
Как же скучно.

Расскажите про ваш опыт портирования систем на КП на нескольких платформ. В смысле есть он или нет. Если же подобной практики у вас нет, то расскажите почему вы так уверены, что в случае КП подобные "высосанные" проблемы не актуальны (может быть портирование вообще не предусматривается, просто каждый раз создаем с нуля)?

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #26 : Март 08, 2011, 08:12:51 pm »
Кстати, да, было бы интересно услышать про опыт портирования чего-нибудь например из ББ в GPCP и обратно.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #27 : Март 08, 2011, 08:16:26 pm »
Только не решаются оне... задачи энти.
Что-то маловато довольных пользователей в сфере той же автоматизации предприятий.

Ну хорошо. Есть такая проблема. Казалось бы, причем тут оберон? Потому что Вирт смог соорудить такую систему с нуля? Еще раз: откуда уверенность, что на такое способен каждый "производственник на месте" в свободное от основной деятельности время?

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #28 : Март 08, 2011, 08:16:44 pm »
Вообще, как я понял из обсуждения, притензий к самому тезису нет, он верен и его можно пускать в народ :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #29 : Март 08, 2011, 08:31:18 pm »
Отсюда разумно и "человеколюбиво" по отношению к страждущим нормальной автоматизации организациям - выращивать как можно больше таких адекватных исполнителей или вооружать их подходом, практиками, инструментами для такой штучной автоматизации.

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