There's a fair bit more that is possible that would otherwise require a fair bit more code wrangling with AspectJ or BytecodeBuddy to achieve the same effects.
I tried to skim-read through the Unison About page, but all I saw was an under-designed variation of Jetbrains MPS for a single language. I assume you have spent longer with the project - do you care to summarize the differences?
From my experience, using the Google maps within the city, it tends to ne pretty sparse with labels by default.
This is a good thing because in a place like tokyo there is just too much stuff - if I care for aometgubd I either search for it, or drop a pub and check what is around.
On the other hand, Maps always shows the labels of things I have searched for in the past, yielding a customized legend of landmarks+things that matter to me.
I really like SemanticMerge, in its current shape it is litte more than a fancy proof of concept.
Its biggest limitation on real projects is that it works on a single-file level, while all the interesting stuff happens on patch level. You may browse their forums to get an idea of what else is missing.
That said, I wish all the best to Codice and I really hope that they continue to invest in this tool.
By "native" they mean JVM-native (not OS-native). I believe what they really mean is that they use JVM primitives for dispatch, as opposed to building their own using functor objects and reflection-like API (which was the only way to implement MOP pre-InvokeDynamic).
It is a bit misleading as there is still a lot that would have to be be emulated - the JVM does not support open types and the Java is centered around classes, which makes prototype mutation hard to implement efficiently ( InvokeDynamic somewhat helps, but would still impose a performance penalty when the prototype is changed).
>> There's an interesting point to be made here, though - "wrapping everything up in one type" is essentially what dynamic type systems do, except that it's baked into the language instead of being implemented by the programmer on an as-needed basis.
This is imprecise - a dynamic language does not really need to "wrap everything in one type" - look at Dart or Groovy. What makes it 'dynamic' is the dynamic dispatch. All dynamic languages I know dispatch based on runtime argument types, but this is only one particular form of dynamic dispatch. Declaring types in dynamic language typically is used at runtime merely as an assertion, that at this point the argument must conform to the said type.
Dynamic dispatch differs from Polymorphic dispatch in the way that polymorphic dispatch takes in account the runtime type of the target (the object whose method you are calling), but the types of the parameters are fixed at compile time.
Many dynamic languages also provide a way to customize the dispatch logic (i.e. call a default handler if no match exists) - typically via some form of Meta Object Protocol. Often the dynamic languages provide features like higher order functions, continuations, pattern matching, etc. but this has nothing to do with their dynamicity - same features are available in some static languages as well.
In a dynamic languages you can do dynamic dispatch - i.e. dispatching based on the actual runtime type of the arguments of a function, as opposed on the declared or statically inferred type. That among other things obviates the need for the visitor pattern and can also be used as rudimentary form of pattern matching.
reply