I'm a noob with respect to both CL and Arc. For a long time I've wanted to familiarize myself with Lisp. My need for speed (driven by lots of number crunching) pushes me toward CL, but the fact that I'm only an occasional programmer makes CL's historical baggage painful (gotta remember that that the non-consing version of APPEND is not NAPPEND but NCONC, for example [and I don't want to touch of a flame war on this point, please {I've done so by accident in the past}: I can fully appreciate that if you program in CL every day, all of these little quirks cease to be difficulties and may even seem charming, just as do the inconsistencies of spelling in English]). I have high hopes for Arc, but I need more hand-holding (e.g., comprehensive texts) than it can provide right now, and I'm too squeamish to be programming at the frontier.
> gotta remember that that the non-consing version of APPEND is not NAPPEND but NCONC, for example
Ah, consistency: yet another thing lacking in Arc. Take 'afn and 'acons, for example. Or 'acons and 'number. Or 'number and 'string. Or 'string and 'sym...
(rv) generates a random algebraic variable. I am writing an algebra tutorial in CL and this code is from my DSL for the bit where I randomly generate algebra problems. (rv 2) would return a list of two variables one would reasonably find in a typical text. ie, x and y or m and n, but not x and a.
(dsb (a b c) (shuffle (cons 1
(random-primes 2 2 10)))
dsb is destructuring-bind. I did not use random-primes very oftwn so no abbrev. yet. :)
(dsb (x y z) (rpu 3 (r+ 5))
(rp n form) expands into a loop expression that repeats that many times collecting the result of the form shown. rpu is the version that ensures no duplicates (u for unique). (r+ n) generates a random number from 1 to n inclusive.
(m+- (m+- (ms* a (ms^ v x))
(m+- x y) generates either a mathematical expression tree my software will use for tutoring, randomly x+y or x-y
ms* generates a product as does m, but is smart about it and tosses a factor of 1. likewise ms^ returns a power but not if the exponent is 1, then just the variable. mss^ is supersmart and converts x^0 to 1.
(ms* b (ms^ (xqv v) y)))
xqv is short for mx-equiv, which copies a mathematical expression to get an equivalent expression. (mx-copy creates a Lisp copy that is "EQ" the original at the application's level of abstraction.
(ms* c (ms^ (xqv v) z))))))
Hmmm. This is a problem in factoring out the gcf of three terms ax^i + bx^j +cx^k.
Note that the above is as much about DSLs as it is about abbreviation, and I think if I wanted to delay shipping even further <g> I would break down and do a full parser of something like "ax^i + bx^j +cx^k,(abc)=[1 5],....".
Thanks. It's not the language itself that I'm concerned about. Rather, I'm wondering how much interest there will ever be in developing a truly fast Arc.
Consider Python, for example. It's been around for a while and is widely used. Yet it's still pretty slow. Fast enough for building websites, sure, but it's nothing like C or Fortran for serious numerical work.
Python's supporters will tell you that its slowness doesn't matter, because you can re-write the time-consuming bits of your code in C. I can imagine that that works well for web programming where latency accounts for much of the execution time anyway and one might only occasionally have a really chunky calculation to do. But in my experience doing Monte Carlo simulations, solving large systems of non-linear equations and that type of thing, a large part of the code is fairly critical for execution speed, so re-writing in C would mean doing a large part of the project in C. If I wanted to do that, I'd just write in C to begin with.
I've experimented with Ruby and Python lately, with the hard-care numerics to be written in C, as I alluded to above. I've not actually done huge amounts of programming recently, although in the past I did so in a proprietary language resembling C and in Fortran. Recently I have a look at CL (which accounts for my interest in Arc) and at OCaml, though I've not yet used either extensively.
As I have no doubt that it is possible to create an Arc implementation that delivers fast execution, it is precisely the socio-political issue that I intended to address in opening this thread.
As long as Arc is implemented in MzScheme, the best it can do is asymptotically approach MzScheme's performance. The discussion in this thread suggests that Arc will not forever be implemented in this way, so the limitation will be lifted. Just how much interest there is in greased-lightning performance is not clear to me.
I'm an English professor who does various kinds of computational analysis on large text corpora (so things like string handling, XML, and regex are really important to me). I've been known to write programs that take three weeks to run in Java, so I'm always looking for ways to make my programs fast without resorting to C. Nothing against C. It's one of my favorite languages. It's just not a lot of fun for string processing.
Basically, I always want to go high and fast with my languages, and that's one of the reasons I like Lisp. It's a super high level language, but (in my usage patterns) it outperforms languages like Ruby (which I adore) and Java (which I find increasingly annoying).
Now, my particular usage is perhaps a bit obscure, but it may generalize to other areas. I can't believe I'm the only one doing lots of text processing who wants a fast, high level language. In the end "web application programming" is really just a special case of text processing, so it may align with PG's goals at some more fundamental level.
