Right on. Regardless of all the bletching over functionality, I'd be more concerned if you lost your focus on getting the basics right.
Having said that, it would be nice if someone could document (however roughly) the changes at each iteration. I know this goes against what you said in 'Arc's Out'[1] but I think it would help folks in fixing up their existing code and encourage the Arc community to dive in deeper... and that, I would have thought, can only be a good thing.
[1] ."So we're giving notice in advance that we're going to keep acting as if we were the only users. We'll change stuff without thinking about what it might break, and we won't even keep track of the changes."
I am new to Lisp as well, so please excuse my ignorance as I am probably missing something thats obvious to others here.
Does this mean then, that whenever we make a change to a macro definition we must also redefine every function that already depends on the original macro definition? If this is the case then I would imagine there's a lot of tricky maintenance required for a program that has lots of 'layers' when a 'base' macro is changed.
Yes. The way most Lisp hackers deal with this is to (a) define macros before functions that use them and (b) use the function load, which evaluates all the expressions in a file in order.
This breaks down on bigger projects spread across multiple source files, at which point one needs some "make" tool such as ASDF for CL where one can pile macros into earlier files and then make other files with code using those macros dependent on the macro-bearing file(s). This can make for a lot of recompilation after minor changes, so I just take my chances and (yep) recompile all when in doubt (which with today's systems goes pretty fast).
I'm currently in the process of teaching myself Scheme as well through a combination of HtDP and SICP and I was wondering what SIPS is? Perhaps it's another source I should check into.
Heh, that's funny and disappointing all at the same time--I was really hoping there was another really great resource on the web for learning Scheme. Thanks for the reply.
It's quite short and set out in a question and answers style. The thing is, it very gently and very subtlety bends your mind around to the Lisp way of thinking. After reading this, SICP seems so much more accessible.
There are also two follow on books - The Reasoned Schemer and The Seasoned Schemer which are again quite short and use the same interactive approach. I haven't had chance to read them yet but they get rave reviews on Amazon
Paul, in emphasising code brevity I think you are missing a greater good. I believe most of us subconsciously look for a language that is frictionless -- one that allows us to express our ideas without the language getting in the way. To me this is a far more appropriate measure of a language's power than the length of a program. I'd love a language that would allow me to stay in flow* and express my creativity without having to stop and think about the actual language itself. That would be the ultimate Zen power tool.
To be more specific here are three attributes that seem to aid frictionless flow. (perhaps in order of importance) -
--> Expressiveness -- i.e. simple, explicit and unambiguous abstractions.
--> Obviousness and readability. -- i.e. no need to decipher tokens, and the code structure illuminates the intention and flow of the process.
--> Terse. -- i.e. apart from the obvious benefit of requiring less work it also helps me 'keep the whole program in my head'.
There's nothing wrong with brevity of course, but when pursued for it's own sake it seems to be counter productive, in that when you focus on terseness alone there can be a tendency to ride roughshod over the more important attributes: expressiveness and obviousness. You then end up with code that's not as enjoyable to create and whose beauty is lost, except perhaps initially to it's creator.
BTW Paul, this is a great first shot, so a big thank you. I, for one, am routing for Arc to be a widespread success, if only so I can do most of what I need to do in a language that I really enjoy.
