I suspect that for the most common uses the disadvantages of providing language interoperability in the same process outweigh the advantages, and so personally I'd be surprised if implementing Python and Arc in the same runtime would have much impact on the uptake of Arc. I could be wrong of course... and then I'd be surprised :-)
With respect to there being lots of variants of Arc, I think about Arc as a personal programming language. Thus that it allows extensive personalization, and people publish many personal variants, is to my mind a feature not a bug.
This diversity of course raises its own issues: we're concerned not just with interoperability between Arc and other languages, but interoperability between variants of Arc! :-) But solving this provides a more powerful platform than one stuck with providing the lowest common denominator of standard language features to ensure interoperability.
I also think that the idea of personal programming languages remains largely unexplored territory. Thus if there is significant uptake of Arc, I imagine it may not come at the expense of other languages, but instead it could be for new uses. Because of this belief I tend not to pay much attention when someone says "Arc should have X because other languages have it", but I'm very interested when someone says "I'd like to use Arc myself, and I'd be able to if only it had X".
"I suspect that for the most common uses the disadvantages of providing language interoperability in the same process outweigh the advantages"
I've never thought of that. I'm used to using Racket stuff from Arc without hesitation, but then the stuff I use is provided with the Racket language, like parameters and regexes. Most of my non-Arc personal code is in Java or Groovy, and I'm very glad I can use it from Rainbow, but I haven't actually done that yet....
Still, I can personally attest that this kind of feature has played a role in my adoption of languages, regardless of whether I've used it. :)
Through-out this whole thread I've wanted to kick in and say: "boy I wish Arc was built on top the jvm, similar to Clojure's implementation", but then I also realize one might as well just switch to Clojure if that's what one wants.
Would have been be nice though. Smart move by Rich.
The way clojure implemented it allows for seamless integration between libraries. With clojure I can load and easily make use of any java code out there. I can use cron job libraries, database libraries etc. etc. And I really don't require much java knowledge, just a basic API used to call the library/jar file. This gets people on-board, hence larger community, building all kinds of kewl apps/libraries... More solutions, more knowledge base... Just more options.
With arc, the language syntax and base libraries are awesome, but you scratch your head more often, wondering" well how the hell am I supposed to do that. " And these problems/features are not small roadblocks... For example, if I need to use Arc connecting to oracle? - good luck, it's not going to happen.
If arc were built atop the jvm, the way clojure is... These problems all go away.
Thanks for the offer. I think real database connections to arc could only improve the adoption + user happiness levels, but I will suggest connecting to oracle was just an example for the point I was trying to make.
What I am suggesting is not new or even surprising. Arc has no depth for libraries. Rich solved this problem right from the get-go by having tight integration with java. Arc would have had similar success had it done the same thing - too bad really. And dropping into Scheme just doesn't cut it.
I'm suggesting users of arc will google things like 'arc oracle', or even 'scheme oracle' which returns jack. With Arc you get Nada for google answers + you get unanswered posts such as these.
step-by-step recipes to connect to a myriad of databases. This was made possible through Clojures tight integration with java. Clojure can import java libraries with 1 simple import statement.
Let's not forget that Clojure is a newer language than Arc - correct?
Now, I'm just looking at the title of the thread "Effort to make it easy to use in production?", and thinking - yeah, I can understand, that's why I moved over to Clojure and its too bad Arc didn't do this.
Sure I'm no expert in the programming language industry, but if I were to come up with a new spiffy language I'd rather do what Rich did. Arc could have been built atop the jvm - correct? It was just easier not to, considering arc was not about being practical, it was about attaining some elusive mystical idealized syntax that will be practical in, possibly, a hundred years from now.
Sorry if this sounds like a rant, but it just seems like the original poster wasn't getting much love, and I can appreciate what and why he/she was asking.
When I started work on my Arc runtime project, the first thing I looked at was what I thought would be the best platform to write the runtime on top of. Racket seemed to be moving away from Arc in some ways, so I didn't start with the assumption that Racket was going to be the right choice. I looked at a number of options, and concluded that as far as I could tell that Racket still had the best mix of features.
The JVM naturally has the advantage that it's easy to call Java libraries, but it has the disadvantage that it has no built-in support for tail call optimization or continuations. Since it's not particularly difficult to make use of libraries running in a different process, it would be easy enough for me to use Java libraries from an Arc implemented in Racket if I wanted to, and so I had no compelling reason to write ar on top of the JVM.
There is a long history of languages written for people who want to use the JVM but who also want to be able to use a less terrible language than Java: Jython, Groovy, Clojure, etc. Since Clojure is a particularly nice language, it didn't surprise me that it rapidly gained popularity among people who want to use the JVM.
For any particular project that I may be working on, there are a mix of features that I need for that project. If I were working on a project that primarily needed to call Java libraries and I didn't need the features unique to Arc, I would most likely use Clojure myself (or Rainbow or Jarc, if it turned out that one of those were suitable to my project). If I were working on a project where the features of Arc were important and I also needed to call some Java libraries, I'd likely write it in Arc calling out to Java libraries.
Since this is a forum for Arc, I answer questions primarily from the perspective of Arc. Since typically a hundred people will browse a forum for each person posting, I primarily answer questions for the majority reading. For example, if someone makes a statement that is wrong, I will say that they are wrong, so that someone else reading the forum isn't left with incorrect facts.
When someone complains about Arc, I tend to suspect that either there's something they want, or else they just feel like complaining. People wanting things is useful. If someone actually wants X and says so, and we come up with a solution for them, then we also help the hundred other people who want that thing as well. Other the other hand, and I'm not saying that anyone has actually done this, but if someone were to sit at a computer and type in a complaint that other people haven't done the work to make Arc a popular language faster than some other language has become popular, that doesn't strike me as being particularly useful.
I'm not against complaining. Complaining is often a useful first step towards finding a solution. However, while I'm not trying to pass judgement, I am trying to discern whether someone is complaining because they just want to complain or because they want a solution.
Again, when I answer a question, I answer a question primarily for people in general reading the forum; and from the perspective of people wanting to use Arc. Thus if Clojure is a better solution for you for most of the projects that you work on, that's fine, I agree you should use Clojure. However when I read "for example, if I need to use Arc connecting to oracle? - good luck, it's not going to happen" my immediate concern is that someone else is going to read that and might be left with the impression that it's prohibitory difficult to connect to oracle from Arc... which, while it's certainly harder to connect to oracle from Arc than it is from Clojure, isn't all that difficult.
Being difficult or easy is a relative thing. The hours of investment by grade-a developers contributing to making these production grade feature-x's in other languages leads me to feel pretty comfortable suggest that having them,
or a dozen other similar feature-x's would not be all that easy.
Sure, if you have spent hundreds of hours doing low level hacking between racket<->arc you can suggest these things are not all that hard, but the reality is that many of these feature-x's are just not going to happen.
Chances are that mainstream features are not a priority for the members here... And that's my message to the OP: go use Clojure or something having the features you want. I say this from 2 years of following arc, the arc forum and its members. There are probably a dozen submissions/comments about db connects and FFI, yet to this day nothing works.
The people on this forum, who know me, know I like the arc language, often promote it and that I'm not here to tear it apart, but I'm going to be real about it and make sure the op gets the right message (from my perspective).
> "If you like the Arc, then instead of complaining that other people aren't figuring out what you'd want to use for you, why not take the time to help and describe what you would need in a db connection library and FFI?"
I'm thinking if you re-read the thread starting from my first comment (http://arclanguage.org/item?id=14539), you'll hopefully come to understand that I haven't been complaining, but rather I have been defending/substantiating my suggestions and thoughts.
As for why I don't take time to describe some spec, well because I'm not asking for anything and I've chosen to spend the bulk of my time learning Clojure and building applications. I guess you could say I take my own advice.
> "If you want some love on the forum, there's an easy way to get that:make a useful contribution."
It's pretty obvious, based upon your replies, that you don't see my posts as valuable contributions, but maybe you'll come to understand these posts are intended to help the OP rationalize his topic, not to gain some form popularity/acceptance with or by you.
If you like the Arc, then instead of complaining that other people aren't figuring out what you'd want to use for you, why not take the time to help and describe what you would need in a db connection library and FFI?
Or, you could add a page to the wiki describing the ways that Clojure is better than Arc.
If you want some love on the forum, there's an easy way to get that: make a useful contribution.
If the JARs are in the classpath, the classes are just as accessible as any standard platform class like java.util.Map. I give a demonstration here, where I explain the custom interface I built so I could sometimes use the same code on both platforms: http://rocketnia.wordpress.com/2010/06/01/lathes-arc-to-impl...
Since then, Jarc's actually added Rainbow compatibility functions, so you might be able to get away with writing code just for Rainbow without leaving Jarc too far behind. Rainbow's faster, but Jarc has a more straightforward implementation.
I recommend having one of the JARs be a language with eval, like Groovy, JRuby, or Clojure. Jarc and Rainbow convert certain values to/from Arc in ways that are nice most of the time but sometimes lose precision, like the distinction between Boolean.FALSE and null.
