Arc Forum | Wish list for a system / site / process for sharing hacks

Arc Forum

Wish list for a system / site / process for sharing hacks

1 point by CatDancer 5420 days ago | 2 comments

Here's my wish list for things that I'd like to be easy to do for sharing hacks and information about hacks. What would you like to have?

Publish a hack. I think, "hey, how about this?", I write a hack, I want to be able to publish it with a push of a button.

Download and use a hack. I see someone has published a hack, I want to be able to try it instantly.

Fix conflicts. Bureaucratic software tries to prevent libraries from conflicting with walls, rules, isolating systems, etc. The hacking approach is to make it easy to fix a conflict. So if I see that hacks A and B aren't working together, I want to be able to easily publish an A2 or B2 or hack C that fixes the problem.

See how a hack affects other hacks. For example, an automated example runner would take the input

  (/ 1 2)
  (obj a 1)

... and show the result

  1/2
  #hash((a . 1))

... in some other system or with some hack applied, I may get some other results

  0.5
  {a 1}

... this difference may be good or bad. If I'm thinking of trying some hacks A and B, I'll want to see if they'll have an effect on some hack C that I'm already using, and if C does work differently, decide for myself whether that change is something I want or not.

... an automated example runner is similar to unit testing and shares much of the same technology: automatically running code, displaying the result, setup and tear down, etc. A difference is that unit testing is prescriptive (a unit test says what the result is supposed to be) while example running is descriptive.

Share information about hack dependencies and conflicts. It may be well known that hack A0 needs hack B0 and C0

  (needs A0 (B0 C0))

I may also know that A0 also works with B1 and doesn't need C in that case, or that A0 also works with hack D9 and E2 without B or C.

  (needs A0 (or (B0 C0)
                (B1)
                (D9 E2)))

I want to be able to share my knowledge, even if I'm not the original author or publisher of these hacks.

Choose hacks sets. Suppose B1 conflicts with B0 and E2 conflicts with B1, but the other hacks don't conflict. Now I have a choice: if I want A0 with the B functionality and the D functionality, I can load (A0 B0 C0 D9 E2). Or, if I only care about A0 with the B functionality, I could load just (A0 B1) instead. I want to be able to see what my options are and to be able to easily choose one.

Share examples of using a hack. An example is a easy and powerful to show how a hack may be used, to help document a hack, or to show a problem with a hack. If I come up with an example, I want to be able to share that easily.

Share the (automated example runner) results of running an example in my environment. Suppose I see an example you've shared, and I try it, but -- guess what -- it doesn't work with my operating system, or in my version of Arc, or with the other hacks I'm using, or produces something different or even better. This is valuable information, and I'd like to be able to share it easily.

Share information about related hacks. Suppose I write a hack, and someone comes up with a new and improved version, I'd like to have a "see also" section that tells me and everyone about that related hack.

Share documentation for a hack. If someone has written a hack but hasn't made documentation for it, and I feel moved to write some documentation, I'd like to be rewarded by having it easy for me to push a button and share that documentation.

Share comments about a hack.

See all the information about a hack. If I'm interested in a hack, I'd like to see all the comments, documentation, related hacks, examples, dependencies, and conflicts that people have shared about that hack.

Have a system for rearranging or changing the presentation of information about a hack. With all this information that can be shared about a hack, popular hacks may end up with a cacophony of information, so I or someone else may want to rearrange the information, putting the most useful information at the top of the page, for example. Like a Wiki, anyone can change the presentation of the information, and we use regular Wiki social conventions to manage it. Unlike a Wiki in which the atoms (the indivisible parts) of editing is individual characters, the atoms would be the chunks of information supplied by people as described above.

1 point by shader 5420 days ago | link

Lots of those sound like reasonable ideas. It sounds like many of those could actually be stand alone systems. Your examples system, for instance, is something I have been planning on adding to the auto-documentation features that arc currently has.

It sounds like these ideas, and similar ones, can be broken down into three sections:

1) Auto documentation and help; Comes with arc for all functions and libraries. (i.e. tools like 'help, 'src 'fns, etc.)

2) Library loading system. Library meta-data, etc. Handles individual libraries and their details.

3) Web service for easy publishing and locating of hacks. Handles finding a hack, and the relationships between hacks on a global scale.

Part 1 can be done separately; it is rather decentralized and can be iteratively improved as it is not required by the others, nor does it require them. The more we work on it, the better a documentation system arc has. It can be worked on independently by multiple people. I will probably be spending most of my time working on these functions ;)

Part 2 and 3 require more standardization, and so need to be done with community oversight, but are still independent from eachother. I envision a library loading system similar to CatDancer's 'lib, that can work standalone like always, loading the new meta-data about dependencies, related hacks, history, etc. from a spefic internet location. Git might be useful here for keeping track of dev history, etc.

Part 3 more specifically would be a web service like news.arc, except it would be psv.arc, hsv.arc, or something. It would create a directory system for storing hacks, and support several apis and web hooks to allow people with proper authorization to publish and download hacks. It could be included with Anarki, and anyone could run their own hack server with minimal effort. This will probably be built last, as it depends on part 2.

With this web service, the functions created for part 2 can be extended to support the service, and find packages by searching a list of known hack servers. There could of course be an 'official' Anarki hack server, but it is just as well if we allow more than one. A centralized Anarki is practically an oxymoron anyway.

So, #1 can be done in place now, and includes extended documentation facilities, examples, etc, #2 is the structure for the library meta-data and the functions used to load it, and can probably be done in a lib in anarki as well. It may require it's own folder or branch. #3 is the web service, and probably the most involved of the three, and will require a separate branch or even repo.

-----

1 point by Adlai 5420 days ago | link

I just had an idea about fixing conflicts and better documentation of dependencies:

Rather than (or in addition to) documenting dependencies on libraries, we should document dependencies on specific functionalities. That would also give a clue about which parts of a library are being depended on. When a library is changed or updated, people would know exactly where to look for incompatibilities.

What made me think of this is mainly the dependency on pg's Arcn releases, and the way that arcfn.com documented the changes to Arc3. Comparing a list of functionalities changed, to a list of those depended upon, seems to me to be a quick way of pinpointing where compatibility issues can be fixed, or could arise in the future.

NOTE: I don't intend this as a way of keeping libs static. In other words, a few libraries depending on a certain functionality foo shouldn't require or pressure the producer of foo to maintain the same "interface". This is intended more as a way to streamline the conflict-resolution and updating of the code which depends on foo, when it does happen to change.

-----