Thank you pg and rtm (opens in new tab)

Any chance of releasing a book or spec alongside Arc at some point? Or are you encouraging people to just play around with it for now? I'm just wondering whether the idea here is to encourage exploration through scarcity, or that there's insufficient resources to produce the documentation, or if it's just too early on at this stage.

However, it's IMO, unacceptable for a fairly new Lisp programmer to cast aside 50 years of Lisp research, development and deployment while brushing aside the industry's backbone languages, and herald Arc as the best thing ever when it isn't even finished.

I can accept personal choice and opinion, if kept to one's self and made in private. Even if someone sings Arc, or Clojure or Common Lisp or Scheme, praises, I am fine with it. But to say "Languages X, Y, Z suck because they don't allow me to write succinct programs", well, you're just trolling for X, Y and Z programmers to come out and straighten you out. The sort of macrology he is after (code-compacting type, not language extension) is pretty basic and could be done with the C pre-processor and M4. You can even write compact assembly programs with GASP, HLA, and NASM macros; it's not rocket science.

I reserve my judgment for Arc until it's done. There is no manual yet to hold the compiler accountable, and to save me from guess-work. However, what I can't ignore is blind fanboyism; if everybody here sang Arc praises, when it is just arc-tutorial.txt and arc.arc, and there were no "dissenting" honest voices, well, the place just wouldn't be the same.

> The guy expressed an opinion...

In technical circles even opinions have to be defensible. You can't just accept "X sucks and Y rocks" as an opinion and let it pass. The whole place will become abuzz with irrational thought, and overrun with "we are all right" group-think liberal-arts type BS.

Ok. I will accept that.

Here is my take on your personal essay, it's also a matter of personal opinion made after sufficient technical evaluation of the matter: I think you need to be a little more critical of your own reasoning, specially when writing for programmers. The spirit of your essay has been largely positive, IMO, but go easy on the snide remarks and the dismissive attitude of other technologies you have very little experience in (yeah, it shows.) Otherwise a much less sympathetic reader than I, and a far more competent one, will come aboard and tear your argument to pieces.

A better way to frame your enthusiastic writing would be "I can do X in Arc, I really wish ${LISP_DIALECT} would let me do the same". This is both curious and also accepting of one's own self-limitations. Someone will come aboard and show you what you have been missing, and you might as well get pointers to the literature that further your understanding of Arc or whatever other technology.

Regards.

I should have been nice, we're all equally-right in some way. hugs.

"I’ve long liked Lisp, but hadn’t been programming in Lisp for a long time because I hadn’t found any features in Lisp compelling enough to overcome the advantage other languages had in having large libraries available and such like."

I mean, come ON. If Lisp wasn't compelling enough because of the perceived lack of libraries, then Arc is the last way to come back to Lisp as it has NIL.

It's completely acceptable to have a preferred Lisp, but it's unacceptable to do so for irrational reasons ;-) Every time you need a new library/feature in Arc you're most likely to call out to the MzScheme runtime and FFI. It's highly hypocritical of you to dismiss a language for lack of libraries, then jump on another language it hosts.

Java as a language, the syntax, is for me sane. It gets a lot of things right, and some things wrong, but on balance, it's sane enough to use. Just like English as a language is sane enough to use, whilst having lots of stupid inconsistencies in spelling/pronunciation etc.

And it's likely to be the fastest/most optimized of any JVM target language.

My statements that I prefer Arc for the kind of programming I do was not intended to be a put-down of other languages.

If you should be so unfortunate to be stuck trying to write good code in Java, ...

One solution is to remove the connotations, eg:

If you are writing code in Java, ...

Note: this version is more concise :-)

But please keep the factual points, such that Java's verbosity can mean that removing duplication doesn't make it shorter. I thought that was an insightful and pithy expression of the idea. But I also note that that's not the only benefit of removing duplication.

Do linguists agonize over language efficiency as much as some programmers do? For example, writing English is maybe far more letters/strokes than Japanese (idk), but we don't all start learning Japanese and bash English.

Hygiene can also be baked-in to a nice lispy defmacro-style system; there's no reason that hygienic macros have to be scheme-style. Variable capture can be permitted with a (capture x) special form. (I like to use ^x as a shorthand for that).

At that point, macros start behaving scope-wise similarly to lexical functions, and captured variables behave kind of like dynamic variables in a function.

It suddenly occurs to me that this form of hygiene could be implemented in the expansion of let, lambda and defun forms, at which point (someone yell at me please if I'm wrong), plain-ol' defmacros would be hygienic, unless there's a type of variable capture that I'm forgetting about right now...

> It's easy enough to achieve with a defmacro-style macro system - just use gensyms.

Gensym cannot prevent global identifiers from being shadowed in macro use environment.

    (define-macro (my-if a b c) `(if ,a ,b ,c))

    (define (boo)
      (let ((if list))      ; if is shadowed
        (my-if 'x 'y 'z)))  ; evaluates to (x y z), not y  

The Rewrite Tool is not dynamic. Perhaps this is the key? But I could imagine a Smalltalk function that takes a method, applies a Rewrite Tool syntactic transformation to its source, compiles the method as a Block, then calls this Block with the arguments that would've been send to the original method.

Something like:

    perform: methodName 
    with: arguments
    rewriting: aMatchingPattern
    as: aRewritePattern

    ``@rcv
        ifTrue: `Block1
        ifFalse: `Block2

    "Order of Blocks reversed"

    ``@rcv
        ifTrue: `Block2
        ifFalse: `Block1 

This particular example would let you dynamically call any method, but with all of the if-then-else equivalents with the then and else clauses swapped.

Would this constitute Smalltalk Macros?