gofr

Well it turns out that gofr does exactly what I want. so yay to the author, and yay for my little pet project, looks like most of the Yak's will have to be shaved another day.

What bugs me about Go

Putting language design aside entirely, because lets face it every programmer has a different idea of what should, and should not, be in the perfect language, there is one thing that is beginning to really bug me about go.

And that is how poorly documented the command line tools are. Firstly see the Plan 9 docs at http... is positively useless to me when I'm on the train with no internet access. Which is a good percentage of the time.

I've been wresting for several days with trying to set up a build system for a multi package project. The documentation for cgo says see the make file, which was not at all illustrative, especially as the make file does not seem to contain any rules that actually call the cgo! All we seem to get is a lot of messing about with intermediary C files. And trying to dig deeper just ends up at the completely undocumented gomake program.

Then my second problem is that I don't want to install the resultant package globally I'm using it in exactly one particular project. Installing it globally for my system is completely the wrong thing to do, especially as I'll be going back an making frequent changes to it, And my ultimate aim is to produce a standalone executable.

The depressing thing is that in this particular instance even the mailing list seems to be of little help. Searching through the archive suggests that no one has gotten an answer to this question. Every thread I found is filled with people saying yes I have this problem too. And the odd, the I have this problem too so I've started writing a build tool variation. I've started yet another thread about this though, just in case I have better results .

So far the only tool I've found that at least claims to handle cgo is gofr. Sadly it seems to be a little out of date at the moment and won't actually compile at. All in all my pet project is delayed, because I've got a Yak or two to shave...


PS: Yes I know its open source, and I would happily contribute documentation, if I actually knew how to solve the problem. Which sadly I do not.

More NCurses

Since someone actually commented on my original post here is a status update
I've actually moved to starting again from scratch, with a wrapper that is more modern than the one I found (It still had semicolons at the end of each line). My new version is already somewhat more comprehensive though nowhere near complete.

One of the changes I've made is to allow method chaining so instead of adding the move and do X method for every single operation I have a Mv and Color and Set (as in attrset) which return the window you called them on. This allows calls like:

window.Mv(10,10).Set(curses.A_BOLD).COLOR(4).AddStr("Hello World")

or better yet:

fmt.FPrintf(window(10,10).Set(curses.A_BOLD).COLOR(4), "Hello World")

Yes I made Ncurses Window type implement the Writer interface : )

And as to releasing it back. I absolutely plan too. Though I still have a few Items I want to get working first such as:

1. Make my InitScreen take configuration options so that it can set things like CBreak, NoEcho and Keypad for you (I already have it initilising the color system if required.
2. Implement the border drawing primitives though this is just fairly mechanical work.
3. Add basic wrappers for the related panel, and menu libraries. I'm still trying to decide how all this should be packaged.
   

Messing about NCurses and Go

So recently I update by go installation and then installed an ncurses library. I quickly discoverd that the ncurses wrapper is incomplete and tends to not be very goanic.

So far I've added a whole host of missing methods and changed a few others. I also added a Write method which lets ncurses Windows work with the methods in the fmt package. I'll have to see if the original author is interested in my changes as I do seem to be taking the wrapper in a slightly different direction.

All together it has been an interesting way of playing with the go language.

Why Go is a good thing

I've seen quite a few posts and comments on blogs along the lines of go is just a crap version of X I can't understand why google is wasting time on it, instead of (just using | improving) X. There are several answers to this.

Firstly Go is probably different from X and does not have the same stated goals as X. Especialy where X turns out to be a high level programming language that has a very large runtime, or runs in a VM or is interpreted.

Secondly Diversity is good. Think of Go as just another mutation of C, which has some new and useful features. Having written a few tiny programs I can see two so far. The first is that even though we are statically typed it is amazing how rarely a type actually appears outside of a method signature. The implicit typing that occurs when you set variables to initial values gets things correct an awful lot of the time. And the big one is concurrency. Everyone knows that programming concurrent software is hard. As the trend these days seems to be to multi core CPU's it is also becoming a very important area. Big thing is that Every program I have written so far has included gorouteens. they are a great way to generate data (if any place you would be inclined to use a generator in Python you'll be creating a go routine.

It occurs to be that a list comprehension style syntax for defining generators would by handy here. But thats just sugar as it where and I can definitely live without it, much as I have been able to live without anonymous functions in python.

I think that Go is a worth while addition to the programming language ecosystem. And this is true weather it survives or becomes extinct.

Generics or Bust

I have to add my voice to the choir calling for generics to be added to Go. As others have noted Go contains no fewer than four parametrized types: arrays, slices, maps and channels. Such types are so mandatory that it seems impossible to build a programming language without them.

And it is an annoying asymmetry that I as a programmer can't define an equally parametrized linked list or binary tree type. I expect that these will come eventually. My hope is that it will be sooner rather than later though.

The Go Language

So there is a new language in town. Having gone through all of the docs I have to say it looks interesting. The need to destinguish between new and make is a little messy, the language FAQ agnoledge this however.

I like the type system, with the implicitly implemented interfaces. It does look like Go programs will involve quite frequent casting. Ditto for the built in concurrency primitives, and I expect that most programs will make quite frequent use of them. Where in Pthon I might use a generator I could well see myself using a goroutine in Go, and getting my generated items from a channel.

A lot of effort has been made to make the language terse, which is a nice feature for a low level language to have. And yes making switch statements default to breaking at the end of each case unless told otherwise. Thank you finally a language that reflects how switch is actually used!

Personally i don't see why they didn't just call the looping construct loop, rather then for. seeing as it is a general purpose looping construct that can be invoked in several ways that look nothing like a traditional for loop. Still this is a minor thing.

What does look certain is that Go programs aren't going to look much like C or java, once enough people learn how to use the language natively. The basic constructs are just different.

Now that I've gotten this far its time to try some actual programming in Go. To this end I've retrieved the list of 99 Lisp problems and I'll see how I go in solving them using Go. Step one will be to build a linked list typo work with. It will be interesting to see how much mindshare Go can capture. And when we can expect a Windows version, lets face it lack of Windows support is glaring omission at present, even if I don't use Windows I still recognise its importance in the marketplace. (Now there's a scary thought Go.net ... its only a matter of time i suspect.)