скриптовый язык для встраивания в приложения

scheme

lua

можешь попробовать tcl,perl,pyton или сам чтото новое придумай

вот как раз нового колеса придумывать не хочется.

python via boost::python адназначна!

ecl, scheme, lua

VB

>VB

онанимусы как всегда рулят

Что, кроме python/tcl/perl сам ничего не знаешь, и оттого встреваешь где ни попадя?

при всем отвращении к М$ -- COM весьма разумная технология, и то что в Linux ее общепринятого аналога до сих пор нет тормозит встраивание скриптовых языков и интеграцию приложений на их основе. Все что есть в Linux это bash-скрипты оставшиеся со времен текстовых терминалов первых unix-образных. Для приложений, работа которых не укладывается в схему stdin/stdout/exitcode общепринятой технологии скриптования и публикации части API не существует.

Тогда как под оффтопиком можно рулить тем же мсоффисом хоть из питона, хоть из тикля, хоть из форта с явой. То есть поддержка VB автоматически означает многие другие языки.

что вы предлагаете?
VB под linux ?

Где вы увидели в вопросе слово "линух"?

этот форум посвещен разработке в первую очередь под Линукс.

DCOP бы, только без KDE.

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

Поддерживаю анонимуса, высказавшего про COM. Хорошей ЕДИНОЙ (что очень важно) компонетной модели Unix-у действительно не хватает, хотя и существует идеологический и технологический задел для ее создания

> Поддерживаю анонимуса, высказавшего про COM. Хорошей ЕДИНОЙ (что очень важно) компонетной модели Unix-у действительно не хватает,

Его нигде не хватает. COM на ХОРОШУЮ компонентную модель не тянет. anonymous, высказавшийся про COM, скорее всего жертва импринтинга - увидел в юности это угребище и считает его панацеей.

в юности я видел все больще ваксы с фортраном

> в юности я видел все больще ваксы с фортраном

                                      ^^^^^^^^^

Ну или так. 

у кого-нибудь QSA (Qt Script for Application) работает?

Не надо тут ля-ля. COM - это не FFI даже. Это очень узенький и ограниченный интерфейсик.

Нормальный FFI есть только у того же Microsoft в .NET...

СлабО обосновать оптимальность? Ведь глупость же сказал, обязан теперь публично покаяться.

С какой радости любая КОМПОНЕНТНАЯ модель будет единой и универсальной?!? Значительная часть форм взаимодействия никак в объектную идеологию не укладывается.

>Что, кроме python/tcl/perl сам ничего не знаешь, и оттого встреваешь где ни попадя?

нет предложил то что юзают другие в довольно серьёзных проектах

>при всем отвращении к М$ -- COM весьма разумная технология, и то что в Linux ее общепринятого аналога до сих пор нет тормозит встраивание скриптовых языков и интеграцию приложений на их основе. Все что есть в Linux это bash-скрипты оставшиеся со времен текстовых терминалов первых unix-образных. Для приложений, работа которых не укладывается в схему stdin/stdout/exitcode общепринятой технологии скриптования и публикации части API не существует.

ето ты не знаеш линукс

>Тогда как под оффтопиком можно рулить тем же мсоффисом хоть из питона, хоть из тикля, хоть из форта с явой. То есть поддержка VB автоматически означает многие другие языки.

а под линуксом из командной строки можно рулить тем же мсоффисом но запученным при помощи вайна под фрёй на соседней машине

кто сказал "универсальной"? единой модель должна быть, а не параллельные версии для Qt, GTK, плюс еще XML-RPC всякий

А зачем ей вообще быть?!? Ну не ложится почти никакое взаимодействие на компонентную архитектуру, хоть ты тресни. Дерьмо получается...

Странно. Мне всегда казалось, что в основе развития современной ВТ лежит компонентный принцип как на аппаратном так и на программном уровне. Примеров тысячи. Расскрути свой системный блок и посмотри из каких КОМПОНЕНТОВ состоит твой компьютер, программы bash, gсс, X являются КОМПОНЕНТАМИ твоей операционной системы и т.д.

Концепция Unix определяет компонентную модель, где основными элементами являются процессы. Процессы могут взаимодейсвовать между собой некоторыми способами. Для многих задач с которыми сталкивается современный разработчик ПО гибкости такой модели явно недостаточно. Возникает потребность в более гибкой компонентной модели, отвечающим современным требованиям. Из-за отсутсвия подходящего стандарта на такую модель, люди в таких проектах как gnome, kde, mozilla вынуждены клепать свои поделки, вместо того чтобы реализовать общую, идеологически правильную компонентную модель на уровне операционной системы.

ukez (18.01.2005 15:54:43):

> развития современной ВТ лежит компонентный принцип как на аппаратном так и на программном уровне. ... Концепция Unix определяет компонентную модель, где основными элементами являются процессы.

Согласен.

> Для многих задач с которыми сталкивается современный разработчик ПО гибкости такой модели явно недостаточно.

Не согласен.

> Из-за отсутсвия подходящего стандарта на такую модель, люди в таких проектах как gnome, kde, mozilla вынуждены клепать свои поделки, вместо того чтобы реализовать общую, идеологически правильную компонентную модель на уровне операционной системы.

Ну, во-первых, такие стандарты есть.

Во-вторых, Гном как раз построен поверх ПРОМЫШЛЕННОГО стандарта.

И, наконец, (IMHO, разумеется) (почти) все эти промышленные и доморощенные конпонентные разработки нарушают компонентную модель Unix и происходят исключительно по причине излишней распальцованности разработчиков.

Сравните fvwm и kde.

fvwm использует родную Юниховую компонентную модель, и при этом весьма шустр, мал и функционален. Kde ... Ок, не буду флейм разводить.

Увы, не я поставил знак тождества между компонетной и объектной архитектурами. Теперь нет смысла называть необъектную компонентную архитектуру этим словом - не поймут-с.

И пойми - не может быть общей модели для принципиально разных форм IPC и разных моделей вычислений.

To Die-Hard:

Сам факт существоания независимых компонентных моделей в продуктах GNOME, KDE, mozilla, в Windows и т.д. по моему мнению говорит об одной из тенденций в разработке ПО. Игнорировать эту тенденцию нельзя и разработка новой, более функциональной модели для Unix стала бы очень хорошим делом. Такая модель не должна быть антогонистической по отношению к исходной компонентной модели Unix, а наобарот являтся ее дополнением Например, в виде дополнительного средства IPC с отображением ресурсов процесса на фаловую систему. Что-то вроде смеси named pipe, procfs и devfs ( кажется так сделано в Plan9 ?).

По поводу уже существующих стандартов. Проблема существующих стандартных компонентых моделей, ИМХО, как раз в чрезмерной "удаленности" от программиста Unix. Java Beans (или как оно там ...) доступна только под Java, Corba имеет репутацию сложного промышленный стандарта для распределенных бизнес систем ( когда говорю Corba, чувствуется влияние таких авторитетных программистких образов как middleware, distributed system, почему-то Oracle ... и т.д. :)) не каждый захочет городить огород с CORBA.

Ощущается нехватка в виде относительно простой, логичной компонентной модели, доступной напрямую через операционную систему, обладающей той же "математической идеологией" что и Unix, но в то же время достаточно функциональной для современного уровня.

To Moridin:

А я и не говорил про объектную компонентную модель, я говорил про то что нужна компонентная модель, а какой она должна иметь дизайн - это вопрос другой. И я не предлагаю объединять все IPC в рмках одной модели, наобарот я предлагаю расширить набор IPC unix-систем реализацией компонентной модели.

ukez(18.01.2005 18:19:56):

> Ощущается нехватка в виде относительно простой, логичной компонентной модели, доступной напрямую через операционную систему, обладающей той же "математической идеологией" что и Unix, но в то же время достаточно функциональной для современного уровня.

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

Посмотри на Irsi :-)

Ну Мигель все-таки талантливый человек, размах и полет мысли у него очень широкий, впрочем как и у Ирси :)

Ну тогда зачем расширять? Unix way - и есть не-объектная компонентная модель, стандартная вся из себя, дико гибкая... Никаких новых велосипедов тут изобретать не надо.

To Die-Hard ***** (*) (18.01.2005 18:49:35)

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

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

Программное обеспечение системы нуждаются в тесной интеграции, которую трудно организовать классическими средствами UNIX. В качестве примера развития идеи компонентной модели для UNIX могу привести Plan9.

Moridin (18.01.2005 20:46:05):

> Unix way - и есть не-объектная компонентная модель, стандартная вся из себя, дико гибкая... Никаких новых велосипедов тут изобретать не надо.

Устами Moridin'а глаголет истина :-)

А объектная парадигма IMHO -- дань моде.

ukez (19.01.2005 1:08:41):

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

Не согласен. Нет желания вступать в длинный флэйм, просто два наблюдения.

1. Если уж речь зашла о тенденциях в разработке программного обеспечения, то IMHO стОит забыть обо всем, кроме творений M$. В настоящее время все остальные тенденции (в количественном аспекте) практически не играют роли.

2. Тенденции эти сегодня определяются рынком, как ни прискорбно. Известный закон (один из законов Мэрфи?) гласит, что на рынке всегда побеждает самое кривое техническое решение.

2chucha :

> Ну Мигель все-таки талантливый человек, размах и полет мысли у него очень широкий, впрочем как и у Ирси :)

Кстати, я с этим полностью согласен. Как про Мигеля, так и про Ирси :-)

Вот только Мигеля на пушечный выстрел нельзя подпускать к руководству Open source проектами.

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

У Ирси масштабы, конечно, не те; но как некая модель в уменьшенном масштабе он вполне смотрится. Тоже весьма неглуп, эрудирован и прозомбирован (если Irsi это прочитает -- прошу прощения за высказанную сугубо личную точку зрения; прошу не воспринимать как оскорбление).

Ладно. я думаю время нас рассудит

Уже рассудило. Диалектику учил в деццве? Развитие по спирали, и всё такое. Нынешные XML-ориентированные технологии (включая тот же SOAP) - это подизвращённый и подгаженный ООПщиной Unix Way (текст, пайпы, generic processing tools).

туцдшыз (newlisp.org) занятная вещица

Опсс! newlisp конечно же

Чем он лучше Гиля (guile)?

Тут уже говорили, я повторюся более развернуто - ИМНО однозначто питон. ПРичем не его встраивать в приложени а приложение в него. Я просто подобную автору вопроса задачу уже решал, 1:1, после долгих поисков остановился на этом варианте.

Благоря свиг-у это делаеться разом (если нуно - могу прислать пару фич для генерации конфиг и маке файлов, если руками лениво и для поддержки корректной сериализации импортированных из С++ объектов).

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