?

Log in

No account? Create an account

Специализни шаблонца!

Previous Entry Поделиться Next Entry
Моя борьба с языками программирования
Vash
udpn
Люди разработали кучу клёвых ЯП.

Есть С++. Язык с zero overhead, на котором написано дофига кода.
Есть Haskell. Красивый язык, на котором тоже дофига кода, но работает медленно.
Есть Agda. Просто офигенный язык, который уже практически нельзя использовать.
Есть ATS. Клёвый, но похож на говно. И зависимые типы в нём не зависимые, а так, говно.
Есть DDC. Это Haskell, в котором эффекты и монады не одно и тоже, поэтому не-говно.

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

1) zero overhead
2) высокая производительность
3) абстрактность (высокий code reuse)
4) доказательное программирование
5) хороший синтаксис
6) использование имеющихся библиотек
7) рефакторинг legacy кода на месте

Ограничений много. Начинать нужно с того, которое добавить тяжелее всего. Глядя на то, как уже долгие годы люди пытаются догнать С++ (Си я не рассматриваю, потому что почти строгий сабсет), можно сделать вывод, что это zero overhead (хотя это может быть и неправдой).

Можно писать с нуля. Для этого нужно в голове держать больше понятий, чем можно удержать.
Можно транслировать. Если транслировать только из своего языка в C++, может получиться что-то хорошее.
При этом не нужно забывать, что транслировать, рассчитывая, что код будет сразу откомпилирован, нельзя, потому что библиотеки и legacy код на С++.

Можно добавить дополнительный синтаксис в язык, который будет биндить определения транслируемого языка (которые будут выглядеть как примитивы) к определениям С++. Например, сказать, что в
data Bool = True | False
нужно
bind Bool type 'bool'
bind True value 'true' -- может, r-value? здесь должны использоваться понятия С++
bind True value 'false'

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

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

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

Значит язык обязан поддерживать синтаксис С++. Так как мы собираемся добавлять в него ещё всякие ништяки, обычный бэкенд не подойдёт, он нашего синтаксиса не знает.

Можно переписать чужой бэкенд. Если он написан на С++, задача становится неподъёмной, потому что там сотни KLOC какого-то пьяного угара (это я про gcc, и в существенно меньшей мере, про clang). На других языках я не нашёл.

Хотя можно и не углубляться в семантический анализ и обойтись синтаксическим, вырезав его, например, из Scalpel или Elsa. Или обойтись частью семантического анализа вроде иерархии символов.

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

Короче говоря, сейчас ставлю себе свежую test suite для компиляторов С++ версии 1.48.0, настраиваю VS2010 (надеясь, что она это потянет), чтобы откомпилить Scalpel, и собираюсь окончательно попрощаться с адекватностью.


я примерно с этих же посылок начинал HNC. В таком виде план нереален, ибо невыполним одним ленивым человеком без финансирования. Как протрезвею, будем обсуждать

Это все прекрасно. Особенно если в ограничения добавить:
REPL
ФВП
Бактракинг (как в прологе)
Передачу сообщений (как в смаллталке)
Продолжения
Макросы (как в m4? как в лиспе?)
Паттерн-матчинг
JIT-компиляцию
Нормальные (как в лиспе) исключения
Спецификацию методов по нескольким параметрам
И еще кучу всего, что не учтено в посте и не может быть учтено одним человеком (невозможно быть знакомым со всем хорошим в этом мире) и точно также не может быть учтено комитетом таких людей (погрязнем в спорах)

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

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

Кстати, что это за Agda и чем она хороша?

А с каких пор "есть DDC"? Last time I checked он был в 100 раз тормознее хаскеля, т.е. его считай нет вообще. Как и Deca.

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

>> А с каких пор "есть DDC"?
С тех пор, как я увидел, как он выводит тип map с эффектами. Я думал, что это невозможно.

>> Плясать от плюсов мне кажется гиблой затеей. Уж лучше допиливать хаскель/агду/ддц/вотева до нормальной производительности.
Так почему же на хаскелле/агде/ддц/вотева никто даже не попытался написать библиотеку вроде uBLAS или Blitz++? Улучшать производительность языка не имея реального кода, на котором можно посмотреть, что там в assembly улетает, смысла не имеет вовсе. Кажется, ленивость, GC и прочие прелести функциональной жизни делают допиливание невозможным, поэтому никто из людей, способных на это, не берётся.

> Можно писать с нуля. Для этого нужно в голове держать больше понятий, чем можно удержать.
> Можно транслировать. Если транслировать только из своего языка в C++, может получиться что-то хорошее.

Вот мне непонятен момент, который должен лежать где-то здесь. Суровая функциональщина предполагает компилирование в CPS, а в C++ и товарищах стэк да циклы. В связи с чем вопрос: это для связи со старыми языками или же это часть zero overhead с отрезанием лишнего? Как при этом должны обстоять дела с рекурсией, со сложными циклами в dependecy analysis?

>> Суровая функциональщина предполагает компилирование в CPS
Неимоверно суровый ATS транслирует в C++. Не знаю, использует ли он CPS как промежуточное представление, но что-то мне подсказывает, что нет. Почему вы считаете, что функциональный код обязан (я ведь правильно понял вас?) быть представлен в виде CPS?

>> В связи с чем вопрос: это для связи со старыми языками или же это часть zero overhead с отрезанием лишнего?
Вопрос не понял. Переформулируйте, пожалуйста.

>> Как при этом должны обстоять дела с рекурсией, со сложными циклами в dependecy analysis?
Императивный код будет обрабатываться так же, как и ранее.
Функциональный код будет обрабатываться так же, как обрабатывается функциональный код.
Если человек мешает одно с другим, например биндит non-pure функцию как конструктор к ADT, то сам себе злобный буратино. С другой стороны, не вижу ничего плохого в том, что строгий fold будет обычной императивной чистой функцией с циклом. Смешанный код имеет довольно дерьмовую семантику (Scheme это прекрасно подтверждает), поэтому нужно разрешать только такое смешивание, которое облегчает рефакторинг (остальное отправлять в категорию UB или, если совсем ересь, запрещать).

>...Legacy код придётся переписывать руками, что никому не нужно. Значит язык обязан поддерживать синтаксис С++. Так как мы собираемся добавлять в него ещё всякие ништяки...

Если язык будет фактически включать в себя С++, он автоматически станет говном, т.к. в том, что сам С++ говно (пусть и неизбежное местами) согласны все. И подобно тому, как ряд проблем С++ вызван наличием внутри него С, так и в этом новом С++++ ничего не взлетит по причине наличия С и С++ внутри. Даже строгую типизацию и безопасное обращение с памятью не сделать.

>> т.к. в том, что сам С++ говно (пусть и неизбежное местами) согласны все
Изначально пост начинался с фразы "все знают, что С++ - говно", но я решил его убрать, чтобы меня наконец-то перестали обвинять в троллинге. Забавный тренд.

>> Даже строгую типизацию и безопасное обращение с памятью не сделать.
Почему же не сделать?
Пуссть у вас есть два модуля, один на С++, второй на Хаскелл. Вы их компилируете в объектные файлы. Код на Хаскелле строго типизирован и относительно безопасен по памяти.
Пусть у вас есть один модуль, в нём волшебным образом можно писать блоки кода на С++ и Haskell. Если некоторая функция на Хаскелл использует только функции на Хаскелл, всё работает точно так же.
Пусть у вас есть один модуль, где языки смешались окончательно. Есть well-behaved subset из С++ (чистые функции, шаблоны, принимающие только typename), есть well-behaved subset Haskell (конечные данные, все функции), их совместное использование совершенно безопасно. Есть всякая хрень из обоих языков, используя которую мы сразу, резко и болезненно начинаем палить себе по ногам.
В чём проблема-то?

Слухайте, слухайте.

Bool, конечно, не равно сумме лжи и истины.

А если возьмёте интуиционистские истины, то вообще суммой не обойтись.

Я что хочу сказать.

Не спешите обсуждать или тем более осуждать. Сначала надо понять.

Чтобы написать что-то лучшее, чем X, нужно понять X. C++ я понял и все котлеты от мух для себя разделил. В Haskell где-то половину уже отделил. По остальным направлениям там "WTF" по поводу практически всего подряд. Я эти языки добавил в список потому, что они частично исправляют известные мне ошибки в первых двух. Про оборотную их сторону я знаю мало, по большей мере, с чужих слов, поэтому критиковать их не могу и не берусь.

От того, что люди, которые не используют перегрузку операторов и шаблоны, начнут их использовать - как раз случится страшное. Их код превратится в тыкву, ибо 90% - используют они их не там и не так, как надо.

Ну не нужно так уж преувеличивать.

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

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

хотя, конечно, вопрос что тебе больше интересно

clang конечно страшен, но *я* рассматриваю это как удобный случай отрефакторить под/на новый язык

Edited at 2012-01-18 13:26 (UTC)

Там синтаксический анализ от семантического разделён? Я имею в виду следующее: после синтаксического анализа получается синтаксическое дерево или сжатый синтаксический лес?

а давайте из этого сделаем типа вики?

я конкретно могу раскидать вот это вот обсуждение в вики-формат, и дальше поддерживать (тут надо написать подробнее)

причем *главного* (апдейт: главнокомандующего) не будет -- у каждого будет свой репозиторий с со своей версией, если он не согласен с чужой

Edited at 2012-01-18 13:38 (UTC)

Вы давно предлагали похожее для HNC, делайте и шлите сообщение в гитхабе!

Я в своем форке буду обсирать обсуждать эти идеи в применении к HNC.