What's happening with Arc?
stackoverflow.com
stackoverflow.com
I think there is always more room for programming languages in the world, especially given how awful most of them are. I just think they need some clear reason to exist or their creation isn't worth the fracturing effect [2].
[1] Personally I use terse to mean "short and unreadable" and concise to mean "short and more readable" (think: "I didn't have time to write a short letter..."). The first thing that occurred to me when I saw Arc was "oh man, a bunch of cryptic one or two letter functions. Is this meant to be programmed over a 1200 baud modem or something?" Every one of those kinds of things is something that has to be memorized, and given how much more advanced IDEs are today what's lost in readability is not made up in typing savings. For me the classic example of "concisity" is Smalltalk. Most methods are just a line or two, they read almost literally as English yet so much is said with so little. No meaningless cryptic two letter sequences but yet one line is equivalent to at least 3 lines of Java [3].
[2] I.e. users becoming party of a community of this new mostly irrelevant language A instead of helping the community of the language that would have been said to obsolete A if it had been written after A instead of before it.
[3] http://www.cincomsmalltalk.com/blog/blogView?showComments=tr...
Short is not always good.
"Short" languages typically have a programming model which makes common coding tasks implicit: ML (and other languages with type inference) make most type annotations implicit, pattern-matching languages (Erlang, Prolog, ML, Haskell, awk) make a lot of de-structuring and switching code implicit, APL dialects (APL, J, K/Q, etc.) make looping implicit, concatenative languages (i.e. Forth, Joy, Factor) and tacit / "points-free" languages (Haskell and J, again) make variables and dataflow implicit, constraint and/or logic languages (Prolog, Mercury, Oz) make search implicit, etc.
It's often a net win, but some problems inevitably clash with their model - it seems important to have some kind of escape built into the language.
Practical programming languages these days aren't just ways of expressing "algorithms," but toolkits for marshalling the vast information processing resources around the world (people, libraries, net protocols, platforms from microcontroller to supercluster, communications systems, etc.) The number of issues is enormous and growing. Useful programming languages have to have a whole army of specialists who provide feedback and code dealing with security, internationalization, performance, accessibility, net protocols, commercial-grade GUI wrapper/frameworks, installers, compilers/runtimes for countless platforms, scientific computing, embedded/realtime computing, frameworks of all sorts, dev tools.... Many of these things will be done poorly, if at all, if not accounted for in the design of the foundations of the language. That's the reason for the serious warts on all popular languages and the desire of many for something better designed.
Yet Graham's approach is, as always, to work privately, get feedback from the same half-dozen friends, then make announcements on a "when we have something to announce, I'll announce it, so don't bother asking" schedule. If none of his friends knows enough about international coding issues, for example, to even realize how little they know about text (something more important to Lisp than to most languages), then he'll make a silly architectural decision regarding Unicode, which he'll announce to, not discuss with, the rest of the world. Hey, if my friends don't seem concerned by it, it can't be very important, right?
This is too bad. Few languages have the potential Lisp has for creating flexible, evolvable code that can rapidly adapt to the changing world. Yes, I do think that the language matters, but it's the whole platform, not just the syntax.
But I don't think you can create a successful, practical, general purpose language these days without an army of specialist volunteers behind you. Graham's message to specialist volunteers is "go away, you're not the people whose opinions I care about," so I think the language WILL last 100 years--in approximately its current form.
Paradoxical as it sounds, that may be the way to end up with the best language for practical programming. It worked for McCarthy, and I think there's more juice yet to be squeezed out of this orange.
As far as axioms go, you can't get simpler than the Turing machine: it doesn't even have a notion of a variable, let alone types or strings.
I don't know about the history of Lisp other from what I've read from you, but it seems what McCarthy was working on was a more elegant model, rather than an "axiomatically pure" model.
Arc on the other hand, is trying to compete with Ruby and Python.
I'm not trying to compete with Ruby and Python. If I were I'd be recruiting armies of people to write libraries.
A language that can express algorithms in few lines that are very cryptic (read: hard to read) is not very useful.
I think were python hit the mark spot on is the adoption of the idea that "programs should be written for people to read, and only incidentally for machines to execute".
And where ruby hit it spot on is "optimizing for happiness", I particularly like Matz's his idea about "harmony"[1].
Matz> I believe consistency and orthogonality are tools of design, not the primary goal in design.
One of the things that annoy me about lisp as a beginner, and maybe this only because I'm a beginner, is that I always have to manually compile code into the syntax tree.
Part of Arc's design philosophy is to never inconvenience advanced users in order to serve novice ones. Long, descriptive names help people unfamiliar with a language's operators better understand what they do, but the length can become a burden once they do know.
For example, when I first started learning Arc, it would have saved me some headache if afn had been named anaphoric-function. Now I would find that a real nuisance. I love being able to invoke such a powerful abstraction with just three keystrokes.
Here's an interesting exercise. This is the given solution to the Arc Challenge [1]:
(defop said req
(aform [w/link (pr "you said: " (arg _ "foo"))
(pr "click here")]
(input "foo")
(submit)))
(define-operator said request
(html-anaphoric-form
[html-with-link
(print "you said: " (argument _ "foo"))
(print "click here")]
(html-input "foo")
(html-submit)))
Your second code snippet is actually much more pleasant to read.
I forgot to mention though that the idea is to use the shortest names possible for the core language operators. That's when they're the biggest win, since you'll learn those well enough not to need descriptive names, and they cut program length more substantially since they're used so often.
The problem comes when everything is "inlined".
(def color (r g b)
(with (c (table)
f (fn (x) (if (< x 0) 0 (> x 255) 255 x)))
(= (c 'r) (f r) (c 'g) (f g) (c 'b) (f b))
c))
I can't make sense of it, it's way too terse.
This is probably why python doesn't have a proper lambda expression.
EDIT:
After some pondering, I see what it does ..
An equally terse implementation in python:
def limit(n, lower, upper):
if n < lower: return lower
if n > upper: return upper
return n
def color(*args):
return dict(zip("rgb", [limit(c, 0, 255) for c in args]))
>>> color(10, 20, 30)
{'r': 10, 'b': 30, 'g': 20}
def color(*args):
rgb_values = [limit(c, 0, 255) for c in args]
return dict(zip("rgb", rgb_values))
I don't know how Lisp-style strings-as-lists should be designed when the strings are Unicode, and how, therefore, macros should be designed, but it seems pretty darned fundamental, not something to tack on later. And this is just the first example that comes to mind. Fundamental decisions have implications for ease of learning the language, ease of evolving code, for performance, for ability to run in parallel, for difficulty of implementation, for portability, for security, and for so many issues that I'm not even aware of, all of which have implications for one another.
No group of half-dozen friends, no matter how smart, knows enough to get these axioms right. Too many lessons have been learned by the rest of the world to ignore what they've found and hope to do well by reasoning from some incomplete set of first principles.
Of course, if you're just trying to solve a fun math problem by eliminating the parts of the real world you don't feel like thinking about, then fine. Those of us who need real tools will look elsewhere. You can publish the solution to your math puzzle. You may just not have the time or inclination to do more, and who could blame you? You're obviously very busy. But if it is intended as a tool for real programming, then carefully designing only the parts you care about will produce yet another mess of poorly integrated retrofits and kludges as the lessons long learned by the rest of the world (post-McCarthy) are belatedly rediscovered. Without project management that includes leveraging the expertise of a large community, Arc probably won't be usable as anything more than a source of ideas for the real 100-year language.
UTF-8 is just one of the possible encodings of such list. It can be decoded and converted to UTF-32 before it goes to the reader/lexer.
It's like writing music for yourself. Of course you want to share it, it people like it and it's meaningful to them, you've done a good deed for the day, but otherwise it's done just to help stoke the fires within.
(pg correct me if I'm wrong)
Graham has spent nearly a decade now tinkering with syntax. I think he'd say that he's trying to get the foundation correct, and all the rest can come after that. But I'm saying that, as much as I like his syntax ideas, there is more to the foundation than syntax, that the other issues will inevitably have implications for the basic design, even for the syntax, that his half-dozen friends don't know enough to fully inform him of the state of the art in these issues, and that his lack of interest in enlisting the help of the rest of the world in the foundational issues is likely to render the Arc Project a mere exploration of syntactic tweaks to Lisp, not a major new language.
Unless you want to write cross-platform networking code. But in that case C is an excellent language for writing networking libraries for your favorite scripting languages.
I'd argue that nowadays C is used more to implement other languages than it is by itself.
Even the really old Unix books recommend piping together small C utilities and stuff written in awk, sh, etc.
Some reactions to the essay:
"I predict a similar fate for Java"
It is ridiculous that pg once said he does not know Java at all. Yet he expresses his opinions about it. How can I take his opinion seriously as someone who knows almost the whole language specification of Java by head and had been programming in Java for at least 9 years? It is not only knowing the language which is important. But knowing all those problem patterns that have to be solved at typical enterprise projects. These projects are inherently complicated and has a lot to do with databases (and less with expressing nice and elegant algorithms). Java is not a particularly good language, but without developing a lot for in enterprise projects you really don't know what is needed by those projects. That said my favourite language is Scala. It ihas all the advantages of Java and the Java platform but it is a much better language than Java. It is not a 'pure' language. Pure languages never really do well for widespread practical use.
"I think it's important not just that the axioms be well chosen, but that there be few of them. Mathematicians have always felt this way about axioms-- the fewer, the better-- and I think they're onto something."
First the core language in mathematics (the language of first order logic) is orthogonal to axioms. You can have a language with simple syntax (some math books define such a minimalistic language for first order logic), but it will not be good for practical use and will not be concise. So for practical use and for conciseness mathematicians have introduced plently of notations. (e.g. typographical conventions for differentiation, integration, infix syntax for addition, multiplication, etc...), etc. The real-world language that mathematicians use day-to-day is more like let's say Scala than a very pure language.
Axioms (and theorems derived from them) are more like libraries. There are plenty of axiom systems: (separate for numbers, geomerty, etc...) The whole mathematics is something like the Java ecosystem: lots of libraries.
What pg speaks about is some kind of utopia. A world where all programmers have to do is to express elegant algorithms. But programmers have to solve complex problems which mostly don't have an elegant solution at all. 100 years later we will still not have incredibly elegant solutions for our then hard problems. Even mathematicians don't always have elegant minimalistic solutions for their problems. Andrew Wiles worked for 10 years to prove his theorem. The proof is the result of lots of work and knowledge, and is incredibly complex. It does not fit on the margin at all.
Just look at natural languages: they are incredibly useful and concise in some sense, but they are incredibly complex. Programming languages will never be so complex, but they will not necessarily be extremely simple either.
Edit: I love minimalism, and I hate convoluted overcomplicated libraries and code bases, and I hate very leaky abstractions. The smaller the code base is the better: this is my main philosophy. But I still think that pg goes too far with his utopia for simplicity. I think that simplicity and conciseness of application code requires some complexity and intricacy on the core language and libraries side.
More of a limit. By historical standards you're approaching it fairly rapidly. A couple decades ago you might have been using Cobol.
Someone has to work on the stuff at the limit, in order to generate the ideas that the "real world" stuff copies.
These are in fact not deep language design topics. Most of what he discusses are not core features of 'serious' languages in 2010: they are already mostly library stuff.
For example let's take Scala. Treating strings as lists? Create a Seq descendant string class, and create implicit conversion from the normal String to it (and vica versa): and you can use it in scala.
Arrays as Hashtables? The syntax is already the same in Scala, they even have common traits (kind of interfaces).
Numbers as lists? Also library implementation detail. Create a Seq based number class and define implicit conversion for it, and you are done. Defining operator behaviour for these 'numbers' is possible in Scala.
The deeper questions are in my opinion: static vs. dynamic. typing. In case of static typing the question is what kind of type system we have?(Scala's is complex but powerful.) What kind of type inference we have? How felxible/convenient the syntax is? Does object orientation makes sense, what kind of (multiple) inheritence we support? Purely functional or enable imperative programming style? (Imperative programming is not just how the computer 'thinks', it is a 'natural' description of some concepts. (Like an instruction manual.))
Basically, static vs dynamic is about how early types can be decided, strong vs. weak is about how strictly they're enforced. People have been mixing the terms up for a while though, even in type system papers, which adds lots of confusion.
For a really good tour of language design issues, check out CTM (http://www.info.ucl.ac.be/~pvr/book.html) or EoPL (http://www.cs.indiana.edu/eip/eopl.htm). I've also heard good things about PLP (http://www.cs.rochester.edu/~scott/pragmatics/), but haven't read it yet.
I prefer a utopia where we don't need to write horrible complicated enterprise applications. They're not fun anyway.
The enterprises don't have a clue what they need anyway, I bet python can replace Java in all enterprise applications and do a better job, but the managers are too thick headed to accept anything unless it's mainstream and backed by a mega corporation.
On the other hand, python is so pleasant you can develop big applications without any IDE support, just good old vim with ctrl-p word completion.
I wouldn't say that understanding Arc's source is a prerequisite for installation. The problem is more just that the instructions are complex [1].
It would probably help if they were updated to let people know that with arc3.1, you don't have to worry about installing version 372 of MzScheme [2]. (Unless there's some reason why you'd prefer people installed arc3.0.) Navigating their website to download the specific old version of MzScheme is especially confusing since they rebranded as Racket.
This reduces the install and run to (on Ubuntu 10.04):
$ sudo aptitude install mzscheme
$ wget http://ycombinator.com/arc/arc3.1.tar
$ tar -xvf arc3.1.tar
$ cd arc3.1
$ mzscheme -f as.scm
Usage examples:
arc> help.acons
[fn] (acons x)
Determines if `x' is a `cons' cell or list.
Unlike 'alist, this function will return nil if given an empty list
See also [[atom]] [[alist]] [[dotted]] [[isa]] [[cons]] [[list]]
nil
arc> help.alist
[fn] (alist x)
Return true if argument is a possibly empty list
Unlike 'acons, this function returns t when given an empty list
See also [[atom]] [[acons]] [[dotted]] [[isa]] [[cons]] [[list]]
nil
arc> help.afn
[mac] (afn parms . body)
Creates a function which calls itself with the name `self'.
See also [[fn]] [[rfn]] [[aif]] [[awhen]] [[aand]]
nilIt needs a big GET ARC button at the bottom though. Linking either to the canonical install page on arclanguage.org or the community anarki git repo. The decision is yours as to which one, no pressure ;)
[ The site is an amazing piece of advertising, but it's not closing the sale :/ ]
In particular, I've been playing with Clojure and enjoying that. It's still a Lisp, so it has a lot of the advantages that Arc has. In addition, it has some cool unique features and almost certainly has more comprehensive libraries thanks to being able to use Java libraries. What advantages does Arc have over Clojure?
I'm not trying to be mean to Arc lovers and call it a useless language. I genuinely want an excuse to give Arc a try.
It has nothing to do with Oracle's Java and vice versa.
If that doesn't seem like much of an advantage to you, you're probably right, and it isn't, and godspeed. There is no pressing need to learn Arc today. (I haven't yet, myself, though not for lack of ambition.) Arc will still be there, still unconnected to anything Java, in five years; we'll see how it feels then.
Thats the plan to let clojure fly.
As for CLR the implementation is pretty good and there is a binary but there wont be a strong push.
Btw. i do not belive that the jvm is going down in flames. Thats typical trollhyping.