GDC получил поддержку ARM

Хорошо бы они QtD возобновили и я был бы очень счастлив.

А почему новый фронтенд требует своих бэкендов?

А почему новый фронтенд требует своих бэкендов?

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

Хорошо бы они QtD возобновили и я был бы очень счастлив.

Ещё бы сам Qt на него переехал и стало бы совсем замечательно.

Для начала неплохо бы было получить поддержку D.

D всегда будет ждать светлое будущее.

Так о том и вопрос. Если «компилятор D получил поддержку ARM», то она у него собственная, не использующая готовый бэкенд ARM, так ведь?

То есть никогда не дождется?

То есть? gdc же всегда основывался на gcc и, в теории, должен был использовать gcc-шный кодогенератор. Разве нет?

А почему новый фронтенд требует своих бэкендов?

Новость как раз о GDC - GNU D Compiler, он использует готовые бэкенды из GCC, а не «свои».

Потому что хороший кодегенератор написать куда сложнее чем язык

Ерунда.

А если бы в студии замутили поддержку D то вообще было бы круто!

Ну во первых поддержка для студии есть http://www.dsource.org/projects/visuald

Во вторых Мелкомягкие в своих презентациях уже упоминают язык https://www.youtube.com/watch?v=cPk6UPVqUJs#t=713 что наводит на мысли, что в перспективе могут сделать и нативную интеграцию.

То есть? gdc же всегда основывался на gcc и, в теории, должен был использовать gcc-шный кодогенератор. Разве нет?

Да, но нужно адаптировать идиомы языка для генерации кода в backend на целевой платформе. Например, поддежка thread-local storage.

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

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

Мелкомгкие уже несколько лет трындят о ренессансе С++, а поддержка актуального стандарта мягко говоря неполная и неизвестно когда она будет полной.

Пока не будет .net версии оно в студии будет на правах «ненужно»

Пока не будет .net версии оно в студии будет на правах «ненужно»

А С++ есть в .NET версии?

Есть, C++/CLI называется.

Скажите, а этот gdc с какой версией D работает?

Для начала неплохо бы было получить поддержку D

Для начала неплохо бы было застабилизировать D.

Есть managed C++. Вполне .net версия.

Ещё бы сам Qt на него переехал и стало бы совсем замечательно.

Яростно лорчую! Использование для Qt в качестве основного нативного языка D - было бы круто.

Скажите, а этот gdc с какой версией D работает?

Текущий master - 2.064.2 , последний релиз DMD - 2.065

Для начала неплохо бы было застабилизировать D.

Очень нравится терпеть баги?

LDC (компилятор на базе LLVM) так же получил экспериментальную поддержку ARM

Я не понял, а разве компилятору в llvm не становятся автоматически достопны все платформы, которые поддерживает llvm?

Qt гвоздями прибит к C++.

Ну они даже C99 никак не осилят. И это в 2014 году!

PyQt

Это называется «биндинг». Сам Qt как был, так и остается написан на C++.

Ну они даже C99 никак не осилят

А кому он там нужен? Разве что разработчикам драйверов, да и то только тех, что в ядре работают.

они даже C99 никак не осилят

А кому он там нужен?

Всем, кто пишет программы на Си.

А на чистом С много под венды пишут?

А на чистом С много под венды пишут?

На чистом Си пишут много кросс-платформенного софта.

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

А как надо? PyGTK не на Си? :)

а зачем?. У меня куча гуйни (и для себя и как части проектов) на Qt, которая работает с сервисами, писанными, как на с++, так и на окамле. Давно понятно, что гуй должен оставаться гуем. А весь остальной кутешный фреймворк вполне заменяем.

Хороший RPC - залог здоровья ;)

а Ди надо попробовать, может и пригодится где...

Не совсем понятно выражение «поддержку программирования на Android и iOS»: т.е. будет нативная версия Ди для обеих систем? Ну, допустим. Хотя имея за плечами gcc/llvm можно и под виндой генерить «экзешники» под любую из систем.

И вот сейчас и настал тот самый важный момент, когда Ди необходим свой ГУЙ, с кнопками и скроллбарами. Если будет кросс-платформенный ГУЙ, то можно в любой ОС создавать приложения под любую другую ОС, что невероятно облегчает жизнь всем.
Понятно, что это нудно, особенно на начальном этапе - красивостей ещё не видно, а уже надо написать хренову тучу обслуживающего кода. Но зато абстрагировавшись от всяких Cocoa/Win32/X, можно сразу обогнать на целый корпус всякие глиняные поделия типа Qt/GTk.
Я не уверен, понимает ли это Уолтер или Андрей, у них и так дел по горло, но стратегию надо разрабатывать, иначе Ди так и останется «интересным языком» с кучей протухших байндингов и фэйспалмовых гуёв.

А много осталось живых платформ, где есть C и нет C++ ?

А вот тех, где затрахаешься на чистом C писать из-за необходимости потребления объектно-ориентированных системных API, становится всё больше и больше. Так что пора эти проекты на C++ переносить давно.

Каким боком стабилизация API/ABI помешает выпиливанию багов?

Ещё бы сам Qt на него переехал и стало бы совсем замечательно.

С нынешней популярностью D это стало бы началом конца Qt.

Я не уверен, понимает ли это Уолтер или Андрей,

Ох лол. Ты такой смешной. гуй ... да ненужен гуй такой уже давно никому. Писать гуй на D/C++/C это онанизм. Прошло уже время прибивания кнопок к коду гвоздями на 200. И вот Уолтер и Андрей это прекрасно понимают :)

А на чем реальные пацаны пишут Гуй?

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

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

LLVM IR не является платформонезависимым представлением, вопреки расхожему заблуждению. Frontend должен поддерживать целевую платформу явно.

На протяжении уже очень долго времени почти все breaking changes в новых релизах возникают из-за починки accepts-invalid багов.

Намеренное изменение чего-либо в API сейчас - редчайшая редкость и обязательно проходит через постепенный deprecation cycle.

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

Не совсем понятно выражение «поддержку программирования на Android и iOS»: т.е. будет нативная версия Ди для обеих систем?

Можно будет создавать нативные бинарники под эти системы. Следующий шаг - допиливание runtime и интеграция с NDK.

вот сейчас и настал тот самый важный момент, когда Ди необходим свой ГУЙ, с кнопками и скроллбарами.

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

D это чистейший open-source проект, каждый работает над теми вещами, которые ему интересны. Если GUI в таком состоянии, значит он просто не нужен сильным программистам сообщества.

Если будет кросс-платформенный ГУЙ, то можно в любой ОС создавать приложения под любую другую ОС

Идеальная кросс-платформенность это миф, родные приложения всегда намного приятнее в использовании.

Ненужно получил поддержку ненужно. Все счастливы.

А много осталось живых платформ, где есть C и нет C++ ?

Осталось много кода на Си, который никто не будет переводить на Си++; осталось много людей, у которых комплексы перед Си++.

пора эти проекты на C++ переносить давно.

Apache, SSH, Python, Ruby, тысячи их. Перенеси, чо.

Ты помнится писал «Использование для Qt в качестве основного нативного языка D». Иначе как переписыванием Qt на D это не назвать.

Ты помнится писал «Использование для Qt в качестве основного нативного языка D». Иначе как переписыванием Qt на D это не назвать.

Кароч, чтобы был нормальный биндинг QtD ;)