The Null Device

Posts matching tags 'functional programming'


Toy of the day: PuzzleScript is an online (browser-based) game development environment capable of making a wide variety of turn-based puzzle games, ranging from Sokoban (of which the Hello World-esque example one starts with is a variant) to more sophisticated and/or eccentric games.

Games are written in a functional/declarative notation, consisting of rules; for example, the Sokoban rule allowing the player to push a crate is written as:

[ > Player | Crate ] -> [ > Player | > Crate ]

Graphics are deliberately kept simple, with elements being 5x5 blocks of coloured pixels, giving the game a vaguely Atari 2600-esque aesthetic.

There is a gallery of games made by users, each with an animated GIF representing the game's play. Some examples:

Games were originally turn-based (in that nothing happened except when the player moved), but there is an experimental real-time feature. Somebody has already coded a (semi-functional and not particularly exciting) Pac-Man clone.

(via MeFi) functional programming hacks javascript nifty videogames 0


Edward C++hands, or an essay by Bartosz Milewski on why C++ is harmful to progress:

I’ve been looking for a good analogy of what programming in C++ feels like and I remembered this 1990 Tim Burton movie, Edward Scissorhands.
Having scissors for hands in not all that bad. Edward has many talents: he can, for instance, create stunning dog hairdos.
I often have these kinds of thoughts after attending C++ conferences: this time it was Going Native 2013. The previous year, the excitement was all about the shiny new C++11 Standard. This year it was more of a reality check. Don’t get me wrong — there were many stunning dog hairdos on display (I mean C++ code that was elegant and simple) but the bulk of the conference was about how to avoid mutilation and how to deliver first aid in case of accidental amputation.
The gist of the article is that, because of backward compatibility requirements with C (also known as “high-level assembly language”), C++ is a deathtrap, with numerous potential pitfalls and even more schemes to mitigate them, each with its own flaws and shortcomings:
The C++ lore is that you should avoid naked pointers, avoid arrays, avoid delete. So the remedy for the lameness of malloc is operator new, which is also broken because it returns a dangerous pointer and pointers are bad. We all know (and have scars on our faces to prove it) that you should use the Standard Library containers and smart pointers whenever possible. Oh, and use value semantics for passing things around. No wait! Value semantics comes with a performance penalty because of excessive copying. So what about shared_ptr and vectors of shared_ptr? But that adds the overhead of reference counting! No, here’s a new idea: move semantics and rvalue references.
Milewski's solution is to move to a functional language like Haskell, or if you can't, write your C++ code as if it were in Haskell:
Of course, you might recognize all these pro-concurrency and parallelism features as functional programming — immutability and pure functions in particular. At the risk of sounding repetitive: Haskell is way ahead of the curve with respect to parallelism, including GPU programming. That was the reason I so easily converted to Haskell after years of evangelizing good programming practices in C++. Every programmer who’s serious about concurrency and parallelism should learn enough Haskell to understand how it deals with it. There is an excellent book by Simon Marlow, Parallel and Concurrent Programming in Haskell. After you read it, you will either start using functional techniques in your C++ programming, or realize what an impedance mismatch there is between parallel programming and an imperative language, and you will switch to Haskell.

c++ functional programming programming programming languages tech 1


Geekier-than-thou technology blog Ars Technica have posted a detailed technical review of Snow Leopard, the latest revision of MacOS X, which delivers few new features but instead comprehensively overhauls the inner workings of the system. And there are a lot of interesting things there, from transparent compression of files to the shift to 64-bit and the replacement of the legacy QuickTime system with a new, Objective C-based one, not to mention a judicious sprinkling of user-interface improvements and technologies brought over from the iPhone programme. (Core Animation, it seems, is everywhere, and there's a CoreLocation service which can determine where a machine is.)

One of the most intriguing improvements (to me, as a programmer, anyway) is one at the lowest level: Apple have quietly extended the C language, adding anonymous/lambda functions and closures, which they call "blocks". So now you can create and pass back blocks of code (more or less) as if you were in Lisp, Python or JavaScript, like so:

typedef void (^work_t)(void);
void repeat(int n, work_t block) { 
  for (int i = 0; i < n; ++i) 
repeat(5, ^{ printf("Hello world\n") });
Which, of course, opens the door to functional-style algorithms like map/filter/reduce, passing predicates as function arguments, and other nifty tricks which people in the functional-programming world have been doing without a second thought for decades.

The code in bold is a block. It's not the prettiest syntax in the world, though it is consistent with C, and gets lexical scope. There are more technical details on blocks here (fun fact: a block is an Objective C runtime object, though can be used from vanilla C), and Apple's own documentation here. Apple have made the blocks extention open source, contributing it back to both GCC and the LLVM compiler they're moving to, and submitting it to the C standards working group (as in this paper), so there's a decent chance that they'll filter through to other platforms. (How quickly they're adopted elsewhere is, of course, another matter.)

Blocks in themselves are nifty for the functional-programming enthusiasts, though understandably may seem esoteric to everybody else. Apple, however, are making thorough practical use of them in a new subsystem named Grand Central Dispatch, which allows programmers to rewrite processor-intensive processes in terms of fine-grained units of work, pass them to queues, and have them automatically spread across however many processors the machine has free at the time; which, in theory at least, should greatly increase efficiency without requiring much more effort on the programmer's part.

(via MeFi) C apple functional programming osx programming tech 0


JavaScript 1.7, the version used in Firefox 2.0, has a raft of Python-inspired features, including generators and list comprehensions. So now, you can do things like:

function fib() {
  var i = 0, j = 1;
  while (true) {
    yield i;
    [i, j] = [j, i + j];
var evens = [i for (i in range(0, 21)) if (i % 2 == 0)];
And, indeed, bulk assignments, like:
[a, b] = [b, a];
That is, as long as you're not concerned about your code working on non-Mozilla web browsers. (I wonder whether Microsoft, who still have well over 80% of the browser market, will adopt these new features.)

functional programming javascript python tech web 0


Python 2.3 is officially out, and brings with it lots of features. Generators are now a first-class part of the language (and not part of __future__), which allows a sort of lazy evaluation; Python can import modules from ZIP files; there is the enumerate() function, which allows you to iterate over a sequence's indices and values more efficiently, as well as Set and Boolean types; and there are a number of nifty new modules, such as a correct CSV handler, and more. Oh, and it's apparently 25% faster too.

functional programming programming python 2

This will be the comment popup.
Post a reply
Display name:

Your comment:

Please enter the text in the image above here: