| про систему оберон, язык оберон и всякую фигню |
[Mar. 11th, 2014|01:32 pm] |
я, собственно, всегда был поклонником дядьки Вирта, это не секрет. само собой, я вертел (в руках) и native oberon, и его порты, и active oberon. если не обращать внимание на то, что Вирт слишком увлекается радикальной хирургией (до основанья всё обрежем, а потом…), то это отличные системы.
active oberon — прикольная экспериментальная площадка. как ОС для современных применений, кстати, могла бы быть вполне няшной, если бы её допиливать. правда, большинство погромистов сразу сделали бы ебальник унитазом: «фу, писать на пасцале!» (а жаба их не смущает, в жабе же ФИГУРНЫЕ СКОБОЧКИ ЕСТЬ!).
oberon os же вообще хороша, перекликается с plan9 местами, но более целостная. принцип «текстового управления» рулит, и компонентная модель позволяет делать разные прикольные штуки почти без усилий. многого не хватает, конечно, но база отличная.
а под винду я когда-то очень сильно котировал BlackBox Component Builder. он очень легковесный, при этом мощный и настолько «взаимоинтегрирован», что его даже IDE назвать нельзя: это нечто сильно большее. всё тот же принцип «текст как основа» (хотя формочки делать никто не запрещает, даже наоборот, и построитель форм вполне себе; только на layout managers традиционно наплевали), при этом «текст» — это вполне полноценные составные документы. даже «живые» документы при необходимости. написан, естественно, сам на себе, в качестве языка — Component Pascal. это такой оберон, но немного продвинутей и с блёстками.
правда, когда я BBCB крутил (ох, давно это было), там был Фатальный Недостаток: внутри-то система юникодная, но преобразование из однобайтовой текущей локали в юникод делалось путём дописывания нуля к коду символа, чтобы он превратился в бвухбайтовый. причём это было закопано в том числе и в компиляторе, а исходников тогда йок. а жаль, потому что очень удобно было делать всякие, например, софты для АРМ (нет, это «автоматизированное рабочее место», а не то, что кто-то подумал): поскольку основа — rich texts, то всякие отчёты и прочая херня делались просто формированием обычных BBCB-документов. при этом можно было делать «живые» документы, которые авоматически менялись, когда менялись значения в базе. ну, и много других вкусных плюшек. но без нормального русского… select'ы радостно возвращали всё в latin-1, было смешно и бесполезно. чуть-чуть я тогда его обкостылил, конечно, но не то, не то…
потом ominc (авторы BBCB) решили сыграть в ящик и открыли исходники системы. сначала под какой-то совершенно зверской лицензией, потом, вроде бы, уже под BSDL-like. я тогда уже подзабил болт, так что ради интереса только выдернул компилятор в отдельную консольную прикладуху и забил.
ещё один недостаток BBCB — это сильная прибитость гвоздями к винде. во-первых, дегенеративное MDI. но это ладно. а во-вторых, попытки абстрагировать уй от системы были сделаны, но не особо прямо. в принципе, подсистема Host должна была быть таким слоем абстракции, но не совсем всё сложилось. вследствие чего безвайновый порт под пингвинусы так никто до сих пор и не сделал. а жаль.
если бы ящик переработать, глобально оторвать бэкэнд, убить идиотское MDI и ещё кой-чего, получилась бы отличная кроссплатформенная среда разработки. именно среда, очень гибкая и шустрая. нет, не надо мне рассказывать про всякие IDE, это не то. кто работал в BBCB (не игрался, а действительно работал), тот поймёт, насколько не то.
с правильным бэкэндом оно ещё и запускалось бы хоть на кофемолках. fbdev, opengl, x11, винда, хренда, что угодно. да, за это надо было бы заплатить «ненативным» видом контролов (или кучей мегакостылей, но ну их нафиг). да пофигу, в принципе. если сделать простую css-like «скиновалку» и хотя бы приблизительный импорт в неё настроек шиндошс/gtk/qt, то вполне съедобно.
да, демонов тоже можно было бы писать: разрабатываем в «нормальном» BBCB, а потом собираем с подсистемой-заглушкой, и получаем консольный софт без уёв.
система во все стороны динамическая, модули грузятся на лету по необходимости, и почти из любого места. поэтому, например, никаких проблем сделать «каркас», который догружает (и кэширует) необходимые модули по сетке. получаем беспроблемные централизованные апдейты (там, где они нужны, понятно).
про «систему расширений» даже говорить не стоит: это же компонентная среда, там всё — «расширения».
к чему вообще спич был? да так, захотелось помечтать о хорошей среде разработки. увы, я, во-первых, портирование в одно рыло не потяну. а во-вторых, рыло одно, потому что совместимость с оригиналом — это гири на ногах, и если уже делать, то разломать и построить заново, используя полезные куски из оригинала и расширив компилятор. а если расширять компилятор — это будет уже не component pascal. а если менять среду — то ещё и достаточно немалое количество уже существующих наработок для BBCB тоже накроется тазом. то есть, фактически, надо будет заниматься портированием и допиливанием того, чего нет (без бумажки библиотек ты какашка же).
может быть я, когда выйду на пенсию, займусь: на пенсии всё равно больше делать нечего и хуй уже не стоит. |
|
|