> combinedStr = strcat(s1,s2,...,sN) horizontally concatenates strings in arrays. Inputs can be combinations of single strings, strings in scalar cells, character arrays with the same number of rows, and same-sized cell arrays of strings.
So you can throw a bunch of different string-like stuff and everything will be concatenated. A bit strange but okay. However, there's more:
> If any input is a cell array, combinedStr is a cell array of strings. Otherwise, combinedStr is a character array.
Ouch. So you can build your program, test it only with non-cell-array arguments, and later on someone trows in an extra thing to concatenate (or uses a cell array to define the output separator).... and that changes the output type of the function!
But that's not the only side-effect! It truns out that
> For character array inputs, strcat removes trailing ASCII white-space characters: space, tab, vertical tab, newline, carriage return, and form-feed. For cell array inputs, strcat does not remove trailing white space.
Oh yeah, you also get different "concatenation" rules when these types change. And that's even before discussing why on earth would a "strcat" function remove trailing spaces from within the stuff you tell it to concatenate...
TL;DR: What is wrong with matlab is that it is designed to write one-liners that probably perform what you want. This is achieved by an endless stream of tweaks in the basic language's functions that automagically try to do "what you probably want". As a result, it is an extremely compact, easy to write for language when the tweaks work, but an utterly terrible experience when the magic doesn't work that makes you feel like walking through a minefield.
You look around and find the strcat function. Nice, this thing should just concatenate whatever stringy thing I throw into it. Well, sorta, kinda: http://www.mathworks.es/es/help/matlab/ref/strcat.html
> combinedStr = strcat(s1,s2,...,sN) horizontally concatenates strings in arrays. Inputs can be combinations of single strings, strings in scalar cells, character arrays with the same number of rows, and same-sized cell arrays of strings.
So you can throw a bunch of different string-like stuff and everything will be concatenated. A bit strange but okay. However, there's more:
> If any input is a cell array, combinedStr is a cell array of strings. Otherwise, combinedStr is a character array.
Ouch. So you can build your program, test it only with non-cell-array arguments, and later on someone trows in an extra thing to concatenate (or uses a cell array to define the output separator).... and that changes the output type of the function!
But that's not the only side-effect! It truns out that
> For character array inputs, strcat removes trailing ASCII white-space characters: space, tab, vertical tab, newline, carriage return, and form-feed. For cell array inputs, strcat does not remove trailing white space.
Oh yeah, you also get different "concatenation" rules when these types change. And that's even before discussing why on earth would a "strcat" function remove trailing spaces from within the stuff you tell it to concatenate...
TL;DR: What is wrong with matlab is that it is designed to write one-liners that probably perform what you want. This is achieved by an endless stream of tweaks in the basic language's functions that automagically try to do "what you probably want". As a result, it is an extremely compact, easy to write for language when the tweaks work, but an utterly terrible experience when the magic doesn't work that makes you feel like walking through a minefield.