Lambda the Ultimate - Comments

Relational Mashup

Ben L. Titzer — Fri, 24 May 2013 03:47:01 -0400

I think LINQ is a cool idea, but it always bothered me that to make the implementation sufficiently extensible and flexible enough to support SQL backends, expression trees were necessary. This adds a whole meta-language to the language that wasn't there before. Perhaps C# would have been cleaner if it did have a meta-language from the beginning, but bolting one on the side always seems like a bit of a hack. From what I understand of the common backends for LINQ, I don't think they they make that much use of the expression trees in any case, so it seems like a lot of complexity pushing in the wrong direction. Relational and mainstream languages are headed for a collision in the coming years. Too much real-world work deals with reading, writing, querying, copying, and otherwise tending to persistent data stores. If the right concurrency models can be made to fit, and the right consistency dimensions carefully added to the language, it will make a huge difference in productivity for the average programmer stuck with some SQL or NoSQL datastore that they are currently clumsily hacking on in the language du jour. This is coming from my experience working with object/relational mappings in Java with both a SQL db and a No-SQLish db.

"And of course, for live

Robbert van Dalen — Fri, 24 May 2013 02:28:45 -0400

"And of course, for live programming, reversing is quite impossible since the code can change randomly.". Unless you treat code as data and track their dependencies, just as with data.

People are way too enamored

naasking — Fri, 24 May 2013 00:17:07 -0400

People are way too enamored with LINQ [...] C# designers did not think of that, and as a result we have an ugly DSL.

It depends what you mean by LINQ. It's a fairly overloaded term now, but the IEnumerable LINQ extensions are quite good. The integration of quasi-quotation in the form of LINQ expressions are also nice. The query syntax was unnecessary, although I'll admit it's been convenient to have in a few cases. Complex grouping queries are much simpler to read in the flat query syntax than in the method-chained syntax. Certainly C# has annoying corner cases even in LINQ, but I don't think you can deny that it's miles better than what's available in other major C tradition languages. As for how Nemerle compares against Virgil, certainly Nemerle is more featureful, but it's not easy to see what the core Nemerle language really is due to the macro magic. Virgil's language is relatively simple and expressive given the description in this paper. In perusing Nemerle's standard library, it doesn't even look like polymorphic Nemerle classes compile to generic CLR classes, ie. all collections under Nemerle.Collections accept and return System.Object. That's certainly not what I'd expect a serious CLR language to generate.

Consider how much simpler writing LINQ could be

Z-Bo — Thu, 23 May 2013 23:55:22 -0400

People are way too enamored with LINQ, but people have to do all kinds of stuff to actually get any "call by intention" to work correctly. For example, Linqkit and calling AsExpandable() and Invoke() and Expand(). A proper DSL crafted solely for the context of SQL Generation would hide these abstractions for the user. C# designers did not think of that, and as a result we have an ugly DSL. Anybody who tells you LINQ is nice is an idiot who is wow'ed by a simple demo. Nemerle is better than Virgil, although F# with full code quotations is much nicer even yet, because it hides all the plumbing Nemerle exposes as macros. Also, not sure when they introduced macros, but Nemerle had macros and fairly expressive generics in 2008. To your point about casting values, I am surprised you did not mention infoof, the property equivalent to typeof. In either event, infoof is trivial in Nemerle, it's simply a macro. The other, broader issue, is that MSIL was never designed for these sorts of embedded languages, that's why we even have expression trees in the first place, because there is no duality between the language we program and and the byte code we execute, so we need to manually quote our code. F# manages to hide a remarkable amount of this mess, but they do so by creating a peer API Expr and map Expr to Expression Trees, so that they can get the advantage of expressing ASTs as discriminated unions. But, of course, F# could be better here, since it doesn't have an elegant solution for the expression problem. At the same time, MSIL gets further hacked up. Rather than genuinely supporting infoof, we get hacks like CallerMemberName. Who thinks up dumb stuff like that? Same people who thought the DLR was elegant, I assume. Meanwhile, .NET framework guys do everything they can to avoid putting in runtime features to improve the experience for F# users, such as CallerMemberName rather than improving the allocator for functional languages.

That might have been true of

naasking — Thu, 23 May 2013 23:42:00 -0400

That might have been true of early Nemerle when they still primarily used the C syntax and before they introduced the powerful macro facilities, but it's grown into too radical a change from the existing C/Java tradition. Been awhile since I looked at it too closely though. Perhaps it's time for another look!

In incremental computation,

Sean McDirmid — Thu, 23 May 2013 22:45:33 -0400

In incremental computation, such as self-adjusting computation, change propagation usually relies on reversibility to navigate to affected parts of the computation. Perhaps this is similar to what happens in Spread.

I have never relied on reversibility in any of the incremental programming systems I've built; I just found it much harder to "undo" than to "redo" (aka damage, repair). Most of the reactive programming languages I've looked at are similar, but then the self-adjusting computation work has never been vigorously compared to FRP work. And of course, for live programming, reversing is quite impossible since the code can change randomly.

Yet another application is updateable views, such as database views and GUIs. Witness the growing body of work on lenses, bidirectional transformations, etc.

True, I just read something this week to that affect. Lenses haven't gone very far yet in practice, but the field is fascinating.

Consider a distributed setting, and suppose the subsystem of interest is an external computation which we lack the means or authority to re-execute in a debugger, or run with tracing enabled. Then there are simply no prospects for debugging or otherwise dynamically analysing that subsystem all, unless we suppose that it somehow maintains its computational history.

We have a whole group in my team who focus on logging in distribute systems. Much of the time travel work comes out of the systems community, not the PL community, for this very reason (not to mention checkpointing etc...).

Modularity

Sean McDirmid — Thu, 23 May 2013 22:35:15 -0400

Let's put it this way: how much about a procedure can you forget after the call so that it can be "uncalled"? The more junk you keep around after the call, the more burdened the procedure caller with forgetting or propagating the junk. Its a fascinating problem, and from what I can tell in this post, it might be proven to be unsolvable in general (junk just accumulates necessarily for most interesting procedures). Janus avoids the issue by not having any encapsulated variables (all variables are arguments or globals).

Nemerle

Z-Bo — Thu, 23 May 2013 21:18:35 -0400

I always thought Nemerle was what C# should have been. Not too mention the quality of engineering of the Nemerle compiler meets or exceeds that of any other Microsoft compiler; they found tons of bugs in MSIL and .NET's CLR generics implementation. This is likely due to the fact that Nemerle is actually a very small core, and much of the language functionality is actually done in macros as part of the standard library. For example, C# added async/await as language features, whereas Nemerle simply wrote some macros.

No, too much syntactic

naasking — Thu, 23 May 2013 19:00:48 -0400

No, too much syntactic departure from the C tradition. C# was supposed to be a better Java. It is in many respects, but Virgil is better than both.

not F#

raould — Thu, 23 May 2013 17:58:45 -0400

so F# isn't what C# shoulda been? :-(

all will be explained in the movie

raould — Thu, 23 May 2013 17:57:16 -0400

you know. the google movie. (gag me with a spoon.)

Thanks for the comments.

Hank Thediek — Thu, 23 May 2013 17:33:37 -0400

Thanks for the comments. One thing I can clear up is that the paper was published in International Journal of Computing Anticipatory Systems. back in 2002. I don't recall any reason why Hilgarten singles out WIE languages. I think it may be that he doesn't know oriental langage, and wants to leave them out. Otherwise I think the paper speaks for itself.

Provenance, slicing, incremental computation, views, ...

Roly Perera — Thu, 23 May 2013 16:54:05 -0400

Indeed, provenance is a key application of reversible computation. (There's no need to distinguish trace-based approaches from other reversible computational models.) Dynamic program slicing is another application, although perhaps related to provenance. In incremental computation, such as self-adjusting computation, change propagation usually relies on reversibility to navigate to affected parts of the computation. Perhaps this is similar to what happens in Spread. Yet another application is updateable views, such as database views and GUIs. Witness the growing body of work on lenses, bidirectional transformations, etc. I find the more you think about it, the more implausible the idea of *irreversible* computation starts to sound. Consider a distributed setting, and suppose the subsystem of interest is an external computation which we lack the means or authority to re-execute in a debugger, or run with tracing enabled. Then there are simply no prospects for debugging or otherwise dynamically analysing that subsystem all, unless we suppose that it somehow maintains its computational history.

Data provenance and reversibility

Robbert van Dalen — Thu, 23 May 2013 16:15:08 -0400

I didn't care to elaborate on data provenance exactly because it is a well-defined term. But yes, I guess my post was all over the place. Anyway, I've seen software written by scientists, used to conduct experiments. And yes, they were generally not of good quality. But I argue that they *must* be of good quality, otherwise how would one trust the scientific outcome? To be honest, I've never seen any collider software. But I do know that they deal with huge huge amounts of distributed data. My gut feeling says that reversible computations (where possible) might be an efficient way to provide data provenance on such datasets (instead of using traces). It is not just in the scientific domain where data provenance is needed. For instance, in the bank domain (where I work) it is getting more and more important. For some background information, see: A Survey of Data Provenance Techniques. I believe reversibility is one of the key properties to achieve data provenance in practice. I'm developing a programming language that has (scaleable) first-class reversibility (next to being retroactive).

Endorphins not logic

marco — Thu, 23 May 2013 15:15:59 -0400

Here I am at home thinking language is there to release endorphins in primate brains, both in the utterer's as the recipient's of the utterance brain. Seems to me logic has little to do with language in normal life.