NN>без условно самый главный недостаток nemerle это .Net

дык бери Scala. он и с типами работает получше в плане автоприведений.

NN>все было бы проще если бы многие фичи вывода типов присутствовали не на уровне языков, а на уровне CIL
NN>конкретизация типов должна присутствовать где то на уровне JIT, а на уровне компиляторов языков должен присутствовать вывод типов который выводит наиболее общий тип

вывод типов в F# есть, и в С# тоже зачатки. так что они решают на уровне компилятора. до JIT. это норм. решение. согласующееся с общей идеологий .Net.

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

_C_>вывод типов в F# есть, и в С# тоже зачатки. так что они решают на уровне компилятора. до JIT. это норм. решение. согласующееся с общей идеологий .Net.
Эм — насколько я понял, в F# — совершенно тупые ограничения, ограниченные исключительно ленью разработчиков, нет?

PS: не помню, как-то пытался какую-то приблуду поднять на F#, чего-то ей не хватало, что-то вроде F#Tools, на подобии T4Toolbox — только нифига не было написано — но далеко не сразу понял в чём беда. А, ну и традиционно с моей русской локалью не дружило, хотя венда и язык разумеется инглиш. Это не траблы языка — просто столкнулся нинароком. Это низа ни в пользу — однако, не видел программ на C# требующих тулбоксов... Пруфлинк не дам, извиняюсь сразу. Скорее пишу эмоции.

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

Ох, "Это низа ни в пользу — однако" -> "Это ниразу не в минус языку".

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

F>а с другой стороны, а что в C++? — ставить пробел перед закрывающей скобкой — обязаловка ныне — смешно же!
эм... у тебя какие то древние сведения

по всему остальному я пришел к nemerle поглядев erlan, но пришел не как к промышленному языку,
а как к языку на котором можно реализовать другой язык программирования,
потому что erlang имеет один "фатальный недостаток" динамическую типизацию + кучу проблем by design,
конечно все эти проблемы меркнут перед его плюсами, но его плюсы не в языке, а в платформе, и по этому без условно для меня
самый главный недостаток nemerle .net, все остальное это уже конечно придирки и пожелания не более,
я не говорю что из-за каких либо приведенных мной недостатков кому то надо отказаться от nemerle и использовать что либо другое

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

erlang — отличная платформа, для тех кто его понимает, хочет использовать и знает как использовать. У нас на Украине есть один банк который вроде как его использует — отклик банкоматов при этом просто отвратительный. Эм. Не факт что там вообще эрли учавствует. Просто к слову, пришлось.
Я вот в последнее время всё больше озадачиваюсь созданием кластера на .NET. Да, пусть это 5 разношерстных WCF сервисов, но это единый комплекс, и для одного из них идеальный вариант "обходить" вызовы сервиса и общаться с оборудованием напрямую, если это происходит на одной машине. Технически — вообще проблем нет. Но и фреймворков готовых предоставить минимальную инфраструктуру — тоже нет. Azure — это в принципе другие, и не подходит, и близко не имеет того что необходимо, увы. Решения судя по гуглу где-то лишь смежные есть, но за немалое бабло, и не факт что оно вообще подходит.
Это я всё к тому — что, всё всегда в наших руках. Erlang — платформа, не только язык, — но сказать, что она универсальна — разумеется тоже никак нельзя.

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

F>>а с другой стороны, а что в C++? — ставить пробел перед закрывающей скобкой — обязаловка ныне — смешно же!
NN>эм... у тебя какие то древние сведения
Да ну? Древние это как? Есть реалии. C++11 — по факту, никем ещё не поддерживается, ближе всех gcc и clang, как я понимаю.
А вот написание — return Singleton<BuildInfo, LeakySingletonTraits<BuildInfo> >::get(); — суровая правда жизни.

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

_C_>вывод типов в F# есть, и в С# тоже зачатки. так что они решают на уровне компилятора. до JIT. это норм. решение. согласующееся с общей идеологий .Net.

F# сдулся,

open System

let foo a b = a + b

let main() = 
    Console.WriteLine("{0}{1}{2}", (foo 1 2), (foo 1.0 2.0), (foo 1 2.0))

main()

проблемы все те же, конкретизация в момент первого использования

Такие локальные функции как тебе надо, если довести до предельного обобщения — так это dynamic в C# и его последующая типизация/специализация. Насколько я помню там где-то рядом ходит макрос late (поищи его и тесты в исходниках и обсуждение в этом форуме в контексте DLR и dynamic), и если надо — творчески переработай. Кроме того похожие вещи поднимались не раз в контексте "duck typing". Насчёт глобального вывода типов, увы, направить никуда не могу. Как-то повелось считать что это зло, и я тут конформист, и даже в поиск на эту тему не хожу

А вот есть такая история: когда мы начали проект на Nemerle, то паралельно с освоением языка начали хреначить фреймворк "на все случаи жизни". Сейчас кажется что в xUSSR так все делают, ну или делают другое а всё равно фрейморк получается. Первым делом переизобрели множественное наследование (на макросах), как развитие темы — traits на интерфейсах (правда без синтаксиса, на маро-аттрибутах, синтаксис тогда ещё не умели), ещё какие-то мега-штуки много. В общем пытались натянуть Nemerle то на глобус то на C++, и удивительно получалось. Макросы однако.
Дотянули и до множественной специализации классов (причём два вида — на дженериках, и на наследниках от фиктивного типа), обломались на множественной специализации интерефесов (это годы тому назад было, и такая фича в Nemerle не поддерживалась, сейчас уже поддерживается), дошли до подстановки констант (в нашем случае регулярных выражений, но там даже сложнее чем, например, числовых). Венцом творения вроде была генерированная по описанию на лямбдах сериализация, причём один объект мог сериализоваться в сколько угодно разных XML и бинарных форматов. Это я только те штуки которые в силу немерянной крутости на слуху часто были, а мелких достижений наверное и не счесть.

А оно всё оказалось не очень-то надо в реальной жизни, и большая часть этих наворотов была к концу проекта просто забыта в дебрях стремительно устаревающего кода и использовалась только для того чтобы в NUnit зелёных кружочков табунами гонять.

И сейчас кажется что основные недостатки это то что linq идёт с <# #> а мог бы и без, то что иногда перед [] надо точку ставить, а лучше бы там вообще <> были и без точек, то что захваченную переменную в отладчике иногда искать надо в дебрях генерированных классов и имён, то что goto definition и find all references не ходит между Nemerle и C# проектами, то что автокомплит иногда тупит, и т.п.

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

_>И сейчас кажется что основные недостатки это то что linq идёт с <# #> а мог бы и без, то что иногда перед [] надо точку ставить, а лучше бы там вообще <> были и без точек, то что захваченную переменную в отладчике иногда искать надо в дебрях генерированных классов и имён, то что goto definition и find all references не ходит между Nemerle и C# проектами, то что автокомплит иногда тупит, и т.п.
А я вот мегаспециальный синтаксис LINQ (в C#) и не использую вовсе — ну не вижу в нём проку и всё — вызвал экстеншн методы -> ну всё же то же самое и безо всякой фигни...

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

F> Это я всё к тому — что, всё всегда в наших руках. Erlang — платформа, не только язык, — но сказать, что она универсальна — разумеется тоже никак нельзя.
реализовать платформу подобную Эрлангу на .Net очень трудно by design слишком разные цели преследовались при их разработке, + в .net целый ворох фич, которые по сути не нужны для подобной платформы, но этот ворох так и будет волочиться за любым языком на этой платформе словно парашют.

примеры приводить сложно, но сходу могу сказать допустим о подгрузке кода на лету, ну т.е. как подгрузке, загрузить сборку то нет проблемы, дак вот тока выгрузить старую можно только грохнув весь домен

то же самое и с потоками Эрланга, с обменом сообщениями, с отсутствием шаред данных, отсутствием мутабельных данных и тд и тп

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

_C_>>вывод типов в F# есть, и в С# тоже зачатки. так что они решают на уровне компилятора. до JIT. это норм. решение. согласующееся с общей идеологий .Net.

NN>F# сдулся,

Уверен, что именно F#?

let inline foo a b = a + b

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

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

Здравствуйте, Tissot, Вы писали:
T>Уверен, что именно F#?

module Main where
main = putStrLn (show (foo 1 2) ++ show(foo 1.0 2.0) ++ show(foo 1 2.0))
    where foo = \a b -> a + b

ага )

The inline modifier can be applied to functions at the top level, at the module level, or at the method level in a class.

но уже лучше )))
правда немного не то, но лучше

F> А я вот мегаспециальный синтаксис LINQ (в C#) и не использую вовсе — ну не вижу в нём проку и всё — вызвал экстеншн методы -> ну всё же то же самое и безо всякой фигни...

Честно говоря затрудняюсь найти аналоги в некоторых случаях. Одно дело простецкие .Where().Select() которых 90%. Но иногда замутишь какой-нить например from ... let ... let ... from. Такую смесь на одних экстеншенах писать, а потом читать и править однозначно сложнее чем на linq. Да и некоторые запросы к базе сначала на SQL обкатать, а потом на linq без фантазии транслировать тоже проще, чем выполнять "изложение на тему" в терминах экстеншн методов.

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

T>>Уверен, что именно F#?

NN>

NN>module Main where
NN>main = putStrLn (show (foo 1 2) ++ show(foo 1.0 2.0) ++ show(foo 1 2.0))
NN>    where foo = \a b -> a + b
NN>

NN>ага )


NN>

NN>The inline modifier can be applied to functions at the top level, at the module level, or at the method level in a class.

Что есть — то есть

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

NN>ну вот почти вторую неделю ковыряю Nemerle, ...

Я уверен, что недели знакомства с языком — это слишком мало чтобы серьезно разговаривать о его недостатках. Напиши что-то более менее реалистичное и тогда будет о чем поговорить.

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

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

F>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
Извини, не втему... Parallel C# видел? К их рантайму прикрутить dsl на nemele....

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

F>>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
D>Извини, не втему... Parallel C# видел? К их рантайму прикрутить dsl на nemele....
Видимо совсем не в тему или я ничего не понял. При чём тут это?

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

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

F>>>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
Уточни, pls, о каких типичных проблемах кластера идёт речь?

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

F>>>>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
D>Уточни, pls, о каких типичных проблемах кластера идёт речь?
Ну я же писал выше, — автоматизация установки / обновления узлов, сервисы, для которых важно, что бы они были одной версии — предотвращать одновременную работу разных версий, для другой части важно иметь гибкий "роутинг", т.е. приоритет может иметь локалхост, но не везде это актуально. Конфигурирование — вероятно, если несколько узлов будут работать с одной конфигурацией, а другие — с другой — тоже как бы не гуд. Короче ничего сверхъестественного не нужно, но инфрастуктура нужна.