OberonCore

А я вовсе не про нежирный ББ рассказываю, а про свои компоненты, сделанные на обероне и запускаемые в оберон-среде. Об этом же и речь всю дорогу.

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

Видите ли, понятие "продукт" и "конечный потребитель" очень расплывчато. Я не могу читать Ваши мысли и догадываться, что Вы имеете в виду.
Наша команда и многие здесь работают в основном над штучными продуктами, которые как бы просто "программная отливка" некоторых ценных методов для какой-то области. И при слове "потребитель" представляется тогда конкретная организация(и), которой эти методы необходимы. Об этой сфере (и, как Вы заметили, "обучения и привития..) обычно и говорится, что "... вне конкуренции".

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

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

Вы же прекрасно знаете, что он оттуда и пришёл. Обычное ядро ОС Oberon.

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

Винда с точки зрения ББ - HAL, файловая система и оконный движок.

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

Ну да. Но питоновские скрипты будут поменьше обероновских...

Ну Вы уж совсем нас за непоймикого считаете ББ устанавливается на клиентской стороне автоматическим инсталлятором, есес-но. Апдейты тоже - инсталляхой, плюс осваиваем апдейт через джаббер - при малом размере модулей ББ, это самое то

Насчёт "коробки" - это Вы погорячились, такое есть далеко не везде, не только в ББ.

Т.е. можно сделать вывод, что КП и ББ позволяют реализовать "красивый" математический алгоритм, но каких то явных приимуществ в виде скорости, размера, объема - не дают.

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

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

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

Вот взять к примеру PureBasic и сравнить его с Делфи. В Пурике код проще, в какойто степени красивее и понятнее, насчет надежности не знаю. Скомпилированные программы в 2-4 раза меньше по объему и работают быстрее. Если сравнивать среду разработки для этих языков, то Делфи имеет более дружественную среду способствующую более быстрой разработке.

Скажу со стороны Delpi. В последних проектах волей не волей нам пришлось перейти к модульному принципу. Но модуль на Delphi это либо dll либо exe. Средний размер 1.5 - 2 мб. Конечно можно компилить с пакетами, но тогда возникают проблемы с bpl, которые почему-то регулярно "отваливаются" (или забываются).
Кстати вариант с пакетами всего лишь аналогичен ББ (разумеется не по функциональности, а по объему). Далее, справку приходится делать отдельным инструментом, а в ББ все свое.

Вы задаёте массу таких вопросов, на которые в двух словах просто не ответить

Давайте постепенно.

Начнём хотя бы с "надёжности". Термин несколько расплывчатый, поэтому скажу только про свои конкретные представления.

Во-первых, за счёт простоты языка количество идиотских ошибок сведено к минимуму. Это действительно так, допустить глупость по недосмотру или от усталости, или от неопытности стало фактически невозможно. Кроме этого, простота языка и среды позволяет эффективно решать другой вопрос - кадровый. Подготовить специалиста в КП\ББ становится куда проще, чем, скажем, в Clarion.

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

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

В-четвёртых, сама среда BlackBox крайне стабильна и надёжна в работе. После перехода на BB, я уже давно позабыл времена, когда приходилось искать способы обхода подводных камней. Если возникает ошибка, то это из-за моих недоработок, а не глюки BlackBox'а. Это чисто психологически легче воспринимается, так как своё легче локализовать и исправить.

После всего вышесказанного, остаётся расставить ASSERT'ы на острых местах, продраться через компилятор и выпадающие трапы (по принципу - чем больше трапов выпадет у тебя, тем меньше их выпадет у клиента) и в результате у вас получится продукт, который работает и за который душа будет спокойна.

Всё это к узкому техническому вопросу компиляции exe не имеет отношения.
И уже в тысячный раз одно и то же.
Надо в какое-то понятное место собрать все это.

Поддерживаю.

Кстати, мне кажется, что вопросы про сборку exe-шника (и не только про exe) возникают в точке идеологического разрыва между тем, что предлагается майнстримом и тем, что предлагается в BlackBox.

И далеко не факт, что предлагаемое в BlackBox - устарело и неудобно. Достаточно почитать Раскина, посмотреть "Шаблоны проектирования" банды четырёх - и будет видно, что тут с BlackBox всё в полном порядке. Не говоря уже о полноценном технологическом применении, начиная от проектирования и заканчивая поддержкой.

А нет случайно каких нибудь онлайн курсов по ББ? Я бы с удовольствием обучился, даже денег наверное за это заплатил. Чувствую есть в КП что-то такое, но уловить пока не могу. Может для этого надо быть физико-математиком?


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

Физиком-математиком быть совершенно не надо. Просто пообщайтесь здесь с реальными программерами на ББ - Ермаковым и компанией. Они направят в нужную сторону. И еще можно пообщаться с Попковым - он ведет школу программистов. Подскажет по делу.

Модуль - это "наше все" в ББ. Это и архитектурная единица. Это очень важно, что система ТРЕБУЕТ модульного программирования. В других системах это МОЖНО сделать, а в ББ по-другому - никак!

При выполнении модуль - это эквивалент DLL. Это практически эквивалент COM-объекта. В общем, "три в одном флаконе".

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

Если говорить об исходных текстах, то модуль своими чётко видимыми границами отделяет части текста друг от друга. Более того, один модуль = один файл.
Если говорить об архитектуре, то те же самые чётко видимые границы отделяют функциональные блоки друг от друга. Если говорить о выполнении, то модуль опять же чётко обозначает элементы выполнения.

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

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

Ага!
Я именно этого и хотел видеть...

Ну тогда не вижу особой разницы с большущим монолитным exe Загоняется diff и апдейтится. Даже если это C++ (и какой-нибудь очень популярный темплейт не менялся), то diff будет вполне вменяемый.



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