Hacker News Reader

Comment by andreyf | Hacker News Reader

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

View on HN

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

http://arclanguage.org/item?id=9219

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.

Yep, a lot of the features mentioned in the presentation are possible with just first class functions, although the syntax will be messier (but arguably more consistent).

The strength and danger of macros is in allowing you to create new syntax, skipping all the extra blub that made your code conform (consistently) to the original parser. What I'd like to know though is how much humans depend on that blub.

It's one thing to write your own macros and use them consistently, or even for a group of people to come up with macros and use them consistently. But if people work independently, what happens when you read someone else's code and find they've come up with macros to do the same things as yours do, but with different names and different usage conventions?

Wouldn't that be a bit like having every scientist invent their own jargon?

Either humans can learn to translate that kind of thing on the fly, or they can't, and lisp with heavy macro usage will only ever be useful as a solo (or small group) language.

Wouldn't that be a bit like having every scientist invent their own jargon?

I don't know about "all scientists", but mathematicians do precisely this all the time! Each paper and each textbook begins by defining what symbols mean what, and which terms are used how. But a textbook is about as big a consistent block of terminology as you'll be able to find. In a grander sense, terms are constantly re-purposed and evolving over time [1].

Something as simple as "⊂" will mean "subset" in one book, and "strict subset" in another. In my experience, the older the book, the more divergent it'll be from current usage. This suggests that the language of mathematics evolves over time, precisely because every practitioner can change the language and push for her own terminology. There is no "Mathematics corporation" which creates languages people would be forced to choose from - no mathematician, no matter how great, would suggest that he would know what the "eternally right way" of expressing mathematics is.

This is especially apparent in more exploratory parts, where definitions start being named after their authors. I, personally, look forward to a time when I get to choose between a Norvig-garbage-collection and Graham-garbage-collection for each object in my code.

We're in this ridiculous stage of software engineering, where, if you're using Java, you have to do garbage collection The Java Way (you get to set a couple of settings, but that's it). No mathematician would ever be forced to make the decisions that Sun's engineers were forced to make when designing Java, because nobody could make those decisions correctly - how programs must interact with the call stack, the mechanics of method invocation, etc.

1. "Compactification" comes to mind as an example: http://en.wikipedia.org/wiki/Compactification_%28mathematics...

what happens when you read someone else's code and find they've come up with macros to do the same things as yours do, but with different names and different usage conventions? Wouldn't that be a bit like having every scientist invent their own jargon?

You can replace the word "macros" with "functions" and your point would be the same. Consistency in naming and usage is part of good programming, but the point is orthogonal to macros.

Edit: actually, it's not orthogonal: macros make it easier to be consistent because they let you write less code, so there's less code to contradict itself.

macros can introduce new syntax, functions do not.

So? If you don't understand what a function does, you read it; if you don't understand what a macro does, you read it. This whole "macros make new syntax so they make code unintelligible" thing is an argument made by the ignorant, for the ignorant.

The vast majority of Lisp macros don't create new syntax anyway. They integrate seamlessly into the s-expression format. That way they blend in nicely with the rest of a program and it's easy to write other macros on top of them. An experienced Lisp programmer would only introduce new syntax when there is a big win in clarity - big enough to justify breaking with the surrounding structure and certainly big enough to make the above objection pointless.

By the way, one of the real problems with Lisp macros is that it can be hard to tell a macro call apart from a function call. (Various techniques have been developed to deal with this, such as indentation and naming conventions.) If macros were so syntactically convoluting this would hardly be an issue.

For the toy example, sure. But as soon as the example gets at all more complicated, you'll need to throw the function(it){} back in.

Also, it's worthwhile to remember that aif does a bit more - it's semantically the equivalent of cond, which sometimes eliminates a ton of if/else blub.

https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expre...

New in 1.8 you can omit the return and curly braces. So at least a little improvement!

Reply on news.ycombinator.com