Разработчики языка программирования D (http://ru.wikipedia.org/wiki/D_%28%D1%8F%... сообщили (http://gcc.gnu.org/ml/gcc/2011-10/msg00037.html) об урегулировании вопроса с передачей Фонду свободного ПО имущественных прав на код фронтэнда GDC (http://www.digitalmars.com/d/2.0/index.html) (Gnu D Compiler). Передача прав на код является одним из основных условий, требуемых для включения новых фронтэндов в состав набора компиляторов GCC. В дальнейшем остаётся согласовать некоторые незначительные технические вопросы и обеспечить гарантию, что после включения в состав GCC фронтэнд не останется без мэйнтейнера и будет поддерживаться в актуальном состоянии.
Напомним, что компания Digital Mars, развивающая язык программирования D, ещё в прошлом году заявила о желании включить GDC в состав GCC. Но процесс остановился из-за нежелания терять права на код. Предложенный вариант с фо...URL: http://www.phoronix.com/scan.php?page=news_item&px=OTk2NA
Новость: http://www.opennet.me/opennews/art.shtml?num=31946
d2 уже умеет? или только d1? жаль что http://dprogramming.ru скорее мертв чем жив.
D2 в основном сейчас и развивается в GDC.
Умеет. Про D1 уже можно забывать, вторая версия вполне рабочая.
А как у D2 с поддержкой x64?Помнится я в свое время хотел перейти на D. Но то что тогда там было плохо с 64-разрядной платформой - меня это тогда остановило. Точнее D1 вроде как поддерживал, а D2 нет. А хотелось все-таки если уж D, то D2.
И под llvm только D1.Что толку в D2, если он поддерживает только ограниченный набор платформ.
> d2 уже умеет? или только d1? жаль что http://dprogramming.ru скорее мертв чем
> жив.Неделя ЛОРа на опеннете? По ссылкам не ходим, офсайты не посещаем?
чем D better C?
http://www.digitalmars.com/d/2.0/overview.html
Ничем. У создателей D не нашлось яиц выкинуть все легаси и сделать действительно современный язык.
> чем D better C?Он хуже. Авторы не смогли внятно сформулировать ни область для нового языка, ни "почему новый язык будет лучше, чем другие языки в данной области применения". Таким образом, основными мотивами при создании нового языка оказалась
- нам не нравится стиль расстановки скобочек
- на C программировать нам утомительно, а в C++ мы так и не разобрались.
+100500, очень точно сказано
Александреску не разобрался в С++?
Аноним лучше знает.
> Александреску не разобрался в С++?Во-первых Александреску позаимствовал идеи других людей и не удосужился на них сослаться; а во-вторых его код --- эстетство ради эстетства, идентичное составлению судоку. Соответственно, этим умствованием он продолжил заниматься и в D.
"Не читайте Александреску." (C) А. Степанов.
мне нравится судоку
Наверное, "несосланным людям" лучше видно, когда обижаться, а когда - нет?Александреску хоть и нудноватый парень, но сделал немало. В отличии от местных АНАЛитигоф. Сейчас, когда он открыл язык Ди, на его фоне С++ кажется бестолковым нагромождением костылей, называемых по ошибке ООП. Он это вовремя осознал и сейчас пилит библиотеку для Ди. А что пилите вы, форумные трепологи?
Если D кто-то назовёт ООП, это будет не меньшей ошибкой.
Ждём когда и FreeBASIC включат в GNU Compilers Collection.
Я может не знаю, а есть ли еще что либо кроме D компилируемое (и соответветсвенно заведомо быстрее всяких джав и питонов) и со сборщиком мусора?
Golang? Причем, я серьезно.
Бедняша, что с тобой? Джава компилируемая, в официальной реализации давно JIT-компилятор есть.
Если тебе без VM надо, то таких тоже дофига: Haskell(GHC), Ocaml, Common Lisp(SBCL), Vala(не совсем сборка мусора, но местные иксперты разницы не заметят) и т.д.
В принципе любой язык, не накладывающий ограничения на кроссплатформенность(как-то java/c#) может иметь компилятор, выдающий нативные бинарники.
> Бедняша, что с тобой? Джава компилируемая, в официальной реализации давно JIT-компилятор
> есть.Не смешите. Так и питон компилируемый и сотни других недоязыков, но эти ваши JIT оптимизировать толком не умеют, время запуска увеличивают, память жрут и тормозят.
> Если тебе без VM надо, то таких тоже дофига: Haskell(GHC), Ocaml,
> Common Lisp(SBCL), Vala(не совсем сборка мусора, но местные иксперты разницы не
> заметят) и т.д.Ну насчёт haskell и vala да, а про ocaml и sbcl сильно не уверен.
> В принципе любой язык, не накладывающий ограничения на кроссплатформенность(как-то java/c#)
> может иметь компилятор, выдающий нативные бинарники.А вот это неправда.
> Ну насчёт haskell и vala да, а про ocaml и sbcl сильно не уверен.http://www.sbcl.org
Steel Bank Common Lisp (SBCL) is a high performance Common Lisp compiler.Если уж коммонлисп компилируют(засовывая половину компилятора в бинарник:), то с всем остальным проблем быть просто не может.
> А вот это неправда.
Тараканы в голове мешают?
"JIT-компилятор" — это нонсенс. JIT-компиляция осуществляется интерпретатором либо байткода, либо непосредственно интерпретируемого языка. Компилируемым язык можно назвать только в том случае, если получаемый в результате компиляции исполняемый файл содержит машинный код, а не байткод, не p-код, не CIL и не УльтраСуперМегаПромежуточныйКод9001™.
> Компилируемым язык можно
> назвать только в том случае, если получаемый в результате компиляции исполняемый
> файл содержит машинный код, а не байткод, не p-код, не CIL
> и не УльтраСуперМегаПромежуточныйКод9001™.какая феерическая чушь.
идите-ка вы учиться, прежде чем комменты строчить
> "JIT-компилятор" — это нонсенс. JIT-компиляция осуществляется интерпретатором
> либо байткода, либо непосредственно интерпретируемого языка. Компилируемым язык можно
> назвать только в том случае, если получаемый в результате компиляции исполняемый
> файл содержит машинный код, а не байткод, не p-код, не CIL
> и не УльтраСуперМегаПромежуточныйКод9001™.Пожалуйста, ответьте на вопрос: чем отличается компилятор от интерпритатора?
интерпритатор - исполняет, компилятор создаёт исполняемые файлы
> интерпритатор - исполняет, компилятор создаёт исполняемые файлыТаким образом, Вы сами, если, конечно, Вы тот же самый Анон, указали на неточность в своих словах.
>> Компилируемым язык можно назвать только в том случае, если получаемый в результате компиляции исполняемый файл содержит машинный код, а не байткод, не p-код, не CIL и не УльтраСуперМегаПромежуточныйКод9001™.
> Бедняша, что с тобой? Джава компилируемая, в официальной реализации давно JIT-компилятор есть.Есть даже GCJ, что впрочем яве не сильно помогает. Жирный неповоротливый шит, где много переусложненных сущностей, тормозящих элементарные операции в разы, а то и десятки раз.
> может иметь компилятор, выдающий нативные бинарники.
Может иметь и имеет - немного разные вещи. Кроме того, фичи языка могут откладывать свой отпечаток на свойства реализации. Сделайте какойнить элементарный integer объектом. И скорость работы с большими объемами данных #$%нется в разы, потому что оверхеда много. Зато типа круто - мелкий гвоздик аж паровым копром забиваем!
> Сделайте какойнить элементарный integer объектом.ну, в смолтолке так и есть. и что?
Языки, компилируемые в c+lglib (vala/genie/occ, etc), например.
> Языки, компилируемые в c+lglib (vala/genie/occ, etc), например.ooc*, простите.
> Я может не знаю, а есть ли еще что либо кроме D компилируемое (и соответветсвенно заведомо быстрее всяких джав и питонов) и со сборщиком мусора?Есть. С. Для С разработан сборщим мусора Boehm GC (http://en.wikipedia.org/wiki/Boehm_garbage_collector). Собственно, именно на его основе и организован сборщик мусора в D.
>Есть. С. Для С разработан сборщим мусора Boehm GC
>(http://en.wikipedia.org/wiki/Boehm_garbage_collector).
>Собственно, именно на его основе и организован сборщик мусора в D.Благодарю. Нужная вещь.
Java (gcj), Objective-C 2.0 (clang), OCaml, Haskell (ghc), Common Lisp (ecl, sbcl), PHP (phc).
> Я может не знаю, а есть ли еще что либо кроме D компилируемое (и соответветсвенно заведомо быстрее всяких джав и питонов) и со сборщиком мусора?Модула 3
> Я может не знаю, а есть ли еще что либо кроме D
> компилируемое (и соответветсвенно заведомо быстрее всяких джав и питонов) и со
> сборщиком мусора?Common Lisp
> компилируемое (и соответветсвенно заведомо быстрее всяких джав и питонов)
Это ошибочное мнение, хотя, например, SBCL таки часто быстрее.
Новость, я б сказал, архиважная! Я уже года два работаю с D и считаю его лучшим преемником обоих Си и Сипипи. Теперь, с включением в ГЦЦ, Ди может значительно расширить аудиторию и улучшить качество программ.
ну если D все таки выстрелит, то это будет серьезная заявка на слив джав и сишарпов
> ну если D все таки выстрелит, то это будет серьезная заявка на
> слив джав и сишарповНормальные библиотеки? Компилятор хотя бы под 4 основные платформы? Скорость работы?
Выстрелить он может только себе в голову.
Он может юзать сишные библиотеки как бы, да и компиляторы вроде под основные платформы присуствуют. О скорости работы сказать не могу, не доводилось, но в любом случае видно что вы не имеете о D понятия куда больше.
Если бы он еще сишные библиотеки юзать не умел, это вообще бы настоящий цирк был. Сейчас в FFI кажется только elisp не умеет :)
>Скорость работы?Про скорость работы в сравнении с Java и C# говорите?
Нативный машинный код не может быть более медленным чем байткод, исполняемый в JVM или .NET. Это аксиома.
> Про скорость работы в сравнении с Java и C# говорите?
> Нативный машинный код не может быть более медленным чем байткод, исполняемый в
> JVM или .NET. Это аксиома.но байткод может быть докомпилирован на конечной машине, уже с учетом его архитектуры и соответственно - более оптимально.
первое что вспомнил из недавно виденного - Chrome V8 делает Delphi в вычислениях :)
http://delphitools.info/2011/09/02/first-look-at-xe2-floatin.../
>> Про скорость работы в сравнении с Java и C# говорите?
>> Нативный машинный код не может быть более медленным чем байткод, исполняемый в
>> JVM или .NET. Это аксиома.
> но байткод может быть докомпилирован на конечной машине, уже с учетом его
> архитектуры и соответственно - более оптимально.
> первое что вспомнил из недавно виденного - Chrome V8 делает Delphi в
> вычислениях :)
> http://delphitools.info/2011/09/02/first-look-at-xe2-floatin.../истинно так, так что я не вижу преимуществ D перед C# / Java. Кстати, было бы интересно увидеть сравнение D с оными. На сайте Digitalmars только сравнение с C++ да и то которое потеряло актуальность с выходом C++11: многие плюшки теперь есть и в плюсах, хотябы де-юре. Единственное в чем D обгоняет - это наличие модулей и встроенного GC.
Я дилетант в компиляторах, но вроде как наличие модулей позвоялет производить лучшую оптимизацию (????).
> но байткод может быть докомпилирован на конечной машине, уже с учетом его
> архитектуры и соответственно - более оптимально.Я думаю, это заблуждение, вызванное маркетоидным засиранием голов.
Я видел вашу ссылку, но она непрезентабельна ввиду узости задач.
Просто на пальцах рассудите: любая VM обладает неким _универсальным_ псевдокодом, который можно "отобразить" на таргет архитектуру. Т.е. он в принципе ýже, чем любая из железок! (наибольший общий делитель) Вопрос: как вы собрались обгонять нативные приложения, не используя полную мощь ЦПУ?? Одни SSE* чего стоят!
Кроме того, есть ещё трюки типа выравнивания, размер кэша 2 уровня и прочая хрень - VM просто опухнет, учитывавши бенефиты каждой платформы!
Вобщем, не надо фапать на JIT, успокаивая себя рекламными лозунгами - мы же всё-таки инженеры и должны думать головой. Да?
весь софт скомпиленный в нативный код прям так через одного юзает sse
> весь софт скомпиленный в нативный код прям так через одного юзает sseВесь, абсолютно весь софт скомпиленый под x64 может наглейше использовать как минимум SSE2: он там _гарантированно_ есть. В природе просто нет x64 процессоров без SSE2.
> Весь, абсолютно весь софт скомпиленый под x64 может наглейше использовать как минимум
> SSE2: он там _гарантированно_ есть. В природе просто нет x64 процессоров
> без SSE2.а ты можешь ходить по потолку, например. но ведь не ходишь.
>> но байткод может быть докомпилирован на конечной машине, уже с учетом его
>> архитектуры и соответственно - более оптимально.
> Просто на пальцах рассудите: любая VM обладает неким _универсальным_ псевдокодом, который
> можно "отобразить" на таргет архитектуру. Т.е. он в принципе ýже, чем
> любая из железок! (наибольший общий делитель) Вопрос: как вы собрались обгонять
> нативные приложения, не используя полную мощь ЦПУ?? Одни SSE* чего стоят!кхм, C тоже оперирует некой виртуальной машиной, являющейся общим знаменателем кучи разношерстных архитектур 80-х. Компилятор уже раскладдывает код с учетом конкретной архитектуры комманд, x86, x64, sparc, IA64, ...
Джиту в отличие от компилятора доступна информация не о конкретной арихтектуре КОММАНД, а о конкретной архитектуре ПРОЦЕССОРА, включающую в себя размер, кол-во и организацию кешей, регистров, конвеееров и прочей приблудни, которую он может задействовать. Понятное дело, чтобы в полную силу задействовать, например, кеш надо на уровне архитектуры вашей программы (исходного кода) учитывать влияние локальности данных и называется это DDD - Data Driven Design. Но при одном и том же исходном коде JIT *может* дать лучший код, так как у него больше информиации для оптимизации.
Еще один источник оптимизации - знание потока исполнения. JIT может встраивать виртуальные вызовы, так как знает что конкретно вызывается. А встроенный виртуальный метод, вызывающийся в цикле может дать хороший прирост производительности.
> Кроме того, есть ещё трюки типа выравнивания, размер кэша 2 уровня и прочая хрень - VM просто опухнет, учитывавши бенефиты каждой платформы!
не сравнивайте апельсины с яблоками: сложность реализации, причем не концептуальная, а техническая, связанная с большим объемом работы и возможность выравнивания - это разные вещи.
Приведу небольшой пример, IPP (Intel Performance Primitives) построенна так, что в самом начале она определяет архитектуру проца и расставляет указатели на функции, оптимизированные под конкретный проц или на generic x86, если не поределила или пользователь (программер) забыл вызвать в самом начале соответствующую функцию определения. performance при использовании конкретного проца вырастает в разы, почему-то, давно это было, у меня в голове крутится цифра в 10 раз, но я могу путать. Но прирост в 2-3 раза - это точно.
Аналогично может поступать jit.
> Кроме того, есть ещё трюки типа выравнивания, размер кэша 2 уровня и
> прочая хрень - VM просто опухнет, учитывавши бенефиты каждой платформы!
> Вобщем, не надо фапать на JIT, успокаивая себя рекламными лозунгами - мы
> же всё-таки инженеры и должны думать головой. Да?
> Джиту в отличие от компилятора доступна информация не о конкретной арихтектуре КОММАНД,а о конкретной архитектуре ПРОЦЕССОРА, включающую в себя размер, кол-во и организацию кешей, регистров, конвеееров и прочей приблудни, которую он может задействовать.
Спасибо за объяснения. Теперь даже я начал понимать почему Эклипс так тормозит. Это видимо потому что - Джиту в отличие от компилятора доступна ... и т.д. и т.п.
Кстати runtime оптимизации давным-давно доступны нормальному софту
http://en.wikipedia.org/wiki/FFTW
For a sufficiently large number of repeated transforms it is advantageous to use FFTW's ability to choose the fastest algorithm by actually measuring the performance of (some or all of) the supported algorithms on the given array size and platform. These measurements, which the authors call "wisdom" can be stored in a file or string for later use.
> Нормальные библиотеки?Вопрос лишь времени. .NET тоже не за год сделали, тем более при таких финансах. Другой вопрос, что КАЖДАЯ новая функция покрывает всё больше потребностей. Причём работает правило 80/20 - 20% функций покрывают 80% нужд типичных программ. ГУЙ, БД, Сеть, Криптография, Мультимедия - этих китов достаточно, чтобы язык был успешным.
> Компилятор хотя бы под 4 основные платформы?
Я назову и 10 платформ, наструя они нужны, если десктопом рулит Win?
> Скорость работы?
ха! :) Уж не писькомерством ли вы хотите заняться, сравнивая микросекунды на сложении строк? Ню-ню, говорю же - аналитиг. Ди делает нативные приблуды, чего уже в принципе достаточно. Главное в языке (при современных гигагерцах) - скорость и надёжность разработки. Поэтому С и С++ тут сразу вычёркиваются как полностью несостоятельные.
> Выстрелить он может только себе в голову.
Лучше вам.
То есть, там уже есть все? Подключение к СУБД, создание веб-интерфейсов, работа с серверами приложений?
под словом выстрелит я имел в виду появится описанные вами тулзы и фреймворки
Подключение к СУБД, создание веб-интерфейсов, работа с серверами приложений не имеет никакого отношения к языку. Язык - это набор правил. А вышеперечисленное - частные программульки и библиотеки.
согласен, я просто имел в виду когда появятся библиотеки для ентерпрайза, написанные на ди
> согласен, я просто имел в виду когда появятся библиотеки для ентерпрайза, написанные
> на дипо моему, D больше сейчас используется для научных разработок
Ну хорошо бы, пускай включают. Если честно, то давно пора.
D же умер давно, когда единственный проект на нём - openmw - переехал на C++.
А что на нем полензого написано, кроме OrfoSwitcher?
Poseidon - IDE для самого D и DWT - порт SWT на D ;)
небольшое уточнение: мертвая IDE
> А что на нем полензого написано, кроме OrfoSwitcher?А что полезного было написано на .НЕТе? НИ ЧЕ ГО. Просто корпорация зла выставила платформу и сказала: пишите! Тут то же самое, но при этом язык - нормальный.
Если вы боитесь его изучать, это не повод прикрывать собственные комплексы околоумными вопросами. Язык - хороший, бери и пиши!
«Digital Mars передаёт права на код FSF, но FSF в ответ тут же предоставляет неограниченную лицензию, позволяющую делать с кодом все что захочется»яничегонепонял.jpg
>урегулировании вопроса с передачей Фонду свободного ПО имущественных прав на код фронтэндаВот она вся суть штольмона. Думаете ваш код свободен? Нет, он принадлежит штольману.
> штольману.Штольман не пытается ничего заж@пить, никого нагнуть, поставить на бабки и прочее. Это дает ему пять очков форы вперед.
я правильно понял?
"чо-то у нас не взлетает. подтолкните, а"
>Передача прав на код является одним из основных условий, требуемых для включения новых фронтэндов в состав набора компиляторов GCCЗато как на Sun и Oracle все возмущались за такие же требования. Где вы. поборники свободы?
Пройдите в сад, анонимный Вы наш. Вы там будете слушать лекцию гр.Столмана про отличие одного от другого.
Три года назад постил новости про D на ЛОР - был срач и идиотские вопросы, которые в duckduckgo найти - пол минуты.Прошло три года, пишу на Common Lisp, читаю опеннет - а срач и идиотские вопросы о D те же что на ЛОРе три года назад.