It’s 6 simple lines in ~/.inputrc:

# change up/down arrows to be search
  "\e[A": history-search-backward
  "\e[B": history-search-forward
  "\e[C": forward-char
  "\e[D": backward-char
  set show-all-if-ambiguous on
  set completion-ignore-case on

All it does is change the arrow keys to become command history search. So now, if I type se and hit up, instead of getting the previous command I had run, I get service httpd restart. Or svn c which gets me svn commit -F ../whatidid.txt.

This is especially helpful for toggling back and forth between commands. Usually when toggling between two or three commands, they inevitably get out of sync – hitting the up arrow twice brings you to the wrong command, and you have to consciously look for it. Now, the first character of each command guarantees you the right one.

Could I use aliases for all of these? I most certainly could. But with this simple .inputrc change, I don't even think about aliases anymore. Like all .inputrc directives, it also works for the MySQL command line client and other readline-derived prompts.

If you use the command line like I do, this will likely save what feels like hours of your life.

The code is available on GitHub: PHP Formatter, and licensed under the MIT License like most of my code.

It uses PHP’s built-in token_get_all function to tokenize the PHP into operators, keywords, strings, HTML, and whitespace, and then steps through these tokens, focusing mostly on rearranging the whitespace. All whitespace (outside of strings and HTML, of course) is stripped except for multiple sequential newlines which are reduced to a single newline. After that, “correct” whitespace is added back into the code.

In order to avoid creating an unruly mess, it then goes through and ensures that no line is longer than 97 characters unless absolutely necessary (i.e. it doesn’t automatically break strings up yet). For consistency sake, it also re-arranges sequential single-line comments to the same line length.

Additionally, PHP Formatter will format inline HTML for indenting, although the HTML formatting is much more permissive, with whitespace for the most part being left untouched. The indenting rule here is that each line that has an opening tag is indented once (regardless of how many tags are opened on that line), and likewise each line with a closing tag is unindented. For this to work, closing tags are rearranged to remain on the same line as the other corresponding open tags were originally. If a closing tag occurs out of order, unclosed tags will be closed to help promote valid markup.

As an added perk, inline JavaScript (through script tags) will be formatted using the JS-Beautify PHP port if it’s available alongside the PHP Formatter. I forked this in order to make it ignore PHP tags inside the JS as though they were just comments, since it’s not actually valid JavaScript, although that’s only necessary if you mix PHP and JS.

All in all, this actually took me a fair bit longer than I thought it would – I was expecting to get a lot more done today and yesterday outside of this – as it turns out that nearly everything about the way we format code is an edge-case, with the word “exception” (or worse “the one exception”) appearing all too often in the comments. Nonetheless, save for a few quirks, it effectively formats code the way I’ve been trying to, and does so with minimal effort on the developer’s part.

Perhaps this sheer volume of time illustrates rather poignantly how great programming is. When I first started programming, I was 10 (let’s not count writing HTML and copying and pasting Perl scripts around from a few years prior to that, since that only barely counts as programming). Within several months, I had released my first open source project with some 20,000 lines of code for the world to see.

Now granted, I’m sure that was 20,000 ugly lines of code. But it worked, and felt magical. Where else can a child create something with as much intrinsic value as a full-fledged bulletin board in under a year with no prior experience, and no mentors or teachers except the open wild internet, and then have people make use of it to boot?

Fast forward a decade and the mystique persists. A rough count suggests I’ve personally written and shipped several hundred thousand lines of code in my life, and written a hundred thousand more that’s never seen the light of day. More interesting than lines of code, though, is that software I’ve directly written has helped people capture tens of millions of dollars of wealth. It’s been run on hundreds of millions of computers. Some of it has been invoked hundreds of billions of times.

To put this in perspective, if I had chosen instead to be a lawyer, or doctor, or some other “accredited” profession, I very likely would’ve helped a grand total of zero people in my career thus far, and couldn’t for another five or so years given that I (likely) wouldn’t even be in law or med school yet.

What intrigues me most about programming is the ability to work collaboratively, yet achieve things individually. This is fun because individually you can punch out a simple web app in a weekend given a well-defined idea of what you’re building, and then grow it to the next level as a team. Perhaps more importantly, though, the ability to work individually allows you to practice and iterate at a higher level than professions that revolve around collaboration.

Stripe co-founder Patrick Collison said it well:

If the same person is designing and implementing, the feedback cycle takes place within that person’s head. Even if product managers have equally good ideas, they’re likely not able to experiment with as many of them.

I think this is an oft-understated aspect of programming, and not just in the context of product managers and engineers. People like to debate whether programming will become an intrinsic skill like math or language, or if programmers will continue to be their own profession. Arguably as more and more industries depend on data-driven decision making, from science to marketing to finance, a specialist who also knows how to write code will simply be able to practice more efficiently – and therefore get better at their specialty – than one who doesn’t.

When you think of it that way, you could argue that “being a programmer” doesn’t really exist, outside of maybe research. Writing the code is the easy part. I’d say code flows from my brain more fluently than English does. Laying out data, organizing code, and writing sequential logic statements is just something I do, like washing dishes or riding a bike. My actual job is building products that help people get ahead. That’s the hard part: understanding requirements, determining what people need and want, and taking it from vague idea to production.

But the programming half of it sure is fun. And in writing this, I hope that maybe I can inspire someone who has considered learning to code to get out there and do it, especially in a market that’s begging for it. Start writing code, open source it, and don’t be afraid to make mistakes along the way. If you need any help, get in touch.

The easiest solution was to write 40 lines of JavaScript to win for me. I spent some time playing around with the shot times, and was unable to get more than 45. But at least now I have a script that gets 45 points automatically every single time:

// first of all, bring in jQuery to handle triggering events
var s = document.createElement('script');
s.src = 'https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js';
document.body.appendChild(s);

// let's define our parameters... basically, how long each shot takes
var wait = 1000,
	freethrow = 100,
	jumpshot = 250,
	forthree = 430,
	waydowntown = 650,
	moneyball = 1000,
	timeouts = [
		// click the start button first, and then the first throw
		// needs a lag first or it doesn't register
		1000, 500, 300, 200,
		freethrow, wait, freethrow, wait, freethrow, wait, freethrow,
		wait, jumpshot, wait, jumpshot, wait, jumpshot, wait, jumpshot,
		wait, forthree, wait, forthree, wait, forthree, wait, forthree,
		wait, waydowntown, wait, waydowntown, wait, waydowntown, wait, waydowntown,
		wait, wait, moneyball],
	n = 0;

// now walk through the timeouts array, alternating between clicking down and up
function go () {
	var timeout = timeouts.shift(),
		i = n++;

	if (timeout)
	{
		setTimeout(function () {

			var e = $.Event(i % 2 == 0 ? 'mousedown' : 'mouseup');
			$('canvas').trigger(e);

			go();
		}, timeout);
	}
}
go();

To run it, just load Google’s homepage or their direct basketball doodle page and paste the code into Chrome’s JS console and hit enter. If all goes right, enjoy a perfect score.

Unfortunately, it looks like the timing of the script may be dependent on the performance of the computer it’s being run on. Tested on three different computers, I got surprisingly different results. On my computer, it hasn’t missed a shot yet. On another one, every now and again it misses one. On a third computer, it wasn’t able to get more than a couple in at all. So, if you can’t experience it first hand, either fiddle with the shot timing variables or just enjoy this video:

I suggested that perhaps the reason that there aren’t any good micro unit testing libraries available for C++ is that you could write your own faster than you could find one, and so everybody just did that; actually, my words were closer to “you could probably do it in a half an hour”. He wasn’t convinced, so I went ahead and did it.

The task at hand is greatly simplified by two features, one in C and one in C++. The first is that C macros let you “stringify” their input, which lets us output what the test actually was. The second is that C++11 can deduce the types of your inputs, and in general print out more or less any type (that has the available conversion, obviously) with streams. This means that not only do you need just two testing functions, test bool and test any comparison (unlike some libraries which try to offer various comparison functions), but you also maintain type safety and are able to take advantage of C++ overloads.

So here’s tester, a micro unit testing library for those who want to just write the damn tests without too much overhead.

Core Functions / Macros

Usage of tester is simple. Include tester.h, and remember these 4 functions (actually macros):

• tester_addsuite(id, name); – sets up the class for the test suite under the heading of the given name. Once run, define void tests::id::test() {} with your actual tests.
• tester_bool(cond, msg); – tests whether the given cond evaluates to true.
• tester_cmp(left, operand, right, msg); – tests whether the given comparison of left and right by the given operand evaluates to true.
• tester_with(var); – outputs a variable name for reference.

Example

#include "tester.h"

// let's test some standard library functions to make sure that they're correct.
tester_addsuite(StdlibTests, "My Stdlib Test Cases");
void tests::StdlibTests::test()
{
	// trailing garbage
	const char *trailgarbage = "123testt5";
	char *endptr;
	tester_with(trailgarbage);
	tester_cmp(strtoul(trailgarbage, &endptr, 10), ==, 123,
		"Trailing garbage in the numeric string should be ignored");
	tester_cmp(endptr - trailgarbage, ==, 3,
		"Trailing garbage in the numeric string should not be eaten");

	// leading garbage
	tester_cmp(strtoul("test123", NULL, 10), ==, 0,
		"Leading garbage in the numeric string should result in a failed output");
}

#include "tester.h"
#include "stdlibtest.h"

int main(int argc, char *argv[])
{
	Tester t;

	t.addCase(new tests::StdlibTests());

	return t.run(argc > 1);
}

That’s all there is to it. Compile along-side the rest of your code (save for your project’s normal main.cpp) and run it:

testproject> ./mytests
Running My Stdlib Test Cases

	[PASS] Trailing garbage in the numeric string should be ignored
	[PASS] Trailing garbage in the numeric string should not be eaten
	[PASS] Leading garbage in the numeric string should result in a failed output
Finished running My Stdlib Test Cases 3 / 3

TOTAL: 1 / 1

testproject> ./mytests verbose
Running My Stdlib Test Cases

	With trailgarbage = 123testt5
	[PASS] Trailing garbage in the numeric string should be ignored
		strtoul(trailgarbage, &endptr, 10) == 123
		123 == 123

	[PASS] Trailing garbage in the numeric string should not be eaten
		endptr - trailgarbage == 3
		3 == 3

	[PASS] Leading garbage in the numeric string should result in a failed output
		strtoul("test123", NULL, 10) == 0
		0 == 0

Finished running My Stdlib Test Cases 3 / 3

TOTAL: 1 / 1

One thing I’ve noticed when writing C++ is just how different my mindset is surrounding “waste”. In dynamic languages, I don’t hesitate to build up nested hash maps and concatenate strings liberally where convenient; one could argue even that some languages beg to be treated that way, and that the expressiveness you gain from being able to throw caution to the wind with regards to performance is a virtue.

However, while I’d readily write some scrappy string concatenations to generate presentable data in say JavaScript, I hesitate about writing the exact same code in C++, thinking twice about the ramifications of copying the string through the various levels of parsing, escaping, and string building, and worrying about the number of times the string is going to have to reallocate and copy; truly micro and premature optimization at its worst. The irony is, of course, that the C++ code would likely be faster than the JavaScript even with dynamic idioms.

So playing around with Folly’s dynamic class was, in a way, liberating. While I love static typing, indulging in the free-wheeling nature of dynamic C++ was oddly satisfying.

Fedora

In order to play around with Folly, I decided to setup a Linux VirtualBox. I launched a 64-bit CentOS 6 ISO, and proceeded to try to get it up to date. I’m going to spare you excessive details, but let’s just say I lost an entire afternoon trying to get CentOS to play nicely with VirtualBox (could not get internet or file sharing to work, though I could access Apache from my computer to the VirtualBox and vice versa) and trying to get GCC 4.7 installed. Memories of trying to upgrade CentOS 5 off of PHP 5.1 a half decade after its successor had been released, or trying to get anything past GCC 4.4 installed even on CentOS 6 lingered as I fired up the VM, having worked with CentOS at BSA (where I end up being the de facto sysadmin), but I felt that I’d still be most productive with an environment I was familiar with.

How wrong I was. After many hours of bashing my head into the wall, wondering how anyone enjoys system administration stuff (I like solving puzzles in my code, not other people’s), I deleted the virtual hard drive and downloaded Fedora, which I haven’t used since I ran a server with Fedora Core 1 when it first came out many years ago. What a difference. In the back of my mind, I had always associated Linux with CentOS and thus always unfairly associated Linux with being a pain in the ass. My outlook has changed thanks to Fedora.

Not only does it come with GCC 4.7 out of the box (not to mention PHP 5.4 and probably updated versions of just about everything else), but VirtualBox’s shared folder integration and bridge networking worked with just two clicks of the mouse. It basically booted up and was in a state that was ready to use. Compiling Folly from there was a breeze, as all of its dependencies were available in yum. While I’m still getting used to systemd and some other things that are different, Fedora thus far has actually been pretty enjoyable to use.

Eigen

While on the topic of awesome open source stuff, I want to give a shout-out to Eigen. If you’re ever doing linear algebra (not that I do very often), Eigen is absolutely fantastic. It’s highly portable, has no dependencies, and is entirely contained in header files, meaning you don’t need to compile a library first. It’s also LGPL, which I think is the most sensible for a library like this.

While some may balk at their use of operator overloading, it’s actually highly enjoyable to work with. Check out the ease of solving a system of equations.

When I first saw it, I was trying to figure out why they didn’t have a better getting started guide for the library itself. Then I realized that the code they provided compiled as-is and that there wasn’t anything else to do, and no platform-dependent intricacies. It’s also incredibly fast execution wise, at least if you’re comparing it to Matlab as I was. I’d go as far as to say that C++ with Eigen is both more enjoyable to code and more practical to use than Matlab.

Thank You

So, thank you to everyone working on Eigen, Folly, Fedora, and of course all of the technologies upon which these are built, for making available such incredibly useful building blocks for the rest of us.

There exists an opportunity here for a service that lets people donate to multiple open source projects all at once, like a bundle site for open source stuff. A way to make donations more as a thank you than a financial contribution, to reward open source contributors while also allowing people to find new projects that they may otherwise never discover based on other people’s donations.

I placed an order for shampoo and some other stuff on Saturday, about $15 with free shipping. They processed it and sent me a tracking number for it Monday evening, and the parcel was delivered in my mailbox at 8:35am Tuesday morning, all neatly packed and wrapped up in recyclable paper and boxing.

American readers, particularly Amazon Prime customers, may be wondering “so what?”, but fellow Canadians should share my joy in finally having services like this up here.

Amazon might as well not exist in Canada. Amazon.ca carries so little that it’s not worth checking. And Amazon.com? If you’re lucky enough for the product to even ship to Canada, it’s not unusual to see $75 of shipping costs on a $20 order.

Honestly, the way US companies ship to Canada you would think we were separated by an ocean and were nothing but tundra; I can see New York from my balcony on a clear day, so I can tell you, it’s not that far.

All this to say, if you’re Canadian, go check out Well.ca. The two orders I’ve placed with them have been awesome experiences – competitive prices with free and fast shipping by Canada Post, everything you could ask for.

An honorary mention goes out to Staples.ca, who also recently introduced free next-day shipping. Apparently Shop.ca is going to start competing for Canadian online consumerism now too. Only a few years late, Canada, but we’re getting there.

Prior to this weekend, Michelle had dabbled in PHP and HTML/CSS here and there, and had a one-semester class in Matlab for her Chemistry program. So when she said she wanted to learn Javascript this weekend, I thought that writing an old-school helicopter game using Canvas in HTML5 and getting it live by the end of the weekend would be a reasonable goal.

Always looking to impress – and quite frankly, from my perspective learning Javascript is easier, or at least way more fun, than writing three chemistry exams in four days – here it is: HTML5 Helicopter.

This is definitely my new favorite game. My high score is 87 131 202.

For this one, I had to take on the dreaded product manager role; it was incredibly frustrating not being allowed to write or talk about code, and having to instead provide high-level constructive feedback and wait while Google answered questions to which I knew the answer.

That’s all part of the learning process, though, and I myself learned a valuable lessons: not being able to do real work invokes an overwhelming feeling of helplessness and uselessness all at once, and is not something I would wish upon my greatest enemy. But the old adage that if you want something done right, you have to do it yourself is nowhere near as accurate as I had previously believed.

So one morning while I was in a holding pattern waiting on a couple of UI screens for BSA v3, I whipped up our very own Donut Bot to hang out with us in Campfire.

How does it work? In its simplest form, the Donut Bot allows for team members to acknowledge favors or good work by sharing donuts. Just type !give 10 Nathan for writing the Donut Bot and the transfer is complete.

But it doesn’t end there. The Donut Bot also offers a roulette wheel for anyone hoping to increase their donut count. Indicate your bet by typing !roulette 10 red. It accepts red, black, even, odd, hi, lo, and any number straight-up. When all bets are in, one person types !spin to let it fly. As a single-zero table, you’re better off with us than in Vegas.

The nature of gambling has proven interesting at BSA. For starters, many of us (myself included) are compulsive gamblers who should never set foot in a casino. Almost 1500 wagers have been placed since the bot took flight on March 1, with 250 of those on the first day alone. Donut bankruptcy has been reached at least a dozen times. Lesson learned.

Once the initial novelty wore off, though, we reset the totals, and upped the stakes, establishing a lottery at the end of March, where donuts were tickets. !leaderboard lists the current donut leaders, and !donuts indicates your own donut count. Of course, we used our very own getAds function from our ad code to pick the winner of the lottery.

All in all, the dynamic of sharing donuts has been great. Between bonding over “we’re in it together, double or nothing” bets, helping each other out of donut bankruptcy, and in general just rewarding good deeds, the Donut Bot has been welcomed to our team with open arms.

I’m releasing the code in hopes that other remote teams can enjoy what we’ve been enjoying for the past month. It was put together hastily (we’ve got a ton of great stuff going on at BSA that keeps me busy), and I’m far from an expert in Node.js, so it may not be a shining example of how to write a Campfire bot, but it gets the job done.

It uses the node-campfire library to interface with Campfire. I had to patch it to automatically reconnect to rooms when Campfire drops the connection, but this actually got fixed before I had a chance to share my patch upstream, which is good to see. It also uses node-dirty to store the donut counts. More info on setting up is available in the README file.

Get the code from BSA’s GitHub.

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.

Demo

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.

Licensing

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.