We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Designing a programming language for the desert

Formal Metadata

Title
Designing a programming language for the desert
Title of Series
Number of Parts
287
Author
Contributors
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
You need a lot of hubris to design your own programming language. As a result, new languages are often engineered (or "over-engineered") for that glorious future where millions of programmers spend their lives working with the language, and a small army is maintaining the compiler and related tools. But how would you design a language that assumes this bountiful future will never arrive? A language that, even in the best of circumstances, will always be obscure and secondary? Futhark is a programming language designed for a very specific domain: high-level, deterministic, data-parallel number crunching. It explicitly disavows general-purpose use, and it is absolutely not possible to write full applications in it. Thus, even if Futhark somehow managed to become the largest conceivable success and completely dominate its domain, that would not translate into very many programmers. And even then, it would at best be a secondary or third language for most of its users. In this talk I will talk about how such a perspective has affected the design of the Futhark language and its tools. To a first approximation, this is just the "principle of least surprise" applied to every part of the language and ecosystem. As a niche language, Futhark's novelty budget is quite limited, and its users will not have the inclination to learn about syntactical subtleties, elaborate package managers or build systems. At the same time, it's trying to innovate in a challenging domain, so some things definitely will have to be novel. Balancing these concerns has been interesting, and my experiences are perhaps even useful for designers of languages, tools, or systems in similar situations.