## Haskell Researchers Announce Discovery of Industry Programmer Who Gives a Shit

I actually found this to be rather funny.

## Eff - Language of the Future

This is just a series of blog posts so far, as far as I can tell. But Andrej Bauer's work has been mentioned here many times, I am finding these posts extremely interesting, and I'm sure I will not be alone. So without further ado...

Programming With Effects. Andrej Bauer and Matija Pretnar.

I just returned from Paris where I was visiting the INRIA Ï€rÂ² team. It was a great visit, everyone was very hospitable, the food was great, and the weather was nice. I spoke at their seminar where I presented a new programming language eff which is based on the idea that computational effects are algebras. The language has been designed and implemented jointly by Matija Pretnar and myself. Eff is far from being finished, but I think it is ready to be shown to the world. What follows is an extended transcript of the talk I gave in Paris. It is divided into two posts. The present one reviews the basic theory of algebras for a signature and how they are related to computational effects. The impatient readers can skip ahead to the second part, which is about the programming language.

## Omega - Language of the Future

When I discovered Tim Sheard's Languages of the Future, I realized that PLs do indeed have a future (beyond asymptotically approaching CLOS and/or adding whimsical new rules to your type checker). Compared to languages like Lisp, pre-generics Java, and Python, the "futuristic" languages like Haskell and O'Caml seemed to mainly offer additional static verification, and some other neat patterns, but the "bang for the buck" seemed somewhat low, especially since these languages have their own costs (they are much more complex, they rule out many "perfectly fine" programs).

Ωmega seems like a true revolution to me - it shows what can be done with a really fancy typesystem, and this seems like the first astounding advancement over existing languages, from Python to Haskell. Its mantra is that it's possible to reap many (all?) benefits of dependent programming, without having to suffer its problems, by adding two much more humble notions to the widely understood, ordinary functional programming setting: GADTs + Extensible Kinds.

Sheard and coworkers show that these two simple extensions allow the succinct expression of many dependently-typed and related examples from the literature. Fine examples are implementations of AVL and red-black trees that are always balanced by construction - it's simply impossible to create an unbalanced tree; this is checked by the type-system. It seems somewhat obvious that sooner than later all code will be written in this (or a similar) way.

How to understand this stuff: my route was through the generics of Java and C# (especially Featherweight Generic Java, FGJω, and A. Kennedy's generics papers). Once you understand basic notions like type constructors, variance, and kinds, you know everything to understand why GADTs + Extensible Kinds = Dependent Programming (and also esoteric stuff like polytypic values have polykinded types for that matter).

It is my belief that you must understand Ωmega now! Even if you're never going to use it, or something like it, you'll still learn a whole lot about programming. Compared to Ωmega, other languages are puny. ;P

## The Future of C#

One of the future additions to C# announced by Anders Hejlsberg in this entertaining video from 2008 is Compiler as a Service. By that he means the ability to eval code strings (and I'm guessing that this will also be integrated with C#'s built-in AST objects).

He shows this off at around minute 59, to great effect and great excitement by the audience. It feels like an inflection point. There probably won't be another REPL-less language from now on.

I predict that after that, they'll add hygienic macros and quasisyntax.

OpenSCAD is a software for creating solid 3D CAD objects... OpenSCAD is not an interactive modeller. Instead it is something like a 3D-compiler that reads in a script file that describes the object and renders the 3D model from this script file (see examples below). This gives you (the designer) full control over the modelling process and enables you to easily change any step in the modelling process or make designes that are defined by configurable parameters.

In days gone by I used to post examples demonstrating the power of DSLs over GUIs. This is a nice example I came across recently. The scripting approach may be useful, of course, to 2D CAD as well. Here is an amusing example.

Maybe the analog computing DSL I fantasized about should output SCAD scripts instead of compiling directly to g-code...

## Programming CNC machines in Haskell

While I like the general idea, it seems this project didn't go far enough.

What I think would be cool is to develop are DSLs that compile to g-code. For example, putting my hacker hat on, I think it might be fun to build a DSL for describing mechanical (analog) computers, this will compile into g-code for cams, shafts, gears etc. that could then be manufactured using CNC machines and/or 3D printers...

## The Right Tool

David MacIver is doing a bit of a sociological study on how programmers pick The Right Tool for the job. Programmers select all the languages they know from a fairly mainstream and popular list and then rank those languages according to statements like "I find it easy to write efficient code in this language" and "When I write code in this language I can be very sure it is correct". At the end of the process the survey taker can see how languages ranked overall under each statement and what statements have been most strongly associated with each language.

Obviously this isn't a formal study and, as with all online surveys, there are going to be challenges with selection bias and with people trying to game the system. None-the-less, it is pretty interesting and fun as is. Perhaps something similar would be worth doing under more controlled circumstances (although it beats me how to feasibly get a large sample size of programmers without introducing selection bias).

## Brians functional brain

A rather fun and instructive series of posts about implementing a cellular automaton in idiomatic Clojure, and making it run fast (and in parallel).

Be sure to read the second part, and the errata.

## Code Bubbles

Most of you have probably heard about Microsoft's now-completed Visual Studio 2020 competition, where the grand prize was to meet Scott Guthrie, the effective head of the Developer Division. People were invited to make submissions, and one of them was shown on Code Project and began life as the Visual Studio 2010 Concept IDE.

Well, Ph.D. student Andrew Bragdon has his own take on "inventing the future". Code Bubbles is an IDE that will be presented at this years ICSE. The level of thought that has gone into this design is simply astonishing. It has the feel of a tiling window manager like XMonad or awesomewm, but without the traditional MDI Application or SDI Application WIMP metaphors we're used to; as a result, it eliminates a ton of clutter. It also integrates key ideas from Eclipse contributed by Mik Kersten and Borland/CodeGear: The Mylyn project for integrating workflow deeply into the IDE. This is some real inspiration for Gilad Braha's Newspeak project (Vassili Bykov's Hopscotch IDE; LANG.NET 2009) and Dan Ingalls' Lively Kernel, since the staple of any good Smalltalk-like language is the environment!

Will makers of 30" monitors will be shaking developers down by their ankles? :)

## The Recruitment Theory of Language Origins

Leo Meyerovich recently started a thread on LtU asking about Historical or sociological studies of programming language evolution?. I've been meaning to post a paper on this topic to LtU for awhile now, but simply cherrypicking for the opportune time to fit it into forum discussion. With Leo's question at hand, I give you an interesting paper that models language evolution, by artificial intelligence researcher Luc Steels. Steels has spent over 10 years researching this area, and his recent paper, The Recruitment Theory of Language Origins, summarizes one of his models for dealing with language evolution:

The recruitment theory of language origins argues that language users recruit and try out different strategies for solving the task of communication and retain those that maximise communicative success and cognitive economy. Each strategy requires specific cognitive neural mechanisms, which in themselves serve a wide range of purposes and therefore may have evolved or could be learned independently of language. The application of a strategy has an impact on the properties of the emergent language and this fixates the use of the strategy in the population. Although neurological evidence can be used to show that certain cognitive neural mechanisms are common to linguistic and non-linguistic tasks, this only shows that recruitment has happened, not why. To show the latter, we need models demonstrating that the recruitment of a particular strategy and hence the mechanisms to carry out this strategy lead to a better communication system. This paper gives concrete examples how such models can be built and shows the kinds of results that can be expected from them.