#programming #programming languges
8 January 2013
By many people I met over the years of my professional career as a software engineer, programming languages seem to be vastly overrated. Every now and then I see a battle of this language against that language and a flame war and a shit storm. To what extend - I don’t know.
For me, languages are tools, no more no less. They are tools for humans to formulate repeatable problem solutions in a way a computer and other humans can deal with. Some languages fit better to that solution and some to another. Some ecosystems have that benefit and that drawback, some another. But, no single language supports you in finding the solution for the problem in question. And that’s the crucial point of engineering, to find solutions. Programming, in essence, is selection or creation of Algorithms, and not simply coding.
I never made a big deal about the language I use, and I used a lot. If I have to learn another, I do it, simple as that. Sure, I have a sense of beauty or smartness of a particular language, but in the end of the day I try to choose the right tool for my particular solution. And that’s what I care about the most, the solution, the algorithm. Moreover, this is the right starting point for optimizations by the way. I even helped optimizing code in languages I never used before just by analyzing the algorithmic complexity of the particular solution, an approach many programmers obviously have forgotten while discussing questions like: which language is the fastest.
It’s rather similar to what Nietzsche once said - who spoke a number of contemporary and ancient languages fluently -: it does not count how many languages you do know or do not know, what counts is if you have something to say in the first place. This is why I spent more time reading papers or books about algorithms instead of the most fancy “Programming in XYZ”. If one has something to say, he or she will find a way to say it. If one has not - no language can help.
2 August 2012
These days I’m doing my first steps in the Go programming language. Today I wrote my web server hello world and I’m really excited. All I had to do was to write these lines of code.
package main
import (
"runtime"
"fmt"
"flag"
"net/http"
"strconv"
)
func main() {
// command line argments
port := flag.Int("port", 8000, "http port")
maxprocs := flag.Int("maxprocs", 1, "GOMAXPROCS")
flag.Parse()
// setup processor usage
runtime.GOMAXPROCS(*maxprocs)
// http handler
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello, %s", "world")
})
// http server
s := &http.Server{
Addr: ":" + strconv.Itoa(*port),
}
s.ListenAndServe()
}
Compilation took less than a second, then I could start the server:
$ bin/web -port=8000 -maxprocs=4
send some requests:
$ ab -c 100 -n 1000000 http://localhost:8000/
and this is what ab told me about performance:
Requests per second: 23454.77 [#/sec] (mean)
During that quick test, the web server allocated about 8MB of resident memory, while ab needed 34MB.
Sure, this thing does nothing useful. And also sure, I can reach similar numbers with an embedded Jetty or a POCO C++ embedded web server, but all I had to do to get this to work was to install Go, write that small code snippet and compile. No Maven XML, no painful dependency resolution, just some calls into the standard library and that’s it. Moreover, I have a single statically linked binary, 3.8MB in size, that I could deploy to whatever 64bit-Linux box I want.
This is practically amazing.
12 January 2012
If you ever have to deal with really huge data that does not fit in RAM anymore, but you still need a consistent interface and efficient handling - and you have not the time to write it yourself, as usual - have a look at STXXL. It has some downsides, but after all it works well and efficiently. For me it was the fastest way - both in runtime and implementation time - to deal with data in the TB range.
You may find it here: http://stxxl.sourceforge.net
#Functional #programming #erlang #scala
17 November 2011
I regret. Before I learned to think and to act functional, I proclaimed X=X+1 for years. Have mercy!
#programming #Functional #scala #erlang
17 November 2011
Why functional is better? So many reasons, one comes here: Programming languages are not made for computers, they are for humans to formulate generic solutions computers can solve faster in the details. The imperative style formulates the steps the computer has to follow, the functional style formulates the generic solution as such. Imperative style wants you to act like a machine, functional style allows you to think like a human.
#agile #project management #programming
17 November 2011
I don’t like name dropping consultants. Name dropping transports no knowledge at all, just obfuscates what is needed to find a decision. A little better is concept dropping, but only a little. What I expect of a consultant is, that she or he asks a lot of questions about my problem and afterwards shows two or three possible solutions for that particular problem, combined with an estimation of the costs.
#agile #programming #project management
17 November 2011
In agile, I guess, it’s all about quality, not quantity. Quality of code, quality of user experience, quality of customer satisfaction. It’s about maintaining quality in a world of change. It’s not at all about being as fast as possible, but as good as possible - while everything around us is changing constantly. It’s about being smart, not being “schneller”.
Remark: “schneller” is German for “faster, now”.
Powered by Tumblr; designed by Adam Lloyd and Ingo Schramm.
