Medium

The times they are'a'changing.  See you there.
https://medium.com/@sreekotay

iOS 7. Meh.

For the record, I am an iPhone fan -- since day 1 (and I can prove it :)).

But I'm not loving iOS 7.

Don't get me wrong: there's a lot to like. Its modern looking, less 'cutesy' (and way less cheesy), uses motion effectively, and generally improves the user interface affordances for a lot of use cases (contacts link in messages, actions in mail, etc.).  And that doesn't even get into the tons of (overdue) under the hood improvements.

But I think, overall, its a cacophony of form over function that hasn't been executed or even thought through very well .  It took me a little while to put my finger on it, but the things I don't like are almost exactly the things people seem excited about:

• The User Interface blends with the content.  I agree content should be the focus, and the UI should not be noticeable, but that is not what I (generally) see with iOS 7 - instead its a hot mess.  The UI was the star in previous iterations of iOS, and while it was obnoxious, it at least delineated interaction boundaries.  In iOS 7, the "edges" between the 2 are kinda blurry -- too often marking neither as the hero, to the detriment of both. 
• iOS7 looks more modern.  In places, it looks incomplete.  In places, it looks ugly.  In lots of places, it looks great -- but it's hard to argue that it Thinks Different.  The aesthetic is nice - but iOS now looks like a generic (albeit polished) smartphone.
• The UI Metaphors are gone - but not really.  Skeumorphism is dead (for now), and "authentically digital" is the new king.  While I fully and completely agree and appreciate how much more modern iOS looks, it still uses motion metaphors that are incongruent with the look and feel -- parallax, inertia, etc.  It embraces many skeumorphic action patterns that are discordant without the visual cues to anchor it (iOS Timer, I'm looking at you).
• There is no visual language.  Circles used to imply pages/screens.  No skeumorphism -- purely digital.  Now circles are everything:  scrolling, signal strength, progress indicator, etc. Blue is something clickable -- except when you can't, or sometimes its clickable anyway.  Selection visibility is all over the place.  Meh.
• Its been streamlined (and now too much is hidden).  Click, double-click, press-and-hold, flick-in-the-middle, swipe from edge, wat - Apple, stahp.  Its kinda OK when these are global and/or accelators, but in combination with the increasing context sensitivity of these guestures (*cough* search)... not great.

I'm not predicting the end of Apple, or saying it's going to impact anything about their business.

I'm just a little... disappointed.  A few hero screens look great -- but the effectiveness is only skin deep.  

Look and feel?  

Look and fail.

Implementing brainfuck, part 2

Update: Faster binaries posted. Source coming shortly.

In Part 1, I presented some benchmarks (see here) for my brainfuck implementation against some of the best.  I'll now lay out the reference interpreter, the optimized interpreter, and source code.

(I'm slower posting all this than I meant to be:  apologies --- dayjob and all...)

To start, the reference interpreter looks like this:

The source code is here: bffsree_ref.c and bfsree.h.
[updated: fixed missing header]
Executables for Windows and Linux.

Its pretty basic --- pretty much add/subtract, move left/right, get/put, and then loop begin/end. It basically is as basic as you can get, though it include three things that are, only in the loosest sense, "optimizations":

1. Although the interpreter will ignore non-valid characters at runtime, they are actually stripped at parse time.
2. I accumulate operations into a counter at parse time (e.g. ++++ becomes +4)
3. I parse the jump locations for loops at parse time.

These are so simple to do inline that it feels like they hardly qualify, and you'll see all 3 in pretty much every implementation (I'd guess).

And presented below is the optimized implementation that I presented in Part 1:

Note that it is NOT materially different.
The main differences are:

• The collapse of the command and "helper" arrays
• Double-instructioning -- whereby it is assumed that to do anything interesting in brainfuck, you always have to move the pointer, so every instruction has a move-the-pointer offset (saves on instruction decodes)
• The inclusion of the "super instructions" that perform the following common tasks:
1. Pointer shifting in a loop
2. Multiplication of a cell by a constant
3. Setting a cell to a value
4. Multiplication of a cell by a constant, then zeroing
5. Multiplying two cells

The first 2 are pretty straighforward -- most of the work is in the third item: collapsing the existing instructions into the optimized "super" instructions without breaking any contracts.  The primary optimizations are around loop invariance.

There are a LOT more optimizations I didn't yet finish tackling -- dead code elimination and constant propagation, in particular -- that should yield materially better performance.

I'll post the details and source to the optimizing implementation in a future post.  

(Oh, btw, forget to mention -- if you use the "-c" option with the optimized implementation from part 1, it will convert your brainfuck program to somewhat performant C code.)

Implementing brainfuck

Updated:  Part 2 is now available.

For those not aware, brainfuck is a small programming language whose sole existence is to amuse programmers. It has certainly been amusing.

In that vein, I got myself a nice X1 Carbon Touch with Windows 8 a few weeks ago, and as always with a new laptop, I play with a few projects to "break it in". I have a fun little image viewer that I upgraded to touch (a few more things to clean up - may post it), and one of the other toys I thought I'd play with was a brainfuck interpreter and debugger. The debugger part is important, as I've done a few language implementations before, but not all the way through the tool chain, and thought it'd be informative. Sadly, I'm not through the whole tool chain yet -- still have to finish the editor/debugger, but the basic mechanics for the implementation are in place.

Because I'm competitive, I wanted to also try some interpreter optimization ideas. I'd been kicking them around with a Javascript interpreter I did over the holidays (*cough* 2011 --- will get back to it at some point). Brainfuck seemed simple enough that it would be a nice testbed.

Anyway, I'll post some more details and source code, but thought I'd start with some results and executables to "whet the appetite" as it were.

For those who are unfamiliar, brainfuck has only 8 operators: "<>[]+-,." ... and "Hello World" looks like this:

>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]
>++++++++[<++++>-] <.>+++++++++++[<++++++++>-]<-.--------.+++
.------.--------.[-]>++++++++[<++++>- ]<+.[-]++++++++++.

I first built a reference interpreter, and then found a few fast online intepreters: Alex Pankatrov's moderately optimizing implementation (bff) and Oleg Mazonka's "fastest in class" interpreter (bff4) (according to Wikipedia). They both crushed my reference interpreter, which lead to my optimized implementation. Compiled versions are included here:

• Alex's bff for Windows and Linux.
• Oleg's bff4 for Windows and Linux.
• My bffsree for Windows and Linux.

Some brainfuck sample programs are here.

UPDATE: Linux binaries updated; had uploaded in text mode (d'oh!).

UPDATE 02.27.13: Slightly faster binaries updated again.

Performance is as follows:
Linux:

program:	mandel.b	hanoi.b	sisihi.b	long.b
bff	6.0s	12.3s	n/a	14.4s
bff4	6.8s	0.5s	5.9s	3.1s
bffsree	2.7s	0.05s	1.4s	0.2s

Windows:

program:	mandel.b	hanoi.b	sisihi.b	long.b
bff	7.6s	16.2s	n/a	17.1s
bff4	6.8s	1.3s	4.1s	3.1s
bffsree	3.4s	0.8s	1.2s	0.16s

Some notes:

• GCC 4.7 for Windows and 4.6 for Linux were used.
• bffsree and bff can read from a file or stdin.  bff4 reads from stdin.
• "sisihi.b" is a brainfuck self interpreter running itself running "hi123.b" -- basically the executable you pick runs a brainfuck program that is a self intepreter running a self interpreter (itself) that runs a simple brainfuck program.  Which is why they call it brainfuck.
• The difference between Linux speed and Windows speed appears to be gcc version and console speed (Windows console is slow).
• Both bff and bff4 seem to fail with "bench.b" (or are crazy slow) --- not sure what that's about.
• Oleg's bff4 appears to have been the fastest since 2009 -- which is quite impressive.

I'll discussion implementation notes in a follow-up post shortly.
Continued here.

Redux: WebGL Random Pixel Toy

Fun: Check out WebGL Sand Toy.

John Robinson, at his storminthecastle blog, posted a 'cloud' version (i.e. a webpage :P) of a toy app I did 5 years ago.  His version is pretty cool, all the more so because it runs in the browser, using WebGL.

Two things strike me about this (other than general fun/goodness):

1. 5 years(-ish) feels about right on the Moore's law curve, and is probably the target for 'native' smartphones apps making the transition to browser based (if the W3C can get its act together)
2. On the other hand, "runs like native" still seems like the highest compliment one can pay a browser based thing... so there's that.

By way of example for both points, consider:

Viewpoint Media Player 3D, in a browser, circa 2002 using 'SreeD'

WebGL racer, in a browser, circa 2011 using OpenGL

In any case, enjoy.

Kindle Fire: Return of the Desktop?

Much has been written about the Amazon Kindle Fire (Amazon's new Android based touchscreen Kindle e-reader/media player).

Is it a game changer? Maybe. We'll see.

I've certainly ordered one, and though many say its no threat to the iPad, given its media capabilities... I dunno --- people might be surprised. If its reasonably performant (and compatible) for browsing, and given its e-commerce, e-book, and media capabilities... well, we'll see.

Certainly its going to make it tough for other Android tablet vendors; Jeff Bezos is right in asserting that devices alone don't sell (and this is old news) -- it's devices+services, as Apple has amply demonstrated again and again.

All that said, there's another interesting thing about the Kindle Fire that distinguishes its market approach from Apple's.

It's about content.

Apple sells activities -- a lifestyle; Amazon sells content.

Contrast Amazon's pitch with Apple's:

Disagree if you want, but its a philosophy difference that extends to the VERY FIRST SCREEN: Amazon hilights the content, not the application(s) -- go watch the Amazon video at the top of the post again.

Sure, you can by music, movies, and books with your iOS device, and there's no question that's a big part of the appeal -- but Apple's metaphor is about the task (books-->'Winnie the Pooh', videos-->'Inception'), and Amazon's is the reverse.

Interesting.

And here I thought "document-centric" computing, and the desktop metaphor it implies, was dead (I even wrote a eulogy).

Is it going to work? Maybe. We'll see.

But, either way, I have to give props to Amazon, and Bezos, for, well, trying to Think Different... :P