Judging from the introduction materials, there are some things Magpie would give us over Arc: A friendly Rubylike syntax, an obvious approach to OO, and a pattern-matching multimethod system based on a nominal type hierarchy, with automatic precedence ordering and static ambiguity errors. Arising from these things, there may be some subtle differences in the feel of programming in the language.

The syntax and OO approach aren't worth emulating, IMO. Even though Magpie values minimizing the transition from pseudocode to runnable code, I think its approach is skewed toward a particular kind of pseudocode at the exclusion of others. I tend to write my pseudocode in Arc--surprise surprise :-p --so all the trouble Magpie goes to for Ruby-like syntax and infix-style method calling seems a bit misguided from where I'm standing.

The multimethod system is something we've approached in Arc from a few different angles. For pattern-matching, there's the built-in destructuring syntax, there's almkglor's 'p-m macro (http://arclanguage.org/item?id=2556), and there's my "patmac" system (http://arclanguage.org/item?id=11956). For multimethods, I have a nominal-typing-with-inheritance multimethod system (http://arclanguage.org/item?id=12135), and of course there's the less frameworkey, more popular 'extend and friends. In a way, this part of Magpie isn't far from how we already use Arc, sometimes; the difference is we don't have all our tools yet.

My patmacs were supposed to be a kind of stepping stone to a more CLOS-like multimethod system which, besides having type checks sorted by inheritance, would also have identity checks which took precedence over all type checks, along with destructuring patterns and so on. Instead, I found the predicate dispatch I already had was nice enough, and it instead pulled me in the direction of failcall and special-case destructuring forms like 'iflet. I kinda expect to get back around to thinking in terms of a Magpie or CLOS style multimethod system sometime, but I'm in no rush.