yup. we have a "Functor" https://github.com/maxpow4h/swiftz/blob/master/swiftz/Unsoun... It requires constructing a "Functor" value manually, otherwise it works fine. You can still write functions over an A in Functor. The Result enum bug presented you can work around by boxing the type, such as in https://github.com/maxpow4h/swiftz/blob/master/swiftz/List.s...

The third problem a work around exists for: remove the default argument. If you want an empty init, provide one.

Sure it is buggy, but you can express these programs.

Thanks for the Box suggestion; I'll try it and see how it works for me. I wouldn't have thought of that workaround.

the twitter app is 30M, we have already past the point of sensible app sizes. edit: fb messenger is 60M, a ghc-ios app with the elm compiler baked in is 24M.

To me that makes it clear that a minimum size of over 20M is a serious problem.

How crazy would it be if the Twitter app was over 50M, or Facebook Messenger over 80M?

(I should not have said "serious problem", I should have said "notable barrier to adoption." That people have made this possible at all is fantastic.)

You may want to try using TemplateHaskell. Where you had:

    data MetaData = MetaData {
      metadataUrl :: String,
      metadataTitle :: String ...

you can use

    import Data.Char
    ...
    upStr n s = toLower (head (drop n s)) : (drop (n+1) s)
    $(deriveJSON (upStr 8) ''MetaData)

This will splice the `metadataUrl` to use the `url` field from JSON. The deriveJSON function takes a function to change the field names.

It's pretty handy.

No it doesn't. It gives the right to any users of your service to get a copy of the source code under the same license. Has nothing to do with "code be made available to the public".

unclear, the license says "interacting with", so even getting a not authorized response technically entitles you to a copy of the source code...

It does both.

'Users' and 'public' are being blurred in this thread.

GitHub wrote about this back in 2009.

https://github.com/blog/517-unicorn

The main problem here is it isn't communicated effectively to users.

From here, I think we should move to a distributed model, like email and xmpp.

It needs to be Open Source so anyone can run it and everyone owns their data.

It needs to be compatible with current Twitter apps so all it requires is setting the API root.

It needs to be distributed so anyone can follow anyone anywhere. There is no owner or root, there is no place to shut down.

Proof of concept: https://nstatus.herokuapp.com

Source: https://github.com/maxpow4h/nekomimi

I wrote about the requirements of it here: http://maxpow4h.com/blog/twitter/

edit: you can use any username with any password to sign in to nstatus. It then uses that password for your username. You can even do this from the official iOS Twitter app, just sign in.

Sounds like what you are after is buddycloud (https://beta.buddycloud.org), lets list its win points:

- open-source - open-standards - free - federated

Keep your own data, talk with whoever you wish.

Built on XMPP and actively contributed to by a great group of developers (admission: I am on of these developers).

When you join up you can find me at lloyd@evilprofessor.co.uk

https://buddycloud.org and https://buddycloud.org/wiki/Buddycloud_HTTP_API to get started.

Or jump into the https://beta.buddycloud.org/team@topics.buddycloud.org to ask any questions about dev issues.

This looks really interesting. Is there a page on the site somewhere that gives a high-level overview of what it is and how it works? The wiki has lots of technical details, but nothing I could find that you could email to a decisionmaker and say "you should read this."

/me nods. I'll write something up this weekend. Thanks for the feedback!

What would its advantages be over status.net/identi.ca?

status.net is great, but I would have federation where you can add a server as a source rather than just a user. Then if that server has a @fred, @fred would always be resolved to the @fred on that server. In conflicts, you should be able to resolve these conflicts and proxy names yourself. (my proof of concept doesn't do this)

Maybe even taking Diaspora and taking out everything except 140char status updates AND adding an API compatible with Twitter apps would be a better approach.

edit: clarity to first sentence.

How do you control spam?

I don't, it's just a proof of concept.

In the distributed implementation I would have a chain of trust from the people you follow, where if you report someone as a spammer, the server that represents people who follow you could look at your list and filter spammers based off this. You could also set the depth to traverse. There is a lot you could do with this.

I'm not saying my implementation is right, but someone needs to do it. Tweeting is a type of communication and needs to be distributed.

It's known as Introsort

No, Introsort is (Quicksort + Heapsort) designed to prevent algorithm to degenerate O(n^2) for particular input sets.

Afaik v8 (and Java's pre Java 7 versions) quicksort algorithms are based on Jon Bentley's work.

There is a git command called git-format-patch that lets you format patches for email. This script then _encodes_ this into a PNG and you can tweet it.

I've added more detail to the README on what happens (refresh, it is probably cached. GitHub pages does that). My implementation of the idea just a couple of scripts and is far from ideal (has dependencies, need twitter api key), but I hope someone likes the concept and builds on the idea.