Re: [fonc] New Bret Victor demos

[Randy Macdonald]

What about this: the first link points to a video.  At 11:35 of that 
video, a verbal and algebraic version of a problem are given.  My 
feeling is that they are subtly different, in that the algebraic version 
allows for 169 as a solution.  Actually, the fact that the verbal 
statement actually solves for x^2, not x, is of note as well.


On 5/29/2013 3:52 PM, Yoshiki Ohshima wrote:

On Wed, May 29, 2013 at 9:59 AM, karl ramberg  wrote:

Bret Victor have made available some nice demonstrations of uses of a _very_
Frank like system. In one he is visualizing Gezira and Nile by Dan Amelang

http://worrydream.com/#!/MediaForThinkingTheUnthinkable
http://worrydream.com/#!/DrawingDynamicVisualizationsTalk
http://worrydream.com/#!/MediaForThinkingTheUnthinkable

Thank you, Karl!

The first one and the third one seem to point to the same page.  Did
you meant to put a link to another page?

--
-- Yoshiki
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc




--

---
|\/| Randy A MacDonald   | If the string is too tight, it will snap
|\\| array...@ns.sympatico.ca|   If it is too loose, it won't play...
 BSc(Math) UNBF '83  | APL: If you can say it, it's done.
 Natural Born APL'er | I use Real J
 Experimental webserver  
<-NTP>{ gnat }-

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] photography and programming

[Randy MacDonald]

On 12/5/2012 4:34 PM, Casey Ransberger wrote:

We seem to have changed subjects:)

Fine then! If you can make the same camera, or a better one using less 
lenses, you win.


Thank you for your apology.


I'm a fan of the Hasselblad design. The detachable back end opens up a 
lot of possibilities. One possibility is to take test shots with the 
Polaroid back end, for e.g. a quick lighting test before moving on to 
the expensive film that goes into the standard back, wherein you can't 
even see what you've shot until you've developed it, which necessarily 
can't happen until after the shoot.
A lot of manipulation, now we have to factor in the experience of the 
user, and introduce a lot of artifacts that are germane to the process, 
not the subject.  The chemical nature of the development process gets 
brought in, for example.
Here's why this is on topic: if we can make a camera that's completely 
understandable by a single individual, but can't shoot anything but 
black and white (bear with me, I'm playing with words and concepts a 
bit) because development of color photos takes too long to be 
practical, with a design analogous to a Hasselblad, we can just swap 
out the back and end up with the FONC idea that optimizations can be 
kept separate from meaning and the math of the meaning in a modular 
way, and...


Now I'm going to do something which is arguably a bit mean: for as 
many lenses as your SLR eschews, is it easier for you to explain 
concretely to a novice (for example, a small child) what your SLR does 
than it is for me to explain how my Hasselblad works?


I have a feeling that explaining the actual optical chip is going to 
be something that's very difficult. Probably, if I tried to teach a 
kid how a camera works, my victim would have a working camera years 
before yours would have a real chip that could recognize a single 
pixel, and my game is mostly made out of a small hole in a milk carton.


For all of humankind doing decades of this stuff, I really wish it was 
the other way around. You should let me play with your SLR sometime:) 
but I'd honestly rather die developing film in a poorly ventilated 
darkroom than shoot with a camera that I am neither able, nor allowed 
to, understand.


Does that make sense?

Casey

P.S.

This is one of the better metaphors that I've seen on the list. Awesome!



---
|\/| Randy A MacDonald   | If the string is too tight, it will snap
|\\| array...@ns.sympatico.ca|   If it is too loose, it won't play...
 BSc(Math) UNBF '83  | APL: If you can say it, it's done.
 Natural Born APL'er | I use Real J
 Experimental webserver  
<-NTP>{ gnat }-

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] photography and programming

[Randy MacDonald]

If you can span the same space with fewer tools, that is good.  If you 
need >1 lens to cover all subjects, so be it.  It sounds like it is a 
problem of fit, not something independent of the problem space.  No need 
to discuss the benefits of SLR's, that is just stretching the analogy.




On 12/4/2012 10:16 PM, John Carlson wrote:

Wouldn't it be best to make programming a bit like single lens photography 
instead of dual (or triple) lens photography?  It would seem like the fewer 
lenses you use, the less likely it would be for one of them to be scratched.  
Unless somehow there was a compensating factor in the lenses.

My 2 bits.  Metaphor isn't quite right, but perhaps you see my point.

Where's my post-mature optimization?

John "Damn the torpedos, we're going full speed ahead and getting nowhere" 
Carlson

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc




--

---
|\/| Randy A MacDonald   | If the string is too tight, it will snap
|\\| array...@ns.sympatico.ca|   If it is too loose, it won't play...
 BSc(Math) UNBF '83  | APL: If you can say it, it's done.
 Natural Born APL'er | I use Real J
 Experimental webserver  
<-NTP>{ gnat }-

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Historical lessons to escape the current sorry state of personal computing?

[Randy MacDonald]

On 7/15/2012 2:48 PM, Tomasz Rola wrote:

Not really. Install Python, run interpreter and in black window type:

print "Hello world"

and you are done.

Or, install Racket, run it and in the interpreter subwindow type

(display "Hello world")

and you are done again. Even better, Racket comes with full IDE, so you
don't need to bother much with additional setups. Either write some
snippet into interpreter subwindow or longer piece into editor subwindow
and when you finish, click running man icon to run it.

It's that easy.

With APL, it's

'Hello World'



Of course, both languages require some reading/learning to be done before
one can program something more complicated. And in both cases, docs are
easily available and (IMHO) well written.



With the right learning, the problems can be big, but the APL doesn't 
have to be.


--
---
|\/| Randy A MacDonald   | If the string is too tight, it will snap
|\\| array...@ns.sympatico.ca|   If it is too loose, it won't play...
 BSc(Math) UNBF '83  | APL: If you can say it, it's done.
 Natural Born APL'er | I use Real J
 Experimental webserver http://mormac.homeftp.net/
<-NTP>{ gnat }-

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] The Web Will Die When OOP Dies

[Randy MacDonald]

@BGB, by the 'same end' i meant tranforming a statement into something 
that a flow control operator can act on, like if () {...} else {}  The 
domain of the execute operator in APL is quoted strings.  I did not mean 
that the same end was allowing asynchronous execution.



On 6/16/2012 1:23 PM, BGB wrote:

On 6/16/2012 10:05 AM, Randy MacDonald wrote:
@BGB, if the braces around the letters defers execution, as my 
memories of Perl confirm, this is perfect.  With APL, quoting an 
expression accomplishes the same end: '1+1'




no, the braces indicate a code block (in statement context), and it is 
the "async" keyword which indicates that there is deferred execution. 
(in my language, quoting indicates symbols or strings, as in "this is 
a string", 'a', or 'single-quoted string', where "a" is always a 
string, but 'a' is a character-literal).


in a expression context, the braces indicate creation of an ex-nihilo 
object, as in "{x: 3, y: 4}".


the language sort-of distinguishes between statements and expressions, 
but this is more relaxed than in many other languages (it is more 
built on "context" than on a strict syntactic divide, and in most 
cases an explicit "return" is optional since any statement/expression 
in "tail position" may implicitly return a value).



the letters in this case were just placeholders for the statements 
which would go in the blocks.


for example example:
if(true)
{
printf("A\n");
sleep(1000);
printf("B\n");
sleep(1000);
}
printf("Done\n");

executes the print statements synchronously, causing the thread to 
sleep for 1s in the process (so, "Done" is printed 1s after "B").


and, with a plain "async" keyword:
async {
sleep(1000);
printf("A\n");
}
printf("Done\n");

will print "Done" first, and then print "A" about 1 second later 
(since the block is folded into another thread).


technically, there is another operation, known as a join.

var a = async { ... };
...
var x = join(a);

where the "join()" will block until the given thread has returned, and 
return the return value from the thread.
generally though, a "join" in this form only makes sense with a single 
argument (and would be implemented in the VM using a special bytecode op).


an extension would be to implicitly allow multiple joins, as in:
join(a, b, c);//wait on 3 threads
except, now, the return value doesn't make much sense anymore, and 
likewise:

join(
async{A},
async{B},
async{C});
is also kind of ugly.

in this case, the syntax:
async! {A}&{B}&{C};
although, this could also work:
async! {A}, {B}, {C};

either would basically mean "async with join", and essentially mean 
something similar to the 3-way join (basically, as syntax sugar). it 
may also imply "we don't really care what the return value is".


basically, the "!" suffix has ended up on several of my keywords to 
indicate "alternate forms", for example: "a as int" and "a as! int" 
will have slightly different semantics (the former will return "null" 
if the cast fails, and the latter will throw an exception).



but, since I got to thinking about it again, I started writing up more 
of the logic for this (adding multiway join logic, ...).





On another note, I agree with the thesis that OO is just message passing:

  aResult ? someParameters 'messageName' to anObject ?? so, once 
'to' is defined, APL does OO.


I was thinking 'new' didn't fit, but

   'new' to aClass

convinced me otherwise.

It also means that 'object oriented language' is a category error.



my language is a bit more generic, and loosely borrows much of its 
current syntax from JavaScript and ActionScript.


however, it has a fair number of non-JS features and semantics exist 
as well.
it is hardly an elegant, cleanly designed, or minimal language, but it 
works, and is a design more based on being useful to myself.




On 6/16/2012 11:40 AM, BGB wrote:


I recently thought about it off-list, and came up with a syntax like:
async! {A}&{B}&{C}



--
---
|\/| Randy A MacDonald   | If the string is too tight, it will snap
|\\|array...@ns.sympatico.ca|   If it is too loose, it won't play...
  BSc(Math) UNBF '83  | APL: If you can say it, it's done.
  Natural Born APL'er | I use Real J
  Experimental webserverhttp://mormac.homeftp.net/
<-NTP>{ gnat }-


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] The Web Will Die When OOP Dies

[Randy MacDonald]

@BGB, if the braces around the letters defers execution, as my memories 
of Perl confirm, this is perfect.  With APL, quoting an expression 
accomplishes the same end: '1+1'



On another note, I agree with the thesis that OO is just message passing:

  aResult ← someParameters 'messageName' to anObject ⍝⍝ so, once 
'to' is defined, APL does OO.


I was thinking 'new' didn't fit, but

   'new' to aClass

convinced me otherwise.

It also means that 'object oriented language' is a category error.

On 6/16/2012 11:40 AM, BGB wrote:


I recently thought about it off-list, and came up with a syntax like:
async! {A}&{B}&{C}



--
---
|\/| Randy A MacDonald   | If the string is too tight, it will snap
|\\| array...@ns.sympatico.ca|   If it is too loose, it won't play...
 BSc(Math) UNBF '83  | APL: If you can say it, it's done.
 Natural Born APL'er | I use Real J
 Experimental webserver http://mormac.homeftp.net/
<-NTP>{ gnat }-

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] The Web Will Die When OOP Dies

[Randy MacDonald]

On 6/10/2012 1:15 AM, BGB wrote:
meanwhile, I have spent several days on-off pondering the mystery of 
if there is any good syntax (for a language with a vaguely C-like 
syntax), to express the concept of "execute these statements in 
parallel and continue when all are done".

I believe that the expression in Dyalog APL is:

⍎&¨statements

or

{execute}{spawn}{each}statements.

--
---
|\/| Randy A MacDonald   | If the string is too tight, it will snap
|\\| array...@ns.sympatico.ca|   If it is too loose, it won't play...
 BSc(Math) UNBF '83  | APL: If you can say it, it's done.
 Natural Born APL'er | I use Real J
 Experimental webserver http://mormac.homeftp.net/
<-NTP>{ gnat }-

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc