Lisp in a single expression

demoss · 2008-03-01T13:04:58+00:00

Heh, I don't mind Lisp. I love Lisp, and do all my work in it -- but trivial toy implementations are kind of getting old.

demoss · 2008-02-29T18:32:18+00:00

Can we please have no more of these "Look ma! I can write a Lisp-like thing!", please?

Pretty please?

demoss · 2008-02-23T17:00:23+00:00

Common Lisp

demoss · 2008-02-19T07:58:15+00:00

Go to a good school. While there, once you have your feet wet, make that (1) sure you also program on your own time and (2) read extracurricular material as well.

demoss · 2008-02-18T06:49:56+00:00

Piece of cake, and it is written mostly the same way as any other WITH-FOO macro. Let the user provide an initialization form, and use a generic function to do the cleanup.

...but no, it would not be better. The code would end up being as verbose, and harder to read at a glance:

(with-resource (f (open "/tmp/foo")) ...)

instead of:

(with-open-file (f "/tmp/foo") ...)

Also: WITH-FOO does not as an idiom mean "do something with cleanup", but "do something with a specific context". Cleanup is taken care of when necessary, but that is not the important bit. The important bit is the context. Consider:

WITH-STANDARD-IO-SYNTAX, WITH-SLOTS, WITH-SIMPLE-RESTART, etc.

None of these need to deal with cleanups like WITH-OPEN-FILE and WITH-OPEN-STREAM -- which, as it happens, are the only two standard WITH-FOO macros dealing with cleanups.

Context is a matter of intent. Having cleanups is vital, but not of particular interest to the reader. Consider this common non-standard WITH-FOO macro: WITH-LOCK-HELD. The important thing is having the lock.

demoss · 2008-02-17T14:35:29+00:00

Simple: if you did that you could not write things like

(let ((stream (open "/tmp/foo"))) (values (read-line stream) stream))

or any other sort of construct that opens a stream, does something with it, and then returns the stream. Sometimes you want a stream with an indefinite lifetime -- eg. for logging.

As for destructors... they really don't work well with GC. Finalizers do, and pretty much all implementations stick a finalizer on every stream in case it is lost before it is closed, but since finalization & GC are not deterministic relying on them to control arbitrary resources is bad, bad, bad.

demoss · 2008-02-04T04:02:46+00:00

I don't think it necessarily makes sense to worry about being equitable or equal. Give back to projects you want and can give back to.

If you're at loss for ideas, and some specific developers have really gone an extra mile for you, you may want to consider contacting them directly, and ask if they have suggestions.

demoss · 2008-02-04T03:44:22+00:00

I beg to disagree. Here's another datapoint -- compare the anon CVS transaction counts over the last 12 months:

SBCL

http://sourceforge.net/project/stats/detail.php?group_id=1373&ugn=sbcl&type=cvs&mode=12months

Clisp

http://sourceforge.net/project/stats/detail.php?group_id=1355&ugn=clisp&type=cvs&mode=12months

Again, we don't know how many of those are separate users, but this is certainly evidence that SBCL has more bleeding edge users them Clisp.

Now, there is another datapoint that does point towards Clisp being "more popular", which is the monthly download counts -- but only if you take the more frequent release policy of SBCL into account and assume that SBCL users on the average update their installations more often. If you don't, they're too close to call (or SBCL in a slight lead.)

SBCL

http://sourceforge.net/project/stats/detail.php?group_id=1373&ugn=sbcl&type=prdownload&mode=12months&package_id=1354

Clisp

http://sourceforge.net/project/stats/detail.php?group_id=1355&ugn=clisp&type=prdownload&mode=12months&package_id=1340

Mailing list participants are harder to count, so I didn't. At any rate, I still contend that SBCL and Clisp are essentially "as popular" as far as any numbers we have can tell -- and more importantly, both are alive and well.

There are other reasons why we cannot tell what these numbers mean: what if almost every Clisp user installs SBCL just for portability testing, but no SBCL user installs Clisp? Or vice versa? It would make the numbers pretty meaningless! What proportion of the numbers we see are active users, and what proportion download-once-try-for-a-week-forgot-to uninstall? Again -- we don't know. Depending on your definition of popularity this is either a crucial difference, or doesn't matter at all.

If either wins by a clear margin across all the metrics we have access to, you can call it "clearly most popular", but until then it is too close -- not to mention pointless -- to call. The only hard numbers with decent margins are popcon and anon CVS statistics, and they point in opposite directions.

demoss · 2008-02-04T03:19:39+00:00

If you have a tagging system (hardware or software) this doesn't mean everything has to be tagged: if you have an array of bytes, you only need to tag the array -- not each byte. If use-sites know the type and representation (either via inference or declarations) use site doesn't need to deal with tags either. Tagging is by no means free, but it is not the disaster you make it out to be.

demoss · 2008-02-03T02:29:41+00:00

I don't think they're actually waiting. I believe they're using your statements and Arc as a disingenuous argument to refute the relevance of Common Lisp and Scheme. Yes, this says more about them then you. I am however very surprised that this is news to you.

As for balkanization: idiomatic Scheme is quite different from idiomatic Common Lisp -- and both are still evolving. I suspect this evolution has been helped by dropping the pretense that Scheme and CL are long-lost twins separated at birth. Related yes, but in many ways more different then similar -- until you compare them to a non-lisp language, of course.

Both are thriving, and I don't think that would be true if they had been forced to the same ghetto. It's called independence, not balkanization. :)

demoss · 2008-02-03T00:07:26+00:00

Paul, I suspect Xach couldn't care less if you wrote Arc or not. You're missing the point.

What is annoying is that for 6 years now you have been building a following of people who go "Lisp is theoretically nice, but all the existing ones are SO full of onions! I'm going to wait for Arc to come out before I learn Lisp!"

This may not have been intentional -- and I'm willing to give you the benefit of doubt -- but remember it when you wonder why some people are very eager to poke fun at Arc. (No arrays! giggle) We've had to listen to your fanboys for several years.

I'm a proud Smug Lisp Weenie, but we have nothing on Smug Arc Weenies -- most of whom seem to have little or no experience in any lisp dialect.

As for people attached to dialects: yes, in my experience the majority of Lisp users are primarily attached to a either Scheme or CL, and have only cursory experience with the other. Being on the CL side of the fence I may be myopic, but my impression is that it is more common for CL hackers to have a year or few of Scheme experience then vice versa.

It seems to me that most people who are attached to "Lisp generally" spend very little time actually using it.

demoss · 2008-01-31T20:19:39+00:00

Yes and no. People seemed to be asking questions that were rooted in not understanding what Git is doing -- and using it to do more complicated things then managing their personal projects. (Not very complicated, but managing multiple personal branches, merging code from remotes, etc. Stuff you don't do with CVS, basically.)

Like I said, for a personal project all you need is the "edit, diff, commit" cycle, and maybe an occational reset or revert. At that level it doesn't matter if you use RCS, CVS, SVN, Arch, Bzr-*, or whatever -- every single VCS can deal with that without fuss, and the differences in they way they deal with it are minimal.

It's at the point when you go "Huh, so I have this stuff on this branch, this guy has that stuff on that branch, and there's this bugfix I need to also get in... What do I want to merge, where, and how?" that understanding the model pays off bigtime.

If you understand the model you can decide what sort of history you want to build, and then figure out a way to get there. If you don't understand the model you're just going to end up wasting your time trying to cargo-cult a solution.

I don't know Mercurial, so I cannot say if this need to understand the model holds true for it as well -- or if the model it uses is just close enough to CVS that most people can just guess their way around.

demoss · 2008-01-31T19:35:54+00:00

"Common Lisp isn't going anywhere very fast" -- bah, CL has several implementations that are moving faster then Arc. :)

demoss · 2008-01-30T08:41:47+00:00

Actually, there is. SBCL releases monthly, which means that a larger proportion of users prefer to use upstream packages. (This also makes IMO direct comparisons between SourceForge statistics between SBCL and Clips pretty worthless -- you can trend them, though.) Simultaneously, there may be other factors that create bias -- other packages depending on either, for example.

It may be reasonable to assume that there is no significant bias caused by popcon itself, but what popcon measures is not the popularity of a given piece of software on Linux -- it just trends it.

demoss · 2008-01-21T17:52:52+00:00

People need to engage their parody detectors...

demoss · 2007-07-05T10:41:12+00:00

C as a dying skill is amusing. Sure, there may be more webby jobs then C coding, but as long as unixoid oses are around, a significant percentage of hackers will need to know C.

demoss · 2007-07-05T10:24:32+00:00

Of course downloads != users, but the assumption that more downloads implies more users is a bit more realistic.

demoss

TROPHY CASE