SearchYC.com

When I look at something like

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

Plenty of examples here: http://arclanguage.com/item?id=722

Arc takes lisp in a new direction. The right thing to be doing now is not to get buried in details like foreign function interfaces but instead to see where pg's ideas lead. From what I can tell he's doing the same sort of thing Roger Hui and Arthur Whitney did when they took APL in the direction of J and Kx respectively - they let go of a few old things in order to make new ideas fit in better.

"$0" expands to the program name ("ar.sh" in his example).

${1+"$@"} is conditional:

if $1 (the first positional parameter) is unset it expands to nothing.

In OOP you instead solve your problem by trying to neatly partition it into lots of little bits of state and specifying how each little bit reacts to changes. As the comment explains, OOP programs are often clumsier than functional ones because OOP enshrines scaffolding in the form of the class hierarchy and method/message dispatch model.

So when is OOP a good idea?

I tend to think that it boils down to the size and organization of your team, the number of independent "architects" in your system and how they are managed.

In a small team this should not be an issue and you're probably better off with a functional approach and perhaps rolling your own messaging scheme like the one in the article if you think you need one.

However in a large team you not only have to deal with whatever problem you're working on, you also have to deal with the secondary problems of how the developers interact with each other. The OOP scaffolding pg makes fun of is one way to make managing a larger team easier since it helps the developers play nicely, stick to their little part of the system and stay out of each others way. It's not the only way, but it is relatively popular in part because it allows some management decisions to be directly expressed in the class hierarchy and programming language.

5. Object-oriented abstractions map neatly onto the domains of certain specific kinds of programs, like simulations and CAD systems.

Also for things like instance creation and method dispatch, OO languages can easily be both faster and more concise than functional languages. In a performance-sensitive setting like a desktop gui or a window system this can easily decide the issue.

But while simulation and OOP do have an important historic relationship, I don't believe you actually gain any special modeling expressiveness by making your objects adhere to a "class" framework. What's worse, the hardcoded assumptions OO languages make about classes and methods can confuse the assumptions in a simulation (e.g. because you can implement an "IS-A" relationship with inheritance doesn't mean you should).

If you want objects in a functional setting, you can just create the appropriate "factory" functions and have those functions return "objects" (i.e. functions with state in closures) which dispatch "methods" however you want them to, just like Jim Rankin did in the article at the top of the thread.

    foo:
        bar
        baz

    foo bar baz

    if (predicate):
        (then-instr)
        (else-instr)

    if (predicate) (then-instr) (else-instr)

    + 1:
        * x x
        * y y

    + 1 * x x * y y

Or alternately if the indented lines gain implicit parens shouldn't

     foo:
        bar
        baz

    foo (bar) (baz)

?