4 ms·

I think the point is that most projects don't need/can't be functional "all the way through". Like any sufficiently complex application many of us work on syste

by colbyh 12y ago

I think the point is that most projects don't need/can't be functional "all the way through". Like any sufficiently complex application many of us work on systems (or at least parts of systems) that could benefit from a functional approach. If the application happens to be written in Ruby, learning how to use and manipulate abstract data types can be rather useful. The only valid complaint I see against taking a functional approach to Ruby is Ruby's shitty, memory intensive object system. Fortunately it's improving with every release and hardware just keeps on getting cheaper, so at the end of the day it's not a very strong complaint.

vinceguidry 12y ago
It's a style and design problem. Ruby is designed to make it easier on the developer when he's trying to do stuff. Part of that design is being able to read the code. If I went into a codebase and saw classes being used for functional constructs instead of repositories for holding state, I'd quietly close the project down and find another gem. Ruby has a way to do immutability. It has methods to do common stuff like nil-checking if you pull in ActiveSupport, something I now do on all my projects. You just don't need to inflict such a heavy-handed approach for the meagre gains it will bring. If you find yourself implementing another language in the one you're using, then it's either the entire point, as in something like Opal, or there's no point at all and you should just go use that other language you're implementing. It's not a question of performance, it's a question of interfacing and code style. The biggest bottleneck is programmer attention, and you're doing a real disservice to the next guy down the line if you mutate Ruby's conventions this way, especially if you don't have clean interfaces written.
- colbyh 12y ago
  I'm sorry, but I really don't follow at all. You call this approach heavy handed when in fact it's relatively small amount of source code that makes for much more readable developer code down the line. To me, Maybe seems like a much lighter touch than monkey patching Object. And I don't understand your insistence that you're "writing another language" in Ruby by using a few functional constructs. For a language that uses .each as its base iterator and encourages you to pass blocks around it seems quite fitting, in fact. Anyways, probably going to have to agree to disagree here. I come from the "every good language is a shitty lisp" school of thought so my personal lens might just not line up with yours.
  - vinceguidry 12y ago
    I went through HtDP and loved it, it helped me gain a data-centric view on programming, and the lessons carried very well into my later Ruby career. I looked at Arc and liked the idea. I like Ruby better than Lisp. It's hard to explain why. One of the reasons why I like to argue about this sort of thing on the Internet is because it helps me isolate the subtler qualities of different styles of programming. I like Ruby because you can build a community around it, in a way that I don't think you can build one around Lisp, at least not like the one you find in Ruby, with the massive quantities of libraries and such. Lisp is too free-form. You almost never need the power it gives you, and it encourages people to build their own language features where the problem being solved could probably do with a more conventional approach. Ruby hits a sweet spot, enough dynamism to where you don't feel constrained, not so much that you can't easily reason about code. Code as data is a neat idea, but code needs to be read by humans and that's the harder task.

by colbyh 12y ago

vinceguidry 12y ago

It's a style and design problem. Ruby is designed to make it easier on the developer when he's trying to do stuff. Part of that design is being able to read the code. If I went into a codebase and saw classes being used for functional constructs instead of repositories for holding state, I'd quietly close the project down and find another gem. Ruby has a way to do immutability. It has methods to do common stuff like nil-checking if you pull in ActiveSupport, something I now do on all my projects. You just don't need to inflict such a heavy-handed approach for the meagre gains it will bring. If you find yourself implementing another language in the one you're using, then it's either the entire point, as in something like Opal, or there's no point at all and you should just go use that other language you're implementing. It's not a question of performance, it's a question of interfacing and code style. The biggest bottleneck is programmer attention, and you're doing a real disservice to the next guy down the line if you mutate Ruby's conventions this way, especially if you don't have clean interfaces written.

colbyh 12y ago
I'm sorry, but I really don't follow at all. You call this approach heavy handed when in fact it's relatively small amount of source code that makes for much more readable developer code down the line. To me, Maybe seems like a much lighter touch than monkey patching Object. And I don't understand your insistence that you're "writing another language" in Ruby by using a few functional constructs. For a language that uses .each as its base iterator and encourages you to pass blocks around it seems quite fitting, in fact. Anyways, probably going to have to agree to disagree here. I come from the "every good language is a shitty lisp" school of thought so my personal lens might just not line up with yours.
- vinceguidry 12y ago
  I went through HtDP and loved it, it helped me gain a data-centric view on programming, and the lessons carried very well into my later Ruby career. I looked at Arc and liked the idea. I like Ruby better than Lisp. It's hard to explain why. One of the reasons why I like to argue about this sort of thing on the Internet is because it helps me isolate the subtler qualities of different styles of programming. I like Ruby because you can build a community around it, in a way that I don't think you can build one around Lisp, at least not like the one you find in Ruby, with the massive quantities of libraries and such. Lisp is too free-form. You almost never need the power it gives you, and it encourages people to build their own language features where the problem being solved could probably do with a more conventional approach. Ruby hits a sweet spot, enough dynamism to where you don't feel constrained, not so much that you can't easily reason about code. Code as data is a neat idea, but code needs to be read by humans and that's the harder task.