>Первый и основной недостаток языка — это довольно медленный компилятор.

А нельзя ли сделать кроме компиляции еще решим интерпретации?
Соответсвенно все ошибки получать в рантайме.

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

D>А нельзя ли сделать кроме компиляции еще решим интерпретации?
D>Соответсвенно все ошибки получать в рантайме.

Чистая интепретация невозможна. Для поддержки МП несколько стадий компиляци должны пройти по всему коду.

Аналог интерпретации в принципе был. REPL в nemish. Правда он сломался, когда прикрутили подключаемые парсеры и никто его не налаживал. Ибо никто из команды не использует, а комьюнити не просит.

У меня витает идея бэкграунд компилятора для вебсервера в NancyFx, который следит за файлами и запускает компиляцию на каждое изменение, а любой запрос дожидался бы конца компиляции. Он, кстати, мог бы стать вполне популярен, ибо может быть использован не только для nemerle, а еще и для C#. Но в обозримом будущем времени на реализацию у меня нет Займитесь кто нибудь, это должно быть не сложно. Выдернуть файлы из проекта и отдать компилятору, потом сборку из памяти загрузить через late.

Если бы было время — я бы адаптировал NRails к Nancy (шоустоппером для рельс стала жесткая завязка MVC3 на студию). Превратить его в набор отдельно подключяемых инструментов (миграции, генерация модели, nemerle spark, route helpers ну и вышеописанный вебсервер). Можно еще простенький транслятор nemerle в js, из reactive фреймворка. В таком ключе, как раз для веба, nemerle будет очень хорош.

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

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

D>>А нельзя ли сделать кроме компиляции еще решим интерпретации?
D>>Соответсвенно все ошибки получать в рантайме.

Z>Чистая интепретация невозможна. Для поддержки МП несколько стадий компиляци должны пройти по всему коду.
Компиляция вроде просто вычисление вынесеное в отдельную статию, что мешает его производить в ран тайме?
Можно пройтись по всему коду и раскрыть везде foreach, или в рантайме раскрывать каждый из них по мере необходимости.

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

Z>>Чистая интепретация невозможна. Для поддержки МП несколько стадий компиляци должны пройти по всему коду.
D>Компиляция вроде просто вычисление вынесеное в отдельную статию, что мешает его производить в ран тайме?
D>Можно пройтись по всему коду и раскрыть везде foreach, или в рантайме раскрывать каждый из них по мере необходимости.

Типы в рантайме менять нельзя.

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

Z>Типы в рантайме менять нельзя.

Можно как в Руби.

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

Z>Если бы было время — я бы адаптировал NRails к Nancy (шоустоппером для рельс стала жесткая завязка MVC3 на студию). Превратить его в набор отдельно подключяемых инструментов (миграции, генерация модели, nemerle spark, route helpers ну и вышеописанный вебсервер). Можно еще простенький транслятор nemerle в js, из reactive фреймворка. В таком ключе, как раз для веба, nemerle будет очень хорош.

А почему завязка MVC3 на студию это шоустоппер для NRails? И что даст переход на Nancy, кроме того, что он более лаконичен?

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

Z>Типы в рантайме менять нельзя.
Можно пример, что за именения типов делает компилятор. У меня такое подозрение что он их не изменяет а создает, чем в принципе можно заниматся и в рантайме.

Здравствуйте, Маслаков Михаил, Вы писали:

ММ>А почему завязка MVC3 на студию это шоустоппер для NRails? И что даст переход на Nancy, кроме того, что он более лаконичен?

Nancy не требует спецпроекта. Значит не требуется допиливать интеграцию, год рельсы встали именно потому, что не хотелось пилить 2008, а 2010 еще не поддерживалось.

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

>>Первый и основной недостаток языка — это довольно медленный компилятор.

D>А нельзя ли сделать кроме компиляции еще решим интерпретации?

Зачем?

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

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

>>>Первый и основной недостаток языка — это довольно медленный компилятор.

D>>А нельзя ли сделать кроме компиляции еще решим интерпретации?

H>Зачем?
Что бы воспользоваться одним из главный плюсов динамических языков,
сразу запустить программу, а не ждать пока скомпилируется.

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

H>>Зачем?
D>Что бы воспользоваться одним из главный плюсов динамических языков,
D>сразу запустить программу, а не ждать пока скомпилируется.

Развеж это плюс? И кто сказал что Nemerle — динамический язык

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

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

H>>>Зачем?
D>>Что бы воспользоваться одним из главный плюсов динамических языков,
D>>сразу запустить программу, а не ждать пока скомпилируется.

H>Развеж это плюс? И кто сказал что Nemerle — динамический язык
Да, это плюс. Никто не говорил, предложение в интерпретации его как динамического.

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

H>>Развеж это плюс? И кто сказал что Nemerle — динамический язык
D>Да, это плюс. Никто не говорил, предложение в интерпретации его как динамического.

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

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

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

H>>>Развеж это плюс? И кто сказал что Nemerle — динамический язык
D>>Да, это плюс. Никто не говорил, предложение в интерпретации его как динамического.

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

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

D>Здравствуйте, hardcase, Вы писали:
H>>Даже если и запустить в таком режиме эту кухню, то выигрыш в скорости будет крайне сомнительным — от шага вывода типов уйти будет нелья, а это самое горячее место в компияторе. Типы будут выводиться, но не в компайл тайме, а в рантайме.
D>В моем понимании при компиляции нужно вывести их везде, при интерпретации только там где реально нужно, постепенно в процессе работы. И так как у вас может быть задействован далеко не весь функционал, то и большенство выводов просто не потребуются.
На сколько понимаю, для этого потребуется, чтобы вывод типов был полностью реактивным. А это будет сделано только в N2.

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

>>Первый и основной недостаток языка — это довольно медленный компилятор.

D>А нельзя ли сделать кроме компиляции еще решим интерпретации?
D>Соответсвенно все ошибки получать в рантайме.

Можно. Но кому это нужно?

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

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

>>>Первый и основной недостаток языка — это довольно медленный компилятор.

D>>А нельзя ли сделать кроме компиляции еще решим интерпретации?
D>>Соответсвенно все ошибки получать в рантайме.

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

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

VD>>Можно. Но кому это нужно?
D>Можно было бы переманивать людей с динамических языков.

Зачем? Немерл приципиально статически типизируемый язык. В этом его фишака. Основное достоинство немерла — это подсистема метапрограммирования времени компиляции — макросы. Для того чтобы макрос сделал свое дело нужно произвести копиляцию. Интерпретатор один фиг будет интепретировать программу которая прошла компиляцию. Так какой в этом смысл?

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

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

Можно и не выводить как в Руби.

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

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

VD>>>Можно. Но кому это нужно?
D>>Можно было бы переманивать людей с динамических языков.

VD>Зачем? Немерл приципиально статически типизируемый язык. В этом его фишака.
Тоесть вот такой сценарий только мне понятен, и вы с ним не сталкиваетесь? Неужто никогда не хочелось что бы не прходилось ждать когда все скомпилируется?
"Это полезно когда есть увереность что с точки зрения копиляции все правильно, а это бывает постоянно. Вспомните насколько часто вы запускаете компиляцию, которая проходит успешно и это вас не удивляет, потому что те измнения которые вы внесли можно было легко проверить своим внутриним компилятором, в процессе кодирования."

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