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

_>>Да, да, им про это уже не раз писали. И они не раз дежурно отмахивались, что сейчас на это нет ресурсов (людей). Не понимая, что это должно быть не ещё одним побочным направлением развития, которое возможно сделает кто-то из сообщества, а именно главным направлением, над которым должен работать главный разработчик.
VD>Орлы, вы поймите, создание современного ЯП — это огромный труд. Большая часть работы по нему не зависит от платформы, так как это код парсинга, тапизации, и т.п. Не сделав всего этого говорить о платформах просто смешно.
VD>Но если вы хотите иметь найтив-продукт, то в этом нет никаких проблем. Просто присоединяйтесь и я вам расскажу, что нужно сделать, чтобы получить нэйтив-реализацию. Там все не так уж сложно. Но без вашей помощи мы не справимся.

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

1. Все ваши инструменты бутстрапятся, правильно? Т.е. если мы вдруг реализуем компиляцию "hello world" в нейтив на базе ваших существующих .net компиляторов, то потом автоматически получим нативную версию всех инструментов (в первую очередь компилятора, ну и всего остального что у вас там есть)?

2. Насколько язык заточен на CLR? Т.е. от каких из негативных моментов CLR можно будет отказаться при переходе на нативный код, а от каких нельзя. В первую очередь речь о: сборщике мусора, интроспекции времени исполнения (рефлексии, от которой кстати отказываются в .net native), ссылочных (а не на стеке, кстати тоже пытаются ввести в будущем в .net) объектах, неэффективных дженериках и делегатах. А так же насколько доступны unsafe возможности (например арифметика указателей) CLR и можно ли их расширить ещё дальше (нативное выделение памяти и т.п., кстати тоже пытаются ввести определённым образом в будущем в .net)..

3. Насколько язык заточен на библиотеку .Net. Именно язык, а не предоставление .net в качестве стандартной библиотеки языка для пользователя (т.е. речь об аналоге взаимоотношений new и VirtualAlloc из C++). Саму библиотеку для пользователя на самом деле написать не так сложно (полно готовые открытых разработок на эту тему). А в самое первое время можно вообще обойтись возможностью доступа к API ОС (для нативного кода это естественно). В отличие от потребностей самого языка, которые надо будет или переделывать внутри или реализовывать функции аналогичные .net.

В зависимости от ответов можно сделать вывод о том, что с помощью например таких (https://habrahabr.ru/post/119850/) инструментов можно сделать нативную реализацию:
— легко
— сложно
— сложно и не нужно (потому что нативная реализация языка с такими врождёнными пороками просто не нужна).

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

_>1. Все ваши инструменты бутстрапятся, правильно? Т.е. если мы вдруг реализуем компиляцию "hello world" в нейтив на базе ваших существующих .net компиляторов, то потом автоматически получим нативную версию всех инструментов (в первую очередь компилятора, ну и всего остального что у вас там есть)?

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

Естественно при этом есть нюансы.
1. АПИ — компилятор использует ряд вызовов рантайма. Их надо воспроизвести в целевом рантайме. Собственно мы используем минимум:
* Работа со строками в формате UTF-16 (классы string и StringBuilder).
* Коллекции (List<T>, HashSet<T>, Dictionary<R, V>, ImmutableArray и т.п.) все это есть в исходниках в библиотеках на гитхабе. Да и написать с нуля не долго.
* Чтение и запись файлов.
* Динамическая загрузка библиотек, создание экземпляра объекта и вызов его метода (это нужно для динамической расширяемости).

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

Конечно же код работы непосредственно с IDE просто перекомпилировать не удастся. У все IDE свои АПИ. Для них надо писать фронтэнд вручную. Движек же IDE у нас работает в отдельном процессе и взаимодействует с фронтэндом через именованные каналы. Так что сервер может работать на платформе отличной от той на которой работает IDE. Фронтэнд у нас очень тонкий. Логики там нет. Он просто должен реализовывать АПИ IDE и преобразоывать их в посылку и прием сообщений IDE-серверу живущему в отдельном процессе.

_>2. Насколько язык заточен на CLR?

Тут, для начала, надо определиться о том, что понимать под понятием "язык". Мы делаем язык для "написания языков" (т.е. компиляторов и тулинга). Называется он Nitra. При его разработке используется как он сам, так и код на языке общего назначения — Nemerle. Сейчас используется Nemerle 1.2.х, который написан сам на себе с применением все того же бустрапинга. Его минус в том, что он не поддерживает сменяемые бэкэнды. В процессе работы над Нитрой мы хотим переписать сабсэт Nemerle используемый в Нитре на Нитре, чтобы забутстрапить и Нитру, и этот сабсэт Нимерла с использованием бэкэндов. В принципе можно было бы перевести на бэкэнды и старый Немерл. Но я в этом не вижу особого смысла. Работы много, толку мало.

В Нитре и этом сабсэте Немерла используются:
1. Автоматическое управление памятью. Для компилятора можно просто выделять память из одного непрерывного блока и тупо забить на его освобождение (делать его для всего пула в конце компиляции). Будет перерасход процентов в 10-20, но учитывая объемы современной памяти — это не критично. На первое время сойдет. Ну, или реализовать самый примитивный вариант GC и вызывать сборку мусора вручную в известных точках. Для движка IDE такой способ будет неприемлем, но для компилятора — прокатит. Далее, конечно, надо реализовать точный GC на основе поколений или один из новомодных алгоритмов. Еще один вариант — реализовать автоматическое управление памятью на базе подсчета ссылок. По сути это ограниченный ЖЦ.
2. Динамическая загрузка кода. Грамматики, код типизации и бэкнд помещаются в библиотеки. Во время исполнения они подгружаются как в компилятор, так и в движок IDE. Там они компонуются с другими такими же сущностными и получается конечный парсер, типизатор и бэкэнд. Эту часть можно абстрагировать в виде АПИ и реализовать для каждой из платформ на базе их родного АПИ. Подгружаемые типы являются монотипными (т.е. не обобщенными).
3. ООП дотнетного типа:
* Классы с одним предком.
* Интерфейсы с множественным наследованием.
* Виртуальные таблицы.
Тут нужна поддержка в рантайме. Таблицы интерфейсов и виртуальная таблица методов. Собственно как это все делается известно. Но это требует реализации.

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

Нитра предоставляет сериализацию символов и АСТ-а. Так что дженерики можно будет записывать в библиотеки в виде АСТ-а и символов, а потом материализовывать их для конкретных типов (как шаблоны С++ только без исходников).

Рефлексия нами по сути не используется. Только для той самой подгрузки грамматик (что может быть абстрагированно).

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

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

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

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

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

_>3. Насколько язык заточен на библиотеку .Net. Именно язык, а не предоставление .net в качестве стандартной библиотеки языка для пользователя

Этого вообще не понял. Языку просто по фигу какая там у него библиотека. Вот библиотека от языка зависит. Если у нас язык с ЖЦ, то и в библиотеке должны быть ЖЦ-типы.

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

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

_>>1. Все ваши инструменты бутстрапятся, правильно? Т.е. если мы вдруг реализуем компиляцию "hello world" в нейтив на базе ваших существующих .net компиляторов, то потом автоматически получим нативную версию всех инструментов (в первую очередь компилятора, ну и всего остального что у вас там есть)?
VD>Упрощенно говоря — да. Компилятор языка это текст плюс ратнтайм, плюс используемый внешний АПИ. Если мы можем компилировать этот текст самим собой, то все что нужно для переноса языка на другую платформу — это скомпилировать себя собой с бэкэндом для этой платформе.

Отлично.

VD>Естественно при этом есть нюансы.
VD>1. АПИ — компилятор использует ряд вызовов рантайма. Их надо воспроизвести в целевом рантайме. Собственно мы используем минимум:
VD>* Работа со строками в формате UTF-16 (классы string и StringBuilder).
VD>* Коллекции (List<T>, HashSet<T>, Dictionary<R, V>, ImmutableArray и т.п.) все это есть в исходниках в библиотеках на гитхабе. Да и написать с нуля не долго.

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

VD>* Чтение и запись файлов.
VD>* Динамическая загрузка библиотек, создание экземпляра объекта и вызов его метода (это нужно для динамической расширяемости).

VD>Если брать не только компилятор, но и движок IDE, то нужны еще:
VD>* Именованные каналы для общения с сервером движка IDE.
VD>* АПИ по работе с потоками и процессами для организации параллельных вычислений.

Ну а это всё по сути прямые обёртки над функциями ОС и пишется элементарно.

Кстати, раз вы таких специалисты по парсингу и т.п., то при переходе нативный код я бы на вашем месте первым делом решил такую простую задачу: автоматическую конвертацию заголовочных файлов из WindowsSDK (или Linux — разницы нет) в декларацию чужих импортируемых функций на вашем языке. Если будет такой простейший конвертер (кстати, помнится для каких-то языков я такое уже видел), то это решит огромное число проблем и сходу (даже без создания своей библиотеки языка) позволит писать полноценные приложения (в том числе и с GUI и всем остальным).

VD>Конечно же код работы непосредственно с IDE просто перекомпилировать не удастся. У все IDE свои АПИ. Для них надо писать фронтэнд вручную. Движек же IDE у нас работает в отдельном процессе и взаимодействует с фронтэндом через именованные каналы. Так что сервер может работать на платформе отличной от той на которой работает IDE. Фронтэнд у нас очень тонкий. Логики там нет. Он просто должен реализовывать АПИ IDE и преобразоывать их в посылку и прием сообщений IDE-серверу живущему в отдельном процессе.

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

_>>2. Насколько язык заточен на CLR?
VD>В Нитре и этом сабсэте Немерла используются:
VD>1. Автоматическое управление памятью. Для компилятора можно просто выделять память из одного непрерывного блока и тупо забить на его освобождение (делать его для всего пула в конце компиляции). Будет перерасход процентов в 10-20, но учитывая объемы современной памяти — это не критично. На первое время сойдет. Ну, или реализовать самый примитивный вариант GC и вызывать сборку мусора вручную в известных точках. Для движка IDE такой способ будет неприемлем, но для компилятора — прокатит. Далее, конечно, надо реализовать точный GC на основе поколений или один из новомодных алгоритмов. Еще один вариант — реализовать автоматическое управление памятью на базе подсчета ссылок. По сути это ограниченный ЖЦ.

Печально это конечно. Подсчёт ссылок — это ужасно (в смысле как универсальное решение для всей памяти). GC лучше, но тоже не очень (при этом его реализация очень не тривиальна).

VD>2. Динамическая загрузка кода. Грамматики, код типизации и бэкнд помещаются в библиотеки. Во время исполнения они подгружаются как в компилятор, так и в движок IDE. Там они компонуются с другими такими же сущностными и получается конечный парсер, типизатор и бэкэнд. Эту часть можно абстрагировать в виде АПИ и реализовать для каждой из платформ на базе их родного АПИ. Подгружаемые типы являются монотипными (т.е. не обобщенными).

Да, это очевидно всё.

VD>3. ООП дотнетного типа:
VD>* Классы с одним предком.
VD>* Интерфейсы с множественным наследованием.
VD>* Виртуальные таблицы.
VD>Тут нужна поддержка в рантайме. Таблицы интерфейсов и виртуальная таблица методов. Собственно как это все делается известно. Но это требует реализации.

Тут тоже всё тривиально (по сути никаких внутренних отличий от C++, так что можно взять готовую эффективную реализацию). Только вот есть один вопрос, который я уже упоминал, но не увидел на него ответа. Что у нас с разделением на типы ссылки и значения? В .net у нас экземпляры классов только ссылочные — это не эффективно. Должны быть и ссылочные механизмы и нормальные объекты-значения. И в памяти и на стеке.

VD>Дженерики, конечно же нами тоже используются, но в рамках обобщенных типов данных. Никаких динамических загрузок обобщенных типов не требуется, так что их можно реализовать путем генерации специализаций.
VD>Нитра предоставляет сериализацию символов и АСТ-а. Так что дженерики можно будет записывать в библиотеки в виде АСТ-а и символов, а потом материализовывать их для конкретных типов (как шаблоны С++ только без исходников).

Позитивно.

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

Вообще отлично.

VD>Таким образом каждый сможет создать для себя свой набор необходимых ему фич. Если тебе не хочется использовать автоматическое управление памятью и ты согласен выписывать руками конструкторы с деструкторами, а так же следить за памятью вручную, то можешь просто сделать расширение с ручным управлением памятью.

Нуу тут опять же есть нюансы. Совсем ручное управление (как в C) мало кому интересно (хотя опять же должно быть доступно в языке, хотя бы в каком-то unsafe режиме). А при полуавтоматическом (умные указатели и т.п.) могут всплывать различные проблемы типа "восходящего фунарга" и т.п. В том же C++ эта проблем сейчас по сути решена благодаря введению в язык семантики перемещения. Но это уже по сути глобальная правка всего языка, а не просто изменение одной мелкой подсистемы (выделения памяти).

_>>3. Насколько язык заточен на библиотеку .Net. Именно язык, а не предоставление .net в качестве стандартной библиотеки языка для пользователя
VD>Этого вообще не понял. Языку просто по фигу какая там у него библиотека. Вот библиотека от языка зависит. Если у нас язык с ЖЦ, то и в библиотеке должны быть ЖЦ-типы.

Речь о том, какие функции .net используются рантаймом (а не библиотекой) языка — их же придётся заменять на вызовы к ОС. Я уже приводил пример, что допустим рантайму C++ необходим доступ к функциям типа VirtualAlloc, VirtualFree и т.п. Плюс там обычно используются различные синхронизации (типа критических секций) и некоторые нюансы многопоточности (типа tls).

===============================================================================

Вообще пока что судя по твоим словам всё относительно позитивно, хотя есть и серьёзные проблемы. Из того, что я прочитал, какую-то реализацию сложнее прямых обёрток вокруг системного АПИ требуют только:

1. Своя библиотека контейнеров (в принципе элементарно)
2. Какое-то управление памятью — а это слооожно (если хотим эффективно).

Остальное получается по идее портируемо в режиме Ctrl+C/Ctrl+V.

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

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

Дык оно так и есть. Просто библиотека и есть часть рантайма для компилятора.

_>А от рантайма должны требоваться грубо говоря только функции выделения и освобождения (если без GC) памяти.

А вот так не бывает. Библоитека она всегда рассчитана на язык. Там масса нюансов.

_>Ну а это всё по сути прямые обёртки над функциями ОС и пишется элементарно.

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

_>Кстати, раз вы таких специалисты по парсингу и т.п., то при переходе нативный код я бы на вашем месте первым делом решил такую простую задачу: автоматическую конвертацию заголовочных файлов из WindowsSDK (или Linux — разницы нет) в декларацию чужих импортируемых функций на вашем языке. Если будет такой простейший конвертер (кстати, помнится для каких-то языков я такое уже видел), то это решит огромное число проблем и сходу (даже без создания своей библиотеки языка) позволит писать полноценные приложения (в том числе и с GUI и всем остальным).

Мы конечно специалисты по парсингу и спарсить заголовочные файлы С не является особой проблемой, но опять же у нас не 100 рук. Плюс тут нужно не только парсить уметь, но и помнить все нюансы работы с этими АПИ. Если с АПИ Винды я еще знаком (хотя уже лет 15 с ними не возился), то с линукосовыми или iOS-ыми я не знаком совсем. Стало быть я плохой кандидат на эту задачу. А вот помочь с парсингом — это пожалуйста.


_>Тут наверное просто стоит определиться, для какой из известных кроссплатформенных IDE вы в первую очередь захотели бы написать плагин. Собственно их вообще таких не много. Но для начал достаточно одной, чтобы хотя бы демонстрация технологии была.

Тут опять таки лучше чтобы такой задачей занимались люди которые близки к этой платформе и этой IDE. Я шарю в MS VS. Для нее я реализацию написал. А вот написть тоже для Эклипса какого или IDEA мне будет проблематично. В то же время я могу элементарно объяснить что надо делать спецу в этих технологиях и он спокойно за месяцок-другой ненапряжной работы это сделает. Движок ведь уже отлажен.

_>Печально это конечно. Подсчёт ссылок — это ужасно (в смысле как универсальное решение для всей памяти). GC лучше, но тоже не очень (при этом его реализация очень не тривиальна).

Да нет ничего печально. Просто ты дико предвзят (причем не по делу) к GC. А для компилятора нет ничего впечатлительного и в тупейшем "нарезателе" памяти. Компилятор программа пакетная. Собрала данные, обработала, выплюнула исполнимый модуль. Основной объем памяти занимают АСТ и дерево разбора.

GC тоже не бином Ньютона. В LLVM есть вся поддержка GC. И есть готовые реализации GC. Состыковать все это вполне подъемная задача. За время компиляции ЖЦ дотнета почти не запускается.

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

_>Тут тоже всё тривиально (по сути никаких внутренних отличий от C++, так что можно взять готовую эффективную реализацию).

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

Лично у меня просто нет ни времени, ни знаний в целевых платыформах отличных от Винды. А для винды и так есть дотнет.

Я, конечно, могу взять и сделать LLVM-версию бэкэнда для Винды. Но не ясно зачем она нужна, и не это отвлечет меня от развития Нитры и Немерла, так что в итоге все встроится в очередь и отдалит результат еще дальше.

_>Только вот есть один вопрос, который я уже упоминал, но не увидел на него ответа. Что у нас с разделением на типы ссылки и значения? В .net у нас экземпляры классов только ссылочные — это не эффективно. Должны быть и ссылочные механизмы и нормальные объекты-значения. И в памяти и на стеке.

У нас — конструктор. Мы вольны добавлять в него все что захотим. Главное, чтобы в рантайме поддержка была. Для самого немерла используется дотнетное разделение на вэлью-типы и ссылочные. Ссылочные живут в хипе, вэлью на стеке и в внутри других объектов. При грамотном проектировании ник каким проблемам с производительностью это не влечет. Но если кому-то хочется это оптимизировать, то флаг ему в руки. Их можно оформить как расширение к компилятору и использовать в своих проектах или ключить в стандартную библиотеку (расширения компилятора — тоже библиотечные вещи).

_>Нуу тут опять же есть нюансы. Совсем ручное управление (как в C) мало кому интересно (хотя опять же должно быть доступно в языке, хотя бы в каком-то unsafe режиме).

Согласен.

_>А при полуавтоматическом (умные указатели и т.п.) могут всплывать различные проблемы типа "восходящего фунарга" и т.п.

Я как то с фунаргами не знаком (глянул википедию). Если речь о релизация ФВП (функций высшего порядка), то очевидно, что тут нужно делить их на два типа:
1. С копирующими замыканиями (значениями лежащими в стеке).
2. Позволять захватывать ссылки только на объекты управляемые ЖЦ или рефкаунтингом.

_>В том же C++ эта проблем сейчас по сути решена благодаря введению в язык семантики перемещения.

Тоже полезная концепция. И не только для замыканий. Я сам думал об уникальных указателях.

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

_>Речь о том, какие функции .net используются рантаймом (а не библиотекой) языка — их же придётся заменять на вызовы к ОС.

Рантайм на котором будет выполняется скомпилированная программа? Да нам как-то по фигу это. Хоть она просто будет в памяти биты гонять.

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

Другое дело, что должна быть еще хоть какая-то стандартная библиотека: коллекции, строки, работа с файлами, сокетами, пайпами... Вот тут лучше брать интерфейс донтентых либ и реализовывать их на базе имеющихся АПИ. Или делать библиотеки доступные для всех платформ (те же коллекции и строки можно тупо написать на сомом языке, так как доступ к ОС им не нужен).

_>Я уже приводил пример, что допустим рантайму C++ необходим доступ к функциям типа VirtualAlloc, VirtualFree и т.п. Плюс там обычно используются различные синхронизации (типа критических секций) и некоторые нюансы многопоточности (типа tls).

Какие тут проблемы то? Это какие-то несусветные мелочи. GC будет несколько более сложным в реализации. А без него удобный язык трудно сделать. Блокировки опять таки это библиотечная сущность. Ну, надо будет реализовать аналоги функции Monitor.Enter/


_>Вообще пока что судя по твоим словам всё относительно позитивно, хотя есть и серьёзные проблемы. Из того, что я прочитал, какую-то реализацию сложнее прямых обёрток вокруг системного АПИ требуют только:

_>1. Своя библиотека контейнеров (в принципе элементарно)

Это вообще не проблема. Код оных уже есть. Остается только его скомпилировать.

_>2. Какое-то управление памятью — а это слооожно (если хотим эффективно).

Это — да.

С дженериками тоже придется повозиться. Но там тоже ясно что делать.

_>Остальное получается по идее портируемо в режиме Ctrl+C/Ctrl+V.

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

Собственно действовать надо путем последовательных приближений. Сначала реализовать примитивныую реализацию на уровне С (без плюсов и классов). Потом добавить к ней классы. Отладить на этой базе ЖЦ или ее замену. Далее добавить поддержку дженериков. В конце получим полноценное решение.

Это позволит тестировать результат с самых ранних стадий.

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

_>>Ну а это всё по сути прямые обёртки над функциями ОС и пишется элементарно.
VD>Все пишет элементарно. Вопрос лишь в том, что надо сесть и сделать. Вот рук которые это сделаю и не хватает. Плюс в данном случае это должны быть руки знакомые с целевой платформой и способные для нее написать эти обертки.

Ну вообще говоря обёртки над функциями ОС генерируются автоматически инструментами. Но при этом они естественно не могут служить удобной стандартной библиотекой языка (она должна быть как минимум кроссплатформенной). Так что потом естественно надо продумать какие-то удобные родные интерфейсы для базовых вещей (хотя бы в рамках стандартной библиотеки C++) и сделать их реализацию на каждой платформе (опять же через вызовы тех самых сгенерированных деклараций нативного АПИ). Но изначально, чтобы оно хоть как-то заработало можно обойтись и прямо функциями ОС.

_>>Кстати, раз вы таких специалисты по парсингу и т.п., то при переходе нативный код я бы на вашем месте первым делом решил такую простую задачу: автоматическую конвертацию заголовочных файлов из WindowsSDK (или Linux — разницы нет) в декларацию чужих импортируемых функций на вашем языке. Если будет такой простейший конвертер (кстати, помнится для каких-то языков я такое уже видел), то это решит огромное число проблем и сходу (даже без создания своей библиотеки языка) позволит писать полноценные приложения (в том числе и с GUI и всем остальным).
VD>Мы конечно специалисты по парсингу и спарсить заголовочные файлы С не является особой проблемой, но опять же у нас не 100 рук. Плюс тут нужно не только парсить уметь, но и помнить все нюансы работы с этими АПИ. Если с АПИ Винды я еще знаком (хотя уже лет 15 с ними не возился), то с линукосовыми или iOS-ыми я не знаком совсем. Стало быть я плохой кандидат на эту задачу. А вот помочь с парсингом — это пожалуйста.

Кстати, как-то забыл упомянуть в предыдущем сообщение очевидную вещь — вам же надо продумать нормальную декларацию для внешних функций (типы, соглашение о вызове и т.п.). У вас же теперь будет прямой вызов таких функций, а не всякий там маршалинг .net'а.Это один из самых важных моментов в современных нативных языках. Потому что если в вашем коде будут легко доступны функции из подключаемых C библиотек и системного АПИ, то это мгновенно даст ему библиотеку (пуская и не родную в начале) на порядок мощнее любого .net'a.

_>>Тут наверное просто стоит определиться, для какой из известных кроссплатформенных IDE вы в первую очередь захотели бы написать плагин. Собственно их вообще таких не много. Но для начал достаточно одной, чтобы хотя бы демонстрация технологии была.
VD>Тут опять таки лучше чтобы такой задачей занимались люди которые близки к этой платформе и этой IDE. Я шарю в MS VS. Для нее я реализацию написал. А вот написть тоже для Эклипса какого или IDEA мне будет проблематично. В то же время я могу элементарно объяснить что надо делать спецу в этих технологиях и он спокойно за месяцок-другой ненапряжной работы это сделает. Движок ведь уже отлажен.

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

_>>Печально это конечно. Подсчёт ссылок — это ужасно (в смысле как универсальное решение для всей памяти). GC лучше, но тоже не очень (при этом его реализация очень не тривиальна).
VD>Да нет ничего печально. Просто ты дико предвзят (причем не по делу) к GC. А для компилятора нет ничего впечатлительного и в тупейшем "нарезателе" памяти. Компилятор программа пакетная. Собрала данные, обработала, выплюнула исполнимый модуль. Основной объем памяти занимают АСТ и дерево разбора.
VD>GC тоже не бином Ньютона. В LLVM есть вся поддержка GC. И есть готовые реализации GC. Состыковать все это вполне подъемная задача. За время компиляции ЖЦ дотнета почти не запускается.

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

VD>Ну, а для своих нужды ты уже сам сможешь решить использовать тебе GC или вручную памятью управлять.

Вот это я что-то не очень понял. Так автоматическое управление памятью всё же опционально или нет? Речь про рантайм языка, который будет присутствовать в любой пользовательской программе.

_>>Тут тоже всё тривиально (по сути никаких внутренних отличий от C++, так что можно взять готовую эффективную реализацию).
VD>Ты говоришь очевидные и банальные вещи. Я тебе заранее мог бы скзазать, что все что нужно сделать евляется известным и тривиальным. Вопрос только в том, что в совокупности это не кислый объем работ который а) надо сделать; б) требует знаний в целевой платформе.
VD>Лично у меня просто нет ни времени, ни знаний в целевых платыформах отличных от Винды. А для винды и так есть дотнет.

Просто есть разные режимы работы. Может быть даже большой объём, но с гарантированным (успешным) результатом и отсутствием каких-либо вопросов по нюансам реализации. А может быть режим "ну давайте начнём и будем надеяться что всё получится". ))) Вот я и пытаюсь выяснить заранее, к какому режиму относится портирование ваших технологий из .net'a. Пока получается что основной объём работы относится к первому варианту, но не всё (по паре вопросов есть и второй вариант).

VD>Я, конечно, могу взять и сделать LLVM-версию бэкэнда для Винды. Но не ясно зачем она нужна, и не это отвлечет меня от развития Нитры и Немерла, так что в итоге все встроится в очередь и отдалит результат еще дальше.

Ну вот тут ты не совсем прав. Если допустим будет существовать нативная версия ваших инструментов под винду и её исходные коды будут доступны, то энтузиасты из других платформ смогут элементарно (!) портировать их к себе, даже "не включая мозг". В отличие от нынешней ситуации, когда для создания нативной версии требуется очень глубокое погружение во все нюансы языка.

_>>Только вот есть один вопрос, который я уже упоминал, но не увидел на него ответа. Что у нас с разделением на типы ссылки и значения? В .net у нас экземпляры классов только ссылочные — это не эффективно. Должны быть и ссылочные механизмы и нормальные объекты-значения. И в памяти и на стеке.
VD>У нас — конструктор. Мы вольны добавлять в него все что захотим. Главное, чтобы в рантайме поддержка была. Для самого немерла используется дотнетное разделение на вэлью-типы и ссылочные. Ссылочные живут в хипе, вэлью на стеке и в внутри других объектов. При грамотном проектировании ник каким проблемам с производительностью это не влечет. Но если кому-то хочется это оптимизировать, то флаг ему в руки. Их можно оформить как расширение к компилятору и использовать в своих проектах или ключить в стандартную библиотеку (расширения компилятора — тоже библиотечные вещи).

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

_>>А при полуавтоматическом (умные указатели и т.п.) могут всплывать различные проблемы типа "восходящего фунарга" и т.п.
VD>Я как то с фунаргами не знаком (глянул википедию). Если речь о релизация ФВП (функций высшего порядка), то очевидно, что тут нужно делить их на два типа:
VD>1. С копирующими замыканиями (значениями лежащими в стеке).

Не эффективно)

VD>2. Позволять захватывать ссылки только на объекты управляемые ЖЦ или рефкаунтингом.

Ну понятно что при GC этой проблемы вообще нет. ))) Это актуально именно для неуправляемых языков.

_>>В том же C++ эта проблем сейчас по сути решена благодаря введению в язык семантики перемещения.
VD>Тоже полезная концепция. И не только для замыканий. Я сам думал об уникальных указателях.

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

_>>Но это уже по сути глобальная правка всего языка, а не просто изменение одной мелкой подсистемы (выделения памяти).
_>>Речь о том, какие функции .net используются рантаймом (а не библиотекой) языка — их же придётся заменять на вызовы к ОС.
VD>Рантайм на котором будет выполняется скомпилированная программа? Да нам как-то по фигу это. Хоть она просто будет в памяти биты гонять.

В смысле пофиг? Этот рантайм же должны предоставлять создатели языка (сейчас за вас это делает CLR).

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

Т.е. никаких синхронизаций и т.п.?

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

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

VD>Или делать библиотеки доступные для всех платформ (те же коллекции и строки можно тупо написать на сомом языке, так как доступ к ОС им не нужен).

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

_>>Остальное получается по идее портируемо в режиме Ctrl+C/Ctrl+V.
VD>Это только на словах. По жизни там не не хилый объем работы. Ну, и естественно, будут разные "подводные камни всплывать" по мере погружения. Но задача вполне себе реализуемая.

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

VD>Собственно действовать надо путем последовательных приближений. Сначала реализовать примитивныую реализацию на уровне С (без плюсов и классов). Потом добавить к ней классы. Отладить на этой базе ЖЦ или ее замену. Далее добавить поддержку дженериков. В конце получим полноценное решение.
VD>Это позволит тестировать результат с самых ранних стадий.

На мой взгляд план может быть таким:
1. подключение llvm (есть готовая инструкция) с каким-нибудь убогим готовым GC
2. разработка удобного подключения C библиотек и ОС АПИ, плюс написание автоматического трансформера заголовочных файлов
3. тут уже можно сделать первое hello world
4. попробовать решить проблему эффективного GC (а лучше ухода от GC)
5. своя библиотека контейнеров и алгоритмов
6. медленная пошаговая замена использования C библиотек на родные библиотеки

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

_>Вот это я что-то не очень понял. Так автоматическое управление памятью всё же опционально или нет? Речь про рантайм языка, который будет присутствовать в любой пользовательской программе.
Ты путаешь две вещи.
1)Компилятор и движок ИДЕ языка программирования который генерирует нитра.
Им для работы нужен ГЦ или заменитель.

2)Код который генерирует компилятор, написанный на нитре.
Тут может быть что угодно.
Этот код не зависит ни от нитры ни от компилятора языка.
Хочешь можешь использовать ГЦ. Не хочешь можешь не использовать ГЦ.
Тут у разработчика языка полный контроль.

А есть ли ГЦ в компиляторе никого волновать не должно от слова совсем.
Я не вижу ни одной причины по которой это могло бы иметь значение.

_>но не всё (по паре вопросов есть и второй вариант).
В случае с портированием только первый.

VD>>Рантайм на котором будет выполняется скомпилированная программа? Да нам как-то по фигу это. Хоть она просто будет в памяти биты гонять.
_>В смысле пофиг? Этот рантайм же должны предоставлять создатели языка (сейчас за вас это делает CLR).
Вот так. Нитре совсем пофиг для какого рантайма генерировать код.
У нас есть некоторые требования для рантайма на котором может работать компилятор, сгенерированный нитрой.
Но нет никаких ограничений на рантайм языков которые компилируют компиляторы, написанные на нитре.

_>На мой взгляд план может быть таким:
Нет. Делать нужно так как Влад сказал.
Мы начинаем с примитивного рантайма который полезен сам по себе.
Ибо позволит на нитре создавать языки, работающие без ГЦ. Что-то типа С на стероидах.
Для того чтобы научить нитру генерировать нативные компиляторы, написанные на нитре (и компилятор самой нитры, ибо он написан на нитре) этого недостаточно.
Дальше можно добавлять возможности, которые можно либо использовать, либо нет.
Те, когда мы добавим поддержку нативного рантайма с ГЦ. С на стероидах просто не будет её использовать.
Но этого будет достаточно чтобы нитра смогла генерировать нативные компиляторы.

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

_>>Вот это я что-то не очень понял. Так автоматическое управление памятью всё же опционально или нет? Речь про рантайм языка, который будет присутствовать в любой пользовательской программе.
WH>Ты путаешь две вещи.
WH>1)Компилятор и движок ИДЕ языка программирования который генерирует нитра.
WH>Им для работы нужен ГЦ или заменитель.

ОК. Для компилятора тут обычный пул наверное подошёл был. Для плагина в IDE не знаю, наверное лучше нормальный GC.

Оффтопик. Просто экспериментальный факт: все испробованные мной IDE написанные на Java (т.е. GC) ощутимо (хотя работать всё равно без проблем можно) подтормаживают в сравнение нативными с такими же возможностями. Мой список сравнения, если что: Eclipse, Netbeans, CLion, VisualStudio, QtCreator.

WH>2)Код который генерирует компилятор, написанный на нитре.
WH>Тут может быть что угодно.
WH>Этот код не зависит ни от нитры ни от компилятора языка.
WH>Хочешь можешь использовать ГЦ. Не хочешь можешь не использовать ГЦ.
WH>Тут у разработчика языка полный контроль.

Это конечно выглядит отлично. Но если вы будете предоставлять подобную технологию "голой", то вряд ли у неё найдётся много пользователей. Потому что разрабатывать свой рантайм (вместо решения прикладных задач) — это сомнительное удовольствие. Вот если у вас в коробке будет идти нормальный эффективный (и возможно кастомизируемый (отключение/подключение GC и т.п.) или просто несколько штук под базовые варианты) рантайм, то таким инструментом уже можно эффективно пользоваться. И кстати в вашем нынешнем решение именно так всё и устроено, только рантайм один и не кастормизируемый (CLR). А вот в случае создания нативной версии это всё надо сделать, что и является одной из важнейших задач на мой взгляд.

WH>А есть ли ГЦ в компиляторе никого волновать не должно от слова совсем.
WH>Я не вижу ни одной причины по которой это могло бы иметь значение.

Согласен.

_>>На мой взгляд план может быть таким:
WH>Нет. Делать нужно так как Влад сказал.
WH>Мы начинаем с примитивного рантайма который полезен сам по себе.
WH>Ибо позволит на нитре создавать языки, работающие без ГЦ. Что-то типа С на стероидах.

Ну лично я то как бы только "за" языки без GC. Только вот хотелось бы увидеть не "C без GC", a "Nemerle без GC"...

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

WH>Для того чтобы научить нитру генерировать нативные компиляторы, написанные на нитре (и компилятор самой нитры, ибо он написан на нитре) этого недостаточно.
WH>Дальше можно добавлять возможности, которые можно либо использовать, либо нет.
WH>Те, когда мы добавим поддержку нативного рантайма с ГЦ. С на стероидах просто не будет её использовать.
WH>Но этого будет достаточно чтобы нитра смогла генерировать нативные компиляторы.

Это всё понятно.

Кстати, хотя полезность нативных компиляторов для продукта очевидна (иначе сложно привлечь людей с других платформ), но в процессе разработки нативной версии я бы абсолютно спокойно пользовался .net компилятором. Т.е. природа самого компилятора думаю никого не волнует и если бы вы скажем сумели бы портировать (например с помощью .net core) прямо свой текущий компилятор на Linux и OSX, то думаю никто бы и не подумал требовать его нативную версию. Естественно подразумевая, что он при этом может генерировать нативный код для этих платформ.

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

_>ОК. Для компилятора тут обычный пул наверное подошёл был. Для плагина в IDE не знаю, наверное лучше нормальный GC.
Работы много, а преимущества мягко говоря не очевидны.
Возможно в очень отдалённом будущем оно и будет сделано, но эта задача совершенно точно находится в самом хвосте. И выпиливание ГЦ будет далеко не главной оптимизацией.

_>Оффтопик. Просто экспериментальный факт: все испробованные мной IDE написанные на Java (т.е. GC) ощутимо (хотя работать всё равно без проблем можно) подтормаживают в сравнение нативными с такими же возможностями. Мой список сравнения, если что: Eclipse, Netbeans, CLion, VisualStudio, QtCreator.
Если там что-то и тормозит, то точно не ГЦ.

_>Это конечно выглядит отлично. Но если вы будете предоставлять подобную технологию "голой", то вряд ли у неё найдётся много пользователей. Потому что разрабатывать свой рантайм (вместо решения прикладных задач) — это сомнительное удовольствие. Вот если у вас в коробке будет идти нормальный эффективный (и возможно кастомизируемый (отключение/подключение GC и т.п.) или просто несколько штук под базовые варианты) рантайм, то таким инструментом уже можно эффективно пользоваться. И кстати в вашем нынешнем решение именно так всё и устроено, только рантайм один и не кастормизируемый (CLR). А вот в случае создания нативной версии это всё надо сделать, что и является одной из важнейших задач на мой взгляд.
Естественно всё так и устроено.
Просто по тому что так было запланировано изначально.
Причём не только рантайм, но и промежуточные языки чтобы пользователи не возились с языками низкого уровня.
Но! Это всё большой объём работы, который должен кто-то сделать.

_>Ну лично я то как бы только "за" языки без GC. Только вот хотелось бы увидеть не "C без GC", a "Nemerle без GC"...
1)Многие конструкции немерле сильно завязаны на ГЦ. Чтобы сделать его без ГЦ нужно менять дизайн. А это будет уже другой язык.
2)Нитра изначально создавалась для создания модульных языков. В смысле модульного синтаксиса и семантики. Так что имея базовый "С без маразмов" можно будет очень легко нарастить на него очень много полезных плюшек.

_>И главное. На этом этапе ещё не получится написать даже "Hello world", потому как функции типа writeln очевидно не входят в рантайм, а относятся к подключаемой библиотеке ввода-вывода. И вот тут начинаются как раз основные игры с разработкой нормального подключения внешних библиотек и т.п. Т.е. один из основных моментов у тебя в плане вообще не озвучен.
По тому что это мелкая деталь реализации.

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

_>но в процессе разработки нативной версии я бы абсолютно спокойно пользовался .net компилятором. Т.е. природа самого компилятора думаю никого не волнует и если бы вы скажем сумели бы портировать (например с помощью .net core) прямо свой текущий компилятор на Linux и OSX, то думаю никто бы и не подумал требовать его нативную версию.
Да там протировать нечего. Всё давно протировано.
Немерле под линухом давно работает.

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

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

_>>Оффтопик. Просто экспериментальный факт: все испробованные мной IDE написанные на Java (т.е. GC) ощутимо (хотя работать всё равно без проблем можно) подтормаживают в сравнение нативными с такими же возможностями. Мой список сравнения, если что: Eclipse, Netbeans, CLion, VisualStudio, QtCreator.
WH>Если там что-то и тормозит, то точно не ГЦ.

Я как бы не претендую на знание того, что там тормозит. ) Но подобное совпадение настораживает. )))

WH>Естественно всё так и устроено.
WH>Просто по тому что так было запланировано изначально.
WH>Причём не только рантайм, но и промежуточные языки чтобы пользователи не возились с языками низкого уровня.
WH>Но! Это всё большой объём работы, который должен кто-то сделать.

Хотелось бы для начала получить хоть что-то работающее. Мне бы хватило для начала нативного "hello world" (собранного не важно каким компилятором (но с бэкендом llvm, для приличной оптимизации), пускай даже под одну винду), написанного на языке с возможностями Nemerle. Дальше уже понятно что и куда развивать.

_>>И главное. На этом этапе ещё не получится написать даже "Hello world", потому как функции типа writeln очевидно не входят в рантайм, а относятся к подключаемой библиотеке ввода-вывода. И вот тут начинаются как раз основные игры с разработкой нормального подключения внешних библиотек и т.п. Т.е. один из основных моментов у тебя в плане вообще не озвучен.
WH>По тому что это мелкая деталь реализации.

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

_>>но в процессе разработки нативной версии я бы абсолютно спокойно пользовался .net компилятором. Т.е. природа самого компилятора думаю никого не волнует и если бы вы скажем сумели бы портировать (например с помощью .net core) прямо свой текущий компилятор на Linux и OSX, то думаю никто бы и не подумал требовать его нативную версию.
WH>Да там протировать нечего. Всё давно протировано.
WH>Немерле под линухом давно работает.

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

_>>Естественно подразумевая, что он при этом может генерировать нативный код для этих платформ.
WH>Как только нитра сможет генерировать нативный код она естественно будет это делать везде.

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

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

_>Хотелось бы для начала получить хоть что-то работающее. Мне бы хватило для начала нативного "hello world" (собранного не важно каким компилятором (но с бэкендом llvm, для приличной оптимизации), пускай даже под одну винду), написанного на языке с возможностями Nemerle. Дальше уже понятно что и куда развивать.

На сегодня есть вот такой игрушечный язык: Nitra-Mini-C
И статья

Автор(ы): Чистяков Владислав Юрьевич
Дата: 07.03.2017
В статье описывается реализация компилятора языка программирования Mini C на базе Nitra (под платформу .Net). Mini C — это упрощенная версия языка C. В статье описывается все этапы реализации языка от создания парсера, до генерации MSIL. И сам язык и данное описание созданы для демонстрации того как разрабатывать языки программирования на Nitra. Nitra — это средство разрабоки ЯП (language workbench). Nitra можно использовать для создания языков программирования с расширяемыми синтаксисом и семантикой, а так же языков предметной области (DSL).

описывающая нюансы его реализации на Нитре.

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

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

Nitra-Mini-C написал парень не знакомый с Немерлом до этого. Я консультировал его и немного помогал. На все про все у него ушло около месяца ненапряжной работы. Написать бэкэнд займет (думаю) от одного дня до недели.

Не хочешь попробовать? Я буду консультировать по Нитре и Немерлу. Ну, и помогу, чем смогу.

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

_>>Хотелось бы для начала получить хоть что-то работающее. Мне бы хватило для начала нативного "hello world" (собранного не важно каким компилятором (но с бэкендом llvm, для приличной оптимизации), пускай даже под одну винду), написанного на языке с возможностями Nemerle. Дальше уже понятно что и куда развивать.
VD>На сегодня есть вот такой игрушечный язык: Nitra-Mini-C
VD>И статья

Автор(ы): Чистяков Владислав Юрьевич
Дата: 07.03.2017
В статье описывается реализация компилятора языка программирования Mini C на базе Nitra (под платформу .Net). Mini C — это упрощенная версия языка C. В статье описывается все этапы реализации языка от создания парсера, до генерации MSIL. И сам язык и данное описание созданы для демонстрации того как разрабатывать языки программирования на Nitra. Nitra — это средство разрабоки ЯП (language workbench). Nitra можно использовать для создания языков программирования с расширяемыми синтаксисом и семантикой, а так же языков предметной области (DSL).

описывающая нюансы его реализации на Нитре.
VD>Язык очень простенький и с ним можено легко разобраться не имея опыта ни в Нитре, ни в компиляторостроении.
VD>Так вот можно для начала попробовать реализовать LLVM-бэкэнд для этого языка. За одно это будет знакомство с Немерле.
VD>Nitra-Mini-C написал парень не знакомый с Немерлом до этого. Я консультировал его и немного помогал. На все про все у него ушло около месяца ненапряжной работы. Написать бэкэнд займет (думаю) от одного дня до недели.

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

Но если в качестве развлечения и самообучения, то можно и попробовать такое.

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

Я? Ну технически я такое могу. И даже определённый интерес (правда пока только фанового типа) имеется. Но прямо сейчас я точно не могу. У меня тут сейчас как раз пик важного проекта, так что свободного времени нет вообще (причём большая часть проблем уже не технического уровня, а всякие контракты, поставки и т.п.). Так что я вот общаясь на форуме по сути немного отдыхаю от всего этого, но на большее времени нет. Можно будет попробовать поговорить об этом где-нибудь ближе к маю, когда надеюсь проект запустится. )))

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

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

Речь идет лишь о том, чтобы попробовать, т.е. обучение, оценка на реальном примере, оценка LLVM, pet project.

_>Но если в качестве развлечения и самообучения, то можно и попробовать такое.

Именно. Это не займет много времени, но ты сможешь сам все оценить изнутри.

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

Я сейчас занят на Нитре. А за это время, я надеюсь, что я с не закончу и вплотную займусь языками.

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

_>>Ну это в итоге получится немного не то, что я говорил. Это будет не нужный кому-то инструмент, а разве что первый тестовый шаг для построения чего-то приличного. Причём дальнейшее развитие будет для меня (как не проектировавшего пока ещё свои языки) не очевидно. В отличие от ситуации наличия уже нормального языка, который надо только перевести на нативные рельсы.
VD>Речь идет лишь о том, чтобы попробовать, т.е. обучение, оценка на реальном примере, оценка LLVM, pet project.

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

_>>Но если в качестве развлечения и самообучения, то можно и попробовать такое.
VD>Именно. Это не займет много времени, но ты сможешь сам все оценить изнутри.

ОК, тогда наверное что-то подобное попробую.

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

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

Хотя если есть очень много свободного времени и желание поразвлечься, то... Но боюсь это не про меня. )

VD>Я сейчас занят на Нитре. А за это время, я надеюсь, что я с не закончу и вплотную займусь языками.

Тогда ближе к лету можем вернутся к этой дискуссии. )

P.S. Я на форуме общаюсь больше через почту (в смысле реагирую на пришедшие туда уведомления об ответах в темах).

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

_>Ну я то предпочёл бы получить готовый инструмент и ещё желательно на халяву. А тут такая суровая реальность... Эх, как тяжела жизнь.

Да. Реальная жизнь она такая.

_>ОК, тогда наверное что-то подобное попробую.

Тогда я я ниже опишу что нужно делать, и что нужно почитать для начала.

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

_>Слишком опасно. ) Особенно для меня (перепробовавшего множество языков, но так и не нашедшего идеала)... ))) Есть большой соблазн сделать "ещё один никому кроме тебя не нужный язык". ))) Безопаснее портировать на нужную тебе платформу какой-то приличный язык у которого уже есть сообщество и т.п.

_>Хотя если есть очень много свободного времени и желание поразвлечься, то... Но боюсь это не про меня. )

Я, видимо, выразился недостаточно понятно. Я не имел в виду, что тебе придется создавать новый язык с нуля. Прод реальным языком я имел ввиду Native Nemerle 2.

Просто он пока еще не существует. По сем сейчас его переносом заниматься невозможно. Но в ближайшее время мы им займемся и можно будет параллельно с нами создавать нативный бэкэнд. Причем бэнэнд будет позволять завести на LLVM и другие дотнетные языки реализованные на Nitra. Например, Cx# (расширяемый C#), который на половину уже написан.

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

_>Тогда ближе к лету можем вернутся к этой дискуссии. )

Ну, чтобы попробовать, ждать лета нет нужды. Даже наоборот полезено было бы сделать это пока есть азарт.

Как я уже сказал можно потренироваться на Mini C. Это позволит понять что нужно бдудет сделать в реальном бэкнде, а так же немного освоиться с Нитрой и Немерле. Надеюсь тебе эти языки понравятся.

Собственно начать надо с изучения вот этой статьи:
http://rsdn.org/article/nitra/MiniC/Nitra-Mini-C.xml

Автор(ы): Чистяков Владислав Юрьевич
Дата: 07.03.2017
В статье описывается реализация компилятора языка программирования Mini C на базе Nitra (под платформу .Net). Mini C — это упрощенная версия языка C. В статье описывается все этапы реализации языка от создания парсера, до генерации MSIL. И сам язык и данное описание созданы для демонстрации того как разрабатывать языки программирования на Nitra. Nitra — это средство разрабоки ЯП (language workbench). Nitra можно использовать для создания языков программирования с расширяемыми синтаксисом и семантикой, а так же языков предметной области (DSL).

Сам код этого проекта находится тут: https://github.com/rsdn/Nitra-Mini-C
Здесь описны DSL-и для работы с AST и типизацией. Эту статью можно прочесть целиком, но скорее ее надо рассматривать как документацию. Так что если в ней что то будет не понятно — это не страшно.
Вот здесь

Автор(ы):

описание языка грамматик Нитры. Это вообще на всякий случай. Для работы с бэкэндом синтаксис вообще не важен.
Так же имеет смысл собрать Nitra с исходников (инструкция здесь).
https://github.com/rsdn/nitra/wiki/Nitra-Build-process
и проект Mini C. Для этого его надо поместить в папку рядом с папкой Nitra и собрать Nitra-Mini-C.sln. Корневую папку лучше делать неглубокой. Но об этом сказано в Nitra Build process.
Ну, а дальше мой скайп vc.rsdn.ru Просто постучись по нему и вместе наметим план работ. Вопросы можно задавать как по скайпу так и на форуме.

В зависимости от выделяемого времени это может занять от недели до 1-2 месяцев. Надеюсь это будет увлекательно!

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

_>>Слишком опасно. ) Особенно для меня (перепробовавшего множество языков, но так и не нашедшего идеала)... ))) Есть большой соблазн сделать "ещё один никому кроме тебя не нужный язык". ))) Безопаснее портировать на нужную тебе платформу какой-то приличный язык у которого уже есть сообщество и т.п.
_>>Хотя если есть очень много свободного времени и желание поразвлечься, то... Но боюсь это не про меня. )
VD>Я, видимо, выразился недостаточно понятно. Я не имел в виду, что тебе придется создавать новый язык с нуля. Прод реальным языком я имел ввиду Native Nemerle 2.

Ага, вот это уже интереснее. Причём я тут подумал — действительно наверное не получится просто перенести обычный Nemerle на нативную платформу. Точнее сделать это без проблем можно, но только результат будет мало кому интересен. А вот если сделать адаптацию, которая позволит использовать все возможности нативной платформы (чтобы грубо говоря было удобно и драйверы писать), при этом не потеряв в удобстве и безопасности, то это очень многим бы пришлось по вкусу. Хотя это и не так просто (см. например попытки в Rust'е).

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

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

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

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

VD>Как я уже сказал можно потренироваться на Mini C. Это позволит понять что нужно бдудет сделать в реальном бэкнде, а так же немного освоиться с Нитрой и Немерле. Надеюсь тебе эти языки понравятся.

На Немерле я уже когда-то давно посматривал. Выводы были такие: макросы — очень приятно, синтаксис — мне в принципе сойдёт, есть минусы (в основном имеющие свои корни в .Net). Про Нитру только слышал, но ничего не видел.

VD>Собственно начать надо с изучения вот этой статьи:
VD>http://rsdn.org/article/nitra/MiniC/Nitra-Mini-C.xml

Автор(ы): Чистяков Владислав Юрьевич
Дата: 07.03.2017
В статье описывается реализация компилятора языка программирования Mini C на базе Nitra (под платформу .Net). Mini C — это упрощенная версия языка C. В статье описывается все этапы реализации языка от создания парсера, до генерации MSIL. И сам язык и данное описание созданы для демонстрации того как разрабатывать языки программирования на Nitra. Nitra — это средство разрабоки ЯП (language workbench). Nitra можно использовать для создания языков программирования с расширяемыми синтаксисом и семантикой, а так же языков предметной области (DSL).

VD>Сам код этого проекта находится тут: https://github.com/rsdn/Nitra-Mini-C
VD>Здесь описны DSL-и для работы с AST и типизацией. Эту статью можно прочесть целиком, но скорее ее надо рассматривать как документацию. Так что если в ней что то будет не понятно — это не страшно.

Кстати мне в одном проекте требовалась интеграция в приложение исполнения вот такого https://www.compuphase.com/pawn/pawn.htm забавного язычка — в чём-то похоже, хотя он и не игрушечный. )

VD>Вот здесь

Автор(ы):

описание языка грамматик Нитры. Это вообще на всякий случай. Для работы с бэкэндом синтаксис вообще не важен.
VD>Так же имеет смысл собрать Nitra с исходников (инструкция здесь).
VD>https://github.com/rsdn/nitra/wiki/Nitra-Build-process

Хы, а зачем запускать VS от админа? ) Т.е. мне то не принципиально (если не считать конечно само отсутствие VS на данный момент на моей рабочей машине), но просто глаз зацепился и интересно. )))

VD>и проект Mini C. Для этого его надо поместить в папку рядом с папкой Nitra и собрать Nitra-Mini-C.sln. Корневую папку лучше делать неглубокой. Но об этом сказано в Nitra Build process.

Угу, и кругом sln файлы в качестве системы сборки. И тут (ну это ещё ладно, разово собрать и всё, можно даже не на рабочем компьютере) и у Mini-C... Это вот первым делом пришлось бы переделать, если переходить на кроссплатформенный уровень.

Кстати (отвлечённые рассуждения), вот казалось бы как раз при программирование под .net (для которого готовый компилятор и библиотеки есть на любом компьютере с виндой) люди должны были бы предпочитать использовать какие-то независящие от IDE системы сборки (любой проект просто копируется и собирается в консольке на любой машине, без установки какого-то дополнительного ПО), однако тут явное засилье проектов VS. В то время как у какого-нибудь C++, у которого для сборки надо установить на компьютер кучу всего (по отдельности или одного жирного монстра типа VS) и тут казалось бы должны были предпочитать работу в проектах для VS, но вместо этого как раз процветают системы сборки (тот же CMake) даже при использование VS.

VD>Ну, а дальше мой скайп vc.rsdn.ru Просто постучись по нему и вместе наметим план работ. Вопросы можно задавать как по скайпу так и на форуме.

Да думаю без проблем договоримся там. ) Можно даже и в реале пересечься (в одном городе живём всё же) со временем.

VD>В зависимости от выделяемого времени это может занять от недели до 1-2 месяцев. Надеюсь это будет увлекательно!

Ну я обычно занимаюсь подобными фановыми вещами "запоями", так что думаю скорее будет речь про неделю. ))) Но ближе к лету. )

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

_>Ага, вот это уже интереснее. Причём я тут подумал — действительно наверное не получится просто перенести обычный Nemerle на нативную платформу. Точнее сделать это без проблем можно, но только результат будет мало кому интересен. А вот если сделать адаптацию, которая позволит использовать все возможности нативной платформы (чтобы грубо говоря было удобно и драйверы писать), при этом не потеряв в удобстве и безопасности, то это очень многим бы пришлось по вкусу. Хотя это и не так просто (см. например попытки в Rust'е).
Проблема в том, что в этом случае от немерле мало что останется.
Уж слишком там всё на глобальный ГЦ завязано. А ты как я понимаю ГЦ не хочешь.

В принципе у меня есть понимание как сделать язык с опциональным локальным ГЦ. Те если писать аккуратно, то ГЦ вообще можно не включать. Либо включать только для части кода не останавливая остальной.
Но в этом случае от немерле останется ещё меньше.

_>Угу, у меня как раз есть несколько идей в данной области. В том смысле что не какие-то оригинальные концепции, а скорее понимание того, какой конкретно набор известных концепций должен реализовать идеальный нативный язык.
Вот это нужно написать перед началом работы над языком.
Причём чем раньше, тем лучше.
Ибо ты можешь чего-то не знать, забыть или просто не подумать.
Чтобы снизить риски появления концептуальных косяков концепцию нужно обсудить.

Перед тем как ты будешь формулировать свои мысли прочитай эти статьи (список по ссылке).
http://joeduffyblog.com/2015/11/03/blogging-about-midori/
Букв много. Но всё по делу. Перед созданием нового языка читать обязательно.
В двух словах: Мужик работал над созданием полностью управляемой ОС и пишет какие были варианты, какие из них оказались рабочими и какие нет. А главное почему.

А вообще весь блог рекомендую.

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

K тому что написал WolfHound добавлю еще нативную Скалу (https://github.com/scala-native/scala-native)
Там вроде многое уже работает. Скала по функционалу ~N++.

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

_>Ага, вот это уже интереснее. Причём я тут подумал — действительно наверное не получится просто перенести обычный Nemerle на нативную платформу. Точнее сделать это без проблем можно, но только результат будет мало кому интересен.

Уж если Go кому-то интересен, то уж Нативный Nemerle точно должен быть интересен. Языки и рядом не стояли. Вот только надо название сменить (наверно) и пиар-компанию продумать или найти брэнд через который язык двигать (как тот же Go).

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

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

_>Хотя это и не так просто (см. например попытки в Rust'е).

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

Удобство не должно приноситься в жертву эффективности. Если для каких-то задач GC и исключения — зло, то надо просто дать возможности их не использовать. Проконтролировать это не сложно. Нужно только альтернативные механизмы сделать.

_>Угу, у меня как раз есть несколько идей в данной области. В том смысле что не какие-то оригинальные концепции, а скорее понимание того, какой конкретно набор известных концепций должен реализовать идеальный нативный язык.

Ну, вот и сможешь осуществить свои задумки. При этом не придется городить язык с нуля. Это, конечно, задача неподъемная.

_>На Немерле я уже когда-то давно посматривал. Выводы были такие: макросы — очень приятно, синтаксис — мне в принципе сойдёт, есть минусы (в основном имеющие свои корни в .Net). Про Нитру только слышал, но ничего не видел.

Ну, вот почитав статейки можно хотя бы общее впечатление оставить.

_>Хы, а зачем запускать VS от админа? ) Т.е. мне то не принципиально (если не считать конечно само отсутствие VS на данный момент на моей рабочей машине), но просто глаз зацепился и интересно. )))

Откровенно говоря уже не помню. Возможно что-то регистрируется. У Немерла такое требование потому, что при сборке файлы копируются в %ProgramFiles%\Nemerle\Net-4.0, она новых версиях Винды закрыт на запись для смертных.

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

_>Угу, и кругом sln файлы в качестве системы сборки.

И что? Это стандарт в дотнете. Студия работает именно с ними, потому и sln. При этом их без проблем можно собирать MSBuild-ом, который входит в донет и запуска IDE не требует..

_>И тут (ну это ещё ладно, разово собрать и всё, можно даже не на рабочем компьютере) и у Mini-C... Это вот первым делом пришлось бы переделать, если переходить на кроссплатформенный уровень.

В дотнете с этим нет никаких проблем. sln — это не более чем список проектов. Можешь заменить его на proj-файл MSBuild-а. Но при этом ты лишишься возможности открывать его в VS. Именно по этому никто так не делает.

Вот когда тебе придется собирать компилятор под LLVM на платформе где дотнета нет, то вместо него придется что-то другое брать. А в дотнете MSBuild — стандарт, а sln — один из его стандартных форматов.

_>Кстати (отвлечённые рассуждения), вот казалось бы как раз при программирование под .net (для которого готовый компилятор и библиотеки есть на любом компьютере с виндой) люди должны были бы предпочитать использовать какие-то независящие от IDE системы сборки

Ты просто явно с дотнетом много не возился. Не зависит от IDE этот формат. Просто у VS форматом проектов служат файлы MSBuild.

С этим есть проблемы на Mono. Там есть аналог MSBuild, но он не полностью совместим с прототипом (рукожопье в Моно процветало). Но сейчас МС на всех парах опенсорсит дотнет. Они создали .Net Core в который переводят все что можно. MSBuild не стал исключением. Сначала они запилили велосипед, но разум востержествовал и MSBuild тоже двинули в Core, попутно сделав MSBuild стандартом проектов и для Core. Так как лицензия на Core очень либеральная (Апач 2, если не ошибаюсь), то Моновцы уже сказали, что будут брать тулы из Core и перейдут на MSBuild.

_>Да думаю без проблем договоримся там. ) Можно даже и в реале пересечься (в одном городе живём всё же) со временем.

Да, можно и так. Я всегда "за".

_>Ну я обычно занимаюсь подобными фановыми вещами "запоями", так что думаю скорее будет речь про неделю. ))) Но ближе к лету. )

ОК

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

VD>Уж если Go кому-то интересен, то уж Нативный Nemerle точно должен быть интересен. Языки и рядом не стояли. Вот только надо название сменить (наверно) и пиар-компанию продумать или найти брэнд через который язык двигать (как тот же Go).

И зря ты так Go "обижаешь". Go никому не интересен как язык (ибо какашка полная), он интересен как инфраструктура для быстрой и простой разработки сетевых приложений (сайты, сервисы, всё что угодно), и в этом он реально крут. А какая будет ключевая фича у "нативного Nemerle"? То что он классный язык – этого слишком мало, как бы и не нативному Nemerle это не шибко помогает даже при наличии всей той прорвы библиотек, что доступна благодаря .NET.

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

KP>И зря ты так Go "обижаешь". Go никому не интересен как язык (ибо какашка полная), он интересен как инфраструктура для быстрой и простой разработки сетевых приложений (сайты, сервисы, всё что угодно), и в этом он реально крут. А какая будет ключевая фича у "нативного Nemerle"? То что он классный язык – этого слишком мало, как бы и не нативному Nemerle это не шибко помогает даже при наличии всей той прорвы библиотек, что доступна благодаря .NET.

А в чем эта "инфраструктурность" заключается?

Я на Nemerle и сейчас, и 10 лет назад мог делать "сайты, сервисы, всё что угодно".

То есть вся разница в том, что он не требует виртуальной машины?

ЗЫ

Давай будем честными. Главное достоинство Go это — Google.

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

VD>А в чем эта "инфраструктурность" заключается?

В том, что всё просто и "из коробки". В том, что есть куча сторонних фрэймворков на все случаи жизни.

VD>Я на Nemerle и сейчас, и 10 лет назад мог делать "сайты, сервисы, всё что угодно".

Да и на C++ я тоже самое могу сделать, вопрос лишь в том, сколько на это времени уйдет. К примеру вот довольно популярный Web-framework для Go. Обрати внимание на "быстрый старт": там меньше 10 строк, которые тебе на выходе дают что-то осязаемое.

VD>То есть вся разница в том, что он не требует виртуальной машины?

Да ладно тебе, причем тут вообще VM? Я в ней проблемы не вижу, а вот то, что это не .NET – это безусловно осязаемый плюс, так как отвязывает и от WIndows и от очередного NIH приступа в MS.

VD>Давай будем честными. Главное достоинство Go это — Google.

Ни разу. Если честно – достоинство инфраструктура для разработки всего и вся связанного с сетями и не имеющего совсем уж жестких требований к производительности.

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

KP>Да и на C++ я тоже самое могу сделать, вопрос лишь в том, сколько на это времени уйдет. К примеру вот довольно популярный Web-framework для Go. Обрати внимание на "быстрый старт": там меньше 10 строк, которые тебе на выходе дают что-то осязаемое.
http://www.nemerleweb.com/tutorial
1)Весь код включая ХТМЛ статически типизирован.
2)Это не тупой серверный шаблонизатор, а реактивный ГУИ живущий на клиенте.

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

VD>Я уже говорил. Беда Rust в том, что авторы отказались от GC и исключений. Это идиотизм. Вот наличие возможностей жить без них — это хорошо. А их полное отсутствие — это идиотизм.
Правильно реализованные исключения строго лучше кодов возврата.
1)Их нельзя проигнорировать, а значит программа не будет молча глотать ошибки.
2)Они делают код быстрее и меньше.
В случае с мидори:

The model I just described doesn’t have to be implemented with exceptions. It’s abstract enough to be reasonably implemented using either exceptions or return codes. This isn’t theoretical. We actually tried it. And this is what led us to choose exceptions instead of return codes for performance reasons.

...

In summary, the exceptions approach was 7% smaller and 4% faster as a geomean across our key benchmarks, thanks to a few things:

No calling convention impact.
No peanut butter associated with wrapping return values and caller branching.
All throwing functions were known in the type system, enabling more flexible code motion.
All throwing functions were known in the type system, giving us novel EH optimizations, like turning try/finally blocks into straightline code when the try could not throw.

(С)http://joeduffyblog.com/2016/02/07/the-error-model/

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

WH>Проблема в том, что в этом случае от немерле мало что останется.
WH>Уж слишком там всё на глобальный ГЦ завязано.

Хм, и что же там так завязано? Я вот например особо не вижу там конструкций, которые нельзя бы было реализовать без GC.

WH>А ты как я понимаю ГЦ не хочешь.

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

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

1. Давным давно. Язык C и даже старый C++ (который был C с классами). Всё приложение нашпиговано сплошными new и delete (ну или malloc и free), причём необходимо следить за их парностью. Неудобно, но ничего лучшего со сравнимой эффективностью на тот момент нет.
2. Позже. Java и потом C#. Различных new стало даже ещё больше, но от delete (и главное необходимости следить за парностью) избавились. Ценой этого стало некоторое сужение применимости языков (в сравнение с C).
3. Современный C++. В приложение нет ни одного new или delete вообще. При этом эффективность и применимость получаемого кода не хуже чем у древнего C. Понятно, что это пример идеального приложения, написанного с нуля на современном стандарте, а в реальности такого не встречается, т.к. всегда приходится использовать разные библиотеки (типа той же Qt), которые чаще всего проектировались в древности. Но на суть общей картины это думаю не влияет.

Так вот, глядя на эту картину... Ты всё равно считаешь наличие GC прогрессом? )

_>>Угу, у меня как раз есть несколько идей в данной области. В том смысле что не какие-то оригинальные концепции, а скорее понимание того, какой конкретно набор известных концепций должен реализовать идеальный нативный язык.
WH>Вот это нужно написать перед началом работы над языком.
WH>Причём чем раньше, тем лучше.
WH>Ибо ты можешь чего-то не знать, забыть или просто не подумать.
WH>Чтобы снизить риски появления концептуальных косяков концепцию нужно обсудить.

Безусловно. Но на это тоже надо время. Чтобы изложить системно, обсудить и т.п. Пока у меня только чёткое понимание каких вещей там точно не должно быть (например интроспекции времени исполнения) и какие точно должны быть (например прозрачный вызов C библиотек и системного API).

WH>Перед тем как ты будешь формулировать свои мысли прочитай эти статьи (список по ссылке).
WH>http://joeduffyblog.com/2015/11/03/blogging-about-midori/

Да, одна статья там прямо по делу, которая "Safe Native Code". И там у него много здравых мыслей)

WH>Букв много. Но всё по делу. Перед созданием нового языка читать обязательно.
WH>В двух словах: Мужик работал над созданием полностью управляемой ОС и пишет какие были варианты, какие из них оказались рабочими и какие нет. А главное почему.

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

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

N>K тому что написал WolfHound добавлю еще нативную Скалу (https://github.com/scala-native/scala-native)
N>Там вроде многое уже работает. Скала по функционалу ~N++.

О, действительно интересно. Прямо на первой же странице все примеры демонстрируют именно то, о необходимости наличия чего я уже писал в этой теме. А именно: данные на стеке, работа с указателями, прямое выделение памяти, прозрачные вызовы C библиотек, бэкенд через LLVM. Правда при этом у них указано, что сам язык управляемый — интересно как это там внутри всё сочетается.

Кстати, у них там видно одно интересное решение, про которое я уже тоже тут говорил, как про полезную временную меру. Они не стали страдать с разработкой своей стандартной библиотеки, а просто взяли готовую библиотеку C. Поэтому у них там во всех примерах сплошные printf и т.п. Понятно, что для готового продукта с таким языком это конечно не верно (все знают минусы printf), но на самой первой стадии это похоже самое идеальное решение. Я его высказал в этой темке с ходу, без всякого серьёзного проектирования, но судя по этому проекту оно достаточно удачное.

Да, но вот с вопросами документации у данных товарищей всё крайне печально. Вообще полная пустота. Я не говорю даже про какие-то документации на компилятор или библиотеки — у них даже про сам язык (поддерживаемые концепции, ограничения и т.п.) вообще ничего нет. Единственное из чего можно сделать какие-то выводы, это из сравнения этого https://github.com/scala-native/scala-native/blob/master/demo/native/smallpt.scala и этого https://github.com/scala-native/scala-native/blob/master/demo/jvm/smallpt.scala исходников. ))) Кстати, забавно что у них там валяется ещё и такая https://github.com/scala-native/scala-native/blob/master/demo/cpp/smallpt.cpp реализация этого же примера — интересно сравнить быстродействие. )))

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

_>>Ага, вот это уже интереснее. Причём я тут подумал — действительно наверное не получится просто перенести обычный Nemerle на нативную платформу. Точнее сделать это без проблем можно, но только результат будет мало кому интересен.
VD>Уж если Go кому-то интересен, то уж Нативный Nemerle точно должен быть интересен. Языки и рядом не стояли. Вот только надо название сменить (наверно) и пиар-компанию продумать или найти брэнд через который язык двигать (как тот же Go).

Ну вообще то концепция Nemerle как раз противоположна Go. Это сложный продукт для узкой аудитории эстетов от программирования. В какой-то степени его аналогами наверное можно было бы назвать Scala из мира JVM и D из нативного мира. Кстати, среди них он вроде как самый "неудачник", но это видимо следствие позиции .net. Причём это позиционирование будет вне зависимости от того нативный/ненативный или управляемый/неуправляемый — это скорее речь о МП и т.п.

А дальше следует смотреть, в каких областях подобных эстетов обитает больше. Это уже вопрос обсуждаемый, но сразу понятно, что область написания формочек к БД в банках сюда точно не подходит.

Далее, что касается нативного Nemerle, то надо понимать, что если мы хотим просто получить одиночный исполняемый файл с машинными кодами после хорошего оптимизатора, то для этого ничего делать не надо — этим сейчас уже занимается MS в своём .net native. Вам надо только проверить что Nemerle со всем этим совместим и всё получится автоматом.

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

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

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

VD>Ты просто явно с дотнетом много не возился. Не зависит от IDE этот формат. Просто у VS форматом проектов служат файлы MSBuild.
VD>С этим есть проблемы на Mono. Там есть аналог MSBuild, но он не полностью совместим с прототипом (рукожопье в Моно процветало). Но сейчас МС на всех парах опенсорсит дотнет. Они создали .Net Core в который переводят все что можно. MSBuild не стал исключением. Сначала они запилили велосипед, но разум востержествовал и MSBuild тоже двинули в Core, попутно сделав MSBuild стандартом проектов и для Core. Так как лицензия на Core очень либеральная (Апач 2, если не ошибаюсь), то Моновцы уже сказали, что будут брать тулы из Core и перейдут на MSBuild.

Я в курсе, т.к. когда-то давно (но ms build уже существовал) активно использовал VS. И поэтому так же в курсе, что эта система сборки является одной из самых ущербных. Даже без учёта отсутствия кроссплатформенности) Единственный её плюс — это автоматическая генерация файлов одной популярной IDE. )))

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

_>Хм, и что же там так завязано? Я вот например особо не вижу там конструкций, которые нельзя бы было реализовать без GC.
Например, замыкания сразу становятся неполноценными.
Да и вообще весь код, написанный на немерле рассчитан на глобальный ГЦ.
Так что даже если сделать язык, который выглядит как немереле, но без глобального ГЦ программы, написанные на немерле ты на нём, не запустишь. Даже если скомпилируешь работать они не будут.

_>Нуу обязательный GC сразу закроет часть ниш для этого языка. Причём некоторые из них сейчас весьма популярны и активно развиваются. Так что с точки зрения широты обхвата лучше без этого.
Какие и почему?

_>3. Современный C++. В приложение нет ни одного new или delete вообще. При этом эффективность и применимость получаемого кода не хуже чем у древнего C.
Это одна из многих форм ГЦ.

_>Так вот, глядя на эту картину... Ты всё равно считаешь наличие GC прогрессом? )
Да. Тем более что можно сделать систему, которая будет работать намного лучше, чем, то что есть в С++.
И с точки зрения безопасности кода. И с точки зрения производительности.

_>каких вещей там точно не должно быть (например интроспекции времени исполнения)
Согласен. Стандартная реализация интроспекции времени исполнения всегда не адекватна задачам, которые с её помощью решаются.
Гораздо лучший вариант сгенерировать всё что нужно во время компиляции.
И языки на основе нитры тут безусловные фавориты.

_>и какие точно должны быть (например прозрачный вызов C библиотек и системного API).
Если мы делаем переносимый макроассемблер, то это получится, само собой. Но про безопасность языка можно сразу забыть.
Если язык более высокого уровня, то нужно делать обёртки. Даже в С++ напрямую С библиотеки не используют.

_>Да, одна статья там прямо по делу, которая "Safe Native Code". И там у него много здравых мыслей)
Там всё нужно внимательно прочитать.
Особенно тебе. Он многие твои заблуждения разбирает.

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

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

_>О, действительно интересно. Прямо на первой же странице все примеры демонстрируют именно то, о необходимости наличия чего я уже писал в этой теме. А именно: данные на стеке, работа с указателями, прямое выделение памяти, прозрачные вызовы C библиотек, бэкенд через LLVM. Правда при этом у них указано, что сам язык управляемый — интересно как это там внутри всё сочетается.
Дедушка без управляемости это уже бабушка, как справедливо заметил Wolfhound. Scala native это 100% Скала. В смысле там только бэкенд другой, фронтенды взяты из jvm версий [Нитра не нужна! ]. "ФронтендЫ" потому что их сейчас два: scalac (прод) и dotty (новый). Все нативные плюшки сделаны через обычные механизмы (аннотации и т.д.).

В данный момент для ГЦ традиционно используют Boehm, потом собираются менять. Это не отменяет конечно, что можно прямо звать malloc, etc, то есть "гибридный" подход в терминологии Влада.

_>Кстати, у них там видно одно интересное решение, про которое я уже тоже тут говорил, как про полезную временную меру. Они не стали страдать с разработкой своей стандартной библиотеки, а просто взяли готовую библиотеку C. Поэтому у них там во всех примерах сплошные printf и т.п.
Не совсем. Они хотят иметь совместимость до уровня работоспособности чистых Scala-библиотек типа Акка/Spark. Для этого они ограничено портируют явовские нэймспейсы на нативную Скалу ручками. Автор говорит, что это довольно просто. Если уровень поддержки достаточный, то какой-нибудь scala.collection._ должна работать из коробки.

_>Да, но вот с вопросами документации у данных товарищей всё крайне печально. Вообще полная пустота.
Проект новый, документация вроде в разработке. Посмотри на тытруба, там вроде в отдельном брэнче что-то валяется.

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

KP>В том, что всё просто и "из коробки". В том, что есть куча сторонних фрэймворков на все случаи жизни.

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

KP>Да и на C++ я тоже самое могу сделать, вопрос лишь в том, сколько на это времени уйдет. К примеру вот довольно популярный Web-framework для Go. Обрати внимание на "быстрый старт": там меньше 10 строк, которые тебе на выходе дают что-то осязаемое.

Про NemerleWeb тебе сказал. Такого у Go скорее всего никогда. Но есть варианты и по проще. Можно просто ASP.MVC-проект создать.

VD>>То есть вся разница в том, что он не требует виртуальной машины?

KP>Да ладно тебе, причем тут вообще VM?

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

Вся разница в том, что есть VM, а в go — нет.

KP>Я в ней проблемы не вижу, а вот то, что это не .NET – это безусловно осязаемый плюс, так как отвязывает и от WIndows и от очередного NIH приступа в MS.

Ну, у .NET тоже есть Моно и Core. Для сервисов и прочего не гуевого софта этого хватает.

VD>>Давай будем честными. Главное достоинство Go это — Google.

KP>Ни разу. Если честно – достоинство инфраструктура для разработки всего и вся связанного с сетями и не имеющего совсем уж жестких требований к производительности.

Ну, вот и у Немерла все тоже самое. Но Go раскрутили. И ты утверждаешь, что Google в этом не виноват.

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

VD>Ну, при том, что к дотнету и Яве фреймворков ведь в разы больше. Плюс еще на макросах решения есть для многого. Но ты мне про какую-то там инфраструктуру рассказываешь.
VD>Вся разница в том, что есть VM, а в go — нет.

Да, ты прав, отдельно стоящая VM на 50-100 мб – это перебор в ряде случаев. В нашем это было просто недопустимо. А так, я бы Python (но тут еще и исходники в открытом виде по факту) или Java предпочел бы

VD>Ну, у .NET тоже есть Моно и Core. Для сервисов и прочего не гуевого софта этого хватает.

Уй да ладно. Mono – это вообще знатное извращение, которое в теории как бы работает. Core – есть, но разнообразие библиотек автоматом исчезает, так как не входят в Core. И, что не маловажно, Core – это Microsoft, а Microsoft – это NIH и полнейшая непредсказуемость. Они столько всего закопали (включая SilverLight), что нужно быть большим оригиналом чтобы влезть в Core для коммерческого продукта.

VD>Ну, вот и у Немерла все тоже самое. Но Go раскрутили. И ты утверждаешь, что Google в этом не виноват.

Хорошо, в целом ты прав про раскрутру. Но то что Nemerle по популярности даже D не догнало – проблема почти полностью на стороне .NET-а

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

KP>Core – есть, но разнообразие библиотек автоматом исчезает, так как не входят в Core.

Библиотеки не обязаны входить в Core, им достаточно таргетить Netstandard. После этого они могут использоваться на любой платформе, которая реализует Netstandard: .NET Framework, Xamarin, .NET Core, UWP.

KP>а Microsoft – это NIH и полнейшая непредсказуемость.

А Google Golang — предсказуемость и определённость?

KP>Они столько всего закопали (включая SilverLight)

Ну, Google наверное поболее сервисов закопали: Discontinued_products_and_services.

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

_>>Хм, и что же там так завязано? Я вот например особо не вижу там конструкций, которые нельзя бы было реализовать без GC.
WH>Например, замыкания сразу становятся неполноценными.

И в чём же их неполноценность например в C++? )

WH>Да и вообще весь код, написанный на немерле рассчитан на глобальный ГЦ.
WH>Так что даже если сделать язык, который выглядит как немереле, но без глобального ГЦ программы, написанные на немерле ты на нём, не запустишь. Даже если скомпилируешь работать они не будут.

А, ну это конечно. Но не думаю что это проблема на данный момент — вряд ли у языка есть много уже написанного полезного ПО. Кроме разве что самих же компиляторов Nemerle и остального. Ну а это мы уже обсуждали — в начале и .net версия пойдёт. А когда-нибудь потом, специально для них, можно и GC приделать.

_>>Нуу обязательный GC сразу закроет часть ниш для этого языка. Причём некоторые из них сейчас весьма популярны и активно развиваются. Так что с точки зрения широты обхвата лучше без этого.
WH>Какие и почему?

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

Далее, если говорить о классическом GC (типа того, что в .net), то автоматически отлетают ещё и все LL области (включая весьма денежную сейчас HFT). Кстати, а в последнее время наработки в области LL начали интересоваться уже и топовые онлайн игры и всяческие средства связи (аудио, видео и т.п.).

_>>3. Современный C++. В приложение нет ни одного new или delete вообще. При этом эффективность и применимость получаемого кода не хуже чем у древнего C.
WH>Это одна из многих форм ГЦ.

Ха, ну если называть это GC, то тогда можешь вполне считать что я за GC! Но на мой взгляд это называется совсем по другому: RAII+объекты на стеке+семантика перемещения+набор правильных контейнеров в стандартной библиотеке.

_>>Так вот, глядя на эту картину... Ты всё равно считаешь наличие GC прогрессом? )
WH>Да. Тем более что можно сделать систему, которая будет работать намного лучше, чем, то что есть в С++.
WH>И с точки зрения безопасности кода. И с точки зрения производительности.

С удовольствием ознакомлюсь с такими техниками. )

_>>каких вещей там точно не должно быть (например интроспекции времени исполнения)
WH>Согласен. Стандартная реализация интроспекции времени исполнения всегда не адекватна задачам, которые с её помощью решаются.
WH>Гораздо лучший вариант сгенерировать всё что нужно во время компиляции.
WH>И языки на основе нитры тут безусловные фавориты.

Позитивно)

_>>и какие точно должны быть (например прозрачный вызов C библиотек и системного API).
WH>Если мы делаем переносимый макроассемблер, то это получится, само собой. Но про безопасность языка можно сразу забыть.
WH>Если язык более высокого уровня, то нужно делать обёртки. Даже в С++ напрямую С библиотеки не используют.

Обёртки конечно же надо делать, но это может/должен делать сам прикладной программист, подключая какую-то нестандартную C библиотеку. А для этого у него в языке должна быть встроенная возможность прозрачно объявить внешнюю функцию, что-то вроде:

extern ccall ptr malloc(size);
extern stdcall ptr VirtualAlloc(ptr, size, uint, uint);

и чтобы компилятор и компоновщик автоматом организовали правильный вызов из соответствующей библиотеки. Да, а в идеале ещё было бы иметь конвертер h файлов (потому как это не только формат языков C/C++, но ещё и формат системного API во всех современных ОС) в файлы нашего языка с подобными объявлениями.

_>>По факту никакие не оказались рабочими. ))) Это я про общую концепцию подобной ОС, а не про отдельные наработки в мелочах. )
WH>Почему?
WH>То, что манагеры из мелкософт закрыли проект аргументом, не является.

И не только они) Нигде проекты такого рода не выжили. )

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

_>>О, действительно интересно. Прямо на первой же странице все примеры демонстрируют именно то, о необходимости наличия чего я уже писал в этой теме. А именно: данные на стеке, работа с указателями, прямое выделение памяти, прозрачные вызовы C библиотек, бэкенд через LLVM. Правда при этом у них указано, что сам язык управляемый — интересно как это там внутри всё сочетается.
N>Дедушка без управляемости это уже бабушка, как справедливо заметил Wolfhound. Scala native это 100% Скала. В смысле там только бэкенд другой, фронтенды взяты из jvm версий [Нитра не нужна! ]. "ФронтендЫ" потому что их сейчас два: scalac (прод) и dotty (новый). Все нативные плюшки сделаны через обычные механизмы (аннотации и т.д.).

Так может они ещё и всю рефлексию с боксингом от JVM оставили? ) Если да, то боюсь толка от языка много не будет...

N>В данный момент для ГЦ традиционно используют Boehm, потом собираются менять. Это не отменяет конечно, что можно прямо звать malloc, etc, то есть "гибридный" подход в терминологии Влада.

Угу, похоже на подход D. Можно использовать, а можно нет. Но вообще на мой взгляд у них тут гораздо полезнее даже не malloc и т.п, а возможность нормального размещения объектов на стеке. Хотя и с длинным синтаксисом. )))

_>>Кстати, у них там видно одно интересное решение, про которое я уже тоже тут говорил, как про полезную временную меру. Они не стали страдать с разработкой своей стандартной библиотеки, а просто взяли готовую библиотеку C. Поэтому у них там во всех примерах сплошные printf и т.п.
N>Не совсем. Они хотят иметь совместимость до уровня работоспособности чистых Scala-библиотек типа Акка/Spark. Для этого они ограничено портируют явовские нэймспейсы на нативную Скалу ручками. Автор говорит, что это довольно просто. Если уровень поддержки достаточный, то какой-нибудь scala.collection._ должна работать из коробки.

А, ну тут у них совсем другая ситуация, по отношению к Nemerle. У последнего, как я понял, нет своей персональной стандартной библиотеки — используется вариант от .net. А у Scala, как я понял, есть своя библиотека (контейнеры и т.п.), написанная на этом же языке, а не прямое использование jvm. Так что абсолютно логично, что её необходимо портировать. Т.е. с одной стороны это больше работы в самом начале, но зато быстро получается нормальный готовый продукт. А в случае Nemerle с одной стороны это не обязательно с самого начала, а с другой придётся ещё самим в начале проектировать подобную библиотеку, а потом делать реализацию под конкретную платформу.

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

WH>http://joeduffyblog.com/2015/11/03/blogging-about-midori/
WH>Букв много. Но всё по делу. Перед созданием нового языка читать обязательно.
WH>В двух словах: Мужик работал над созданием полностью управляемой ОС и пишет какие были варианты, какие из них оказались рабочими и какие нет. А главное почему.

Это в одном слове. Лучше опиши, что там у него интересного было. А то букв слишком много. Начал читать, но уснул. Все что успел прочесть — какие-то банальности.

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

WH>>Например, замыкания сразу становятся неполноценными.
_>И в чём же их неполноценность например в C++? )
Захвати локальную переменную.
Сохрани замыкание.
Выйди из функции.
Что будет?

_>Ну для начале априори отлетает весь низкий уровень (драйверы, микроконтроллеры и т.п.),
Это просто не правда.
Есть работающие ОС, в которых все драйверы управляемые.

_>что закрывает доступ ко многим бурно развивающимся сейчас областям (типа IoT, носимой электроники и т.п.).
Тут вообще никаких проблем. От слова совсем. Туда почти что угодно влезет.

_>Далее, если говорить о классическом GC (типа того, что в .net), то автоматически отлетают ещё и все LL области (включая весьма денежную сейчас HFT). Кстати, а в последнее время наработки в области LL начали интересоваться уже и топовые онлайн игры и всяческие средства связи (аудио, видео и т.п.).
Так есть и другие алгоритмы например
https://www.azul.com/resources/azul-technology/azul-c4-garbage-collector/

WH>>И с точки зрения безопасности кода. И с точки зрения производительности.
_>С удовольствием ознакомлюсь с такими техниками. )
Re: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 29.10.14

Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 29.10.14

Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 30.10.14

Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 30.10.14

_>Обёртки конечно же надо делать, но это может/должен делать сам прикладной программист, подключая какую-то нестандартную C библиотеку. А для этого у него в языке должна быть встроенная возможность прозрачно объявить внешнюю функцию, что-то вроде:
Ты всё на какие-то банальности скатываешься. То о чём ты говоришь делается всегда. Иначе просто программу на современной ОС не запустить.

WH>>То, что манагеры из мелкософт закрыли проект аргументом, не является.
_>И не только они) Нигде проекты такого рода не выжили. )
Это не аргумент.
До недавнего времени не было ни одного генератора парсеров который одновременно генерировал бы быстрый парсер и умел качественно восстанавливаться после ошибок без единой подсказки со стороны программиста.
А чтобы при этом ещё и умел во время разбора изменять грамматику на основе встреченных в коде данных... это была вообще не научная фантастика.
Но я такой написал. Именно его использует нитра. И в принципе понятно, как сделать его ещё лучше.

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

WH>>>Например, замыкания сразу становятся неполноценными.
_>>И в чём же их неполноценность например в C++? )
WH>Захвати локальную переменную.
WH>Сохрани замыкание.
WH>Выйди из функции.
WH>Что будет?

Всё нормально будет:

auto f=[]{
    auto s="hello world!"s;
    return [s=move(s)]{return s;};//если записать короче, в виде "return [=]{return s;};", то тоже будет работать, но произойдёт лишнее копирование.
};
cout<<f()();//выведет "hello world!"

_>>Ну для начале априори отлетает весь низкий уровень (драйверы, микроконтроллеры и т.п.),
WH>Это просто не правда.
WH>Есть работающие ОС, в которых все драйверы управляемые.

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

_>>что закрывает доступ ко многим бурно развивающимся сейчас областям (типа IoT, носимой электроники и т.п.).
WH>Тут вообще никаких проблем. От слова совсем. Туда почти что угодно влезет.

Ну давай, расскажи мне как написать под мой любимый (самое идеальное сочетание возможностей/цене в данный момент) STM32F042F6P6 код на каком-нибудь из современных языков с GC.

_>>Далее, если говорить о классическом GC (типа того, что в .net), то автоматически отлетают ещё и все LL области (включая весьма денежную сейчас HFT). Кстати, а в последнее время наработки в области LL начали интересоваться уже и топовые онлайн игры и всяческие средства связи (аудио, видео и т.п.).
WH>Так есть и другие алгоритмы например
WH>https://www.azul.com/resources/azul-technology/azul-c4-garbage-collector/

Угу, Zing справляется (и там кстати дело не только в GC — переделано всё). Правда результат всё равно хуже C++ решений, но хотя бы просто можно писать в данной области. Так а у тебя есть готовые наработки такого уровня, чтобы вставить их в свой язык с GC (причём это ещё и опцией должно быть, т.к. актуально только для части задач)?

WH>>>И с точки зрения безопасности кода. И с точки зрения производительности.
_>>С удовольствием ознакомлюсь с такими техниками. )
WH>Re: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 29.10.14

WH>Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 29.10.14

WH>Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 30.10.14

WH>Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 30.10.14

Если всё указанное делать руками, то не вижу никакой разницы с каким-нибудь обычным аллокатором на пуле из C++. Если же ты подразумевал в данном тексте, что это всё как-то автоматически организует компилятор, то я слабо себе представляют как подобное возможно.

_>>Обёртки конечно же надо делать, но это может/должен делать сам прикладной программист, подключая какую-то нестандартную C библиотеку. А для этого у него в языке должна быть встроенная возможность прозрачно объявить внешнюю функцию, что-то вроде:
WH>Ты всё на какие-то банальности скатываешься. То о чём ты говоришь делается всегда. Иначе просто программу на современной ОС не запустить.

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

Но понятно, что на практике в любом серьёзном языке естественно присутствует какая-то разновидность механизма FFI. Я же говорю не просто о самом факте наличия FFI, а уже о его конкретной реализации: для нативного языка это должно выглядеть не как P/Invoke или JNI, а ближе к варианту из C++. Причём это критически важный фактор для успешности подобного языка.

WH>>>То, что манагеры из мелкософт закрыли проект аргументом, не является.
_>>И не только они) Нигде проекты такого рода не выжили. )
WH>Это не аргумент.
WH>До недавнего времени не было ни одного генератора парсеров который одновременно генерировал бы быстрый парсер и умел качественно восстанавливаться после ошибок без единой подсказки со стороны программиста.
WH>А чтобы при этом ещё и умел во время разбора изменять грамматику на основе встреченных в коде данных... это была вообще не научная фантастика.
WH>Но я такой написал. Именно его использует нитра. И в принципе понятно, как сделать его ещё лучше.

Аналогия не является доказательством. )

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

_>Всё нормально будет:
Это нужно не забыть написать.
А если в два замыкания?

_>Ну и кому надо писать под эти дано сдохшие ОС? Мы же говорим тут не об общетеоретических возможностях, а о вполне конкретном положение на рынке.
Там тоже ничего не мешает.

_>Ну давай, расскажи мне как написать под мой любимый (самое идеальное сочетание возможностей/цене в данный момент) STM32F042F6P6 код на каком-нибудь из современных языков с GC.
А в такой штуке вообще управление памятью нужно?
В 6К нужно сразу всю память статически распределять.

_>Угу, Zing справляется (и там кстати дело не только в GC — переделано всё). Правда результат всё равно хуже C++ решений, но хотя бы просто можно писать в данной области. Так а у тебя есть готовые наработки такого уровня, чтобы вставить их в свой язык с GC (причём это ещё и опцией должно быть, т.к. актуально только для части задач)?
1)Ничего сверхъестественного там нет.
2)Я не собираюсь с глобальным ГЦ воевать.
Большая часть памяти вообще без ГЦ будет освобождаться.

_>Если всё указанное делать руками, то не вижу никакой разницы с каким-нибудь обычным аллокатором на пуле из C++. Если же ты подразумевал в данном тексте, что это всё как-то автоматически организует компилятор, то я слабо себе представляют как подобное возможно.
Главное я точно знаю, как такое возможно.
Первый пример в первом сообщении использует определённые умолчания при переписывании сигнатур функции и вывод типов внутри кода. Всё управление памятью сводится к двум unique.
Второй то что получается после переписывания и вывода типов.

Переписывание сигнатур тривиально. Все параметры, которые не помечены unique помещаем в один разделяемый кластер. Каждый параметр, помеченный unique помещаем в отдельный эксклюзивный кластер.
Для примерно 100% кода — это умолчание будет работать.

Вывод типов тупая раскраска многосвязного графа.
В начале граф бесцветный. Узлы графа, которые соответствуют параметрам функции и локальным вызовам unique красим в цвет соответствующего кластера. Далее красим этим цветом все смежные узлы. Если узел покрашен более чем одним цветом выдаём сообщение об ошибке. Если узел оказался бесцветным заводим ещё один кластер который живёт пока не завершиться функция и красим его цветом все бесцветные узлы.

_>Аналогия не является доказательством. )
Это не аналогия. Это демонстрация несостоятельности аргумента: Если до сих пор никто не смог, то это невозможно.
А другие аргументы ты так и не представил.

Лично я считаю, что управляемая ОС не только возможна, но и неизбежна. Ибо это единственный способ значительно повысить безопасность и производительность ОС.

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

WH>1)Их нельзя проигнорировать, а значит программа не будет молча глотать ошибки.
Правильно реализованные "коды возврата" тоже нельзя проигнорировать. И наоборот: при желании исключения тоже можно игнорировать: catch (...). В остальном спорить не буду.

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

_>Так может они ещё и всю рефлексию с боксингом от JVM оставили? ) Если да, то боюсь толка от языка много не будет...
Не в курсе. Помню из видео, что на какой-то числодробилке (вроде raytracing) оно в данный момент на ~20% медленней плюсов.

N>>Не совсем. Они хотят иметь совместимость до уровня работоспособности чистых Scala-библиотек типа Акка/Spark. Для этого они ограничено портируют явовские нэймспейсы на нативную Скалу ручками. Автор говорит, что это довольно просто. Если уровень поддержки достаточный, то какой-нибудь scala.collection._ должна работать из коробки.

_>А у Scala, как я понял, есть своя библиотека (контейнеры и т.п.), написанная на этом же языке, а не прямое использование jvm. Так что абсолютно логично, что её необходимо портировать.
Стандартную библиотека никто не трогает и она живет своей жизнью. Они портируют куски из явовской, необходимыe для ее поддержки.

_>А в случае Nemerle с одной стороны это не обязательно с самого начала, а с другой придётся ещё самим в начале проектировать подобную библиотеку, а потом делать реализацию под конкретную платформу.
В случае Nemerle может вообще ничего делать будет не надо, если MS выкатить открытый AOT-компилятор, к которому можно будет подкрутить все эти stack alloc и прочее.

Проблема с Немерле в том, что сам Немерле не нужен. Я уже им говорил, что нитру надо было делать кусками (парсер, IDE плагины, типизатор и т.д.) на популярной платформе/языке. Сложный нишевой продукт, написанный на никому неизвестном языке для платформы, которой не пользуются 80% target audience?! Оно не переживет даже "hit by a bus" или просто потерю интереса сам знаешь кого. Там наверняка есть полезные куски, так как ребята толковые и мне честно говоря жалко.

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

_>>Всё нормально будет:
WH>Это нужно не забыть написать.

Ты про move? Ну это как бы оптимизация. Т.е. в принципе для почти всех случаев ты можешь тупо писать [=] и всё будет работать. Не сработает только для объектов у которых запрещено копирование, но тут уже ругнётся компилятор. Плюс на больших объектах (типа гигабайтного vector'а) подобный код будет тормозить — тут как раз и надо "не забыть" про move. ))) Но хороший программист на C++ естественно не забудет указать это во всех возможных местах, из соображений перфекционизма. В принципе возможно в будущем подобное сможет делать и компилятор. Т.е. он уже делает это (сам вставляет move) в очень многих случаях (когда видит, что дальше объект гарантированно не используется, например в return), но пока ещё не во всех возможных — пока программисту иногда приходится ему помогать. Но развитие то не стоит на месте и возможно что в будущих версиях компиляторов практика явного указания move будет исчезать совсем.

WH>А если в два замыкания?

Ты имеешь в виду, два замыкания, захватывающие одну и ту же локальную переменную? Ну так это уже зависит от того, какое поведение ты хочешь в такой ситуации — тут же может быть много разных вариантов. Например могут быть независимые друг от друга копии в каждом замыкании. Могут быть ссылки на совместно используемый объект. Причём они могут быть модифицируемыми или нет (например в одном замыкание можно будет менять его, а в другом нет) и т.п. В общем множество разных вариантов. И все они естественно без проблем реализуются (причём не требуется ни GC, ни ручное управление памятью).

_>>Ну и кому надо писать под эти дано сдохшие ОС? Мы же говорим тут не об общетеоретических возможностях, а о вполне конкретном положение на рынке.
WH>Там тоже ничего не мешает.

Где там? Ты можешь написать на Java или C# драйвер для ядра винды или линуха? О чём вообще речь? )

_>>Ну давай, расскажи мне как написать под мой любимый (самое идеальное сочетание возможностей/цене в данный момент) STM32F042F6P6 код на каком-нибудь из современных языков с GC.
WH>А в такой штуке вообще управление памятью нужно?
WH>В 6К нужно сразу всю память статически распределять.

Естественно не нужно. Там всё выделение решается через глобальные (статически, причём компоновщик контролирует чтобы всё влезло) и локальные (тут, на стеке и реализуется вся "динамика") переменные. Вопрос в том, чтобы язык позволял использовать все свои возможности без требования необходимости работающего "new". Вот C++ это отлично может — даже в таких условиях работает всё, включая и замыкания и контейнеры с алгоритмами из STL и всё остальное. Так вот если допустим сделать нативный вариант Nemerle в лоб, без какой либо адаптации (типа отсутствия обязательного GC и т.п.), то по твоему он сможет аналогичное? )

_>>Угу, Zing справляется (и там кстати дело не только в GC — переделано всё). Правда результат всё равно хуже C++ решений, но хотя бы просто можно писать в данной области. Так а у тебя есть готовые наработки такого уровня, чтобы вставить их в свой язык с GC (причём это ещё и опцией должно быть, т.к. актуально только для части задач)?
WH>1)Ничего сверхъестественного там нет.
WH>2)Я не собираюсь с глобальным ГЦ воевать.
WH>Большая часть памяти вообще без ГЦ будет освобождаться.

Я и не говорю, что там какая-то магия. Просто это большой объём работы. Причём позволяющий всего лишь слегка приблизиться к результатам другого варианта, в котором его эффективность получается "на халяву" (не надо никакой тяжёлой работы с оптимизациями разных GC).

_>>Если всё указанное делать руками, то не вижу никакой разницы с каким-нибудь обычным аллокатором на пуле из C++. Если же ты подразумевал в данном тексте, что это всё как-то автоматически организует компилятор, то я слабо себе представляют как подобное возможно.
WH>Главное я точно знаю, как такое возможно.
WH>Первый пример в первом сообщении использует определённые умолчания при переписывании сигнатур функции и вывод типов внутри кода. Всё управление памятью сводится к двум unique.
WH>Второй то что получается после переписывания и вывода типов.
WH>Переписывание сигнатур тривиально. Все параметры, которые не помечены unique помещаем в один разделяемый кластер. Каждый параметр, помеченный unique помещаем в отдельный эксклюзивный кластер.
WH>Для примерно 100% кода — это умолчание будет работать.
WH>Вывод типов тупая раскраска многосвязного графа.
WH>В начале граф бесцветный. Узлы графа, которые соответствуют параметрам функции и локальным вызовам unique красим в цвет соответствующего кластера. Далее красим этим цветом все смежные узлы. Если узел покрашен более чем одним цветом выдаём сообщение об ошибке. Если узел оказался бесцветным заводим ещё один кластер который живёт пока не завершиться функция и красим его цветом все бесцветные узлы.

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

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

WH>Лично я считаю, что управляемая ОС не только возможна, но и неизбежна. Ибо это единственный способ значительно повысить безопасность и производительность ОС.

А что ты называешь управляемой ОС? Такую, в API которой не присутствует разновидность VirtualFree и при этом есть встроенный глобальный сборщик мусора? Или что?

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

_>>Так может они ещё и всю рефлексию с боксингом от JVM оставили? ) Если да, то боюсь толка от языка много не будет...
N>Не в курсе. Помню из видео, что на какой-то числодробилке (вроде raytracing) оно в данный момент на ~20% медленней плюсов.

Да, у них там в репозитории как раз 3 реализации (jvm, c++ и их) примера с raytracing. Надо будет приглядеть к нему, что там за алгоритмы и циклы.

Просто это принципиальный момент. Потому как даже если взять мощный оптимизатор, умеющий разные эффективные вещи типа автовекторизации (а LLVM это отлично умеет), то в случае классической Java это будет абсолютно бесполезно, просто потому что из-за специфики устройства языка данные не будут укладываться в схему SIMD. И как следствие такой код будет уже в на порядок отставать от аналогичного C++ кода. Но только на определённых (где главную часть алгоритма занимают распараллеливаемые циклы) честных (например надо не забыть включить правильную оптимизацию в C++ варианте) тестах. Ну и SIMD — это не единственная проблема, там много чего ещё следует.

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

_>>А у Scala, как я понял, есть своя библиотека (контейнеры и т.п.), написанная на этом же языке, а не прямое использование jvm. Так что абсолютно логично, что её необходимо портировать.
N>Стандартную библиотека никто не трогает и она живет своей жизнью. Они портируют куски из явовской, необходимыe для ее поддержки.

Хм, ну тоже вариант. Позволяет максимально быстро получить нужный результат. Хотя не уверен, что такой результат будет самым оптимальным (т.к. грубо говоря java api в условиях нативного мира далеко не идеально), но для начала точно сойдёт.

_>>А в случае Nemerle с одной стороны это не обязательно с самого начала, а с другой придётся ещё самим в начале проектировать подобную библиотеку, а потом делать реализацию под конкретную платформу.
N>В случае Nemerle может вообще ничего делать будет не надо, если MS выкатить открытый AOT-компилятор, к которому можно будет подкрутить все эти stack alloc и прочее.

В MS уже сами занялись этим (размещением на стеке), так же как и убийством рефлексии и ещё некоторых оптимизациях. Естественно только в рамках .net native, т.к. там пока можно не сильно держаться за обратную совместимость. Теоретически, если это направление "развить и углубить" (например избавиться от P/Invoke и ещё несколько нюансов), а так же снять зависимость от MS (через открытие исходников под свободной лицензией), то этим всем уже реально можно будет пользоваться. Правда к современному .net это будет иметь уже совсем слабое отношение.

N>Проблема с Немерле в том, что сам Немерле не нужен. Я уже им говорил, что нитру надо было делать кусками (парсер, IDE плагины, типизатор и т.д.) на популярной платформе/языке. Сложный нишевой продукт, написанный на никому неизвестном языке для платформы, которой не пользуются 80% target audience?! Оно не переживет даже "hit by a bus" или просто потерю интереса сам знаешь кого. Там наверняка есть полезные куски, так как ребята толковые и мне честно говоря жалко.

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

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

_>Всё нормально будет:
_>

_>auto f=[]{
_>    auto s="hello world!"s;
_>    return [s=move(s)]{return s;};//если записать короче, в виде "return [=]{return s;};", то тоже будет работать, но произойдёт лишнее копирование.
_>};
_>cout<<f()();//выведет "hello world!"
_>

Что если между созданием замыкания и его возвратом мы хотим использовать замыкаемую переменую?

#include <cstdlib>
#include <iostream>
#include <string>

int main()
{
    using namespace std::string_literals;

    auto f = [] {
        auto s = "hello world!"s;
        auto result = [s = move(s)] { return s; };
        std::cout << s << std::endl; // Ожидаем `hello world!`.
        return result;
    };
    std::cout << f()() << std::endl;

    std::system("pause");

    return 0;
}

_>Могут быть ссылки на совместно используемый объект.

Ну не то чтобы прям сырые ссылки; ты имеешь в виду умные указатели. Ведь в языке отсутствует такая фича как невыразимость висячик ссылок:

auto f = [] {
    auto s = "hello world!"s;
    auto result = [&] { return s; }; // &
    std::cout << s << std::endl;
    return result;
};
std::cout << f()() << std::endl;

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

_>Ну я думаю, что на данном этапе язык, на котором написан сам их продукт, не так принципиален.
Нитру без Немерле использовать нельзя. То есть языками реализованными на ней пользоваться конечно можно, но если ты хочешь писать свой язык, то тебе придется узнать Немерле и еще пяток написанных на нем DSL.

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

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

Q>Что если между созданием замыкания и его возвратом мы хотим использовать замыкаемую переменую?
Q>

#include <cstdlib>
Q>#include <iostream>
Q>#include <string>

Q>int main()
Q>{
Q>    using namespace std::string_literals;

Q>    auto f = [] {
Q>        auto s = "hello world!"s;
Q>        auto result = [s = move(s)] { return s; };
Q>        std::cout << s << std::endl; // Ожидаем `hello world!`.
Q>        return result;
Q>    };
Q>    std::cout << f()() << std::endl;

Q>    std::system("pause");

Q>    return 0;
Q>}

"Ожидать `hello world!`" в подобном коде могут только люди не читавшие стандарт C++. )))

_>>Могут быть ссылки на совместно используемый объект.
Q>Ну не то чтобы прям сырые ссылки; ты имеешь в виду умные указатели. Ведь в языке отсутствует такая фича как невыразимость висячик ссылок:
Q>

auto f = [] {
Q>    auto s = "hello world!"s;
Q>    auto result = [&] { return s; }; // &
Q>    std::cout << s << std::endl;
Q>    return result;
Q>};
Q>std::cout << f()() << std::endl;

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

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

_>>Ну я думаю, что на данном этапе язык, на котором написан сам их продукт, не так принципиален.
N>Нитру без Немерле использовать нельзя. То есть языками реализованными на ней пользоваться конечно можно, но если ты хочешь писать свой язык, то тебе придется узнать Немерле и еще пяток написанных на нем DSL.

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

_>>Во всяком случае пока есть кому заниматься его развитием.
N>Немерле в данный момент времени это никому не интересное legacy, где по желанию левой пятки поправляет простые косяки три (или уже один?) человека по необходимости. Никакого развития у него нет и не будет. Новый Немерле2 на Нитре, даже если и будет реализован, согласно заявленному функционалу (более навороченные макросы) будет вряд ли круче уже выпущенной скалы.

Лично мне был бы интересен язык с возможностями современного C++ и наличием макросов в стиле Scala/Nemerle. Одно время я думал, что такой язык появится уже вот вот: Rust. Но при ближайшем рассмотрение оказалось, что он менее удобен чем C++ — в одних местах они слишком перемудрили, а в других наоборот слишком упростили.

Теперь вот думаю, не попробовать ли сделать что-то своё, когда появится свободное время. Ведь если у нового языка от рождения будет поддержка в топовых IDE (как раз благодаря технологиям ребят) и при этом нативная поддержка C и возможно C++ библиотек (с автоматическим конвертером), то это уже сразу получится рабочий инструмент, а не просто игрушка одиночки для фана. )))

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

_>"Ожидать `hello world!`" в подобном коде могут только люди не читавшие стандарт C++. )))

Так ведь его просто так не прочитаешь — он же платный!

_>На самом деле может быть что угодно (но естественно не так, как в твоём примере — очередном нарушение стандарта)

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

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

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

_>изначальное размещение нашей переменной будет произведено не на стеке, а в куче.

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

Я-то не против наличия отсуствия сборщика мусора. Просто сопроводил примером утверждение WolfHound о замыканиях в языках без GC.

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


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

Вот это и есть ручное управление памятью. Забыть что-то или ошибиться при этом не составляет труда. А далее сиди тупи "где же ошибка?".

Когда ты пишешь на языке с GC таких проблем просто нет.

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

Ты должен будешь продумывать каждый указатель, каждое поле.

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

Как говорил Бендер из Футурамы: "не следует доверять человеку работу машины".

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

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

И никто не запрещает вставлять в язык средства автоматизации ручного управления памятью.

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

N>Немерле в данный момент времени это никому не интересное legacy, где по желанию левой пятки поправляет простые косяки три (или уже один?) человека по необходимости. Никакого развития у него нет и не будет. Новый Немерле2 на Нитре, даже если и будет реализован, согласно заявленному функционалу (более навороченные макросы) будет вряд ли круче уже выпущенной скалы.

Какой-то кромешный ад заблуждений.

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

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

Скала не имеет никаких возможностей по расширению синтаксиса. Сделать на ней что-то вроде Ammy невозможно в принципе. Как не странно "легаси" язык в купе с фремворком на нем же написанным (по сути Нитра это библиотеки написанные на Немерле) это делать позволяет.

Это как раз Скала не нужна. Язык переусложнен и выдает медленный код бай дизайн. Его популярность (если это можно назвать популярность) определяется только тем, что его есть кому популяризировать.

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

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

Наоборот я хочу в Немерле 2 убрать хардкод имевшийся в Немерле 1. То есть сам язык будет даже меньше и будет написан на более высоком уровне.

Концепция Немерла — это решение сложных проблем за счет расширения языка и создания ДСЛ-ей. Эта концепция отлично показала себе на Нитре. Нужно только сделать процесс расширения еще проще и предоставить людям базу языка и набор удобных расширений.

Что касается платформы, то тут я с вами соглашусь. Иметь нативный вариант и вариант под Яву было бы здорово. Но мы все сразу не потяем. Мы дотнетчики и в других платформах придется разбираться. А времени и так не хватает. Задачи адски сложные и объемные. Качественная их реализация требует много усилий.

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

Советовать и критиковать очередь стоит. А очередь делать никто встать не спешит.

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

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

_>>Ну я думаю, что на данном этапе язык, на котором написан сам их продукт, не так принципиален.
N>Нитру без Немерле использовать нельзя. То есть языками реализованными на ней пользоваться конечно можно, но если ты хочешь писать свой язык, то тебе придется узнать Немерле и еще пяток написанных на нем DSL.

А то какой-нибудь bison и yacc узнавать не надо.

_>>Во всяком случае пока есть кому заниматься его развитием.
N>Немерле в данный момент времени это никому не интересное legacy, где по желанию левой пятки поправляет простые косяки три (или уже один?) человека по необходимости. Никакого развития у него нет и не будет. Новый Немерле2 на Нитре, даже если и будет реализован, согласно заявленному функционалу (более навороченные макросы) будет вряд ли круче уже выпущенной скалы.

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

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

_>>"Ожидать `hello world!`" в подобном коде могут только люди не читавшие стандарт C++. )))
Q>Так ведь его просто так не прочитаешь — он же платный!

https://github.com/cplusplus/draft/blob/master/papers/n4140.pdf?raw=true — текст C++14 с точностью до пары незначительных опечаток.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4618.pdf — очень близкое к тому, что будет принято в этом году как C++17.

_>>На самом деле может быть что угодно (но естественно не так, как в твоём примере — очередном нарушение стандарта)
Q>Если я нарушаю Стандарт, так пусть бы компиялтор меня остановил. Компиляторы нормальных языков обычно так делают.

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

_>>В случае наличия необходимости работать с одним объектом в произвольных местах кода (кстати это весьма редкая ситуация, т.к. она мешает построению потокобезопасного по построению кода и соответственно применяется только если уж точно по другому нельзя)
Q>Не вижу проблем работать с одним объектом в произвольных местах кода, если объект не изменяется.

Если не изменяется, то конечно не мешает многопоточности. ) Кстати, а как это будет реализовано например на C#? Ну т.е. как там выглядит замыкание, захватывающее константный объект? Хотя я что-то уже не припомню как там вообще объявить неизменяемую локальную переменную нашего класса...

_>>изначальное размещение нашей переменной будет произведено не на стеке, а в куче.
Q>Так ведь не начальное, а в процессе рефакторинга. Изменился контекст, и приходится переделывать тело лямбды. В языках со сборкой мусора в данном примере — нет.

Вообще то и здесь можно изначально написать в традициях "языков со сборкой мусора", только это будет длиннее в исходном коде (в смысле длиннее чем вариант на стеке, но при этом ровно так же, как и в каком-нибудь C#/Java) и намного менее эффективно при исполнение. Поэтому естественно все будут писать изначально в нормальном удобном и эффективном стиле, а в 0,001 проценте случаев (ты сам то понял какая у нас извращённая архитектура получилась в конце всех этих рассуждений? Функция, возвращающая из себя два замыкания, связанные между собой общими данными, созданными в этой функции — ты когда-нибудь видел такое на практике?), в которых уж точно нельзя написать по нормальному, сделают рефакторинг и напишут в точности как в языках со сборкой мусора.

Q>Я-то не против наличия отсуствия сборщика мусора. Просто сопроводил примером утверждение WolfHound о замыканиях в языках без GC.

Ещё раз поясняю. Проблем нет в принципе, никаких. Есть исключительно вопрос оптимизации. В большинстве случаев замыкания в C++ будут эффективнее чем в Java/C# и т.п., а в редких случаях будут работать точно так же.

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

_>>На самом деле может быть что угодно (но естественно не так, как в твоём примере — очередном нарушение стандарта), смотря по ситуации. Ключевая разница будет в другом. В случае наличия необходимости работать с одним объектом в произвольных местах кода (кстати это весьма редкая ситуация, т.к. она мешает построению потокобезопасного по построению кода и соответственно применяется только если уж точно по другому нельзя), изначальное размещение нашей переменной будет произведено не на стеке, а в куче. А дальше там уже могут быть десятки разных способов как удобнее оформить этот факт, в зависимости от конкретной ситуации.
VD>Вот это и есть ручное управление памятью. Забыть что-то или ошибиться при этом не составляет труда. А далее сиди тупи "где же ошибка?".

Где ручное то? Там всё автоматически будет. Или под ручным ты подразумеваешь тот факт, что программист должен будет выбрать сам (а не следовать навязанному языком) где размещать объект, на стеке (в 99,9% случаев на современном C++) или в куче (в 0,1% случаев на C++ и в 100% случаев на C#)?

VD>Когда ты пишешь на языке с GC таких проблем просто нет.

Да, да, и поэтому подобные http://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/ статьи мне только мерещатся. ))) Особенно мне там нравится заголовок "Less Managed, More Control". Хотя результат в конце статьи тоже выглядит не плохо:

So? What are the results of these changes? If you run the program above:
The stack version will run in 400 ms with 0 GC collect
The heap version will run in 5000 ms with 100+ GC collect

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

Ну, да, это как раз главное преимущество языков типа Java/C# — намутите любой кривой код и он всё равно кое-как заработает. Идеально для написания всяческого нетребовательного энтерпрайза слабыми внутренними программистами. Только вот непонятно что ты хочешь ловить в этой среде со своим сложным инструментом (в котором главным преимуществом является МП, которое в принципе на уровне мозга может воспринимать только часть программистов).

VD>Ты должен будешь продумывать каждый указатель, каждое поле.
VD>Если для программирования микроконтроллеров это приемлемо (в виду крайне ограниченности в ресурсах), то при программировании под десктоп или даже под телефон — это явное убийство времени и занятие своего мозга не продуктивным процессом.
VD>Как говорил Бендер из Футурамы: "не следует доверять человеку работу машины".

Только вот почему-то я ничего не продумываю, а пишу в 99,9% случаев просто объект класса (а не ссылку или указатель). Потому что в нормальном коде ситуации с расшариванием ссылок на нестатические объекты крайне редка. Причём в этом самом редком случае опять же есть полностью известный алгоритм действий (в этом случае получается полный аналог кода на Java/C#), так что опять же не надо даже включать мозг. )))

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

В современных ОС — невозможно.

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

Естественно GC далеко не главная причина тормозов Jvm/.Net. Главная проблема с GC не в медленности кода, а совсем в другом.

VD>И никто не запрещает вставлять в язык средства автоматизации ручного управления памятью.

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

VladD2,

У меня тут в процессе дискуссии появилась ещё одна мысль. Возможно я бы смог поучаствовать в развитие проекта не просто для фана, а уже по делу. Но для возможности этого мне надо знать ответ на один вопрос. Вот предположим у тебя есть твоя доработанная Nitra. И при этом кто-то написал для неё полноценный бэкенд через LLVM. Сможешь ли ты сделать на базе этого точную копию скажем C++14 (это естественно не итоговая цель, а важнейший промежуточный шаг, хотя и он при определённом подходе может принести вам коммерческий успех)? Ну чтобы итоговый продукт мог компилировать произвольный C++ исходник и результат не отличался от clang'а. И при этом естественно работала бы поддержка в IDE.

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

_>Где там? Ты можешь написать на Java или C# драйвер для ядра винды или линуха? О чём вообще речь? )
Где я сказал жаба или C#? Я сказал ГЦ.

_>Естественно не нужно. Там всё выделение решается через глобальные (статически, причём компоновщик контролирует чтобы всё влезло) и локальные (тут, на стеке и реализуется вся "динамика") переменные. Вопрос в том, чтобы язык позволял использовать все свои возможности без требования необходимости работающего "new". Вот C++ это отлично может — даже в таких условиях работает всё, включая и замыкания и контейнеры с алгоритмами из STL и всё остальное. Так вот если допустим сделать нативный вариант Nemerle в лоб, без какой либо адаптации (типа отсутствия обязательного GC и т.п.), то по твоему он сможет аналогичное? )
Если сделать замыкания такими же убогими как в С++ то сможет.
Только радости от этого никакой.
И я вообще считаю большой ошибкой делать один язык для систем где на всё 6К и где память измеряется гигабайтами.

WH>>Лично я считаю, что управляемая ОС не только возможна, но и неизбежна. Ибо это единственный способ значительно повысить безопасность и производительность ОС.
_>А что ты называешь управляемой ОС? Такую, в API которой не присутствует разновидность VirtualFree и при этом есть встроенный глобальный сборщик мусора? Или что?

Midori was built on a foundation of three kinds of safety: type, memory, and concurrency-safety. These safeties eliminated whole classes of bugs “by-construction” and delivered significant improvements in areas like reliability, security, and developer productivity. They also fundamentally allowed us to depend on the type system in new and powerful ways, to deliver new abstractions, perform novel compiler optimizations, and more. As I look back, the biggest contribution of our project was proof that an entire operating system and its ecosystem of services, applications, and libraries could indeed be written in safe code, without loss of performance, and with some quantum leaps forward in several important dimensions.

И в мидори нет глобального сборщика мусора.
Глобальный сборщик мусора зло и не нужен.

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

_>Сможешь ли ты сделать на базе этого точную копию скажем C++14
Технически (с некоторыми доработками нитры) это возможно. Но на практике из-за запутанности и монструозности С++ это не один десяток человеколет работы.

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

_>>Где там? Ты можешь написать на Java или C# драйвер для ядра винды или линуха? О чём вообще речь? )
WH>Где я сказал жаба или C#? Я сказал ГЦ.

Это было для простоты формулировки. Ну ОК, давай возьми любой другой язык с обязательным GC. Вот например можно Go взять (он даже нативный как раз). И попробуй написать на нём драйвер под винду или линух. )))

_>>Естественно не нужно. Там всё выделение решается через глобальные (статически, причём компоновщик контролирует чтобы всё влезло) и локальные (тут, на стеке и реализуется вся "динамика") переменные. Вопрос в том, чтобы язык позволял использовать все свои возможности без требования необходимости работающего "new". Вот C++ это отлично может — даже в таких условиях работает всё, включая и замыкания и контейнеры с алгоритмами из STL и всё остальное. Так вот если допустим сделать нативный вариант Nemerle в лоб, без какой либо адаптации (типа отсутствия обязательного GC и т.п.), то по твоему он сможет аналогичное? )
WH>Если сделать замыкания такими же убогими как в С++ то сможет.
WH>Только радости от этого никакой.

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

WH>И я вообще считаю большой ошибкой делать один язык для систем где на всё 6К и где память измеряется гигабайтами.

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

_>>А что ты называешь управляемой ОС? Такую, в API которой не присутствует разновидность VirtualFree и при этом есть встроенный глобальный сборщик мусора? Или что?
WH>

WH>Midori was built on a foundation of three kinds of safety: type, memory, and concurrency-safety. These safeties eliminated whole classes of bugs “by-construction” and delivered significant improvements in areas like reliability, security, and developer productivity. They also fundamentally allowed us to depend on the type system in new and powerful ways, to deliver new abstractions, perform novel compiler optimizations, and more. As I look back, the biggest contribution of our project was proof that an entire operating system and its ecosystem of services, applications, and libraries could indeed be written in safe code, without loss of performance, and with some quantum leaps forward in several important dimensions.

WH>И в мидори нет глобального сборщика мусора.
WH>Глобальный сборщик мусора зло и не нужен.

Т.е. я правильно тебя понял, что именно архитектура Midori кажется тебе идеалом ОС будущего?

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

_>>Сможешь ли ты сделать на базе этого точную копию скажем C++14
WH>Технически (с некоторыми доработками нитры) это возможно. Но на практике из-за запутанности и монструозности С++ это не один десяток человеколет работы.

Хм, если инструмент, позиционирующийся как средство для лёгкого создания новых языков, будет требовать десяток человеколет для создания одного языка (причём речь по сути только о фронтенде), то зачем он вообще такой нужен?

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

_>Хм, если инструмент, позиционирующийся как средство для лёгкого создания новых языков, будет требовать десяток человеколет для создания одного языка (причём речь по сути только о фронтенде), то зачем он вообще такой нужен?
Я говорю не вообще, а конкретно про С++.
Такое впечатление что его создавали специально для того чтобы никто не смог компилятор написать.
Да никто и не смог. Есть хоть один компилятор который на 100% соответствует стандарту?
А уж как бедные создатели ИДЕ страдают Я обсуждал проблемы этого дела с людьми которые этим занимаются. Там АД!

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

_>Это было для простоты формулировки. Ну ОК, давай возьми любой другой язык с обязательным GC. Вот например можно Go взять (он даже нативный как раз). И попробуй написать на нём драйвер под винду или линух. )))
Нативности тут недостаточно. Нужен ещё и инструментарий.
Он для ГО есть?

_>Ну тебе может и никакой, а другим нравится (что они в разы быстрее). Деланием продукта в ориентации на свои вкусы вы занимаетесь уже давно и успехов (я не про технические) пока не видно. Может стоит попробовать поделать что-то в ориентации на вкусы потенциальных пользователей? )
Так разным пользователям нужно разное.
Вот если пользователь готов платить тогда другое дело. Бросим всё и будем развивать проект в нужном этому пользователю направлении.
А пока у нас уже есть пользователь, который сделал на нитре коммерческий продукт.
http://www.ammyui.com/

_>Более того, я думаю ты в курсе что те же самые языки (хотя ещё плюс Фортран, которого нет на МК) доминируют на мейнфреймах и суперкомпьтерах... ))) Ну а насчёт того ошибка это или нет... Быть может это ты чего-то не понимаешь, а не вся индустрия? )
А давай сравним с количеством жабы и .НЕТа в индустрии.

Тут у нас два принципиально разных сценария.
1)Каждый байт на счету.
2)Инфраструктуру в несколько мегабайт никто не заметит и на перерасход памяти в десяток другой процентов всем наплевать. Но при этом есть сотни мегабайт кода, который пишут сотни программистов.

_>Т.е. я правильно тебя понял, что именно архитектура Midori кажется тебе идеалом ОС будущего?
Примерно. Там много что можно улучшить. Но глобальное направление выбрано верно.

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

_>>Это было для простоты формулировки. Ну ОК, давай возьми любой другой язык с обязательным GC. Вот например можно Go взять (он даже нативный как раз). И попробуй написать на нём драйвер под винду или линух. )))
WH>Нативности тут недостаточно. Нужен ещё и инструментарий.
WH>Он для ГО есть?

Причём тут Go? ) Он просто для примера был. Я же тебе написал, выбери ЛЮБОЙ, какой тебе нравится язык с обязательным сборщиком мусора и продемонстрируй как на нём написать драйвер ядра для винды или линуха (он же андроид, в этом смысле). Ты же сказал что с этим проблем нет...

_>>Ну тебе может и никакой, а другим нравится (что они в разы быстрее). Деланием продукта в ориентации на свои вкусы вы занимаетесь уже давно и успехов (я не про технические) пока не видно. Может стоит попробовать поделать что-то в ориентации на вкусы потенциальных пользователей? )
WH>Так разным пользователям нужно разное.

Безусловно. Для этого проводят исследования рынка и т.п. Вы делали подобное? Имеете представление в каких областях может быть востребована ваша технология? )

WH>Вот если пользователь готов платить тогда другое дело. Бросим всё и будем развивать проект в нужном этому пользователю направлении.

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

WH>А пока у нас уже есть пользователь, который сделал на нитре коммерческий продукт.
WH>http://www.ammyui.com/

Я видел. ) Кстати, вот скажи, какую основную целевую аудиторию ты видишь у Nitra:
1. встраиваемые в приложения простенькие скриптовые (правда тогда смысл от вашей поддержки в IDE теряется, но статические языки для таких целей обычно не применяются) языки (типа js, lua и т.п.)
2. простенькие статические DSL для каких-то узких утилитарных задач с поддержкой их редактирования в больших IDE (по сути случай ammy)
3. полноценные универсальные статические языки, слегка кастомизируемые для конкретных проектов и с полной поддержкой больших iDE

_>>Более того, я думаю ты в курсе что те же самые языки (хотя ещё плюс Фортран, которого нет на МК) доминируют на мейнфреймах и суперкомпьтерах... ))) Ну а насчёт того ошибка это или нет... Быть может это ты чего-то не понимаешь, а не вся индустрия? )
WH>А давай сравним с количеством жабы и .НЕТа в индустрии.

Ну в среднем это будет близко. Т.е мир C/C++ сравним с миром Java (про .net тут смешно вспоминать). Только задачи у них очень разные при этом, конкурирующие только в очень малом количестве областей. И главное эта разность не только по названиям, но и по неординарности задач, уровню программистов и т.п... )))

WH>Тут у нас два принципиально разных сценария.
WH>1)Каждый байт на счету.
WH>2)Инфраструктуру в несколько мегабайт никто не заметит и на перерасход памяти в десяток другой процентов всем наплевать. Но при этом есть сотни мегабайт кода, который пишут сотни программистов.

Ну для начала там не только перерасход памяти, но и замедление и ещё ряд негативных моментов. Но пока это всё экономически выгодно решать покупкой ещё одного сервера (т.е. для миров МК, мобильных устройств, суперкомпьютеров и с недавних пор уже и десктопов это не будет действовать) подобные решения будут процветать и дальше. Более того, языки типа Java и C# являются только промежуточным звеном в этой цепи, а в её конце наблюдаются скорее всяческие JS, Python и им подобные, которые ещё проще для работы. И кстати я сам с удовольствием пользуюсь такими решениям (это чтобы ты не думал, что у меня GC-фобия — просто всему своё место) на моём любимом Питончике.

_>>Т.е. я правильно тебя понял, что именно архитектура Midori кажется тебе идеалом ОС будущего?
WH>Примерно. Там много что можно улучшить. Но глобальное направление выбрано верно.

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

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

_>>Хм, если инструмент, позиционирующийся как средство для лёгкого создания новых языков, будет требовать десяток человеколет для создания одного языка (причём речь по сути только о фронтенде), то зачем он вообще такой нужен?
WH>Я говорю не вообще, а конкретно про С++.
WH>Такое впечатление что его создавали специально для того чтобы никто не смог компилятор написать.
WH>Да никто и не смог. Есть хоть один компилятор который на 100% соответствует стандарту?
WH>А уж как бедные создатели ИДЕ страдают Я обсуждал проблемы этого дела с людьми которые этим занимаются. Там АД!

Хм, ну вот в том же Netbeans анализатор C++ кода работает просто отлично. А при этом там всё построено на банальном ANTLR, про который я не раз тут слышал от вас, что Nitra намного круче.

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

С>А то какой-нибудь bison и yacc узнавать не надо.
это DSL-и, коих и в нитре, как собак не резаных. Немерле там по аналогии с яком в нитре вместо C.

С>Я так думаю, что крутизна скалы её и погубит. Понаворотили ужасов каких-то
Go и Яваскрипт наше все!

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

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

VD>Немерл уже 10 лет превосходит Шарп и вероятность того, что Шарп впитает все возможности в ближайшие 10 лет не велика.
Немерле сейчас намного хуже шарпа. Языковые фичи шарпа подтянулись (по макросам консенсуса в МS пока очевидно нет), а нормальной экосистемы в Немерле, как не было 10 лет назад, так и нет.

VD>Скала не имеет никаких возможностей по расширению синтаксиса. Сделать на ней что-то вроде Ammy невозможно в принципе.
Во-первых, сравнение нитры со скалой это апельсины с яблоками. Во-вторых, на скале отлично пишутся встроенные ДСЛи (лучше чем на Немерле). В-третих, самая крутая фишка в Аммy это не Нитра, а живая модель. Я был удивлен, что до Ammy в WPF этого не было. Я могу тебе показать несколько проектов декларативных UI на питоне с подобным функционалом. При этом там не только надязык, а еще и полностью семантика (аналог WPF) полностью сделана.

VD>Как не странно "легаси" язык в купе с фремворком на нем же написанным (по сути Нитра это библиотеки написанные на Немерле) это делать позволяет.
Что странного в том, что вы написали фрейморк интеграцией раскраски и подсказок внешних языков для VisualStudio? Руки у вас вроде на месте. При чем здесь немерле? Абсолютно также за это время можно было бы написать это на яве, шарпе или питоне (на питоне быстрее! ).

VD>Это как раз Скала не нужна. Язык переусложнен и выдает медленный код бай дизайн.
В Скале есть проблемы, но ничего лучше для общего программирования сейчас в статике просто нет.

VD>Наоборот я хочу в Немерле 2 убрать хардкод имевшийся в Немерле 1. То есть сам язык будет даже меньше и будет написан на более высоком уровне.
Убирать ты можешь что хочешь, но популярности это не даст. Для популярности без крутого бренда нужно иметь уникальные фишки (сейчас желательно в системе типов или в рантайме, так как простые плюшки уже есть везде), а у вас их нет. "Свободный расширяемый синтакс" никому нафиг не сдался.

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

VD>Советовать и критиковать очередь стоит. А очередь делать никто встать не спешит.
Я не критикую, а помогаю алексу выбрать точку приложение усилия.

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

_>Лично мне был бы интересен язык с возможностями современного C++ и наличием макросов в стиле Scala/Nemerle. Одно время я думал, что такой язык появится уже вот вот: Rust. Но при ближайшем рассмотрение оказалось, что он менее удобен чем C++ — в одних местах они слишком перемудрили, а в других наоборот слишком упростили.

Еще твоим целям отвечает https://nim-lang.org/, но я до сих пор не понимаю зачем тебе Nemerle или Nitra.
Nemerle1 это застывшая какашка, без всякого шанса стать нативной или плюсоподобной.
Немерле2 пока существует только в голове Влада даже для .NET, то есть трогать тут просто нечего.
Nitra возможно облегчит тебе создания нового языка, но для этого надо бы сначала огласить чем он будет лучше того, что уже есть.

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

_>Хм, ну вот в том же Netbeans анализатор C++ кода работает просто отлично. А при этом там всё построено на банальном ANTLR, про который я не раз тут слышал от вас, что Nitra намного круче.
Что оно там анализирует?
Сколько на него потрачено усилий?
На сколько оно соответствует стандарту?
Что с ним происходит при встрече с Boost::Preprocessor и Boost::MPL одновременно?

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

_>Причём тут Go? ) Он просто для примера был. Я же тебе написал, выбери ЛЮБОЙ, какой тебе нравится язык с обязательным сборщиком мусора и продемонстрируй как на нём написать драйвер ядра для винды или линуха (он же андроид, в этом смысле). Ты же сказал что с этим проблем нет...
Ох. Сам по себе ГЦ в ядре не проблема.
Но есть ли инструменты, которые прямо сейчас позволяют скомпилировать код с ГЦ для ядра винды или линукса я не знаю.

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

_>Я видел. ) Кстати, вот скажи, какую основную целевую аудиторию ты видишь у Nitra:
В нитре нет ничего что можно было бы заточить на одну из перечисленных тобой аудиторий. Она будет одинаково хорошо работать для всех.

_>1. встраиваемые в приложения простенькие скриптовые (правда тогда смысл от вашей поддержки в IDE теряется,
Это ещё почему? Нашу поддержку ИДЕ можно легко встроить куда угодно. В том числе в своё приложение. Нужно только реализовать довольно простой интерфейс, работающий через пайпы (можно переделать на сокеты).
Учитывая то что там и так весь код общения генерируется макросами можно легко генерировать интерфейс для других языков.

_>но статические языки для таких целей обычно не применяются) языки (типа js, lua и т.п.)
Я уже много лет задаю один вопрос: Для каких задач (не решений, а именно задач) динамическая типизация лучше статической.
Ещё никто не показал примера где динамическая типизация была бы лучше. Ни одного.

_>И главное эта разность не только по названиям, но и по неординарности задач, уровню программистов и т.п... )))
Это феерическое заблуждение.

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

_>Более того, языки типа Java и C# являются только промежуточным звеном в этой цепи, а в её конце наблюдаются скорее всяческие JS, Python и им подобные, которые ещё проще для работы.
Это если сравнивать с убогой явой.
А если сравнивать с немерле, то динамически типизированные языки сливают с треском.

_>И кстати я сам с удовольствием пользуюсь такими решениям (это чтобы ты не думал, что у меня GC-фобия — просто всему своё место) на моём любимом Питончике.
Ты думаешь, что заработал очки в моих глазах... а получилось наоборот.
Динамическая типизация с инженерной точки зрения всегда плохое решение.

_>А как ты думаешь, почему этот проект не взлетел (ну кроме теории заговора менеджеров MS)?
С инженерной точки зрения я не вижу ни одной причины закрывать проект.

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

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

WH>Нативности тут недостаточно. Нужен ещё и инструментарий.
WH>Он для ГО есть?

у Го нет возможности энтри поинт для драйвера сделать. Ну, и там с адресной арифметикой, вроде как, плохо. В остальном никаких противопоказаний нет.

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

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

_>Причём тут Go? ) Он просто для примера был. Я же тебе написал, выбери ЛЮБОЙ, какой тебе нравится язык с обязательным сборщиком мусора и продемонстрируй как на нём написать драйвер ядра для винды или линуха (он же андроид, в этом смысле). Ты же сказал что с этим проблем нет...

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.1892&amp;rep=rep1&amp;type=pdf
https://lwn.net/Articles/352519/
http://dl.acm.org/citation.cfm?id=1408654.1408657

Ты лучше объясни, что может помешать сделать язык с GC на котором можно будет писать драйверы?

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

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

_>>Лично мне был бы интересен язык с возможностями современного C++ и наличием макросов в стиле Scala/Nemerle. Одно время я думал, что такой язык появится уже вот вот: Rust. Но при ближайшем рассмотрение оказалось, что он менее удобен чем C++ — в одних местах они слишком перемудрили, а в других наоборот слишком упростили.
N>Еще твоим целям отвечает https://nim-lang.org/, но я до сих пор не понимаю зачем тебе Nemerle или Nitra.

Да, он мне как раз сильно понравился, когда я его первый раз увидел (пару лет назад по ссылке на этом же форуме). Главный плюс в том, что элементарно уйти на низкий уровень (в его случае это уровень C), если очень надо. Ну и подключение C библиотек естественно тоже. А главный минус в том, что его приятный питоноподобный синтаксис является всё же оригинальным со всеми соответствующими выводами для IDE (а я уже давно привык к удобным мощным IDE)... Ну и плюс мне тогда показалось, что у него сообщество на тот момент меньше чем даже у Nemerle (сейчас уже не уверен).

N>Nemerle1 это застывшая какашка, без всякого шанса стать нативной или плюсоподобной.
N>Немерле2 пока существует только в голове Влада даже для .NET, то есть трогать тут просто нечего.
N>Nitra возможно облегчит тебе создания нового языка, но для этого надо бы сначала огласить чем он будет лучше того, что уже есть.

Я неплохо разбираюсь во всяческих низкоуровневых вещах, но при этом никогда не имел непосредственного дела с LLVM и вообще разработкой языков. Соответственно в начале данной дискуссии я подумывал о том, что ради фана (в каком-то смысле самосовершенствования) в свободное время (которого у меня будет тоже не много и не скоро) попробовать портировать вроде как неплохой инструмент из мира .net на нативную платформу. Хотя если Немерле2 нет сейчас совсем, то это конечно уже осложняет ситуацию.

Потом, в ходе дискуссии, мне пришла в голову мысль, что раз уж заявлено лёгкое создание произвольных языков, то почему бы не сделать реально полезное мне для дела, а не просто для фана (и тогда это может быть уже на совсем другом уровне и с другими ресурсами). Для этого в начале надо сделать (с меня только бэкенд на базе LLVM) копию C++ на Nitra, чтобы потом легко делать (уже мне, и тут у меня есть готовый список добавлений) надстройку в нужном направление. Причём такая система по построению будет совместима со всеми библиотеками C/C++, иметь поддержку для IDE (от Nitra) и великолепную производительность (от LLVM). Однако если WolfHound пишет, что такая схема будет требовать десятки человека лет, то это опять же теряет смысл, т.к. проще тогда самому разобраться во фронтенде clang'а или gcc, и в анализаторе кода моей IDE — всё это доступно в исходниках. Просто я думал что это слишком сложно (цена не стоит того результата), а на Nitra будет легко. Но раз нет, то нет. Правда тогда опять же появляется вопрос зачем вообще нужна Nitra, только для мелких утилитарных DSL'ей?

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

_>Я видел. ) Кстати, вот скажи, какую основную целевую аудиторию ты видишь у Nitra:
_>1. встраиваемые в приложения простенькие скриптовые (правда тогда смысл от вашей поддержки в IDE теряется, но статические языки для таких целей обычно не применяются) языки (типа js, lua и т.п.)
_>2. простенькие статические DSL для каких-то узких утилитарных задач с поддержкой их редактирования в больших IDE (по сути случай ammy)
_>3. полноценные универсальные статические языки, слегка кастомизируемые для конкретных проектов и с полной поддержкой больших iDE

А зачем ограничивать варианты использования вообще? Nitra — это универсальный инструмент.

1. Nitra — это основа для создания полностью расширяемых (во время выполнения) языков программирования. В частности база для Nemerle 2 (название может и поменяться). Такие языки позволят легко и качественно встраивать внешние (чужие) расширения. В том числе и встроенные DSL-и.
2. Nitra — это средство разработки полноценных языков программирования (компиляторов, интерпретаторов и тулинга, т.е. IDE, linter-ов, ...).
3. Nitra — это средство создания внешних DSL.
4. Nitra — это средство разработки IDE-плагинов, компиляторов и прочего тулинга для уже имеющихся языков. Причем использование Nitra позволяет существенно поднять уровень кода, уменьшить его объемы и сделать код легче контролируемым.
5. Nitra — это средство создания препроцессоров вроде Ammy.

А будут это скрипты или компилируемые языки в общем-то по фигу. Вот, например, Ammy вообще генерирует XAML, т.е. по сути препроцессор.

Зачем выбирать какую-то там лишившую аудиторию мне не ясно. Ниша и так очень узка. Люде занимающихся разработкой языков пока что крайне мало.

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

_> Однако если WolfHound пишет, что такая схема будет требовать десятки человека лет, то это опять же теряет смысл, т.к. проще тогда самому разобраться во фронтенде clang'а или gcc, и в анализаторе кода моей IDE — всё это доступно в исходниках. Просто я думал что это слишком сложно (цена не стоит того результата), а на Nitra будет легко. Но раз нет, то нет. Правда тогда опять же появляется вопрос зачем вообще нужна Nitra, только для мелких утилитарных DSL'ей?

А при чём тут Nitra, если сам по себе стандарт С++ — ПРЕОГРОМНЫЙ? То есть, объём работы объективно большой, хоть на нитре, хоть на чём. Тут надо скорее думать, нужен ли миру еще один компилятор С++, а если нужен — то где бы взять одного спонсора и десять студентов, чтобы они год вбивали описание С++ на нитре.

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

N>Конечно нет. Язык становится легаси, когда на нем не пишут новые программы и у него нет развития.

Нет. Легаси подразумевает моральное устаривание. Типа это унаследовано и мы это терпим просто потому, что не можем все переписать на новом языке.

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

У нас же стуация такая. Есть реально морально устаревшие языки вроде С/С++, Шарпа и Явы. Но используют именно их, потому что:
1. Реально есть много легаси-кода.
2. Выбор языков делается не осмысленно, а брэндам и пиару.

Вот есть Котлин, Скала, но люди продолжают писать на Яве.

Есть Немерл, а люди продолжают писать на Шарпе.

Есть Ди, Раст, ... но люди продолжают писать на С++.

N>Немерле сейчас намного хуже шарпа. Языковые фичи шарпа подтянулись (по макросам консенсуса в МS пока очевидно нет), а нормальной экосистемы
в Немерле, как не было 10 лет назад, так и нет.

Это полное непонимание или намеренная неправда. По языковым фичам Шрап даже то что будет в VS 2017 не дотягивает до Немерла десятилетней дановсти. Какие-то фичи появились, но далеко не все и общий уровень удобства просто не сравним. Те же алгебраических типов данных нет. Вместо паттерн-матчинга сделана убогая пародия.

Про макросы и говорить нечего.

Я не знаю, что ты там себе подразумеваешь под экосистемой, но что нет у Немерла — это РеШарпера. Но это опять таки следствие того, что хомячки выбирают не мозгом, а задом. А библиотеки и т.п. у Немерла такие как и у других дотнет-языков. Даже более того, в F# есть определенные проблемы с использованием библиотек дотнета, а в Немерле их нет.

N>Во-первых, сравнение нитры со скалой это апельсины с яблоками. Во-вторых, на скале отлично пишутся встроенные ДСЛи (лучше чем на Немерле).

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

Плюс, например, Anny это не встроенный DSL. Такое на Скале делается только путем написания всего стека компилятора от печки, т.е. годы работы.

N>В-третих, самая крутая фишка в Аммy это не Нитра, а живая модель.

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

Ну, а то что Ammy умеет перезагружать XAML на лету — это фича самого WPF и заслуга автора Ammy, который эту возможность додумался задействовать.

N>Я был удивлен, что до Ammy в WPF этого не было.

Не было поддержки в IDE. А возможность менять бинарные baml-ы была изначально.

Меня вот интересует другое, данная подмена намеренная, или ты просто с логикой накосил? Мы говорили о разработке DSL, а ты подменяешь обсуждение, на обсуждение фич DSL-я. Что реализация на Скале как-то может повлиять на наличие или отсутствие этой загрузки?

N>Я могу тебе показать несколько проектов декларативных UI на питоне с подобным функционалом. При этом там не только надязык, а еще и полностью семантика (аналог WPF) полностью сделана.

Покажи. Хуже не будет. Уверен, что ни будет уступать Ammy хотя бы потому, что в Питоне нельзя выразить код в виде джейсона.

В прочем, особо не удивлюсь их наличию. Питон (как и многие скрипты) не плохо ДСЛ-изируется. Вопрос только в только в тормозах таких решений, в выразительности и в предоставляемом сервисе. У Питона то самого проблемы с интеллисенсом, а уже о интелисенсе в ДСЛ-ях и говорить не приходится. Тут же ты получаешь полноценный язык.

N>Что странного в том, что вы написали фрейморк интеграцией раскраски и подсказок внешних языков для VisualStudio?

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

N>Руки у вас вроде на месте. При чем здесь немерле?

Это язык на котором такой продут можно реализовать нашими силами. И Нитра была придумана в попытках осмыслить то как правильно реализовать Немерл. Открою тебе небольшой сикрет. Язык вроде Немерле очень не просто реализовать вообще. А реализовать его качественно и с поддержкой IDE вообще еще тот вызов. МС просто на переписывание C# на C# убило 6 лет. И это с ресурсами и без малейшего намека на расширяемость. Мы же работали в троем 3.5 года. Если бы мы взяли за основу C# или C++, проект неминуемо был бы завален.

N>Абсолютно также за это время можно было бы написать это на яве, шарпе или питоне (на питоне быстрее! ).

Только в твоем воображении. Ты нихрена не знаешь о устройстве и сложности Нитры, но судить о них на основе собственных домыслов.

VD>>Это как раз Скала не нужна. Язык переусложнен и выдает медленный код бай дизайн.
N>В Скале есть проблемы, но ничего лучше для общего программирования сейчас в статике просто нет.

Ага, ага. То то в ДжетБрэйс пилят Котлин, который бай дизайн упрощенная версия Скалы.

Вот тот же Немерл ничем не уступает Скале по возможностям, но при этом значительно проще его в этом само "общем программировании". Вот только возможности по пиру несоизмеримы. Да и забил я в свое время на него. Надоело, с такими как ты, сражаться.

N>Убирать ты можешь что хочешь, но популярности это не даст.

Популярность есть у очень малого количества языков. И в большинстве случаев за ними стоят серьезные конторы. И действительно благодаря таким как ты (коих большинство) никакие фичи не привлекут людей пользоваться языком. У вас всегда будет 100500 контраргументов высосанных из пальца.

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

Но я все же попробую. Это самое по себе очень интересная задача. И я хочу иметь такой язык.

Учитывая, что язык будет полным констрктором (без ограничений, что были у Немрела), возможно это привлечет людей вроде ionoy (автора Ammy) и alex_public.

Возможно попробую заинтересовать проектом какую-нибудь большую платформу.

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

Наша основная фишка — возможность добавления любых фишек. Причем как авторами, так и сторонними лицами. Это всем фишкам фишка.

Даже у Немерла 1 было не мало случаев, когда приходил орел, вроде тебя, и говорил — "А у вас нет такой-то фишки". Ему отвечали — "Так сделай!". Некоторые из них брались и делали. Например, так появились Computation-Expression.

N>Мне нужен высокопроизводительный универсальный язык с максимально удобной, но строгой типизацией и обширной инфраструктурой, работающий на всем популярном железе. Меня не интересует раскраска моих языков в студии, так как я их пишу редко, а студией пользуюсь только для плюсов. Нитра или Немерле мне не помогут.

Нда... Я тебе как раз говорю о бэкэнде для LLVM. А уж то что ты там себе понимаешь под "высокопроизводительный универсальный язык..." ты сможешь потом сам допилить в виде расширений.

Твоя категоричность вообще умиляет.

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

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

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

С>>А то какой-нибудь bison и yacc узнавать не надо.
N>это DSL-и, коих и в нитре, как собак не резаных. Немерле там по аналогии с яком в нитре вместо C.

Ну, так не пофигу ли что изучать ДСЛ bison-а или ДСЛ Нитры?

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

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

Мы же накрываем не только парсинг, но и типизацию. Плюс та самая инфраструктура. Из коробки будет код для серьезных языков (причем не одного). Куча библиотечного кода. Поддержка той же IDE из коробки. Причем не просто подсветка, как ты пытаться изложить. Это полноценный движок IDE. И для его поддержки практически не надо писать специализированный код.

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

_>У меня тут в процессе дискуссии появилась ещё одна мысль. Возможно я бы смог поучаствовать в развитие проекта не просто для фана, а уже по делу. Но для возможности этого мне надо знать ответ на один вопрос. Вот предположим у тебя есть твоя доработанная Nitra. И при этом кто-то написал для неё полноценный бэкенд через LLVM. Сможешь ли ты сделать на базе этого точную копию скажем C++14 (это естественно не итоговая цель, а важнейший промежуточный шаг, хотя и он при определённом подходе может принести вам коммерческий успех)? Ну чтобы итоговый продукт мог компилировать произвольный C++ исходник и результат не отличался от clang'а. И при этом естественно работала бы поддержка в IDE.

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

Я могу консультировать того кто этим займется и помогать ему (им) трудных случаях. Но у самого меня есть еще много более приоритетных задач. Так мне сначала хочется сделать Nemerle 2 и Cx#

Автор: VladD2
Дата: 12.01.17

. А чтобы заняться ими, я должен довести до приличного состояния поддержку IDE для самой Нитры (нитра пока что использует наш старый движок типзиации.

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

WH>Технически (с некоторыми доработками нитры) это возможно. Но на практике из-за запутанности и монструозности С++ это не один десяток человеколет работы.

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

Сложность грамматики там соизмерима с Шарпом. Все сложности упираются в шаблоны и прероцессор. А это как бы даже не особо связано грамматикой и семантикой.

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

VD>Сложность грамматики там соизмерима с Шарпом. Все сложности упираются в шаблоны и прероцессор. А это как бы даже не особо связано грамматикой и семантикой.
1)Вот именно эта сложность и съест всё время. После чего добавки попросит.
2)Это всё фронтенд. C чем ещё оно может быть связано?

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

WH>1)Вот именно эта сложность и съест всё время. После чего добавки попросит.

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

WH>2)Это всё фронтенд. C чем ещё оно может быть связано?

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

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

WH>Что оно там анализирует?

Да какая разница?

WH>Сколько на него потрачено усилий?

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

Если есть качественная грамматика для АнтЛР, то перевести ее в Нитровскую вообще чисто рутинный процесс.

Ну, типизацию придется написать. Это неизбежно.

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

WH>На сколько оно соответствует стандарту?

Опять же вопрос десятый. Если людей удовлетворяет, то сделать аналог можно точно.

WH>Что с ним происходит при встрече с Boost::Preprocessor и Boost::MPL одновременно?

Отработать должны. Типизатор С++ подразумевает реализацию интерпретатора шаблонов. Слава Богу модель вычисления там не очень сложная. Фактически простенький функциональный язык с рекурсией паттерн-матчингом.

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

VD>Ну, не "десятки человеко лет" (ц) же?
VD>Пусть даже на это год уйдет (что явно много). Но задача то подъемная. Просто придумать как грамотно кэшировать инклюды тоже задача не простая.
Это самая простая из проблем. Но и её ты очень сильно недооцениваешь.
Я разговаривал с людьми, которые в джетбрейнс поддержку С++ делают. Мы с ними на одном этаже сидели. Так что я из первых рук про ужасы знаю. Да и без них догадывался.

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

WH>Это самая простая из проблем. Но и её ты очень сильно недооцениваешь.

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

WH>Я разговаривал с людьми, которые в джетбрейнс поддержку С++ делают. Мы с ними на одном этаже сидели. Так что я из первых рук про ужасы знаю. Да и без них догадывался.

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

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

VD>Отработать должны. Типизатор С++ подразумевает реализацию интерпретатора шаблонов. Слава Богу модель вычисления там не очень сложная. Фактически простенький функциональный язык с рекурсией паттерн-матчингом.
Поверь мне. Между "должны" и "отрабатывают в соответствии" со стандартом в случае с С++ огромная пропасть.
C#, Java, Scala, Kotlin итп на нитре можно сделать за пару месяцев. Но С++ это совсем другой зверь. Там всё очень страшно.

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

N>Nemerle1 это застывшая какашка, без всякого шанса стать нативной или плюсоподобной.

+1

N>Немерле2 пока существует только в голове Влада даже для .NET, то есть трогать тут просто нечего.

Это не совсем так. Кое что уже сделано. У Немерле 2 и Cx# будет много общего АСТ-а и типизации. Сейчас Cx# типизируется до тел методов. Т.е. остается реализовать типизацию выражений и можно спокойно заниматься бэкэндом на базе LLVM. Для этого даже дотнетный бэкэнд не нужен ведь.

N>Nitra возможно облегчит тебе создания нового языка, но для этого надо бы сначала огласить чем он будет лучше того, что уже есть.

Пилить язык с нуля, конечно можно. Но все же не оправданно. Если только захочется сделать развитие С++

Автор: alex_public
Дата: 11.02.17

какого нибудь.

А так лучше брать базовый Немерл и дорабатывать его напильником. Или использовать его как базовые блоки.

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

С>А при чём тут Nitra, если сам по себе стандарт С++ — ПРЕОГРОМНЫЙ?
Преогромность там далеко не самое страшно. Стандарт C# вроде даже больше.
Там проблемы с тем что стандарт С++ состоит из огромной горы ужасных и запутанных конструкций.

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

VD>Надо не забывать, что у них сложность умножалась на рукопашную реализацию типизации. У нас тоже рядом орел из той команды работал. Так что я в курсах их сложностей, в какой то мере.
Ох. Не хочу спорить. Если тебе будет нечем заняться можешь попробовать. Но я тебя предупредил.

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

WH>Поверь мне. Между "должны" и "отрабатывают в соответствии" со стандартом в случае с С++ огромная пропасть.
WH>C#, Java, Scala, Kotlin итп на нитре можно сделать за пару месяцев. Но С++ это совсем другой зверь. Там всё очень страшно.

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

А работать в соответствии со спеками — это уже от правильности реализации типизации и АСТ-а зависит. В С++ 14 еще есть статические функции, которые можно вызвать из макросов. Для них тоже нужен интерпретатор или JIT-компилятор.

Ну, и простая логика. Те кто на этим СиЛионом работали тоже ведь с задачей справились не за 50 лет, а за 2-3. И команда у них вроде как не 100 человек. А если вспомнить, что у них все начиная от парсинга вручную делается, да еще (если не ошибаюсь) на С++ же, то понятно, что их время можно еще раза в три уменьшить.

В общем, Нитра позволит относительно просто спарсить и стипизировать С++. Надо решать следующие задачи:
1. Интерпретатор рекурсивных шаблонов.
2. Кэширование АСТ-а и символов из инклюдов.
3. Интерпретатор статических функций вызываемых из шаблонов.
4. Наверняка придется прикручивать костыли к макросам содержащимся внутри кода.

В С++ 17 вроде как обещают таки импорт реализовать. А раз так, то возможно вопрос импорта можно будет упростить.

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

WH>Ох. Не хочу спорить. Если тебе будет нечем заняться можешь попробовать. Но я тебя предупредил.

У меня есть чем заняться и без этого. И я понимаю, что это не на форуме поболоболить. Но задача вполне подъемная.

Собственно фазы там такие:
1. Отрабатываем препроцессор и получаем "раскрытие" исходники (без макросов).
2. Парсим все это дело и получаем АСТ.
3. Строим символы для шаблнов и типов.
4. Связываем ссылки на шаблоны с символами шаблонов.
5. Запускаем интерпретатор, которые начинает заменять шаблоны на их воплощения отрабатывая при этом рекурсию, если надо. После этого этапа вместо получаем нужные воплощения шаблонов и ссылки на них в местах где были ссылки на шаблоны. Собственно после этого шаблоны раскрыты и вся магия связанная с ними выполнена.
6. Типизируется тупой С с классами и без шаблонов.

Это, конечно, без учета оптимизаций. С ними все будет по сложнее.

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

WH>Ох. Сам по себе ГЦ в ядре не проблема.

Ну для начала язык должен поддерживать работу с указателями вне GC, что обычно редко встречается в языке с обязательным GC. Например, тот же C# это умеет только в режиме unsafe. А в большинстве языков с обязательным GC и такого нет.

Далее, если мы говорим про работу в ядре ОС, то GC должен быть реалтаймовый (надеюсь не надо напоминать про IRQ/MSI?). По типу того, что используется в Zing'e, но миниатюрный (тот то жрёт жрёт от гигабайта до 2 терабайт памяти). Если при этом хватит быстродействия (т.к. подобные GC обычно гарантируют реалтаймовость ценой общего её снижения), то теоретически такое может работать в ядре. Но про реальные воплощения подобного я не слышал.

WH>Но есть ли инструменты, которые прямо сейчас позволяют скомпилировать код с ГЦ для ядра винды или линукса я не знаю.

Собственно в теории скомпилировать не проблема. Только вот рантайм языка должен быть заточен под реализацию для ядра (речь даже не про решение проблем из предыдущего абзаца, а банально про другое системное API, используемое рантаймом). Т.е. грубо говоря в отличие от C/C++ мира, где используется один и тот же инструмент для создания кода в любых режимах работы, то тут понадобится два отдельных инструмента. Соответственно вряд ли кто-то занимается выпуском подобных профессиональных решений, разве что для фана поразвлечься.

_>>Я видел. ) Кстати, вот скажи, какую основную целевую аудиторию ты видишь у Nitra:
WH>В нитре нет ничего что можно было бы заточить на одну из перечисленных тобой аудиторий. Она будет одинаково хорошо работать для всех.

Т.е. получается что создание полноценных мощных языков тоже сюда укладывается... Хотя вариант создания копии C++ тебя пугает. )

_>>но статические языки для таких целей обычно не применяются) языки (типа js, lua и т.п.)
WH>Я уже много лет задаю один вопрос: Для каких задач (не решений, а именно задач) динамическая типизация лучше статической.
WH>Ещё никто не показал примера где динамическая типизация была бы лучше. Ни одного.

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

_>>Более того, языки типа Java и C# являются только промежуточным звеном в этой цепи, а в её конце наблюдаются скорее всяческие JS, Python и им подобные, которые ещё проще для работы.
WH>Это если сравнивать с убогой явой.
WH>А если сравнивать с немерле, то динамически типизированные языки сливают с треском.

Вообще то пока что как раз не видно ни одного статически типизированного языка, сравнимого по удобству написания с динамическими. Кстати, как ни странно ближе всего к ним подходят в этом смысле такие статические языки как Хаскель и C++, потому как они хотя бы могу предложить свой вариант написания кода без указания типов (при этом с полной статический проверкой). Но у них свои проблемы (извращения с чистотой и иммутабельностью у Хаскеля, и необходимость писать лишние auto и общая низкоуровневость у C++), так что они тоже не могут претендовать на сравнение.

_>>А как ты думаешь, почему этот проект не взлетел (ну кроме теории заговора менеджеров MS)?
WH>С инженерной точки зрения я не вижу ни одной причины закрывать проект.

Ну, судя по тому что Joe Duffy пишет: "Now, I am helping to bring many of those lessons learned back to the shipping products including, perhaps surprisingly, C++." То причины понятны.

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

Ну т.е. не видишь. )

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

_>>Хм, ну вот в том же Netbeans анализатор C++ кода работает просто отлично. А при этом там всё построено на банальном ANTLR, про который я не раз тут слышал от вас, что Nitra намного круче.
WH>Что оно там анализирует?

Ну я думаю ты прекрасно знаешь чем занимается анализатор кода в IDE. )))

WH>Сколько на него потрачено усилий?

Без понятия.

WH>На сколько оно соответствует стандарту?

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

WH>Что с ним происходит при встрече с Boost::Preprocessor и Boost::MPL одновременно?

Кстати на препроцессор ты точно зря думаешь. ))) Это же элементарная штука даже для компилятора, а уж для анализатора IDE (которому незачем раскрывать все макросы (они в коде служат просто "функциями" без типизации), а нужно отрабатывать только ifdef и include) тем более. Вот всяческое метапрограммирование на шаблонах — это действительно тяжёлая тема для таких анализаторов и обычно не весь Boost они способны переварить. )))

P.S. Кстати, если вы хотите реального большого успеха вашему продукту, то как можно этого добиться с помощью реализации простеньких вещей (которые пишутся элементарно на множестве других известных инструментов)? Как раз наоборот, надо продемонстрировать возможность решения самой сложной задачи в своей области и тогда слава сама найдёт вас.

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

_>>Причём тут Go? ) Он просто для примера был. Я же тебе написал, выбери ЛЮБОЙ, какой тебе нравится язык с обязательным сборщиком мусора и продемонстрируй как на нём написать драйвер ядра для винды или линуха (он же андроид, в этом смысле). Ты же сказал что с этим проблем нет...
VD>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.1892&amp;rep=rep1&amp;type=pdf
VD>https://lwn.net/Articles/352519/
VD>http://dl.acm.org/citation.cfm?id=1408654.1408657

А ты сам свои ссылки смотрел? ) Там же используется не обычный Хаскель или Java, а специальные версии, в которые введена поддержка работы с указателями, прямые вызовы системного API (типа kmalloc) и т.п. Т.е. к оригинальным языкам с обязательным GC это уже имеет слабое отношение.

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

The Java version took 178 microsecondsand the C version took 63 microseconds. When a GC occurred during a copy, the Java version took 230 microseconds.

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

VD>Ты лучше объясни, что может помешать сделать язык с GC на котором можно будет писать драйверы?
VD>Что ты видишь в GC такого, что не позволило бы запускать его в режиме ядра?

Первые три абзаца здесь http://rsdn.org/forum/philosophy/6696674.1

Автор: alex_public
Дата: 13.02.17

как раз про это.

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

С>А при чём тут Nitra, если сам по себе стандарт С++ — ПРЕОГРОМНЫЙ? То есть, объём работы объективно большой, хоть на нитре, хоть на чём. Тут надо скорее думать, нужен ли миру еще один компилятор С++, а если нужен — то где бы взять одного спонсора и десять студентов, чтобы они год вбивали описание С++ на нитре.

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

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

_>>У меня тут в процессе дискуссии появилась ещё одна мысль. Возможно я бы смог поучаствовать в развитие проекта не просто для фана, а уже по делу. Но для возможности этого мне надо знать ответ на один вопрос. Вот предположим у тебя есть твоя доработанная Nitra. И при этом кто-то написал для неё полноценный бэкенд через LLVM. Сможешь ли ты сделать на базе этого точную копию скажем C++14 (это естественно не итоговая цель, а важнейший промежуточный шаг, хотя и он при определённом подходе может принести вам коммерческий успех)? Ну чтобы итоговый продукт мог компилировать произвольный C++ исходник и результат не отличался от clang'а. И при этом естественно работала бы поддержка в IDE.
VD>Теоретически это возможно. Вопрос лишь в том, что мне не хочется тратить свое время на С++. Кроме того, что это определенный объем работ связанный с перенесением синтаксиса и типизацией, там еще нужно решить ряд проблем связанных с препроцессором. Все инклюды в файлах нужно кэшировать и запускать обработку не с нуля, а с заранее разобранными инклюдами. Именно по этому С++ является плохо IDE-зируемым языком и при реализации для него движков IDE обычно прибегают к множеству хаков.

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

Что касается кэширования при работе анализатора в IDE, то да, для C++ это обязательная вещь. Помнится ещё VisualAssist в древние времена 6-ой студии делал это, скидывая результаты анализа всех используемых библиотек на диск. Эклипс помнится тоже таким старадал (сейчас не знаю). А вот Netbeans и QtCreator уже полностью обходятся анализом при загрузке проекта и кэшированием в памяти. Кстати, ещё отдельная мысль по этому поводу: для ускорения компиляции больших проектов на C++ традиционно используют предкомпилированные заголовки, а вот из анализаторов IDE данный факт кажется не использует никто...

VD>Я могу консультировать того кто этим займется и помогать ему (им) трудных случаях. Но у самого меня есть еще много более приоритетных задач. Так мне сначала хочется сделать Nemerle 2 и Cx#

Автор: VladD2
Дата: 12.01.17

. А чтобы заняться ими, я должен довести до приличного состояния поддержку IDE для самой Нитры (нитра пока что использует наш старый движок типзиации.

Ладно, там посмотрим, ближе к делу)

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

VD>В С++ 14 еще есть статические функции, которые можно вызвать из макросов. Для них тоже нужен интерпретатор или JIT-компилятор.

В смысле не из макросов, а из шаблонов? Тогда да, есть такое, хотя и намного более слабое чем в D — там можно любую функцию так использовать (компилятор сам будет разбираться все ли данные ему доступны на момент компиляции), а в C++ только отдельно помеченную как constexpr.

VD>В С++ 17 вроде как обещают таки импорт реализовать. А раз так, то возможно вопрос импорта можно будет упростить.

Не, скорее всего модулей не будет в C++17. Во всяком случае в текущей версии ничего такого нет, а она уже почти итоговая.

Ну и кстати лично я не особо по этому поводу переживаю, т.к. в реальности модули для C++ являются всего лишь неким средством автоматической синхронизации h и lib файлов. Т.е. грубо говоря решают проблему, от которой и раньше никто не страдал.

Вообще C++17 выходит неправильным. В том смысле что в какой-то момент для языка выбрали план развития в виде версий каждый 3 года, причём в начале идёт с принципиальными изменениями, а следующая с доработками к ней. Т.е. C++11 — принципиальная (так и было), C++14 — доработки (так и было), C++17 — принципиальная (должна быть). И да, в C++17 планировалось добавить модули, интроспекцию, концепты, диапазоны (на базе буста, но концептами), сопрограммы (есть как библиотека в бусте, но специфическая, с использованием ассемблера) и т.п. принципиальные изменения. А по факту на данный момент этого нет ничего (по легенде — не успели договориться), так что в C++17 именно языковых изменений меньше чем в C++14 (в которой добавили полиморфные лямбды, которые реально крайне удобные и которые мало в каких статических языках имеются). Собственно из языковых изменений В C++17 скорее всего будет только несколько мелочей: "if constexpr()" (явно взятый из D), "if(init; condition)" (вообще просто сахар), декомпозицию (типа "auto [x, y]=f();//f возвращает структуру или кортеж с парой членов") и автоматическое определение параметров шаблонов при объявление переменных (типа "pair p(10, 10.0);"). А все остальные изменения касаются только стандартной библиотеки — в неё перетащили очередной кусок из Буста (т.е. для большинства программистов вообще ничего не изменилось) и добавили многопоточные версии большинства стандартных алгоритмов STL (безусловно полезно, но не тянет на революционный шаг, скорее на доработку). А все главные вкусности, получается по факту откладываются на C++20, который теоретически по плану должен был быть "доработкой C++17"...

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

VD>Ну, так не пофигу ли что изучать ДСЛ bison-а или ДСЛ Нитры?
Пофигу. Я просто сказал, что знания DSL-ей не достаточно, надо еще и общий язык знать.

VD>В Нитре их не дофига, а в самый раз. Все они упрощают решения той или иной проблемы. Выбор то не велик. Или учить ДСЛ и потом кратко и понятно решать проблему, или пилить все снуля попутно узнавая все тонкости предметной области.
Меня лечить не надо, я примерно в курсе как сделана Нитра. Подход не нравится, но спорить смысла нет, ибо субъективно.

VD>Бизон накрывает только парсинг. При этом использует не гибкие алгоритмы, не предоставляет автоматическое восстановление после обнаружения ошибок и имеет кучу других проблем.
Я бы потрогал ваш парсер, но он для платформы которой я и вообще мало кто пользуется. Поэтому я продолжаю использовать parsec/ANTLR.

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

VD>Из коробки будет код для серьезных языков (причем не одного). Куча библиотечного кода. Поддержка той же IDE из коробки. Причем не просто подсветка, как ты пытаться изложить. Это полноценный движок IDE. И для его поддержки практически не надо писать специализированный код.
Слово "Будет" я слышу уже 10 лет. Сделайте один полезный и полный ЯП, тогда поговорим.

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

WH>>Сколько на него потрачено усилий?
_>Без понятия.
Во-во, а учить лезешь.

WH>>На сколько оно соответствует стандарту?
_>Стандарту в смысле успевает за изменениями в языке? С этим проблем нет.
Я не про "как-то работает", а про "соответствует стандарту".

WH>>Что с ним происходит при встрече с Boost::Preprocessor и Boost::MPL одновременно?
_>Кстати на препроцессор ты точно зря думаешь. ))) Это же элементарная штука даже для компилятора, а уж для анализатора IDE (которому незачем раскрывать все макросы (они в коде служат просто "функциями" без типизации), а нужно отрабатывать только ifdef и include) тем более.

Ты вообще знаешь что такое Boost::Preprocessor? Судя по твоему ответу даже не догадываешься.
Да и С++ в целом плохо знаешь.

_>Вот всяческое метапрограммирование на шаблонах — это действительно тяжёлая тема для таких анализаторов и обычно не весь Boost они способны переварить. )))
ЧТД. Стандарту не соответствуют.

_>P.S. Кстати, если вы хотите реального большого успеха вашему продукту, то как можно этого добиться с помощью реализации простеньких вещей (которые пишутся элементарно на множестве других известных инструментов)? Как раз наоборот, надо продемонстрировать возможность решения самой сложной задачи в своей области и тогда слава сама найдёт вас.
А что ловля на слабо где-то кроме детского сада работает?

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

_>Ну для начала язык должен поддерживать работу с указателями вне GC, ...
Я с тебя фигею. Ты показываешь проблему и тут же показываешь, как её решать.

_>Т.е. грубо говоря в отличие от C/C++ мира, где используется один и тот же инструмент для создания кода в любых режимах работы,
Что у нас с исключениями и RTTI в ядре?

_>Т.е. получается что создание полноценных мощных языков тоже сюда укладывается... Хотя вариант создания копии C++ тебя пугает. )
Ты меня вообще не слушаешь.
С++ меня пугает по тому что его стандарт выглядит так какбудто его делает толпа обдолбанных укурков цель которых сделать всё так чтобы и пользователям языка и разработчикам инструментов было максимально больно.
Писать компилятор С++ это всё равно что писать код на брейнфаке.

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

_>Вообще то пока что как раз не видно ни одного статически типизированного языка, сравнимого по удобству написания с динамическими.
Ты на немерле сколько кода написал?

_>Ну, судя по тому что Joe Duffy пишет: "Now, I am helping to bring many of those lessons learned back to the shipping products including, perhaps surprisingly, C++." То причины понятны.
И что же тебе понятно?

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

VD>Ну, и простая логика. Те кто на этим СиЛионом работали тоже ведь с задачей справились не за 50 лет, а за 2-3. И команда у них вроде как не 100 человек.
Умножь размер команды на время работы.
Получишь число человеко-лет, которые они на это потратили.

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

VD>Вот есть Котлин, Скала, но люди продолжают писать на Яве.
Потому что на Яве для них быстрей и удобней. Им не надо возиться с запутанными сообщениями в сложной системе типов, ждать медленного компилятора, получать тупые ошибки потому что языком занимаются два с половиной человека по праздникам, искать ответы на простые вопросы, которых нет на SO.

VD>Есть Немерл, а люди продолжают писать на Шарпе.
И правильно делают, на нем большинство софта можно сделать намного быстрее.

VD>Есть Ди, Раст, ... но люди продолжают писать на С++.
И правильно делают, на нем большинство софта можно сделать намного быстрее.

VD>Это полное непонимание или намеренная неправда. По языковым фичам Шрап даже то что будет в VS 2017 не дотягивает до Немерла десятилетней дановсти.
Ты не объективен, спор бессмыслен.

VD>Я не знаю, что ты там себе подразумеваешь под экосистемой, но что нет у Немерла — это РеШарпера. Но это опять таки следствие того, что хомячки выбирают не мозгом, а задом.
Это не главная проблема. Главная (о которой тебе проели все уши, но воз и ныне там) это то что Немерле дотнет-only, a на этой платформе хомячки отличаются уникальной степенью ведомости.

VD>А библиотеки и т.п. у Немерла такие как и у других дотнет-языков.
И это очень плохо. Библиотеки должны быть свои. У всех успешных jvm языков (Scala, Clojure, Kotlin) свои библиотеки.

N>>Во-первых, сравнение нитры со скалой это апельсины с яблоками. Во-вторых, на скале отлично пишутся встроенные ДСЛи (лучше чем на Немерле).
VD>Еще раз повторяю, синтаксис там не изменить. Я эти эти скаловские макросы придумал, так что понимаю о чем говорю. Там возможна только реинтерпретация исходного синтаксиса. Он довольно гибок, но произвольного синтаксического расширения не допускает. Плюс, например, Anny это не встроенный DSL. Такое на Скале делается только путем написания всего стека компилятора от печки, т.е. годы работы.
Если язык гибкий, внешние DSL-ы практически не нужны, если только он не представляет собой саму задачу (полный язык программирования, написания плагинов IDE для уже существующих DSL. Тут Нитра возможно была бы полезна!). Поэтому я говорю про встроенные DSL, где все работает, как в Нитре, из коробки и штатно. Скала оптимизирована именно под этот сценарий, а Немерле нет. Никому на скале и в голову не придет, делать Аммy. Люди просто исправят косяки WPF прямо на Скале.

Вот тебе наша Амму и WPF в придачу. Двухсторонний байндинг, рендеринг в swt и ехтjs, aвтокомплит, все дела без всяких "годов работы".

    gui {
      Window() {
        MenuBar() {
          MenuHeader(_.text := "File") {
            MenuItem(_.text := "New...")
            MenuItem(_.text := "Close")
          }
          MenuHeader(_.text := "Edit") {
            MenuItem(_.text := "Copy")
            MenuItem(_.text := "Cut")
            MenuItem(_.text := "Paste")
          }
        }
        TabFolder() {
          Group(_.tab := "Home") {
            Grid(_.columns := 2) {
              Stack(_.title := "Test") {
                Label(_.caption := "ID") <-- obj.name
                Text(_.caption := "Tenor") <-> obj.tenor
                CheckBox(_.caption := "Is EOD", _.enabled := false) <-- obj.isEod
              }
              Stack(_.title := "Test2") {
                Text(_.caption := "ID") <-- obj.name
                Text(_.caption := "Tenor") <-> obj.tenor
                ComboBox(_.caption := "MyCombo", _.selectedItem <-> obj.pickedValue) <-- obj.choices
              }
            }
          }
    ...

VD>Покажи. Хуже не будет. Уверен, что ни будет уступать Ammy хотя бы потому, что в Питоне нельзя выразить код в виде джейсона.
VD>В прочем, особо не удивлюсь их наличию. Питон (как и многие скрипты) не плохо ДСЛ-изируется. Вопрос только в только в тормозах таких решений, в выразительности и в предоставляемом сервисе.

https://github.com/nucleic/enaml
https://kivy.org/#home

N>>Что странного в том, что вы написали фрейморк интеграцией раскраски и подсказок внешних языков для VisualStudio?
VD>А ты попробуй. Я не хочу тебя огорчать, но ты только языком горазд молоть. Извращаешь все и вся. Нитра это немножко (хе-хе) больше чем просто какая-то там раскраска.
Давай пальцы веером не гнуть. Я не говорю, что это просто, но IDEA и Еclipse раскрашивает/подсказывает десятки языков. Возможно на Нитре оно проще, но это не rocket science.

VD>Как там твои решения на Питоне все раскаршивают? Интеллисенс предоставляют?
Конечно. https://github.com/kivy/kivy/wiki/Setting-Up-Kivy-with-various-popular-IDE's#kv-lang-auto-completion-and-highlighting

N>>Руки у вас вроде на месте. При чем здесь немерле?
VD>Это язык на котором такой продут можно реализовать нашими силами. И Нитра была придумана в попытках осмыслить то как правильно реализовать Немерл. Открою тебе небольшой сикрет. Если бы мы взяли за основу C# или C++, проект неминуемо был бы завален.
Извини, но не верю. Поспекулирую: начали бы на Яве/Скале/Котлине проект был бы гораздо дальше, а ты бы до сих пор работал в JB.

N>>В Скале есть проблемы, но ничего лучше для общего программирования сейчас в статике просто нет.
VD>Ага, ага. То то в ДжетБрэйс пилят Котлин, который бай дизайн упрощенная версия Скалы.
Ну вот когда допилят мы посмотрим, а пока вот так.

N>>Убирать ты можешь что хочешь, но популярности это не даст.
VD>Популярность есть у очень малого количества языков. И в большинстве случаев за ними стоят серьезные конторы. И действительно благодаря таким как ты (коих большинство) никакие фичи не привлекут людей пользоваться языком. У вас всегда будет 100500 контраргументов высосанных из пальца.
Я сейчас пользуюсь только Скалой, Питоном, Хаскелем и плюсами. За этими языками нет никакой серьезной конторы и я как раз один из малого количества adopters. Ты вообще о чем тут?

N>> Для популярности без крутого бренда нужно иметь уникальные фишки (сейчас желательно в системе типов или в рантайме, так как простые плюшки уже есть везде), а у вас их нет. "Свободный расширяемый синтакс" никому нафиг не сдался.
VD>Наша основная фишка — возможность добавления любых фишек. Причем как авторами, так и сторонними лицами. Это всем фишкам фишка.
Это типа "за все хорошее, против всей х..."? Тут надо бы показать пример. Например берем Nemerle2 и за пару месяц прикручиваем к ней типизацию ownership-а из Rust-a. Это пример того, что я не знаю как сделать на нативной Скале без плагина в компилятор, а ты мне Ammy тычешь.

VD>Даже у Немерла 1 было не мало случаев, когда приходил орел, вроде тебя, и говорил — "А у вас нет такой-то фишки". Ему отвечали — "Так сделай!".
10 лет назад я заказывал ровно одну фишку — доступность на нормальной платформе.

VD>Нда... Я тебе как раз говорю о бэкэнде для LLVM. А уж то что ты там себе понимаешь под "высокопроизводительный универсальный язык..." ты сможешь потом сам допилить в виде расширений.
У тебя телега впереди лошади. Не надо сейчас говорить о LLVM. У вас никакого языка сейчас нет, кроме N1, который никому нафиг не нужен, включая тебя. Тебе надо сначала сделать язык на том что ты знаешь (дотнет) и если он будет для меня интересен, я возможно буду готов помочь в его нативизации на LLVM. В дизайне языка неплохо было бы иметь нативизацию ввиду конечно. А сейчас обьекта приложений усилия для меня просто нет. Делать C#/"упрощенный Немерле" на Нитре мне не интересно, так как результатом будет шаг назад по сравнению со Скалой.

N>>Я не критикую, а помогаю алексу выбрать точку приложение усилия.
VD>Откровенно говоря ты просто трепишься. При этом выдаешь море заблуждений с зашкаливающей категоричностью.
В принципе да, как и ты. Я не против Нитры или Немерле2 и продолжаю несмотря на твое хамство ждать от них полезный выхлоп для себя. Пока его нет. На N2 я честно говоря не надеюсь, так как не вижу интересных идей. Нитра мне интересна, но ее режет дотнет и N1. Если бы выдача была для jvm мне было бы интересней, но сам я делать это не буду, так как не уверен, что овчинка стоит выделки.

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

VD>У нас же стуация такая. Есть реально морально устаревшие языки вроде С/С++, Шарпа и Явы. Но используют именно их, потому что:
VD>1. Реально есть много легаси-кода.
VD>2. Выбор языков делается не осмысленно, а брэндам и пиару.
Ты серьёзно не учитываешь, что выбирать могут вполне осмысленно, но с учётом количества готовых специалистов, инструментов и прочего? В плане библиотек у связок джава-скала или C#-Nemerle может всё и хорошо, но не у C++/D/Rust. В последнем случае надо писать биндинги и не всегда их можно генерировать.
Ну и поддержка ИДЕ важна (с этим, как я понимаю, у вас проблем нет, но не у скалы/D/раста), как и "стабильность".

VD>Ага, ага. То то в ДжетБрэйс пилят Котлин, который бай дизайн упрощенная версия Скалы.
Дык, разве в Kotlin есть метапрограммирование?

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

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

DE>Ну и поддержка ИДЕ важна (с этим, как я понимаю, у вас проблем нет, но не у скалы/D/раста), как и "стабильность".
У Скалы с IDE-поддержкой проблем давно нет. В смысле там все лучше в Еclipse и IDEA чем у Немерле в студии.

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

N>10 лет назад я заказывал ровно одну фишку — доступность на нормальной платформе.

Многие люди считают, что эта платформа как раз ненормальная.

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

WH>>>Сколько на него потрачено усилий?
_>>Без понятия.
WH>Во-во, а учить лезешь.

По парсерам я тебя ничему не учу (это не моя область), а скорее запрашиваю готовое решение. )

WH>>>Что с ним происходит при встрече с Boost::Preprocessor и Boost::MPL одновременно?
_>>Кстати на препроцессор ты точно зря думаешь. ))) Это же элементарная штука даже для компилятора, а уж для анализатора IDE (которому незачем раскрывать все макросы (они в коде служат просто "функциями" без типизации), а нужно отрабатывать только ifdef и include) тем более.
WH>
WH>Ты вообще знаешь что такое Boost::Preprocessor? Судя по твоему ответу даже не догадываешься.

Ну вообще то я когда-то делал на нём задание sql схемы для библиотечки SOCI. Т.е. пишешь вот так:

DECLARE_TABLE("Persons", Person, (
    ("int primary key", id),
    ("text", name),
    ("real", total)
))

И потом можешь писать так:

CreateTable<Person>();
for(int i=0; i<10; i++) Insert(Person{i, L"Имя"+to_wstring(i), sin(i/3.0)});

Но это всё древние решения, которые с появлением библиотек типа sqlpp11 уже не актуальны. Там уже давно нужная схема генерируется не макросом (хотя такое решение тоже присутствует из коробки), а скриптом на Питоне по sql файлу, а сама библиотека делает статический анализ всех sql конструкций на этапе компиляции (как в linq, только намного эффективнее). Кстати, это как раз одно из мест где МП выглядит максимально полезным (причём даже такое слабое МП как в C++ позволяет создать полноценный эффективный инструмент) — решения на эту тему я видел и в Scala и в Rust. А вот Nemerle похоже проигнорировал данное направление, т.к. в .net имеется linq, который хоть и с рантаймовыми тормозами, но уже работает из коробки. )))

Ну что-то я увлёкся воспоминаниями. Так вот, не смотря на относительно страшный вид макроса DECLARE_TABLE, с точки зрения анализатора кода IDE он является полным примитивом.

WH>Да и С++ в целом плохо знаешь.

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

_>>P.S. Кстати, если вы хотите реального большого успеха вашему продукту, то как можно этого добиться с помощью реализации простеньких вещей (которые пишутся элементарно на множестве других известных инструментов)? Как раз наоборот, надо продемонстрировать возможность решения самой сложной задачи в своей области и тогда слава сама найдёт вас.
WH>А что ловля на слабо где-то кроме детского сада работает?

Т.е. ты даже не хочешь попробовать поразмышлять? Вот предложим случится чудо и вы полностью закончите свой основной продукт. Вот он у вас на руках и вы приступаете к его предъявлению публике. Как вы это собираетесь делать? Просто информация про какие-то парсеры и т.п. — это будет разговор ни о чём. Всегда нужен реальный работающий пример применения вашего инструмента. И что вы предъявите? Что-то вроде Ammi? Так подобное сейчас каждый второй не напряжно делает без всяких специализированных инструментов, просто в лоб, причём задача элементарно решается вообще на каком-нибудь Питоне. Вот если показать, что ваш инструмент может решать задачи, считающиеся реально сложными в индустрии — только тогда и можно получить известность...