Не хватает "своего варианта", либо, как минимум, чего-то вроде "потребности проекта полностью покрываются имеющимися языками". А то всё голосование выглядит, как наивная спекуляция (пункты 13-15 — особо выделяются из-за "крутизны"). Да и вообще, выяснять причины отсутствия желания — некорректно. Причины есть у "наличествующего" желания, а не у его отстуствия.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Плохо смотрел.
ГВ>либо, как минимум, чего-то вроде "потребности проекта полностью покрываются имеющимися языками".
Опять же плохо смотрел. Есть пункт "Мне хватает возможностей одного из мэйнстрим-языков".
ГВ> А то всё голосование выглядит, как наивная спекуляция (пункты 13-15 — особо выделяются из-за "крутизны"). Да и вообще, выяснять причины отсутствия желания — некорректно. Причины есть у "наличествующего" желания, а не у его отстуствия.
Позволь каждому самому решать, что корректно, а что нет. Не нравится, не голосуй.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Banch, Вы писали:
B>Есть ещё причины: B>- за 5 лет так и не вышел релиз B>- нет ссылок на реальные примеры использования
Ну, так добавь эти, или любые другие, пункты и проголосуй за них.
Я добавил те что пришли в голову.
Что до пяти лет, то современные языки за 5 минут на коленке не делаются. Даже у корпораций вроде MS и Sun на это уходит 3-5 лет. А в опен-сорсе таких бабок нет.
B>А вообще язык кажется перспективным. Там много того, что должно упростить построение и развитие сложных проектов.
По тому и хочется понять что останавливает от его применения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Голосование] Почему я не использую Nemerle
ГВ>>Не хватает "своего варианта", VD>Плохо смотрел. ГВ>>либо, как минимум, чего-то вроде "потребности проекта полностью покрываются имеющимися языками". VD>Опять же плохо смотрел. Есть пункт "Мне хватает возможностей одного из мэйнстрим-языков".
На счёт этого ты прав — я не залогинился.
ГВ>> А то всё голосование выглядит, как наивная спекуляция (пункты 13-15 — особо выделяются из-за "крутизны"). Да и вообще, выяснять причины отсутствия желания — некорректно. Причины есть у "наличествующего" желания, а не у его отстуствия.
VD>Позволь каждому самому решать, что корректно, а что нет.
Я разве отбираю у кого-то такое право?
VD>Не нравится, не голосуй.
Не нравится. Не голосую.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я заинтересуюсь Nemerle, когда произойдут следующие вещи:
* что-нибудь измениться на nemerle.org, который уже 5 лет не обновлялся
* язык перевалит за 1.0, а не будет в 0.9 бете с 2005-го года (вообще, товарищи, в языке с этого времени хоть что-нибудь происходило?)
* релизы языка будут сопровождаться внятными release notes-ами
* появится более-менее приличное описание языка
* на сайте появиться нормальная инструкция, как откомпилировать исходники для windows, linux и macos
* появится IRC канал, где будет хоть с десяток человек, чтобы получить ответы на вопросы
* появится парочка блогов
* напишут нормальную вики на английком языке
* на англоязычном форуме будет больше активности, чем три сообщения в неделю, а Влад хоть немного подучит английский
* вся та неведомая мощь немерле найдет хоть какое-то применение в библиотеках. То жалкое количество из 5 библиотечек, созданное в 2005 году, совсем не впечатляет.
* будет хоть немного публично доступных проектов на немерле, взглянув на которые можно будет сказать, что nemerle is cool
* и последнее: умрет этот дебильный никому не нужный проект под названием "интеграция Neverle и VS".
Сравните Nemerle и, например, Perl6 (который тоже не понятно где бороздит космические пространства). Так вот у Perl6 есть несколько активных сайтов, вики, IRC (170 человек последний раз, когда я заходил), релизы регулярные и сопровождаются простынями о том, что было сделано, есть bug tracker, даже есть граф с количесвом pass/fail тестов, книгу какую-то они там всем миром пишут, rakudo и parrot можно откомпилировать под любую платформу благодаря хорошо отлаженному toolset-у. У Nemerle даже близко ничего подобного нет за 5 лет... потраченных на какую-то интеграцию.
Re[2]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
A>>... У Nemerle даже близко ничего подобного нет за 5 лет... потраченных на какую-то интеграцию.
V>Языкам с легкой организацией REP-loop вроде как IDE не особо нужна, в отличие от статически типизируемых с выводом типов.
Языки OCaml и Haskell очень жестко статически типизированы и с выводом типов, при этом у обоих вполне нормальный REPL.
Re[4]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>С целью сбора информации прошу ответить на вопрос: VD>
VD>Почему я боюсь/не хочу/не могу использовать Nemerle в своей работе?
О переходе на другой язык вообще, безотносительно Nemerle.
Отсутствие подходящих для меня библиотек.
Я, например, использую С++; тут необходимых сторонних библиотек много, очень часто с открытыми исходниками. Уже не раз они мне помогали:
1. использую библиотеку из коробки;
2. исправляю ошибки в библиотеке, дополняю её;
3. саму библиотеку я не использую, но чтение кода позволяет разобраться в необходимом мне алгоритме.
И всё это в пределах одного языка и одного компилятора. Был опыт ковыряния кода на Фортране и Матлабе — не вставило. Если перейти на другой язык, то знания мейнстримовых языков области деятельности всё равно будет необходимо, всё равно придётся читать и писать на них код, а после писать для них обёртки. Зачем?
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>... и IDE качества ниже плинтуса. Собственно популярность этих языков тоже не блещет. А возраст у них куда старше.
На фоне Немерле они весьма популярны. Возраст у Немерле тоже уже не нулевой с таким темпом роста популярности он и OCaml
не догонит.
Ну и этот твой агрессивный ответ иллюстрирует еще одну причину непопулярности Немерли — слишком злые фанаты.
Re[4]: [Голосование] Почему я не использую Nemerle
Здравствуйте, FR, Вы писали:
V>>Языкам с легкой организацией REP-loop вроде как IDE не особо нужна, в отличие от статически типизируемых с выводом типов.
FR>Языки OCaml и Haskell очень жестко статически типизированы и с выводом типов, при этом у обоих вполне нормальный REPL.
Не знаю насчет OCaml, но у т.н. "интерпретатора" Haskell никакой он не нормальный. В окне непосредственного исполнения ты можешь использовать ограниченное подмножество языка. Все остальное надо оформлять в файл и вскармливать среде.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
Re[6]: [Голосование] Почему я не использую Nemerle
Здравствуйте, kochetkov.vladimir, Вы писали:
FR>>слишком злые фанаты.
KV>Если бы это было аргументом, то линукс бы вообще не имел прав на существование
Есть большие подозрения что злые фанаты у линукса появились уже после того как он стал вполне популярным
Re[5]: [Голосование] Почему я не использую Nemerle
V>Не знаю насчет OCaml, но у т.н. "интерпретатора" Haskell никакой он не нормальный. В окне непосредственного исполнения ты можешь использовать ограниченное подмножество языка. Все остальное надо оформлять в файл и вскармливать среде.
Здравствуйте, VladD2, Вы писали:
VD>Почему я боюсь/не хочу/не могу использовать Nemerle в своей работе?
Почитал, на досуге, главный вопрос сколько человеко-часов мне потребуется на переход и что я получу в замен обычных плюсов? В своем опыте имею бэйсик, турбо си, паскаль, с++ сейчас. Я не хочу никого обидеть, просто вот не понял необходимости ЕЩЕ.
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Re[6]: [Голосование] Почему я не использую Nemerle
Здравствуйте, FR, Вы писали:
FR>не догонит. FR>Ну и этот твой агрессивный ответ иллюстрирует еще одну причину непопулярности Немерли — слишком злые фанаты.
Чем меньше коммюнити тем злее фанаты.
Re[7]: [Голосование] Почему я не использую Nemerle
Здравствуйте, kochetkov.vladimir, Вы писали:
FR>>слишком злые фанаты.
KV>Если бы это было аргументом, то линукс бы вообще не имел прав на существование
Там не все злые, токмо красноглазые.
Re[6]: [Голосование] Почему я не использую Nemerle
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, VladD2, Вы писали:
VD>>... и IDE качества ниже плинтуса. Собственно популярность этих языков тоже не блещет. А возраст у них куда старше.
FR>На фоне Немерле они весьма популярны. Возраст у Немерле тоже уже не нулевой с таким темпом роста популярности он и OCaml не догонит.
Поживем — увидим.
FR>Ну и этот твой агрессивный ответ иллюстрирует еще одну причину непопулярности Немерли — слишком злые фанаты.
Агрессивный? Тебе виднее, конечно. Я просто говорю что вижу. То на что ты мне давал ссылку вообще не рабочее было. Зависло на первых же примерах. Для Хасклея та же фигня.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
FR>>На фоне Немерле они весьма популярны. Возраст у Немерле тоже уже не нулевой с таким темпом роста популярности он и OCaml не догонит.
VD>Поживем — увидим.
Вообще жаль что так получается, что с Немерле что с тем же D.
FR>>Ну и этот твой агрессивный ответ иллюстрирует еще одну причину непопулярности Немерли — слишком злые фанаты.
VD>Агрессивный? Тебе виднее, конечно. Я просто говорю что вижу.
Конечно агрессивный. Евангелист должен быть немного политиком и уметь не говорить "то что видишь"
VD>То на что ты мне давал ссылку вообще не рабочее было. Зависло на первых же примерах. Для Хасклея та же фигня.
Здравствуйте, VladD2, Вы писали:
VD>С целью сбора информации прошу ответить на вопрос: VD>
VD>Почему я боюсь/не хочу/не могу использовать Nemerle в своей работе?
Пир продавших душу Майкрософту когда-нибудь закончится. Придёт Спаситель и низвергнет Майкрософт и польстившихся на синтаксический сахар в геену огненную... Там будет плач и скрежет зубов...
художников никогда не обижал
Re[3]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
N>>О переходе на другой язык вообще, безотносительно Nemerle. N>>Отсутствие подходящих для меня библиотек.
VD>А какие библиотеки нужны?
Обработка изображений, компьютерное зрение, пару раз численные методы...
Я в курсе, что практически у каждой популярной библиотеки есть биндинги для .Net. OpenCV даже биндинги к Питону официально поддерживает. Но сейчас при необходимости подключиться к ним отладчиком мне вообще никаких лишних телодвижений делать не надо.
Интеловские IPP ещё используем. С ними из под "родного" С++ работать также удобней.
Плюс всё это кроссплатформенно.
P.S. Все продукты видеоанализа, которые я видел, написаны на С/С++. Многие из них также используют IPP и OpenCV. Это почти отраслевой стандарт. Тут задача — придумать нормальный алгоритм. Кодирование — ерунда.
Re[8]: [Голосование] Почему я не использую Nemerle
Здравствуйте, FR, Вы писали:
FR>Вообще жаль что так получается, что с Немерле что с тем же D.
Я не знаю, что там получилось с Ди. А у немерла еще все впереди. Москва не сразу строилась.
FR>Конечно агрессивный. Евангелист должен быть немного политиком и уметь не говорить "то что видишь"
Видимо дело в том, что я не хочу быть евангелистом. Я просто вижу перспективность вещи и говорю об этом.
FR>Не понял на что именно я тебе ссылку давал?
Ты мне давал ссылку на какую-то IDE для ОКамла. Но что-то глючила она очень сильно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Nuzhny, Вы писали:
N>Я в курсе, что практически у каждой популярной библиотеки есть биндинги для .Net. OpenCV даже биндинги к Питону официально поддерживает. Но сейчас при необходимости подключиться к ним отладчиком мне вообще никаких лишних телодвижений делать не надо.
Дык и дальше не надо будет.
N>Интеловские IPP ещё используем. С ними из под "родного" С++ работать также удобней. N>Плюс всё это кроссплатформенно.
Это несомненно плюс. Жаль только с немалым трахом.
N>P.S. Все продукты видеоанализа, которые я видел, написаны на С/С++. Многие из них также используют IPP и OpenCV. Это почти отраслевой стандарт. Тут задача — придумать нормальный алгоритм. Кодирование — ерунда.
Тут вопрос в том, что С/С++ на сегодня позволяет выжать максимум скорости. Но платой за то является весьма посредственная функциональность. Точнее сложность реализации на С++ сложного анализа. В задачах анализа очень удобно применять паттарн-матчинг и ДСЛ-и. И тут С++ не силен.
Ну, да я не предлагаю всем пересесть на дотнет и выбросить С++ полностью. Там где нужна максимальная скорость не грехом будет даже ассемблером (по крайней мере встроенным) воспользоваться. Но это весьма не большая группа задач. Да и ее можно весьма эффективно абстрагировать от тупых но ресурсоемких вычислений и рализовывать логику на более высокоуровневых языках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Ларик, Вы писали:
Л>Почитал, на досуге, главный вопрос сколько человеко-часов мне потребуется на переход и что я получу в замен обычных плюсов? В своем опыте имею бэйсик, турбо си, паскаль, с++ сейчас. Я не хочу никого обидеть, просто вот не понял необходимости ЕЩЕ.
Все зависит от задач и опыта.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [Голосование] Почему я не использую Nemerle
Здравствуйте, FR, Вы писали:
VD>>Я не знаю, что там получилось с Ди. А у немерла еще все впереди. Москва не сразу строилась.
FR>Да все у них в смысле туманного будущего практически одинаково
Туманность будущего определяется задымленностью глаз смотрящего (т.е. неуверенностью).
VD>>Видимо дело в том, что я не хочу быть евангелистом. Я просто вижу перспективность вещи и говорю об этом.
FR>Ну тогда тебе и смысла нет проводить подобные опросы.
Наверно. Просто легко в споры втягиваюсь. Есть такая беда...
FR>Ну могу только сказать что у меня не глючит.
Я плохо на нее влияю?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Голосование] Почему я не использую Nemerle
Не хотел отвечать, так как этот список один большой набор домыслов и инсинуаций. Есть, конечно, пара дельных замечаний. Но они тонут в море домыслов.
A>Я заинтересуюсь Nemerle, когда произойдут следующие вещи: A>* что-нибудь измениться на nemerle.org, который уже 5 лет не обновлялся
Для этого нужно было заходить на сайт чаще чем раз в 5 лет.
A>* язык перевалит за 1.0, а не будет в 0.9 бете с 2005-го года (вообще, товарищи, в языке с этого времени хоть что-нибудь происходило?)
Если бы ты заходил на сайт чаще чем раз в 5 лет, то увидел бы, что текущая версия 1.0.
A>* релизы языка будут сопровождаться внятными release notes-ами
Дельное замечание. Постараемся реализовать.
A>* появится более-менее приличное описание языка
Если зайти на сайт и попытаться его почитать, то окажется, что оно таки есть.
A>* на сайте появиться нормальная инструкция, как откомпилировать исходники для windows, linux и macos
Та же фигня. Инструкция доступна уже года 3. Линуксоавая так вообще 5.
A>* появится IRC канал, где будет хоть с десяток человек, чтобы получить ответы на вопросы
IRC-канало есть, но вот посещают его не многие, так как многие знающие люди его не читают предпочитая веб-форумы.
A>* появится парочка блогов
В гугле тебя тоже забанили?
A>* напишут нормальную вики на английком языке
Да, да. Зайдя на сайт нужно все таки его читать.
A>* на англоязычном форуме будет больше активности, чем три сообщения в неделю, а Влад хоть немного подучит английский
Критика английского Влада тоже справедлива. Вот только не имеет отношения к делу.
С активностью на форумах все в порядке. Особенно если вспомнить, что главное, что на них можно получить ответ на любой вопрос, а не то что туда ходят туча дятлов по трепаться за жизнь.
А уж русскоговорящим и подавно жаловаться грешно. Форум на РСДН постоянно забит вопросами. И ответы на них даются чуть ли не в реал-тайме.
A>* вся та неведомая мощь немерле найдет хоть какое-то применение в библиотеках. То жалкое количество из 5 библиотечек, созданное в 2005 году, совсем не впечатляет.
Для этого на них тоже нужно смотреть. Или хотя бы описание читать.
A>* будет хоть немного публично доступных проектов на немерле, взглянув на которые можно будет сказать, что nemerle is cool
Для этого нужно чтобы их кто-то делал. Но это сложно. Проще списки требований выдвигать. В прочем немного есть. Каталог snippets в твоем распоряжении.
A>* и последнее: умрет этот дебильный никому не нужный проект под названием "интеграция Neverle и VS".
Это вообще какая-то глупость сказанная явно со зла. Не нравится, не ешь. Нотпэд и VIM в твоем распоряжении.
A>Сравните Nemerle и, например, Perl6 (который тоже не понятно где бороздит космические пространства).
Ага! Ну, хоть какая то конкретика. Давай сравним. Я в перле не силен, так что буду пользоваться цитатами из Википедии.
A> Так вот у Perl6 есть несколько активных сайтов, вики, IRC (170 человек последний раз, когда я заходил),
Читаем что по этому поводу написано в разделе "Perl#Текущая версия и разработка" википедии:
Сегодня основной для разработчиков является пятая версия языка Perl, однако (на некоторых веб-серверах) продолжают использоваться программы (скрипты), написанные на предыдущей — четвёртой — версии (из-за частичной обратной несовместимости). Фактически стандарт языка определяется реализацией интерпретатора.
С 2000 года идет разработка новой (6-ой) версии языка. В отличие от предыдущих версий, разработчики планируют создать четко определенный стандарт языка. В настоящее время существуют экспериментальные компиляторы Perl 6
A>релизы регулярные и сопровождаются простынями о том, что было сделано,
Ну, просто достижение нечеловеческих масштабов. Релизы? Их есть у меня (с): http://code.google.com/p/nemerle/downloads/list
До недавнего времени выкладывались все билды, но сейчас мы это дело ограничили немного, так как слишком много мусора получается. Многие билды просто никто не успевает скачать.
A>есть bug tracker,
Этого у нас нет. У нас принято перед комитом в trunk прогонять все тесты. Так что не прохождение тестов — это аварийная ситуация и при этом инсталлятор автоматически не собирается.
A> книгу какую-то они там всем миром пишут,
Ну, я тоже какую-то пишу. Правда не всем миром (я всем миром не умею).
A> rakudo и parrot можно откомпилировать под любую платформу благодаря хорошо отлаженному toolset-у. У Nemerle даже близко ничего подобного нет за 5 лет... потраченных на какую-то интеграцию.
Ну, можно подытожить. Ты явно не заходил на сайт последние 5 лет и столько же не пытался скачать последних сборок. Это если в очень мягких выражениях.
Не понимаю только одного. Почему так зло?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Был бы компилятор в LLVM...
Да было бы очень не дурно. Но это не мало работы. LLVM весьма низкоуровневый рантайм. Нужно многое реализовать вручную.
Фактически умнее было бы создать VM на его базе или встроить его поддержку в Моно.
В прочем если кто-то возьмется за реализацию нэйтив-компилятора для Немерле на основе LLVM или чего-то аналогичного, то я буду только "за" и постараюсь оказать ему всяческую поддержку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Все зависит от задач и опыта.
Я так понимаю ВЫ тянете этот проект здесь? Накидайте эссе что он дает, да я тоже не в радости от виндовских плюсов (студии), шарпы меня просто бесят, но сейчас и так кризис, а переучиватся некогда, кушать охота иногда.
ЗЫ Статьи почитал, но как-то технически, нет разделения "вот это лучше этим"
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Re[3]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>Языкам с легкой организацией REP-loop вроде как IDE не особо нужна, в отличие от статически типизируемых с выводом типов.
Необходимость IDE определяется не языком или наличием у него консольного интерпретатора, а привчками и умениями разработчика использующего язык. Лично моя эффективность без IDE значительно ниже.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Ларик, Вы писали:
Л>Я так понимаю ВЫ тянете этот проект здесь? Накидайте эссе что он дает, да я тоже не в радости от виндовских плюсов (студии), шарпы меня просто бесят, но сейчас и так кризис, а переучиватся некогда, кушать охота иногда.
Одна из этих статей: http://rsdn.ru/summary/3766.xml
за такое эссе не проканает?
Л>ЗЫ Статьи почитал, но как-то технически, нет разделения "вот это лучше этим"
Не очень понял мысли. Что значит технически?
Скажем в C# метарограммирование вообзе практически не возможно (если не считать генерации кода в строчку и компиляцию его отдельными утилитами). В C++ есть метапрограммирование основанное на побочных эффектах (рекурсивной специализации шаблонов). Оно тяжело в приготовлении, часто жрет много места на дисе, тормозит, тяжело в отладке и сопровождении. В Немерле метапрограммирование встроено, что называется, нарочно. С ним нет таких проблем как в С++. При этом сам язык успешно мимикрирует под тот же C#, причем не без помощи тех же макросов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, можно подытожить. Ты явно не заходил на сайт последние 5 лет и столько же не пытался скачать последних сборок. Это если в очень мягких выражениях.
VD>Не понимаю только одного. Почему так зло?
Я у него никакого зла не заметил Вероятно, ты признаешь справедливость его претензий но у тебя нет надежды на решение этих проблем потому рождается чувство злобы которое ты приписываешь собеседнику
Ты себя со стороны давно видел то ?
Re[2]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Anton Batenev, Вы писали: AB>Здравствуйте, VladD2, Вы писали:
VD>> Почему я боюсь/не хочу/не могу использовать Nemerle в своей работе? AB>Ну для самого-самого начала...
Можешь продолжать, ибо fixed. Я весь во внимании
AB>Пояснения требуются?
<sarcasm>Ну уж поясни, каким образом, глючность медиавики (Apache+PHP+MySQL) под виндой влияет на то, что ты боишься использовать Nemerle в своей работе? </sarcasm>
Хреново, что сайт глючит, согласен. Издержки переноса с польской фряхи на RSDN'овскую винду. Над этим работаем, сейчас переносим багтрекер на гуглокод, как только, так сразу займемся приведением вики в божеский вид под правильную платформу на правильном фреймворке.
Здравствуйте, любой, Вы писали:
Л>Пир продавших душу Майкрософту когда-нибудь закончится. Придёт Спаситель и низвергнет Майкрософт и польстившихся на синтаксический сахар в геену огненную... Там будет плач и скрежет зубов...
Так МС-у Немерл как раз и не нужен. То что языку крышка стало ясно когда его полюбили экс-советские программисты. У всех нас вместе взятых настолько плохая карма, что факт массовой любви — это приговор любому языку или технологии (достаточно вспомнить тот-же Delphi). Использовать язык в такой ситуации абсолютно бесперспективно.
Здравствуйте, kochetkov.vladimir, Вы писали:
k> VD>> Почему я боюсь/не хочу/не могу использовать Nemerle в своей работе? k> AB>Ну для самого-самого начала... k> Можешь продолжать, ибо fixed. Я весь во внимании
Ну "нешмогла я" пройти молча мимо
k> Хреново, что сайт глючит, согласен. Издержки переноса с польской фряхи на RSDN'овскую винду. Над этим работаем, сейчас переносим багтрекер на гуглокод, как только, так сразу займемся приведением вики в божеский вид под правильную платформу на правильном фреймворке.
То, что нельзя пока исходники получить одним архивом пропустим — уверен, что вы сделаете.
Шаг 2.
$ make
...
../lib/IAnonymous.n:1:3:1:3: warning: N10002: CR character found in input stream
...
ERROR:reflection.c:2587:get_field_on_inst_generic_type: assertion failed: (field_index >= 0 && field_index < dgclass->count_fields)
Stacktrace:
at (wrapper managed-to-native) System.MonoType.GetField (string,System.Reflection.BindingFlags) <0x00004>
at (wrapper managed-to-native) System.MonoType.GetField (string,System.Reflection.BindingFlags) <0xffffffff>
at System.MonoType.GetField (System.Reflection.FieldInfo) <0x00078>
at System.Reflection.Emit.TypeBuilder.GetField (System.Type,System.Reflection.FieldInfo) <0x0001b>
at Nemerle.Compiler.ILEmitter.FrameworkGetField (System.Type,System.Reflection.FieldInfo) <0x0006e>
at Nemerle.Compiler.ILEmitter.GetFieldInfo (System.Type,Nemerle.Compiler.IField) <0x00046>
at Nemerle.Compiler.ILEmitter.emit (Nemerle.Compiler.Typedtree.TExpr) <0x066ba>
at Nemerle.Compiler.ILEmitter.emit (Nemerle.Compiler.Typedtree.TExpr) <0x04cea>
at Nemerle.Compiler.ILEmitter.emit (Nemerle.Compiler.Typedtree.TExpr) <0x01a9c>
at Nemerle.Compiler.ILEmitter.emit (Nemerle.Compiler.Typedtree.TExpr) <0x01dc8>
at Nemerle.Compiler.ILEmitter.emit (Nemerle.Compiler.Typedtree.TExpr) <0x01dc8>
at Nemerle.Compiler.ILEmitter.emit (Nemerle.Compiler.Typedtree.TExpr) <0x041a4>
at Nemerle.Compiler.ILEmitter.Run () <0x000f7>
at Nemerle.Compiler.MethodBuilder/_N__N_lambda__60081__60202.apply_void () <0x000ce>
at Nemerle.Compiler.TypeBuilder.FinalizeType () <0x000a4>
at Nemerle.Compiler.TypeBuilder.EmitImplementation () <0x001a5>
at Nemerle.Compiler.TypesManager/_N_emit_impl__53220.apply_void (Nemerle.Compiler.TypeBuilder) <0x0004e>
at Nemerle.Compiler.TypesManager/_N_maybe_f__53791.apply_void (Nemerle.Compiler.TypeBuilder) <0x0019c>
at Nemerle.Collections.NList.Iter<object> (Nemerle.Core.list`1<object>,Nemerle.Builtins.FunctionVoid`1<object>) <0x000bf>
at Nemerle.Core.list`1<object>.Iter (Nemerle.Builtins.FunctionVoid`1<object>) <0x0002a>
at Nemerle.Compiler.TypesManager.Iter (Nemerle.Core.list`1<Nemerle.Compiler.TypeBuilder>,Nemerle.Builtins.FunctionVoid`1<Nemerle.Compiler.TypeBuilder>) <0x00084>
at Nemerle.Compiler.TypesManager.Iter (Nemerle.Builtins.FunctionVoid`1<Nemerle.Compiler.TypeBuilder>) <0x00028>
at Nemerle.Compiler.TypesManager.compile_all_tyinfos (bool) <0x00169>
at Nemerle.Compiler.TypesManager/_N__N_lambda__52660__52763.apply_void () <0x0001f>
at Nemerle.Compiler.Solver.Enqueue (Nemerle.Builtins.FunctionVoid) <0x00045>
at Nemerle.Compiler.TypesManager.EmitDecls () <0x00052>
at Nemerle.Compiler.ManagerClass.Run () <0x003f5>
at Nemerle.CommandlineCompiler.MainClass.main_with_catching () <0x0011f>
at Nemerle.CommandlineCompiler.MainClass.Main () <0x0018b>
at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
$ mono --version
Mono JIT compiler version 2.4.2.2 (tarball Fri Jul 24 11:24:57 EDT 2009)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
GC: Included Boehm (with typed GC)
SIGSEGV: altstack
Notifications: epoll
Architecture: x86
Disabled: none
Какая дополнительная информация требуется для исправления ошибки?
Меня это не успокоило
VD> Собранные под виндой бинарники на Моно, тем не менее, работают. Так что сам компилятор можно скопировать с Винды из использовать под Линуксом.
ОК. Где можно взять собранный под виндой компилятор?
Здравствуйте, Anton Batenev, Вы писали:
AB>Меня это не успокоило
Тут два варианта:
Или починят моно.
Или немерле переедет на другой движек для генерации сборок.
$ ls -l ncc.exe
-rwxr-xr-x 1 abbat abbat 16384 2010-04-05 16:18 ncc.exe*
$ ./ncc.exe
install the Windows version of Mono to run .NET executables
Жесть... Да, я знаю, что для бинарников моно недостаточно простого указания бита исполнения для файла, как это принято в мире *nix, но подобное неожиданное поведение каждый раз сносит башню.
Ладно, идем в First Tutorial и берем пример "Rewriting line counter without mutable values":
class FunctionalLineCounter
{
public static Main () : void
{
def sr = System.IO.StreamReader ("~/8.0-RELEASE-i386-disc1.iso");
def read_lines (line_no : int) : int { // (1)
def line = sr.ReadLine ();
if (line == null) // (2)
line_no // (3)else {
System.Console.WriteLine (line); // (4)
read_lines (line_no + 1) // (5)
}
};
System.Console.WriteLine ("Line count: {0}", read_lines (0)); // (6)
}
}
Не подумайте чего плохого прочитав имя файла — я просто хотел посмотреть как оно себя поведет в неожиданной ситуации, но засада случилась не здесь:
$ mono out.exe
Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path "/home/abbat/projects/nemerle/test/~/8.0-RELEASE-i386-disc1.iso".
at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000]
at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000]
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
at System.IO.File.OpenRead (System.String path) [0x00000]
at System.IO.StreamReader..ctor (System.String path, System.Text.Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize) [0x00000]
at System.IO.StreamReader..ctor (System.String path) [0x00000]
at (wrapper remoting-invoke-with-check) System.IO.StreamReader:.ctor (string)
at FunctionalLineCounter.Main () [0x00000]
Здравствуйте, Anton Batenev, Вы писали:
AB>Не подумайте чего плохого прочитав имя файла — я просто хотел посмотреть как оно себя поведет в неожиданной ситуации, но засада случилась не здесь:
В данном случае проблемы с тем что System.IO.StreamReader не знает что вместо ~ нужно подставить home пользователя.
Почему он этого не знает я не знаю.
Задай полное имя /home/abbat/8.0-RELEASE-i386-disc1.iso тогда по идее должно сработать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Anton Batenev, Вы писали:
AB>Не подумайте чего плохого прочитав имя файла — я просто хотел посмотреть как оно себя поведет в неожиданной ситуации, но засада случилась не здесь:
1. А с чего mono должно само разворачивать тильду?
2. Причем тут nemerle? Этот же результат ты бы получил на любом другом языке под mono.
VD>Почему я боюсь/не хочу/не могу использовать Nemerle в своей работе?
Считаю подход к метапрограммированию в Nemerle идеологически неверным.
Пояснение:
Делать макросы плагинами к компилятору, означает создавать жесткую зависимость между структурами данных компилятора и пользовательским кодом. Это мешает развиваться компилятору, так как невозможно легко и безопасно менять внутренние структуры и алгоритмы компиляции и мешает развиваться пользовательскому коду, так как при каждом новом релизе компилятора есть риск неработоспособности макросов.
Плюс к этому, Nemerle является фактически "языком одного компилятора", так как любой конкурирующий компилятор вынужден будет в точности повторять внутренности нынешнего, иначе часть пользовательского кода работать не будет.
Re[6]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Anton Batenev, Вы писали:
VD>> AB>Какая дополнительная информация требуется для исправления ошибки? VD>> Это баг Моно: VD>> https://bugzilla.novell.com/show_bug.cgi?id=467834
AB>Меня это не успокоило
А тебя никто и не успокаивал. Тебе ответили на вопрос который ты задал. В Моно есть баги. Исправят, и будет все ОК.
VD>> Собранные под виндой бинарники на Моно, тем не менее, работают. Так что сам компилятор можно скопировать с Винды из использовать под Линуксом.
AB>ОК. Где можно взять собранный под виндой компилятор?
Здравствуйте, kochetkov.vladimir, Вы писали:
k> AB>Не подумайте чего плохого прочитав имя файла — я просто хотел посмотреть как оно себя поведет в неожиданной ситуации, но засада случилась не здесь: k> 1. А с чего mono должно само разворачивать тильду?
Здравствуйте, kochetkov.vladimir, Вы писали: KV>1. А с чего mono должно само разворачивать тильду?
А кто ее должен разворачивать?
KV>P.S: http://www.go-mono.com/docs/index.aspx?link=T:System.Environment.SpecialFolder вообще-то.
Ненене. Строчка от юзера могла прийти. Mono.Unix.Path.GetFullPath починили уже?
Хотя вот как раз программист о принятых в разных осях алиасах задумываться не должен.
Re[10]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>1. А с чего mono должно само разворачивать тильду? MC>А кто ее должен разворачивать?
Если строчка могла прийти от юзера, то наличие там тильды — это малейшее из зол, которые необходимо ожидать и соответствующим образом обрабатывать.
MC>Mono.Unix.Path.GetFullPath починили уже?
А что с ним?
MC>Хотя вот как раз программист о принятых в разных осях алиасах задумываться не должен.
Именно поэтому вышеупомянутый SpecialFolder и является тем самым путем, благодаря которому программер может не задумываться об алиасах.
Здравствуйте, kochetkov.vladimir, Вы писали: KV>Это исключительно функционал шелла, причем не особо стандартизованный.
Зато удобная. И тот же питон тильды умеет разворачивать.
В общем объяснять отсутствие фичи тем, что это типа чужой и нестандартный функционал — несерьезно. Лучше уж честно признаться что лень/нет денег/...
KV>Если строчка могла прийти от юзера, то наличие там тильды — это малейшее из зол, которые необходимо ожидать и соответствующим образом обрабатывать.
Соответствующим — это каким? У нас же, блин, дотнет. Кроссплатформенная технология. Под линуксом мож я хочу тильду разворачивать, а под виндой — нет.
MC>>Mono.Unix.Path.GetFullPath починили уже? KV>А что с ним?
Было время, он не разворачивал тильду. Как сейчас — хз.
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>Не знаю насчет OCaml, но у т.н. "интерпретатора" Haskell никакой он не нормальный. В окне непосредственного исполнения ты можешь использовать ограниченное подмножество языка. Все остальное надо оформлять в файл и вскармливать среде.
Эьл вы про Hugs ?
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Не очень понял мысли. Что значит технически?
Сорри, не правильно высказался, как объяснить начальству, заказчику, что ЭТО лучше. Я от ВАС не требую ничего, а устраиваю что-то вроде "порки" , Вы же советов спрашивали? Идея интересная, многое мне понравилось, но это только для нового проекта пока, старое разумеется никто перетаскивать не будет.
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Re[7]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD> http://nemerle.googlecode.com/svn/nemerle/trunk/boot VD> Это файлы компилятор которыми собирается сам компилятор. Они немного отстают в версии, но тоже периодически обновляются.
Так при выполнении make он и должен был собрать им или нет?
Здравствуйте, Ларик, Вы писали:
Л>Сорри, не правильно высказался, как объяснить начальству, заказчику, что ЭТО лучше.
Мне кажется, что если заказчик предъявляет претензии к языку (что совершенно не обязательно), то объяснение должно быть очень простым — "это позволит нам использовать продвинутые техники, что в итоге приведет к снижению затрат на разработку". Ну, если там есть дествительно толковые программисты, то можно объяснить про поддержку ФП, схожесть с шарпом и про метапрограммирование.
Л>Я от ВАС не требую ничего, а устраиваю что-то вроде "порки", Вы же советов спрашивали?
ОК
Л> Идея интересная, многое мне понравилось, но это только для нового проекта пока, старое разумеется никто перетаскивать не будет.
Дык я сам бы не стал переписывать что-то уже работающее на другом языке. Другое дело новый проект (особенно если он небольшой) или какую-то более менее обособленную часть проекта (подпроект). Ведь длл созданная на Немерле может быть соврешенно не отличима от сишарпной или вбшной. Ну, а если это отдельное приложение, то вообще проблем нет. Опять же все наработки можно будет использовать через подключение библиотек.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Anton Batenev, Вы писали:
AB>Так при выполнении make он и должен был собрать им или нет?
Дано, но немного более новой версии. Это так называемый бутстрапинг, когда компилятор собирается сам собой. При этом, чтобы скомпилировать из исходников новую версию, нужно иметь старую версию бинарников (которой будте компилироваться новая). При существенных изменениях в компиляторе, после перекомпиляции бинарники закладываются в SVN, чтобы в дальнейшем собирать ими последующие версии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mr.Cat, Вы писали:
MC>В общем объяснять отсутствие фичи тем, что это типа чужой и нестандартный функционал — несерьезно. Лучше уж честно признаться что лень/нет денег/...
Сходи на сапорт Новела и задай им этот вопрос. Может они тебе про деньги расскажут. Что здесь то об этом говорить?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Dufrenite, Вы писали:
D>Пояснение: D>Делать макросы плагинами к компилятору, означает создавать жесткую зависимость между структурами данных компилятора и пользовательским кодом. Это мешает развиваться компилятору, так как невозможно легко и безопасно менять внутренние структуры и алгоритмы компиляции и мешает развиваться пользовательскому коду, так как при каждом новом релизе компилятора есть риск неработоспособности макросов. D>Плюс к этому, Nemerle является фактически "языком одного компилятора", так как любой конкурирующий компилятор вынужден будет в точности повторять внутренности нынешнего, иначе часть пользовательского кода работать не будет.
Делать API к текстовому редактору, означает создавать жесткую зависимость между структурами данных редактора и пользовательским кодом (макросами). Это мешает развиваться редактору, так как невозможно легко и безопасно менять внутренние структуры и алгоритмы обработки текста и мешает развиваться пользовательскому коду, так как при каждом новом релизе редактора есть риск неработоспособности макросов.
Плюс к этому, макросы MS Word является фактически "языком одного редактора", так как любой конкурирующий редактор вынужден будет в точности повторять внутренности нынешнего, иначе часть пользовательского кода работать не будет.
Аналогия ясна?
Это вопрос организации публичного интерфйса компилятора. Данная задача ничем не отличается от аналогичных для других приложений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
N>>Интеловские IPP ещё используем. С ними из под "родного" С++ работать также удобней. N>>Плюс всё это кроссплатформенно. VD>Это несомненно плюс. Жаль только с немалым трахом.
Я его, видимо, не заметил.
N>>P.S. Все продукты видеоанализа, которые я видел, написаны на С/С++. Многие из них также используют IPP и OpenCV. Это почти отраслевой стандарт. Тут задача — придумать нормальный алгоритм. Кодирование — ерунда. VD>Тут вопрос в том, что С/С++ на сегодня позволяет выжать максимум скорости. Но платой за то является весьма посредственная функциональность. Точнее сложность реализации на С++ сложного анализа. В задачах анализа очень удобно применять паттарн-матчинг и ДСЛ-и. И тут С++ не силен.
Мой субъективный опыт подсказывает, что мощные языки наиболее полезны на задачах автоматизации рутины. Для действительно сложных задач важнее именно библиотеки:
1. На примитивном языке Матлаба можно реализовывать несколькими строками достаточно сложные математические алгоритмы.
2. На С++ с помощью грамотного дизайна и перегрузки операторов можно реализовать удобные библиотеки и описывать решение математических задач практически нативным языком.
А вот даже простая задача парсинга xml на С++ в приглядном виде реализуется на зубодробительных шаблонах. Это для меня пример автоматизации рутинной задачи.
Re[3]: [Голосование] Почему я не использую Nemerle
V>>>Языкам с легкой организацией REP-loop вроде как IDE не особо нужна, в отличие от статически типизируемых с выводом типов.
FR>>Языки OCaml и Haskell очень жестко статически типизированы и с выводом типов, при этом у обоих вполне нормальный REPL.
V>Не знаю насчет OCaml, но у т.н. "интерпретатора" Haskell никакой он не нормальный. В окне непосредственного исполнения ты можешь использовать ограниченное подмножество языка. Все остальное надо оформлять в файл и вскармливать среде.
Аналогично с Эрлангом. Иногда раздражает, но не так критично
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>Это исключительно функционал шелла, причем не особо стандартизованный. MC>Зато удобная. И тот же питон тильды умеет разворачивать. MC>В общем объяснять отсутствие фичи тем, что это типа чужой и нестандартный функционал — несерьезно. Лучше уж честно признаться что лень/нет денег/...
Дело не в отсутствии денег (если бы все участники проекта занимались им за деньги, то не было бы даже того, что есть сейчас) и отнюдь не в лени. Это удобная фишка, согласен. Особенно если не ограничиваться разворачиванием тильды, а реализовать вообще весь zsh-like expansion в операциях с System.IO. И, кстати, в nemerle это можно реализовать максимально прозрачно для разработчика с минимальными изменениями исходного кода его проекта. Но тут проблема в другом: в расстановке приоритетов на фоне нехватки времени, которое получается выделять под работу над проектом. Поверь, лично мне, было бы гораздо интереснее засесть за реализацию разворачивания путей (особенно, на фоне того, что я сейчас активно осваиваю этот язык), чем закрывать воркарраундами глюки в медиавики, разворачивать платформу под новую версию сайта, переносить багтрекер, налаживать автосборку инсталлятора и т.п. Но добавить фишку, которой порадуются сейчас от силы 2-3 человека на мой взгляд не так важно, как довести до ума внешнее "облико морале" проекта и облегчить процесс интеграции изменений проекта, тестирования его новых версий и т.п. И я не думаю, что мой взгляд на это дело сильно отличается от взгляда остальных участников.
Если кому-либо действительно нужна эта фишка прямо сейчас, почему бы ему самому не заняться ее реализацией?
KV>>Если строчка могла прийти от юзера, то наличие там тильды — это малейшее из зол, которые необходимо ожидать и соответствующим образом обрабатывать. MC>Соответствующим — это каким? У нас же, блин, дотнет. Кроссплатформенная технология. Под линуксом мож я хочу тильду разворачивать, а под виндой — нет.
Ага, а вот ситуации, что юзер передаст путь содержащий всякие "../../../../", спец.имена в винде и т.п. почему-то разработчиков всегда волнуют меньше, чем вопросы по разворачиванию тильд
Здравствуйте, VladD2, Вы писали:
VD>Дык я сам бы не стал переписывать что-то уже работающее на другом языке. Другое дело новый проект (особенно если он небольшой) или какую-то более менее обособленную часть проекта (подпроект). Ведь длл созданная на Немерле может быть соврешенно не отличима от сишарпной или вбшной. Ну, а если это отдельное приложение, то вообще проблем нет. Опять же все наработки можно будет использовать через подключение библиотек.
Так вот тут и вся проблема, студенты его еще не знают, да и не скоро узнают, я что-то сделал, отдал, получил деньги, мне теперь всю жизнь это тащить? Поэтому заказчик (я в основном с японцами работаю) и требуют читабельный код на плюсах, но и соответсвенно платят "мне" что это уже весь код "их".
ЗЫ Еще почитал, ну некоторые решения очень красивые, мне они несколько недель работы стоили.
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Re[2]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Ларик, Вы писали:
Л>Почитал, на досуге, главный вопрос сколько человеко-часов мне потребуется на переход и что я получу в замен обычных плюсов? В своем опыте имею бэйсик, турбо си, паскаль, с++ сейчас. Я не хочу никого обидеть, просто вот не понял необходимости ЕЩЕ.
На Немерле очень удобно решать задачи со сложной логикой; при этом, код можно показывать людям знакомым с Шарпом после минимального введения.
Ce n'est que pour vous dire ce que je vous dis.
Re[8]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Что? Не понял...
Полез по примерам. Если реально(!) интересно могу потратить некоторое время чтобы дать реальные плюсы применения, проблема в том что я свой старый код не могу выкладывать, нужно будет порубать его.
Основная идея что заказчик принципиально не принимал шарп и многое я делал руками в плюсах. А здесь я увидел свежую волну, жалко что не видел этого 2-3 года назад. Кстати, а почему не сделаете что-то вроде сайта в формате codeproject, готовые решения без флуда, ну максимум обсуждение. Или я еще не нашел?
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Re[9]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD> AB>Так при выполнении make он и должен был собрать им или нет? VD> Дано, но немного более новой версии. Это так называемый бутстрапинг, когда компилятор собирается сам собой.
Отлично, но не собирается. Мня это огорчает не особо, т.к. я практически при любом раскладе не целевая аудитория, но если бы это был какой-нибудь GCC, то количество матов бы зашкалило — дьявол он в деталях всегда, а не в общей концепции.
Почитал доки (наконец-то вдумчиво), пощупал примеры... Да, возможно это клево, но у меня просто нет таких задач, где он бы был мне полезен. На моих рабочих "дробилках" он сольет по скорости, для каких-то мелких одноразовых вещей у меня в распоряжении bash/perl/ruby/python как данность, область GUI-ни целиком и полностью покрывается Qt/GTK. Впихивать же куда-то его насильно "for fun" не вижу смысла.
Здравствуйте, Ларик, Вы писали:
Л>Кстати, а почему не сделаете что-то вроде сайта в формате codeproject, готовые решения без флуда, ну максимум обсуждение. Или я еще не нашел?
А разделы "статьи" и "библоитеки" на рсдн.ру о чем?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Anton Batenev, Вы писали:
AB>Отлично, но не собирается.
Что и где не собирается?
AB>Почитал доки (наконец-то вдумчиво), пощупал примеры... Да, возможно это клево, но у меня просто нет таких задач, где он бы был мне полезен.
Это только так кажется по первой. Когда по пишешь на этом языке и потом приходится возвращаться к старым, то начинается конкретная ломка. Создается впечатление, что постоянно не хватает каких-то возможностей.
AB> На моих рабочих "дробилках" он сольет по скорости,
Ну, дотенет конечно не Интел Ц++, но тоже весьма производительная штука. А макры позволяют генерировать максимально эффективный для данной платформы код. Это конечно не просто, но возможно, в отличии от ручной реализации.
AB>для каких-то мелких одноразовых вещей у меня в распоряжении bash/perl/ruby/python как данность, область GUI-ни целиком и полностью покрывается Qt/GTK. Впихивать же куда-то его насильно "for fun" не вижу смысла.
Ну, никто не навязывается. Хотя тот же GTK впихивается не хуже. Да и при некотором опыте код по краткости не особо уступает скриптам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD> AB>Отлично, но не собирается. VD> Что и где не собирается?
Так я же выше писал про ошибку — выяснили, что баг моно и надо собирать под виндой и брать ее сборку. Т.е. make при сборке компилятора из транка завершается с ошибкой из за моно(?).
Здравствуйте, Anton Batenev, Вы писали:
AB>Так я же выше писал про ошибку — выяснили, что баг моно и надо собирать под виндой и брать ее сборку. Т.е. make при сборке компилятора из транка завершается с ошибкой из за моно(?).
Да. Под виндой собирать лучше через MSBuild. Для этого один из батников лежащих в корне нужно запустить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>А разделы "статьи" и "библоитеки" на рсдн.ру о чем?
Ну немного не поняли моей мысли, мне интересно не вопросы "как сделать это?", а примеры "как я сделал это". Живые, компилируемые, чтобы можно было реально посмотреть.
P.S. Мне реально интересно развитие, благо время сейчас куча, вот и мучаю Вас
Самая большая в мире ложь — "Я прочел и согласен с условиями пользовательского соглашения".
Re[12]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Ларик, Вы писали:
Л>Ну немного не поняли моей мысли, мне интересно не вопросы "как сделать это?", а примеры "как я сделал это". Живые, компилируемые, чтобы можно было реально посмотреть.
Дык в половине случаев так оно и есть.
Л>P.S. Мне реально интересно развитие, благо время сейчас куча, вот и мучаю Вас
Развитие чего? Себя? Ну, тогда попробуй освоить язык и написать какой-нить макрос. Время точно не пройдет даром. Гарантирую!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Голосование] Почему я не использую Nemerle
ANS>>Кстати, рефлексия хоть какая-то по макросам возможна? Или потребности и в такой колбасе нет?
S>Тут все в руках автора макроса: макрос может наследить в коде и понаставить меток для рантайм анализа.
найн. меня интересует этап выполнения макросов. то что в run-time можно использовать механизмы нижележащей платформы плюс рукописные "метки" и так понятно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>найн. меня интересует этап выполнения макросов. то что в run-time можно использовать механизмы нижележащей платформы плюс рукописные "метки" и так понятно.
К сожалению, в рантайме область использования макросов сильно ограничена возможностями платформы. Тут ни тип расширить, ни метод переписать.
Если принять эти ограничения, то можно написать макроатрибут, превращающий такие ограниченные макросы из компайлтайм макросов в рантайм макросы. Будет проблема с доступностью апи компилятора, но для райнтайма можно сэмулировать его ограниченное подмножество.
Здравствуйте, seregaa, Вы писали:
ANS>>найн. меня интересует этап выполнения макросов. то что в run-time можно использовать механизмы нижележащей платформы плюс рукописные "метки" и так понятно.
S>К сожалению, в рантайме область использования макросов сильно ограничена возможностями платформы. Тут ни тип расширить, ни метод переписать.
S>Если принять эти ограничения, то можно написать макроатрибут, превращающий такие ограниченные макросы из компайлтайм макросов в рантайм макросы. Будет проблема с доступностью апи компилятора, но для райнтайма можно сэмулировать его ограниченное подмножество.
Любая достаточно сложная программа /.../ содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
ANS>Любая достаточно сложная программа /.../ содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Кстати, а почему? Как на счет применения патерна "Интерпретатор"?
Потому что можно поспорить с определением реализации как "неспецифированой, глючной и медленной".
Кстати, о какой программе мы говорим? О компиляторе Немерле? Или о гипотетической программе, написанной на Немерле?
Если первый случай, то возможно что CL больше подошел бы на роль языка реализации компилятора (кстати, как у него обстоят дела с интеропом с .net?), но это было бы стратегически неправильно — писать компилятор на языке, отличном от компилируемого. Тем более никто не гооворит о том, что немерле — самый подходщий кандидат для этого. И тем более неправильно распространять "недостатки" компилятора немерле на саму идею языка и все программы, на нем написанные.
А если речь о гипотетической программе, то причем здесь интерпретатор?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Вывод я огласил — есть фатальный недостаток, который Влад продаёт как фатальное преимущество.
Этот "фатальный недостаток" обусловлен ограничениями платформы, а не "десятым правилом". Если тебе не нравится платформа, так и скажи, что на язык то наезжать ))
Здравствуйте, seregaa, Вы писали:
ANS>>Вывод я огласил — есть фатальный недостаток, который Влад продаёт как фатальное преимущество. S>Этот "фатальный недостаток" обусловлен ограничениями платформы
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, seregaa, Вы писали:
ANS>>>Вывод я огласил — есть фатальный недостаток, который Влад продаёт как фатальное преимущество. S>>Этот "фатальный недостаток" обусловлен ограничениями платформы
ANS>нет!
Здравствуйте, FR, Вы писали:
V>>Языкам с легкой организацией REP-loop вроде как IDE не особо нужна, в отличие от статически типизируемых с выводом типов. FR>Языки OCaml и Haskell очень жестко статически типизированы и с выводом типов, при этом у обоих вполне нормальный REPL.
Забыл более похожий на Nemerle Scala — он тоже статически типизированный с выводом типов, и та-дам! с REPL-ом.
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
FR>>Языки OCaml и Haskell очень жестко статически типизированы и с выводом типов, при этом у обоих вполне нормальный REPL. VD>... и IDE качества ниже плинтуса. Собственно популярность этих языков тоже не блещет. А возраст у них куда старше.
А вот для Scala есть IDE выше плинтуса — и Eclipse и IDEA его поддерживают, а я пишу в vim-е. Есть мнение, что потребность в IDE возникает у определенных коммьюнити. Т.е. дело не в языке. Могу предположить, что если народ повалит с Java на Haskell, то создаст замечательную IDE на базе Eclipse.
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>Не знаю насчет OCaml, но у т.н. "интерпретатора" Haskell никакой он не нормальный. В окне непосредственного исполнения ты можешь использовать ограниченное подмножество языка. Все остальное надо оформлять в файл и вскармливать среде.
В REPL можно запускать только выражения. Задавать, скажем, типы нельзя
Re[6]: [Голосование] Почему я не использую Nemerle
Здравствуйте, lomeo, Вы писали:
L>А вот для Scala есть IDE выше плинтуса — и Eclipse и IDEA его поддерживают, а я пишу в vim-е. Есть мнение, что потребность в IDE возникает у определенных коммьюнити. Т.е. дело не в языке. Могу предположить, что если народ повалит с Java на Haskell, то создаст замечательную IDE на базе Eclipse.
Возможно. Осталось дождаться этого счастливого момента.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Что касается Nemerle, то, как я уже когда-то упоминал, у него фатальный недостаток — вся его машинерия работает только в compile-time.
А как иначе в строго-статически-типизируемом языке? Ты хоть понял что сказал?
ANS>Кстати, рефлексия хоть какая-то по макросам возможна? Или потребности и в такой колбасе нет?
ЗАЧЕМ? Буде нужен скриптовый язык (а твои намеки исключительно в эту сторону, даже если ты сам этого не осознаешь) — бери себе и спокойно хости в своей программе тот же JScript (.Net), и делай в рантайме чего хошь.
Re[6]: [Голосование] Почему я не использую Nemerle
L>В REPL можно запускать только выражения. Задавать, скажем, типы нельзя
Именно что... Обобщенное программирование в repl — это сложновато в реализации, потому как плохо понятно, что делать с уже инстанциированными типами при изменении их шаблонов.
Re[7]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
L>>В REPL можно запускать только выражения. Задавать, скажем, типы нельзя
V>Именно что... Обобщенное программирование в repl — это сложновато в реализации, потому как плохо понятно, что делать с уже инстанциированными типами при изменении их шаблонов.
Инстанциированных типов в Haskell нет, это не С++. Шаблонов тоже нет по той же причине. Или ты что-то другое имеешь в виду? Поясни, пожалуйста. На шаблоны в С++ скорее похожи typeclasses, хотя по сути это сахар для тех же алгебраических типов.
Re[8]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>List — обычный обобщенный тип, шаблон в терминах С++, где a — тип-параметр.
Я давно не писал на С++. Поправь, если что не так. Для меня шаблон и инстанциирование шаблона — это скорее макрос и его применение, из которого рожаются типы. Недаром, шаблон в С++ должен подключаться исходником.
Тип "List a" в Haskell — не шаблон. Вот, например, у нас есть функция List a -> a -> a, которая возвращает, скажем, первый элемент списка или значение по умолчанию, представленное вторым параметром. В С++ да — нарожается куча функций. В Haskell — нет. Соответственно, говорить об инстанциировании нет смысла, так как его нет. А значит оно не может являться препятствием к заданию типов в GHCi.
В Haskell есть конкретизация типа (List Int), но она работает только в компайл-тайме, ничего не генерит, в отличие от инстанциирования шаблона, и нужна только для тайпчекера. Или ты думаешь, что для каждого конкретного использования генерится cвой объектный код?
Ну, или приведи пример, как можно чинить препятствия REPL-у в случае параметризованных типов. В Scala вон REPL есть, и параметризованные типы задавать там можно. И дальше посмотрим на что больше похож Haskell — на Scala или C++.
L>>На шаблоны в С++ скорее похожи typeclasses, хотя по сути это сахар для тех же алгебраических типов. V>Не в ту степь.
Единственное, что нашёл схожего с шаблонами. Могу и подробнее.
V>Неожиданно от хаскелиста такое "мягко говоря"... Ты бы представлением библиотек Хаскеля поинтересовался.
Что такое "представление библиотек Хаскеля"?
Re[10]: [Голосование] Почему я не использую Nemerle
Здравствуйте, lomeo, Вы писали:
V>>List — обычный обобщенный тип, шаблон в терминах С++, где a — тип-параметр.
L>Я давно не писал на С++. Поправь, если что не так. Для меня шаблон и инстанциирование шаблона — это скорее макрос и его применение, из которого рожаются типы. Недаром, шаблон в С++ должен подключаться исходником.
Я ведь сказал посмотреть в сторону библиотек Хаскеля — они представляют из себя предобработанный исходник, а не бинарник (сравни с либами того же дотнета).
L>Тип "List a" в Haskell — не шаблон. Вот, например, у нас есть функция List a -> a -> a, которая возвращает, скажем, первый элемент списка или значение по умолчанию, представленное вторым параметром. В С++ да — нарожается куча функций. В Haskell — нет. Соответственно, говорить об инстанциировании нет смысла, так как его нет. А значит оно не может являться препятствием к заданию типов в GHCi.
Мде... Вообще-то именно порождается функция для конкретного параметра a.
L>В Haskell есть конкретизация типа (List Int), но она работает только в компайл-тайме, ничего не генерит, в отличие от инстанциирования шаблона, и нужна только для тайпчекера.
Инстанциирование типов из шаблонов C++ тоже ничего не генерит, кроме случаев явного указания такой генерации. Код генерится в месте использования шаблона.
L>Или ты думаешь, что для каждого конкретного использования генерится cвой объектный код?
Конечно, а если он в какой-то реализации совпадает, то лишь по той же причине, почему генерится одинаковый код для генериков или почему шаблонный код в С++ для разных типов "схлопывается" в один и тот же, если бинарные представления типов совпадают. Просто хочу сказать, что переиспользование или генерение идентичного бинарного кода — это внутренности реализации/оптимизации, а ты, как программист, должен считать, что имеешь каждый раз с независимо порожденным кодом из шаблона/обощенного типа/генерика для каждой конкретной комбинации типов-параметров.
L>Ну, или приведи пример, как можно чинить препятствия REPL-у в случае параметризованных типов. В Scala вон REPL есть, и параметризованные типы задавать там можно. И дальше посмотрим на что больше похож Haskell — на Scala или C++.
Ну или покажи мне хоть один интерпретатор Хаскеля, где можно определять типы в REPL. Мало ли кто на что похож...
L>>>На шаблоны в С++ скорее похожи typeclasses, хотя по сути это сахар для тех же алгебраических типов. V>>Не в ту степь.
L>Единственное, что нашёл схожего с шаблонами. Могу и подробнее.
Это ближе к контрактам, что ортогонально обсуждаемому, хотя интересная фича сама по себе.
V>>Неожиданно от хаскелиста такое "мягко говоря"... Ты бы представлением библиотек Хаскеля поинтересовался.
L>Что такое "представление библиотек Хаскеля"?
Ну открой их каким-нить текстовым редактором да посмотри.
Re[11]: [Голосование] Почему я не использую Nemerle
L>>Ну, или приведи пример, как можно чинить препятствия REPL-у в случае параметризованных типов. В Scala вон REPL есть, и параметризованные типы задавать там можно. И дальше посмотрим на что больше похож Haskell — на Scala или C++.
V>Ну или покажи мне хоть один интерпретатор Хаскеля, где можно определять типы в REPL. Мало ли кто на что похож...
У OCaml конечно система типов послабее Хаскельной, но те же параметризованные типы присутствуют, при этом в REPL можно спокойно задавать типы, и в библиотеках не текст а байт или нативный код.
Re[11]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>Конечно, а если он в какой-то реализации совпадает, то лишь по той же причине, почему генерится одинаковый код для генериков или почему шаблонный код в С++ для разных типов "схлопывается" в один и тот же, если бинарные представления типов совпадают. Просто хочу сказать, что переиспользование или генерение идентичного бинарного кода — это внутренности реализации/оптимизации, а ты, как программист, должен считать, что имеешь каждый раз с независимо порожденным кодом из шаблона/обощенного типа/генерика для каждой конкретной комбинации типов-параметров.
Сколько вариантов бинарного кода порождается для такой функции (как должен считать я, как программист) ?
foo :: a -> b
foo x = foo [x]
Re[12]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mr.Cat, Вы писали:
MC>Зато удобная. И тот же питон тильды умеет разворачивать. MC>В общем объяснять отсутствие фичи тем, что это типа чужой и нестандартный функционал — несерьезно. Лучше уж честно признаться что лень/нет денег/...
Я, как обычно, перестарался и реализовал чуть больше, чем было надо. Поэтому оно не только разворачивает тильду, но и также имена спец.папок и переменные окружения:
C:\Users\VKochetkov\Documents\Visual Studio 2008\Projects\PathExpansion\PathExpander\bin\Debug\Nemerle.dll
C:\Users\VKochetkov\Links\desktop.lnk
C:\Program Files\Nemerle\docs
C:\Windows\System32\drivers\etc\hosts
C:\Temp\x86
C:\Users\VKochetkov\desktop.ini
Я хз, как оно будет работать под линуксом (подозреваю, что нужно допиливать, с учетом особенности реализации в Mono членов Environment), но сам макрос занял у меня от силы час, да и то, потому что только-только осваиваю язык
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я, как обычно, перестарался и реализовал чуть больше, чем было надо. Поэтому оно не только разворачивает тильду, но и также имена спец.папок и переменные окружения:
А зачем тут макрос?
ИМХО просто функции достаточно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>Я ведь сказал посмотреть в сторону библиотек Хаскеля — они представляют из себя предобработанный исходник, а не бинарник (сравни с либами того же дотнета).
У меня нет дотнета. Что ты понимаешь под библиотекой? hi-файл? Или объектник?
L>>Тип "List a" в Haskell — не шаблон. Вот, например, у нас есть функция List a -> a -> a, которая возвращает, скажем, первый элемент списка или значение по умолчанию, представленное вторым параметром. В С++ да — нарожается куча функций. В Haskell — нет. Соответственно, говорить об инстанциировании нет смысла, так как его нет. А значит оно не может являться препятствием к заданию типов в GHCi. V>Мде... Вообще-то именно порождается функция для конкретного параметра a.
С чего ты это взял? List имеет kind * -> *, т.е. принимает только боксовые значения, ну и сам является боксовым само собой. Размер у него всегда будет один. Зачем генерить, скажем, для map кучу реализаций, если достаточно одной?
L>>В Haskell есть конкретизация типа (List Int), но она работает только в компайл-тайме, ничего не генерит, в отличие от инстанциирования шаблона, и нужна только для тайпчекера. V>Инстанциирование типов из шаблонов C++ тоже ничего не генерит, кроме случаев явного указания такой генерации. Код генерится в месте использования шаблона.
По барабану. В Haskell при использовании map f [1,2,3] и map f "abc" не будет сгенерено двух новых функций. Оптимизатор, конечно, может это сделать, или мы с помощью SPECIALIZE, но это необязательная вещь (в ghci, о котором мы говорим, оптимизатор отключён).
L>>Или ты думаешь, что для каждого конкретного использования генерится cвой объектный код? V>Конечно, а если он в какой-то реализации совпадает, то лишь по той же причине, почему генерится одинаковый код для генериков или почему шаблонный код в С++ для разных типов "схлопывается" в один и тот же, если бинарные представления типов совпадают. Просто хочу сказать, что переиспользование или генерение идентичного бинарного кода — это внутренности реализации/оптимизации, а ты, как программист, должен считать, что имеешь каждый раз с независимо порожденным кодом из шаблона/обощенного типа/генерика для каждой конкретной комбинации типов-параметров.
Я как программист считаю, что каждый раз имею дело с одним и тем же кодом, пока я этого явно не укажу. Тем более, что до сих пор мне казалось, что так и есть на самом деле. Чем плох такой подход?
L>>Ну, или приведи пример, как можно чинить препятствия REPL-у в случае параметризованных типов. В Scala вон REPL есть, и параметризованные типы задавать там можно. И дальше посмотрим на что больше похож Haskell — на Scala или C++. V>Ну или покажи мне хоть один интерпретатор Хаскеля, где можно определять типы в REPL. Мало ли кто на что похож...
Да я кроме GHC ни с чем и не работаю. Так что кроме Hugs больше сказать ничего не могу, да и не уверен, что есть. Однако я не вижу причин, почему это сделать невозможно. В любом случае отсутствие никак не подтверждает твоего утверждения о наличии шаблонов в Haskell.
V>>>Неожиданно от хаскелиста такое "мягко говоря"... Ты бы представлением библиотек Хаскеля поинтересовался. L>>Что такое "представление библиотек Хаскеля"? V>Ну открой их каким-нить текстовым редактором да посмотри.
Кого их? Ты про hi? Или про объектники? Открыл все, ничего полезного не увидел. Ткни пальцем, зачем загадками говоришь
На всякий случай — unboxed values нельзя использовать как применение полиморфного типа в функциях. Это чтобы разговор в сторону не уходил
Re[13]: [Голосование] Почему я не использую Nemerle
Небольшой совет. Генерировать исключения из макросов — это плохой подход.
Вмест этого нужно использовать методы Message.Error() или Message.FatalError().
Последний генерирует специальное исключение перехватываемое в коде раскрытия макроса.
Message.FatalError можно применять так же как ислючение в твоем коде.
Ну, и вообще не стоит нигде и никогда генерировать исключение типа Exception. Это верный путь к проблемам.
KV>[c#] KV> <[ KV> def getEnvironmentVariable(name) {Environment.GetEnvironmentVariable(name) ?? throw Exception($"Environment variable $name is not defined")} KV>[/code]
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: [Голосование] Почему я не использую Nemerle
Здравствуйте, nikov, Вы писали:
N>Сколько вариантов бинарного кода порождается для такой функции (как должен считать я, как программист) ? N>
N>foo :: a -> b
N>foo x = foo [x]
N>
Можно представить реализацию, где будет порождено столько вариантов, сколько есть разных типов в вызовах этой функции. Я так делал в одном своем компиляторе.
Re[12]: [Голосование] Почему я не использую Nemerle
ANS>Любая достаточно сложная программа /.../ содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Вывод компилятор Common Lisp и любая достаточно сложная программа написанная на Common Lisp — это неспецифицированная, глючная и медленная реализация половины языка Common Lisp.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [Голосование] Почему я не использую Nemerle
Здравствуйте, lomeo, Вы писали:
V>>Ответ на твой вопрос, как и на мой, зависит исключительно от реализации, т.е. никого не интересует.
L>?!?! А я думал мы говорим конкретно о GHCi.
Даже в нем, в режиме оптимизации, насколько я знаю, он порождает отдельные реализации ф-ий для нерекурсивных типов, т.е. типов-аналогов value-type из дотнета. Понятное дело, что все указатели совместимы по размеру, поэтому физически для боксированных типов может и быть одна реализация. Тоже самое происходит и в С++ при компиляции шаблонов (бинарно-эквивалентные реализации "схлопываются" в одну в процессе оптимизации), но, повторюсь, это подробности реализации и оптимизации бинарного представления. Ты же каждый раз должен считать, что работаешь с конкретно порожденной для данного набора типов-параметров реализацией, особенно при наличии явной специализации обобщенных ф-ий (как и в С++).
Re[14]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
VD>Небольшой совет. Генерировать исключения из макросов — это плохой подход.
Дык там же из макроса генерится не исключение, а код, кидающий исключение в рантайме?
VD>Вмест этого нужно использовать методы Message.Error() или Message.FatalError(). VD>Последний генерирует специальное исключение перехватываемое в коде раскрытия макроса. VD>Message.FatalError можно применять так же как ислючение в твоем коде. VD>Ну, и вообще не стоит нигде и никогда генерировать исключение типа Exception. Это верный путь к проблемам.
Здравствуйте, vdimas, Вы писали:
V>Ты же каждый раз должен считать, что работаешь с конкретно порожденной для данного набора типов-параметров реализацией, особенно при наличии явной специализации обобщенных ф-ий (как и в С++).
Ты так и не ответил, почему я должен так считать
И насчёт "представления библиотек Haskell" — пни меня в нужном направлении, я честно не нашёл там то, о чём ты говоришь.
Re[15]: [Голосование] Почему я не использую Nemerle
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Дык там же из макроса генерится не исключение, а код, кидающий исключение в рантайме?
А, тогда не понял. Приношу свои извенения.
KV>Угу Поленился свой класс исключения сделать
Ну, хотя бы тогда какой-нить АпликэшонЭксцешон, что ли... А то ведь вообще отловить нельзя будет. Да и объявление класса — это же две строки если с использованием атрибута Recor.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Lazin, Вы писали:
L>>потому-что я использую F#
VD>Уважаемый, для этого есть пунк в голосовании. Не нужно засорять форум бессмысленными сообщениями.
Могу ответить и по существу. Самое слабое место, на мой взгляд — вовсе не в фичах языка и не в реализации, а в том, что убедить начальство в разумности этого шага — крайне сложно
В случае F# — все просто, есть примеры использования, положительные отзывы, известный вендор, литература. Это все отличные аргументы для не программистов. Nemerle, на данный момент, этим не может похвастаться. Все остальное, по сути — мелочи.
Re[4]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
L>>В случае F# — все просто, есть примеры использования, положительные отзывы, известный вендор, литература.
VD>Что за примеры?
Здравствуйте, minorlogic, Вы писали:
M>С целью сбора информации прошу ответить на вопрос:
M>Почему я боюсь/не хочу/не могу использовать косметику Mary Key в своей работе?
Mary Kay — польская кустарщина. Я пользую только C#vergirl.
Re[6]: [Голосование] Почему я не использую Nemerle
Здравствуйте, nikov, Вы писали:
L>>>В случае F# — все просто, есть примеры использования, положительные отзывы, известный вендор, литература.
VD>>Что за примеры?
N>Здесь, раздел Industrial applications
На примеры использования тянет очень плохо. Книги, три библиотеки (вообще не ясно зачем было их под F# затачивать?). "Investment banks such as Morgan Stanley, Credit Suisse and UBS already employ hundreds of F# programmers who build in-house software." — просто прогон какой-то.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>>>Что за примеры?
N>>Здесь, раздел Industrial applications
VD>На примеры использования тянет очень плохо. Книги, три библиотеки (вообще не ясно зачем было их под F# затачивать?). "Investment banks such as Morgan Stanley, Credit Suisse and UBS already employ hundreds of F# programmers who build in-house software." — просто прогон какой-то.
Вот буквально сейчас мне прислали предложение работы в каком-то инвестиционном банке в Лондоне на позиции Senior F# Developer.
Здравствуйте, nikov, Вы писали:
N>Вот буквально сейчас мне прислали предложение работы в каком-то инвестиционном банке в Лондоне на позиции Senior F# Developer.
И какая связь с имеющимися продуктами?
Продуктах на F# и на Nemerle написано примерно одинаковое количество. Чуть больше нуля. Но кончено после такого промоушена от МС найти работу на F# будет намного проще. И это при том, что писать программы проще как раз на Nemerle.
В общем, это еще раз подверждает что бабвло всегда побиждает бабро.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Продуктах на F# и на Nemerle написано примерно одинаковое количество. Чуть больше нуля. Но кончено после такого промоушена от МС найти работу на F# будет намного проще. И это при том, что писать программы проще как раз на Nemerle.
VD>В общем, это еще раз подверждает что бабвло всегда побиждает бабро.
Эххх. Не угадал Немерл с целевой аудиторией. .NET-чики не любят синтаксис изобретать. Им подавай сертифицированный МСом стандарт. Надо было с С++ дружить. Там и потребность есть, и опыт кастомизации синтаксиса через шаблоны и перегрузку опреаторов, и сообщество более к опенсорсу привычное, не так боятся что "не стоит серьезной организации".
Вот не так давно обсуждали: A как насчет LINQ?
Здравствуйте, Mazay, Вы писали:
M>Эххх. Не угадал Немерл с целевой аудиторией. .NET-чики не любят синтаксис изобретать. Им подавай сертифицированный МСом стандарт. Надо было с С++ дружить. Там и потребность есть, и опыт кастомизации синтаксиса через шаблоны и перегрузку опреаторов, и сообщество более к опенсорсу привычное, не так боятся что "не стоит серьезной организации".
Согласен, только с одной оговоркой. Не к С++, а к Ява-сообществу... скорее.
M>Вот не так давно обсуждали: A как насчет LINQ?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mazay, Вы писали:
M>>Эххх. Не угадал Немерл с целевой аудиторией. .NET-чики не любят синтаксис изобретать. Им подавай сертифицированный МСом стандарт. Надо было с С++ дружить. Там и потребность есть, и опыт кастомизации синтаксиса через шаблоны и перегрузку опреаторов, и сообщество более к опенсорсу привычное, не так боятся что "не стоит серьезной организации".
VD>Согласен, только с одной оговоркой. Не к С++, а к Ява-сообществу... скорее.
Ява — это только привычка к опенсорсу. Традиции кастомизации синтаксиса там нет, опять же захотят "серьёзную организацию" и потребность там не столь острая как в плюсах. И вообще, как мне кажется, Ява сообщество более инертное — индусам же нельзя такие мощные инструменты давать.
С++ имеет кучу проблем, но поскольку это лучшее что сегодня есть для программирования нативного кода, все колятся, но продложают жрать. ИМХО если откатиться к C как к базовому языку и сделать все высокоуровневые фичи как макросы Немерла, то это будет вполне человеческим решением. Или, как я уже говорил, сделать компилятор в LLVM.
M>>Вот не так давно обсуждали: A как насчет LINQ?
. Ты же вроде говоил, что весь LINQ можно реализовать на макросах Немерла?
VD>Дык он давно реализован. Причем в виде тех самых макросов: VD>http://nemerle.googlecode.com/svn/nemerle/trunk/Linq
Ну вот в дотнете он уже не нужен (в смысле уже есть), а в плюсах бы пригодился.
Главное гармония ...
Re[12]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Ява — это только привычка к опенсорсу.
Не. Ява — это неплохой рантайм и никуда не годный (убогий) язык. Причем язык с весьма близкой системой типов и рантаймом. Этот набор качеств создает и среду и аудиторию.
С++ же он совсем другой. Да и реализоовать язык типа немерла без виртуальной машины во много раз сложнее. Ведь нужен GC, работа с метаданными сборок, рефлексия, библиотеки и т.п. В общем, объем работы увеличивается в разы. А сил и так мало.
M>Традиции кастомизации синтаксиса там нет, опять же захотят "серьёзную организацию" и потребность там не столь острая как в плюсах.
Ну, синтаксис то в С++ изменить тоже нельзя. Скорее можно вести речь о семантике.
Тут да, С++ с метапрограммироанием на шаблонах кое что позволяет сделать.
Дык ява-программистам это тоже нужно! У них этого нет совершенно. Что делате значимость фичи еще большей.
M> И вообще, как мне кажется, Ява сообщество более инертное — индусам же нельзя такие мощные инструменты давать.
Как скзать. Большинство новых дотнета технологий пришло из явы. Гибернэйт, Спринг и т.п. Опен-сорс в ява-комьюнити развит очень сильно. И от части многие открытые проекты (как и в случае С++) решают проблемы которые создает язык.
M>С++ имеет кучу проблем, но поскольку это лучшее что сегодня есть для программирования нативного кода, все колятся, но продложают жрать.
На счет "лучшего" я бы сильно поспорил. Я считаю ОКамл и Ди более мощьными языками. Просто инертность мышления и привязанность к разрекламмированным технологиям, плюс поддержка больших фирм делают свое дело. Но эта же проблема есть и в дотнете.
M>ИМХО если откатиться к C как к базовому языку и сделать все высокоуровневые фичи как макросы Немерла, то это будет вполне человеческим решением. Или, как я уже говорил, сделать компилятор в LLVM.
С — никудышная основа для языка вроде немерл. Немерл типобезопасный высокоуровневый язык с семантикой которая позволяет писать код близкий к С по скорости. Ему С будет как костыль. Собственно проблемы С++ вызваны в основном наследием С и отказом от некоторых фич Симулы (например, сборщика мусора). Это конено обепечило ему приемственность, низкоуровневость и скорость кода, но при этом стало диким тормозом в развитии.
Гы. Он и реализован на базе дотнета. Если бы в дотнете не было его реализации. Или если хотя бы не было реализации провайдеров, то объем работы увеличился бы многократно.
Надо же понимать, что фрэймворк это не только джит-компилятор и сборщик мусора. Это еще куча кода и утилит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
M>>Ява — это только привычка к опенсорсу.
VD>Не. Ява — это неплохой рантайм и никуда не годный (убогий) язык. Причем язык с весьма близкой системой типов и рантаймом. Этот набор качеств создает и среду и аудиторию.
VD>С++ же он совсем другой. Да и реализоовать язык типа немерла без виртуальной машины во много раз сложнее. Ведь нужен GC, работа с метаданными сборок, рефлексия, библиотеки и т.п. В общем, объем работы увеличивается в разы. А сил и так мало.
Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё.
M>>Традиции кастомизации синтаксиса там нет, опять же захотят "серьёзную организацию" и потребность там не столь острая как в плюсах.
VD>Ну, синтаксис то в С++ изменить тоже нельзя. Скорее можно вести речь о семантике. VD>Тут да, С++ с метапрограммироанием на шаблонах кое что позволяет сделать. VD>Дык ява-программистам это тоже нужно! У них этого нет совершенно. Что делате значимость фичи еще большей.
M>> И вообще, как мне кажется, Ява сообщество более инертное — индусам же нельзя такие мощные инструменты давать.
VD>Как скзать. Большинство новых дотнета технологий пришло из явы. Гибернэйт, Спринг и т.п. Опен-сорс в ява-комьюнити развит очень сильно. И от части многие открытые проекты (как и в случае С++) решают проблемы которые создает язык.
Ну да. Гибернейт и Спринг — это когда сто тыщь мильёнов велосипедов написали, тогда софтверные компании наконец разродились чем-то более-менее стандартным.
M>>С++ имеет кучу проблем, но поскольку это лучшее что сегодня есть для программирования нативного кода, все колятся, но продложают жрать.
VD>На счет "лучшего" я бы сильно поспорил. Я считаю ОКамл и Ди более мощьными языками. Просто инертность мышления и привязанность к разрекламмированным технологиям, плюс поддержка больших фирм делают свое дело. Но эта же проблема есть и в дотнете.
Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода).
M>>ИМХО если откатиться к C как к базовому языку и сделать все высокоуровневые фичи как макросы Немерла, то это будет вполне человеческим решением. Или, как я уже говорил, сделать компилятор в LLVM.
VD>С — никудышная основа для языка вроде немерл. Немерл типобезопасный высокоуровневый язык с семантикой которая позволяет писать код близкий к С по скорости. Ему С будет как костыль. Собственно проблемы С++ вызваны в основном наследием С и отказом от некоторых фич Симулы (например, сборщика мусора). Это конено обепечило ему приемственность, низкоуровневость и скорость кода, но при этом стало диким тормозом в развитии.
Это всё понятно. Просто есть некоторый спектр задач, где сборщик мусора как-то не очень важен (мне например умных указателей за глаза хватает, им бы ещё синтаксис человеческий), зато важен прямой доступ к памяти, скорость кода, портабельность. В Си с типобезопасностью и контролем памяти как-нибудь разобраться можно, требуется лишь средство расширения синтаксиса.
Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет. Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз.
Главное гармония ...
Re[13]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
VD>С++ же он совсем другой. Да и реализоовать язык типа немерла без виртуальной машины во много раз сложнее. Ведь нужен GC, работа с метаданными сборок, рефлексия, библиотеки и т.п. В общем, объем работы увеличивается в разы. А сил и так мало.
Я, конечно плохо представляю кишки Немерла, но разве нельзя сначала реализовать чисто систему макросов без привязки к GC, метаданным, рефлексии и тем более библиотекам?
Главное гармония ...
Re[14]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё.
А зачем тебе нативность?
Нативность и производительность понятия не связанные.
M>Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода).
А зачем тебе прямой доступ к памяти вообще и shared memory multithreading в частности?
M>Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет. Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз.
Аааааа!!!!!!!!! Шареная память в распределенной системе
Прощай защита от сбоев. А если учесть что в больших кластерах компы мрут довольно часто то как в таком состоянии вообще что-то посчитать можно?
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: [Голосование] Почему я не использую Nemerle
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Mazay, Вы писали:
M>>Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё. WH>А зачем тебе нативность? WH>Нативность и производительность понятия не связанные.
Это в теории. А на практике — посмотри в шутаут. Кроме того, виртуальные машины есть не везде.
M>>Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода). WH>А зачем тебе прямой доступ к памяти вообще и shared memory multithreading в частности?
Для производительности. Пока компиляторы много чего не умеют делать. Вон remark в форумах по С++ много интересного на эту тему пишет. И Интел делает ставку именно на многоядерность и разделяемую память (глянь на tbb library — она вся на общей памяти основана). И для видеокарт не очень ясно как должна выглядеть managed память, ибо память там важна ещё больше чем в CPU. Короче это не мой каприз, а объективная потребность.
M>>Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет. Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз. WH>Аааааа!!!!!!!!! Шареная память в распределенной системе WH>Прощай защита от сбоев. А если учесть что в больших кластерах компы мрут довольно часто то как в таком состоянии вообще что-то посчитать можно?
Ничего не мрут (если это не Beowulf из списаных персоналок). Нормально считается. Кластер это всё-таки не облако.
Главное гармония ...
Re[14]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё.
А что за расчеты?
M>Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода).
Ты ничего не путаешь. Как минимум Ди весьма шустрый код порождает. Про многопоточность у ОКамла не скажу, но тоже звучит странно. Язык весьма императивный. С нэйтив-интерфейсом сишным. Не думаю, что там очень уж сложно сделать то что нужно. Хотя сама идея разделять память в многозадачности весьма спорная. Грабель можно лбом собрать тысячи...
M>Это всё понятно. Просто есть некоторый спектр задач, где сборщик мусора как-то не очень важен (мне например умных указателей за глаза хватает, им бы ещё синтаксис человеческий),
Это так только кажется. Даже сама необходимость возиться с умными указателями уже отнимает часть потенциала твоего мозга.
M>зато важен прямой доступ к памяти, скорость кода, портабельность.
Тогда Ди мог бы тебе подойти. Там как раз совещены многие вкусности из типобезопасных языков и прямой доступ в стиле С, если это нужно.
Может и окалм подойдет.
Поять же всегда можно действительно требовательные куски и на С реализовать, а объемную логику на более высокоуровневом язке.
M> В Си с типобезопасностью и контролем памяти как-нибудь разобраться можно, требуется лишь средство расширения синтаксиса.
Тут одно за другое цепляется. Чтобы получить такие средства расширения синтаксиса как в немреле желательно иметь в языке на котором это все пишется фичи которые без того же ЖЦ реализовать будет не так то просто.
Собственно как вариант можно предложить кроскомпиляцию. Когда вместо того чтобы писать на одном языке все, писать макросы на Немерле или Лиспе, а уже по ним генерировать код на С. Но это потребует создания некоторой инфраструктуры.
M>Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет.
Ну, почему нет? Есть. Просто они видимо выходят за твое кругозор. В том же четвертом фрэймворке добавили качественных костылей в виде задач (Task) и PLink-а.
В F#, Хаскеле и Nemerle (в последнем реализовано на макросах) есть Async который позволяет оперировать кодом как объектом. Например, останавливать вычисления в одном потоке и возобновлять в другом.
Кроме того есть иделогия акторов. Не для всех случаев жизни подходит (так как общение происходит только через посылку сообщений), но в некоторых вариантах использования очень рулит.
M> Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз.
А что за синтаксическая поддержка там нужна?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Mazay, Вы писали:
M>Я, конечно плохо представляю кишки Немерла, но разве нельзя сначала реализовать чисто систему макросов без привязки к GC, метаданным, рефлексии и тем более библиотекам?
Она на нем самом и написана.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: [Голосование] Почему я не использую Nemerle
VD>Ты ничего не путаешь. Как минимум Ди весьма шустрый код порождает. Про многопоточность у ОКамла не скажу, но тоже звучит странно. Язык весьма императивный. С нэйтив-интерфейсом сишным. Не думаю, что там очень уж сложно сделать то что нужно. Хотя сама идея разделять память в многозадачности весьма спорная. Грабель можно лбом собрать тысячи...
У D такая проблема у базового компилятора backend построен на базе digital mars C++ который по оптимизации чуть лучше bcc,
то есть слабоват (обогнать на том же окамле часто без проблем). Был компилятор gdc http://dgcc.sourceforge.net/ на базе
gcc, и первого D, но он заглох, вот он да очень часто обгонял g++ на одинаковых задачах, за счет того что у D front end лучше
и более агрессивно выносит все что можно в conpile time. Но перед смертью gdc все завещал внуку, то есть LLVM D Compiler http://www.dsource.org/projects/ldc пока он совсем сырой, но по шустрости не уступает gdc. В общем все непросто
У OCaml'а с многопоточностью такая же любовь как у питона и руби, то есть аналог GIL. Правда в отличии от интерпретаторов
это вполне можно развязать, но пока авторы не торопятся. Но в тех же кластерах использовать это не мешает, библиотеки
для межпроцессного взаимодействия есть.
Re[15]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
M>>Это да. Я просто со свое колокольни смотрю. Мне нужен нативный, производительный язык. У меня рассчёты сутками на кластере молотятся и по идее надо ещё.
VD>А что за расчеты?
Молекулярное моделирование.
M>>Конечно мощные. Никто и не спорит. Просто есть ряд фатальных недостатоков. У OCaml-а — упёртное нежелание признавать shared memory multithreading и вообще давать прямое управление памятью. У D — плохой компилятор (в смысле низкая производительность кода).
VD>Ты ничего не путаешь. Как минимум Ди весьма шустрый код порождает. Про многопоточность у ОКамла не скажу, но тоже звучит странно. Язык весьма императивный. С нэйтив-интерфейсом сишным. Не думаю, что там очень уж сложно сделать то что нужно. Хотя сама идея разделять память в многозадачности весьма спорная. Грабель можно лбом собрать тысячи...
FR уже описал ситуацию с D и c OCaml. Только про OCaml следует подчеркнуть, что узлы в кластерах тоже имеют несколько ядер с общей памятью, а OCaml не даёт возможности воспользоваться этой общностью в корыстных целях. Про грабли разговор отдельный.
M>>Это всё понятно. Просто есть некоторый спектр задач, где сборщик мусора как-то не очень важен (мне например умных указателей за глаза хватает, им бы ещё синтаксис человеческий),
VD>Это так только кажется. Даже сама необходимость возиться с умными указателями уже отнимает часть потенциала твоего мозга.
Ээээ. Что значит возиться? Больше текста писать при объявлении и инициализации? Сравни:
int *pi;
pi = new int(123);
int *pi(new int(321));
...
delete pi;
delete pj;
Действительно, синтаксис громоздок. Потому я и хочу макросы Немерла, что бы можно было написать например вот так:
int ^pi;
pi = snew int(123);
int ^pi(snew int(321));
...
С нормальным ситаксисом всё будет легко и просто.
VD>Поять же всегда можно действительно требовательные куски и на С реализовать, а объемную логику на более высокоуровневом язке.
Проблема в том, что даже в не слишком большой программе не всегда очевидно какой кусок окажется самым дорогим. В ходе модификации программы, изменения требований и даже значений входных параметров картинка в профайлере может сильно меняться. Со временем скатываешься к тому, что больше усилий тратишь на борьбу с глюками интеропа.
M>> В Си с типобезопасностью и контролем памяти как-нибудь разобраться можно, требуется лишь средство расширения синтаксиса.
VD>Тут одно за другое цепляется. Чтобы получить такие средства расширения синтаксиса как в немреле желательно иметь в языке на котором это все пишется фичи которые без того же ЖЦ реализовать будет не так то просто.
VD>Собственно как вариант можно предложить кроскомпиляцию. Когда вместо того чтобы писать на одном языке все, писать макросы на Немерле или Лиспе, а уже по ним генерировать код на С. Но это потребует создания некоторой инфраструктуры.
Угу.
M>>Вот кстати о кластерах. Все говорят, что MPI — это ассемблер, и нужно что-то высокоуровневое, но красивых решений до сих пор нет.
VD>Ну, почему нет? Есть. Просто они видимо выходят за твое кругозор. В том же четвертом фрэймворке добавили качественных костылей в виде задач (Task) и PLink-а.
Не видел. Это именно над MPI обертки?
VD>В F#, Хаскеле и Nemerle (в последнем реализовано на макросах) есть Async который позволяет оперировать кодом как объектом. Например, останавливать вычисления в одном потоке и возобновлять в другом.
Да это и так не проблема.
VD>Кроме того есть иделогия акторов. Не для всех случаев жизни подходит (так как общение происходит только через посылку сообщений), но в некоторых вариантах использования очень рулит.
Идеология это конечно хорошо, но чего-нить более материального хочется. В смысле языковой поддержки, желательно не отдельным языком а расширением C++.
Всё это похоже на симптоматическое лечение — лишь оттягивает проблемы.
M>> Например есть такая фича как запись/чтение в/из памяти соседнего узла в кластере, сейчас это делается через вызов библиотечной функции, что нифига не удобно. Лучшее что есть (АФАИК) это библиотека Shmem, но всё равно это лишь библиотека. ИМХО синтаксическая поддержка была бы тут в самый раз.
VD>А что за синтаксическая поддержка там нужна?
Вот такое апи есть в SHMEM ():
void shmem_double_p(double *addr, double value, int pe)
addr The remotely accessible array element or scalar data object which
will receive the data on the remote PE.
value The value to be transferred to addr on the remote PE.
pe The number of the remote PE where value will be transferred.
These routines provide a very low latency remote write capability for single elements
of most basic types.
Это же жесть. Чтобы просто записать один double мне нужно звать функцию. Хочу как-то так:
pe_x.data.x = 3.14; //pe_x - PE, что-то вроде прокси к удалённому процессу, data - удалённая структура, объявленная выше.
И чтоб компилятор побольше багов отлавливал.
Главное гармония ...
Re[2]: [Голосование] Почему я не использую Nemerle
T>Ребята, продумайте лучше грамотный PR, распишите чем он лучше других, какие его плюсы, какая его ниша.
У них было достаточно времени, чтобы это придумать. Но результатов нет. Нет ниши, и никто на нём не программирует, только вопят, что это самый лучший язык.
Опрос не понравился — подбор ответов странный, не содержит вариантов, с которыми я бы согласился, и многие ответы явно глупые. Получается, что Nemerle не используют по глупости, но это всего лишь эффект от подбора вариантов ответа. Это всё равно, что опрос: "Почему вы не ходите на гей-парад" с вариантами ответа:
1 Я не люблю веселье
2 Боюсь, что будет плохая погода
Правильный ответ (среди вариантов отсутствует) — у нормального человека не может возникнуть желание пойти на гей-парад, и он не должен это никак объяснять. Вот и Nemerle нормальный человек не станет использовать, и по той же причине (ИМХО).
Бросили бы эти немерлисты заниматься фигнёй — она только отвлекает от изучения нужных для работы тем в программировании.
Re[3]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Partisan, Вы писали:
P>Опрос не понравился — подбор ответов странный, не содержит вариантов, с которыми я бы согласился, и многие ответы явно глупые.
Тебе конечно виднее. Но эти ответы добавляли сами голосующие.
Кстити, подсказка... ты тоже можешь свой вариант добавить.
P>Получается, что Nemerle не используют по глупости,
О, как?
P>но это всего лишь эффект от подбора вариантов ответа. Это всё равно, что опрос: "Почему вы не ходите на гей-парад" с вариантами ответа: P>1 Я не люблю веселье P>2 Боюсь, что будет плохая погода P>Правильный ответ (среди вариантов отсутствует) — у нормального человека не может возникнуть желание пойти на гей-парад, и он не должен это никак объяснять. Вот и Nemerle нормальный человек не станет использовать, и по той же причине (ИМХО).
Ну, так кто мешал добавить свой ответ, то?
P>Бросили бы эти немерлисты заниматься фигнёй — она только отвлекает от изучения нужных для работы тем в программировании.
Да кто тебе мешает то? Проходи мимо и изучай что хочешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Голосование] Почему я не использую Nemerle
Ну, геями немерлистов называло достаточно много людей, но раньше это было завуалированно через публичное объявление себя д'Артаньяном. Но чтобы вот так открыто... Поздравляю, вы первый... Месье
P>Бросили бы эти немерлисты заниматься фигнёй — она только отвлекает от изучения нужных для работы тем в программировании.
А вот это просто убило. Позвольте я продолжу логическую цепочку: "раз отвлекает от изучения нужных тем, значит препятствует профессиональному росту. Раз препятствует профессиональному росту, значит уменьшает стоимость специалиста на рынке труда. Раз уменьшает стоимость, значит повышения зарплаты ему не видать... ГРАЖДАНЕ!!! Из-за этих клятых немерлистов мне зарплату не повышают!!!"
Здравствуйте, Mazay, Вы писали:
M>FR уже описал ситуацию с D и c OCaml. Только про OCaml следует подчеркнуть, что узлы в кластерах тоже имеют несколько ядер с общей памятью, а OCaml не даёт возможности воспользоваться этой общностью в корыстных целях. Про грабли разговор отдельный.
Ну процесс на ядро плюс mmf, в общем решаемо, но придется напильничком поработать