Amazon have launched an interesting service called Mechanical Turk. Citing tales of chess masters hidden inside wooden cabinets disguised as mechanical Turkish chess robots, Amazon introduce the service as Artificial Artificial Intelligence.

Programmers can use an API to schedule tasks with the service, tasks that can only be completed by a human. Amazon then brokers these tasks to humans through their website. The humans earn cash for their uniquely human traits.

The immediate thing that springs to my mind is breaking CAPTCHAs. This would seem to quite possibly have implications for security and anti-spam techniques. I'm sure there are similar but clandestine services which have existed for a while, but Amazon's weight will count for a lot. I assume Amazon will just have to try to ban clients from using the service for these activities. They will be required by law to prevent illegal activity, but catching it will be hard. From a security perspective, computationally intractable but humanly straightforward tasks will no longer really be viable for certain high value tasks, for example protecting services like AdWords.

On the other hand, I think this is more interesting because of the positive things it will provide. Even as a freelancer/startup hacker with very low spending power, it is now possible for me to solve very difficult problems involving intelligence. Amazon allows me to place requirements on the humans who perform my tasks, qualifications. With a qualified workforce, I can ask many difficult questions: "what is the text content of this podcast?" Or "is this site dodgy or respectable?" I could ask the question 100 times and mandate that different workers respond each time, creating a reasonable sample. I could ask "Is this business plan sane?" and require students on business courses respond. There are all kinds of possibilities. I look forward to seeing some interesting applications.

In the longer term, if Amazon is successful in creating a digital market place for intelligence, it will apply some free market economics to the Real Artificial Intelligence industry. Companies that create software that can solve the problems placed on the Mechanical Turk site to a reasonable standard should be allowed to solve this problems in live situations if they can do so more cheaply. The data Amazon collect about the tasks and the solutions will provide an excellent training site for machine learning. I'd love to be able to run some genetic algorithms on the data, and I'm sure Amazon would too.

With this, the Alexa Web Search Platform, S3, the Simple Queue Service and others, Amazon is making a real stand in the web service space, in a way that perhaps only Yahoo! is also doing. I'd love to know what the plan is, certainly to become the platform for a much wider range of revenue generating activities, it's grid computing. But is there a business model in it?

Went along to London 2.0 last night, a monthly meetup of nerds with a web flavour. I met Simon Willison of Django and Yahoo! again, he was the guy got me started on Django, we talked about the sad state of Yahoo! UK. I met Adrian Holovaty, also of Django, and discussed magic removal briefly and possible routes for a transamerican road trip. It was Adrian's first trip outside the US. I felt sorry for him doing it as a fly by night work trip. I met Edward (didn't get his surname), a hacker at ITN and another UEA alumnus. A few years younger than me, I couldn't think of any common friends we might have, and we neglected to bad mouth the professors for some reason. I met Phil Dawes, a programmer at Dresdner Kleinwort Wasserstein, some guys from ThoughtWorks, including the guy responsible for Custard, Remi Delon, the original author of CherryPy and a few other people whose names and associations escaped me. Towards the end of the night we shrunk down into one group and had an edifying if slightly bravado-fuelled discussion about performance traits of Ruby and Rails.

Tonight, Swedish Beers.

Another big advantage of effects-free programming is that it makes developing concurrent applications much safer. Current frameworks seem to stay away from the concurrency issue, each response is generated in a single thread and the web and database servers are used to enable concurrency. E.g. Apache worker thread contains a mod_python which contains an instance of Django. At least it seems this way. FastCGI does a similar thing, spawning multiple instances of the CGI to handle requests. All this means that the framework coder worries not about thread safety. This is a workable solution because HTTP is stateless, just get the cookie, pull the session from the DB and we're ready to go again.

To be quite honest, I'm not exactly what the implications of being able to do concurrent code more safely would be in this context, I just don't have enough experience in this area, perhaps the answer is that a Haskell-based framework would feel very similar in this respect. The coder working on top of the framework would not see concurrency-related stuff. However, I would expect that while Python and Ruby assert that no threading problems will leap up out of the framework and bite you, Haskell would guarantee it.

This does have implications for the framework implementation of course. A mod_haskell solution wouldn't be ideal, Apache's threads are more heavyweight than the GHC solution certainly and so would damage performance. Haskell would be a good candidate for building a FastCGI-based system, but it might be optimal to use HWS. However, HWS has nothing like the usage of Apache and so it's hard to assert it demonstrates the same security and reliability.

Well, it's finally here. Orange Israel is planning to offer their customers the option to reduce their phone bills by watching ads. I infered that this was going to happen a couple of months ago, which makes me sound all on the pulse and super-business-savvy, but really, it was pretty obvious. Advertising revenues have been proven so successfully online that it was really only a matter of time.

But will it actually work? Mobiles are personal devices. When I sit down at a computer to browse or a TV to view I'm entering the fray and I may be more willing to put up with messages from the outside world. Not so with my phone, it's within a metre of me 24/7, I don't step outside it's reach, so I'm more sensitive to invasions caused by it. Traditionally my mobile phone has not been portal to outside content, but a link to a select group of trusted individuals, my friends, family and a select group of work contacts. These are people that I have spent a lot of time vetting and even then I sometimes groan when they ring :-). If somebody outside my mental whitelist calls me, more often than not the call finishes with "Can you remove my name from your database please."

It seems that Orange are showing the ads only when people go out into the mobile net, in this case by playing a game, Celltrix, in the pilot at least. This will certainly keep the invasiveness of the ads to a minimum and so people will be more willing to sign up. This will be an interesting experiment though and I expect lots of eyes are on it, not least those of the GYM club.

One of my crazy plans for total obscurity (the inverse of world domination) is to try bringing some of the back cover benefits of functional languages to the web frameworks arena, basically to build a Rails or a Django in Haskell.

Well, first of all I've never used Rails, so I suck. So I downloaded it. Haven't done anything with it yet, but just to get it on disk is a big step (I'm on the Django devs mailing list for gawd's sake, though only as a lurker). It's all in the name of research guys, honest.

More than anything, this is an exercise in learning a language by applying it to a familiar domain. However, the advantages of implementing such a platform with Haskell are:

1. Non-strict evaluation and compilation provide greater efficiency. Data structure documentation with efficiency comments in big O notation can't hurt either :-).
2. Expressiveness and clarity of code, Ruby is a touch Perlish, though all the Rails examples are fairly pretty (this is DHH's stated goal for Rails after all). Django isn't quite so pretty perhaps, focusing more on practicality. Python and Ruby have some neat syntactic toys, but Haskell is the state of the art when it comes to expressive code.
3. Strongly-typed but with type inference. One of the great things about Django (and possibly Rails) and a feature I prized in InfoCMS was beautiful joyous harmony between the types used at the data layer and the types used at the interface layer. Forms are validated using information about the tables the data will have to later be injected into. Lots of very sturdy data types would be fantastically useful for this.
4. Removal of side effects. Side effects should be limited to the supporting layers that interact with the DB or with the OS etc, my code should be purely functional, allowing clarity and easier debugging and testing.

Now, I'm reading from the Haskell crib-sheet a bit here, and I haven't necessarily felt the power of these supposed advantages just yet, but it's all interesting theory.

On the other hand, there are some clear disadvantages compared to the way things are done in Django and Python at least, and I suspect Rails and Ruby too.

1. Haskell is a compiled, static language. Django's ORM for example, does all kinds of runtime dynamic magic to provide a slick programmer experience. Though they're removing the more magical magic, introspection is still a big part of the toolset. Particularly in the realm of data models and mapping, it will be hard to provide something as usable under compilation.
2. No objects, no variables even! My functional skills are not so leet. I've always been an OO boy. Learning to live without objects and side effects would not be impossible, but it's a huge paradigm shift for me and probably everybody else. Most web hackers want to make their lives easier, and while learning Ruby is a jump many have demonstrated their willingness to make, a whole new language paradigm is a much larger one.
3. Development speed. The great debate: strong typing, prevents bugs or just slows coders down? Everyone has to unit test anyway, so just catch 'em there. Now strong typing in Haskell is certainly no where near as much as a drag as in Java or C++ for instance, type inference whilst retaining both parametric and ad hoc polymorphism means a lot. However I'm certain that the code-compile-test loop sucks compared to edit-test. The compile step is a big drag on my hacking style, and GHC is not known for it's speediness in compilation. I remember hacking Java for wwWebflow and zoning out completely through compiles, so much so that I'd get really lazy and stupid when the time to edit and test came again. This could probably be solved by building a test environment which uses GHCi or Hugs in interactive mode. This would be a must really.

Discussion with Ladislav on Hypothetical centered around the problems of implementing the ORM layer without the O bit. Thinking about that now, I think the best way to go would be to allow a developer to specify rules for marshaling Haskell record types into tables (Django's doing this here). A good set of defaults would be provided, but allowing tweaking of the marshaling rules would allow tenacious DBAs to squeeze maximum performance from the application . Rules would ideally be written in Haskell allowing insertion of custom bits like index magic. Code for pulling records from the DB would be functional, the prevailing model would probably be to write query functions that get used by the controllers. It would be nice to have a Django/Rails/Class::DBI style interface, I just have to think about that some more.

Some of the concerns are deal breakers, but I'd love to test them in the wild. Haskell apps have tended to be toys a bit so far, with the notable exception of Darcs. I guess I kind of hope that there's some possibility that a Haskell web framework could garner some interest in the same way. I should just stick to Django probably :-).

I did actually write some actual code on Sunday, for what it's worth. Just some types for representing requests and responses really, all of which is already done in HWS. It felt good though.

← previous page, next page →

Choose another page: 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113 or return to the most recent entries.

Last updated at 11:32, Wednesday June 18th, 2008. All times are shown in 24-hour clock format and are BST.

Rate my journal on bloghop.com: