Zealint писал(а):
Тут есть, как Вы верно намекаете, косвенная связь. Дело в том, что определённые особенности реализации библиотек могут довольно сильно зависеть от того, какие синтаксические конструкции предоставляет язык. Привожу пример: в C++ не было «лямбд», зато были извращения с разнообразными и трудночитаемыми указателями на функции, прописать полное определение которых можно было только в несколько строк. Теперь стало проще
...
Так вот, я бы хотел, чтобы синтаксис был продуман настолько, чтобы не возникало подобных неудобств, заставляющих многие естественные для математика операции выполнять неестественным образом.
Самое важное в данном случае, это то, что вы называете "неудобствами" на самом деле является
отсутствием соответствующих удобств, т.е. все эти лямбды и R-value references являются специально разработанными конструкциями и языковыми механизмами, которые
привносят удобство. Соответственно, задача разработчика - придумать такие механизмы, которые облегчают работу программиста и математика. Поэтому я вижу смысл разработки языка в тщательном анализе и селекции существующих механизмов и в разработке новых.
Zealint писал(а):
Тогда желательно, чтобы компилятор умел нормально объединяться с известными ассемблерами. Это далеко не всегда обеспечено. Ещё один вариант - так называемые intrinsics функции.
Intrinsic functions не являются эквивалентом ассемблерных вставок, т.к. не дают возможность реализовать свой функционал. Проблем с написанием функций целиком на ассемблере я не вижу, главное - соблюдать соглашения о вызовах и писать соответствующие прототипы функций в заголовочных файлах.
Zealint писал(а):
Как Вы видите свою идею для реализации, например, типа данных Int72? Даже если так, всё равно доступ к флагу переноса бывает нужным сам по себе, без ADC. Конечно ADC rax, 0 может выдать нам этот флаг, но уж больно это по-инвалидски. Тем более, это вынуждает использовать константу 0, которую а ассемблере как-то редко принято использовать в таком контексте
Int72 - не вижу проблем. Умножения отбрасывают лишние разряды, сложения/вычитания добавляют перенос после операции с 64 битами к 8 битным операндам.
Тут дело вот в чём. С математической точки зрения, операция умножения всегда возвращает результат удвоенного размера. Сложение/вычитание всегда дают результат на один бит больше. То есть флаг переноса на самом деле не всегда является в полном смысле слова таким же признаком, как, например, признак нуля или знака. Это именно дополнительный значащий бит, поэтому в данной ситуации для компилятора важно это понимать. По поводу ADC RAX, 0, - конечно, выглядит это не очень красиво, но серьёзных неприятностей я в этом не вижу, тем более, что константы зачастую кодируются меньшим количеством бит, чем требует операнд. Ещё один момент заключается в том, что старший бит вряд ли часто потребуется извлекать отдельно. Чаще всего он будет использоваться именно в цепочках операций. Так что ничего неприятного/неэффективного в данной особенности я не вижу.
Zealint писал(а):
Есть жёсткие функциональные языки, однако они слабо повлияли на создание и популяризацию архитектуры ЭВМ, которая была бы чем-то похожа на такую парадигму.
Я всегда выступал с резкой критикой функциональных языков.
Zealint писал(а):
Напротив, популярные архитектуры скорее похожи на императивные языки. Эти языки развивались под действием этой архитектуры и вообще образа алгоритмического мышления в виде последовательности команд. Иными словами, раз у нас архитектура x86 или любая на неё концептуально похожая, то и язык должен быть уже императивным. Не вполне уверен, что декларативный язык (в т. ч. функциональный) будет хорошо ложиться на такую архитектуру...
Я бы сказал так:
1. Функциональщина вообще не даёт (и не может дать) никакого прироста в скорости работы программы. Ухудшить - легко.
2. Невозможно сделать аппаратную архитектуру, заточенную под ФП.
Так что об ФП в плане панацеи (или даже толчка) эффективности можно забыть.
Zealint писал(а):
Разработчику языка следует очень хорошо изучить неоднозначности других языков, поскольку порой они удивляют даже опытных программистов.
Полностью согласен.
Zealint писал(а):
pavia писал(а):
Для создания Си++ надо несколько десятков человеко лет. Компиляторы в одиночку не пишутся. И столько же надо для создания библиотек.
Такие вещи делаются коллективами и длиною 5-7 лет.
Да, согласен, только я бы увеличил срок лет на 10 хотя бы.
Компилятор с (объектно-ориентированного) языка (с автоматическим сбором мусора) COOL в архитектуру MIPS пишется одним человеком за 2-3 месяца. Проверено практикой.
Компилятор с языка С++ стандарта 2011 со всем toolchain пишется одним человеком в свободное от работы время за два года.
Собс-но, я не к тому, что это пара пустяков, но не стоит преувеличивать сложность создания рабочего компилятора даже по самым продвинутым стандартам. Основная сложность заключается в разработке
оптимизации. Это - да, может отнять много человеко-лет.
Zealint писал(а):
Например, в Maple есть возможность вводить формулы и получать результат в подобном виде, только, к сожалению, редактор решительным образом ужасно реализован и формулы там уродские. Можно ли сделать лучше, я не знаю. Но такой вариант работы с формулами мне нравится гораздо больше.
Есть сила привычки и ограниченный набор символов, которые удобно набирать с клавиатуры, а также всего 10 пальцев, два из которых стучат по пробелу. Поэтому трудно представить редактор, который позволил бы достаточно эффективно (по времени) набирать код вроде такого:
Да, мне тоже сложно себе представить набор программ в таком виде. По крайней мере, про текстовые редакторы придётся забыть.
Zealint писал(а):
С одной стороны (по моему мнению) программы, написанные в таком стиле, будут не только удобнее читать и понимать, но и проще делать их более компактными, так как богатый выбор возможностей набора формул и наличие разнообразных символов, например, utf-8, позволит сократить лексические извращения
Сначала кажется, что использование UTF-8 облегчает эту задачу. Однако, если покопать, открывается куча подводных камней. ОС Windows заточена под использование кодировки Win-1251, поэтому переносимость сразу теряется. А разновидности виндовс - это подавляющий процент рынка, забить на него нельзя. Далее, символы в юникоде разные, есть, например, пробел, разные тире. Как отличать, что относится к идентификаторам? Современные стандарты С/С++ разрешают использование символов UTF-8 в именах идентификаторов, однако при этом используется куча дополнительных регламентирующих таблиц. Поскольку юникод активно развивается, эти таблицы наверняка будут меняться, а значит надо менять компилятор только из-за смены смысла какого-то символа. В результате пока что все современные компиляторы, поддерживающие юникод, на таблицы забили и я полагаю, у разработчиков при упоминании совместимости со стандартом в данной части начинается сильная мигрень.
В общем, это тот самый случай, когда за 30-40 лет накопился ком проблем, который пока не очень понятно, с какого конца раскручивать. Лично я пока что для себя решил так: национальные символы запрещены. Собс-но, это не означает, что они запрещены
навсегда. Разрешить их использование потом - не проблема. А вот менять что-то в уже использующихся кодах - может превратиться в очередную головную боль и до ужаса кривые стандарты. Лучше перетерпеть лет 10 и не гнаться за прогрессом вместе с толпой, эта толпа может завести не туда.
Zealint писал(а):
Возьмите тот же
vim, кто из профессионалов набора в нём не «ломал» поначалу пальцы? И ничего, не нарадуются этим инструментом, судя по подобным статьям.
Ага, пол-года бессонных тренировок...
Нет уж, инструмент должен быть достаточно удобен, чтобы им без проблем мог начать пользоваться новичок. VIM к этим инструментам явно не относится.
Zealint писал(а):
Предвижу вопрос: как такое компилировать? На самом деле ясно, что есть некий внутренний формат, невидимый для пользователя, который представляет из себя обычную последовательность символов в одну строку. Он и компилируется, а отображается лишь графическая интерпретация такого кода. Самое трудное здесь я вижу в том, чтобы редактор кода правильно понимал, что делает пользователь, так как в Maple это не всегда так и порой приводит к невидимым ошибкам, определить которые можно лишь удалив всю строку и переписав её заново.
Самое трудное в этом - безболезненная смена редактора. В вашем случае потребуется визуальный редактор и программу невозможно будет редактировать в любом другом стандартном текстовом редакторе.