Anyone want to explain that diagram of the while loop to me? The author apparently believes it is so self evident that he doesn't have to explain what any of the symbols or colors mean.
Still doesn't really help. What's the while loop actually doing? Where's the data being stored, and how do you get it out?
Similarly for his quicksort example (http://www.rebelscience.org/Cosas/quicksort.htm) - from what I can see, there's no means to input or output whatever you're sorting - that part is all internal, and the only accessible parts are 'start' and 'done'.
I think you need to drag your understanding and drop it onto his concepts. You're far too bogged down with all of this "seeing". When are you people going to stop just seeing, and start truly knowing? Drag and drop your mind. It's the way of the future.
"Why is motion in spacetime impossible? It has to do with the definitions of space and time and the equation of velocity v = dx/dt. What the equation is saying is that, if an object moves over any distance d x, there is an elapsed time d t. Since time is defined in physics as a parameter for denoting change (evolution), the equation for velocity along the time axis must be given as v = dt/dt which is self-referential. The self-reference comes from having to divide dt by itself. dt/dt always equals 1 because the units cancel out. This is of course meaningless as far as velocity is concerned."
You're never going to convince anybody of anything if you can't explain yourself without using jargon. To be fair though, it looks like he's written a lot on the subject so cherry-picking one piece out of context is going to cause confusion. The guy should write some kind of manifesto that anyone can understand.
I don't think it's possible to explain COSA such that we could understand it, because that would require designing it to an extent that its flaws would become obvious.
(Although Savain doesn't have time to finish designing COSA, he sure has plenty of time to write blog posts...)
I'm all in favor of alternate models of computing, or styles of programming, but this guy writes like he invented cold fusion or N-rays. I think he relishes his self-appointed status as an embattled minority/shunned Messiah.
This is not to say that his ideas are totally without merit. I'm sure there are problem domains well-suited to his approach. However, just like all previous One True Ways, it's unlikely to be always be the best way of doing things. He also glosses over important details like his claimed hardware support, and how you're supposed to construct non-trivial flow diagrams in practice.
I don't buy the argument that textual code is a remnant of our mathematical past and visual programming is the future. Surely our writing systems are just as text-based and yet, I don't see anyone proposing we supplant them with pictograms.
Aside from that, many problems are simply not suited to an event-based model, just as many problems are not suited to functional models and others are not suited to imperative models. There is not, and will never be, a one size fits all approach to development.
The reason software is so susceptible to errors is nothing to do with the model of its development, but rather that bugs can be "hidden" until the program is running, and commonly much longer after that. This is why you rarely get bugs in CSS, HTML or PNGs - the full results of modifications can be seen in near real time. When you do get bugs in HTML or CSS, they are browser issues or issues with resizing - things that are not immediately apparent.
Importantly, any programming environment sufficiently well equipped to be useful, will always have places to hide bugs. Event-based programming does nothing to address this, in fact I think it provide more bugs.
Man, this is the first time I've stumbled on a netkook page that doesn't have huge blocks of 28 point times new roman and blue underlined text that isn't links.
This entry scores very high on the crackpot index ( http://math.ucr.edu/home/baez/crackpot.html - replace some scientist notables with computer-science notables) and is generally just funny.
It did make me start to think though about one reason I enjoy computer science (or the engineering side more specifically) - it tends to be much easier to get traction on good ideas than many other fields. For the most part, good ideas in computer science are self-evident, and easily adopted by practitioners. Too easily sometimes- without enough scientific method being applied. Of all scientific fields, computer science would be the _last_ one I'd accuse of engendering blindness to obviously good ideas. A cadre of older programmers dictating to the younger generation how to think about programming? Seriously, lol (:
Well, Savain would say, "If the Turing Computing Model is as awesome as computer scientists make it out to be, why doesn't it solve the parallel programming crisis?"
Hey, I remember that guy from posting crazy comments on ESRs blog. He has got stome great stoff on "Artificial Intelligence From The Bible": http://www.rebelscience.org/Seven/bible.html
20 comments
[ 3.8 ms ] story [ 58.3 ms ] threadSimilarly for his quicksort example (http://www.rebelscience.org/Cosas/quicksort.htm) - from what I can see, there's no means to input or output whatever you're sorting - that part is all internal, and the only accessible parts are 'start' and 'done'.
"Why is motion in spacetime impossible? It has to do with the definitions of space and time and the equation of velocity v = dx/dt. What the equation is saying is that, if an object moves over any distance d x, there is an elapsed time d t. Since time is defined in physics as a parameter for denoting change (evolution), the equation for velocity along the time axis must be given as v = dt/dt which is self-referential. The self-reference comes from having to divide dt by itself. dt/dt always equals 1 because the units cancel out. This is of course meaningless as far as velocity is concerned."
(Although Savain doesn't have time to finish designing COSA, he sure has plenty of time to write blog posts...)
This is not to say that his ideas are totally without merit. I'm sure there are problem domains well-suited to his approach. However, just like all previous One True Ways, it's unlikely to be always be the best way of doing things. He also glosses over important details like his claimed hardware support, and how you're supposed to construct non-trivial flow diagrams in practice.
I don't buy the argument that textual code is a remnant of our mathematical past and visual programming is the future. Surely our writing systems are just as text-based and yet, I don't see anyone proposing we supplant them with pictograms.
Aside from that, many problems are simply not suited to an event-based model, just as many problems are not suited to functional models and others are not suited to imperative models. There is not, and will never be, a one size fits all approach to development.
The reason software is so susceptible to errors is nothing to do with the model of its development, but rather that bugs can be "hidden" until the program is running, and commonly much longer after that. This is why you rarely get bugs in CSS, HTML or PNGs - the full results of modifications can be seen in near real time. When you do get bugs in HTML or CSS, they are browser issues or issues with resizing - things that are not immediately apparent.
Importantly, any programming environment sufficiently well equipped to be useful, will always have places to hide bugs. Event-based programming does nothing to address this, in fact I think it provide more bugs.
http://rebelscience.blogspot.com/2010/02/reliable-software-p...
It did make me start to think though about one reason I enjoy computer science (or the engineering side more specifically) - it tends to be much easier to get traction on good ideas than many other fields. For the most part, good ideas in computer science are self-evident, and easily adopted by practitioners. Too easily sometimes- without enough scientific method being applied. Of all scientific fields, computer science would be the _last_ one I'd accuse of engendering blindness to obviously good ideas. A cadre of older programmers dictating to the younger generation how to think about programming? Seriously, lol (: