Please, kill your darlings

As pointed out below, they aren't equivalent.

Compare the output of both when run against "foo bar WIBBLE"

Great post. This is one of my biggest pet peeves with Ruby and languages like it; they encourage developers to "show off" by using the most esoteric features they can find (even better if these features use weird symbols).

Compared to a language like Python that has few neuroses, the same developer writes much less readable code.

The post may have been better if the author included a Python sample that does the same thing:

    long_string = 'ajix mxozl xoap'
    new_string = []
    for word in long_string.split(' '):
        new_string.append("{}{}".format(word[0].upper(), word[1:]))
    new_string = ''.join(new_string)

Admittedly there are a few annoying symbols in here, mostly due to the non-intuitive operation of the join function and the well-meaning but less-than-ideal string formatting syntax (which could've been avoided if we used conventional strong concatenation, and which PEP 0498 attempts to improve). Also admittedly, coders who want to show how smart they are would try to use a list comprehension to do this, which is slightly less readable and imo shouldn't be used over this format without a good reason. But it's still much easier to parse than the Ruby version because everything is explicitly spelled out in the loop, and you generally shouldn't have to consult the language docs to look up 4 different rarely-seen operators.

Remember, debugging is twice as hard as authoring, so if you write the most clever code possible, you are by definition not intelligent enough to debug it. ;)

I understand that people can't be expected to stick to that on their own, so they need languages that promote function, uniformity, and ease of use over showmanship.

The simplicity of the code is one of the main things I look for in interviews. If you could've done something with the conventional, simple language construct that doesn't require someone to go back and refer to the docs, even if it takes more lines, but instead you used the super-arcane construct to prove how well you know the language or to "get it all on one line", I'm going to look on that pretty dubiously. The last thing I want to deal with on my projects is the residue of someone's ego impacting our ability to read their code and get things done quickly and easily.

P.S., in Python, there are a couple of shortcut functions for capitalizing each word in a sentence: str.title() and str.capwords().

I don't mind the implementation of this code, but 99% likely, it's in a method called `capitalize_sentence` or similar. If that is strewn through the middle of your code, it's probably breaking single-responsibility-principle.

As I said, until it hits some kind of edge case. Again, I'm not trying very hard here, but this oneliner doesn't give the expected output if your sentence has a string like "æsir".

  irb> @sentence = "\u00e6sir are gods"
  => "æsir are gods"

  irb> @sentence = @sentence.split(' ').map!{|x| x = x[0..0].upcase  "æsir Are Gods"

(Expected output being "Æsir Are Gods")

If you want to understand why this is failing, the code I gave above will make it way simpler. Of course, viewpoints differ – you might claim that troubleshooting it is only a job for "professionals".

One-liners are fine if you know you'll never need to extend the logic later on. Problem is, how often does that stay true?

For instance your 'titleize' method, in order to properly title case any string, ought to support a second option of words to ignore, such as "a, an, the, ...". If you wrote it as a one-liner at first, then you've got to go into your mapper and add conditionals if an ignore list is passed, and you've got more work than if you left it as a more expanded piece of logic.

Again, this is somewhat of a trivial example, but building on the original post's point of "how easily can I understand this later on" can also include "how easily can I extend this later on". Avoiding one-liner cleverness can help as a general principle.