OberonCore

Почему сразу C++? А, ну да, я ж сам пример на C++ привел. Ну это потому что в других языках вообще до неприличия просто Мне, например в хаскеле нравятся списки. И в питоне - тоже ничего Нет там ни страшных шаблонов, не супер сложных компиляторов, и сборка мусора присутствует. Все равно не так надежно как в обероне?

Лично мне в половине случаев хватает односвязного списка (тогда руками, как делать нечего...), либо массива...

В других случаях возникает что-то посложнее - либо дерево, либо граф. Тут есть свои "заначки" библиотечные, которые используешь; но они не универсальны, а заделаны удобно под определённые use-cases.

Часто использую RocotStructs - древесные S-выражения, по сути.

Понятно. Все хорошее в жизни незаконно, аморально, либо ведёт к ожирению. Это я в том смысле, что хорошее всегда недоступно по какой-нибудь дурацкой причине (развивается в год по чайной ложке за полкопейки на общественных началах и засекречено-закопирайчено (Композита), перпендикулярно промышленным стандартам за пределами узкой отрасли (Cache), "не пользуется спросом потому, что дорого, а дорого потому, что не пользуется спросом" (новые инструментальные средства на основе Оберонов) и т.п.). Зато полно успешно продаваемых СУБД-мастадонтов за десятки мегабаксов и плохо совместимых с ними систем программирования-мастадонтов с ворохом убогих контейнеров-суррогатов нормальной СУБД. Очень печально.

И в этом перечне нет Оберона: http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers. Так что SQLite проплывает мимо.

Про что Вы - "засекречено"?

Одно другому - не мешает, между прочим...
Мне неясно только одно: почему СЕЙЧАС Оберонцы системс не включат в состав ББ минимальную библитеку стандартных динамических структур данных?
Ладно, в первой половине 90-х или даже во второй. Но сейчас-то - имеется колоссальный опыт применения разнообразных структур в С++, Яве и Сишарпе.
Можно пойти по минималистскому пути и включить всего 3-4- самых простых и постоянно используемых.
Хотя массивы оберона хороши, но они не растущие.

Это не те контейнеры.
В обероне контейнер - это Store. Но я с ним еще не разобрался.

Про растущие массивы - посмотрите библиотеку Mt у нас на сайте, модуль MtMem.
Там есть SetLength для динамических массивов.

Понячтно, что все можно написать "для себя". Я тоже могу написать нечто похожее лично для себя и своих работ.
Но профессиональные программисты все же предпочитают не изобретать очередной "велосипед", а пользоваться стандартной реализацией. Это повышает надежность и мобильность программ.
Тут Оберон системс не доработали. Подскажите им, пусть в очередную версию включат.
Тут же еще один плюс есть: они могут оптимизировать эти контейнеры максимальным образом, ибо обладают всей полнотой информации о ББ и КП.

Кстати, вернемся к вопросу о психологии программистов.

Инструмент провоцирует метод проб и ошибок. И это приводит к профессиональной деформации личности.
ИМХО, профессиональная деформация как раз и заключается в том, что "программерам закон не писан".
Между прочим, пару высказываний инфо-21 показали мне, что даже он не избежал этого явления.
В чем, по вашему мнению, состоит профессиональная деформация личности программистов?

Согласен.Не логично. Чтобы повысить надёжность и мобильность нужно пользоваться надёжными и мобильными реализациями. А не стандартными. Впрочем, одно другому не мешает: стандартная реализация может быть надёжной. Обычно.

Почему же не логично.
1. Стандартная реализация обычно одинаково работает на всех платформах - это мобильность
2. Стандартная реализация обычно "вылизывается" на предмет различных блох и скорости - это надежность.

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

Тут недооценены ещё (всё впереди) плюсы ББ как "мини-ОС" внутри отдельного процесса, если эти процессы рассматривать в рамках целых комплексов. Особенно в рамках целевой платформы для CASE-4GL Нужно понять, как это готовить А готовить, как практика показывает, можно очень интересно. А раздули б - уже не развернуться.

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

Ну что ж поделаешь, никто не хочет ездить на телеге в 21 веке и жить без электричества А компиляторы питона и хаскеля действительно намного проще C++.

Мда, опять аналогии...
Ну что же, ездить на телеге запряженной лошадью, вообще - то моя потаённая мечта (пока приходится довольствоваться логаном). Что касается электричества, то лично мне очень не хватает (по настоящему не хватает) автономии.
Что касается сути вопроса, то проблема действительно важная и интересная. Считаю, что на данном форуме она неявно присутствует во многих столкновения мнений. Мой личный опыт работы в DELPHI, заставляет многое переосмыслить. Сколько раз я ловил себя на мысли, использование чего-то готового, совершенного, с обилием возможностей требует слишком много времени и сил. Короче, где та грань?

Михаил Донской (http://itblogs.ru/blogs/donskoy/default.aspx) говорил из своего опыта, что если проект идёт больше полугода, то создание собственной инфраструктуры под него всегда оправдывает себя. Если меньше полугода - то проще обычно брать готовую основу.

1. ИМХО ББ намного опередил стандартные средства разработки. Концепция встроенной модульности - это просто СУПЕР!!!! Ни DLL изучать нет нужды, ни COM - тоже в топку!
Но с другой стороны, я себе не представляю, например, АСУ нашего универа, написанное на ББ. Пока интуиция мне подсказывает, что ББ - это не для корпоративных систем уровня предприятия.
2. И с другой стороны, в самом языке не хватает шаблонов (именно поэтому Легалов для исследования процедурно-параметрической парадигмы пытается ренализовать оберон с шаблонами). Отсюда и сложности в написании простых контейнеров, чья работа от типа не зависит. А у меня такое ощущение, что как раз в ББ шаблоны реализовать - ну просто нефиг делать! Ибо динамическая загрузка и динамическое связывание - все работает. Осталось добавить спереди один шаг: динамическая подстановка конкретного типа в модуль.

По поводу параметризма - может быть, может быть... Если будет промежуточное представление.

Но не проще ли решать такие задачи на уровне генерационном, из описаний выше...

В любом случае, каждый пляшет от своих задач. Только так можно ясно понять, что нужно.

Дык, это, респект! Если нравится, то можно и на телеге кататься Я вот лично испытываю только положительные чувства, когда обгоняю мужичков с лошадками и телегами (это не уничтожительная аналогия, я живу рядом с деревней). Но сам предпочитаю оставаться за рулем



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

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

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