What I want for a scripting language
Mar. 8th, 2014 05:06 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
pnathanI've recently switched positions to one more Linuxy.
In this situation, I have, roughly, several options for programming languages to do my job in. My job will entail devops/tools/scripting sorts of things. Things that I need to be able to do include - shelling out, string futzing, regex work, bundling thingies and sending them to remote servers, and *so forth*.
On the plate of possibilities we have - Ruby, Python, Clojure, and Go. Python is the officially preferred language (as well as the common tooling language).
Roughly, the first three languages are similar - dynamic typing, interpreted(ish), unsound type system, relatively easy regexes, and not terribly fast. Go is different - it is statically typed, compiled, also has unsound type system (lots of potshots have been made here), and is actually reasoanbly fast. Go and Clojure both have a relatively sane multithreading story.
I evaluate languages on several areas:
0. Maturity. This is a bit hard to define, but it roughly translates to the amount of times angry engineers have forced changes in the language because mistakes were made (along with the willingness of maintainers to make this change). A good language has had this happen early on and very few aspects are widely considered to be wholly bad design at this point.
1. Expressivity. Where does it live on the Blub lattice?
2. Speed. Contrary to many popular opinions, speed does matter at times, and you need to be able to break out the optmization guns when the occasion demands.
3. Correctness of written code. How likely is an arbitrary piece of given code likely to have bugs? Something like Agda might rate very low here, and something like hand-written hex might rate very high. This is typically achieved by a combination of tests and type systems. Tests rely on having reasonable "seams" in the code creation process, where test instrumentation can be injected and the module evaluated for correctness.
4. OODA decision rate. How fast can you observe your code's effects and change it? Lisps traditionally rate extremely high on this, with C++ ranking supremely low.
5. Quality of implementation. Separate from maturity, the compiler/interpreter actually defines the language you use - it reifies the language. It should, therefore, be a very solid system.
6. Library breadth and depth. Much like implementation and maturity, libraries that have been around a long time, and have had the bugs ironed out of them provide a better service to the language.
I plan to work through each of the 4 languages and write a simple tool to parse logfiles in each language, summing up my experiences with each language as I go through.
In this situation, I have, roughly, several options for programming languages to do my job in. My job will entail devops/tools/scripting sorts of things. Things that I need to be able to do include - shelling out, string futzing, regex work, bundling thingies and sending them to remote servers, and *so forth*.
On the plate of possibilities we have - Ruby, Python, Clojure, and Go. Python is the officially preferred language (as well as the common tooling language).
Roughly, the first three languages are similar - dynamic typing, interpreted(ish), unsound type system, relatively easy regexes, and not terribly fast. Go is different - it is statically typed, compiled, also has unsound type system (lots of potshots have been made here), and is actually reasoanbly fast. Go and Clojure both have a relatively sane multithreading story.
I evaluate languages on several areas:
0. Maturity. This is a bit hard to define, but it roughly translates to the amount of times angry engineers have forced changes in the language because mistakes were made (along with the willingness of maintainers to make this change). A good language has had this happen early on and very few aspects are widely considered to be wholly bad design at this point.
1. Expressivity. Where does it live on the Blub lattice?
2. Speed. Contrary to many popular opinions, speed does matter at times, and you need to be able to break out the optmization guns when the occasion demands.
3. Correctness of written code. How likely is an arbitrary piece of given code likely to have bugs? Something like Agda might rate very low here, and something like hand-written hex might rate very high. This is typically achieved by a combination of tests and type systems. Tests rely on having reasonable "seams" in the code creation process, where test instrumentation can be injected and the module evaluated for correctness.
4. OODA decision rate. How fast can you observe your code's effects and change it? Lisps traditionally rate extremely high on this, with C++ ranking supremely low.
5. Quality of implementation. Separate from maturity, the compiler/interpreter actually defines the language you use - it reifies the language. It should, therefore, be a very solid system.
6. Library breadth and depth. Much like implementation and maturity, libraries that have been around a long time, and have had the bugs ironed out of them provide a better service to the language.
I plan to work through each of the 4 languages and write a simple tool to parse logfiles in each language, summing up my experiences with each language as I go through.
