Tuesday, January 18, 2011

c, python, go, vala, mono - what go has to offer

If you are on a Debian / Ubuntu system and just want to write a very short go program [ to experiment with syntax ] then:
  apt-get install gccgo

If you are on a Debian / Ubuntu system and want to test out programs that conform to Go 1.0 then:
  apt-get install golang-go

If you are writing more involved programs and have already mastered basic Go syntax, then Debian 8 (jessie) has Go 1.3 available

You can always download a source package from golang.org directly also

If you want to experiment without doing any of the above then you can write and execute Go code directly at play.golang.org

If you came here looking to install Docker, then you should know that docker requires Go 1.1 or newer, however pre-rolled packages for Docker are available and do not require a separate local install of Go.
  apt-get install lxc-docker

( lxc-docker is available once you have added docker own deb repository )

Now back to the article ...

The ordering in the article title was deliberate, and represents how I feel personally about those languages, based on a cursory look at the licensing and patent situation for each.

Here is a patent statement about Go which is a recent language from Google:


So how does go compare in syntax with the other languages?

Here i show a variable definition as this can be a useful first guess as to how high or low level the language is:

var a uint64 = 1;

a := uint64(1);

Focusing on the first form, this looks to be say 'who then what' rather than the C order which would be more like 'what then who'

Go is not designed for people who are entirely happy using ANSI C, if you were entirely happy, then there would be no reason to hanker after constructs from other languages (Cython, Python, C++, whatever).

Go is braces friendly, and semicolon warm:

If you hate braces, then you are probably not a Java or C# coder, and Go will not interest you either.

I say semicolon 'warm'. Here are the words from the Go site:
You might have noticed that our program has no semicolons. In Go code, the only place you typically see semicolons is separating the clauses of for loops and the like; they are not necessary after every statement.
In fact, what happens is that the formal language uses semicolons, much as in C or Java, but they are inserted automatically at the end of every line that looks like the end of a statement. You don't need to type them yourself.
Seems that the language does use semicolons, but providing you use braces as intended, then you can leave it to the language to insert them for you. Yey \o/

Here is that said in Wikipedia words:
automatic semicolon insertion feature requires that opening braces not be placed on their own lines

So I began with a point about the patent situation for Go...
now what about the license?

Go has a BSD style license and you can find the text here:
   http://code.google.com/p/go/source/browse/LICENSE

Now here is the question I always ask:- Are Debian, FSF*, and Red Hat happy to package / distribute the go binaries provided by Google?

(*In the case of the FSF it is more likely that they will be approached for comment or give an opinion rather than necessarily acting as distributor)

Well there has been some work to add Go compilation to gcc, which compiling from source would have you typing:
--enable-languages=c,c++,go

or just maybe install gccgo direct from your repository ... here for Debian.

Here is where things are with Red Hat / Fedora ... some clarification is required before Go is packaged as an rpm.

( I will not play the game of Debian versus Red Hat in terms of approval, I value both opinions in conjunction with the fsf, in order to feel that others with more experience have okayed the thing. There was a time for me when Debian's say so was the key indicator of such things, but with go-oo.org code and mono in debian, I prefer multiple checks these days )


So where does that leave me in regard to 'Go', and will I learn to program in that language?

Having spent the last few months hopping between C and Python, and checked the patent and license situation, Go / Rest / Nimbus are languages I may never need now that Asyncio is part of Python3 standard library.
  https://mail.python.org/pipermail/python-dev/2013-November/130419.html

Above Go in my list of languages/frameworks to learn would be Cython and Django, by which time, Go may have moved up into the top 20 of Dr Dobbs / PyPL popularity lists.

Monday, January 3, 2011

LibreOffice and 'variant' OpenOffice writing formats

In truth, I know very little about LibreOffice as it is a new project, with new sign on, and has yet to decide it's own goals and morals.

What I would like of LibreOffice is a non-Oracle managed, truly free office suite.

I feel that instead I will be disappointed, however, that is probably my faulty expectation, which already is likely out of step with the project.

Reading the LibreOffice 'ooxml writing' discussions last night was useful, I learned something that raised some questions for me.

Seems that it is the go-oo.org version of OpenOffice that is now in debian (with ooxml write capability).
Did this happen just because somebody complained about the 'Oracle' logo on startup screen? I do not know.

What I do know is the result: Now that go-oo.org variant is in Debian, this fact is now being used by some, as argument for ooxml writing to be included in the default install for LibreOffice (argument not won quite yet).

LibreOffice has Google and Canonical ?financial? backing, and whilst I like some of what Google does, I do not forget that they are a huge corporation with billion dollar revenue. Compatibility is utmost probably in what both Canonical and Google want, and software freedom, probably lists somewhere lower down.

In the last couple of months there have been two mistakes I think:
  (1) Debian project being so eager to pull code from go-oo.org, without considering that in providing ooxml writing code by default, the project has made a choice on behalf of users.
  (2) My expecting LibreOffice to be more resistant to taint than existing free office projects.

If debian can have an emacs23-nox and a full fat emacs23, can it not simply have openoffice.org-dfsg and openoffice.org-odf-ooxml, with the later including provisional ooxml writing support?
In my opinion this would be much more convenient than having a user fiddle with xcu/xcs config files.

Should the existing debian packages be renamed go-oo.org rather than openoffice.org, seems that it might be a more appropriate name.

*go-oo.org contact email is kendy at novell.com and here is an extract from the main page
Go-oo has built in OpenXML import filters and it will import your Microsoft Works files. Compared with up-stream OO.o, it has better Microsoft binary file support (with eg. fields support)

Back to LibreOffice and it's goals, this message seems to read like a manifesto:
    http://listarchives.documentfoundation.org/www/discuss/msg03870.html
I can find no repeat of these goals as a list of objectives on documentfoundation.org
Is Italo solely responsible for setting goals for tdf, probably not. Was he shooting from the hip in an attempt to curtail a monster thread ... possibly.

The difficulties with what choices to make regarding writing ooxml output are highlighted in this message:
     http://listarchives.documentfoundation.org/www/discuss/msg03880.html
and I repeat an extract below:

"It leaves Libre Office with three choices when it comes to these
formats. It can either:-

1. Write in the format as used by Microsoft.
2. Write in the format as specified in the ISO standard.
3. Refuse to write in the new formats at all."

The above are exactly that - choices. To just say "want docx" without being aware of the choices involved, is something you might excuse a child of doing.
However adult computer users cannot sidestep responsibility for those choices.

Having written on a pretty dry subject I include a funny (or despairing?) extract from slashdot:
Fool me 48 times, shame on you, fool me the 49th... Shit! You did it again!
But you won't fool me 50 times. I'm sure you wouldn't do that.