jkarni

I played a lot of chess as a kid. The story of Kasparov beating the pawn-of-the-regime Karpov was quite thrilling then. Strange twist that he became a pawn of ultra-capitalism - Peter Thiel, cryptocurrencies, NFTs [0], all under the guise of morality. Sad.

[0] https://www.euronews.com/culture/2021/12/14/garry-kasparov-l...

I've used direnv for a few years now. Especially combined with nix, it's magical how seamlessly you can navigate between very different environments!

I've seen this claim snowball over time as blockchain people desperately try to ad hominemate him.

I do think he did once (quite a few years ago) consult for a blockchain company. That's about the only factual basis I've discerned for it.

(Disclaimer/source: I met Stephen once or twice a while back, via the Haskell community.)

> The road from there to something noteworthy is still long, but I don't think it's inconceivable.

That already happens. People who know what they are doing (i.e. professionals) already buy scripts and book rights and make movies out of them. It works pretty well already.

A browser extension for creating unions/campaigns, that can collectively decide whether to e.g. boycott a website. If they so decide, all members of that union will, when visiting the page during the time-period of the boycott, see a message explaining the reasons for the boycott instead of the site.

(Or the union can decide to display a banner with a message at the bottom of the page, if a full boycott is too strong.)

Eventually the idea is to allow for a more integrated discussion about websites _on the website itself_ (i.e., forums with threads for pages/sites, accessible from that page via the extension, so that starting or participating in the discussion becomes easy).

I think a lot of the difficulties we have in collective organization in the realm of the internet can be ameliorated with a tool of this nature. Think of what it would take to effectively signal something to facebook. How would you find people who might have similar demands as you to organize a boycott? How would they find you? How would you remember about the boycott? How would Facebook know what the "canonical" set of demands are?

The work so far is here: https://izens.net/ (and on github: https://github.com/izens-net). There's still a lot to do, but a basic version of the browser extension already works.

(Other people were involved too, and some did in fact more work than me, in case the tone above suggests it's entirely me work.)

I've thought a lot about digital unionization [0] in the past year or two, primarily because I think it's an important approach to a number of problems we are witnessing. The thoughts below led some friends and I to start building https://izens.net/ as one general approach to this problem.

The first thing to notice is that the calculus of unionization or collective action is very different than what we historically know. As a user, whether you see yourself as a customer or a laborer vis-a-vis Google, in both cases your position is different than traditional customers or laborers. The importance of convenience for all your transactions is much bigger. We probably aren't willing to spend an hour a week going to union meetings, because Google isn't as significant to us (as users) as a traditional employer, and because we have a similar relationship to a variety of other companies (Facebook, Amazon, Apple, etc.) as to Google, which would by analogy thereby entail a lot of time.

Moreover, it is much harder to build a social relationship with people in similar positions. At a job, or at a checkout line, you meet people in the same place as you. With a Google service, it's just doesn't happen naturally that you encounter people (and can easily and spontaneously communicate with people) in the same position as you (even though there are likely so many more). The companies themselves control how you inhabit their "space" - whether you can "meet" other people in the relevant way currently depends, for instance, on whether there is a chat or forum connecting you to those people. And of course, relying on their graciousness for that space is not going to go down well most of the time [1] as soon as this collective organization starts becoming significant. (This sort of control of how social interactions take place has been compared to the British enclosures.)

There are probably a number of valuable ways to collectively organize in this space. But the above considerations, and the fact that our own skills (and hence ability to contribute) are in programming and design, led a few friends and I to an idea: that we could create those spaces for collective organization via browser extensions and phone apps. The idea is that you install a browser extension (we haven't started on the app), and join one or more unions (or campaigns). The browser extension, based on the policy files of the unions you've joined, can a) block the website for some period of time for all its members, with some message; or b) display a banner when a member visits a site. The union members discuss and decide what the policy will look like. From there you can organize boycotts and make demands.

(https://izens.net/ (and the browser extension) is still in it's early phases, so feedback is much appreciated!)

[0] I agree that it may be misleading to think of it as a consumer union in most cases, for reasons other people have mentioned. On the other hand, the Posner & Weyl idea that we are data laborers suggests it might be a labor union. Ultimately, none of this matters much to the broader points.

[1] Compare this to moving out of WhatsApp, which I'm in the process of doing. I can use WhatsApp itself to get in touch with the people I want to coordinate with, thus making that coordinating relevant and timely.

And here is a "Piano Phase" written in C with no libraries that fits in an (old-style, 140 character) tweet:

main(){int l=999,i,j;int v[]={133,119,89,80,75,119,113,80,89,119,75,80};for(;;){putchar(250*(j++%v[i%12]&&(j+i)%v[i%12]==0));i+=(j%l)==0;}}

Just compile and run that with "a.out | aplay".

It's been a while since I wrote this, and I remeber cheating a bit somewhere, but not surprisingly I can't figure out what it's doing much less how it's cheating.

We're definitely still in alpha - during the time we've been on HN, for example, we've discovered that the large amount of traffic projects were getting meant our timeouts were too short. Had we exclusively been using our own patch system for changes, it might have been hard to submit a fix! We turned on github issues again since if someone had a hard time installing or running, they wouldn't have been able to submit bug reports. And we still have breaking changes relatively often.

I'll take this opportunity to say again - this is alpha software, and not ready for production use!

Radicle is a full-fledge (fledling of a) programming language, so you can really do as you wish with access control. Here's the module for authorization [0], and in this module [1] you can see an example of it being used.

[0] https://github.com/radicle-dev/radicle/blob/master/rad/prelu... [1] https://github.com/radicle-dev/radicle/blob/master/rad/monad...

It does support it. In fact, it's much finer grained than Github. It's relatively easy to change things so e.g. patches to a certain file can only be submitted by people in a certain group, while other files anyone can change.

> There is no notion of access restriction for now at least as this is something missing from ipfs itself, check out radicle’s faq.

This isn't quite true. We already have an authentication and authorization mechanism on top of ipfs. So for instance, only admins/maintainers (of which there might be multiple ones) can accept patches.

(Being an admin/maintainer is different than being a machine owner - currently there can be only one owner. Currently owner has to be online for any new inputs to be processed, though reading should work if your data is replicated, and we've already built some tooling around making that easy.)

We store their public key on the machine. They can add (or remove) admins. Every input is signed, and (when relevant) the author is checked for authorization.

There already is access control. Only admins can accept patches, for instance (though a bug we've just made a fix for [0] meant if someone else tried doing it the entire patch system for that project would break). Programmatic content-filtering is really the bread-and-butter of Radicle. Ad-hoc content-filtering is a bit harder, but as I mentioned elsewhere still possible.

[0] https://github.com/radicle-dev/radicle/pull/552

As u/sneak pointed out, you can also completely remove things from the logs. It goes outside the semantics of the Radicle language itself, so it's not exactly first-class, but is possible.

While it's true there's currently no easy way to do that, we've made the machines (the name we use for each instance of an issue, project or patch utility instance) upgradable by the maintainer [0], and each submission is already signed. So if it becomes a big problem, we can write up a little expression that adds banning, rate-limiting, or removes certain content, from the materialized view, and anyone who wants to use it can.

That said, the already-accepted content will still be in the logs of the machine, even if it doesn't show up at all in the materialized state.

[0] This is based on the eval-redefinition we describe here: https://ipfs.io/ipfs/QmadmGA6mBWZ93Wv4XKuCu9wdPf7Da8pjH3Corz...

4GB is a bit of an overestimate (it's probably more like 2.5GB) but yeah, Haskell project often consume a lot of memory when building.

That said, there are brew and deb packages!

To be fair, production (vs. library) code has to usually care much less about being extensible, since whoever needs to use it can also usually change it.

In servant dealing with the expression problem (albeit in a pretty different way than the usual tagless final approach) was in my opinion a pretty big win - it means you can add terms the the API DSL as well as interpretations for it. I pretty regularly do the former when using it, and there are lots of libraries doing the latter. (Disclaimer: I'm one of the authors of servant.)

If you're talking about the discussion of head and snoc at the beginning of the article, laziness just moved the costs around - head becomes O(n) (from O(1)), but snoc becomes O(1) (from O(n)), because you only pay for the snoc costs when inspecting the queue with 'head'.

SEEKING WORK

Location: Berlin Remote: Yes

I'm one of the original authors of the servant web framework [0]. Web services that are statically guaranteed to match the specification API; documentation (in markdown or Swagger) that never gets out of date; client libraries generated automatically. In short, beautiful APIs.

<myaccount>@gmail.com

[0] http://haskell-servant.github.io/

A more complete description is available here [0], but the essence of it is that the type of many functions that used to be specifically about lists has become more general, but also arguably harder to understand.

[0] https://wiki.haskell.org/Foldable_Traversable_In_Prelude

Evaluation-order in a sense is more low-level in Haskell.

Funnily, there's haskell-cafe thread[0], a github issue, and even a paper, about this (and I think maybe reddit got involved too).

Anyhow, the title is kind of too much. At least, given the aforementioned discussions, we're conflicted liars.

[0]https://mail.haskell.org/pipermail/haskell-cafe/2015-April/1... [2]http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf [3] https://github.com/haskell-infra/hl/pull/8

We had QQ originally, but removed it because it wasn't extensible (you can define new expressions in the type-level DSL, but you couldn't add them to the QQ). We've figured out how to do that now, and there's an issue someone opened asking for it back (https://github.com/haskell-servant/servant/issues/55), so it'll probably soon return.

You do get kind of used to it, though, for what it's worth. And you can always break things up. E.g.:

    type MyAPI = "users" :> Get '[JSON] User
              :<|> "users" :> ReqBody '[JSON] User :> Post '[] ()

Can generally be rewritten as:

    type GetUser = Get '[JSON] User
    type PostUer = ReqBody '[JSON] User :> Post '[] ()
    type MyAPI = "user" :> (GetUser :<|> PostUser)

etc.

We came up with a way of reifying specifications of web APIs at the type level, and built a web framework around it. The basic idea was, I believe, first developed by Ralf Lämmel and Klaus Ostermann [0], as a Haskell solution to the expression problem, but I think it's the first large-scale application of these ideas.

Checking for correctness and deriving functionality from that comes pretty naturally after that, so it's easy to reduce boilerplate (e.g., generate client libraries and documentation automatically) and make static guarantees (e.g., that a link exists within an API, and won't 404).

[0] http://www.informatik.uni-marburg.de/~kos/papers/gpce06.pdf

Some more background https://lukepalmer.wordpress.com/2009/07/07/emphasizing-spec... .

I'd been thinking about just this recently. But to my mind, you don't even have to implement a build system - prolog can be directly used as one (modulo some library functions). You specify a goal, and a bunch of rules that have build-related side-effects, and then building a "target" is just a query. The syntax is even pretty similar to make, minus all the inexhaustible and unintuitive intricacies.

Two things that you'd get, that to the best of my (limited) knowledge aren't possible in make, is having cut, and the notion of both "and" and "or" - not only can you declare multiple dependencies and rules, but also "alternative" rules in case one does not succeed (e.g., in case you shell-out to a non-existent binary, try a different one).

Sorry, I should have added some context:

>Notice that RPN requires no parenthesis, unlike the polish notation of Lisps where the operator comes first, and RPN requires no precedence rules, unlike the infix notation used in most programming languages and in everyday arithmetic.

This seems wrong to me. It's the lack of variadic functions that is the relevant difference to lisp in terms of doing away with parens, not PN vs RPN.

Love the article, though

Huh? Why does Polish notation require parenthesis but Reverse Polish not? I thought the whole point of Polish notation was that it didn't require parens.

Unless your operators don't have a fixed arity, anyhow (Lisp's don't). But even then I don't see how RPN is in a better position...

The default keyword [0] would fix the extra-type-annotations issue, no?

[0] https://www.haskell.org/haskellwiki/Keywords#default

Agreed. I find it hilarious that a position (logical positivism, I mean) that is often criticized for failing it's own test of meaningfulness - because it lacks verification conditions - can also be criticized for being empirically false...