Improvement proposals

[Bystroushaak]

Dne 19.6.2016 v 07:49 Russell Allen mail at russell-allen.com 
[self-interest] napsal(a):
 >
 > *- Official repo
 > *
 > You didn't mention the Self homepage selflanguage.org
 > <http://selflanguage.org> - is the expectation nowadays that projects
 > just use their github repo as the front page of their identity?

Depends on the project. In my mind, it is like the official 
„headquarters“ of the project, where all the action is.

I didn't mention the Self language web, because I had it blocked before 
(just one of the weird local proxy blocklists), so I didn't used it much.

 > In my defence when I set that up there weren't organisation pages on
 > github! i can certainly move it across to one if people think that would
 > be helpful.

It is just possibility, I don't want to force you into this.

 > *- Splitting repos
 > *
 > I have considered splitting up the repo into bits before but have been
 > worried about things getting out of sync. I can see the advantages
 > though. Maybe some sort of automatic build checking could help. The big
 > advantage is that it would become more apparent that there are various
 > Self subprojects which people might find interesting.

I think it would be really useful to at least move the documentation 
(handbook, papers) into separate repository.

 > *- Wiki
 > *
 > I've loved wikis since I first came across them, but my experience with
 > the squeak community wiki was that you ended up with a mass of
 > unstructured info of low value.

Yes, that happens. I would suggest moderation of the content outside 
„user pages“ by moderators.

 > Also the information seemed to become ’Trapped’ in the wiki and
 > forgotten.

This is good point. I think it depends on how good your indexes are. For 
example, wikipedia have excellent indexes and categories.

 > *- Internal documentation
 > *
 > Self has a mechanism to attach comments to objects and slots. I did a
 > html interface to that, I'll update it and put it back online.
 >
 > There's probably a lot of low hanging fruit in this area,
 > documentation-wise. It would keep documentation as close as possible to
 > what it describes.

That would be great.

 > *- Package management
 > *
 > The Self transporter was designed for a single team building an artefact
 > in a single tree. It's really good at that, but the design choices place
 > restrictions on it.
 >
 > I've made changes to show developing in multiple succeed trees, so that
 > is a solvable problem. It needs better integration with the gui.
 >
 > However the transporter works by destructively applying a set of slots
 > in a layer over the existing object tree. It's not undoable, so it won't
 > be plausible to unload modules in their current form.
 >
 > Modules should be considered like libraries in source form for a
 > developer to include in a compiled program, not modules for a runtime
 > system in the sense of apt or yum or rpm systems on Linux.
 >
 > If someone wants that sort of functionality then they'll need to do some
 > designing (and coding :)

Yep. This is huge project to do. You need versions and dependencies and 
to solve all sort of hard problems. But from my experience, this is also 
extremely useful for creating larger projects. I use it all the time in 
python and I myself created like 30 modules for other to use.

Relevant informations:

- 
https://www.reddit.com/r/programming/comments/45ftk1/so_you_want_to_write_a_package_manager/
- 
http://blog.ezyang.com/2014/08/the-fundamental-problem-of-programming-language-package-management/

 > *- General
 > *
 > The Self community is tiny. It's also a community of interest not a
 > project. I don’t think you should think of the community as a thing
 > which needs a direction and focus. It’s just a bunch of people. For this
 > type of situation you won’t get a clear signup to a big vision. You
 > might get help for specific tasks.

I am the last one who would want to direct and focus the community in 
sense of leadership and telling people what to do.

I think that it needs „information“ focusing, eg. public planning in 
form of talk about what people do and what people think needs to be 
done, and most importantly, putting this outside of the conference. In 
my experience, this helps the decentralized groups of people with 
decentralized leaderless organization of work without the need of 
explicit organization.

In my mind, this boils down to some kind of wiki with discussion. The c2 
wiki I mentioned is nice example of this approach, see

- http://c2.com/cgi/wiki?SelfLanguage

 > Self as a system clearly isn’t something you would base commercial
 > software on, except for fun. If you do then you would expect to be
 > writing large parts of infrastructure you get for free in something like
 > Python. That said, if you can afford it (in terms of time, money, focus)
 > then go for it!

Meh. I am just a poor coder, who managed to get a month of vacation in 
between two jobs. But from longer time perspective, I think I may manage 
to get more free time and I am willing to put it into Self.

 > I would say Self is a serious game, with a shoutout to Alan Kay’s
 > concept of serious play. Self is my musical instrument. My personal
 > focus would be on making it a better instrument. This is more so for me
 > as the other systems I work on increasingly are not *my* instruments but
 > someone else’s, Apple’s, Microsoft’s etc and they tell me what tunes I’m
 > allowed to play.

I think that Self is „good enough“. In my mind, what needs to be 
improved, because it is non-existent, is all other things that usually 
supports people who want to use the language.

There is huge focus towards improving of the language and VM itself, but 
almost non-exsitent focus towards other „infrastructure“ of the 
language. I think that this is what my email boils down to.

I don't want to look like I am saying that somebody should do something. 
I am willing to do my share of work, I just feel like I need discussion 
about the topics first.