The current western culture puts a lot of value in ideas. The famous inventors are viewed as heroes that saved the mankind. The institution of a patent office and other "intellectual property laws" are designed to guarantee that whoever comes with a certain idea first, will profit from merely recording and sharing it to the end of their lives, and even decades after death. At the same time, the process of inventing something is portrayed as a single moment of insight, after which you can just relax and live happy forever after. It's like winning on a lottery -- as long as you don't lose your lottery ticket, or give it away, you are set.
I think this is all a fairy tale at best. Dangerous lies at worst.
In reality, most ideas are worthless. I can have dozens of ideas per minute, hundreds per hour. I can't even afford to record all of them, not to mention doing anything useful with them. And that's just my own ideas. If I wanted to listen to all ideas of the people around me -- to understand each one and evaluate them -- I'd be drowned in a huge noise. And no, they are not all old ideas repeated and rehashed -- they are all original like snowflakes, there are no two alike. And like snowflakes, there are gazillions of them, and new ones keep on coming.
In real life people work hard to protect against the flood of ideas. We carefully choose the friends to listen to and trust, the books and magazines to read. We run quickly past soapbox preachers on the street. We try to outsource the hard work of deciding what is a good idea by relying on others -- politicians, authorities, religious leaders.
An of course, behind the question about publishing lies an assumption that by publishing you gain something: a chance on collaborating on the idea growing, or at least filtering.
I'm sure that some pattern-language wikis, like C2, make it occasionally possible: by inviting people to share their experiences related to the topic.
I think everything that is on the web helps in the IncidentalCollaboration.
By making our thoughts visible on the web, people might not directly tell us something, but when they see our thoughts, and then other people's thoughts, and still other people's thoughts, and start drawing conclusions based on the similarity, and speaking to those thoughts, ...
I would post notes that people can't understand, because: SpeakingEdge does function. If you've read enough of something, you can read 2 paragraphs of an explanation, and, even though they're using words you haven't heard before, -- you can pick out enough to say, "Yeah, I know what they mean, I know what they're talking about." (CommonContext functions.) "They're about to say blah blah blah, and I'll bet they'll make up word X to explain it." And sure enough, you continue reading it, and there's word X, or something like it.
Because you've been going through the same types of logic that haven't been articulated yet, but the pattern is laid down in our minds. It is like "PreForm," but for the HiveMind.
A really good book is: Myths of Innovation.
If you come up with 100s of ideas in an hour --
It may very well be that all of the ideas are "good." I don't see the "good/bad" success rate in terms of "...on a scale from 1 to 10," how good is this idea?
Rather, I see them more in terms of, "Do I have enthusiasm for this idea? Do I have the materials to make it happen soon? What are the first steps like? Is this idea combustable?"
If you're inspired, you can have a lot of really really great ideas. And they can all be good!
Like: I'm sure that Radomir, just in 5 minutes, can come up with at least 20 really cool images to draw.
And I think I'd like every single one of them. I think they're all good.
So, which one will become real? Maybe you'll use Tarot cards and dice to figure out which. :) Maybe one is speaking to you particularly, begging to be drawn. So that is the one that works.
I suppose it will be a while before I'm up to producing a drawing worth publishing. I didn't realize how easy it is to lose your edge. It's especially painful when you think you still can do it -- until you actually try. Oh well, back to practicing, I guess...
Yikes!
ヤバイって！これ一瞬で６万かせげたしｗｗｗｗｗ
http://inuchat.net/lv/xrl6xig
こんな簡単ならもっと早くやってりゃよかった(´д｀)
ヤバイって！これ一瞬で６万かせげたしｗｗｗｗｗ
http://inuchat.net/lv/gse3g40
こんな簡単ならもっと早くやってりゃよかった(´д｀)
(Article under discussion: http://www.communitywiki.org/en/ForumBoard )
(continuing discussion)
This is great -- this solves my question about "thinking in essays, rather than comments," -- as well. Post the essay on CW, and then comment here.
So the procedure is: Write an essay on CW. When we want to comment on it, create a thread here, and then link to the thread from the CW article. Link to the article at the beginning of the thread.
Yes? We'll see how it goes.
Hm, ... I think I just discovered a problem: Thread index numbers appear to change...
Wait, never mind that; It depends on the link.
http://board.sheep.art.pl/kareha.pl/1254589005/l50 May be consistent.
I had obtained a URL that uses a hash, somehow.
Yes, that's one way. But you don't necessarily have to create the page right away -- sometimes you are not sure which page a thread should go to, or consider creating a whole set of pages. You can discuss it in a single thread then.
At other times, you may create a thread about some refactoring you plan to do, like splitting a page into smaller parts, or joining several pages into a single article -- having the conversation detached from any particular page, or rather attachable to any of them, might make it easier. At least that's the theory.
You get that URL by clicking on the thread's heading.
Of course, some simple conveniences like using the same markup on the wiki and the board, and respecting the same page links and LocalNames could be added...
We could use FLOWS protocol to leave commands here, to push sections of discussion to wiki. I will work on this soon
<nod> Yes -- threads without pages, threads with one page, threads with multiple pages. Pages with no threads, pages with one thread, pages with multiple threads. It can work.
I implemented, what appears to me, a new way of parsing text. Python code.
The metaphor applied is to treat text as the base melody in a system of tracks, -- annotations to the melody. Compare: Track-based music editors.
So for example, you have a big long stream of bytes.
You make a channel called "lines," which has a track in the channel for each line.
So if you want to annotate a line, just attach data to the track instance for that line.
Then, you want to break the text into sections, so you make a new channel, and have a track for each section of the text. (Perhaps an H1 division, or something.)
Then you break the text into smaller sections.
I'm not sure I understand the meanings of "track" and "channel".
Let me try on an example. We have a stream of of bytes:
0101010101010101010101010101010101010101010101...Now, we add a channel, which is? Suppose it's another stream, going in parallel:
0101010101010101010101010101011010101010101010...
::::::::::::::::::::::::::::::::::::::::::::::...Now we add a track for every line. What is a track here? A stream within the "channel" stream?
Here's an example of a "Tracker":
http://www.youtube.com/watch?v=XoS8fWO_EOs
Here's a stream of bytes:
Text: H e l l o , W o r l d ! \n H o w a r e y o u ?
Lines:[--------------------------] [------------------------]
WS: [] [] [] [] []
Granted, this is a pedantic example.
For it to really be useful, you have tracks for sections of a document, for particular sequences within text, ...
An example of use is:
That didn't come out right, I'd need to use a fixed width font, or like you have done with the 1's and zeros.
Hello, World! How are you? <- text channel
:::::::::::::.:::::::::::: <- lines channel (2 tracks)
......:......:...:...:.... <- WS channel (4 tracks)
:::::..:::::..:::.:::.:::. <- words channel
You can attach data to the channels.
The code to make lines, for example, is:
cursor = tracker.cursor() # defaults to char reference
cursor.open("lines")
while not cursor.done()
It's silly to do here, but you can say:
tracker.channel("words").chars()
(returns:) ["Hello", "World", "How", "are", "you"]
tracker.channel("lines").children("words")
(returns:) [[<Track>, <Track>], [<Track>, <Track>, <Track>]]
[[x.chars() for x in L] for L in tracker.channel("lines").children(words)]
(returns:) [["Hello", "World"], ["How", "are", "you"]]]
Again, this is all rather silly when you're doing "Hello, world!", but when you have multi-sectioned documents, where the sections themselves contain different types of sub-sections (clearly delineated or otherwise,) these mechanics are lifesavers.
That's a pretty interesting way of storing the parse tree -- by recording the spans of branches at every level of the tree. How do you construct the tree (decide which tracks begin and end where) -- by multi-pass top-down scanning, starting at the root of the tree, and working down through more and more detailed tracks?
Multi-pass top-down scanning, essentially.
There's nothing saying you can't do single-pass with the assistance of a given grammar, and do it that way.
(I can imagine applying multiple grammars as well; So long as the channels they use don't over-ride one another.)
It's all about, "What's easiest? What makes most sense to me?" My files are almost all short, so I do not worry about performance -- rather, I'm far more concerned with how long it takes me to write a parser.
I'm interested in having both a person (myself, basically) and the computer (my program) being able to interact with the text -- hence my interest in round-tripping. So the data that is read is more like annotations to the text, rather than separate data structures. When the computer makes changes, they are re-applied in the places where they were recorded, and when the computer makes additions, they are generally applied at the end of the track that represents the structure as a whole.
I've written a Table class that reads tables into name & index accessible rows and columns, that is serialized back out exactly as it was serialized in, and that can be modified and have entries extended and so on. (A feature I'd like to add is the ability to have a "delete column," so that when an entry is deleted, it simply puts an "XX" in the delete column. That way, as a person, you can still read the text file and see the deleted column, and finally delete if you like, but so that it is not really required.)