Arc Forumnew | comments | leaders | submitlogin
Next steps
6 points by shader 141 days ago | 7 comments
Here's a new thread for brainstorming cool ideas to work on with Arc. Obviously we can each pursue our own projects, but I think it would be more fun and productive to work on some things together.

So, propose away!



5 points by shader 141 days ago | link

My first thought is a package system based on melpa / use-package from emacs. Please point out if something like this has already been done and I have just forgotten it.

Basically, just a simple index and package fetching system that pulls libraries directly from github or other vcs sources. Then we only need one file in the standard library "package.arc", that provides functions for querying the index and fetching packages from github into a ~/.arc directory, supported by a macro like use-package from emacs (https://github.com/jwiegley/use-package) or 'ns from clojure.

An important point here is that a package fetching utility can be independent of any module system. Which is good, because we don't really have that yet. The emacs community doesn't seem to think one is necessary; everything is just imported into the global namespace, and prefixed with the package name if necessary to keep it separate. Maybe we could make some macros to simplify the prefix process, but that could quickly get complicated.

We could also experiment with some avant garde packaging ideas, such as akkartik's thoughts on avoiding version pinning, searching the vcs sources directly for the package, or building the community CI tools that automatically find downstream dependencies and run their tests against your lib changes.

-----

3 points by zck 138 days ago | link

> My first thought is a package system based on melpa / use-package from emacs.

That would be great! Use-package is amazing, and that (combined with similar loading things from package.el) could make loading dependencies way easier. I know that when I'm writing arc code, I'm reluctant to use libraries -- even libraries included with arc -- because they're (afaik) impossible to automatically load.

> We could also experiment with some avant garde packaging ideas, such as akkartik's thoughts on avoiding version pinning...

Amusingly, the Emacs ecosystem can be thought of as a package manager that avoids version pinning; the standard package repositories (GNU Elpa, Melpa) only keep the latest version of a package around; you can't install older versions.

Of course, I know of no package foo.el that introduced _foo2.el_ when breaking backwards compatibility. So we can maybe do better that way.

-----

3 points by shader 141 days ago | link

I'd be willing to donate some hosting for an initial version of the package index, if we decide we need one. I have a vultr instance I'm not using for much at the moment.

-----

3 points by shader 141 days ago | link

The second most popular idea is probably a module system. I honestly don't know much about what that would entail, beyond reading rocketnia's comments in his ns.arc from 7 years(!) ago.

Basically, it seems kinda hard, because of how much arc currently depends on global tables to collect special objects like macros, the interactive help stuff, etc.

We could just decide that Arc is deliberately focused on 'hackability', like emacs, and that modules are unnecessarily refined and restrictive for our uses.

-----

5 points by hjek 139 days ago | link

* Unvote (like HN)

* File upload. On the News site I run, users do this in the roundabout way of uploading files to non-free services like Google Drive or Dropbox and then link to them.

* Ecommerce

-----

4 points by shader 138 days ago | link

> Unvote (like HN)

That would be nice I suppose, but we can't actually modify the arclanguage forum, so it would be of limited benefit. I guess a lot of people come to arc because they want to run an HN clone though, so it might be worth pursuing.

> File upload

Yeah, I think enhancing some of the fundamental web-service functionality in arc would be good. Beyond file upload, better support for OAuth, ssl, etc. would be good too.

> Ecommerce

Good idea. Not sure how to make that better myself, but demystifying and enabling easy ecommerce would be cool.

I think that also has the same motivation for the previous category; we need better support for web application development, because that's what most people want to do.

-----

3 points by hjek 137 days ago | link

It's true that unvote wouldn't make it to Arc Forum as it's never updated, but the same is true for any new feature, sadly.

Regarding SSL, I've been working on an example Nginx + LetsEncrypt secure reverse proxy configuration for Arc, https://github.com/arclanguage/anarki/blob/master/extras/new...

It's just insane that Arc Forum doesn't encrypt HTTP but, well, as you write, we can't change Arc Forum. Maybe they'll update it some day, or someone will set up an unofficial one that's more up to date?

Regarding web application development, there's already an interesting web based app development interface, https://github.com/arclanguage/anarki/blob/master/lib/prompt...

It looks quite humble but it has both a repl and an interface for saving/running various web apps.

I've set it to be enabled by default in Anarki. And it's only available for admins, because it can run system commands. I wonder if it would be possible to allow any user to develop apps securely, e.g. by disabling unsafe commands or sandboxing it somehow? Perhaps there is a simple way of doing that? It could open Arc web app development up to any user of an Anarki driven page.

I think those features mentioned above still need better documentation, too.

Other HN features that Anarki News is lacking:

* favourites

* hide item

* past front pages

* show all stories from same site by clicking on domain name

-----