PDF-ка на 42 страницы. (Ссылка найдена здесь, но там висит предупреждение, что в будущем URL может измениться. Пока же там можно найти ссылки на статьи, слайды и видео других докладов).
Любопытно. Одерски, похоже, придерживается мнения, что будущее за параллельностью. Посему нужно поддерживать ее в языке. Например, за счет специализированных типов коллекций. Еще один тренд, по его мнению, это DSL-естроение.
После просмотра презентации осталось несколько впечатлений.
Во-первых, все таки напрягает стиль кодирования функциональщиков – бесскобочная нотация, в которой выражение выглядит как последовательность слов. Так что сразу и не поймешь, где там функция, а где аргументы. Или же вся последовательность – это просто список аргументов. Ну, например:
def encode(number: String): Set[List[String]] = if (number.isEmpty) Set(List()) else { for { splitPoint <- 1 to number.length word <- wordsForNum(number take splitPoint) rest <- encode(number drop splitPoint) } yield word :: rest }.toSet |
Чем хороши языки вроде C++, Java, C#, Eiffel, D – почти не имея опыта работы с языком все-таки можно прочти сразу понять, что вызывается и с какими параметрами. А вот в функциональщине, если с ней плотно не работать каждый день – фигушки :( Ближе нужно быть к народу, господа ученые :)
Во-вторых, есть у меня сомнения в том, что такие штуки, как параллельные и персистентные коллекциидолжны быть введены раз и навсегда в языке (хотя я не уверен, что Одерски под персистентными имел в виду именно хранящиеся во внешней памяти). Имхо, такие вещи должны быть на уровне библиотек – попроще и посложнее, с ориентацией на различные задачи, с разным уровнем адаптации под нужды разработчиков. Хотя, если цель завлечь в параллельное программирование бесплатной первой дозой – тогда становится понятно. Мол, просто берешь стандартный SortedSet, потом просто вызываешь par и ты уже в Хопре! А что там – под кaпотом – разве кого-то сейчас это интересует, по большому-то счету? ;)
В-третьих, похоже, что я понял, о чем идет речь, когда люди масштаба Одерски говорят о DSL-естроении. Поскольку я-то, грешным делом, считал, что они продвигают “малое DSL-естроение”. Т.е. обычный разработчик вроде меня пишет какой-нибудь прикладной код и встречает какую-то более-менее формализуемую повторяющуюся задачку. Например, по работе с конфигурационными файлами. И решает работу с конфигом оформить в мелкий DSL, поскольку так удобнее, проще, да и вообще, лично мне больше нравится именно так.
Думаю, что такое мелкое DSL-естроение не есть хорошо, поскольку ведет к усложнению процесса сопровождения программы разными людьми, у каждого из которых есть собственное чувство прекрасного (подробнее см.Social Problems Of Lisp).
Но, полагаю, Одерски говорит о “большом DSL-естроении”, когда DSL-и разрабатываются не под конкретные мелкие сиюминутные нужды отдельных разработчиков. А как основа для больших проектов. Например, какая-то лаборатория нуждается в серии вычислительных экспериментов по определению надежности ленточных фундаментов. Экспериментов будет много, каждый довольно дорогой, поэтому от вычислительных программ требуется максимум эффективности. В сочетании с достаточной гибкостью изменения параметров и методов расчетов. Для чего лаборатория разрабатывает или заказывает у кого-нибудь DSL под свою задачу. Чтобы параметры экспериментов описывались на DSL-е, а описания затем транслировались в эффективный код, использующий различные технологии вроде MPI.
В такой интерпретации я ничего не имею против DSL-естроения. Хотя и не очень понимаю, чем здесь internal DSL лучше external DSL. Но это уже другой вопрос.
47 комментариев:
не только Одерски думает что будущее за параллельностью, вот например, выдержка из статьи Intel CTO: "Functional programming looks to be one of the foundations for parallel programming going forward with higher levels of abstraction and more automation of parallelism"
Чем хороши языки вроде C++, Java, C#, Eiffel, D – почти не имея опыта работы с языком все-таки можно прочти сразу понять, что вызывается и с какими параметрами
С таким же успехом можно сказать: "Чем хороши ocaml, sml, haskell, agda, coq -- почти не имя опыта работы с языком (а на самом деле, имея с каким-либо одним из них или похожим), можно понять, что вызывается и с какими параметрами".
Очень часто народ жалуется, что 'f a b c' выглядит менее привычно, чем 'f(a, b, c)'. Привычка, конечно, сильная вещь, но в реале получается заметно меньше знаков препинания, код выглядит чище, читается легче и пишется быстрее.
Ближе нужно быть к народу, господа ученые
И второе распространенное заблуждение -- что функциональные языки делают академики. Практически все mainstream-языки также разрабатывались в исследовательских отделах, просто они решали более распространенные проблемы. А в конечном итоге оказалось, что на функциональных языках не только компиляторы/доказыватели теорем удобнее писать, но и все остальное.
@Alex Ott:
Ну, Intel-у то ничего другого и не сказать. Новые процессоры им нужно продавать. Которые с большим количеством ядер. И эти ядра нужно чем-то загружать.
Презентацию еще не посмотрел, но скажу пару слов о персистентности.
В функциональном программировании понимается другое. Если своими словами, то это, когда значение можем повторно использовать при создании новых значений. Например, вставляя новый элемент в дерево, мы строим новое дерево, в котором используем элементы старого.
Вот, возможность повторно использовать существующие значения и есть это самое. Если бы не было иммутабельности, то такой возможности бы не было. И пусть меня поправят буквоеды на счет более точных формулировок :)
@Vladimir Shabanov:
>С таким же успехом можно сказать
Можно было бы, если бы сейчас доминирующими языками были функциональными. А это не так. И большинству (намного большему большинству) привычнее другая форма записи. И когда об удобстве большинства не задумываются приводя в качестве аргумента "а если привыкнуть, то все нормально", то это фигня. Не практично.
>Практически все mainstream-языки также разрабатывались в исследовательских отделах, просто они решали более распространенные проблемы.
Исследовательские отделы крупных корпораций (AT&T, Sun, MS) явно были ориентированны на другую среду, нежели чисто академические организации. Потому C, C++, Java и С# оказались успешными практическими инструментами. Как и Perl, Python и Ruby, которые вовсе не учеными делались.
@dsorokin:
Спасибо, теперь все стало на свои места.
Просто у меня еще воспоминания об ООСУБД живы, там персистентные (долговрменно хранимые) коллекции были нормальным явлением.
>С таким же успехом можно сказать
Можно было бы, если бы сейчас доминирующими языками были функциональными. А это не так. И большинству (намного большему большинству) привычнее другая форма записи. И когда об удобстве большинства не задумываются приводя в качестве аргумента "а если привыкнуть, то все нормально", то это фигня. Не практично.
Как раз очень практично. Люди задумываются о том, чтобы было удобно программировать, а не для того, чтобы было удобно большинству.
Большинству удобно вообще ничего нового не изучать.
Исследовательские отделы крупных корпораций (AT&T, Sun, MS) явно были ориентированны на другую среду, нежели чисто академические организации. Потому C, C++, Java и С# оказались успешными практическими инструментами. Как и Perl, Python и Ruby, которые вовсе не учеными делались.
Те же ocaml (MS один из спонсоров) и haskell (делается в MS) не менее успешные и практические инструменты. Просто менее популярные. А то, что их считают академическими уже очень давно является мифом.
@Vladimir Shabanov:
>Как раз очень практично. Люди задумываются о том, чтобы было удобно программировать, а не для того, чтобы было удобно большинству.
Вот именно, "а не для того...". Нет чтобы сделать так, чтобы большинству было удобно программировать.
Между тем, в новых языках не спроста зачастую используется С-подобный синтаксис. Поскольку фиг знает по какой причине C оказался ближе к народу, чем Pascal. Можно сетовать на то, что "народец мелкий попался", а можно просто учесть как данность.
>А то, что их считают академическими уже очень давно является мифом.
Опять не так. То, что они являются академическими -- это миф. А то, что их считают таковыми (я, например) -- это не миф. Это, опять таки, данность.
2Евгений: процессора с большим кол-вом ядер уже достаточно давно существуют, также как и SMP системы, но производители не говорили об ФП до этого...
@Alex Ott:
>процессора с большим кол-вом ядер уже достаточно давно существуют, также как и SMP системы, но производители не говорили об ФП до этого...
Они тогда находились в распоряжении тех, кто знал, что с ядрами/процессорами делать. Сейчас же нужно сбывать добро массовой публике. Плюс можно оседлать новый модный тренд (коим сейчас является ФП после того, как народ привык к ООП).
Поскольку фиг знает по какой причине C оказался ближе к народу, чем Pascal.
По причине того, что он короче. Кстати, по этой же причине 'f a b' лучше 'f(a, b)'.
Можно сетовать на то, что "народец мелкий попался", а можно просто учесть как данность.
Фишка такая, что если всегда делать также, как что-то делается сейчас, то никакого прогресса не будет.
Люди взяли и сделали так, как действительно удобнее, несмотря на то большинству пока кажется, что это не так.
>А то, что их считают академическими уже очень давно является мифом.
Опять не так. То, что они являются академическими -- это миф. А то, что их считают таковыми (я, например) -- это не миф. Это, опять таки, данность.
Согласен, неправильно написал. Большинство действительно считают их академическими, но таковыми они не являются.
Только я не понял твою позицию -- ты пишешь, что их академичность -- миф, но при этом считаешь их академическими.
@Vladimir Shabanov:
>По причине того, что он короче. Кстати, по этой же причине 'f a b' лучше 'f(a, b)'.
У краткости есть разумный предел. И если 'l m t' явно короче чем 'launch(nuclearMissile, whiteHouse)', то явно не так понятнее.
>Люди взяли и сделали так, как действительно удобнее, несмотря на то большинству пока кажется, что это не так.
У меня на этот счет несколько другое мнение. Медленно движущееся большинство при всех своих негативных сторонах, является отличным фильтром для слишком уж неудобных вещей. Если что-то вошло в массы, значит оно удобнее и жизнеспособнее.
>Только я не понял твою позицию -- ты пишешь, что их академичность -- миф, но при этом считаешь их академическими.
Я считаю их академическими потому, что как в высшем образовании, для них слишком высокий порог входа. Для людей с определенным складом ума (с ярко выраженной предрасположнности к математике) это не является проблемой. А вот мне приходится напрягаться. Собственно, степень напряжения и определяет "уровень академичности" -- чем больше напрягаешься, тем академичнее :)
гы-гы
в математике была (и до сих пор вроде) принята нотация f(a, b), а не f a b
при этом скобки для унарных функций могут часто опускаться, да, но не для бинарных
мне не понятно, как привыкшие к f `a` b в хаскеле смогут без напряга смотреть на скаловские f a b
как вариант, скаловские операторы могли бы выделяться цветом; есть ли ИДЕ, которое это умеет?
в математике была (и до сих пор вроде) принята нотация f(a, b), а не f a b
Есть такое, но математикам надо ручками писать, а руками однозначного пробела не поставишь.
мне не понятно, как привыкшие к f `a` b в хаскеле смогут без напряга смотреть на скаловские f a b
Если набор этих 'a' фиксированный, то их можно тупо как ключевые слова подсвечивать.
Но вообще у Скалы синтаксис тот еще.
> Есть такое, но математикам надо ручками писать, а руками однозначного пробела не поставишь.
еще раз гы-гы
ln x от lnx на письме различаем? значит, ставим-таки пробелы ручками (я во всяком случае ставлю, точнее, пишу ln линейно связно)
теперь по сути вопроса -- что должна означать последовательность f a b
мне кажется, что без дополнительных знаков она должна означать что-то, где роли всех букв одинаковы, т.е. как скаловский бинарный оператор, так и хаскельный вызов функции не подходят
как вариант, возможна все-таки скаловская трактовка, только тогда синтаксис дожен быть все же чуть разным, например x MAX y, или, ладно, x max y, если иде может подстветить max по-другому
хаскельный вариант тоже имеет право на жизнь, если к нему добавить хотя бы 1 символ, например так f: a b
но скаловский все-же лучше, т.к. подстветка операторов в скале выделила бы больше знаков, чем подстветка только первого члена в хаскеле -- значит, там потенциально больше информации
пробежал твой пост
http://vshabanov-ru.blogspot.com/2008/07/blog-post.html
мое мнение: мы не ссым, а видим, что языкам типа хаскеля требуется серьезная переделка, или как минимум серьезная обработка напильником
и даже скале, автор которой весьма реалистичен, напильник все равно требуется
> Есть такое, но математикам надо ручками писать, а руками однозначного пробела не поставишь.
еще раз гы-гы
ln x от lnx на письме различаем? значит, ставим-таки пробелы ручками (я во всяком случае ставлю, точнее, пишу ln линейно связно)
В общем про пробелы -- это было предположение. Толком не знаю, почему и откуда появилась f(a,b).
Есть еще такая фишка, что в функциональных языках есть карирование, т.е. f a b -- это на самом деле (f a) b -- последовательное применение одноаргументных ф-ий, а у ф-ий с одним аргументом скобки опускаются.
А в целом про синтаксис -- это дело привычки. Реально, никакой путаницы вообще не возникает. Выражения ограничены либо скобками, либо какими-нить знаками препинания, либо ключевыми словами. Т.е. выражение легко выцепляется глазами и по пробелам сразу видно где ф-ия, где аргументы.
Я (и не только я) считаю, что вызов ф-ии без лишнего синтаксического шума гораздо легче читается и пишется (ну и более правильно отражает идею, что f a b = (f a) b).
мое мнение: мы не ссым, а видим, что языкам типа хаскеля требуется серьезная переделка, или как минимум серьезная обработка напильником
Интересно. А что там надо серьезно переделывать?
@Vladimir Shabanov:
>Есть еще такая фишка, что в функциональных языках есть карирование, т.е. f a b -- это на самом деле (f a) b
Ну вот, для тех кто уже в теме f a b = (f a) b. А для начинающих это постоянное выяснение -- "f(a, b)", "(f(a))(b)", "f(a(b))", f().a().b() и т.д.
В ФП и так заморочек хватает, а тут еще и синтаксис к которому привыкать нужно. В общем, нужно сильно хотеть, чтобы сквозь это все продираться при обучении.
Тут напрашивается аналогия с Lisp-ом: лисперы говорят, что они скобочек не замечают. И нет основания им не верить. Важно другое -- какой процент потенциальных разработчиков плюнули на Lisp как раз из-за того, что вначале скобочек было слишком много? :)
@Евгений: синтаксис - это конечно классная отмазка чтобы не изучать новое :-)
P.S. в той же Clojure, скобочек бывает меньше чем в Java ;-) Просто они расположены не так...
@Alex Ott:
>синтаксис - это конечно классная отмазка чтобы не изучать новое :-)
Если цель -- изучать новое, то да, отмазка. :)
А если нужно писать софт, то вовсе не факт, что изучение нового окупиться.
Позволю себе привести глупую аналогию. Допустим, что когда-то вам дали дубинку и показали, как ей отбиваться от хулиганов. Работает этот способ отлично -- пару раз по горбу дашь и тебя оставляют в покое. Да, есть неудобство -- носить ее с собой нужно, достать нужно успеть, опять же, не переоценить собственные возможности.
И тут кто-то говорит -- а ведь можно и без дубинки, просто голыми руками и с большим эффектом -- просто хороший быстрый удар ребром ладони в шею и всех делов. Ничего не нужно с собой носить, ты всегда готов к отражению агрессии.
Правда за внешней простотой и эффективностью будут спрятаны годы упорных тренировок. Кто-то через это пройдет. И начнет ценить достигнутую простоту и будет стремиться к еще большим достижениям. А кто-то плюнет, найдет себе более интересное времяпрепровождение и продолжит носить дубинку.
Причем, что интересно, оба будут успешно отбиваться от гопников. И, не исключено, что обладатели дубинок даже реже будут подвергаться агрессии, т.к. сама дубинка будет приличным сдерживающим фактором :)
Мой опыт (включая наблюдение за разными людьми) показывает, что изучение новых языков (точнее подходов к программированию), всегда себя оправдывало с точки зрения производительности разработчика - более ясного кода, меньше багов и т.д.
P.S. на YaC2011 был хороший доклад Алексея Воинова (мы вместе работали когда-то) на эту тему - посмотрите
@Alex Ott:
Вот именно, подходов. C ФП можно познакомиться и на примере Erlang-а с нормальным синтаксисом.
Кроме того, сами хаскелисты не могут использовать хаскель для всего. Если не ошибаюсь, Шабанов и Зефиров сейчас в одной конторе работают. Но GUI пишут не на хаскеле, а на C# -- таки битие определяет сознание. И если нужно забивать гвозди, то изучать микроскоп не обязательно :)
Erlang реализует один из подходов к ФП, Хаскель - другой, и т.д. И в знании обоих нет ничего плохого.
Я тоже пишу часть времени на С++, но от того, что я часто применяю приемы из разных ФЯ, код часто короче, ошибок сильно меньше и т.д.
@Alex Ott:
Похоже, тему эту нужно раскрыть в отдельной заметке. Поскольку здесь у нас точки зрения, вероятно, довольно сильно отличаются.
Но исходный мой посыл остается таковым: если бы в языках, ведущих родословную от ML, применялся более привычный большинству программистов синтаксис, то это сделало бы процесс изучения языка чуть-чуть, но проще. А значит и сами языки были бы привлекательнее.
Поскольку замшелый императивщик может привыкнуть, скажем, к OCaml-овским let x = y in ...
Только понять почему это должно настолько сильно отличаться от C-шного стиля декларирования сущностей внутри блока не сможет.
Большой плюс Scala в этом смысле то, что они у себя этих ML-ных корней не используют настолько сильно. Хотя бы объекты объявляются привычным образом.
Если программист не может понять, то он не программист, а обезьянка, которая делает строго по образцу...
В мире куча непривычного - разные культуры и т.п.
@Alex Ott:
Ну значит я пример такой обезъяны, которая, тем не менее, успешно устроилась в индустрии и ест хлеб с маслом.
Поскольку не могу понять, ни причин использования именно такого вида деклараций переменных/констант в C, ни аналогичных причин для Pascal, ни аналогичных для OCaml. Да и пофигу, если честно. Только вот декларации в C и Pascal оказываются понятнее и привыкать к ним даже не приходится -- раз и все. В отличии от.
Но GUI пишут не на хаскеле, а на C# -- таки битие определяет сознание.
Это продавленное свыше решение. Прототип гуя был сделан на хаскеле за 3-4 месяца. Аналогичного функционала на C# потом не могли добиться где-то 1.5 года (бОльшим кол-вом народа).
У нас в проекте две большие части -- моделирование и рисование схем. Рисование схем делает отдельная команда на C#. По-этому, пришлось и остальную часть гуя делать на C# для однородности.
Не стоит радоваться тому, что "вона хаскелисты тоже на C# пишут". Это вынужденная мера. Использование C# всячески ограничивается до уровня "тупой интерпретатор того, что скажет хаскель". И, в целом, C# реально очень сильно тормозит проект.
Хотя, кроме C# у нас еще ООБД есть, которая нафиг не нужна, но это идея генерального, так что также вынуждены использовать. Есть часть на java -- VHDL-транслятор, который ужаснейшее глюкало, но его разработчик абсолютно уверен, что java это отличный инструмент. У команды схемного редактора есть еще проблемы с видением/процессами.
В общем типичный real world, который может кому-то кажется нормальным, но для меня это местами прямо дикость какая-то. Хотя потихоньку какой-то результат получается, но ооочень потихоньку (с точки зрения хаскелиста).
@Vladimir Shabanov:
>В общем типичный real world
Так в том-то все и дело. Что из-за real world все упирается либо в отсутствие людей, либо в наличие уже существующих наработок, либо в специфику предметной области (из-за которой конкретный язык либо вообще не имеет значения, либо есть выбор только из одного) и т.д.
Посему знание, скажем, Haskell-я может быть как Феррари в деревенском сарае -- красиво, но ездить не где.
@Alex Ott:
изучение новых подходов -- да, весьма оправдано, но не для обычного разработчика, а скорее для разработчика ЯП
когда и если будет сделан язык, позволящий в рамках привычного синтаксиса выражать новые подходы, эти подходы будет оправдано изучать обычным разработчикам
(это я не к тому, чтобы поменьше писать в блогах о пользе новых подходов -- как раз об этом писать надо побольше)
@dsorokin
> Вот, возможность повторно использовать существующие значения и есть это самое. Если бы не было иммутабельности, то такой возможности бы не было.
такая возможность есть и без иммутабельности (через коллекции с поддержкой персистентности), и именно в этом я вижу реалистичную и перспективную идею одерского
@Vladimir Shabanov
> Интересно. А что там надо серьезно переделывать?
1. см. чуть выше; я например считаю, что персистентностью надо управлять не только компилятору, но и программисту -- он может затребовать, сколько thunk-ов может висеть в памяти и т.п., а еще может даже написать свой оптимизированный вариант персистентной коллекции *специально* для данного юз кейса
дальше -- вообще все то, что в планах у одерски :-)
вот например стандарный прокол хаскеля из-за отсутствия системы эффектов: http://www.haskell.org/haskellwiki/DDC/EffectSystem
короче: основной профит ФП это персистентность, но она нужна не всегда, а управляемо
опять-таки, вовсе не всегда именно персистентность нужна для распараллеливания; например, откат транзакции может делаться через (персистентно) сохраненившуюся копию, а может делаться через алгебраически обратную операцию -- и тут ваш хаскель кмк спасует
> Аналогичного функционала на C# потом не могли добиться где-то 1.5 года (бОльшим кол-вом народа).
не поверю, что причина в языке -- скорее, в существенно низшей квалификации разрабов
в сишарпе достаточно возможностей (в т.ч. языков), чтобы лепить интерфейсы; да и не нужно нихрена вообще для лепки интерфейсов, кроме рефлексии и атрибутов
да, могут быть идеи, которые в сишарпе не выражаются (точнее, сишарп их верифицировать не сможет), но при лепке интерфейсов это преодолевается грубой силой / тупой работой
вот ты лучше скажи, как сделать аналоги аннотаций в хаскеле: http://www.linux.org.ru/forum/development/4550090
s/(в т.ч. языков)/(в т.ч. языковых)/
1. см. чуть выше; я например считаю, что персистентностью надо управлять не только компилятору, но и программисту -- он может затребовать, сколько thunk-ов может висеть в памяти и т.п., а еще может даже написать свой оптимизированный вариант персистентной коллекции *специально* для данного юз кейса
Вообще, в хаскеле есть strictness annotation-ы и форсирование вычислений, а также переменные. Т.е. не хочешь thunk-ов и персистентости -- пожалуйста.
дальше -- вообще все то, что в планах у одерски :-)
А что, например? Я мельком просмотрел презентацию -- многое из того, что там только в планах или только-только появилось, в хаскеле есть уже достаточно давно.
вот например стандарный прокол хаскеля из-за отсутствия системы эффектов: http://www.haskell.org/haskellwiki/DDC/EffectSystem
Системы эффектов -- очень экспериментальная вещь. Есть отдельные языки с эффектами, но в них обычно кроме эффектов ничего толком нет. Этот DDC пилят уже достаточно давно, но вроде как он до сих пор сырой и экспериментальный.
В хаскеле еще много чего нет (тех же зависимых типов, например), но не стоит называть это проколом. Хаскелл все-таки очень практичный язык, и туда стараются добавлять только то, что действительно облегчит жизнь большому кол-ву людей (хотя многие штуки достаточно экспериментальные).
короче: основной профит ФП это персистентность
это профит чистых структур данных, для которых фп необязателен.
опять-таки, вовсе не всегда именно персистентность нужна для распараллеливания;
Для распараллеливания хорошо отсутствие побочных эффектов, из-за которых становится важным порядок выполнения.
например, откат транзакции может делаться через (персистентно) сохраненившуюся копию, а может делаться через алгебраически обратную операцию -- и тут ваш хаскель кмк спасует
Почему-же спасует? Ничто не мешает сделать обратную операцию.
> Аналогичного функционала на C# потом не могли добиться где-то 1.5 года (бОльшим кол-вом народа).
не поверю, что причина в языке -- скорее, в существенно низшей квалификации разрабов
Действительно, квалификация была ниже, да еще и нужно было использовать упомянутую выше ООБД. Однако, кроме гуя, там хватает логики (делается IDE с симулятором/отладчиком и пр.), а вот логику писать там долго (да и с гуем большие проблемы из-за того, что народ очень любит гуй в дизайнере делать, а не программно).
да и не нужно нихрена вообще для лепки интерфейсов, кроме рефлексии и атрибутов
а для чего в гуе рефлексия и атрибуты?
да, могут быть идеи, которые в сишарпе не выражаются (точнее, сишарп их верифицировать не сможет), но при лепке интерфейсов это преодолевается грубой силой / тупой работой
грубая сила / тупая работа занимают время.
вот ты лучше скажи, как сделать аналоги аннотаций в хаскеле: http://www.linux.org.ru/forum/development/4550090
А зачем? Чем не устраивает генерация кода из структуры БД?
> А зачем? Чем не устраивает генерация кода из структуры БД?
ыыыы! прочти тред еще раз
> а для чего в гуе рефлексия и атрибуты?
нда...
чтобы делать гуй программно
>Действительно, квалификация была ниже,
вот и выплывают настоящие причины
>да еще и нужно было использовать упомянутую выше ООБД.
весело там у вас
> а вот логику писать там долго
тааак... значит, там на сишарпе писали не только гуй?
так или иначе, сишарпа должно хватать для гуя даже с небольшой логикой
> грубая сила / тупая работа занимают время.
но зачастую это быстрее или даже выгоднее, учитывая квалификацию разрабов
часто тупая работа решает, например нажать 100 раз на клавишу вместо того, чтобы выяснить, как записать макрос, записать клавиатурный макрос вместо программирования функции, ... вплоть до твоих случаев
я не говорю, что так должно продолжаться и дальше, но это реальность
я не очень уверен, но по-моему ты неправ, активно различая персистентные структуры данных и отсутствие побочных эффектов
если их следует различать, приведи пример
если у нас есть алгоритм, в императивной форме юзающий побочный эффект в Х, то мы можем сделать его чистым, если Х будем передавать доп. параметром туда, кому побочный эффект нужен, и сделаем Х персистентным для тех, кому видеть побочный эффект не надо
обатное утверждение, кмк, тоже верно, хотя я и не уверен
> Этот DDC пилят уже достаточно давно, но вроде как он до сих пор сырой и экспериментальный.
из чего не надо делать вывод про системы эффектов
этот DDC пилят настолько редко, что я не нашел там человеческого (а не обзорного) описания их системы эффектов
то, что монада ИО, призванная защищать от неверных действий, не дает выполнить верные -- с моей точки зрения приговор для хаскеля; я однозначно ему предпочту с++, который, хотя и не защищает в ряде случаев, все же дает возможность сделать правильно, когда это надо
система эффектов -- это must have современного языка
@Евгений Охотников
Поскольку замшелый императивщик может привыкнуть, скажем, к OCaml-овским let x = y in ...
Только понять почему это должно настолько сильно отличаться от C-шного стиля декларирования сущностей внутри блока не сможет.
Ну есть же пример того же питона тоже с весьма своеобразными блоками и видимостью, который сишники осваивают без проблем и быстро.
Насчет Прототип гуя был сделан на хаскеле за 3-4 месяца. Аналогичного функционала на C# потом не могли добиться где-то 1.5 года (бОльшим кол-вом народа). это нормально, даже если прототип и релиз на одном и том же языке. Если прототип по трудоемкости не отличается на порядок в более легкую сторону от релиза это уже не прототип по моему.
@Rustam:
>Ну есть же пример того же питона тоже с весьма своеобразными блоками и видимостью, который сишники осваивают без проблем и быстро.
Может потому, что эти своеобразные правила не сразу проявляются? Что-то я не припомню, чтобы в простых программах на Питоне были заморочки по поводу объявления переменных.
Ну и Питон - все-таки больше императивный язык :)
@Евгений Охотников
Ну вот, для тех кто уже в теме f a b = (f a) b. А для начинающих это постоянное выяснение -- "f(a, b)", "(f(a))(b)", "f(a(b))", f().a().b() и т.д.
В ФП и так заморочек хватает, а тут еще и синтаксис к которому привыкать нужно. В общем, нужно сильно хотеть, чтобы сквозь это все продираться при обучении.
В ML образных это не просто синтаксис а одна из базовых вещей которые необходимо изучать в первую очередь.
В сишном синтаксисе не говоря уже о C++, тоже кстати заморочек хватает, взять хотя бы такую тоже вполне базовую вещь как объявление не тривиальных типов указателей.
@Евгений Охотников
В питоне сразу проявляются блоки кода и утиная типизация, и очень быстро сильно отличная от тех же С++/C# объектная система.
@Rustam:
Особенности синтаксиса есть везде. Речь о другом. Если человеку, который знает, скажем, Паскаль, дать кусок алгоритма, реализованного на C++ или C#, то паскалист хотя бы в общих чертах будет понимать, какие действия выполняются в этом куске -- циклы, вызовы функций и пр.
Поэтому то переходы с Паскаля на С, затем на C++, после чего на Java/C# -- это лишь уточнение и привыкание к некоторым деталям.
Переход же с какой-нибудь Java на функциональный язык (из ML семейства) требует намного больших училий из-за двух вещей:
1. Думать нужно по другому (но чтобы научиться думать по другому требуется много времени).
2. Привыкнуть к синтаксису.
И если от п.1 никуда не денешься (даже переход с C на Питон этого требует и происходит не сразу), то вот по поводу п.2 я уверен в том, что будь и флагманских ФЯ более привычный синтаксис, то мало потеряв в "выразительности", они бы больше приобрели в популярности.
> А зачем? Чем не устраивает генерация кода из структуры БД?
ыыыы! прочти тред еще раз
Там, в основном, бред. Что именно надо почитать? А лучше просто скажи, чем не устраивает генерация кода из БД?
> а для чего в гуе рефлексия и атрибуты?
нда...
чтобы делать гуй программно
Даже не могу себе представить, как это выглядит. Это можно использовать для загрузки гуя из описания, но при чем тут программный гуй?
тааак... значит, там на сишарпе писали не только гуй?
Дак на нем среду разработки делают (создание/редактирование проектов, интеграция с компиляторами/симулятором/отладчиком).
так или иначе, сишарпа должно хватать для гуя даже с небольшой логикой
Вот только на это его и хватает.
я не очень уверен, но по-моему ты неправ, активно различая персистентные структуры данных и отсутствие побочных эффектов
Из 2-го следует первое, но не наоборот.
если их следует различать, приведи пример
DiffArray.
> Этот DDC пилят уже достаточно давно, но вроде как он до сих пор сырой и экспериментальный.
из чего не надо делать вывод про системы эффектов
А я и не делал никаких выводов. Просто оно пока еще слишком сыро и узко, чтобы вставлять.
то, что монада ИО, призванная защищать от неверных действий, не дает выполнить верные -- с моей точки зрения приговор для хаскеля;
Верные -- это какие?
если у нас есть алгоритм, в императивной форме юзающий побочный эффект в Х, то мы можем сделать его чистым, если Х будем передавать доп. параметром туда, кому побочный эффект нужен, и сделаем Х персистентным для тех, кому видеть побочный эффект не надо
Передавать параметром эффект? Что-то не понял
система эффектов -- это must have современного языка
А можно пример такой системы эффектов?
@Alex Ott:
>Мой опыт (включая наблюдение за разными людьми) показывает, что изучение новых языков (точнее подходов к программированию), всегда себя оправдывало с точки зрения производительности разработчика - более ясного кода, меньше багов и т.д.
Поднял эту тему в отдельной заметке: http://eao197.blogspot.com/2011/09/progflame.html
P.S. на YaC2011 был хороший доклад Алексея Воинова (мы вместе работали когда-то) на эту тему - посмотрите
Пока не нашел этого выступления. Ни видео, ни текста :(
я надеюсь, что скоро они выложат его...
@Евгений Охотников
И если от п.1 никуда не денешься (даже переход с C на Питон этого требует и происходит не сразу), то вот по поводу п.2 я уверен в том, что будь и флагманских ФЯ более привычный синтаксис, то мало потеряв в "выразительности", они бы больше приобрели в популярности
По моему это или никак, или очень мало влияет на популярность, что и показывают например Scala, Немерле и Dylan.
Просто на фоне первого пункта второй требует на порядок меньше усилий на освоение.
Отправить комментарий