4 ms·

I strongly approve of this message. I think the reason why Ruby has such terrible DSLs is not due to its technological strengths or weaknesses but instead becau

by tel 11y ago

I strongly approve of this message. I think the reason why Ruby has such terrible DSLs is not due to its technological strengths or weaknesses but instead because the community promotes the idea that a good DSL is super human readable. I'm not one to denigrate syntax or readability, but I think it must without any question be prioritized below good semantics. The "Zen of Python" has some (but hardly all) this hammered out well * Explicit is better than implicit. * Simple is better than complex. * Special cases aren't special enough to break the rules. * In the face of ambiguity, refuse the temptation to guess. Working in DSLs—and really there's no reason to think that we're not always working in DSLs nearer or further from our actual domain—should simplify concepts first and syntax later.

RangerScience 11y ago
> I'm not one to denigrate syntax or readability, but I think it must without any question be prioritized below good semantics I strongly disagree. You get what you wish for / focus on - if you wish for good semantics, you will get good semantics, but not necessarily readability. If you wish for readability, you may not get good semantics - but the point of having good semantics is readability, so... This is the issue I have with the Zen of Python (versus the Principle of Ruby). The Zen of Python attempts to list out the things you should do so that you get Developer Happiness. Ruby just says "Go get developer happiness". And so you get Python code that follows all the Zen of Python but fails to make you happy, and you have Ruby code that breaks all the rules of the Zen of Python, but does make you happy. Given that what makes a good programmer happy amount to ease of use, effectiveness, reliability and speed (in an order dependent on circumstance), or more succinctly - if I am happy when I am effective... I'd rather be happy than right.
- tel 11y ago
  Mostly we're just expressing a difference of opinion, but one thing that I'd like to contest is that the goal of the Zen of Python is to produce developer happiness. In particular, I'll state that my cherry picking from that screed is not aimed at developer happiness. I personally think developer happiness is a very poor place to put your stock. I believe much more that the goal should be one of craft and if the mechanism is painful and difficult then this is merely the cost to play. I think there's a lot of room for places where developers are made to be happy. Education is a HUGE target here and I'm happy to note that a lot of Ruby's early successes, I believe, were centered there. I believe happiness, convenience, and a little bit of absurdity are fine traits. But when I want to get work done, when I want to make things to share and to last and to communicate my goals and intentions, then I want to suffer whatever is necessary to do that well. So, in my opinion, developer happiness be damned. Then, again, it's also my perspective that developer happiness can perhaps be maximized in this way as well. But if you take it as your solitary goal then I don't think you're well equipped to make the whole journey.

by tel 11y ago

RangerScience 11y ago

> I'm not one to denigrate syntax or readability, but I think it must without any question be prioritized below good semantics I strongly disagree. You get what you wish for / focus on - if you wish for good semantics, you will get good semantics, but not necessarily readability. If you wish for readability, you may not get good semantics - but the point of having good semantics is readability, so... This is the issue I have with the Zen of Python (versus the Principle of Ruby). The Zen of Python attempts to list out the things you should do so that you get Developer Happiness. Ruby just says "Go get developer happiness". And so you get Python code that follows all the Zen of Python but fails to make you happy, and you have Ruby code that breaks all the rules of the Zen of Python, but does make you happy. Given that what makes a good programmer happy amount to ease of use, effectiveness, reliability and speed (in an order dependent on circumstance), or more succinctly - if I am happy when I am effective... I'd rather be happy than right.

tel 11y ago
Mostly we're just expressing a difference of opinion, but one thing that I'd like to contest is that the goal of the Zen of Python is to produce developer happiness. In particular, I'll state that my cherry picking from that screed is not aimed at developer happiness. I personally think developer happiness is a very poor place to put your stock. I believe much more that the goal should be one of craft and if the mechanism is painful and difficult then this is merely the cost to play. I think there's a lot of room for places where developers are made to be happy. Education is a HUGE target here and I'm happy to note that a lot of Ruby's early successes, I believe, were centered there. I believe happiness, convenience, and a little bit of absurdity are fine traits. But when I want to get work done, when I want to make things to share and to last and to communicate my goals and intentions, then I want to suffer whatever is necessary to do that well. So, in my opinion, developer happiness be damned. Then, again, it's also my perspective that developer happiness can perhaps be maximized in this way as well. But if you take it as your solitary goal then I don't think you're well equipped to make the whole journey.