I had high hopes for Arc over a decade ago, then it languished, then pg stopped participating.... then I looked at Racket (then PLT-Scheme) since that's what Arc was built on and realized Racket was the language I was looking for :)

You said this in the HN thread:

"I'm sure Arc is the wrong choice if I want to be as effective as possible in 6 months. If Arc is only the best choice if I want to be as effective as possible in 5+ years someone save me ;)"

The specific language is only one aspect of effectiveness - others include available libraries, an active contributing community, etc. I don't think there's reliable evidence that Arc will change enough in 3 years to fulfill your "effective as possible" goal.

Paul's last submission to his own forum has been over 5 years ago! And his last comment has been over 4 years ago. It would seem that he's not actively involved any more.

I was very excited to hear about Arc over 7 years ago, and I had high hopes that Paul might be the person to create a successful lisp and rally a great community. This has not happened, and I think it would be foolish to think this will change much in the next three years.

In the end, I ended up choosing Racket as my lisp - it made my short list to evaluate in part because Paul chose it to implement Arc :)

I burned a lot of time looking for my (not "the") perfect language, and finally settled on Racket for the dynamic language and OCaml for the statically typed language.

Now I'm trying see which problems are best suited to each of them.

Clojure has a lot of good things, but I've never been able to get past the dependency on the JVM, lack of tail calls, etc., but it's pretty darn concise.

http://lojic.com/blog/2008/09/04/how-to-write-a-spelling-cor...

One third the lines of the Ruby version and roughly half the lines of Norvig's Python version is quite an endorsement of conciseness.

If anyone has input data that demonstrates a difference between pg's and Norvig's, please reply with a comment.

Also, Paul, if it is equivalent in functionality, I'd pass it on to Norvig and he can add a link to his page.

http://norvig.com/spell-correct.html

You may want a nicer page to link to - maybe a blog post or something with more background info.

In case you didn't see it, see above (http://arclanguage.org/item?id=10580)

Not exactly the same results than Norvig's version (>>> correct("speling") -> "sling" / "godd" -> "god") but I tested the Ruby version linked on his site, and it yields the same results.

I.e: Your / my "correction" of pg's version give "spelling" and "good".

On the one hand, building on top of the JVM gives quite a head start in many ways, and I think it's a bit ridiculous how poor the interop situation is for native programs despite the availability of FFIs (although some/much of this may be fundamental to language differences).

On the other hand, it seems the least common denominator problem always creeps up when building on a VM plus you have an extra dependency in the chain, etc.

  ;; set a pointer to the cons cell, then dereference it as a pointer,
  ;; and bang the new value in the given offset

http://blog.plt-scheme.org/2007/11/getting-rid-of-set-car-an...

After your explanation, I do see the lowercase 'a'. But, it does bother me a little that the 'keystone' is rectangular vs. a wedge, as it seems like it might slip out of the arch.

I also see orthogonality and (as another poster said) a floppy disk.

Probably the most prominent image is a square which unfortunately doesn't seem very arc or arch like to me.

  Indeed, our experience is that making the result of `cons' immutable
  does not create many porting problems. Nevertheless, if your code does
  use `set-car!' or `set-cdr!', and if converting to a more functional
  style is difficult, then consider using `mcons' and the `scheme/mpair'
  library.

It's longer than the 8 line naive Haskell version because it's optimized.

  import Data.List

  knightMoves :: Int -> (Int,Int) -> [(Int,Int)]
  knightMoves n (x, y) = filter (onBoard n)
          [(x+2, y+1), (x+2, y-1), (x+1, y+2), (x+1, y-2),
           (x-1, y+2), (x-1, y-2), (x-2, y+1), (x-2, y-1)]

  onBoard :: Int -> (Int,Int) -> Bool
  onBoard n (x, y) = 1 <= x && x <= n && 1 <= y && y <= n

  knightsTo :: Int -> (Int,Int) -> [[(Int,Int)]]
  knightsTo n finish = [pos:path | (pos, path) <- tour (n*n)]
    where tour 1 = [(finish, [])]
          tour k = [(pos', pos:path) |
                  (pos, path) <- tour (k-1),
                  pos' <- sortImage (entrances path)
                          (filter (`notElem` path) (knightMoves n pos))]
          entrances path pos =
                  length (filter (`notElem` path) (knightMoves n pos))

  sortImage :: Ord b => (a -> b) -> [a] -> [a]
  sortImage f xs = map snd (sortBy cmpFst [(f x, x) | x <- xs])
    where cmpFst x y = compare (fst x) (fst y)

  main = do
    print ((knightsTo 64 (1,1)) !! 0)


  $ ghc -O2 knights_tour.hs --make
  $ time ./knights_tour

  30x30 = 0.22 s
  64x64 = 4.17 s

The performance is a little disappointing though :( Here's the performance of my Ruby (i.e. slowest of all languages!) version:

  ~/sync/code/ruby$ irb
  irb(main):001:0> load 'spelling_corrector.rb'
  => true
  irb(main):002:0> def time_sc n
  irb(main):003:1> t1 = Time.now
  irb(main):004:1> n.times { correct "zaqxsw" }
  irb(main):005:1> puts Time.now - t1
  irb(main):006:1> end
  => nil
  irb(main):007:0> time_sc 10
  25.809097

The Clojure version is considerably faster (0.33s per word):

  user=> (time (dotimes i 10 (correct "zaqxsw" *nwords*)))
  "Elapsed time: 3254.863 msecs"