Arc Forumnew | comments | leaders | submitlogin
1 point by akkartik 3943 days ago | link | parent

I'm curious: Did any specific incompatibility cause you trouble?

The gotchas I'm concerned with are enumerated at https://sites.google.com/site/arclanguagewiki/arc-3_1/known-.... I think they're far worse than any incompatibilities anarki causes. Anarki's incompatibilities at least error out immediately, but some of these gotchas are quite insidious. They are they reason we try to push newcomers away from installing arc3.1 at https://sites.google.com/site/arclanguagewiki/getting-starte....

There's no value in being strictly compatible with an old, buggy release that never guaranteed compatibility in the first place. We should instead focus on a live version that's getting fixes over time, whether it's anarki or arc-nu or rainbow-js or something else.

The documentation at arcfn has been out of sync with arc3.1 as well as anarki for many years. I love that we're fixing this, but I'd rather gradually bring the docs in sync over time than switch to a more misleading version of the code.

I'm open to being convinced otherwise about this, and if you like you can revert the frontpage change while we argue :)



2 points by dram 3943 days ago | link

I am wandering what's the purpose of people who come here.

Some random thoughts:

1. want to learn about Lisp and Arc

2. want to learn about language design and implementation

3. want to deploy a clone of Hacker News

4. want to use Arc as a daily programming tool

5. want to make a fork :)

For 1, I think bugs in Arc is not too fatal for those guys, we just need to make them aware of those bugs.

For 2, they need to, and I think they would like to investigate those bugs, so I think its better to let them fix those bugs by themself, learning from mistakes is effective. :)

For 3, those people will not tolerant of bugs, but compatibility is also critical for them, both about codes and data. As they need to consider how much work they will need to do when PG release a new version.

For 4, they will satisfied with anarki or other forks.

For 5, as a fork, they need to treat something as a reference, and I think vanilla arc is the most suitable one.

So I think it's more suitable to make vanilla arc as default, as it can make more people happy. Anyone not satisfied with it can choose forks.

PS: I'm in group 3. :)

I'm not sure how far has anarki diverged from vanilla arc, and whether data is still compatibe with it, so I decide to use vanilla arc, and integrate some bug fixes.

PS 2: Of course, if PG can release a new version, that would be the most suitable choice. :)

-----

2 points by akkartik 3942 days ago | link

Ok, I'm outvoted just looking at the votes, so feel free to make arc3.1 the default.

But I still think you're chasing some mythic notion of compatibility. From http://www.arclanguage.org: "Arc is still fluid and future releases are guaranteed to break all your code." There is no "reference" here; if you want upgrades to be smooth you're guaranteed to be disappointed.

"if PG can release a new version, that would be the most suitable choice. :)"

Even if that new version gets no bugfixes for 4 years?! O_O What if that next version takes ten years to show up? Heck, what if it takes a year to show up. Are you sure you'll still care?

I don't know anybody on this site who still uses arc 3.1. Even my 'curated bugfixes' repo at http://github.com/akkartik/arc was a short-lived thing. It's just the nature of this community to go off on some tangent :)

Have you read the gotchas page? Many of those gotchas I'm talking about aren't minor bugs. They took weeks of pain and in some cases months to come up with a fix. I wouldn't wish that pain on anyone. For example, for several months I thought that arc and racket was just really slow, all it could do was 1 request per second. But it just seemed slow because all my requests were getting throttled because of some code in HN that most sites will never need, because they'll never have that much traffic.

Perhaps the compromise position would be the 'stable' branch of anarki. But I'm not aware of anyone who uses it. I really think that if you want to benefit from this community anarki is the most common baseline, and the whole point of a new site is to give newcomers the benefit of more updated information than the existing site, and to get them using what the veterans here are most familiar with so that they can get their questions answered soonest.

If the community has new ideas should we go try them out, or should we wait for PG to first grant them his permission? I know what he'd do :) And if people here have new ideas it's worth getting them feedback from others as long as we can be responsive to issues when they come up. And I think we're pretty responsive :) Arc is a bleeding-edge language, and we shouldn't try to act otherwise.

(Incidentally, yes, the HN site on anarki is indeed data-incompatible with arc3.1. It hashes passwords with sha512 rather than sha1, for one: http://arclanguage.org/item?id=17278. Which would you use?)

Hold on, I'll post a poll. I don't actually know that anarki is the most commonly used :) I'm also interested in rocketnia's reasoning of this whole issue.

-----

2 points by dram 3942 days ago | link

Although not thought every point throughtly, I have read gotchas page for several times.

I'm not against to bug fixes, but I think anarki has go far beyond that.

Take password hash for example, if let me choose, I'll remain it as is. If someone have hosted HN-like site using arc3.1, it'll be hard for them to use anarki instead because of that change.

-----

2 points by akkartik 3942 days ago | link

Ok, glad we can agree on the common ground of bug fixes. Perhaps we should make the stable branch in anarki the default. I'm not sure what's on it at the moment, but it's probably quite close to arc3.1, and we can patch in the biggest fixes to it.

In general, I'm uncomfortable supporting a version that we are not empowered to update. That's basically my biggest objection.

This community has had a culture of letting newcomers come in and show off new ideas to each other. I think that is valuable, so I'm in favor of allowing anyone to update the default version most of us use. But we can agree to disagree on that score :)

(I still think you're WRONG about the password issue :) What'll you do if PG switches the hash in the next release? SHA-1 is insecure, and an insecure default is a recipe for reputation damage down the road. Good thing arc isn't very popular..)

-----

1 point by dram 3942 days ago | link

Ideally, I would like to see arc3.1 be shown as default, along with a pack contains seperated patch files to critical bugs.

And we can treat anarki as a fully fork, with no restriction and full freedom.

About password issue. If PG switches hash, he surely will consider about compatibility, without that, all users of HN will need to reset their passwords.

-----

2 points by akkartik 3942 days ago | link

You: "About password issue. If PG switches hash, he surely will consider about compatibility.."

I'll quote PG and RTM again: "Arc is still fluid and future releases are guaranteed to break all your code." http://www.arclanguage.org

I interpret this sentence on the frontpage to mean that he will not be concerned about compatibility. Arc is for exploratory programming. If you have users you're on your own. I really don't see how you can interpret it any other way.

The good news is that migrating passwords isn't hard. I've done it for a site myself.

-----

1 point by dram 3942 days ago | link

PG and RTM may break other code, but I think they will not break their own code, as news.arc is inside of Arc, not outside. :)

I'm curious how did you migrate passwords, I thought some more code are needed to migrate them automatically.

-----

3 points by akkartik 3942 days ago | link

Yeah, I wrote some more code :)

First I transformed all existing hashes:

  (maptable [list 'sha512_sha1 (sha512 _)] hpasswords*)
Then, as users login and I momentarily have their unhashed passwords, I hash it with just sha512, making the hpasswords* value:

  (= hpasswords*.user
     (list 'sha512 (sha512 password)))
Password verification can now use the first element (the 'type') to decide how to hash the password.

-----

1 point by akkartik 3942 days ago | link

"I think they will not break their own code, as news.arc is inside of Arc, not outside."

But then how would they ever migrate beyond sha1? Would the hundred-year language save passwords in a way that gets more insecure every year?

I think arc's default assumption is that there's no difference between 'inside' and 'outside'. And this is how lisp used to be.

-----

2 points by dram 3942 days ago | link

Another method would be hash sha1 hashed values directly, like:

  (sha512 (+ (sha1 pw) user-salt site-salt))
Anyway, existing passwords still need to be migrated manually.

BTW, for security, it is also unsecure to pass unhashed passwords around network, unless use https.

-----

1 point by akkartik 3942 days ago | link

"BTW, for security, it is also unsecure to pass unhashed passwords around network, unless use https."

Yes. Though you can get that with apache or nginx.

-----

1 point by akkartik 3942 days ago | link

"Ideally, I would like to see arc3.1 be shown as default, along with a pack containing separate patch files for critical bugs."

This could actually be quite cool! Full transparency; we show the default, and we enumerate its biggest issues along with their fixes. That sets expectations in advance. Yes, make it so :)

-----

1 point by thaddeus 3942 days ago | link

If your counting votes then yes please do a poll instead. I think arnarki should be the recommended version we provide to new users.

-----