Re: [fonc] Formation of Noctivagous, Inc.

2013-09-22 Thread John Pratt

Is it really hard to read?  It's not.


On Sep 21, 2013, at 1:43 PM, David Barbour wrote:

 I can't comment on the content because I couldn't read it. You are welcome to 
 your self-defeating attitude AND the lint in your pocket. Good luck, Pratt.
 
 On Sep 21, 2013 10:59 AM, John Pratt jpra...@gmail.com wrote:
 Considering that you didn't even comment on what the website is
 before criticizing it, I don't give a fuck if your eyes bleed.
 
 On Sep 21, 2013, at 12:56 PM, David Barbour wrote:
 
 Can you change the font on that website? My eyes are bleeding.
 
 
 On Sat, Sep 21, 2013 at 9:49 AM, John Pratt jpra...@gmail.com wrote:
 
 In the process of learning programming to form Noctivagous, Inc.
 I came to question fundamental computing science, specifically
 how the programs are laid out.  I am, however, interested in anyone
 who wishes to work on my newest project, 1draw33, which I announced
 first on the FONC list, in 2012.  The website, if people are interested,
 is
 http://noctivagous.com
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc
 
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc
 
 
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc
 
 ___
 fonc mailing list
 fonc@vpri.org
 http://vpri.org/mailman/listinfo/fonc

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


Re: [fonc] Formation of Noctivagous, Inc.

2013-09-22 Thread Josh Grams
On 2013-09-21 08:11PM, John Pratt wrote:

Is it really hard to read?  It's not.

I found it pretty hard to read.  I got through about two of the
sections of text before I gave up.

I could certainly fight my way through it if I had to, but...I'm
sorry; your stuff may be great, but there's too much interesting
stuff out there for me to have much incentive to spend effort on
things with that painful of a presentation...

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


Re: [fonc] Formation of Noctivagous, Inc.

2013-09-22 Thread Tom Lieber
Is this an anti-aliasing problem? I can read it fine on OS X, which it
looks like John also uses.


On Sun, Sep 22, 2013 at 6:24 AM, Josh Grams j...@qualdan.com wrote:

 On 2013-09-21 08:11PM, John Pratt wrote:
 
 Is it really hard to read?  It's not.

 I found it pretty hard to read.  I got through about two of the
 sections of text before I gave up.

 I could certainly fight my way through it if I had to, but...I'm
 sorry; your stuff may be great, but there's too much interesting
 stuff out there for me to have much incentive to spend effort on
 things with that painful of a presentation...

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




-- 
Tom Lieber
http://AllTom.com/
http://infinite-sketchpad.com/
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Personal Programming Environment as Extension of Self

2013-09-22 Thread David Barbour
Mark,

You ask some good questions! I've been taking some concrete actions to
realize my vision, but I haven't much considered how easily others might
get involved.

As I've written, I think a tactic concatenative (TC) language is the key to
making it all work great. A TC language can provide a uniformly safe and
simple foundation for understanding and manipulating streaming updates.
User actions must be formally translated to TC commands, though I can start
at a higher level and work my way down. However, the artifacts constructed
and operated upon by this language must be concretely visualizable,
composable, and manipulable - e.g. documents, diagrams, graphs, geometries.
Homoiconic this is not.

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 to my interest in AR and VR environments,
and Meta's support for Unity.)

I would very much favor a lightweight toolkit approach, similar to what the
REBOL/Red community has achieved -fitting entire desktops and webservices
as tiny apps built upon portable OS/runtime ( 1MB).  BTW, if you are a big
believer in tools, I strongly recommend you look into what the
REBOLhttp://www.rebol.com/what-rebol.htmlcommunity has achieved, and
its offshoot
Red http://www.red-lang.org/p/about.html. These people have already
achieved and commercialized a fair portion of the FoNC ideals through their
use of dialects. They make emacs look like a bloated, outdated, arcane
behemoth.

(If REBOL/Red used capability-based security, pervasive reactivity, live
programming, strong types, substructural types, external state, and...
well, there are a lot of reasons I don't favor the languages. But what
they've accomplished is very impressive!)

I think the toolkit approach quite feasible. ABC is designed for continuous
reactive behaviors, but it turns out that it can be very effectively used
for one-off functions and imperative code, depending only on how the
capability invocations are interpreted. ABC can also be used for efficient
serialization, i.e. as the protocol to maintain values in a reactive model.
So it should be feasible to target Unity or build my own visualization/UI
toolkit. (ABC will be relatively inefficient until I have a good compiler
for it, but getting started should be easy once ABC is fully defined and
Agda-sanitized.)

Best,

Dave


On Sep 21, 2013 10:52 PM, Mark Haniford markhanif...@gmail.com wrote:

 David,

 Great Writeup.  To get down to more practical terms for laymen software
 engineers such as myself,  what can we do in immediate terms to realize
 your vision?

 I'm a big believer in tools( even though I'm installing emacs 24 and
 live-tool).  Is there currently a rich IDE environment core in which we can
 start exploring visualization tools?

 Here's what I'm getting at. We have rich IDEs (in relative terms),
 Intellij, Resharper, VS, Eclipse, whatever..  I think they are still very
 archaic in programmer productivity.  The problem I see is that we have a
 dichotomy with scripting ennviroments (Emacs) as opposed to heavy IDEs.
  e.g.  we can't easily script these IDEs for expermination.

 thought?




 I find myself agreeing with most of your intermediate reasoning and then
 failing to understand the jump to the conclusion of tactic concatenative
 programming and the appeal of viewing user interfaces as programs.


 Tacit concatenative makes it all work smoothly.

 TC is very effective for:
 * automatic visualization and animation
 * streaming programs
 * pattern detection (simple matching)
 * simple rewrite rules
 * search-based code generation
 * Markov model predictions (user anticipation)
 * genetic programming and tuning
 * typesafe dataflow for linear or modal

 Individually, each of these may look like an incremental improvement that
 could be achieved without TC.

 But every little point, every little bit of complexity, adds up, pushing
 the system beyond viable accessibility and usability thresholds.

 Further, these aren't little points, and TC is not just marginally
 more effective. Visualization and animation are extremely important.
 Predicting and anticipating user actions is highly valuable. Code
 extraction from history, programming by example, then tuning and optimizing
 this code from history are essential. Streaming commands is the very
 foundation.


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