In GoLang code (and C/C++) you'll see things like this:
os.Stderr.WriteString(fmt.Sprintf("==> Error: %s\n", err.Error()))
But I don't know, I prefer simpler easier to read, something like:
os.Stderr.WriteString(fmt.Println(`==> Error: ` + err.Error()))
That gets rid of the "%s\n" perl looking junk (IMHO)
Obviously formatting (perl/c++/c way) is useful when you have multiple instances of the string value to be output as you can reuse %s over and over. But sometimes I feel people use language features that really aren't saving any keystrokes and don't even serve much purpose.
Formatting is also useful for dates and other situations where you use a shortform to describe an output format of your preference, or print something with only two keystrokes i.e. "%d" instead of converting using Itoa() or IntToStr() or ConvertToScientificNotation() and bloating up the code with function calls.... But it seems like in some cases people are just using these functions because they are used to them from C or C++ or perl without adding much benefit.
On the opposite end of the spectrum, you have Oberon programmers who tend to go too far the other way in some cases without ever using shortforms. You will see them do things such as:
example.WriteString("some string");
example.WriteInt(5);
example.WriteLine;
Instead of the shorter and simpler (variadic function):
example.WriteLn("some string", 5)
Or you will see them do this (put multiple procedures on one line):
out.WriteString("put it all on one line"); out.WriteInt(5) out.WriteLine;
I find that a fine balance is needed. I find the oberon way obnoxious, and also the c/c++/perl way obnoxious too. So something in between, a compromise. Not something too obfuscated and terse, but not something too verbose and heavy handed, not to mention tedious. The oberon reason for all this is to avoid language complexity, as Wirth was critical of Pascal's writeln that could accept multiple types and arbitrary amount of parameters (which GoLang calls a variadic function, of sorts, or use an interface). Oberon wants to keep it simple but at the cost of all Oberon end users code now being more complicated than what even standard pascal had with it's old writeln.
GoLang offers much flexibility and solves the issue, at a little bit of a cost of some compiler complexity, but IMO well worth it. The issue is, though, GoLang programmers are still using c/c++/perl coding techniques even if their language has way to avoid it. I.e. GoLang offers a way out of the problem, but, that doesn't mean people are actually going to use that way out or take up the offer.
|