Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Сдаётся мне, что по количеству слов "фобия", "кос[т]ность", "дремучее прошлое"

Про лень забыл.

ГВ> и прочих сугубо идеологомозговедческих артефактов эта тема в ФП скоро выйдет в устойчивые лидеры. Уж по термину "Блаб" — стопудово.

Гена, ты когда сам себе вместо "Спи, Генульчик, спи, родной" говорил "Встать, урод, проснись, скотина"?

Здравствуйте, EvilChild, Вы писали:

EC>Здравствуйте, VladD2, Вы писали:

VD>>Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++.

EC>Это особенно заметно на legacy C++ code — тогда люди делали массу отпимизаций, которые сейчас просто потеряли смысл и просто сбивают с толку компилятор, т.к. информация, что именно должен делать компилятор слишком детализированная и ему негде развернуться.

Его так просто сбить с толку ? в топку !!!

Здравствуйте, VladD2, Вы писали:

VD>CLR — это runtime для Microsoft .Net. Microsoft .Net — это реализация стандарта CLI от Microsoft.
Ага. То есть не CLR, а CLI. Хотя все равно буду путать

VD>Если говорить о CLI, то потенциально, нет.
VD> В прочем там есть и интерпретируемый вариант, но используется он только в тех случаях когда для платформы пока не портирован компилятор в нэйтив-код.
Вот это я и хотел сказать с самого начала


VD>И в очередной раз ошибаешся.
Ну. Что ж тут сделаешь.. Зато всегда найдется тот кто поправит

Здравствуйте, VladD2, Вы писали:

EC>>Ещё потому, что есть прорва legacy code написанного на нём,

VD>Вот это чистейшей воды миф. Практически все API делаются совместимыми с C или одной из VM.

Это суровая реальность, данная как мимнимум мне в ощущениях.

EC>> которую никто в здравом уме просто так не выбросит, а итероперировать с C++ проще всего на C++

VD>В здравом уме люди не стали бы писть сегодня на С++. Но они же это делают? Так что апелляция к здравому уму по меньшей мере неуместна.

О поддержке слышал?

Здравствуйте, IT, Вы писали:

IT>Согласен. Единственная проблема — очень сильно чувствуется узаконенный душок побочных эффектов компиляции некторых других языков.

Ты о триках в духе C++ template metaprogramming говоришь? Если да, то не согласен — где тут побочные эффекты?

Здравствуйте, VladD2, Вы писали:

ie>>>factorial 0 = 1
ie>>>factorial n = n * (factorial (n-1))

VD>К примеру, сможешь объяснить, что будет если убрать одни из скобок?

Ндаа, на скобки я внимания не обратил. Что кстати будет без скобок, рекурсивный вызов во время исполнения?

Здравствуйте, WolfHound, Вы писали:

WH>Те ты считаешь что С++ простой и мощьный?

Разве из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой и мощный"?

Здравствуйте, demi, Вы писали:

D>>>Вот и имеем, то что имеем — монструозный, гипертрофированный, подчас не решающий достойно проблемы, и просто у@ищный (извините) C++
Супер! 36 очков, и это не предел
Вы очень точно выразили основные проблемы программирования (и в частности, программирования на С++).
добавлю еще от себя немного
все существующие языки программирования "плоские". Вот например солюшн: 50 проектов (exe,lib,dll), в каждом по 50 классов, в каждом классе по 50 методов. Плюс глобальные функции и переменные, оставшиеся еще со времен когда проект был на Си. И во всем этом нужно ориентироваться. Плюс еще куча библиотек, API и т.д.
И класс CPoint содержащий два поля X и Y и пару методов, и какой нибудь CApplication в который запихана основная логика приложения — по сути своей равноправные классы. А этого быть не должно. Надо сказать, что и Ди и даже Немерле этой проблемы не решают.
ООП недалеко ушло от Си, просто вместо кучи функций появилась куча классов.
Ди — это лишь попытка что-то сделать, вряд ли на Ди перейдут с С++ (ну если только будет какой-нибудь плагин который позволит встраивать Дишные файлы в С++-ные проекты и компилировать все вместе... тогда может быть энтузиасты часть НОВОГО кода будут писать на Ди)
Здесь нужен КАЧЕСТВЕННО новый подход к дизайну языка, к самой концепции "языка программирования", к средствам разработки.

VladD2 wrote:
> C>Агащаз. Еще надо его добавить в список за-pin'еных объектов. В JVM он
> C>хранится в виде single-linked списка. А это уже overhead.
> Мне плевать на JVM. В дотнете никаких списков нет. Это ровно один бит
> расположенный рядом с битом использованием для пометки объекта как
> посещенного. Так что у тебя проблемы с матчастью.
Тебя послать RTFS? Для GC важно заранее знать где он может встретить
за-pin'еные объекты, так как от этого сильно зависит оптимальность
упаковки кучи. Скажем, в JVM каждый pinned-объект скушает целую страницу
памяти из-за того, что GC использует guard-pages как триггер (это
позволяет сделать аллокатор буквально из двух инструкций). В .NET,
кстати, точно так же.

>> > Никаких контекстов ЖЦ сохранять не нужно.
> C>Нужно.
> ОК. Подверди, плиз свои утверждения. Сразу предупреждаю, чно кивать на
> Яву не надо.
Немного сложно объяснить — нативные функции могут работать даже во время
цикла полной сборки мусора, надежных общих способов остановить натвную
функцию не существует (я уж молчу про целые параллельные нативные
потоки, работающие с объектами в VM).

Поэтому у нативных функций есть два варианта работы с объектами в VM —
через pinned-объекты и с помощью handle'ов. Pinned-объекты очень часто
слишком дороги (поэтому в JNI из JVM они используются обычно только для
доступа к массивам). Так что остаются handle'ы.

Но тогда появляется проблема — нужно синхронизировать доступ GC к данным
в этом треде и доступ нативного мутатора. А тут появляется целая куча
интересных сценариев (рассказать?). Чтобы этого избежать можно просто
использовать мьютекс и не мучаться — но это жуткая потеря
производительности, поэтому в новых JVM используют хитрую схему с
трамплинами и code patching'ом. Поэтому при входе в нативную функцию и
требуются действия по модификации контекста GC.

Кстати, мне подумалось, что именно из-за этого MS и не сделала
нормальный аналог JNI.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, VladD2, Вы писали:

I>

ie>>>>factorial 0 = 1
ie>>>>factorial n = n * (factorial (n-1))
I>

VD>>К примеру, сможешь объяснить, что будет если убрать одни из скобок?

I>Ндаа, на скобки я внимания не обратил. Что кстати будет без скобок, рекурсивный вызов во время исполнения?

Без внутренних? Будет возвращать 1 для нуля и надолго задумываться в противном случае. Что за ряд он там будет пытаться считать — можно отправить в качестве вопроса в этюды

Здравствуйте, VladD2, Вы писали:

VD>Думаю, твой профайлер показывал не время именно интеропа, а время проведенное вне управляемого кода.

На прокси стабы указывал.

Здравствуйте, EvilChild, Вы писали:

ie>>на Haskell так:
ie>>

ie>>factorial 0 = 1
ie>>factorial n = n * (factorial (n-1))
ie>>

EC>Этот вариант всех рвёт по компактности и изяществу.

Жаль что он некорректный.

Что до изящиства, но мне кажется, две пары совершенно лишних скобок вряд ли можно назвать изяществом.

Здравствуйте, igna, Вы писали:
I>Разве из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой и мощный"?
совершенно верно. Из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой или мощный".

Здравствуйте, Mirrorer, Вы писали:

VD>>Если говорить о CLI, то потенциально, нет.
VD>> В прочем там есть и интерпретируемый вариант, но используется он только в тех случаях когда для платформы пока не портирован компилятор в нэйтив-код.
M>Вот это я и хотел сказать с самого начала

И все же твои аргументы весма сомнительны. Ведь интерпретатор можно сделать и для ассемблеара. Нельзя же на этом основании делать какие-то выводы о производительности в общем?

Здравствуйте, EvilChild, Вы писали:

EC>Это суровая реальность, данная как мимнимум мне в ощущениях.

А, ну, так бы сразу и сказал. Понятно, что там если В.Пупкин или И.И.Иванов не являются определяющими общее положение вещей, но ты другое дело.

VD>>В здравом уме люди не стали бы писть сегодня на С++. Но они же это делают? Так что апелляция к здравому уму по меньшей мере неуместна.

EC>О поддержке слышал?

Слышал. Какое поддержка имеет отношение к тому, что постоянно появляются новые проекты на С++?

Здравствуйте, igna, Вы писали:

I>

ie>>>>factorial 0 = 1
ie>>>>factorial n = n * (factorial (n-1))
I>

VD>>К примеру, сможешь объяснить, что будет если убрать одни из скобок?

I>Ндаа, на скобки я внимания не обратил. Что кстати будет без скобок, рекурсивный вызов во время исполнения?

Проблема в том, что это могут с уверенностью сказать только продвинутые Хаскелисты. Лично я знаю только одно — Хаскель очень агрессивно использует композицию фукнций и по умолчанию он все рассматривает как композицию однопараметровых функйи. Так что казалось бы невинная запись "factorial n — 1" может превратиться в черт знает что. Причем в иногда это будет давать тот же результат как ты можешь интуитивно предполжить, а иногда получается такое, что ты даже выполнив код не сможешь понять, что же произошло.

В отличии от Хаскеля, Nemerle имеет семантику близкую к С++, что приводик к тому, что для большинства C++/C#/Java-программистов воспринимают его совершенно интуитивно (конечно после того как они изучают расширенные констркции вроде паттерн-матчинга).

Что до многословности, то Nemerle поддерживает Python-оборазный синтаксис, так что этот пример можно записать так:

Factorial(n : uint) : ulong
  | 0 => 1
  | _ => n * Factorial(n - 1)

или даже так:

factorial(n)
  | 0 => 1
  | _ => n * Factorial(n - 1)

если использовать локальные фукнции и их вывод типов.
Это уже мало чем отличаетя от Хаскеля (даже короче на одни идентификатор). Но опять таки этот выигрыш эфимерен. Учитывая что большинство программистов имеет C++/C#/Java-образование я считаю скобки предпочтительными.

К тому мы прассматриваем случай когда код обособлен. В программах же фукнции идут одна за другой и скобки позволяют выделять отдельную функцию (ведь в хаскеле отдельные строки все же описывали одну фукнцию). Потом скобки позволяют пользоваться такими элементарными удобствами как перход от по ним в редакторе (хорошем, естественно). Ведь не всегда фукнция видна на странице, и удобно бывает перейти к парной скобке.

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

Так что вопрос "что лучше?" не является примитивным. Возможно в примитивных случаях запись Хаскеля хороша. Но если учесть все "но", то лично я без сомнения отдаю предпочтение подходу Немерла. Хотя и отдаю себе отчет, что тут немало влияет банальная вкусовщина.

Здравствуйте, Cyberax, Вы писали:

[много воды поскипано]

Ссылок нет, на сем закончим эту бесельную беседу. Будут ссыкли — обсудим.

Еще раз повторюсь, что я говорю о конкретной реализации в дотнете. Никакх список там нет. Сборщик мусора просто проверяет биты запинености. Запиненные объекты просто не предвигаются. Это вызывает известные проблемы, но так как обычно запиненность не длится долго, то и серьезных проблем не происходит.

Здравствуйте, VladD2, Вы писали:

VD>Слышал. Какое поддержка имеет отношение к тому, что постоянно появляются новые проекты на С++?

При чём здесь новые проекты? Речь шла о том, что часто пишут на C++ потому как необходимо поддерживать существующий код.

VD>Жаль что он некорректный.
После исправления ошибки он свои эстетические свойства не потеряет.

VD>Что до изящиства, но мне кажется, две пары совершенно лишних скобок вряд ли можно назвать изяществом.
Дело вкуса.

Здравствуйте, IT, Вы писали:

IT>Согласен. Единственная проблема — очень сильно чувствуется узаконенный душок побочных эффектов компиляции некторых других языков.

Это ты о чем?