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

E>>Более того, глядя на свой C++ный код я понимаю, что на D он может быть портирован, а вот на другие языки (в первую очередь, Scala) -- только переписан.

VD>А смысл портировать код? Он приципиально не изменится. С точки зрения поддержки все останется так же. Убьешь кучу времени и все. О том и речь.

В моем понимании портирование от переписывания отличается тем, что для получения работающей реализации на новом языке вовсе не требуется убивания кучи времени. А вот смысл может оказаться в том, что более простой и удобный в использовании язык (каким выглядит D по сравнению с C++) позволит:
a) проще решать кадровую проблему при найме новых специалистов;
b) снизить затраты на разработку нового кода на основе уже существующих наработок.

Я знаю примеры систем, которые переписывались с Фортрана на C/C++ и тем самым получали вторую жизнь. Были даже системы, которые переписывались с Эльбрусовского автокода на C/C++ и начинали жить заново. Так там было действительно переписывание. По сравнению с ними плавный переход с C++ на D -- это вообще легкий променад.

VD>Интересно. Но боюсь, что он блаб в этой области. То есть он понимает, что что-то такое нужно, но вот как оно должно выглядеть он не знает. По крайней меере идей по декомпозиции я пока не вижу. А это будет решающим. Работать просто с АСТ практически невозоможно. Это черезвычайно сложно. Так что у него два варианта. Сделать макросы крайне ограниченными (например, только для генерации нового кода, но не для декомпозции), все же ввести в язык нечто более мощьное чем if/switch.

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

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

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

E>Я знаю примеры систем, которые переписывались с Фортрана на C/C++ и тем самым получали вторую жизнь. Были даже системы, которые переписывались с Эльбрусовского автокода на C/C++ и начинали жить заново. Так там было действительно переписывание.
Ты говоришь о переписывание с убогих недоязычков в полноценный язык.

E>По сравнению с ними плавный переход с C++ на D -- это вообще легкий променад.
А это переписывание с одного полноценного языка на друго. Пусть чуть болие удобный. Но лишь чуть. И это не даст скольнибудь заметных преимуществ.

E>Ты можешь производить впечатление офигенного супер-пупер-профи и знатока во всех областях программирвания, и в области макросостроения в первую очередь. Более того, невозможно запретить тебе так думать про тебя самого.
Знаешь чем Влад отличается от автора D? Тем что Влад уже написал собственную систему метапрограммирования и прошолся по всем граблям, а автор D еще нет.
И главная проблема в R# это ужасно сложная работа с AST. Именно по этому проект и заглох.
А на немерле макросы живут по тому что там работать с AST очень просто.
Соотвественно если автор D не предусмотрит удобную работу с AST то из этой затеи ничего не выдет.

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

E>В моем понимании портирование от переписывания отличается тем, что для получения работающей реализации на новом языке вовсе не требуется убивания кучи времени. А вот смысл может оказаться в том, что более простой и удобный в использовании язык (каким выглядит D по сравнению с C++) позволит:
E>a) проще решать кадровую проблему при найме новых специалистов;
E>b) снизить затраты на разработку нового кода на основе уже существующих наработок.

С кадрами — это мечты. Ты сейчас С++-ника найдешь влет, а вот знание Ди — экзотика. Но не о том речь.
Пиши себе новый код на Ди. Кто же мешает то? Зачем при этом старый портировать?

E>Я знаю примеры систем, которые переписывались с Фортрана на C/C++ и тем самым получали вторую жизнь.

Идиоты, что взять? Фортрановские модули можно подлиновывать к С/С++-проектам.

E> Были даже системы, которые переписывались с Эльбрусовского автокода на C/C++ и начинали жить заново.

Вот в этом смысл несоменно есть.

E> Так там было действительно переписывание. По сравнению с ними плавный переход с C++ на D -- это вообще легкий променад.

Не сказал бы. Автоматического конвертера нет и быть не может. Это будет по любому трах. Причем не ясно зачем.
Ладно, закрываем тему. Считашь и ладно.

E>Ты можешь производить впечатление офигенного супер-пупер-профи и знатока во всех областях программирвания, и в области макросостроения в первую очередь. Более того, невозможно запретить тебе так думать про тебя самого.

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

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

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

ЗЫ

Кстати, на вопрос (о том планируется ли как-то решать проблему декомпозиции кода) ты так и не ответл.

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

VD>С кадрами — это мечты. Ты сейчас С++-ника найдешь влет, а вот знание Ди — экзотика. Но не о том речь.

И об этом то же. У нас сейчас толкового C++ника найти уже не реально. Научить студента C++у -- одного года мало, проверено. Как более простой язык D дает надежду, что в течении года факультативных занятий студента 5-го курса можно научить прилично владеть языком программирования и после окончания ВУЗа придти на работу и писать нормальный код, который не будет нуждаться в еженедельном обязательном Code Review.

VD>Пиши себе новый код на Ди. Кто же мешает то? Зачем при этом старый портировать?

Например, чтобы к некоторым нашим системам дописывать новые модули на D, нужно иметь D-шные версии ряда библиотек. В первую очередь ObjESSty и SObjectizer. Вот эти библиотеки можно портировать, а не переписывать заново, как в случае со Scala, к примеру.

E>>Ты можешь производить впечатление офигенного супер-пупер-профи и знатока во всех областях программирвания, и в области макросостроения в первую очередь. Более того, невозможно запретить тебе так думать про тебя самого.

VD>Забавно. Сразу пошел переход на личности и оскорбления. Надо принимать меры чтобы повадно небыло.

Твое право, хрен отнимешь.

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

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

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

VD>ЗЫ

VD>Кстати, на вопрос (о том планируется ли как-то решать проблему декомпозиции кода) ты так и не ответл.

Не ответил, поскольку пока не имею этой информации.

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

E>И об этом то же. У нас сейчас толкового C++ника найти уже не реально. Научить студента C++у -- одного года мало, проверено.
+1

E>Как более простой язык D дает надежду, что в течении года факультативных занятий студента 5-го курса можно научить прилично владеть языком программирования и после окончания ВУЗа придти на работу и писать нормальный код, который не будет нуждаться в еженедельном обязательном Code Review.
А вот это уже смешно. Для этого язык должен быть полностью типобезопасным и с полностью автоматическим управлением памятью. Ну как язык на букву N.

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

E>>Как более простой язык D дает надежду, что в течении года факультативных занятий студента 5-го курса можно научить прилично владеть языком программирования и после окончания ВУЗа придти на работу и писать нормальный код, который не будет нуждаться в еженедельном обязательном Code Review.
WH>А вот это уже смешно. Для этого язык должен быть полностью типобезопасным и с полностью автоматическим управлением памятью. Ну как язык на букву N.

Возможно. Надеюсь, что реальный опыт расставит все на свои места.

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

E>И об этом то же. У нас сейчас толкового C++ника найти уже не реально. Научить студента C++у -- одного года мало, проверено.

Сам Страуступ оценивает этот срок в 1.5-2 года.

E> Как более простой язык D дает надежду, что в течении года факультативных занятий студента 5-го курса можно научить прилично владеть языком программирования и после окончания ВУЗа придти на работу и писать нормальный код, который не будет нуждаться в еженедельном обязательном Code Review.

С чего бы Ди стал более простым в обучении? Количество сущьностей в нем больше. В конце концов в язык впихнули (по-моему, совершенно зря) библиотеки. Так что обучение ни как не будет быстрее.

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

VD>>Пиши себе новый код на Ди. Кто же мешает то? Зачем при этом старый портировать?

E>Например, чтобы к некоторым нашим системам дописывать новые модули на D, нужно иметь D-шные версии ряда библиотек. В первую очередь ObjESSty и SObjectizer. Вот эти библиотеки можно портировать, а не переписывать заново, как в случае со Scala, к примеру.

Создать объвязочные библиотеки несравнимо проще чем все переписать на другом языке. Не находишь? К тому же это проблемы проектирования вашей системы. Если бы вы поддерживали скажем КОМ, то интеграция прошла бы в автоматическом режиме.

E>Безусловно, высказывание твоего мнения -- это твое неотъемлимое право.

Спасибо за понимание.

E> Однако, поскольку ты говоришь о человеке,

Я говорю о том что человек делает, а он лично мне глубого безразличен.

E> которого ты вообще не знаешь,

Что я не знаю? Я вижу результат и вижу куда все развивается. О чем и высказываюсь.

E> не знаешь его целей и тех вариантов, которые он счел неприемлимые -- твое мнение нельзя считать вообще заслуживающим внимания.

Мое мнение это мое мнение. То что ты не считашь его интересным или верным — это всего лишь твое мнение. С моей точки зрения ты никто и звать тебя никак, но я стараюсь не выражаться об этом, а говорить по сути вопроса. Вот такая силяви.

Как верно заметил Вольфхаунд в отличии от тебя, да и автора Ди я лично занимался вопросом встаивания метапрограммирования в ЯП. Другими словами я прошел то о чем рассуждаю. И не просто прошел, а сделал выводы. Ты же не толко не говришь ничего по теме, но и всячески пыташся оскорбить собеседника. Но вот именно это не взывает никакого уважения.

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

E> Попросту говоря -- это словестный понос, который только отнимает мое время в нашем с тобой разговоре. И моя просьба состоит в том, чтобы ты освободил меня от необходимости иметь дело с подобными вещами.

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

E>Не ответил, поскольку пока не имею этой информации.

Тогда к чему весь этот фонтан из дерьма?

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

E>> не знаешь его целей и тех вариантов, которые он счел неприемлимые -- твое мнение нельзя считать вообще заслуживающим внимания.

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

VD>Как верно заметил Вольфхаунд в отличии от тебя, да и автора Ди я лично занимался вопросом встаивания метапрограммирования в ЯП. Другими словами я прошел то о чем рассуждаю. И не просто прошел, а сделал выводы. Ты же не толко не говришь ничего по теме, но и всячески пыташся оскорбить собеседника. Но вот именно это не взывает никакого уважения.

VD>В общем, твое желание переводить обсуждение техничеких проблем в личностные мне не нравится. Предлагаю прекратить этим заниматься.

Извини, я действительно не учел твоего опыта и знаний в области метапрограммировании, полученных во время разработки R#. Без сомнения, твой опыт настолько богат и знания настолько объемны, что ты имеешь право называть незнакомых тебе людей блаб программистами. Действительно, для этого нет никаких препятствий, ведь мудрости "Не судите да не судимы будете" уже, как минимум, две тысячи лет и свою актуальность она давно потеряла. Да и программированию никогда не имела отношения.

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

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

E>Так же я прошу не вступать в разговоры со мной. Поскольку с твоим высоким уровнем знаний и опыта ты не сможешь получить в общении со мной никакой полезной информации.

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

Здравствуйте, Андрей Хропов, Вы писали:

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

АХ>>>Ну хорошо, выражусь по-другому: в системном языке должна быть возможность спуститься на низкий уровень и контролировать каждый бит. Все время это делать не надо, но, скажем, критические части ядра ОС по-другому не напишешь.
WH>>Ну загрузчик по любому нужно писать на асме. Тут даже С не подходит.
АХ>C + inline asm

GCC asm темплейты можно использовать не только в C.

Обёртка для rdtsc :

В файле спецификации :

   function x86Time return Long_Long_Integer;
   pragma Inline (x86Time);

В файле тела :

   function x86Time return Long_Long_Integer is
   begin
      return Time : Long_Long_Integer do
         Asm ("rdtsc", Volatile => True,
             Outputs => Long_Long_Integer'Asm_Output ("=A", Time));
      end return;
   end x86Time;

Результат — в листинге использование x86Time превращается в одну инструкцию.

Если инкапсулировать ненадёжный сам по себе код в надёжные обёртки, получаем
безопасность + низкоуровневость два в одном флаконе по той же цене.

Возможно, в GDC то же можно провернуть.

WH>>А вот то что пишут на С уже можно писать на чемто болие высокоуровневом.
АХ>Можно, но возможность спуститься на низкий уровень должна быть.
+1
Хотя... кому как. Просто фишка в том, что те, кому это надо, и те, кому это не надо,
программировали бы в пределах одного языка.

WH>>>>Все что нужно это value-типы, поддержка двоичных данных на уровне виртуальной машины и оптимизатор который умеет делать region-inference. Еще нужно иметь несколько различных алгоритмов сборщика мусора в том числе подсчет ссылок и вобще отсутствие сборщика мусора (работает только region-inference).
АХ>>>Не согласен.
АХ>>>Помимо этого должна быть возможность вообще не пользоваться сборщиком мусора,
WH>>Перечитай еще раз что я сказал.
АХ>region inference говоришь. И где-нибудь он реализован? Как это на практике работает?
АХ>Он все равно кажется не слишком предсказуемым. Это вроде статического GC как мне кажется или то что иногда называют memory pools.
В разных вариациях встречается в Cyclone и Аде.
В Cyclone это регионы.
Неплохой материал :
Safe and Flexible Memory Management in Cyclone
По их утверждению,

For MediaNet, using unique
and reference-counted pointers increased throughput by
up to 42% compared to relying entirely on conservative
garbage collection.

В Аде же — уровни доступа для типобезопасности и Storage Pools для выделения/освобождения памяти.
Storage Pool, вообще говоря, отвечает не за то, когда освобождать память, а как выделять и как освобождать. Аллокатор. С другой стороны, после своей финализации уничтожает и все объекты внутри себя, этим тоже можно пользоваться. В примере из Стандарта был Mark/Release на Storage Pool.
Обычно всё же стандартного Storage Pool хватает. Уровни доступа же чувствуются постоянно.

Пример альтернативного Storage Pool :
Memory Management with Storage Pools

АХ>>>должен быть встроенный ассемблер (желательно с легко настраиваемым под конкретную архитектуру набором инструкций)
WH>>Только для загрузчика. А для этого проще внешний язычек прикрутить.
АХ>А мне больше нравится встроенный асм, хотя бы потому что можно имена переменных те же использовать.
Да вот именно. Зачем внешний ассемблер?
Extended Asm в gcc — замечательная штука, грех не использовать.

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

V>А можно подробнее про "интерполяцию фактов" применительно к тому, что именно заставит Microsoft заменить свой теперешний флагман C# на немерле.

Ну зачем же обязательно Майкрософт? Вот если Новелл подсуетится, забодяжит Slim Binaries вместо этой каши под названием MSIL bytecode, и невзначай начнёт поддерживать Nemerle, без внимания общественности это не останется.

Главный двигатель эволюции в IT – конкурренция. Если .NET сужать до одного только Майкрософта, конкурренции, конечно, не будет.

Здравствуйте, Андрей Хропов, Вы писали:

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

АХ>>>2) Сам HotSpot отъедает ресурсы.
WH>>По мне так это вобще тупиковая идея.
АХ>А что лучше?


АХ>Порвать статический анализ под конкретную архитектуру (типа Intel C++) вроде теоретически можно только чем-то вроде HotSpotа, который в динамике отслеживает что и где можно заинлайнить и т.п.

Slim Binaries
A Tree-Based Alternative to Java Byte-Codes

In the second part, we introduce the concepts of dynamic runtime optimization and adaptive profiling. In
our system, a dynamic runtime optimizer performs code optimizations continuously, based on runtime
profile data. A background process regularly generates faster program versions that then replace earlier, less
optimal versions. Basing compilation on an adaptive profiler allows the code optimizer to make superior
optimization decisions, improving even the quality of already optimized code on subsequent re-optimization
iterations.

Теоретически нет преград и межпроцедурным оптимизациям тоже.

Очередная весть с полей.

На DSource развивается проект TioPort, целью которого является создание конвертера из Java в D. Сегодня этот проект достиг значимой вехи в своем развитии: опубликован порт SWT на D.

Насколько удобно будет пользоваться этим SWT.d и что из этого получится -- Но сам факт примечателен. Если, как говорит разработчик TioPort, конвертация происходила по большей части автоматически, то это открывает возможность портирования на D из Java и других библиотек. Что должно поспособствовать наполнению D хорошими и разными инструментами/библиотеками/фреймворками.

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

OCT>
OCT>Теоретически нет преград и межпроцедурным оптимизациям тоже.
Как бы тебе сказать... Sun JVM такое уже лет 7 делает. Прочитай про механизм HotSpot.

Ну а Tree-based — это вообще ерунда, способ промежуточного представления байт-кодов особого значения не имеет.

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


E>>Я знаю примеры систем, которые переписывались с Фортрана на C/C++ и тем самым получали вторую жизнь.

VD>Идиоты, что взять? Фортрановские модули можно подлиновывать к С/С++-проектам.

Кстати сишные модули также легко подлинковываются к D-шным. В то же codeblocks (с GDC компилятором) можно в проект добавлять как сишные так и D файлы и все нормально собирается и отладка также прозрачно работает.

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

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

E>>И об этом то же. У нас сейчас толкового C++ника найти уже не реально. Научить студента C++у -- одного года мало, проверено.

VD>Сам Страуступ оценивает этот срок в 1.5-2 года.

E>> Как более простой язык D дает надежду, что в течении года факультативных занятий студента 5-го курса можно научить прилично владеть языком программирования и после окончания ВУЗа придти на работу и писать нормальный код, который не будет нуждаться в еженедельном обязательном Code Review.

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

С того что в нем гораздо меньше исключений из правил, UB, и неодназначностей чем в C++.

VD>Вот писать может быть будет по проще. Хотя указатели на месте. Небезопасноть тоже. Так что мест для граблей достаточно. Так что не факт, что уж так координально проще будет писать.

Реально намного проще писать. Мелочи типа auto, вложенных функций, делегатов уже многие вещи упрощают. Ну и человеческие шаблоны.

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

FR>С того что в нем гораздо меньше исключений из правил, UB, и неодназначностей чем в C++.

Тода надо признать, что D все равно более сложный чем любой типобезопасный язык, так как доупскает массу UB.

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

VD>>Вот писать может быть будет по проще. Хотя указатели на месте. Небезопасноть тоже. Так что мест для граблей достаточно. Так что не факт, что уж так координально проще будет писать.

FR>Реально намного проще писать. Мелочи типа auto, вложенных функций, делегатов уже многие вещи упрощают. Ну и человеческие шаблоны.

Для обучения это все только усложнение.

Что же до описанных тобой приемуществ, то опять повторюсь, что есть языки которые делают все тоже самое значительно лучше и при этом не имеют проблем D. Воти и возникает вопрос для кого этот язык? Для дебилов которые не в состоянии освоить что-то сильно отличное от С++? Ну, так им все эти лмябды по барабану.

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

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

FR>>С того что в нем гораздо меньше исключений из правил, UB, и неодназначностей чем в C++.

VD>Тода надо признать, что D все равно более сложный чем любой типобезопасный язык, так как доупскает массу UB.

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

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

Для обучения тоже.

VD>>>Вот писать может быть будет по проще. Хотя указатели на месте. Небезопасноть тоже. Так что мест для граблей достаточно. Так что не факт, что уж так координально проще будет писать.

FR>>Реально намного проще писать. Мелочи типа auto, вложенных функций, делегатов уже многие вещи упрощают. Ну и человеческие шаблоны.

VD>Для обучения это все только усложнение.

Вряд ли усложнение, все это вместе по моему проще чем объяснить например типы и предназначние конструторов для C++

VD>Что же до описанных тобой приемуществ, то опять повторюсь, что есть языки которые делают все тоже самое значительно лучше и при этом не имеют проблем D. Воти и возникает вопрос для кого этот язык? Для дебилов которые не в состоянии освоить что-то сильно отличное от С++? Ну, так им все эти лмябды по барабану.

Пока язык для достаточно опытных программистов, которые "устали" от C++, но не хотели бы отказыватся от многих его возможностей. Дальше надеюсь что он станет хорошей альтернативой C++ вообще.
Про дебилов ты зря. Я знаю достаточно людей (включая и самого себя) которые в состоянии освоить вещи очень отличные от С++ и майнстрима вообще, но которым нравится и главное комфортно работать именно с С — С++, думаю многим из них и D понравится.

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

FR>С этой стороны да.
FR>Но он позволяет в отличии от C++, реально писать на безопасном подмножестве языка. (Про необходимость ключика для комилятор я уже раньше говорил).

C++ тоже позволят писать на безопасном подмножестве. Вот только обычно это никто не делает. Как показали первые же примеры кода на D тоже никто так делать не будет.

FR>Вряд ли усложнение, все это вместе по моему проще чем объяснить например типы и предназначние конструторов для C++

С++ без паттернов извращенческого программирвания довольно простой ООЯ. Так что как раз изучать его не так сложно. Сложности начинаются при реальной работе когда кроме знания языка нужно еще знать море паттернов для совершенно повседневных и примитивных операций.

Но без них можно жить. Просто вместо одной простой и понятной строки будет куча кода (например цикл для поиска элемента в списке).

Другими словами простота синтаксиса С++ превращаетя в сложноть паттернов. Ну, и в купе с полнешей небезопастностью языка это выливается в горы геморроя.

FR>Пока язык для достаточно опытных программистов, которые "устали" от C++, но не хотели бы отказыватся от многих его возможностей.

У этого языка одна возможнсоть — создавать геморрой людям его использующим. И зачем нужна замена которая уменшает геморрой вместо его полного устранения я лично не понимаю.

Для низкого уровня (возни с битами) вполне достаточно С++. Для прикладного программирования (влючая сервы и любой десктопный софт) придуманы гораздо более удобные и мощьные языки.

FR> Дальше надеюсь что он станет хорошей альтернативой C++ вообще.

Если это будет так, то это будет четким доказателством, алогичности человеческой природы.

FR>Про дебилов ты зря.

Думаешь обидятся? Да они никогда не воспринимают критику на свой счет.

FR> Я знаю достаточно людей (включая и самого себя) которые в состоянии освоить вещи очень отличные от С++ и майнстрима вообще, но которым нравится и главное комфортно работать именно с С — С++, думаю многим из них и D понравится.

Ну, что же. Приношу свои соболезнования. Лично я в жизни не буду использовать ни С++, ни ди, если у меня будет хоть какой-то выбор. Это пешерное програмирование для людей не ценящих свое время и не желающих получать удовольствие от самого процесса программирования. А я, знаете ли, люблю получать от программирования удовольствие.

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

VD>Это пешерное програмирование для людей не ценящих свое время и не желающих получать удовольствие от самого процесса программирования. А я, знаете ли, люблю получать от программирования удовольствие.

Сдается мне, что процесс получения удовольствия слабо зависит от рода проблем, которые приходится решать. Кому то интереснее одно, кому то другое.