4 ms·

I would love it if a Haskell-like language ended up becoming as widely used as Ruby is today, but I don't think it's going to happen. I've met one or two develo

I would love it if a Haskell-like language ended up becoming as widely used as Ruby is today, but I don't think it's going to happen. I've met one or two developers in my life whose eyes don't glaze over when I talk about lambda calculus, algebraic data types, or higher order functions that go beyond mapping over an array-like data structure. Trying to explain monads prompts most people to say they left their oven on and flee the room. These things are very abstract, to a degree where I think many people just aren't comfortable with them. Not that there's anything wrong with that, as I have a hard time with very low levels of abstraction. We've all got our comfort zone.

solomatov 13y ago
>I would love it if a Haskell-like language ended up becoming as widely used as Ruby is today, but I don't think it's going to happen. I've met one or two developers in my life whose eyes don't glaze over when I talk about lambda calculus, algebraic data types, or higher order functions that go beyond mapping over an array-like data structure. Trying to explain monads prompts most people to say they left their oven on and flee the room. You are probably working in the wrong company. I know dozens of colleagues who know what lambda calculus and moands are.
kybernetikos 13y ago
I think that a lot of this is a problem with jargon and explanation rather than with the concepts themselves. For a programmer the difference between abstract and concrete is really just the difference between 'something I don't yet see why I would need to use it' and 'something you've given me a good example for'. If you want to explain monads to a software developer, call it a 'design pattern that lets you chain actions on wrapped values' rather than "an endofunctor, together with two natural transformations".
spion 13y ago
I think that most people able to deal with AbstractSingletonProxyFactoryBean will also be able to deal with monads. The jump in abstraction level doesn't seem that high but the complexity seems much lower and code reuse is actually possible, so it would be worth it too. Maybe even for those programmers that never embraced those abstract factories because they simply didn't feel like they'd get enough benefit. There is just not enough (approachable) material on the subject right now but the amount seems to be growing every day. The percieved "coolness" factor is also rising, and even though in principle we should choose only based on technical merits, us programmers will definitely go through many more obstacles for something that is perceived as cool / fashionable / in demand. My guess is that most programmers are simply put off by the completely alien terminology rather than the complexity or abstraction level. But this terminology wont remain alien forever - its already entering into more widespread use. I yearn for a reasonably "right way" to develop software - for a set of solid patterns with truly good characteristics. Not a silver bullet, but at least a set of universal principles that apply to any high quality bullet. The acceleration of the current chaos only reinforces this yearning. There is just too much magic, too many approaches, too many opinions, too much rehashing of the same-old, too much cargo-culting, but not enough facts. I have a hunch that the functional languages of today may be on the verge of being able to offer that "right way". I guess I'll find out soon...

solomatov 13y ago

>I would love it if a Haskell-like language ended up becoming as widely used as Ruby is today, but I don't think it's going to happen. I've met one or two developers in my life whose eyes don't glaze over when I talk about lambda calculus, algebraic data types, or higher order functions that go beyond mapping over an array-like data structure. Trying to explain monads prompts most people to say they left their oven on and flee the room. You are probably working in the wrong company. I know dozens of colleagues who know what lambda calculus and moands are.

kybernetikos 13y ago

I think that a lot of this is a problem with jargon and explanation rather than with the concepts themselves. For a programmer the difference between abstract and concrete is really just the difference between 'something I don't yet see why I would need to use it' and 'something you've given me a good example for'. If you want to explain monads to a software developer, call it a 'design pattern that lets you chain actions on wrapped values' rather than "an endofunctor, together with two natural transformations".

spion 13y ago

I think that most people able to deal with AbstractSingletonProxyFactoryBean will also be able to deal with monads. The jump in abstraction level doesn't seem that high but the complexity seems much lower and code reuse is actually possible, so it would be worth it too. Maybe even for those programmers that never embraced those abstract factories because they simply didn't feel like they'd get enough benefit. There is just not enough (approachable) material on the subject right now but the amount seems to be growing every day. The percieved "coolness" factor is also rising, and even though in principle we should choose only based on technical merits, us programmers will definitely go through many more obstacles for something that is perceived as cool / fashionable / in demand. My guess is that most programmers are simply put off by the completely alien terminology rather than the complexity or abstraction level. But this terminology wont remain alien forever - its already entering into more widespread use. I yearn for a reasonably "right way" to develop software - for a set of solid patterns with truly good characteristics. Not a silver bullet, but at least a set of universal principles that apply to any high quality bullet. The acceleration of the current chaos only reinforces this yearning. There is just too much magic, too many approaches, too many opinions, too much rehashing of the same-old, too much cargo-culting, but not enough facts. I have a hunch that the functional languages of today may be on the verge of being able to offer that "right way". I guess I'll find out soon...