In fact, many languages (or at least their large libraries) do have accommodations for sounds, images, etc. This is because most languages have some sort of "class" mechanism, and create classes for those things (in their standard library or in a very common one). And sometimes, what you are working on is a string parsing/manipulating/generating program, where strings do belong.
Why is what's popular popular in general? The biggest obstacles to popularity for Lisp, as I see it (and I'm not an expert) are the prefix syntax and its attendant parentheses; the history of having been chiefly used for AI, which is rather esoteric; and the (undeserved) reputation for slowness. Paul Graham has more to say in http://www.paulgraham.com/iflisp.html . None of these are intrinsically bad, but they are often perceived as such.
The interviewers are surprised because Lisp isn't popular, as you observed, and nobody expects it to be used for anything big.
Is Lisp impractical? Not really. As I understand it, the one problem it has is lack of libraries. Why? Because it's not popular. Even so, most things you want to do are probably librarified already, as "lack" here is relative.
Is Arc impractical? Not in the abstract, but it sounds like it will be for you. I don't think that Arc should be the first language you pick up, for a few reasons. It is still in a state of flux; it is missing certain features; it is designed for experience hackers; and, most importantly, there is a real paucity of documentation. http://arcfn.com/ has some great stuff, but that's about it. Starting in Arc would, therefore, be difficult.
Learning another Lisp would be a good idea, however; I would recommend learning Scheme. You might try working through How To Design Programs (http://www.htdp.org/) in Dr. Scheme (http://www.plt-scheme.org/); as I learned Scheme as a later language, I never worked through it, but from what I see and what I hear, it seems like a very good text. (I've never used Common Lisp, so I don't feel qualified to talk about it, but if someone wants to put in a good word for it, that might be helpful.) After you get a handle on that, you would almost certainly be able to pick up Arc in its undocumented state.
And if you really want a challenge, of course, you could always jump right into Arc; sometimes that is the best way to learn something.
Personally, when learning Lisp, syntax wasn't a big issue. While the infix syntax of most languages is fairly intuitive, the rest of syntax (of e.g. C++ or Perl) is scary compared to Lisp's parens. (Although perhaps what puts people off is the frightening simplicity of Lisp's lack of syntax after using a conventional language.)
One the things that proved difficult about learning Lisp was choosing an implementation. There is no canonical implementation and as such I had to try several out before I learned which ones I enjoyed using. This survey of CL implementations (http://common-lisp.net/~dlw/LispSurvey.html) helped me when deciding which implementations to try. I recommend both CLISP (http://clisp.cons.org/) and SBCL (http://www.sbcl.org/), but that is just personal preference.
Also, the IDE was a difficult issue. I eventually settled on emacs with slime (http://common-lisp.net/project/slime/), although I have occasionally used Cusp, a Lisp plugin for Eclipse (http://bitfauna.com/projects/cusp/index.html). The main problem here was a lack of (thourough, easy to follow, up to date) instructions. Over the last couple of years I have gradually found good instructions on slime, but I can't seem to find any of them right now...
I wasn't saying that the prefix syntax was an issue, just that it hampered popularity. Perception ≠ reality, after all. I too quite like the prefix syntax. I still slightly miss the simplicity of some of the Ruby code that I wrote, but the prefix syntax always wins me over; its benefits (macros) outweigh the minor downsides. Especially with []s and ssyntax.
And thanks for the CL thoughts! Regarding IDEs, I myself have ended up working just from the Mac OS X text editor TextMate (using Visor, which puts Terminal on a hotkey), and haven't found it problematic.
I'll second the recommendation for Scheme in general and PLT Scheme in particular. Arc is built on top of PLT Scheme at the moment. Another great book is The Structure and Interpretation of Computer Programs (http://mitpress.mit.edu/sicp/).
This is actually fairly simple to write (first defining butlast for convenience):
(def butlast (seq)
" Returns every element of `seq' but the last one.
See also [[last]] [[cut]] "
(cut seq 0 -1))
(mac letn parms
" Simultaneously ssigns the given (unparenthesized) local variables in the
one-statement body.
See also [[let]] [[with]] [[letns]]"
`(with ,(butlast parms) ,(last parms)))
(mac letns parms
" Sequentially assigns the given (unparenthesized) local variables in the
one-statement body.
See also [[let]] [[with]] [[letn]]"
`(withs ,(butlast parms) ,(last parms)))
Then letn is like with, but unparenthesized, and letns is like withs, but unparenthesized. (letn = "let n variables".) And yes, destructuring works.
Heck no. We can do this ourselves. Remember, the textual transformation to transform let's is just that: a textual translation. It should be possible to create an automated translation tool (based off raymyers' treeparse) that will handle this for us.
Let the old version of 'let be Arc2Let, and the proposed new let be Arc2.7Let. Let the old version of 'with and 'withs be Arc2With and Arc2Withs, respectively. We need to determine if each Arc2Let in the source is composed of a single expression in the body. If it is, we leave it as-is. If it isn't, we simply replace it with Arc2.7As.
For each Arc2With we determine if the body is composed of a single expression. If it is, we replace it with Arc2.7Let, removing the parens around the Arc2With bindings. If it isn't, we leave it as-is. Ditto for Arc2Withs, replacing it with Arc2.7Lets.
We define an expression simply as a sequence of whitespace, base-expression, and whitespace. We define whitespace as being either a comment (either #||# or ;) or ordinary whitespace.
A base-expression is simply a symbol, a number, a character, a string, a quote-expression, a comma and comma-at expression, or a list. A quote-expression is simply the ' quote or ` backquote character followed by maybe whitespace, followed by an expression; comma and comma-at are defined similarly. A list is composed of an opening parenthesis followed by many expressions, followed by a closing parens.
We can determine if a 'let form has several expressions by defining two variants of a 'let form. An Arc2Let is composed of ( <maybe whitespace> let <whitespace> <expression> <expression> <expression> [many <expression>]), and that we have to transform to Arc2.7As (by filtering out the let expression using treeparse 'filt). An Arc2.7LetCompatible is composed of just (let <expression> <expression> <expression>), which we do not transform.
----
Of course, this does represent a veritable fork of the Arc code ^^.
I would leave with and withs alone, so that we have the option of the implicit do (also because it makes it easier to implement given/Anarki-let :P). And why not use a code-tree-walker if we want to do this—isn't that the point of Lisp?
Right, comments. Just a little important, aren't they? :P
You raise a good point... it's the same number of parentheses either way. But in that case, why not just have let and lets (as given(s)), and be done with it?
Edit: as an aside, given that pg has said that he'll modify Arc as if there's nobody else programming in it, and that he does not appear to be using Anarki, eventually when Arc3 does come around, it is very possible that Anarki will be incompatible with Arc3. We may very well need to build a converter program in the future to transform Arc2-base Anarki to Arc3-base Anarki, so my abstract nonsense may very well be necessary in the future.
The best thing to do is to install the Anarki version: it runs on all mzschemes and is more active, with a bunch of enhancements. It's a git repository that anyone can push to and pull from. More information here: http://arclanguage.org/item?id=4951
Thanks, it works great! Nice to be doing Arc again. Also, looks like the bug where it repeats all kinds of things is not from scheme or arc but is rlwrap and ssh fighting. Because if I drop either one, it works again. Not yet finished documenting the bug.
Thank you! That works wonderfully. It even saves readline history across (quit) and restart. The prompt shows up at different times now, but that seems cosmetic.
? I though I was the only one with that problem, and I hadn't realized that the readline was causing it. Unfortunately, I don't know enough about mzscheme to even know where to begin looking to fix it... I've seen it in other mzscheme things, though, so it's not just Arc.
Exactly! But let me try something. Okay, if I skip ssh that doesn't help at all. Readline moves the prompt like you described. Rlwrap does it, and so does the .arcshrc thing.
Funny thing is, debian's mzscheme + arc2.tar are fine, no problem at all. So it must be my mzscheme.
You yourself gave an example. The fact that Arc allows destructuring (that is, writing (let (a b) lst ...)) means that the presence of a list is not an adequate indicator of whether you're letting or withing. And without that, how do you know when you're done defining variables? If you don't parenthesize them, they could go on forever. The only other option is to remove the implicit do in let/with; that way, only the last statement would be run, and the first n would be variable bindings; to run more than one, you would use do.
let is a convenience for binding one variable; it allows you to leave out the parentheses of with. Do you need them both? No. But they're nice. (After all, you don't need either; both are equivalent to function calls.)
; in fact, that's often what I do. But being able to write snippets of Scheme can be important, if you need to work with things (for instance, datatypes like the boolean) which don't exist in Arc.
(mac $ body
" Allows access to the underlying Scheme. "
(list 'seval (cons 'quasiquote body)))
In other words, it generates a literal list containing 'quasiquote; when this is evaluated, it looks like (seval (quasiquote body0 body1 ... bodyN)). This technique is perfectly valid Arc2.
