3 ms·

User-defined, powerful operators are the most important feature that make programming in Haskell feel so foreign. Yet, since they often require the programmer t

User-defined, powerful operators are the most important feature that make programming in Haskell feel so foreign. Yet, since they often require the programmer to sort of grasp a model of the thing the program is trying to accomplish, once you understand the operators (e.g. parser combinators) you have a rather deep understanding of the foundation for this particular program and the rest of the code is expressed very concisely and (sometimes) reasoned about easily. Regarding the short variable names in math: They are supposed to be written and, more importantly, manipulated by hand and so short notation is very important.

emsy 12y ago
This reply goes to axman6 as well: I for one, write code under the assumption that the reader will have to decrypt it in order to understand it. Therefore I postpone implementation details until the very end. This leads to code that outlines the logic in a fairly readable manner. Of course the implementation details are still code, but at that point there is so little code that you will understand it in no time. The Haskell examples of elegance I've seen so far seem to cramp so much responsibilities in so little code, yet nobody seems to bother about the Single Responsibility Principle. I like operator overloading, but I use them for implementation details, not to keep the number of lines small. The downside is that I have a deeply nested programming structure, which can be unfamiliar for people who churn out 500 lines of bare implementation details in one function. My criticism towards math goes further than variable naming. The language of math is non-descriptive and anyone accepts it with the reasons that: a) That's how it's always been. b) It's short and once you get used to it it's easy. But this just keeps people who struggle with the language of math to embrace and love mathematics. I don't say I have a better solution, but I say that we can get in programming right what's wrong in math: a descriptive language with a low entrance barrier.

emsy 12y ago

This reply goes to axman6 as well: I for one, write code under the assumption that the reader will have to decrypt it in order to understand it. Therefore I postpone implementation details until the very end. This leads to code that outlines the logic in a fairly readable manner. Of course the implementation details are still code, but at that point there is so little code that you will understand it in no time. The Haskell examples of elegance I've seen so far seem to cramp so much responsibilities in so little code, yet nobody seems to bother about the Single Responsibility Principle. I like operator overloading, but I use them for implementation details, not to keep the number of lines small. The downside is that I have a deeply nested programming structure, which can be unfamiliar for people who churn out 500 lines of bare implementation details in one function. My criticism towards math goes further than variable naming. The language of math is non-descriptive and anyone accepts it with the reasons that: a) That's how it's always been. b) It's short and once you get used to it it's easy. But this just keeps people who struggle with the language of math to embrace and love mathematics. I don't say I have a better solution, but I say that we can get in programming right what's wrong in math: a descriptive language with a low entrance barrier.