OberonCore

good riddance. for both sides.

Скатерть, конечно хорошо. Но все равно неправильно, как будто в природе есть другие . . . , не самописные программы (((.

мне хватило начала. всё, дальше я брезгую. «я сам на смолтолке не программировал, но где-то что-то слышал». отлично, например. ну подумаешь, кого вообще волнует, что Алан Кей считал message passing основополагающей фичей ООП? что он классифицировал объекты в основном по протоколам, а не по классам-родителям (эти классы были просто вспомогательной штукой для упрощения реализации похожих протоколов). ерунда, не стоит упоминания. как и разница между прототипной и «классовой» объектными моделями. Self? какой Self, не знаю, не слышал, не о чем тут говорить.

на этом я с отвращением видео закрыл. спасибо, рассуждения этого человека о чём-либо (и особенно об ООП) мне неинтересны. вообще.

Интересная позиция. Доклад также вызвал негативную реакцию. Но по другим причинам. У меня нет профессионального ит образования. И такие видео переодически смотрю. Повышаю квалификацию !!!

В классической интерпретации ООП - наследование, полиморфизм, инкапсуляция. Вот и вызывает недоумение призывы докладчика отказаться от наследования, сокрытие сделать абсолютным, все объекты исключительно иммутабельными. Что остается от ООП ???

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

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

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

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


про наследовние: повторюсь, это совершенно не обязательно. это вообще вспомогательный инструмент, один из способов реализации соответствия протоколов. главное — именно протоколы. параметрический полиморфизм автоматически обеспечивается именно соблюдением протоколов (а ad-hoc становится не нужен). полное сокрытие внутренней структуры объекта обеспечивается тем, что никаких средств общения с объектами кроме посылки сообщений попросту не существует. именно это сделано в Smalltalk и доведено до абсолюта в Self (который, конечно, больше эксперимент нежели язык для реального использования); а также насколько было возможно — реализовано в Objective C (про который лектор тоже умолчал, а это очень интересная штука). мутабельность объектов вообще из другой сказки, можно да, можно нет, без разницы, определяется конкретной задачей.

если вы на этом месте хотите спросить про оберон — да, оберон никакое не полноценное ООП, как и сикресткрест. оберон ограничено использует некоторые ООП концепции там, где это имеет смысл и упрощает жизнь. здравый подход, как и в остальном.

p.s.: «профессионального образования» и у меня нет. меня торжественно выперли со второго курса универа, да и учился я совсем не на программиста. это автоматически делает все мои рассуждения балабольством недоучки, потому что иметь Мнение позволено только с Официальной Бумажкой.

Вообщем, я запутался. Протоколы, параметрический полиморфизм !!! Похожее не те видео смотрел (((. Буду искать те ))). А вышку все же закончил, учится мне нравилось, и профессура даже хвалила. Правда про программирование ни слова. Одна теоретическая механика, сопромат и мат анализ до кучи. Так что в остальном полный самоучка.

ps: Почему то так и предполагал ))). А про бумажку. Вы зря. Где то наверное есть и такое. К счастью не приходилось сталкиваться. Ни разу диплом даже не показывал. Если в голове нет ничего, то там и не появится ничего. Наблюдал неоднократно !!!

я про это и говорил: для начинающих недостаточно разжёвано, для «продолжающих» бесполезно. как, впрочем, и большинство выступлений на большинстве конференций: словоблудие, да трата времени. те, кто туда выпить за казённые деньги ездят — с ними всё понятно; а зачем остальные на это финансы и время тратят — не ясно вообще.

объект определятеся не классом или иерархией: объект определяется набором сообщений, на которые он умеет реагировать определённым образом. это называется «протокол». очень грубо и неправильно протокол можно представить как набор методов базового класса, который обязаны реализовывать все наследники. а теперь убираем из картинки иерархию, и заменяем методы на сообщения.

один объект может реализовывать несколько протоколов, никаких проблем. поскольку в жёсткую типизацию это никак не засовывается, придумали хак: интерфейсы. сначала множественное наследование, потом правильно испугались и сделали интерфейсы. костыль и костыль. в Self вместо этого сделали трейты (traits).

про типы полиморфизма читайте сами, там ничего сложного. если опять очень грубо и не очень верно, то параметрический — это когда просто посылают сообщения, а диспетчер автоматически выбирает обработчик по параметрам сообщения. ad-hoc — это когда мы в коде своими ручками выбираем. ООП принесло параметрический, все в восторге прыгали и кидались чепчиками.

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

p.s.: а в целом — все эти умности вам нахрен не нужны, практической пользы в них ноль. ценится умение быстро говнокодить, чтобы TTM (time to market) было минимальным. чем адовей говнокод — тем лучше: тогда вас точно не уволят, потому что никто больше в этом не разберётся. я вот говнокодить не умею, поэтому голодаю. а не занимался бы фигнёй — галерами бы командовал.

ps: Поточное программирование, когда результат оценки прямо пропорционален количеству написаного кода. Отвратительная тенденция. Особенно для тех кто с умной головой и моральными принципами. Мне с этим повезло. Начальство требует исключительно результат, но не лезет в код и не прессует по времени ))). И ещё все таки верю, что качество обязательно перерастет в количество (денежных знаков, если что) !!!

покажите им как-нибудь нечто, что уже работает, и скажите: «окей, теперь это всё надо выкинуть и написать заново, правильно.» то есть, нормальная ситуация при нормальной разработке. скорее всего будет весело.

вы такое больше не пишите публично. это ересь против современной финансовой системы, и вообще экстремизм. мыслепреступление. к тому же так действительно не работает. вы сейчас находитесь на сайте, посвящённом дохлому коммерческому проекту, который не только был лучшим, но и до сих пор не имеет аналогов по простоте, скорости и удобству. ну что, сильно это помогло BBCB? а создатели разбрелись работать над чем угодно, только не над обероном. нужен ли ещё пример? а их есть у меня: модула-2 была разработана примерно в то же время, когда набирала популярность сишечка. где модула? где очень крутая система top speed modula-2?

я ведь не просто так говорю, что ни хорошо, ни даже нормально делать не надо: это гарантия провала. вон, мой SoN-компилятор тоже никто спонсировать не хочет: потому что пустыня, никого нет. полтора бедуина доят одного верблюда. там, где делают хорошо — деньги не водятся.

да блин, даже гершель, который уже имел рабочий прототип — и тот дал дуба.

TopSpeed MODULA-2 любовь с первого взгляда, и похоже на всю жизнь ))). По поводу, там где хорошо - там финансы не водятся. Сталкивался и с таким. Но . . . , надежда покидает последней. А гениальный BB перестал быть коммерческим проектом, как только перешел в разряд open source. И соответственно результат закономерен. Кто будет платить за то, что можно взять бесплатно.

Гершель. Интересный проект. К сожалению моих знаний не хватает, чтобы оценить его в полном объеме. Исходя из того что удалось понять. Для решения задачи был выбран путь создания полностью идентичной реплики BB, только для 64 разрядов. Крайне сложная задача. Которая по мере развития потребовала создания множества дополнительных инструментов контроля правильности реализации отдельных частей. Титанический труд, выполняемый на голом энтузиазме. Реализовать его в полном объеме в обозримые сроки, настолько малой группой . . . !!! Даже тот промежуточный результат на котором развитие приостановилось, уже настоящий подвиг ))).

В этом отношении, все шансы на полную реализацию есть в Вашем варианте. А именно признать, что главная ценность BB не в кодогенераторе, а именно в самой IDE. А кодогенератор (по терминологии авторов Гершель - синтезатор, очень непривычный термин) надо создать с нуля. Причем не просто создать, а сделать его лучшим - универсальным, расширяемым и оптимизирующим. С нетерпением жду Ваших отчетов о продвижении на этом пути. Странно, что никто кроме Вас не додумался до такого решения. Или просто, когда путь озвучен. Он кажется таким ‘простым’ и единственно возможным . . . ???

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

кстати, Juice. запилено одним студентом, по удобству и скорости обходило браузерную жабку как стоячую. об этом даже не знает никто.

так я делаю во-первых, компилятор диалекта Oberon/Ur, а во-вторых, никакие 64 бита там не планируются никогда. у меня никогда не будет чего-то отличного от x86, поэтому на всё остальное мне плевать.

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

И под отчетом понимал не нечто обязательное к исполнению. А именно Ваши замечательные информационные топики. И в открытом доступе ничего выкладывать не надо. Компилятор по своей сути не должен быть open source проектом !!!

Вот только не понятно. А как вы собираетесь делать графическую оболочку. Что то своё, или исключительно командная строка ???

так есть же LC. никаких проблем портировать с оберона на оберон. заодно, наконец, окончательно дропнуть совместимость с оригиналом. O/Ur — это развитие ультрапаскаля, который в свою очередь развитие компонентного паскаля. ну как «развитие»… вбоквел. в O/Ur и так достаточно потырено: полностью Meta, куча штук из System частично. Stores, например, прекрасно работает, портирован практически без изменений. разве что CHAR даунгрейднуть обратно до восьми бит, и мальца по этому поводу помассажировать везде (потому что unishit я видал в гробу в белых тапках).

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

Так и я том же. Редактор у Вас свой. GC портирован. Что осталось - перетащить игровой порт (который совсем и не BB, а чистый LC) и портировать динамическую загрузку, тем более что мета уже перенесена. И с 8-ми битными чарами очень поддерживаю. У себя тоже оставил только их. Вы только пирата Зану не забудьте ))).

Аж завитки берут, сколько у Вас всякой интересной работы !!! Сам сейчас страдаю простой, но нудной работай. Перегоняю одни циферки в другие. Конвертор из Oberon Risc Machin в инструкции Dalvik VM. Как же мне повезло, что первой регистровой машиной, с которой познакомился была VM Дональда Кнута. Ее и взял за основу ))).

После неё, что arm, что amd, что тем более dex android кажутся пресными и непродуманными (((. Разве что risc-v очень похожа ))). В результате одна команда orm (4 байта) превращается в 2-3 инструкции dex (8-10 байт). И где здесь компактность и экономия, о которой android нигде не забывает упомянуть ???

в динамическую загрузку O/Ur как раз умеет (там, собственно, хост-реализации файлов, дат, и некоторых других штук как раз загружаются уже после старта системы; причём компилятся на лету из исходников). а GC не портирован, весь Kernel написан с нуля. ;-) и аналог Quackerjack в O/Ur таки полностью работоспособен — на нём видеоигори рабочие есть. ;-) как раз сама среда BlackBox не портирована — потому что меня, в принципе, она устраивает в том виде, в котором есть сейчас. O/Ur больше заточен под standalone apps.

насчёт далвика — он просто эффективней классического стекового байткода жавы, что и педалировали. по крайней мере так говорят рекламные материалы, лично мне было неинтересно разбираться.

в любом случае — я бы если не сразу SSA делал, то раскрутил бы риск-код обратно в SSA, и пилил бы кодоген на другие архитектуры уже из SSA.

Так получается у Вас все практически сделано, причем в оригинальном собственном варианте. Осталось ‘сущая мелочь’ - поменять один Nanojit кодоген на оптимизирующий Sea of Nodes ))).

А если в демку дополнительно добавить продвинутую IDE (которая у Вас уже есть). То получиться мегатонная бомба, которая не оставит никаких шансов на выживание другим - не Оберон компиляторам ))).

Не знаю, как JVM. Решил вообще с ней не заморачиваться, так как в итоговый apk попадает именно dex. А насчет конкретно эффективности Dalvik. Сильно сильно сомневаюсь. Она заточена на безопасность, отсюда масса ограничений. Это нельзя, так нельзя. В результате сильно погорячился когда сказал, что одна команда orm разворачивается в 2-3 dex. В реальности, например некоторые операции чтения записи прирастают в 10 раз. Тихий ужасть (((.

А, когда доберусь до SSA, наверное буду делать по схеме: раскручивать risc в SSA, оптимизировать, затем собирать обратно в risc. Другими словами, использовать как простой трансформатор risc в risc. Просто очень удобно непосредственно из риск переводить в другие архитектуры. Может и не пару недель, как у Вас но где-то близко к этой цифре. Плюс JIT получается до безобразия простой, даже примитивный, и от того очень быстрый !!!

в данном случае проще всё выкинуть и сделать как надо. O/Ur в теперешнем виде родился из маленького эксперимента с житером же, и там внутри УЖОС УЖОС УЖОС (ещё и на крестах). всё сжечь, и сделать Как Надо. к тому же для SoN не нужен AST: SoN отлично AST заменяет. так что намного проще (и удобней) петь SoN прямо из парзера. меня так-то не напрягает всё выкинуть и переделать, если в итоге будет лучше.

SSA (в любом виде) тоже проще делать сразу — или из парзера, или из AST. если уже есть SSA — нет смысла гонять в риск и обратно. и да: лучше сразу в SoN, потому что «классический» SSA не так удобно делать без AST.

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

просто при раскрутке в «классический» SSA вам понадобится как минимум вести явный CFG, что напрягает; SoN это всё сделает за вас автоматически. жавовый C2 сразу разматывает байткод в SoN, например. но из парзера петь удобней, потому что как минимум у вас уже будут явно отмеченые циклы, и можно спокойно пропустить фазу loop detection. SoN реально ПРОЩЕ, в разы (а то и на порядок). просто надо делать ровно так, как Клифф показывает, а не пытаться умничать. я вот попытался — и зря. ;-)

самое главное, что надо помнить: peephole не должен менять семантику кода. любые code rewrite должны делаться строго отдельными фазами (например, апгрейд выражения до REAL если там REAL встретилось). и не надо умничать с type lattices: type framework должен соблюдать монотонность. иначе вам придётся изобретать хитрые правила для Meet и Dual, и вы запутаетесь, особенно если плаваете в lattice theory (как я, например). и ещё строго следить, чтобы пипхолы не сваливались во «флип-флоп»: когда один оптимизатор что-то меняет, потом второй меняет обратно, потом первый опять взад, и так пока вам не надоест ждать. простейший способ этого достичь — следовать правилу: «пипхол должен выкидывать код, а не добавлять!» иначе всё может казаться рабочим, но однажды можно попасть на Особый Случай, и застрять там очень надолго.

Алиса все сломал. Предлагаю нагрузить его чем то спиртосодержащим и отправить под палящие лучи солнца на тропический остров. Пусть страдает ))). А если серьезно. Считаю, что именно из таких исследований получаются по настоящему стоящие вещи. И если есть понимание, как сделать лучше. Надо делать. Тогда уже точно получится бесспорный шедевр !!!.

А AST это похоже всего лишь дань традиции. И при наличии SSA (SoN) просто лишнее звено (уровень), не несущее никакой смысловой нагрузки или в лучшем случае дублирующее мету из SSA ???.

А SSA-SoN понимаю, что только на словах звучит всё просто. В реале пока не будет хотя бы минимального уровня понимания (книга дракон до сих пор пугает) браться за такие задачи не буду. Да и потом с очень очень большой осторожностью. Не пытаться объять необъятное, а реализовывать маленькие маленькие кусочки постепенно. Тогда может что нибудь и получится ))).

«делайте что угодно, только не кидайте меня в терновый куст!» ;-)

«классическое» SSA без AST таки неудобно, некоторые штуки на AST проще. прикол в том, что SoN — это и есть AST! в прямом смысле: структуры данных почти идентичные. но в то же время SoN — это и SSA-представление.

и это… не надо пугаться, ну! ;-) Дракон — это Фундаментальный Труд, что-то типа: «как построить дом начиная с создания печи для кирпичей». там есть про парзинг, про регулярные выражения и ещё про кучу всяких гитик. оттуда можно узнать, например, о регулярных выражениях как DFA и NFA, создании оптимальных автоматов, их преобразовании. тема, вроде бы относящаяся к компиляции сильно боком. про типы грамматик, LR(n), LARL, LL, парзинг «снизу» и «сверху», парзинг автоматами… короче, вы будете знать МНОГО. всё это в той или иной ситуации пригодится. но совершенно не всё это сразу необходимо, чтобы сделать компилятор. вот вы Дракона не читали — а компилятор сделали, например. ;-)

книга от Inria — нормальный вводный курс по SSA. где не трогают ни парзинг, ни другие внутренние представления, ничего кроме SSA и сопутствующего (CFG, def-use, domination, live ranges, interference graphs, etc.). и её даже не обязательно читать полностью: надо только грок основную идею SSA и базовые понятия (как раз CFG, def-use, dominators). после чего можно спокойно переключаться на SoN.

я почему агитирую: когда вы въедете в SoN, вы будете ОЧЕ сожалеть о каждой минуте, потраченой на откладывание этого на завтра. ;-) с SoN писать оптимизирующие компиляторы проще и быстрее, чем неоптимизирующие без SoN. с «классическим» SSA это совсем не так, и зачастую проще сделать дубовый компилятор стипя «чо вижу то и пою». с SoN — неа. я вам так скажу: я почти уверен, что если бы Вирт знал про SoN, то книга «compiler construction» выглядела бы совсем иначе. ;-) все эти годы мы делали компиляторы не просто неправильно, но ещё и значительно сложнее, чем можно было.