LCR>А VB, который клал с прибором на наследование вообще?..
LCR>Это чё? Здесь явно пропущена мысль:
LCR>
LCR>А VB, который клал прибор на наследование вообще?..
Нет. Фразеологический оборот "клал с прибором" употребляется именно в том виде, в котором и вошел в статью. Этимологию этого оборота я объяснить затрудняюсь.
Зверёк Харьковский,
ЗХ>Нет. Фразеологический оборот "клал с прибором" употребляется именно в том виде, в котором и вошел в статью. Этимологию этого оборота я объяснить затрудняюсь.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>И – тогда – появился – .Net
Честно говоря, достала уже эта реклама дотнета и серебряных пуль...
Не надо забывать, что введение языка в дотнет намертво привязывает этот язык к фреймворку со всеми вытекающими...
Флеймов по этому поводу было уже много и не хочется разводить очередной.
Здравствуйте, Shire, Вы писали:
ЗХ>>И – тогда – появился – .Net S>Честно говоря, достала уже эта реклама дотнета и серебряных пуль... S>Не надо забывать, что введение языка в дотнет намертво привязывает этот язык к фреймворку со всеми вытекающими... S>Флеймов по этому поводу было уже много и не хочется разводить очередной.
Вообще-то говоря, если посмотреть список моих сообщений на РСДНе, можно заметить, что я никаким краем не дот-нетчик, и ко всеобщему щастю посредством равенства и братства отношусь весьма скептически (например, тут
Тем не менее, невиданную легкость межъязыковой интеграции в рамках .Net отрицать нельзя. Более того, подробное исследование этой проблемы боюсь, покажет, что для естественного интеропа ОО-языков прослойка типа дотнета просто необходима. Об этом и статья.
Зверёк Харьковский wrote:
> Тем не менее, невиданную легкость межъязыковой интеграции в рамках > .Net отрицать нельзя. Более того, подробное исследование этой проблемы > боюсь, покажет, что для естественного интеропа ОО-языков прослойка > типа дотнета просто необходима. Об этом и статья.
На самом деле, интеграция в .NET невидано легкая до тех пор, пока не
пытаются объединить разные по концепциям языки. Например, Haskell и
Python для .NET просто скрестить уже не получится. То есть получится, но
результат будет не сильно лучше, чем если бы использовался COM.
ИМХО, самый большой плюс для интероперабельности языков в .NET — это
унифицированый GC.
ЗХ>Нет. Фразеологический оборот "клал с прибором" употребляется именно в том виде, в котором и вошел в статью. Этимологию этого оборота я объяснить затрудняюсь.
После такой тонкой и интеллигентной статьи, я не верю, что ты не знаешь этимологии. Лукавишь, лукавишь
P.S. Этимология этого оборота, если уж на то пошло, восходит к некоему Баширову, артистру театра и кино (и цирка, в душе).
Здравствуйте, mihailik, Вы писали:
ЗХ>>Нет. Фразеологический оборот "клал с прибором" употребляется именно в том виде, в котором и вошел в статью. Этимологию этого оборота я объяснить затрудняюсь.
M>После такой тонкой и интеллигентной статьи, я не верю, что ты не знаешь этимологии. Лукавишь, лукавишь
Не надо надо мной издеваться Я очень нежное и ранимое существо.
M>P.S. Этимология этого оборота, если уж на то пошло, восходит к некоему Баширову, артистру театра и кино (и цирка, в душе).
Да? А подробнее? Потому как я про этот оборот помню только довлатовское:
Николай Тихонов был редактором альманаха. Тетка моя была секретарем
этого издания. Тихонов попросил ее взять у Бориса Корнилова стихи. Корнилов
дать стихи отказался.
— Клал я на вашего Тихонова с прибором, — заявил он.
Тетка вернулась и сообщает главному редактору:
— Корнилов стихов не дает. Клал, говорит, я на вас с ПРОБОРОМ.
— С прибором, — раздраженно исправил Тихонов,- с прибором. Неужели
трудно запомнить?!
Здравствуйте, Cyberax, Вы писали:
C>Зверёк Харьковский wrote:
>> Тем не менее, невиданную легкость межъязыковой интеграции в рамках >> .Net отрицать нельзя. Более того, подробное исследование этой проблемы >> боюсь, покажет, что для естественного интеропа ОО-языков прослойка >> типа дотнета просто необходима. Об этом и статья.
C>На самом деле, интеграция в .NET невидано легкая до тех пор, пока не C>пытаются объединить разные по концепциям языки. Например, Haskell и C>Python для .NET просто скрестить уже не получится. То есть получится, но C>результат будет не сильно лучше, чем если бы использовался COM.
Более того:
Как-то мы все дружно позабыли что собственно .NET это один единственный
язык — C#. Остальные языки пришлось менять до полной неузнаваемости и смены
архитектуры.
COM как средство interop как-то представляется более терпимым — суть универсальным.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Cyberax, Вы писали:
C>>Зверёк Харьковский wrote:
>>> Тем не менее, невиданную легкость межъязыковой интеграции в рамках >>> .Net отрицать нельзя. Более того, подробное исследование этой проблемы >>> боюсь, покажет, что для естественного интеропа ОО-языков прослойка >>> типа дотнета просто необходима. Об этом и статья.
C>>На самом деле, интеграция в .NET невидано легкая до тех пор, пока не C>>пытаются объединить разные по концепциям языки. Например, Haskell и C>>Python для .NET просто скрестить уже не получится. То есть получится, но C>>результат будет не сильно лучше, чем если бы использовался COM.
CS>Более того:
CS>Как-то мы все дружно позабыли что собственно .NET это один единственный CS>язык — C#. Остальные языки пришлось менять до полной неузнаваемости и смены CS>архитектуры.
Абсолютно согласен: все это "многобразие языков" — на самом деле один язык + несколько подогнаных под этот один. Посмотрите что они сделали с VB.
CS>COM как средство interop как-то представляется более терпимым — суть универсальным.
Согласен.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Абсолютно согласен: все это "многобразие языков" — на самом деле один язык + несколько подогнаных под этот один. Посмотрите что они сделали с VB.
И чем F# отличается от родного Ocaml-а? Ну, или что схожего у L#-а и C#? Возможность пользоваться общей библиотекой?
... << RSDN@Home 1.2.0 alpha rev. 575>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>На самом деле, интеграция в .NET невидано легкая до тех пор, пока не C>пытаются объединить разные по концепциям языки. Например, Haskell и C>Python для .NET просто скрестить уже не получится. То есть получится, но C>результат будет не сильно лучше, чем если бы использовался COM.
Короче их все задолбашся перечислять. Вот один из списков: http://www.dotnetpowered.com/languages.aspx. Изучи на досуге.
C>ИМХО, самый большой плюс для интероперабельности языков в .NET — это C>унифицированый GC.
А, по-моему, не стоит говорить о вещах в которых плохо разбирашся.
.net — это отличный бэкэнд для любого компилятора. Там решена целая куча задач:
1. Генерация нэйтив-кода.
2. Имеется гибкая система типов.
3. Имеются высокоуровневые средства для генерации высокоуровнего языка.
4. Имется рефлекшон и исчерпывающая метаинформация с возможностью ее рсширения.
В общем, много чего имеется. Тут в пору отедельную статью писать.
ЗЫ
Вообще ты бы по сотарожнее делился бы своими откровениями. А то это уже не смешно.
... << RSDN@Home 1.2.0 alpha rev. 575>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> C>На самом деле, интеграция в .NET невидано легкая до тех пор, пока не > C>пытаются объединить разные по концепциям языки. Например, Haskell и > C>Python для .NET просто скрестить уже не получится. То есть > получится, но > C>результат будет не сильно лучше, чем если бы использовался COM. > Ух ты! И обосновать сможешь?
Да. Покажите, пожалуйста, ленивую функцию в стиле Хаскелла, которую
можно использовать в качестве Схемного потока.
Или там интероперабельность s-выражений между разными вариантами Лиспа.
> .net — это отличный бэкэнд для любого компилятора. Там решена целая > куча задач: > 1. Генерация нэйтив-кода.
Согласен.
> 2. Имеется гибкая система типов.
Где она "гибкая"? Где множественное наследование реализации (Python,
C++)? Где мультиметоды? Где ленивые функции? Где поддержка динамических
объектов (для динамических языков)?
Все это можно эмулировать средствами .NET, но вот шансы того, что два разных языка будут использовать для эмуляции одни и те же
средства — весьма малы.
Тут уж стоит на Parrot VM смотреть — там они постарались все по
максимуму сделать.
> Вообще ты бы по сотарожнее делился бы своими откровениями. А то это > уже не смешно.
Точно, я же на письмо про GC еще не ответил — так все в драфтах и
валяется. Щас допишу...
Здравствуйте, Ka3a4oK, Вы писали:
KK>Абсолютно согласен: все это "многобразие языков" — на самом деле один язык + несколько подогнаных под этот один. Посмотрите что они сделали с VB.
VB еще ладно. Его уже ничего не испортит.
А вот во что С++ превращается в шаловливых-то ручонках...
А вообще это нормальный процесс — Java — JavaVM, С# — .NET
И я не понимаю — чего стесняться-то? Языки хорошие для своего
domain. И VM хорошие. Ну и все собственно.
Здравствуйте, Cyberax, Вы писали:
C>Да. Покажите, пожалуйста, ленивую функцию в стиле Хаскелла, которую C>можно использовать в качестве Схемного потока.
Я не знаток Хаскеля, но проблем в реализации линивой функциональности не вижу.
C>Или там интероперабельность s-выражений между разными вариантами Лиспа.
И в чем проблема? С-варажния и в африке с-варажения.
C>Где она "гибкая"?
В дотнете. Ты бы прежде чем рассуждать разобрался бы.
C> Где множественное наследование реализации (Python, C>C++)?
См. МС++ и Эфил. Без проблем реализуют нужную функциональность. Плюсь множественное наследование интерфейсов на котором все что хочешь можно реализовать.
C> Где мультиметоды?
Почитай как работает Type.InvokeMember. В Clos они реализованы и под дотнетом. К тому же мультиметоды это более высокоуровневая фича реализованная шататно в паре языков (из тысяч). В общем, это поиски отмазки.
C> Где ленивые функции?
Повторяшся. Линивость это алгоритмическое свойство которое глупо встраивать в низкоуровневый фрэймоврк. Дотнет и MSIL — это своеобразный ООП-ассемблер, а не конечный язык программирования.
C> Где поддержка динамических C>объектов (для динамических языков)?
Чушь какая-то. Любой объект в дотнете динамический. И успешное вополощение массы динамически типизированных языков тому подтверждение.
C>Все это можно эмулировать средствами .NET, но вот шансы того, что два C>разных языка будут использовать для эмуляции одни и те же C>средства — весьма малы.
Рантаймы вроде дотнета или явы являются огромным подспорьем в деле компиляторостроения (а нет того скрипта который не мечтал бы быть компилируемым), так как снимают массу забот с программиста. Да они не в силах решить все проблемы компиляторщика, но по сравнению с созданием компилятора для аппаратной платформы — это невероятная помощь.
C>Тут уж стоит на Parrot VM смотреть — там они постарались все по C>максимуму сделать.
Пара вопросов если можно...
1. Почему на такой убогой платфоме как дотнет реализовано столько языков (среди которых добрая половина скриптовые), а на такой удобной как Parrot пока что только один (ну, два под вопросом)?
2. В чем проблемы при реализации на дотнете типизированных языков?
... << RSDN@Home 1.2.0 alpha rev. 575>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> C>Да. Покажите, пожалуйста, ленивую функцию в стиле Хаскелла, которую > C>можно использовать в качестве Схемного потока. > Я не знаток Хаскеля, но проблем в реализации линивой функциональности > не вижу.
Мы говорим не про проблемы реализации, а про проблемы интероперирования.
> C>Или там интероперабельность s-выражений между разными вариантами Лиспа. > И в чем проблема? С-варажния и в африке с-варажения.
В том, КАК они будут представлены.
> C> Где множественное наследование реализации (Python, > C>C++)? > См. МС++ и Эфил. Без проблем реализуют нужную функциональность. Плюсь > множественное наследование интерфейсов на котором все что хочешь можно > реализовать.
Где стандарт на эмуляцию MH с помощью интерфейсов, чтобы я могу в своем
велосипедном языке SuperВелосипед прозрачно работать с Питоновскими
классами?
> C> Где мультиметоды? > Почитай как работает Type.InvokeMember.
А скорость, а скорость...
> В Clos они реализованы и под дотнетом. К тому же мультиметоды это > более высокоуровневая фича реализованная шататно в паре языков (из > тысяч). В общем, это поиски отмазки.
Я прекрасно знаю как мультиметоды реализуются. Еще более прекрасно я
знаю, что в каждом языке под .NET они реализованы по-своему.
> C> Где поддержка динамических > C>объектов (для динамических языков)? > Чушь какая-то. Любой объект в дотнете динамический. И успешное > вополощение массы динамически типизированных языков тому подтверждение.
Взять объект в Perl.NET, передать его в Python.NET, который прикрепит к
нему пару новых методов и передаст его скрипту на JScript.NET — не
получится. Так как общепринятого формата на динамические объекты — нет.
> C>Все это можно эмулировать средствами .NET, но вот шансы того, что два > C>*разных* языка будут использовать для эмуляции *одни и те же* > C>средства — весьма малы. > Рантаймы вроде дотнета или явы являются огромным подспорьем в деле > компиляторостроения (а нет того скрипта который не мечтал бы быть > компилируемым), так как снимают массу забот с программиста. Да они не > в силах решить все проблемы компиляторщика, но по сравнению с > созданием компилятора для аппаратной платформы — это невероятная помощь.
Я не спорю. Только вот в интероперабельности это все мало чем поможет.
> C>Тут уж стоит на Parrot VM смотреть — там они постарались все по > C>максимуму сделать. > Пара вопросов если можно... > 1. Почему на такой убогой платфоме как дотнет реализовано столько > языков <http://www.dotnetpowered.com/languages.aspx> (среди которых > добрая половина скриптовые), а на такой удобной как Parrot пока что > только один (ну, два под вопросом)?
Это скорее проблема отсутствия энтузиазма — ребята взялись за слишком
большой по масштабу проект.
> 2. В чем проблемы при реализации на дотнете типизированных языков?
Неоднозначное отображение системы типов на систему типов в C#.
Здравствуйте, 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# пишутся только библиотеки. Сама реализация вся на С. Исходники то доступны, чего стоит взглянуть прежде чем заявлять такое?
Здравствуйте, Andir, Вы писали:
A>На чистом C моно. На C# пишутся только библиотеки. Сама реализация вся на С. Исходники то доступны, чего стоит взглянуть прежде чем заявлять такое?
"сама реализация" — это наверно ядро системы? Тогда может быть.
*.c 241 файл
*.cs 3745 файлов
Здравствуйте, Дарней, Вы писали:
A>>На чистом C моно. На C# пишутся только библиотеки. Сама реализация вся на С. Исходники то доступны, чего стоит взглянуть прежде чем заявлять такое?
Д>"сама реализация" — это наверно ядро системы? Тогда может быть.
Есть два понятия у моно: mono-project — это весь проект в целом, туда входят все библиотеки и в том числе реализация .Net Framework BCL. И второе понятие mono — это собственно реализация CLI для разных платформ.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Я очень нежное и ранимое существо.
