Здравствуйте, Schade, Вы писали:
S>Действительно, странно было бы выводить тип топ-левел конструкций исходя из первого использования, как это сделано в Немерле для локальных функций.
Ну для приватных методов не так уж и странно, и кстати не раз уже предлагалось. Просто это не настолько важно, чтобы все кинулись это немедленно реализовывать.
S>Тут компилятор сам в состоянии разобраться, что функция имеет тип string -> string option, и подсказки ему не нужны. Нет, конечно, совсем без указания типов не обойтись, но механизм вывода здорово снижает их количество.
Компилятор то разберется, а вот сразу ли разберется человек? Предположим, что ты ничего не знаешь про StreamReader. ReadToEnd на первый взгляд вполне может возвращать массив байтов.
Кроме того этот конкретный пример хорошо показывает, что экономия на аннотации типов зачастую настолько мизерна, что даже элементарное знание библиотек, с которыми работаешь, помогает гораздо больше. Вместо самодельной функции в данном случае проще использовать IO.File.ReadAllText. Я уже не говорю о менее приземленных вещах типа грамотного дизайна или макросов.
S>// какой страшный ужас :), для начала можно переписать так
S>// l.FoldLeft([], (elem, acc) => if (f(elem)) elem::acc else acc).Rev()
S>def my_filter (f, l) { List.Rev (List.FoldLeft(l, [], (elem, acc) => if (f (elem)) elem::acc else acc)) }
S>// лишние скобки
S>def x = my_filter( (x) => x>0, [1,2,3,-5,-9,7] )
S>// Nemerle это уточнение типа не нужно
S>def longEnough(str:string) {str.Length > 5}
S>def x2 = my_filter ( longEnough , ["String1", "Str2"] )
S>
Кстати, в отличие от OCaml/F# в Nemerle есть такая штука как list comprehensions:
Если ее использовать, то оказывается описания типов не так уж и страшны:
// нормальный обобщенный метод расширения, как раз такой есть в ст. библиотеке под названием Filter ;)public static MyFilter[T](this l : list[T], f : T->bool) : list[T] { $[x | x in l, f(x)] }
// ocamllet my_filter f = List.fold_left (fun acc elem -> if f elem then elem::acc else acc) [] >> List.rev
Плюс ко всему человек, который понятия не имеет об одном или более следующих пунктов:
1) композиции функций
2) карринге
3) свертке
4) устройстве односвязных списков
сможет хотя бы в общих чертах понять что делает функция и как ее вызвать. list comprehensions это не rocket science, это очень просто, встречается даже в языках для школьников младших классов, типа питона.
VD>>К тому же большой вопрос является ли добром вывод типов для конструкций верхнего уровня (типов и их членов). S>А чего в этом злого?
Попробуй посмотреть и исходники F#, а еще лучше добавь туда фичу-другую. Или хотя бы баг исправь.
Компилятор F# писал в основном один человек, PhD из Кембриджа. Всего за время его жизненного цикла там было максимум человек пять контрибуторов, в основном профессиональные разработчики или исследователи из MS и MSR. Комментариев и аннотаций типов там почти нет. Зато есть громадные не только в высоту, но и ширину(до 300 с лишним символов) функции, а написан он вообще на Caml, совместимость с F# для бутстрапинга там в виде вставок и условной компиляции. Всем желаю приятного просмотра и редактирования его исходников.
Компилятор Nemerle тоже написан не идеально, академические проекты редко когда могут похвастаться действительно хорошим кодом, но достаточно понятно и вменяемо для того, чтобы тем или иным образом, в то или иное время, в компилятор влезло больше двадцати человек народу, в основной массе значительно меньшей квалификации(по крайней мере номинально ). Некоторые помнится даже отправляли патчи после недели знакомства с Nemerle и функциональными языками вообще. С комментариями в коде тоже местами туговато, а адекватной текущему состоянию дел документации вообще нет, но зато есть аннотации типов и они неплохо помогают ориентироваться по коду.
Если посмотреть на опыт еще более сложных проектов, то вообще становится интересно. GHC написан в литературном стиле(в основном одни комментарии с вкраплениями кода), на первый взгляд все аннотации типов на месте. Большинство вменяемых библиотек на функциональных языках, которые я видел, тоже с аннотациями. Так пишут профессионалы от ФП, почему для любителей возможность не указывать типы является такой важной мне не совсем понятно. Наверное потому, что ничего кроме небольших игрушечных проектиков на ФЯ они не пишут, да и не собираются, так как еще не дошли нужного состояния ума или безумия. В принципе для вышеоговоренных проектов написание write-only кода вполне оправданно, сложно запутаться в собственном коде, тем более когда его кот наплакал.
S>Ну, скажем так, реализация местами еще халтурненькая. Есть, например, в зачатке вывод типов лямбд из использования:
Здесь проблема скорее не с лямбдами, а с вызовом метода. В OCaml объекты были структурированными типами, таких проблем быть не могло, так как просто добавлялся констрейн по названию и типу метода в выводимый обобщенный тип. В F# тоже кажется есть похожие констрейны, но видимо в таких случаях они не помогают или не используются(тем более, что CLR это безобразие не поддерживает).
S>Но все-таки это скорее проблема текущей сырой реализации.
Про сырую реализацию не нужно. F# разрабатывается чуть ли не с 2002-го года. В начале 2005-го уже была версия 1.0. Don Syme пользовался наработками, которые он сделал в процессе реализации дженериков и переноса академических языков на .NET(Project 7, 1999-2002). Это то, что возможно в F# без серьезной потери совместимости с Caml. Это как раз последствия использования алгоритма Хиндли-Милнера, выводящего наиболее общие типы. Просто чудо, что он местами смог его побороть. В Nemerle кардинально сменили алгоритм, выбрав более подходящую для .NET модель.
Например перегрузкой в F# все очень плохо, ни определить, ни нормально использовать нельзя (у Nemerle естественно подобных проблем нет как класса). Тривиальные примеры, от которых у F# сносит крышу:
Console.WriteLine 1
let f = System.Console.WriteLine in f "test"
Кроме того в F# нет такой банальной вещи как авто-боксинг, предлагается использовать функции box и unbox. Поддержка операторов преобразования из внешнего кода тоже под вопросом, определять их в F# понятное дело тоже нельзя.
При большом желании, которого у меня нет, можно еще много накопать, так как идеология интеграции Nemerle и F# с .NET совершенно иная.
1) Nemerle обязан позволять программисту воспроизвести почти любой код на безопасном диалекте C# 2.0, так чтобы он для внешнего кода выглядел неотличимо от C# варианта
2) Использовать код из внешних библиотек на других языках CLR, причем с аналогичным или большим удобством, чем это позволяет делать C# (вот в этом аспекте у F# вообще плохо, он пытается частично решить проблему своей громадной стандартной библиотекой).
У F# задача совсем другая. Некое подмножество F#(функции + основные типы данных) обязано работать в точности как OCaml и F# обязан уметь компилировать OCaml код, написанный на этом подмножестве, с вставками F# и условной компиляцией. Такая извращенская схема видимо была задумана для упрощения бутстрапинга компилятора F# и достижения других личных целей вроде портирования большой существующей базы кода с OCaml, но интеграцию с .NET это естественно усложняет. Поэтому, на мой взгляд, F# никогда не стать действительно "first-class .NET language".
VD>>Можно. Но прямые решения (использованные в F# и Scala) приводят к серьзным потяерям производительности и мало чем отличаются от тупого перемапливания на алгеброические типы. Меж тем пока что не ясно даст ли это повышение удобства использования языка. Пусть F# и Scala побалуются. Если будут сообщения о том, что это очень удобно, то и мы добавим. Темболее, что технология будет уже отработана и можно будет сделать тесты. S>Так это же замечательно, что балуются, а не объявляют себя законченным решением. А то так можно и до уровня Оберона закостенеть.
В Nemerle другая схема. Балуются в основном сторонние контрибуторы или вообще посторонние люди типа меня. Если конечный результат хорош, то это добавляется в "законченное решение". Активные паттерны пока никого особо не заинтересовали. А вообще примерно в том виде в каком они сделаны в F#, можно добавить в компилятор(через макросы это будет сложнее) за пару дней, а кода это добавит сотню строчек, максимум две(скорее всего это даже преувеличенные цифры). Квазицитирование и паттерн-мэтчинг кода между прочим активно используется не только в макросах, но и в компиляторе. Такие элементарные фичи, связанные с генерацией кода добавляются поэтому достаточно легко и просто.
VD>>Это назвается спор ради спора, или отсуствие конструктива. S>Да это собственно даже не спор. Просто попытка донести мысль, что и в F# есть на что посмотреть.
Везде есть на что посмотреть, но это не значит что нужно реализовывать все увиденное у других, тем более точно по образу и подобию. Когда Nemerle создавался, на OCaml смотрели самым пристальным образом, так как на нем писали первую версию компилятора и видимо позаимствовали то, что показалось нужным позаимствовать. А что касается F#, то есть серьезные подозрения, что многие вещи в нем появились после того как Don Syme как-раз посмотрел на Nemerle.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Компилятор то разберется, а вот сразу ли разберется человек? Предположим, что ты ничего не знаешь про StreamReader. ReadToEnd на первый взгляд вполне может возвращать массив байтов.
С поддержкой IDE, пусть и такой слабой как у F#, все становится не так страшно.
VK>Кроме того этот конкретный пример хорошо показывает, что экономия на аннотации типов зачастую настолько мизерна, что даже элементарное знание библиотек, с которыми работаешь, помогает гораздо больше. Вместо самодельной функции в данном случае проще использовать IO.File.ReadAllText. Я уже не говорю о менее приземленных вещах типа грамотного дизайна или макросов.
Ну, не совсем так. Поведение ReadAllText несколько иное.
VK>
S>>// какой страшный ужас :), для начала можно переписать так
S>>// l.FoldLeft([], (elem, acc) => if (f(elem)) elem::acc else acc).Rev()
S>>def my_filter (f, l) { List.Rev (List.FoldLeft(l, [], (elem, acc) => if (f (elem)) elem::acc else acc)) }
S>>// лишние скобки
S>>def x = my_filter( (x) => x>0, [1,2,3,-5,-9,7] )
S>>// Nemerle это уточнение типа не нужно
S>>def longEnough(str:string) {str.Length > 5}
S>>def x2 = my_filter ( longEnough , ["String1", "Str2"] )
S>>
VK>
VK>Кстати, в отличие от OCaml/F# в Nemerle есть такая штука как list comprehensions: VK>
(* вот list comprehension *)
[ for e in l when f e -> e ]
(* а вот array comprehension *)
[| for e in l when f e -> e |]
(* а вот так - IEnumerable comprehension *)
{ for e in l when f e -> e }
VK>Если ее использовать, то оказывается описания типов не так уж и страшны: VK>
VK>// нормальный обобщенный метод расширения, как раз такой есть в ст. библиотеке под названием Filter ;)
VK>public static MyFilter[T](this l : list[T], f : T->bool) : list[T] { $[x | x in l, f(x)] }
VK>// ocaml
VK>let my_filter f = List.fold_left (fun acc elem -> if f elem then elem::acc else acc) [] >> List.rev
VK>
Длину строки сравниваем ?
let my_filter f l = [for e in l when f e -> e]
Кстати, было бы очень странно, если бы такой стандартной функции не было. Но проиллюстрировать свои слова хотелось небольшим примером, без лишних деталей.
VK>Плюс ко всему человек, который понятия не имеет об одном или более следующих пунктов: VK>1) композиции функций VK>2) карринге VK>3) свертке VK>4) устройстве односвязных списков VK>сможет хотя бы в общих чертах понять что делает функция и как ее вызвать. list comprehensions это не rocket science, это очень просто, встречается даже в языках для школьников младших классов, типа питона.
Дружественность к человеку с C/C#/Java/Delphi бэкграундом — такой цели просто не ставилось. Ок, это минус.
VK>Попробуй посмотреть и исходники F#, а еще лучше добавь туда фичу-другую. Или хотя бы баг исправь. VK>Компилятор F# писал в основном один человек, PhD из Кембриджа. Всего за время его жизненного цикла там было максимум человек пять контрибуторов, в основном профессиональные разработчики или исследователи из MS и MSR. Комментариев и аннотаций типов там почти нет. Зато есть громадные не только в высоту, но и ширину(до 300 с лишним символов) функции, а написан он вообще на Caml, совместимость с F# для бутстрапинга там в виде вставок и условной компиляции. Всем желаю приятного просмотра и редактирования его исходников.
Ну, теперь этим есть кому заняться
VK>Если посмотреть на опыт еще более сложных проектов, то вообще становится интересно. GHC написан в литературном стиле(в основном одни комментарии с вкраплениями кода), на первый взгляд все аннотации типов на месте. Большинство вменяемых библиотек на функциональных языках, которые я видел, тоже с аннотациями. Так пишут профессионалы от ФП, почему для любителей возможность не указывать типы является такой важной мне не совсем понятно.
Аннотации типов — bon tone, там где они нужны для понимания. Да и выводимые хаскелем типы (если нет аннотаций) часто просто страшно выглядят
Тут волей-неволей будешь писать аннотации, даже если они и не обязательны.
VK>[...]
VK>У F# задача совсем другая. Некое подмножество F#(функции + основные типы данных) обязано работать в точности как OCaml и F# обязан уметь компилировать OCaml код, написанный на этом подмножестве, с вставками F# и условной компиляцией. Такая извращенская схема видимо была задумана для упрощения бутстрапинга компилятора F# и достижения других личных целей вроде портирования большой существующей базы кода с OCaml, но интеграцию с .NET это естественно усложняет. Поэтому, на мой взгляд, F# никогда не стать действительно "first-class .NET language".
Тут он конечно наступает на те же грабли, на которые наступил C++ — совместимость со старым кодом. Причем зря, бо Caml-ового кода, который можно скомпилировать на F# без переписывания — не так уж много. Куда ни глянь, везде используются конструкции, не реализованые в F# (да и вряд ли они будут реализованы под CLR в ее нынешнем варианте). Поскольку переписывать CLR под F# никто не будет, я надеюсь, у разработчиков хватит решимости забить на совместимость с Caml.
VK>Везде есть на что посмотреть, но это не значит что нужно реализовывать все увиденное у других, тем более точно по образу и подобию. Когда Nemerle создавался, на OCaml смотрели самым пристальным образом, так как на нем писали первую версию компилятора и видимо позаимствовали то, что показалось нужным позаимствовать. А что касается F#, то есть серьезные подозрения, что многие вещи в нем появились после того как Don Syme как-раз посмотрел на Nemerle.
Здравствуйте, Schade, Вы писали:
S>3. C Nemerle, похоже, все и так получится, "вопреки всему". Если за счет MS-овских бабок линейка дополнится еще и вылизанным F# — см. п.2 про богатство выбора. Бешеной популярности, судя по всему, не снискать не тому, ни другому — среднечеловеческая консервативность не знает границ, а вот получить в свои руки еще один инструмент — почему бы и нет?
Дык, я не против ОКамла на дотнете. Я тоже только за. Как-грисъя — пусть цветут все цветы.
Проблема в другом. Если уж поддерживать F#, то разумно было бы поддержать и Немерле, а то и Скалу с Буу.
Это все очень перспективные языки. Причем F# среди них самый консервативный.
Потом лично у меня нет даже сомнения, что если бы МС вбухал относительно микроскопические бабки в развитие Немреле и хоть немного помог ему морально (объявил бы о поддержке и малость пропиарил), то Немерле легко сошел бы за очередную псевдо-рпеволюцию созданную МС и навел бы немало шороха. В общем, я уверен, что караз этот язык пропер бы. Пусть он не заменил бы Шарп и темболее Васик, но то что он мог бы занять достойное место в линейке языков и смог бы преманить на свою сторону нехилую часть C#-щиков и C++-ников — это точно.
S>Таки врет товарисч Syme? S>
S>From 1999 to 2004 I worked extensively with the .NET Common Language Runtime Team, both on the design and implementation of generics and on other issues related to the .NET Common IL's type system. During 2002 and 2003 Andrew Kennedy and I were working essentially full-time as as an adjunct members of the CLR team in a mix of architectural, development, testing and program management roles (thankfully our workload has eased off...) Some of those who I had the pleasure of working with were Dario Russi, Vance Morrison, Sean Trowbridge, Simon Hall, Shri Borde, Ian Bearman, Chris Brumme and Patrick Dussud.
S>From 1999 to 2003 I was involved with the design of C#, authoring the first draft of the C# language design for generics. I also prototyped the initial support for generics in the Microsoft C# compiler. During this time I had the pleasure of working with Anders Hejlsberg, Peter Golde, Peter Hallam and others.
Может и не врет. Вот только это никак не отрицает того, что не он их разработал.
Вот http://research.microsoft.com/projects/clrgen реальная страница в которой он (вроде бы) упоминается как "You may also contact dsyme@microsoft.com, akenn@microsoft.com or the C# team."
Так что или в то время он работал в "The PPG group at MSR Cambridge" (см. предыдущую ссылку), или он работал над интеграцией полученного прототипа для Ротора в исходный компилятор МС. А может он просто курировал ту группу. Вот только факт, что дженерики сначала появились в Роторе и то что разработаны они были в Кембридже.
S>Действительно, странно было бы выводить тип топ-левел конструкций исходя из первого использования, как это сделано в Немерле для локальных функций.
В ОКамле вывод типов работает глобально. В нем ожно вообще не указывать типы. Ну, или делать это очень редко.
S> Но если тело функции/метода содержит достаточно информации для вывода типа — зачем тогда type annotations?
В простых случаях и в Немерле можно не указывать типы полей (если у них есть простые инициализаторы).
А надо это для:
1. Документирования кода.
2. Для нужд IDE. Без этого скорость работы IDE будет зависить от объема кода, что не приемлемо.
S> Вот например: S>
S>let FileContents fname =
S> try
S> use stream = new IO.FileStream(fname, IO.FileMode.Open)
S> (* конструкция use аналогична let, но обеспечивает реализацию Dispose-паттерна *)
S> use reader = new IO.StreamReader(stream)
S> Some (reader.ReadToEnd())
S> with _ -> None
S>
S>Тут компилятор сам в состоянии разобраться, что функция имеет тип string -> string option, и подсказки ему не нужны. Нет, конечно, совсем без указания типов не обойтись, но механизм вывода здорово снижает их количество.
Вот ОКамл обходится. Но ценой тому совсем хреновые сообщения об ошибках и очень плохая поддержка в IDE.
Ты ведь не занимался данной проблемой и не понимшь, что многие вещи в коде завязаны друг на друга. Скажем в коде метода может появиться использование другого метода. Это приводит к тому, что по одному метду уже нельзя точно вычислить тип. И таких проблем много.
S>F# определяет тип функции my_filter как ('a -> bool) -> 'a list -> 'a list, а Nemerle — по факту первого использования, как int -> bool, list[int], list[int]
Скромный вопрос. F# делает это для методов или локальных функций ака let-ов?
Как показала практика для локальных фунций вывод дженерик-типов смысла не имеет. Мы мишем реальный код и обобщать его нет смысла. Такая задача встает только когда люди играются с языком. Это из серии "а что если?". На практике или обобщается сам метод и тогда все локальные фунции автоматом получаются обобщенными, или этого попросту не требуется.
Более того. Вывод обобщений может завуалировать ошибку. Вывод конкретных типов выявляет больше ошбок.
Ну, а если уж вдруг потребуетс создать обобщенную локальную фунцию, то не грех описать это явно. Там ведь особо напрягаться не приходится.
S>И если дальше продолжим: S>
S>let my_filter f = List.fold_left (fun acc elem -> if f elem then elem::acc else acc) [] >> List.rev
S>let x = my_filter (fun x -> x > 0 ) [1; 2; -9; 14; -5; 7]
S>let longEnough (s:string) = s.Length > 5
S>let x2 = my_filter longEnough ["String1"; "Str2"; "String4"]
S>
S>То F# нормально скомпилирует, а Nemerle пошлет. Нет, понятно, что многократно используемые функции надо выносить за локальные пределы, но там type inference не работает. Как окажется в списке параметров пара-тройка функций — задолбишься выписывать типы.
Ой, настолько надуманный пример, что просто противно. Обобщенные методы должны быть в библиотеках. А там им сам бог велел быть явно аннотированными. Так твой фильт уже давно лежит в станартной библиотеке. Да и такие анохранизмы как использование статических методов тоже давно канули в лету. Есть же методы расширения. Продемонстрированный тобой код даже без применения лист-компрехеншона можно записать так:
Блин, такой интуитивности F#-пу не видать как своих ушей. Тут разве что LINQ может что-то предложить.
VD>>К тому же большой вопрос является ли добром вывод типов для конструкций верхнего уровня (типов и их членов).
S>А чего в этом злого?
Я уже говорил. Это плохо для человека. И это плохо для поддержки IDE.
VD>>Реально ввывод типов F# значительно слабее его аналога в немерле.
S>Ну, скажем так, реализация местами еще халтурненькая. Есть, например, в зачатке вывод типов лямбд из использования: S>
S>(* вот так работает *)
S>let x = "SomeString" |> (fun s -> s.Length)
S>(* вот так, увы, нет *)
S>let x = (fun s -> s.Length) "SomeString"
S>
S>Но все-таки это скорее проблема текущей сырой реализации.
Боюсь, что это все проблемы адаптации Хиндли-Милера к дотнетной системе типов. Скрещивание ужа с ежом всегда было занятием не благодарным.
В Немерле изначально тоже использовался такой полход. Но где-то по пути своего развния была разработана уникальная система типов и я как пользователь могу сказать, что она удалась на славу. Единствный серьзный недостатко — она довольно тормозная. Но потенциально она позволяет параллельную типизацию, так что есть куда масштабироваться.
VD>>Примеры, плиз в студию, где F# дает что-то больше чем Nemerle. Тогда обсудим. Пока что это похоже на домыслы.
Что-то ответ я так и не увидел?
S>Так это же замечательно, что балуются, а не объявляют себя законченным решением. А то так можно и до уровня Оберона закостенеть.
Просто замечательно. Более того. Тройка Скала/Немерле/Шарп много выигрывают от того, что ведут исследования параллельно и пользуются результатами оных сообщя.
Я же не говорю, что F# маст дай и т.п. Я просто говорю, что МС пытается вкладыват деньги в язык который будет априори чужд большинству ее аудитории и даже не замечает языки которые действительно могли бы выстрелить.
Пойми, что бесмысленно заниматься пенисометрией. F# не плохой язык. Его проблемы не в том, что у него фича-лист меньше чем у Немерле. Его проблема в том, что это на 99% ОКамл который уже не принят индустрией. Ну, сложный он для понимания простых смертных. Нельзя его рассматривать как на расширение того что было. А вот Немерле отлично прокатывает за C#++ на первой стадии. Когда еще там люди освоют паттерн-матчинг, алгеброические типы и разные компрешеншоны, но приемущества они получат сразу. И работать они смогут сразу. Этого у F# не будет никогда.
Посему уж если давать бабки на F#, то глупо не дать их и на Немреле. Более того. Разумно было бы объеденить или хотя бы скоординировать усилия двух направлений. Вместе разультат мог бы оказаться куда лучше. Скажем F# и Немерле могли бы использовать одни и те же общие ФП-библиотеки. Код между ними стал бы переносим. А там уже не загорами фунциональные оптимизации в CLR (Нью-Васюки, значич ).
VD>>Это вообще сахар. Давно маньяки вроде тебя добавили оператор >> полностью аналогичный этой самой точке. Только синтаксис получился чище чем в Хаскеле.
S>Да, сахар. Мелочь, а приятно.
Хорошо, что тебе приятно. Только за приемущество это не катит.
Скажем, сахар в частичном применении у Немерла куда по приятнее.
S>Ууууу. Про мелочевки-то и распинаться не охота.
Так что из этого приемущества пытаться своять? Нет никаких приемуществ. Или скажем так. На каждый выверт в F# можно найти 2 в Немерле.
С точки зрения поддержки ФП оба языка прекрасны. И поиск среди них более идеального не большее чем попытка выдвать свои субъективные предпочтения за реальность.
А вот то, что скажем Немерле лучше воспринимается C#-пщиками. И то что Немерле обладает законченной и мощьной макро-подсистемой — это факт неоспоримый. И эти приемущества перевесят очень многое.
S>Да это собственно даже не спор. Просто попытка донести мысль, что и в F# есть на что посмотреть.
А с этим кто-то спорил? Это я что ли заявил, что F# плохо ФП поддерживает? Это ты заявил обратное о Немреле.
VD>>Можно пару слов о проектах написанных тобой на F#-е? S>Ай, поймал. Нет, публичного предъявить нечего. Из действующего — только скромненький анализатор статистики работы одной специфической промышленной железяки с PC внутри. Специфика работы, понимаешь, не программистской, и даже не админской.
Вот, о том и речь.
S>Да я и не надеялся, что он пойдет прям таки в массы.
И я не надеюсь. А вот Немерле мог бы пойти если его поддержать. Причем, я не против поддержки и F#-а. Я против поддержки именно F# в ущерб остальным, да еще и в привычном для МС закрытом режиме. F# и так самый закрытый язык из тройки.
VD>>С чего бы это? C# же не заменил Васик хотя технически языки почти клоны? А Немерле отличается от Шарпа довольно сильно. Он сложнее и мащьнее. Индусам может не подойти.
S>Васик-шмасик. Васик — это блин традиция, а то местами и диагноз (помнишь, как некоторые ВБ-шники взывыли, когда увидели, что им подсунули под видом VB7?). Надо же было как-то ВБ-шников пересаживать на .NET, не пугая страшной буквой C?
Дык точно так же Немерел и темболее F# не замена Шарпу. Но F# может в лучшем случае привлечь к платформе тех кто не ровно дышитк к ОКамлу. А Немерле двинуть в массы лучшие фичи из ФП. Хороший шарпщик спокойно перейдет на Немреле, а вот на F# — нет.
VD>>Да и какая разница, на замену или рядом? Главное чтобы он был. А чтобы он был нужны вливания денег и поддержка. В прочем, велика вероятность, что он таки будет во преки всему. S>Дык я ж разве против? Опять-же см. п.2 дисклеймера про богатство выбора. Вот.
Проблема в том, что компилятор и темболее разработка и развите языка — это довольно затратное дело. Вести его на голом энтузиазме очень не просто. И если будут поддерживать скажем F#, а не Немерле забьют, то в результате более перспективный Немрле может сдохнуть, а F# будет прозибать. Другими словами мы получим собаку на сене. Вроде что-то есть и это что-то забьет другое, но вот воспринято это будет очень узким кругом лиц.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Schade, Вы писали:
S>В отличие от OCaml, не от F#. S>
S>(* вот list comprehension *)
S>[ for e in l when f e -> e ]
S>(* а вот array comprehension *)
S>[| for e in l when f e -> e |]
S>(* а вот так - IEnumerable comprehension *)
S>{ for e in l when f e -> e }
S>
Кстати, о приемуществах макросов. Если в коде на Немерле изменить исходный формат, то он все равно будет работать. Например, прокатят и таки варианты:
def my_filter(f, l) { $[x | x in l, f(x)] }
def x = my_filter(_ > 0, array[1, 2, 3, -5, -9, 7]);
или
def my_filter(f, l) { $[x | x in l, f(x)] }
def x = my_filter(_ > 0, array[1, 2, 3, -5, -9, 7] : Collections.Generic.IEnumerable[int]);
более того, если лист-компрехэншон подставить в foreach, то на выходе будет не список, а код итерации. Другими словами макросы позволяют добиться офигительной гибкости. И я почит уверен, что объем кода в них меньше чем тот хардкод что заложен в F#.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дык, я не против ОКамла на дотнете. Я тоже только за. Как-грисъя — пусть цветут все цветы. VD>Проблема в другом. Если уж поддерживать F#, то разумно было бы поддержать и Немерле, а то и Скалу с Буу.
Разумно. Почему не стали — . Может, Москаль не так уж и стремился к тому, чтобы далее плотно работать с Немерле? Раз он там так плотно засел за систему доказательства теорем. Кстати, если им там все-таки на первом этапе выделили какое-то финансирование, что-нибудь в плане развития Немерле за этим последовало? Может, просто МС решил, что от этой команды отдачи не будет?
VD>Это все очень перспективные языки. Причем F# среди них самый консервативный.
Его консервативность заключается в Камловом наследии? Не факт, что эта цель (частичная совместимость с Камлом) будет преследоваться в дальнейшей работе.
VD>Потом лично у меня нет даже сомнения, что если бы МС вбухал относительно микроскопические бабки в развитие Немреле и хоть немного помог ему морально (объявил бы о поддержке и малость пропиарил), то Немерле легко сошел бы за очередную псевдо-рпеволюцию созданную МС и навел бы немало шороха. В общем, я уверен, что караз этот язык пропер бы. Пусть он не заменил бы Шарп и темболее Васик, но то что он мог бы занять достойное место в линейке языков и смог бы преманить на свою сторону нехилую часть C#-щиков и C++-ников — это точно.
Как мне кажется, чтобы монстр заметил интересный проект, этому проекту мало быть интересным. Надо еще достаточно громко кричать про себя, чтобы до нужных ушей долетело. И не только на RSDN — здесь нужных ушей МС-а увы нет. Так вот, представь себе, что ты ничего не знаешь про Немерле, и заходишь на nemerle.org. Какое первое впечатление? Что проект давно и успешно скончался. Вот так и Хейлсберг зашел, посмотрел, и, облегчив совесть, ушел. "Ничего не нашел".
VD>В ОКамле вывод типов работает глобально. В нем ожно вообще не указывать типы. Ну, или делать это очень редко. VD>В простых случаях и в Немерле можно не указывать типы полей (если у них есть простые инициализаторы).
VD>А надо это для: VD>1. Документирования кода. VD>2. Для нужд IDE. Без этого скорость работы IDE будет зависить от объема кода, что не приемлемо.
1. Никто не запрещает аннотировать явно, там где это нужно
2. Что есть то есть, IDE подтормаживает (хотя по субъективным впечатлениям просто что-то где-то очень криво написано)
VD>Вот ОКамл обходится. Но ценой тому совсем хреновые сообщения об ошибках и очень плохая поддержка в IDE.
Кстати, сообщения об ошибках, кроме совсем уж клинических случаев, вполне внятные.
VD>Ты ведь не занимался данной проблемой и не понимшь, что многие вещи в коде завязаны друг на друга. Скажем в коде метода может появиться использование другого метода. Это приводит к тому, что по одному метду уже нельзя точно вычислить тип. И таких проблем много.
VD>Скромный вопрос. F# делает это для методов или локальных функций ака let-ов?
let-ы — это не только и не столько локальные функции, функции уровня модуля тоже объявляются let-синтаксисом. Методы классов — по другому. Вывод типов работает и там, и там.
VD>Как показала практика для локальных фунций вывод дженерик-типов смысла не имеет. Мы мишем реальный код и обобщать его нет смысла. Такая задача встает только когда люди играются с языком. Это из серии "а что если?". На практике или обобщается сам метод и тогда все локальные фунции автоматом получаются обобщенными, или этого попросту не требуется.
Для локальных — конечно не имеет, они ведь как правило и вызываются из кода по 1-2 раза.
VD>Более того. Вывод обобщений может завуалировать ошибку. Вывод конкретных типов выявляет больше ошбок.
VD>Ну, а если уж вдруг потребуетс создать обобщенную локальную фунцию, то не грех описать это явно. Там ведь особо напрягаться не приходится.
VD>Ой, настолько надуманный пример, что просто противно. Обобщенные методы должны быть в библиотеках. А там им сам бог велел быть явно аннотированными. Так твой фильт уже давно лежит в станартной библиотеке.
Ой, да шо ви таки с Vermicious Knid'ом прикопались к этому несчастному примеру? Неужели для того, чтобы проиллюстрировать сказанное на словах кодом нужно этот код брать из реального проекта, да еще и так, чтоб без изъяна? Я же сразу сказал — пример банальный и надуманный — всего лишь указать на различие в принципах type inference.
Да и что это была бы за ФП-библиотека без filter, в конце-то концов.
VD>Да и такие анохранизмы как использование статических методов тоже давно канули в лету. Есть же методы расширения. VD>Продемонстрированный тобой код даже без применения лист-компрехеншона можно записать так: VD>
VD>Блин, такой интуитивности F#-пу не видать как своих ушей. Тут разве что LINQ может что-то предложить.
Неправда твоя:
let result = ["String1";"String2";"Str3"].Filter (fun x -> x.Length > 5)
Называется, найдите 10 отличий
Кстати, что случилось с нотацией _.Member?
Почему вот так не работает?
def result = ["String1", "Str2", "String4"].Filter(_.Length > 5);
VD>Боюсь, что это все проблемы адаптации Хиндли-Милера к дотнетной системе типов. Скрещивание ужа с ежом всегда было занятием не благодарным.
Но всегда есть надежда, что от ежа и ужа родится корова, несущая золотые страусиные яйца в промышленных масштабах.
VD>В Немерле изначально тоже использовался такой полход. Но где-то по пути своего развния была разработана уникальная система типов и я как пользователь могу сказать, что она удалась на славу. Единствный серьзный недостатко — она довольно тормозная. Но потенциально она позволяет параллельную типизацию, так что есть куда масштабироваться.
Вот пусть и развиваются параллельно. А там, глядишь, и из Хиндли-Милнера, натянутого на .NET что приличное получится.
VD>>>Примеры, плиз в студию, где F# дает что-то больше чем Nemerle. Тогда обсудим. Пока что это похоже на домыслы. VD>Что-то ответ я так и не увидел?
Да тут все будет спорным получаться. Хотя бы в силу того, что если на мой взгляд, F#-вый вывод типов это преимущество, то на твой — это недостаток.
VD>Просто замечательно. Более того. Тройка Скала/Немерле/Шарп много выигрывают от того, что ведут исследования параллельно и пользуются результатами оных сообщя. VD>Я же не говорю, что F# маст дай и т.п. Я просто говорю, что МС пытается вкладыват деньги в язык который будет априори чужд большинству ее аудитории и даже не замечает языки которые действительно могли бы выстрелить.
VD>Пойми, что бесмысленно заниматься пенисометрией. F# не плохой язык. Его проблемы не в том, что у него фича-лист меньше чем у Немерле. Его проблема в том, что это на 99% ОКамл который уже не принят индустрией. Ну, сложный он для понимания простых смертных. Нельзя его рассматривать как на расширение того что было. А вот Немерле отлично прокатывает за C#++ на первой стадии. Когда еще там люди освоют паттерн-матчинг, алгеброические типы и разные компрешеншоны, но приемущества они получат сразу. И работать они смогут сразу. Этого у F# не будет никогда.
VD>Посему уж если давать бабки на F#, то глупо не дать их и на Немреле. Более того. Разумно было бы объеденить или хотя бы скоординировать усилия двух направлений. Вместе разультат мог бы оказаться куда лучше. Скажем F# и Немерле могли бы использовать одни и те же общие ФП-библиотеки. Код между ними стал бы переносим. А там уже не загорами фунциональные оптимизации в CLR (Нью-Васюки, значич ).
Сдается мне, что все-таки плохо убеждали. Или они прям надеялись, что добрый дядя из МС сам их заметит, придет, отсыпет бабла — резвитесь, мол, мужики?
Кстати, то что МС таки заметил существование ФП как такового, это уже повод для оптимизма. Если все-таки решатся подрихтовать под это дело CLR (эх, мечты-мечты), то и Немерле от этого выиграет.
VD>С точки зрения поддержки ФП оба языка прекрасны. И поиск среди них более идеального не большее чем попытка выдвать свои субъективные предпочтения за реальность.
О! На том и остановимся.
VD>Проблема в том, что компилятор и темболее разработка и развите языка — это довольно затратное дело. Вести его на голом энтузиазме очень не просто. И если будут поддерживать скажем F#, а не Немерле забьют, то в результате более перспективный Немрле может сдохнуть, а F# будет прозибать. Другими словами мы получим собаку на сене. Вроде что-то есть и это что-то забьет другое, но вот воспринято это будет очень узким кругом лиц.
Ну, в общем, поглядим. Не исключено, что из F# в итоге вылепят что-то очень похожее на Немерле.
Здравствуйте, Schade, Вы писали:
S>Разумно. Почему не стали — . Может, Москаль не так уж и стремился к тому, чтобы далее плотно работать с Немерле? Раз он там так плотно засел за систему доказательства теорем. Кстати, если им там все-таки на первом этапе выделили какое-то финансирование, что-нибудь в плане развития Немерле за этим последовало? Может, просто МС решил, что от этой команды отдачи не будет?
МС решил? О чем ты? Я же теб цитировал Хейльсберга "не нашел документации на сайте". Это при том, что весь сайт — это дукументация. В общем, всем просто все по барабану. Вот Симон был близок к "телу" и прорвался.
S>Его консервативность заключается в Камловом наследии? Не факт, что эта цель (частичная совместимость с Камлом) будет преследоваться в дальнейшей работе.
Как не крути — это факт. Не буду повторяться. Тут уже много было сказано по этому поводу.
S>Как мне кажется, чтобы монстр заметил интересный проект, этому проекту мало быть интересным. Надо еще достаточно громко кричать про себя, чтобы до нужных ушей долетело. И не только на RSDN — здесь нужных ушей МС-а увы нет. Так вот, представь себе, что ты ничего не знаешь про Немерле, и заходишь на nemerle.org. Какое первое впечатление? Что проект давно и успешно скончался. Вот так и Хейлсберг зашел, посмотрел, и, облегчив совесть, ушел. "Ничего не нашел".
Ага нужно кричать прямо в ухо причем тем кто деньги распределяет. Жаль я с ними лично не занаком .
S>1. Никто не запрещает аннотировать явно, там где это нужно
Дык заставляет или нет — это лирика. По жизни это приводит к выбору весьма неэффективных алгоритмов. Если в пакетном режиме, во время компиляции, это прокатывает, то в IDE уже нет.
S>2. Что есть то есть, IDE подтормаживает (хотя по субъективным впечатлениям просто что-то где-то очень криво написано)
Тут все уперается в алгоритмы и оптимизации.
VD>>Вот ОКамл обходится. Но ценой тому совсем хреновые сообщения об ошибках и очень плохая поддержка в IDE. S>Кстати, сообщения об ошибках, кроме совсем уж клинических случаев, вполне внятные.
Где? В ОКамле? Не смешите мои пятки. А в ФШарпе у членов типов надо специфицировать типы. Это и спасает.
VD>>Скромный вопрос. F# делает это для методов или локальных функций ака let-ов? S>let-ы — это не только и не столько локальные функции, функции уровня модуля тоже объявляются let-синтаксисом. Методы классов — по другому. Вывод типов работает и там, и там.
В дотнете не бывает ни модулей ни "функций уровня модуля". У него бывают методы.
Что-то не видел кода на F# чтобы в котором был объявлен метод без инлайн-тела и при этом он бы не содержал аннотаций типов.
S>Для локальных — конечно не имеет, они ведь как правило и вызываются из кода по 1-2 раза.
Дык а на уровне методов, типы нужно указывать явно. Так зачем тогда выводить обобщения? Чтобы программист не мог разобраться с тем что происходит?
S>Ой, да шо ви таки с Vermicious Knid'ом прикопались к этому несчастному примеру?
Дык потому прикопались, что пробовали писать на расхваливаемом тобой F#-е и постоянно и много пишем на Немерле. И выводы были однозначными. Писать на Немерле удивительно просто и ненапряжно. А вот когда пытаешся что-то изобразить на F#, то постоянно натыкашся на какие-то проблемы. Интеграция к F# вообще вырубается при наличии малейших ошибок в коде. Не скажу что Немерловая стабильна, но на ней хоть можно писть реальный код.
S> Неужели для того, чтобы проиллюстрировать сказанное на словах кодом нужно этот код брать из реального проекта, да еще и так, чтоб без изъяна?
Желательно. А то вот такие теоретики доказывают все что угодно, а по жизни все совсем наоборот. Это очень похоже на подход Вират. Докапается до какой-то фигни вроде того как должен оператор выглядить, и на основании этого делает вывод, что Оберон это круто, а остальное не достойно созерцания.
Напомню, что разговор начался с того, что ты тут стал утверждать, что писать в ФП стиле на F# значительно проще (или лучше, не помню), чем на Немерле.
S>Неправда твоя: S>
S>let result = ["String1";"String2";"Str3"].Filter (fun x -> x.Length > 5)
S>
S>Называется, найдите 10 отличий
А Filter — это фунция расширение или просто метод? В моем случае — это фунция расширение, то есть ты сам можешь добавить такие к любому типу. Например, в библиотеке есть фнкция FilterLazy которая работает в отложеном режиме.
S>Кстати, что случилось с нотацией _.Member?
Ничего. Работает как работал.
S>Почему вот так не работает? S>
S>def result = ["String1", "Str2", "String4"].Filter(_.Length > 5);
S>
А ты подумашь, что ты написал. Перевожу в форму лямбд:
def result = ["String1", "Str2", "String4"].Filter((x => x.Length) > 5);
Естествнно компилятор офигивает. Ты ведь пытаешься сравить функцию с целым, да еще передать результат туда где ожидается функция.
Констркция "_.Length" — это получение фунции из свойства некоторого объекта. Собственно не вижу особой проблемы в подобных случаях воспользоваться полноценной лямбдой. Оверхэд не вилик. Темболее что синтаксис лмябды с одним параметром в Немерле и C# 3.0 очень компактный:
def result = ["String1", "Str2", "String4"].Filter(x => x.Length > 5);
VD>>Боюсь, что это все проблемы адаптации Хиндли-Милера к дотнетной системе типов. Скрещивание ужа с ежом всегда было занятием не благодарным. S>Но всегда есть надежда, что от ежа и ужа родится корова, несущая золотые страусиные яйца в промышленных масштабах.
Ага. Всегда есть надежда, что завтра умрет неизвестный тебе дальний родственник-миллиардер и оставит тебе пару миллирдов в наследство.
S>Вот пусть и развиваются параллельно. А там, глядишь, и из Хиндли-Милнера, натянутого на .NET что приличное получится.
Не может там ничего приличного получиться. Система типов дотнета не совместима с ней. Это все припарки.
VD>>>>Примеры, плиз в студию, где F# дает что-то больше чем Nemerle. Тогда обсудим. Пока что это похоже на домыслы. VD>>Что-то ответ я так и не увидел? S>Да тут все будет спорным получаться. Хотя бы в силу того, что если на мой взгляд, F#-вый вывод типов это преимущество, то на твой — это недостаток.
А... Ну, ясно. В общем, это по русски называется — треп. Сказал бы често, что опыта в Немерле почти не имеешь и F# знаешь тоже не крепко, а заявления основаны на личных предубеждениях.
Приемуществ у F# никаких нет. Из недостатков — отсуствие макросистемы и плохая интеграция с дотнетом. Если вернуться в начало, то не думю, что надо быть семи пядий во лбу, чтобы понять, что код на Немерле будет понятен куда большему числу программистов просто потому, что он С-подобный и использует привычные идиомы и синтаксис.
S>Сдается мне, что все-таки плохо убеждали. Или они прям надеялись, что добрый дядя из МС сам их заметит, придет, отсыпет бабла — резвитесь, мол, мужики?
А кого убеждать то? Такое ощущение что тут везде бродят казначеи из МС.
S>Кстати, то что МС таки заметил существование ФП как такового, это уже повод для оптимизма. Если все-таки решатся подрихтовать под это дело CLR (эх, мечты-мечты), то и Немерле от этого выиграет.
Это да. Но хотелось бы на нем писать и проблем не занть, а не мучиться и вкалывать на то чтобы его до ума довести.
VD>>С точки зрения поддержки ФП оба языка прекрасны. И поиск среди них более идеального не большее чем попытка выдвать свои субъективные предпочтения за реальность. S>О! На том и остановимся.
Дык тебя за язык никто не тянул. Утверждения надо обосновывать...
S>Ну, в общем, поглядим. Не исключено, что из F# в итоге вылепят что-то очень похожее на Немерле.
Вряд ли. ОКамл там слишком глубоко сидит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>МС решил? О чем ты? Я же теб цитировал Хейльсберга "не нашел документации на сайте". Это при том, что весь сайт — это дукументация. В общем, всем просто все по барабану. Вот Симон был близок к "телу" и прорвался.
Просто сайтом никто не занимается. И гляда на фасад проекта создается впечатление, что проект помер. А чтобы убедиться, что это на самом деле не так, нужно приложить хоть какие-то минимальные, но усилия. Никто не захотел — итак неплохо кормят.
У того же F# — немалое коммьюнити. Сайт проекта не замер на месте, Дон регулярно сообщает о новостях. Есть несколько фанских блогов (Robert Pickering, Jon Harrop), издаются книги, есть шарашка Flying Frog Consultancy, которая издает журнал и оказывает консультационные услуги. О нем банально знает больше народу.
VD>Где? В ОКамле? Не смешите мои пятки. А в ФШарпе у членов типов надо специфицировать типы. Это и спасает.
Да не требует F# аннотирования типов для членов класса. Не требует.
VD>В дотнете не бывает ни модулей ни "функций уровня модуля". У него бывают методы. VD>Что-то не видел кода на F# чтобы в котором был объявлен метод без инлайн-тела и при этом он бы не содержал аннотаций типов.
Это издежки межвидового спаривания
Модуль в переводе на терминологию дотнета модуль — это static class, а функции уровня модуля — соответственно статические мемберы.
Метод без инлайн-тела — это только в interface-файлах. Кстати за это наследие Камла сам повбывав бы. Там это хоть смысл имело, а тут — опять таки зацепились за legacy код.
VD>Дык а на уровне методов, типы нужно указывать явно. Так зачем тогда выводить обобщения? Чтобы программист не мог разобраться с тем что происходит?
И все-таки она вертится! Тьфу, в смысле не требуется указывать типы явно для методов.
VD>Желательно. А то вот такие теоретики доказывают все что угодно, а по жизни все совсем наоборот. Это очень похоже на подход Вират. Докапается до какой-то фигни вроде того как должен оператор выглядить, и на основании этого делает вывод, что Оберон это круто, а остальное не достойно созерцания.
О как. Вирт у нас уже почти матерное слово . Не, это сам знаешь по чьей части (СГ). Я вроде никак не пытался заявить, что F# суть единственно верный и непокобелимый путь.
VD>Напомню, что разговор начался с того, что ты тут стал утверждать, что писать в ФП стиле на F# значительно проще (или лучше, не помню), чем на Немерле.
Утрируешь. Он начался с того, что я сказал, что это интересный проект, который не стоит на месте. Ну да, обмолвился, что Немерле, мол, осторожный шаг в сторону ФП, дык ведь со всех сторон обложился оговорками, что это лишь мое личное мнение.
VD>А Filter — это фунция расширение или просто метод? В моем случае — это фунция расширение, то есть ты сам можешь добавить такие к любому типу. Например, в библиотеке есть фнкция FilterLazy которая работает в отложеном режиме.
Есть аналогичная фича — type augmentation
type 'a List with
member x.FilterLazy f = Seq.filter f x
let result = [1;2;3;4;5;6].FilterLazy (fun x -> x>3)
(* result : int seq *)
Хотя, Немерловский FilterLazy, судя по всему, определен единожды для IEnumerable<T> и автоматом расширяет все типы, реализующие этот интерфейс? Тады +1. Хотя то же самое в F# выглядит не сложнее:
let result = [1;2;3;4;5;6] |> Seq.filter (fun x -> x>3)
VD>Не может там ничего приличного получиться. Система типов дотнета не совместима с ней. Это все припарки.
Ну, это сомнений не вызывает, думаю и у Syme, который как заправский зоотехник их скрещивал. Однако ж интересно, что попытаются сделать с этим дальше. Явно придется что-то под чего-то обрабатывать напильником.
VD>А... Ну, ясно. В общем, это по русски называется — треп. Сказал бы често, что опыта в Немерле почти не имеешь и F# знаешь тоже не крепко, а заявления основаны на личных предубеждениях.
Опыта в Немерле вообще не имею, а что, скрывал?
VD>А кого убеждать то? Такое ощущение что тут везде бродят казначеи из МС.
В том-то и дело, что здесь не бродят. А там, где этот зверь водится, RSDN особо не читают.
VD>Это да. Но хотелось бы на нем писать и проблем не занть, а не мучиться и вкалывать на то чтобы его до ума довести.
Да мучиться и вкалывать вообще мало кому хочется, однако ж...
Здравствуйте, Schade, Вы писали:
S>Утрируешь. Он начался с того, что я сказал, что это интересный проект, который не стоит на месте. Ну да, обмолвился, что Немерле, мол, осторожный шаг в сторону ФП, дык ведь со всех сторон обложился оговорками, что это лишь мое личное мнение.
Так вот, сам по себе Nemerle, без этой самой макросистемы, как мне кажется, представляет собой довольно осторожный шаг в сторону ФП. Возможно, соизмеримый с тем, чего планируется достигнуть в рамках эволюции C#, пусть даже и с заимствованием немерловых идей. F# все-таки более ориентирован на функциональный стиль программирования, пусть и ценой существенного отличия от мэйнстрима в синтаксисе, и, видимо, поэтому стал "более проходным" с точки зрения MS, поскольку в случае Nemerle получается некоторое дублирование.
И напомню, что ты так и ни продемонстрировал ни одного приемущества F# в сфере функционального программирования. Собственно это просто невозможно сделать. Все что предлагает ФП в Немерле есть. Это тебе и пытались объяснить.
VD>>А Filter — это фунция расширение или просто метод? В моем случае — это фунция расширение, то есть ты сам можешь добавить такие к любому типу. Например, в библиотеке есть фнкция FilterLazy которая работает в отложеном режиме. S>Есть аналогичная фича — type augmentation S>
S>type 'a List with
S> member x.FilterLazy f = Seq.filter f x
S>let result = [1;2;3;4;5;6].FilterLazy (fun x -> x>3)
S>(* result : int seq *)
S>
S>Хотя, Немерловский FilterLazy, судя по всему, определен единожды для IEnumerable<T> и автоматом расширяет все типы, реализующие этот интерфейс?
Да. А что нельзя сделать что-то вроде: S>
type 'a IEnumerable with
member x.FilterLazy f = ...
И вообще, что за за приколы? Выглядит как дописывание тела класса извне. Я что могу таким макаром и виртуальный метод залудить?
S> Тады +1. Хотя то же самое в F# выглядит не сложнее: S>
S>let result = [1;2;3;4;5;6] |> Seq.filter (fun x -> x>3)
S>
Это совсем не то, и таки опять таки поддерживается в Немерле. Реализовано как и оператор >> в классе функции:
public static @|> (a : 'p1, fac : 'p1 -> 'r) : 'r
{
fac(a)
}
public static @|> (a : 'p1, fac : 'p1 -> void) : void
{
fac(a)
}
VD>>Не может там ничего приличного получиться. Система типов дотнета не совместима с ней. Это все припарки. S>Ну, это сомнений не вызывает, думаю и у Syme, который как заправский зоотехник их скрещивал. Однако ж интересно, что попытаются сделать с этим дальше. Явно придется что-то под чего-то обрабатывать напильником.
Ну, а если обработать, то будет что-то новое. Вот в Немерле как раз так и поступили отказавшись от вывода обобщений. Я по началу тоже "страдал", но потом понял, что на практике это проблем не вызвает. Обобщеный код должен быть исключительно в библиотеках и хэлпер-модулях, а там описания типов очень оплезны. Так что по жизни получился весьма удобный подход. Конечно если говорить о гибридном языке скрещивающем ООП с ФП. Для Хаскеля это было бы видимо не очень красиво. В прочем, лично меня коробят системы типов основанные на Хидли-Милере. Конкретно коробит то, что в них идентификаторы сатновятся уникальными. Мне стандарнтая С++-подобная схема больше нравится (когда есть типы и их методы имеют локальные (внутри типа) имена).
VD>>А... Ну, ясно. В общем, это по русски называется — треп. Сказал бы често, что опыта в Немерле почти не имеешь и F# знаешь тоже не крепко, а заявления основаны на личных предубеждениях. S>Опыта в Немерле вообще не имею, а что, скрывал?
А тогда к чему было говорить процитированное выше? Собственно весь сыр бор из этого и пошел. Как можно заявлять о том что Х лучше преспособленно для Y чем Z если о Z только мельком слыхивал?
VD>>А кого убеждать то? Такое ощущение что тут везде бродят казначеи из МС. S>В том-то и дело, что здесь не бродят. А там, где этот зверь водится, RSDN особо не читают.
Боюсь, что эти звери сводки с Вол-стрит читают.
VD>>Это да. Но хотелось бы на нем писать и проблем не занть, а не мучиться и вкалывать на то чтобы его до ума довести. S>Да мучиться и вкалывать вообще мало кому хочется, однако ж...
Однако же на F# бабло дают, а не более перспективный в смысле популярности язык, нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Потом лично у меня нет даже сомнения, что если бы МС вбухал относительно микроскопические бабки в развитие Немреле и хоть немного помог ему морально (объявил бы о поддержке и малость пропиарил), то Немерле легко сошел бы за очередную псевдо-рпеволюцию созданную МС и навел бы немало шороха. В общем, я уверен, что караз этот язык пропер бы. Пусть он не заменил бы Шарп и темболее Васик, но то что он мог бы занять достойное место в линейке языков и смог бы преманить на свою сторону нехилую часть C#-щиков и C++-ников — это точно.
Мне кажется что спонсором может стать не только Майкрософт. Нужно лишь
1. Чаще обновлять главную страницу Nemerle.org. Чтобы мобилизировать интересующихся языком.
+ можно собрать ссылки в блогах про Nemerle и выложить их на Nemerle.org
+ завести свои блоги на сайте
+ ...
А то не понятно (особенно если ты не русскоговорящий)
а) где брать последнюю версию. Спасибо за ссылку http://nemerle.org/Download
б) куда задавать вопросы. Например в конфе мой вопрос по ASP.Net + Nemerle до сих пор лежит без ответа. Спасибо "Блудов Павел" помог.
2. Написать на главной странице или проспамить всяких там Mozilla или Apache Fundation на предмет спонсорской поддержки.
Есть еще предложение выложить проект на Codeplex или SourceForge...
A>Мне кажется что спонсором может стать не только Майкрософт. Нужно лишь A>1. Чаще обновлять главную страницу Nemerle.org. Чтобы мобилизировать интересующихся языком. A>+ можно собрать ссылки в блогах про Nemerle и выложить их на Nemerle.org A>+ завести свои блоги на сайте A>+ ...
A>А то не понятно (особенно если ты не русскоговорящий) A>а) где брать последнюю версию. Спасибо за ссылку http://nemerle.org/Download A>б) куда задавать вопросы. Например в конфе мой вопрос по ASP.Net + Nemerle до сих пор лежит без ответа. Спасибо "Блудов Павел" помог.
A>2. Написать на главной странице или проспамить всяких там Mozilla или Apache Fundation на предмет спонсорской поддержки.
A>Есть еще предложение выложить проект на Codeplex или SourceForge...
Еще вспомнил. Мой знакомый парень из Белоруссии сказал что они с другом используют Nemerle в коммерческих разработках. Всем довольны и если все выгорит то передадим 2000$ или Владу или IT. Так что можно пожертвования собирать с комьюнити в конце концов...
Здравствуйте, alvas, Вы писали:
A>Мне кажется что спонсором может стать не только Майкрософт. Нужно лишь A>1. Чаще обновлять главную страницу Nemerle.org. Чтобы мобилизировать интересующихся языком.
Это мы постараемся делать. Уже получены права на ее редактирования русской частью комьюнити. Первые изменения уже сделаны.
A>+ можно собрать ссылки в блогах про Nemerle и выложить их на Nemerle.org
Вся информация идет в конференции. Блоги, что были (но их мало) и так лежат на nemerle.org.
A>+ завести свои блоги на сайте
Да, уж. Без модных прбамбасов, сколь бы бессмысленными они ни были, не обойтись.
A>+ ...
Что-то мне подсказывает, что все это мало что даст с точки зрения поддержки языка. Тут нужны контакты. Почт уверен, что если пойти официальным путем, то мало что получится. В прочем попробовать все же стоит.
A>А то не понятно (особенно если ты не русскоговорящий) A>а) где брать последнюю версию. Спасибо за ссылку http://nemerle.org/Download
Вроде бы это мы уже поправили. Возможно надо сделать более заметнуд ссылку прямо сверху главной страницы.
A>б) куда задавать вопросы. Например в конфе мой вопрос по ASP.Net + Nemerle до сих пор лежит без ответа. Спасибо "Блудов Павел" помог.
Что за вопрос? В общем, то могу ответить "заочно". Ранее поддержка ASP.Net была реализована на минимальном уровне и по причине глюков не работала с ASP.Net 2.0. Однако о поддержке было напсано (и написано до сих пор) на сайте.
Будов реализовал (на сколько до конца не знаю) подержку ASP.Net 2.0 и Студии. Эта поддержка есть только в свежей CTP-версии. Она доступна на сайте языка (и у нас).
A>2. Написать на главной странице или проспамить всяких там Mozilla или Apache Fundation на предмет спонсорской поддержки.
Хм. Врдя ли это их проект. Но в принципе разумно. Надо бы подготовить бумажку и попробовать простучат все каналы что найдутся.
A>Есть еще предложение выложить проект на Codeplex или SourceForge...
Задолбаемся синхронизировать репозитории. Если только ссылку дать. В прочем, пиара в en-тете явно не хватает. Тут ты прва. Надо бы еще поговорить с Михалем, он вроде как сейчас общается с CLR team. Может через них можно закинуть удочку.
В обещм, согласен, что нужно бы подергаться на эту тему. А вось...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Мне кажется, что это не просто пиар. Нескольких моих знакомых (не индусов ) сейчас перебросили из C# compiler team на F#. Здесь приглашают поработать над проектом интеграции. Правда странно, что Product: Visual C#.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dotneter, Вы писали:
VD>>>Им и раньше не один человек занимался. К тому же эти люди были очень близки с реальными разработчиками из МС, напиример, с разработчиками из команды Шарпа. Вот только из тройки языков: Scala, Nemerle и F# последний является самым не проходным.
D>>Не проходным куда? На амазоне по нему можно например две книги найти в отличии от двух проходных.
VD>В мэйнстрим. Синтаксис и семантика ОКамла — это приговор для языка пытающегося стать популярным. Не будут (в массе своей) люди привыкшие к С/Паскале-подобному синтаксису ломать свое сознание и привыкать к МЛ-е подобному.
Ничего, если приспичит, то сломают, никуда не денутся.
VD>F# — это довольно прямолинейная адаптация ОКамла на дотнет, когда как Скала и Немерле — это новые языки взаимствовашие из МЛ-е подобных языков идеологию. В них все функциональные фичи адаптированны к ОО-миру дотнета/явы.
И что с того? Какое это имеет отношение к "проходимости" языка в мире Майкрософт?
В гугл-группе JVM languages Jon Harrop (автор OCaml/F# for Scientists и F# for Visualization, вроде как собирается написать подобную книгу по скале) описал аргументы, почему на его взгляд F# — более правильный функциональный язык, по сравнению со Скалой. Основные моменты — многословность, слабый вывод типов и слабая проверка полноты паттерн-матчинга, не очень убеждающе, но всёж...
P.S. Искать подходящее сообщение, куда можно было ответить лень, поэтому пишу в корень
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, G2, Вы писали:
К>[cut]
К>В гугл-группе JVM languages Jon Harrop (автор OCaml/F# for Scientists и F# for Visualization, вроде как собирается написать подобную книгу по скале) описал аргументы, почему на его взгляд F# — более правильный функциональный язык, по сравнению со Скалой. Основные моменты — многословность, слабый вывод типов и слабая проверка полноты паттерн-матчинга, не очень убеждающе, но всёж... К>P.S. Искать подходящее сообщение, куда можно было ответить лень, поэтому пишу в корень
А вот ещё он добавляет по поводу функциональных языков на .Net/JVM, приводится пример, что исключения в окамле в 6 раз быстрее чем в плюсах, но в F# они в 600 медленнее.
Мы уже победили, просто это еще не так заметно...
