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 ()

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

C++ зашёл очень вовремя. D уже успел устареть. Две разных стандартных библиотеки = авторы не договорились, для чего же собсна нужен такой язык. Все эти version, alias и ещё десяток сортов сахара - они крутые, но не проще ли define/ifdef применять во всех случаях, которых на деле не так уж и много? Людям не нужен просто язык типа C++ - они предпочтут использовать сам C++ с новым стандартом и готовыми инструментами, а не наступать ещё на парочку граблей. Людям нужен язык с проверками перед запуском и возможность не разъяснять машине кучу деталей на тех участках, где узких мест нет. Фигурные скобочки - это не то, ради чего изучают новый язык. Они не упрощают жизнь человека, они всего лишь упрощают транслятор (хотя и это спорно).

quiet_readonly ★★★★ ()

к версии gcc 4.8 будет предпринята попытка официально ввести в состав gcc gdc
будет предпринята
попытка

Новость ни о чём...

Будет попытка, результат которой ещё неизвестен.

Вот когда включили (или не включили) бы в состав gcc, вот тогда и написали бы новость.

D - пока ещё не тот ЯП, что каждый чих его разрабов достоин обсуждения.

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

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

Очередной неосилятор Си который пытается рассуждать о нем? Perl это логическое продолжение Си и техника реализации «классов» в нем подобна Си. Большие проекты где архитектура вцелом или его части может динамично расширяться в ту или иную сторону не пишутся на ООП поскольку «преимущества» ОПП тут же становятся недостатками. На связке Perl + Си проекты пишутся не просто так: Inline::C, XS позволяет очень быстро интегрировать скорострельный код, тогда как сам Perl позволяет программировать несколькими способами: уровень «чистого перла» - это низкоуровневый по отношению к ООП и на уровне ООП используюя модули вроде Moose. Я вам сочувствую если вы зациклились на ООП и считаете что эта костылеобразная модель (да-да, ООП - неудобный костыль) есть локоматив прогресса.

Есть другой подход к разработке: софт пишем на Си, а там где спешить особо некуда - пишем на Perl. То есть Perl используем как библиотеку к Си.

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

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

Уже давно как существует одна стандартная библиотека.

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

На большом и/ли длитетельном проекте статический компилятор всегда тебе экономически спасет жизнь.

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

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

Очередной неосилятор Си который пытается рассуждать о нем?

Перечитай вопрос, на который я отвечал. На счёт Perl как логического продолжения Си — это очень узкое использование Perl. В отличии от Си, в Perl есть duck typing и наследование. Я видел, как первое время на Perl пишут те, кто пришёл из Си, это душераздирающее зрелище. На счёт неосилятора, мне даже неловко, я на Си с 89г программировал.

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

Большие проекты где архитектура вцелом или его части может динамично расширяться в ту или иную сторону не пишутся на ООП поскольку «преимущества» ОПП тут же становятся недостатками.

4.2

Вот если сюда добавить «и должны быть готовы завтра, и не требуют продуманного взаимодействия с человеком или проверки всех пользовательских конфигураций» - тогда всё становится верно. В противном случае как раз таки ООП используется очень часто, что и доказывают все программы-бренды с человеческим интерфейсом. Popovshop, GIMP, офисные пакеты тому примеры.

Странно называть ООП костылём, если как раз не-ооп языки и являются подпорками для написания наколенных программ с жёстко забитыми данными.

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

Чувак наверное на самом деле имел ввиду «проверки перед запуском». Собсна в этом и есть смысл статически типизируемых языков - ведь глупо как-то самому гонять все возможные ветви исполнения программы, чтобы найти забытую точку с запятой, ведь с этим может справиться компьютер независимо от языка. Да и вообще, если честно, не видел ещё IDE для скриптовых языков, которые бы проводили анализ перед запуском и обламывали бы запуск, если проверка прошла с ошибками. Это прискорбно.

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

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

Как можно заключить из сообщений в рассылке разработчиков gcc

*разработчиков gcc*

Угадай.

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

Перечитай вопрос, на который я отвечал.

Почитаем вместе?

А что perl разве хорошо работает с десятками классов? Вроде ОО - это его самое слабое место?

Вообще говоря тут видна некомпетентность человека в области программирования. Нормальный программист сходу зацепится за выражение: «разве хорошо работает с десятками классов». Верно? Имелось ввиду что не захлебывается ли perl от десятков классов тогда как с двумя классами работает отлично? Но оставим этот бред. Дальше хуже: «Вроде ОО - это его самое слабое место». Тут о чем? Что имелось ввиду? Может вопрос был такой: «Не тормозит ли от ООЖ сам perl как ТЯПСОТ (Тормозной Язык Программирования С ОТступами) ?» Вообщем, тут бред. Прежде чем отвечать непонятно на что надо было разобраться есть ли вопросы и о чем вопросы вообще?

Ваш ответ:

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

ООП в perl нет и она не задумывалась изначально. Оно и не нужно, поскольку perl обеспечивает базовый набор примитивов который позволяет достичь всего, в том числе и ООП (что и видно на примере Moose).

На счёт Perl как логического продолжения Си — это очень узкое использование Perl.

Неужели? Perl и есть логическое продолжение Си: он расширяет его и реализует ряд примитивов таким образом что для достижения цели вы вольны выбирать любой путь пограммирования (как насчет AI::Prolog ?). Вообщем, я не понял вас - разверните вашу мысль.

В отличии от Си, в Perl есть duck typing и наследование.

Вы так пишете как будто в Си это недостижимо :).

Я видел, как первое время на Perl пишут те, кто пришёл из Си, это душераздирающее зрелище.

Я не видел и не понимаю вы о чем. Есть вероятность что вы столкнулись с быдлокодерами. Раскрываем мысль.

На счёт неосилятора, мне даже неловко, я на Си с 89г программировал.

И что? Люди по 50 лет работают на одной работе, но мастерами своего дела не становятся. Максимум - набираются опыта (то есть они сумеют сделать то что уже делали).

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

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

Мне неочевидно. Разверните мысль.

В противном случае как раз таки ООП используется очень часто, что и доказывают все программы-бренды с человеческим интерфейсом. Popovshop, GIMP, офисные пакеты тому примеры.

Все эти программы можно написать и не используя ООП вообще. Вообщем и тут разверните мысль, пожалуйста.

Странно называть ООП костылём, если как раз не-ооп языки и являются подпорками для написания наколенных программ с жёстко забитыми данными.

«Программы с жестко забитыми данными» - а что, такое еще встречается где-то? Вы ответили непонятно на что. Костыльность ООП подразумевалась в плане того что сама нотация несет ряд ограничении и, поэтому, реализация этой нотации делает невозможным в случае необходимости отойти от ООП. То есть если перед вами трясина и надо перебраться на другую сторону то вы просто утонете.

PS: Но боюсь вы снова не поймете о какой именно костыльности ООП идет речь, поскольку чтобы понять это - надо в реальном бою об это столкнуться (то есть хотя бы один раз надо «утонуть в болоте»).

PPS: Какой пусть написания вы выберете в Си - ваше право. Си не ограничивает в возможностях, тогда как ООП - ограничивает. В Си может потребоваться (а может и нет) дополнительный оверхед для реализации некоторых «внусностей» если вы будете в своей системе использовать «особые» техники/стили программирования. Примитивы perl позволяют практически сходу реализовать любой подход в программировании, не ограничивая программиста не только сверху (AI::Prolog, Moose), но и снизу ( Inline::C, Inline::Asm). Противопоставьте здесь Java/C#/Python и сразу увидите костыльность.

Однако, большие возможности требуют большой ответственности. И мне вот интересно, почему некоторые люди не могут отойти от типов и программировать так чтобы не возиться с типами и количеством парметров? У меня таких проблем просто нет (может потому такие вещи продумываются сразу и я не надеюсь на то меня кто-то будет бить по рукам в рантайме?). Как следствие, я не использую IDE, а использую практически примитивные текстовые редакторы.

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

Некоторые системы не поддаются продумыванию. GIMP, LibreOffice несут в себе код двадцатилетней давности; GIMP появился ещё тогда, когда для него графического фреймворка ещё не было - пришлось разрабам самим взять да написать GTK и иже с ним. Они имеют кучу компонент (хотя бы система кистей в GIMP) и все они должны работать правильно, при этом любая компонента может быть просту отключена или перемещена в порядке планового улучшения интерфейса, и уж точно никто не будет тестировать всё подряд, да и вообще смысл данной программы не в количестве мелких несвязанных функций. Может понадобиться новый, ранее никем не предвиденный тип кистей или логика обработки шрифтов. Код в любом случае и на любом языке столь велик, что знать его в одиночку не получится.

ООП позволяет превратить программу, с точки зрения программиста, в граф с иерархической структурой в виде дерева и довольно малым количеством связей между ветвями этого дерева (это одно из правил хорошего стиля в ООП, повторяется во всех статьях и учебниках). Такое кстати из текстового редактора нормально не редактируется - тут желательны хотя бы зачатки IDE, чтобы держало весь этот граф в памяти и переходило в один клик от строчки Foo foo = new Foo(); к объявлению класса Foo и вообще к объявлению любого символа. Чтобы дебаггер так же путешествовал по всему графу. Вот тогда можно продумывать не детали реализации, а только узлы графа (тоже правило хорошего стиля). И даже посторонний человек может взять и сделать хороший патч, при этом не влезая в подробности реализации, но в то же время не нарушив логику работы программы.

У меня таких проблем просто нет (может потому такие вещи продумываются сразу и я не надеюсь на то меня кто-то будет бить по рукам в рантайме?)

Торвальдс более 10 лет назад утверждал, что осознавать архитектуру ряда систем в одиночку невозможно - потому, мол, он и выложил своё ядро в сеть. Что же касается холивара «продумывание» vs «автоматические проверки»... Во-первых, «продумывание» усложняет приём патчей со стороны - их же тоже придётся сильно продумывать. Во-вторых, написанный на питоне eric4 в opensuse почему-то кидал исключения то там, то сям. А код QtCreator ещё при сборке анализируется машиной, и падения/зависоны случаются только там, где действительно есть баги (парсер glsl недавно ещё зависал на определённом коде).

Если же отказаться от ООП - это будет удобно в том плане, что А) можно обойтись текстовым редактором с удобным скроллом и табами, а не бороться с IDE; Б) Можно без проблем наращивать число мелких функций и бекендов (удлинняя ченджлог), игнорируя дублирование. Хорошо для серверных утилит.

А вот на персоналках нужна цельная система, которая исполняет желания человека (компьютер же умный), а список опциональных функций вообще по барабану. Короче говоря, ООП vs «кодим как есть» эквивалентно «цельная система, которая пытается угадать желания человека» vs «функциональная система с кучей опций, но их надо выбирать самому и они могут просто перестать работать при масштабировании».

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

tl;dr версия:

«То есть, ООП выгорает на долговременных проектах?» (c) один студент

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

Благодарю за ответ. Вы - хороший собеседник. У меня сложилось чувство что вы видете два варианта построения систем: 1) ООП; 2) куча мелких функции (или что-то подобное).

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

PS: ознакомьтесь с gtk

anonymous ()

D представляется интересным для программирующих пользователей

То есть настоящие мужики снова будут сами писать драйвера для своей видеокарты?

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

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

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

Короче, говоря: динамически типизируемые компилируемые языки проводят все те же самые проверки при компиляции, что и статические, кроме, очевидно, проверки типов.

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

Короче, говоря: динамически типизируемые компилируемые языки проводят все те же самые проверки при компиляции, что и статические, кроме, очевидно, проверки типов.

Столько внимания уделяется типам и типизации тогда как это, вообще говоря, второстепенные проблемы. Нормальная техника разработки не должно фокусировать ваше внимание на второстепенные вещи только если вы сами этого не пожелаете (например для оптимизации). Вот еще одна костыльность ООП.

anonymous ()

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

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

Столько внимания уделяется типам и типизации тогда как это, вообще говоря, второстепенные проблемы. Нормальная техника разработки не должно фокусировать ваше внимание на второстепенные вещи только если вы сами этого не пожелаете (например для оптимизации). Вот еще одна костыльность ООП.

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

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

Я не слежу за D, но на CTFE там даже рейтрейсер написали %) Так что CTFE пригоден для гораздо большего, чем склейка строк.

Я вот о чем. В D ты можешь объявить в программе строковый литерал, который будет содержать в себе, скажем, декларацию данных в синтаксисе ASN.1. Посредством CTFE ты сможешь распарсить эту декларацию, сгенерировать, в строковом представлении, кучу D-шного кода для отображения ASN.1-описания на D-шные классы, затем передать сгенерированое строковое представление в строковый mixin и получить эффект, как будто весь этот сгенерированный D-шный код был написан вручную или создан внешним asn1-транслятором.

Т.е. что-то вроде:

mixin( AsnOneToD(
q"{
  FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       IA5String
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }

  END
}" ) );

auto f = new FooQuestion();
f.trackingNumber = 1;
f.question = "To D or not to D";

В принципе, это тот же самый подход, который точно так же может использоваться в динамических языках вроде Ruby/Python, когда результат генерации текста передается в eval и объявленные в тексте сущности «магическим» образом появляются в программе.

«It is possible that a more general AST macro facility will replace mixin tenplates in a future revision of language».

Так что это именно макросы.

Того, о чем ты здесь говоришь, в D2 нет. А вещает о синтаксических макросах и модификации AST Александреску чуть ли не с момента появления D2.

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

Того, о чем ты здесь говоришь, в D2 нет. А вещает о синтаксических макросах и модификации AST Александреску чуть ли не с момента появления D2.

Что бы об этом сказали лисперы...

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

В D ты можешь объявить в программе строковый литерал, который будет содержать в себе, скажем, декларацию данных в синтаксисе ASN.1. Посредством CTFE ты сможешь распарсить эту декларацию, сгенерировать, в строковом представлении, кучу D-шного кода для отображения ASN.1-описания на D-шные классы, затем передать сгенерированое строковое представление в строковый mixin и получить эффект, как будто весь этот сгенерированный D-шный код был написан вручную или создан внешним asn1-транслятором.

Шо это? «Виртуальные метапарадигмы»? Сколько тысяч страниц в спецификации этого нового и духоподъёмного стандарта ASN.1?

tp_for_my_bunghole ()

Через 5-7 лет язык D достигнет такого уровня который не снился C++.

За частично готовую и неполноценную альтернативную реализацию компилятора языка D будут давать Нобелевскую премию. Если ещё получится.

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

Сколько тысяч страниц в спецификации этого нового и духоподъёмного стандарта ASN.1?

нового

facepalm.jpg

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

facepalm

Действительно, всего лишь на четверть века моложе лиспа.

«One may use an ASN compiler which takes as input an ASN.1 specification and generates computer code (for example in the language C) for an equivalent representation of the data structures. This computer code, together with supplied run-time libraries, can then convert encoded data structures to and from the computer language representation. Alternatively, one can manually write encoding and decoding routines.»

Компилятор в компиляторе, и интерпретатор ECMASript сбоку. У Уолтера Брайта хобби такое, компиляторы писать.

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

Компилятор в компиляторе, и интерпретатор ECMASript сбоку. У Уолтера Брайта хобби такое, компиляторы писать.

Осталось понять, причем тут Брайт и ECMAscript.

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

Осталось понять, причем тут Брайт и ECMAscript.

DMDScript ни при чём. Да и Bright ни при чём, D тоже.

Главное ведь что? Процесс. На CTFE/WTF напишут столько кода что это сподвигнет кого-то на создание другого языка.

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

нового и духоподъёмного стандарта ASN.1

Нового? Вы последние 30 лет были в заморозке, я вижу?

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

Язык без дебагера - это не то, что нужно пользователю.

Да ладно, кому это мешало скажем с PHP?

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

Не путай скриптовый WEB-ориентированный язык и системный.

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

Наверно. Такая бюрократия до меня не дошла. А вы в заморозке с 1958 года судя по всему?

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

Он _не говорит_ о прототипировании, он говорит о переписывании и рефакторинге уже написанной программы.

отлаженный прототип


Ты какой-то странный: только что говоришь о «программированием» задачи и, бац, уже откуда-то взялся отлаженный прототип. Его дядя Стёпа будет отлаживать вместо тебя что ли?

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

Расскажи это моему проекту на Perl в 50 тыщ строк кода.


Ого, да ты Вельзевул своего маленького ада :).

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

А вещает о синтаксических макросах и модификации AST Александреску чуть ли не с момента появления D2.

Месье Александреску помог в очередной раз изобрести лисп?

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

Расскажи это моему проекту на Perl в 50 тыщ строк кода.

А если проект пишет не быдлокодер, то сколько бы строк вышло?

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

Осталось понять, причем тут Брайт и ECMAscript.

DMDScript ни при чём.

ECMAscript.

DMDScript

Сдается мне, что ты норкоман, мил человек.

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

Сдается мне, что ты норкоман, мил человек.

Психически здоровый. Просто я не знал что имею дело не с человеком.

Как-то ты спотыкаешься на некоторых словах и дальше просто перестаёшь воспринимать информацию. Ты эти слова мне показываешь в своём комменте. Я даже не знаю какие опции тебе предоставлять.

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

Vala прагматичней.

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

Кстати, что означает слово референсный?

Эталонная или образцовая реализация. Эталонная не в смысле идеальная, а как пример для подражания.

У меня его даже спеллчекер подчеркивает.

Правильно делает.

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

С++ неоправданно идиосинкратичен для изучения непрофессиональными программистами.

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

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

Не путай скриптовый WEB-ориентированный язык и системный.

Ну для Си отладчик вообще бесполезен. ))

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

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

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

Помню, в первой половине 90-х была популярная тема «Ада против Си++». Победитель известен, и он, увы, не тот, кто мне больше нравился :)

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

Что касается линукса, то там бесплатно можно разрабатывать только открытые проекты, а коммерческие - опять же за отдельную плату

Эээ, сх^Wс чего бы это? GNAT под обычной GPL, у рантайма специальное исключение. Откуда вообще дровишки?

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

Так это же замечательная новость! Наверное, отсутствие такой версии под винду так сильно воспринял :)

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

Кхм. А почему ты решил, что вендового GNAT не существует?

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

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

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

Хотя стоп, я был неправ - исключение из GPL относится только к GNAT Pro. Разрабатывать closed source с помощью GNAT GPL всё же нельзя.

Но в разделе download таки есть версия GNAT GPL для венды.

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

Теперь вижу GNAT GPL под линукс, винду и мак. Просто список поддерживаемых платформ расширился, а ограничения все те же. Коммерческая разработка только в GNAT Pro, причем по годовой подписке.

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

Коммерческая разработка только в GNAT Pro, причем по годовой подписке.

В заговоре против Ады участвует даже AdaCore.

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