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

C>Подключаемая грамматика – наподобие подключаемой библиотеки – выглядит очень привлекательной альтернативой полностью определенному языку.

Все это не раз проходили, не прижилось.
Один из первых языков на котором я профессионально начал программировать это Форт, ожидания от него были практически такие же как от
Немерла, еще раньше тоже самое было с Лиспом, и совсем печально с Dylan,
не помогла даже поддержка Apple, притом Dylan по возможностям очень близок к Немерле http://www.opendylan.org/books/drm/Language_Overview.html

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

C>в общем, языки и рантаймы — это разные вещи.

Угу и многие языки без соответствующего рантайма никому не нужны.
Даже те же питон и руби в конце концов потребовали изменения рантайма NET.
OCaml превратившись в F# тоже много чего растерял.

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

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

C>>Подключаемая грамматика – наподобие подключаемой библиотеки – выглядит очень привлекательной альтернативой полностью определенному языку.

FR>Все это не раз проходили, не прижилось.
FR>Один из первых языков на котором я профессионально начал программировать это Форт, ожидания от него были практически такие же как от
FR>Немерла, еще раньше тоже самое было с Лиспом, и совсем печально с Dylan,
FR>не помогла даже поддержка Apple, притом Dylan по возможностям очень близок к Немерле http://www.opendylan.org/books/drm/Language_Overview.html

я пытаюсь понять, есть ли причины, которые заставят вас писать собственный компилятор изобретенного вами языка программирования, вместо того, что бы воспользоаватся метапрограммированием немерла, например(когда он позволит компилировать любой пользовательский синтаксис и позволит отключить собственный)
учитывая, что озвучены временные затраты порядка 2 месяцев на имплементацию с#
если причины есть — назовите их

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

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

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

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

C>Как вы обьясняете для себя существование множества языков программирования?
C>для чего то люди их выдумывают?
C>На мой взгляд — именно от невозможности реализовать что либо в библиотеке.

2 основных причины:
1. Критический объём фишек, которые нельзя реализовать силами существующих языков/рантаймов. Сюда же относятся узкопрофильные ЯП, желание попробовать скомбинировать идеи из различных типов ЯП и попытка изобрести принципиально новый ЯП.
2. Обострённый синдром NIH+избыток лишней энергии+нежелание изучать готовые решения. Забавная закономерность: окружающие очень скоро объявляются полными идиотами, а похожие языки, как один, страдают от фатальных недостатков.

C>>>Позволяет отказаться от ненужного наследства.
S>>Как?
C>написать грамматику, в которой не будет устаревших конструкций — например указателей, если они вам не нужны.
А почему бы просто не использовать устаревшие конструкции и не мучать окружающих?

---

C>>>Некоторые товарищи утверждают, что на имплементацию C# на немерле у них ушло 2 месяца.
S>>Нет, 2 месяца — это на немерль с синтаксисом шарпа. Полноценный компилятор, со всеми прелестями и нюансами — на порядок больше работы.
C>Не понял этого замечания — этот "немерль с синтаксисом шарпа" умеет компилить программы на шарпе?
Нет — поведение скомпилированного кода не будет совпадать с поведением оригинальной программы. Фактически, там транслятор c# в AST немерла. Немерлисты! Если ошибаюсь — поправьте, ок?

C>>>Можно ли за аналогичное време реализовать эрланг? F#?
S>>Да, только по поведению это будет всё тот же nemerle.
C>что имеется в виду под поведением? в чем отличие от оригинального F#?
См выше.

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

C>>написать грамматику, в которой не будет устаревших конструкций — например указателей, если они вам не нужны.
S>А почему бы просто не использовать устаревшие конструкции и не мучать окружающих?

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

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

S>А почему бы просто не использовать устаревшие конструкции и не мучать окружающих?
одна причина — элегантных синтаксических конструкций не так много,
и они оказываются нагружены устаревшими понятиями
например &x *x x->y занимаются ненужной нам адресной арифметикой
а мы могли бы приспособить их, например, для ленивых вычислений
или x|y x&y по традиции заняты возней с битами, что тоже не очень востребовано в нашем проекте
учитывая весь этот багаж, для наших целей остаются такие монстры, как x^^, a&&&b, x==>y, что уродливо.

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


C>>>>Некоторые товарищи утверждают, что на имплементацию C# на немерле у них ушло 2 месяца.
S>>>Нет, 2 месяца — это на немерль с синтаксисом шарпа. Полноценный компилятор, со всеми прелестями и нюансами — на порядок больше работы.
C>>Не понял этого замечания — этот "немерль с синтаксисом шарпа" умеет компилить программы на шарпе?
S>Нет — поведение скомпилированного кода не будет совпадать с поведением оригинальной программы. Фактически, там транслятор c# в AST немерла. Немерлисты! Если ошибаюсь — поправьте, ок?

ну приведите пример программы на с#, когда поведение будет отличаться.
даже если такой пример найдется, останется только занести его в баг лист и зафиксить.
понятно что генерируемый код будет несколько разный.
Такое бывает, например, в компиляторах C++ разных фирм или версий
— но никто не говорит, что у них "разное поведение"

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

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

var file = File.Open(...);
try
{
}
finally
{
    if (file != null)
        file.Dispose();
}

против

using (file = File.Open(...))
{
}

И это очень простой пример.

G>А теперь вопрос: если одни и те же задачи можно решать библиотекой или расширением\изменением\созданием нового языка, то что ты выберешь?
Если кода будет примерно одинакого то библиотеку.
А если синтаксисом код можно ужать хотябы в пару раз то синтаксис.

G>Может все таки стремиться не столько к изменяемым языкам, сколько к возможности выразить максимум средствами языка?
Ну иди попробуй выразить Nemerle.Peg средствами языка.

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

S>1. Критический объём фишек, которые нельзя реализовать силами существующих языков/рантаймов. Сюда же относятся узкопрофильные ЯП, желание попробовать скомбинировать идеи из различных типов ЯП и попытка изобрести принципиально новый ЯП.
Подавляющее колличество таких фишек можно сделать макросами.

S>Нет — поведение скомпилированного кода не будет совпадать с поведением оригинальной программы. Фактически, там транслятор c# в AST немерла. Немерлисты! Если ошибаюсь — поправьте, ок?
Там не компилируются некоторые фичи типа unsafe и иногда перегрузка работает не так как в C#. Но найти отличия в перегрузке может разве что nikov.
Также вывод типов заметно мощьнее. Но это не влияет на поведение.

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

C>я пытаюсь понять, есть ли причины, которые заставят вас писать собственный компилятор изобретенного вами языка программирования, вместо того, что бы воспользоаватся метапрограммированием немерла, например(когда он позволит компилировать любой пользовательский синтаксис и позволит отключить собственный)
C>учитывая, что озвучены временные затраты порядка 2 месяцев на имплементацию с#
C>если причины есть — назовите их

Угу "вы можете купить автомобиль любого цвета при условии сто это будет черный форд".
Тут же выше уже называли причины рантайм. Другая причина просто язык далекий от мейнстрима.
Третья написание небольшого языка используя например OCaml/Хаскель будет ненамного сложнее
чем чем на макросах Немерле или Лиспа.

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

WH>Там не компилируются некоторые фичи типа unsafe и иногда перегрузка работает не так как в C#. Но найти отличия в перегрузке может разве что nikov.
WH>Также вывод типов заметно мощьнее. Но это не влияет на поведение.

А хоть какой-то нетривиальный C# проект на нем уже пробовали компилировать?

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

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

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

WH>var file = File.Open(...);
WH>try
WH>{
WH>}
WH>finally
WH>{
WH>    if (file != null)
WH>        file.Dispose();
WH>}
WH>

WH>против
WH>

WH>using (file = File.Open(...))
WH>{
WH>}
WH>

WH>И это очень простой пример.
G>>А теперь вопрос: если одни и те же задачи можно решать библиотекой или расширением\изменением\созданием нового языка, то что ты выберешь?
WH>Если кода будет примерно одинакого то библиотеку.
WH>А если синтаксисом код можно ужать хотябы в пару раз то синтаксис.

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


G>>Может все таки стремиться не столько к изменяемым языкам, сколько к возможности выразить максимум средствами языка?
WH>Ну иди попробуй выразить Nemerle.Peg средствами языка.
Какого языка?

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

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

Откуда такие сведения? Есть конкретный опыт или это всего-лишь измышлизмы?

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

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

Вырази конструкцию создания экземпляра анонимного типа ленивой функцией.

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

FR>Тут же выше уже называли причины рантайм.
Это хорошая причина.

FR>Другая причина просто язык далекий от мейнстрима.
Это вообще не рпричина.

FR>Третья написание небольшого языка используя например OCaml/Хаскель будет ненамного сложнее чем чем на макросах Немерле или Лиспа.

А IDE ты тоже собрался писать?
А если тебя все устраивает но не хватает какойто фичи будешь весь язык переделывать?

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

G>Вместо оператора using можно сделать функцию using, что гораздо проще. В ленивом языке вообще любую конструкцию можно функцией выразить.
ComputationExpressions иди функцией вырази...

WH>>Ну иди попробуй выразить Nemerle.Peg средствами языка.
G>Какого языка?
Любого. Только макросы не используй.
Только давай без халтуры. Чтобы производительность была на уровне.

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

C>Некоторые товарищи утверждают, что на имплементацию C# на немерле у них ушло 2 месяца.

Не утверждают, а так оно почти и есть.

C>Можно ли за аналогичное време реализовать эрланг? F#?

F# — можно. Эрланг намного сложнее, так как в нем основная фишка это не язык, а рантайм. Сам язык там очень простой и его парсер и интерпретатор пишутся легко и быстро. А вот рантайм — это совсем другое дело. На это нужно не мало времени.

C>Если сроки реально такого порядка — стоит ли ожидать в будущем отдельный диалект языка программирования на каждую программерскую контору или крупный проект?

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

В прикладных же проектах обычно используются специализированные расширения которые позволяют упростить решение именно этих задач. Это опять же не создает новый язык. Обычно все ограничиваенся созданием DSL-я который позволяет описать задачу близко к ее декларации.

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

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

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

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

IT>Откуда такие сведения? Есть конкретный опыт или это всего-лишь измышлизмы?

Отлично можно наблюдать при переходе C#2 -> C#3.

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

FR>>Другая причина просто язык далекий от мейнстрима.
WH>Это вообще не рпричина.

Причина, но скажем даже не от мейнстрима а от типичного NET языка.
А если еще и рантайм при этом не подойдет может оказаться проще писать с нуля чем втискивать макросами.

FR>>Третья написание небольшого языка используя например OCaml/Хаскель будет ненамного сложнее чем чем на макросах Немерле или Лиспа.
WH>
WH>А IDE ты тоже собрался писать?

Нет, меня IDE мало волнует

WH>А если тебя все устраивает но не хватает какойто фичи будешь весь язык переделывать?

А вот этот случай как раз самое то для макропрограммирования.

C>>>>>Можно ли за аналогичное време реализовать эрланг? F#?
S>>>>Да, только по поведению это будет всё тот же nemerle.
C>>>что имеется в виду под поведением? в чем отличие от оригинального F#?

M>>На примере Erlang'а. Erlang — это не только синтаксис. Это и легковесные потоки, и асинхронные сообщения, и архитектура shared-nothing и т.д. и т.п. Для того, чтобы реализовать этона Немерле, ндо писать рантайм (грубо говоря) эрланга на Нмерле

C>суть моего оригинального вопроса состояла в следующем
C>- предположим, эрланга в природе еще нет,
C>и его идеи только что родились в моей гениальной голове.
C>Что мне выбрать — написать рантайм, и компилятор, и прикрутить это к какой нибудь среде программирования
C>или взять платформу метапрограммирования вроде немерле, реализовать на ней синтаксис,
C>допилить таки недостающие части рантайма — те самые легковесные потоки и сообщения.
C>(заметьте, мне не нужно писать весь рантайм, 90% уже есть).

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

Ну, можно и так. Только на практике все упирается в «насколько это нужно» и «насколько это соответствует требованиям». Как бы допиливание рантайма не вылилось в написание рантайма с нуля