now the problem I see with say Arc is how to make use of that in a Google.com AppEngine, or a Microsoft Azure Platform
Why?
You can run Arc on a virtual server for $7/month. Less than the price of a pizza.
If there was some one thing that could only be done inside Google AppEngine or Microsoft Azure, write a little bit of native code (Python or F#) to do it inside the platform, and then have your Arc server connect to it to do that task.
You don't need to first get Arc running inside of platform X or platform Y, just run Arc. It works fine. And then if you want to run Arc in the cloud, fire up as many Amazon EC2 instances as you want.
So you make a good point as to how Arc can run in the cloud. I guess Arc could fit best in a platform stack like a cloud version of LAMP... somethng of that nature.
Amazon is hosting MySQL Database Services in the cloud, so you could take and have that as your database, and Arc make use of that.
Still what I am seeing though, and what I am running into from an Architect, design point of view, is fitting Arc into the puzzle.
I am trying to see if Arc gains me anything, in achieving what I laid out, with a more Organic approach, reflective nature for a system of record or business platform, that would allow a more organic, dynamic solution.
What I see though, is having to have Arc run on a seperate platform, or at least on-premise at the client, in a seperate platform, than the core data and solution run on.
That may be fine, but what I am trying to really get at, is what will Arc offer me, over using F# as my Dynamic Language, for example. To give that reflective, Dynamic, Organic in nature Functional development of a system of record or a business platform.
That's what I am trying to see... what would be the case I would make, that would bring Arc into the answer.
I am asking to, in way because I would really like to try and find a valid use for it, and follow it development, and contribute to it's development and growth as a language.
But if it comes down, to it's another Dynamic Language, it's hard for a business then to commit resources to learning it, making use of it, and deploying or employing it's use.
See what I am getting at?
And I offer all comments on that matter, because I am very interested at what Arc can possibly bring. I am looking for what all that could, is, and might be.
First, do you like Arc? Do you read the tutorial (http://ycombinator.com/arc/tut.txt) and say, "Oh, yes, this a language I want to program in"?
Second, are you in a "known problem, known solution", "known problem, unknown solution", or a "unknown problem, unknown solution" situation? Do you know yet exactly what it means for you for data to be "organic" or "dynamic"? Arc is an excellent language for prototyping, sketching out ideas, trying things out. In a day you could make a small web application that stores and retrieves data, and you could try one one "dynamic" or "reflective" thing and see what you thought of it when you tried it out for real.
Third, are you offering SaaS, software-as-a-service, as for example how Salesforce does? That is, are you storing your customer's data for them? Now you can use whatever server language you want, your customers won't know or care. If Arc gives you a competitive advantage because of its flexibility, you can go ahead and use Arc.
And, by the way, I wouldn't start off using MySQL to store data. Just keep it all in memory backed by files on disk. SQL databases are good at quickly looking up records on computers that don't have very much memory, but they aren't particularly "dynamic" or "organic".
Fourth, are you asking client businesses to work with your code? That is, as you say, do you need other businesses to "commit resources to learning it, making use of it, and deploying or employing it's use"? If so, then no, I would not use Arc. Other languages impose restrictions so that bureaucracies can use them. The trade-off is that then the languages they can use are less powerful and so their programmers are less productive. But you can't go to a bureaucratic business as say, "hey, you should use Arc, it's more powerful", because you won't be meeting their bureaucratic needs.
