My understanding is just that - it's the opposite of flag, however I thought there was some karma threshold or something that permitted vouch to occur, where as flag was fairly immediate. Maybe is just needs to be dead first.
Today’s new feature lets users rescue [dead] posts on a
case by case basis. Beside the ‘flag’ link, you’ll see a
‘vouch’ link to click when a post should not be [dead].
When enough users vouch for a post, the software will
unkill it. Think of vouches as the inverse of flags: a
flag says that a post shouldn’t be on HN; a vouch says it
should.""
Yeah, if you have enough karma, you can see "vouch" links on dead submissions. The easiest way to see this is to go to https://news.ycombinator.com/newest; many of those links will be dead.
Given the open nature of the anarki repo, it's likely that news will break. And when it does we wouldn't be able to discuss it.
So unless these tests could prove that the forum would work (which is highly unlikely) then my vote would be not to do this. It's akin to putting the services issue logging/tracking system under the same service [1]. It's a bad idea IMO.
Or maybe the immediate and painful result of breaking the forum would motivate us to be more careful and fix the issues more quickly. It probably won't happen that often anyway.
I was about to say that an outage might risk killing the community, which would be bad, but 1) we still have this forum and GitHub (as krapp points out), and 2) if the community is really so weak that it can't revert a commit in order to get the forum running again, it's probably not worth hosting a separate site anyway.
The idea is growing on me, just because of how audacious it is. (^^)
I do agree with some of your point though; it would be good to have some separate logging and bootstrap systems in place so that we can detect and repair faults more easily, without the intervention of a specific admin. For one thing, the software that pulls the changes will probably not be arc-based, so it should still be running even if the forum goes down. Secondly, we could try to set it up so that it always pulls hotfix patches immediately when the logging / monitor system indicates failure.
Also, marking a particular branch (probably not master) as a more 'stable' version might be good.
Another option is to ensure the service has a robust failover procedure towards a secondary free service as a temporary measure. And maybe someway to safely automate an intentional failover.
edit: my original comment was in consideration of the arc forum potentially going away. Honestly I'm not sure I would move over if that wasn't the case. I'd have to see :)
Yeah, that's part of why I've never seriously considered it before.
The only reasons for thinking about it now are that 1) we want to add some features to the forum, and there's no way to test them here, and 2) it isn't actually a bad idea to have a community site for Anarki. The risk of weakening the community has deterred me from the idea of forking the arc forum, but if we still treat this as the 'official' arc community, and make a separate site more focused around anarki, I don't think that would be too bad.
It might actually help some, since separating more could allow us to really focus on and develop our unique points of experimental language hacking.
Don't let my comments stop you. Your thinking is quite valid. I'm just trying to contribute my opinion in hopes of helping you shape whatever you decide.
> It might actually help some, since separating more could allow us to really focus on and develop our unique points of experimental language hacking.
As far as I can tell, pretty much everyone has moved over to anarki, so I don't understand your comment. How does creating a separate forum for anarki help to "focus on and develop our unique points of experimental language hacking"?
Thank you for your opinions; it really does help me clarify my own thoughts. That and I rather dislike talking to myself for more than a few minutes at a time...
Currently, this is an Arc forum. People are drawn here from pg's posts about Arc, and their attraction to the simplicity and beauty of the language. Also probably dreams of silver bullets... That won't stop just because we make a separate community, and I really don't think there's anything wrong with it.
However, I think we're also torn a bit between maintaining basically a bugfix version of arc, or going on to develop it further.
The question then is what "further" means - which direction would it go? One answer is that it can't really be predicted; creating such a community would be a way to find out.
On the other hand I can speculate, based on what I've seen of this community so far.
People come, entranced by pg's vision of arc, and then find out that the code base itself is really small and approachable. In general, lisp variants are used by people who like to make the language fit their needs, but where most dialects would add to the language via macros, with arc (or anarki) people find it just as easy to hack on the core of the language itself. Eventually this leads them to forking it, or building their own implementation in javascript or something.
I suspect this is partly because arc is so small, and does not have many standard libraries or a package system. You can read it all in a fairly short amount of time. So the fact that most of the code is aimed at developing arc means that the easiest thing to develop with it is... arc.
This trend of exploration and extension will undoubtedly continue, and I think it will be much more free to develop into something significant if we simply look at anarki with the slightly different perspective that having a separate community site we could actually upgrade might offer. Instead of being weighed down by arc as the 'community bugfix edition', it could become a 'language based on arc' with a solid foundation, but room to grow.
The core paradigms and strengths of arc appear to be "exploratory programming", and "language hacking". I think it would be cool if we could develop the former beyond the latter, but who knows how it will turn out?
Of course, I may be entirely off-base here myself...
Hmm, you know, a new anarki forum could have the benefit of adding a tags feature for posts. A few good tags could be 'lang-design', 'arc', 'anarki', 'help', etc., etc. Not only would this allow our subtypes of members to zero in on their content of interest, but would make searching for meaningful info much easier. Now that would probably make me jump over.
Yep, improving the forum would help a lot, in a lot of ways.
I've often thought that the structure of the news.arc forum is rather unhelpful for the arc community, especially now that we're so small and lethargic. Conversations can go extended periods of time without comment, so they get locked. Or they fall off the front page, and hard to find again. Neither is conducive to long-term development and improvement; we probably lose a lot of valuable work and ideas that way.
One thing I'm considering as part of developing a new community site is collecting and archiving all of the arclanguage.org content, so we can actually access it. And preserve it, if the site goes down.
But I end up wasting all my time on discussion, instead of actually making progress on that...
Anyone know how long an IP stays banned? Or what I can do about it? Rather inconvenient not to be able to check the forum from home...
I suppose I could set up a proxy or something. And I was planning on scraping everything to a new community site anyway, so maybe I should take this as the incentive to do so.
Looks as though it ranks how bad you are and always keeps the baddest of the bad-asses in cache, while never deleting any from disk. In a low volume site like this I doubt you'll get out of it without contacting them.
I did ping the HN admins about the lock period a year or two ago, and they were kind enough to extend it for us. It's now 90 days, if I recall correctly.
Sure, but from what I can see they soon quickly discover they need to use anarki and move over.
And impacting newbies does not appear to be considered in "focus on and develop our unique points of experimental language hacking". So...
edit: maybe I'm wrong, but it seems to me what he really wants is a language design group. And I'm fine with that, but I think it's wrong to conflate anarki users with language designers. They are not one in the same.
I was expecting arclanguage.org to stay mostly as it is. Support for newcomers to arc would be included in that.
You may not be entirely wrong, but I probably shouldn't have tried to compress a description of a language used and developed by a loosely federated group of unique individuals into a single phrase.
I can try to unpack it a bit...
"Experimental (language) hacking" -> Exploratory programming is supposedly a primary paradigm of arc
"Experimental language hacking" -> Arc isn't exactly production ready; it's a very experimental language, and that makes it fun (and sometimes frustrating) to use, and easier to explore new directions and possibilities. You're less likely to reverently assume that the way it is is the way it must be.
"Experimental language hacking" -> And yes, we hack on arc itself. So I am thinking a bit of a language design community, I guess. In an anarchic language community though, the lines between 'users' and 'designers' become rather vague...
If that's an argument against us using Anarki then it also seems like an argument against anyone using Anarki, or at least against anyone blindly committing it to production. Breakage can happen with any open source project, but given the generally slow nature of the community, even if news is likely to break, it isn't likely to break often.
Also, we already have Github to check and discuss it, and I think there is a more appropriate venue than here for those issues.
I'm going to piggyback on this thread for anarki + osx. Can some explain why the arc.sh script requires that coreutils be installed - what's that dependancy for? emacs?
edit: I'm ok if they take it down. I'll know where to go via the anarki wiki (if someone updates it). And it may actually be better if they do take it down IMHO as it will force everyone to find a place with more control over the setup.
I think if we fork the community site to run on anarki. which I think is more likely than being given control over the Arc Forum, we should consider ways to archive and bring forward all of the stuff on the existing arc forum. It shouldn't be too hard to crawl the forum, though I think there might be some DoS prevention that would slow it down.
I liked the article, but I'm at a loss as to why that would lead you make CL more notable than other lisp or scheme dialects.
For me, the article makes good points about Lisp in general and makes a good case for lisp vs. non-lisp languages, but other than that it just read like a very good lisp intro.
Your comment detailed what the libs.arc file contained.
the code within tem.arc was originally part-in-parcel within those files, but was extracted out into its' own file. So he was just commenting that there is other code that exists in anarki that was originally included and that there may be more examples of such.
The service looks interesting. I was glad to see the change logs of your repo were respected. The service itself seems intermittent I can't seem to get a pulse on how stable it is.
Yeah, about half of my 10 or so page reqs timed out, so that's probably not covered under outages. I'll just have to follow it a little more; it just wasn't the greatest intro experience, but that happens.
But those are comments from the same person I'm responding to?
Did you perhaps have a similar opinion as well? I certainly recall other people asking for a package manager.
To be clear, what I said is just my opinion, and I should have said "we don't need that" or "it's a bad idea" rather than "we don't want that", which sounds like I'm speaking for others. If a couple of us feel strongly about adding interfaces, you should feel free to do it and see how it goes. If I'm right then you'll eventually realize that it's only serving as bureaucracy. If you do enjoy it then I'll eventually realize that I'm wrong ^_^
I think API boundaries arise naturally from syntax that doesn't fit on one screen. Edits to one piece of code can only be quick and easy if they manage to preserve the assumptions that make the rest of the code work. These assumptions form an API boundary, and at some point it becomes easier not to break the code if that boundary is documented and verified.
Currently, we break up the API boundaries in Anarki by function and by file. We document the function APIs with docstrings, and we write verified documentation for them with (examples ...). We verify the file APIs with "foo.arc.t" unit test files.
If we put more effort into documenting or verifying those boundaries, it would hardly be a big change in how we use the language. We could perhaps add a bunch of "foo.arc.doc" files or something which could compile into introductory guides to what foo.arc has to offer (whereas the docstrings still act as API documentation). And we could perhaps add an alternative to Anarki's (require ...) that would load a library in a mode that faster faster, abiding by an interface declared in a "foo.arc.i" file.
It seems like the most drastic change in philosophy would happen if we broke Anarki apart into sections where if someone's working on one section and discovers they're breaking something in another section, they don't feel like they can fix it themselves.
I suppose that happens whenever people put Arc libraries in their own separate GitHub repos. There are actually a number of those repos out there, including my own (Lathe). Even aw, who was a strong believer in avoiding unnecessary black-box interface boundaries, would still put things in various repositories, and the hackinator tool would collect them into one file tree.
It also happens naturally with poor knowledge sharing. Seems like despite my attempts at explaining ns.arc, I'm still the only one with a very clear idea of how it works and what it's good for, so other people can't necessarily fix it when it breaks.
(Come to think of it, that makes ns.arc a great test case for pulling out an Anarki library into its own repo. That'd save other Anarki maintainers the trouble of having to fix it to keep Anarki's tests running.)
Hmm, even if some libraries are maintained separately from the Anarki repo, Anarki's unit tests can still involve cloning some of those repos and running their tests. If Anarki maintainers frequently break a certain library and want to help maintain it, they can invite its developer to fold it into the Anarki repo. And if the developer wants to keep maintaining it in their own repo, the Anarki project can potentially use a hackinator-style approach to maintain patches that it applies to those libraries' code. We have a lot of options. :)
"Hmm, even if some libraries are maintained separately from the Anarki repo, Anarki's unit tests can still involve cloning some of those repos and running their tests. If Anarki maintainers frequently break a certain library and want to help maintain it, they can invite its developer to fold it into the Anarki repo. And if the developer wants to keep maintaining it in their own repo, the Anarki project can potentially use a hackinator-style approach to maintain patches that it applies to those libraries' code. We have a lot of options. :)"
This would be fine. Whether we consider something an API has nothing to do with how we divide code into repositories or sections. Perhaps the key is to know who is calling us. I'd be happy to provide a guarantee to anyone who "registers" their repository with Anarki: if it's easy for me to run your codebase, I'll check it everytime I make a change to Anarki, and ensure that it continues to pass all its tests. If I break an interface, I'll fix all its callers and either push my changes or send the author a PR.
I don't know yet how "registering" would work. But we can start with something informal.
>I don't know yet how "registering" would work. But we can start with something informal.
Perhaps just the functionality to clone a repo into /lib under the requisite namespaces as a way to include remote dependencies, including pinning to branch and version? No need to "register" anything at first.
"It seems like the most drastic change in philosophy would happen if we broke Anarki apart into sections where if someone's working on one section and discovers they're breaking something in another section, they don't feel like they can fix it themselves."
Exactly! It's a huge problem in the programmer world today that we are indisciplined about this distinction. There's a major difference between making a boundary just to make edits easy and "APIs". APIs are basically signalling to most people that they shouldn't be crossing them, and guaranteeing that anybody calling them will be able to upgrade without modifying their code. That is worlds away from just not being able to see everything on a single screen.
Since we use words like "abstraction" and "interface" for both situations, it is easy to cross this line without any awareness that something big and irreversible has changed.
Currently nothing in Anarki is an API. I recommend we be restrained in using that term, and in introducing any APIs.
"There's a major difference between making a boundary just to make edits easy and "APIs"."
Maybe there's a difference somewhere in what we mean by "API." There's a distinction to make, but I wouldn't make that one.
I'm saying APIs arise naturally at boundaries people already feel aren't worth the effort to cross for various plausible reasons. Recognizing an API boundary is a positive thing: Then we can talk about it and help people understand the ways in which it's worth it for them to cross the boundary. But talking about it also makes it something people form as a concept in their mind and form expectations around, so it can become a more imposing boundary that way if we're not careful. We should seek a sweet spot.
The important distinction is that sometimes the reasons people don't cross boundaries are good ones, and sometimes they're baloney.
I think what you and I want to avoid for Anarki is documentation that gives people baloney reasons to think it's not worth it for them to edit the Anarki code.
While we can try to minimize the good reasons that exist, and we can encourage people to try it before they knock it, there's no point in denying that the good reasons sometimes exist.
If you ask me, the reason we have to settle for a "sweet spot" is totally a consequence of the fact that Anarki is made of text. Text loves bureaucracies. Someone sees text, they ask for the Cliff's Notes, and then someone has to maintain the Cliff's Notes.... So you've gotta get rid of the text, or you'll have an API boundary.
Programming without bureaucracy would be like having a conversation without writing it down. I believe in this. I think conversational programming is exactly what we can do to simplify the situation of programming in the world, and Era's my name for that project, but Anarki is a more traditional language, and it takes a more traditional trajectory into APIs.
Our documentation can try to convey "This is all subject to change! Edit it yourself, open an issue, or drop by on Arc Forum for some help! We count on contributions like yours to make Anarki a good language. Since others are welcome to do the same thing, watch out for changes in this space." We could put an "unstable, just like everything else here" tag on the corner of every single documentation entry.
Anarki is far from the only unstable codebase people have ever seen. Being a Node.js user, my code has regularly been broken by upgrades, and Node.js isn't even a version 0.0.x project. I think only a certain number of people would mind if Anarki promised stability and then couldn't deliver on it, let alone mind if Anarki made it clear in the API documentation that there was nothing stable to find there in the first place.
---
"guaranteeing that anybody calling them will be able to upgrade without modifying their code"
You know me well. I probably said that pretty insistently in the past. It's something obsess over and a major requirement I have for code I write (and hence all its dependencies), even though things like Node.js show me it's not a current norm in software.
It's the 100-year language ideal. Spend a lot of time to get the axioms just right, and then the language is stable and nobody ever feels the need to change it since there's nothing to improve on! In 100 years, Arc is supposed to be the language that's too perfect to be anything but the stablest language around.
I still believe in that ideal, but not in quite the same way. People will come up with a reason to promote their alternative language, even if it's just to say they're different than their parents. But I do believe languages can be designed to be more compatible with their forks, even to the point where it's difficult to say where one language ends and another begins. The resulting unified "ecosystem of all languages" could have a much simpler design than the "ecosystem of all languages" we currently have.
That's also part of my approach in Era. I make decisions in those codebases with the goal of simplifying the ecosystem of all languages.
I don't think this is something I would pursue in Anarki. Arc was very far from the the 100-year language upon release, it was unstable, and it seems like Anarki has pretty much been maintained by and for people who could embrace that part of Arc's journey.
Another option is to have stable branches/tagged releases.
As for "breaking things harder and more often". I don't think 'harder' has to happen 'often'. I'd be ok with 'harder' when need be with more 'often' being good.
This language has 3-6 people active users and maybe another 6-10 lurkers. More changes like the app/news change have potential to garner more users and more users means more changes which may lead to a fuller and richer language.
Having the news app so heavily integrated was a poor design choice to begin with. This is a language and the language development should not be constrained by a single application which is currently the case. That app needs to be a downstream consumer of the language.
Ideally we can get to a point where you can just repo your own app and marry it with a tagged release while collectively the app users can report any breaking changes.
If we don't do this the language is dead for all but a hand full of hardcore arc lovers + news appers.
I think a stable branch is a good idea. People can experiment elsewhere while not stepping on anyone's toes.
>Ideally we can get to a point where you can just repo your own app and marry it with a tagged release while collectively the app users can report any breaking changes.
Currently, it looks like "apps" are mapped to an admin namespace and will only work for that user, so that would need to be changed to make them portable.
> I think a stable branch is a good idea. People can experiment elsewhere while not stepping on anyone's toes.
I think it's possible to experiment with things while still considering stability and backwards compatibility. I recently reworked the password hashing function, but I took care to not break the logins of every user, when doing that.
I must say I'm a bit upset by you being so apparently casual and careless about creating several breakages[0][1][2] in News that I've had to fix, and then suggesting that I should just get off the master branch if I don't like your "experimentation".
I will. I'm done with this.
Experimentation is not the same as carelessness. Seriously, WTF is this?:
You also made a bunch of breaking changes the repo a while ago. Because of those, I got more of the tests running under the Travis CI script to help us all monitor them without having to ask each other to remember to run them all the time. I really hope I didn't make you feel ashamed about that. You got to make changes, and I got to make changes, and I felt like the repo was better with both of those together. The same is true here.
I did break some things in Anarki, and I appreciate you spending time helping me fix those breakages and adding more automated tests. Thank you.
What bugs me here is not so much that stuff gets broken now and then, but this nonchalant attitude to breaking things, and lack of acknowledgement for others that have to wipe up the mess.
> And... people just have to fix it once.
> Given that is not a mature language or a stable framework yet, I would disagree that breaking changes, per se, should be avoided as a matter of course.
Also, I have a strong aversion to CAPTCHAs, partly because they're non-free Google SaSS, but also just because they are just plain annoying. Why would anyone want to inflict that upon themselves? There's already plenty of ways to deal with spammers in News.
And, quite unrelated, I'm not big on Github as their site requires non-free JS, and I'm particularly wary of them since they were bought by MS, so that is just one more reason to host the code elsewhere. So, I've forked Anarki, and we'll see what happens: https://notabug.org/hjek/knark
>What bugs me here is not so much that stuff gets broken now and then, but this nonchalant attitude to breaking things, and lack of acknowledgement for others that have to wipe up the mess.
You don't have to wipe up the mess. I didn't ask you to wipe up the mess, and I didn't expect you to. I also suspect you're conflating my beliefs about whether or not Anarki should be willing to make breaking changes when necessary with some general lack of regard for whether or not anything works at all, and that's not the case.
I'm new to lisps, to this lisp in particular, to this framework, and to working in a team. I admit (and have admitted) that I make mistakes and I've picked up some bad habits that I need to correct. If I know about an issue, I will gladly deal with it.
But, as to the specific issues you listed... I don't know what happened with the css (it worked for me when I pushed it but your comment that it might have needed testing in other browsers is correct,) but #104 wasn't broken, but misconfigured. And you've explained at length already why that entire commit was misguided, but it wasn't broken.
But sometimes I do miss things, forget things, there are some mistakes I might not even see because I'm working on Windows. But I am trying to make things better here. So thank you for cleaning up after me, and I will try harder in the future.
That said, I stand by moving news, and I stand by my statement that we should be making breaking changes (with the caveat that those changes improve the code.) Now is the time to do that, when there are so few people actually using this codebase, as opposed to later when there might be dozens or hundreds, or never, simply because change is difficult to deal with. Chances are most of the entire universe of people using this fork in production are already in this thread. Moving news to a new folder shouldn't be a reason to create a hostile fork.
And that's why I agreed with i4cu's suggestion earler that a stable branch might be a good idea... which for some reason you interpreted as a personal attack,
"(...) and then suggesting that I should just
get off the master branch if I don't like your "experimentation"."
Rather than more charitably, that you should stay on the master branch and the unstable branch should be elsewhere, as I was actually conceding your point and agreeing with what I thought would be an equitable solution.
> You don't have to wipe up the mess. I didn't ask you to wipe up the mess, and I didn't expect you to.
I agree. That was my own expectation, and also I might have been wrong in expecting stability from a repo that's meant to be "extremely permissive in accepting patches."
> And you've explained at length already why that entire commit was misguided, but it wasn't broken.
That I don't agree with. I would consider a commit, that makes all links not work in the default config and prepends the site name to already absolute links, broken as well as misguided.
> But I am trying to make things better here. So thank you for cleaning up after me, and I will try harder in the future.
That's great. It's good to see work done on Arc. Looking forward to see where this goes.
> Moving news to a new folder shouldn't be a reason to create a hostile fork.
Let's just call it a fork, not a hostile fork, shall we? Also there's some other reasons listed in the readme of the fork.
I agree that we should hold ourselves to some standard about not breaking Anarki for each other.
It's our job, yours and mine and that of other long-time participants, to explain the norms that we have here. And to do it in a nice way, realizing that what's obvious to us isn't necessarily obvious to newcomers.
This is a pretty non-standard repo where anybody can make changes, so it's understandable that a newcomer may think stability is not important. We have to articulate precisely what sorts of stability are necessary and what we don't consider important. It's a tough job. So I really hope you stick around to help us out :)
I'm actually curious how you run a production service on Anarki. Everytime I ever tried to do that I would maintain a cutout in between that was wholly in my control, and decide what patches should flow from Anarki to it.
> So I really hope you stick around to help us out :)
Definitely!
> I'm actually curious how you run a production service on Anarki. Everytime I ever tried to do that I would maintain a cutout in between that was wholly in my control, and decide what patches should flow from Anarki to it.
Usually I'm trying out the latest commits on a local laptop before doing git pull on the server. Works fine. If it's broken for some reason, then I'll just do a `git reset --hard [known-good-revision]`, because the `www` folder with all the news data is outside the git tree anyway so it stays as it is (and no-one have yet been changing the data format, so that's not an issue either.)
I find it a lot simpler to manage than for example Wordpress (although Wordpress on the other hand has tons more featuers and plugins).
> Also, I have a strong aversion to CAPTCHAs, partly because they're non-free Google SaSS, but also just because they are just plain annoying. Why would anyone want to inflict that upon themselves? There's already plenty of ways to deal with spammers in News.
Languages allow people to make their own choices on what is worthy to build. Debates like this are why it's a shitty idea to have apps baked into the language.
> I find the border between app.arc and news.arc a bit murky.
It could just be the name that's offsetting you, but app.arc is an application library just like srv.arc is, only manages application ops/state instead of server ops/state. The best way to look at it is that app.arc, like srv.arc, can optionally be used by different applications (like news.arc, blog.arc or whatever), which is why it's under lib. Someone who wants to build an app, needs to know what libs can be used and those can be. They also need to know that news.arc is not a library to to use for a new shiny app they want to build and when they want to share their app where to put it. Right now the only place is under app/, and ideally (IMHO) we can move them out further someday.
Agreed. Yet it is also possible to imagine apps that could benefit from tighter coupling with News, e.g. to access user 'karma' and to integrate into the layout and navigation of News.
Also, the password reset email function in app.arc requires `this-site` to be set, but `this-site` is set in news.arc. I'm not sure how I'd go about fixing that.
So I could just put values (like site-url*) into app.arc with default settings and reset them from news.arc. Provided that it's utilized dynamically then all is good.
However lacking this functionality in arc I would just move the required config settings to app.arc and be done with it. You're still loading app.arc at the top of news.arc so the only real problem is app users need to know to change the settings therein (a comment would do).
News already has a repl and "apps" in prompt.arc, and I'm already working on getting them to work together. That could provide the basis for a plugin (app, what have you) system.
For what it's worth I agree with the app/news changes. So Good Job I say.
And with that said, after looking at the anarki directory it's apparently becoming a dumping ground for people to place files at the top level. I'm not sure why this is happening, but I hope others take a look at what you have done with app/news and continue the trend of organizing things better.
