Software/Device Development and Design

Those who rely on Moore's Law...

Those who rely on Moore's Law inevitably ignore and fall prey to Wirth's Law.

(See also Jevons paradox.)

Read more


Nemerle's "when": Bad Idea, Easily Solved

It's no secret I'm a big fan of D, and very critical of most other languages. But there is another language I actually do like: Nemerle.

Some highlights of Nemerle

Like D, Nemerle is one of the few languages which truly "gets" metaprogramming and provides a decent implementation[1] (unlike, say, C# which only offers a half-baked generics system plus a dynamic type and simply leaves it at that). D and Nemerle's approaches to metaprogramming are entirely different and both have their pros and cons, but I like them both.

Another thing I love about Nemerle is its powerful, yet extremely accessible, algebraic types and pattern matching. This is actually one area where Nemerle is vastly ahead of D: While D does offer algebraics via its standard library, they're nowhere near as nice and clean as they are in Nemerle.

Nemerle (as does D) naturally has its downsides, though. For one, it lacks D's fantastic "ranges and algorithms" system. Also, like C#, Nemerle's reliance on CLR (ie, Mono/.NET) renders it medicore at best for low-level bare-metal work. And unlike Nemerle's designer's, I remain entirely unconvinced that merging the ideas of "statement" and "expression" leads to an cleaner, nicer language. I realize the common statement/expression separation isn't necessary and hasn't always existed, but I happen to like it, and I find it more useful than problematic. I don't like implicit returns, and as for the benefits of blurring the statement/expression line: Having lambdas, the ternary operator and an expression equivalent to switch blocks are all I've ever desired. The merging just seems unneccesary and overboard. But that said, I can certainly live with it just fine.

Overall, D is still my preferred language. But Nemerle is the only other language I can say I genuinely like.

Nemerle's one big blunder

For all its good, there is one big thing about Nemerle that's been bugging the hell out of me: The if statement requires an else clause. If you don't want else, you say "when", not "if".

That may seem minor, and the Nemerle designers do have a very deliberate reason for it: "to avoid stupid bugs with dangling-else". They provide the usual old dangling-else example that relies on combining bad indentation with omitting brackets on multi-line blocks.

I have a problem with that reasoning.

In language design, any feature or deviation from common expectation needs to pull its own weight. The benefits must outweigh the costs. Let's see:

Benefit: "Eliminate stupid dangling-else bugs": Mmmm hmmm. Ok. So....Who the fuck actually hits this issue?!? I've been coding for twenty-five years. As such, I firmly believe that stupid mistakes happen, to even the best of programmers, and that the true mark of an amateur is believing you can (or have) overcome that. I openly admit I've made, and will continue to make on a regular basis, every stupid freaking mistake in the book...except this one. I have never made this one. I have never even seen this one get made by anyone, anywhere. I admit, I really do have no doubt it does get made. Sure. Occasionally. On rare occasions. But heck, who the fuck ever omits the curly braces around a multi-line "if" body anyway (a requirement for this bug to occur in a whitespace-insensitive language)? If it does happen, who the fuck lets it pass code review, whether dangling-else bug or not?

Is the benefit of eliminating this rare bug worthwhile? Naturally, that depends on the cost:

Cost: Take one of the most basic, common, fundamental constructs in all of programming, modify it, rename it, and force every addition/removal of every "else" clause anywhere to always involve swapping between "if" and "when" on a different line of code.

So, a major disruption to one of the most fundamental constructs in order to eliminate a bug that's quite frankly more theoretical than real? No. No Nemerle, that is not a good tradeoff.

Solution

Luckily, Nemerle's biggest problem also demonstrates one if it's greatest strengths: This design flaw is easily changed, in mere user code alone, without hacking or modifying the language or compiler at all:

macro plainIf(cond, body) syntax("if", "(", cond, ")", body) { <[ when($cond) { $body } ]> }

That's it. That solves it. Those few lines bring back a normal "if". Just toss that into a "plainIf.n", compile to a DLL:

ncc -r Nemerle.Compiler.dll -t:dll plainIf.n -o plainIf.dll

Then toss that DLL into your project:

ncc -r plainIf.dll [...the rest of your args here...]

And magically, you can use "if"s with or without an else. Nice.

For convenience, I've put this code (along with Posix/Windows buildscripts and a small test program) up on GitHub, in a simple project named plainIf.


[1] Ok, I realize there is *ahem* a certain enthusiastic subset of programmers who will look at Nemerle's macros and bring up the ol' "Everything is LISP" idea. And y'know what? They may well be mostly right. But, if I want to drown in a torrent of barely-readable symbols, I'll just use brainfuck and get to the "shoot myself" stage that much quicker.

Read more


Unity and Unreal Compete: Indies Win!

Big news from game engine developers at GDC this past week:

First, Epic dropped the up-front cost of Unreal Engine 4 to "free for everyone", with only a 5% royalty beyond each project's first $3000 revenue (per quarter).

Then, the following day, Unity released their long-teased Unity3D 5, along with an indie bonus of their own: Nearly all previously Pro-only features are now available for free to non-Pro users (excluding the snazzy Pro-only editor skin, darn!).

Also exciting is Valve's unveiling of Source 2, also free for developers. Although, I admit I know very little about Source, so I can't really comment any further on it.

I've had an eye on both Unity3D and Unreal Engine for awhile now, I even dabble in Unity3D a bit, and I find it interesting the directions both have taken. The two engines come from opposite backgrounds: Unity3D from the indie scene, and UE from the AAA industry (Although initially, Epic itself originated from the old DOS shareware scene - arguably the original indie game scene). But lately, they've been encroaching on each other's territory. Unity has been touting one AAA-targeted feature after another. Meanwhile, Epic has reversed the "expensive, exclusive and difficult" image from their UE3 days, and drastically reduced both technical and financial barriers of entry - a move aimed, in large part, straight at indies.

The wall between indie and AAA development tools has collapsed, attacked from both sides, with Unity and Epic being two of the biggest demolitionists (among others as well). And indies are quite possibly the biggest beneficiaries.

Here's what the two engines now offer to indies:

  • Anyone can get started. (Both Unity and Unreal)
  • Easy to use game editing environment, with rapid prototyping and development turnarounds, and loads of useful tools. (Both Unity and Unreal)
  • Engine with AAA-quality and speed. (Both Unity and Unreal)
  • Target all the most popular PC, console and mobile platforms... (Both Unity and Unreal)
  • ...and then some (Unity)
  • Develop and release without investing one cent on tools or engine. (Both Unity and Unreal)
  • Official online store for buying/selling assets. (Both Unity and Unreal)
  • Ease and safety of [an older version of] C# and other CLR languages (Unity)
  • Full power of native C-linkage languages (implying a potential for possibly using D!) (Unreal)
  • Full, unrestricted access to the entire build system and engine source. (Unreal)
  • Partial ability to develop on Linux (Unity via Wine, albeit unsupported and occasionally problematic[1]. Unreal via an in-progress community-driven Epic-sanctioned effort[2].)

Even the few differences above aren't so different after all: Unity is perfectly capable of interop with native C-linkage languages (it just requires taking extra trips manually across the managed/unmanaged barrier), and there's no reason a managed scripting system can't be used on top of Unreal Engine (you're just "on your own" with that, AFAIK).

Of course, Unity and Unreal aren't even the only options in town. There's still Source 2 as mentioned earlier, plus CryEngine, MonoGame (a resurrection of XNA), and even others.

It's a good time to be an indie: Engines compete, we win.


[1] I'll have to save my adventures using Unity3D's editor on Linux for a separate post. In brief: It gets the job done, although not spectacularly well. Certainly not well enough to obviate the need for a native Linux editor.

[2] At the moment, I have no idea what the exact state of Unreal Engine's editor is on Linux. I know it exists, my understanding is that it's usable, but I know nothing about how usable. Could be flawless, could be comparable with Unity under Wine, could be less, I don't know. But I am definitely interested.

Read more


Unity3D vs. Linux Developers: Profit is Fine, But Ignorance is Better?

A little background:

Unity3D has quickly become one of the most significant game engines and development tools in the world, fueled in no small part by being insanely cross-platform. But somewhat contradictory to their belief in cross-platform, their actual developer toolset only works on Windows and Mac, with what's become a rather noteworthy disinterest in supporting Linux-based developers. This, despite the fact that the #1 voted feature request on their own feature request board, by a wide margin, has long been a Linux-based editor. Naturally, this has been quite controversial with many predictable arguments on both sides.

As a side note, I can personally attest that Wine is not a suitable long-term solution here. I do use Unity under Wine, and I can get work done with it, but there are definite problems (which I'll have to save for a separate post).

With that background out of the way, the rest of this post is mainly in response to this:

"Now, let's be honest, of those 9,175 votes, how many of them would actually be developers who would buy [Unity3D Pro] and develop on Linux? Answer: probably far less than the actual number of votes on it."
    - liamdawe @ Gaming on Linux: Unity Confirms They Have No Plans For A Linux Editor

Let's do a little basic gradeschool arithmetic:

In the time since that original post, the votes have increased to 16535.

Up to 10 votes are allowed per user, so let's be maximally conservative and pretend that everyone voting on it used all 10 votes (I didn't, but let's pretend I did). So that's 1653 people.

As for the number of people who would actually buy the Pro version: First, let's make the questionable assumption that the people who have already voted are the only ones who would actually buy it. Second, would you say 10% qualifies as "far less" than the number of people? Hmm, yea, I'd say 10% qualifies as "far less" than 100%. So that makes 165 buyers of Pro.

Let's completely ignore the fact that using Pro for two of the most popular platforms (Android and iOS) carries an additional per platform cost equal to that of the basic "Pro" itself.

There are two pricing options: Flat $1500 until the next major release (at which point an upgrade free is required), or monthly fees that total $1800 every two years ($75 * 24) which is roughly in the general ballpark of the lifespan of each major release. So let's go with the lesser: $1500, and completely ignore upgrade frees.

Unity also profits off their Asset store, even from non-Pro users, and soon they will also offer other value-extras to non-Pro users (hosted build servers and analytic tools). Let's completely ignore all of that.

That makes an estimated minimum baseline of 165 * $1500 == $247,500. Nearly a quarter million dollars US just for a conservative baseline estimate on Linux developers alone. (Don't forget, software developers are much more likely to be Linux users than average computer users are, it is arguably a programmer's OS after all.)

Oh, but wait, there's costs:

Unity Editor is built primarily on what? Unity Engine and Mono. Both of those already run on Linux, with full support. And most of Unity's C++ code (yes, it has C++ code) is in the engine (again, already fully supported on Linux), not the editor. And Unity Editor already runs on one Posix system: Mac.

Additionally, what most people who have never done cross platform development (I have) don't realize is that unless you're doing things really, really, REALLY badly, the vast majority of even a natively compiled (let alone CLR/Mono) program is completely OS-independent.

There's also the well-known developer's rule of "0, 1, infinity" (if you don't know it, look it up). Applied to cross-platform development, it means that adding your first extra platform (already done - Mac) costs far more than adding your second, third or fourth extra platform. (Ok, yes, I'm aware that "0, 1, infinity" technically refers more to not imposing arbitrary hard numeric limits, but the practical reasons behind that are rooted in exactly the same principle I'm applying here.)

All that combines to mean that the real costs (as opposed to imaginary scenarios by peanut gallery members who know exactly nothing about real-world cross-platform development) of creating and supporting a Linux editor is minimal.

There is money on the table, and Unity is throwing it away. They are giving that money, userbase and mindshare to their #1 competitor: Epic, a company who has historically been somewhat MS-centric and yet has already become vastly more friendly to Linux developers than Unity.

Read more


Mobile "Me Too" Fashion

Let me tell you a little story.

Microsoft once had a visual style, Aero, that was widely hailed as "good looking". Then Microsoft switched to Metro which was atrociously hideous in both touch-based and "traditional" desktop modes, and a fairly major flop for the company.

Then Apple came along, decided "I must imitate Microsoft's horrible new visual style!" And iOS 7 was born.

Then Google said, "Yes, me too! I have to imitate Microsoft's horrible looking new visual style as well, lest I be the only one left behind in old-fashioned 'good-looking land'". Thus arose Android L.

Now they all look horrid because Silicon Valley can't pull their trendster, hipster, Portlanian heads out the ass of "me too" fashion industry mentality.

Read more


Google Pulls a Microsoft, Pisses All Over Standards

This one page alone (discovered while searching for why my POP access to Gmail[1] is borderline broken) is sufficient proof that the dumbfucks working at Google have their heads completely up their retard asses, and are hard at work mimicking Microsoft's widely-ridiculed practice of pissing all over standards just for the fuck of pissing all over standards:

https://support.google.com/mail/answer/47948?hl=en

So Google expects people to use a non-standard convention in order to make what I'll call "Google POP3" behave like NORMAL FUCK STANDARD POP3?! Except even that still isn't normal POP3 behavior (unconditionally ignores anything beyond 30 days old whether it's been downloaded or not, and retrieves outgoing messages as if they had been incoming).

And yet, the motherfuckers over at Google have the nerve to pretend to be better than Microsoft? Fuck the whole lot of them. For fuck's sake, it's no secret that many of them came from Microsoft in the first place, so it shouldn't surprise anyone that they are the new Microsoft.

[1] "Uhh, if you hate Gmail so much, why do you use it?" Normally I don't, I run my own mail server. But anytime you do that, you still need an administrative contact address that's separate from your own server and domain. Otherwise, if you hit any registrar or hosting snags (and don't think you won't), then your "official" contact address goes right down with the ship, and now you're really in trouble. "Why not Hotmail or Yahoo Mail?" Uhh, would you use Hotmail or Yahoo without anyone pressing a gun to your head?

Read more