Уважаемые немерлисты, скажите мне, пожалуйста, какие из современных языков программирования вы считаете серьезными конкурентами Nemerle.
Только не надо говорить, что у Nemerle нет конкурентов — это будет значить, что вы просто профукаете те прогрессивные вещи, которые есть (или появятся) в других языках, и вскоре останетесь позади.
Nemerle меня восхищает, но я вам скажу чего мне в нем не хватает:
1) поддержки целых чисел производной разрядности и чисел с плавающей точкой произвольной точности на уровне языка (поддержка литералов на уровне языка)
2) поддержки регулярных выражений (контроль правильности на этапе компиляции, прекомпиляция в CIL), интеграция регулярных выражений с механизмом pattern matching'а
3) нормальныого pattern matching'а (хотя бы на уровне Mathematica от Wolfram Research)
4) развитой системы типов на уровне прогрессивных совеменных языков (например, Scala): trait'ы, абстрактные типы — члены класса, нстоящая ко/контравариантность.
5) возможности преобразовывать AST в код в рантайме, а не только на этапе компиляции (посмотрите хотя бы, что сделано в этом отношении MS в System.Query.dll).
Здравствуйте, <Aiiiei>, Вы писали:
Aii>Уважаемые немерлисты, скажите мне, пожалуйста, какие из современных языков программирования вы считаете серьезными конкурентами Nemerle.
Смотря с какого угла посмотреть на этот вопрос. Ведь пока Немерл сам не является конкурентом даже C#.
Aii>Nemerle меня восхищает, но я вам скажу чего мне в нем не хватает: Aii>1) поддержки целых чисел производной разрядности и чисел с плавающей точкой произвольной точности на уровне языка (поддержка литералов на уровне языка)
Начнем с того, что их поддержки нет в .NET. Беда в том, что их поддержку на уровне языка не так просто добавить, как это сделано с list.
Aii>2) поддержки регулярных выражений (контроль правильности на этапе компиляции, прекомпиляция в CIL), интеграция регулярных выражений с механизмом pattern matching'а
Ну он достаточно нормальный. А вот что даст, если он будет на уровне Mathematica? Можно примеры?
Aii>4) развитой системы типов на уровне прогрессивных совеменных языков (например, Scala): trait'ы,
Дык, реализовать на макросах можно, только этим всерьез так никто и не занялся.
Aii>абстрактные типы — члены класса,
Что именно имеешь ввиду?
Aii>нстоящая ко/контравариантность.
Какая поддерживается .NET'ом, та и есть
Aii>5) возможности преобразовывать AST в код в рантайме, а не только на этапе компиляции (посмотрите хотя бы, что сделано в этом отношении MS в System.Query.dll).
+1, но как только LINQ зарелизится, уж на том уровне, что там есть, поддержку добавить труда не составит.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[2]: Кокуренты Nemerle
От:
Аноним
Дата:
02.04.07 08:29
Оценка:
Здравствуйте, ie, Вы писали:
Aii>>Уважаемые немерлисты, скажите мне, пожалуйста, какие из современных языков программирования вы считаете серьезными конкурентами Nemerle. ie>Смотря с какого угла посмотреть на этот вопрос. Ведь пока Немерл сам не является конкурентом даже C#.
Ну, в перспективе, Nemerle имеет гораздо больше шансов, чем C#. Популярность последнего — не более, чем временное явление.
Aii>>1) поддержки целых чисел производной разрядности и чисел с плавающей точкой произвольной точности на уровне языка (поддержка литералов на уровне языка) ie>Начнем с того, что их поддержки нет в .NET. Беда в том, что их поддержку на уровне языка не так просто добавить, как это сделано с list.
Не понимаю, почему необходима их поддержка на уровне платформы. Компилятор мог бы распознавать такие литералы и заменять их на создание объектов соответствующего типа. А арифметические операции — превращать в вызов методов.
Aii>>2) поддержки регулярных выражений (контроль правильности на этапе компиляции, прекомпиляция в CIL), интеграция регулярных выражений с механизмом pattern matching'а ie>http://nemerle.org/Quick_Guide#Regular_Expressions_match
К сожалению, их нельзя смешивать с другими паттернами. Например, если я хочу проверить первый элемент кортежа (строку) — с помощью регулярного выражения, а второй (вариант) — с помощью деконструирования варианта. Да и никакой прекомпиляции, как я понимаю, нет. Компиляция регулярного выражения в CIL будет происходит в рантайме. Да и контроля правильности выражений нет пока.
Aii>>3) нормальныого pattern matching'а (хотя бы на уровне Mathematica от Wolfram Research) ie>Ну он достаточно нормальный. А вот что даст, если он будет на уровне Mathematica? Можно примеры?
Просто он куций. Не хватает возможности пропустить несколько элементов списка, и альтернатив — когда один из под-образцов может принимать разные формы.
Aii>>4) развитой системы типов на уровне прогрессивных совеменных языков (например, Scala): trait'ы, ie>Дык, реализовать на макросах можно, только этим всерьез так никто и не занялся.
Ну, будем надеяться, что это временный недочет.
Aii>>абстрактные типы — члены класса, ie>Что именно имеешь ввиду?
Ну посмотри в обзоре Scala, 5.2 Abstract Members
Aii>>нстоящая ко/контравариантность. ie>Какая поддерживается .NET'ом, та и есть
В Scala, например, immutable объекты наподобие списков — ковариантны. Но, действительно, дотнета такое не позволяет напрямую. Обойти это можно, создавая не настоящие объекты, а умные обертки. Но это, конечно, криво. Однако ж, те же функциональные типы реализованы ведь через специальные обертки — и ничего.
Здравствуйте, <Aiiiei>, Вы писали:
Aii>>>Уважаемые немерлисты, скажите мне, пожалуйста, какие из современных языков программирования вы считаете серьезными конкурентами Nemerle. ie>>Смотря с какого угла посмотреть на этот вопрос. Ведь пока Немерл сам не является конкурентом даже C#.
Aii>Ну, в перспективе, Nemerle имеет гораздо больше шансов, чем C#. Популярность последнего — не более, чем временное явление.
Твоими бы устами, да мед пить... Хотя да, я тоже в это верю
Aii>>>1) поддержки целых чисел производной разрядности и чисел с плавающей точкой произвольной точности на уровне языка (поддержка литералов на уровне языка) ie>>Начнем с того, что их поддержки нет в .NET. Беда в том, что их поддержку на уровне языка не так просто добавить, как это сделано с list.
Aii>Не понимаю, почему необходима их поддержка на уровне платформы. Компилятор мог бы распознавать такие литералы и заменять их на создание объектов соответствующего типа. А арифметические операции — превращать в вызов методов.
Компилятор то может. Но это решение будет однобоким. В языках с нормальной поддержкой больших чисел перемножение 2х long'ов даст какой-нибудь bigint, а как это сделать без поддержки платформы неясно.
Aii>>>2) поддержки регулярных выражений (контроль правильности на этапе компиляции, прекомпиляция в CIL), интеграция регулярных выражений с механизмом pattern matching'а ie>>http://nemerle.org/Quick_Guide#Regular_Expressions_match
Aii>К сожалению, их нельзя смешивать с другими паттернами. Например, если я хочу проверить первый элемент кортежа (строку) — с помощью регулярного выражения, а второй (вариант) — с помощью деконструирования варианта. Да и никакой прекомпиляции, как я понимаю, нет. Компиляция регулярного выражения в CIL будет происходит в рантайме. Да и контроля правильности выражений нет пока.
Ок, проблема ясна, но для ее решения надо делать свою реализацию регексов. А как ты предлагаешь контролировать правильнось?
Aii>>>3) нормальныого pattern matching'а (хотя бы на уровне Mathematica от Wolfram Research) ie>>Ну он достаточно нормальный. А вот что даст, если он будет на уровне Mathematica? Можно примеры? Aii>Просто он куций. Не хватает возможности пропустить несколько элементов списка, и альтернатив — когда один из под-образцов может принимать разные формы.
Можно все-таки пример?
Aii>>>нстоящая ко/контравариантность. ie>>Какая поддерживается .NET'ом, та и есть Aii>В Scala, например, immutable объекты наподобие списков — ковариантны. Но, действительно, дотнета такое не позволяет напрямую. Обойти это можно, создавая не настоящие объекты, а умные обертки. Но это, конечно, криво. Однако ж, те же функциональные типы реализованы ведь через специальные обертки — и ничего.
Тут действительно дилема. С одной стороны можно понаделать оберток, а с другой подождать, когда в фрэймворк добавят нормальную поддержку ковариантности (вроде что-то собирались улучшать). Думаю разработчики выбирут второй путь.
Здравствуйте, Аноним, Вы писали:
А>Уважаемые немерлисты, скажите мне, пожалуйста, какие из современных языков программирования вы считаете серьезными конкурентами Nemerle. А>Только не надо говорить, что у Nemerle нет конкурентов — это будет значить, что вы просто профукаете те прогрессивные вещи, которые есть (или появятся) в других языках, и вскоре останетесь позади.
А>Nemerle меня восхищает, но я вам скажу чего мне в нем не хватает: А>1) поддержки целых чисел производной разрядности и чисел с плавающей точкой произвольной точности на уровне языка (поддержка литералов на уровне языка)
А почему в Nemerle на уровне языка нет поддержки комплексных чисел или дробей?
Здравствуйте, ie, Вы писали:
Aii>>Не понимаю, почему необходима их поддержка на уровне платформы. Компилятор мог бы распознавать такие литералы и заменять их на создание объектов соответствующего типа. А арифметические операции — превращать в вызов методов.
ie>Компилятор то может. Но это решение будет однобоким. В языках с нормальной поддержкой больших чисел перемножение 2х long'ов даст какой-нибудь bigint, а как это сделать без поддержки платформы неясно.
А почему бу в стандартной библиотеке Nemerle просто не включить классы для работы с длинными числами? Тут никакая поодержка компилятора не нужна.
Aii>>К сожалению, их нельзя смешивать с другими паттернами. Например, если я хочу проверить первый элемент кортежа (строку) — с помощью регулярного выражения, а второй (вариант) — с помощью деконструирования варианта. Да и никакой прекомпиляции, как я понимаю, нет. Компиляция регулярного выражения в CIL будет происходит в рантайме. Да и контроля правильности выражений нет пока.
ie>Ок, проблема ясна, но для ее решения надо делать свою реализацию регексов. А как ты предлагаешь контролировать правильнось?
Что мешает добавить поддержку ещё одного вида изменения синтаксиса — на уровне паттерн-матчинга. Ведь при помощи макросов можно внести определённую концепцию в язык (те же анонимные типы, например). Хотелось бы иметь так же механизм декомпозиции этой самой концепции.
Здравствуйте, konsoletyper, Вы писали:
Aii>>>Не понимаю, почему необходима их поддержка на уровне платформы. Компилятор мог бы распознавать такие литералы и заменять их на создание объектов соответствующего типа. А арифметические операции — превращать в вызов методов. ie>>Компилятор то может. Но это решение будет однобоким. В языках с нормальной поддержкой больших чисел перемножение 2х long'ов даст какой-нибудь bigint, а как это сделать без поддержки платформы неясно. K>А почему бу в стандартной библиотеке Nemerle просто не включить классы для работы с длинными числами? Тут никакая поодержка компилятора не нужна.
Да можно, конечно. Взять самую удачную реализацию (или написать свою) и добавить. Проблема в другом.
Aii>>>К сожалению, их нельзя смешивать с другими паттернами. Например, если я хочу проверить первый элемент кортежа (строку) — с помощью регулярного выражения, а второй (вариант) — с помощью деконструирования варианта. Да и никакой прекомпиляции, как я понимаю, нет. Компиляция регулярного выражения в CIL будет происходит в рантайме. Да и контроля правильности выражений нет пока. ie>>Ок, проблема ясна, но для ее решения надо делать свою реализацию регексов. А как ты предлагаешь контролировать правильнось? K>Что мешает добавить поддержку ещё одного вида изменения синтаксиса — на уровне паттерн-матчинга.
Ничего не мешает добавить. Аноним говорил о "компиляция регулярного выражения в CIL", а это никак с паттерн-матчингом не связано.
Здравствуйте, <Аноним>, Вы писали:
А>Уважаемые немерлисты, скажите мне, пожалуйста, какие из современных языков программирования вы считаете серьезными конкурентами Nemerle. А>Только не надо говорить, что у Nemerle нет конкурентов — это будет значить, что вы просто профукаете те прогрессивные вещи, которые есть (или появятся) в других языках, и вскоре останетесь позади.
А>Nemerle меня восхищает, но я вам скажу чего мне в нем не хватает: А>1) поддержки целых чисел производной разрядности и чисел с плавающей точкой произвольной точности на уровне языка (поддержка литералов на уровне языка)
Зачем это на уровне языка? Я вообще такими числами никогда не пользовался и желания не возникает. К тому же это приговор производительности. Не дай бог начать автоматически к ним приводить операции с встренными типами.
В следующем фрэймворке вроде как будет добавляет такой класс. Реализации можно и сейчас найти по поутине. Единственная проблема литералы особо крупных размеров. Но это мне кажется надуманная проблема.
А>2) поддержки регулярных выражений (контроль правильности на этапе компиляции, прекомпиляция в CIL), интеграция регулярных выражений с механизмом pattern matching'а
Мне не рнавятся сами регекспы. Я бы предпочел EBNF like-опискания. Вот konsoletyper
копает в нужном направлении.
Макросистемы Немерле достаточно чтобы гладко встроить их поддержку в язык.
А>3) нормальныого pattern matching'а (хотя бы на уровне Mathematica от Wolfram Research)
Поглядел это чудо. Кроме слов ужас ничего другого в голову не приходит. Шифрование отдыхает. Если речь о таком же синтаксисе, то я лично категорически против. Ечли речь о расширенных возможностях, то компилятор Немерле и его авторы открыты для разумного расширения языка. Можешь сделать это сам, а можешь попросить компиляторшиков. Лиш бы идеи расширения были интересными и разумными.
А>4) развитой системы типов на уровне прогрессивных совеменных языков (например, Scala): trait'ы, абстрактные типы — члены класса, нстоящая ко/контравариантность.
Нет в Скале никакой развитой системы типов. Ситема типов там практически иднтичная Немерловой. trait — это всего лишь приятный синтаксический сахар который можно добавить в Немерле на макросах. Нужно только три вщеи:
1. Насущьная необходимость (откровенно говоря я не часто испытываю в них нужду).
2. Продуманный дизайн (Скалоский тяжеловат).
3. Люди которые все это реализуют. Вот это пожалуй главное .
А>5) возможности преобразовывать AST в код в рантайме, а не только на этапе компиляции (посмотрите хотя бы, что сделано в этом отношении MS в System.Query.dll).
А какие проблемы с работай в рантайме? Загружай компилятор в рантайме, скармливай ему код и получай все что хочешь. Интеграция к студии так и делает. Она не только все макросы хостит, но и развернутую информацию о них дает. Просто это не нужно на практике. Все что мне приходило в голову я мог (по крайней мере гипотетически) реаизовать во время компияляции.
Единственно, что можно было бы добавить — это аналог динамик-метода из второго фрэймворка, чтобы можно было отдельные методы к уже существующему классу доделывать. В прочем, опять таки задача гипотетическая. На практике лично мне она не нужна. Кому надо, тот пусть еею и занимается. Только перед этим я бы на его месте задумался, а надо ли оно вообще.
ЗЫ
Все пункты нельзя найти ни в одном языке. Ну, может быть в Лиспе. Да и откровенно говоря нужно ли все это?
Что касается Скалы, то язык несомненно перспективный, но не без проблем. Ковариантность для коллекций выливается в низкую производиетельность при работес вэлью-типами, так как дженерики в Скале (как и во всей Яве) — это фикция. Отсуствие макросов не позволяет сделать многие вещи проще. Излишняя переусложненность языка отталкивает новых пользователей. Ну, и вывод типов откровенно слабее.
Что касается конкуренции с C#... Вопрос очень не простой. За C# самый звучный брэнд IT-рныка и контора супер-милиорадер и монополист на рынке десктопных ОС. Тягаться с ним без финансирования практически невозможно. Мы убьем еще года два на приведение поддержки Nemerle до уровеня C#. Вот если бы найти спонсора... Лучшим бы спонсором мог бы стать сам МС.
Уверен, что C# будет развиваться в направлении определенном Nenerle и F#. Но так же уверен, что этобудет делать с опаской, мелкими шажками, непоследовательно, и с ошибками (надеюсь не ольшими).
Так что будущее еще не известно. И мы его можем сделать таким как захотим. (с) Назад в будущее .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
А>>2) поддержки регулярных выражений (контроль правильности на этапе компиляции, прекомпиляция в CIL), интеграция регулярных выражений с механизмом pattern matching'а
VD>Мне не рнавятся сами регекспы. Я бы предпочел EBNF like-опискания. Вот konsoletyper
копает в нужном направлении. VD>Макросистемы Немерле достаточно чтобы гладко встроить их поддержку в язык.
+1. У меня тоже регексы вызывают некоторую дисгармонию. Но, к сожалению, это де-факто в разборе строк. Так что, пожалуй, их грамотная поддержка, в параллель с EBNF, лишней не будет.
ie>Компилятор то может. Но это решение будет однобоким. В языках с нормальной поддержкой больших чисел перемножение 2х long'ов даст какой-нибудь bigint, а как это сделать без поддержки платформы неясно.
понятно как.
так же, как происходит умножение long на short.
всё приводится к наиболее полному типу — явно или неявно.
ie>Ок, проблема ясна, но для ее решения надо делать свою реализацию регексов. А как ты предлагаешь контролировать правильнось?
не надо.
можно написать макрос, который во время компиляции проверит правильность (существующим классом regexp), а далее скомпилит (например) конечный автомат для этого выражения. и всё — во время компиляции!
Здравствуйте, _pk_sly, Вы писали:
ie>>Компилятор то может. Но это решение будет однобоким. В языках с нормальной поддержкой больших чисел перемножение 2х long'ов даст какой-нибудь bigint, а как это сделать без поддержки платформы неясно.
__>понятно как.
Мне — нет.
__>так же, как происходит умножение long на short. __>всё приводится к наиболее полному типу — явно или неявно.
Не, видимо мы говорим о разных вещах. Это можно сделать, добавив в стандартную библиотеку какую-нибудь реализацию класса BigInt. Изначально речь шла о немного другой поддержке больших чисел, но как правило заметили, она нафиг не нужна, ибо тормоза, да и реализовать без поддержки платформы невозможно.
ie>>Ок, проблема ясна, но для ее решения надо делать свою реализацию регексов. А как ты предлагаешь контролировать правильнось?
__>не надо.
Что не надо?
__>можно написать макрос, который во время компиляции проверит правильность (существующим классом regexp),
Вот это я и хочу понять, как он проверит, что регекс правильный? Какой критерий правильности регеска?
__> а далее скомпилит (например) конечный автомат для этого выражения.
И чем это отличается от деланья своей реализации регексов?
__>и всё — во время компиляции!
Здравствуйте, ie, Вы писали:
ie>Не, видимо мы говорим о разных вещах. Это можно сделать, добавив в стандартную библиотеку какую-нибудь реализацию класса BigInt. Изначально речь шла о немного другой поддержке больших чисел, но как правило заметили, она нафиг не нужна, ибо тормоза, да и реализовать без поддержки платформы невозможно.
На самом деле такие желания обычно возникают у людей усиленно использующих скрптовые языки типа Питона и Руби. Там сделана прозрачная поддержка болших целых, но к сожалению это ужасно сказывается на производительности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
