Здравствуйте, VladD2, Вы писали:
VD>Лучше направить силы на разработку строготипизрованных компонентных клонов Руби и Питона, раз уж эти языки многим наравятся.
Они нравятся именно тем, что не являются статически типизированными и динамическими. Добавь туда статическую типизацию и все преимущества испарятся.
C>> А вот eao197 приводил вполне полезные примеры из C>>своей build-системы.
VD>Скорее, бесполезные. На Немерле можно создать подобную систему и она даже будет куда более строго контролировать формат выдавая понятные сообщения об ошибках. Но зачем это делать кода есть Ant и MSBuild?
На Немерле Ну попробуй. И чей формат эта система будет контролировать? XML-ного описания?
И кстати, зачем MSBuild, если давно был Ant? И зачем Ant, если давно был Make?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Они нравятся именно тем, что не являются статически типизированными и динамическими. Добавь туда статическую типизацию и все преимущества испарятся.
Очепятался... Языки вроде Ruby и Python нравятся именно потому, что они динамически типизированные, а не статичести. А типизация там, кстати, строгая.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Нет, так как с "нормальной бабой" в комплекте обязательно идет сифилис C>(Microsoft), триппер (GC) и СПИД (тормоза).
VladD2 wrote: > C>ParrotVM поддерживает множественное наследование, > Говорить о вреде МН я не намерен. Придерживался и придерживюсь этой > точки зрения. Так что для меня этот пункт минус, а не плюс.
А давайте запретим футбол? Я его не смотрю, значит он плохой.
> C> замыкания, > Для них не нужна подержка VM.
Нужна. Для _полноценной_ поддержки замыканий+continuation'ов.
> C>мультиметоды, > То же самое. Да и мультиметоды никакого отношения к ООП не имеют.
Как и просто методы, классы и интерфейсы
> C> динамические вызовы, > Есть в чем проблема с динамическими вызовами в дотнете?
Нет их.
> C> больше встроеных типов данных. > 1. Это только слова. > 2. "Больше" не значит "лучше". Ты докажи, что они нужны, вот тогда и > поговрим.
Где числа неограниченой точности? Где встроенные quad-char'ы?
> Итак, твои заявления о более широкой поддержке ООП пока что меня не > убедили. Скорее наоборот.
Не надо говорить слова "поддержка ООП", пожалуйста. Это абсолютно
бессмысленная фраза.
> C>Ну так покажите пример интеропа нескольких разных динамических языков. > Все языки реализующие CLS-потребительль/CLS-производитель совместимы > друг с другом без интеропа. Показывать тут просто нечего. Лечите свои фобии.
Ну да, а все С-программы тоже совместимы. Я ведь могу экспортировать и
импортировать Сшные функции!
Здравствуйте, VladD2, Вы писали:
VD>Как выглядит SoundDeviceImpl? И зачем вообще все эти изыски?
Абстрактные блоки должны собираться в графы (для обработки сигналов) произвольным образом в более сложные девайсы, получившиеся девайсы используются как очередные строительные блоки и т.д. Плюс к этому их десткрипторы для визуального редактирования графов/блоков.
В приведеном коде изысков — ноль. Простая задача генерирования синуса при заданной частоте дискретизации обернута в очередной строительный кирпичик.
Здравствуйте, VladD2, Вы писали:
VD>Я ничего не имею против юнит-тестов. В некоторых задачах они полезны. Но я не хочу жить на юнит тестах и писать их ко всем задачам.
VD>Вот для маросов может юнит тесты и будут полезны, так как они являются порождающими сущьностями. А к примеру, для формы ввода они на фиг не упали.
Для формы ввода они тоже полезны, но пока именно для формы ввода их не придумали.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>Абстрактные блоки должны собираться в графы (для обработки сигналов) произвольным образом в более сложные девайсы, получившиеся девайсы используются как очередные строительные блоки и т.д. Плюс к этому их десткрипторы для визуального редактирования графов/блоков.
V>В приведеном коде изысков — ноль. Простая задача генерирования синуса при заданной частоте дискретизации обернута в очередной строительный кирпичик.
Откровенно говоря из этого рассказа и отрывков кода идеи уловить я не смог.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Они нравятся именно тем, что не являются статически типизированными и динамическими. Добавь туда статическую типизацию и все преимущества испарятся.
Тешь себя этой мыслью. Очень помогат дальше писать на С++. А я как-то не вижу приемуществ у динамических языков. Вернее их недостатки сильно перекрывают приемущества.
E>На Немерле Ну попробуй.
Зачем? У меня еще все дома. Заниматься бессмыслеенным велосипедостроением мне не интересно.
E> И чей формат эта система будет контролировать? XML-ного описания?
Ничей, так как ее не будет. Но потенциально ей было бы пофигу.
E>И кстати, зачем MSBuild, если давно был Ant?
Спроси МС.
E> И зачем Ant, если давно был Make?
Дерьмо потому что этот мэйк. Возможностей мало. Все расширение за счет платформно зависимых утилит. Возможности расширения на полноценном ЯП вроде Явы или Шарпа нет вообще. Есть куча полностью не совместимых форматов, а конвертеров нет. Для того же Анта и МСБильда уже есть конверторы. Да и делать их просто, так как это просто ХМЛ-преобразование.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Очепятался... Языки вроде Ruby и Python нравятся именно потому, что они динамически типизированные, а не статичести. А типизация там, кстати, строгая.
Кому как.
Вот блоки кода, работа со списками, континюэйшоны и т.п. мне в Руби нравятся. А тормоза и ненедежность нет.
Самое смешное, что тебе тоже все это не нравится, так как основной код ты на С++ пишешь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> C>ParrotVM поддерживает множественное наследование, >> Говорить о вреде МН я не намерен. Придерживался и придерживюсь этой >> точки зрения. Так что для меня этот пункт минус, а не плюс. C>А давайте запретим футбол? Я его не смотрю, значит он плохой.
Давай лучше футбольных хулиганов запретим. Хоть аналогия будет по прямее.
МН — это багодром. Далее см. выделенное жирным выше.
>> C> замыкания, >> Для них не нужна подержка VM. C>Нужна. Для _полноценной_ поддержки замыканий+continuation'ов.
Объясни как F#, Немерле и C# 2.0 обеспечивают эти самые замыкания и продолжения без подержки среды?
Продолжения вообще алгоритмическая сущьность. Что тут будет поддерживать VM? Сохранение полного своего состояния что ли?
>> То же самое. Да и мультиметоды никакого отношения к ООП не имеют. C>Как и просто методы, классы и интерфейсы
Потрясающая аргументация. Почитай любые работы по ООП. Методы там всюду. А вот про мультиметоды я даже и упоминания не видел.
Мультиметоды — это вариант решения задачи множественной диспечеризации. В принципе заменяется банальными if-ами. Так что не надо мешать горячее с мягким. То же сопоставление с образцом прекрасно заменяет мультиметоды на рактике. Ну, а проблемы... есть у любого решения. Те же мультиметоды не ясно как связывать с вновь загруженными типами.
>> C> динамические вызовы, >> Есть в чем проблема с динамическими вызовами в дотнете? C>Нет их.
Да? Ну, ты, былин, эксперт. Жаль что ты мне раньше не сказал. А то я уже 4 года их использую.
C>Где числа неограниченой точности? Где встроенные quad-char'ы?
В больном воображении. На фиг не упали такие типы. Если что их не трудо будет оформить в виде класса. Если конечно компилятор полноценный.
>> Итак, твои заявления о более широкой поддержке ООП пока что меня не >> убедили. Скорее наоборот. C>Не надо говорить слова "поддержка ООП", пожалуйста. Это абсолютно C>бессмысленная фраза.
Дык, не говори. Это же твои слова.
C>Ну да, а все С-программы тоже совместимы. Я ведь могу экспортировать и C>импортировать Сшные функции!
Попробуй импортировать в Borland C++ 3.1 функцию из библиотеки созданной GCC, к примеру.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вот блоки кода, работа со списками, континюэйшоны и т.п. мне в Руби нравятся. А тормоза и ненедежность нет.
Тормоза действительно есть. Но ведь не математическими расчетами же на Ruby в его нынешнем состоянии заниматься.
А вот надежность повыше C++ ной будет, имхо.
VD>Самое смешное, что тебе тоже все это не нравится, так как основной код ты на С++ пишешь.
Самое смешное, что за последние 1.5-2 месяца я больше программировал на Ruby, чем на C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>> И чей формат эта система будет контролировать? XML-ного описания?
VD>Ничей, так как ее не будет. Но потенциально ей было бы пофигу.
Ну вот давай попробуем подумать потенциально. Предположим, что ты бы использовал Nemerle для создания Internal DSL. Делал бы на макросах такие же описания, как у меня на Ruby. Ну а дальше что? Ведь сначала бы пользователю пришлось скомпилировать свое описание из Nemerle DSL в исполняемый код, затем этот код бы запустился для управления компиляцией моего проекта. Так что ли?
Когда-то ты уже пытался доказывать, что C# можно в качестве скриптового языка применять. Теперь на эту роль Nemerle предендует.
E>>И кстати, зачем MSBuild, если давно был Ant?
VD>Спроси МС.
E>> И зачем Ant, если давно был Make?
VD>Дерьмо потому что этот мэйк. Возможностей мало. Все расширение за счет платформно зависимых утилит. Возможности расширения на полноценном ЯП вроде Явы или Шарпа нет вообще. Есть куча полностью не совместимых форматов, а конвертеров нет. Для того же Анта и МСБильда уже есть конверторы. Да и делать их просто, так как это просто ХМЛ-преобразование.
Так видишь, в каждом инструменте есть свой набор фатальных (для кого-то) недостатков. И для их преодоления кто-то создает свой инструмент. Если бы это было не так, мы бы сейчас про Nemerle не разговаривали.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote: > Давай лучше футбольных хулиганов запретим. Хоть аналогия будет по прямее. > МН — это багодром. Далее см. выделенное жирным выше.
Ага, а GC — это костыль для тех, кто не умеет с памятью работать
Я изначально говорил про большие языковые возможности ParrotVM. MH — это
одна из таких возможностей, которых нет в CLI.
> C>Нужна. Для _полноценной_ поддержки замыканий+continuation'ов. > Объясни как F#, Немерле и C# 2.0 обеспечивают эти самые замыкания и > продолжения без подержки среды?
Прекрасно знаю, еще со времен Java — просто переменные кладутся не в
стек а в поля служебного объекта.
А вот где continuation'ы? Настоящие, а не в виде сгенерированых конечных
автоматов?
> Продолжения вообще алгоритмическая сущьность. Что тут будет поддерживать > VM? Сохранение полного своего состояния что ли?
"Легкие" потоки, например. Чтобы можно было нормально представлять
веб-навигацию, например (см. http://www.seaside.st).
>> > То же самое. Да и мультиметоды никакого отношения к ООП не имеют. > C>Как и просто методы, классы и интерфейсы > Потрясающая аргументация. Почитай любые работы по ООП. Методы там всюду. > А вот про мультиметоды я даже и упоминания не видел.
Определения ООП — "объекты, обменивающиеся сообщениями". В LSP тоже
ничего не говорится о методах.
Ну и такую деталь, что методы являются частным случаем мультиметодов я
уж вообще говорить не буду.
> Мультиметоды — это вариант решения задачи множественной диспечеризации. > В принципе заменяется банальными if-ами.
Ну да, а наследование с полиморфизмом — банальным switch'ем. Что дальше?
> Те же мультиметоды не ясно как связывать с вновь загруженными типами.
В ParrotVM — совершенно ясно, так как код динамический. В .NET —
действительно ничего нормального не получится (о чем я говорил уже раза
три).
> C>Нет их. > Да? Ну, ты, былин, эксперт. Жаль что ты мне раньше не сказал. А то я уже > 4 года их использую.
Еще раз говорю — это _рефлексивные_ вызовы, а не динамические. Динамику
можно эмулировать с помощью словарей делегатов и рефлексии, но в CLI ее нет.
> C>Где числа неограниченой точности? Где встроенные quad-char'ы? > В больном воображении. На фиг не упали такие типы.
Опять же _тебе_ они нафиг не упали, а вот мне они очень даже нужны.
> Если что их не трудо > будет оформить в виде класса. Если конечно компилятор полноценный.
Оформите quadchar (32-битный символ) в виде класса на C#, пожалуйста.
Чтобы с ним работать было не хуже чем с обычным char'ом, JIT его понимал
и использовал оптимизации типа SSE2/AltiVec и т.п.
> C>Не надо говорить слова "поддержка ООП", пожалуйста. Это абсолютно > C>бессмысленная фраза. > Дык, не говори. Это же твои слова.
Где я это сказал? Вроде я ничего такого в последнее время не пил...
> C>Ну да, а все С-программы тоже совместимы. Я ведь могу экспортировать и > C>импортировать Сшные функции! > Попробуй импортировать в Borland C++ 3.1 функцию из библиотеки созданной > GCC, к примеру.
В BC3.1 не получится. А вот в Watcom — элементарно.
Здравствуйте, eao197, Вы писали:
E>Тормоза действительно есть. Но ведь не математическими расчетами же на Ruby в его нынешнем состоянии заниматься.
А что мешает и рассчеты делать на более удобном языке?
E>А вот надежность повыше C++ ной будет, имхо.
Ну, вот и подумай зачем тогда вообще нужен С++ если вполне сравнимую производительность можно полуить на Шарпе или Немерле.
E>Самое смешное, что за последние 1.5-2 месяца я больше программировал на Ruby, чем на C++.
У меня почти тоже самое, за исключением того, что я вообще в последнее время к С++ обращаюсь только для тестов.
И Руби мне тоже особо не нужен. Так как Шарп и Немрле дают большу надежность и больше возможностей (хотя бы в следствии размеров библиотек и количества стороннего кода).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Ну вот давай попробуем подумать потенциально. Предположим, что ты бы использовал Nemerle для создания Internal DSL.
Я уже говорил, что смысла ведосипедить нет. Ну, да ладно... предположим.
E>Делал бы на макросах такие же описания, как у меня на Ruby. Ну а дальше что? Ведь сначала бы пользователю пришлось скомпилировать свое описание из Nemerle DSL в исполняемый код, затем этот код бы запустился для управления компиляцией моего проекта. Так что ли?
В общем-то это не проблема. Ведь нет особых проблем автоматически компилировать "скрипт" перед использованием. Если это делать с умом (т.е. кэшировать сборку если ничего не изменилось в проекте).
Другое дело, что вообще не разумно применять внутренний ДСЛ для описания проекта, так как этим самым мы даем слишком большой набор возможностей потенциальному пользовател.
Если бы передо мной стала бы такая задача, то я скорее всего сделал бы свой вариант Ант-а/МСБилд-а. То есть в качестве языка описания взял бы текстовый форат, и сделал бы расуширяемую за счет компонентного подхода утилиту, которая читала бы и интерпретировла бы этот формат.
Совершенно естествнно, что в качестве инструмент я выбрал бы не Руби или С++ а управляемый язык.
E>Когда-то ты уже пытался доказывать, что C# можно в качестве скриптового языка применять. Теперь на эту роль Nemerle предендует.
Не, я не пытался доказывать. Я использовал C# в качестве скриптового языка. С большим, надо признать, успехом.
VD>>Дерьмо потому что этот мэйк. Возможностей мало. Все расширение за счет платформно зависимых утилит. Возможности расширения на полноценном ЯП вроде Явы или Шарпа нет вообще. Есть куча полностью не совместимых форматов, а конвертеров нет. Для того же Анта и МСБильда уже есть конверторы. Да и делать их просто, так как это просто ХМЛ-преобразование.
E>Так видишь, в каждом инструменте есть свой набор фатальных (для кого-то) недостатков.
Что-то я измоих слов этого не вижу.
E> И для их преодоления кто-то создает свой инструмент. Если бы это было не так, мы бы сейчас про Nemerle не разговаривали.
Про Nemerle я говорю только потому-что увидил что-то что можно реально назвать шагом вперед в области мэйнстрим-языков общего назначения. Появится что-то новое, будем говорить о нем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> Давай лучше футбольных хулиганов запретим. Хоть аналогия будет по прямее. >> МН — это багодром. Далее см. выделенное жирным выше. C>Ага, а GC — это костыль для тех, кто не умеет с памятью работать
Ты сам с собой что ли разговр ведешь?
Причем тут костыли, ЖЦ?
C>Я изначально говорил про большие языковые возможности ParrotVM. MH — это C>одна из таких возможностей, которых нет в CLI.
Проделай простешое размышление. Ответь на вопрос. Если МС имевший код компилятора С++ поддерживающего МС делвая виртуальную машину для Явы и Дотнет не решил включать эту возможность, значи все же это было архитектурное решение, а не недостаток знаний или умений?
На сегодня есть ряд решений заменяющих МН и они вводятся в язык без именения виртуальной машины. Так что встраивание МН в ВМ не очень разумное решение.
Кстати, Эфил и С++ таки поддерживают МН не смотря на его отсуствие в ВМ дотнета.
C>Прекрасно знаю, еще со времен Java — просто переменные кладутся не в C>стек а в поля служебного объекта.
И зачем тогда поддержка в рантайме? Ты не понимашь того что чем проще рантайм, тем проще его перенос?
Лучше потратить время на оптимизации устраняющие котокоживущие локальные объекты заменя их где можно стэковыми переменными.
C>А вот где continuation'ы? Настоящие, а не в виде сгенерированых конечных C>автоматов?
continuation-ы — это алгоритмические сущьности. Их можно реализоывать разными путями. В том числе и на конечных автоаматах. Так что прежде чем продолжать обсуждение "настоящих" continuation-ов потрудись объяснить чем плохи решения на базе переписывания кода с использованием те хе КА.
>> Продолжения вообще алгоритмическая сущьность. Что тут будет поддерживать >> VM? Сохранение полного своего состояния что ли? C>"Легкие" потоки, например.
Легкие потоки уже есть в чистом виде. Эмулировать их на базе continuation-ов смысла нет.
C> Чтобы можно было нормально представлять C>веб-навигацию, например (см. http://www.seaside.st).
Это можно сделть даже на базе итераторов, которые являются одним из вариантов реализации continuation-ов (хотя и ограниченым). Вот, напиример, очень похожая задача решенная с использованием итераторов Михаликом http://blogs.gotdotnet.ru/personal/mihailik/PermaLink.aspx?guid=cb5f993a-2371-4365-80cf-0605461a49c4
C>Ну и такую деталь, что методы являются частным случаем мультиметодов я C>уж вообще говорить не буду.
Спорный вопрос. Эдак и глобальные функции можно считать частным случаем методов.
Мултиметоды могжно реализовать в языках вообще к ООП отношения не имеющим. Так что это именно алгоритмическая фича. К тому же заменяемая другими решениями.
>> Те же мультиметоды не ясно как связывать с вновь загруженными типами. C>В ParrotVM — совершенно ясно, так как код динамический.
Дык а смысл тогда что-то было делать?
C> В .NET — C>действительно ничего нормального не получится (о чем я говорил уже раза C>три).
Сделать то можно все что угодно. Вопрос только в скоросте полученного решения и в востребованности возможности. То что востребованость нулевая и так видно. А вот с производительностью... Почти уверен, что она будет низкой.
>> C>Нет их. >> Да? Ну, ты, былин, эксперт. Жаль что ты мне раньше не сказал. А то я уже >> 4 года их использую. C>Еще раз говорю — это _рефлексивные_ вызовы, а не динамические.
Сеньезно? И делегаты? Ну, ты действительно эксперт. К тому же поведуй мне разницу между "рефлективными" и "динамическими" вызовами.
C> Динамику C>можно эмулировать с помощью словарей делегатов и рефлексии, но в CLI ее нет.
Кого "её"?
C>Опять же _тебе_ они нафиг не упали, а вот мне они очень даже нужны.
Воспользуешся классом, если что. В нормальном языке разнины ты не заметишь.
>> Если что их не трудо >> будет оформить в виде класса. Если конечно компилятор полноценный. C>Оформите quadchar (32-битный символ) в виде класса на C#, пожалуйста.
Зачем? Проще и разумнее строку. Только опять же смысла нет. С поддержкой юникода и так все ОК.
C>Чтобы с ним работать было не хуже чем с обычным char'ом, JIT его понимал C>и использовал оптимизации типа SSE2/AltiVec и т.п.
Оптимизации — это проблемы джита. А символы всегда хоаняться в базовых типах. char в дотнете это просто UInt16. Нет проблем использовать вместо него хоть UInt64. Бросто как всегда на фиг не упало. Для возни с юникодом есть соотвествющий API.
>> C>Не надо говорить слова "поддержка ООП", пожалуйста. Это абсолютно >> C>бессмысленная фраза. >> Дык, не говори. Это же твои слова. C>Где я это сказал? Вроде я ничего такого в последнее время не пил...
Ну, ты эта... следи за тем, что говоришь. А говорил ты это выше по теме. Ты же начал обсуждение поддржки ООП ВМ-мами.
>> C>Ну да, а все С-программы тоже совместимы. Я ведь могу экспортировать и >> C>импортировать Сшные функции! >> Попробуй импортировать в Borland C++ 3.1 функцию из библиотеки созданной >> GCC, к примеру. C>В BC3.1 не получится. А вот в Watcom — элементарно.
Неполучится? А что так? А вот между Моно и Дотнетам полная бинарная совместимось. Забавно правда?
Выходит, что у С++ хреново даже в совместимости между собственными компиляторам. О чем тогда говорить на междязыковом и межплатформном уровне?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А что мешает и рассчеты делать на более удобном языке?
Давно я не занимался расчетами, но кажется мне, что ни на одном управляемом языке не хватит скорости для действительно больших расчетов. Даже элементарные проверки на выход за пределы массивов на больших объемах информации будут давать существенный оверхед.
Да и кажется мне, что в C++ есть много возможностей по выжиманию скорости. Хотябы возможность переопределения new/delete, переопределение операторов, expression templates.
VD>Ну, вот и подумай зачем тогда вообще нужен С++ если вполне сравнимую производительность можно полуить на Шарпе или Немерле.
Нужен хотя бы для сопровождения унаследованных проектов.
У Nemerle, несмотря на его достоинства, есть один большой недостаток: привязанность к .NET.
Так что, если смотреть, куда бы сдернуть с C++, то мне больше нравится D или Scala. Только у D с библиотеками хуже, т.к. у Scala, насколько я понимаю, полная интероперабильность с JDK. Да и развивается Scala, уже 2.0 вышла.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Давно я не занимался расчетами, но кажется мне, что ни на одном управляемом языке не хватит скорости для действительно больших расчетов.
Ясно. Фобии.
E>Даже элементарные проверки на выход за пределы массивов на больших объемах информации будут давать существенный оверхед.
В курсе, что во многих случаях компилятор их устраняет. И то что это одна ассемблерная инструция на цикл?
В общем, ясно. Импытываем фобии к управляемому коду и в это время пользуемся одним из самых медленных интерпретаторов в мире.
E>Да и кажется мне, что в C++ есть много возможностей по выжиманию скорости. Хотябы возможность переопределения new/delete, переопределение операторов, expression templates.
VD>>Ну, вот и подумай зачем тогда вообще нужен С++ если вполне сравнимую производительность можно полуить на Шарпе или Немерле.
E>Нужен хотя бы для сопровождения унаследованных проектов.
Рано или поздно ты начнешь писать новый проект. А учитывая, что уже сейчас кучу кода (по твоим словам) пишешь на Руби, у тебя и сейчас много слабо связанных задач.
E>У Nemerle, несмотря на его достоинства, есть один большой недостаток: привязанность к .NET. E>Так что, если смотреть, куда бы сдернуть с C++, то мне больше нравится D или Scala. Только у D с библиотеками хуже, т.к. у Scala, насколько я понимаю, полная интероперабильность с JDK. Да и развивается Scala, уже 2.0 вышла.
Scala тоже очень красивый язык. Если ориентироваться на Яву, то он наверно лучший выбор. Но Ди по-моему — это плохой выбор. Он имеет раяд просчетов и уступок вроде нетипобезопасных инструций. Да и с библиотеками у него явно плохо.
Что до Немелра, то на Моно он работает и вроде как ребята считают поддержку Моно очень важной. Похоже сами (возможно часть) сидят в Линуксе. Другое дело, что Моно пока что сильно уступает по скорости кода.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>И все из-за невозможности в дотнет использовать интегральных констант в качестве параметров генериков. Тогда бы решалась в лет и можно было бы сделать не пенисонометрии ради, а спокойствия за код для.
Да нет же Отсутствие возможности использования скаляров как параметров генериков никоим образом не помешает решить задачу на Nemerle, в котором есть гораздо более развитые средства метапрограммирования. Не надо смотреть на решение задачи под углом C++ — лучше поближе ознакомиться с Nemerle для начала.
Здравствуйте, VladD2, Вы писали:
E>>Даже элементарные проверки на выход за пределы массивов на больших объемах информации будут давать существенный оверхед.
VD>В курсе, что во многих случаях компилятор их устраняет. И то что это одна ассемблерная инструция на цикл?
Сомневаюсь, что компилятор способен убрать эти проверки для векторов и массивов, чья размерность во время компиляции неизвестна. А в большинстве случаев размерности как раз в run-time определяются, и память для них динамически выделяется.
VD>В общем, ясно. Импытываем фобии к управляемому коду и в это время пользуемся одним из самых медленных интерпретаторов в мире.
Так я же Ruby не для числодробительных задач применяю
VD>Scala тоже очень красивый язык. Если ориентироваться на Яву, то он наверно лучший выбор.
Видимо у меня другие понятия о красоте, или еще недостаточно Scala покурил.
VD>Но Ди по-моему — это плохой выбор. Он имеет раяд просчетов и уступок вроде нетипобезопасных инструций. Да и с библиотеками у него явно плохо.
У D есть отличная фишка -- поддержка RAII.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Ну попробуй. И чей формат эта система будет контролировать? XML-ного описания?
Если нам не помогут, то мы тоже никого не пощадим.
