Arc Forumnew | comments | leaders | submit | lojic's commentslogin
4 points by lojic 2559 days ago | link | parent | on: How many people still lurk here?

True :)

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 :)

I still pop in occasionally out of curiosity.


3 points by lojic 3443 days ago | link | parent | on: Interested in being an Arc tutor?

I think anyone who is interested in a lisp has been positively influenced by Paul Graham, I certainly have.

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'm certainly not trying to "save [you]", but I see many similarities between your quest for the most effective language and my own and countless others :) The language is very important, and concision is important, but you really need to evaluate the entire ecosystem to make a good choice.


2 points by jsgrahamus 3442 days ago | link

lojic - What did you end up using Racket for?


3 points by lojic 3442 days ago | link

I've mainly just been learning the language. Working through some tutorials, reading books/articles, coding, etc. Did a few Project Euler problems, and now I'm working through SICP.

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.

The Racket community is incredibly strong IMO.


If it is correct, it's impressive. I wrote the Ruby version that Norvig links to which is here:

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.

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

I actually get fairly consistent traffic from Norvig's site to my blog post, so it could be a way to expose Arc to more programmers.


2 points by palsecam 5372 days ago | link

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

In case you didn't see it, see above (

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".

And pg's vanilla version for (correct "yellow") gives "fellow".


2 points by lojic 5371 days ago | link

Sorry, I noticed your post after I posted in haste. Nice work - 12 lines is still darn impressive. Followup with a comment if you use Norvig's test program and notice any other issues.


2 points by lojic 5430 days ago | link | parent | on: Question: What are Arc's strengths?

I really have mixed emotions regarding the two approaches of building on the JVM vs. building from scratch.

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.

If the Y axis is features and the X axis is time, it seems clear that building on a VM gives you a higher Y intercept. The question is whether the slope is unduly impeded. I suspect it might be, but that's totally subjective on my part.


2 points by lojic 5437 days ago | link | parent | on: Arc 3.1 (works on latest MzScheme)

Can you summarize the principal changes required to work with an immutable cons ? I guess now that the files are versioned (thanks!) I can just do a diff, but if there are extensive changes, it might cause a Lisp newbie to miss the forest for the trees.


4 points by lojic 5437 days ago | link

In ac.scm

  ;; set a pointer to the cons cell, then dereference it as a pointer,
  ;; and bang the new value in the given offset
Hmm... so the fix was to "cast" the immutable cons cell to a mutable cons cell? Glad it works, but I was kind of hoping to learn that the immutable cons cell thing was workable for Arc. I guess I should read up on the MzScheme decision to make it immutable and see what pros/cons are associated with it.


1 point by soegaard 5436 days ago | link

See Flatt's blog post:

Further discussions can be found in the mail archive.


1 point by vegashacker 5436 days ago | link

Here's a post about it:


1 point by lojic 5500 days ago | link | parent | on: Arc Logo

My wife (a fine artist) liked the aesthetics and said it reminded her of a Mondrian painting, but she didn't get the lowercase 'a' or keystone :)

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.

There seems to be a lot of potential with arcs, arches, 'A', lambda character, etc. Also, having a logo change is not a huge problem, so not getting paralyzed with an attempt to get the perfect logo initially is important IMO.


1 point by lojic 5521 days ago | link | parent | on: Request for Bugs

Some info from:

  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'


Isn't that the right direction, away from Java & COBOL ?


Here's a Haskell version from:

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


2 points by lojic 5696 days ago | link | parent | on: Arc Challenge

Thanks! I'd say that definitely compares favorably with the Clojure version aesthetically.

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 =
  irb(main):004:1> n.times { correct "zaqxsw" }
  irb(main):005:1> puts - t1
  irb(main):006:1> end
  => nil
  irb(main):007:0> time_sc 10
So that's 2.6s per word.

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

  user=> (time (dotimes i 10 (correct "zaqxsw" *nwords*)))
  "Elapsed time: 3254.863 msecs"
For words for which a correction was found, the Clojure version processed 900/s, Ruby 100/s


1 point by cchooper 5696 days ago | link

Oddly, the Ruby version runs more slowly every time I run it. I think memory locality may be the problem, as the Ruby process grows each time (now at 85 MB). That's nothing compared to my MzScheme process which is now consuming 700MB. That's probably due to the inefficient way in which nwords is constructed. A bit of tuning there might work wonders for overall performance.


1 point by babo 5691 days ago | link

Please post python's speed as a reference, it's wicked fast as far as I remember.