Ziad Hatahet hatahet

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.

Problems

Generic Interfaces

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

Comcast and Netflix now have a direct adjacency

Looked at the host serving my Netflix streams today and noticed something new.

No clue if money is changing hands or not, and the return path is what actually matters, but it appears that Comcast and Netflix have reached some sort of agreement regarding direct interconnection.

$ traceroute -a 198.45.63.164
traceroute to 198.45.63.164 (198.45.63.164), 64 hops max, 52 byte packets
    (hops 1-2 redacted)

Git Bisect and Feature Branches

There are people out there who claim that merge-based workflows (that is, workflows which contain non-fast-forward merges) are bad. They claim that git bisect gets confused by merge-based workflows, and instead advocate rebase-based workflows without explicit feature branches.

They're wrong.

Furthermore, the "advantages" of their workflows are in fact disadvantages. Let me show you.

EDIT! full code can be found here gist

So I played around with rust a bit now. And I thought I might share some random stuff.

So say you wanted to represent a expression tree with plus and minus nodes and a node for values. One way to do this would be to use rust's enum's.

In rust enums are like haskell's union types so you can specify the different values to be constructors carrying data.

	/bin/cat
	/bin/chmod
	/bin/cp
	/bin/date
	/bin/dd
	/bin/df
	/bin/expr
	/bin/hostname
	/bin/launchctl
	/bin/ln

	//C#
	public void Linq43()
	{
	List<Customer> customers = GetCustomerList();

	var customerOrderGroups =
	from c in customers
	select
	new
	{

	-Xmx10g
	m2.xlarge (4 virtual cores)

	Both Jetty and Netty execute the same code--generate 8k of random bits and compute a sha1, returning it over the wire.

	INTERNAL (Benchmark tool runs on same machine)
	--------

	Jetty:

	extern mod extra;

	use extra::json::*;

	/*
	* This function manages to do absolutely no copying, which is pretty cool.
	*
	* "What are all those `'r`s?" you ask. Well, they're liftime parameters. They
	* indicate how long something lasts (before it's freed). They can't change how
	* long something lives for, they only allow you to tell the compiler stuff it

	// Not sure whether it's faster than FindFirstFile, etc. - but it does it in one kernel call

	#include <windows.h>
	#include <stdio.h>

	// to compile:
	// cl fileinfo.c setargv.obj

	void fileinfo(const char*name);
	int main( int argc, const char* argv[] )