Здравствуйте, Mystic, Вы писали:
M>Тогда возникает другой вопрос: а в чем тогда цимес?
Я его описал выше. Если вы, например, захотите на F# писать, то там тоже все по другому и не так как в c#.
Если вам F# изучить как два пальца об асфальт, то возможно вам Nemerle и не нужен. Хотя, я думаю, что все будет как раз наоборот.
С Nemerle функциональщину изучать намного проще. А дальше или на F# или так и останетесь на Nemerle.
А главный цимес в том что нужно знать как минимум 3-4 языка с разной парадигмой чтобы чувствовать себя профессиональным программистом.
Здравствуйте, Mystic, Вы писали:
M>Не сказал бы. Была одна попытка, в результате которой приходилось по документации выискивать аналоги конструкций C#. Ну а потом, посмотрев на мой исходник, мне сказали, что я пишу императивно и неправильно. А как правильно не сказали
Ну, так смог же? Пусть не правильно, пусть немного подумать пришлось, но ведь смог?
Ну, а чтобы научиться писать правильно нужно к этому стремиться. Если будет реальная задача, то потихонечку освоишь все премудрости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mystic, Вы писали:
M>Основная проблема в том, что приходится лазить по документации в поисках того, как та или иная конструкция реализуется средствами Nemerle. Плюс бороться с возникающими ошибками. Что достаточно утомительно и не видно никаких преимуществ. Когда я понял, что в результате код на Nemerle будет полностью идентичный сишарповскому, я задал вопрос: а в чем смысл моих страданий? Этот риторический вопрос окончательно погасил мой энтузиазм.
перед тем как начать читал? VD>В прочем, даже если возникли проблемы, то почему было не задать вопрос в форуме?
Он судя по всему спрашивал, причем у тебя
А его в ответ закидали тухлыми помидорами на тему "да у тебя вообще код кривой". Так вот и потерял человек интерес к Немерле
Здравствуйте, hardcase, Вы писали:
H>4. А также строгая статическая типизация и вывод типов по Хиндли-Милнеру.
Ага. Только последние два дядьки тут совершенно не причем. Система вывода типов у Nemerle уникальная. Некоторые идеи заимсвованы у авторов Скалы, но алгоритм Nemerle сильно отличается. А если учитывать, что его и дальше развивали (лично я к этому делу руку приложил), то про Хиндли-Милнера можно даже не вспоминать.
Вот в F# используется модифицированный Хиндли-Милнер. Из-за этого они вынуждены требовать от пользователя явно задавать последователь файлов в проекте и кода внутри файла. Я слышал, что из-за в F# даже папки внутри проекта не реализовали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Много слышу в последнее время про Немерле. Почитал — кроме хорошего метапрограммирования ничего не пишут. А>Можно в нескольких предложениях сказать о плюсах Немерле?
Нет, нельзя. И не потому, что я злой или не словоохотливый. Просто чтобы понять эти преимущества нужно понять суть тех возможностей которые есть в языке, а это значит нужно понять сам язык.
Тут уже не мало говорилось, что одним из преимуществ Nemerle является то, что на нем можно писать как на C#. Но на самом деле — это само по себе не преимущество. Это упрощает вхождение в язык. Если ты знаешь C#, то начать писать на Nemerle можно за пару вечеров.
Но чтобы извлекать из Nemerle преимущества, которые по сравнению с C# в нем несомненно есть и которые могут со временем весьма сильно поднять производительность труда и упростить решение сложных зада, нужно освоить то что отличает Nemerle от C#, и научиться применять эти отличия на практике.
Второй этап более долгий. Если начать программировать можно уже через 2-3 дня, то на освоение функциональных возможностей уйдет не менее месяца (постоянного программирования). При этом лучше всего иметь под рукой человека который будет производить ревизию твоего кода и подсказывать какие возможности Nemerle можно применить в тех или иных местах, чтобы сделать программу более простой и короткой.
Макросы — это следующий уровень. В прочем простые макросы можно начать писать чуть ли не сразу. Но действительно серьезно поднять уровень абстракции в программе могут только не тривиальные макросы. А они требуют не малого опыта.
Думаю, что средний программист знакомый с C# может освоить Nemerle до уровня "хорошо" где-то за год.
Последовательность действий должна быть такая:
1. Осваиваем программирование на Nemerle в стиле C#. На это обычно уходит от одного дня до пары недель (в зависимости от способностей, отводимого времени и стремления).
2. Изучение маленьких прелестей Nemerle. Где-то 1-3 недели.
3. Изучение функциональных возможностей и изменение стиля кодирования с нарочита императивного на умеренно функциональный. На этом этапе программист начинает понимать, что вместо массивных циклов можно писать очень компактные и удобные контракции. Понимает, что кроме ООП есть варианты и паттерн-матчинг и т.п.
4. Достижение некоторого уровня мастерства в применении ФП и начало баловства с макросами. Главная проблема на этом этапе не увлекаться игрушками. Болезнь все на базе функций высшего порядка нормально на этом этапе, но к сожалению она затагивает .
5. Более глубокое погружение в макросы и осознание того факта, что синтаксические абстракции при грамотном применении могут давать отдачу значительно большую чем ООП или структурное программирование.
6. Программист хорошо владеет ФП, ООП и понимает с чем едят макросы. Далее начинается самосовершенствование которому нет конца.
Ответ на вопрос дойдет ли конкретный человек до шестой ступени во многом определяется желанием (стремлением). Дойдя до шестого пункта человек неизбежно изменяется. Но начинает думать по другому.
Понятно, что если за плечами есть серьезный опыт ФП (любой клон МЛ) и/или Лиспа, то все может выглядеть по другому. Но для человека с C/C#/Java/C++ базой путь будет примерно таким.
О первых преимуществах ты сможешь судить только закончив третий пункт. А реальную мощь языка осознаешь только потратив на Nemerle тот самый год и дойдя до шестого пункта.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Он судя по всему спрашивал, причем у тебя
Он у меня в обсуждении совершенно вводного материала что-то спрашивал. На что я ему резонно заметил, что или он читает не тот материал, или он слишком многого хочет. Введение есть введение оно не позволяет сразу сесть и писать сложные задачи.
ВВ>А его в ответ закидали тухлыми помидорами на тему "да у тебя вообще код кривой".
Ну, это отдельное спасибо нашему горячему парню Синклеру.
ВВ>Так вот и потерял человек интерес к Немерле
Дык здесь вроде не религиозное объединение.
Мы не не превращаем в веру. Мы с удовольствием делимся своими впечатлениями и мыслями. Все кто считает их несостоятельными могут выбрать себе что-то другое. Или не выбирать вовсе.
Парадокс Блаба не позволяет аргументированно убедить программиста в преимуществах языка.
Я конечно могу привести примеры, но они окажутся или каким-то сахаром без которого, по мнению того кто его не пробовал, можно легко пережить или чем-то непонятным.
Такими фичами являются макросы $-строк позволяющие вывести весьма сложно-форматировнный текст в одной короткой строке, или макрос PEG-парсера который позволяет описать грамматику прямо внутри своего кода и получить статически типизированный парсер (пример калькулятора на его основе). Первый пример ($-строки) может показаться легким сахарком, хотя на практике он очень удобен. Второй чем-то сложным и непонятным. Но и то и другое еще можно объяснить, так как это пример расширения языка повышающие его мощность. А вот как объяснить людям преимущества паттерн-матчинга? Я пробовал — это почти бесполезно. Вот когда они проникнутся им, то и объяснять будет ничего не надо. А до тех пор — для непосвященного — это будет "непонятная хреновина без которой он (не посвященный) всю жизнь обходился и дальше спокойно проживет".
Вот такие дела.
По сему убеждать кого-то можно только из спортивного интереса (ради флэйма и задора). Толку от этого ноль. Я для себя решил, что это нужно мне и этого уже достаточно чтобы я этим занимался. C# я перерос. Он мне стал скучен. В С++ я разочаровался полностью. Хаскель слишком заумного и медленно. Лисп слишком уныло и запущено. Пролог пригоден только для ряда задач... В общем, надо просто писать софт на новом языке. Если я окажусь прав (в чем я в общем-то не сомневаюсь), то и сторонники будут только прибывать со временем. Кто-то возможно плюнет, а кто-то со временем вернется. Но если вещь стоящая, то всегда найдутся уверенные в себе люди которые захотят получить конкурентное преимущество.
По сему лучше тратить время не на уговоры и объяснения, а на развитие продукта. Единственное что может остановить Nemerle — это остановка его развития.
Мне кажется, что у многих кто боится использовать Nemerle на практике главная загвоздка не в том, что они не понимают преимуществ Nemerle, а в том, что они боятся, что авторы плюнут на него и он умрет не родившись. Самое смешное, что этот страх и провоцирует такой сценарий. Поляки явно ждали быстрых лавров. Но они ошибались. Языки завоевывают популярность десятилетиями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется, что у многих кто боится использовать Nemerle на практике главная загвоздка не в том, что они не понимают преимуществ Nemerle, а в том, что они боятся, что авторы плюнут на него и он умрет не родившись. Самое смешное, что этот страх и провоцирует такой сценарий. Поляки явно ждали быстрых лавров. Но они ошибались. Языки завоевывают популярность десятилетиями.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Т.е. зная Шарп, вы уже можете писать на немерле — достаточно потратить лишь совсем немного времени, чтобы разобраться в небольших отличиях в синтаксисе.
ВВ>Где здесь "борьба" и что здесь утомительного?
Спасибо большое
А борьба была в том, что прочитав
Nemerle не поощряет императивный стиль
я решил его и не использовать. Основным документом был этот, но все равно дело шло медленно. Сейчас уже не помню, но вроде сообщения об ошибках часто вызывали недоумение. Более того, постоянно искал, где бы можно было применить какую-нить функциональную фишку, но не находил... Плюс, возможно, отладка...
Общая идея была такая: заюзать Nemerle при разработке утилит, задача которых генерить код на C++ (Delphi, Ada), возможно на основании некоторого входного файла. Т. е. основная нагрузка в них это парсинг + вычисления. Вроде бы как выбор правильный, но в целом уже на вычислениях возникли проблемы: (1) перевод некоторых императивных конструкций (2) прозраность сообщений об ошибках (3) отладка (4) скорость компиляции... По первому пункту меня все тянуло вместо массивов использовать списки, и большую часть времени я изучал всякие возможности для работы с ним и пытался реализовать все в терминах списков. По второму пункту иногда при опечатке сообщение об ошибке ставило меня в тупик. По четвертому пункту надобыло разбираться с работой ngen.exe, а большого желания не было. Решил мужественно терпеть По третьему возможно интеграция с MS Studio? В общем хватало вывода отладочных сообщений, чтобы не разбираться с чем-то еще...
Здравствуйте, Mystic, Вы писали:
ВВ>>Где здесь "борьба" и что здесь утомительного? M>Спасибо большое M>А борьба была в том, что прочитав M>
Nemerle не поощряет императивный стиль
Поощряет или нет, но в императивном стиле на Немерле писать практически так же удобно, как и на Шарпе — особенно по сравнению с тем же F#, который, к слову, тоже позиционируется как гибридный язык.
Да и это, не понимаю, чем императивный код на Немерле хуже точно такого же императивного кода на Шарпе.
M>я решил его и не использовать. Основным документом был этот, но все равно дело шло медленно. Сейчас уже не помню, но вроде сообщения об ошибках часто вызывали недоумение. Более того, постоянно искал, где бы можно было применить какую-нить функциональную фишку, но не находил... Плюс, возможно, отладка...
Вообще сама постановка вопроса — "искал где можно применить какую-нибудь функциональную фишку, но не находил" — довольно странная. На самом деле все наоборот. Как раз в реальных-то проектах зачастую очень сложно найти место, где реально надо применить какую-нибудь "императивную фишку", т.е. где действительно нужно явно указывать последовательность шагов, описывать алгоритм, а не просто декларировать намерения.
Тут Влад в соседнем посте приводил "стадии обучения" Немерле. Если Немерле — первый ФЯ, то его изучение — это в первую очередь изучение новой парадигмы, а описанным тобой методом ее "не взять". Можешь просто писать на Немерле как и на Шарпе — будет по крайней мере не хуже, получишь "сверху" небольшие вкусности, вроде коллекции весьма полезных стандартных макросов.
Но ведь правда — посмотри, отличий не так много. Например, VB.NET в этом плане — как императивный язык — гораздо сильнее отличается от Шарпа. А на моей памяти люди без проблем переключались между выбенетом и шарпом. К тому же идеология Шарпа и Немерле в каком-то плане похожа — если нет 100% уверенности, что программист написал именно то, что хотел — то выдавать ошибку или по крайней мере ворнинг. (В отличие от выбенета, где идеология — непонятно, что хотел программист, так давайте догадаемся).
А ФП лучше, на мой взгляд, изучать по книжкам/статьям. И тут не столь важно, на каком там конкретно языке будут примеры к статьям. По Немерле, конечно, материалов не так много, как по другим языкам. Но ФП оно и в Африке ФП, его нельзя применять как фишку, это просто другое средство для достижения того же, что делается в Шарпе средствами class based OOP.
А "функциональные фишки" — это в C#, где они сделаны через жопу делегаты и прочие радости жизни.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вообще сама постановка вопроса — "искал где можно применить какую-нибудь функциональную фишку, но не находил" — довольно странная. На самом деле все наоборот.
Наверное тут кроется или большая разница в мышлении, или разные решаемые задачи. Время от времени я делаю набеги на вотчину функциональных языков (Haskell, Nemerle) читаю книги, статьи, и вроде даже все понимаю. Смотря на функциональный код я могу на время стать компилятором и перевести его в результате в набор машинных инструкций, и только тогда понять, что он делает. Могу решать простые упражнения (например из книги Душкина).
Но как только я ставлю перед собой реальную задачу, все функциональные языки уводят меня совсем не туда. Мне везде начинают мерещиться списки, которые я не знаю потом как обрабатывать. Мерещаться ленивые вычисления, которые непонятно как организовать. В случае обычных языков программирования решение задачи у меня совершенно подсознательно переводится в императивные конструкции. В этом отношении мне наиболее нравится Ada: все строго, четко.
Вот приведенный мною пример. Да, конечно его можно императивно один в один реализовать на Nemerle. Но где хоть одно хотя-бы одно маленькое преимущество??? И как этот пример реализовать на чистом ФЯ без mutable? Меня можно расстрелять, но я этого не сделаю. Или это будет очень долгий труд...
Ну а в случае между VB.NET и C# я больших различий в них не вижу, с другой стороны я и не эксперт в .NET Мне больше нравятся C, Delphi, Ada. И при программировании под .NET я обычно использую некоторое подмножество этих языков, которое эквивалентно названным выше.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Вообще сама постановка вопроса — "искал где можно применить какую-нибудь функциональную фишку, но не находил" — довольно странная. На самом деле все наоборот. M>Наверное тут кроется или большая разница в мышлении, или разные решаемые задачи.
Слушай, ну о какой понятности императивного кода может идти речь, если я переделывал на Немерле твой PokerHouse, но при этом ни хрена не понял, что вообще этот код делает. Да и сам бы ты как быстро разобрался в подобном коде от другого программиста, где из всей документации — название пространства имен? Это не камень в твой огород, просто ты написал типичнейший императивный код — есть куча деталей, показывающих как именно нужно решить задачу, какие именно нужно сделать вычисления, каким именно образом их сделать, но что за задача решается при этом не видно
И это типичная проблема с императивщиной.
Если бы мне достался в наследство такой код с заданием, скажем, исправить какой-нибудь баг, то первое, что я бы потребовал — это тех. документацию. Если бы тех. документации вместе с комментариями к коду не было, то потянулись бы к док., описывающему требования (дай бог, чтобы он хоть был). А часто оказывается так, что прочитав требования, просто переписываешь такой код с нуля — может быть, даже в очень похоже стиле — просто потому что в собственном коде ориентироваться проще, и ты в итоге так даже время сэкономишь.
Знаешь легендарная тенденция новых программистов на проекте "все переписать" именно отсюда происходит. И она зачастую вполне оправдано. Потому что часто вообще очень трудно понять, что тут делает какой-то конкретный кусок кода, зачем он нужен — может, он там в каком-нибудь частном случае используется для какой-нибудь хитрой проверки, чтобы в этом частом случае избежать очень хитрого бага. Но без комментария такой код попросту теряет ценность.
Другой вопрос — функциональный подход, который есть подвид декларативного. Где ты не описываешь, как именно тебе нужно производить вычисления, а показываешь *что* конкретно ты хочешь получить. Такой код по определению более понятный
M>Время от времени я делаю набеги на вотчину функциональных языков (Haskell, Nemerle) читаю книги, статьи, и вроде даже все понимаю. Смотря на функциональный код я могу на время стать компилятором и перевести его в результате в набор машинных инструкций, и только тогда понять, что он делает. Могу решать простые упражнения (например из книги Душкина).
Может быть, просто во время таких забегов (Хаскель я бы вообще пока не трогал, честно), ты пропустил какие-то важные концепции и теперь без них понимать код сложно? Хотя бы те же алгебраические типы, паттерн матчинг, операции с фукнциями вроде композиции, каррирования?
В ФП вообще есть достаточно ограниченный набор концепций — можно по пальцам пересчитать — нужно просто в них разобраться, именно *понять*, и все. Все остальное будет сводиться к специфике синтаксиса того или иного языка.
M>Но как только я ставлю перед собой реальную задачу, все функциональные языки уводят меня совсем не туда. Мне везде начинают мерещиться списки, которые я не знаю потом как обрабатывать. Мерещаться ленивые вычисления, которые непонятно как организовать. В случае обычных языков программирования решение задачи у меня совершенно подсознательно переводится в императивные конструкции. В этом отношении мне наиболее нравится Ada: все строго, четко.
Ленивости и в современном Шарпе хватает, причем в Шарпе она почему-то опять сделана через жопу... непонятно даже через что сделана.
Списки проще всего обрабатывать через паттерн матчинг или хотя бы даже обычным перебором.
M>Вот приведенный мною пример. Да, конечно его можно императивно один в один реализовать на Nemerle. Но где хоть одно хотя-бы одно маленькое преимущество???
Тебе говорят — как только начнешь писать на Немерле, то поймешь и преимущества.
Ты говоришь — я могу начать писать на Немерле, когда пойму преимущества.
Это нормально. Этакий замкнутый круг. Тут есть два варианта:
1. Забить
2. Поверить на слово тем, кто говорит о преимуществах и начать писать. Учитывая, что и правда для перехода на "императивный Немерле" требуется день от силы.
Решать тебе
M>И как этот пример реализовать на чистом ФЯ без mutable? Меня можно расстрелять, но я этого не сделаю. Или это будет очень долгий труд...
Задача, которую ты описывал, — это по сути реализация компилятора. Это чуть ли не "родная" для ФП задача. Для нее очень очень хорошо подходят алгебраические типы и ПМ. Я думаю несложно нагуглить примеры, показывающие решение схожих задач.
Здравствуйте, Mystic, Вы писали:
M>Смотря на функциональный код я могу на время стать компилятором и перевести его в результате в набор машинных инструкций, и только тогда понять, что он делает.
Вот в этом и проблема.
Пока не научишся понимать функциюнальщину не компилируя код в машинные инструкции толку от функциональных языков для тебя не будет.
Тебе нужно усвоить разницу между императивщиной и функциональщиной.
Императивщина это последовательность команд изменяющих данные.
Функциональщина это последовательность функций отображающих одни данные в другие данные.
Тебе нужно сменить первый способ мышления на второй. Тогда ты поймешь функциональщину.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Посмотрел еще раз твой первоначальный код. Все же до конца не уверен, что правильно понял задачу. Есть комбинация карт и надо вычислить некий числовой эквивалент, как бы силу комбинации.
В покере не силен, как и в Немерле, но на функциональный манер получается что-то типа:
using System;
using System.Console;
using CardCombination;
using Card;
using CardSuit;
enum CardSuit
{
| V = 13
| Q = 14
| K = 15
| T = 16
}
variant Card
{
| Plain { v: int }
| High { s: CardSuit }
public GetRank() : int
{
match (this)
{
| Plain(v) => v
| High(s) => s :> int
}
}
}
variant CardCombination
{
| Single { c: Card }
| Pair { c: Card }
| TwoPair { p1: Pair; p2: Pair }
| Three { c: Card }
| Street { c: Card }
| Flush { c: Card }
| Full { c: Card }
| Four { c: Card }
| StreetFlush { c: Card }
public GetRank() : int
{
match (this)
{
| Single(c) => c.GetRank()
| TwoPair(p1, p2) => p1.GetRank() + p2.GetRank()
| Pair(c) with r = 0x20 | Three(c) with r = 0x80
| Street(c) with r = 0x100 | Flush(c) with r = 0x200
| Full(c) with r = 0x300 | Four(c) with r = 0x400
| StreetFlush(c) with r = 0x500 => c.GetRank() + r
}
}
}
module Program
{
Main() : void
{
def GetRank(c) {
| [] => 0 | x::xs => x.GetRank() + GetRank(xs)
}
def cards = Pair(High(V)) :: Single(High(Q)) ::
Single(Plain(6)) :: Single(High(T)) :: [];
_ = WriteLine(GetRank(cards));
_ = ReadLine(); //Да, а обновление я так и не скачал
}
}
Здравствуйте, VladD2, Вы писали:
H>>Нашел: Type Inference with Deferral VD>Ага. Но человеческим это можно назвать только если ты из научной среды .
А вот, кстати, совсем не праздный вопрос.
Учитывая куда (на майкрософт) ведет ссылка, описывающая алгоритм вывода типов в языке, не является ли это бомбой под будущем языка? Ведь они там могут и запатентовать его (тьфу-тьфу-тьфу и по дереву постучал).
Здравствуйте, AngeL B., Вы писали:
AB>А вот, кстати, совсем не праздный вопрос. AB>Учитывая куда (на майкрософт) ведет ссылка, описывающая алгоритм вывода типов в языке, не является ли это бомбой под будущем языка? Ведь они там могут и запатентовать его (тьфу-тьфу-тьфу и по дереву постучал).
Я не юрист, но мне кажется, что код, который уже выпущен под опен-сорс лицензией, нельзя "отозвать обратно". Если я, скажем, придумаю некий алгоритм и открою исходники, то все, после этого я могу конечно патентовать, мне никто не мешает, но засудить тех, кто уже использует мои исходники (вместе с алгоритмом) я не могу, так они получили все это добро по вполне законной лицензии.
Но могу ошибаться, тонкостей не знаю
Здравствуйте, AngeL B., Вы писали:
AB>А вот, кстати, совсем не праздный вопрос. AB>Учитывая куда (на майкрософт) ведет ссылка, описывающая алгоритм вывода типов в языке, не является ли это бомбой под будущем языка? Ведь они там могут и запатентовать его (тьфу-тьфу-тьфу и по дереву постучал).
Ссылка ведет на работу Михаля Москаля — одного из авторов Немерле. Эта же работа доступна на сайте Немерла.
Весь код Немерла опубликован под MIT-подобной лицензией и стало быть может меняться как угодно. Что до алгоритмов, то в нашей стране они даже не патентуются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>В покере не силен, как и в Немерле, но на функциональный манер получается что-то типа:...
В императивной версии разбираться просто в лом, но если они соотвествуют, то это хорошая демонстрация того насколько программа, будучи переписанная в функциональном стиле (даже без излишних вывертов), становится понятнее и короче.
Кстати, в Немерле особо рулит (на мой взгляд) табличное форматирование. Сравни...
Без него:
variant CardCombination
{
| Single { c: Card }
| Pair { c: Card }
| TwoPair { p1: Pair; p2: Pair }
| Three { c: Card }
| Street { c: Card }
| Flush { c: Card }
| Full { c: Card }
| Four { c: Card }
| StreetFlush { c: Card }
public GetRank() : int
{
match (this)
{
| Single(c) => c.GetRank()
| TwoPair(p1, p2) => p1.GetRank() + p2.GetRank()
| Pair(c) with r = 0x20 | Three(c) with r = 0x80
| Street(c) with r = 0x100 | Flush(c) with r = 0x200
| Full(c) with r = 0x300 | Four(c) with r = 0x400
| StreetFlush(c) with r = 0x500 => c.GetRank() + r
}
}
}
С ним:
variant CardCombination
{
| Single { card : Card }
| Pair { card : Card }
| TwoPair { pair1 : Pair; pair2 : Pair }
| Three { card : Card }
| Street { card : Card }
| Flush { card : Card }
| Full { card : Card }
| Four { card : Card }
| StreetFlush { card : Card }
public GetRank() : int
{
match (this)
{
| Single(c) => c.GetRank()
| TwoPair(p1, p2) => p1.GetRank() + p2.GetRank()
| Pair(c) with r = 0x20
| Three(c) with r = 0x80
| Street(c) with r = 0x100
| Flush(c) with r = 0x200
| Full(c) with r = 0x300
| Four(c) with r = 0x400
| StreetFlush(c) with r = 0x500 => c.GetRank() + r
}
}
}
Ну, и однобуквенные имена полей, на мой взгляд, не плохое решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Как раз в реальных-то проектах зачастую очень сложно найти место, где реально надо применить какую-нибудь "императивную фишку", т.е. где действительно нужно явно указывать последовательность шагов, описывать алгоритм, а не просто декларировать намерения.
