What's happening with Arc? • Hacker News Board

Re: What's happening with Arc?

#41

Post by hasenj » Tue, Oct 26, 2010, 7:04 PM UTC

pg wrote: post #35

hasenj wrote: post #32

Earlier quoted context omitted.

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…

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.

[1]: http://www.artima.com/intv/ruby2.html

Re: What's happening with Arc?

#42

Post by nadam » Tue, Oct 26, 2010, 7:05 PM UTC

pg wrote: post #38

nadam wrote: post #17

Earlier quoted context omitted.

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…

"What pg speaks about is some kind of utopia." 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.

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.

http://en.wikipedia.org/wiki/Joy_(programming_language)

Re: What's happening with Arc?

#43

Post by evanrmurphy » Tue, Oct 26, 2010, 10:01 PM UTC

hasenj wrote: post #41

pg wrote: post #35

Earlier quoted context omitted.

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…

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]:

  (defop said req
    (aform [w/link (pr "you said: " (arg _ "foo"))
             (pr "click here")]
      (input "foo")
      (submit)))

What would you prefer that it looked like? If you replaced all the abbreviated names with long descriptive ones, you'd have something like:

  (define-operator said request
    (html-anaphoric-form
      [html-with-link 
        (print "you said: " (argument _ "foo"))
        (print "click here")]
      (html-input "foo")
      (html-submit)))

---

[1] http://arclanguage.org/item?id=722

Re: What's happening with Arc?

#44

Post by [deleted] » Tue, Oct 26, 2010, 10:08 PM UTC

evanrmurphy wrote: post #43

hasenj wrote: post #41

Earlier quoted context omitted.

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…

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 learni…

[deleted]

Re: What's happening with Arc?

#45

Post by [deleted] » Tue, Oct 26, 2010, 10:11 PM UTC

hasenj wrote: post #41

pg wrote: post #35

Earlier quoted context omitted.

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…

[deleted]

Re: What's happening with Arc?

#46

Post by SiVal » Tue, Oct 26, 2010, 10:21 PM UTC

pg wrote: post #30

SiVal wrote: post #11

Earlier quoted context omitted.

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 s…

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 lang…

"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.

Re: What's happening with Arc?

#47

Post by olalonde » Tue, Oct 26, 2010, 11:51 PM UTC

silentbicycle wrote: post #24

olalonde wrote: post #19

Wasn't Arc meant to be a toy/academic language?

Wasn't Unix written to play Space Travel ( http://www.courses.fas.harvard.edu/~lib215/reference/history... )?

It wasn't a genuine question, no rhetoric meant.

Re: What's happening with Arc?

#48

Post by hasenj » Wed, Oct 27, 2010, 1:57 AM UTC

evanrmurphy wrote: post #43

hasenj wrote: post #41

Earlier quoted context omitted.

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…

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 learni…

I despite long names in JavaLibrariesAndFrameWorks but I don't appreciate tla aop (three letter acronyms all over the place).

Your second code snippet is actually much more pleasant to read.

Re: What's happening with Arc?

#49

Post by evanrmurphy » Wed, Oct 27, 2010, 4:20 AM UTC

hasenj wrote: post #48

evanrmurphy wrote: post #43

Earlier quoted context omitted.

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 learni…

I despite long names in JavaLibrariesAndFrameWorks but I don't appreciate tla aop (three letter acronyms all over the place). Your second code snippet is actually much more pleasant to read.

Sure, it's subjective. :)

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.

Re: What's happening with Arc?

#50

Post by hasenj » Wed, Oct 27, 2010, 9:01 AM UTC

evanrmurphy wrote: post #49

hasenj wrote: post #48

Earlier quoted context omitted.

I despite long names in JavaLibrariesAndFrameWorks but I don't appreciate tla aop (three letter acronyms all over the place). Your second code snippet is actually much more pleasant to read.

Sure, it's subjective. :) 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 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  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."