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

J>Дело не в том ... rand() — это просто пример недетерминированной функции. Другим примером может быть предположение о наличии какого-то файла на диске,

И в чем проблема? Ну, скажет тебе компилятор "Нет нужного мне файла. Ивини комрад!", и что?

J>какие-то тонкие предположения о наличии у пользователя каких то-прав в системе, наличие интернета в момент компиляции, да мало ли еще что.

Опять же или компилятор ругнется и подскажет что делать, или ты имеешь пример плохого кода. Ты же не страдаешь от того, что бюбая библиотека или любой код может быть плохим и приводить к проблеме?

J>Т.е. возникает неявная (!) возможность того, что компилируемость кода зависит от внешних факторов никак не отраженных в исходнике (напр. если происходит вызов внешней либы).

Дык ты уже так или иноче от этого зависишь. Ты же не компилируешь (надеюсь) исходники из командной строки? Ты ведь скорее всего пользуешся неким build-engine-ом? А он и есть внешнаяя утилита без которой проект не собрать. А разные Ant-ы и MSBuild-ы к тому же расширяются именно что библоиотеками.

J>Вот еще подумалось — если такие языки распространятся, то скачав безобидный исходник из сети и поставив его на компиляцию, я могу стать жертвой
J>очень хитрого вируса. Нет, в самом коде не будет "format c:", но какой-то хитрый макрос будет вызывать какую-то стандартную либу и использовать дыры в ней. Да мало ли ужастей можно придумать?

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

J>Я понимаю, что это все может показаться надуманным,

Ага. Именно этим и кажется.

J>но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек

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

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

VD>>http://en.wikipedia.org/wiki/Diamond_problem

M>Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?

Это где же такое написанно?

M>Или что то путаю , или миксины создают различную имплементацию много раз ?

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

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

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

J>Знал бы почему — обосновал бы . В принципе, я понял твою точку зрения. К тому же выше fmiracle & WolfHound также привели достаточно весомые аргументы. Теперь надо бы подумать над этим

Хороший подход.

J>В общем-то суть в том, что у меня никогда не возникало необходимости звать что-то недетерминированное в рантайме. Даже кодогенерация зависит только от своих параметров (заготовка-описание, код на DSL итп), те детерминированна.

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

Однако на уровне реализации тебе все равно может понадобится некий не дерерминрованный код. Хотя бы ради быстродействия. Ведь недетерминированность и наличие побочных эффектов не совсем одно и то же. Например, быстрая сортировка массива совершенно детерминированная функция, но в процессе работы она меняет исходный массив. К тому же ее детерминированность зависит от фукнций сравнения. Если они будут кривыми, то и разультат будет не поределенным.

J> Когда же мне сказали, что можно звать абсолютно все, я немного испугался. Теперь успокоился и понял, что это просто инструмент — такой же как и другие, обычный. Бъет по лбу (программиста сразу или юзера — через месяц), если что-то напортачил.

Естественно. И инструмент мощьный. А мощь конечно можно и во благ, и во вред использовать. Можно каталоги рекурсивно грохать в корнях дисков , а можно автоматом генерировать файлы для перевода программы на другой разговорный язык.

J>Короче, compile-time code execution — это просто возможность писать все на одном языке, не привлекая скрипты и внешние тулзы для кодогенерации.

Именно. Но это только одна сторона. Ведь данный подход к тому же существенно упрощает создание метапрограмм. У него есть возможности контроллированной генерации коад и возможности анализировать код прогаммы и даже производить его декомпозицию. В купе это дает офигительно мощьное решение повзоляющее иногда писать мета-код проще чем писать прикладной код на С++.

J> Ничего сверхъестественного.

Так и есть. Хотя конечно если не изучить как это устроено, то выглядит магией. А некоторые вообще по началу не верят, что такое возможно.

J>ИМХО, кроме всех очевидных плюсов, здесь есть минус — хитрый метакод запрятан в исходниках и внешне (в файл-менеджере) неотличим от "обычного" кода. Эта проблема решается, видимо, только тщательным документированием ...

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

И на самом деле это еще только поверхностный взгляд. Рельно макросы могут менять синтаксис языка (страшно? ), стркуткуру программы и многое другое! Они даже могут парсить текстовые строки в компайлатайме. Например, для вывода в строку в Nemerle исползуется стандратный макрос которые овзоляет использовать похожую на php/Ruby — квази-строки:
def x = 1;

WriteLine($"x = $x; x + 2 = $(x + 2)");

этот код выведет:

x = 1; x + 2 = 3

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

Здравствуйте, Слоноежик, Вы писали:

С>>И что из этого. Правильное решение. D как впрочем и CLI не может гарантировать отсутсвие побочных эффектов. Сомневаюсь — что кому нибудь понравится функция которая вычисляет правильное значение только по чертвергам в полнолуние.
С>Досадный Глюк. естественно не CLI а CLR

Ага. Это досадный глюк присуствует даже в машине Тьюринга.

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

D>Windows — это очень узкий круг вычислительных устройств.

Я даже осмелюсь сделать более громкое заявление! Windows — вообще не вычислительное устройство, а семейство операционных систем! Во как значичь.

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

D>Т.е. у нас есть Windows и кусочек Linux, это хорошо.

Не совсем. У нас есть дотне и Моно. Моно — это эдакий не очень хороший (более медленный) дотент в котром меньше библиотек, но который переносим почти как же как С, так как его исходники это процента на 3 С-код, а остальное написано на C#.

Так что можно сказать, что у нас есть Windows, Linux и даже МакОС, но Windows немного ровнее.

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

ДГ>>Хм. Означает ли это, что вне пределов .NET для Nemerle нет никакой перспективы?

ie>На текущий момент — да.

Уточню. Не .NET, а на реализациях CLI (Comon Language Runtime). К коим относится и Моно.

ie>Теоритически не исключена возможность прикручивания других бэкендов.

+1 Но это не малая работа, так как кроме кодогенератора нужно реализовать еще и рантайм-сервисы вроде GC и рефлексии.

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

ДГ>>3. Поддержка со стороны IDE, кроме VS + твоей интеграции?

K>MonoDevelop — кроссплатформенно.

Откровенно говоря когда мы взялись за работу над Интекрацией с VS, то поломали тот что было сделано для MonoDevelop, так как там все было очень криво, а эти ребята не сумели абстрагироваться от компилятора. Но сейчас все развянано и можно даже использовать наши наработки для создания следующией версии Интеграции с MonoDevelop.

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

D>Практика программирования уже успела многое сказать о пригодности интерфейса STL

Да я привел STL и wxWidgets в качестве примера библиотек в предположении, что для коммерческого использования потребуется перевод на D аналогичных по сложности библиотек.

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

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

VD>>>http://en.wikipedia.org/wiki/Diamond_problem

M>>Вы же прочли что эта проблема решена в С++ ? на тоже вики странице ?

VD>Это где же такое написанно?

C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" ("class B : virtual A"), C++ takes special care to only create one A object, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A.


M>>Или что то путаю , или миксины создают различную имплементацию много раз ?

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

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

Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

M>Попробую еще раз на пальцах , при использовании миксинов , код компилируется и линкуется Многократно, виртуальное же наследование лишено этих недостатков.

Описался , имел ввиду наследование в общем.

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


VD>Открыты, в смысле имеют ОпенСорс-реализацию, пока только #GTK и MS Forms (в Моно). Причем MS Forms реализована не полностью. Есть планы по реализации (в Моно) WPF.

Похоже на то, что WPF будет реализовать на порядок проще для любых платформ, чем Windows.Forms (или даже на несколько порядков проще и переносимей)

VladD2 wrote:
> D>И даже не CRM система для нового склада памперсов...
> Небольшая справка. "Софт для АЭС" — это такой прикло который постоянно
> всплывает как последний аргумент против управляемых сред. В общем, "Софт
> для АЭС" стал таким примера притянутого за уши аргумента.
Кстати, будешь смеяться, но мой софт скоро будет использоваться на АЭС
(Indian Point Energy Center) для учета персонала

Прямо жаль, что я его писал на Java, а не на С++. А то бы можно было бы
начать флейм "Только С++ пригоден для использования на АЭС". Эххх...

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

ie>>Не знаю. Но C# программеры в моем окружении относятся к Немерле скорее положительно, а C++ наоборот

VD>Дык это понятно. Если для C#-программиста Nemerle — это логическое развитие с небольшим количеством изменений, то для С++программиста — это крушения образа мысли. Сам переживал подобное пару раз и знаю насколько это тяжело переносить.

VD>Реакция обычно следующая. Сначала полное не понимание и безразличие. Потом страх и животная неприязнь. Потом разбитое состояние, ощущения расстерянности вызванное тем, что человек начинает понимать, что знакомые идеомы, навыки и т.п. все-все-все — это много лет не лучшим образом проведенной жизни. Далее есть варианты. Сильный человек оценивает достоинства и недостатки и выбирает более мощьный и простой язык, а мнее сильный обычно просто говорит себе — ну и хрен с ним — и поглубже зарывает голову в песок.

А умный — осознает, что смысл жизни далек от всего этого. Бугага.

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

VD>Я бы сказал, что байт-код тоже не существеннен. В итоге ведь все равно имеем нэйтив-код.
Ну да, я имел ввиду что на после компиляции имеет байт код. А JIT это уже часть рантайма. Чисто гипотетически можно обойтись и без него. Правда о скорости в таком случае можно забыть

VD>А вот что их действительно отличает — это наличиеразвитого рантайма. Это значит наличие GC, рефлексии, динамической компиляци, защиты. Вот только в моем разуме это все приемущества, а не недостатки.
Веришь, в моем тоже Хотя конечно все от задач зависит. Но задач, которым нужен с++ с его возожностью ручного управления памятью я вижу все меньше и меньше...

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

D>>Карты сообщений, откуда все это пошло.. отсутствие средств языка, таких как делегаты например.

T>А что вы предлагаете для программирования COM-серверов и ActiveX на D вместо ATL? Вы хоть раз пробовали делать это без ATL? Или всё, про COM дружно забываем?

Я в свое время делал это на Delphi. И никак не мог понять почему COM программирование считается большим анусом... Потом прочитал книгу Inside COM, посмотрел на реализацию простейшего СОМ сервера на С++. Как бы это помягче выразится.. Впечатления были очень протеворечивые..

Я не говорю что Delphi панацея.(Тем более что Делфи при смерти уже..) Но в нем программист был избавлен от туевой хучи ручной работы. Что меня несказанно радовало.

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

C>Кстати, будешь смеяться, но мой софт скоро будет использоваться на АЭС

C>А то бы можно было бы начать флейм "Только С++ пригоден для использования на АЭС". Эххх...

А меня 3 года назад сватали разработчиком С++ на Запорожскую АЭС.
Причем что плюсы я не знал тогда не знаю и сейчас
Плюсы там используются в системе контроля. То бишь датчики там разные, с них снимается информация и при превышении допустимого уровня звучит алярма. А для отладки и разработки используется эмулятор атомной станции писанный то ли в Беркли то ли еще где. И тоже писан на плюсах. Такие дела...

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

M>Я не говорю что Delphi панацея.(Тем более что Делфи при смерти уже..) Но в нем программист был избавлен от туевой хучи ручной работы. Что меня несказанно радовало.

Да не, ты чего , какое при смерти — Delphi for PHP ещё всем покажет

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

VD>Реакция обычно следующая. Сначала полное не понимание и безразличие. Потом страх и животная неприязнь. Потом разбитое состояние, ощущения расстерянности вызванное тем, что человек начинает понимать, что знакомые идеомы, навыки и т.п. все-все-все — это много лет не лучшим образом проведенной жизни. Далее есть варианты. Сильный человек оценивает достоинства и недостатки и выбирает более мощьный и простой язык, а мнее сильный обычно просто говорит себе — ну и хрен с ним — и поглубже зарывает голову в песок.

Ээээ C++ ?

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

M>Я не говорю что Delphi панацея.(Тем более что Делфи при смерти уже..) Но в нем программист был избавлен от туевой хучи ручной работы. Что меня несказанно радовало.

Вот и я боюсь, что на D работа с COM выродится во что-нибудь VCL-образное. VCL существенно ограничивает (мои) возможности, COM-сервера получаются как правило громадными и неоптимальными, а написать Full ActiveX или DCOM-службу на нём вообще нереально, проще уж на чистом API. В общем, месяцы, проведённые на билдере, я вспоминаю как кошмар. ATL — просто чудо по сравнению с этим.