5 ms·

Although I think the post is very clear describing the reasons why Haskell isn't attractive in business, this part rubbed me the wrong way: > Thus, instead of

by kace91 6y ago

Although I think the post is very clear describing the reasons why Haskell isn't attractive in business, this part rubbed me the wrong way: > Thus, instead of our discourse being about semantics, engineering quality, and implementation, we instead discuss our tools in terms of social factors and emotions (i.e. it “feels readable”, “feels usable”, “feels fast”). Thinking about readability or usability as emotions and social factors, rather than as first level concerns, is a non starter to me, and I find it extremely off putting that the author seems to pile up those qualities in the marketing "group", as if they were not real properties of a language. You can design a drill in a way that makes it the most scientifically correct at using the power it's supplied efficiently, but if the design hurts the users hands and requires months of training to operate, any worker will throw it in the trash, because they can drill things just fine with a regular tool. (I'm not necessarily saying that Haskell is that drill, just saying that usability should never be treated with condescension when you're designing tools).

awinter-py 6y ago
haskell isn't a drill it's a root canal
- smitty1e 6y ago
  Well, if the dental work needs a conceptual makeover, then see a dentist. I'd contend that the immutability of containers and why Docker is such a win might be getting Haskell to its moment. For me, the hardest unlearning piece isn't the syntax. Rather, the impact of the purity on the execution model is the stumbling block. Monads seem arcane because laziness + purity = statelessness, which never really had tangible meaning until the idea that a Docker image is also stateless came along. Maybe some cruder, crayon-level examples can be devised to help us slow folk get there.
  - awinter-py 6y ago
    docker is a win on desktop because I can run two database instances at once on my laptop + understand what's happening + a win for cloud when combined with kube to understand exactly what's being exposed haskell isn't simple or understandable it's flexible but I have no idea what's happening where effects are getting folded in from all over the codebase all the type abstractions are for injecting code from somewhere else
- StreamBright 6y ago
  At least you can be sure to have a pure, monadic, side-effect free, perfect root canal.
rfergie 6y ago
I took his point to be that things like "feels readable" and "feels fast" and to do with feelings rather than actual quantifiable things that could reasonably be compared between languages. So it isn't that those things aren't important; just that they are subjective
- dkubb 6y ago
  And yet, effective marketing is less about the quantifiable and more about the subjective feelings that your product will ultimately provide.
- kace91 6y ago
  I'd argue that ease of use and readability are perfectly quantifiable - there are thousands of people whose job is precisely optimising usability for many products. Sure, dealing with people is harder and less clear cut than measuring cycles in a processor - there's a lot of variability, context based on previous experience, etc. But that's no reason to ignore the human factor of programming and gather some metrics/statistics, then seeing where you can improve. What those features are, rather than subjective, it's contextual, and I feel that behind the author's phrase might lie the usual complain by functional programmers that non-functional languages just feel foreign because people are usually taught other styles during their learning process. As an explanation, that might be partly true, but it being true doesn't really save you from the fact that if you want people to use your tool, you have to make it easily usable, and usable for real world people rather than for spherical cows.
  - clarry 6y ago
    > I'd argue that ease of use and readability are perfectly quantifiable Do we have any objective metrics? The only thing I can think of is all the (inconclusive) studies about error density. Unfortunately error density is a very far cry from measuring the overall quality of a software product, or the mental effort that was required to produce it, or the mental effort required to maintain it. > there are thousands of people whose job is precisely optimising usability for many products Yeah but programming languages are more abstract; they're tools of thought (just like mathematical objects), and optimizing their use is nothing like observing a user press the buttons on a machine to get themselves a cup of coffee. Controlled studies are very difficult to run, for obvious reasons. (Unlike for the coffee machine)
easygenes 6y ago
I think what they're getting at in writing about how people are not given the right frameworks to reason about a tool's usability they're saying that people might say something "feels readable" without knowing whether it's actually easier for them to parse. Similarly for other statements. Someone might say a tool "feels fast" without actually knowing if it's faster for their problem domain than another viable tool. An analogy in the art world is that drawing lines which imply motion behind a character might make them "feel faster" but are they actually moving at all?
pwm 6y ago
The thing is that, at least in my experience, "feels readable" is indeed emotional territory. More specifically people relate favourably to things they are comfortable with and most programmers are comfortable with ALGOL/C syntax. Show them something unfamiliar, eg. Haskell, and they will say it's weird and unreadable. That statement is usually not based on careful assessment, it's a gut reaction.
- karatestomp 6y ago
  Everyone got a ton of identity, equality, and proof-based stuff in math classes. Very few programmers, even the non-college grads and those who started young, had none of that before writing Hello World. Many of us found imperative (and other non-mathy) programming styles immediately easier to understand, regardless. Me, I have to translate mathematical statements into "programmy" style to have a hope of understanding it ("OK so what does this term/operation 'do' in isolation?") and keep a crib sheet handy for WTF all the single-character bits (so, usually all of it) mean. [EDIT] my point being, that preference doesn't seem especially "emotional" to me.
  - pwm 6y ago
    > Everyone got a ton of identity, equality, and proof-based stuff in math classes. Sure and some people like it some hate it (according to western popular culture most people hate it). Also even if someone loves doing school algebra if no one tells them that you can write code that way they'll never know. If you only expose them to imperative Hello World code then of course they'll relate to that. Conditioning, familiarity and experience matter a lot. > Many of us found imperative ... programming styles immediately easier Immediately as-in you've been shown an imperative and a declarative Hello World and related to the former? Or you've only been shown the former? See my earlier point. > I have to translate mathematical statements into "programmy" style Same point as above. I did that as well for ages in the past, now I have to do the opposite. > my point being, that preference doesn't seem especially "emotional" to me. Maybe emotional is indeed the wrong word. But it's definitely not logical either and I'd also say it's not inherent, ie. people can change (I know I did) but at that point we'll dive into nature vs. nurture and that never ends :)

by kace91 6y ago

awinter-py 6y ago

haskell isn't a drill it's a root canal

smitty1e 6y ago
Well, if the dental work needs a conceptual makeover, then see a dentist. I'd contend that the immutability of containers and why Docker is such a win might be getting Haskell to its moment. For me, the hardest unlearning piece isn't the syntax. Rather, the impact of the purity on the execution model is the stumbling block. Monads seem arcane because laziness + purity = statelessness, which never really had tangible meaning until the idea that a Docker image is also stateless came along. Maybe some cruder, crayon-level examples can be devised to help us slow folk get there.
- awinter-py 6y ago
  docker is a win on desktop because I can run two database instances at once on my laptop + understand what's happening + a win for cloud when combined with kube to understand exactly what's being exposed haskell isn't simple or understandable it's flexible but I have no idea what's happening where effects are getting folded in from all over the codebase all the type abstractions are for injecting code from somewhere else
StreamBright 6y ago
At least you can be sure to have a pure, monadic, side-effect free, perfect root canal.

rfergie 6y ago

I took his point to be that things like "feels readable" and "feels fast" and to do with feelings rather than actual quantifiable things that could reasonably be compared between languages. So it isn't that those things aren't important; just that they are subjective

dkubb 6y ago
And yet, effective marketing is less about the quantifiable and more about the subjective feelings that your product will ultimately provide.
kace91 6y ago
I'd argue that ease of use and readability are perfectly quantifiable - there are thousands of people whose job is precisely optimising usability for many products. Sure, dealing with people is harder and less clear cut than measuring cycles in a processor - there's a lot of variability, context based on previous experience, etc. But that's no reason to ignore the human factor of programming and gather some metrics/statistics, then seeing where you can improve. What those features are, rather than subjective, it's contextual, and I feel that behind the author's phrase might lie the usual complain by functional programmers that non-functional languages just feel foreign because people are usually taught other styles during their learning process. As an explanation, that might be partly true, but it being true doesn't really save you from the fact that if you want people to use your tool, you have to make it easily usable, and usable for real world people rather than for spherical cows.
- clarry 6y ago
  > I'd argue that ease of use and readability are perfectly quantifiable Do we have any objective metrics? The only thing I can think of is all the (inconclusive) studies about error density. Unfortunately error density is a very far cry from measuring the overall quality of a software product, or the mental effort that was required to produce it, or the mental effort required to maintain it. > there are thousands of people whose job is precisely optimising usability for many products Yeah but programming languages are more abstract; they're tools of thought (just like mathematical objects), and optimizing their use is nothing like observing a user press the buttons on a machine to get themselves a cup of coffee. Controlled studies are very difficult to run, for obvious reasons. (Unlike for the coffee machine)

easygenes 6y ago

I think what they're getting at in writing about how people are not given the right frameworks to reason about a tool's usability they're saying that people might say something "feels readable" without knowing whether it's actually easier for them to parse. Similarly for other statements. Someone might say a tool "feels fast" without actually knowing if it's faster for their problem domain than another viable tool. An analogy in the art world is that drawing lines which imply motion behind a character might make them "feel faster" but are they actually moving at all?

pwm 6y ago

The thing is that, at least in my experience, "feels readable" is indeed emotional territory. More specifically people relate favourably to things they are comfortable with and most programmers are comfortable with ALGOL/C syntax. Show them something unfamiliar, eg. Haskell, and they will say it's weird and unreadable. That statement is usually not based on careful assessment, it's a gut reaction.

karatestomp 6y ago
Everyone got a ton of identity, equality, and proof-based stuff in math classes. Very few programmers, even the non-college grads and those who started young, had none of that before writing Hello World. Many of us found imperative (and other non-mathy) programming styles immediately easier to understand, regardless. Me, I have to translate mathematical statements into "programmy" style to have a hope of understanding it ("OK so what does this term/operation 'do' in isolation?") and keep a crib sheet handy for WTF all the single-character bits (so, usually all of it) mean. [EDIT] my point being, that preference doesn't seem especially "emotional" to me.
- pwm 6y ago
  > Everyone got a ton of identity, equality, and proof-based stuff in math classes. Sure and some people like it some hate it (according to western popular culture most people hate it). Also even if someone loves doing school algebra if no one tells them that you can write code that way they'll never know. If you only expose them to imperative Hello World code then of course they'll relate to that. Conditioning, familiarity and experience matter a lot. > Many of us found imperative ... programming styles immediately easier Immediately as-in you've been shown an imperative and a declarative Hello World and related to the former? Or you've only been shown the former? See my earlier point. > I have to translate mathematical statements into "programmy" style Same point as above. I did that as well for ages in the past, now I have to do the opposite. > my point being, that preference doesn't seem especially "emotional" to me. Maybe emotional is indeed the wrong word. But it's definitely not logical either and I'd also say it's not inherent, ie. people can change (I know I did) but at that point we'll dive into nature vs. nurture and that never ends :)