Итак, я проделал ряд экспериментов. Для этого модифицировал код следующим образом:
MODULE Test;
IMPORT Files, Texts, Oberon;
PROCEDURE P*;
VAR
W : Texts.Writer;
file : Files.File;
r : Files.Rider;
t : INTEGER;
b : BYTE;
s012345678901234567890123456789, u0123456789012345678900123456789 : INTEGER; (* 2 *)
BEGIN
Texts.OpenWriter(W);
file := Files.Old("Test.rsc");
Files.Set(r, file, 0);
Texts.WriteInt(W, Files.Length(file), 6);
Texts.WriteInt(W, 0, 6); (* число 0 будем менять, чтобы убедиться, что у нас запущена новая версия модуля *)
t := 0;
WHILE ~r.oef DO
Files.ReadByte(r, b);
t := t + b;
END;
Texts.WriteInt(W, t, 6);
Texts.Append(OBeron.Log, W.buf);
Files.Close(file);
END P;
END Test.
Программа подсчитывает сумму байт в объектнике (простейшая чексумма), а также смотрит какой объем файла объектника. В лог выдает: file_size flag sum, где flag это число для контроля того, что у нас модуль нужной версии загружен (это сделано, чтобы избежать человеческого фактора при тестировании).
Пример вывода: 432 0 32948.
Что будем менять: будем менять длину имени переменной t (2 варианта: t и t01234), будем менять длину переменных s012345678901234567890123456789 и u012345678901234567890123456789 (короткие варианты соответственно s и u), также посмотрим что будет, если этих двух переменных не будет вовсе.
При тестировании каждый вариант теста будем запускать 2 раза — с flag=0 и flag=1. Чтобы убедиться, что мы нигде не налажали.
Итого, можно уверенно сделать следующие выводы, что:
Содержимое объектного файла никак не зависит от именования локальных переменных процедур
Как и ожидалось, в зависимости от литерала flag'а (0 или 1) у нас сумма может увеличиваться на 1
Компилятор Оберона (писанный Виртом для Project Oberon 2013) не выбрасывает неиспользуемые локальные переменные
Также можно осторожно предположить, что объем объектника не зависит от числа локальных переменных (если они не инициализируются (в том числе неявно, компилятором) и не используются).
Желающие могут попробовать воспроизвести мои результаты. У вас все для этого есть. Ну, заодно и оцените каково программировать код в Project Oberon 2013 ;-)
PS. И я посмотрел — в Project Oberon 2013 действительно удалена глава 12.9 посвященная посмертной отладке и инспекции стека и кучи. Таким образом Вирт посчитал возможность в случае падения приложения её хоть как-то отладить, лишней. Оберон стал еще проще :-)
Размер бинаря — 320 байт, соответственно все выровнить по 256 не выйдет. Да и формат хорошо описан (в книжке, которуя я например читал) и там нет выравнивания по 256.
Нет, Виртовский компилятор не выкидывает, насколько я знаю, неиспользуемые переменные.
Сравнить объектные файлы несколько сложнее конечно — писать придется несколько больше (а чтобы это на персоналке проверить, нужно файлы на персоналку еще как-то передать). Но я попробую для чистоты эксперимента :-)
Ну или какой эксперимент произвести, чтобы убедиться в правдивости твоих слов.
Результаты моих личных исследований и экспериментов говорят об обратном — размер объектного файла (*.rsc) никак от именований локальных переменных не зависит.
Вот тестовый модуль:
MODULE Test;
IMPORT Files, Texts, Oberon;
PROCEDURE P*;
VAR
W : Texts.Writer;
file : Files.File;
t : INTEGER; (* длину названия именно этой переменной будем варьировать *)
BEGIN
Texts.OpenWriter(W);
file := Files.Old("Test.rsc");
Texts.WriteInt(W, Files.Length(file), 6);
Texts.WriteInt(W, 123, 6); (* число 123 будем менять, чтобы убедиться, что у нас запущена новая версия модуля *)
Texts.Append(Oberon.Log, W.buf);
END P;
END Test.
Размер объектника получается у данного модуля всегда 320 байт. вне зависимости от того, сколько букв t в названии переменной, то есть зовется она t, или же ttttttttttttttttttttt.
Таким образом получается, что названия локальных переменных в Обероне все же бесплатны.
Или я что-то делаю не так?
Кроме того, в Обероне также нет возможности (по крайней мере я такой возможности не обнаружил) посмотреть при трапе стек или кучу. Если укажешь на таковую возможность, буду весьмя благодарен.
При трапе лишь указывается место в исходнике где трап произошел.
PS. Да, на слово я не верю, все и всегда стараюсь проверять экспериментально. Особенно если я могу это сделать. В случае с обероном я могу. Сори :-)
Я не являюсь фанатиком Оберона (например вот тут мы с Kemet'ом долго и нудно спорим на тему чуда портирования ОС Оберон за два выходных: habrahabr.ru/post/258993/#comment_8440659 ), но поскольку я немного в теме (лет 8-9 наверно уже как), то таки имею кое-что сказать про «старый ZX Spectrum». :-)
Итак, Вирт в Project Oberon 2013 слепил не просто операционку, или там язык, а еще и компьютер на FPGA целиком. Слеплено это дело на Spartan-3 (стоило это дело порядка 100 баксов) с использованием в качестве ОЗУ тамошней SRAM. SRAM'a там 1 мегабайт (из которых часть используется под видеопамять). В изначальной рабочей станции (Ceres) же когда Вирт делал первоначальную версию Оберона в 1989 году по естественным причинам также было что-то около 1-2 Мб ОЗУ.
В этом компьютере (на FPGA, 2013 год), в процессоре, нет MMU, а также нет и прерываний. Таким образом классическая пошаговая отладка там, мягко говоря, затруднительна (напомню, что поскольку этот процессор модель для изучения, он должен быть максимально простым и вполне обозримым в плане размеров), впрочем как и, например, вытесняющаяя многозадачность.
Поэтому даже в 2015 году отобрать у Вирта его «старый ZX Spectrum» не представляется возможным — он сам его сделал и вот как раз совсем недавно :-)
Единственное что возможно — это перенести его на какую-то новую платку с FPGA (благо повод имеется — Spartan-3 выведен из продажи), где будет больше ОЗУ. Но тут нюанс — на SDRAM (которой бывает МНОГО — десятки мегабайт! иногда сотни!) перейти будет проблематично в данном проекте: с одной стороны самому писать на верилоге модуль для работы с SDRAM (его обновления и так далее) — это существенно увеличить объемы исходников компа и их сложность, кроме того после этого остро встанет проблема процессора — у процессора Вирта нет конвеера, поэтому он будет бОльшую часть времени просто простаивать. С другой стороны, использовать готовый модуль (которые тем же Xilinx'ом предоставляются) для работы с SDRAM тоже нельзя — это противоречит духу проекта :-) Абсолютно все части компа должны быть как на ладони и понятно как работают.
А дешевых плат с большими объемами SRAM я лично не встречал :-( Собственно даже на альтеру DE2-115 просто так не перетащить: там просто так не сделать 32битную адресацию для SRAM (без потери производительности).
Если есть предложения как можно было бы наименее болезненным способом нарастить память у Оберон-компа — велком! Может совместными усилиями и придумаем что. ;-)
А мы ведь еще про потребление энергии даже говорить не начали :-) Сколько эта штука за 173 бакса сможет прожить од пальчиковой батарейки? А от cr3032? А от CR44?
Ну, наврятли это все же делались за пару выходных за все эти полгода. Полагаю это все же как минимум 2-3 недели фултайма. Кроме того, Вирт в таком вот режиме, когда основную часть времени уходит на учебный процесс и т.п., написал первую ревизию Проекта Оберон за 2 года. Таким образом выходит, что ваш коллега вполне мог бы осилить проект оберон (из рассчета что два его выходных это примерно полгода работы профессора из Цюриха в свободное от основных занятий время) за 8 выходных.
Ну, либо твои коллеги на порядок профессиональней учеников и коллег Вирта, а также самого Вирта, и лучше разбираются как в чужом железе, так и в Обероне :-)
Ты не написал как именно порт Project Oberon 2013 осуществлялся, сказал лишь что за 2 выходных. Исходня из того, что у вас уже Native Oberon под VAX-11 уже был, я предположил что эти наработки как раз и использовались. Просто глупо не использовать эти наработки и этот опыт делая порт Project Oberon 2013 под VAX-11.
Ну вот оттуда видимо и перенесли те части в PO которые за VAX-11 отвечали. Без этого допил бекенда под VAX-11 и перенос системы занял бы как обычно — полгода. Как Вирт и писал.
А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.
А кстати, ты ведь опять тут вводишь хабрасообщество в заблуждение. За два выходных получилось его портировать (Project Oberon 2013) в основном не потому что он такой маленький простой и хорошо описанный, а потому, что у вас уже был порт на вашу железяку (VAX-11) прежнего Project Oberon, а новый Project Oberon от старого не слишком отличается. Соответственно требовалась лишь адаптация порта под новую версию Project Oberon.
Насколько я помню, Вирт писал, что портирование Project Oberon на новую платформу занимало примерно по полгода работы. Но никак не два выходных.
А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.
Любоптыно. А железка у вас с экраном/gui? А в важей железке тоже прерываний нет, или вы ими просто не пользуетесь? А если пользуетесь, то как реализовали их поддежрку в Project Oberon, ведь там их поддержки нет вовсе, да и язык тоже их не умеет.
Понятно, что при использовании ЯП многие вещи субъективны. Ну, например кто-то будет в Обероне страдать от модульности (её наличия) и от статической типизации :-)
Ну а кто-то например, чисто субъетивно и по причинам вообще не связанным с языком, будет утверждать что С++ это боль и страдания :-)
Ну, во-первых это полуправда. Хотя бы потому, что операционная система Оберон от 2013 года не написани ни на Обероне ревизии 2007 года ни на Обероне ревизии 2013 или 2015 года. Там свой диалект (и именно поэтому мне пришлось компилятор Виртовский таки портировать).
А во-вторых если говорить о том Обероне что в Project Oberon 2013, то цели создания его ничем в общем то не отличаются от целей создания Оберона (и системы и языка) что вышел в 1989 году. Конкретный язык оптимизированный под данный конкретный проект, под конкретное железо и нужды. Цели идентичные — изначально Оберон был также писан потому и для того, чтобы было по чему преподавать и на чем тренеровать студентов. Но была и разница — тогда рабочии станции Ceres с Обероном на борту, насколько я понимаю, использовались еще и для почты внутри университета например.
Попытка же из Оберона сделать ЯП общего назначения (то есть не под конкретный проект) неизбежно его раздувает. В оригинальном ЯП Оберон описание 16 страниц, в Оберон-2 (а это уже первые шаги к народному ЯП) уже 26 + 50 страниц из Oakwood Guidelines (там уже и стандартная библиотека какая-то появляется + уточнения семантики и синтаксиса языка). Насколько я понимаю, Компонентный Паскаль и Активный Оберон (со всеми расширениями) еще сложнее и больше.
Но мы с тобой конечно смотрим на Оберон под разными углами — ты с точки зрения практического применения, ибо ты его активно применяешь в работе, поэтому у тебя Active Oberon, а я с точки зрения исследователя и копателя концепций, поэтому меня больше занимают именно виртовские Обероны — изначальный и вот свежий.
В плане оптимизации проекта по размеру и обозримости (и ЯП и ОС) Вирт безусловно добился отличных успехов. Тут если ему и есть равные, то я их не знаю.
В плане применимости на практике (то есть не для DIY, а именно промышленно, когда нужен прежде всего результат, а не процесс), видимо следует смотреть на то, что там делали уже ученики Вирта — Active Oberon, КП и проч.
Вот и получается, что никакого страдания нет, а если оно у тебя есть, то связано не только см Обероном, но и другими языками. Ведь не назовёшь же серьёзной проблемой ЯЗЫКА непонимание где что находится в ПРОЕКТЕ?
Я как раз назову это (а точнее то, сколько усилий требуется чтобы разобраться что где в проекте находится и что с чем как связано, и как это все использовать) проблемой языка, причем весьма серьзеной. В модуле этой проблемы почти нет. В С++ (если оно не в стиле stl писано) тоже проблемы в общем то нет. В Аде — нет. А вот в Обероне, Го, Яве и C++ в стиле boost/stl — есть.
На любом языке, открыв чужой проект в каком нибудь нотепаде ( ты же обероновские модули в неком подобии нотепада сиотришь, когда для С++ используешь наdороченную и настроенную IDE?) нужно потратить время на то чтобы разобраться что где лежит, настроить ту самую супер IDE и вперёд.
Ошибаешься. В основном когда я разбираюсь в чужом проекте (не важно на каком он языке) я использую либо просто веб-просмотрщик github'a (или что-то аналогичное), либо что-то типа FAR'а (если в винде) либо grep + cat | less в юниксах. Вне зависимости от языка.
Если бы я говорил с учетом IDE, то java могла бы (но это вовсе не обязательно) переместиться на самый верх списка (у java прекрасные IDE), но она там, где она есть — рядышком с Обероном. Просто потому, что я не люблю зависить от того, за каким компьютером я сейчас сижу и какое окружение у меня сейчас настроено. Частенько я код читаю, и в нем разбираюсь вообще с планшета, где IDE нет вовсе никакой.
Тем более что если я умею разбираться в коде без IDE, то в IDE я тем более смогу сориентироваться, а вот если я привыкну использовать IDE, то без нее (или в другой IDE) может быть уже больно.
Ну и вообще, у меня обычно получается найти то что нужно в чужом проекте (без IDE) часто быстрее чем у людей знакомых с этим прокетом и с IDE ;-)
Кстати, портирование Оберон-компилятора (виртовского) с переписыванием кусков Оберон-системы под другую платформу, это вот программированием и написанием кода на Обероне не считается, правда? ;-) Ведь компилятор — это очень маленькая и простая штучка, в которой разобраться легко, а кусочки операционки — это вообще фигня.
Так что да, действительно, не пишу и не писал на Обероне :-) Совсем. Никогда.
PS. Но таки да, по работе я оберон действительно не использую. Это хобби и отличная моделька для изучения.
Не-е, меня лично ломает писать на Matlab'e и js (больше всего кода я сейчас пишу как раз на матлабе). А вот ПИСАТЬ код на Обероне — от этого ломки нет (и Оберон я таки лучше знаю и легче на нем пишу, чем на Go, на котором я по работе пишу). А вот разбираться в Обероно-проектах, да, хуже чем в С++ или Аде и, тем более, на Модуле-3 (хотя на Аде я писал совсем-совсем мало, а на Модуле-3 не писал вовсе, но разбираться в исходниках на этих языках почему то проще. парадокс? ;-) )
А что именно осложняет разбираться в проектах на Обероне (а также Go, Java) я описал выше и довольно подробно. Не вижу смысла повторяться.
PS. И да, мне Модула-3 тоже очень нравится. Они же вроде сейчас затеяли сделать для нее llvm бекенд? Судя по активному шевелению в рассылке.
Ты прекрасно знаешь, что периодически я на нем пишу. И еще чаще я читаю код на нем писанный.
Вообще, чтение кода штука значительно более частая чем написания кода, и вот с чтением у Оберона имеются определенные проблемы.
Если говорить о том сколько требуется усилий чтобы разобраться в коде написанного на разных языках в проекте более-менее осмысленного размера, то, по моему личному опыту получается примерно такой списочек (вначале идут ЯП в коде которых проще всего разобраться — где что лежит и как это поправить). Список не полный, и кроме этого, я сюда включил только императивные ЯП:
Modula-2, Modula-3
Ada (with generics too), ObjC, С, С++(without stl/boost-like code)
Go, java, Oberon 1990/2015
C++/templates (stl, boost, etc)
Напомню, что это список чисто субъективный, и основан на моем личном опыте.
С++(without stl/boost-like code) — это код С++ возможно с интенсивным использованием stl и boost, но не код этих библиотек сам по себе.
С++/templates (это как раз код stl или boost) на последнем месте не в последнюю очередь из за того, что там нет разделения на спецификацию и реализацию. Компилятор это не умеет.
Программа подсчитывает сумму байт в объектнике (простейшая чексумма), а также смотрит какой объем файла объектника. В лог выдает: file_size flag sum, где flag это число для контроля того, что у нас модуль нужной версии загружен (это сделано, чтобы избежать человеческого фактора при тестировании).
Пример вывода: 432 0 32948.
Что будем менять: будем менять длину имени переменной t (2 варианта: t и t01234), будем менять длину переменных s012345678901234567890123456789 и u012345678901234567890123456789 (короткие варианты соответственно s и u), также посмотрим что будет, если этих двух переменных не будет вовсе.
При тестировании каждый вариант теста будем запускать 2 раза — с flag=0 и flag=1. Чтобы убедиться, что мы нигде не налажали.
Итак, результаты:
Итого, можно уверенно сделать следующие выводы, что:
Также можно осторожно предположить, что объем объектника не зависит от числа локальных переменных (если они не инициализируются (в том числе неявно, компилятором) и не используются).
Желающие могут попробовать воспроизвести мои результаты. У вас все для этого есть. Ну, заодно и оцените каково программировать код в Project Oberon 2013 ;-)
PS. И я посмотрел — в Project Oberon 2013 действительно удалена глава 12.9 посвященная посмертной отладке и инспекции стека и кучи. Таким образом Вирт посчитал возможность в случае падения приложения её хоть как-то отладить, лишней. Оберон стал еще проще :-)
Нет, Виртовский компилятор не выкидывает, насколько я знаю, неиспользуемые переменные.
Сравнить объектные файлы несколько сложнее конечно — писать придется несколько больше (а чтобы это на персоналке проверить, нужно файлы на персоналку еще как-то передать). Но я попробую для чистоты эксперимента :-)
О результатах отпишусь чуть позже.
Не сразу понятно что за рабочие среды такие. А вот в оригинале все понятно:
Человек любит сразу на продакшн-серваке разработку вести (в частности)!
Не можешь подсказать где именно эта информация находится в обеъктном файле? Вот его структура:
Ну или какой эксперимент произвести, чтобы убедиться в правдивости твоих слов.
Результаты моих личных исследований и экспериментов говорят об обратном — размер объектного файла (*.rsc) никак от именований локальных переменных не зависит.
Вот тестовый модуль:
Размер объектника получается у данного модуля всегда 320 байт. вне зависимости от того, сколько букв t в названии переменной, то есть зовется она t, или же ttttttttttttttttttttt.
Таким образом получается, что названия локальных переменных в Обероне все же бесплатны.
Или я что-то делаю не так?
Кроме того, в Обероне также нет возможности (по крайней мере я такой возможности не обнаружил) посмотреть при трапе стек или кучу. Если укажешь на таковую возможность, буду весьмя благодарен.
При трапе лишь указывается место в исходнике где трап произошел.
PS. Да, на слово я не верю, все и всегда стараюсь проверять экспериментально. Особенно если я могу это сделать. В случае с обероном я могу. Сори :-)
Итак, Вирт в Project Oberon 2013 слепил не просто операционку, или там язык, а еще и компьютер на FPGA целиком. Слеплено это дело на Spartan-3 (стоило это дело порядка 100 баксов) с использованием в качестве ОЗУ тамошней SRAM. SRAM'a там 1 мегабайт (из которых часть используется под видеопамять). В изначальной рабочей станции (Ceres) же когда Вирт делал первоначальную версию Оберона в 1989 году по естественным причинам также было что-то около 1-2 Мб ОЗУ.
В этом компьютере (на FPGA, 2013 год), в процессоре, нет MMU, а также нет и прерываний. Таким образом классическая пошаговая отладка там, мягко говоря, затруднительна (напомню, что поскольку этот процессор модель для изучения, он должен быть максимально простым и вполне обозримым в плане размеров), впрочем как и, например, вытесняющаяя многозадачность.
Поэтому даже в 2015 году отобрать у Вирта его «старый ZX Spectrum» не представляется возможным — он сам его сделал и вот как раз совсем недавно :-)
Единственное что возможно — это перенести его на какую-то новую платку с FPGA (благо повод имеется — Spartan-3 выведен из продажи), где будет больше ОЗУ. Но тут нюанс — на SDRAM (которой бывает МНОГО — десятки мегабайт! иногда сотни!) перейти будет проблематично в данном проекте: с одной стороны самому писать на верилоге модуль для работы с SDRAM (его обновления и так далее) — это существенно увеличить объемы исходников компа и их сложность, кроме того после этого остро встанет проблема процессора — у процессора Вирта нет конвеера, поэтому он будет бОльшую часть времени просто простаивать. С другой стороны, использовать готовый модуль (которые тем же Xilinx'ом предоставляются) для работы с SDRAM тоже нельзя — это противоречит духу проекта :-) Абсолютно все части компа должны быть как на ладони и понятно как работают.
А дешевых плат с большими объемами SRAM я лично не встречал :-( Собственно даже на альтеру DE2-115 просто так не перетащить: там просто так не сделать 32битную адресацию для SRAM (без потери производительности).
Если есть предложения как можно было бы наименее болезненным способом нарастить память у Оберон-компа — велком! Может совместными усилиями и придумаем что. ;-)
Зато там x86! ;-)
Ну, либо твои коллеги на порядок профессиональней учеников и коллег Вирта, а также самого Вирта, и лучше разбираются как в чужом железе, так и в Обероне :-)
В общем, по моему, что-то не сходится.
Разве нет?
А кстати, ты ведь опять тут вводишь хабрасообщество в заблуждение. За два выходных получилось его портировать (Project Oberon 2013) в основном не потому что он такой маленький простой и хорошо описанный, а потому, что у вас уже был порт на вашу железяку (VAX-11) прежнего Project Oberon, а новый Project Oberon от старого не слишком отличается. Соответственно требовалась лишь адаптация порта под новую версию Project Oberon.
Насколько я помню, Вирт писал, что портирование Project Oberon на новую платформу занимало примерно по полгода работы. Но никак не два выходных.
Любоптыно. А железка у вас с экраном/gui? А в важей железке тоже прерываний нет, или вы ими просто не пользуетесь? А если пользуетесь, то как реализовали их поддежрку в Project Oberon, ведь там их поддержки нет вовсе, да и язык тоже их не умеет.
Ну а кто-то например, чисто субъетивно и по причинам вообще не связанным с языком, будет утверждать что С++ это боль и страдания :-)
А во-вторых если говорить о том Обероне что в Project Oberon 2013, то цели создания его ничем в общем то не отличаются от целей создания Оберона (и системы и языка) что вышел в 1989 году. Конкретный язык оптимизированный под данный конкретный проект, под конкретное железо и нужды. Цели идентичные — изначально Оберон был также писан потому и для того, чтобы было по чему преподавать и на чем тренеровать студентов. Но была и разница — тогда рабочии станции Ceres с Обероном на борту, насколько я понимаю, использовались еще и для почты внутри университета например.
Попытка же из Оберона сделать ЯП общего назначения (то есть не под конкретный проект) неизбежно его раздувает. В оригинальном ЯП Оберон описание 16 страниц, в Оберон-2 (а это уже первые шаги к народному ЯП) уже 26 + 50 страниц из Oakwood Guidelines (там уже и стандартная библиотека какая-то появляется + уточнения семантики и синтаксиса языка). Насколько я понимаю, Компонентный Паскаль и Активный Оберон (со всеми расширениями) еще сложнее и больше.
Но мы с тобой конечно смотрим на Оберон под разными углами — ты с точки зрения практического применения, ибо ты его активно применяешь в работе, поэтому у тебя Active Oberon, а я с точки зрения исследователя и копателя концепций, поэтому меня больше занимают именно виртовские Обероны — изначальный и вот свежий.
В плане оптимизации проекта по размеру и обозримости (и ЯП и ОС) Вирт безусловно добился отличных успехов. Тут если ему и есть равные, то я их не знаю.
В плане применимости на практике (то есть не для DIY, а именно промышленно, когда нужен прежде всего результат, а не процесс), видимо следует смотреть на то, что там делали уже ученики Вирта — Active Oberon, КП и проч.
Я как раз назову это (а точнее то, сколько усилий требуется чтобы разобраться что где в проекте находится и что с чем как связано, и как это все использовать) проблемой языка, причем весьма серьзеной. В модуле этой проблемы почти нет. В С++ (если оно не в стиле stl писано) тоже проблемы в общем то нет. В Аде — нет. А вот в Обероне, Го, Яве и C++ в стиле boost/stl — есть.
Ошибаешься. В основном когда я разбираюсь в чужом проекте (не важно на каком он языке) я использую либо просто веб-просмотрщик github'a (или что-то аналогичное), либо что-то типа FAR'а (если в винде) либо grep + cat | less в юниксах. Вне зависимости от языка.
Если бы я говорил с учетом IDE, то java могла бы (но это вовсе не обязательно) переместиться на самый верх списка (у java прекрасные IDE), но она там, где она есть — рядышком с Обероном. Просто потому, что я не люблю зависить от того, за каким компьютером я сейчас сижу и какое окружение у меня сейчас настроено. Частенько я код читаю, и в нем разбираюсь вообще с планшета, где IDE нет вовсе никакой.
Тем более что если я умею разбираться в коде без IDE, то в IDE я тем более смогу сориентироваться, а вот если я привыкну использовать IDE, то без нее (или в другой IDE) может быть уже больно.
Ну и вообще, у меня обычно получается найти то что нужно в чужом проекте (без IDE) часто быстрее чем у людей знакомых с этим прокетом и с IDE ;-)
Чукча таки опытный читатель ;-)
Так что да, действительно, не пишу и не писал на Обероне :-) Совсем. Никогда.
PS. Но таки да, по работе я оберон действительно не использую. Это хобби и отличная моделька для изучения.
А что именно осложняет разбираться в проектах на Обероне (а также Go, Java) я описал выше и довольно подробно. Не вижу смысла повторяться.
PS. И да, мне Модула-3 тоже очень нравится. Они же вроде сейчас затеяли сделать для нее llvm бекенд? Судя по активному шевелению в рассылке.
Вообще, чтение кода штука значительно более частая чем написания кода, и вот с чтением у Оберона имеются определенные проблемы.
Если говорить о том сколько требуется усилий чтобы разобраться в коде написанного на разных языках в проекте более-менее осмысленного размера, то, по моему личному опыту получается примерно такой списочек (вначале идут ЯП в коде которых проще всего разобраться — где что лежит и как это поправить). Список не полный, и кроме этого, я сюда включил только императивные ЯП:
Напомню, что это список чисто субъективный, и основан на моем личном опыте.
С++(without stl/boost-like code) — это код С++ возможно с интенсивным использованием stl и boost, но не код этих библиотек сам по себе.
С++/templates (это как раз код stl или boost) на последнем месте не в последнюю очередь из за того, что там нет разделения на спецификацию и реализацию. Компилятор это не умеет.