LINUX.ORG.RU

Попытка реинтеграции компилятора D в состав GCC

 , ,


2

6

Как можно заключить из сообщений в рассылке разработчиков gcc, к версии gcc 4.8 будет предпринята попытка официально ввести в состав gcc gdc — свободную реализацию компилятора языка D (digitalmars D).

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

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

D не накладывает жёстких парадигменных ограничений и позволяет записывать код в обобщённом, объектно-ориентированном, функциональном и процедурном стилях, а так же их комбинации. Штатно предоставляются полные средства интроспекции. Дополнительно компилятор несёт в себе нечто вроде интерпретатора языка, позволяющего динамически добавлять/изменять методы во время исполнения.

Имеются средства прямого вызова функций, реализованных на языках C и C++.

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

Свободно доступен референсный компилятор dmd, однако он предназначен, скорее, для исследовательских целей. Появление штатного фронтенда D в наборе gcc позволяет надеяться на переход от чисто экспериментального применения этого интересного и мощного языка к широкому внедрению.

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от tailgunner

Думаю, что их просто устраивает текущее положение вещей.

dave ★★★★★ ()
Ответ на: комментарий от tp_for_my_bunghole

CTFE похоже на корявую реализацию некоторых возможностей лиспов.

Эсли это немного перефразировать ближе к настоящим идеям Уолтера, то будет так: «Мы взяли только самые удобные и надёжные элементы других языков, чтобы получить практический язык для реальных задач». Грубо говоря, шизоидный ЛИСП нет смысла куда-то тащить - лишь некоторые его идеи могут быть полезны.

И вообще, прежде чем сравнивать вкус устриц, кому-то хорошо бы сходить на сайт Ди и немного окунуться в идеи языка. Ди даже в мыслях не собирается конкурировать с Жабами, Шарпами или, прости господи, Лиспами, он просто пилится для решения задач. Любые попытки его сравнивать с другими языками - это проявление дилетантства и убогости мировоззрения, т.к. Ди сравнения не нужны - это просто ЯЗЫК. Хочешь - пиши, не хочешь - займись крайне полезным трындением на форумах - в сети ведь так мало твоих увековеченных фраз!....

matumba ★★★★★ ()
Ответ на: комментарий от tailgunner

Вообще, прихожу к заключению, что у LispWorks самая либеральная лицензия, если говорить об интересных средах программирования. Например, коммерческие среды для Smalltalk - это просто кошмарный сон, когда речь заходит о цене (VA ST ~ $7000, но без royalty, а у VisualWorks постоянный roaylty). GNAT, видимо, тоже дорогое удовольствие. Склоняют к использованию изрядно поднадоевших Си++ и Java, нечестивцы!

dave ★★★★★ ()
Ответ на: комментарий от matumba

Любые попытки его сравнивать с другими языками - это проявление дилетантства и убогости мировоззрения

Клевый постулат. Святая инквизиция на лоре?

sv75 ★★★★★ ()
Ответ на: комментарий от matumba

О, у языка уже есть фанаты.

Грубо говоря, шизоидный ЛИСП нет смысла куда-то тащить - лишь некоторые его идеи могут быть полезны.

И вообще, прежде чем сравнивать вкус устриц, кому-то хорошо бы сходить на сайт Ди и немного окунуться в идеи языка. Ди даже в мыслях не собирается конкурировать с Жабами, Шарпами или, прости господи, Лиспами

Ди сравнения не нужны - это просто ЯЗЫК. Хочешь - пиши, не хочешь - займись крайне полезным трындением на форумах - в сети ведь так мало твоих увековеченных фраз!....

В результате ноль.

Во что там окунаться? В ASN.1?

tp_for_my_bunghole ()
Ответ на: комментарий от tp_for_my_bunghole

хорошо бы сходить на сайт Ди и немного окунуться в идеи языка

Во что там окунаться? В ASN.1?

Тебе для начала нужно окунуться в русский язык.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от matumba

Эсли это немного перефразировать ближе к настоящим идеям Уолтера, то будет так: «Мы взяли только самые удобные и надёжные элементы других языков, чтобы получить практический язык для реальных задач». Грубо говоря, шизоидный ЛИСП нет смысла куда-то тащить - лишь некоторые его идеи могут быть полезны.

Одна из идей лиспа это одинаковое представление кода и данных. Это даёт «бесплатно» сериализацию, макросы(изменение AST). И реализация ECMAScript для скриптования лиспам не нужна, по очевидным причинам.

В языке D нет идей лиспа кроме сборщика мусора. Я вижу корявую реализацию возможностей лиспа, с затрачиванием немалых усилий по реализации(CTFE/ASN.1), которые трудно полноценно повторить в альтернативных реализациях(GDC).

Ди даже в мыслях не собирается конкурировать с Жабами, Шарпами или, прости господи, Лиспами

В таком случае что означает «практический язык для реальных задач»?

tp_for_my_bunghole ()
Ответ на: комментарий от tailgunner

Тебе для начала нужно окунуться в русский язык.

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

tp_for_my_bunghole ()
Ответ на: комментарий от tp_for_my_bunghole

Два шприца этому наркоману.

anonymous ()

Я как-то пытался собрать gdc/d на одной из своих машин (оговорюсь: среди них вообще нет ни одной x86 любой разрядности). Однако, мне это не удалось. Я даже багрепорт отправил им (лень искать, какой, они забыли про него сами, походу).

Включение же в коллекцию GCC обязательно означает полную поддержку и портируемость на не-x86 архитектуры. Это очень и очень хорошо.

powerpc ()
Ответ на: комментарий от powerpc

Вы правы, они собрали первую версию, но не смогли вторую. К сожалению проверить не могу, мой мак погиб. Чисто для интереса, он у Вас не собирался или не работал?

at ★★ ()
Ответ на: комментарий от at

`make check' не работал, как я помню. А для Debian'а это считается нормальным, если они собрали и оттестировали на x86, а под другие архитектуры просто собрали без тестирования. Я встречал это и для Gnome ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667529 ), и для LibreOffice ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667047 ), и ещё много для чего (ну лень копаться, реально, можешь просто поверить, что ну мягко говря «халатно» майнты дебиана относятся к не-x86?).

Пытался найти мой отрепортированный баг для этого gdc через гугль — не нашёл. Ну больше года где-то прошло, да.

powerpc ()
Ответ на: комментарий от powerpc

Когда я пользовался powerpc все было относительно нормально. Возможно у мантейлеров было больше маков. Крайний раз из не-x86 ставил дебиан на спарк года 2 назад. Все было нормально, по крайней мере серверная часть. Возможно сейчас что то изменилось.

P.S. D довольно интересный язык, хотя его оригинальная версия сильно завязана на x86 компилятор.

at ★★ ()
Ответ на: комментарий от at

Да, сейчас всё хуже и хуже... С каждым днём.

Вот хорошо, что подтянулись RedHat'овцы, ибо им важно иметь RHEL для POWER. Они и вытащили релиз Fedora 17. В частности, пофиксили тот самый фиг-найдёшь-где баг в LO Base.

А раньше в Fedora всё было прекрасно на POWER/PowerPC. До версии Fedora 13. Я на большинстве продакшн-машин использовал как раз Fedora до 2010 года. Моя статья на OSNews: http://www.osnews.com/story/23071/GNU_Linux_Distros_Silently_Drop_PowerPC/

powerpc ()
Ответ на: комментарий от matumba

Угу, а Брайт - гений, который знает что в каких языках шизоидно, а что нет.

Любые попытки его сравнивать с другими языками - это проявление дилетантства и убогости мировоззрения, т.к. Ди сравнения не нужны

Ха-ха-ха-ха...

sched ()
Ответ на: комментарий от matumba

Любые попытки его сравнивать с другими языками - это проявление дилетантства и убогости мировоззрения, т.к. Ди сравнения не нужны - это просто ЯЗЫК.

Это сильно сказано. Очень сильно. Но хотелось бы ещё и обоснований. Веских. Без сколь-нибудь убедительного обоснования так можно сказать про любой ЯП. Даже про басик. :)

DeVliegendeHollander ★★ ()
Ответ на: комментарий от sched

Поверю на слово. :)

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

DeVliegendeHollander ★★ ()
Ответ на: комментарий от anonymous

Любопытно, как Вы воссоздаёте в этом самом REPL контекст выполнения более-менее сложной задачи, а не дай Б-г, многопоточной?

anonymous ()
Ответ на: комментарий от tp_for_my_bunghole

Уже представить страшно D++, а ведь оно будет!

anonymous ()
Ответ на: комментарий от DeVliegendeHollander

Но я вообще фанатиков не понимаю.

+1

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

А на основании чего вы стоите ваши суждения? На основании личного опыта?

PS: Поскольку ЯП разные и возможности у них разные. Следовательно, равенства быть не может. То есть, если взять ряд криетриев с их весомыми коэффициентами и провести анализ - то мы получим разные результаты. В свое время, изучая разные ЯП на профипригодность, универсальность и гибкость, я проделал что-то подобное для себя. Несомненно, на полноту я не претендую, поскольку некоторые языки не рассматривались в силу их экзотичности и низкой распространенности, но с тем что рассматривал я не поленился и покопался в собственной реализации языков чтобы понять сильные и слабые стороны. Одним из основных требовании было что-то наподобие «язык должен позволять достичь любых требуемых решении» (на самом деле были ряд конкретных требовании). Ну и, в конечном счете, мне удалось выбрать лишь несколько достойных, которые «лучше других на десять голов» (вкупе с тех сторонами также рассматривались важные нетехнические свойства, как например, лицензия). Полагаю, мой подход к выбору если и не самый правильный с научно-исследовательской позиции, но как минимум, он достоен уважения. И я легко мог бы устроить дискуссию (лично мне очень интересно) по разбору конкретных языков и их свойств на 100500+ страниц, но, свое время мне нужно расходовать более рационально. Хотя, скажу вам что время от времени в просторах реала и рунета нечто подобное я устраивал ранее, и, скажу что до сих пор ярые сторонники php, python, java, C# и C++ полностью сливали дискуссию и в некоторых случаях просто удаляли весь тред (особенно обидчивые ребята\^W девочки по разбору питона на опеннете). Тут два варианта: мне попадались фанаты/быдлокодеры которые не сильно задумывались над возможностями в выборе языка, либо обычные чернорабочие\^W хомячки, которые используют тот или иной ЯП потому что просто используют его :-).

PPS: А на основании чего строяться ваши суждения? И, да, уточните ваш склад мышления если вдруг наберетесь смелости ответить.

PPPS: «Я лишь категорически против этого бездумного обезьянства ... ведь таких пользователей, как известно, 95% - они своей массой задавят любой здравый смысл.» (с) anonymous ( Выпущена первая опытно-промышленная партия российского микропроцессора MultiClet MCp0411100101 (комментарий) )

anonymous ()
Ответ на: комментарий от basp

А вы строковые макросы из D видели? Этим отстрелить себе ногу гораздо проще, чем плюсовыми шаблонами.

однако, если пользоваться с умом, возможны плюшки, как здесь: https://github.com/PhilippeSigaud/Pegged http://lycus.org/ (гусары, молчать про PEGGED @ Urban dictionary! )

или, box3n от h3r3t1c — та самая игрушка типа quake. Там свой парсер конфигов на Enki/EBNF, тоже активно используется метапрограммирование.

Ни одной качественной (и активно развивающейся) среды разработки за столько лет,

Здрасьте, ни одной. Под винду есть плагин к Visual Studio, Visual D: http://www.dsource.org/projects/visuald/wiki/Features http://dblog.aldacron.net/2010/04/20/installing-visual-d-without-buying-visua... там работает отладчик от MSVC и есть визард AST конвертации С++ в D : http://www.dsource.org/projects/visuald/wiki/Tour/CppConversion

вообще же пользуюсь плагином для MonoDevelop: http://mono-d.alexanderbothe.com/ — прекрасным образом работает везде. Даже есть сборки под винду с GTK и Mono. И вполне рабочий Eclipse плагин: http://code.google.com/a/eclipselabs.org/p/ddt/ — работает почти всё то же, что и для C++. Автор (Bruno) кстати, писал PDF-ку с master thesis на тему «как он писал плагин для D для Eclipse», полезно для знакомства с Eclipse плагинами вообще. Ссылка есть где-то на сайте.

ни одного живого, качественного и документированного gui-фреймворка.

есть несколько разной степени живучести. Например, последний проект для GTK2, на гитхабе, см. в рассылке. Он поприятнее чем предыдущий, особенно с UFCS (Uniform Function call syntax, это когда foo.bar(a,b,c) = bar(foo,a,b,c) в DMD 2.059+). Гораздо менее корявая прослойка, чем предыдущая. Остальное да, разной степени заброшенности.

Долгое время существовали 2 стандартные библиотеки (одна рекомендованная, другая - правильная).

ну и что? под C вон вообще сколько альтернативных libc и рантаймов. всё-таки официальная одна, и судя по скорости разработки, Phobos — основная. В Tango еле-еле успевают портировать совместимость с новым DMD2, новых фич толком не появляется.

И с тех пор не появилось ни одного серьезного проекта на D.

тот же http://lycus.org/

А ведь еще тогда (3 года назад) казалось, что еще чуть-чуть и язык стабилизируется,

практически уже. D2 с выходом книжки.

появятся инструменты разработки и т.д.

они таки есть. Чего конкретно тебе не хватает?

anonymous ()
Ответ на: комментарий от unC0Rr

Почему в gcc, а не на базе llvm?

есть и на llvm — https://github.com/ldc-developers/ldc . Он по-моему, всё-таки перспективнее gdc, потенциально. Хотя gdc сейчас тоже неплохо развивается, вот если в gcc таки осилят протолкнуть, это будет ПЕАР.

anonymous ()
Ответ на: комментарий от glebiao

Я считаю, что популяризация D нужна: другой адекватной альтернативы слишком обросшему особенностями особенностей C++, не привязанной к вендору (читай, .Net), пока не видно.

почему не видно, Go тот же. Вполне неплохой тулчейн в GG, протолкнули таки в GCC, единая тулза go install/go build/... , патчи к gdb. Есть на кого равняться, в плане наличия тулзов.

anonymous ()
Ответ на: комментарий от glebiao

Ни одной качественной (и активно развивающейся) среды разработки за столько лет

Это естественно. Ниша занята C++, пока пройдёт период популяризации, пока народ распробует и начнёт использовать... Это не начало 90-ых, когда C++ пошёл в народ усилиями Борлана и ТопСпида --- на незанятое место.

любители и сейчас могут поковырять веточкой OpenWatcom 1.9 (и грядущий 2.0). Почувствуй себя в 90х! правда C++ стандарты свежие толком не поддерживаются, x86-64 нет (хотя был под альфу, т.е., архитектурно возможно — просто рук не хватает допилить), ну и сам тулчейн немного NIH синдромом отдаёт: wmake, wlink (тоже недопиленный по сравнению с JWlink), свой vi под все платформы. Отладчик wd и профилятор правда классные, да :))

anonymous ()
Ответ на: комментарий от anonymous

ещё вот Mono под андроид развивается. Та же интеграция с С++ и т.п. В принципе, если бы допилить Vala (вкорячить рантайм с ком-объектами, сборщик мусора, например) — под винду это мог бы быть маленький такой, мелкотравчатый киллер С#, миниме.

anonymous ()
Ответ на: комментарий от anonymous

А на основании чего вы стоите ваши суждения? На основании личного опыта?

В основном - да.

PS: /* простыня поскипана */

Интересный подход. Но у меня нет столько времени на исследование языков. Знакомство с ЯП и их функциональными возможностями происходит случайно и хаотично. Исключительно на практике. Ни один из знакомых мне языков не стану называть ни «плохим», ни «идеальным». Незнакомые - тем более. Исключение - бейсик. Когда-то давно мне пришлось разбираться с «наследием»-ворохом программ на этом... и дописывать новые. С тех пор я полностью согласен с Э.Дийкстрой.

PPS: А на основании чего строяться ваши суждения? И, да, уточните ваш склад мышления если вдруг наберетесь смелости ответить.

См.выше - по большей части личный опыт. Склад мышления...не знаю...обычный: оцениваю то, что знаю, стараюсь заранее не принимать на веру суждения о том, чего не знаю. Например, Си знаю, давно пишу на нём, хороший язык, подходит для решения около 50% моих задач. С++ знаю хуже, но в связке с Qt - подходит для решения около 30% моих задач. И у Си, и С++ есть свои недостатки. А вот Java знаю на уровне HelloWorld, поэтому выносить окончательное суждение по нему не имею права. Приблизительно так.

DeVliegendeHollander ★★ ()
Ответ на: комментарий от quiet_readonly

не видел ещё IDE для скриптовых языков, которые бы проводили анализ перед запуском и обламывали бы запуск, если проверка прошла с ошибками

есть всякие штуки типа pylint, pep8.py

pawnhearts ★★★★★ ()
Ответ на: комментарий от powerpc

у меня отлично работал debian на ia64, включая гном и кучу прикладного и серверного софта.

pawnhearts ★★★★★ ()
Ответ на: комментарий от pawnhearts

У нас разные интернеты и дистовотчи? Вот тут ( http://distrowatch.com/table.php?distribution=yellowdog ) написано, что последний релиз был в 2009 году. Сама компания TerraSoft, выпускавшая собственно Powerstation-десктопчики и бывшая главным разрабом, давно продалась Fixstars'у, который тут же сказал: «никаких десктопов!» ну и заодно свернул YDL.

А D тут при том, что он x86-only :-)

powerpc ()
Ответ на: комментарий от powerpc

ok, who cares? я работал несколько лет назад над эмбедед ppc там было в лучшем случае 2.4+patches, если не 2.2

pawnhearts ★★★★★ ()
Ответ на: комментарий от Hackeridze

В каком, блин, процессе? Разрабы там сдохли уже давно! Кто бы занялся qtd вновь...

ну, уж прям давно...

[gleb@gdell: qtd] :hg/default $ hg log | head

changeset: 414:b2a803c73b89 tag: tip user: David Nadlinger <code@klickverbot.at> date: Fri May 06 13:39:49 2011 +0200 summary: Declare tabArray const.

changeset: 413:bdc08c8391ad user: Max Samukha <maxsamukha@gmail.com> date: Thu May 05 22:32:50 2011 +0300 summary: removed unnecessary regex grouping

С Qt 4.8 собирается (пара тривиальных правок) и в общем и целом, работает.

Конечно, реанимация нужна, но больной не так уж сильно пахнет :)

glebiao ()
Ответ на: комментарий от glebiao

С Qt 4.8 собирается (пара тривиальных правок) и в общем и целом, работает.

Конечно, реанимация нужна, но больной не так уж сильно пахнет :)

Если вдруг Qt 5.0 зарелизится - запах будет то что надо.

ratvier ()
Ответ на: комментарий от sched

Вообще-то я за ним специально не наблюдаю, но несколько его комментариев, которые наводят на такие мысли, видел.

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

DeVliegendeHollander ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.