JavaScript, and lessons learned

For various reasons, I found myself doing a bunch of JavaScript stuff this weekend.  The project was to get a decent WYSIWYG editor into Redmine.  Because I don't feel like writing an essay tonight, here's the short version of what I learned: Redmine is actually pretty easy to write plugins for; the development model is not bad at allJavaScript sucks balls.  It is a truly hideous language.The jQuery and Aloha devs are programming gods.  What they've produced is incredible, considering the fetid, rancid cesspool that is JavaScript.jQuery is a nice toolkitAloha is slickAloha and Redmine documentation isn't very good.  jQuery is not bad"Dependency hell" takes on a whole new meaning in JavaScript.My biggest take-away from this was that Golang is a much better place for me; it's a lot less work to write good code in Go than in JavaScript; there's a lot less ambiguity.  I'm not sure if I could survive in the JavaScript world.  It's simply too chaotic for me.

Read More

The power of ad-hoc interfaces

That’s not a technical term; it doesn’t mean anything by itself.  But since Go doesn’t have a term (or I’m not aware of it) for the particular flavor of type interfaces it supports, I’m calling Go’s interfaces “ad-hoc interfaces.” I keep being tickled by Go’s submarine features.  These are things which aren’t touted with any fanfare, but which I find more useful as I gain experience with the language.  In this case, the feature I’m growing increasingly fond of is the fact that types are not tightly coupled to interfaces; this is in contrast to Java objects, which are tightly coupled to interfaces.

Read More

Now *this* is interesting

I needed to compare some images for something at work and have been trying a few different approaches.  Since I wrote the application that’s using it in Go, and since this was going to be called tens of thousands of times, I was looking for a Go library rather than something I’d have to fork off a bunch.  I ended up implementing a couple of libraries, and one of these was a near-line-for-line clone of the pdiff application.

Read More

Programming satisfaction

The satisfaction quotient is very high with Go.  This post isn’t so much about Go, per se, except that I’ve been getting a high amount of satisfaction with my Go programs. I moved into management last year, and I don’t have much time for coding any more.  I work more managing than I did programming; most of my week is spent in meetings, which means that to get any of my tasks done, I have to put in more hours than the standard 40.

Read More

Go and Java

I recently had to write something in Java again, and was struck by the fact that – with Java – absence does not make the heart grow fonder. The little test application just read in an HTML file and broke it out into pieces – a prefix, containing everything up to and including the tag, the inner body HTML, and a suffix including the close body tag and everything after it.  It was just a sanity test for some regexp in Java.

Read More

Go revelations

Hoo boy.  There are some things which need to percolate in my subconscious for a while before I figure them out; when my brain accomplishes this feat, it’s a thoroughly enjoyable revelation.  When I was 20, it would happen in hours, or overnight; now it seems to take a bit longer (a couple of days), but I still enjoy it just as much. Go has a sort of multiple inheritance based on a rule called shallowest-first.

Read More

Mozilla's Rust Language

Mozilla released version 0.1 of it’s programming language offering called Rust.  There are a number of things about Rust which are nice; it uses LLVM, which means it gets tail-call-optimization, which Go doesn’t have; it has isolated, lightweight tasks, and channels much like Go; I’ve come across discussions about Erlang-style supervisors, which is encouraging; it has a Ruby-like syntax for closures; it has some limited type inferrence (very similar in scope to what Go can do); and it has pattern matching a-la OCaml, which Go doesn’t.

Read More

Universal truths

The fact that channel communications (whatever their implementation details) take much, much longer than function calls seems to be a constant truth no matter what the programming language.  I don’t have the benchmarks for Erlang offhand, but here are ones that I just recently ran for Go: main.BenchmarkChannel-2     500000              6106 ns/op main.BenchmarkFunction-2        100000000               10.2 ns/op main.BenchmarkAnonymous-2       100000000               11.5 ns/op Here’s the source code in case you want to pick holes in my benchmark: package mainimport “testing”func BenchmarkChannel(b *testing.B) {        c := make(chan int, 1000)        accum := 0        go func() { for { accum += <-c } }()        for i := 0; i < b.N; i++ {                c <- i        }}func BenchmarkFunction(b *testing.B) {        accum := 0        for i := 0; i < b.N; i++ {                handle(i, &accum)        }}func handle(v int, accum *int) {        *accum += v}func BenchmarkAnonymous(b testing.B) {        accum := 0        f := func(i int) { accum += i }        for i := 0; i < b.N; i++ {                f(i)        }} This was run with: gotest -run -cpu=2 -bench=‘.‘ Changing GOMAXPROCS didn’t make any difference.

Read More

My shocking Erlang discovery

Sending messages to PIDs is really, really slow (comparatively). Consider the following code, containing two tests that do almost the same thing.  I say “almost” because there’s a small bug causing the totals to be off-by-one, but they’re performing the same amount of functional work.  One uses PID message passing to increment a value; the other uses lambda expressions. -module(test).-export([test/2]).-export([one/1, two/1]). test(F, N) ->    A = F(init),    {T,R} = timer:tc( lists,foldl, [ fun( _, Acc) -> F(Acc) end, A, lists:seq(1, N) ]),     F({stop,R}),    io:format(”\n~ps~n”,[T/1000000]).

Read More

Running a code server in erlang

For as old as Erlang is, there’s a distinct lack of documentation about some aspects of it.  I’ve had a hard time finding information about how to run a code server, so I’m going to write down what I’ve learned here. First, there are a couple of things I should note:While you can use the erlang runtime as a hack-as-you-go platform, it’s really better to follow the OTP principles; you get a lot of things for free that you otherwise end up writing yourself.

Read More