Lambda the Ultimate

So... how big can dynamically-typed systems get? Do static type systems really matter? I'd love to know the answer to this.

We have some big systems at Amazon, and most of them seem to use strong static typing; at least the ones I know about do. Is that a requirement, or could we just as well have done them in Perl, Ruby, Lisp, Smalltalk?

Read more about it here.

U is a small (< 1000 words) computational model:

http://urbit.sf.net/u.txt

U is different because it:

• has no user-defined functions or lambda
• has a built-in hyper-Turing operator
• expects an unreliable packet network

I have to apologize for posting this weird beast with no real context. I'm working on higher layers that should make its purpose clearer, but they are not done, and we all hate hand-waving. Still, the U spec is self-contained, and it should be precise and readable. If anyone can look at it and maybe even find some gotchas, I'd be super grateful.

I'm especially curious about the follow operator. Are there any logical flaws in its definition, or ways it could be improved, generalized or tightened?

Also, if anyone knows of any other UDP-level functional languages, or anything else U reminds them of, I would of course be happy to hear it.


Thanks,
Curtis
(curtis dot yarvin, at gmail)

The Naked Objects Approach is not a sleazy way to make a quick buck, but a framework for writing business applications that does away with the usual Model-View-Controller architecture. To quote the website:

In the naked objects approach ... writing a business application implies writing only the business domain objects themselves. All business functionality is implemented as behaviours or methods on those objects - the objects can be described as being 'behaviourally complete'. These business objects are then presented directly and automatically to the user, by means of a completely generic viewing mechanism. Similarly, the persistence layer can be generated completely automatically from the domain object definitions (manual mapping will still be required if the objects must interface with existing databases).

Sounds like polytypic programming to me! Ruby on Rails has something similar with scaffolding, and the Django framework in Python does the same.

It's nice to see application of theory, though I'm virtually certain those doing the applying wouldn't recognise it as such.

The ACM has named 34 new Fellows for 2005, one of whom is Robert Harper, "for contributions to type systems for programming languages." This recognition is certainly well deserved, and Harper's work has been discussed here many times.

Here is the official ACM press release.

My Google Alert on Haskell tortured me with weeks of unrelated news about folks called Haskell, sports results from a college of the same name and local incidents from a town of the same name. Finally today I got a on-topic hit. Allow me to share it with you, it is here.

PS Is this is the proper way to submit some interesting link?

While studying OO at university, it was drilled into me that I should "package data with the methods that operate on that data".

In recent years I have come to wonder why so much emphasis is placed on this concept.

For example, most 3D Vector classes I have encountered look something like:

class 3DVector
{
private float X;
private float Y;
private float Z;

public 3DVector Normalize();
public 3DVector Add (3DVector other);
public float Dot (3DVector other);
... etc
}

This appears well organised.. Various methods that act on a 3D vector nicely packaged up together. I'm guessing most OO programmers would generally approach class design in this way.

But at the same time, its very hard for multiple vendors to add their own functionality to the class, they are forced to collaborate and merge their methods into the "current version".

In this instance, would it not be more sensible to have something like:

class 3DVector // Agreed, Never going to change
{
public float X;
public float Y;
public float Z;
}

---- Vendor (1)

3DVector Vendor1_3DVector_Normalize (3DVector v)
3DVector Vendor1_3DVector_Add (3DVector a, 3DVector b)
float Vendor1_3DVector_Dot (3DVector a, 3DVector b)

---- Vendor (2)

3DVector Vendor2_3DVector_Cross (3DVector a, 3DVector b)
float Vendor2_3DVector_Length (3DVector v)
3DVector Vendor2_3DVector_Dot (3DVector a, 3DVector b)

Then as a vendor, you are able to release new functions as and when you please.

As an application developer, you are free to pick and choose those functions that fit your requirements, or add your own.

The vendors would have to collaborate on the initial "Data Format" of a class, but once settled, an eco-system of functions would build up that operate on it.

I realise this is a simplistic example, and can see it would be hard to extend the idea to more complex objects with state. But I was curious whether there are any real-world OO systems that leverage this sort of thing, and how far they take it?