Автор Тема: Future BlackBox.  (Прочитано 6960 раз)

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Future BlackBox.
« : Сентябрь 16, 2016, 07:40:11 pm »
В продолжение темы: http://oberspace.dyndns.org/index.php/topic,685.msg21597.html#msg21597

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

А какие собственно недостатки у ББ? Ну, то есть такие, чтобы критичные были. Да, у него древний и убогий компилятор с багами (да ещё и с кодом который сложно править, отлаживать и модифицировать), да доисторический сборщик мусора, и да там сильно протекает абстрагирование от хост-системы. Ну и реализация некоторых стандартных компонентов оставляет желать лучшего, а поддержка редактирования исходников довольно убога.

Но так ли всё это важно?

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

Остальное же возможно править инкрементально, без революций.
Y = λf.(λx.f (x x)) (λx.f (x x))

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #1 : Сентябрь 16, 2016, 08:16:48 pm »
Вообще, чтобы понять что нужно править в ББ в первую очередь (в том числе для того, чтобы его юзвериная база расширялась) нужно понять чем он таки цепляет людей.

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

Однако, я полагаю, его выбирают прежде всего за workflow в нем, за специфичный и довольно необычный для наших дней, цикл разработки программы. На это ведутся и подсаживаются также, как иные подсаживаются на REPL-цикл разработки в python/haskell/js/etc. То есть если задачи человека подходят под подобный цикл разработки и если ему это банально понравится (не могу сказать от каких факторов это зависит - понравится ему или нет, может от склада характера, от образа мышления, от предыдущего опыта - хз).

Собственно именно это и есть основное преимущество ББ перед всем остальным. В этой нише у него конечно есть конкуренты, и их можно разобрать отдельно (классический оберон, АО, естественно родоначальник подобного цикла разработки - Smalltalk, в какой-то степени lisp, в какой-то степени erlang). Перед ними у ББ есть два основных преимущества - он значительно более нативный, обычный (смотрится как обычная, хотя уже и дюже устаревшая виндовозная программа, с привичными сочетаниями кнопочек, менюшками, шрифтами и проч), и он всё же побыстрее и полегче за счет компилируемости в нативный бинарь (хотя лисп тут может с ним поспорить конечно).

Соответственно для продвижения ББ в массы (естественно без надежды победить поганый мейнстрим, а просто чтобы активных пользователей стало в на один-два порядка больше), нужно продвигать не ББ как таковой, а этот специфический цикл разработки ПО. Любыми способами - статьями про Smalltalk, про Cedar, про MESA, про лисп, про что угодно. Чтобы люди попробовали, и кто-то на это дело клюнул-втянулся-запал. Хотя бы на уровне хобби. А чтобы человек выбрал в итоге именно ББ (с бОльшей вероятностью), нужно в первую очередь чинить в ББ то, что мешает его сразу начать использовать такому человеку.

То есть засунуть его в репозиторий линуксов (убунты хотя бы), причем нативный, а не через wine. (соответственно нативный нужно починить до юзабельного состояния). Сделать так, чтобы не нужно было ставить 32битные либы, то есть нужен компилятор который генерит 64бита. Ну или сделать прослойку транслирующую из 64битной системы в 32битное ББшное царство. Такой костыль, насколько я понимаю, вполне возможен.

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

При этом скорость исполнения бинарей в принципе не важна, эффективность GC тоже не особо важна и так далее. Кстати, размер дистра тоже не особо важен.

Ах, да. И поменьше пафоса в документации и статей, и побольше дела. Пафос отталкивает.

PS. Да, в этой нише простота языка еще важна. Среди классически (без вывода типов и проч) строго статически типизированных ЯП у КП и Оберона мало соперников в плане простоты (наверно только Go тут где-то как-то рядом). При этом в данной нише очень важно, чтобы язык был описан полностью, поэтому какой-нибудь АО не годится. С языком тут по большей части ничего делать не надо. Разве что капс убрать и адаптировать под 64бита. :-)
Y = λf.(λx.f (x x)) (λx.f (x x))

kkkk

  • Full Member
  • ***
  • Сообщений: 135
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #2 : Сентябрь 16, 2016, 09:19:07 pm »
...
Но так ли всё это важно?
...
Остальное же возможно править инкрементально, без революций.
1. Да, важно. Не для всех, конечно, но важно.
2. В том-то и дело, что написан он так, что инкрементально получается плохо. Иногда чтобы улучшить программу, её надо переписать, используя опыт, но не код.

Со многим, что Вы написали, согласен

Ivan Denisov

  • Jr. Member
  • **
  • Сообщений: 67
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #3 : Сентябрь 20, 2016, 07:12:12 pm »
Алексей наметил важное направление мысли. Вот что меня подкупило когда-то в ББ, это удобный доступ к простой быстрой графике в сочетании с достаточно быстрым исоплнением кода. Вот и всё. После уёбищных языков встроенных в Matlab, Flash и 3D Max и т.п. и невозможности Visual Studio c пол тычка заставить показывать картинки, BlackBox - очень крут.
А потом приходит вторая волна. Дело в том, что большая часть софта для науки - глючная (ученые не программисты), либо существует только для Linux, либо еще какая-то неудача. Поэтому Блэкбокс стал большим шагом вперед.
1. Моя программка в любой стадии разработки готова к дистрибуции (запаковал в архив, дал коллеге, если надо, то прямо у него на компе допилил)
2. Работаю в Linux через Wine, но уверен, что на Windows у людей будет работать также.
3. Компонентный Паскаль на все случаи жизни ( у Дугласа 8000 модулей в рабочей папке), народ рассматривает ББ как мини-ОС и в ней далает множество задач.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #4 : Сентябрь 20, 2016, 07:32:15 pm »
Алексей наметил важное направление мысли. Вот что меня подкупило когда-то в ББ, это удобный доступ к простой быстрой графике в сочетании с достаточно быстрым исоплнением кода. Вот и всё. После уёбищных языков встроенных в Matlab, Flash и 3D Max и т.п. и невозможности Visual Studio c пол тычка заставить показывать картинки, BlackBox - очень крут.
А потом приходит вторая волна. Дело в том, что большая часть софта для науки - глючная (ученые не программисты), либо существует только для Linux, либо еще какая-то неудача. Поэтому Блэкбокс стал большим шагом вперед.
1. Моя программка в любой стадии разработки готова к дистрибуции (запаковал в архив, дал коллеге, если надо, то прямо у него на компе допилил)
2. Работаю в Linux через Wine, но уверен, что на Windows у людей будет работать также.
3. Компонентный Паскаль на все случаи жизни ( у Дугласа 8000 модулей в рабочей папке), народ рассматривает ББ как мини-ОС и в ней далает множество задач.

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

Но я понимаю о чем ты. В подобной экспериментально-научной деятельности очень приятно когда у тебя свой мирок, в котором ты настроил всё как хочешь, и там работаешь спокойно, не вылезая оттуда. И тут тебе и графика, и среда разработки и так далее. Но мне таки в ББ сильно не хватает REPL, коим я пользуюсь и в ROOT и в матлабе. Ну и человеческой нотации для матриц не хватает. И готовых библиотек для обработки данных (на чем матлаб и выезжает, кстати, тут даже ROOT слабее, а вот питончик с numpy/scikit уже вполне на уровне).

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

Поэтому остается тащемто только одно - альтернативный цикл разработки/отладки/построение ПО. REPL++ :-)
Y = λf.(λx.f (x x)) (λx.f (x x))

Ivan Denisov

  • Jr. Member
  • **
  • Сообщений: 67
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #5 : Сентябрь 21, 2016, 03:14:12 am »
ну, вот ROOT очень хорош для всего подобного, ну и scikit тоже неплох весьма. Тут тебе и графики и визуализация всего и вся. Не даром ученые питоном упарываются в последние года
Про ROOT почитал сейчас, я бы не когда в здравом уме такое не выбрал для работы. Это ж специфический мутант из CERN, какой-то скриптовый язык. Ну уж нет. К тому-же лицензия GPL, значит придется открывать коды. Так дело не пойдет.

Про поголовное увлечение Питоном, среди моих коллег это только альтернатива Perl в силу хорошей поддержки регулярных выражений и хэштаблиц. Ну и всякие недоучки еще его любят, те кто не осилил ничего серьезного недоучился на первых курсах все время рассуждают про Питон, но при этом ничего не делают.
« Последнее редактирование: Сентябрь 21, 2016, 03:16:27 am от Ivan Denisov »

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #6 : Сентябрь 21, 2016, 01:16:10 pm »
ну, вот ROOT очень хорош для всего подобного, ну и scikit тоже неплох весьма. Тут тебе и графики и визуализация всего и вся. Не даром ученые питоном упарываются в последние года
Про ROOT почитал сейчас, я бы не когда в здравом уме такое не выбрал для работы. Это ж специфический мутант из CERN, какой-то скриптовый язык. Ну уж нет.

Ну, давай по порядку.

Начнем с определений:
  • Scripting - (скриптование, скриптовое применение ЯП) - автоматизация рутины в некой среде, часто скрипты пишутся в стиле writeonly, читабельность не особо важна. Также, поскольку скрипты сами по себе не содержат реализацию каких-то сложных алгоритмов, а наборот просто связывают и вызывают различные функции данной среды, то нет жестких требований к производительности самого скрипта
  • Command language - такой ЯП который предназначен в первую очередь для исполнения в command line interface. Вообще говоря, таковой язык не обязан даже быть полным по тьюрингу. Требования к производительности реализации ещё ниже чем в случае скриптинга, зато выше требования к компактности записи - часто хочется уложиться в одну строчку.
  • REPL - Read–eval–print loop, специфический workflow для разработки ПО. Поскольку используется для разработки ПО, то REPL применяется к general purpose languages а не к command languages, однако оказывается, что если данный ЯП неплохо годится для REPL стиля разработки, то этот ЯП может быть использован как command language для какой-либо среды. Обычно он хуже чем специализированный command language для данной среды, но зато достигается универсанализация на всех уровнях - от cli до написания компонент для данной среды.

А теперь вот перечень того, чего не бывает:
  • Скриптовый язык - написание скриптов это применение, а не свойство языка как такового. Правда обычно для скриптового применения данного ЯП в данной среде желательно иметь возможность засунуть исполнения скрипта в песочницу, чтобы криво написанный скрипт не нарушил работоспособность всей среды, но при этом обеспечить максимально прозрачное взаимодействие скрипта со средой. В песочницу засовывается абсолютно любой язык, хоть С++ хоть асм, хоть пролог, другое дело что для некоторых языков имеющиеся реализации уже сразу пригодны для организации песочницы.
  • Интерпретируемый язык - это нюансы конкретной реализации, а не свойство языка
  • Компилируемый язык - это опять нюансы конкретной реализации, а не свойство языка

Ну, а теперь разберемся: в ROOT используется обычный С++ (современный естественно, а не стандарта 98 или 2003 годов).

В качестве REPL для C++ там выступает cling, который базируется на clang и всё что ты там вводишь компилируется в нативный код на лету (так называемая jit-компиляция).

Итоговая производительность того, что крутится в REPL (и не было оформлено в виде либы) четко на уровне clang c опцией компиляции -O0 (но обещают допилить и высокие уровни оптимизации).

А чтобы в REPL веселее жилось, в cling добавили пару специфичных именно для REPL мелких расширений.

Это язык никак не меняет, и по сравнению с тем, что в Microsoft Visual Studio сделали с С++, это вообще фигня (причем фигня, которая используется и работает только в сеансе REPL).

Итого, в ROOT для написания модулей системы используется С++, для скриптинга используется C++ (без организации песочницы, скрипт может обрушить среду), разработка идет в стиле REPL, и в качестве command language опять используется C++. На всех этапах всё компилируется в машкод.

Таким образом, никаких мутантов, обычный чистый С++. А с учетом того, что современные С++ компиляторы легко умеют генерировать проверку выхода за границы массивов... :-)

Для сравнения в ББ проникновение КП не столь всеобъемлюще: в качестве языка для компонент используется КП, для скриптинга используется КП (без организации песочницы - скрипт может обрушить среду), а вот в качестве command language используется уже отдельный язык с реализацией в виде интерпретатора.

К тому-же лицензия GPL, значит придется открывать коды. Так дело не пойдет.
Насколько я помню, когда (долгое время) ББ был GPL only, это никому из русского сообщества не мешало :-)

Ну а на самом деле же, во-первых там только часть либ под GPL, остальное под LGPL (что, соответственно не принуждает что-либо раскрывать когда-либо). Во-вторых открывать исходники ты обязан только если ты кому-то отдаешь бинарь, и он попросил тебя ещё и исходники показать ему. Открывать исходники всему свету ты не обязан. И не обязан их показывать кому-то если ты просто используешь GPL-код и бинари не распространяешь.

Кроме того, в ROOT тебе же доступены абсолютно все либы на C и С++. Под всеми лицензиями (а всяких либ для окучивания экспериментальных данных на с++ написано мноого). Не нужно абсолютно никаких усилий, чтобы из cling их интерактивно дёргать. То же и с построениями графика и вообще работы с графикой. Я помнится из этого REPL с SDL работал. Написал строчку, ткнул Enter - появилось окошко. Еще написал и ткнул - в окошке что-то нарисовалось.

Про поголовное увлечение Питоном, среди моих коллег это только альтернатива Perl в силу хорошей поддержки регулярных выражений и хэштаблиц. Ну и всякие недоучки еще его любят, те кто не осилил ничего серьезного недоучился на первых курсах все время рассуждают про Питон, но при этом ничего не делают.
Я не знаю что там не так с твоими коллегами, но парни которые пишут scikit, scipy, numpy и так далее, явно знают как теорию, так и практику, и активно работают. Кроме того, мой знакомый по работе много и плодотворно занимался машинным обучением и подобными вещами, как в научной, так и в прикладной области - основной инструмент это таки питон с соответствующими либами и тулзами. В том же яндексе именно питон в основном используется для анализа данных.

Хотя, возможно, они все конечно недоучки :-)
« Последнее редактирование: Сентябрь 21, 2016, 01:18:08 pm от valexey_u »
Y = λf.(λx.f (x x)) (λx.f (x x))

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #7 : Сентябрь 21, 2016, 01:25:00 pm »
Но это всё не умаляет основного достоинства ББ - его цикла разработки. Тем у кого задачи на такой цикл хорошо ложатся, или кому просто это по нраву, альтернативу найти будет сложно.

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

И это не работает с циклом разработки ББшным, тут, чтобы подчистить хвосты после неудачного запуска какой-нибудь функции, придется перезапускать IDE целиком.
Y = λf.(λx.f (x x)) (λx.f (x x))

Ivan Denisov

  • Jr. Member
  • **
  • Сообщений: 67
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #8 : Сентябрь 21, 2016, 01:47:02 pm »
Кошмар на улице вязов — вводить С++ в качестве команд в терминале. Совершенно бестолковая трата времени. Какие эксперименты. Должно быть в голове придумано и потом пишешь процедуры. Если получается сверху вниз — прекрасно. Иногда не сразу получается так. Но REPL, вот только честно, ЗАЧЕМ ?

Ivan Denisov

  • Jr. Member
  • **
  • Сообщений: 67
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #9 : Сентябрь 21, 2016, 06:34:29 pm »
И это не работает с циклом разработки ББшным, тут, чтобы подчистить хвосты после неудачного запуска какой-нибудь функции, придется перезапускать IDE целиком.
Тут сразу видно, что ты Алексей не работал в ББ достаточно. ББ не надо перезапускать при разработке. Хвосты соберет сборщик мусора при выгрузке модуля из памяти. Даже переход от разработки к продакшану в ББ возможно совершить БЕЗ перезагрузки среды.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #10 : Сентябрь 21, 2016, 06:57:33 pm »
И это не работает с циклом разработки ББшным, тут, чтобы подчистить хвосты после неудачного запуска какой-нибудь функции, придется перезапускать IDE целиком.
Тут сразу видно, что ты Алексей не работал в ББ достаточно. ББ не надо перезапускать при разработке. Хвосты соберет сборщик мусора при выгрузке модуля из памяти. Даже переход от разработки к продакшану в ББ возможно совершить БЕЗ перезагрузки среды.
Алексей работать с ББ достаточно. Алексей говорить не про сраный кусок памяти, Алексей говорить про ресурс который не память! Сокеты, файловые дескрипторы etc. Всё это ББшный (как и любой другой) GC не собирать и не освобождать!
Y = λf.(λx.f (x x)) (λx.f (x x))

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #11 : Сентябрь 21, 2016, 07:04:52 pm »
А если серьезно, то даже не во внешних ресурсах дело. В ББшных модулях присутствуют глобальные переменные, или не глобальные, а просто синглетоны которые где-то там висят в куче. И есть например такая штука, как состояние самой кучи и GC как такового. Так вот, при тестах и при разработке бывает очень важно чтобы каждый раз, каждый прогон начинался с одного и того же состояния всей программы целиков. Вплоть до состояния генератора псевдослучайных чисел, фрагментации и состояния кучи и так далее. И тем более все глобальные переменные должны иметь каждый раз одни и те же значения в начале прогона.

С циклом разработки которые родной для ББ так не получится. Только перезапуск IDE каждый раз. Либо удаленный отладчик/интроспектор и вторая запускаемая копия ББ. Иначе никак.
Y = λf.(λx.f (x x)) (λx.f (x x))

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #12 : Сентябрь 21, 2016, 07:41:55 pm »
Кошмар на улице вязов — вводить С++ в качестве команд в терминале.
Эмм.. А какие проблемы? Оно простое и лаконичное. Вот Оберон тут не прокатил бы - он больше заточен на многострочечность, настолько, что даже в ББ и Оберон-системе пришлось дополнительный язык делать, в качестве command language.

В определенный момент я заменил матлаб на ROOT/cling - было вполне удобно.

Совершенно бестолковая трата времени. Какие эксперименты. Должно быть в голове придумано и потом пишешь процедуры. Если получается сверху вниз — прекрасно. Иногда не сразу получается так. Но REPL, вот только честно, ЗАЧЕМ ?
Какие процедуры? Процедуры не являются самоцелью же.

Вот прилетело мне в очередной раз несколько сот мегабайт собранных данных с "полей". Мне нужно разобраться что там было и как, понять закономерности, попытаться как-то наглядно это всё визуализировать. Ну и какие процедуры мне писать, а, главное, зачем? Я ещё понятия не имею что в тех данных, как их анализировать, какие features выделять и использовать. Поэтому берем REPL и давай эти данные крутить так и сяк, и графики построить и статистику навести и визуализировать, и посмотреть есть ли корреляция между вот этими параметрами, а потом визуализировать, и понять что фигня это, а не корреляция. И все эти попытки аккуратно, автоматически, записываются в журнал.

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

И вот когда уже всё подтвердилось (чаще всего с 10-20 итерации), вот тогда уже оформляется это всё в код который будет просто и удобно сопровождать, будет быстро исполняться и так далее и тому подобное.

Что-то из головы тут придумывать довольно бессмысленно, придумывание в отрыве от данных (а их, напомню, сотни мегабайт) не сработает, а REPL как раз служит способом разгребания этих сотен мегабайт и придумыванию того самого, из головы.

Это если мы про REPL применительно к обработке данных.

Естественно в нормальном программировании REPL служит несколько другому - через REPL намного проще и быстрее пощупать и исследовать например неизвестную тебе библиотеку.

Но ещё раз - я не ярык сторонник REPL. Для каждой задачи - своё. Иногда такие задачи, что несколько дней кряду просто таки да, придумал из головы, написал на бумажке схему и пишешь код. Пишешь, пишешь, пишешь. И только через три дня первый раз пытаешься скомпилировать. Для такой задачи и такого подхода абсолютно бессмысленны и REPL и ББшный цикл разработки.

А иногда у тебя цикл нужен настолько короткий и быстрый, что вот REPL как раз подойдет. В ББ же нечто среднее - там цикл не такой быстрый как REPL, но и не такой длинный как в традиционной разработке. Ну и цикл обероноББшный подразумевает трансформацию и наращивание стокового ББ до того, что тебе нужно. С отрезанием ненужного, конечно. Эдакое эволюционное программирование. Есть в этом некий дзен конечно. Эдакий бонсайчик растишь.

Но не всем бонсай нужен. Инногда нужно поле засеять, а иногда здоровенное дерево вырастить.
Y = λf.(λx.f (x x)) (λx.f (x x))

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Future BlackBox.
« Ответ #13 : Сентябрь 21, 2016, 08:00:14 pm »
Да, и это я не к тому, что ББ говно, или как-то он особенно плох.

Я к тому, что задачи бывают разные и решаются они по разному. Для некоторых задач подход аля Smalltalk or Oberon system/BB имеет очевидные минусы, вроде тех, о которых я упомянул выше и о которых обязательно скажут те, кто подобные задачи решает.

И это скажут не потому, что они мейнстримщики/недоучки/виртомнерукопожатые, а потому, что это реально так. И не надо на это обижаться, и не надо называть недоучками тех, кто про такое скажет.

На самом деле, информирование общественности о цикле разработки аля smalltalk/cedar/oberon/etc, таки реально увеличит число тех, кто им будет пользоваться, просто потому, что, вероятно, у части народа такие задачи, которые лучше всего ложились бы именно на такой цикл разработки, но они просто не знают что он существуют. Поэтому пользуются либо repl-циклом, либо классикой.

Хотя, цикл разработки фронтенда на js сейчас уже напоминает нечто среднее между repl-циклом и ББшным. После изменения исходника модуля на js у тебя сразу меняется и состояние системы/приложения в браузере. Другое дело, что частенько IDE там всё еще отдельно от приложения. Хотя, разработка плагинов для какого-нибудь atom'a уже вот именно оно и есть.
Y = λf.(λx.f (x x)) (λx.f (x x))