Ivano Pagano ivanopagano

From section 9 of John Backus's 1977 Turing Award lecture Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs:

Denotational semantics and its foundations provide an extremely helpful mathematical understanding of the domain and function spaces implicit in programs. When applied to an applicative language (...), its foundations provide powerful tools for describing the language and for proving properties of programs. When applied to a von Neumann language, on the other hand, it provides a precise semantic description and is helpful in identifying trouble spots in the language. But the complexity of the language is mirrored in the complexity of the description, which is a bewildering collection of productions, domains, functions, and equations that is only slightly more helpful in proving facts about programs than the reference manual of the language, since it is less ambiguous.

...

Thus

Specification

Out Of The Tarpit

BOOM Analytics: Exploring Data-Centric, Declarative Programming for the Cloud

Dedalus: Datalog in Time and Space

Logic and Lattices for Distributed Programming

Internet Scale Services Checklist

A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."

http://mvdirona.com/jrh/talksandpapers/jamesrh_lisa.pdf

Basic tenets

Does the design expect failures to happen regularly and handle them gracefully?
Have we kept things as simple as possible?

##Scala eXchange 2014 slides

collected by Adam Warski

Feel free to complete the list!

The Binary Compatibility Challenge by Martin Odersky

A Skeptic's Look at scalaz' "Gateway Drugs”: A Practical Exploration by Brendand McAdams

Introduction to scalaz-stream

Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.

The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca

Collections Redesign Proposal

I'm going to start off by motivating what I'm doing here. And I want to be clear that I'm not "dissing" the existing collections implementation or anything as unproductively negative as that. It was a really good experiment, it was a huge step forward given what we knew back in 2.8, but now it's time to learn from that experiment and do better. This proposal uses what I believe are the lessons we can learn about what worked, what didn't work, and what is and isn't important about collections in Scala.

This is going to start out sounding really negative and pervasively dismissive, but bear with me! There's a point to all my ranting. I want to be really clear about my motivations for the proposal being the way that it is.

	package org.iainhull.akka


	import scala.concurrent.duration._

	import akka.actor._
	import akka.event.Logging
	import akka.pattern.ask
	import akka.util.Timeout
	import akka.persistence.{PersistentView, AtLeastOnceDelivery, PersistentActor}

	import scala.language.experimental.macros
	import scala.reflect.macros.whitebox

	class FreeMacros(val c: whitebox.Context) {
	import c.universe._

	def smartName(name: String): String = (
	name.toList match {
	case h :: t => h.toLower :: t
	case Nil => Nil

	import scalaz._, Scalaz._

	// Adjunction between `F` and `G` means there is an
	// isomorphism between `A => G[B]` and `F[A] => B`.
	trait Adjunction[F[_],G[_]] {
	def leftAdjunct[A, B](a: A)(f: F[A] => B): G[B]
	def rightAdjunct[A, B](a: F[A])(f: A => G[B]): B
	}

	// Adjunction between free and forgetful functor.

	// let's imagine you have an algebra that has a constructor like the following
	sealed trait Algebra[A]
	case class Ext[E, A](e: E, f: E => A) extends Algebra[A]

	/*
	* Not at all an uncommon pattern! Basically, this is going to show up any time you're
	* doing GADTs or GADT-like things, or any sort of type-aligned sequence (in any form).
	* The problem is that the pattern matcher affixes types in a linear fashion, and thus
	* will not unify the solution to E between the two parameters. For example:
	*/