Arc Forumnew | comments | leaders | submit | bayareaguy's commentslogin
1 point by bayareaguy 5619 days ago | link | parent | on: Where are we going?

Judging from it's first year, I don't think Arc will follow the popularity paths of those other languages. It's more likely to go the way of Dylan.

-----

1 point by bayareaguy 5882 days ago | link | parent | on: Tagging

Reminds me of elisp, which looks for a top-level call to (interactive) in order to know if the function can be invoked "interactively" (i.e. via M-x or command-execute).

-----


This is the common sh shell idiom to properly pass the original command line to the program being invoked.

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

however if $1 is set, it expands to "$@", which in turn expands to all the parameters, each one quoted as a separate word.

-----

1 point by laughingboy 5883 days ago | link

Thank you.

-----


Do any lisp systems handle seralizing closures?

-----

4 points by absz 5884 days ago | link

Well, I know that Gambit-C, which is a Scheme dialect, (http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_P...) can; in fact, it can even serialize continuations.

-----

1 point by ryantmulligan 5882 days ago | link

I checked out Gambit-C but my question is, where is the community? It looks like it's just some guys research project, then some other researcher made Termite on top of it. It's community is either non-existent or in hiding, it would seem...

-----

1 point by absz 5881 days ago | link

That's a good question, and I have no idea--I just came across it because of Termite (which looks quite nice, by the way; those concurrency primitives [which are Erlang's, really] ought to be in Arc, but I digress). My point was really that it is technologically feasible to do so.

-----

1 point by ryantmulligan 5881 days ago | link

ah okay. You are saying it's possible to put this in Arc because it's in Gambit. Okay, sure. Gambit seems to be a much more performant implementation of scheme that Arc is striving to be. I think there is a lot to be said about serializing closures. Persistence is the nasty nasty dark secret of Computer Science. Our only tool that semi works is Relational Databases, but they aren't good for everything.

-----

1 point by CatDancer 5884 days ago | link

http://sisc-scheme.org/manual/html/ch05.html#SerialIO

-----

4 points by bayareaguy 5884 days ago | link | parent | on: Object Oriented Arc

In Arc (and most other functional languages), you generally solve your problem by specifying how to transform some input into some output. It should be no suprise to anyone here that this is a great fit for the most visible aspects of Web programming.

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.

Right now Arc doesn't look like a language for big teams, but perhaps with a good module system that could change.

-----

4 points by absz 5883 days ago | link

I do think you leave out an important class (no pun intended) of problems for which OOP is helpful. Simulation, windowing systems... these are modeled elegantly by using classes and objects. In other words, OOP seems to me to be a good fit when the problem you are trying to solve deals with objects. The problem lies in trying to coerce other problems into noun-land.

-----

4 points by bayareaguy 5883 days ago | link

I think pg agrees with you in http://paulgraham.com/noop.html when he writes:

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.

Personally I prefer the approach in SICP ( http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html... ).

-----

2 points by absz 5883 days ago | link

I've skimmed the SICP link, and that does look like a good method. But I don't think they're mutually exclusive. As Jonathan Rees points out (http://paulgraham.com/reesoo.html), the definition of OOP varies; having just inheritance (coughjavacough) does make that problematic. Ruby's mixins and duck typing allow "is-a" without inheritance, thus alleviating some of the complaints.

I think that describing certain things, e.g. a windowing system, in terms of classes and objects does result in a useful description. "My window contains a button and a text field" maps nicely to an OO model. The implementation can (perhaps should) be user-level and/or functional with closures, but that modeling system can be powerful.

And of course, some of this is "taste;" I can't think very well in a visual paradigm, but I love a symbolic one. OOP may be orthogonal to your mental processes, in which case don't use it.

-----

2 points by jimbokun 5883 days ago | link

"Personally I prefer the approach in SICP ( http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html.... )."

I was negligent in citing prior work. I had SICP in mind when I wrote my code.

The main differences are I wrapped it all up in a macro, I supported inheritance, and "method invocations" require one less set of parentheses:

    (define acc (make-account 100))
    ((acc 'withdraw) 50)
    50
    ((acc 'withdraw) 60)
    "Insufficient funds"
    ((acc 'deposit) 40)
    90
    ((acc 'withdraw) 60)
    30
I also didn't allow for initial arguments (yet). And you need to say "(vars 'varname)" to get values in method bodies instead of just "varname." I could probably fix both those things together.

But, generally speaking, the goal was to provide a macro for creating SICP style "objects."

-----

1 point by NickSmith 5883 days ago | link

Be interested to read your code Jim with your 'fixes'.

-----

4 points by bayareaguy 5887 days ago | link | parent | on: Musings on Language Design

I can sympathize with you somewhat. I like lisp but I'm not a deep lisper. Personally I'd would like it more if it could play nice with Python modules. But that sort of thing is not where the real Arc "action" is at the moment.

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.

The theme of this party is succinctness. Let's all see how well that works out. How low can you go?

-----


what language is that?

-----

1 point by mattknox 5885 days ago | link

LispNYC ( a lisp user group in New York ) has, in the last year or so, seen the debut of at least 3 lisps: otter by perry metzger, clojure by rich hickey, and nyclisp by me. Nyclisp is by far the least mature, but I'm trying to clean it up a bit for a release.

-----

1 point by bayareaguy 5887 days ago | link | parent | on: The Real Arc Challenge

Based on "Rewriting Reddit"[1], reddit switched from Lisp to Aaron Swartz's web.py.

It doesn't include much and is pretty small:

  powerbook.local 101> find webpy | xargs wc
      95     243    2326 webpy/experimental/pwt.py
     133     295    3662 webpy/experimental/untwisted.py
      27      65     419 webpy/README.tests
      17      42     460 webpy/setup.py
       0       0       0 webpy/test/__init__.py
       8      16     155 webpy/test/alltests.py
      90     188    2458 webpy/test/db.py
      10      27     275 webpy/test/doctests.py
      16      54     538 webpy/test/form.py
      58     149    1668 webpy/test/webtest.py
      81     213    2608 webpy/tools/_makedoc.py
     677    2170   22981 webpy/tools/markdown.py
      62     141    1307 webpy/web/__init__.py
      98     345    3364 webpy/web/cheetah.py
     724    2285   21731 webpy/web/db.py
     357    1116   12084 webpy/web/debugerror.py
     215     689    6742 webpy/web/form.py
     279     869    8368 webpy/web/http.py
     224     612    8548 webpy/web/httpserver.py
     169     479    4427 webpy/web/net.py
     153     621    5532 webpy/web/request.py
     895    2623   25482 webpy/web/template.py
     888    2560   24743 webpy/web/utils.py
     377    1188   10713 webpy/web/webapi.py
      54     155    1580 webpy/web/wsgi.py
    1019    3963   40392 webpy/web/wsgiserver/__init__.py
      25     225    1542 webpy/web/wsgiserver/LICENSE.txt
    6751   21333  214105 total

[1] http://www.aaronsw.com/weblog/rewritingreddit

-----

1 point by bayareaguy 5888 days ago | link | parent | on: picoLisp - arc before arc

The database abstractions described on the "Pico Lisp Application Development" page

http://www.software-lab.de/ref.html#dbase

are interesting but seem to preclude the use of an alternate persistence layer (e.g. a sql dbms or some other scheme).

-----

2 points by kjk 5888 days ago | link

I don't see why. Using built-in database is optional. picoLisp can read/write files so there's nothing stopping you from serializing the structures to file (like Python's picle) or adding a module to query a database.

Although I think that for many cases where you would use serialization to a file or store small amounts of data in sqlite, using built-in object database integrated with the language would be a better solution.

-----

1 point by bayareaguy 5887 days ago | link

My point wasn't that picoLisp was in any way stopping you from using a separate database, it was that if you go the route of using the built-in abstractions listed on that page you won't find any out-of-the-box interoperability with any existing SQL database. You'll have to roll your own.

That's too bad because I think using the picoLisp database as a cache backed by a SQL database makes a lot of sense.

-----

1 point by bayareaguy 5889 days ago | link | parent | on: Two brief ideas

Even since this started to work, I still prefer some_dict.has_key("username") because then if an ordinary string accidently found its way into some_dict I'd get a runtime error instead of a silent logic bug.

-----

More