That post is a little rant heavy but I agree completely: simple, everyday tasks are still way more verbose and require more lines of code than they should in most languages.
Python/Ruby is probably the closest I've seen to a language that provides enough batteries to be productive but gets out of my way syntactically as much as possible, but both of them could use some further evolution.
The reason I love Python is that in general when I want to write something a certain way, or what seems to be the most natural way to do something is how it is actually done. As a programmer it gets out of my way and lets me do what I need to get done.
The author to a certain degree is calling for exactly that, a language that makes tasks that every programmer does over and over extremely simple, make the stuff that is not done nearly as often harder to do, or take up more lines.
> what seems to be the most natural way to do something is how it is actually done
I love Python too, but it's not without its quirks. Eg:
','.join(mylist)
Which nearly everyone I know at first assumed would be:
list.join(',')
Nobody thinks of what's being done here 'take a dot, and use it to join this list'. They think of 'take this list, and join it into a string using dot'.
> Nobody thinks of what's being done here 'take a dot, and use it to join this list'. They think of 'take this list, and join it into a string using dot'.
Even fewer people think of how to do that in the face of heterogeneous and polymorphic lists.
Intuition is not God, it's just an informant. Sometimes it's wrong, no matter the language.
It's a convenience so that every iterable object in the world doesn't need to implement a join() method. I pass generator expressions to join as often as lists, so it works out well that the method is on the string rather than the list.
> It's a convenience so that every iterable object in the world doesn't need to implement a join() method.
The way to do this would be to have an IterableMixin that implements join() (and a load of other stuff) so long as the subclass implements a small number of basic methods.
Sure, but is it up to the programmer to "subclass" or somehow specify that his type implements IterableMixin? Or is it up to the python interpreter to realise that it implements certain functions and automatically do this?
Methods aren't defined by what they return. I have a host method (a property, to be precise) that returns a location of the host. It wouldn't make sense for it to return another host object.
string methods are things you do to strings.
list methods are things you do to list.
Most people think of taking a list, and gluing it with a string, not taking a string, and using it as glue for a list.
Python/Ruby is probably the closest I've seen to a language that provides enough batteries to be productive but gets out of my way syntactically as much as possible, but both of them could use some further evolution.