я сомневаюсь, что только продвижение языка D, является активным, а остальные языки ни каких шагов не проявляют. И другие с грешками. что насчёт рейтинга, то во многих статьях идёт ссылка именно к TIOBE, а это наверное не пустозвон, а проверенно и их рейтингом следует принимать во внимание если не как факт, то как один из самых уважаемых мнений.

Возможно.


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

Нет, нет! Как раз таки надо принимать этот рейтинг как факт, т.е. количество запросов "x programming" по различным x. Но не более того. Любые попутки какой-либо иной интерпретации как минимум спорны. 

Это сообщение отредактировал(а) kemiisto - 3.8.2008, 20:44

из источников был www.linuxcenter.ru, www.opennet.ru, www.rsdn.ru (это лишь те которые я часто использую) и другие...

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

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

Добавлено через 6 минут и 55 секунд
А сам язык выглядит вполне съедобно . Кончено в нем нет кардинально новых решений, но заложенные возможности не разочаровывают. Но хотелось бы еще посмотреть его быстродействие в сравнении с с++  

  И я о том же!


Ох, знаете, очень, ну очень, спорный тезис. Спорный не только в рамках информатики. Имея некоторое отношение к научному сообществу (к химическому правда), уверяю Вас: то, что Вы написали - предмет постоянных споров. Есть некий метод, не дающий 100%-х результатов, но использовать альтернативные методы не представляется возможным по причине их отсутствия или высокой (не обязательно дененжной, а вычислительной, например) стоимости. Стоит ли пользовать такой метод? Нужны ли данные, достоверность которых неочевидна? Тут не всё так однозначно. Признаться, я ещё и сам для себя до конца не решил, чью сторону занять. 


А за эту информацию будьте любезны кругленькую сумму! Нехорошо. Капиталисты, блин...   

P.S. Прошу прощенья за   , но просто не мог не высказаться.

Добавлено через 5 минут и 58 секунд

Пожалуйста!
Очень интересный сайт!

Это сообщение отредактировал(а) kemiisto - 3.8.2008, 22:37

kemiisto, только лучше имхо брать компилятор DMD.

Судя по тестам, D вполне подойдёт для постепенного вытеснения С++ в новых проектах  

Мультилайн-запись строк в первую очередь:

Предполагается, что aaa и bbb очень длинны.

По правде говоря, Garbage Collector вызывается либо когда заканчивается ОЗУ, либо когда завершается программа, либо вручную, так что ничего он не замедляет кроме завершения работы приложения разве что... Все критичные к освобождению ресурсов места по прежнему управляются вручную при помощь Dispose да using.


C каких пор работать с памятью напрямую стало удобно? Да и вообще подобные утверждения дурно пахнут преждевременной оптимизацией...

Это только для Java и только по умолчанию, ставь кл.слово final и метод даже в Java не будет виртуальным.


Про остальные пункты уже сказали...

На мой взгляд единственным "недостатком" осталось, то что в C# шаблоны - динамические, а в D - статические. Но тут уж вопрос спорный, что лучше?

Говорится:
Уж лучше голодай, чем что попало есть, и лучше будь один, чем вместе с кем попало. (с) Омар Хайям
Во много раз лучше отсутсвие всяких рейтингов, чем присутсвие такого бреда как Tiobe...


Это сообщение отредактировал(а) source777 - 4.8.2008, 14:53

source777, 

Возможно, но при работе с 3D (OpenGL) это имхо приходится делать немного чаще.

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


P.S. Кстати хочется отметить, что D -  весьма хорошая замена С++ для тех кто ещё до сих пор пользуется этим самым С++. Ну а для тех, кто уже перешёл на .NET | Java, он никаких существенных преимуществ не даёт. + ему не хватает крупной компании в роли двигателя, если у Java есть Sun, у C# - MS & Novell, то у D только Digital Mars, этого маловато чтобы раскрутиться для полноценной конкуренции. 


Это сообщение отредактировал(а) source777 - 4.8.2008, 20:59

Ну, во-первых, приходится сортировать и обсчитывать объекты огромных современных игровых уровней. При сортировке оптимизация крайне желательна, т.к. это сильно влияет на фпс.
Во-вторых, существует потребность быстро загружать данные с диска в память видеокарты (есть даже пейпер Fast Texture Transfers), а это проще всего сделать, если маппить подготовленный на видеокарте буфер и напрямую читать в него файл с диска (OpenGL), либо маппить файл в память с помощью команд ОС.
Если принять во внимание технологию мегатекстур, то там крайне важно быстро считывать данные из файла мегатекстуры, т.к. её невозможно загрузить целиком.
Быстрый расчёт вещественных чисел, разумеется, тоже важен, в D также есть для этого все средства, включая встроенный x86-ассемблер.
Вот как альтернатива C++ язык D очень хорош, по крайней мере у него я вижу только два недостатка - мало литературы и куча плюсовых проектов.

Откуда такие сведения?
По моим наблюдениям (профайлинг в NetBeans Profiler) Garbage Collector в циклическом приложении периодически включается и подбирает созданные в цикле объекты. Это хорошо видно по пилообразному графику потребления памяти. GC активируется примерно каждые 5 секунд.

Согласно Рихтеру:


Т.е. в случае твоего приложения, это вариант, когда приложение беспрерывно создаёт новые объекты... Если бы ты вынес процедуру создания объектов из цикла, то сборшик мусора не проявил бы активности...

source777, это понятно, но меня интересуют именно игры, а там, естественно, всё зациклено... Но интересно тогда, чем процесс сборки мусора в JRE отличается от такового в CLR.

А что там зациклено то? Ты для каждой прорисовки заново все объекты создаёшь что ли? Не легче ли создать все нужные объекты при загрузке уровня, а потом уже ими "управлять"?

Добавлено через 42 секунды
P.S. Про JRE не знаю, жди джавистов...