As an infrequent developer, dabbler, and amateur in a vast number of programming languages, I think a great deal of the difficulties that arise when plodding ar

As an infrequent developer, dabbler, and amateur in a vast number of programming languages, I think a great deal of the difficulties that arise when plodding around between different languages stem from a great number of design decisions that prioritize elegance, abstraction, terseness, and library economy over user experience. What results are a number of extremely powerful language features that are useful to everyone but remain inaccessible to anyone uninitiated into the cabal of that language's practitioners. While we're on the subject of cabals, I think Haskell is a paragon case of this type of situation. Haskell is a phenomenal language and has the potential to be incredibly expressive and useful when it comes to accomplishing tasks that require one and done programmatic solutions. However, the language ecosystem refuses to abandon a great number of practices that, while they are historically and conceptually justified given its relation to category theory and mathematics, will ensure haskell never sees the same degree of general purpose adoption other languages do. For example, the following function is one I came up with on the spot for illustrative purposes: folds :: (b->b->b)->[b]->[b] folds f x = map (\n -> foldl f n x) x It's not immediately obvious what this does unless you have basic knowledge of functional programming. Part of the difficultly stems from my choice of names, but I'm sticking with the convention to use single letters in the majority of cases that capture abstractions. If I have obtained the prerequisite knowledge of haskell necessary to quickly read the above simple function and tell what it does it's incredibly powerful and easy reading, however, if I'm just picking things up for a small project there is waaaaaay to much learning overhead for me to even consider using haskell. Compare the haskell function with the same function expressed in javascript: function folds(f, items){ return items.map(x => items.reduce(f, item)); } If you are familiar with haskell, the haskell version is probably faster to read and comprehend. However, if you don't know haskell the js is probably easier to come to grips with based on its lingual contents. The there's common lisp, which almost reads like English if it were't drowning in parens and quote weirdness: (defun folds (f items) (map 'list (lambda (item) (reduce f items :initial-value item)) items)) The keyword arg goes a long way in helping the code read like a sentence, which is a good thing. In fact, that's the sort of syntactic support of semantics swift promotes using parameter labels: func move(from start: Point, to end: Point) x.move(from: x, to: y) It's immediately clear to a caller what purpose each of the arguments of that function serve. Obviously this is a huge, complex issue, and I'm never going to do it justice in a hackernews comment, but in general I think if library designers and developers focused more on user experience and usability we'd have more pleasant code to interact with. User experience isn't a concept reserved strictly for graphical applications--any tool, no matter what it is, has a user experience, and it's important to consider the user up front when we go about designing technology. In this respect I think Knuth's concept of literate programming has a lot of worth, as it can cut down on research time tremendously and increase ease of use--if the code itself can provide all of the contextual information I need, there's no reason for me to go scouring the documentation, which--another issue--is frequently spotty, unclear or confusing, and on some occasions incomplete.