Совмещать более одного не скриптового языка в проекте — это значит создавать себе лишние 30-70% работы, бестолковой и грязной.

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

Use CERN ROOT, Luke.

ROOT homepage.
Система классов продумана, есть поддержка Qt4 для GUI. Все объекты наследуют TObject ввиду того, что тут кроме библиотек ещё и интерпретатор С++ есть (CINT).

Разработка велась очень и очень долго (лет 17), весь численный матан уже сделан, графики (1D,2D,3D) и аппроксимация есть — на все грабли уже наступили.
Лучше писать расширения к ROOT в виде тех же библиотек. Также есть привязки к Python — PyROOT, нелюбители С++ тоже будут довольны.

Сам каркас + интерфейс чаще всего и переделывались?

Ну да. Существенные изменения бывали только в GUI и организации вычислений (от «подождите я считаю» до грида и decission-cube).

На чем написан угадать не берусь... на баше? Наверное каждый новый лидер переписывал его на своем любимом ЯП;-)

каркас был на tcl`е - и единственная миграция это с 7-ки на 8-ку (может раньше и с 6-ки, но не застал). Кстати предложения переделать всё «по-взрослому на Qt/Gtk/Wx» заказчик отвергал просто с порога :).

Ну это так, историческое отступление..

Сейчас подобную систему (в смысле gui и диспетчер) я бы возможно делал на Python`е - он подходит как клей, его много и он вряд-ли сдохнет ближайшие 10 лет.

На чём делать числодробилки - в принципе вдоль, если согласованы и неизменны форматы и API. Но чем больше внутри ОО, тем легче ошибки проскакивают в релизы.

Всё таки, программа должны быть «Батарейки в комплекте»

Я вам русским языком объясняю: сервер приложений, который запускает клиентские вычислительные модули и общается с ними по какому-нибудь протоколу. Вам тут уже вагон вариантов предложили от xmlrpc и soap до кондора и mpi.

Посоветуйте инструмантарий

LISP же.

C++, Pascal, Qt

Но ведь это же быдлотехнологии и ненужны.

каркас был на tcl`е

У меня мелькала такая догадка, но я решил что это слишком брутально;-)

А о какой системе речь?

Но чем больше внутри ОО, тем легче ошибки проскакивают в релизы.

Ну, это все таки спорное утверждение. Вопрос же не в ОО как в таковом, а в том что его не умеют готовить. ИМНО.

Прототипчик, не смог завести. Creator его открывает но не собирает. И я не могу найти как вообще его собирать: как компилировать паскалевский модуль, как компилировать сишный. У меня сложилось впечатление, что паскаль очень привязан к C++, и для добавления 2 и более модулей будет необходима изменение Сишной программы и перекомпилирование её. Но это так. Я посмотрел в торону Clang, охренел от такой фантастики. Можете ли объяснить подробней как им пользоваться? Это же, фактически, интерпретатор С++, или я что-то не так понимаю? А работает ли он на нормальной скорости? А как программу, которая написана на С++, можно с помощью clang скомпилить в исполняемый файл?

Хм... Опасался такого.

На всякий случай укажу: для открытия проекта надо открыть файл *.creator, драг&дропом или из диалога открытия проекта. Тогда по Ctrl+B будет работать сборка.

В настройках сборки (пятый режим, Ctrl+5), как я надеюсь, build directory остаётся ../bin. Clang — это просто GCC-совместимый компилятор c++, можно заменить команду clang++ на gcc или g++.

Тогда для сборки будет достаточно gcc и fpc.

низкоуровневой работы с памятью

Что, конкретно имеется в виду под низкоуровневой работой с памятью

Ручное выделение памяти, сборка мусора, адресная арифметика.

Сборка мусора — ручное управление памятью?

Я не знаю версии паскаля без ручного выделения памяти. Тоже и с указателями. Правда адресная арифметика есть не везде, но ее можно смоделировать.

Так какой

низкоуровневой работы с памятью

нет в паскале?

s/ручное управление памятью/низкоуровневая работа с памятью/

Правда адресная арифметика есть не везде, но ее можно смоделировать.

Ну началось... вона на плюсах и рефлексию делают, и черти чего, но это не значит что это удобно получается и хорошо работает.

Чего, на паскале можно выделить память одним куском, а потом самостоятельно его делить между объектами разных типов? И это будет хорошо и естественно?

Ссылок в паскале тоже вроде нету;-)

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

Что-то из тебя смайлики полезли. К чему бы это?

Я ничего не говорил про применение паскаля к число дробилкам. Я лишь не согласен с утверждением об отсутствии в паскале низкоуровневой работы с памятью.

Чего, на паскале можно выделить память одним куском, а потом самостоятельно его делить между объектами разных типов?

Я не совсем понимаю о чем ты. Но такой код вполне допустим.

И это будет хорошо и естественно?

Нет. Естественно будет написать свой менеджер памяти, раз уж готовый не удовлетворяет. Во Free Pascal такое возможно.

По поводу указателей и адресной арифметики во Free Pascal см. документацию. Особенно начиная с фразы

Remark: Free Pascal treats pointers much the same way as C does.

Ссылок в паскале тоже вроде нету

А это тут причем? В C их тоже нет и что, в C тоже нет низкоуровнего управления памятью?

Я лишь не согласен с утверждением об отсутствии в паскале низкоуровневой работы с памятью.

Ок. Пусть так, я не специалист по паскалю и это лишь ИМНО.

амиго vsrmis тема еще актуальна или нет?

похоже что мой проект пересекается с твоими хотелками.