Было бы хорошо, если бы я решил написать весь свой Ruby, как если бы это был Haskell?


10

Учитывая, что у Ruby есть хорошие встроенные возможности работы со списками - уменьшить, отобразить, выбрать, собрать и т. Д. Он имеет Procs, Blocks и Lambdas, и имеет хорошую поддержку итераций ( eachсемейство), было бы плохим решением при разработке, если я попытаюсь написать все мои вещи в Ruby максимально функциональным способом? Специально для кода, у которого мало ввода-вывода или нет (таким образом, менее очевидные побочные эффекты)?

Я изучаю Haskell (так называемый «настоящий» язык хакера) и влюблен в его способ делать вещи - я люблю Ruby, но думаю, что это может быть еще веселее, когда в него проникает больше дух Haskell (ну, не так ли? Руби заимствовать / многому научиться у него в первую очередь?)

Конструктивное руководство приветствуется ...


13
Почему бы тогда просто не написать на Хаскеле?

1
Я написал бы только на Хаскеле, но Руби не так уж и плох, чтобы заслуживать полного отказа. Мне нравится тот факт, что я могу использовать его при написании сценариев, и для многих быстрых экспериментов мне нравится взламывать вместе при изучении искусственного интеллекта. Но, вероятно, еще и потому, что я только начал изучать Haskell, возможно, в конце концов последую вашему совету :-)
nemesisfixx

2
Я не понимаю, почему вы запрашиваете разрешение переполнения стека. Если вы пишете код, которым собираетесь делиться с другими в команде, вам все равно придется координировать свои стили кодирования. Иначе, какое это имеет значение?
Майк Дэниелс

Почему прошу ТАК? потому что я уважаю честное мнение опытных хакеров и программистов. Использование чисто функционального подхода к программированию может иметь преимущества, которыми опытный ум может поделиться со мной (и другими, такими как я).
nemesisfixx

Учитывая, что есть объективные причины для «нет», это законный вопрос.
Эндрю Гримм

Ответы:


16

Я делал это с питоном. Я считаю, что писать в наследственно чистом функциональном стиле на языке, не предназначенном для этого, сложно. Например, сопоставьте два определения in_order :

def in_order(xs):
    for i in range(1,len(xs)):
        if xs[i] > xs[i+1]:
            return False
    return True

inOrder :: (Ord a) => [a] -> Bool
inOrder xs = and $ zipWith (<=) xs (tail xs)

Написание in_orderпути Haskell в python будет и многословным (поскольку python не очень хорошо поддерживает необходимые идиомы) и медленным (линейное пространство вместо постоянного пространства Haskell из-за лени).

Тем не менее, я успешно создал программы на Python с функциональной организацией и идиоматической реализацией каждой функции. Идея, что это хороший способ программирования, на самом деле является тезисом моего проекта codecatalog . Итак, мои компоненты ориентированы на абстракции и функции (с чистым интерфейсом ), работающие на них, а не на классы с состоянием, и это прекрасно сочетается. Фактически, код, организованный таким образом, кажется более гибким для повторного использования, чем код, организованный с помощью классов. Однако это может быть личным предубеждением, так как я все еще преданный Хаскелла.

Поэтому я бы сказал, что ответ на ваш вопрос - своего рода . Используйте свои функциональные корни, чтобы помочь вам думать, но не переусердствуйте. Например. симуляция ленивых списков в Ruby только ради идиомы, вероятно, принесет больше хлопот, чем стоит.


Каким-то образом ваше описание заставило меня думать о паскале.
rasjani

@rasjani, а? Есть причина почему?

Я не знаю, может быть, из-за того, что вы плохо понимаете английский, или то, что вы описали, в некоторой степени соответствует тому, как (по крайней мере) все расположено / структурировано в паскалях. Просто своего рода ментальная связь, может не иметь никакой реальной связи с
вами

1
Утверждение «линейное пространство вместо постоянного пространства Хаскелла из-за лени» не является точным. Лень все еще подразумевает линейный порядок. Однако я понимаю вашу точку зрения.

3
@aromero, я не понимаю твоего. При чем тут порядок? Постоянное пространство приходит из мусора Хаскелла, собирающего главы списка сравнений после того, как andих потребляет; он будет вести себя как петля. Принимая во внимание, что список сравнений python должен быть сгенерирован полностью, прежде чем аналог andувидит какой-либо из них (если вы не используете генераторы ... что, я полагаю, возможно).

7

Вы можете написать код Ruby в функциональном стиле, как если бы это был Scheme, а не Haskell. Чтобы написать это так, как если бы это был Haskell, ему понадобится система типов, похожая на Haskell, плюс повсеместная ленивая оценка.


1

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

Ситуация загрузки модуля / кода ужасна, с одной стороны. В текущем интерпретаторе не включена оптимизация хвостовых вызовов, поэтому вы не можете использовать рекурсию, как в Haskell. И как только вы попадаете в Monads, нет никакого сравнения уровней абстракции, которых вы можете достичь в Haskell и Ruby.

Если вам интересно, я выложил код сравнения Ruby / Haskell на gist.github.com, как я учился.

Лучшая техника, которую я привел в Ruby, заключалась в том, чтобы найти чистые функции там, где я могу, и это то, что вы пытаетесь сделать.


В одном из моих тестов Smalltalk: self assert: ((m >>= f) >>= g) equals: (m >>= [:x | (f value: x) >>= g]). Нет никакой причины, почему вы не можете сознательно использовать монады, в отличие от их использования, даже не зная, что вы их используете (например, списки).
Фрэнк Шиарар

0

Я бы сказал "да". То, о чем (я думаю) вы говорите, это влияние функционального программирования на языке ruby. Функциональная парадигма имеет несколько действительно хороших концепций, которые дополняют или пересекаются с объектно-ориентированным (в частности, без побочных эффектов).

Отличительной особенностью ruby ​​является то, что он позволяет вам кодировать в линейном, объектно-ориентированном или функциональном стиле или в некоторой их комбинации. А ваш простой линейный скрипт может превратиться в ОО / функциональный стиль, если и когда его сложность возрастает.


0

Это зависит от того, будете ли вы сотрудничать с другими. Если вы работаете над кодом самостоятельно, используйте любой стиль, который вам удобнее всего. Однако, если вы работаете с другими программистами на Ruby, они могут не использоваться для чисто функционального стиля программирования и, следовательно, могут быть сбиты с толку вашим кодом. Опять же, если ваши соавторы также являются программистами на Haskell, которые перешли на Ruby, у вас может не быть этой проблемы.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.