Здравствуйте, Cyberax, Вы писали:
>> C>Или там интероперабельность s-выражений между разными вариантами Лиспа. >> И в чем проблема? С-варажния и в африке с-варажения.
C>В том, КАК они будут представлены.
Это не говорит о том, что .NET как средство объединения языков вообще плох. Это говорит о том, что в нем кое-чего не хватает. Возможно, со временем появятся какие-то стандарты и в этой области. Если разработчики не будут сидеть сложа руки.
А то обычно все сводится к одному.
"Ха, да этот .NET вообще остой полный. Там даже динамической типизации нет! (ленивых функций, мультиметодов — подставить по вкусу)
Да ну его нафиг! Мы лучше все сами заново сделаем"
Дарней wrote:
>>> C>Или там интероперабельность s-выражений между разными вариантами > Лиспа. >>> И в чем проблема? С-варажния и в африке с-варажения. > C>В том, КАК они будут представлены. > Это не говорит о том, что .NET как средство объединения языков вообще > плох. Это говорит о том, что в нем /кое-чего не хватает/. Возможно, со > временем появятся какие-то стандарты и в этой области. Если > разработчики не будут сидеть сложа руки.
Не думаю. Те же мультиметоды реализуются с помощью достаточно громоздких
конструкций кода, причем вариантов как это можно написать — масса, с
разными trade-off'ами. Так что вероятность того, что писатели разных
языков договорятся об одном формате — минимальна.
"Официальные" стандарты от MS помогли бы, но чего-то пока в эту сторону
движения нет никакого.
Вот общий GC — это действительно полезно.
> А то обычно все сводится к одному. > "Ха, да этот .NET вообще остой полный. Там даже динамической типизации > нет! (ленивых функций, мультиметодов — подставить по вкусу) > Да ну его нафиг! Мы лучше все сами заново сделаем"
С динамикой у .NET вообще куча проблем. Например, подгруженые сборки
будут жить пока существует домен приложения (а в Java ненужные классы
собираются GC), так что языкам с динамической JIT-генерацией байт-кода
не очень приятно.
Здравствуйте, Cyberax, Вы писали:
C>Не думаю. Те же мультиметоды реализуются с помощью достаточно громоздких C>конструкций кода, причем вариантов как это можно написать — масса, с C>разными trade-off'ами. Так что вероятность того, что писатели разных C>языков договорятся об одном формате — минимальна.
C>"Официальные" стандарты от MS помогли бы, но чего-то пока в эту сторону C>движения нет никакого.
Наверно.. но иметь хоть какое-то общее подмножество лучше, чем никакого
Здравствуйте, Cyberax, Вы писали:
>> C>Тут уж стоит на Parrot VM смотреть — там они постарались все по >> C>максимуму сделать. >> Пара вопросов если можно... >> 1. Почему на такой убогой платфоме как дотнет реализовано столько >> языков <http://www.dotnetpowered.com/languages.aspx> (среди которых >> добрая половина скриптовые), а на такой удобной как Parrot пока что >> только один (ну, два под вопросом)?
C>Это скорее проблема отсутствия энтузиазма — ребята взялись за слишком C>большой по масштабу проект.
Это проблема отсуствия мозгов. Браться за задачи о которые ломают зубы огромные корпорации — это еще то развлечение. Можно было просто доработать одну из виртуальных машин явы или дотнета.
В общем, отмазки не выдерживают никакой критики. Наличие мелких пролем никак не умоляет возможностей интеграции разных языков которые предоставляются рантаймами явы и дотета. Именно это и привело к появлению такого количества языков для них.
... << RSDN@Home 1.2.0 alpha rev. 577>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> C>Это скорее проблема отсутствия энтузиазма — ребята взялись за слишком > C>большой по масштабу проект. > Это проблема отсуствия мозгов. Браться за задачи о которые ломают зубы > огромные корпорации — это еще то развлечение.
Linux.
А эти ребята в итоге сделают VM, работа у них движется, хотя и медленно.
> Можно было просто доработать одну из виртуальных машин явы или дотнета.
Там вроде бы ясно написано почему они от этого _пока_ отказались.
> В общем, отмазки не выдерживают никакой критики. Наличие мелких пролем
"Все хорошо, прекрасная маркиза"....
> никак не умоляет возможностей интеграции разных языков которые > предоставляются рантаймами явы и дотета. Именно это и привело к > появлению такого количества языков для них.
Для Java их еще больше, а уж языков написанных на С — вообще огромное
количество. Только вот, сволочи, не интероперируют они...
А может интероперабельность эту нужно чуть выше (в иерархии технологий и архитектур) поискать — в WSDL-Web-сервисах. Ну уж очень это интересно выглядит (готовый Web-сервис можно спокойно и без лишнего труда использовать из разных программ на любом языке). Танцы с бубнами, конечно, и здесь иногда имеют место, но в перспективе — почему бы нет?
Alexey Rovdo wrote:
> А может интероперабельность эту нужно чуть выше (в иерархии технологий > и архитектур) поискать — в WSDL-Web-сервисах. Ну уж очень это > интересно выглядит (готовый Web-сервис можно спокойно и без лишнего > труда использовать из разных программ на любом языке). Танцы с > бубнами, конечно, и здесь иногда имеют место, но в перспективе — > почему бы нет?
Потому что WSDL — это тупик. Это еще хуже, чем обмен .NET-овскими объектами.
На самом деле Web-серивисы — это просто еще один протокол RPC, только
overhype-нутый.
Здравствуйте, Cyberax, Вы писали:
>> Можно было просто доработать одну из виртуальных машин явы или дотнета.
C>Там вроде бы ясно написано почему они от этого _пока_ отказались.
Они еще и пишут его на plain C... меня терзают смутные сомнения по поводу судьбы этого проекта
Дарней wrote:
>>> Можно было просто доработать одну из виртуальных машин явы или дотнета. > C>Там вроде бы ясно написано почему они от этого _пока_ отказались. > Они еще и пишут его на plain C... меня терзают смутные сомнения по > поводу судьбы этого проекта
Чистый С сам по себе — не проблема. В конце концов, почти весь GTK на С
написан.
Здравствуйте, Cyberax, Вы писали:
C>Чистый С сам по себе — не проблема. В конце концов, почти весь GTK на С C>написан.
Тем не менее, он их создает, и в немаленьком количестве. Взять тот же самый GTK — скорость его работы под Win32 оставляет только желать лучшего. Я конечно понимаю, что это для него не родная платформа. Но Swing и тот кажется по сравнению с ним не таким уж тормозным.
К тому же GTK вроде бы достаточно старый проект. Какой смысл начинать новый проект на чистом C, я не знаю
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>VB еще ладно. Его уже ничего не испортит. CS>>А вот во что С++ превращается в шаловливых-то ручонках...
VD>Ага в приличный язык. На нем даже современный софт писать становится можно.
Но это уже не VB тогда, а C# с VB-like синтаксисиом.
Дарней wrote:
> C>Чистый С сам по себе — не проблема. В конце концов, почти весь GTK на С > C>написан. > Тем не менее, он их создает, и в немаленьком количестве. Взять тот же > самый GTK — скорость его работы под Win32 оставляет только желать лучшего.
Это скорее просто низкое качество реализации рендеринга на Винде.
> Я конечно понимаю, что это для него не родная платформа. Но Swing и > тот кажется по сравнению с ним не таким уж тормозным. > К тому же GTK вроде бы достаточно старый проект. Какой смысл начинать > новый проект на чистом C, я не знаю
Parrot VM такими темпами тоже скоро станет старым проектом.
Andrei N.Sobchuck wrote:
> Д>К тому же GTK вроде бы достаточно старый проект. Какой смысл > начинать новый проект на чистом C, я не знаю > А какие есть варианты?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А mono на С++?
По большей части на C#, хотя в критичных к производительности местах есть и C. Но C# на момент начала того проекта не было, а предлагать Яву я не стал, а то фанаты С предали бы меня анафеме
Здравствуйте, Дарней, Вы писали:
ANS>>А mono на С++?
Д>По большей части на C#, хотя в критичных к производительности местах есть и C. Но C# на момент начала того проекта не было, а предлагать Яву я не стал, а то фанаты С предали бы меня анафеме
На чистом C моно. На C# пишутся только библиотеки. Сама реализация вся на С. Исходники то доступны, чего стоит взглянуть прежде чем заявлять такое?
