AR>Критерии следующие: поддержка макросов или другой формы метапрогаммирования (скажем, различные eval'ы Ruby); работа на CLR или JVM, чтобы не возникло проблем с наличием библиотек;
Ну библиотеки не только для CLR и JVM пишутся, например для питона их очень много, плюс огромная стандартная библиотека.
AR>вывод типов или динамический язык (поскольку обе платформы и их библиотеки заточены под статические языки, то скорее первое); возможность комбинировать ФП и ООП. Если можете подсказать другие языки, которые под эти критерии подходят, буду только рад.
Питон
AR>У Dylan'а разве есть поддержка .NET? На их сайте об этом ничего найти не могу.
С dylan я ошибся реализации под NET нет, но все остальное нужное есть.
Здравствуйте, Alexey Romanov, Вы писали:
AR>Похожего очень много:
Различей тоже
AR>система типов,
А в чем тут схожесть?
AR>кавычки,
Это что такое? Цитирование?
AR>type inference, и т.д. F# кавычки не так активно выделяет, что есть минус.
AR>Синтаксис гораздо приятнее в Nemerle, если знаешь Ruby/C#/Java и не знаешь OCaml.
+1
AR>Поддержка в Visual Studio лучше у F# + есть интерактивный режим: очень большой плюс.
Ну ничего, наши парни тоже не промах А если серъезно, то и у F# VSIP'а куча недостатков. Так что еще не ясно, у кого появится нормальный VSIP раньше.
AR>Поскольку F# MicroSoft'овский и по нему уже начали писать 3 книги, вполне может оказаться в результате популярнее Nemerle.
Да и бог с ним. Нам ли переживать. А вообще я думаю надо уже засылать Немерлистов да и Влада с Игорем в MS работать, пущай двигают.
AR>С другой стороны, по Lisp есть немало книг, а вот популярности
+1
AR>Скорость пока не сравнивал, но F# ей очень гордится.
JIT работает за вас Хотя код они порой действительно генерят хороший.
AR>У кого какие мнения?
Если мне скажут на работе: на C# больше не пишем, пишем на F# — ни сколько не расстроюсь. Но конечно, Немерл у меня вызывает гораздо больше симпатий.
AR>Еще один язык, в котором есть type inference и макросы -- Boo, но я думаю с ним подождать до появления поддержки generics. boo programming language -- 1.160.000 хитов. Есть ли по нему какие-нибудь соображения?
Здравствуйте, Alexey Romanov, Вы писали:
AR>Критерии следующие: поддержка макросов или другой формы метапрогаммирования (скажем, различные eval'ы Ruby); работа на CLR или JVM, чтобы не возникло проблем с наличием библиотек; вывод типов или динамический язык (поскольку обе платформы и их библиотеки заточены под статические языки, то скорее первое); возможность комбинировать ФП и ООП.
По этим критерия Буу тихонько курит в сторонке. ФП у него довольно слабо (по сравнению с Немерлом). А МП просто в зачаточном состоянии (плагины к компилятору оперирующие с АСТ). Буу это попытка сделать статически типизированный Питон. А так как многие положительные черты Питона основываются на его динамической природе, то и результат получается так себе. Плюс в Буу очень немного хайтека. Это скорее добротная работа середнячков. Немерле же точная противоположенность. Это чистеший хайтек. Это же приводит к тому, что в Немерле до сих пор доволно много глюков.
AR>Если можете подсказать другие языки, которые под эти критерии подходят, буду только рад.
Для Явы есть Скала. С точки зрения читоты проектирования она будет даже по круче Немерла, но в ней нет макросов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Просто язык очень вяло развивается, иначе он мог бы стать и конкурентом для Nemerle.
Я бы сказал, что по возможностям ему (пока?) с Немерле не тягаться, а вот сообщество вокруг него поактивнее будет
(сравни хотя бы активность и кол-во юзеров здесь и здесь).
Вот недавно выпустили Webbness,
что-то вроде Ruby ob Rails для .NET.
Похожего очень много: система типов, кавычки, type inference, и т.д. F# кавычки не так активно выделяет, что есть минус.
Синтаксис гораздо приятнее в Nemerle, если знаешь Ruby/C#/Java и не знаешь OCaml.
Поддержка в Visual Studio лучше у F# + есть интерактивный режим: очень большой плюс.
Поскольку F# MicroSoft'овский и по нему уже начали писать 3 книги, вполне может оказаться в результате популярнее Nemerle. С другой стороны, по Lisp есть немало книг, а вот популярности
На данный момент сравнение популярности: f# programming language -- 513.000 хитов, nemerle programming language -- 98.900.
В западной блогосфере вижу упоминания F# намного чаще.
Скорость пока не сравнивал, но F# ей очень гордится.
У кого какие мнения?
Еще один язык, в котором есть type inference и макросы -- Boo, но я думаю с ним подождать до появления поддержки generics. boo programming language -- 1.160.000 хитов. Есть ли по нему какие-нибудь соображения?
30.01.07 18:09: Перенесено модератором из 'Декларативное программирование' — IT
Здравствуйте, Alexey Romanov, Вы писали:
AR>Попробовал слегка эти языки. Первые заключения:
Не понятно какие критерии отбора языков, если языки на платформе NET (или с подержкой) выводом типов и макросами (или с развитым метапрограммированием?) то не хватает например dylan'а
Здравствуйте, FR, Вы писали:
AR>>Попробовал слегка эти языки. Первые заключения: FR>Не понятно какие критерии отбора языков, если языки на платформе NET (или с подержкой) выводом типов и макросами (или с развитым метапрограммированием?) то не хватает например dylan'а
Ну и зачем вводить людей в заблуждение? Во-первых с каких это пор Dylan появился на платформе .NET? Во-вторых так как Dylan динамически-типизированный язык вывод типов там неполноценный и является лишь средством оптимизации. Такой "вывод типов" и в JScript.NET есть.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Alexey Romanov, Вы писали:
AR>>Попробовал слегка эти языки. Первые заключения:
FR>Не понятно какие критерии отбора языков, если языки на платформе NET (или с подержкой) выводом типов и макросами (или с развитым метапрограммированием?) то не хватает например dylan'а
Критерии следующие: поддержка макросов или другой формы метапрогаммирования (скажем, различные eval'ы Ruby); работа на CLR или JVM, чтобы не возникло проблем с наличием библиотек; вывод типов или динамический язык (поскольку обе платформы и их библиотеки заточены под статические языки, то скорее первое); возможность комбинировать ФП и ООП. Если можете подсказать другие языки, которые под эти критерии подходят, буду только рад.
У Dylan'а разве есть поддержка .NET? На их сайте об этом ничего найти не могу.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Здравствуйте, FR, Вы писали:
AR>>>Попробовал слегка эти языки. Первые заключения: FR>>Не понятно какие критерии отбора языков, если языки на платформе NET (или с подержкой) выводом типов и макросами (или с развитым метапрограммированием?) то не хватает например dylan'а VK>Ну и зачем вводить людей в заблуждение? Во-первых с каких это пор Dylan появился на платформе .NET?
Точно меня замкнуло, почему то отложилось в памяти что Open Dylan требует NET, сейчас посмотрел оказывается нативный компилятор.
VK>Во-вторых так как Dylan динамически-типизированный язык вывод типов там неполноценный и является лишь средством оптимизации. Такой "вывод типов" и в JScript.NET есть.
Так в списке же Boo есть, он в этом отношении близок к Dylan.
Здравствуйте, ie, Вы писали:
ie>Здравствуйте, Alexey Romanov, Вы писали:
AR>>Похожего очень много:
ie>Различей тоже
AR>>система типов,
ie>А в чем тут схожесть?
Есть функциональные типы. Есть варианты. Есть кортежи. Есть литералы списков.
AR>>кавычки,
ie>Это что такое? Цитирование?
Да.
AR>>type inference, и т.д. F# кавычки не так активно выделяет, что есть минус.
AR>>Синтаксис гораздо приятнее в Nemerle, если знаешь Ruby/C#/Java и не знаешь OCaml.
ie>+1
AR>>Поддержка в Visual Studio лучше у F# + есть интерактивный режим: очень большой плюс.
ie>Ну ничего, наши парни тоже не промах А если серъезно, то и у F# VSIP'а куча недостатков. Так что еще не ясно, у кого появится нормальный VSIP раньше.
Ну посмотрим. У меня VSIP Nemerle только-только заработал.
AR>>Поскольку F# MicroSoft'овский и по нему уже начали писать 3 книги, вполне может оказаться в результате популярнее Nemerle.
ie>Да и бог с ним. Нам ли переживать. А вообще я думаю надо уже засылать Немерлистов да и Влада с Игорем в MS работать, пущай двигают.
Поскольку хотелось бы зарабатывать на этом деньги, нужно, чтобы работодатели знали, что это такое
AR>>С другой стороны, по Lisp есть немало книг, а вот популярности
ie>+1
AR>>Скорость пока не сравнивал, но F# ей очень гордится.
ie>JIT работает за вас Хотя код они порой действительно генерят хороший.
AR>>У кого какие мнения?
ie>Если мне скажут на работе: на C# больше не пишем, пишем на F# — ни сколько не расстроюсь. Но конечно, Немерл у меня вызывает гораздо больше симпатий.
AR>>Еще один язык, в котором есть type inference и макросы -- Boo, но я думаю с ним подождать до появления поддержки generics. boo programming language -- 1.160.000 хитов. Есть ли по нему какие-нибудь соображения?
ie> не знаком с ним.
Здравствуйте, FR, Вы писали:
VK>>Во-вторых так как Dylan динамически-типизированный язык вывод типов там неполноценный и является лишь средством оптимизации. Такой "вывод типов" и в JScript.NET есть.
FR>Так в списке же Boo есть, он в этом отношении близок к Dylan.
Отнюдь:
"Boo is a statically typed language.
Static typing is about the ability to type check a program for type correctness.
Static typing is about being able to deliver better runtime performance.
Static typing is not about putting the burden of declaring types on the programmer as most mainstream languages do.
The mechanism that frees the programmer from having to babysit the compiler is called type inference.
Type inference means you don't have to worry about declaring types everywhere just to make the compiler happy. Type inference means you can be productive without giving up the safety net of the type system nor sacrificing performance.
Boo's type inference kicks in for newly declared variables and fields, properties, arrays, for statement variables, overriden methods, method return types and generators."
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Alexey Romanov, Вы писали:
AR>>Критерии следующие: поддержка макросов или другой формы метапрогаммирования (скажем, различные eval'ы Ruby); работа на CLR или JVM, чтобы не возникло проблем с наличием библиотек;
FR>Ну библиотеки не только для CLR и JVM пишутся, например для питона их очень много, плюс огромная стандартная библиотека.
В общем да + есть Jython и IronPython.
AR>>вывод типов или динамический язык (поскольку обе платформы и их библиотеки заточены под статические языки, то скорее первое); возможность комбинировать ФП и ООП. Если можете подсказать другие языки, которые под эти критерии подходят, буду только рад.
FR>Питон
Беда в том, что при сравнении питона и руби у меня все время выигрывает руби Что чище: len(s) или s.length? __gt__ или > ?
VK>>>Во-вторых так как Dylan динамически-типизированный язык вывод типов там неполноценный и является лишь средством оптимизации. Такой "вывод типов" и в JScript.NET есть.
FR>>Так в списке же Boo есть, он в этом отношении близок к Dylan.
AR>Отнюдь:
В Boo вывод типов очень слабый, спотыкается на несложных примерах. И к тому же Boo может работать в режиме динамической типизации.
Здравствуйте, Alexey Romanov, Вы писали:
FR>>Ну библиотеки не только для CLR и JVM пишутся, например для питона их очень много, плюс огромная стандартная библиотека.
AR>В общем да + есть Jython и IronPython.
Есть стандартная библиотека CPython http://docs.python.org/lib/lib.html
AR>>>вывод типов или динамический язык (поскольку обе платформы и их библиотеки заточены под статические языки, то скорее первое); возможность комбинировать ФП и ООП. Если можете подсказать другие языки, которые под эти критерии подходят, буду только рад.
FR>>Питон
AR>Беда в том, что при сравнении питона и руби у меня все время выигрывает руби Что чище: len(s) или s.length? __gt__ или > ?
Фигня, тем более в динамическом языке добавка s.length вполне разрешимый вопрос, реально что у руби лучше это только полноценные блоки кода. Кроме того метопрогаммирование в питоне кажется мощнее, хотя тут могу ошибатся в руби не силен.
Здравствуйте, FR, Вы писали:
FR>В Boo вывод типов очень слабый, спотыкается на несложных примерах. И к тому же Boo может работать в режиме динамической типизации.
Слабость не отсуствие. В Буу он есть. Это главное. А динамическая типизация вот и в Nemerle теперь есть. Это можно рассматривать как дополнительную возможность.
Так что с точки зрения класса языка — я бы все же отнес Буу и Немерле к одному классу статически типизированных компонентных языков.
Однако полностью согласен, что с точки зрения технологичности Буу до Немерла еще расти и расти. Думаю, даже что Буу просто никогда не доростет до нужного уровня. По крайней мере видел я его уже очень адвно, но с тех пор никаких серьезных изменений нет. Его макрсы — это сасвсем не то, что макросы Немерла. Да и вывод типов очень слабый. Единственное приемущество вроде бы он быстрее компилируется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexey Romanov, Вы писали:
AR>В общем да + есть Jython и IronPython.
За Jython не скау, а IronPython — это довольно плохая реализация Питона для дотнета. Одни минусы. Динамическая типизация, плохая интеграция с дотнетом, неполноценность...
AR>Беда в том, что при сравнении питона и руби у меня все время выигрывает руби Что чище: len(s) или s.length? __gt__ или > ?
Согласен, мне тоже руби больше нравится при таком сравнении. Но как Немерле здесь смотрится на уровне. Если учесть, что у него есть паттерн-матчинг и полноценная поддержка ФЯ, то вообще Руби с Питоном смотря на его фоне слабовато.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>В Boo вывод типов очень слабый, спотыкается на несложных примерах. И к тому же Boo может работать в режиме динамической типизации.
VD>Слабость не отсуствие. В Буу он есть. Это главное. А динамическая типизация вот и в Nemerle теперь есть. Это можно рассматривать как дополнительную возможность.
В немерле динамическая типизация такая же как вывод типов в Boo
Возмем тот же Dylan, это динамический типизированный язык с возможностью аннотации типов, то есть статическая типизация в нем тоже есть (притом вполне жесткая), по моему это тоже неплохо, во всяком случае лучше чем плохой вывод типов.
VD>Так что с точки зрения класса языка — я бы все же отнес Буу и Немерле к одному классу статически типизированных компонентных языков.
Угу.
VD>Однако полностью согласен, что с точки зрения технологичности Буу до Немерла еще расти и расти. Думаю, даже что Буу просто никогда не доростет до нужного уровня. По крайней мере видел я его уже очень адвно, но с тех пор никаких серьезных изменений нет. Его макрсы — это сасвсем не то, что макросы Немерла. Да и вывод типов очень слабый. Единственное приемущество вроде бы он быстрее компилируется.
Просто язык очень вяло развивается, иначе он мог бы стать и конкурентом для Nemerle.
Здравствуйте, VladD2, Вы писали:
AR>>Беда в том, что при сравнении питона и руби у меня все время выигрывает руби Что чище: len(s) или s.length? __gt__ или > ?
VD>Согласен, мне тоже руби больше нравится при таком сравнении. Но как Немерле здесь смотрится на уровне. Если учесть, что у него есть паттерн-матчинг и полноценная поддержка ФЯ, то вообще Руби с Питоном смотря на его фоне слабовато.
Да, паттерн-матчинг -- это есть гуд. И list comprehensions. И то, что язык компилируемый до IL уж точно будет быстрее и Руби и Питона. Теперь осталось поднять волну энтузиазма размером с Руби
Здравствуйте, VladD2, Вы писали:
VD>По этим критерия Буу тихонько курит в сторонке. ФП у него довольно слабо (по сравнению с Немерлом). А МП просто в зачаточном состоянии (плагины к компилятору оперирующие с АСТ). Буу это попытка сделать статически типизированный Питон. А так как многие положительные черты Питона основываются на его динамической природе, то и результат получается так себе. Плюс в Буу очень немного хайтека. Это скорее добротная работа середнячков. Немерле же точная противоположенность. Это чистеший хайтек. Это же приводит к тому, что в Немерле до сих пор доволно много глюков.
Спасибо!
AR>>Если можете подсказать другие языки, которые под эти критерии подходят, буду только рад.
VD>Для Явы есть Скала. С точки зрения читоты проектирования она будет даже по круче Немерла, но в ней нет макросов.
Здравствуйте, FR, Вы писали:
FR>В немерле динамическая типизация такая же как вывод типов в Boo
Не скзал бы. Но это не важно, так как она нужна так же как goto.
FR>Возмем тот же Dylan, это динамический типизированный язык с возможностью аннотации типов, то есть статическая типизация в нем тоже есть (притом вполне жесткая), по моему это тоже неплохо, во всяком случае лучше чем плохой вывод типов.
Я незнаю этого языка, но знаю, что языки с "возможностью" обычно проблемотично оптимизировать на 100%, так как на днамике в них решается множество проблем. И вообще я не люблю компромисы.
FR>Просто язык очень вяло развивается, иначе он мог бы стать и конкурентом для Nemerle.
"Бы" очень опасная штука.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexey Romanov, Вы писали:
AR>Да, паттерн-матчинг -- это есть гуд. И list comprehensions.
Это как раз мелочи. Макросы могут и не то.
AR>И то, что язык компилируемый до IL уж точно будет быстрее и Руби и Питона.
Важно не то что он в IL компилируется, а то как это делается. А делается это неплохо, то есть без разных динамических выкрутасов. Получается полностью статически типизированный код (если конечно специально не выпендрваться с object). Оптимизации правад не хватает. Но и так уже очень не полхо, так как сам дотнет не мало делает оптимизаций.
AR> Теперь осталось поднять волну энтузиазма размером с Руби
Всему свое время. Если мы с ИТ доделаем интеграцию, и Немерловцы доведут компилятор до приличного релизного состояния, то думаю через некоторое время Руби будет бледной тенью выглядить. А может и Шарп подвинится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexey Romanov, Вы писали:
AR>Это было из сравнения F# и Nemerle, а не Boo.
А что оно есть в F#?
Ну, да F# обречен, так как это чистый ML-клон. А ML очень неохотно принимается С-ориентированными программистами.
F# скорее любопытное исследование из которго нужно тырить хорошие идеи. Думаю — это понимают и создатели F#.
AR>Я имею ввиду, что оно скомпилировалось и дает хоть какой-то Инетллисенс.
Вот именно "хоть какой-то". Но почти уверен, что через некоторое время мы его добьем и он будет сравним с Шарповским. А где-то может и лучше. Хинты (спасибо IT) уже лучше шарповских.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>В немерле динамическая типизация такая же как вывод типов в Boo
VD>Не скзал бы. Но это не важно, так как она нужна так же как goto.
Угу, на эту тему можно долго и бессмысленно ругатся
FR>>Возмем тот же Dylan, это динамический типизированный язык с возможностью аннотации типов, то есть статическая типизация в нем тоже есть (притом вполне жесткая), по моему это тоже неплохо, во всяком случае лучше чем плохой вывод типов.
VD>Я незнаю этого языка, но знаю, что языки с "возможностью" обычно проблемотично оптимизировать на 100%, так как на днамике в них решается множество проблем. И вообще я не люблю компромисы.
Я тоже достаточно поверхностно с ним знаком, но язык неплохой и типизация жесткая как динамическая так и статическая. Притом статическая вполне полноценная, и даже больше, с уклоном в контракты, например (вроде это из ады взято) есть ограниченные типы:
define method f (x :: limited(<integer>, min: -1000,
max: 1000))
При этом если возможно проверки проводятся во время компиляции.
FR>>Просто язык очень вяло развивается, иначе он мог бы стать и конкурентом для Nemerle.
VD>"Бы" очень опасная штука.
Угу, так как даже сейчас Nemerle надо догонять по популярности Boo.
Кстати у Dylan'а тоже большие проблемы с популярностью. И по возможностям он очень близок к Nemerle.
Здравствуйте, FR, Вы писали:
FR>Я тоже достаточно поверхностно с ним знаком, но язык неплохой и типизация жесткая как динамическая так и статическая. Притом статическая вполне полноценная, и даже больше, с уклоном в контракты, например (вроде это из ады взято) есть ограниченные типы: FR>
ie>f (x : int) : int
ie>requires x >= -1000 && i <= 1000 otherwise throw System.ArgumentOutOfRangeException ($"$x is not in -1000 - 1000 range")
ie>
В Dylan'е можно написать такой же макрос.
FR>>При этом если возможно проверки проводятся во время компиляции.
ie>Хмм, а как это реализовано, интересно.
Наверно так же как VC может превращать кучу вызовов функций с константными вызовами в одну асссемблерную инструкцию.
А если серъезно, то и у F# VSIP'а куча недостатков. Так что еще не ясно, у кого появится нормальный VSIP раньше.
не знаком с ним.
