We report several prominent findings. First, language adoption follows a power law; a small number of languages
account for most language use, but the programming market supports many languages with niche user bases. Second, intrinsic features have only secondary importance in adoption. Open source libraries, existing code, and experience strongly influence developers when selecting a language for a project. Language features such as performance, reliability, and simple semantics do not. Third, developers will steadily learn and forget languages, and the overall number of languages developers are familiar with is independent of age. Developers select more varied languages if their education exposed them to different language families. Finally, when considering intrinsic aspects of languages, developers prioritize expressivity over correctness. They perceive static types as more valuable for properties such as the former rather than for correctness checking.
DEC64 is a number type. It can precisely represent decimal fractions with 16 decimal places, which makes it very well suited to all applications that are concerned with money. It can represent values as gargantuan as 3.6028797018963967E+143 or as measly as 1.0E-127, which makes it well suited to most scientific applications. It can provide very fast performance on integer values, eliminating the need for a separate int type and avoiding the terrible errors than can result from int truncation.
DEC64 is intended to be the only number type in the next generation of application programming languages.
An empirical study to determine if identifier-naming conventions (i.e., camelCase and under_score) affect code comprehension is presented. An eye tracker is used to capture quantitative data from human subjects during an experiment. The intent of this study is to replicate a previous study published at ICPC 2009 (Binkley et al.) that used a timed response test method to acquire data. The use of eye-tracking equipment gives additional insight and overcomes some limitations of traditional data gathering techniques. Similarities and differences between the two studies are discussed. One main difference is that subjects were trained mainly in the underscore style and were all programmers. While results indicate no difference in accuracy between the two styles, subjects recognize identifiers in the underscore style more quickly.
Interesting research from Microsoft on equipping compilers with information necessary to automatically parallelize code via reference immutability tagging:
A key challenge for concurrent programming is that side- effects (memory operations) in one thread can affect the be- havior of another thread. In this paper, we present a type sys- tem to restrict the updates to memory to prevent these unin- tended side-effects. We provide a novel combination of im- mutable and unique (isolated) types that ensures safe paral- lelism (race freedom and deterministic execution). The type system includes support for polymorphism over type quali- fiers, and can easily create cycles of immutable objects. Key to the system’s flexibility is the ability to recover immutable or externally unique references after violating uniqueness without any explicit alias tracking.
A slideshow by Rob Pike, one of the principal inventors of Go. I was surprised by the number of places I found myself nodding along in agreement, having independently arrived at similar opinions about the Way Things Ought To Be Done.
Go has definitely taken over a big piece of the ground I had originally intended to cover with Radian, but I still think there’s room for a comparable language on the more dynamic / scripty end of the scale. Go is a tool for concurrent programming in the large, but there are lots of people who work in the terrain originally occupied by shell scripts and currently dominated by Python, Ruby, and to a decreasing degree Perl, and I think Radian has something to offer there.
$low = lc $str; $hi = uc $str;
low, hi = (str.lower(), str.upper())
low, hi = str.downcase, str.upcase
String low = str.toLowerCase(); String hi = str.toUpperCase();
var low, hi = strings.ToLower(str), strings.ToUpper(str)
string low = str.ToLower(); string hi = str.ToUpper();
#!/usr/bin/env radian import number from radian import string from radian function count_str(i): if i > 0: result = string.decimal(i) & " bottle" & ("s" if i > 1 else "") else: result = "no more bottles" end if end count_str for i in number.range_with_step(99, 0, -1): var bottles = count_str(i) sync io.print( bottles & " of beer on the wall, " & bottles & " of beer," ) var action = "Take one down and pass it around, " if i > 0 else "Go to the store and buy some more, " bottles = count_str(i - 1 if i > 0 else 99) sync io.print( action & bottles & " of beer on the wall." ) sync io.print( "" ) end i
While there are plenty of guides available on how to write good code for Unix-like operating systems, there’s not a lot of information out there about how to package it up for other people to use. This page lists some of the things you should think about when distributing source code for other people to install and produce binary packages from.
I’m unexcited about the first piece of advice – “use GNU autoconf” – but the point of this article is to tell you how to do things in the normal way, which autoconf certainly is.
Examples of some pleasant little syntax tricks for working with range and sequence objects in the Groovy language, which runs on top of Java and its class library.
Interesting reference material: it seems obvious in retrospect, but it had never occurred to me that the process of rendering a floating-point number into a string was the sort of project people might write papers about.
Here’s something I bet you never think about, and for good reason: how are floating-point numbers rendered as text strings? This is a surprisingly tough problem, but it’s been regarded as essentially solved since about 1990.
References to the “Dragon4″ algorithm, and to a recent improvement, “Grisu3″.