once bitten

words and things from Edd Dumbill 
Tags


Filed under

programming

 
August 31, 2010
 

Clojure aims to minimize accidental complexity

A lot of people talk about how wonderfully expressive is Clojure. However, expressiveness is not the goal of Clojure. Clojure aims to minimize accidental complexity, and its expressiveness is a means to that end.

via nathanmarz.com

I am loving everything Nathan writes about Clojure right now. This concluding paragraph is a wonderful summary of the primary attraction of Clojure to anybody who's written software for more than a few months.


Filed under  //   clojure   programming  

Comments [0]

August 11, 2010
 

Why use Clojure?

Clojure gets data structures right
via programming-puzzler.blogspot.com

This quote comes from a detailed explanation of why the author uses Clojure. But this simple sentence resonates most. The whole post is very much worth reading.


Filed under  //   clojure   programming  

Comments [0]

July 15, 2010
 

John Graham-Cumming: Programmer Gore

And when distributed or parallel systems go wrong, they go wrong in weird and wonderful ways that make great programmer gore stories.

via blog.jgc.org

I love this tale of computers gone wrong. It happens all the time, and it's great to talk about it. Underneath the fun and the horror, we learn. Just a little. Sometimes not just about computer systems, but about ourselves too.


Filed under  //   programming   stories  

Comments [0]

July 13, 2010
 

REPLs suck, I want something block oriented

via youtube.com

Not for the first time, it struck me today that while they are powerful for tinkering and exploration, line-oriented REPLs like 'irb' in Ruby mostly suck. Ruby's a block-oriented language, and you can't do meaningful exploration in a line-oriented environment.

I never had the luxury of working in an Oberon OS -- the video shows Bluebottle, a later successor -- but I really wish for one while trying to prototype code in REPLs. (I did write Oberon, however -- on the Amiga, no less!)

The Oberon programming language itself is a compiled language, and thus not suitable for REPLs, but what I'm wishing for is to take the idea of the Ruby or Clojure REPL and smush it together with the text GUI of Oberon OS. 

If you've not come across the concept before, the idea is that you edit and run programs in place on the screen. To quote the Wikipedia page on Oberon:

Oberon has a text user interface (TUI). It combines the point-and-click convenience of a graphical user interface (GUI) with the linguistic strength of a command line interface (CLI) and is closely tied to naming conventions of the Oberon language. Any text appearing on the screen can be edited and used as command input. Nothing like a prompt is required.

For a wonderful overview of some of Oberon's history, and what it was (and is, with Bluebottle) like to use the system, check out this article by Lukas Mathis.


Filed under  //   oberon   programming   repl   ruby  

Comments [3]

July 8, 2010
 

A JavaScripter writes on why Clojure has the edge on Node.js

I'm a professional JavaScripter so you shouldn't read this as Us vs. Them. But if you're interested in a really high performance evented webserver that has the same delicious lack of ceremony of Node.js, I recommend playing around with Clojure and aleph.
via dosync.posterous.com

I hope nobody paints this as too much of a religious war. As far as I'm concerned, Node.js and Clojure/aleph have a lot in common, and are exposing developers to a more efficient way of writing applications. (To be truly efficient in writing JavaScript, your keyboard needs a }); key of course.)

I really need a spare hacking weekend to get on top of this. I've been looking for the right way in to Clojure web applications, and aleph is very intriguing.

For reference, here's Hello World in Clojure/aleph

(use 'aleph)
        
(defn hello-world [request]
  (respond! request
    {:status 200
     :headers {"Content-Type" "text/html"}
     :body "Hello World!"}))

(run-aleph hello-world {:port 8080})


Filed under  //   clojure   javascript   nodejs   programming  

Comments [2]

July 6, 2010
 

Alex Young: Oblique Strategies for the Autodidact

Oblique Strategies for the Autodidact

Next time you come to start a new language:

  • Try keeping your initial studies broad: get an overall picture of the landscape
  • Don’t read too much detail early on to keep motivated
  • Learn how to make the environment work effectively before writing code
  • Find the best sources of documentation. When you get the inkling something is wrong, plunder the docs
  • Read other people’s code
via alexyoung.org

Fun little post on learning a new programming language. Unsure I agree on every point (I enjoy a bit of rushing in and mistake-filled hacking), but it's worth sharing for the subheading "Oblique Strategies for the Autodidact" alone.


Filed under  //   learning   programming  

Comments [0]

April 2, 2010
 

Programming languages I've learned, in order

This is a fun programmer meme, from James Tauber. I may have missed a few, but here's my personal programming language odyssey.

  • BASIC (Sinclair ZX-81)
  • Z80 assembly
  • BASIC (BBC Micro)
  • 6502 assembly
  • BASIC (Commodore)
  • Logo
  • Pascal
  • LISP
  • 680x0 assembly
  • C
  • Rexx (Amiga)
  • Ada
  • Oberon
  • Haskell
  • Prolog
  • Perl
  • Java
  • Javascript
  • C++
  • Lua
  • Scheme
  • PHP
  • Python
  • C#
  • Ruby
  • Objective C

Bolded entries are languages I've used recently.


Filed under  //   programming  

Comments [0]

November 13, 2009
 

Brief encounter with the Go language

I won't pretend my opinion on Go counts for much, but here are the results of my first encounters, following the installation guide.

$ cat >hello.go <<EOF
package main

import "fmt"

func main() {
	fmt.Printf("hello, world\n")
}
EOF
$ 6g hello.go
$ 6l hello.6
$ ./6.out
hello, world

Go is a compiled language. So how does the binary stack up against C compiled programs?

$ ls -sk 6.out
 624 6.out

Wow, 624KB (against 8.5KB for the same in C, on Mac OS X 10.6). But:

$ otool -L 6.out
6.out:

So, no shared libraries. The result's completely self-contained.


Filed under  //   go   programming  

Comments [0]