An email to Kyle Neath on IP and Capital

Reading That's My Property on Kyle's Warpspire blog, I saw some parallels with recent ponderings on capital versus cash flow.

---

Kyle,

Firstly, props for the blog, quite inspiring to see someone out there and getting on with things. Maybe I just like it because you're on my level. (I read your blog because you remind me of me - what a sentiment.)

Just been reading your thoughts on IP, and thought I'd draw some parallels with capital investment. I've been reading and thinking about capital, interest rates and salary, and it seems that the best thing is to try to turn a chunk of capital into an income, in a better way than just spending it in small chunks (mirroring your point on VC-hunting startups these days).

Suppose I have an idea. Not just any idea, but one of those 'this could change *everything* [for people like me trying to do what I'm trying to do right now]' ideas. The ones people get really precious about and fail to make use of for fear of exploitation. To me, that's like a chunk of money. Now, you can either use it as capital, and try to wring future returns out of it by renting it to other people (licensing), for which you need lawyers, or you can build your own company on it. Either way, it was only ever one idea, one chunk of money. It is limited in how much it can change the world, or get you early retirement.

Capital is limited. Much better is a flow of income. Saving £200 a month is better than investing £20,000, after four or five years. In a similar way, I treat ideas like a flow, not capital. I have some great ideas I'm wild about, but if I haven't done anything with them myself after a while, I will give them away. More ideas will come, formed and shaped by the experiences I have.

Ideas are always over-valued. Google was founded on one idea, sure, but they built on that initial investment with many, many others, and a lot of hard work.

I'm hoping to build a portfolio of the ideas I have, not to boast or to sell, but to convince someone, someday, that these things do not stop falling out of my head, and that it's worth paying me for a time so that I focus on *their* problems. Until then, I'm working on refining the filters, stimuli and breadth of search space available to my imagination so that what does fall out of it always improves in quality and usefulness.

I am, however, always wrong to some degree. Where am I wrong here?

Phil

Duck-typing vs static with interfaces

Reading Jason Baker's thoughts on the issue, here is my response:

Personally, I've been pondering duck typing vs interfaces for a while. It seems that the choice is between a catch-all (duck typing) and a square hole (interfaces). Interfaces are great for static languages, but are more restrictive at design time than going for duck typing. At the same time, duck typing means that an increasing number of tests are needed to make sure the system copes with different usage.

But what if we restrict ourselves to web services? A datastream (MIME, xml, etc) is passed in, and the service provider has an SLA contract for expecting it to 'work'. But since we're dealing with externally supplied input, we do all our input-checking at the start, to make sure it's all sanitised. After that, we have effectively already done the checking we need (if we've done it well).

Now, do you take the static+interface approach, because you already know what the input is like, or do you take the duck-typing approach, because we've already sanitised the input, and have our TDD tests aligned with our input sanitisation?

My answer would be to go with duck-typing here. If we've defined our SLA well, we have excluded non-compliant input data, which will be turned down at the point of reception into the system. Thus we can dispense with the overheads of interfaces, since we can (Atwood style) throw hardware at the interpreted language speed issue.

Catch them in the URL net.

In The Problem With URLs, Codinghorror ponders how to regex his way to catching URLs mixed in with user's text.

The whole discussion becomes about either how to write a better rule or regex, or whether to force users to delimit their URLs properly (with angle brackets, square brackets, bbcode tags...)

But this is foolish. 

Parsing text for things like URLs is a similar problem to trying to detect spam - the inputs are as varied as people can imagine them. So stop trying to deal with it using a series of fixed and universal laws!

Suggested algorithm:

1. Get the feasible string: from the beginning of what you think might be a URL to the first space (or illegal character), allowing for i18n - you can use your regex here - and a list of any open parenthetics in the paragraph ( (,[,< etc).


2. Generate a series of the possible URLs from it, by dropping each of the characters from the end that could be wrong:
   " Give me a URL (like http://www.example.com/querya?b)(ideally)? " becomes:
   
   
   
   1. "http://www.example.com/querya?b)(ideally)?"
   
   
   2. "http://www.example.com/querya?b)(ideally)"
   
   
   3. "http://www.example.com/querya?b)"
   
   
   4. "http://www.example.com/querya?b"
   
   
   5. "http://www.example.com/querya"
   
   
   
   and any other variations you find useful.


3. Assign each one a rating based on:
   
   • whether there are unbalanced parentheses inside
   
   
   • whether the parenthesis would balance open ones in the paragraph - in this example the open bracket would be balanced by this close bracket, so that lowers the scores for a. and b.
   
   
   • whether the URL is sensible - "blah.com/)" is less sensible than "blah.com/"
   
   
   • any other good/bad valuation you can think of
   
   


4. Rank the options


5. If the top two (or more) options are very close or equal in ranking, then test for the existence of each by just polling the URLs in ranked order until you find a real one. If you adjust the threshold of how close is close, you should only be testing in rare cases. If you don't like polling, just pick one, you can't out-unwit every idiot or mistake.


6. Finally, return the selected URL

There are endless ways to improve it beyond even that - you could even try balancing the parentheses such that your wikipedia article has its missing bracket fixed. At some point, perhaps, it becomes a bit pointless, but if this is all in a library and isn't too slow, nobody need rewrite it again, and the users are happy.

For me, the power of the method is in using ranking to allow unlikely options - unless you can separate all the possible inputs on a Venn diagram (which you can't here), then some rules will work for some sets of inputs, and others for others, and you'll never find a complete set that works for all of them.

In short, regexes only work for uniform and predictable input on their own

Other fun games:

• consider trying to find wrongly-typed URLs and correcting them for the user


• providing suggestions on 'better' URLs (did you mean .com instead of .vom?)


• suggesting (and automating) the use of tinyurl or other URL compacting services for long or multiple-line-spanning URLs

Droplet or sign of a coming flood?

Interface-defined variables (or A quick idea on hybrid or diluted type systems 2)

Having expounded a vague hope in A quick idea on hybrid or diluted type systems, I came to realise that what I was really doing was defining a series of interfaces.

We can already define objects via interfaces:

ISomeInterface MyProperty = new ClassImplementingISomeInterface();

What if we limited ourselves to only defining any method or property with interfaces? Thus I would have a class MyClass, with properties IStringable NameString, IEnumerable<inumber> NumList, etc. That way the class would be maximally flexible, as we would be making the properties make only the minimum requirements of the inputs. Of course, if I pass an object that implements an interface derived from that required, it can still be cast into the minimum required interface.

Excellent, a dynamic and gregarious acceptance of many different static types - some of the innate strengths of dynamic languages in a statically-typed one.

Web Services

Let us step back from a moment and consider how this would help in the world of web services. A web service needs to be forgiving in what it will accept, and strict in its output, if it is to be used by the maximum set of other web services. If we assume that the input and output are various flavours of xml, then the static type is equivalent to the exact DTD of an xml doc, and the set of interfaces is, well, unknown.

In looking at REST interfaces, I came across a discussion of how to handle the inevitable change of interface versions when providing a RESTful API. Kalsey decides, in the end, to provide a version tag in the xml output file, containing pointers to the current, previous and latest API versions, with date-based URLs to provide access to specific versions of the API interface.

If, instead, we consider a request on a REST URI as a request for certain data conforming to a certain interface, then we can skip versioning. We define, instead, a series of smaller interfaces, and allow the user to request any subset of them. Thus my request xml should supply input data in an xml form that can be cast into any of the simpler interfaces, given an xml-generated object.

Stack Overflow Collab

Stack Overflow is new hub for the exchange of coding knowledge, built to leverage the innate tendencies of coding types to want to be right, to want to solve problems, and to gain kudos. So it has attracted many coders in search of recognition, and shows the important trait that its backers (Jeff Atwood, Joel Spolsky etc) are willing to follow the curve of user feedback. Thus SO is a community responsing to individual problems.

The Open Source movement, by contrast, has built up from existing partnerships (largely from the Real World) forming relaxed coding collaborations. The larger projects have then acquired others from across the net who were interested and got involved. The key here is that OSS is a community responding to a collective demand.

So how about filling in that great Venn overlap of community drawn by solutions to individual problems, and the productivity of a community solving a larger problem together? In other words, SO, give us a collaboration hub. Surely it's the ideal place for the inexperienced to participate at the fringes of an OSS project, and for experienced coders to progress up the kudos chain by contributing work and experience to a project, rather than a single point of expertise.

The system, interface, ranking, discovery and how it all overlaps with the overflowing stack of questions and answers on SO are subsidiary issues. But since people's individual project gave rise to problems, which gave rise to the need for SO, let the circle complete, and the solvers coagulate and combine to produce new projects.

I came, I saw, I solved, I wondered about the project, I got involved, we collaborated, we solved, we progressed, we share the story, we conquer.

Missing the value of information

This begins as critique, but I'm sure ideas will surface.

Mike of Mike On Ads has written a javascript example to mine the user's browser history for top sites, and use statistics to work out their gender. In the comments, many many people have posted their scores and whether the score was correct. Some are right, some are wrong.

But there are two complications here. Firstly, a complication of the quality of the data - many PCs have multiple users, particularly in family homes, which will render their scores useless. Also, no frequency data is included - a hundred visits to espn.com will be cancelled out by a single salon.com.

The second, and more interesting, point is this: why do you want their info? For any normal commercial reason - in particular serving ads or choosing content - what is interesting is not the true gender of the viewer; it is their statistical gender. If someone arrives at your sport&sewing site, should you pitch it as a sport site or a sewing site based on their gender, or the ratio of crochet sites to
live sport news sites? You might think you want their gender, but what you really want is correlation.

Ideas:
I should mention that I wouldn't endorse the practise, and that soon enough it should be prevented by, I suggest, returning the default link colours rather
than the live colours for anything but links from the parent domain - i.e. strengthen the XSS protection.

Even without this kind of temporary naughtiness, you can still find out about your general user base - watch what links they click, videos they watch, news items they find interesting. And build useful statistics - perhaps your site is visited by three fairly separate groups, which might determine your site development strategy. This time, you have frequency data, timing data, everything.

But remember not to be evil.

A quick idea on hybrid or diluted type systems

One of the main uses of object-orientation in programming is to collect things and encapsulate them. Thus, I can pick up any MyBendableObj made out of the BendableObj class which implements the Bendable interface and know that I can do MyBendableObj.bend(). This reflects how we tend to think as humans - I have a piece of paper, I can fold it. I don't really care if it's 80gsm or 85gsm, unless I'm trying to fold it more than a few times.

A large rift between camps of programming languages (or rather, between their developers) is between statically typed languages like C++ and dynamically typed languages like Python. There are some nice midway-points - you can use Rhino to do Javascript (dynamic) on top of a Java (static) VM, for example.

The old argument goes that static means fast, because the compiler knows what memory requirements are going to be needed, and dynamic means easy to code because you can change your mind about what a variable will hold. In PHP, $data can be a value one minute and an array of mixed objects the next. In Fortran, once declared an integer, always an integer.

But I suspect there is a hybrid possible. For the most part, my choice of type for a variable conveys information to the compiler for its compile-time work. It's a promise not to try to change the variable's type. But there are other ways to do that.

Suppose I take an otherwise dynamically typed language and add a language extension that allows loose declaration of type; I declare it to be a single variable, an object, a collection of objects, etc. Nobody really puts completely different things in $data, unless they're writing appallingly bad code.

So let me do this:
singlevar val = new String();
mixedarray outputCollection = array(i, 4.235, myObj);
singleobj house = new House();

Thus we give the compiler information it can use. I promise not to do too much funny stuff. But it means

• Flexibility: my IOobject can be a file, a socket or a commandline pipe with the flexibility of a dynamic language (singleobj myIOobj = getIOObjectFromHandle(thisHandle)).
• Compile errors: I can catch myself doing mySingleObj = objectArrayGenerator(); and fix it.
• Speed: My compiler is (presumably) doing much the same optimisation for all my fixed-length types, allocating my object handles on the heap, etc etc. And it can do that here, too. Variable length strings are tricky, I'll grant you, but leave them as objects.
• JIT compilation: hopefully the extra information can aid the JIT compiler
• Not annoying the coder: dynamic languages are great. You do what you mean to do, and you don't worry about what's coming back. Except that you do, for the most part, know what's coming back. Even if it's a function coming back and you're about to do a functional filter lambda thing with it, that's a good start.
• Confine implicit conversions to a single type strata: float to integer, integer to char array, these are easy. MyMixedObjectCollection to boolean? It's not even meaningful.

Stepping away from all the theory and the lemmas and the other stuff I haven't much clue about (which is probably why I'm somehow wrong), it feels natural to same something about what this variable will hold, without having to nail down exactly what. I have a CD case that can hold a CD. Or I might put a DVD in it. Or a bluray disc. In the dynamic world I don't care, I could put an elephant, two monkeys and a mathematical axiom in there. In the static world the DVD wouldn't cut it.

Templates should get a lot easier with these type strata - a vector of ints, floats, bools, all make some sense.

Perhaps this would lead the way to per-object overloading: destroy all these books but coat that one in paraffin - we understand exceptions to rules in the everyday world. Why not let us overload the destroy() method in this one, then pass the whole collection to be systematicallyDestroy()ed?

There is much for me to learn about functional programming, typing, OO and design patterns, so I'm not well placed to see whether this would all work. But in my mind, it spun a fine drop.