E2E2E: Meijer, Rys and Vick - Programming Data

Excellent!

Relational vs Knowledge Representation performance. Using the relational algebra to optimize queries over Knowledge Representation data

http://www.hpl.hp.com/techreports/2005/HPL-2005-170.pdf

JSon doesn't replace XML of course but what it does do is to loose many of the elements of XML that are not really that needed. For example, why do you need special syntax for comments, processing instructions (even attributes). Why not just use namespaced elements? So you could have <xml:comment xmlns:xml="...">My comment</xml:comment> and to only have one kind of attribute: the namespace qualifier. But that will also disappoint some people because attributes look better.

So XML mixes presentation style with semantic modelling and since attributes are limited compared to elements that is unfortunate.

The RDF/XML serialization model is quite nice in this respect because there a property can be serialized as both an attribute and and element and still mean the same thing (a property).

It's very interesting to hear about Microsoft's thoughts on this. Especially on a possible "one type-system to rule them all".

It'd be very interested to hear an E2E with the Microsoft Semantic Engine people as that is also a very interesting database and maching learning technology that appears to have great potential both in corporate, home and cloud environments.

Then of course there's XAML. So there is quite a lot of approaches to knowledge or information representation within Microsoft. I would imagine that M would XAML less relevant but then again.

I'm finding the discussion on type systems very interesting and insightful. Once I started to understand Haskell, I realized that many of my ideas about the trade-offs between static and dynamic type systems were misconceptions. As a result, I now find it frustrating...exasperating, really, when people claim dynamic type systems to have certain inherent advantages, which aren't advantages of dynamic types, per se, but rather disadvantages of the most well-known implementations of static typing (C++, Java, C#, etc.).

These thoughts lead me to wonder just what, exactly, *are* the inherent advantages of dynamic type systems. I think Michael Rys's distinction of pessimistic and optimistic systems is the insight I've been seeking. I wouldn't be surprised if this becomes the canonical distinction in the future.

Is that really a new distinction though. Either your program blows up at compile-time (source to MSIL) or "run-time compile-time" (MSIL to native); or not at all of course; there's always that slight chance of success; although we try to avoid it at all costs.

Is the optimistic system just the system that says that it's pessimistic to think your program wohn't run? heh

Gilad Bracha still believes strongly in dynamic typing it appears; well with optionally static typing. I suppose the reason is that although the most sophisticated type-systems are very expressive, they're never as expressive as the most expressive type-system: the one that doesn't repress any expression: dynamic typing.

Dependent typing looks like a new expression typing realm (potentially undecidable but...)

It's official: from now on it's not type-systems, it's expression repression systems

It seems to me like the advantage of dynamic type systems is that you don't have to deal with the disadvantages of static type systems, whether it be induced by the limitations of a type system (C++, C#, Java) or the limitations of one's understanding of a type system (Haskell).

There are disadvantages of dynamic type systems as anyone who has ever made a variable name typo can tell you.  In particular, I've always considered dynamic language designers who enforce case sensitivity in their variable names as especially cruel.

You're not going to be able to replace static type systems with dynamic ones in the mainstream commercial environment until you can at the very least match the productivity that IntelliSense delivers today. I spend upwards of 30% of my week at work doing code and technical reviews and anecdotally it appears the vast majority of developers quite literally "see" the solution to whatever problem they're working on in terms of what IntelliSense presents them with when they invoke it (type '.' etc). They almost never press F1, so you need contextually appropriate API / type discoverability.

Honestly speaking  when it comes to static / dynamic I think its neither one nor the other, it's both. I love PowerShell and really appreciate its malleability when it comes to working with foreign objects, on the other hand in a rigorous engineering context, like the core of a pricing engine, then I want as much strictness as possible - I explicitly do not want to accommodate accidental evolutions of APIs - I need to be able to reason in a formal way about what I'm building and static typing is a great help in this context. I want as much compile time "program verifiction" as  I can get, and then back that up with lots of unit testing. So static whenever possible and dynamic only when neccessary is my personal mantra.

Types are not just about ruling out invalid expressions, they also *add* information. The type of a variable can determine what piece of code to run in a given expression. This is type-based dispatch, as opposed to value based dispatch (vtables). 

Take a function like "read :: Read a => String ->a" in Haskell. It will parse any value of a type that's in the Read class. You don't nead a readInt, or readFloat etc., the type of the *result* of read is used to determine which specific parser to use. A dynamic language can't do that - it doesn't know the type of the result until after the function has executed, but it doesn't know which function to execute since it depends on the result type! 

That type is in turn determined from the context. This really starts shining when you compose it together, e.g. this function which reads a space separated list of values:

readSpaceSeparatedList :: (Read a) => String -> [a]

readSpaceSeparatedList xs = map read (words xs)

Now you can read a list of Ints, or Floats, or MyUserDefinedDataType using the same function. The specific expected type at the call site determines how the parsing happens. And indeed maybe the call site doesn't need to know what the specific type is:

sumSpaceSeparatedList :: (Num a, Read a) => String -> a

sumSpaceSeparatedList str = sum (readSpaceSeparatedList xs)

So again, we've written yet another layer of code and we *still* haven't had to decide exactly what parser to use to read the actual data from the string. We've only narrowed it down to something that's numeric (for the sum). Eventually something will force it to an Int or Float or something and then the compiler will figure out that it needs to use the Int or Float instance for Read.

Imagine how you'd write that in a dynamic language. You'd need a readInt, readFloat,etc, and similar for the two other functions. Or you'd need to wrap up the parser in an object and thread it through all the functions, but that's hideous (sort of like manual vtables to do OOP in C).

Anyway, this got longer than intended. The point is that a type system is not just about catching errors - types constitute extremely useful information that can actually be used by the compiler to make decisions, which can let you avoid writing ugly and boilerplate code.

Well yes, a common use of types to make decisions is optimization. I would say types form a triple of benefits: (i) correctness, (ii) abstraction, (iii) optimization; correctness because they help repress incorrect expressions; abstraction because they help hide and de/compose difference; optimization because knowing the  types of values lead to knowledge about the best machine representation, etc.

Oh, my. So many good discussion topics, so little time. I stopped counting after the first five. More E2E sessions would be nice.

I'd like to hear more about developments in the area of type systems, relational (im)purity,  and programming languages to replace SQL.

Cost based optimization and how things are evolving in that area would be interesting too.

On a side topic, calling SQL relational is a blasphemy. It's as relational as a cow is a noble steed.

You're the only one I know of who would put together such an awesome little "panel" of programming geniuses. I do aerospace software testing, so I naturally gravitate toward the programming side of things when I'm online. I'm just getting into PowerShell and am loving it so far. Great stuff!