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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #45 : Март 09, 2011, 05:11:39 pm »
Если можно позволить себе роскошь использовать такие вот направленные средства, безусловно этим стоит пользоваться. К сожалению очень частно это не так. То есть сейчас кажется, что да, можно. Черен некоторое время оказывается, что нужно еще вот это и вот это, и сложность (время доработки) становится просто не реальным.

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

Замечу, что никто ни разу тут не сказал "Оберон нинужен!" :-) Нужен, но не везде.

PS. А доспецифицировать, хотя бы отдельным Annex'ом (пусть опциональным) что и как должно быть при выходе за границы массива и прочих радостях, было бы неплохо.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #46 : Март 09, 2011, 05:15:18 pm »
Да никто не говорит, что плохо.

Чтобы что-то нормально доспецифицировать, нужен реальный прецедент. Прецедент создания ещё одной реализации. И т.п. Тогда будет реальный опыт от задачи, а что нужно.
Иначе - только высасывать из пальца.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #47 : Март 09, 2011, 05:18:22 pm »
Серверное ПО и middleware.
Параллелизм у меня лично есть.

И то, что опубликовал как новинку Google при выходе Go (в декабре 2009 г.), у меня как раз в том же декабре тоже уже было. Мне было приятно видеть аналог.
Только в Go это есть у всех, а в КП это есть только у вашей конторы. К чему бы это? :-) Вообще штука не новая совершенно. Не слишком понятно, почему именно Go выделяете из общей массы. Язык забавный, но не более того. Тот же гугл на нем например не пишет.

Если уж на то пошло, то более гугловским сейчас является python. Google python :-)

Node.JS хорош тем, что это framework с объектами-кубиками для серверных приложений. "Кубиковый подход" в серверном ПО только-только начинается. И будет распространятся всё шире. Опять же, я имел это на КП ещё осенью 2009-го.
Эта кубиковость на серверном ПО была давно на java, erlang'e и много чем еще. А в тех масштабах, которые имют место на КП сейчас, думаю оно и лет 20-25 назад было :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #48 : Март 09, 2011, 05:19:09 pm »
Про различные аппаратные платформы - опыта нет. Про портирование компилятора - также.
Какой опыт есть - это создание серверного middleware, который работает под Windows и Linux, большинство модулей которого являются платформенно-независимыми. Одно приложение запускается и под Windows, и под Linux без перекомпиляции (т.е. большая часть системы оказывается бинарно идентичной для обоих платформ), в зависимости от выбранного пускача (exe или elf).

Это ровно одна платформа. И рантайм один и железка одна и та же.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #49 : Март 09, 2011, 05:20:22 pm »
Да никто не говорит, что плохо.

Чтобы что-то нормально доспецифицировать, нужен реальный прецедент. Прецедент создания ещё одной реализации. И т.п. Тогда будет реальный опыт от задачи, а что нужно.
Иначе - только высасывать из пальца.
Я бы сказал, что вначале нужен опыт портирования с одной реализации на другую. Возможность приобрести таковой опыт имеется у каждого – есть GPCP (аж под две платформы разные), есть ББ – просто море потенциальных граблей :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #50 : Март 09, 2011, 05:47:50 pm »
Нет практического интереса в таком сидении "на двух стульях". Не могу пока представить, для чего это стало бы нам нужно.
И хотелось бы избегать такого "сидения" любыми другими методами.

Если я контролирую некоторую реализацию (она в открытых исходниках и настолько компактна, что может обслуживаться самостоятельно), то какой мне интерес в других? Обслуживать две уже сложнее :)

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #51 : Март 09, 2011, 05:51:52 pm »
Эта кубиковость на серверном ПО была давно на java, erlang'e и много чем еще. А в тех масштабах, которые имют место на КП сейчас, думаю оно и лет 20-25 назад было :-)

Про Эрланг не буду спорить. Это интересная очень штука, хотя и специфичная.

На Яве вменяемой кубиковости не наблюдалось, в частности, по причине недостаточной вменяемости проектировщиков :)
Мелкий конкретный индикатор "недостаточной вменяемости" - применение наследования реализации и негомогенных иерархий классов. Если я это вижу, сразу ставлю у себя в голове галочку "не первого сорта архитектура".

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

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #52 : Март 09, 2011, 05:56:44 pm »
А в тех масштабах, которые имют место на КП сейчас, думаю оно и лет 20-25 назад было :-)

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

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #53 : Март 09, 2011, 05:59:49 pm »
На Яве вменяемой кубиковости не наблюдалось, в частности, по причине недостаточной вменяемости проектировщиков :)
Мелкий конкретный индикатор "недостаточной вменяемости" - применение наследования реализации и негомогенных иерархий классов. Если я это вижу, сразу ставлю у себя в голове галочку "не первого сорта архитектура".

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

valexey

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

Сама постановка задачи - сохранять предельную, "фанатичную" компактность, аскетизм - нигде систематически за рамками Оберон-направления ещё не ставилась. Такой эксперимент идёт в единственном экземпляре. И причина повышенной конфликтности вокруг Оберон-темы часто как раз в этом непонимании - в том, что приходящие со стороны начинают требовать чего-нибудь, что не согласуется с чистотой этого эксперимента.
Не стремится. С чего бы? По возможности все лишнее всегда выкидывается. Взять скажем наши проекты – иногда после рефакторинга код уменьшается в несколько раз. Выкидываются в том числе лишние общности и так далее. Это нужно сильно мозгом повредиться, чтобы переусложнять задачу. И кто этим занимается, тот обычно вылетает в трубу.

Попыток не тащить лишнее в продукт всегда было море. Взять ту же BeOS например.  Взять тот же iPhone (это уже пример из юзвериных интерфейсов). Взять юникс/posix. И так далее.

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

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #55 : Март 10, 2011, 12:04:31 pm »
Попыток не тащить лишнее в продукт всегда было море. Взять ту же BeOS например.  Взять тот же iPhone (это уже пример из юзвериных интерфейсов). Взять юникс/posix. И так далее.

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

Согласен. Но Юникс/Позикс хороши были 20 и более лет назад.
Я не вижу в мире опен-соурс-юниксов на должном уровне понимания современных проблем, приближающегося к пониманию у той же MS с её экспериментами с Сингулярностью и некоторыми другими работами MS Research (Axum и др.).

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #56 : Март 10, 2011, 05:49:29 pm »
Попыток не тащить лишнее в продукт всегда было море. Взять ту же BeOS например.  Взять тот же iPhone (это уже пример из юзвериных интерфейсов). Взять юникс/posix. И так далее.

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

Согласен. Но Юникс/Позикс хороши были 20 и более лет назад.
Я не вижу в мире опен-соурс-юниксов на должном уровне понимания современных проблем, приближающегося к пониманию у той же MS с её экспериментами с Сингулярностью и некоторыми другими работами MS Research (Axum и др.).
А чем юникс/позиск не хороши сейчас? :-)

У меня ощущение, что ты смотришь немного не в ту сторону. Начнем с основной ошибки: MS Research занимается опенсорс-проектами и является частью опенсорс сообщества. Внезапно, так сказать. В отличае от Microsoft.

Во-вторых посмотри например Plan B, тот же House, Minix, и кучи других экспериментальных систем и языков, в том числе реалтаймовые, в том числе и для микроконтроллеров. Про Inferno и Plan 9 я таки молчу, ибо про это знают все. Ответвлением от этого всего является Google Go.

Linux, BSD, Solaris – это current production systems, и сравнивать их с Сингулярити не корректно абсолютно, сравнивать их надо с текущей продакшн-осью от MS – Windows 7.

Нужно очень четко понимать, что на production системе ставить эксперименты, отрабатывать новые технологии и идеи крайне глупо, хотя бы вследствие толщины и количества исторических наслоений, массы функциональности, которая в реальной работе абсолютно необходима, но для отработки концепции и поиске решений только мешает (мешает до степени полной невозможности что-либо исследовать). Поэтому революционных прорывов в linux/bsd мы не увидим, и опенсорс сообщество ими не ограничено.

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

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #57 : Март 11, 2011, 02:26:40 pm »
Да, про Plan 9 и Inferno, конечно, я в курсе.

В Plan 9 интересна демонстрация того, как возможно ООП на базе процессов-сообщений вместо объектов-методов. Явные аналогии - Эрланг и ETH Composita.

Но в массовом юникс-коммюнити таки наблюдается... раздолбайское презрение к "высокоуровневым штучкам", согласитесь :)
Занятно было бы провести опрос хотя бы по реакции на понятие "сборка мусора" - сколько процентов среди юникс-программистов охарактеризуют его как отрицательное и сколько - среди Windows-программистов :) Скриптовых программистов не опрашивать (ну а функциональные особо не дадут значения :) ).

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #58 : Март 13, 2011, 12:55:54 pm »
Идёт прерывание выполняемого алгоритма. В понятиях системы ББ (и некоторых других Оберон-систем) - инициированной команды. С какого перепуга нужно в описании языка разжёвывать, как именно будет происходить нештатное прерывание алгоритма в конкретной среде.
Прерывание КАКОГО алгоритма?
Допустим идем в цикле по массиву. Бац. вышли за пределы массива, я правильно понимаю что по этому определению у нас управление просто должно передаться оператору следующему за этим циклом? Или эта операция будет просто проигнорирована (как неправомерная) и цикл побежит дальше? Или передастся управление некому хендлеру внештатных ситуаций? Или комп прекратит работу? Что-то еще?

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

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

Да, а софистику не я первый начал. Кто к нам с мячом придет, тому и в воротах стоять :-)
Что должно произойти при выходе индекса за пределы массива  - можно посмотреть в исходном коде модуля обеспечения времени исполнения, Kernel (для КП): http://oberon.talk4fun.net/WeBB//System/Mod/Kernel.html ( PROCEDURE DefaultTrapViewer, см. ошибку №135 )
Разумеется, в описании языка можно обнаружить отсутствие таких элементарных вещей, как механизма оповещения пользователя об обнаруженной компилятором ошибке. Мне кажется, что не нужно смешивать техническое описание языка и техническое описание компилятора того же языка. Описание языка не должно включать в себя описание реализации самого языка. Так что, на самом деле, проблема высосана из пальца.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Тезис про Oberon, C, CP и ObjC.
« Ответ #59 : Март 13, 2011, 08:48:54 pm »
Что должно произойти при выходе индекса за пределы массива  - можно посмотреть в исходном коде модуля обеспечения времени исполнения, Kernel (для КП):

Вы там увидите только то, в чем именно заключается неописанный в языке undefuned behavior. Все описанные проблемы (vendor lock, переносимость) - остаются в силе. Да, эти проблемы могут быть неактуальными для вас (или казаться неактуальными).