My Language Is More Agile Than Yours: A Study of Arc

http://docs.google.com/Present?docid=dg93d8cv_68c2xw9jd5&skipauth=true

by mqt • 17 years ago

77 94 17 years ago

docs.google.com

axod2• 17 years ago

  >> printIfNotNull(foo.getBar().getName()); // pointless method

  >> in arc ...
  >> ... aif is a macro that expands this code to
  >>
  >>(let it ((foo 'bar) 'name)
  >>  (if it
  >>      (print it)))

Why is a macro not pointless, while a method/function apparently is? I don't think that makes sense personally. Surely a macro is just a function that's been inlined - which may be better, depending on if you're optimizing for speed or size. Anyone explain?

Also, I'm not sure if this was being serious or not:

  >> Priorities in language design
  >> A Language Should ...

If it was serious, it completely depends on what problem you're trying to solve as to what priorities you're going to have.

andreyf6• 17 years ago

Because aif works with any expression, not just print. Granted, in a functional language like JS, one could say:

    ifNotNull(foo.getBar().getName(), function (it) { print it; });

but "function (it)" and all of the "().{}" are still blub. As PG points out on the arclanguage forums [1], an even simpler way of putting it is:

    (only.print foo!bar!name)

Which, without the Arc-specific syntax sugar, is:

    ((only print) ((foo 'bar) 'name))

So "only" is a modifier that makes a verb (function) happen only if its argument is truthy (think Python decorators).

Note to PG: the dot operator is undocumented, and f.g.h.3 does not at all what I expect - looks like it does (f g h 3), whereas I expected (f (g (h 3))), in the spirit of Python decorators.

1. http://arclanguage.org/item?id=9350

axod2• 17 years ago

In js, if printIt is a function already defined, you don't need the function(it){}

ifNotNull(foo.getBar().getName(), printIt);

Granted, in java passing functions around is more of a pain.

pg• 17 years ago

    (def only (f)
      (fn args (if (car args) (apply f args))))

The . and ! operators got redefined so that x.y.z is ((x y) z) instead of (x y z). I think I posted the source on arclanguage.org.

hlidotbe• 17 years ago

That's what I was wondering too. Almost all examples use macro. And for this one the argument that you need a temp variable to avoid redundancy is kind of moot since his macro use one too (I'm not familiar with the syntax so I might be wrong)

utx00• 17 years ago

a macro can be pointless sure. mostly if the same thing can be accomplished with a function (most of the time, but not exactly). a macro is not a function that's being inlined.

sker• 17 years ago

Is this similar for all the dialects of Lisp? Because if it is, I might start learning one tonight.

Raphael_Amiard• 17 years ago

The macro definition abilities is mostly similar for most popular lisps around, Common Lisp, Scheme, Clojure

andreyf6• 17 years ago

I like the argument, especially using the word "blub" to describe the cruft that is inherent to the language, but I have to question how much it's preaching to the choir, and how much will penetrate people who don't already agree.

Maybe it's indicative of my crowd and not the community at large, but even the smartest people seem to hit up Haskell-for-fun and Python-in-practice over Arc. It's hard to call them blub-programmers, since they're genuinely curious, hard-working people...

klipt3• 17 years ago

Haskell isn't exactly blub; between the first class functions and the custom monads it's quite possible to create custom languages. E.g. the parsing library Parsec:

http://book.realworldhaskell.org/read/using-parsec.html

gaius2• 17 years ago

Haskell-for-fun and Python-in-practice

I am in exactly that camp, tho' I do fully intend to use Haskell for real once it becomes viable to do so. It's like the Python Paradox all over again.

patio11• 17 years ago

The point about string concatenation is, umm, I don't want to say "wrong" because wrong sounds argumentative so I think I'll pick a circumlocution like "contrary to fact" or "a bedtime story to scare CS101 students with, second only to 'use left shift instead of dividing by two, it is faster'".

Also in modern Java (and Ruby) projects you can typically write:

logger.debug("This is a stupidly expensive calculation: " + stupidlyExpensiveCalculation())

and it will get executed regardless and logged only if your logging settings, which are configured elsewhere and can be toggled with a mouseclick, are set to log the debug level.

Now, don't get me wrong, Arc's solution of defining a macro which checks to see whether your debug setting, which is defined elsewhere and can be toggled with a mouseclick, is on or not is a good idea. Its just not a revolutionary new idea for us wizened Big Freaking Enterprise App Ugly Language Programmers. Nor was it really that new in the halycon days of yore when Log4j crawled out of the primordial ooze.

gaius2• 17 years ago

We get this for free in Haskell.

klipt3• 17 years ago

Not exactly free ... laziness and the resulting thunks do use up extra processing time and memory. But in many cases it is a price worth paying.

http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html

smikhanov2• 17 years ago

Agree.

isDebugEnabled() method is used to scare people since 2001, probably around the time when it came out of common use.

Macro that is being used for exactly that is not a distinguishing feature of the language. Java proponents may come out with, say, accessing array in constant time (how many car/cdr pairs you need for that?)

Important is that neither of the described facts add something to the value of one language against another and usually serve only as a basis for speculation.

Edit: when I'm saying "went out of common use", I mean that elegant alternatives like

logger.log("Expensive calculation is going to be: {0}", objectWithExpensiveToStringMethod);

have emerged.

asmosoinio• 17 years ago

I am not sure if I understood you correctly, so let me check: Did you mean that stupidlyExpensiveCalculation() will be always executed, regardless if debugging is enabled?

Seems to me you say this like it's a good thing. Or I am misunderstanding...

TJensen• 17 years ago

The real problem is not the string concatenation, it is that stupidlyExpensiveCalculation() will evaluate, regardless of whether debugging is on or not (at least in Java, not sure about Ruby), since Java doesn't do lazy evaluation of arguments.

In this case, that just slows things down. Worse yet is when it is stupidCalculationWithSideEffects(). And I have seen that before. :(

stcredzero6• 17 years ago

The reason is that logger.debug(...) should really be

    logger.debug {
       ...
    }

Which can be done trivially in a language with convenient blocks/lambdas. Then the debugging expressions will not run at all with debugging disabled.

Yes, having a meta-syntax as your syntax is very useful.

matth2• 17 years ago

If it takes X characters to achieve something in language A, and X*4 to achieve the same thing in BLUB, I don't think this means BLUB is 4 times slower to develop in than A.

When I develop software, most of the big delays, and excuses for procrastination are in forcing my brain into action over the higher level concepts. I find a lot of the extra lines of code required when using BLUB can be written at high speed, with little "hurt" to the brain.

I'm not saying BLUB is just as fast to develop with, I'm just saying the benefit isn't as good as number of lines ratio good.

wglb2• 17 years ago

I wonder. If it were only limited to the ratio of time required to type it, maybe.

But I think during the writing of the program, you type the code, review the code, look at some other code, come back to that code, so you are writing/editing/modifying a particular piece of code multiple times.

I have a superstition that there is an element of polynomial effect on the size of the resulting program on the time to get it working or to parse code written by another person.

rgoddard• 17 years ago

For me, I have found that a more concise language is easier to think in and write in. I recently worked on an application that was implemented both on the web using mostly javascript and as a desktop application in VB.Net.

One of the more complicated features I waited to implement in the web version, just because I found it rather difficult to think of the problem in VB. The javascript code was just easier to write and think in, and once implemented I could translate it to VB.

Although I do not know if there is a limit to the benefits of moving to a smaller language. Also, this is just my personal experience and I do not know how much it generalizes to other people.

req22• 17 years ago

It's not in writing 40 lines that something like "blub" hurts, it's in reading it afterward. As long as you don't end up in Perl one liners, shorter code will tend to better highlight the relevant content (e.g., there are four keys that perform one of four things).

richcollins5• 17 years ago

Code generation isn't as powerful as late binding. Lisps would be more interesting if you could easily manipulate environments, and set the environment that functions are evaluated in. In this regard, Arc isn't as agile as some OO languages (Io for instance).

wglb2• 17 years ago

I am curious what you mean about "easily manipulate environments" for the functions to be evaluated in.

smikhanov2• 17 years ago

Probably, something similar to JavaScript's call() and apply() is meant here.

Though classical Lisps all have funcall and apply (not sure about Arc).

stcredzero6• 17 years ago

Does this mean that you can change the meanings of your language's "words" for specific "contexts?" (Context meaning the semantic thing, not a stack frame, though that could be the implementation.)

richcollins5• 17 years ago

Yes. The meaning of symbols within a closure can't change after creation. They are always bound to the same variable.

In Io, the meanings of symbols are determined when the block is activated.

pmjordan• 17 years ago

Clojure's vars can thread-locally, temporarily be re-bound, see

http://clojure.org/vars

and

http://clojure.org/api#binding

vlisivka• 17 years ago

Original blub code should look like that: frame.addKeyListener(new KeyListener() { public void keyTyped(KeyEvent event) { switch (event.getKeyChar()) { case 'j': drop(); break; case 'h': move(-1); break; case 'k': move(1); break; case 'u': rotate(); break; } }

      public void keyPressed(KeyEvent event) {
      }

      public void keyReleased(KeyEvent event) {
      }
    });

About Arc code:

    (on-key-press frame
      'u     (rotate-shape)
      'j     (drop-shape)
      'h     (move-shape -1)
      'k     (move-shape 1))

Is this code ADDS NEW key event handler OR OVERRIDES old one? When it is invoked - when key is PRESSED or when key is TYPED?

illumen3• 17 years ago

ah, events as function calls. How so terribly 50's.

here's a way where events are objects... rather than an invocation. Much more flexible.

a python + pygame example...

cu,

key_handlers= dict(u=rotate, j=drop, h=lambda : move(-1), k=lambda : move(-1))

buttons = {1:'u', 2:'j', 3:'h', 4:'k'}

for e in pygame.event.get(): if e.type == KEYDOWN: key_handlers[e.key]()

    elif e.type == JOYBUTTONDOWN:
        key_handlers[buttons[e.button]]()

    elif e.type in [QUIT, MOUSEBUTTONDOWN, HTTPD]:
        quit()

stcredzero6• 17 years ago

The grandparent code is much easier to understand.

10ren5• 17 years ago

Yes, most of the examples in the non-Arc language were written with artificial duplication, which obscures the actual advantages of Arc.

There's the `printIfNotNull(foo.getBar().getName()); // pointless method`, also pointed out by axon, and the following code being duplicated instead of being a function:

    if (log.isDebugEnabled()) {
      log.debug("foo.valueOf(expression) = " + 
        foo.valueOf(expression));
    }

BTW: heads up on your comment formatting: HN needs a blank line between text and code for 4-space indentation to be recognized.

moe• 17 years ago

I like this PG quote from slide 24 a lot:

   "One way to design a language is to just write down the program you'd
    like to be able to write, regardless of whether there is a compiler that
    can translate it or hardware that can run it."

Test driven really works, even for language development.

illumen3• 17 years ago

Can't do much without batteries.

silentbicycle9• 17 years ago

I think it's impossible to have any kind of meaningful conversation about language design when one side is just writing off everything they don't like as "blub". It's incredibly condescending, no better than people reflexively writing off Lisp users as "lisp weenies".

andreyf6• 17 years ago

Would it be as offensive to call the extra repetition that is inherent in some languages as "blub code", and languages like Arc trying to get rid of the blub(ber) in code?

silentbicycle9• 17 years ago

I'd lean toward avoiding "blub" entirely; it sounds like you're implying their code (and brain) is full of mush. You're probably making a face like a fish blowing bubbles while you say it. Be civil!

As novel as this may seem, most people who regularly program in languages other than Lisp also consider excessively verbose code to be a bad thing. (Hence the interest in refactoring.) If you're dealing with someone who just started programming a few months ago, they don't have enough experience to know why it's problematic, but then, they probably need someone to be patient and helpful, rather than smug.

You can say, "There are some things that are inherently hard to express in some languages that come naturally in others, and until you have experience with a couple different styles of languages, you'll only really know techniques used in your main language. Learning new languages adds new techniques to your problem solving toolkit. It takes a while, but it'll make you a much better programmer in the long run.", and it doesn't make you sound like you're sneering inside.

If you want to make the point that the way their language's object framework is designed makes any nontrivial program in it have a bunch of repetitive boilerplate, say that. Name-calling makes people defensive, not likely to consider new ideas.

Retric5• 17 years ago

Not all language cruft is created equil. I find the more more that happens within a line the easer it is to write but the harder it is to read.

x = (a = 7 * (b = 14)) + (c = 9 * ((d > 7)? e:f));

Now toss in some casts and the line becomes harder to read, but at the same time it's considered poor from to have 4 assignments on one line. Yet that's valid C, C++, Java, C# etc and it's got fewer symbols so it must be better according to the arc view of the world.

So is reqiring one assignment per line cruft or a good idea? How about those assignments? I would argue that one of the most useful mesures of a language is how easy it is to read other peoples code, but then you end up with something like Pascal...

PS: I acutaly like mantaining pascal code more than most languages then again it could have more to do with the experence of the people who use Pascal.

gcv• 17 years ago

The "blub" argument fairly applies just as much to Lisp as it does to, e.g., Java. For example, (any dialect of) Lisp is my blub language, as I understand Lisp quite well. I do not understand Haskell to anywhere near the same extent. I've tried to learn it several times, but monad transformers consistently make my eyes glaze over. I am perfectly comfortable admitting this, and I intend to try harder to understand programming language concepts with which I am unfamiliar, rather than write off Haskell advocates as condescending.

silentbicycle9• 17 years ago

I get what you're saying, but I think dropping the "blub" term would make everybody better off. Using "blub" intrinsically frames the conversation in terms of one language being "the stupid one used by the stupid people", and that's likely to be counterproductive. The word always has that baggage.

It's not a linear continuum, with some "most powerful language" at the top. Different styles of languages have different strong points and weak points.

bitwize• 17 years ago

I think monad transformers are starting to do Haskellers up in knots, especially when there are many types of computations you want to do which are by necessity monadic in Haskell.

I, for one, find uniqueness types to be an easier to understand and use solution to the problem of maintaining referential transparency in the face of a stateful universe.

req22• 17 years ago

Care to suggest a short term that has the same denotational meaning without the connotations you dislike?

DougBTX• 17 years ago

'cruft'

silentbicycle9• 17 years ago

As noted elsewhere in the thread:

"Boilerplate" has that meaning, but without the connotation that the person using it is automatically a moron. (http://en.wikipedia.org/wiki/Boilerplate_%28text%29)

See also: Simon Peyton-Jones's "Scrap Your Boilerplate" papers (http://research.microsoft.com/en-us/um/people/simonpj/papers...)

Tritis2• 17 years ago

Anything Arc does better than Clojure that would be enough to offset the benefit of running on the JVM and full java interop?

jimbokun• 17 years ago

A Clojure slogan could be "The Java De-Blubber!"

theoneill• 17 years ago

I believe it's called flensing.

MaysonL• 17 years ago

Did you notice the slide (#48) pointing to the Java implementation of Arc? I'm not sure how full the interop is yet, but it's a start.

http://github.com/conanite/rainbow/tree/master

sharkbrainguy• 17 years ago

it's built on plt-scheme so Tail Calls are optimised

10ren5• 17 years ago

Some other points of view here: http://www.reddit.com/r/programming/comments/8nuhn/my_langua...

psranga2• 17 years ago

A lot of the stuff presented here is mainstream practice in Tcl (e.g., new constructs, dbg evaluation). Tcl is seriously underappreciated language.

In my programming whenever I see myself writing blubber (I like that word), I just factor it out into a separate procedure and give it a descriptive name.

So when I'm reading the code of the calling routine, I rarely see blubber; it's contained in simple routines that are easy to read/verify.

Most of the examples here amount to thoughtful library development. With a good library, C++ and macro processor can also many of these things.

Here's a version of aif that works for most cases (I'm not claiming that C has the expressive power of Lisp):

    #define aif(expr, val, code...) \
      { if ((expr) != (val)) { \
          code ; \
        } \
      }

IMHO, this is good enough for blubber reduction.

dreish• 17 years ago

That's not aif at all. In fact, you can't even do it for "most cases" in C because you don't know what type expr will evaluate to, but if we could cheat and assume it will be an int:

  #define aif(expr, code)  \
     {                     \
     int it = (expr);      \
     if (it)               \
        {                  \
        code;              \
        }                  \
     }

But this is still not close because in a Lisp, if is an expression that returns a value. We can't use the ternary operator because then there's no place to declare the "it" variable. You can't have an expression that declares a variable local to that expression in C no matter how hard you try.

And the above lacks the "do {} while (0)" weirdness needed to make a cpp macro behave syntactically roughly like a function.

psranga2• 17 years ago

I agree. My bad. I appreciate the clarificaiton.

st3fan• 17 years ago

This presentation could have been about Clojure instead. Just s/Arc/Clojure/

stevedekorte• 17 years ago

From the slides, it looks like Arc dumps lots of short words in to one giant global namespace where they can easily collide with local names. Is this correct?

For example, it looks like Arc uses the "t" as a global true value. Is it really safe to assume "t" wouldn't be accidentally used as a local variable?

randallsquared• 17 years ago

Well, T has been the true value in Common Lisp, at least, and I don't remember it ever causing me a problem. Of course, in CL, you can shadow it in your own namespace, and that hasn't been possible in Arc without writing a namespace library first. :)

My Language Is More Agile Than Yours: A Study of Arc

Related Stories