[Repost of the
I would like to spur discussion about structure of the project and also
about the community, its organization and knowledge bases. I believe
that this discussion is really important for the future of Self development.
Self is open source, which is important, but not sufficient condition to
thrive. Open source success is only partially given by the license, but
more importantly by the community of people around projects. In the end,
it is the people what makes all the difference.
Self has somehow sleeping community, which I think is partially because
we don’t have good tools for communication and self-organization.
Here is what I think that would be useful:
Official Github organization
Github allows to create „organizations“, which is used to group multiple
projects under one „official“ entity.
Current state of Self on Github is confusing, especially for newcomers.
From what I understand, „official“ repository is the one in Russel
Allen’s personal account, but there is no „THIS IS OFFICIAL REPOSITORY,
CONTRIBUTE HERE“ sign. People have to figure this on their own and hope
that they didn’t figure it wrong.
I would also recommend to split the Self repository into several
smaller, single-purpose-oriented repositories. For example: separate the
handbook, and maybe application directory (git can do this
without the loss of history).
It would be probably good idea to decide if we want to allow anyone to
access this „organization“ and to let anyone add their own application
repositories. This would simplify the discovery of available Self
software. Other possibility is to use it only for „official“ stuff and
„syndicate“ Self packages somewhere else (wiki or package repository).
Talking to the people
We need to start to talk to the people. This is a problem that all
smaller projects have; there is too much context in your head (this is
relevant to the /bus factor/ from previous blog
The „THIS IS OFFICIAL REPOSITORY, CONTRIBUTE HERE“ sign is the classical
example of the context that everyone from the mail-list have. It was
posted few times into Self conference, but for anyone coming outside the
Self community, this is really hard to figure. You have to talk to
people, or they won’t know.
The Self wiki <https://github.com/russellallen/self/wiki> is another
example of this problem. There is no sign that there actually is a wiki.
I suggest to put a BIG animation with dancing whores ladies with „HELLO
FRIENDS, YOU ARE WELCOME HERE AND WE WANT YOUR CONTRIBUTION“ sign in
their hands to the README and to the homepage.
If you want something from the people (eg. contribution), you have to
tell them. They are not mindreaders and they won’t engage without
knowing that it is ok to engage.
For example, I pushed a lot of typo and RST formatting fixes to the Self
Handbook / Russel Allen’s git repository and I felt really uneasy doing
this. Is it okay to contribute? Is it okay to make changes in someone
15.12.2010, 09:55 Thorsten Dittmar written:
for me self is still one of the most beautiful languages I know, but the lib's are not so shapelily. So we have a kind of an Ugly Duckling here... a lady with amazing intrinsic values and horrible "lips"...
Of course, we can start with some cosmetics.. We can change the UI and other stuff, but for me that doesn't look like the right way... Self has so many unfinished stuff, that I guess we will not make it better to open another bottle.
What is /„unfinished stuff“/? What is the state of Self? Where is the
FAQ? Where is the screenshot section? Where is community knowledge base?
Where is documentation? Where is the detailed description of VM? Where
do you collect information?
Currently, only way to get a clear idea about Self and its state is to
read the mail archive
and the 115 thousands lines of C++ sources. Mail archive is the worst
possible database for this kind of stuff. Not only that history is not
easily accessible for newcomers, it also cannot be edited and improved.
Also attachments don’t work much.
We need good community Wiki, where we can:
* collect information about Self
* document the VM
* document aspects of programming in Self
o It is really hard to find any source code to study. There are
applications in Self’s git repository, but it took me 6 months
to notice. Again, there is no signs pointing to this.
* discuss various stuff about Self, ideas, improvements, highlights
and so on
* document what is in bad shape, what needs to be done and plan future
* provide user’s sections
o Something like a blog, but for all kinds of data, files,
snippets and information related to Self, that user’s may save
for benefit of themselves and others.
o This need to be under user’s control.
* have user profiles – some small section, where you may shortly
introduce yourself and maybe tell others what you do
o It is hard to tell who is working on the Self and what are they
doing. Again – this is context information which are not available.
* collect list of links to all relevant Self information sources
o I am willing to do this and maintain this section.
* collect list of links to Self alternative interpreters and inspired
o I partially did this in previous blog.
* tell people how to contribute, where to contribute and other
o Viz „Talking to the people“.
Wiki is important part of the plan to increase the Self’s bus factor
(see previous blog). It also helps people (newcomers especially) to put
themselves into perspective of what Self is, how to interact with
community and how to contribute.
I am willing to be maintainer of this Wiki. I don’t really want to, but
I have strong feeling, that if I am not going to do it, nobody will.
I don’t think it is a good idea to use this specific wiki software,
because to me, it looks like it is seriously limited in capabilities.
I like, that it uses the Git for synchronization, but I feel, that we
will need something more advanced. Something that will be able to host
large variety of content, categories and discussions. When I think about
it, I see it like the hybrid between the c2 wiki
<http://c2.com/cgi/wiki/FrontPage> and Wikipedia.
I don’t expect anyone to come with clear solutions, but I think that we
need to talk about this and look at alternatives. What do you think?
One of the services, which I think is critical for success of any
language is the package repository and package manager.
I am not that sure how easily this may be done for Self, but I am 100%
sure, that this is necessary for larger adoption;
We need to give people the tool, which will allow them to build
applications on top of other people libraries. Not just that – also the
place where we can discover new libraries and projects, instead of
having them scattered all over the Internet.
I have a lot of experiences with Python and believe me when I say, that
this is big win for the language and big reason to use it.
I know, that Self was a research language, and partially probably still
is. I will impersonate the Generic Beginner* and speak using his voice,
when I say:
I think that after 26 years, it is time to make up your mind. How do
you perceive Self? What is it to you? Do you take Self seriously, or
is this just a game?
I can’t build a product on Self in its current state. I can’t afford
to wait decades for improvements. I need to know, whether I can
count on you (the community).
I may put my time and/or resources into Self, but I need to know
that I won’t be wasting my time, and that I am not alone.
I want to know your opinion. It may be clear in your head, but again –
if you don’t talk to the people, they won’t know.
For me, this is NOT a game.
What about you?
*Not necessarily my opinion, but I think it comes to mind of all
newcomers looking at Self and thinking „hey, this looks nice, should I
[This is a copy of the blogpost: https://blog.selflanguage.org ]
have long maintained that Self is the finest Yak shaving system in existence. Everything is possible and nothing is finished :)
So I was playing with building a website front end for the mailing list archives, which led me to improving the Self web server, which led me to making a new experimental stream framework for Self. This also led me to some interesting ideas on automatically checking for methods which should be present in an object but aren’t, but I’ll write about that later!
Self already has a readStream and writeStream prototypes, which are very basic entities modelled largely on Smalltalk-80. They’re mainly used in the context reading and writing to files and sockets.
What I’ve put together is a quick stream framework for putting together pipelines of filters etc and streaming objects through them. The general aim is to avoid the technical and conceptual overhead of copying collections multiple times as you handle them.
This isn’t particularly groundbreaking, lots of other languages do this sort of thing. It’s a bit like Smalltalk’s Xtreams but much more minimal. I’d like to hear suggestions on how to make what I’ve done more elegant and Self-ish.
The code is at https://github.com/russellallen/flow
Basically, streams are entities which understand either readIfFail: or write:IfFail:. Streams can only be read or write.
Flow streams are composable, which means you can link them in a chain with pipeable connectors.
The relevant parts are in the global object ‘flow’.
This isn’t optimised at all – ideally streams should cheat by copying larger chunks behind the scenes where appropriate for performance. Also file streams probably need to be more aware of reading and writing chunks with internal buffers, and string writing should be optimised to reduce copying!
Possible improvements include adding spitting and merging pipes, specific buffering pipes etc.
Using flow streams is a two or three step process:
1 Build structure.
| myPipeline |
'This is a bit of text for us to play with' reading
|= (flow pipeable map copyOn: [|:c| c capitalize])
|= (flow pipeable filter copyOn: [|:c| c isVowel])
|= (flow pipeable gather copyOn: [|:c| (c & c) asList])
|= flow writable string copy.
2 Put pipeline into action
3 (Optionally) convert your stream into something else
[myPipeline contents = 'IIIIAAIIOOEEOOUUOOAAII'] assert.
And that’s about it. I’ll play with this some more, any suggestions?