[wish] Optional runtime

[Marand-]

I understand that requiring a runtime (like Scala does) is against the intent of Mirah, but what about having some sort of optional runtime that further distances the language from its Java roots when used?

Something like how Red is separated into a small, fast core of "Red/System" and the more feature-filled "Red" that is built on top of it. With Red, you choose Red/System when execution speed is priority, and otherwise use the full Red for faster development.

In Mirah's case, you would use core Mirah when you either can't use a runtime or want speed and file size as close to Java as possible; Mirah+runtime would be for cases where you don't care and would prefer abstracting away the Java to make the language even more Ruby-like.

It's not something that could just be implemented overnight, sure, but if the (optional) runtime is part of Mirah itself, it could be extended over time, without taking away the advantages of the Mirah core.

I suggest this because, while I really like Mirah itself, not having an extensive, Ruby-esque runtime means it loses much of its niceness when interacting with Java. It's like having this awesome-looking couch that seems really comfortable at first, but when you sit on it a bunch of sharp bits under the cushion poke through. All it needs is a bit more padding to keep the sharp bits (Java) from being a pain in the ass.

[baroquebobcat]

This feels more like a mailing list discussion. That said, I've been thinking about it too. I don't really want Mirah to be more Ruby like per-se, but there are some cool things we could do with runtime access. eg, we could use dynalink to provide gradual typing.

[Marand-]

This feels more like a mailing list discussion.

Oh, sorry about that. I always forget mailing lists are a thing for some reason.

I don't really want Mirah to be more Ruby like per-se, but there are some cool things we could do with runtime access. eg, we could use dynalink to provide gradual typing.

I get that, it's just the closest relationship Mirah has syntax-wise, so it was a good example of what I meant about abstracting away Java. The idea itself actually came from how Clojure wraps Java syntax and concepts -- especially common parts like strings, numbers, etc. -- in ways that make them idiomatic to Clojure. You still have to make trips into Java land for things, but even that interaction is cleaned up for Clojure use with thing like dot and double-dot forms, .methodName calling, etc.

I was thinking about how I wished Mirah had stuff like that so I could spend more time with the Mirah parts than the Java parts, and then I remembered how Red separated its disparate parts and realised that could be how the two ideas (runtime-free Mirah vs. more feature-filled Mirah) could coexist.

[pannous]

+1000 for dynalink. Ready to assist with that goal.

[baroquebobcat]

Speaking of dynalink. It looks like there is work towards exposing the internal one used by Nashorn: http://openjdk.java.net/jeps/276

In which case, dynalink would become a shim on 7-8, and on 9 we'd used the bundled one. This is starting to feel like a really good idea to me.