Здравствуйте, Слава, Вы писали:
С>А то какой-нибудь 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 одновременно?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Причём тут Go? ) Он просто для примера был. Я же тебе написал, выбери ЛЮБОЙ, какой тебе нравится язык с обязательным сборщиком мусора и продемонстрируй как на нём написать драйвер ядра для винды или линуха (он же андроид, в этом смысле). Ты же сказал что с этим проблем нет...
Ох. Сам по себе ГЦ в ядре не проблема.
Но есть ли инструменты, которые прямо сейчас позволяют скомпилировать код с ГЦ для ядра винды или линукса я не знаю.
_>Нуу так пользователь то может и готов платить, но за готовый продукт, а не оплачивать заказную разработку. Т.е. по нормальному в начале вы должны вкладывать свои (ну или инвесторов, если умеете заниматься их соблазнением) ресурсы, а потом уже пожинать плоды с многочисленных пользователей.
Вот мы и вкладываем в то что позволит сделать полнофункциональный проект с наименьшими затратами ресурсов.
_>Я видел. ) Кстати, вот скажи, какую основную целевую аудиторию ты видишь у Nitra:
В нитре нет ничего что можно было бы заточить на одну из перечисленных тобой аудиторий. Она будет одинаково хорошо работать для всех.
_>1. встраиваемые в приложения простенькие скриптовые (правда тогда смысл от вашей поддержки в IDE теряется,
Это ещё почему? Нашу поддержку ИДЕ можно легко встроить куда угодно. В том числе в своё приложение. Нужно только реализовать довольно простой интерфейс, работающий через пайпы (можно переделать на сокеты).
Учитывая то что там и так весь код общения генерируется макросами можно легко генерировать интерфейс для других языков.
_>но статические языки для таких целей обычно не применяются) языки (типа js, lua и т.п.)
Я уже много лет задаю один вопрос: Для каких задач (не решений, а именно задач) динамическая типизация лучше статической.
Ещё никто не показал примера где динамическая типизация была бы лучше. Ни одного.
_>И главное эта разность не только по названиям, но и по неординарности задач, уровню программистов и т.п... )))
Это феерическое заблуждение.
_>Ну для начала там не только перерасход памяти, но и замедление и ещё ряд негативных моментов.
Это не правда. Если делать грамотно, то у компилятора оказывается очень много дополнительной информации что позволяет лучше оптимизировать код.
Так что оно будет на том же уровне или быстрее. Пример мидори это подтверждает.
_>Более того, языки типа Java и C# являются только промежуточным звеном в этой цепи, а в её конце наблюдаются скорее всяческие JS, Python и им подобные, которые ещё проще для работы.
Это если сравнивать с убогой явой.
А если сравнивать с немерле, то динамически типизированные языки сливают с треском.
_>И кстати я сам с удовольствием пользуюсь такими решениям (это чтобы ты не думал, что у меня GC-фобия — просто всему своё место) на моём любимом Питончике.
Ты думаешь, что заработал очки в моих глазах... а получилось наоборот.
Динамическая типизация с инженерной точки зрения всегда плохое решение.
_>А как ты думаешь, почему этот проект не взлетел (ну кроме теории заговора менеджеров MS)?
С инженерной точки зрения я не вижу ни одной причины закрывать проект.
_>И есть ли шансы на реализацию (не в смысле сделать работающим, а в смысле сделать интересным хоть для каких-то групп пользователей) подобного в ближайшем будущем?
Основная проблема в том, что у кучи пользователей в голове те же заблуждения что у тебя.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Причём тут Go? ) Он просто для примера был. Я же тебе написал, выбери ЛЮБОЙ, какой тебе нравится язык с обязательным сборщиком мусора и продемонстрируй как на нём написать драйвер ядра для винды или линуха (он же андроид, в этом смысле). Ты же сказал что с этим проблем нет...
Здравствуйте, 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#
Здравствуйте, WolfHound, Вы писали:
WH>Технически (с некоторыми доработками нитры) это возможно. Но на практике из-за запутанности и монструозности С++ это не один десяток человеколет работы.
Ты людей то так не пугай. С++ есть ряд проблем, но десятки человеколет — это ты что-то совсем загнул. За десятки его можно и на С написать.
Сложность грамматики там соизмерима с Шарпом. Все сложности упираются в шаблоны и прероцессор. А это как бы даже не особо связано грамматикой и семантикой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Сложность грамматики там соизмерима с Шарпом. Все сложности упираются в шаблоны и прероцессор. А это как бы даже не особо связано грамматикой и семантикой.
1)Вот именно эта сложность и съест всё время. После чего добавки попросит.
2)Это всё фронтенд. C чем ещё оно может быть связано?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>1)Вот именно эта сложность и съест всё время. После чего добавки попросит.
Ну, не "десятки человеко лет" (ц) же?
Пусть даже на это год уйдет (что явно много). Но задача то подъемная. Просто придумать как грамотно кэшировать инклюды тоже задача не простая.
WH>2)Это всё фронтенд. C чем ещё оно может быть связано?
Думаю, сложностей там будет достаточно. Но за 10 лет вручную компиляторы пишутся. Ты людей то так не пугай.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Что оно там анализирует?
Да какая разница?
WH>Сколько на него потрачено усилий?
Ну, не десятки человеко-лет точно. Я бы на их месте просто взял бы имеющийся компилятор и анализировал их внутренее представление.
Если есть качественная грамматика для АнтЛР, то перевести ее в Нитровскую вообще чисто рутинный процесс.
Ну, типизацию придется написать. Это неизбежно.
Проблемы будут именно с IDE, так как надо кэшировать выхлоп препроцессора иначе парсинг будет занимать нереально много времени. Вот с этим придется потрахаться. Еще возможно проблемы вызовет вычислительная полнота шаблонов. Тут фактически надо интепретатор писать, а может и компилятор джитовский.
WH>На сколько оно соответствует стандарту?
Опять же вопрос десятый. Если людей удовлетворяет, то сделать аналог можно точно.
WH>Что с ним происходит при встрече с Boost::Preprocessor и Boost::MPL одновременно?
Отработать должны. Типизатор С++ подразумевает реализацию интерпретатора шаблонов. Слава Богу модель вычисления там не очень сложная. Фактически простенький функциональный язык с рекурсией паттерн-матчингом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, не "десятки человеко лет" (ц) же? VD>Пусть даже на это год уйдет (что явно много). Но задача то подъемная. Просто придумать как грамотно кэшировать инклюды тоже задача не простая.
Это самая простая из проблем. Но и её ты очень сильно недооцениваешь.
Я разговаривал с людьми, которые в джетбрейнс поддержку С++ делают. Мы с ними на одном этаже сидели. Так что я из первых рук про ужасы знаю. Да и без них догадывался.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Это самая простая из проблем. Но и её ты очень сильно недооцениваешь.
Задачка как задача. Если к ней сразу подходить как созданию интерпретатора, а не жить в заблуждении, что это просто дженерики, то вполне себе обычная задача.
WH>Я разговаривал с людьми, которые в джетбрейнс поддержку С++ делают. Мы с ними на одном этаже сидели. Так что я из первых рук про ужасы знаю. Да и без них догадывался.
Надо не забывать, что у них сложность умножалась на рукопашную реализацию типизации. У нас тоже рядом орел из той команды работал. Так что я в курсах их сложностей, в какой то мере.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Отработать должны. Типизатор С++ подразумевает реализацию интерпретатора шаблонов. Слава Богу модель вычисления там не очень сложная. Фактически простенький функциональный язык с рекурсией паттерн-матчингом.
Поверь мне. Между "должны" и "отрабатывают в соответствии" со стандартом в случае с С++ огромная пропасть.
C#, Java, Scala, Kotlin итп на нитре можно сделать за пару месяцев. Но С++ это совсем другой зверь. Там всё очень страшно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
