tcl

глубоко уходящее в метапрограммирование

ruby

Питон

для размышлений

http://pipes.yahoo.com/pipes/

Ok, вопрос - почему? Вы делали сами некую платформу на tcl? Удобно работать с ней потом было или нет?

(начал делать на tcl, но сейчас вижу, что код будет поддерживать очень сложно - язык мощный, по сути у меня сейчас 500 строчек пишут программу на тысячи полторы, но читабельность - никакая)

А на Ruby можно организовать обмен сообщениями как в smalltalk? Если да - то как это сделать?

В чем его киллер-фичи при разработке платформы?

http://c2.com/cgi/wiki?RubyIsSmalltalkMinusMinus
Не могу ручаться, но вот тут вроде расписано.

я что-то цель не совсем понял. Т.е. надо:
а) придумать гармоничное апи для подключения модулей, чтобы новый было легко написать в стиле import||use||require my-wanderapp?
б) автоматически скачивать/устанавливать недостающие модули?

Если я тебя правильно понял, то могу предложить помедитировать на то, как сделано у com.cemerick/pomegranate для кложури. Там достаточно указать репы (вместо appstore можно что-то своё поднять для гемов и т.д.) и зависимости добавить. Оно сделано поверх maven, поэтому классическую инфраструктуру окружения конкретного ЯП тоже стоит изучить.

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

Smalltalk

tcl, python и ruby (тупо лучше всего знаю эти языки)

Если так, то ты сам лучше всего знаешь

какой из представленных языков подойдет больше для этих целей

А на Ruby можно организовать обмен сообщениями как в smalltalk?

Даже на пхп можно, очевидно же

Если да - то как это сделать?

Написать систему обмена сообщениями например

Долго буду изучать, не вариант.

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

Спасибо Кэп, пруф дали выше. Вопрос «как» касался конкретного варианта реализации. А так - естественно можно хоть на голом Си все это сделать.

Я вопроса не понял ваще. ВОт я знаю питон но не знаю ни руби ни тикля - ясно, что я отвечу «питон». Вы хотите найти тут человека, к-й лучше Вас знает эти три ЯП и при этом делал такие вещи? ИМНО маловероятно...

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

Лично я заложился бы на «что-то очень глубоко уходящее в метапрограммирование», в моем представление это tcl (в руби слишком много ООП, питон тут вообще «ниачом»)

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

Основное требование - для платформы создать максимальный уровень абстракции, чтобы потом дописывать необходимый модуль было а) не долго б) не приходилось ломать голову над тем как «вставить в этот зоопарк нового франкенштейна».

лол.. gem?

А программировать нужно на руби.

Блин, питонщики, http://www.ibm.com/developerworks/ru/library/l-python_part_6/ это ж нифига не удобно..

А программировать нужно на руби.

Или хотя бы js.

UI на js, остальное на руби.

бг у меня такая задача реализована на java с nio из-за больших нагрузок, с десятком приемником и передатчиков сообщений и затейливо маршрутизацией (теперь вот какбы нарисовать гуйню к этой маршрутизации)

так что выбор языка тут дело десятое

Делал на tcl так. У пользователя базовый загрузчик, в нем меню, из которого пользователь выбирает нужное приложение, оно загружалось в slave-интерпретатор. А еще был проекты, где приложения сами себя собирали из нужных модулей на машине клиента, тащили модули по отдельности из сервера хоть в рантайме, каждый модуль определял свое namespace. Каждый из модулей мог в свою очередь тащить себе другие модули, если надо ему, в дочернее namespace, функционировало без проблем. В общем, все было динамически на пространствах имен. Так что tcl должен подойти, за питон и руби не скажу, не использую.