Component Pascal и Oberon

> Или можно под офтопиком pthreads использовать?

вообще-то, можно. Есть порт в районе cygwin или mingw.

не унифицированы между разными ОС - самому писать?

а в модуле windows есть CreateThread, так что если не ломает писать по-разному, можно

Что на счёт колбэков в нимрод из разных тредов - работает? Как вообще на счёт safe-кода - всем стандартным библиотекам можно доверять?

пробовать надо. Написать свой тест и пробовать.

ну т.е. в нимроде нет - т.е. либо «интерфейсы», либо «AST-макросы»

нет, такого нет. Там есть модули, есть include-ы, есть ООП с мультиметодами и dispatch trees, есть интерфейсы, есть макросы. Всё отдельно. В ooc cover — это что-то вроде интерфейсов в Go, попытка отделить интерфейсы от классов.

ECL тоже транслируется в си - в результате тормозит не то что больше си, а и больше sbcl, а со сборкой со всеми библиотеками рантайм у него практически как у sbcl получается. Так что «не доказательство»

конечно, не доказательство. Доказательством будет конкретный бенчмарк, вроде того, что написали для Vala: сравнили конкретные версии тестов, компиляторов, реализаций алгоритмов. Для других версий результаты могут быть другими.
Насчёт «рантайм практически как у sbcl» — не согласен, всё сильно зависит от набора. В SBCL «минимальный рантайм» — образ около 32 Мб, в ECL — около 2х.

Если я и соглашусь терпеть vm, то это должно давать что-то существенное:

ну с этим я и не спорю. Просто в некоторых случаях это гибкое, существенное можно и без VM. А в некоторых без VM не обойтись. Так что гибкие языки и без VM существуют, вопрос в количестве костылей и конечной стоимости получившегося решения..

> И, насколько я знаком с Vala, он (именно как язык) - вторичная лажа.

там два языка, с синтаксисом питона и с синтаксисом C#. Как языки они интересны в контексте поддержки GObject. Вне этого контекста, по сравнению с обычным C# и обычным питоном ничего особо интересного нет.

> теоретически - да. практически - где результаты?

ну вот Vala benchmark — вполне себе результат. Что-то среднее между C++ и C, ближе к Си. По сравнению с Mono разница раз в 3-4. Для других языков подобных примеров не видел, но навскидку логично ожидать примерно того же. Потому что все эти языки близки к Си.
С ECL, Gambit Scheme и т.п. тут другая история, языки дальше от Си.

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

да вот хотя бы пример: язык Pawn C встраиваемый интерпретатор Small C.

 — язык Си расширен конечными автоматами, см.

@reset() { play «track1.mp3», 255 }

если бы это был нормальный Си, такое же можно было бы на Ragel сделать.

Вот это и нужно системам управления: легко и просто описать логику управления. А бороться с сегфолтами, скоростью компиляции и модульностью не нужно.

>> Или можно под офтопиком pthreads использовать?

вообще-то, можно. Есть порт в районе cygwin или mingw.

мля, я не про библиотек - я про нимрод! Только не надо говорить «берите ffi и используйте»

так что если не ломает писать по-разному, можно

ещё как ломает! т.е. минус мультиплатформенность... (т.е. на уровне си)

пробовать надо. Написать свой тест и пробовать.

"...нет уж, нет уж - лучше вы к нам!"

Насчёт «рантайм практически как у sbcl» — не согласен, всё сильно зависит от набора. В SBCL «минимальный рантайм» — образ около 32 Мб, в ECL — около 2х.

Как у вас так получается? Загрузил sbcl «минимально» - 2 Мб. Загрузил ECL - те же 2. Загрузил у ECL все (5?) стандартных библиотек - >5Мб. Ну да, sbcl пожирнее будет, но у него и библиотек побольше.

Согласен, что всё зависит от набора. Вот только выгоды в ECL особой не вижу.

Так что гибкие языки и без VM существуют, вопрос в количестве костылей и конечной стоимости получившегося решения..

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

>Пробовал Скалу

Да, у скалы с документацией беда. Пришлось покупать електронну книжку. Кстати, без проблем с русскими пластиковыми карточками... Даже CVV не спрашивало. Первое издание по 2.7 есть в торрентах, а вот второго, которе вышло 13-го декабря, пока нет.

Тут недавно конфуз вышел.

Забей! Из этих троих только Одерский пытался как-то формализовать ООП. Кроме того, не хочешь, да не пользуйся. В Скале и параметрического полиморфизма тебе хватит. Кроме того, с делегированием и трейтами вопрос ооочень интересный. Да, с одной сторону миксин становится подтипом трейта, с другой — внутри трейта ты можешь пользоваться интерфейсом стороннего класса либо через метод super, причем из-за скаловской линеаризации иерархии происходят очень прикольные вещи а-ля АОП, либо через принудительное объявление типа this, что является вроде как делегацией. И кто тут чего поймет?

Дальше - больше. Есть еще штука под названием path dependant types, т.е. тип Foo.T и Bar.T разный. И многие вопросы, которые решаются с помошью наследования можно порешать с помощью типов-членов.

Плохо то, что в Скале нет по-настоящему абстрактных типов.

В общем, язык крайне достойный. Особенно из-за возможности невозбранно пользоваться бескрайними наработками ява-мира.

Вот только выгоды в ECL особой не вижу.

я вижу только один профит от ECL: Embedded Qt, встраивать CL в Qt GUI приложения. Собрал, поставил. Половина примеров работает. Другая половина вываливается с глупыми багами (не находит «переменную» |0.5| внутри paint коллбека, пример с макросом !/qfun внутри paint, что-то намудрили с макросом. Хотя другой похожий пример без такого макроса работает) cl-smoke медленный ибо через CLOS, в CommonQt часть недопортировали, так что сейчас EQL похоже самые рабочие биндинги к Qt. Конечно, если биндинги к Qt не нужны, то ECL особо и не нужен :) Хотя к тем же fltk или fox было бы проще привязаться. вот в бложике человек разошёлся, встраивает в Qt приложения всё подряд: ECL, Lua, схему s7.

Вот в репозиториях CMUCL-а в contrib обнаружилась такая фишка: embedded-c — пример встраивания откомпилированного Си кода в FASL-ы.

Макрос define-c-code, который принимает код на Си в виде текста и код на лиспе в виде заглушек функций. Макрос разворачивается в 1)нужные обёртки для FFI 2) текст Си-кода, включая код заглушек. Затем Си-код компилируется Си компилятором в /tmp, создаётся .so библиотека, и подгружается через dlopen в сгенерированные обёртки. Результат: пишется си код на лиспе, заглушки понимают си-переменные и лисп-переменные, из лиспа можно вызывать си реализацию. Правда, тот пример написан для КМУКЛа. Для SBCL надо бы его нормально переделать — там используются кмукловые пакеты sys, ext, load-time-function. Хотя переделать должно быть не сильно сложно.

что значит «в рамках системы навигации»?

пример с проекта. система навигации - GPS, прокладывание пути, POI, отображение на экране

> пример с проекта. система навигации - GPS, прокладывание пути, POI, отображение на экране
Ясно. В общем, тут завёл отдельную тему про рилтайм и сборку мусора, выяснили, что до десятков микросекунд можно сократить время приостановки тредов для сборки мусора (ценой общего замедления). Правда, там не совсем внятно описаны характеристики программы. GPS навигаторы, к-рые я видел - довольно тормозные. Хотя, наверное, есть и более быстрые, для каких-нибудь крылатых ракет.

>Хорошо бы еще мнение Сильви услышать по поводу даннных PL...
А оно что, авторитет?

CP = oberon-2 + чуток расширений + более созвучное с паскалем название.

каковы впечатления.

Жить можно. GPCP неплохо интегрирован с JVM.

Нужно ли это знать как разработчику?

Необязательно.

разработчику из всего оберона нужно знать про модульность и про динамическую модульность, модули

Это — суть компонентного программирования. Остальное (синтаксис, рантайм, реализация) — не столь существенные детали.