I saw that reddit thread recently, and was initially against the idea, but I could see why it might have some value. It may be more efficient, and can be more concise too.
Most of the time though I think that the additional nesting layer of a a let form helps make the code clearer, and probably simpler to parse too—it's obvious where the boundaries of the scope are. Also, I'm not sure there's a good reason to suddenly introduce new variables partway through an environment.
I could see restricting '= to only assign to declared variable names, if that would help with the typo vs global problem. Maybe introduce a separate 'declare or 'global form that can be used to explicitly introduce global variables, instead of accidentally making them. On the other hand, arc is the language of user power—adding complexity to prevent people from shooting themselves in the foot seems like a step in the wrong direction.
I'm actually somewhat intrigued with the idea of using guix as a language package manager. It has really nice facilities for setting up "environments" that contain a set of packages, so you can use it for bundling together all of the deps needed to build a particular application. As a bonus, it uses scheme as its configuration language :)
It wouldn't solve arc side of actually loading packages, which probably still needs work, but it should work pretty well at managing them.
Actually, poking through the markup of the forum in general, I'm still impressed by how simple the site really is. There's something to be said for minimalism like that. Not only does it make the initial development easier, but I imagine it's easier to do mashups and derivative works too.
> There's something to be said for minimalism like that. Not only does it make the initial development easier, but I imagine it's easier to do mashups and derivative works too.
If I may kick off a tangent, this is the part of "Worse is better" that tends to be forgotten/deemphasized in Pitman's formulation. C and Unix succeeded because they focused on keeping the implementation simple and accessible for many years. (They eventually forgot that lesson, of course, and have been coasting on the initial momentum for a very long time.)
Indeed. And Richard actually makes that point, that the "initial virus" has to be good and simple, and that having won it will have much more pressure to improve until it gets to 90% of "good". Unfortunately, in the process it conditions users to accept worse, and the patching process probably doesn't result in a simple end result.
In fact, reading the story about the "PC loser-ing problem", I realized that I was so conditioned by the Unix solution that I had never even _considered_ the former as a possibility. I do sometimes wonder how many amazingly good ideas we've lost, that would now actually be much simpler than the stack we have, but we're just used to it.
I think the concept could be better generalized by rephrasing it as "cheaper is better" though. Technically it's not "worse", it just has a different set of values. Obviously, users value it more, or they wouldn't adopt it.
I see it as closely related to ideas like "compatibility is key", "customer is king", and "money is power", each of which builds on the following.
Customers adopt products that have the best cost-benefit ratio. It doesn't matter if the fancy "good" solution is 10% better (from 90% to 100%) if it also costs 2x as much. Maintenance of the ideal solution may actually be cheaper, but it's really hard to estimate maintenance in advance, especially in design fields like software development.
Once the "cheap" solution is adopted, future adoption and upgrades are even cheaper compared to switching to the "good" solution, because the user is already invested, and has built a network of integrations that would be very hard to replicate.
The network effect and basic epidemiology probably provide good explanations for the rapid victory of "cheap" solutions—they spread faster because they are easier to "get", and that amplifies the infection rate to new nodes. Anyone can understand why to adopt something cheap. It takes a lot of effort to learn and understand the technical advantages of a superior system. Given the work involved in properly evaluating competing options to discover technically superior solutions, I think it's safe to assume that the percentage of potential customers that just pick the cheapest one that works, or that is already adopted by the largest number of other users, will always be higher than those who actually compare all the options to pick a better solution.
So "worse" solutions actually are "better", because they're cheaper to adopt. This is especially visible when you look at history and see how many times the systems focusing on backwards compatibility won out over those that merely tried to be "new." Compatibility reduces the cost of adoption. It's that simple.
Does that mean that we're doomed to a "race to the bottom"? I don't think so. In fact, I think with some care new solutions can be designed that are sufficiently better/faster/cheaper that they do disrupt the existing ecosystem. It happens all the time. We see Facebook beating Myspace, all the various chat programs killing XMPP, Slack starting to eat IRC, etc. Most of those did it by making adoption easier for new users. The secret is that a new system doesn't have to replace the existing system, just be easy to adopt. Lots of people use multiple chat programs at the same time. The Lean Startup book was written by an entrepreneur working on a chat system, who initially thought that to make adoption easy he had to integrate with existing systems. What they learned was that people didn't mind adding it to their list of chat systems, and actually liked the ability to meet new networks of friends.
I've been very intrigued recently by a lot of early internet protocols, like IRC, SMTP, NNTP, etc. which are very clean and simple. So easy to use that you can literally connect to an SMTP server via telnet and send an email by hand with just a few simple text commands. I've seen people mention gopher a few times recently (the core doesn't change very fast, but people like to implement custom clients), and even HTTP is pretty simple. I think there's a lot to be said for simple, text-based protocols, because they're easy to understand and implement something that connects to them. I almost think a good test for how complicated an interface is, is how easy it would be to implement in arc, which has very little library support for most of these things. It turns out to be quite easy to build an IRC bot with arc.
It is interesting to me that arc may not be very widely adopted, but it is probably one of the few programming languages that has almost as many implementations as it has community members. If we made it just a little bit easier to pick up and start using (particularly in production), the community would probably grow a little faster.
I think there's a lot of opportunity now and in the near future for reintroducing simple foundations, perhaps slightly extended, but mostly made more accessible for new users. Our technology stack has gotten so tall and complicated in the name of shortcuts and simplicity, that a lot of efficiency can be gained by cutting out a few layers. Once people start targeting certain abstraction boundaries, like WASM + WASI, it should be pretty easy to replace everything under that boundary with a much simpler system. A lot of the disadvantages of "good" systems, like microkernels vs monolithic ones, are now so completely outweighed by the rest of the environment that it should be pretty straightforward to build an OS with much better security much closer to the metal than what we have now with 2+ layers of VM sandboxing.
But you should elaborate on your last 2 paragraphs. I'm not sure I buy either that Arc adoption can pick up or that the mainstream tech stack will ever cut out layers.
My synthesis of "Worse is better" for myself (with Mu and SubX):
a) I don't think of evolution as "bad". Building something incompatible is indeed maladaptive. I'm clear-eyed about that.
b) Mu doesn't try to come up with the perfect architecture that doesn't need to evolve. Instead it tries to identify and eliminate every source of friction for future rewrites.
c) My goal isn't to go mainstream. I'd be happy to just have some minor Arc-level adoption. I think it's better to have a small number of people who actually understand the goal (an implementation that's friendly to outsiders) than to have a lot of adoption that causes Mu to forget its roots. My real goal is to build something that outlasts the mainstream stack (the way mammals outlasted the dinosaurs). That doesn't feel as difficult. It's clear the mainstream has a lot of baggage bogging it down. It'll eventually run out of steam. But probably not in my lifetime.
Anyways, I hope in a year or so to give Mu an Arc-like high-level language. It won't improve Arc's adoption, but hopefully it will help promulgate the spirit of this forum: to keep the implementation transparent, and to be friendly to newcomers without burning ourselves out.
ATM, simplifying the HTML and CSS, removing obsolete tags (like font) where possible. Also eventually themes and having the base font size be selectable, since not everyone is comfortable reading 10pt grey on grey text.
This isn't actually related to the work you are doing, but I was curious why you chose to use notabug.org over, say, gitlab.com. I hadn't actually seen the service before you linked to it on this forum.
Under knarks "Why the fork?" section hjek links to the 'ethical repository'. Since notabug.com is only for open source projects then the repo's will likely be considered 'free software' which I believe makes it grade A in 'ethical repository' terms.
Personally I find the term 'ethical repository' offensive. It insinuates that non-free software is unethical when the majority of non-free software has no nefarious intent or code. Not exactly the greatest sales pitch in my book.
I think free (or "open source") and ethical mean the same in most cases.
Exceptions might include something like Facebook, which is technically somehow usable w/o non-free JS when using their basic mobile web page, but where the company is still engaging in other unethical activities, like selling user data to sway elections.
Or something like Amazon, where you might possibly be able to buy something w/o non-free JS (haven't checked), but where the treatment of their employees is unacceptable.
But, I think, when we're talking git hosting sites, there's no difference?
But FSF considers Gitlab ethical enough for hosting GNU packages.
As I understand it - the 'Open Source' movement concerns itself with improving the software by making the code openly accessible, where as the 'Free Software' movement concerns itself with a fighting for users rights (i.e. having the freedom to access, modify and distribute the code in a manner that empowers the user).
And so, an 'Open Source' repository holds code that is openly accessible for the purpose of improving the software. Where as an 'Ethical Repository' holds code that is graded by its' ability to guarantee users rights according to a specific set of morals (established by free software foundation). It so happens that open source repos tend to align well the ethics associated with free-software, but they should not be mistaken for each other. As an example to illustrate: If a repo SaaS were built for open source code, but restricted users from a certain country it wouldn't rank high in ethical repository grading. This is because while having the code openly accessible leans towards a Grade A rating (excellent), the restricting some users part puts it at a Grade F rating (unacceptable).
"Despite initially accepting it, Richard Stallman of the FSF now flatly opposes the term "Open Source" being applied to what they refer to as "free software". Although he agrees that the two terms describe "almost the same category of software", Stallman considers equating the terms incorrect and misleading. Stallman also opposes the professed pragmatism of the Open Source Initiative, as he fears that the free software ideals of freedom and community are threatened by compromising on the FSF's idealistic standards for software freedom. The FSF considers free software to be a subset of open-source software, and Richard Stallman explained that DRM software, for example, can be developed as open source, despite that it does not give its users freedom (it restricts them), and thus doesn't qualify as free software."
> They are categorically demonizing innocent people.
I'm sorry; that was not my intention.
Perhaps I can make a comparison to clarify? As an example, some people think that guns are unethical because they may be seen as an unjust instrument of violence. Even if a particular gun hasn't killed anyone (yet), or even if most guns happened not to be used to kill, then surely it can still be legitimate for people to object to the passive presence of guns, because it gives gun owners the power to kill, and that power may be considered unjust by principle.
Similarly, some people think that non-free software is unethical because it gives programmers the power to do bad stuff, regardless of whether some particular non-free program is actually malware (yet).
(Sorry in advance if I've derailed this discussion into a more controversial subject.)
(continuing the discussion for clarity... no emotional connotation is intended)
I realize this is a comparison for clarification, but isn't it still just 'categorically demonizing innocent people'?
You picked a more controversial topic where more people are likely to agree with the demonization I suppose, but your assertion that the power to kill "may be considered unjust by principle" is not well supported by vague assertions that "some think" guns "may be seen as" unjust instruments of violence. I fully support everyone's right to object to something they see as dangerous; opinion does not constitute principle, however.
To me, something is just or unjust based on whether or not it aligns with or infringes anyone's rights. So, I suppose I might actually agree that a power could be "unjust in principle" if it could be shown that the power could not be used justly - that is, without infringing on anyone else's rights. For some powers, mostly political ones, this is the case. In this case I think guns may be a poor comparison, because they actually can be used in ways which are just (defense, etc.), even if you believe that those cases are unlikely and so desire strict gun control, etc.
In contrast, it may be that producing nonfree software is always 'wrong' (in that it infringes on the supposed rights of the users to understand and modify the program they are running) and therefore having or providing the power to do so would be 'unjust in principle'. If the concern is merely that some may produce malware, and there are actually legitimate reasons for producing nonfree software, then it is not unjust in principle to do so, or to provide someone with said power.
I hope I've understood all that correctly, and restated it well. I'm not sure that I agree with the idea that nonfree software is always bad, but I am open to it. Perhaps what I'm missing is a clear understanding of the specific rights that nonfree software violates.
No worries, I know you (as well as the authors) are simply trying to apply implicit safety measures to counter bad actors. And I'm certainly not offended by you adopting the program. It's my feeling, however, that their approach is horribly wrong and bordering on corruption. I simply don't believe they will have any success when trampling over the good actors in their process of trying to better the world. IMO; If they really wanted to make a dent, they should push for a regulation requiring that browsers provide functionality that enforces a free-software configuration OPTION. Then allow society to decide for themselves (this is a free world after all). I'd even be ok if the default setting was on. But as it sits right now they will get nowhere really fast.
edit: oh and as for the gun analogy... I'm from Canada and fully support gun control (we have it), but I'm not going around and implying that every gun owner is unethical in the process of asking for gun control. That would be shooting myself in the foot!
However I am opposed to that call for action given it's an all-or-none implementation. I feel it's the role of each country to regulate, which is why I expressly suggested it as a configuration option (ideally it could be enforced at the browser level country by country and if not then user by user).
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.
For anarchic service management, what do you think about trying to set it up so that the service is automatically updated if the latest commit passes some form of CI testing? The CI tests themselves could be updated if the new version passes the latest working version of the site.
It would still be possible for someone to break things in two passes of "delete the tests" then "delete the server" but regular automated backups should mitigate the risks somewhat. And we haven't had many problems with spammers anyway...
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 . 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.
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.
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...
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.
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.