VD>Компилятор — это такая же программа как и все другие. Если ее удобно писать, то будет удобно писать и многие другие программы.

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

а большинство программ работают по другому:
они стартуют,
получают в произвольном порядке события,
в произвольном порядке меняют свое внутреннее состояние,
в произвольном порядке выдают события наружу,
и часто могут вообще никогда не завершаться (по крайней мере логически).
и если компилятор — это функция, то такая программа — скорее агент (или в упрощенном виде — объект).

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

T>>Действительно, неужели это о чём-то вообще свидетельствует? Какая у вас проблема с ядром на си/++?

A>может и так.. Просто мне это кажется странным. особенно для очень развитых представителей.
A>Мне кажется что наличие исходников языка на самом себе показывает как минимум его самодостаточность..

Показывает. А вот насчёт "как минимум" — тут всё зависит от целей, которые преследовали авторы. Для практичных языков самодостаточность — последнее дело, они и так уже решают поставленные задачи. Языкам "ради искусства" и "двигающим науку вперед" self-hosted компилятор, конечно, необходим в качестве аргумента в споре "кто круче".

Здравствуйте, anokata, Вы писали:

A>Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.

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

Вообще общего правила нет. Например, Erlang использует самораскрутку: для компиляции его рабочего кода используются уже собранные в поставке beam'ы компилятора. С другой стороны, С сам по себе сейчас обычно использует самораскрутку процентов на 99.9, легче сделать кросс-компилятор для первого внедрения, чем рисовать всё это на ассемблере.

A>Неужели это свидетельствует о их слабости или недоразвитости? или просто на остальных ЯВУ трудно писать компиляторы?

Может, это просто не их целевая ниша?
Не вопрос написать такой компилятор и среду, но им может чего-то не хватать.

Здравствуйте, anokata, Вы писали:

A>Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.
A>Неужели это свидетельствует о их слабости или недоразвитости? или просто на остальных ЯВУ трудно писать компиляторы?
A>Единственно вижу что на хаскеле пишут другие языки, но он опять же частично написан на С. Есть другие примеры?

Потому что Си (а также С++, D, ObjC, Java, C#, Delphi и т.п.) — нормальные языки, понятные и удобные для реального, практического, старого доброго программирования.
А хаскели и прочее — это абстрактная околоматематическая сущность. Вроде матлаба или чего-то типа того. ИМХО, в большинстве случаев это даже не "языки программирования", а скорее средства компьютерного моделирования какой-то математической парадигмы или теории. По крайней мере, их разработчики точно не ставят целью создание языка, на котором можно писать к примеру ядра операционных систем или навороченные GUI приложения.
Разумеется, в них есть польза, и немалая — например, что с их помощью можно создавать, исследовать и обкатывать новые концепции и парадигмы, которые затем можно встроить в нормальные языки (пример тому — функциональное программирование — лямбды и прочее, которое уже "обкатано" и сейчас прекрасно вписывается в старую добрую классическую модель реального, практического программинга).

Здравствуйте, VladD2, Вы писали:

VD>Компилятор — это такая же программа как и все другие. Если ее удобно писать, то будет удобно писать и многие другие программы.

Не вполне согласен. Все программы — разные. Компилятор — очень специфическая программа.
В качестве контрпримера: удобно ли будет писать интерпретатор SQL на SQL?

Здравствуйте, anokata, Вы писали:

A>Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.
A>Неужели это свидетельствует о их слабости или недоразвитости? или просто на остальных ЯВУ трудно писать компиляторы?

1. не всякий язык хорошщо подходит для написания трансляторов. а про фп языки вообще говорят, что единственная серьёзная программа которую на таком языке пишут обычно — собственный транслятор

2. большинство языков работают медленней С, но позволяют программировать быстрее. т.е. они подходят для программ, имеющих небольшой тираж

3. компиляторы пишут очень квалифицированные специалисты

A>Единственно вижу что на хаскеле пишут другие языки, но он опять же частично написан на С. Есть другие примеры?

ghc вроде целиком на хаскеле написан. на C там RTS

Здравствуйте, samius, Вы писали:

S>Вот допустим, ушел в монастырь писать компилятор блаб на блаб-е. Написал, вышел, кому стало легче?

Я вот не могу понять, что ты тут на русском написал, что уж там о блабах то говоить.

VD>>Потом автор языка (если он сам пишет компилятор) получает неоценимый опыт использования языка. А это положительно влияет на дизайн языка. В него реже попадают вещи для галочки, и чаще появляются нужные и удобные вещи.
S>Нужные и удобные для написания компилятора? А если язык создавался с другой целью, то именно вещи для компилятора будут для галочки, а нужные и удобные будут слиты.

Можно поинтересоваться какие из специализированных фич для написания компиляторов ты знаешь? Другими словами, о чем идет речь то?

Компилятор — это такая же программа как и все другие. Если ее удобно писать, то будет удобно писать и многие другие программы.

Здравствуйте, anokata, Вы писали:

A>Здравствуйте, Temoto, Вы писали:

T>>Действительно, неужели это о чём-то вообще свидетельствует? Какая у вас проблема с ядром на си/++?

A>может и так.. Просто мне это кажется странным. особенно для очень развитых представителей.
A>Мне кажется что наличие исходников языка на самом себе показывает как минимум его самодостаточность..
А что с ней делать с этой самодостаточностью?

Здравствуйте, samius, Вы писали:

A>>может и так.. Просто мне это кажется странным. особенно для очень развитых представителей.
A>>Мне кажется что наличие исходников языка на самом себе показывает как минимум его самодостаточность..
S>А что с ней делать с этой самодостаточностью?

Это как минимум отличный тест компилятора. Компиляторы не мальенькие по объему программы.

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

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, VladD2, Вы писали:

J>>>Разве дельфи бутстрапили?? Его компилер на плюсах же написан. IDE — да, на дельфи, а компилер на плюсах.
VD>>Еще со времен паскаля они писали компиляторы на нем же. Потом, правда, бросили (если не ошибаюсь).
LVV>Ошибаетесь.
LVV>Компонентный паскаль написан на компонентном паскале. И весь БлэкБокс — тоже.
LVV>ВСЕ тексты доступны в среде — можно модифицировать, если сильно нужно.

А при чём тут дельфи?
Кто о чём, а голый о бане?

Здравствуйте, anokata, Вы писали:

A>Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.

Очень много проверенных временем тулов (свободных, коммерческих, внутренних и т.д) для создания компиляторов, которые написаны на С/C++ и генерят код на C/C++. Потому удобней взять готовые инструменты а не писать свои.

Здравствуйте, FR, Вы писали:

FR> Там вообще дурдом, судя по устанавливаемым пакетам (для 2009 студии) IDE написан (может и частично) на уже вымершем J#

IDE на дельфях. J# там используется для рефакторинговых/моделинговых туловых, которые можно полностью отключить.

Здравствуйте, Sinclair, Вы писали:

S>Не вполне согласен. Все программы — разные. Компилятор — очень специфическая программа.
S>В качестве контрпримера: удобно ли будет писать интерпретатор SQL на SQL?

SQL — это не язык программирования общего назначения. На нем вообще ничего написать (кроме запросов к БД) нельзя. А вот на любом ФЯ, которые в чем-то похожи на SQL писать компиляторы милое дело.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

A>>>может и так.. Просто мне это кажется странным. особенно для очень развитых представителей.
A>>>Мне кажется что наличие исходников языка на самом себе показывает как минимум его самодостаточность..
S>>А что с ней делать с этой самодостаточностью?

VD>Это как минимум отличный тест компилятора. Компиляторы не мальенькие по объему программы.
Вот допустим, ушел в монастырь писать компилятор блаб на блаб-е. Написал, вышел, кому стало легче?

VD>Потом автор языка (если он сам пишет компилятор) получает неоценимый опыт использования языка. А это положительно влияет на дизайн языка. В него реже попадают вещи для галочки, и чаще появляются нужные и удобные вещи.
Нужные и удобные для написания компилятора? А если язык создавался с другой целью, то именно вещи для компилятора будут для галочки, а нужные и удобные будут слиты.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

S>>Вот допустим, ушел в монастырь писать компилятор блаб на блаб-е. Написал, вышел, кому стало легче?

VD>Я вот не могу понять, что ты тут на русском написал, что уж там о блабах то говоить.
Не могу понять, что ты не смог на русском понять.

VD>>>Потом автор языка (если он сам пишет компилятор) получает неоценимый опыт использования языка. А это положительно влияет на дизайн языка. В него реже попадают вещи для галочки, и чаще появляются нужные и удобные вещи.
S>>Нужные и удобные для написания компилятора? А если язык создавался с другой целью, то именно вещи для компилятора будут для галочки, а нужные и удобные будут слиты.

VD>Можно поинтересоваться какие из специализированных фич для написания компиляторов ты знаешь? Другими словами, о чем идет речь то?
Про специализированные я ничего не говорил, а вот удобными были бы АлгТД, ПМ, лямбды.

VD>Компилятор — это такая же программа как и все другие. Если ее удобно писать, то будет удобно писать и многие другие программы.
Язык прежде всего должен делать удобным то, для чего он предназначен. И чем уже его предназначение, тем неудобнее будет на нем писать что-либо другое, и наоборот. Хаскель удобен для написания компилятора, но почему-то скрипты для винды пишут на повершеле а геймдев на С++ в своем большинстве.

Здравствуйте, Mr.Delphist, Вы писали:

LVV>>ВСЕ тексты доступны в среде — можно модифицировать, если сильно нужно.
MD>Никогда не видел сырцов компилятора. VCL — да, конечно. Но даже сырцов системных юнитов (не говоря уже про компиль) никогда не видал. С какой версии у них такой сахар тростниковый пошёл?

Ты похоже про Дельфи а твой оппонент про BlackBox
А в Делфи системные юниты и RTL сейчас доступны в исходниках компилятор нет.

Здравствуйте, _Obelisk_, Вы писали:

_O_>Очень много проверенных временем тулов (свободных, коммерческих, внутренних и т.д) для создания компиляторов, которые написаны на С/C++ и генерят код на C/C++. Потому удобней взять готовые инструменты а не писать свои.
Они все настолько убоги, что на них даже смотреть противно.
Не то, что пользоваться.

Здравствуйте, VladD2, Вы писали:

VD>Потом автор языка (если он сам пишет компилятор) получает неоценимый опыт использования языка. А это положительно влияет на дизайн языка. В него реже попадают вещи для галочки, и чаще появляются нужные и удобные вещи.

Например, val/var.

Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.
Неужели это свидетельствует о их слабости или недоразвитости? или просто на остальных ЯВУ трудно писать компиляторы?
Единственно вижу что на хаскеле пишут другие языки, но он опять же частично написан на С. Есть другие примеры?

Здравствуйте, anokata, Вы писали:

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

A>Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.
A>Неужели это свидетельствует о их слабости или недоразвитости? или просто на остальных ЯВУ трудно писать компиляторы?
A>Единственно вижу что на хаскеле пишут другие языки, но он опять же частично написан на С. Есть другие примеры?

Действительно, неужели это о чём-то вообще свидетельствует? Какая у вас проблема с ядром на си/++?

Здравствуйте, Temoto, Вы писали:

A>>Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.
A>>Неужели это свидетельствует о их слабости или недоразвитости? или просто на остальных ЯВУ трудно писать компиляторы?
A>>Единственно вижу что на хаскеле пишут другие языки, но он опять же частично написан на С. Есть другие примеры?

T>Действительно, неужели это о чём-то вообще свидетельствует? Какая у вас проблема с ядром на си/++?

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

Здравствуйте, x-code, Вы писали:

XC>А хаскели и прочее — это абстрактная околоматематическая сущность. Вроде матлаба или чего-то типа того. ИМХО, в большинстве случаев это даже не "языки программирования", а скорее средства компьютерного моделирования какой-то математической парадигмы или теории. По крайней мере, их разработчики точно не ставят целью создание языка, на котором можно писать к примеру ядра операционных систем

это точно. как-то не самая частая задача

XC>или навороченные GUI приложения.

в подписи

Здравствуйте, netch80, Вы писали:

N>Ядро на Си или близком к тому языке необходимо потому, что средства взаимодействия с внешней средой (ОС и прочее), как правило, реализованы в первую очередь в интерфейсе для Си. Особенно это характерно для Unix мира.

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

Здравствуйте, anokata, Вы писали:

A>Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.
A>Неужели это свидетельствует о их слабости или недоразвитости? или просто на остальных ЯВУ трудно писать компиляторы?
A>Единственно вижу что на хаскеле пишут другие языки, но он опять же частично написан на С. Есть другие примеры?

Все очень просто. Бутстрапинг — это геморрой в начальной стадии проекта. Ведь очень легко получить компилятор которым нельзя будет скомпилировать самого себя. По сему нужна многопроходная (хотя бы двупроходная) компиляция. Усиленное тестирование.

Вторая причина — это сложность переноса на другие платформы. Если компилятор написан на С и это нэйтив-компилятор, то перенести его на другую платформу (в идеале) можно тупой перекомпиляцией.

Но все же главная причина — дурь. Те кто не использует бутсрапинга (и при этом пытается создать новый язык который будет удобен другим) делает огромную ошибку, на мой взгляд.

Бутстрапинг очень полезен по двум причинам.
1. Это отличный тест самого компилятора. Причем тест который постоянно развивается.
2. Это возможность создателям языка больше использовать этот самый язык. А без этого трудно сделать язык который был бы нужен другим.

На самом деле почти все популярные сегодня языки когда-то бутсрапились или стремятся к этому. Вот тут

Автор: x-code
Дата: 23.05.11

товарищ перечислял "нормальные языки", по его мнению, языки (С++, D, ObjC, Java, C#, Delphi). Так среди них только C# и D не бутстрапились. Причем для C# уже пишется компилятор на C#, а D в этот список явно попал случайно (так как под нормальными языками явно понимаются популярные ныне или в недавнем прошлом).

А вот с D все сложнее. Его автор хотел создать лучшего потомка С, но пока что народ его не воспринимает. И, возможно, что от части происходит это потому, что D не пишется на D.

Здравствуйте, VladD2, Вы писали:


VD>На самом деле почти все популярные сегодня языки когда-то бутсрапились или стремятся к этому. Вот тут

Автор: x-code
Дата: 23.05.11

товарищ перечислял "нормальные языки", по его мнению, языки (С++, D, ObjC, Java, C#, Delphi). Так среди них только C# и D не бутстрапились. Причем для C# уже пишется компилятор на C#, а D в этот список явно попал случайно (так как под нормальными языками явно понимаются популярные ныне или в недавнем прошлом).

Разве дельфи бутстрапили?? Его компилер на плюсах же написан. IDE — да, на дельфи, а компилер на плюсах.

On 23.05.2011 14:59, x-code wrote:

> Потому что Си (а также С++, D, ObjC, Java, C#, Delphi и т.п.) — нормальные
> языки, понятные и удобные для реального, практического, старого доброго
> программирования.
> А хаскели и прочее — это абстрактная околоматематическая сущность. Вроде матлаба

Ты вспомни эти свои слова, когда всякие хаскели будут стрелять в 200 ядер со
скоростью заоблачной, а С в это время только успеет скомпилироваться (на одном
ядре).

>> Потому что Си (а также С++, D, ObjC, Java, C#, Delphi и т.п.) — нормальные
>> языки, понятные и удобные для реального, практического, старого доброго
>> программирования.
>> А хаскели и прочее — это абстрактная околоматематическая сущность. Вроде матлаба

MZ>Ты вспомни эти свои слова, когда всякие хаскели будут стрелять в 200 ядер со
MZ>скоростью заоблачной, а С в это время только успеет скомпилироваться (на одном
MZ>ядре).

Думаете до пенсии увидим такое?

Здравствуйте, Jack128, Вы писали:

J>Разве дельфи бутстрапили?? Его компилер на плюсах же написан. IDE — да, на дельфи, а компилер на плюсах.

Еще со времен паскаля они писали компиляторы на нем же. Потом, правда, бросили (если не ошибаюсь).

Здравствуйте, VladD2, Вы писали:

J>>Разве дельфи бутстрапили?? Его компилер на плюсах же написан. IDE — да, на дельфи, а компилер на плюсах.
VD>Еще со времен паскаля они писали компиляторы на нем же. Потом, правда, бросили (если не ошибаюсь).
Ошибаетесь.
Компонентный паскаль написан на компонентном паскале. И весь БлэкБокс — тоже.
ВСЕ тексты доступны в среде — можно модифицировать, если сильно нужно.

Здравствуйте, VladD2, Вы писали:

VD>Все очень просто. Бутстрапинг — это геморрой в начальной стадии проекта. Ведь очень легко получить компилятор которым нельзя будет скомпилировать самого себя. По сему нужна многопроходная (хотя бы двупроходная) компиляция. Усиленное тестирование.

VD>Вторая причина — это сложность переноса на другие платформы. Если компилятор написан на С и это нэйтив-компилятор, то перенести его на другую платформу (в идеале) можно тупой перекомпиляцией.

VD>Но все же главная причина — дурь. Те кто не использует бутсрапинга (и при этом пытается создать новый язык который будет удобен другим) делает огромную ошибку, на мой взгляд.

VD>Бутстрапинг очень полезен по двум причинам.
VD>1. Это отличный тест самого компилятора. Причем тест который постоянно развивается.
VD>2. Это возможность создателям языка больше использовать этот самый язык. А без этого трудно сделать язык который был бы нужен другим.

VD>На самом деле почти все популярные сегодня языки когда-то бутсрапились или стремятся к этому. Вот тут

Автор: x-code
Дата: 23.05.11

товарищ перечислял "нормальные языки", по его мнению, языки (С++, D, ObjC, Java, C#, Delphi). Так среди них только C# и D не бутстрапились. Причем для C# уже пишется компилятор на C#, а D в этот список явно попал случайно (так как под нормальными языками явно понимаются популярные ныне или в недавнем прошлом).

VD>А вот с D все сложнее. Его автор хотел создать лучшего потомка С, но пока что народ его не воспринимает. И, возможно, что от части происходит это потому, что D не пишется на D.

А может просто считать С новым ассемблером и компилиться через него как некоторые и делают?) разве такой способ не проще? и перенос на другие платформы получаем за так.

Компилятор FreePascal написан на FreePascal

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Jack128, Вы писали:

J>>Разве дельфи бутстрапили?? Его компилер на плюсах же написан. IDE — да, на дельфи, а компилер на плюсах.

VD>Еще со времен паскаля они писали компиляторы на нем же. Потом, правда, бросили (если не ошибаюсь).

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

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, VladD2, Вы писали:

J>>>Разве дельфи бутстрапили?? Его компилер на плюсах же написан. IDE — да, на дельфи, а компилер на плюсах.
VD>>Еще со времен паскаля они писали компиляторы на нем же. Потом, правда, бросили (если не ошибаюсь).
LVV>Ошибаетесь.
LVV>Компонентный паскаль написан на компонентном паскале. И весь БлэкБокс — тоже.

Валерн, извини, но засунь этот компонентный паскаль в места куда не заглядывает луч света. Я говорил о продуктах Борланда, которые реально были (да и остаются) популярны. А Блэкокс твой — это никчемная игрушка даже не имеющая полноценного GC.

Здравствуйте, anokata, Вы писали:

A>А может просто считать С новым ассемблером и компилиться через него как некоторые и делают?) разве такой способ не проще? и перенос на другие платформы получаем за так.

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

Здравствуйте, Jack128, Вы писали:

J>по крайней мере начиная с седьмой версии — точно на плюсах. Периодически из компилятора ассерты вываливаются с именами файлов..

Я думаю, что на плюсы они пересели где-то в 3-ей версии. Но на плюса писать компиляторы объективно удобнее чем на Дельфи.

Здравствуйте, VladD2, Вы писали:


VD>На самом деле почти все популярные сегодня языки когда-то бутсрапились или стремятся к этому. Вот тут

Автор: x-code
Дата: 23.05.11

товарищ перечислял "нормальные языки", по его мнению, языки (С++, D, ObjC, Java, C#, Delphi). Так среди них только C# и D не бутстрапились. Причем для C# уже пишется компилятор на C#, а D в этот список явно попал случайно (так как под нормальными языками явно понимаются популярные ныне или в недавнем прошлом).

D тоже пишется
http://code.google.com/p/dil/
http://www.dsource.org/projects/ddmd

VD>А вот с D все сложнее. Его автор хотел создать лучшего потомка С, но пока что народ его не воспринимает. И, возможно, что от части происходит это потому, что D не пишется на D.

По моему эта причина совершена несущественна.

Здравствуйте, VladD2, Вы писали:

VD>Потом автор языка (если он сам пишет компилятор) получает неоценимый опыт использования языка. А это положительно влияет на дизайн языка. В него реже попадают вещи для галочки, и чаще появляются нужные и удобные вещи.

Угу и чаще появляются нужные и удобные вещи нужные для написания компиляторов

Здравствуйте, Jack128, Вы писали:

J>Разве дельфи бутстрапили?? Его компилер на плюсах же написан. IDE — да, на дельфи, а компилер на плюсах.

Там вообще дурдом, судя по устанавливаемым пакетам (для 2009 студии) IDE написан (может и частично) на уже вымершем J#
основная библиотека VCL и часть рантайма (даже для C++ builder) на паскале, а комилятор (и дельфи и С++) на С++

Здравствуйте, FR, Вы писали:

FR>D тоже пишется
FR>http://code.google.com/p/dil/
FR>http://www.dsource.org/projects/ddmd

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

VD>>А вот с D все сложнее. Его автор хотел создать лучшего потомка С, но пока что народ его не воспринимает. И, возможно, что от части происходит это потому, что D не пишется на D.

FR>По моему эта причина совершена несущественна.

Она не решающая, но существенная. Развивая язык сам на себе автор лучше понимает что в языке важно, а что вторично.

Здравствуйте, FR, Вы писали:

VD>>Потом автор языка (если он сам пишет компилятор) получает неоценимый опыт использования языка. А это положительно влияет на дизайн языка. В него реже попадают вещи для галочки, и чаще появляются нужные и удобные вещи.

FR>Угу и чаще появляются нужные и удобные вещи нужные для написания компиляторов

Ты уже перечислил такие вещи? Перечисли, обсудим. Я знаю только одну такую — квази-цитирование.

Здравствуйте, VladD2, Вы писали:

J>>Разве дельфи бутстрапили?? Его компилер на плюсах же написан. IDE — да, на дельфи, а компилер на плюсах.
VD>Еще со времен паскаля они писали компиляторы на нем же. Потом, правда, бросили (если не ошибаюсь).

Компиляторы всех паскалей и 16-битного дельфи — целиком ассемблер. На самом паскале был написан IDE, да и то не весь.

У 32-битного дельфи компилятор я не смотрел, но, скорее всего, плюсы.

Здравствуйте, desperado_gmbh, Вы писали:

_>Компиляторы всех паскалей и 16-битного дельфи — целиком ассемблер. На самом паскале был написан IDE, да и то не весь.

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

За Борлоновские реализации я не так уверен, но мне кажется, что где-то читал, что и Турбо Паскаль тоже бутстрапился.
Так что хотелось бы увидеть пруфлинк.

Здравствуйте, VladD2, Вы писали:

VD>Тем паче. Хотя на первый взгляд эти две разработки кажутся чьими-то левыми подлками. Я правильно понимаю, что ваторы Ди к ним отношения не имеют?

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

FR>>По моему эта причина совершена несущественна.

VD>Она не решающая, но существенная. Развивая язык сам на себе автор лучше понимает что в языке важно, а что вторично.

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

Здравствуйте, VladD2, Вы писали:

FR>>Угу и чаще появляются нужные и удобные вещи нужные для написания компиляторов

VD>Ты уже перечислил такие вещи? Перечисли, обсудим. Я знаю только одну такую — квази-цитирование.

Да практически все что немерл унаследовал от ML семейства.

Здравствуйте, FR, Вы писали:

FR>Угу, но не важно, рантайм и стандартная библиотека (фобос) практически полностью написаны на D и именно авторами языка, их объема более чем достаточно для заявленных тобой целей.

Смеешься что ли? Какой на фиг у Ди рантайм? И что там за библиотеки?

FR>Для этого не обязательно писать именно компилятор, рантайм и стандартная библиотека ничем ни хуже.

Нет. Компилятор — это большой и сложный код. Библиотеки на их фоне просто игрушка. Они же не воспроизвели явские или дотнетные либы?

Здравствуйте, FR, Вы писали:

FR>Да практически все что немерл унаследовал от ML семейства.

Да, ну? Стало быть все что есть в МЛ пригодно только для написания компиляторов?
В курсе, что его разрабатывали как для создания теорем-пруверов?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>ghc вроде целиком на хаскеле написан. на C там RTS

Ага, в результате его не установить по-человечески, если в системе уже нету ghc.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, VladD2, Вы писали:

VD>Смеешься что ли? Какой на фиг у Ди рантайм? И что там за библиотеки?

Вполне приличный, язык-то нативный под три платформы, рантайм сишный практически полностью включает плюс gc плюс
реализация исключений и базового объекта, реализация встроенных примитивов (массивов и т. п.), примитивы для
мультитрединга, RTTI, по объему в последней версии (2.053) такой:

c/cpp: files = 7  lines = 749  size = 16 kb. (17326 bytes)
asm: files = 1  lines = 85  size = 2 kb. (2662 bytes)
d: files = 166  lines = 65909  size = 1757 kb. (1799949 bytes)

global: files = 174  lines = 66743  size = 1777 kb. (1819937 bytes)

Библиотеки такие (содержание в левой части страницы, на самой странице рантайм) http://www.digitalmars.com/d/2.0/phobos/phobos.html

FR>>Для этого не обязательно писать именно компилятор, рантайм и стандартная библиотека ничем ни хуже.

VD>Нет. Компилятор — это большой и сложный код. Библиотеки на их фоне просто игрушка. Они же не воспроизвели явские или дотнетные либы?

Нет библиотеки у D я не назвал бы простыми, очень много кода с шаблонами и практически включают в себя и стандартные библиотеки
небольшого функционального языка, да и по объему вполне уже прилично:

c/cpp: files = 30  lines = 14684  size = 525 kb. (538365 bytes)
d: files = 109  lines = 152783  size = 4937 kb. (5055714 bytes)

global: files = 139  lines = 167467  size = 5462 kb. (5594079 bytes)

(сишные файлы там zlib в исходниках)

Компилятор кстати:

c/cpp: files = 217  lines = 215303  size = 6194 kb. (6343482 bytes)

global: files = 217  lines = 215303  size = 6194 kb. (6343482 bytes)

из них унаследованный backend:

c/cpp: files = 80  lines = 94803  size = 2853 kb. (2922336 bytes)

global: files = 80  lines = 94803  size = 2853 kb. (2922336 bytes)

Вполне сопоставимо по объему.

Здравствуйте, VladD2, Вы писали:

FR>>Да практически все что немерл унаследовал от ML семейства.

VD>Да, ну? Стало быть все что есть в МЛ пригодно только для написания компиляторов?

Не только, но для этого очень удобен.

VD>В курсе, что его разрабатывали как для создания теорем-пруверов?

Угу, но потом на нем (исключая частично OCaml) в основном или писали компиляторы — трансляторы
или использовали для обучения.

Здравствуйте, FR, Вы писали:

VD>>Да, ну? Стало быть все что есть в МЛ пригодно только для написания компиляторов?

FR>Не только, но для этого очень удобен.

Не находишь, что есть определенная разница между "для этого очень удобен" и "специализированная фича пригодная только этого"?

VD>>В курсе, что его разрабатывали как для создания теорем-пруверов?

FR>Угу, но потом на нем (исключая частично OCaml) в основном или писали компиляторы — трансляторы
FR>или использовали для обучения.

Видимо именно по этому на вики упоминается, что "also used in bioinformatics, financial systems, and applications including a genealogical database, a peer-to-peer client/server program, etc.".

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, desperado_gmbh, Вы писали:

_>>Компиляторы всех паскалей и 16-битного дельфи — целиком ассемблер. На самом паскале был написан IDE, да и то не весь.

VD>Ну, на счет всех — это заведомая лож, так как доподленно известно, что самый первый — Виртовский — Паскаль создавался методом бутстрапинга.

Естественно, я говорил только про борландовские

VD>За Борлоновские реализации я не так уверен, но мне кажется, что где-то читал, что и Турбо Паскаль тоже бутстрапился.
VD>Так что хотелось бы увидеть пруфлинк.

К сожалению, дизассемблированные мной исходники шестого турбопаскаля накрылись вместе с диском несколько лет назад. Они время от времени всплывают на разных сайтах, но в принципе достаточно посмотреть на tpc.exe через дизассемблер. Нормальный рукописный код, ничего общего не имеющий ни с выдачей tpc, ни с выдачей tcc.

Здравствуйте, x-code, Вы писали:

XC>Потому что Си (а также С++, D, ObjC, Java, C#, Delphi и т.п.) — нормальные языки, понятные и удобные для реального, практического, старого доброго программирования.

Перефразирую: нормальные языки, понятные и удобные для старых добрых программистов для которых эти языки стали привычкой и реально, практически применяются по инерции

XC>А хаскели и прочее — это абстрактная околоматематическая сущность. Вроде матлаба или чего-то типа того. ИМХО, в большинстве случаев это даже не "языки программирования", а скорее средства компьютерного моделирования какой-то математической парадигмы или теории. По крайней мере, их разработчики точно не ставят целью создание языка, на котором можно писать к примеру ядра операционных систем или навороченные GUI приложения.

House — операционная система написанная на Хаскель

Здравствуйте, LaptevVV, Вы писали:

LVV>ВСЕ тексты доступны в среде — можно модифицировать, если сильно нужно.
Никогда не видел сырцов компилятора. VCL — да, конечно. Но даже сырцов системных юнитов (не говоря уже про компиль) никогда не видал. С какой версии у них такой сахар тростниковый пошёл?

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, LaptevVV, Вы писали:

LVV>>ВСЕ тексты доступны в среде — можно модифицировать, если сильно нужно.
MD>Никогда не видел сырцов компилятора. VCL — да, конечно. Но даже сырцов системных юнитов (не говоря уже про компиль) никогда не видал. С какой версии у них такой сахар тростниковый пошёл?
Не знаю. Я пользуюсь BB1.5 — там все есть, не только компилятор. Тексты самой среды и всего-всего, что в среде сделано и работает.
Предрелиз сейчас 1.6. А исходники открыли наверное тогда, когда сделали BlackBox свободным — это я и не знаю с какой версии...
На форуме oberoncore.ru могут подробно ответить

Здравствуйте, WolfHound, Вы писали:

_O_>>Очень много проверенных временем тулов (свободных, коммерческих, внутренних и т.д) для создания компиляторов, которые написаны на С/C++ и генерят код на C/C++. Потому удобней взять готовые инструменты а не писать свои.
WH>Они все настолько убоги, что на них даже смотреть противно.
WH>Не то, что пользоваться.

Правильно. Как только начинаешь писать такое на С++, говнокод подавить при всем желании не получится и нужно приседать вокруг крутого языка С/C++.

Здравствуйте, DarkGray, Вы писали:

VD>>Компилятор — это такая же программа как и все другие. Если ее удобно писать, то будет удобно писать и многие другие программы.

DG>сам по себе компилятор — это очень узкий класс задач.

Этот класс задач можно назвать так — "трансформация данных". И узок он примерно так же как талия бегемота.

DG>по сути компилятор — это одна большая функция, которая получает один пакет на вход, потом долго жужжит и выдает один пакет на выход, завершаясь.

По сути любая программа это одна большая (или не очень) функция. И что из того?

DG>а большинство программ работают по другому:
DG>они стартуют, получают в произвольном порядке события, в произвольном порядке меняют свое внутреннее состояние, в произвольном порядке выдают события наружу, и часто могут вообще никогда не завершаться (по крайней мере логически).

Ну, то есть они состоят из ряда маленьких функций которая получает один пакет на вход, потом жужжит и выдает один пакет на выход? Огромные различия с точки зрения используемых возможностей ЯП.

Потом твои знания о современных компиляторах сильно устарели. На сегодня компиляторы стали на много сложнее. Их код используется в IDE, средствах тестирования и т.п. Да и сами они умеют компилировать инкременально, параллельно и т.п.

DG>и если компилятор — это функция, то такая программа — скорее агент (или в упрощенном виде — объект).

Сегодня трудно представить программу которую можно представить в виде одной функции. Любая программа — это куча разнородного кода. Мне смешно объяснять взрослому человеку, что компилятор тут ничем не отличается. В современном компиляторе нет разве что GUI. Хотя в GUI их код так же используется.

Вот Вольвхаунд предлагает использовать в следующей версии немерла реактивный подход. Его в GUI на сегодня мало кто применяет, а ты говоришь "одна функция".

DG>и соответственно если язык обкатывался на описании компилятора, то легко могут быть упущены такие направления как:
DG>обработка и генерация событий,

Это какая-то редкостная ересь. Сообщением является любой вызов функции. Что тут обкатывать? То что в языки проектировавшиеся императивщиками вроде Хельсберга гвоздями прибили события и делегаты еще не значит, что это так и надо. В языках ML-ного ряда исходно были функции высшего порядка. Они решают те же проблемы играючи и применяются в куче мест. Одна беда их событиями не называют. Но в чем разрица между списком функций и событиями дотнета? Три грамма никому не нужного синтаксического сахара — вот и вся разница.

Надеюсь, ты не будешь спорить по поводу того, что в любом ФЯ работа с ФВП продумана и оттестирована до блеска?

Потом современный компилятор — это тебе не компилятор Паскаля времен Вирта. Это в нем теперь используются и события и все остальное, что есть в арсенале ЯП. В прочем, я уже повтояюсь.

DG>описание изменчивого внутреннего состояния,
DG>недетерминированный характер работы программы
DG>и т.п.

Любая программа имеет свое состояние которое изменяется во времени. Вопрос только в том как оно хранится. Компиляторы тут ничем не отличаются.

Вопрос именно в объеме и сложности. Компиляторы, на сегодня, это очень объемные и сложные программы. Они задействуют все возможности языка на котором они пишутся. И даже этого не хватает чтобы удержать сложность компиляторов в разумных пределах. Так что не надо.

VD>Ну, то есть они состоят из ряда маленьких функций которая получает один пакет на вход, потом жужжит и выдает один пакет на выход? Огромные различия с точки зрения используемых возможностей ЯП.

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

Здравствуйте, DarkGray, Вы писали:

VD>>Ну, то есть они состоят из ряда маленьких функций которая получает один пакет на вход, потом жужжит и выдает один пакет на выход? Огромные различия с точки зрения используемых возможностей ЯП.

DG>если программа — это одна функция из миллиона операций, то, в первую очередь, нужен инструмент который упрощает работу с операциями, но если программа миллион функций по одной операции, то, в первую очередь, нужен инструмент который упрощает работу с набором функций и мало критичен инструмент для работы с операциями.

Не бывает работающих программ состоящих из одной функции. Любая "большая функция" состоит из множества вызовов функций по меньше. И совершенно по барабану кто и как вызывает эти функции. Сложность в их количестве, точнее в интеллектуальной сложности задачи.

Инструменты для борьбы с миллионом операций и с миллионом функций одни и те же — это средства инкапсуляции. Чем они мощнее, тем более сложные задачи можно решать с помощью языка.

Здравствуйте, DarkGray, Вы писали:

DG>а большинство программ работают по другому:
DG>они стартуют,
DG>получают в произвольном порядке события,
DG>в произвольном порядке меняют свое внутреннее состояние,
DG>в произвольном порядке выдают события наружу,
DG>и часто могут вообще никогда не завершаться (по крайней мере логически).

Недавно кто-то кидал ссылку на подборочку видео с конференции Scala Exchange 2011. На одном из них Одерски рассказывал про новый Eclipse plugin и какие изменения в логике компилятора были сделаны для его поддержки. Так вот, ты не поверишь...

Здравствуйте, jazzer, Вы писали:

BZ>>ghc вроде целиком на хаскеле написан. на C там RTS

J>Ага, в результате его не установить по-человечески, если в системе уже нету ghc.

Не знаю ничего. `emerge ghc` вставал безо всяких плясок. Правда, компилялся он долго почти как OpenOffice без ccache, но хоть это и вызывало у меня массу недоумения "чего ж там такого понаворотили", к простоте установки это не имеет отношения.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, jazzer, Вы писали:

BZ>>>ghc вроде целиком на хаскеле написан. на C там RTS

J>>Ага, в результате его не установить по-человечески, если в системе уже нету ghc.

D>Не знаю ничего. `emerge ghc` вставал безо всяких плясок. Правда, компилялся он долго почти как OpenOffice без ccache, но хоть это и вызывало у меня массу недоумения "чего ж там такого понаворотили", к простоте установки это не имеет отношения.

Ну я рад за вас, безусловно.
Но у меня на работе нет доступа к установке дистриб-пакетов, это только админы могут делать.
Так что я могу только качнуть исходники и собрать сам.
Вот тут геморрой и начинается.
Нормальным пакtтам (99% по моему опыту) достаточно для сборки простого gcc, они сам все, что надо для бутстрапа, им соберут.
GHC к таковым явно не относится. Т.е. может уже и относится, это было бы замечательно, но когда я пробовал последний раз, он без уже установленного ghc собираться не желал, и последовательный откат на несколько версий назад ничего не дал.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, dimgel, Вы писали:

D>Недавно кто-то кидал ссылку на подборочку видео с конференции Scala Exchange 2011. На одном из них Одерски рассказывал про новый Eclipse plugin и какие изменения в логике компилятора были сделаны для его поддержки. Так вот, ты не поверишь...
Что-то страшное у них получилось.
Интеграция немерле сделанная по тому же принципу работает куда лучше.

Здравствуйте, WolfHound, Вы писали:

WH>Что-то страшное у них получилось.

ХЗ, не щупал. (У меня lib.web под 2.9 вообще не компилируется, и не до неё сейчас разбираться.) Из видео мне крайне не понравилось, что цепляются только файлы, загруженные в IDE. Т.е. если у меня модуль с двадцатью зависимостями из этого же проекта, мне либо надо все двадцать найти и открыть в других вкладках, либо ловить ошибки компиляции. Бред какой-то.

WH>Интеграция немерле сделанная по тому же принципу работает куда лучше.

У вас тоже полноценный компилятор к IDE прикручен и тоже с возможностью компиляции поддерева (тагетирование или как его там)? Прикольно, значит вот какие нынче православные веяния в сей далёкой от моей бренной жизни области.

Здравствуйте, dimgel, Вы писали:

D>ХЗ, не щупал. (У меня lib.web под 2.9 вообще не компилируется, и не до неё сейчас разбираться.) Из видео мне крайне не понравилось, что цепляются только файлы, загруженные в IDE. Т.е. если у меня модуль с двадцатью зависимостями из этого же проекта, мне либо надо все двадцать найти и открыть в других вкладках, либо ловить ошибки компиляции. Бред какой-то.
Вот я и говорю что-то страшное у них получилось.
Интеграция немерле таким не страдает.

D>У вас тоже полноценный компилятор к IDE прикручен
Ага.

D>и тоже с возможностью компиляции поддерева (тагетирование или как его там)?
Насколько я понимаю немерле строит полное дерево типов проекта.
А методы типизируются по требованию.
Но тут лучше Влада спросить.

D>Прикольно, значит вот какие нынче православные веяния в сей далёкой от моей бренной жизни области.
По-другому делать просто не разумно.
Код компилятора (не считая кодогенерации) и интеграции с ИДЕ совпадает чуть менее чем полностью.
Так зачем его писать два раза?