A thought about bytecode: One problem with distributing things in a
compiled version is that it doesnt really afford collaboration. If the
primary means of distribution instead would be the source as such it's much
easier to debug and fix issues discovered in imported modules. If something
like a
David Barbour dmbarb...@gmail.com writes:
My own plan is to implement a streamable, strongly typed, capability-secure
TC bytecode (Awelon Bytecode, ABC) and build up from there, perhaps
targeting Unity and/or developing a web-app IDE for visualization. (Unity
is a tempting target for me due
Chris,
You offer a lot of good advice. I agree that dog-fooding early would be
ideal.
Though for UI, I currently favor one of two directions:
* web apps
* OpenGL (perhaps just a subset, the WebGL API)
I also want to address these in a manner more compatible with reactive
programming.
Pavel,
I'm interested in collaborators. But the very first help I'd need is
administrative - figuring out how to effectively use collaborators. ;)
Regarding names: I think it best if names have an explicit lookup
mechanism. I.e. names aren't documentation, they're more like an index in a
map. If
When a font is hard to read, I use [Ctrl +].
So I did read the whole page. I didn't found it appealing, for one
silly reason. Despite the pretty picture and the sales pitch…
…I haven't the slightest idea _how_ this program is used.
Loup.
On Sun, Sep 22, 2013 at 10:05:58AM -0400, Tom Lieber
Okay, so if I understand correctly you want everyone to see the same thing,
and just deal with the collisions when they occur.
You also plan to mitigate this by using some visual indicators when that
word doesn't mean what you think it means. This would require search
before rendering, but
Ambiguity in English is often a problem. The Artist vs. Cowboy example
shows that ambiguity is in some cases not a problem. I think it reasonable
to argue that: when the context for two meanings of a word is obviously
different, you can easily disambiguate using context. The same is true for
Don't forget that words can be images, vector graphics or 3D graphics. If
you have an open system, then people will incorporate names/symbols. I'm
not sure you want to avoid symbolic processing, but that's your choice.
I'm reminded of the omgcraft ad for cachefly.
John
On Sep 23, 2013 8:11 PM,
I think it's fine if people model names, text, documents, association
lists, wikis, etc. -- and processing thereof.
And I do envision use of graphics as a common artifact structure, and just
as easily leveraged for any explanation as text (though I imagine most such
graphics will also have text
I don't really have a big concern. If you just support numbers, people
will find clever, but potentially incompatible ways of doing strings. I
recall in the pre-STL days supporting 6 different string classes. I
understand that a name is different than a string, but I come from a perl
Oh, I see. As I mentioned in the first message, I plan on UTF-8 text being
one of the three basic types in ABC. There is text, rational numbers, and
blocks. Even if I'm not using names, I think text is very useful for tagged
values and such.
{Hello, World!}
Text is also one of the problems
11 matches
Mail list logo
