Someone was kind enough to bring this to my attention:
http://www.youtube.com/v/4moyKUHApq4&hl=en&fs=1
PWUAUAUAHAHAHHHAHAHAHAHAUUAUAHAHAHHHAAAA!!!!!!!!!!
They released Adobe Adam in March, 2005. The above talk was given on
July 25th in 2007. My birthday. Coincidence? There are no coincidences.
Sean mentioned he is just beginning to get people at Adobe to listen.
And he is principal scientist and engineering manager. At Adobe.
I wonder if Pascal would trust their code: http://stlab.adobe.com/
PWUAHAHAHAHAHAHAHHAAA!!!!!!!
kenny
Kenny wrote:
> Someone was kind enough to bring this to my attention:
>
> http://www.youtube.com/v/4moyKUHApq4&hl=en&fs=1
>
> PWUAUAUAHAHAHHHAHAHAHAHAUUAUAHAHAHHHAAAA!!!!!!!!!!
>
> They released Adobe Adam in March, 2005. The above talk was given on
> July 25th in 2007. My birthday. Coincidence? There are no coincidences.
>
> Sean mentioned he is just beginning to get people at Adobe to listen.
> And he is principal scientist and engineering manager. At Adobe.
>
> I wonder if Pascal would trust their code: http://stlab.adobe.com/
>
> PWUAHAHAHAHAHAHAHHAAA!!!!!!!
>
> kenny
btw, Jon, you are needed over in the C++ forum. Parent disses your
language big time towards the end when asked about it. Lisp only
implicitly: he says he uses C++ because he needs to ship real applications.
Guess I better delete: http://www.theoryyalgebra.com/
Oh, and the bit about C++ being the best language for generic
programming... oh, my.
:)
kt
Kenny wrote:
> Kenny wrote:
>> Someone was kind enough to bring this to my attention:
>>
>> http://www.youtube.com/v/4moyKUHApq4&hl=en&fs=1
>>
>> PWUAUAUAHAHAHHHAHAHAHAHAUUAUAHAHAHHHAAAA!!!!!!!!!!
>>
>> They released Adobe Adam in March, 2005. The above talk was given on
>> July 25th in 2007. My birthday. Coincidence? There are no coincidences.
>>
>> Sean mentioned he is just beginning to get people at Adobe to listen.
>> And he is principal scientist and engineering manager. At Adobe.
>>
>> I wonder if Pascal would trust their code: http://stlab.adobe.com/
>>
>> PWUAHAHAHAHAHAHAHHAAA!!!!!!!
Oh, I forgot to mention: Sean estimates the code savings as two orders
of magnitude. This about a library the yobbos are proud to point out is
a pigment of my imagination and which they yawned over me talking about
it at ECLM 2008...PWUUAHAHAHAHAHAA... oh, I said that.
Looks like C++ will have it before Lisp! PWUAHA!
The funny thing is that C++ strangely wins here because I would never
claim two or even one order of magnitude for Cells. I would not even
measure it in LOC, more counts of the special form SETF.
kenny
ps. Man, how about those opening ceremonies? I loved the tai chi, been
doing that a bit at the beach, gotta do more. And the precision
choreography? Inconceivable. k
--
$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/
On Sat, 09 Aug 2008 03:04:16 -0400, <·········@gmail.com> wrote:
>
> I loved the tai chi, been doing that a bit at the beach, gotta do
> more.
Good Idea.
When I was taking a weekly class in Yang Long Form, I noticed how easy
it was to avoid bad collisions with people in a hurry. There were
a few other benefits too :-)
--
One of the strokes of genius from McCarthy
was making lists the center of the language - kt
** Posted from http://www.teranews.com **
On Aug 9, 9:04 am, Kenny <·········@gmail.com> wrote:
> Kenny wrote:
> > Kenny wrote:
>
> >> Someone was kind enough to bring this to my attention:
> >>
> >> http://www.youtube.com/v/4moyKUHApq4&hl=en&fs=1
> >>
> >> PWUAUAUAHAHAHHHAHAHAHAHAUUAUAHAHAHHHAAAA!!!!!!!!!!
> >>
> >> They released Adobe Adam in March, 2005. The above talk was given on
> >> July 25th in 2007. My birthday. Coincidence? There are no coincidences.
> >>
> >> Sean mentioned he is just beginning to get people at Adobe to listen.
> >> And he is principal scientist and engineering manager. At Adobe.
> >>
> >> I wonder if Pascal would trust their code:http://stlab.adobe.com/
> >>
> >> PWUAHAHAHAHAHAHAHHAAA!!!!!!!
>
> Oh, I forgot to mention: Sean estimates the code savings as two orders
> of magnitude. This about a library the yobbos are proud to point out is
> a pigment of my imagination and which they yawned over me talking about
> it at ECLM 2008...PWUUAHAHAHAHAHAA... oh, I said that.
>
> Looks like C++ will have it before Lisp! PWUAHA!
Who cares if they "get it" first; it'll look like shit and have tons
of
other problems that bubble up to _whatever_ they implement on top of C+
+
anyway.
http://yosefk.com/c++fqa/ .. x)
..anyway, I've added some small "state type" things for SymbolicWeb.
Nothing like Cells etc., and it's early but maybe interesting:
http://sw.nostdal.org/radio-button-app
http://sw.nostdal.org/checkbox-app
..and the source code for these:
http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/examples/radio-button.lisp
http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/examples/checkbox.lisp
..and the source code for the checkbox widget itself:
http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/src/widgets/checkbox.lisp
Its state can be serialized to the browser URL and history; cool? :)
Not-so-related, but here is a very early "site" I'm building using SW:
http://varefalne.no/ .. just to show that ajaxy stuff can really
maintain browser history and be "RESTful" or "bookmarkable".
PS: For now only IE6+ and FF2+ is supported; but things work somewhat
on
web-kit based browsers and Opera too.
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune N�stdal wrote:
> On Aug 9, 9:04 am, Kenny <·········@gmail.com> wrote:
>> Kenny wrote:
>> > Kenny wrote:
>>
>> >> Someone was kind enough to bring this to my attention:
>> >>
>> >> http://www.youtube.com/v/4moyKUHApq4&hl=en&fs=1
>> >>
>> >> PWUAUAUAHAHAHHHAHAHAHAHAUUAUAHAHAHHHAAAA!!!!!!!!!!
>> >>
>> >> They released Adobe Adam in March, 2005. The above talk was given on
>> >> July 25th in 2007. My birthday. Coincidence? There are no coincidences.
>> >>
>> >> Sean mentioned he is just beginning to get people at Adobe to listen.
>> >> And he is principal scientist and engineering manager. At Adobe.
>> >>
>> >> I wonder if Pascal would trust their code:http://stlab.adobe.com/
>> >>
>> >> PWUAHAHAHAHAHAHAHHAAA!!!!!!!
>>
>> Oh, I forgot to mention: Sean estimates the code savings as two orders
>> of magnitude. This about a library the yobbos are proud to point out is
>> a pigment of my imagination and which they yawned over me talking about
>> it at ECLM 2008...PWUUAHAHAHAHAHAA... oh, I said that.
>>
>> Looks like C++ will have it before Lisp! PWUAHA!
>
> Who cares if they "get it" first; it'll look like shit and have tons
> of
> other problems that bubble up to _whatever_ they implement on top of C+
> +
> anyway.
Yeah, on cells-devel I said I did not think it would save C++. I just
like making fun of The Yobbos. The best part is that Cells (the idea) is
ineluctably the future of software (the title of Sean's talk, btw), so
someday they will have to bow before The Kenny. PWUAUHAHHHAAAAA!!!!!
>
> http://yosefk.com/c++fqa/ .. x)
>
>
> ..anyway, I've added some small "state type" things for SymbolicWeb.
> Nothing like Cells etc., and it's early but maybe interesting:
Yes, I can tell from your postings you are doing a fine job of achieving
many of the benefits of Cells. All roads lead to dataflow, I think. Both
Adam and Cells arose not from trying to be fancy but simply by trying to
mae it easier to program GUIs. You are like a galaxy in early stages of
its formation. Or something liek that.
OpenAIR (currently in a holding pattern) is tunnelling from the other
end, starting with Cells and layering on the Ajax. It's all good.
>
> http://sw.nostdal.org/radio-button-app
> http://sw.nostdal.org/checkbox-app
>
> ..and the source code for these:
> http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/examples/radio-button.lisp
> http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/examples/checkbox.lisp
>
> ..and the source code for the checkbox widget itself:
>
> http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/src/widgets/checkbox.lisp
>
> Its state can be serialized to the browser URL and history; cool? :)
And the history?! Scary cool!
>
> Not-so-related, but here is a very early "site" I'm building using SW:
> http://varefalne.no/ .. just to show that ajaxy stuff can really
> maintain browser history and be "RESTful" or "bookmarkable".
>
>
> PS: For now only IE6+ and FF2+ is supported; but things work somewhat
> on
> web-kit based browsers and Opera too.
Ah, WebKit! That was going to be the desktop implementation for OpenAIR.
Glad to hear it is a substandard.
kt
On Aug 9, 5:52 pm, Kenny <·········@gmail.com> wrote:
> Lars Rune Nøstdal wrote:
> > On Aug 9, 9:04 am, Kenny <·········@gmail.com> wrote:
> >> Kenny wrote:
> >> > Kenny wrote:
>
> >> >> Someone was kind enough to bring this to my attention:
>
> >> >> http://www.youtube.com/v/4moyKUHApq4&hl=en&fs=1
>
> >> >> PWUAUAUAHAHAHHHAHAHAHAHAUUAUAHAHAHHHAAAA!!!!!!!!!!
>
> >> >> They released Adobe Adam in March, 2005. The above talk was given on
> >> >> July 25th in 2007. My birthday. Coincidence? There are no coincidences.
>
> >> >> Sean mentioned he is just beginning to get people at Adobe to listen.
> >> >> And he is principal scientist and engineering manager. At Adobe.
>
> >> >> I wonder if Pascal would trust their code:http://stlab.adobe.com/
>
> >> >> PWUAHAHAHAHAHAHAHHAAA!!!!!!!
>
> >> Oh, I forgot to mention: Sean estimates the code savings as two orders
> >> of magnitude. This about a library the yobbos are proud to point out is
> >> a pigment of my imagination and which they yawned over me talking about
> >> it at ECLM 2008...PWUUAHAHAHAHAHAA... oh, I said that.
>
> >> Looks like C++ will have it before Lisp! PWUAHA!
>
> > Who cares if they "get it" first; it'll look like shit and have tons
> > of
> > other problems that bubble up to _whatever_ they implement on top of C+
> > +
> > anyway.
>
> Yeah, on cells-devel I said I did not think it would save C++. I just
> like making fun of The Yobbos.
hehe .. yeah x) .. it's a bit annoying how some people do not even
acknowledge that there is a problem.
Some say .. "keep it simple" .. "just don't do it" .. and yeah, that
will work when your goals and needs are simple in-themselves. But it
won't last. He mentions in the talk; as things grow in complexity,
things eventually turns into a network of objects that communicate.
> The best part is that Cells (the idea) is ineluctably the future of software (the title of Sean's talk, btw),
Yeah, I think in particular with concurrency and many cores becoming
the norm this will happen for sure.
Because, a single user using a GUI is async, but with many cores you
kinda got even more async "users" at the same time at many levels (not
only at the "GUI level"). So the problems with asyncness becomes
bigger than they already are. In those scenarios you're even more
unsure where things "come from" or when. The "network" or graph
becomes even more apparent here.
So that isolation thing with propagation through a graph or network
etc. he mentions .. something like that, it makes sense. We might need
more (language) constructs at a lower level though; maybe at or close
to hardware. I don't know; something like those circuits he shows in
his slides.
> so someday they will have to bow before The Kenny. PWUAUHAHHHAAAAA!!!!!
lol .. .. x)
> > http://yosefk.com/c++fqa/ .. x)
>
> > ..anyway, I've added some small "state type" things for SymbolicWeb.
> > Nothing like Cells etc., and it's early but maybe interesting:
>
> Yes, I can tell from your postings you are doing a fine job of achieving
> many of the benefits of Cells. All roads lead to dataflow, I think. Both
> Adam and Cells arose not from trying to be fancy but simply by trying to
> mae it easier to program GUIs. You are like a galaxy in early stages of
> its formation. Or something liek that.
Yeah, I'm searching. I think everyone is; none of us really are 100%
there yet. I've been mostly busy with other stuff though; ajax, comet,
http, browser history, javascript etc. -- in general trying to get
this low-level "web stuff" right before looking at how to hook widgets
together at a higher level.
> OpenAIR (currently in a holding pattern) is tunnelling from the other end, starting with Cells and layering on the Ajax. It's all good.
Yeah, exactly. I'm doing it the other way around. The "web stuff" and
ajax etc.etc. first without anything Cells'y. Trying to keep it as
simple and low-level and "to-the-point" as possible. Then later at a
"widget level", which I guess I'm getting started with now, I'll add
data-flow and Cells'y stuff.
> > PS: For now only IE6+ and FF2+ is supported; but things work somewhat
> > on web-kit based browsers and Opera too.
>
> Ah, WebKit! That was going to be the desktop implementation for OpenAIR.
> Glad to hear it is a substandard.
hehe .. I know how to implement support for this stuff for webkit/
safari/khtml(konqueror) also. I just haven't gotten to it yet. I think
FF and IE covers about 95% or so of web-users out there, so I'm OK
with this for now while working out other stuff.
When it comes to Opera I'll just give it some time because I know they
are working on fixing a bug that makes this stuff harder than it
should be (the window.location.replace(..) function is broken for
starts) -- and I'll just be wasting time creating a work-around for
that now.
--
Lars Rune Nøstdal
http://nostdal.org/
> hehe .. yeah x) .. it's a bit annoying how some people do not even
> acknowledge that there is a problem.
You have touched on something quite huge. Turing started it all. he had
these two or three primitives /we/ used to move these dots around on a
paper tape. The dots should have been moving themselves. Perhaps he
realized this and did the apple in a paroxysm of shame?
Now the yobbos cannot imagine any other paradigm other than the one in
which they are in control. I like to say fish do not know they swim.
Programmers do not know they are hand-executing dataflow as they write
all that code. One of my slides shows anguished puppeteers struggling
with the strings that control their mannequins. Programmers have been
doing it so long you cannot even point out to them that they are doing
it. They will not see it!
>
> Some say .. "keep it simple" .. "just don't do it" .. and yeah, that
> will work when your goals and needs are simple in-themselves. But it
> won't last. He mentions in the talk; as things grow in complexity,
> things eventually turns into a network of objects that communicate.
I came out of my seat at that one.
>
>> The best part is that Cells (the idea) is ineluctably the future of software (the title of Sean's talk, btw),
>
> Yeah, I think in particular with concurrency and many cores becoming
> the norm this will happen for sure.
Uh-oh. I have to do concurrency? Should be fun. At least we have the
dependency graph. But until Cells/3 there was no data integrity and most
things worked just fine. To avoid the performance penalty (death knell?)
of forever worrying about synchronization I would relax integrity in
|Cells| (parallel Cells) and then make synchronization an option which
can be avoided by coding with a fuzzy integrity mindset, ie writing
rules fully aware that data is arriving in different order and sometimes
inconsistent with each other but eventually they'll converge so sure,
launch that missile. Might be a bad example.
> Because, a single user using a GUI is async, but with many cores you
> kinda got even more async "users" at the same time at many levels (not
> only at the "GUI level"). So the problems with asyncness becomes
> bigger than they already are. In those scenarios you're even more
> unsure where things "come from" or when. The "network" or graph
> becomes even more apparent here.
I think I got away without integrity for so long because the propagation
was a mess but only transiently and the stable correct state was always
reached before the next redraw event. :) That kind of integrity chunking
provides a nice escape from forever worrying about synchronization.
>
> So that isolation thing with propagation through a graph or network
> etc. he mentions .. something like that, it makes sense. We might need
> more (language) constructs at a lower level though; maybe at or close
> to hardware. I don't know; something like those circuits he shows in
> his slides.
You are a better listener than I! But yes, Turing cocked it up:
computers are useful to us for building models, and nothing is more
fundamental to models than change, and dataflow paradigms manage change.
The easiest way to manage change is to implement in our computers the
mechanism of causation. datflow paradigms give data causal power over
other data. QfrickinED. Oh, sorry, I digressed. My point was: dataflow
is the only way to program computers, it should have been supported in
hardware from day one.
>
>> so someday they will have to bow before The Kenny. PWUAUHAHHHAAAAA!!!!!
>
> lol .. .. x)
>
>>> http://yosefk.com/c++fqa/ .. x)
>>> ..anyway, I've added some small "state type" things for SymbolicWeb.
>>> Nothing like Cells etc., and it's early but maybe interesting:
>> Yes, I can tell from your postings you are doing a fine job of achieving
>> many of the benefits of Cells. All roads lead to dataflow, I think. Both
>> Adam and Cells arose not from trying to be fancy but simply by trying to
>> mae it easier to program GUIs. You are like a galaxy in early stages of
>> its formation. Or something liek that.
>
> Yeah, I'm searching. I think everyone is; none of us really are 100%
> there yet. I've been mostly busy with other stuff though; ajax, comet,
> http, browser history, javascript etc. -- in general trying to get
> this low-level "web stuff" right before looking at how to hook widgets
> together at a higher level.
This is why you must show this to the most important person you can find
in the largest school system you can get to easily:
http://www.theoryyalgebra.com/
The revenue from that will finance the dataflow army so we can work on
Nothing Else.
:)
kt
--
$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/
Kenny <·········@gmail.com> writes:
>> hehe .. yeah x) .. it's a bit annoying how some people do not even
>> acknowledge that there is a problem.
>
> You have touched on something quite huge. Turing started it all. he had
> these two or three primitives /we/ used to move these dots around on a
> paper tape. The dots should have been moving themselves. Perhaps he
> realized this and did the apple in a paroxysm of shame?
Apropos: Does anyone know a primitive calculus like the Turing Machine or
the Lambda Calculus based on dataflow ideas?
Nicolas
Nicolas Neuss wrote:
> Kenny <·········@gmail.com> writes:
>
>>> hehe .. yeah x) .. it's a bit annoying how some people do not even
>>> acknowledge that there is a problem.
>> You have touched on something quite huge. Turing started it all. he had
>> these two or three primitives /we/ used to move these dots around on a
>> paper tape. The dots should have been moving themselves. Perhaps he
>> realized this and did the apple in a paroxysm of shame?
>
> Apropos: Does anyone know a primitive calculus like the Turing Machine or
> the Lambda Calculus based on dataflow ideas?
Well, I'm not smart like you people, but Parent offers this:
"The most ambitious library, Adam, stems from the intuition that the
logic behind a simple human interface can be distilled to a function:
f(x) -> x'"
What the hell does that mean?
kt
--
$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/
Kenny <·········@gmail.com> writes:
> "The most ambitious library, Adam, stems from the intuition that the
> logic behind a simple human interface can be distilled to a function:
>
> f(x) -> x'"
>
> What the hell does that mean?
I guess it means that a user interface allows the user to choose a f
and to choose a x, to let the computer compute f(x) and display the
result x'.
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Pascal J. Bourguignon wrote:
> Kenny <·········@gmail.com> writes:
>> "The most ambitious library, Adam, stems from the intuition that the
>> logic behind a simple human interface can be distilled to a function:
>>
>> f(x) -> x'"
>>
>> What the hell does that mean?
>
> I guess it means that a user interface allows the user to choose a f
> and to choose a x, to let the computer compute f(x) and display the
> result x'.
>
Ah, yes, a succinct way of describing the GUI model "pick a noun (by
clicking on it or tabbing to it) and then pick a verb (with a menu or a
keychord)" and the system will do something.
And Parent is striving for the functional thing one senses when working
with a declarative paradigm, each rule being a standalone declarative
expression of what should be given what is.
In the talk SP mentions that he got the STL guy to write a book
explaining STL, and I gather Adam is an STL beast (is anything
interesting in C++ done with STL given C++'s general turgidity?)...
maybe Adam will become a C++ standard and then maybe dataflow will come
to dominate the programming ecosystem because in C++ the paradigm offers
a 100x improvement and in Lisp it is only 10x.
And Adam will have been documented. :)
kenny
--
$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/
>
> And Adam will have been documented. :)
>
> kenny
>
> --
>
> $$$$$:http://www.theoryyalgebra.com/
> Cells:http://common-lisp.net/project/cells/
> BSlog:http://smuglispweeny.blogspot.com/
Adam and Eve are DSL's <em>currently</em> implemented in C++...
On Aug 9, 4:20 pm, Kenny <·········@gmail.com> wrote:
> > hehe .. yeah x) .. it's a bit annoying how some people do not even
> > acknowledge that there is a problem.
>
> You have touched on something quite huge. Turing started it all. he had
> these two or three primitives /we/ used to move these dots around on a
> paper tape. The dots should have been moving themselves. Perhaps he
> realized this and did the apple in a paroxysm of shame?
>
> Now the yobbos cannot imagine any other paradigm other than the one in
> which they are in control. I like to say fish do not know they swim.
> Programmers do not know they are hand-executing dataflow as they write
> all that code. One of my slides shows anguished puppeteers struggling
> with the strings that control their mannequins. Programmers have been
> doing it so long you cannot even point out to them that they are doing
> it. They will not see it!
>
>
>
> > Some say .. "keep it simple" .. "just don't do it" .. and yeah, that
> > will work when your goals and needs are simple in-themselves. But it
> > won't last. He mentions in the talk; as things grow in complexity,
> > things eventually turns into a network of objects that communicate.
>
> I came out of my seat at that one.
>
>
>
> >> The best part is that Cells (the idea) is ineluctably the future of software (the title of Sean's talk, btw),
>
> > Yeah, I think in particular with concurrency and many cores becoming
> > the norm this will happen for sure.
>
> Uh-oh. I have to do concurrency? Should be fun. At least we have the
> dependency graph. But until Cells/3 there was no data integrity and most
> things worked just fine. To avoid the performance penalty (death knell?)
> of forever worrying about synchronization I would relax integrity in
> |Cells| (parallel Cells) and then make synchronization an option which
> can be avoided by coding with a fuzzy integrity mindset, ie writing
> rules fully aware that data is arriving in different order and sometimes
> inconsistent with each other but eventually they'll converge so sure,
> launch that missile. Might be a bad example.
>
> > Because, a single user using a GUI is async, but with many cores you
> > kinda got even more async "users" at the same time at many levels (not
> > only at the "GUI level"). So the problems with asyncness becomes
> > bigger than they already are. In those scenarios you're even more
> > unsure where things "come from" or when. The "network" or graph
> > becomes even more apparent here.
>
> I think I got away without integrity for so long because the propagation
> was a mess but only transiently and the stable correct state was always
> reached before the next redraw event. :) That kind of integrity chunking
> provides a nice escape from forever worrying about synchronization.
>
>
>
> > So that isolation thing with propagation through a graph or network
> > etc. he mentions .. something like that, it makes sense. We might need
> > more (language) constructs at a lower level though; maybe at or close
> > to hardware. I don't know; something like those circuits he shows in
> > his slides.
>
> You are a better listener than I! But yes, Turing cocked it up:
> computers are useful to us for building models, and nothing is more
> fundamental to models than change, and dataflow paradigms manage change.
> The easiest way to manage change is to implement in our computers the
> mechanism of causation. datflow paradigms give data causal power over
> other data. QfrickinED. Oh, sorry, I digressed. My point was: dataflow
> is the only way to program computers, it should have been supported in
> hardware from day one.
>
>
>
>
>
> >> so someday they will have to bow before The Kenny. PWUAUHAHHHAAAAA!!!!!
>
> > lol .. .. x)
>
> >>> http://yosefk.com/c++fqa/.. x)
> >>> ..anyway, I've added some small "state type" things for SymbolicWeb.
> >>> Nothing like Cells etc., and it's early but maybe interesting:
> >> Yes, I can tell from your postings you are doing a fine job of achieving
> >> many of the benefits of Cells. All roads lead to dataflow, I think. Both
> >> Adam and Cells arose not from trying to be fancy but simply by trying to
> >> mae it easier to program GUIs. You are like a galaxy in early stages of
> >> its formation. Or something liek that.
>
> > Yeah, I'm searching. I think everyone is; none of us really are 100%
> > there yet. I've been mostly busy with other stuff though; ajax, comet,
> > http, browser history, javascript etc. -- in general trying to get
> > this low-level "web stuff" right before looking at how to hook widgets
> > together at a higher level.
>
> This is why you must show this to the most important person you can find
> in the largest school system you can get to easily:
>
> http://www.theoryyalgebra.com/
>
> The revenue from that will finance the dataflow army so we can work on
> Nothing Else.
>
> :)
>
> kt
>
> --
>
> $$$$$:http://www.theoryyalgebra.com/
> Cells:http://common-lisp.net/project/cells/
> BSlog:http://smuglispweeny.blogspot.com/
One of the more interesting bits of hardware I've seen lately is the
Ambric multicore chips - up to 336 cores, with a dataflow IDE (hooking
up short chunks of a subset of Java, or assembly language), with core
to core communication being executable at clock cycle speeds:
essentially register of core one to register of core two. Very clean,
and the present implementation is at 130 nm, so they have a fair amoun
of low-hanging performance improvement waiting.
mayson wrote:
> On Aug 9, 4:20 pm, Kenny <·········@gmail.com> wrote:
>>> hehe .. yeah x) .. it's a bit annoying how some people do not even
>>> acknowledge that there is a problem.
>> You have touched on something quite huge. Turing started it all. he had
>> these two or three primitives /we/ used to move these dots around on a
>> paper tape. The dots should have been moving themselves. Perhaps he
>> realized this and did the apple in a paroxysm of shame?
>>
>> Now the yobbos cannot imagine any other paradigm other than the one in
>> which they are in control. I like to say fish do not know they swim.
>> Programmers do not know they are hand-executing dataflow as they write
>> all that code. One of my slides shows anguished puppeteers struggling
>> with the strings that control their mannequins. Programmers have been
>> doing it so long you cannot even point out to them that they are doing
>> it. They will not see it!
>>
>>
>>
>>> Some say .. "keep it simple" .. "just don't do it" .. and yeah, that
>>> will work when your goals and needs are simple in-themselves. But it
>>> won't last. He mentions in the talk; as things grow in complexity,
>>> things eventually turns into a network of objects that communicate.
>> I came out of my seat at that one.
>>
>>
>>
>>>> The best part is that Cells (the idea) is ineluctably the future of software (the title of Sean's talk, btw),
>>> Yeah, I think in particular with concurrency and many cores becoming
>>> the norm this will happen for sure.
>> Uh-oh. I have to do concurrency? Should be fun. At least we have the
>> dependency graph. But until Cells/3 there was no data integrity and most
>> things worked just fine. To avoid the performance penalty (death knell?)
>> of forever worrying about synchronization I would relax integrity in
>> |Cells| (parallel Cells) and then make synchronization an option which
>> can be avoided by coding with a fuzzy integrity mindset, ie writing
>> rules fully aware that data is arriving in different order and sometimes
>> inconsistent with each other but eventually they'll converge so sure,
>> launch that missile. Might be a bad example.
>>
>>> Because, a single user using a GUI is async, but with many cores you
>>> kinda got even more async "users" at the same time at many levels (not
>>> only at the "GUI level"). So the problems with asyncness becomes
>>> bigger than they already are. In those scenarios you're even more
>>> unsure where things "come from" or when. The "network" or graph
>>> becomes even more apparent here.
>> I think I got away without integrity for so long because the propagation
>> was a mess but only transiently and the stable correct state was always
>> reached before the next redraw event. :) That kind of integrity chunking
>> provides a nice escape from forever worrying about synchronization.
>>
>>
>>
>>> So that isolation thing with propagation through a graph or network
>>> etc. he mentions .. something like that, it makes sense. We might need
>>> more (language) constructs at a lower level though; maybe at or close
>>> to hardware. I don't know; something like those circuits he shows in
>>> his slides.
>> You are a better listener than I! But yes, Turing cocked it up:
>> computers are useful to us for building models, and nothing is more
>> fundamental to models than change, and dataflow paradigms manage change.
>> The easiest way to manage change is to implement in our computers the
>> mechanism of causation. datflow paradigms give data causal power over
>> other data. QfrickinED. Oh, sorry, I digressed. My point was: dataflow
>> is the only way to program computers, it should have been supported in
>> hardware from day one.
>>
>>
>>
>>
>>
>>>> so someday they will have to bow before The Kenny. PWUAUHAHHHAAAAA!!!!!
>>> lol .. .. x)
>>>>> http://yosefk.com/c++fqa/.. x)
>>>>> ..anyway, I've added some small "state type" things for SymbolicWeb.
>>>>> Nothing like Cells etc., and it's early but maybe interesting:
>>>> Yes, I can tell from your postings you are doing a fine job of achieving
>>>> many of the benefits of Cells. All roads lead to dataflow, I think. Both
>>>> Adam and Cells arose not from trying to be fancy but simply by trying to
>>>> mae it easier to program GUIs. You are like a galaxy in early stages of
>>>> its formation. Or something liek that.
>>> Yeah, I'm searching. I think everyone is; none of us really are 100%
>>> there yet. I've been mostly busy with other stuff though; ajax, comet,
>>> http, browser history, javascript etc. -- in general trying to get
>>> this low-level "web stuff" right before looking at how to hook widgets
>>> together at a higher level.
>> This is why you must show this to the most important person you can find
>> in the largest school system you can get to easily:
>>
>> http://www.theoryyalgebra.com/
>>
>> The revenue from that will finance the dataflow army so we can work on
>> Nothing Else.
>>
>> :)
>>
>> kt
>>
>> --
>>
>> $$$$$:http://www.theoryyalgebra.com/
>> Cells:http://common-lisp.net/project/cells/
>> BSlog:http://smuglispweeny.blogspot.com/
>
> One of the more interesting bits of hardware I've seen lately is the
> Ambric multicore chips - up to 336 cores, with a dataflow IDE (hooking
> up short chunks of a subset of Java, or assembly language), with core
> to core communication being executable at clock cycle speeds:
> essentially register of core one to register of core two. Very clean,
> and the present implementation is at 130 nm, so they have a fair amoun
> of low-hanging performance improvement waiting.
Dammit! Why wasn't I told?! Throw me a bone, people!
Now I just need to sucker the #lisp yobbos into porting SBCL to Ambric.
Given their cumulative IQ, how hard can that be?
:)
kz0
--
$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/
Kenny <·········@gmail.com> writes:
>> One of the more interesting bits of hardware I've seen lately is the
>> Ambric multicore chips - up to 336 cores, with a dataflow IDE (hooking
>> up short chunks of a subset of Java, or assembly language), with core
>> to core communication being executable at clock cycle speeds:
>> essentially register of core one to register of core two. Very clean,
>> and the present implementation is at 130 nm, so they have a fair amoun
>> of low-hanging performance improvement waiting.
>
> Dammit! Why wasn't I told?! Throw me a bone, people!
>
> Now I just need to sucker the #lisp yobbos into porting SBCL to
> Ambric. Given their cumulative IQ, how hard can that be?
No, they won't-a. What? You think you're some kind of Jedi, waving
your hand around like that? I'm a Toydarian, mind tricks don't work on
me. Only money. No money, no parts, no deal!
--
__Pascal Bourguignon__
P� Sat, 09 Aug 2008 01:13:40 +0200, skrev Kenny <·········@gmail.com>:
> Someone was kind enough to bring this to my attention:
>
> http://www.youtube.com/v/4moyKUHApq4&hl=en&fs=1
>
> PWUAUAUAHAHAHHHAHAHAHAHAUUAUAHAHAHHHAAAA!!!!!!!!!!
>
> They released Adobe Adam in March, 2005. The above talk was given on
> July 25th in 2007. My birthday. Coincidence? There are no coincidences.
>
> Sean mentioned he is just beginning to get people at Adobe to listen.
> And he is principal scientist and engineering manager. At Adobe.
>
> I wonder if Pascal would trust their code: http://stlab.adobe.com/
>
> PWUAHAHAHAHAHAHAHHAAA!!!!!!!
>
> kenny
Actually it frustrated the hell out of me! I only got through half.
Acyclic graph being the necessary for provability. What the hell is that?
Has he heard of the Boyer-More algorithm?
--------------
John Thingstad