Ouch ^2. Yes I am lucky. At least know that I’m hugely grateful to be able to follow the ST dream. But well spotted that Unicode makes things more complicated. Yes, most current Smalltalk implementations are Unicode savvy, and in fact Squeak’s String>>asLowercase implementation looks like

asLowercase
	"Answer a String made up from the receiver whose characters are all
	lowercase."

	^ self copy asString translateToLowercase

translateToLowercase
	"Translate all characters to lowercase, in place"

	self translateWith: LowercasingTable

Which looks a little over-complicated to me. But its not my problem

Somebody give Pete a job … doing Smalltalk!

Sorry, bit off-topic!

Ouch!. Forgive me, I wasn’t thinking about the C, only about the Smalltalk output. But I shouldn’t be displaying bad examples all the same.

But this is interesting. The equivalent Smalltalk code is simply
aString asLowercase
but in C I had to write a function to do it. There was no strtolower function to hand in the C library, a library routine that would be tried and tested and free of errors. The Smalltalk code is something as simple as

asLowercase
        ^self collect: [:c| c asLowercase]

whereas the C code has – count ‘em – 9 lines!
So C forces one to write more code, providing much more opportunity for mistakes, and makes it far harder to debug and correct (low level debuggers, no edit-and-continue).

I make mistakes. I’m currently working on a JIT written in Smalltalk that will be transliterated into C. Were I in C I would be making snail-like progress but in Smalltalk I feel like I’m flying along. Programming systems should be designed for humans, with all their failings. I put down my O(n^2) blunder to the paucity of the C development ecosystem and yet another example of why trying to implement a faster Smalltalk VM makes sense

That said, next time I’ll be sure to write

char *
lower(char *s)
{
    int i = strlen(s);
    buf[i] = 0;
    while (--i >= 0)
        buf[i] = tolower(s[i]);
    return buf;
}