Introducing SDFRY, The Modern Programming Language


Programming languages have stagnated. 1958 was a great year for language development, as was 1995, depending on who you ask. The only problem is 17 years have passed since then and we’re still trying to shoe-horn software development principles into languages not built for them.

It seems that we’re primed for a revolution. Not one rooted in languages picking up steam despite being older than the average Valley CTO, but new languages that make us really think.

Thus, I introduce SDFRY (pronounced “super deep fry”) that strives to optimize writing software for humans, not for computers, named after its fundamental rule: Seriously, Don’t Freaking Repeat Yourself. Designed without buzz-words like “dynamically typed” or “purely functional”, SDFRY fills a gaping void by being a pragmatic every-day language built for developers.

Behold the power of a truly expressive language that eliminates the dry aspects of programming.


Play Connect Four | View Code

The Important Stuff

SDFRY starts by eliminating the repetition of boring syntax that makes code harder to write and even harder to read. The following rules shall be enforced by the compiler:

  • All whitespace is significant. Indentation will be performed by a tab (\t), and at most two tabs may be present on any line of code to avoid repetition. Did you know that almost 40% of all Python code is wasted as whitespace?
  • There shall be no parentheses for function calls or conditions. They’re repetitive, unnecessary, and unnatural. The compiler knows that it’s a function as much as the developer does.
  • Strings begin and end with a tilde (~), which doubles for string concatenation, and the backtick (`) escapes strings for nesting variables. Strings can also end with a newline. This means that when you finish a line with a string, you don’t have to close the quote; much like the elimination of semicolons in other modern languages, using both a newline and closing quote to signify the end of a string is wasteful. The decision to use a tilde instead of a quote was to avoid the masses coming from inferior languages crying about supposed “imbalanced quotes.
  • Functions are declared as a token followed by a colon (:), and anonymous functions are declared simply by a double colon (::). Every competent developer would know what you meant if you removed the millions of def‘s, function‘s, fn‘s, and func‘s from your code. The money operator ($) returns from a function, though single expression anonymous functions automatically return.
  • The comma operator (,) behaves identically to the newline, allowing developers to put together as many expressions on a single line as desired.

Operators and Constructs

Often, developers are forced to write caveman-like statements like if (hungry()) eatFood(); due to limitations in the language. In SDFRY, conditions can be written in prefix or infix notation. eatFood if hungry would likely be optimal in this case. And, in the interest of not repeating ourselves over, and over, and over again, synonymous constructs exist to better match the way developers think:

  • If constructs: if, assuming, given, when, supposing, whenever, wherever
  • Not-If constructs: unless, notwithstanding, lest
  • Else clauses: else, then (for not-if), otherwise
  • Always-true constructs: always, whatever
  • Loop constructs: while, until, for, loop, repeat-until, till, do-while
  • Infinite loop constructs: do, repeat, forever, do-forever

One of the primary reasons bad languages require explicit syntax for calling functions or accessing objects is likely the desire to keep the syntax context-free. This makes it easier for compilers to read code, but it doesn’t always fit with developers’ intentions. As already noted, functional calls are first class citizens in SDFRY. To extend on this, object access is syntactically identical to a function call; once again, the compiler knows whether your variable is an object or a function, and so does the developer.

Thus, in order to solve a Quadratic q, you can just say q solve. The standard -> operator also exists to dereference members in SDFRY, but with opposite semantics to its use in C/C++ where it is simply wrong. The -> operator now points to the object and can be run either way, e.g. addClass hovered -> header or header <- addClass hovered, or write ~Hello World~ -> document.

To maintain consistency, the assignment operator also works both ways, with = and := being traditional assignment and =: being reverse assignment, as does function calling, where a space or <= are the traditional convention, and => passes the argument into a function in reverse. It’s assumed that despite being available, <-, := and <= will not be used in favor of the standard space, =, and space respectively, however they are included to provide symetric calling conventions with their respective reverse notation.

Furthermore, second only to the DRY mantra, SDFRY aims to promote convention over configuration wherever it can. A traditional for(var i = 0; i < 9; i++) loop can be written as just for 9:, making the assumption that you wanted to use i as your incrementor. Nested loops will proceed to use j, k, and so-on.

Functions and Lambda Semantics

Due to technological limitations, developers have traditionally been required to decide whether they want to wrap something in a lambda or not. In SDFRY, this decision making pain-point has been removed in favor of ease of development: everything is a lambda. The underscore (_) will represent the standard this context, providing a 2x (or 4x depending on your keyboard configuration) key stroke savings with no foreseeable degradation when searching or reading.

Think of the following example in JavaScript: $('header').css('top', $('#header').css('top') + $('#flydown').height());. The need to select header twice is redundant and repetitive. In SDFRY, the equivalent would be: header css top + #flydown height => _ css top or more traditionally but less idiomatically header css top _ + height -> #flydown.

In this regard, Lisp showed us the power of lambdas but lacked the balls to enforce it everywhere.

Function arguments by default can be accessed with the @ operator (referred to as the "argument" operator), and subsequently @2, @3, etc., without needing to specify redundant parameter names, further promoting convention over configuration. The @ operator (referred to as the "apply" operator) can also be used to split an array up into arguments to avoid the need for both call and apply. To ease delegation, a function called without any parameters will be passed its caller's parameters.

First-class DOM and Scope

Due to heavy dependence on DOM manipulation both client and server side, SDFRY has made jQuery/Sizzle's $ function part of the language. As such, any CSS selector accepted by Sizzle will be accepted as a first-class variable name.

Although are plenty of examples that demonstrate how broken other languages are in this regard, look no further than typical JavaScript: var sidebar = $('#sidebar');. In SDFRY, developers can access #sidebar directly to mean the same thing. This is especially useful with HTML5's new semantic tags such as <header>, as seen above.

The "lambda everywhere" semantic is exceedingly easy to remember, but it does add some complexity to maintaining the call stack and scope as a developer. As such, scope has been completely eliminated from SDFRY. The reason for this fits in with the core principles of the language: if you are reusing a variable name, you are likely repeating yourself. This should be apparent in every day code in old-fashioned languages that make you write things like this: Box::Box(string name, int width, int height) : name(name), width(width), height(height) {}, only to be called with Box box("box", width, height);.

This will likely become a StackOverflow question, so let me make this perfectly clear: there is no intention to introduce scope to SDFRY, and you will without a question thank us later once you have shed the stigma and baggage associated with maintaining scope as a developer. If you think you rely on scope, you are likely writing incorrect code.

Eliminating scope also ties together nicely with the notion that CSS selectors are first class citizens. DOM elements are by definition global; in jQuery, $('#sidebar') is the same everywhere, and consequently so is #sidebar in SDFRY. Instead of railing against this with different semantics for variables, SDFRY embraces it.

Function Naming

In order to align with the built-in constructs and to maintain the overall idioms of the language, all functions must provide at least 2 synonyms; ideally, a function should provide adequate synonyms such on any given source file each function is only be called by name once, although this is not always possible. Synonyms shall be defined with the pipe (|) operator, as in this function signature: addClass | classify | appendClass className:.

This ensures that repetitious function calls will not appear on the same page of code to better engage future developers.

Additionally, SDFRY brings name resolution to the 21st century by providing three different resolution approaches. First, of course, functions can be called by name, as in any language. Secondly, function names will be matched by the least number of characters needed to resolve. This means that an object with functions addClass and append can be differentiated by ad and ap. Thirdly, camelCase functions will be resolved by acronym, so e iips will invoke jQuery's event.isImmediatePropagationStopped(), barring any conflicts.

The motivation for the alternate name resolution was the obvious dependence poorly designed languages have on IDEs. Sure, all the major IDEs will already write "isImmediatePropagationStopped" when you type "iips" and hit tab. But to paraphrase some guy on Hacker News: if your IDE makes writing code easier, your language sucks. The corollary is, thus, that bringing these features into the language ensures it will not suck or be held hostage by advanced IDEs that write and refactor code for you. IDEs? What is this, Java? Total non-starter.

Usage and Deployment

As SDFRY is an exceptionally high-level language, it will likely compile to many languages with time. The spec implementation has been written to compile to JavaScript for both client and server code, due to its monopoly on the client-side and similarity in semantics (lambdas, loose types, little care for correctness), although it's not unreasonable to assume that in the future it will support languages like PHP (for widespread server-side availability) or Fortran (for performance), thus providing the ultimate silver bullet: developers can write in SDFRY and have the performance-intensive parts compile to Fortran (and then optimized assembly), server-side work done in PHP, and client-side work done in JavaScript for free.

The module system closely resembles that of NodeJS and other scripting languages, but with some modifications to better suit the language. Most notably, there's no require function. Code that needs to be split up into separate files is likely too long. A better solution than splitting your code into multiple files would be to re-think your code and write it better.

Future Plans

There exists debate within the community as to whether the standard UNIX way of invoking scripting languages is ideal for a language of this power and expressiveness. Currently, the spec implementation runs the deepfry [file] command, which produces the appropriate files to be run.

Many feel strongly, however, that a REPL would be better suited, with no option to load a file from disk. The code would be typed into the REPL at first, and further modifications could be made accordingly at the prompt. The environment would be responsible for saving the current state when it was closed, and respawning to that same point. This would again take powerful aspects of Lisp and extend on them in a way that Lisp failed to do. Arguably, if you are loading code from a file, you are being repetitious. This will be re-addressed before version 1 is released.

On a brighter note, I'm pleased to announce that we have found a publishing deal for Learn SDFRY the Easy Way; prior to this point, we were having trouble convincing a publisher to print a hard-cover reference book that was only 12 pages including the copyright mumbo jumbo, preface, and author biography. Having an official text should also encourage the widespread adoption of referring to SDFRY developers as greasers as opposed to the derogatory SDFRY'ists or fryers.


Right now, SDFRY is in a private beta only for developers who are awesome. I primarily wrote this so that I could take over the world by myself, but realized that since it's so awesome I have no choice but to share it. But only with people who are worthy, since it guarantees you're going to be great. It will be released for everyone to use soon, once everyone achieves expert programming abilities. If you attempt to clone this in an afternoon and put it on GitHub for everyone to use, well, kudos to you, but expect serious patent litigation. In the meantime, those in the private beta can start changing the world with their unparalleled level of expressiveness.

SDFRY offers an edge for startups so large that they will succeed over everyone else. So if you're not using SDFRY, stop working, and start talking about tools instead. And stop using bad languages.

UPDATE: I've received many emails asking about the syntax of comments. At this time, general consensus in the community is that the language is so self-documenting that comments are unnecessary, and as such have been left out of the spec. It's likely that any proposals for comments would be rejected on the basis that they simply repeat the code, however I personally have not ruled them out.

5 Responses to Introducing SDFRY, The Modern Programming Language
  1. Jason Palmer

    I tend to agree regarding comments, however one key use for them (IMHO) is for TODO’s. Code is always ever-evolving, and I find a great way to remember to take care of technical debt or enhance a feature in the next iteration is to place a TODO comment.


    if I had to write without comments my code would become longer (and possibly less DRY) to deal with reality; servers and accounts change, upcoming features are planned. Most of us single developer projects live in the code; not in GIT and waterfally documents.

  3. Bijay

    Seems preety cool.

  4. Zion

    Howdy! I’m at work browsing your blog from my new iphone 4! Just wanted to say I love reading through your blog and look forward to all your posts! Keep up the fantastic work!

  5. 14to9

    Outstanding post. Richly detailed and satisfying. Of all of the carefully crafted elements, somehow my favorite is the lack of trailing quote on “imbalanced quote.