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

Q>>Хаскель сокращает время «вдвое и больше» — по сравнению с чем? По сравнению с C++ весьма вероятно. По сравнению с .NET — сомневаюсь.

FR>Если под NET используется F# или Nemerle конечно сомнительно. Если же Шарп то по моему все таки Хаскель намного более выразительный язык.

Да, в том-то и дело, на производительность программиста влияет не только язык, а вся связка язык + библиотеки + рантайм, то есть в моём случае .NET-языки + FCL + CLR.
1) ЯП. Я не ограничен одним языком, могу один проект писать на C# (привычнее), соседний проект на F# (немного мощнее), тривиальный интероп (а не всякие адские байндинги через Си). Со следующей версии Студии F# будет иметь поддержку инфраструктуры: визарды, code-behind для GUI- и веб-проектов, etc.
2) Библиотеки. Очень удобно, когда всё под рукой: надо ли файл по FTP закачать, или поток создать, по файловой системе пройтись, XML распарсить, IoC-контейнер создать, сделать maintainable GUI, etc — т. е. все те рутинные вещи, которые надо часто использовать, программируя на любом ЯП. Я сомневаюсь, что Хаскель предоставляет более мощную библиотеку компонентов, чем .NET. Ну не будет в этом аспекте у Хаскеля «вдвое и больше».
3) Рантайм. В этот пункт можно включить производительность, переносимость, особенности сборки мусора, утечки ленивых цепочек, etc.

Ну и плюс некоторые другие параметры: документация, IDE, организованность сообщества, поддержка от производителя, etc.

По совокупности имеющейся информации о Хаскеле пока что я не могу сделать вывод о «вдвое и больше». Разве что так: «возможно, существует узкий круг задач, для которых производительность программиста на Хаскеле вдвое выше, чем .NET-программиста». Но никак не «для большинства задач Хаскель предоставляет прирост в производительности вдвое и больше».

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

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

VD>>Елы-палы. Вот тебе пример с LaPerouse. Ты ему что-то показал. Он сказал "О, да! Кажись ФП короче..." и уже через пост стал говорить тоже самое, что и в начале. Не ужели не видно, что вариант "смотрите как круто" не работает просто потому, что для них показанная крутизна не более чем непонятный код который всего лишь чуть короче оригинала?

К>Ммм, ты вот про это

Автор: LaPerouse
Дата: 29.01.09

:

К>

К>Начал рефакторить схему на на immutable, потому что в том виде, в котором она сейчас реализована со связкой по состоянию получается слишком печально.

Ну сделать ее чисто иммутабельной я и не пытался, да и делать такое в условиях java было бы безумием. Я просто внес в схему такие изменения, которые позволили бы создать иммутабельные интерфейсы к ней. С сохранением прежних мутабельных. В результате я теперь могу с ней работать двояко: иммутабельно и мутабельно. Иммутабельных алгоритмов у меня немного, ибо они адски дороги на java, ну нет здесь чудесных функциональных мапов с логарифмическим временем добавления. Но изменения, которые я внес в схему, сделали более прозрачными и императивные алгоритмы.

Таким образом, что я сделал:

1. Снес понятие идентити для нод. Теперь ноды (INode) — это только значения (с идентификатором). До этого нода имела обратную ссылку на Pin элемента, а пин элемента — ссылку на ноду. Теперь ссылка только в одну сторону от пина к ноде, которая, повторюсь, является значением без identity. Правда, пришлось учесть это в алгоритмах, которые полагались на instance ноды, например, оперировали с hashCode экземпляра ноды, теперь это заменено на node.isEqual по идентификтору.
2. Благодаря пункту 1 достаточно легко делается копирование схемы и участков схем.
3. Иммутабельные интерфейсы реализованы через getCopy() для схемы. То есть бекэндом идут те же самые императивные интерфейсы, которые создают копию, изменяют ее и возвращают. Они адски дороги, поэтому используются только в одном месте, где изменение на месте выливается совсем в хреновую кашу.

P.S. Почему-то VladD2 считает меня эдаким прожженным императивщиком, адептом императивного хардкода. Почему он так считает и из каким моих постов в этой теме можно сделать такой вывод абсолютно не понятно. Таким я был, возможно, два года назад, но вот уже больше года я признаю большие преимущества функционального подхода. Другое дело, я считаю, что все хорошо в меру.

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

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

LP>>Только ссылки потому то и нужны, чтобы адресовать изменяющиеся объекты c identity. Иначе их никто и ссылками не называл (то есть это название отражало бы лишь только способ размещения в памяти).
EC>А почему они обязательно должны быть изменяющимися?

Если объект неизменяющийся, тогда само понятие уникальности данного объекта исчезает и он становится неотличим от просто значения.
Скажем, представим себе знаменитое яйцо Колумба. Вопрос, то яйцо, которое Колумб умудрился поставить на кончик, надломив скорлупу на одном из его концов, это тот же объект "яйцо" или Колумб решил задачу уже совершенно для другого объекта? Колумб, будучи убежденным императивщиком, решил, что это тот же объект. Однако некоторые философы (видимо, фанаты Хаскеля) утверждают, что надломив кончик яйца, Колумб получил совершенно новый объект.

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

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

VD>Елы-палы. Вот тебе пример с LaPerouse. Ты ему что-то показал. Он сказал "О, да! Кажись ФП короче..." и уже через пост стал говорить тоже самое, что и в начале.

Ты, кажется, не совсем вник в суть нашего с lomeo спора. Я выдвинул утверждение, что существуют алгоритмы, которые наиболее хорошо реализуются именно императивно. В качестве доказательства этого тезиса был приведен императивный алгоритм, функциональная реализация которого была бы, как мне казалось, накладной. lomeo опроверг это доказательство, но приведя сопоставимую по сложности функциональную реализацию алогоритма. Но при этом мое утверждение не было опровергнуто, хотя и осталось недоказанным ввиду опровержения единственного доказательства, приведенного мной. И я не вижу причин пока чтоотказываться от своего пусть и чисто субъективного мнения о полезности императивщины.

VD>Не ужели не видно, что вариант "смотрите как круто" не работает просто потому, что для них показанная крутизна не более чем непонятный код который всего лишь чуть короче оригинала?

По обрывку приведенного алгоритма lomeo совершенно правильно восстановил суть задачи и привел правильную реализацию алгоритма. Я без проблем понял его код, и не отрицаю, ошибался по поводу конкретного примера. См. выше.

LP>Скажем, представим себе знаменитое яйцо Колумба. Вопрос, то яйцо, которое Колумб умудрился поставить на кончик, надломив скорлупу на одном из его концов, это тот же объект "яйцо" или Колумб решил задачу уже совершенно для другого объекта? Колумб, будучи убежденным императивщиком, решил, что это тот же объект. Однако некоторые философы (видимо, фанаты Хаскеля) утверждают, что надломив кончик яйца, Колумб получил совершенно новый объект.

И они правы. Яйцо с надломленным кончиком нельзя высидеть.

Нарушен, практически, базовый иинвариант яйца.

T>>Именно. "Серебряная пуля" — это средство, сокращающее труд программистов вдвое и больше.
Q>Хаскель сокращает время «вдвое и больше» — по сравнению с чем? По сравнению с C++ весьма вероятно. По сравнению с .NET — сомневаюсь.

По общению с программистами под .Net я могу сказать одно — скорость разработки у них такая же, как у программистов на Java, только восхищения рюшечками больше.

Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.

Взять, хотя бы, F#. Уж на что полезная вещь. Как велика его доля в современных проектах на .Net?

Q>>>Хаскель сокращает время «вдвое и больше» — по сравнению с чем? По сравнению с C++ весьма вероятно. По сравнению с .NET — сомневаюсь.
FR>>Если под NET используется F# или Nemerle конечно сомнительно. Если же Шарп то по моему все таки Хаскель намного более выразительный язык.
Q>Да, в том-то и дело, на производительность программиста влияет не только язык, а вся связка язык + библиотеки + рантайм, то есть в моём случае .NET-языки + FCL + CLR.

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

Q>1) ЯП. Я не ограничен одним языком, могу один проект писать на C# (привычнее), соседний проект на F# (немного мощнее), тривиальный интероп (а не всякие адские байндинги через Си). Со следующей версии Студии F# будет иметь поддержку инфраструктуры: визарды, code-behind для GUI- и веб-проектов, etc.

Процент кода в твоем проекте, написанный на F# конкретно каков?


Q>2) Библиотеки. Очень удобно, когда всё под рукой: надо ли файл по FTP закачать, или поток создать, по файловой системе пройтись, XML распарсить, IoC-контейнер создать, сделать maintainable GUI, etc — т. е. все те рутинные вещи, которые надо часто использовать, программируя на любом ЯП. Я сомневаюсь, что Хаскель предоставляет более мощную библиотеку компонентов, чем .NET. Ну не будет в этом аспекте у Хаскеля «вдвое и больше».

Юниксы предоставляют, всё же, не меньше, а как бы и не больше всего.

Q>3) Рантайм. В этот пункт можно включить производительность, переносимость, особенности сборки мусора, утечки ленивых цепочек, etc.

Q>Ну и плюс некоторые другие параметры: документация, IDE, организованность сообщества, поддержка от производителя, etc.

Haskell поддерживается Майкрософтом, не забывай.

Q>По совокупности имеющейся информации о Хаскеле пока что я не могу сделать вывод о «вдвое и больше». Разве что так: «возможно, существует узкий круг задач, для которых производительность программиста на Хаскеле вдвое выше, чем .NET-программиста». Но никак не «для большинства задач Хаскель предоставляет прирост в производительности вдвое и больше».

Я говорю примерно так: очень часто я могу переформулировать задачу так, что производительность программиста с использованием Хаскеля будет максимальной по сравнению с использованием других формулировок и средств. Более того, в общем и целом количество пользы для конечного пользователя от использования Хаскеля возрастает — можно реализовать больше фич.

Например, очень часто компоненты слишком сильно связывают, можно развязать. Очень часто возможно использовать DSL. Не менее часто DSEL. И тд, и тп.

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

T>По общению с программистами под .Net я могу сказать одно — скорость разработки у них такая же, как у программистов на Java, только восхищения рюшечками больше.

В C#, в отличие от Java, хоть есть делегаты и замыкания, а не всякие там IRunnable/ICallable. А, ну да, это ж рюшечки. Кстати, опиши вкратце методологию получения результата «скорость разработки у них такая же, как у программистов на Java». Т. е. что значит «по общению»? Или иначе: по каким признакам в общении можно сравнить эффективность разработчиков?

T>Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.

T>Взять, хотя бы, F#. Уж на что полезная вещь. Как велика его доля в современных проектах на .Net?

Скажи я про «долю в современных проектах» в отношении Хаскеля, ведь немедленно бы поднялся хай в духе «ну и что, мы не из миллиона мух, которые не ошиблись!» Так что давай про долю не надо. Эта доля, кстати, заметно повысится (прогноз, ага) с добавлением F# «в коробку».

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

T>В конечном счёте все определяется количеством строк, которые необходимо написать

Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?

Q>>2) Библиотеки. Очень удобно, когда всё под рукой: надо ли файл по FTP закачать, или поток создать, по файловой системе пройтись, XML распарсить, IoC-контейнер создать, сделать maintainable GUI, etc — т. е. все те рутинные вещи, которые надо часто использовать, программируя на любом ЯП. Я сомневаюсь, что Хаскель предоставляет более мощную библиотеку компонентов, чем .NET. Ну не будет в этом аспекте у Хаскеля «вдвое и больше».

T>Юниксы предоставляют, всё же, не меньше, а как бы и не больше всего.

Ага, ну да. Для каждого из перечисленных действий надо найти и собрать отдельную библиотеку, разбираться в отстойной (как правило) документации, и писать обёртки над Си.

T>Я говорю примерно так: очень часто я могу переформулировать задачу так, что производительность программиста с использованием Хаскеля будет максимальной по сравнению с использованием других формулировок и средств.

Заливать файлы на FTP приходится, как ты эту задачу не переформулируй. И общаться с базой данных, и создавать GUI, etc. У меня создаётся впечатление, что когда говорят об «абстрактной усреднённой задаче», у тебя в голове возникает какой-нибудь компилятор, который ты можешь показательно накидать на Хаскеле за пару минут. Ну переформулируй задачу «написать файловый менеджер» или «создать клиент для Джаббера» так, чтобы «производительность программиста на Хаскеле будет максимальной по сравнению с использованием других формулировок и средств». Должно быть, под «задачей» ты имеешь в виду что-то другое, тогда уточни.

T>Более того, в общем и целом количество пользы для конечного пользователя от использования Хаскеля возрастает — можно реализовать больше фич.

Больше фич по сравнению с чем? Почему — больше? Обоснуй.

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

LP>>Скажем, представим себе знаменитое яйцо Колумба. Вопрос, то яйцо, которое Колумб умудрился поставить на кончик, надломив скорлупу на одном из его концов, это тот же объект "яйцо" или Колумб решил задачу уже совершенно для другого объекта? Колумб, будучи убежденным императивщиком, решил, что это тот же объект. Однако некоторые философы (видимо, фанаты Хаскеля) утверждают, что надломив кончик яйца, Колумб получил совершенно новый объект.

T>И они правы. Яйцо с надломленным кончиком нельзя высидеть.

T>Нарушен, практически, базовый иинвариант яйца.

Может быть, но тут соль не в инвариантах. Речь о том, может ли считаться измененный объект, пусть и остающийся в пределах своих инвариант, новым объектом, или это суть старый объект. Различие между ФП и ИП уходят корнями в этот вопрос, а все остальное — следствие.

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

T>>В конечном счёте все определяется количеством строк, которые необходимо написать

Q>Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?

Нет код на Brainfuck не компактный, хотя сам язык очень даже.
Вот J да Хаскелю много форы может дать

Вообще на простых компактных языках, например на обероне или яве часто получается некомпактный код.

T>>И они правы. Яйцо с надломленным кончиком нельзя высидеть.
T>>Нарушен, практически, базовый иинвариант яйца.
LP>Может быть, но тут соль не в инвариантах. Речь о том, может ли считаться измененный объект, пусть и остающийся в пределах своих инвариант, новым объектом, или это суть старый объект. Различие между ФП и ИП уходят корнями в этот вопрос, а все остальное — следствие.

Объект можно менять функционально, если он линеен (уникален в смысле "uniqueness types" Clean — на него одна ссылка).

И вообще, Lambda — the ultimate imperative!

T>>В конечном счёте все определяется количеством строк, которые необходимо написать
Q>Ну да, поэтому лаконичности ради вместо «длинных» английских слов в Хаскель засунули лексемы типа «$», «::», «@», «:l», «_|_»? Если есть поддержка Юникод, можно вообще все токены иероглифами обозначить, и имена функций тоже. Количество строк уменьшится ⇒ читаемость возрастёт, так что ли? А Brainfuck, должно быть, самый читабельный язык?

Ты что-то с чем-то путаешь, по-моему.

Если я попытаюсь угадать твою мысль и ответить на неё, то да, запись

bracketed open close parser = rule id <* open <*> parser <* close

короче, чем

bracketed open close parser = do
   open
   x <- parser
   close
   return x

Да и наглядней, надо сказать.

Q>>>2) Библиотеки. Очень удобно, когда всё под рукой: надо ли файл по FTP закачать, или поток создать, по файловой системе пройтись, XML распарсить, IoC-контейнер создать, сделать maintainable GUI, etc — т. е. все те рутинные вещи, которые надо часто использовать, программируя на любом ЯП. Я сомневаюсь, что Хаскель предоставляет более мощную библиотеку компонентов, чем .NET. Ну не будет в этом аспекте у Хаскеля «вдвое и больше».
T>>Юниксы предоставляют, всё же, не меньше, а как бы и не больше всего.
Q>Ага, ну да. Для каждого из перечисленных действий надо найти и собрать отдельную библиотеку, разбираться в отстойной (как правило) документации, и писать обёртки над Си.

Нет. Есть куча специальных программ, по одной на каждое действие.

T>>Я говорю примерно так: очень часто я могу переформулировать задачу так, что производительность программиста с использованием Хаскеля будет максимальной по сравнению с использованием других формулировок и средств.
Q>Заливать файлы на FTP приходится, как ты эту задачу не переформулируй. И общаться с базой данных, и создавать GUI, etc. У меня создаётся впечатление, что когда говорят об «абстрактной усреднённой задаче», у тебя в голове возникает какой-нибудь компилятор, который ты можешь показательно накидать на Хаскеле за пару минут.

As I used to explain students on the first lecture of my old (IBM/360-oriented) "Compiler construction" course, this topic of computer science has much wider practical significance than one can expect just from the name of course. Actually compiler design is a pretty powerful programming paradigm (i.e. structuring the programming system as if it were a compiler for some new language) and more widespread usage of this paradigm might have substantial benefits. <b>To say it in other words this is programming technology applicable to a wide range of programming tasks.</b>

Выделено автором.

Q>Ну переформулируй задачу «написать файловый менеджер» или «создать клиент для Джаббера» так, чтобы «производительность программиста на Хаскеле будет максимальной по сравнению с использованием других формулировок и средств». Должно быть, под «задачей» ты имеешь в виду что-то другое, тогда уточни.

Я могу заливать файлы с помощью библиотеки, а могу с помощью ftp через скрипт. Последнее ещё и проще в отладке, поскольку создание скрипта достаточно декларативно.

Файловый менеджер у Булата Зиганшина во FreeArc, практически. На Хаскеле.

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

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

T>>Более того, в общем и целом количество пользы для конечного пользователя от использования Хаскеля возрастает — можно реализовать больше фич.
Q>Больше фич по сравнению с чем?

С Java. С C#.

Q>Почему — больше?

Потому, что получится быстрее писать. Разделение компонент получится выше.

Q>Обоснуй.

Вот.

Я сейчас скажу совсем страшную вещь. Её мало, кто понимает вообще.

Все могут использовать закачку файлов на ftp. Все могут использовать клиент к Джабберу. Все имеют доступ к необходимому для реализации файлового менеджера API.

У одних это проще, у других это сложней. Разница не настолько принципиальна, я виндовый GUI с drag-n-drop писал на ассемблере.

Но мало, кто может придумать, как сделать наиболее хитрую закачку, ту, в которой нуждаются реальные пользователи. Мало, кто может придумать причину, по которой закачка не нужна вообще в данном продукте. И мало, кто может придумать что-то такое, в чём пользователи даже ещё не нуждаются — не поняли, что нуждаются. Пусть даже эти пользователи — твои коллеги, взаимодействующие с твоей подсистемой.

(в случае клиента Джаббера — что мой клиент будет давать сверх того, что дают остальные?)

В случае двух последних "мало, кто", ответственных за высший класс программиста, речи о библиотеках не идёт вообще. Они, максимум, держатся в уме.

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

T>>По общению с программистами под .Net я могу сказать одно — скорость разработки у них такая же, как у программистов на Java, только восхищения рюшечками больше.
Q>В C#, в отличие от Java, хоть есть делегаты и замыкания, а не всякие там IRunnable/ICallable. А, ну да, это ж рюшечки.

Нет, это "попало в .Net недавно и не успело стать ещё широко используемым."

Q>Кстати, опиши вкратце методологию получения результата «скорость разработки у них такая же, как у программистов на Java».

Я не проводил измерения. Но скорость работы программистов не отличается даже в полтора раза.

Q>Т. е. что значит «по общению»?

Так, поговорили. Мне рассказали, я рассказал.

Q>Или иначе: по каким признакам в общении можно сравнить эффективность разработчиков?

Когда тебе рассказывают про конкурентов, например: "У конкурентов Java, и вот они писали столько-то. Мы справились быстрее, но у нас нет десяти их фич, но есть одна наша."

T>>Всё самое полезное попало в .Net недавно и ещё не успело стать широко используемым.
T>>Взять, хотя бы, F#. Уж на что полезная вещь. Как велика его доля в современных проектах на .Net?
Q>Скажи я про «долю в современных проектах» в отношении Хаскеля, ведь немедленно бы поднялся хай в духе «ну и что, мы не из миллиона мух, которые не ошиблись!» Так что давай про долю не надо. Эта доля, кстати, заметно повысится (прогноз, ага) с добавлением F# «в коробку».

Почему не надо?

Ты рассматриваешь .Net, как набор языков. Из которых F# самый мощный и активно продвигается поставщиком платформы. Я на это дело смотрю ровно так же.

Haskell это отдельный продукт, его никто не продаёт в нагрузку. До него ещё дорасти надо. Надеюсь, теперь ты на Хаскель смотришь так же.

Так что давай — вот сколько у тебя кода на легко доступном в .Net F#?

А планируешь ли ты на нём писать? А что планируешь писать?

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

VD>>Вот ты найдешь хотя бы одну ссылку когда бы ты возразил на подобные заявления поклонников хаскеля?

VE>Ну ежели ты думаешь, что человек должен возражать каждый раз, когда он не согласен, то тогда твой вывод обоснован. Заодно можно понять и твоё рвение в спорах

Да хоть разок. А то вот только сейчас ты сказал, что не всегда согласен с вышеупомянутым товарищем. А так казалось, что он просто громче других, но все остальные с ним согласны по всем пунктам.

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

VD>Да хоть разок. А то вот только сейчас ты сказал, что не всегда согласен с вышеупомянутым товарищем. А так казалось, что он просто громче других, но все остальные с ним согласны по всем пунктам.

Просто, в отличии от поклоников Немерле или Оберона, он совершенно неагрессивен

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

T>В конечном счёте все определяется количеством строк, которые необходимо написать и количеством ошибок в них. Это тема для отдельного обсуждения.

Не совсем так. Скажем наличие скобок строки конечно увеличивает, но ни на количество ошибок, ни на скорость создания кода, ни на скорость его чтения влияния не оказывает.

Вот количество ошибок и правда влияет на скорость создания законченного решения. Так как на их исправление может уйти больше время чем на написание кода. Именно по этому С++ серьезно проигрывает даже Яве (явно более ограниченной в выразительных возможностях по сравнению с С++). Причем загадки никакой тут нет. Просто Ява обеспечивает типобезопасность и сборку мусора. Этого достаточно чтобы сильно обогнать С++ по скорости получения рабочего решения.

T>Процент кода в твоем проекте, написанный на F# конкретно каков?

В моих современных проектах 98% кода пишется на... ну вы сами знаете на чем .

T>Например, очень часто компоненты слишком сильно связывают, можно развязать. Очень часто возможно использовать DSL. Не менее часто DSEL. И тд, и тп.

Ну, так и на других языках можно делать точно так же. Причем в Лиспе и Немерле (как в прочем в Темплэйт Хаскеле) есть боле мощьные средства ДСЛ-естроения, которые позволяют создавать ДСЛи практически любой сложности и не иметь ограничений в области производительности.

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

T>Ты рассматриваешь .Net, как набор языков. Из которых F# самый мощный и активно продвигается поставщиком платформы. Я на это дело смотрю ровно так же.
T>Haskell это отдельный продукт, его никто не продаёт в нагрузку. До него ещё дорасти надо. Надеюсь, теперь ты на Хаскель смотришь так же.
T>Так что давай — вот сколько у тебя кода на легко доступном в .Net F#?
T>А планируешь ли ты на нём писать? А что планируешь писать?

Ты прав в том что кода на F# катастрофически мало. Но с чем то связано? Мой список (по возрастанию значимости):
1. До сих пор интеграция F# со студией ниже плинтуса.
2. Язык, как и Хаскель, совсем не похож на привычные массам императивные языки. Намного проще выучить Яву после Дельфи или наоборот нежели выучить F# или Хаскель после Явы, Шарпа, С++, Дельфи и т.п.
3. F# очень плохо интегрируется с основой платформой так как его система типов (основанная на Хидли-Милере) сильно отличается от системы типов дотнета.

При этом F# не является самым мощным языком дотнета. Скажем его средства ДСЛ-естроения примитивны. А поддержка того же LINQ-а ниже плинтуса.

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

VD>>Не понял твоего посыла про синтаксис, но синтаксис очень даже причем. Когда людям не приходится ломать привычки в области синтаксиса и семантики базовой части языка (или приходится, но не много), то им намного проще освоить сам ФП, так как для них ФП становится всего лишь новыми фичами которые нужно "доучить".

FR>Синтаксис на самом деле ерунда, например перейти с си на паскаль несложно и возможно без всякой ломки.
FR>Вот то что нужно "доучить" как раз и сложно.

Дык разница между синтаксисом и семантикой С и Паскаля очень незначительная. Разница фактически описывается примитивными подстановками. А вот разница с ОКамлом получается очень значительная.

Мои наблюдения за людьми которые изучали F# и Немерле показали, что Немерле ими воспринимался намного проще и быстрее. Более того после знакомства с Немерле F# воспринимался уже намного проще, так как разница действительно оказывалась же почти в одном синтаксисе.

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

VD>>В случае скажем Хаскля или ОКамла человек вынужден сильно и одномоментно ломать свое сознание.

FR>В случае OCaml'а сознание практически не ломается, а хаскель как я понимаю требует такой ломки, например я в нем "все понимаю но разговаривать не могу"

Сдается мне, что ОКамл ты знаешь так же как и Хаскель. Так как языки фактически имеют общую базу. Отличие Хаскеля в незначительном синтаксическом различии, классах типов вместо привычного ООП и в ленивости. Это не так много, чтобы хорошо понимать дин язык и совсем плавать в другом.

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

К>Ммм, ты вот про это

Автор: LaPerouse
Дата: 29.01.09

:

К>

К>Начал рефакторить схему на на immutable, потому что в том виде, в котором она сейчас реализована со связкой по состоянию получается слишком печально.

Ты почитай все что вокруг. По-моему все очевидно.