I'll probably release a new version later this year. Most of the changes will be in news.arc, which is now pretty solid. Maybe I'll actually make an effort to make it installable without having to understand the source.
Graham cares about having a better programming language, but he doesn't really care enough to do what it takes to make it happen. (He has no obligation to do so, of course.)
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.
My goal from the beginning was to continue where JMC left off: to continue building Lisp up from axioms till I have a more complete language. I've compromised a bit to make it something runnable, which I think you need in order to test out your ideas on programs of substantial length. But "practical programming" is not in itself the main goal.
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.
Wasn't McCarthy working on a model that's more elegant than Turing machines?
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 believe his goal was a formal model of computation that was also good for expressing algorithms. Plus eval probably seemed like a neat trick. We take it for granted, but imagine how pleasing that must have been to think of.
I'm not trying to compete with Ruby and Python. If I were I'd be recruiting armies of people to write libraries.
I meant "compete" in terms of expressiveness. And actually that's not the only thing.
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.
If the language forces you to carry the compiler in your brain as you try to read code, it's a bad idea.
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.
A language that can express algorithms in few lines that are very cryptic (read: hard to read) is not very useful.
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]:
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.
Right, and I agree with that. I prefer = over define.
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))
This is the first thing in html.arc
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}
This is a lot clearer, without sacrificing conciseness:
def color(*args):
rgb_values = [limit(c, 0, 255) for c in args]
return dict(zip("rgb", rgb_values))
By simply getting the inlined list comprehension outside the dict expression, the whole thing becomes 10 times easier to read: "Ah, it's mapping 'rgb' characters to rgb values."
Lambda calculus is actually simpler than Turing machines. There are only two primitives: function definition and application. You can use that to express any computable function, including booleans, conditionals, integers, arithmetic, strings, etc.
"Axioms" has a nice, mathy ring of solidity to it, but I'm pretty sure that, along with the axioms you are analyzing there are others you are barely thinking about but which also form the foundation of Arc. For example, the notion of code and data being the same in Lisp: strings of text. Is that an axiom? That's certainly one of the keys to the unusual power and flexibility of Lisp. Yet text data these days is a very rich construct. A typical string might be an entry in a Thai-Japanese dictionary. To accommodate general text data for the next hundred years, you must use Unicode (axiomatic, whether you realize it or not), which implies that the code itself (being data) must be in Unicode, which has implications for the semantics of code and how you walk through a string-as-list "character by character". Are you planning to have macros? Of course you are, which means that macros will be designed based on the assumption that what they parse is Unicode. What implications does that assumption have for the design of macro syntax? I don't know, but if you start by designing macros on the basis of ASCII assumptions, your macros will become a mess when you eventually try to retrofit Unicode. Most languages don't have to deal with this, because code and data are assumed separate.
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.
No, it's not "just an implementation detail". I don't want to get into the details here, but your assumption that having your strings in one encoding composed conceptually of code points in a different encoding is not necessarily the way to go. I was on a JCP expert committee that rejected that option for Java, but that doesn't mean it couldn't end up best for Arc. It's just not as easy a decision as you imply. There are alternative approaches with different pros and cons, and since these abstractions all leak, you need to make a cross-implementation decision so that you don't end up with different coding practices on different platforms. Plus all the other issues that Unicode presents that make parsing a challenge that might have implications for a language that is famous for parsing and rewriting its own source at runtime.... These could all be worked out through a vigorous discussion process among a diverse group large enough to make sure that the implications of each approach are understood, but Graham doesn't work that way.
I've always had the impression that pg works on Arc as a hobby, a service to himself. If it's useful to other people, that's fantastic, but that's not why he's doing it.
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.
That is how he seems to work on it, but he talked as if it were so much more. Well, lots of us do that, and I'm not expressing any moral objection. Graham doesn't owe us anything. I'm making the practical observation that I don't think it can ever be a major language if developed this way.
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.
You don't need huge libraries and labyrinthine frameworks to be a 'useful' language. C is a perfectly good language with just the most basic standard library.
> C is a perfectly good language with just the most basic standard library.
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.
As much as I like pg's essays generally I don't particularly like his essays on hardcore programming topics like language design. Maybe it is because I am inexperienced in most of the topics he discusses in his essays but I am quite experienced in programming.
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.
One more thing, he discusses some details about strings, lists, hashtables, and representing numbers as lists.
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.))
Also, note that static and dynamic typing are not mutually exclusive (dynamic typing with optional static annotations is one very practical point in the continuum; inferred (i.e., few to no annotations) static typing is another), and static/dynamic typing are distinct from strong & weak typing. C is semi-weakly typed, because you can fake out the type system easily with casts.
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.
I am not against language research. For example there is one interesting research language, called 'Joy' which is the most concise of all languages I know and its simplicity inspires me. It is really fun. I just have no clue how I would write a 'usual' big business system in it because I did not develop my system development cognitive patterns on such an exotic language.
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.
Python is a better language than Java overall, but Java has some advantages over Python: because of static typing it is faster and has a very good IDE support. (autocomplete, code navigation, refactoring, etc...) In my eyes the most superior languages have static typing with a clever type inference, so that the code remains concise despite static typing. I like Scala because it really has the best of all worlds. (Although really mastering it is a bit more work than mastering Java or Python.)
make it installable without having to understand the source
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
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]]
nil
It 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 :/ ]
I've always been meaning to check it out, but the barrier of entry has been too high (likely due to my laziness). IMO: an installer would be a good idea, availability on aptitude would be the best.
Personally I have a hard time seeing what the goal for Arc would be. "100 year language" seems pretty fuzzy. I mean, Lisp is already at least a 100 year language IMO so what could Arc do to make itself more so? What is it going to do that the other two popular Lisp-1s don't? The only differentiator I've seen so far is pg's confusion of terse for concise [1].
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.
It probably has a positive correlation, but isn't an end in itself.
"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.
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.
Almost unrelatedly, any idea if there's a strong push for a more current, well-maintained .NET/mono version of Clojure, now that the JVM is going down in flames?
clojure is trying to bootstrap it self to be able to be on many platforms but for that we need
1. the proper primitives to make it possible (done in 1.2)
2. match java speed (working on it primitive types ...)
3. rewrite the data structures and compiler in clojure
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.
I'm playing around with it. Right now, my spare-time project is filling out the blogging software that came with the language. I am finding that it's a lot of fun to work with.
