А может все таки сделать нормальную VM (пират не годится) для "скриптовых" (слабо-типизированных) языков ? Если перенять опыт Self VM то получится не так и медленно. Конечно медленней чем VM под строгие языки, но ведь машины быстреют. В критичных местах можно подкладывать код на C/C++.

Народ, ведь если б не Java то его нишу вполне мог занять слаботипизированный Smalltalk. Если "копировать" не получается может лучше "инновировать" ?

anonymous (*) (20.03.2004 6:11:36)

Ну, кстати, если внимательно почитать статью, то Пеннингтон там рассматривает GPL-альтернативы VM, которые уже кое что могут. А еще он затрагивает такие вещи, как взаимодействие через всякие компонентные технологии. Только почему-то он вспомнил только UNO (из OO.org) и XPCOM (из Мозиллы). А где COM? А где CORBA, мать ее за ногу? :)

Но если честно, то задача слишком сложная. Кстати, а к кому ты обращаешься с призывами делать свои разработки? Это же сообщество, а не коммерческая фирма (хотя их тоже просить сделать что-то бестолку - только самому сесть и писать... Осталось самое просто - начать и закончить :)). Можно сколько угодно жаловаться, сколько угодно требовать удовлетворения своих прихотей - "лучше бы они сделали это", "а нафига они делают так?", "когда же исправят все баги?", "лучше бы написали свой VM". Вот к кому обращены эти все фразы? Здесь же никто никому не должен, понимаешь? Другая совсем инфраструктура. Пока кто-то не возмется - дело не тронется. Либо какая-нибудь контора не откроет какой-нибудь полезный код. А, может, вообще не стоит рыпаться? Может сейчас и без того все хорошо? сишный/плюсовый код пишется, на разные платформы переносится. Вот я пока и не могу понять, чем собственно в сегодняшнем положении дел недоволен Пеннингтон? И вообще... Я не во всем понял его тревоги...

Хочется свои 5 копеек вставить...

Есть qtc - биндинг Qt на c, идёт в составе KDE SDK.

Интерфейсы на С - это правильно и хорошо, но не необходимо, хотя при желании можно и C наружу вытащить, причём замедления почти не будет (см. qtc).

Smart pointers - плач Ярославны ( к сожалению ), если делать их "на все случаи жизни". Пример - boost.smartptr. Там много и умно про это дело написано.

PS. Классный тред! Конструктивные разговоры >100 постов на ЛОР - надо в летописи заносить :-)

PPS. freedesktop.org - очень круто (imho). Сдружить KDE с Гномом - это попытки, достойные уважения. Кстати, пробовали их qt-gtk?

Re[2]: Ряженка с кефиром рулят.

> Плюсовый манглинг сюда же, к соглашениям о вызовах?:)

Ага ;)

Я про подход. Если те же вызовы стандартизованы - то становится действительно неважен язык реализации. Если на языке X неудобно реализовать принятые соглашения - он не подходит и на нём писать не будут. Если удобно - соответственно..

> Нет, перешел на следующий уровень - почитываю труды В. И. Ленина
> перед сном :)

Смотри, понравится - не слезешь :-)

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

Просвети, как он проступает наруж в CLR дотнетовском, например?

> Напишешь на C++ - и инфраструктурой смогут пользоваться только
> приложения на C++.

Нет. То есть смотря как напишешь. Если наружу отдать классы - конечно, удобно будет реюзать это только из OO-языков. Но вообще-то C++ универсальный инструмент и ничто не мешает отдать наружу простой процедурный интерфейс для сложной приплюснутой начинки. Думать надо конечно о деталях, а где не надо?

> Вот тебе уже пример, когда язык - немаловажная деталь.

Это только пример непродуманности конкретных интерфейсов (или их предназначенности для других целей).

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

Нет, я говорю о интерфейсах, описываемых в качестве __бинарного__ стандарта.

> А вот еще есть библиотека OpenCascade. Тоже написана на C++. Один
> из проектов в рамках OpenCascade - это попытка прикрутить к
> библиотеке Питон. Автор этого проетка где-то на сайте так и
> говорит, что вот не может он поиспользовать все возможности, ибо в
> Питон не совсем аналогичен C++ (я не помню точно, на что он
> жаловался, но легко найти).

Но посмотри - все эти JVM, CLR и прочие друзья как раз и пытаются решать сию проблему. То есть класс смотрит наружу через __стандартные__ __бинарные__ интерфейсы. И тому питону по идее должно становиться по барабану, на чём написан используемый класс.
И в этом есть преимущества явные. Как и недостатки разумеется.

> Пожалуйста тебе - интерфейсы... :)

Вот спасибо-то! ;-)

Плохо глядел ;) Из виденного мной - lablGtk имеет конечно низкий уровень, но в нем есть и абстрактные высокоуровневые классы.

про атомарность read/write

> Я только хотел уточнить (после того, как еще раз прочел тот документ): как Вы будете реализовывать атомарный write/read без временных файлов?

> Типа функции

> double calculateSomething( double param1, double param2, double param3 ) - если все, что у Вас есть, это файловая система.

Нет, у меня есть IPC. А файловая система -- это обертка.

Примерно так: open -- транслятор создает порт (основной IPC примитив в Mach), дает вызвавшему потоку право PORT_SEND[_ONCE]. write -- получает параметры, вычисляет функцию, и _только_ после этого дает клиентскому потоку право PORT_RECEIVE. read -- посылает значение, ждет, пока клиент его получит, уничтожает порт, ждет, пока кто-то еще захочет написать в файл.

про низкооборотность

> У всех этих "станков" перед С++ есть один большой недостаток - у них низкооборотный двигатель :)

Не факт. nestedsums на C++ ( библиотека для аналитического разложения обобщенных полилогарифмов, см. http://arxiv.org/abs/math-ph/0201011 ) работает ненамного быстрее, чем на Reduce ( фактически, интерпретатор LISP).

про gnome-kde-vfs

> Представили себе кросс-десктопный gnome-kde-vfs

Посмотрели на ROOT, MathLink, Axiom, GiNaC... Увидели, что OO I/O нужно не только desktop environment'-у... И каждый его изобретает с нуля... И какая там к чертям совместимость... :((

QtC?

Вот если честно, то я не видел никогда qtc, но могу предположить что это такое. Если неправ, то поправь. qtc - это, наверняка, сишная обертка вокруг *классов стандартных виджетов*. И только *ими* и можно пользоваться конечной программе. Ну то есть сделано по-сути отображение для всех конкретизированных классов типа QList.xxx (); <-> qlist_xxx ();

А можно ли через сишный интерфейс qtc языкам, которые не имеют четко выраженной объектно-ориентированной направленности (скажем, тот же Lisp или Scheme) использовать механизмы наследования? Можно ли конструировать новые классы на основе тех, что есть в Qt? Я предполагаю, что нет. Из-за несовместимых парадигм нельзя. Ты это сможешь сделать только через C++. А вот в Gtk+, это можно. Именно такое его использование заложено в его архитектуру (вернее, в архитектуру рантайм сиситемы GObject). С компромиссами и неудобствами (они вызовут бурю отрицательных эмоций у тех, кто пишет на C++), но заложено. Именно GObject является главной достопримечательностью Gtk+. Вопрос надобности этих механизмов на все случаи жизни оставим в стороне. Я бы не стал, разумеется, везде помахивать флагом с надписью "Gtk+", так как случай Gtk+ - очень нетипичный для программирования. Графический тулкит - один из ярких примеров, где такие механизмы очень полезны и нужны. а в общем случае... вряд ли нужно. Тут вполне

Хотя мы уже тут удалились от темы... Это больше подходит к религиозным флеймам C vs. C++, Gtk+ vs. Qt, в которых я стараюсь не учавствовать. Отвлеклись...

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

ТРЕД ЗАКРЫТ

Все, тред закрыт.

Если только не добавить до 130+ постов, с главной страницы его не видно.

Жаль. А поговорили хорошо:)

> И снова таки никаких претензий насчёт монополизма не выдвинешь.

IBM такая же контора как и MS (по масштабам). Посмотрим как это им понравится....

> и весь IPC можно запихать в файловые операции.

> Мне казалось, Вы в том треде утверждали, что "все - файл"

Да, именно так.

> Порт - это файл?

Нет, это базовый примитив IPC.

> и весь IPC можно запихать в файловые операции.

Для _клиентского_ потока это будет обычный open-write-read.

> И вообще - что такое все эти права с т.зр. операций с файлами?

Что-то вроде ACL, только они для каждого потока свои.

А ты хто такой? ;-)

> Все, тред закрыт.

Никак, анонимный модератор к нам пожаловал? ;)

> Стой! А как по-другому ты себе видишь биндинг Gtk+ для Lisp'а и его диалекта Scheme?

Как я вижу:

(toplevel :border 10
  (vbox
    (button :text "aaa" :signal '("click"  . (lambda (...) (...)))
    (entry  :text "bbb" :signal '("return" . (lambda (...) (...)))
     ....
  )
)

Как сейчас:

(structure ()                                                                                        
                                                                                                     
  (define window (gtk-window-new 'toplevel))                                                         
                                                                                                     
  (define button (gtk-button-new-with-label ""))                                            
                                                                                                     
  (gtk-container-set-border-width window 10)                                                         
                                                                                                     
  (g-signal-connect window "delete_event" (lambda (w) (throw 'quit 0)))                              
                                                                                                     
  (g-signal-connect button "clicked"                                                                 
                    (lambda ()                                                                       
                      (write standard-output "hello, world\n")))                                     
                                                                                                     
  (gtk-container-add window button)                             

;; Содание и размещение Entry, я даже не буду описывать.
                                     
  (gtk-widget-show-all window)                                                                       
                                                                                                     
  (setq interrupt-mode 'exit)                                                                        
  (recursive-edit))