
Alloy is a language for describing structures and a tool for exploring them - mooreds
https://github.com/AlloyTools/org.alloytools.alloy
======
infogulch
Last week Microsoft Research posted an interesting talk by Kevin Buzzard [1]
from Imperial College London about how he wants to formalize all mathematics
with theorem provers. He's currently using LEAN [2]. Half of the talk is a
discussion of the challenges he's faced convincing other mathematicians that
this is valuable, and the other half is about his success using LEAN as a tool
to teach undergraduates about formal proofs in general.

I think Alloy was mentioned at the end, but not really compared to LEAN.

[1]: [https://youtu.be/Dp-mQ3HxgDE](https://youtu.be/Dp-mQ3HxgDE)

[2]: [https://leanprover.github.io/](https://leanprover.github.io/)

~~~
dang
Discussed on HN the other day:
[https://news.ycombinator.com/item?id=21200721](https://news.ycombinator.com/item?id=21200721).

Also a month ago:
[https://news.ycombinator.com/item?id=20909404](https://news.ycombinator.com/item?id=20909404)

It's an excellent talk. I couldn't stop watching it.

------
hwayne
There was a fantastic talk at strangeloop this year on Alloy:
[https://www.youtube.com/watch?v=FvNRlE4E9QQ](https://www.youtube.com/watch?v=FvNRlE4E9QQ).
The speaker used it to find a serious security bug in their live code and a
feature interaction bug in their UI that had meant they had been writing
broken code for the past _year_.

(full disclosure I'm referenced towards the end)

~~~
timClicks
I watched that earlier this week, and have been making my way through the
Software Abstractions book by Jackson. Alloy's still in the "this thing makes
me feel stupid" territory, but it does feel learn-able to me. I really like
the emphasis on iterative development.

~~~
RBerenguel
I found Jackson’s book excellent, one of the most readable books with the
depth the book had.

------
orthecreedence
Forgive my ignorance, but after looking at the Github readme I'm not really
understanding what this _does_. What kinds of things would Alloy be used for?

~~~
sgk284
Here’s a good intro from strangeloop:
[https://www.youtube.com/watch?v=FvNRlE4E9QQ](https://www.youtube.com/watch?v=FvNRlE4E9QQ)

~~~
orthecreedence
Thanks, this is really helpful.

------
dapids
In what way is this alloy different than the official/original alloy? This the
official alloy now? There is literally no mention or prior credit on your site
to the original? A lot of unanswered things here.

[http://alloy.lcs.mit.edu/](http://alloy.lcs.mit.edu/)

~~~
wyldfire
I've been wondering about this for a while. This one shows up ranked fairly
highly on Google searches for alloy. I was very confused but I suspect it's an
identically or confusingly named fork. But when I first discovered it, I spent
a while assuming that development had just migrated to GitHub.

Has the original alloy gone unmaintained?

~~~
dapids
In any case if it has, in my personal opinion it's quite shady to fork a
project and remove all reference to the pre-fork, except the cover of the
book, which is just a picture and not even a link to the original MIT site.

------
snappergrass
[https://mitpress.mit.edu/books/software-abstractions-
revised...](https://mitpress.mit.edu/books/software-abstractions-revised-
edition)

------
naringas
how does this relate to tools like TLA+? coq?

~~~
hwayne
Re TLA+, I'll copying my response from the last time Alloy was linked here:

\---

Alloy comes from the Z line of “systems are basically giant relational algebra
problems”, while TLA+ comes from the LTL line of “systems are basically giant
temporal logic problems”, which leads to a lot of fundamental differences
between them. They also had different design philosophies: Jackson wanted a
language that was easy to build tooling for, Lamport wanted a language that
was easy to express complex logic in.

One consequence of this is that Alloy is a much smaller language: you can fit
the entire syntax on a single sheet. It's also much easier in TLA+ to write a
spec that you can't model-check, while with Alloy you have to be actively
trying. It’s also impossible to write an unbound model in Alloy, so you’re
guaranteed that every spec is over a finite state space. Which gets rid of the
common TLA+ runtime problem of “is this taking a long time because it’s a big
state space or because it’s an infinite state space".

Re tooling: Alloy converts to SAT, which makes model checking much, much
faster. Specs that would take minutes to check in TLA+ take less than a second
in Alloy. Being able to model-find as well as model-check is really nice, as
is the ability to generate multiple counter/examples. The visualizer is really
useful, too, especially for showing counterexamples to nontech folk. But the
thing I honestly miss most when working in TLA+ is the REPL. It’s not the best
REPL, but it’s a hell of a lot better than no REPL.

Okay, so drawbacks: Alloy doesn’t have an inbuilt notion of time. You have to
add it in as a sequence sig. This means you can’t study liveness properties or
deadlocks or anything like that. It also makes simulating concurrency awkward.
This isn’t a huge problem if you have simple interactions or only one
structure that’s changing, but the more “timelike” the problem gets, the worse
Alloy becomes at handling it.

Less fundamental but still a big problem I keep having: no good iteration or
recursion. Transitive closure is pretty nice but it’s not powerful enough. For
example:

    
    
        sig node {edge: set Node}
    

Is N1 connected to N2? Easy, just do `N1 in N2^.edge`. Through which nodes
does N1 connect to N2? That's much harder.

The biggest problem with Alloy adoption, though, is social: there’s no
comprehensive online documentation. If you want to learn it you have to buy
_Software Abstractions_. Fantastic book but not something that’s especially
convenient, and it doesn't cover newer features. We're working on changing
this, but it will be a while before we have comprehensive online documentation
available.

Which one is more appropriate to use really depends on your problem. As a
very, very, VERY rough rule of thumb: TLA+ is best you're most interested in
the dynamics of a system: the algorithms, the concurrency, etc. Alloy is best
when you're most interested in the statics of a system: the requirements, the
data relationships, the ontology, etc. My standard demos for showcasing TLA+
are concurrent transfers and trading platforms, while my standard demos for
Alloy are access policies and itemized billing. You can use each in the
other's niche, too (see Zave's work on Chord), so it's not a stark division.

\---

(Since writing that post, we're a few steps closer to having online
documentation, and in the next couple of weeks or so I'll be running some
first drafts past the rest of the team.)

Coq, by contrast, is a full theorem prover. I'm not experienced with it, but
from my understanding it's mostly used in programming to prove things at a low
level, where you're directly synthesizing code. Alloy is much higher level,
relying on you to do the translations to code yourself. The upside is you
don't need to know how to write mathematical proofs to use it, you just hit
the "check model" button and it takes care of all of that for you.

If you want to see an example of Alloy in practice, I recently wrote a
tutorial on using it to formally verify that your database migrations are
safe: [https://www.hillelwayne.com/post/formally-modeling-
migration...](https://www.hillelwayne.com/post/formally-modeling-migrations/)

~~~
lol768
My undergraduate degree in CS covered Alloy, it was good fun to learn and
solve problems with but I have to agree that the biggest pain point was
definitely the limited documentation (even _with_ access to the university's
own resources). It's great to see improvements are on the horizon in this
area!

Edit: one of the other things I disliked about it was the GUI (it's Swing,
IIRC). [http://alloytools.org/workshop/slides/cunha-
alloy.pdf](http://alloytools.org/workshop/slides/cunha-alloy.pdf) looks pretty
cool and should probably be the future interface for the tool.

~~~
hwayne
If you happen to remember some of the pain points, please let me know! I keep
a list of the common pitfalls that I need to address in the docs.

