Granted, space leak issues are pretty difficult to analyse, so it makes the language seem hard to use in practice, but that's because all the low-hanging fruit like type errors are solved by how the language is designed, so you only end up with the hard bugs.
This is not correct. To understand why, please see Ryan Culpepper's answer to this SO question:
http://stackoverflow.com/questions/7046950/lazy-evaluation-v...
They aren't that many to begin with, so it could just be (self-)selection bias.
Forth people do fine using Forth too, but I don't see that as a point that it's an appropriate language for most projects and/or people.
BTW the people on #haskell are quite active, and nice :)
(maybe a pointless counter-example, I once went onto #ruby, and asked about an easy way to make a function name refer to a function( to be able to do things like list map f easily, without the superflous do |x| f x end ), and I got yelled at because I was trying to write "non-ruby code".
To answer your question, because methods aren't first-class in Ruby, you can't pass them around the way you want to. I've decided I don't want my languages telling me what I can or can't do when I know what I want to do is a simple matter of making more types of pointers first-class.
def call_on_two fn
fn.call 2
end
call_on_two 1.method(:+) #=> 3
A method like that could be easily enough created, though it'd be kind of ugly:
module Enumerable
def map_fn fn
map { |i| method(fn).call i }
end
end
def foo num
num + 2
end
[1, 2, 3].map_fn :foo #=> [3, 4, 5]
Which doesn't mean a thing. How many of them are employed developers working in the language, as opposed to dabblers?
Very few professional developers I've known hang on IRC. It's 2014 already.