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

VD>Что же до любьви к прекрасному... то очень советю покурить Nemerle.

"И тут Остапа понесло"

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

А>>А если уже написаны тонны кода, то никто в здравом уме просто так язык не сменит.

VD>А как же тогда люди на С++ то перешли?

На нем более чем 10 лет тому назад как начали

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

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

Но такой вариант — это на самом деле и не вариант даже...

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

VD>>3. Есть языки более мощьные и удобные нежели С++ и D, но это уже не поймут ни С++-, ни D-и программисты в следствии все того же парадокса Блаба.

D>С подобным парадокcом неоднократно сталкивался, в том числе и сам
D>Дайте примеры по 3-ему пункту плиз.

Неужели — это до сих пор нужно делать на этом форуме?

Пожалуйста! Их есть у меня (с).
http://rsdn.ru/summary/3766.xml
http://rsdn.ru/article/philosophy/Scala.xml

Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.

Языки чем-то похожие на D, но превосходящие его на голову.
Кстати, ты тут приводил пример факториала времени компиляции. Вот как примерно это будет выглядеть на Nemerle:

macro CompileTimeFactorial(n : uint)
{
    def res = Util.Factorial(n);
    <[ $(res : ulong) ]>
}

module Util
{
  // 
    Factorial(n : uint) : ulong
    {
        | 0 | 1 => 1
        | _     => n * Factorial(n - 1)
    }
}

То есть это просто одинарный код только вызванный в макросе. А в прикладном коде он будет выглядеть как вызов фукнции:

WriteLine(CompileTimeFactorial(10));

и факториалы это просто детские шалости. Макросы это прямая и эффективная реализация метапрограммирования.

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

A>Тогда загляни в википедию. Кстати, выше по ветке я уже писал и про Eiffel и про CLOS.

Мне казалось здесь идет речь о статически типизируемых компилируемых языках. CLOS это вообще бибилотека макросов, Прел — скрипт.
К тому же список все равно мизерный. И все языки довольно старые.
Кстати, ты прочел эту статью до конца? Там в конце пимечательный раздел есть:

Debate
There is debate as to whether multiple inheritance can be implemented simply and without ambiguity. It is often criticized for increased complexity and ambiguity, as well as versioning and maintenance problems it can cause (often summarized as the diamond problem).[1] Detractors also point out that multiple inheritance implementation problems such as not being able to explicitly inherit from multiple classes and the order of inheritance changing class semantics. There are languages that address all technical issues of multiple inheritance, but the main debate remains whether implementing and using multiple inheritance is easier than using single inheritance and software design patterns.

Так вот на сегодня почти единодушный ответ дизайнеров ЯП заключается в испльзовании еденичного наследования и миксинов/трэйтсов.

VD>>Как раз С++ показал, что множественное наследование (МН) — это не верный путь развития.

A>Мне он ничего такого не показал

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

VD>>Единственное разумное его применение — это подключение реализации интерфейсов.

A>А что-нибудь про policy-based design ты слышал? Это так, к примеру.

О. Конечно. И не раз. Даже сам использовал до 2000-ного года. Это паттерн применяемый в одном ЯП. Он без проблем эмулируется в других языках (с помощью, миксинов, макросов или вовсе паттернов проектирования). И практически не нужен на практике так как есть более достойные решения.

VD>>Но, к сожалению, МН создает ряд проблем вроде брилиантового наследования, которые очень неприятны.

A>Противники множественного наследования обычно говорят именно в таком ключе "ряд проблем вроде бриллиантового наследования". Никто не хочет этот ряд продолжать

А зачем? Неоднозначность это уже огромная проблема. Это те грабли которые бьют по голове в самый неподходящий момент.

И это при том, что другие подходы решают проблемы решаемые МН не создавая неоднозначностей.

Понимаешь, то так просто — есть два решения. Одно решает нужные проблемы, но создает другие, а второе решает те еж проблемы, но не создает нвоых. Выбор для разумного человека очевиден... если бы не эффект Блаба.

Вот эта тема прекрасно показывает что такое Блаб. Тут на Ди наговорили с три корабоа. И макросов у него нет, и видите ли, МН ему не хватает, и еще много чего. Меж тем это всего лишь некомпетентный взгляд на проблему. Для тех кто не пытался разобраться в Ди — это всего лишь некий странный С++ в котором много странных и не нужных фич (я же без них обхожусь!) и отсуствие давно привычных возможностей. Причем сразу же начинается защита собственной позиции. Даже намека нет на объективный анализ.

Меж тем действительно слабые стороны Ди даже не обсуждались. И оно не мудренно. Ведь ни противники, ни сторонники Ди не знают даже о существовании других подходов. Обсуждение ограничено рамками С++. А это очень узкие рамки.

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

VD>>А как же тогда люди на С++ то перешли?

B>На нем более чем 10 лет тому назад как начали

Ошибашся. Уже более двадцати.

B>А вообще — это реальная проблема, как перейти на новые технологии,
B>если уже

+1

B>есть серьезный багаж, который просто так не выкинуть.

Дело не в багаже. Дело в косности, привычках, лени и ... В общем, вот тут все описано:
http://rsdn.ru/Forum/Message.aspx?mid=2346697&only=1

Автор: Lazy Cjow Rhrr
Дата: 12.02.07

http://rsdn.ru/Forum/Message.aspx?mid=2229002&only=1

Автор: VladD2
Дата: 23.11.06

B>Ну кардинальный вариант понятен.
B>Всех "старичков", кроме парочки, нафиг увольняем.
B>Вместо них нанимаем молодых и энергичных, разбирающихся во всем новом.
B>Оставшихся "старичков" нагружаем исключительно суппортом старой версии,
B>а всех новых и прогрессивных сажаем писать новую с нуля версию,
B>где будет все просто замечательно.

Проблема в том, что старички становятся начальниками. Так что как раз они и будут "набирать".

B>Но такой вариант — это на самом деле и не вариант даже...

Ага. Это утопия.

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

A>"И тут Остапа понесло"

Можно спросить уважаемого Остпа, что он такого ел с утра, что его с этого понесло?

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

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

VD>>>3. Есть языки более мощьные и удобные нежели С++ и D, но это уже не поймут ни С++-, ни D-и программисты в следствии все того же парадокса Блаба.

D>>С подобным парадокcом неоднократно сталкивался, в том числе и сам
D>>Дайте примеры по 3-ему пункту плиз.

VD>Неужели — это до сих пор нужно делать на этом форуме?

VD>Пожалуйста! Их есть у меня (с).
VD>http://rsdn.ru/summary/3766.xml
VD>http://rsdn.ru/article/philosophy/Scala.xml

Автор(ы): Martin Odersky, Philippe Altherr, Vincent Cremet, Burak Emir, Sebastian Maneth, Stephane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Matthias Zenger, http://scala.epfl.ch
Дата: 22.05.2005
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.

VD>Языки чем-то похожие на D, но превосходящие его на голову.
VD>Кстати, ты тут приводил пример факториала времени компиляции. Вот как примерно это будет выглядеть на Nemerle:

Читал про nemerle немного. Выбивает интерес сразу то, что язык работает через .NET CLI (как и любую другую VM)
Субъективно конечно — но синтаксис мне не понравился, как-то скептически отношусь к добавлению функционала через всяческие синтаксические причуды (закорючки и пр.)

Вы отчаянный Nemerle-ист!
А я C++ шник, все же. Но нужно ведь постоянно что-то улучшать, адаптироваться и развиваться. За 9 лет со времен принятия первого стандарта С++ многое изменилось, для IT индустрии такой срок — целая вечность.
Эх.. раз уж теперь эта ветка о философии.

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

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

VD>>>А как же тогда люди на С++ то перешли?

B>>На нем более чем 10 лет тому назад как начали

VD>Ошибашся. Уже более двадцати.

Я имел ввиду исключительно тот проект, на котором сейчас сижу.

T>>Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.
D>В языке C++ его же идиому RAI сложно использовать

чем же её сложно использовать?
кроме того, о незакрытых файлах и неразлоченых мьютексах тоже сборщик мусора позоботиться? RAII ведь не только про память.

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

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?
D>Разве мы не заслужили

А от нас что-то зависит? Оно то может и пора, но пока непонятно, за счет чего может осуществится такой переход. Финансовых магнатов за этим языком не наблюдается. Весомых козырей тоже нет. Удобство при проектировании и разработке в общем-то фоска, так как проще обходить старые грабли, чем решать с нуля нетривиальное бизнес-требование, такое как GUI, кроссплатворменность, работа с БД, работа с COM, распределенное приложение, и т. д. Для примера, насколько просто написать на D элементарное приложение с использованием, например, библиотеки wxWidgets? Что-то мне кажется, что на этом пути можно встретить очень много проблем, начиная прямо от макросов DECLARE_CCLASS, IMPLEMENT_CCLASS, BEGIN_EVENT_TABLE. Думаю, что тривиальным фасадом тут обойтись будет проблематично.А как дела обстоят с использованием STL? Остается надежда на энтузиастов, большей частью студентов, которым еще предстоит создать средства для этого. Но... что-то мне кажется, что сейчас студенты больше интересуются не тем, чтобы самому реализовывать свою можель велосипедае (иногда более совершенную, иногда менее), а тем, чтобы осваивать коммерчески успешные продукты, которые впоследтвие предоставят им возможность заработать больше денег.

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

VD>>2 Хитрик Денис: [skipped]
A>Надо думать, на тебя запрет на открытую переписку о модерировании не распространяется?

Интересно, а история слыхала случаи о отправке модератора в бан?

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

D>Читал про nemerle немного.

Надо было не немного. Именно из-за немного срабатывает парадокс Блаба.

D> Выбивает интерес сразу то, что язык работает через .NET CLI (как и любую другую VM)

И что? VM — весьма условная штука. На самом деле всё так же компилится в native-код и выполняется достаточно быстро.

D>Субъективно конечно — но синтаксис мне не понравился, как-то скептически отношусь к добавлению функционала через всяческие синтаксические причуды (закорючки и пр.)

Какие именно закорючки не понравились? Чем вообще синтаксис плох?

VladD2 wrote:
> GC в D применяется очень слабенький. Причина тому наличие указателей
> (как в С++) и невозможность по этому поводу переупорядочивать объкты в
> памяти.
Не совсем так — там просто никто особо и не заботился о точном GC. Сам
язык, в общем и целом, позволяет использовать точный GC, но есть
несколько вещей, которые его запрещают (типа объединений в стиле С).

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

VD>Кстати, ты тут приводил пример факториала времени компиляции. Вот как примерно это будет выглядеть на Nemerle:
VD>

VD>macro CompileTimeFactorial(n : uint)
VD>{
VD>    def res = Util.Factorial(n);
VD>    <[ $(res : ulong) ]>
VD>}

VD>module Util
VD>{
VD>  // 
VD>    Factorial(n : uint) : ulong
VD>    {
VD>        | 0 | 1 => 1
VD>        | _     => n * Factorial(n - 1)
VD>    }
VD>}
VD>

И это простой и понятный пример? Множество скобок и др. символов лично для меня не вполне читабельны. Все программы на Немерле так выглядят?

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

D>Долой прошлое, господа!
D>Хватит уже ходить по граблям обратной совместимости с другими граблями.

D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ?
D>Разве мы не заслужили

Предлагаю устроить новый флейм "D vs Oberon".

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

N>И это простой и понятный пример? Множество скобок и др. символов лично для меня не вполне читабельны. Все программы на Немерле так выглядят?

В C/C++ тоже множество непонятных скобок, в том числе фигурных, символов ('>>', '%', '!=') и т.д. Для меня вот C/C++ нечитабельным выглядит. Не то, что Scheme! Там вообще только один вид скобок — круглые. Тот же факториал записывается легко и доступно, с использованием совершенно читабельного синтаксиса.

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

D>Генератор примеров :
D>http://www.digitalmars.com/d/comparison.html

D>

D>template factorial(int n : 1)
D>{
D>    enum { factorial = 1 }
D>}

D>template factorial(int n)
D>{
D>    enum { factorial = n* factorial!(n-1) }
D>}

D>void test()
D>{
D>    writefln("%s", factorial!(4));    // prints 24
D>}
D>

И где тут шаблоны и чем они лучше?

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

T>Я предлагаю вам привести какой-нибудь простой и ясный пример. Вот задача. Вот так она криво и плохо решается (или вообще не решается на C++). А вот так она красиво и грамотно решается на D. И сразу всё станет ясно и убедительно.

Advanced D Programming Language Features (by Walter Bright) -- там этих примеров достаточно. К тому же ничего не сказано о начавшихся работах по добавлению в язык compile-time вычислений.

Что касается перспектив замены C++ на D, то сейчас они весьма призначны. Но не из-за качеств самого языка, а из-за сопутствующей инфраструктуры -- документации, книг и учебных курсов, библиотек, инструментов и пр.

Однако время для того, чтобы сейчас пробовать D в мелких proof-of-concept проектах вместо C++, уже пришло. ИМХО.

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

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

VD>Проблема в том, что старички становятся начальниками. Так что как раз они и будут "набирать".

Не у всех ведь мозг превратился в кость. Человек разумный — способен разумно выбирать. Без фанатизма.

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

T>Я забыл как там у Страуструпа "C++ is my favorite garbage collection language, because it produces no garbage" или как-то так.

It produces memory leaks which is the same but worse.