Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

PL designer here with extensive experience writing compilers in C#, Java, and Scala. Pattern matching is nice but OO will get you most of the way and filling the matching gap is simple.

The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching. There are so many OO solutions to this problem it's not funny; I think I had a small argument with Wadler over this back in 2001 or 2.

As for persistent collection types, observable collections with undoable operations are just as good, if not better because they can still support mutability while persistent collections cannot.

View on HN

I've written compilers in C, C++, C#, Delphi, Java, ML and Lisp; targeting x86, x64, JVM and MSIL. I was maintainer of the Delphi front end at Borland / Embarcadero. Pattern matching isn't just nice; you end up with substantially better typechecking, and doesn't need ugly patterns like visitors with their inverted callback control flow, if you want to decouple e.g. type checking or code generation from your AST classes. Visitors are implicitly closed to extension unless you create very abstract visitors (and I've gone down that path, it's not pleasant) - you lose a big chunk of the extensibility objects give you over ADTs. (I'd prefer to use multimethods, but they are rarely available.)

I think persistent collections, along with nice syntax for updating immutable objects (i.e. cloning with a subset of changed attributes) are more practical than having undo available. Immutable data types remove the burden of worrying about who's going to modify the data type from under you, so it lets you share subgraphs more freely. You don't need to worry as much about coupling, because the things you give your state to can't modify it. A possible alternative is mutable collections with snapshots or freezing, but I think persistent collections are a better approach.

Wow. Don't mind us mere mortals please continue your discussion, it seems really fascinating even though i hardly understand a word of it.

I consider myself a mere mortal too but I can understand most of the discussion.

The most complex code I've ever personally worked with involved a proliferation of abstract visitors in Java. I really don't think most people working on the code could understand how it all tied together (myself included).

> Visitors are implicitly closed to extension unless you create very abstract visitors (and I've gone down that path, it's not pleasant)

I'd love to hear more detail about your experience on this point.

I've never had to use visitors in my compiler implementations; abstract methods + overrides is good enough; I also use partial classes in C# heavily even those these don't support separate compilation. I also dislike callbacks also, but control flow in general is abstracted away by a flow analysis framework of some sort anyways (technically you don't need this for parsing, but it works well for the systems I build). On the other hand, scalac is just a giant pattern match in Typers and Namers, a style I dislike but to each his own.

I've built a live programming environment where reactive mutable collections are much more appropriate than immutable persistent collections, you can check it out here:

http://research.microsoft.com/en-us/people/smcdirm/liveprogr...

The problem with immutable collections in general is that they completely cannot track change deltas, which is necessary when building an incremental systems. Undo is also essential for these kinds of systems. I think persistent collections are a dead end, but its an argument I'll have to work on over the next few years.

I couldn't help but notice this phrase:

[X] is nice but [Y] will get you most of the way and [dealing with the difference] is simple.

reads a lot like the Blub conceit. I'm not accusing you of that, but I do disagree that OO can give you what pattern matching typically does.

What is the blub conceit? Google searched it and got nothing.

The important bit is:

    As long as our hypothetical Blub programmer is looking down the power 
    continuum, he knows he's looking down. Languages less powerful than Blub 
    are obviously less powerful, because they're missing some feature he's used 
    to. But when our hypothetical Blub programmer looks in the other direction, 
    up the power continuum, he doesn't realize he's looking up. What he sees are 
    merely weird languages. He probably considers them about equivalent in power 
    to Blub, but with all this other hairy stuff thrown in as well. Blub is good 
    enough for him, because he thinks in Blub.

From PG's Beating the Averages (http://www.paulgraham.com/avg.html)

A "my language is more expressive than yours" version of the Sapir–Whorf hypothesis.

I live ok without pattern matching and I build compilers/runtimes for a living; is that blub conceit?

I also have no problem with the expression problem. C# has partial classes anyways, which work even if type checking is non-modular. Of course, I would like it if C# support some form of pattern matching, but not enough to switch over to F# (whose pattern matching isn't as rich as Scala's, anyways).

> I live ok without pattern matching and I build compilers/runtimes for a living; is that blub conceit?

No, I would have quoted it the first time if it was. But if you want to repeat that again you will certainly sound conceited.

OK, I have no idea what point you are trying to make then. Please forgive my ignorance on your social conventions.

The point was simply that what you wrote is how a very bad argument starts. I took care to point out I wasn't accusing you of that but you have reacted defensively anyway.

It's my fault for trying to engage an HN-er in a form of discourse other than debate.

If its a meta comment, just say so directly. It is a bit difficult to decode these comments sometimes, especially when defending OOP.

>reads a lot like the Blub conceit

Perhaps. But then again the "Blub conceit" is nothing that exists in real life as a proven fact of computer science.

It's just an argument expressed in an essay. Not some kind of formal logical error.

What's your point?

My point, which is pretty obvious, is that it "reading like the Blub conceit" doesn't mean anything at all with regards to its correctness.

Might as well say "your argument reads a lot as something that an unbeliever in the flying spaghetti monster would say".

>The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching.

Why do you think this? I prefer having an open trait that's only inherited by ADTs.

I can get non-exhaustive match warnings and I still 'solve' the expression problem by matching on a superset of my partial functions (that do the matching).

Virtual classes with family polymorphism attacks the problem directly: you can add new variants as well as enhance the super class with new abstract methods: your system is abstract until all variants have implemented the abstract methods of the super class. You can then do cool things like factor all your functionality for X in one layer and Y in another layer, replicating variants in X and Y layers to specify their implementations separately.

When I did this in Scala (using traits and type parameters in a virtual class pattern), I got a lot of pushback from the FP people, who thought this problem couldn't, or more correctly SHOULDN'T, be solved using object-oriented constructs; it was one of the main things they liked to boast about in how FP was better than OOP, and I literally took that away from them. A 10,000 line pattern match was somehow preferable to a file with 20 traits that described how the new operation was performed per variant. Martin even made my pattern illegal via a new type check in the Scala compiler after I left EPFL :)

Reply on news.ycombinator.com