"There is a persistent but unfounded notion that between can be used only of two items and that among must be used for more than two. Between has been used of more than two since Old English; it is especially appropriate to denote a one-to-one relationship, regardless of the number of items."
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.
You know how when programming in e.g. Java, it's nice to have a good IDE to auto-insert common code patterns so you don't have to do a lot of typing? In Arc all the code patterns are already squeezed out, so I can write nice programs without a lot of typing in a plain editor. I find this makes writing programs in Arc a pleasure, so it's simply more fun for me :-)
I do find Arc particularly useful when I'm working on algorithms, where I'm trying to figure out what to do. The conciseness, simplicity, and transparency of Arc means that I can get close to working on a direct expression of the algorithm itself, instead of a more verbose translation of the algorithm into a more cumbersome verbose implementation. (See my write up on a parser combinator http://awwx.ws/combinator/ for an example). This makes it easier to change the algorithm, because I don't have to mentally translate the implementation back into the algorithm to work on it.
I think your question of Arc vs. .Net, Java, etc. may be a bit of a false dichotomy however. If I were writing a program, and to take Java as an example again, if there was some powerful Java library that I could use or some Java-based cloud computing environment would be useful to me, I wouldn't be thinking "OK, so should I use Arc or use Java?" Instead I'd be calling the Java library from Arc, or running Arc inside of the Java-based cloud computing environment.
There is some overhead to using Arc, it is slower than other languages so you may find that you need to work on optimization sooner than you otherwise would; calling a e.g. Java library from Arc can be less convenient than simply calling the library from the same language it's implemented in.
So for any particular project I think it comes down to a cost/benefit analysis. When I'm in a "known problem, known solution" kind of situation where I just need to crank out some code to get something done, I often will just grab Perl or Java or Python, whatever tool happens to be quickest to implement the particular task in because of the libraries the language has available or the environment it runs in. I'll probably end up writing some "boilerplate" type code, but I'm only writing it once and I know what to write, so I don't care all that much.
When I'm exploring, when I don't know what the solution is and I may not even have a good sense of what the right problem to be solving is yet, then I'm happiest when I can play around with the code very easily. I want as little of "boilerplate" type code as possible, because as I try "this, that, and the other thing" I don't want to be typing boilerplate stuff for each attempt.
- I found I never used the label feature, so I dropped it.
- I noticed that I was often repeating the argument list in the test and in the body, so the test and body are now implicitly wrapped in a fn and the one argument list is used for both.
- Sometimes I need to use the value of the test expression in the body, so the value returned by the test expression is now available in the body as it.
- I haven't used this yet so maybe I don't need it, but inspired by redef in Anarki the original function is now available in the body as orig.
I use extend when I need to conditionally redefine a function based on a specific test that I'm applying to the arguments. For other kinds of redefinitions, you may want to use redef or some other method.
> Just to be clear: do you mean that an arc reader, on encountering #table(a 1 b 2) should create an object equivalent to that returned by (obj a 1 b 2)
Yes, for that example. Though with #table(...) the values are always literals, so #table(a (+ 1 2)) wouldn't be (obj a (+ 1 2)) but instead would return the same value as (obj a '(+ 1 2))
a table literal in code should also contain other code to be executed at runtime ... I prefer {...} to #table(...)
right, if you want your table literal to be able to act like a "template" in the sense that you can insert expressions to be evaluated, then we'd need some kind of syntax to "unquote" the expression.
But I don't know how to do that and get everything to work.
I'm certainly open to suggestions, I'd just need working syntax to implement it.
The other option is not to try to get the syntax you like for constructing tables to be the same one as the writer/reader uses to output/read literal tables.
You could come up with a {...} syntax you like to use while programming, and that would be easier than coming up with a {...} syntax that the writer would also use to output tables, because that has the complication that every table needs to be able to be written out in a way that can be read back in.
For example, suppose you wanted a {...} syntax that worked like obj. Then, in regular Arc:
arc> {a (+ 3 7)}
#hash((a . 10))
or, using #table as the read/write syntax:
arc> {a (+ 3 7)}
#table(a 10)
That's easy to do. Now, if you also wanted your {...} to be used as the read/write syntax, that would be a lot more difficult, maybe impossible. At least I don't know how to design a syntax that would work for both, and still be able to read/write any table value.
This doesn't strike me as being particularly odd, since it's exactly the same for lists already.
arc> (read "'(a (- 5 4))")
(quote (a (- 5 4)))
arc> (eval:read "'(a (- 5 4))")
(a (- 5 4))
arc> (eval:eval:read "'(a (- 5 4))") ; would call a with 1
Error: "reference to undefined identifier: _a"
Here's where I think the real gotcha is:
arc> '{b 1 a 2 a 3}
{a 3 b 1}
arc> '`{,(uniq) 1 ,(uniq) 2}
(quasiquote {(unquote (uniq)) 2})
arc> `{,(uniq) 1 ,(uniq) 2}
{gs1700 2}
Having a table as syntax can be a bit unintuitive, since it doesn't preserve order and multiplicity in the source the way a list does. Still, I personally try not to rely on side effects or evaluation order in expressions like this, and I figure that whenever someone does rely on those, they'll be writing code, so they can just use 'obj.
EDIT: Now that I think about it some more, those concerns can be mitigated too.
I do lots of my programming in Groovy, where the tables made by literal syntax do preserve order. They use LinkedHashMap, which essentially stores its references in both a hashtable and a linked list, so you get hashtable access speed and fast insertions and deletions while preserving order, at the cost of space efficiency.
As for the multiplicity issue, that can be caught by the reader. That is,
arc> `{,(uniq) 1 ,(uniq) 2}
can produce an error at read time rather than silently treating the expression as `{,(uniq) 2}. Since any table already loaded has unique keys, nothing that can be written out will trigger this error when it's read back in.
EDIT: Well, I suppose there might be some question as to whether the reader should really have to compare things by 'iso, which would put a wrench in any plans for writing recursive/repetitive mutable structures. But I'll stop arguing with myself and give someone else a turn. :-p
is what is happening is that the reader parses "{...}" into a table object with a as a key and (- 5 4) as the value, and then the Arc compiler would, when it was passed a table object to compile, recursively compile the values of the table?
If so, then the part I wasn't getting was that the reader would return an actual table object which the Arc compiler would then work on... I hadn't thought of that approach.
