jyrgenn

More or less since I started programming in Go, I have wanted to know which method I should use for collecting strings: (a) use a bytes.Buffer and WriteString(), or (b) just "add" together a string with +=. The convenience of the latter is appealing, but how would that be performance-wise? So I finally checked it.

package main

import (
	"bytes"
	"fmt"
	"os"
	"time"
)

var startT time.Time

func main() {
	for reps := 10000; reps <= 100000; reps += 10000 {
		fmt.Printf("\nreps: %d\n", reps)
		snippet := os.Args[1]

		startT = time.Now()
		buf1 := bytes.NewBufferString("")
		for i := 0; i < reps; i++ {
			buf1.WriteString(snippet)
		}
		seconds1 :=
			float64(time.Now().Sub(startT)) / float64(time.Second)
		len1 := buf1.Len()
		fmt.Printf("last of %d: %s; %g s\n", len1,
			buf1.Bytes()[len1-10:len1-1], seconds1)

		startT = time.Now()
		buf2 := ""
		for i := 0; i < reps; i++ {
			buf2 += snippet
		}
		seconds2 :=
			float64(time.Now().Sub(startT)) / float64(time.Second)
		len2 := len(buf2)
		fmt.Printf("last of %d: %s; %g s\n", len2,
			buf2[len2-10:len2-1], seconds2)
	}
}

The result was more clear-cut than I had expected:

$ ./strcatz fldsjbcsldfbcdkhasfacde

reps: 10000
last of 230000: dkhasfacd; 0.001061327 s
last of 230000: dkhasfacd; 0.501937235 s

reps: 20000
last of 460000: dkhasfacd; 0.001232219 s
last of 460000: dkhasfacd; 2.42185104 s

reps: 30000
last of 690000: dkhasfacd; 0.00211587 s
last of 690000: dkhasfacd; 6.120059 s

reps: 40000
last of 920000: dkhasfacd; 0.002452257 s
last of 920000: dkhasfacd; 13.718863728 s

reps: 50000
last of 1150000: dkhasfacd; 0.0048127 s
last of 1150000: dkhasfacd; 18.529621865 s

reps: 60000
last of 1380000: dkhasfacd; 0.004334798 s
last of 1380000: dkhasfacd; 24.74539053 s

reps: 70000
last of 1610000: dkhasfacd; 0.005095205 s
last of 1610000: dkhasfacd; 32.982584273 s

reps: 80000
last of 1840000: dkhasfacd; 0.009039379 s
last of 1840000: dkhasfacd; 44.176404262 s

reps: 90000
last of 2070000: dkhasfacd; 0.008148565 s
last of 2070000: dkhasfacd; 53.003958242 s

reps: 100000
last of 2300000: dkhasfacd; 0.008536743 s
last of 2300000: dkhasfacd; 67.390456565 s

The += method is not only slower to begin with, but also goes up more than linear, which is not quite surprising. I do find it surprising, though, that the difference is so large, in the order of 10000. So, I guess, that question is answered: In a place where performance matters at all, don't use += for repeated string concatenation.

Today I thought of that version cum configuration control system ("ShapeTools") with Makefile-like input files I had the pleasure to work on 20+ years ago.

One user, a co-student of mine, came whining (again!) about some alleged bug in the "shape" program that had allegedly deleted his (alleged) source files. No way, we said.

No, it didn't. It only tended to skip the very last character of the Shapefile. Which didn't do any harm (ever), because that (always) was a newline character, right?

clean:
        rm -f core *.o $(PROGRAM) #*# *~

(For totally unrelated reasons, I implemented a new Shapefile parser not long after that bug report. And I still never end a "clean" rule in a Makefile with "*~".)

I am interested in programming languages in general. In particular, I was always intrigued by how another programming language can offer me new possibilities to express my programs and allow me to grow as a programmer.

I learned my first one in school. The computers there — a room full of PET 2001s, when they were new — had only BASIC, which frustrated me soon. At the university, I started out with a course in Pascal and did quite some programming on the side in it. Pascal filled many of the gaps that I had found annoying with BASIC too soon.

For fun I learned the basics of FORTRAN, but never had any real use for it. Modula-II came along, even for largish programming assignments, but didn't really catch my interest. I found Ada more interesting, but had little opportunity to use it outside of the process control course. I looked a bit into Forth, but again had no real application to get some practice.

It was when I got to C that I was finally hooked. That was, finally, "the real thing", in a way, and a language that served me well, not only in the technical sense — for most of my professional life, it was one of the main things that kept me well-fed.

There were other interesting languages I learned at the university, Tcl, for instance, not the greatest language, but a very easily embeddable interpreter. For a while, I put one into every major program I wrote. I learned a little of Prolog, but not enough, which I regret.

But I was fascinated by functional languages and got a bit more productive in that field — Lisp, Hope, ML mainly. Lisp was the only one that I built an implementation for myself — or, rather, more than one. First for an assignment, together with a co-student, in Modula-II. We did not like some of the requirements in that course, and not so much the implementation language, so afterwards, we did a similar one in C. Years later, I made a Lisp interpreter in Java, and still later another one in C. All these are not really complete — in particular the garbage collector of the latter is a bit too eager and collects away things it shouldn't —, but both do implement a small but "real" Lisp, one that can use recursion and higher-order functions and has the basic builtins available. In between I have written one in Go, which is the most complete of all of them, although still in the My Favourite Toy Language category rather than a useful programming environment.

As mentioned, C was instrumental to most of the professional jobs I had, and the one I currently have. But others came into view, mainly Perl. Perl has even become the default language for me when I want to try something or have to implement just a bit of functionality. This is not because I value Perl so highly for its technical merits, but it is available everywhere, everybody knows it, so many things are admittedly much easier to do in Perl than in C, and consequently Perl has become a kind of habit. I am not the biggest fan of Perl, though; I find it inelegant and clumsy in places, and seductively encouraging questionable programming habits in others. Still, often it gets things done with relatively little effort.

There are others that I found interesting on the way, but have not found enough time (and practical use) to really learn them — Lua, SNOBOL, and APL (or J, rather) come to mind. I will have to work with JavaScript soonish, but I am strongly meh about it.

Then I saw more and more of Go. An article about it by Rob Pike finally made me dig into it, something I had been wanting to do for a while. Now that seems to be a fine language, with great ideas built into it, while still catering to the habits of programmers who grew up with C and its descendants. Go has the potential to give me back some of the fun I head with C 20 years ago, by combining ease and pragmatism (like in Perl) with a, finally, elegant language (although not as elegant as Lisp or the more modern functional languages). I'll see; for now I haven't done more than a few sample programs and the abovementioned Lisp interpreter in Go.

Then there is Haskell. I became curious about Haskell already in the early 90s, when I had contact with other functional languages as a student (see above). Someone passed me an article about Haskell in, I think, the ACM SIGPLAN Notices. Haskell was still new then, but in between it has matured for a few decades and is still there, which I assume is a good sign. As I always liked functional programming, this may be something to go with.

Now the biggest obstacle in adopting a new programming language for myself is not the difficulty of learning it and getting up to speed for real tasks, but other people. While my workplace has, to my regrets, a culture of people mostly doing their development projects alone, it is still considered important that someone else will be able to fix things when the original author is on vacation, or to do further development after the original author has left. I agree with that, of course. But that makes it difficult to adopt a new programming language when the others are just not interested in doing the same. And alas, it appears they are not.

Besides shell scripts, we work with C and — mostly — Perl, but I would love to do things in Go or Haskell. And I would like to do that at work, to make my work easier and more interesting. But as there is no one to take over a project done in one of these languages, I cannot do that. (There is one who would be interested enough in Go, I guess, but he is a student and will leave us in a year or two.) That is quite frustrating. Perhaps I should try to initiate a kind of consensus which language we should adopt next — but I am afraid there is too little interest to leave the beaten tracks of C and Perl. After all, they have already adopted Perl as a new laguage not even twenty years ago, so why do something like that again so soon?

(From the discussion on an article on Google Plus)

There are always different opinions about a programming language. IMO it is a matter not just of personal taste, but also of the personal balance of priorities you have. For instance, if you particularly want terseness, freedom of expression, and lots of pragmatic shortcuts, Perl is just the thing. If you need real type safety and a firm grip on the module interfaces for a large team, Java or Ada may be the right thing. (I happen to like both, BTW.)

For me, Go may have just the right balance of type safety, pragmatic shortcuts (partly implicit strong typing! automatic memory management!), good performance, and powerful language features (closures! channels! interfaces! goroutines! multiple values!).

I lean to the stricter side of programming, such that I see it as a weakness of, say, Python or Ruby that variables do not have to be declared explicitly. Doing it with a simple ":=" like in Go, on the other hand, is so elegant I could squeak!

In a similar vein I am not a friend of the implicit string<->number equivalence that has become so popular since Perl (I guess) opened that particular box. I am very happy that Go does not follow that practice, but can, apparently, provide well-controlled implicit conversions where they are useful.

C has served me well for nearly a quarter of a century, in more than just the technical sense, and I still like it. But many things are so tedious to do in C. Implementing complex data structures, handling memory management, and constantly aiming carefully for the space between the toes takes, after an initial rush in the first years, much of the fun from programming and is quite tiring in the end.

Go may be just the thing to avoid many of C's tediousnesses, while keeping most of C's expressive power plus quite some of its own, and give me back the fun I have been missing.

http://golang.org/

Update: In the meantime I have learned that Go does no implicit conversion between strings and integers, but instead uses a common interface for print formatting, which is even better.

Update of the update: Later I learned that there is not (and cannot be) one common interface for print formatting implemented by all types and objects, but the formatter code looks at the value via reflection to decide how it should be formatted. There is built-in knowledge for simple types, an interface that can be used for those struct types that implement it, and generic code to explore other struct types via reflection.