Re: [fonc] Piumarta and Warth’s Open Objects in Scheme

[Julian Leviston]

Link broken.

Julian

http://www.getcontented.com.au/ - You Need GetContented - Make Websites, Not 
War!

> On 29 Oct 2014, at 5:55 pm, Kurt Stephens  wrote:
> 
> Something I threw together.  :)
> 
> http://devdriven.com/2014/10/piumarta-and-warths-open-objects-in-scheme/
> 
> -- KAS
> ___
> 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] Programming Language Theory Stack Exchange

[Julian Leviston]

Nope...

If you go here:
http://stackoverflow.com

...you'll notice that there's a clear heading saying "top questions", and it's 
very clear that there are questions and answers under that. Particularly the 
"Ask Question" button on its own. The structure, design and layout of the site 
informs the purpose very clearly.

Contrast this with the freeform wiki nature of LTU which doesn't really have a 
layout...

Julian.

http://www.getcontented.com.au/ - You Need GetContented - Make Websites, Not 
War!

On 28 Sep 2014, at 2:12 pm, Miles Fidelman  wrote:

> Silly question, perhaps, but isn't that true of a stack exchange site as well?
> 
> 
> Julian Leviston wrote:
>> I think because of a lack of overview. When you go there initially, you're 
>> immediately reading the latest article, which, if you understand the context 
>> and what the site is, is fine... but if you don't, then it can be confusing.
>> 
>> Julian
>> 
>> http://www.getcontented.com.au/ - You Need *GetContented *-**The Best Thing 
>> Since Sliced Websites! :)
>> 
>> On 28 Sep 2014, at 12:58 pm, Trevor Wennblom > <mailto:tre...@umn.edu>> wrote:
>> 
>>> How so Julian? Hehe.
>>> 
>>> On Sat, Sep 27, 2014 at 8:20 PM, Julian Leviston >> <mailto:jul...@leviston.net>> wrote:
>>> 
>>>Hehe that's interesting. I'd never associated LTU with modern
>>>languages. I'm not sure why. Possibly because of the archaic UX
>>>and UI. It's incredibly difficult to parse.
>>> 
>>>J
>>> 
>>>http://www.getcontented.com.au/ - You Need *GetContented *-**Get
>>>Your Website Happy. :)
>>> 
>>>On 28 Sep 2014, at 12:37 am, Miles Fidelman
>>>mailto:mfidel...@meetinghouse.net>>
>>>wrote:
>>> 
>>>>David Barbour wrote:
>>>>>A proposed stack exchange for programming language theory has
>>>>>reached commitment phase. It needs two hundred people. If
>>>>>you're interested in PL, please participate:
>>>>> 
>>>> 
>>>>For those not aware of it, the starting point for discussions of
>>>>programming language theory is http://lambda-the-ultimate.org/
>>>> 
>>>>Miles Fidelman
>>>> 
>>>>-- In theory, there is no difference between theory and practice.
>>>>In practice, there is.    Yogi Berra
>>>> 
>>>>___
>>>>fonc mailing list
>>>>fonc@vpri.org <mailto:fonc@vpri.org>
>>>>http://vpri.org/mailman/listinfo/fonc
>>>> 
>>> 
>>> 
>>>___
>>>fonc mailing list
>>>fonc@vpri.org <mailto:fonc@vpri.org>
>>>http://vpri.org/mailman/listinfo/fonc
>>> 
>>> 
>>> ___
>>> fonc mailing list
>>> fonc@vpri.org <mailto:fonc@vpri.org>
>>> http://vpri.org/mailman/listinfo/fonc
>> 
>> 
>> 
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
> 
> 
> -- 
> In theory, there is no difference between theory and practice.
> In practice, there is.    Yogi Berra
> 
> ___
> 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] Programming Language Theory Stack Exchange

[Julian Leviston]

I think because of a lack of overview. When you go there initially, you're 
immediately reading the latest article, which, if you understand the context 
and what the site is, is fine... but if you don't, then it can be confusing.

Julian

http://www.getcontented.com.au/ - You Need GetContented - The Best Thing Since 
Sliced Websites! :)

On 28 Sep 2014, at 12:58 pm, Trevor Wennblom  wrote:

> How so Julian? Hehe.
> 
> On Sat, Sep 27, 2014 at 8:20 PM, Julian Leviston  wrote:
> Hehe that's interesting. I'd never associated LTU with modern languages. I'm 
> not sure why. Possibly because of the archaic UX and UI. It's incredibly 
> difficult to parse.
> 
> J
> 
> http://www.getcontented.com.au/ - You Need GetContented - Get Your Website 
> Happy. :)
> 
> On 28 Sep 2014, at 12:37 am, Miles Fidelman  
> wrote:
> 
>> David Barbour wrote:
>>> A proposed stack exchange for programming language theory has reached 
>>> commitment phase. It needs two hundred people. If you're interested in PL, 
>>> please participate:
>>> 
>> 
>> For those not aware of it, the starting point for discussions of programming 
>> language theory is http://lambda-the-ultimate.org/
>> 
>> Miles Fidelman
>> 
>> -- 
>> In theory, there is no difference between theory and practice.
>> In practice, there is.    Yogi Berra
>> 
>> ___
>> 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] Programming Language Theory Stack Exchange

[Julian Leviston]

Hehe that's interesting. I'd never associated LTU with modern languages. I'm 
not sure why. Possibly because of the archaic UX and UI. It's incredibly 
difficult to parse.

J

http://www.getcontented.com.au/ - You Need GetContented - Get Your Website 
Happy. :)

On 28 Sep 2014, at 12:37 am, Miles Fidelman  wrote:

> David Barbour wrote:
>> A proposed stack exchange for programming language theory has reached 
>> commitment phase. It needs two hundred people. If you're interested in PL, 
>> please participate:
>> 
> 
> For those not aware of it, the starting point for discussions of programming 
> language theory is http://lambda-the-ultimate.org/
> 
> Miles Fidelman
> 
> -- 
> In theory, there is no difference between theory and practice.
> In practice, there is.    Yogi Berra
> 
> ___
> 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] Earley Parsing Explained (incomplete first draft)

[Julian Leviston]

On 19 Sep 2014, at 7:11 am, Loup Vaillant-David  wrote:

> Hi,
> 
> After spending months banging my head over Earley Parsing, I have
> decided to write a tutorial.  Ian once said Earley parsing is simple
> and easy to implement.  I agree with "simple", but not with "easy".
> The required background knowledge is not trivial.
> 

Easy is pretty subjective! What's easy to my a 6 year old is not going to be 
easy for a 50 year old, and vice versa.
Perhaps you mean approachable to someone of average intellect and cultural 
heritage?

> This tutorial is an attempt to gather this knowledge in one place.
> Nothing fancy, no deep math, no proof of correctness.  Just a
> (hopefully) intuitive explanation of the concepts, needed to implement
> Earley parsing.  The goal is to help competent programmers who know
> little about parsing to write their own Earley parsing framework.
> 
> So far, I have done most of the recogniser.  The following pages are
> "done", and up for review:
> 
> http://loup-vaillant.fr/tutorials/earley-parsing/
> http://loup-vaillant.fr/tutorials/earley-parsing/what-and-why
> http://loup-vaillant.fr/tutorials/earley-parsing/chart-parsing
> http://loup-vaillant.fr/tutorials/earley-parsing/recogniser
> 
> Questions and criticisms are most welcome.  I'd like to know about any
> factual inaccuracy, poor wording, confusing explanation… please don't
> hesitate to question anything, even the structure of this tutorial.
> 
> Enjoy, and thanks,
> Loup.


I really like your writing style!

One criticism I'd have is there aren't any pointers to people who don't have 
programming language construction backgrounds. So, perhaps adding a 
pre-requisite reading list at the beginning aimed at bringing someone who has 
finished high school and nothing else "up to speed"...

This is perhaps my general criticism of most technical work. The assumed 
knowledge is high, and it shouldn't be. As more and more people get involved in 
computing, this means there can be less and less assumed backgrounds. I wrote 
about good code and by extension good writing a while back here: 
http://www.genericoverlords.com/good_coding

Julian

http://www.getcontented.com.au/ - You Need GetContented - Get Your Website 
Happy. :)___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] A Happy Reminder that ...

[Julian Leviston]

I quite like the "promise" of what's been shown as Aurora. It seems very 
similar to a base for Frank ;-)

Aurora demo here:
https://www.youtube.com/watch?v=L6iUm_Cqx2s

I like that Aurora could potentially mean we could just stop making typing & 
syntax errors (because the language & ID understands what you can and can't say 
in the syntax of the language)

Julian

On 14 Apr 2012, at 5:07 am, David Nolen  wrote:

> ... our language environments need as much innovation as our languages. Very 
> Smalltalk-y & very fun:
> 
> http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/
> 
> David  
> ___
> 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] The Operating System is Out of Date

[Julian Leviston]

There was movement at the station:

http://davidad.github.io/blog/2014/03/12/the-operating-system-is-out-of-date/

Julian

http://www.getcontented.com.au/ - You Need GetContented - Now Anyone Can 
Website! :)

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

Re: [fonc] maru hg-to-git mirror on github

[Julian Leviston]

On 18 Jan 2014, at 7:25 pm, Attila Lendvai  wrote:

> 1 extend the level of my understanding of it
> 
> 2 use this process to shape the project to be easier to approach for
>   newcomers. then publish results with the hopes of integrating it
>   into the official repo eventually.

Hi Atila,

I just saw your "due to lack of interest" post about this thread. Don't be 
disenheartened. I'm quite interested in your effort. I don't have a heap of 
time to invest in this, but I wanted to get back to learning maru again and 
doing a similar thing at some stage, too. For me, the last time I tried, it was 
just too difficult because I didn't know enough LISP/scheme. Now I know a *lot* 
more, but I just need to get some chunks of time to work on learning it better 
(possibly).

So, suffice to say I'm very happy there are others working on the pedagogical 
aspects of maru. Thank you! Please don't think your efforts are in vain.

From,
Julian___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] quasiquoting in maru

[Julian Leviston]

On 27 Nov 2013, at 1:59 pm, Faré  wrote:

> If you're interested, there's experimentation and design to do, and
> probably a paper to publish.

Forgive me if I'm barking up the wrong tree, but wouldn't it be solved by not 
using text for source code?

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

Re: [fonc] Really nice presentation of the VPRI project

[Julian Leviston]

I'm curious, does Frank and its precursors (sub-cursors?) include sound, or 
only visual languages?

Julian

On 15 Nov 2013, at 5:13 pm, David Girle  wrote:

> Figure 1 of TR-2013-002, "KScript and KSWorld ... "  would appear to indicate 
> the headless piece of Frank might be 2-3,000 LOC ?  
> Would that be a possible first step to publish, before the full 10,000 LOC ?
> 
> david
> 
> 
> On Thu, Nov 14, 2013 at 10:48 AM, Yoshiki Ohshima  
> wrote:
> I still want to release Frank for example...  We revised the syntax of
> KScript during the its life time and still many parts of it is written
> in the old syntax.  Yes, it is about 10,000 lines of code, but it is
> still some work to convert them all.
> 
> A movie of demo would be good, yes.
> 
> Thank you for the interest!
> 
> On Mon, Nov 11, 2013 at 11:11 AM, Brian Rice  wrote:
> > Well, I certainly appreciate the effort and can fill in some details from
> > how long we've been tracking the project externally. That said, I look
> > forward to some more concrete and hopefully interactive details. Right now,
> > it's difficult for me to communicate this to others except in person with a
> > lot of hand-waving.
> >
> >
> > On Mon, Nov 11, 2013 at 10:43 AM, Yoshiki Ohshima 
> > wrote:
> >>
> >> At Sat, 9 Nov 2013 10:37:02 +0100,
> >> Loup Vaillant-David wrote:
> >> >
> >> >
> >> > I don't understand the first link... Am I supposed to find a video
> >> > recording there?
> >>
> >> There is no video recording but only the slides in the PDF file.  I'm
> >> afrait that some of the stuff in it may not make sense unless
> >> accompanied by commentary.
> >>
> >> -- Yoshiki
> >>
> >> > On Fri, Nov 08, 2013 at 01:12:24PM +0100, karl ramberg wrote:
> >> > > http://d.hatena.ne.jp/squeaker/20131103#p1
> >> > >
> >> > > http://tinlizzie.org/~ohshima/AGERE2013/AGERESlides.pdf  (33 Mb)
> >> > >
> >> > > Cheers,
> >> > > Karl
> >> >
> >> > ___
> >> > fonc mailing list
> >> > fonc@vpri.org
> >> > http://vpri.org/mailman/listinfo/fonc
> >> ___
> >> fonc mailing list
> >> fonc@vpri.org
> >> http://vpri.org/mailman/listinfo/fonc
> >
> >
> >
> >
> > --
> > -Brian T. Rice
> >
> > ___
> > fonc mailing list
> > fonc@vpri.org
> > http://vpri.org/mailman/listinfo/fonc
> >
> 
> 
> 
> --
> -- Yoshiki
> ___
> 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] Urbit, Nock, Hoon

[Julian Leviston]

http://www.urbit.org/2013/08/22/Chapter-0-intro.html

Interesting?

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

Re: [fonc] New Bret Victor demos

[Julian Leviston]

No.

The problem isn't that it's hard to express the abstract, the problem is it's 
hard to express the level of abstraction one is referencing simply without 
confusion.

Julian

On 03/06/2013, at 5:48 AM, shawnmorel  wrote:

>> It's pretty difficult to visually express "a class of objects" (or any 
>> concept that is meta to the concrete, really) unless you perhaps used the 
>> greek concept of icon, however we've overused that in computing such that an 
>> icon is now taken to mean the thing it's an icon for… 
> 
> Category theory seems to do a rather good job of expressing the abstract with 
> graphical notation no?
> 
> shawn
> 
> ___
> 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] New Bret Victor demos

[Julian Leviston]

He does run into some obvious issues expressing linguistic concepts visually, 
though, doesn't he? About 44:00 in, you can see that he has to explain that 
"fish" is just an example used to express a behaviour on *any* object.

It's pretty difficult to visually express "a class of objects" (or any concept 
that is meta to the concrete, really) unless you perhaps used the greek concept 
of icon, however we've overused that in computing such that an icon is now 
taken to mean the thing it's an icon for... 

It would seem he needs meta-icons, if there could be such a thing. I would use 
animation, or perhaps something even better (!) for this purpose. ;-) (Ironic, 
isn't it, considering he's explaining to the audience how he's using a new 
medium, and yet he's stuck in the old medium way of thinking still) ;-)

I do like that he's asking the questions, though :)

Julian

On 30/05/2013, at 5:37 AM, karl ramberg  wrote:

> Yes, I meant to link to the fish demo.
> Sorry about that.
> 
> Karl
> 
> 
> On Wed, May 29, 2013 at 9:19 PM, Norman Nunley  wrote:
> Maybe Karl meant to reference 'Stop Drawing Dead Fish'? 
> http://vimeo.com/64895205
> 
> Norman
> 
> 
> On Wed, May 29, 2013 at 2: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
> 
> 
> ___
> 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] Layering, Thinking and Computing

[Julian Leviston]

On 07/04/2013, at 1:48 PM, Tristan Slominski  
wrote:

> a lot of people seem to have the opinion the language a person communicates 
> in locks them into a certain way of thinking.
> 
> There is an entire book on the subject, "Metaphors We Live By", which 
> profoundly changed how I think about thinking and what role metaphor plays in 
> my thoughts. Below is a link to what looks like an article by the same title 
> from the same authors.
> 
> http://www.soc.washington.edu/users/brines/lakoff.pdf
> 
> 

Having studied linguistics, I can tell you there are MANY books on this 
subject. I can point to at least the following reference work on the topic:

http://mitpress.mit.edu/books/language-thought-and-reality

I wasn't interested in this discussion. I would agree that semi-educated 
ordinary man definitely thinks in language and it definitely shapes the 
thoughts that they're capable of, however what I'm talking about is really only 
found in people who speak more than two other languages than their "native" 
language, and/or in languages not touched by that "modern culture" (such as the 
Australian Aborigines "dreamtime" metalinguistic awareness).

I guess my question mostly relates to whether or not learning more languages 
than one, (perhaps when one gets to about three different languages to some 
level of proficiency and deep study), causes one to form a pre/post-linguistic 
awareness as I referenced in my original post.

I think learning only one language is bad for people who want to understand 
each other, and the same thing with programming languages. Less than 3 
languages doesn't allow one to "triangulate" meaning very well, perhaps even 
properly.

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

[fonc] Layering, Thinking and Computing

[Julian Leviston]

Something on the recent "discussion" titled "Natural Language Wins" got me 
thinking: a lot of people seem to have the opinion the language a person 
communicates in locks them into a certain way of thinking.

I'm interested in this with respect to programming languages. I've encountered 
numerous programmers in my life who only seem capable of thinking procedurally 
when it comes to programming, and yet can easily think non-procedurally in 
other affairs (such as using objects in their daily life, or writing maths 
functions).

Before I learned LISP at all, a lot of people told me it'd change the way I 
thought, but all it really did was make me aware of another programming 
language which was less locked in than the others.

I don't think in language. I think in visual and feeling/thought form-patterns 
- they're faster than language because they're smaller than language, and they 
come before the language rendering is formed. Perhaps I used to think in 
language when I only knew one language, but I don't remember doing so.

This is how I program, too. I find that programming languages express the 
patterns I build better or worse, but I don't feel I'm hedged into a way of 
thinking by the language - I find the language dictates what's possible to 
express a lot of the time, but I don't see this as the language limiting ME, 
rather what I can express is limited by the language. (ie in the latter I 
remain limitless, in the formed, I would be limited). Same thing in natural 
language. For example, this paragraph is poorly expressed in english without a 
lot of work.

[FOR ME], [easy+] [express myself] [precisely++] [in esperanto] than [in 
english].  (for example). In LISP, it's the same thing. LISP is "perfectly" 
precise. It's completely unambiguous. Of course, this makes it incredibly 
difficult to use or understand sometimes.

What I wonder is, is it possible to build a series of tiny LISPs on top of each 
other such that we could arrive at incredibly precise and yet also incredibly 
concise, but [[easily able to be traversed] meanings]. This was/is the aim of 
the STEPS project, was it not? I continue to grapple with this idea and its 
implementation(s).

The ramifications are that one could replace any part of the system because one 
could understand any part of it, but also that it would enable a learning not 
possible by any other means because it would be "able to be 
inspected/introspected". Thus, using would become learning would become 
programming. This is one of my most passionate aims, but unfortunately daily 
"grind work to pay the bills" generally takes away from my efforts. 

Julian

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

Re: [fonc] Natural Language Wins

[Julian Leviston]

Apology accepted. ;-)

Julian

On 06/04/2013, at 12:42 AM, Kirk Fraser  wrote:

> Actually that's your reasoning.  Years ago when I was in college, educators 
> wrote that innovation for innovation's sake is worth nothing.  Truly 
> worthwhile inventions judging by percent of Nobel Prize awards are by Jews, 
> hence in Hebrew.  But until the world converts to their superior culture, 
> inventions are best communicated to the world in English since automatic 
> machine translation is frequently imperfect.
> 
> On Fri, Apr 5, 2013 at 2:19 AM, Julian Leviston  wrote:
> 
> On 05/04/2013, at 7:19 AM, Kirk Fraser  wrote:
> 
>> The main source of invention is not "math wins" as described on 
>> http://www.vpri.org/html/work/ifnct.htm since the world would be speaking 
>> math if it were really the source of inspiring more inventions that improve 
>> the world's standard of living.  Math helps add precision to tasks that 
>> involve counting.  Attempting to move from counting to logic such as in 
>> statistics sometimes leads to false conclusions, especially if logic is not 
>> given priority over the tools of math.  For human value, readability is 
>> required, so computer language improvements must focus on natural language. 
> 
> Your assumptive base is incorrect. You're assuming because "all the world 
> speaks english" english has won in terms of being the main source of 
> innovation. That's not correct reasoning.
> 
> Julian
> 
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
> 
> 
> 
> 
> -- 
> Kirk W. Fraser
> http://freetom.info/TrueChurch - Replace the fraud churches with the true 
> church.
> http://congressionalbiblestudy.org - Fix America by first fixing its 
> Christian foundation.
> http://freetom.info - Example of False Justice common in America
> ___
> 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] Natural Language Wins

[Julian Leviston]

The fact that we're not communicating very effectively disproves your point. ;-)

Julian

On 06/04/2013, at 12:42 AM, Kirk Fraser  wrote:

> Actually that's your reasoning.  Years ago when I was in college, educators 
> wrote that innovation for innovation's sake is worth nothing.  Truly 
> worthwhile inventions judging by percent of Nobel Prize awards are by Jews, 
> hence in Hebrew.  But until the world converts to their superior culture, 
> inventions are best communicated to the world in English since automatic 
> machine translation is frequently imperfect.
> 
> On Fri, Apr 5, 2013 at 2:19 AM, Julian Leviston  wrote:
> 
> On 05/04/2013, at 7:19 AM, Kirk Fraser  wrote:
> 
>> The main source of invention is not "math wins" as described on 
>> http://www.vpri.org/html/work/ifnct.htm since the world would be speaking 
>> math if it were really the source of inspiring more inventions that improve 
>> the world's standard of living.  Math helps add precision to tasks that 
>> involve counting.  Attempting to move from counting to logic such as in 
>> statistics sometimes leads to false conclusions, especially if logic is not 
>> given priority over the tools of math.  For human value, readability is 
>> required, so computer language improvements must focus on natural language. 
> 
> Your assumptive base is incorrect. You're assuming because "all the world 
> speaks english" english has won in terms of being the main source of 
> innovation. That's not correct reasoning.
> 
> Julian
> 
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
> 
> 
> 
> 
> -- 
> Kirk W. Fraser
> http://freetom.info/TrueChurch - Replace the fraud churches with the true 
> church.
> http://congressionalbiblestudy.org - Fix America by first fixing its 
> Christian foundation.
> http://freetom.info - Example of False Justice common in America
> ___
> 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] Natural Language Wins

[Julian Leviston]

On 05/04/2013, at 7:19 AM, Kirk Fraser  wrote:

> The main source of invention is not "math wins" as described on 
> http://www.vpri.org/html/work/ifnct.htm since the world would be speaking 
> math if it were really the source of inspiring more inventions that improve 
> the world's standard of living.  Math helps add precision to tasks that 
> involve counting.  Attempting to move from counting to logic such as in 
> statistics sometimes leads to false conclusions, especially if logic is not 
> given priority over the tools of math.  For human value, readability is 
> required, so computer language improvements must focus on natural language. 

Your assumptive base is incorrect. You're assuming because "all the world 
speaks english" english has won in terms of being the main source of 
innovation. That's not correct reasoning.

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

Re: [fonc] yet another meta compiler compiler

[Julian Leviston]

But Maru already *does* this. The current version of Maru actually has this in 
its source tree: an implementation of Smalltalk in Maru, using Ometa to specify 
Smalltalk syntax.

Julian

On 12/02/2013, at 3:42 PM, Kjell Godo  wrote:

> OK I found Ometa.pdf .   Thank you for that.
> 
> BorgLisp is a generalization of the COLA idea if mixing Smalltalk with
> Lisp.  Instead of limiting it to just Smalltalk and Lisp it is very
> easy to generalize it to all languages by using the lisp idiom of
> using the first thing in the list to specify the compiler that will be
> used to compile the rest of the list.
> 
> ( c ... ( prologLisp ... ) ... ( lambdaLisp ... ( prologLisp ... ) ...
> ( assemblerLisp ... ) ) )
> 
> I hope that Maru will incorporate this idea if it seems good.  Then
> Maru would become BorgLisp.  If you will.
> 
> If you did it this way then perhaps you wouldn't need the funny names
> for the C Lisp expressions inside of Maru.
> 
> I have lambdaLisp working ( I tried to do two optimizations and got
> stuck in a debugging fuge.  Never try to optimize )( note to the
> future. )
> I have the ADD instruction working in assemblerLisp and all addressing
> modes work.
> This would be a Smalltalk rendition of llvm.  Which gives me pause.
> That's why there are no other assembler instructions implemented I
> guess.
> I would like to add PrologLisp.  To show how two languages could interact.
> And then I should have a third language to show how three languages
> could interact.
> If it was simple and easy to implement in Smalltalk that would be cool.
> 
> I think the same source level debugger that I have working now could
> work for each of the languages.
> 
> So anyhow.  If Maru could become BorgLisp by incorporating multiple
> languages like COLA did but generalizing it to all languages and not
> just the 2.
> 
> And then Maru/BorgLisp could be a new and better Smalltalk if you gave
> it an image.
> 
> It would be cool to make it so that you could run it with an image or
> without an image.  You choose.
> 
> So anyway.  I hope Maru becomes BorgLisp by incorporating multiple languages.
> 
> How can I run Maru in Windows?
> 
> I have a VMWare Ubuntu appliance which is a server version of Ubuntu.
> Will that work?  Is there any documentation?  All I saw was line after
> line of undocumented code.  Which seemed opaque to even the most
> casual observer.
> 
> So anyway.
> 
> On Sat, Feb 9, 2013 at 8:12 PM, Julian Leviston  wrote:
>> "Borglisp", hey?
>> 
>> Sounds like Ometa to me.
>> 
>> Julian
>> 
>> On 10/02/2013, at 6:27 AM, Kjell Godo  wrote:
>> 
>>> What will this book be called?  I would like to get one when it comes out.
>>> 
>>> Why do you always start with C?  Why not start with a higher language
>>> like Smalltalk?  You could compile ByteArrays that could then run
>>> fast.  Wouldn't it be more self documenting?  You would have access to
>>> all the Smalltalk resources.
>>> 
>>> Because C is the portable assembler.
>>> Because C has better access to all of the OS and all other languages.
>>> By starting with C you leverage the C compiler.
>>> You would have to write a C compiler in Smalltalk to get the same thing.
>>> 
>>> I am writing BorgLisp in Smalltalk which is supposed to asimilate all
>>> other computer languages into itself as dialects of lisp.  Like
>>> Clojure asimilates Java into itself.  Like Cola was a combination of
>>> Lisp and Smalltalk and C.
>>> 
>>> I have one dialect of Lisp in BorgLisp so far and a source level
>>> stepping debugger that can handle macros( it should ).  It's written
>>> in Dolphin Smalltalk but I would like to port it over to Pharo or
>>> VisualWorks.  If I tried to do the same thing in C I don't think I
>>> could.
>>> 
>>> Please explain why starting with C is better than this.
>>> 
>>> Is there a debugger for C that is as good as the one in Smalltalk?
>>> Do you use Test Driven Development as a way to get around not having a 
>>> debugger?
>>> What programming environment do you use?
>>> 
>>> I look at Maru and there are absolutely no comments in there.
>>> A litterate version of Maru would be way too cool to ever actually
>>> happen in this cursed universe we live in.  I hope Maru is what I'm
>>> talking about but I can't remember if it is or not.
>>> 
>>> I hope you write this book with the literate meta compiler compiler in it.
>>> 
>>> I hope I get my hands on 

Re: [fonc] yet another meta compiler compiler

[Julian Leviston]

"Borglisp", hey?

Sounds like Ometa to me.

Julian

On 10/02/2013, at 6:27 AM, Kjell Godo  wrote:

> What will this book be called?  I would like to get one when it comes out.
> 
> Why do you always start with C?  Why not start with a higher language
> like Smalltalk?  You could compile ByteArrays that could then run
> fast.  Wouldn't it be more self documenting?  You would have access to
> all the Smalltalk resources.
> 
> Because C is the portable assembler.
> Because C has better access to all of the OS and all other languages.
> By starting with C you leverage the C compiler.
> You would have to write a C compiler in Smalltalk to get the same thing.
> 
> I am writing BorgLisp in Smalltalk which is supposed to asimilate all
> other computer languages into itself as dialects of lisp.  Like
> Clojure asimilates Java into itself.  Like Cola was a combination of
> Lisp and Smalltalk and C.
> 
> I have one dialect of Lisp in BorgLisp so far and a source level
> stepping debugger that can handle macros( it should ).  It's written
> in Dolphin Smalltalk but I would like to port it over to Pharo or
> VisualWorks.  If I tried to do the same thing in C I don't think I
> could.
> 
> Please explain why starting with C is better than this.
> 
> Is there a debugger for C that is as good as the one in Smalltalk?
> Do you use Test Driven Development as a way to get around not having a 
> debugger?
> What programming environment do you use?
> 
> I look at Maru and there are absolutely no comments in there.
> A litterate version of Maru would be way too cool to ever actually
> happen in this cursed universe we live in.  I hope Maru is what I'm
> talking about but I can't remember if it is or not.
> 
> I hope you write this book with the literate meta compiler compiler in it.
> 
> I hope I get my hands on it.  I wish Maru was literate.
> 
> Now what Favorite shall I put this link under so that I might have
> some chance of ever seeing it again.  I suppose my Git account would
> be a good place to do that.  But I don't Git over there that much.
> 
> If I seem scattered maybe it's because I am a high functioning autistic.
> 
> He said.
> 
> On Fri, Feb 8, 2013 at 8:08 PM, Charles Perkins  wrote:
>> Thank you, Alan!
>> 
>> That means quite a bit to me.
>> 
>> I was so looking forward to a good pillage. Ah well… to follow your metaphor
>> (a kinder one and more inclusive to be sure) I am most appreciative of the
>> generous sharing of seeds going on around here.
>> 
>> Chuck
>> 
>> On Feb 8, 2013, at 5:42 PM, Alan Kay  wrote:
>> 
>> Looks nice to me!
>> 
>> But no ivory towers around to pillage. (However planting a few seeds is
>> almost always a good idea)
>> 
>> Cheers,
>> 
>> Alan
>> 
>> 
>> 
>> From: Charles Perkins 
>> To: Fundamentals of New Computing 
>> Sent: Friday, February 8, 2013 3:52 PM
>> Subject: [fonc] yet another meta compiler compiler
>> 
>> While we're all waiting for the next STEP report I thought I'd share
>> something I've been working on, inspired by O'Meta and by the Meta-II paper
>> and by the discussions on this list from November.
>> 
>> I've written up the construction of a parser generator and compiler compiler
>> here:
>> https://github.com/charlesap/ibnf/blob/master/SyntaxChapter.pdf?raw=true
>> 
>> The source code can be had here: https://github.com/charlesap/ibnf
>> 
>> Don't be fooled by the footnotes and references, this is a piece of outsider
>> literature. I am a barbarian come to pillage the ivory tower. Yarr.
>> 
>> Chuck
>> ___
>> 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] Send Science to the Landfill

[Julian Leviston]

 But don't you understand? Falun Dafa is the new answer-for-it-all! 


When will people simply address their fears? We *are* going to die.

Julian

On 30/12/2012, at 11:08 AM, John Carlson  wrote:

> Sorry, I use "it" too much.  What I was trying to say was that science 
> doesn't have an axiom for Falun Dafa, like science has for a point.
> 
> 
> On Sat, Dec 29, 2012 at 6:03 PM, John Carlson  wrote:
> John,
> 
> The FONC grant is done.  Let it be.  Please leave your email behavior at the 
> door.  As to why science cannot believe in such things is because of Godel's 
> Incompleteness Theorems.  Science doesn't have an axiom for it like it does 
> for a point (in math).
> 
> Find the most succinct axiom you can find, and bring it to us.  Here are two 
> that could be improved:
> 
> Something doesn't come from nothing.
> Complexity doesn't increase.
> 
> 
> On Sat, Dec 29, 2012 at 5:33 PM, John Pratt  wrote:
> These are larger issues, rarely brought up anywhere except in
> places where people don't counter the mainstream.  How is it
> that FONC needs to exist?  Because people don't consider things
> like this.
> 
> 
> 
> On Dec 29, 2012, at 3:27 PM, David Leibs wrote:
> 
>> Are you sure you don't want a response from me? Are you trying to put Alan 
>> in a petri dish?
>> -David Leibs
>> 
>> On Dec 29, 2012, at 3:23 PM, John Pratt  wrote:
>> 
>>> 
>>> I want a response from Alan Kay on this thread.  Then I will leave you all 
>>> alone.
>>> 
>>> 
>>> 
>>> On Dec 29, 2012, at 3:16 PM, David Harris wrote:
>>> 
 What are you on about?  How is this related to FONC?
 
 David
 
 
 
 On Sat, Dec 29, 2012 at 3:10 PM, John Pratt  wrote:
 
 
 What sickness science brings to everyday people!  They cannot even believe 
 in mysterious things, such as the divine, without first thinking it has to 
 show up on a laboratory microscope.
 
 The petri dish has to exist before the thing will be acknowledged as 
 fitting inside a petri dish.
 
 "We don't have a petri dish for that.  It cannot exist.  I cannot study it 
 inside of its petri dish."
 
 "Tell me where its petri dish is first, then I will believe you and we 
 will go study it."
 
 Mystical things of the past are regarded as superstition, described in 
 terms of theoretical, mechanical concepts.  Automobiles, air planes, and 
 light rail trains are the indicators of supreme accomplishments given to 
 man by this modern science.
 
 Computers, electronics are never questioned for what they are underneath-- 
 a huge mess of chemical circuits.  Contemptible expediency in its approach 
 to making its own version of warped plastic and silicon clockwork.
 
 Cram as much as you invent into the smallest space possible, sheath it 
 with cosmetic jewelry cases, and sell it to the world, telling the world 
 it is pure jewelry, inside and out.  When it happens to hit the floor, the 
 lie is exposed-- a mess of soldering, wires, and toxic chemicals.
 
 Dazzling athletics, to cram this inelegant approach to match the world's 
 demand for novelty and excitement.
 
 Pack it all into a tiny package.  Call it sheer wizardry and a triumph of 
 modern science.  Its engineers confounded by accusations of philistine 
 circuitry-- "engineering, math, and science works!  our engineering campus 
 buildings are not ugly-- they are utilitarian!  I like math and was good 
 at it in high school."
 
 If the shoe fits, wear it regardless of whether the shoe is distasteful in 
 appearance on the outside.  Make a distasteful shoe, cover it up with a 
 cosmetic shell.  Where there is a problem, an engineer will solve it.  
 Make sure that you don't need a solution you want to know about, however.  
 Just be content that a problem was solved and look the other way when the 
 details are explained of its operation.
 
 "That'll do the trick."
 
 I didn't like parabolas because the world cannot be reduced to two, three, 
 or four axes, thank you very much.
 
 I don't like polynomials because I want to draw the line before I call it 
 a function of the world, saying that the world consists only of 
 deterministic, reductionist functions.  "Oh, then you are just tired of 
 'discreteness' and you need its polar opposite of discreteness, 
 non-discreteness."
 
 Such is mathematics and science today.  "Why does no one want to learn 
 math and science anymore??"
 
 ___
 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://v

Re: [fonc] Send Science to the Landfill

[Julian Leviston]

I think you've entirely missed what science and mathematics *are*.

Deep inquiry into any subject has to involve "the divine" as you call it here. 
Go watch some Richard Feynmann videos if you think scientists such as Alan Kay 
don't subscribe to deeply held beliefs of the mysterious.

You can see it in him (Alan) when he talks. He understands "the divine" as 
Feynmann did - deeply.

Mathematics and the sciences are possibly our deepest inquiries into things. By 
definition that means not everyone will be interested. Alan has that driving 
burning question about mankind... he hasn't yet realised that there are reasons 
not everyone can be educated.

So be it. That's his lot. I don't feel you've properly understood him *or* 
science and math. It's not science or math's fault that the human condition is 
at such a low level of awareness, though. Don't blame them or Alan for our 
commercialistic or warlike states. These are all of our "crosses to bear".

Julian

On 30/12/2012, at 10:10 AM, John Pratt  wrote:

> 
> 
> What sickness science brings to everyday people!  They cannot even believe in 
> mysterious things, such as the divine, without first thinking it has to show 
> up on a laboratory microscope.
> 
> The petri dish has to exist before the thing will be acknowledged as fitting 
> inside a petri dish.
> 
> "We don't have a petri dish for that.  It cannot exist.  I cannot study it 
> inside of its petri dish."
> 
> "Tell me where its petri dish is first, then I will believe you and we will 
> go study it."
> 
> Mystical things of the past are regarded as superstition, described in terms 
> of theoretical, mechanical concepts.  Automobiles, air planes, and light rail 
> trains are the indicators of supreme accomplishments given to man by this 
> modern science.
> 
> Computers, electronics are never questioned for what they are underneath-- a 
> huge mess of chemical circuits.  Contemptible expediency in its approach to 
> making its own version of warped plastic and silicon clockwork.
> 
> Cram as much as you invent into the smallest space possible, sheath it with 
> cosmetic jewelry cases, and sell it to the world, telling the world it is 
> pure jewelry, inside and out.  When it happens to hit the floor, the lie is 
> exposed-- a mess of soldering, wires, and toxic chemicals.
> 
> Dazzling athletics, to cram this inelegant approach to match the world's 
> demand for novelty and excitement.
> 
> Pack it all into a tiny package.  Call it sheer wizardry and a triumph of 
> modern science.  Its engineers confounded by accusations of philistine 
> circuitry-- "engineering, math, and science works!  our engineering campus 
> buildings are not ugly-- they are utilitarian!  I like math and was good at 
> it in high school."
> 
> If the shoe fits, wear it regardless of whether the shoe is distasteful in 
> appearance on the outside.  Make a distasteful shoe, cover it up with a 
> cosmetic shell.  Where there is a problem, an engineer will solve it.  Make 
> sure that you don't need a solution you want to know about, however.  Just be 
> content that a problem was solved and look the other way when the details are 
> explained of its operation.
> 
> "That'll do the trick."
> 
> I didn't like parabolas because the world cannot be reduced to two, three, or 
> four axes, thank you very much.
> 
> I don't like polynomials because I want to draw the line before I call it a 
> function of the world, saying that the world consists only of deterministic, 
> reductionist functions.  "Oh, then you are just tired of 'discreteness' and 
> you need its polar opposite of discreteness, non-discreteness."
> 
> Such is mathematics and science today.  "Why does no one want to learn math 
> and science anymore??"
> ___
> 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] Falun Dafa

[Julian Leviston]

I think you've missed the point.

The point is... you need to use your body and your emotions as well as your 
mind. Our society is overly focussed on the mind.

Julian

On 23/12/2012, at 1:52 PM, BGB  wrote:

> On 12/22/2012 5:52 PM, Julian Leviston wrote:
>> Thank you, captain obvious.
>> 
>> Man is a three-centered (three-brained if you will) being. Focussing on only 
>> one of the brains is by definition imbalanced.
>> 
>> Bring back the renaissance man.
>> 
> 
> so, if, say, a person likes computers, but largely lacks either an emotional 
> or creative side, is this implying that computers somehow took away their 
> emotions and creativity, or is it more likely the case that they didn't 
> really have them to begin with?...
> 
> like, a person after a while, observing that they rarely feel much of 
> anything, no longer have much of any real sense of romantic interest, have 
> little intrinsic creative motivation, are unable to understand symbolism, 
> tend to see the world in a literal manner, ...
> 
> and, then wonder: "so it is? what now?..."
> 
> doesn't really seem like it is the computer's fault anymore than a person 
> also noting that they are also partially color-blind.
> 
> unless I have missed the point?...
> 
> 
> a more obvious downside though is that generally, doing lots of stuff on a 
> computer keeps the user nailed down to their chair. even though they might 
> realize that getting up and doing stuff might be better for their health, 
> doing so is time away from working on stuff...
> 
> I guess a mystery then would be if, some time in the future, there will be 
> ways of using computers which don't effectively require the users to be 
> sitting in a chair all day (ideally without compromising either the user 
> experience or capabilities). (granted, yes, traditional exercise can be 
> tiring/unpleasant though...).
> 
> 
> as for the mentioned practice, it seems like it could conflict with a 
> persons' religious beliefs (many people consider these types of things as 
> being occult).
> 
> more often a person might do something like memory-verses or similar instead 
> (like, memorize and recite John 3:16 or similar, ...).
> 
> or such...
> 
> 
>> Julian
>> 
>> On 23/12/2012, at 4:28 AM, John Pratt  wrote:
>> 
>>> I want to tell everyone on this list about something I found.
>>> 
>>> Maybe someone out there hears what I say, thinks I am pretty
>>> crazy for saying it to an entire mailing list, but appreciates it.
>>> 
>>> That is the kind of person I am sometimes.  I might tell a CEO
>>> not to use high-class mustard on a hotdog and genuinely wonder afterwards
>>> why he gets angry.  So, similarly, I am going to tell all of you to
>>> go to FalunDafa.org because this is the best thing I have done
>>> to extricate myself cognitively from computer prison that we
>>> all live in.
>>> 
>>> It is true that computers are impressive, but they are also injurious
>>> in other respects and if people won't acknowledge the downsides
>>> to what they do to our cognition, I don't think that is ok, either. I am
>>> actually a generalist on this subject, so I don't take technical stances
>>> on this minor subject or that minor subject inside the vast field of
>>> computer science.  But what holds true for me also holds true for you,
>>> that computers draw you in to a certain, narrow type of thinking that
>>> needs to be balanced by true, traditional, human things like music or dance 
>>> or art.
>>> ___
>>> 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] Falun Dafa

[Julian Leviston]

Thank you, captain obvious.

Man is a three-centered (three-brained if you will) being. Focussing on only 
one of the brains is by definition imbalanced.

Bring back the renaissance man.

Julian

On 23/12/2012, at 4:28 AM, John Pratt  wrote:

> I want to tell everyone on this list about something I found.
> 
> Maybe someone out there hears what I say, thinks I am pretty
> crazy for saying it to an entire mailing list, but appreciates it.
> 
> That is the kind of person I am sometimes.  I might tell a CEO
> not to use high-class mustard on a hotdog and genuinely wonder afterwards
> why he gets angry.  So, similarly, I am going to tell all of you to
> go to FalunDafa.org because this is the best thing I have done
> to extricate myself cognitively from computer prison that we
> all live in.
> 
> It is true that computers are impressive, but they are also injurious
> in other respects and if people won't acknowledge the downsides
> to what they do to our cognition, I don't think that is ok, either. I am
> actually a generalist on this subject, so I don't take technical stances
> on this minor subject or that minor subject inside the vast field of
> computer science.  But what holds true for me also holds true for you,
> that computers draw you in to a certain, narrow type of thinking that
> needs to be balanced by true, traditional, human things like music or dance 
> or art.
> ___
> 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] Views in FoNC

[Julian Leviston]

"the reason one is doing something" is a noun-group that describes a noun.

"reasoning of the human mind as a process" is ALSO a noun-group that describes 
a noun.

Functional-grammarly speaking, that is. ;-)

Even so, even in a traditional grammatical sense, "reasoning" and "a reason" 
are both nouns.

Julian

On 09/12/2012, at 11:23 AM, David Barbour  wrote:

> 
> 
> 
> On Sat, Dec 8, 2012 at 3:50 PM, Julian Leviston  wrote:
> 
> "a" reason, not "reason". Note I didn't say "reasoning comes before 
> processing". I meant "a reason to do something" surely must come before and 
> inform "a process to do". As in... the point of doing what you're doing.
> 
> Yes, I understood that. But it is not a significant difference whether you 
> use reason as a noun or verb. As a noun, reason is oft discovered in the 
> doing, or inspired in the exploration.
> 
> -- 
> bringing s-words to a pen fight
> ___
> 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] Views in FoNC

[Julian Leviston]

On 09/12/2012, at 10:29 AM, David Barbour  wrote:

> On Sat, Dec 8, 2012 at 3:02 PM, Julian Leviston  wrote:
> I'm a bit confused - general architecture of what, exactly? Sorry if this is 
> obvious. The organisation? The artefact that VPRI will eventually produce? or 
> FoNC itself?
> 
> Based on the sample views, I assume an architecture for an integrated 
> development environment. 
>  
> 
> Surely REASON comes before PROCESS, doesn't it?
> 
> Process does not happen before or after reason. Reasoning is part of the 
> process. People often think with their fingers and bodies - tweaking, 
> twiddling, learning, inspiring, a sort of brownian motion in thought space. 
> The process (paradigm, language, architecture) makes certain kinds of 
> reasoning more or less difficult, and thus less or more probable. 
> 

LOL.

"a" reason, not "reason". Note I didn't say "reasoning comes before 
processing". I meant "a reason to do something" surely must come before and 
inform "a process to do". As in... the point of doing what you're doing.

I thought this might be obvious from my example (I guess not?)

Julian


> http://en.wikipedia.org/wiki/Nudge_(book)
> 
> Regards,
> 
> Dave
> 
>  
> ___
> 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] Views in FoNC

[Julian Leviston]

I'm a bit confused - general architecture of what, exactly? Sorry if this is 
obvious. The organisation? The artefact that VPRI will eventually produce? or 
FoNC itself?

What is a "view" here? It appears to be inverted for your use. Surely REASON 
comes before PROCESS, doesn't it? (That is, rather than focus on the processes, 
or applications that a user will be focussing on, why not focus on the things 
that the people are trying to achieve).

That is, in the process going to the bank to get some money out, the reason is 
surely king - it's the driver... and that's to get money out so I can go and 
buy food.

Julian

On 09/12/2012, at 3:09 AM, John Carlson  wrote:

> So I was just designing a generic architecture presentation, and I came up 
> with 5 different types of views.  Are there more?
> 
> Editor (programmer, designer, scripter)
> Debugger (programmer)
> Browser (end user, player, sharing)
> Configuration (setting property lists)
> Administration (ACLs, grant, revoke, capabilities, upgrading schema)
> 
> What are the FoNC thoughts on supporting all these views?  What's the best 
> approach for children?  On one of my projects, we combined the Editor, 
> Debugger and Browser into a single view , which we called the workbench (or 
> recorder), then we added views for various tools we wanted to incorporate.  
> If we would have had a GUI builder, we probably would have had Configuration. 
>  What I don't know how to do is incorporate Administration, except by 
> providing capabilities to share behavior and structure.  How does the user 
> interface for capabilities appear in FoNC?
> 
> John
> ___
> 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] [talk] Cool Code - Kevlin Henney

[Julian Leviston]

Yes. A concrete way to teach an abstraction is to provide multiple concrete 
examples each of which are different excepting their abstract commonality.

For example, addition is an abstract concept when compared to the concept of 
identity. It is known that one way of teaching it is by grouping identities 
(objects) of one type and then showing a similar grouping of objects of another 
type. Pigs, ducks, oranges, computers. Once you've shown a few examples of 
this, it becomes obvious.

By saying "Concrete is better than abstract for learning", I'm not in any way 
discounting previously understood concepts, quite the opposite.

For example, multiplication can be taught without reference to addition. What a 
pain! In my opinion, understanding is the process of concretising knowledge 
into being... that is, when I understand something, I literally include that 
knowledge into my self. You've no doubt experienced this process. That's why 
the word understanding is such a fascinating word to me. You put your body 
under the knowledge.

If one understands addition thoroughly, one can be taught multiplication more 
easily than if one doesn't understand addition... because one has less of an 
abstract leap to make... perhaps by someone saying to you "one way of looking 
at multiplication is that it is adding or counting groups each with the same 
numbers of things in them", and then showing how the concept of 4 groups each 
with 3 chickens in them can be "speed counted" with multiplication by taking 
each group of three chickens and adding them together, OR by taking one group 
of three chickens and counting them four times, etc then taking this and 
trying with different groups of different things.

Note that I chose a "simple" example so that you'd understand. Some might say I 
chose a fairly concrete example, however there were no actual chickens or 
oranges, or any of the objects I referred to involved. We use abstraction so 
much in our lives, and quite a lot of us don't understand it very well, that 
it's often hard for us to know what is abstract and what isn't. I have no doubt 
that's why advertising "works" so well on us (often causing most people to buy 
things they don't really necessarily want or need).

I would say that the concept of addition is so well understood by us all that 
it *is* concrete for us, in terms of understanding. Thus, what is concrete for 
me may not be concrete for you. What is solid is what I understand fully, and 
what is not so solid is the body of knowledge that I do not yet understand.

My point is simply that if you want someone to learn, you should use objects 
that are concrete to the person, and yes they can be very abstract objects in 
terms of general understanding. I am sorry I generalised to such a degree that 
may have left you all misunderstanding me.

I think and hope the idea of scale makes more obvious that which I was 
attempting to communicate. I think addition is a very abstract concept in terms 
of uneducated people and very small children, but for us, it's completely 
concretised. Things that are basic for you, or not basic for me, and vice versa.

Much Love,
Julian


On 04/12/2012, at 3:07 AM, David Barbour  wrote:

> I agree there's much value in lawful, powerful building blocks. I would 
> formalize that with composition law (i.e. exists F. forall X,*,Y. P(X*Y) = 
> F(P(X),'*',P(Y)), for some useful set of properties P). We can find many 
> lawful, powerful building blocks in category theory or algebraic topology. 
> Basically, with 'lawful' and 'powerful' you're saying that there isn't much 
> point to starting concrete if it will limit us later.
> 
> But that leaves "approachable" as a problem. I think most concepts - even 
> arrows or monads - can be made approachable after working with using concrete 
> examples (that are individually useful) and gaining some intuition for the 
> composition laws. I.e. start concrete and work towards abstract. If you start 
> by tossing concepts like 'arrows' at students, they'll be quite intimidated. 
> If a language requires users `import Control.Arrow` or `import Control.Monad` 
> before they can use concrete instances, it is not helping with the learning 
> process. 
> 
> 
> 
> On Mon, Dec 3, 2012 at 4:22 AM, Loup Vaillant  wrote:
> David Barbour a écrit :
> On Sun, Dec 2, 2012 at 6:12 AM, Pascal J. Bourguignon
> mailto:p...@informatimago.com>> wrote:
> 
> Julian Leviston mailto:jul...@leviston.net>>
> 
> writes:
> 
>  > Concrete is better than abstract for learning.
> 
> Definitely.  Programmer students should learn assembler and write a
> couple of assembler programs.
> 
> 
> Concrete doesn

Re: [fonc] [talk] Cool Code - Kevlin Henney

[Julian Leviston]

Concrete is better than abstract for learning.

Julian


On 03/12/2012, at 12:23 AM, John Nilsson  wrote:

> Yes.
> 
> Hence you write a pattern language and spare people the agony of reading the 
> programs it was discovered in.
> 
> Which was precisely my point. Maybe this is is why we dont read programs and 
> why we instead have pattern literature as our primary means of communicating 
> interesting design ideas.
> 
> BR
> John
> 
> Den 2 dec 2012 14:18 skrev "Pascal J. Bourguignon" :
> John Nilsson  writes:
> 
> > Isn't the pattern language literature exactly that? An effort to
> > typeset and edit interesting design artifacts.
> 
> Unless you're programming in lisp(*), reading a program written with
> patterns is like looking at the wave form of "Hello world!" said aloud.
> 
> 
> (*) See:
> http://groups.google.com/group/comp.lang.lisp/msg/ee09f8475bc7b2a0
> http://groups.google.com/group/comp.programming/msg/9e7b8aaec1794126
> 
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> A bad day in () is better than a good day in {}.
> ___
> 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] Final STEP progress report?

[Julian Leviston]

How does one donate?

Julian


On 09/11/2012, at 12:10 PM, Kim Rose  wrote:

> Dear Jeff,
> 
> Good question; honestly support = donations -- but could be you know someone, 
> or some organization, etc, etc. that could be a viable donor but may not be 
> aware of Viewpoints and our work, efforts, etc., and you could bring us to 
> their attention.  So "support" could mean networking, etc. Many larger 
> companies have "matching funds" programs so if an employee makes a donation 
> to a non-profit, they have a program that will match the donation.
> 
> Thanks for asking.
> Kim
> On Nov 8, 2012, at 7:58 AM, Jeff Gonis wrote:
> 
>> Hi Kim,
>> 
>> Donations is self-explanatory, but what do you mean when you say "support"?  
>> Is there a way that a lay-person such as myself can "support" VPRI, or are 
>> monetary donations the most straight-forward way?
>> 
>> Thanks,
>> Jeff
>> 
>> 
>> On Wed, Nov 7, 2012 at 3:53 PM, Kim Rose  wrote:
>> Hi, Carl -
>> 
>> I am sure there will be some documentation and pointers where more can be 
>> found online.I wouldn't "hold my breath" for another "blue book".  ;-)
>> 
>> Kim
>> 
>> Viewpoints Research is a 501(c)(3) nonprofit organization dedicated to 
>> improving "powerful ideas education" for the world's children and advancing 
>> the state of systems research and personal computing. Please visit us online 
>> at www.vpri.org
>> 
>> 
>> 
>> 
>> 
>> On Nov 8, 2012, at 7:45 AM, Carl Gundel wrote:
>> 
>>> Thanks Kim.  Will there be enough documentation for interested people to be
>>> able to build on top of VPRI's STEPS project?  I'm thinking something like
>>> the blue book with a CDROM.  :-)
>>> 
>>> -Carl
>>> 
>>> -Original Message-
>>> From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Kim
>>> Rose
>>> Sent: Wednesday, November 07, 2012 5:37 PM
>>> To: Fundamentals of New Computing
>>> Subject: Re: [fonc] Final STEP progress report?
>>> 
>>> Hello,
>>> 
>>> For those of you interested and waiting -- the NSF (National Science
>>> Foundation) funding for the 5-year "STEPS" project has now finished (we
>>> stretched that funding to last for 6 years).  The final report on this work
>>> will be published and available on our website by the end of this calendar
>>> year.
>>> 
>>> We have received some more funding (although not to the extent of this
>>> original 5-year grant) and our work will carry on.   That said, we're always
>>> looking for more funding to maintain day to day operations so we welcome any
>>> support and donations at any time.  :-)
>>> 
>>> Regards,
>>> Kim Rose
>>> Viewpoints Research Institute
>>> 
>>> Viewpoints Research is a 501(c)(3) nonprofit organization dedicated to
>>> improving "powerful ideas education" for the world's children and advancing
>>> the state of systems research and personal computing. Please visit us online
>>> at www.vpri.org
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Nov 8, 2012, at 5:23 AM, Carl Gundel wrote:
>>> 
 Well, I do hope that VPRI has managed to find more funding money so that
>>> this doesn't have to be a final STEP report.  ;-)
 
 -Carl
 
 -Original Message-
 From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of
>>> Loup Vaillant
 Sent: Wednesday, November 07, 2012 1:45 PM
 To: Fundamentals of New Computing
 Subject: [fonc] Final STEP progress report?
 
 Hi,
 
 The two last progress reports having being published in October, I was
>>> wondering if we will have the final one soon.  Have we an estimation of when
>>> this might be completed? As a special request, I'd like to know a bit about
>>> what to expect.
 
 Unless of course it's all meant to be a surprise.  But please at least
>>> tell me you have decided not to disclose anything right now. In any case, I
>>> promise I'll be patient.
 
 Cheers,
 Loup.
 
 PS: If I sound like a jumping impatient child, that's because right
   now, I feel like one.
 ___
 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
>> 
>> ___
>> 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] The problem with programming languages

[Julian Leviston]

rience here.
> 
> For B1), I learned lots of little ways of writing "readable" code from Martin 
> Fowlers "Refactoring", tricks like this:
> 
> http://martinfowler.com/refactoring/catalog/introduceExplainingVariable.html
> http://martinfowler.com/refactoring/catalog/decomposeConditional.html
> 
> But this can only go so far - it works in business programming but with 
> really complicated things it isn't enough to make an "ordinary" programming 
> language a good "tool for thought".
> 
> B2) is more serious, with the before-mentioned Lisp macros, POLs etc. I again 
> (unfortunately) do not have experience programming in this style.
> 
> I will be very vague here, but maybe you could somehow invert B) and instead 
> of finding a way to program that's similar to the way we currently think, 
> find a programming language that would be convenient to reason in. I have 
> things like program derivation in mind here, an interesting modern example is 
> this paper:
> 
> http://www.cs.tufts.edu/~nr/comp150fp/archive/richard-bird/sudoku.pdf
> 
> Maybe a good idea for an advanced programming course would be to take two 
> weeks off from ordinary work, pick a couple of non-trivial algorithmic 
> problems and, say, try to solve two of them via literate programming, two of 
> them via constructing a language bottom-up in Lisp or Smalltalk, two of them 
> via derivation etc. On the other hand, it seems quite reasonable to ask 
> whether this matters at all during problem solving, maybe the same mostly 
> unconscious mental facilities do the work anyway and then this would matter 
> only for communicating the solution to other people. Anyway, maybe that's 
> what I will try to do during my vacation this year :)
> 
> Cheers,
> Jarek
> 
> 2012/5/8 Julian Leviston 
> Isn't this simply a description of your "thought clearing process"?
> 
> You think in English... not Ruby.
> 
> I'd actually hazard a guess and say that really, you think in a semi-verbal 
> semi-phyiscal pattern language, and not very well formed one, either. This is 
> the case for most people. This is why you have to write hard problems down... 
> you have to bake them into physical form so you can process them again and 
> again, slowly developing what you mean into a shape.
> 
> Julian
> 
> On 09/05/2012, at 2:20 AM, Jarek Rzeszótko wrote:
> 
>> Example: I have been programming in Ruby for 7 years now, for 5 years 
>> professionally, and yet when I face a really difficult problem the best way 
>> still turns out to be to write out a basic outline of the overall algorithm 
>> in pseudo-code. It might be a personal thing, but for me there are just too 
>> many irrelevant details to keep in mind when trying to solve a complex 
>> problem using a programming language right from the start. I cannot think of 
>> classes, method names, arguments etc. until I get a basic idea of how the 
>> given computation should work like on a very high level (and with the 
>> low-level details staying "fuzzy"). I know there are people who feel the 
>> same way, there was an interesting essay from Paul Graham followed by a very 
>> interesting comment on MetaFilter about this:
> 
> 
> ___
> 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] The problem with programming languages

[Julian Leviston]

By the way,

This paragraph from Graham's essay, and in fact, his constant reiteration of it 
in most of his work, is perhaps the most under-rated idea that we have in the 
programming industry. It's actually not just the programming industry... My 
emphasis added:

You can magnify the effect of a powerful language by using a style called 
bottom-up programming, where you write programs in multiple layers, the lower 
ones acting as programming languages for those above. If you do this right, you 
only have to keep the topmost layer in your head.

This isn't just a style - it's programming to a micro-interface, and 
programming in extremely tiny chunks... it's also what FONC seem to be doing 
with the idea of POLs and Ometa translating between them. The interface *is* 
the micro-language... what's inside the interface is simply the implementation 
of the micro-language. (or POL, if you like).

One technique I use that is particularly helpful is naming my "variables" 
really long descriptive names. Effectively I use variable names as comments. 
But this is just because I program in languages that don't support a visual 
combining of infinitely recursive sub-languages. The LISPS apparently support 
this according to Graham, but in the end when I program in LISP I sill end up 
writing files of text, often using arcane symbols that feels like I'm a 
fyre-weilding mage from yester-epoch. That feels like an epic fail to me.

Julian

On 09/05/2012, at 2:20 AM, Jarek Rzeszótko wrote:

> Natural languages are commonly much more ambiguous and you could say "fuzzy" 
> (as in fuzzy logic) than (currently popular) programming languages and hence 
> switching between those two has to cause some difficulties.
> 
> Example: I have been programming in Ruby for 7 years now, for 5 years 
> professionally, and yet when I face a really difficult problem the best way 
> still turns out to be to write out a basic outline of the overall algorithm 
> in pseudo-code. It might be a personal thing, but for me there are just too 
> many irrelevant details to keep in mind when trying to solve a complex 
> problem using a programming language right from the start. I cannot think of 
> classes, method names, arguments etc. until I get a basic idea of how the 
> given computation should work like on a very high level (and with the 
> low-level details staying "fuzzy"). I know there are people who feel the same 
> way, there was an interesting essay from Paul Graham followed by a very 
> interesting comment on MetaFilter about this:
> 
> http://www.paulgraham.com/head.html
> http://www.metafilter.com/64094/its-only-when-you-have-your-code-in-your-head-that-you-really-understand-the-problem#1810690
> 
> There is also the Pseudo-code Programming Process from Steve McConnell and 
> his "Code Complete":
> 
> http://www.coderookie.com/2006/tutorial/the-pseudocode-programming-process/
> 
> Another thing is that the code tends to evolve quite rapidly as the 
> constraints of a given problem are explored. Plenty of things in almost any 
> program end up being the way they are because of those constraints that 
> frequently were not obvious in the start and might not be obvious from just 
> reading the code - that's why people often rush to do a complete rewrite of a 
> program just to run into the same problems they had with the original one. 
> The question now is how much more time would documenting those constraints in 
> the code take and how much time would it save with future maintenance of the 
> code. I guess the amount of this context that would be beneficial varies with 
> applications a lot.
> 
> If you mention TeX, I think literate programming is pretty relevant to this 
> discussion too, and I am personally looking forward to trying it out one day. 
> Knuth himself said he would not be able to write TeX without literate 
> programming, and the technique is of course partially related to what I've 
> said above regarding pseudocode:
> 
> http://www.literateprogramming.com/
> 
> Cheers,
> Jarosław Rzeszótko
> 
> 
> 2012/5/8 David Goehrig 
> 
> On May 8, 2012, at 2:56 AM, Julian Leviston  wrote:
> 
> >
> > Humans parsing documents without proper definitions are like coders trying 
> > to read programming languages that have no comments
> 
> One of the under appreciated aspects of system like TeX with the ability to 
> do embedded programming, or a system like Self with its Annotations as part 
> of the object, or even python's .__doc__ attributes is that they provide 
> context for the programmer.
> 
> A large part of the reason that these are under appreciated is that most 
> programs aren't sufficiently well factored to take advantage of

Re: [fonc] The problem with programming languages

[Julian Leviston]

Isn't this simply a description of your "thought clearing process"?

You think in English... not Ruby.

I'd actually hazard a guess and say that really, you think in a semi-verbal 
semi-phyiscal pattern language, and not very well formed one, either. This is 
the case for most people. This is why you have to write hard problems down... 
you have to bake them into physical form so you can process them again and 
again, slowly developing what you mean into a shape.

Julian

On 09/05/2012, at 2:20 AM, Jarek Rzeszótko wrote:

> Example: I have been programming in Ruby for 7 years now, for 5 years 
> professionally, and yet when I face a really difficult problem the best way 
> still turns out to be to write out a basic outline of the overall algorithm 
> in pseudo-code. It might be a personal thing, but for me there are just too 
> many irrelevant details to keep in mind when trying to solve a complex 
> problem using a programming language right from the start. I cannot think of 
> classes, method names, arguments etc. until I get a basic idea of how the 
> given computation should work like on a very high level (and with the 
> low-level details staying "fuzzy"). I know there are people who feel the same 
> way, there was an interesting essay from Paul Graham followed by a very 
> interesting comment on MetaFilter about this:

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

Re: [fonc] The problem with programming languages

[Julian Leviston]

Sorry it wasn't obvious what I was saying there...

They're important because when they're tiny, it's very easy to learn them... 

Julian

On 08/05/2012, at 8:45 PM, Julian Leviston wrote:

> This is why tiny languages (Alan calls them POLs, I believe: 
> problem-oriented-languages) are so important.
> 
> A language being anything that involves "communication"... including user 
> interface interaction.
> 
> Julian
> 
> On 08/05/2012, at 8:07 PM, Clinton Daniel wrote:
> 
>> I suppose my point is that for new users, the analogies formed by
>> reusing existing terms are uncertain in that you don't know which
>> parts of the analogy carry across to the concept in question. Once
>> you're familiar with the concept itself, you know which parts apply
>> and which don't, but the point of reusing terms in the first place is
>> to help in learning the concept.
>> 
>> If you invent a new term, you don't get the problem of inferring
>> properties that don't carry across (or missing properties that aren't
>> analogous), but you burden new users with finding analogies
>> themselves.
>> 
>> In the end I agree that people are the problem, but I think we should
>> make things as easy as possible to learn by using analogies where
>> appropriate and inventing new terms where analogies would be
>> counter-productive. Where that line rests, however, is much of what
>> makes the issue difficult.
>> 
>> Clinton
>> 
>> 
>> On 8 May 2012 16:13, Julian Leviston  wrote:
>>> I disagree. We do our best. This is always the case.
>>> 
>>> The problem with language is ... there is no problem. The "problem" is with 
>>> people and their lack of awareness.
>>> 
>>> I agree that "our best" currently sucks, though.
>>> 
>>> Words aren't the things they refer to - they're just pointers. The only way 
>>> to precisely use language is to realise that it's not precise, and 
>>> therefore stipulate DSLs.
>>> 
>>> What's your point?
>>> 
>>> Julian
>>> 
>>> 
>>> On 08/05/2012, at 4:07 PM, Clinton Daniel wrote:
>>> 
>>>> The other side of that coin is burdening users with a bunch of new
>>>> terms to learn that don't link to existing human concepts and words.
>>>> "Click to save the document" is easier for a new user to grok than
>>>> "Flarg to flep the floggle" ;)
>>>> 
>>>> Seriously though, in the space of programming language design, there
>>>> is a trade-off in terms of quickly conveying a concept via reusing a
>>>> term, versus coining a new term to reduce the impedance mismatch that
>>>> occurs when the concept doesn't have exactly the same properties as an
>>>> existing term.
>>>> 
>>>> Clinton
>>>> 
>>>> 
>>>> On 8 May 2012 00:14, John Pratt  wrote:
>>>>> 
>>>>> The problem with programming languages and computers in general is that 
>>>>> they hijack existing human concepts and words, usurping them from 
>>>>> everyday usage and flattening out their meanings.
>>>>> ___
>>>>> 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] The problem with programming languages

[Julian Leviston]

This is why tiny languages (Alan calls them POLs, I believe: 
problem-oriented-languages) are so important.

A language being anything that involves "communication"... including user 
interface interaction.

Julian

On 08/05/2012, at 8:07 PM, Clinton Daniel wrote:

> I suppose my point is that for new users, the analogies formed by
> reusing existing terms are uncertain in that you don't know which
> parts of the analogy carry across to the concept in question. Once
> you're familiar with the concept itself, you know which parts apply
> and which don't, but the point of reusing terms in the first place is
> to help in learning the concept.
> 
> If you invent a new term, you don't get the problem of inferring
> properties that don't carry across (or missing properties that aren't
> analogous), but you burden new users with finding analogies
> themselves.
> 
> In the end I agree that people are the problem, but I think we should
> make things as easy as possible to learn by using analogies where
> appropriate and inventing new terms where analogies would be
> counter-productive. Where that line rests, however, is much of what
> makes the issue difficult.
> 
> Clinton
> 
> 
> On 8 May 2012 16:13, Julian Leviston  wrote:
>> I disagree. We do our best. This is always the case.
>> 
>> The problem with language is ... there is no problem. The "problem" is with 
>> people and their lack of awareness.
>> 
>> I agree that "our best" currently sucks, though.
>> 
>> Words aren't the things they refer to - they're just pointers. The only way 
>> to precisely use language is to realise that it's not precise, and therefore 
>> stipulate DSLs.
>> 
>> What's your point?
>> 
>> Julian
>> 
>> 
>> On 08/05/2012, at 4:07 PM, Clinton Daniel wrote:
>> 
>>> The other side of that coin is burdening users with a bunch of new
>>> terms to learn that don't link to existing human concepts and words.
>>> "Click to save the document" is easier for a new user to grok than
>>> "Flarg to flep the floggle" ;)
>>> 
>>> Seriously though, in the space of programming language design, there
>>> is a trade-off in terms of quickly conveying a concept via reusing a
>>> term, versus coining a new term to reduce the impedance mismatch that
>>> occurs when the concept doesn't have exactly the same properties as an
>>> existing term.
>>> 
>>> Clinton
>>> 
>>> 
>>> On 8 May 2012 00:14, John Pratt  wrote:
>>>> 
>>>> The problem with programming languages and computers in general is that 
>>>> they hijack existing human concepts and words, usurping them from everyday 
>>>> usage and flattening out their meanings.
>>>> ___
>>>> 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] The problem with programming languages

[Julian Leviston]

Naming poses no problem so long as you define things a bit. :P

Humans parsing documents without proper definitions are like coders trying to 
read programming languages that have no comments

(pretty much all the source code I ever read unfortunately)

J


On 08/05/2012, at 4:36 PM, David Barbour wrote:

> On Mon, May 7, 2012 at 11:07 PM, Clinton Daniel  
> wrote:
> The other side of that coin is burdening users with a bunch of new
> terms to learn that don't link to existing human concepts and words.
> "Click to save the document" is easier for a new user to grok than
> "Flarg to flep the floggle" ;)
> 
> Seriously though, in the space of programming language design, there
> is a trade-off in terms of quickly conveying a concept via reusing a
> term, versus coining a new term to reduce the impedance mismatch that
> occurs when the concept doesn't have exactly the same properties as an
> existing term.
> 
> Yeah. I've had trouble with this balance before. We need to acknowledge the 
> path dependence in human understanding.
> 
> My impression: it's connotation, more than denotation, that interferes with 
> human understanding. 
> 
> "Naming is two-way: a strong name changes the meaning of a thing, and a 
> strong thing changes the meaning of a name." - Harrison Ainsworth (@hxa7241)
> 
> Regards,
> 
> Dave
> 
> -- 
> bringing s-words to a pen fight
> ___
> 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] The problem with programming languages

[Julian Leviston]

But I wasn't asking you. :P

:)


On 08/05/2012, at 4:28 PM, David Barbour wrote:

> 
> 
> On Mon, May 7, 2012 at 11:13 PM, Julian Leviston  wrote:
> What's your point?
> 
> I like my PLs to be point free, as much as possible. ;)
> 
> Regards,
> 
> Dave
> 
> -- 
> bringing s-words to a pen fight
> ___
> 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] The problem with programming languages

[Julian Leviston]

I disagree. We do our best. This is always the case.

The problem with language is ... there is no problem. The "problem" is with 
people and their lack of awareness.

I agree that "our best" currently sucks, though.

Words aren't the things they refer to - they're just pointers. The only way to 
precisely use language is to realise that it's not precise, and therefore 
stipulate DSLs.

What's your point?

Julian


On 08/05/2012, at 4:07 PM, Clinton Daniel wrote:

> The other side of that coin is burdening users with a bunch of new
> terms to learn that don't link to existing human concepts and words.
> "Click to save the document" is easier for a new user to grok than
> "Flarg to flep the floggle" ;)
> 
> Seriously though, in the space of programming language design, there
> is a trade-off in terms of quickly conveying a concept via reusing a
> term, versus coining a new term to reduce the impedance mismatch that
> occurs when the concept doesn't have exactly the same properties as an
> existing term.
> 
> Clinton
> 
> 
> On 8 May 2012 00:14, John Pratt  wrote:
>> 
>> The problem with programming languages and computers in general is that they 
>> hijack existing human concepts and words, usurping them from everyday usage 
>> and flattening out their meanings.
>> ___
>> 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] LightTable UI

[Julian Leviston]

I'm pretty much in agreement with you about all your points. I just thought it 
was worth a look, as I said.

Julian

On 24/04/2012, at 5:50 PM, Jarek Rzeszótko wrote:

> You make it sound a bit like this was a working solution already, while it 
> seems to be a prototype at best, they are collecting funding right now: 
> http://www.kickstarter.com/projects/306316578/light-table. 
> 
> I would love to be proven wrong, but I think given the state of the project, 
> many people overexcite over it: some of the things proposed aren't new, just 
> wrapped into a nice modern design (you could try to create a new "skin" or UI 
> toolkit for some Smalltalk IDE for a similiar effect), while for the ones 
> that would be new like the real-time evaluation or visualisation there is too 
> little detail to say whether they are onto something or not - I am sure many 
> people thought of such things in the past, but it is highly questionable to 
> what extent those are actually doable, especially in an existing language 
> like Clojure or JavaScript. I am not convinced if dropping 200,000$ at the 
> thing will help with coming up with a solution if there is no decent set of 
> ideas to begin with. I would personally be much more enthusiastic if the 
> people behind the project at least outlined possible approaches they might 
> take, before trying to collect money. Currently it sounds like they just plan 
> to "hack" it until it handles a reasonable number of special cases, but tools 
> that work only some of the time are favoured by few. I think we need good 
> theoretical approaches to problems like this before we can make any progress 
> in how the actual real tools work like.
> 
> Cheers,
> Jarosław Rzeszótko
> 
> 2012/4/24 Julian Leviston 
> Thought this is worth a look as a next step after Brett Victor's work 
> (http://vimeo.com/36579366) on UI for programmers...
> 
> http://www.kickstarter.com/projects/ibdknox/light-table
> 
> We're still not quite "there" yet IMHO, but that's getting towards the 
> general direction... tie that in with a tile-script like language, and I 
> think we might have something really useful.
> 
> Julian
> ___
> 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] LightTable UI

[Julian Leviston]

Thought this is worth a look as a next step after Brett Victor's work 
(http://vimeo.com/36579366) on UI for programmers... 

http://www.kickstarter.com/projects/ibdknox/light-table

We're still not quite "there" yet IMHO, but that's getting towards the general 
direction... tie that in with a tile-script like language, and I think we might 
have something really useful.

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

[fonc] (Lisp) language implementation building

[Julian Leviston]

Hi Ian & Alan,

Further to your suggestion that I write a LISP interpreter, I'm about 90% of 
the way done. That is, I've built the following so far:

- using Ruby
- a Lexer into Ruby array structures for lists (Ruby Array & array of arrays  
(etc.) at this point in the process), Symbol, String, Integer & Float data types
- base Lisp data types of ConsCell and using the Ruby Symbol class as Lisp 
Symbol/Atom.
- an Environment class for holding a Dictionary which represents name 
definitions (ie to symbols, cons cells, lambdas and constant literals)
- a base env (instance of Environment class)
- a Parser for translating the ruby arrays from the lexer's output into 
ConsCell pairs, Symbols & constant literals
- in the env, I've put the seven ruby base Lisp definitions as lambdas: atom, 
car, cdr, cond, cons, eq and quote
- I've also put the two special operators... lambda & label... tho i haven't 
finished with these yet...
- I've built a base-level evaluate.

You guys weren't wrong! Man I've learned a HELL of a lot in the last two weeks! 
:) (But you knew that, right? hehe). 

So I've obviously got to finish the lambda code, and the evaluate function... 
but I've already got some interesting ideas brewing. I think I might need to go 
and "finish learning" Common Lisp, tho.

It strikes me that there are a lot of exceptions in Lisp. It doesn't feel very 
regular (which is hilarious because it's one of the most regular languages I've 
ever used). I wonder, though if there is a way to build a more regular 
language. I wonder if I look at Maru again if I'll be absolutely excited :)

I've learned a huge amount about cons cell structure - I thought I already 
understood them but I really didn't. Very interesting!

I've already learned a huge amount about the original definition of LISP in the 
1.5 manual. There were base functions in there I was wondering why anyone would 
need as a base function - until I started trying to write my own implementation 
and seeing the patterns crop up all over the place.

Anyway I just wanted to give you guys an update report of where I'm up to... 
quite exhilarating building my own implementation. I'd like to make it compile 
down to machine code, but first I have to finish it up and make it at least 
able to get to a point where I can replace my ruby functions with Lisp ones 
(that's making it metacircular, right? Or is that only when I've made a 
compiler that can build itself?)

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

Re: [fonc] Computing mats

[Julian Leviston]

On 15/04/2012, at 12:50 AM, Miles Fidelman wrote:

> K. K. Subramaniam wrote:
>> Hi,
>> 
>> I am fascinated by the emergence of transparent and flexible displays. With
>> such displays one can build a rollable mat with a network of processors (and
>> battery!) spread across the spine sharing the load. Heat dissipation will no
>> longer be a design constraint in such forms. Such computers can make it to
>> students in schools and colleges schools within the next five years.
> 
> not to mention what happens when mirror shades become a reality (can you say 
> "google glasses?").
> 

Haha speaking of this, I can't resist linking to this "spoof" of what it'd 
really be like...

http://www.youtube.com/watch?feature=player_detailpage&v=_mRF0rBXIeg

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

Re: [fonc] Article "Lisp as the Maxwell’s equations of software"

[Julian Leviston]

This section at once both interests and bothers me

> The great Norwegian mathematician Niels Henrik Abel was once asked how he had 
> become so good at mathematics. He replied that it was “by studying the 
> masters, not their pupils”. The current essay is motivated by Abel’s 
> admonishment. As a programmer, I’m a beginner (and almost completely new to 
> Lisp), and so this essay is a way for me to work in detail through ideas from 
> masters such as Alan Kay, Peter Norvig, and Paul Graham. Of course, if one 
> takes Abel at his word, then you should stop reading this essay, and instead 
> go study the works of Kay, Norvig, Graham, and the like! I certainly 
> recommend taking the time to study their work, and at the end of the essay I 
> make some recommendations for further reading. However, I hope that this 
> essay has a distinct enough point of view to be of interest in its own right. 
> Above all, I hope the essay makes thinking about Lisp (and programming) fun, 
> and that it raises some interesting fundamental questions. Of course, as a 
> beginner, the essay may contain some misunderstandings or errors (perhaps 
> significant ones), and I’d welcome corrections, pointers, and discussion.
> 

Niels Henrik Abel wasn't asked "how did you begin to learn mathematics" he was 
asked how he got so good at it. I'm sure to BEGIN mathematics he learnt from 
someone who wasn't one of the great masters (mostly because they were not in 
fact likely to be alive). But I'm also sure that who he learnt from taught him 
not to be closed about mathematics - to search out the greater understandings, 
and most likely told him OF the great masters. When we are beginners, we need 
clear, well thought-out teachers who are ABOVE our understanding. It doesn't 
matter how far, only that they have a capacious understanding of what is above 
them themselves and not motivated by ego (and preferably are in the process of 
extending themselves, too and are honest about it). Ideally they don't teach us 
incorrect information (obviously) because that is damaging.

I had this when learning martial arts. I once had a few lessons from an amazing 
master - the top of our entire series of schools - a grandmaster. I couldn't 
understand the lesson! He was teaching such advanced stuff that I wasn't sure 
what was and what wasn't the lesson. Here's the rub: most of the semi-advanced 
students in the room could have given me more than enough for me to go on 
with... his time would be wasted teaching me this stuff... and his basics (the 
maxwell equations of martial arts) were so highly advanced I didn't even 
understand them to be basics.

What I needed was well grounded basics taught to me in a frame that I could 
understand. The context is incredibly important. This entire process of 
learning LISP and Maru has been incredibly rewarding, but do you know what else 
it has been? Intensely frustrating. Like... possibly one of the most 
frustrating things I've ever done. I *knew* there was a way through it, because 
it's obvious that so many people I talk to on here and read from on the 
internet have made their way through it... but seriously folks, this is where 
our pedagogical efforts are up to at the moment? There's no clear, obvious and 
shining path to understand this stuff. This is actually part of the work that 
I'm most interested in (and have been for the last decade). It's exciting and I 
think I might be getting to a point where I can understand enough to put some 
of my ideas into practice quite soon.

I still feel the same way as receiving the grandmaster's lesson when given 
directions by Alan or Ian. I'm just not at their level yet. I can see when they 
give me some advice what I need to do to get to the point where I can use that 
advice, but I'm just not there yet. I have to literally shelve their advice, 
then go find something in the middle, with that advice in mind until the point 
where I'm able to use the advice (sometimes days or weeks later). I'm intensely 
grateful for the chance to be able to talk to the likes of Alan and Ian, but 
it's not easy for me sometimes.

So... this over-humble article is actually perfectly what I needed about a 
month ago (maybe more?) when I began my foray into LISP. Thank you very much 
Andre. It's incredibly helpful. I'll continue to read now :) Amusingly, things 
seem to happen like this in my life. It's usually how I know I'm on the right 
track... I will work on something incredibly hard, and then something will 
appear that explains it all clear and succinct :)

Also, "lispy" as referred to by the article, is great. I can't believe no one 
has linked to it before on here when discussing this. Mind you, I don't 
particularly like python, but it is quite readable and understandable. 
(http://norvig.com/lispy.html)

Kind Regards,
Julian

On 13/04/2012, at 9:50 AM, Andre van Delft wrote:

> FYI: Michael Nielsen wrote a large article "Lisp as the Maxwell’s equations 
> of software", ab

Re: [fonc] Kernel & Maru

[Julian Leviston]

I started on this yesterday when I received your email Ian, and I just wanted 
to say thank you (and Alan, too) very much for responding.

I'm still interested in what your thoughts on Kernel are (and Arc, too, 
actually) sometime if you have a couple of moments to pen them... 

Julian

On 11/04/2012, at 7:54 AM, Ian Piumarta wrote:

> Extending Alan's comments...
> 
> A small, well explained, and easily understandable example of an iterative 
> implementation of a recursive language (Scheme) can be found in R. Kent 
> Dybvig's Ph.D. thesis.
> 
> http://www.cs.unm.edu/~williams/cs491/three-imp.pdf
> 
> Regards,
> Ian
> 

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

[fonc] Kernel & Maru

[Julian Leviston]

Hi All,

I'm quite interested in knowing what the VPRI list people think about the 
Kernel programming language with respect to McCarthy's work. By the way, if 
you're not familiar with LISP, Maru & Kernel, please don't comment.

In the recent months, I've done SO MUCH reading and learning... I've finally 
gone through and taken a look at LISP after skirting it for decades. I honestly 
can't believe I've missed that language in my life as a programmer - it's 
PHENOMENAL, anyway I digress. This has let me understand the Maru work 
obviously with much more clarity than before (which previously was more like 
wading through mud in the dark).

I did notice, as I learned more and more Common LISP, that there are some 
deficiencies in purity and homogeneousness... (ie for example special 
operators) and this brings me to Kernel...

Kernel purports to be the perfect tool in terms of purity, and yet so much of 
it is unapproachable. I hesitate to criticise someone who is without doubt far 
more intelligent than myself, but I find a lot of the creator's writing 
incredible difficult to understand. It seems to be something to do with 
adhering (or lack thereof) to a standardised nomenclature within its own 
parameters, but I could be completely wrong here. 

Perhaps it's just that the nomenclature of the creators of languages such as 
this presuppose so much understanding. It seems that it's not being written to 
be approachable by anyone with the required intellectual development, but 
rather to be approachable to anyone who has absorbed years upon years of 
computer science "cruft" - ie someone who has a doctorate in computer science.

Also, simply, what are the "semantic inadequacies" of LISP that the "Maru 
paper" refers to (http://piumarta.com/freeco11/freeco11-piumarta-oecm.pdf)? I 
read the footnoted article (The Influence of the Designer on the Design—J. 
McCarthy and Lisp), but it didn't elucidate things very much for me.

It seems, on a whole, that Common LISP isn't particularly uniform with respect 
to special operators and macros, and Kernel seeks to address that. However, it 
seems that Maru has a smaller "kernel" than Kernel itself does while achieving 
what Kernel attempts to do with a much more pragmatic approach. Am I missing 
things here? I'm not attempting to detract from Kernel: it seems a master work 
by any standard!

I have to say that all of these papers and works are making me feel like a 3 
year old making his first steps into understanding about the world. I guess I 
must be learning, because this is the feeling I've always had when I've been 
growing, yet I don't feel like I have any semblance of a grasp on any part of 
it, really... which bothers me a lot.

Thanks for your thoughts,
Julian
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)

[Julian Leviston]

You can get around the idea of ubiquity of languages if you're prepared to 
build tiny easily understandable (in 5 minutes or less) micro languages.

Consider "how to use iOS touch" as if it were a language and how easy it is to 
learn. Afterall, a user interface is simply a visual / behavioural language, 
right? ;-)

Julian

On 15/03/2012, at 11:34 AM, C. Scott Ananian wrote:

> On Wed, Mar 14, 2012 at 6:02 PM, Jameson Quinn  
> wrote:
> If you're going to base it on Javascript, at least make it Coffeescript-like. 
> I also agree that some basic parallelism primitives would be great; it is 
> probably possible to build these into a Coffeescript-like dialect using JS 
> under the hood (though they'd probably optimize even better if you could 
> implement them natively instead of in JS). 
> 
> I think you are underestimating the value of using a standard widely-deployed 
> language.  I love languages as much as the next guy---but our previous 
> learning environment (Sugar) has had incredible difficulty getting local 
> support outside the US because it is written in *Python*.  Python is "not a 
> commercially viable language" (not my words) and you can't even take 
> university classes in Python in many countries (say, Uruguay) because there 
> is no company behind it and no one who will give you a "certificate" for 
> having learned it.
> 
> This is very sad, but the true state of affairs.
> 
> JavaScript is not perfect, but at heart it is a functional object-oriented 
> language which is pretty darn close to Good Enough.  There are huge benefits 
> to using a language which is supported by training materials all over the 
> web, university systems outside the US, etc, etc.
> 
> I am open to *very* slight extensions to JavaScript -- OMeta/JS and 
> quasiquote might squeeze in -- but they have to be weighed against their 
> costs.  Subsets are even more problematic -- once you start subsetting, then 
> you are throwing away compatibility with all the wealth of JavaScript 
> libraries out there, in addition to confusing potential contributors who are 
> trying to type in examples they found in some book.
>   --scott
> 
> -- 
>   ( http://cscott.net )
> ___
> 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] Where is the Moshi image?

[Julian Leviston]

Just out of curiosity, what's this?

http://tinlizzie.org/dbjr/frank.lbox/

Julian

On 14/03/2012, at 11:10 AM, Martin Baldan wrote:

> I've been reading a few more documents, and it seems that the first
> step towards having something like Frank at home would be to get hold
> of a Moshi Squeak image.
> 
> For instance, in "Implementing DBJr with Worlds" we can read:
> 
> "Try It Yourself!
> The following steps will recreate our demo. (Important: this only works in our
> "Moshi" Squeak image. Bring in Worlds2-aw.cs, WWorld-A-tk.1.cs,
> WWorld-B-tk.4.cs,
> Worlds-Morph-A-tk.5.cs, Worlds-DBJr-B-tk.1.cs, then look at file 'LStack 
> WWorld
> workspace') These instructions are here so that we won't lose them.
> This demo was
> difficult to get working."
> 
> 
> 
> But the Mythical Moshi image turned out to be surprisingly elusive.
> 
> For instance, all I've found in this list is this email message:
> 
> http://www.mail-archive.com/fonc@vpri.org/msg01037.html
> 
> "The other research that are based on the Moshi image equally
> interesting, but the Moshi image is nowhere to be downloaded so one
> can only read the code and papers about it."
> 
> Are we getting into military secret land? :D
> ___
> 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] Block-Strings / Heredocs (Re: Magic Ink and Killing Math)

[Julian Leviston]

On 14/03/2012, at 2:11 AM, David Barbour wrote:

> 
> 
> On Tue, Mar 13, 2012 at 5:42 AM, Josh Grams  wrote:
> On 2012-03-13 02:13PM, Julian Leviston wrote:
> >What is "text"? Do you store your "text" in ASCII, EBCDIC, SHIFT-JIS or
> >UTF-8?  If it's UTF-8, how do you use an ASCII editor to edit the UTF-8
> >files?
> >
> >Just saying' ;-) Hopefully you understand my point.
> >
> >You probably won't initially, so hopefully you'll meditate a bit on my
> >response without giving a knee-jerk reaction.
> 
> OK, I've thought about it and I still don't get it.  I understand that
> there have been a number of different text encodings, but I thought that
> the whole point of Unicode was to provide a future-proof way out of that
> mess.  And I could be totally wrong, but I have the impression that it
> has pretty good penetration.  I gather that some people who use the
> Cyrillic alphabet often use some code page and China and Japan use
> SHIFT-JIS or whatever in order to have a more compact representation,
> but that even there UTF-8 tools are commonly available.
> 
> So I would think that the sensible thing would be to use UTF-8 and
> figure that anyone (now or in the future) will have tools which support
> it, and that anyone dedicated enough to go digging into your data files
> will have no trouble at all figuring out what it is.
> 
> If that's your point it seems like a pretty minor nitpick.  What am I
> missing?
> 
> Julian's point, AFAICT, is that text is just a class of storage that requires 
> appropriate viewers and editors, doesn't even describe a specific standard. 
> Thus, another class that requires appropriate viewers and editors can work 
> just as well - spreadsheets, tables, drawings. 
> 
> You mention `data files`. What is a `file`? Is it not a service provided by a 
> `file system`? Can we not just as easily hide a storage format behind a 
> standard service more convenient for ad-hoc views and analysis (perhaps 
> RDBMS). Why organize into files? Other than penetration, they don't seem to 
> be especially convenient.
> 
> Penetration matters, which is one reason that text and filesystems matter.  
> 
> But what else has penetrated? Browsers. Wikis. Web services. It wouldn't be 
> difficult to support editing of tables, spreadsheets, drawings, etc. atop a 
> web service platform. We probably have more freedom today than we've ever had 
> for language design, if we're willing to stretch just a little bit beyond the 
> traditional filesystem+text-editor framework. 
> 
> Regards,
> 
> Dave

Perfectly the point, David. A "token/character" in ASCII is equivalent to a 
byte. In SHIFT-JIS, it's two, but this doesn't mean you can't express the 
equivalent meaning in them (ie by selecting the same graphemes) - this is 
called translation) ;-)

One of the most profound things for me has been understanding the ramifications 
of OMeta. It doesn't "just" parse streams of "characters" (whatever they are) 
in fact it doesn't care what the individual tokens of its parsing stream is. 
It's concerned merely with the syntax of its elements (or tokens) - how they 
combine to form certain rules - (here I mean "valid patterns of grammar" by 
rules). If one considers this well, it has amazing ramifications. OMeta invites 
us to see the entire computing world in terms of sets of 
problem-oriented-languages, where language is a liberal word that simply means 
a pattern of sequence of the constituent elements of a "thing". To PEG, it 
basically adds proper translation and true object-orientism of individual 
parsing elements. This takes a while to understand, I think.

Formats here become "languages", protocols are "languages", and so are any 
other kind of representation system you care to name (computer programming 
languages, processor instruction sets, etc.).

I'm postulating, BGB, that you're perhaps so ingrained in the current modality 
and approach to thinking about computers, that you maybe can't break out of it 
to see what else might be possible. I think it was turing, wasn't it, who 
postulated that his turing machines could work off ANY symbols... so if that's 
the case, and your programming language grammar has a set of symbols, why not 
use arbitrary (ie not composed of english letters) ideograms for them? (I think 
these days we call these things icons ;-))

You might say "but how will people name their variables" - well perhaps for 
those things, you could use english letters, but maybe you could enforce that 
no one use more than 30 variables in their code in any one simple chunk, in 
which case build the

Re: [fonc] Block-Strings / Heredocs (Re: Magic Ink and Killing Math)

[Julian Leviston]

On 13/03/2012, at 6:19 PM, BGB wrote:

> On 3/12/2012 9:01 PM, David Barbour wrote:
>> 
>> 
>> On Mon, Mar 12, 2012 at 8:13 PM, Julian Leviston  wrote:
>> 
>> On 13/03/2012, at 1:21 PM, BGB wrote:
>> 
>>> although theoretically possible, I wouldn't really trust not having the 
>>> ability to use conventional text editors whenever need-be (or mandate use 
>>> of a particular editor).
>>> 
>>> for most things I am using text-based formats, including for things like 
>>> world-maps and 3D models (both are based on arguably mutilated versions of 
>>> other formats: Quake maps and AC3D models). the power of text is that, if 
>>> by some chance someone does need to break out a text editor and edit 
>>> something, the format wont hinder them from doing so.
>> 
>> 
>> What is "text"? Do you store your "text" in ASCII, EBCDIC, SHIFT-JIS or 
>> UTF-8? If it's UTF-8, how do you use an ASCII editor to edit the UTF-8 files?
>> 
>> Just saying' ;-) Hopefully you understand my point.
>> 
>> You probably won't initially, so hopefully you'll meditate a bit on my 
>> response without giving a knee-jerk reaction.
>> 
> 
> I typically work with the ASCII subset of UTF-8 (where ASCII and UTF-8 happen 
> to be equivalent).
> 
> most of the code is written to assume UTF-8, but languages are designed to 
> not depend on any characters outside the ASCII range (leaving them purely for 
> comments, and for those few people who consider using them for identifiers).
> 
> EBCDIC and SHIFT-JIS are sufficiently obscure that one can generally pretend 
> that they don't exist (FWIW, I don't generally support codepages either).
> 
> a lot of code also tends to assume Modified UTF-8 (basically, the same 
> variant of UTF-8 used by the JVM). typically, code will ignore things like 
> character normalization or alternative orderings. a lot of code doesn't 
> particularly know or care what the exact character encoding is.
> 
> some amount of code internally uses UTF-16 as well, but this is less common 
> as UTF-16 tends to eat a lot more memory (and, some code just pretends to use 
> UTF-16, when really it is using UTF-8).



Maybe you entirely missed my point:

>>  If it's UTF-8, how do you use an ASCII editor to edit the UTF-8 files?

>> Hopefully you understand my point.

>> You probably won't initially, so hopefully you'll meditate a bit on my 
>> response without giving a knee-jerk reaction.
> 

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

Re: [fonc] Block-Strings / Heredocs (Re: Magic Ink and Killing Math)

[Julian Leviston]

On 13/03/2012, at 1:21 PM, BGB wrote:

> although theoretically possible, I wouldn't really trust not having the 
> ability to use conventional text editors whenever need-be (or mandate use of 
> a particular editor).
> 
> for most things I am using text-based formats, including for things like 
> world-maps and 3D models (both are based on arguably mutilated versions of 
> other formats: Quake maps and AC3D models). the power of text is that, if by 
> some chance someone does need to break out a text editor and edit something, 
> the format wont hinder them from doing so.


What is "text"? Do you store your "text" in ASCII, EBCDIC, SHIFT-JIS or UTF-8? 
If it's UTF-8, how do you use an ASCII editor to edit the UTF-8 files?

Just saying' ;-) Hopefully you understand my point.

You probably won't initially, so hopefully you'll meditate a bit on my response 
without giving a knee-jerk reaction.

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

Re: [fonc] Sorting the WWW mess

[Julian Leviston]

Right you are. Centralised search seems a bit silly to me.

Take object orientedism and apply it to search and you get a thing where each 
node searches itself when asked...  apply this to a local-focussed topology (ie 
spider web serch out) and utilise intelligent caching (so search the localised 
caches first) and you get a better thing, no?

Why not do it like that? Or am I limited in my thinking about this?

Julian

On 02/03/2012, at 4:26 AM, David Barbour wrote:

> 
> 
> On Thu, Mar 1, 2012 at 7:08 AM, Martin Baldan  wrote:
> I think it was Julian, in message:
> 
> http://vpri.org/mailman/private/fonc/2012/003131.html
> 
> BTW, I'm having a hard time trying to find who said what in this mailing 
> list. Maybe I'm missing something, I feel  a bit silly, but here's the 
> problem:
> 
> _ Apparently, Google can't search this mailing list, I guess it's because of 
> its private nature. For instance, the query:
> 
> google site:http://vpri.org/mailman/private/fonc/2012/thread.html
> 
> shields no results.
> 
> 
> _ I can search e-mails for keywords in my Gmail account, but when I find one, 
> I don't know what message number it is. I only see the date and time.
> 
> _ The mailing list web interface lets me arrange messages by date, but it 
> doesn't show me the date of each message in a column.
> 
> So what should I do?
> 
> http://www.mail-archive.com/fonc@vpri.org/
> 
>  
> 
> As for centralization, I don't think you can avoid some degree of natural 
> centralization of trust. For instance, I tend to trust the VPRI people when 
> it comes to programming-related theory and ideas. Am I giving them too much 
> power? ;)
> 
> What should be avoided is single points of failure in infrastructure. I 
> should be able to decide whom to trust, without artificial limits imposed by 
> the technology.
> 
> Best,
> 
>  -Martin
> 
> 
> ___
> 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] Error trying to compile COLA

[Julian Leviston]

What if the aim that superseded this was to make it available to the next set 
of people, who can do something about real fundamental change around this?

Perhaps what is needed is to ACTUALLY clear out the cruft. Maybe it's not easy 
or possible through the "old" channels... too much work to convince too many 
people who have so much history of the merits of tearing down the existing 
systems. 

Just a thought.
Julian

On 02/03/2012, at 2:04 AM, Reuben Thomas wrote:

> On 1 March 2012 15:02, Julian Leviston  wrote:
>> Is this one of the aims?
> 
> It doesn't seem to be, which is sad, because however brilliant the
> ideas you can't rely on other people to get them out for you.
> 
> On 01/03/2012, at 11:42 PM, Reuben Thomas wrote:
> 
>> The biggest challenge for FONC will not be to achieve good technical
>> results, as it is stuffed with people who have a history of doing
>> great work, and its results to date are already exciting, but to get
>> those results into widespread use; I've seen no evidence that the
>> principals have considered how and why they failed to do this in the
>> past, nor that they've any ideas on how to avoid it this time around.

> -- 
> http://rrt.sc3d.org
> ___
> 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] Error trying to compile COLA

[Julian Leviston]

Is this one of the aims?

Julian

On 01/03/2012, at 11:42 PM, Reuben Thomas wrote:

> The biggest challenge for FONC will not be to achieve good technical
> results, as it is stuffed with people who have a history of doing
> great work, and its results to date are already exciting, but to get
> those results into widespread use; I've seen no evidence that the
> principals have considered how and why they failed to do this in the
> past, nor that they've any ideas on how to avoid it this time around.

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

Re: [fonc] Error trying to compile COLA

[Julian Leviston]

On 29/02/2012, at 10:29 AM, BGB wrote:

> On 2/28/2012 2:30 PM, Alan Kay wrote:
>> 
>> Yes, this is why the STEPS proposal was careful to avoid "the current day 
>> world". 
>> 
>> For example, one of the many current day standards that was dismissed 
>> immediately is the WWW (one could hardly imagine more of a mess). 
>> 
> 
> I don't think "the web" is entirely horrible:
> HTTP basically works, and XML is "ok" IMO, and an XHTML variant could be ok.

Hypertext as a structure is not beautiful nor is it incredibly useful. Google 
exists because of how incredibly flawed the web is and if you look at their 
process for organising it, you start to find yourself laughing a lot. The 
general computing experience these days is an absolute shambles and completely 
crap. Computers are very very hard to use. Perhaps you don't see it - perhaps 
you're in the trees - you can't see the forest... but it's intensely bad.

It's like someone crapped their pants and google came around and said hey you 
can wear gas masks if you like... when what we really need to do is clean up 
the crap and make sure there's a toilet nearby so that people don't crap their 
pants any more.

> 
> granted, moving up from this, stuff quickly turns terrible (poorly designed, 
> and with many "shiny new technologies" which are almost absurdly bad).
> 
> 
> practically though, the WWW is difficult to escape, as a system lacking 
> support for this is likely to be rejected outright.

You mean like email? A system that doesn't have anything to do with the WWW per 
se that is used daily by millions upon millions of people? :P I disagree 
intensely. In exactly the same was that facebook was taken up because it was a 
slightly less crappy version of myspace, something better than the web would be 
taken up in a heartbeat if it was accessible and obviously better.

You could, if you chose to, view this mailing group as a type of "living 
document" where you can peruse its contents through your email program... 
depending on what you see the web as being... maybe if you squint your eyes 
just the right way, you could envisage the web as simply being a means of 
sharing information to other humans... and this mailing group could simply be a 
different kind of web...

I'd hardly say that email hasn't been a great success... in fact, I think 
email, even though it, too is fairly crappy, has been more of a success than 
the world wide web.

Julian

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

Re: [fonc] Error trying to compile COLA

[Julian Leviston]

Two things spring out of this at me (inline): 

On 28/02/2012, at 9:21 PM, Loup Vaillant wrote:

> - Features matter more than I think they do.
> - One may not expect the user to write his own features, even though
>   it would be relatively simple.

What about when using software becomes "writing" features - see etoys. Is 
clicking and dragging tiles still "writing" software? :)

> - Current systems may be not as badly written as I think they are.
> - Code reuse could be harder than I think.

It's not that they're written badly, it's just that that so many years on, no 
one has really understood some of the powerful ideas of yesteryear. Even those 
powerful ideas allowed a certain level of magnification... but the powerful 
ideas of these days in addition to the past allow an incredibly large 
possibility of magnification of thought... 

A good comparison would be:

- Engineer "A" understands what a lever does, therefore with that simple 
understanding can apply this knowledge to any number of concrete examples - it 
takes him almost no time to work out how to implement a lever. He teaches his 
apprentices this simple rule and law of physics, quite quickly, and they can 
write it down in a couple of sentences on a single piece of paper and also 
utilise it whenever and wherever they see fit. The Engineer "A" charges about 
$40 to implement a lever.

- Engineer "B" doesn't understand what a lever does, but he does have a 1000 
page book that illustrates almost every possible use of a lever, so when he 
finds a need, he looks up his well indexed book, which only takes a few minutes 
at the most... and then he can effectively do 90% of what Engineer "A" can do, 
but not actually understanding it, his implementations aren't as good. His 
apprentices get a copy of this book which only costs them $40 and which they 
have to familiarise themselves with. The book weighs two pounds, and they have 
to take it everywhere. The Engineer "B" charges only $50 to implement one of 
his 1000 page book ideas... he also charges $10 per minute that it takes to 
look it up.

> - The two orders of magnitude that seem to come from problem oriented
>   languages may not come from _only_ those.  It could come from the
>   removal of features, as well as better engineering principles,
>   meaning I'm counting some causes twice.
> 
> Loup.

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

Re: [fonc] Error trying to compile COLA

[Julian Leviston]

Structural optimisation is not compression. Lurk more.

Julian

On 28/02/2012, at 3:38 PM, BGB wrote:

> granted, I remain a little skeptical.
> 
> I think there is a bit of a difference though between, say, a log table, and 
> a typical piece of software.
> a log table is, essentially, almost pure redundancy, hence why it can be 
> regenerated on demand.
> 
> a typical application is, instead, a big pile of logic code for a wide range 
> of behaviors and for dealing with a wide range of special cases.
> 
> 
> "executable math" could very well be functionally equivalent to a "highly 
> compressed" program, but note in this case that one needs to count both the 
> size of the "compressed" program, and also the size of the program needed to 
> "decompress" it (so, the size of the system would also need to account for 
> the compiler and runtime).
> 
> although there is a fair amount of redundancy in typical program code (logic 
> that is often repeated,  duplicated effort between programs, ...), 
> eliminating this redundancy would still have a bounded reduction in total 
> size.
> 
> increasing abstraction is likely to, again, be ultimately bounded (and, 
> often, abstraction differs primarily in form, rather than in essence, from 
> that of moving more of the system functionality into library code).
> 
> 
> much like with data compression, the concept commonly known as the "Shannon 
> limit" may well still apply (itself setting an upper limit to how much is 
> expressible within a given volume of code).

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

Re: [fonc] Error trying to compile COLA

[Julian Leviston]

Hi,

Comments line...

On 27/02/2012, at 5:33 PM, BGB wrote:

>> 
>> I don't think it was a prank. It's not really hidden at all. If you pay 
>> attention, all the components of Frank are there... like I said. It's 
>> obviously missing certain things like Nothing, and other optimisations, but 
>> for the most part, all the tech is present.
> 
> sorry for asking, but is their any sort of "dense people friendly" version, 
> like maybe a description on the Wiki or something?...
> 
> like, so people can get a better idea of "what things are about and how they 
> all work and fit together"?... (like, in the top-down description kind of 
> way?).
> 

I don't think this is for people who aren't prepared to roll up their sleeves 
and try things out. For a start, learn SmallTalk. It's not hard. Go check out 
squeak. There are lots of resources to learn SmallTalk.


> 
>> My major stumbling block at the moment is understanding OMeta fully. This is 
>> possibly the most amazing piece of work I've seen in a long, long time, and 
>> there's no easy explanation of it, and no really simple explanation of the 
>> syntax, either. There are the papers, and source code and the sandboxes, but 
>> I'm still trying to understand how to use it. It's kind of huge. I think 
>> perhaps I need to get a grounding in PEGs before I start on OMeta because 
>> there seems to be a lot of assumed knowledge there. Mostly I'm having 
>> trouble with the absolute, complete basics.
>> 
>> Anyway I digress... have you had a look at this file?:
>> 
>> http://piumarta.com/software/maru/maru-2.1/test-pepsi.l
>> 
>> Just read the whole thing - I found it fairly interesting :) He's build 
>> pepsi on maru there... that's pretty fascinating, right? Built a micro 
>> smalltalk on top of the S-expression language... and then does a Fast 
>> Fourier Transform test using it...
>> 
> 
> my case: looked some, but not entirely sure how it works though.
> 

You could do what I've done, and read the papers and then re-read them and 
re-read them and re-read them... and research all references you find (the 
whole site is totally full of references to the entire of programming history). 
I personally think knowing LISP and SmallTalk, some assembler, C, Self, 
Javascript and other things is going to be incredibly helpful. Also, math is 
the most helpful! :)

Julian

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

Re: [fonc] Error trying to compile COLA

[Julian Leviston]

> 
> boot-eval.c  boot.l  emit.l  eval.l  Makefile
> 
> So, the ".l" files are  
> 
> So this is the file extension for Maru's implementation language (does it 
> have a name?).
> 
> Sure enough, the very first line of "eval.l" reads:
> 
> ;;; -*- coke -*-
> 
> This made me smile. Well, actually it was a mad laughter.
> 
> It compiles beautifully. Yay!
> 
> Now there are some ".s" files. They look like assembler code. I thought it 
> was Nothing code, but the Maru webpage explains it's just ia-32. Oh, well. I 
> don't know yet where Nothing enters the picture.
> 
> So, this is compiled to ".o" files and linked to build the "eval"  
> executable, which can take ".l" files and make a new "eval" 
>  executable, and so on. So far so good.
> 
> But what else can I do with it? Should I use it to run the examples at 
> "http://tinlizzie.org/dbjr/"; ? All I see is files with a ".lbox" file 
> extension. What are those? Apparently, there are no READMEs. Could you please 
> give me an example of how to try one of those experiments?
> 
> Thanks for your tips and patience ;)
> 
> 
> 
> 
> On Sun, Feb 26, 2012 at 3:48 AM, Julian Leviston  wrote:
> As I understand it, Frank is an experiment that is an extended version of 
> DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile, 
> which sits atop maru all of which which utilise ometa and the "worlds" idea.
> 
> If you look at the http://vpri.org/html/writings.php page you can see a 
> pattern of progression that has emerged to the point where Frank exists. From 
> what I understand, maru is the finalisation of what began as pepsi and coke. 
> Maru is a simple s-expression language, in the same way that pepsi and coke 
> were. In fact, it looks to have the same syntax. Nothing is the layer 
> underneath that is essentially a symbolic computer - sitting between maru and 
> the actual machine code (sort of like an LLVM assembler if I've understood it 
> correctly).
> 
> They've hidden Frank in plain sight. He's a patch-together of all their 
> experiments so far... which I'm sure you could do if you took the time to 
> understand each of them and had the inclination. They've been publishing as 
> much as they could all along. The point, though, is you have to understand 
> each part. It's no good if you don't understand it.
> 
> If you know anything about Alan & VPRI's work, you'd know that their focus is 
> on getting children this stuff in front as many children as possible, because 
> they have so much more ability to connect to the heart of a problem than 
> adults. (Nothing to do with age - talking about minds, not bodies here). 
> Adults usually get in the way with their "stuff" - their "knowledge" sits 
> like a kind of a filter, denying them the ability to see things clearly and 
> directly connect to them unless they've had special training in relaxing that 
> filter. We don't know how to be simple and direct any more - not to say that 
> it's impossible. We need children to teach us meta-stuff, mostly this direct 
> way of experiencing and looking, and this project's main aim appears to be to 
> provide them (and us, of course, but not as importantly) with the tools to do 
> that. Adults will come secondarily - to the degree they can't embrace new 
> stuff ;-). This is what we need as an entire populace - to increase our 
> general understanding - to reach breakthroughs previously not thought 
> possible, and fast. Rather than changing the world, they're providing the 
> seed for children to change the world themselves.
> 
> This is only as I understand it from my observation. Don't take it as gospel 
> or even correct, but maybe you could use it to investigate the parts of frank 
> a little more and with in-depth openness :) The entire project is an 
> experiment... and that's why they're not coming out and saying "hey guys this 
> is the product of our work" - it's not a linear building process, but an 
> intensively creative process, and most of that happens within oneself before 
> any results are seen (rather like boiling a kettle).
> 
> http://www.vpri.org/vp_wiki/index.php/Main_Page
> 
> On the bottom of that page, you'll see a link to the tinlizzie site that 
> references "experiment" and the URL has dbjr in it... as far as I understand 
> it, this is as much frank as we've been shown.
> 
> http://tinlizzie.org/dbjr/
> 
> :)
> Julian
> 
> 
> 
> ___
> 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] Error trying to compile COLA

[Julian Leviston]

What does any of what you just said have to do with the original question about 
COLA?

Julian

On 26/02/2012, at 9:25 PM, BGB wrote:

> On 2/25/2012 7:48 PM, Julian Leviston wrote:
>> 
>> As I understand it, Frank is an experiment that is an extended version of 
>> DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile, 
>> which sits atop maru all of which which utilise ometa and the "worlds" idea.
>> 
>> If you look at the http://vpri.org/html/writings.php page you can see a 
>> pattern of progression that has emerged to the point where Frank exists. 
>> From what I understand, maru is the finalisation of what began as pepsi and 
>> coke. Maru is a simple s-expression language, in the same way that pepsi and 
>> coke were. In fact, it looks to have the same syntax. Nothing is the layer 
>> underneath that is essentially a symbolic computer - sitting between maru 
>> and the actual machine code (sort of like an LLVM assembler if I've 
>> understood it correctly).
>> 
> 
> yes, S-Expressions can be nifty.
> often, they aren't really something one advertises, or uses as a front-end 
> syntax (much like Prototype-OO and delegation: it is a powerful model, but 
> people also like their classes).
> 
> so, one ends up building something with a C-like syntax and Class/Instance 
> OO, even if much of the structure internally is built using lists and 
> Prototype-OO. if something is too strange, it may not be received well though 
> (like people may see it and be like "just what the hell is this?"). better 
> then if everything is "just as could be expected".
> 
> 
> in my case, they are often printed out in debugging messages though, as a lot 
> of my stuff internally is built using lists (I ended up recently devising a 
> specialized network protocol for, among other things, sending compressed 
> list-based messages over a TCP socket).
> 
> probably not wanting to go too deeply into it, but:
> it directly serializes/parses the lists from a bitstream;
> a vaguely JPEG-like escape-tag system is used;
> messages are Huffman-coded, and make use of both a value MRU/MTF and LZ77 
> compression (many parts of the coding also borrow from Deflate);
> currently, I am (in my uses) getting ~60% additional compression vs 
> S-Expressions+Deflate, and approximately 97% compression vs plaintext (plain 
> Deflate got around 90% for this data).
> 
> the above was mostly used for sending scene-graph updates and similar in my 
> 3D engine, and is maybe overkill, but whatever (although, luckily, it means I 
> can send a lot more data while staying within a reasonable bandwidth budget, 
> as my target was 96-128 kbps, and I am currently using around 8 kbps, vs 
> closer to the 300-400 kbps needed for plaintext).
> 
> 
>> They've hidden Frank in plain sight. He's a patch-together of all their 
>> experiments so far... which I'm sure you could do if you took the time to 
>> understand each of them and had the inclination. They've been publishing as 
>> much as they could all along. The point, though, is you have to understand 
>> each part. It's no good if you don't understand it.
>> 
> 
> possibly, I don't understand a lot of it, but I guess part of it may be 
> knowing what to read.
> there were a few nifty things to read here and there, but I wasn't really 
> seeing the larger whole I guess.
> 
> 
>> If you know anything about Alan & VPRI's work, you'd know that their focus 
>> is on getting children this stuff in front as many children as possible, 
>> because they have so much more ability to connect to the heart of a problem 
>> than adults. (Nothing to do with age - talking about minds, not bodies 
>> here). Adults usually get in the way with their "stuff" - their "knowledge" 
>> sits like a kind of a filter, denying them the ability to see things clearly 
>> and directly connect to them unless they've had special training in relaxing 
>> that filter. We don't know how to be simple and direct any more - not to say 
>> that it's impossible. We need children to teach us meta-stuff, mostly this 
>> direct way of experiencing and looking, and this project's main aim appears 
>> to be to provide them (and us, of course, but not as importantly) with the 
>> tools to do that. Adults will come secondarily - to the degree they can't 
>> embrace new stuff ;-). This is what we need as an entire populace - to 
>> increase our general understanding - to reach breakthroughs previously not 
>> thought possible, and fast. Rather than changing the world, t

Re: [fonc] Error trying to compile COLA

[Julian Leviston]

As I understand it, Frank is an experiment that is an extended version of DBJr 
that sits atop lesserphic, which sits atop gezira which sits atop nile, which 
sits atop maru all of which which utilise ometa and the "worlds" idea.

If you look at the http://vpri.org/html/writings.php page you can see a pattern 
of progression that has emerged to the point where Frank exists. From what I 
understand, maru is the finalisation of what began as pepsi and coke. Maru is a 
simple s-expression language, in the same way that pepsi and coke were. In 
fact, it looks to have the same syntax. Nothing is the layer underneath that is 
essentially a symbolic computer - sitting between maru and the actual machine 
code (sort of like an LLVM assembler if I've understood it correctly).

They've hidden Frank in plain sight. He's a patch-together of all their 
experiments so far... which I'm sure you could do if you took the time to 
understand each of them and had the inclination. They've been publishing as 
much as they could all along. The point, though, is you have to understand each 
part. It's no good if you don't understand it.

If you know anything about Alan & VPRI's work, you'd know that their focus is 
on getting children this stuff in front as many children as possible, because 
they have so much more ability to connect to the heart of a problem than 
adults. (Nothing to do with age - talking about minds, not bodies here). Adults 
usually get in the way with their "stuff" - their "knowledge" sits like a kind 
of a filter, denying them the ability to see things clearly and directly 
connect to them unless they've had special training in relaxing that filter. We 
don't know how to be simple and direct any more - not to say that it's 
impossible. We need children to teach us meta-stuff, mostly this direct way of 
experiencing and looking, and this project's main aim appears to be to provide 
them (and us, of course, but not as importantly) with the tools to do that. 
Adults will come secondarily - to the degree they can't embrace new stuff ;-). 
This is what we need as an entire populace - to increase our general 
understanding - to reach breakthroughs previously not thought possible, and 
fast. Rather than changing the world, they're providing the seed for children 
to change the world themselves.

This is only as I understand it from my observation. Don't take it as gospel or 
even correct, but maybe you could use it to investigate the parts of frank a 
little more and with in-depth openness :) The entire project is an 
experiment... and that's why they're not coming out and saying "hey guys this 
is the product of our work" - it's not a linear building process, but an 
intensively creative process, and most of that happens within oneself before 
any results are seen (rather like boiling a kettle).

http://www.vpri.org/vp_wiki/index.php/Main_Page

On the bottom of that page, you'll see a link to the tinlizzie site that 
references "experiment" and the URL has dbjr in it... as far as I understand 
it, this is as much frank as we've been shown.

http://tinlizzie.org/dbjr/

:)
Julian

On 26/02/2012, at 9:41 AM, Martin Baldan wrote:

> Is that the case? I'm a bit confused. I've read the fascinating reports about 
> Frank, and I was wondering what's the closest thing one can download and run 
> right now. Could you guys please clear it up for me?
> 
> Best,
> 
> Martin
> 
> On Sat, Feb 25, 2012 at 5:23 PM, Julian Leviston  wrote:
> Isn't the cola basically irrelevant now? aren't they using maru instead? (or 
> rather isn't maru the renamed version of coke?)
> 
> Julian
> 
> 
> On 26/02/2012, at 2:52 AM, Martin Baldan wrote:
> 
> > Michael,
> >
> > Thanks for your reply. I'm looking into it.
> >
> > Best,
> >
> >  Martin
> > ___
> > 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] Error trying to compile COLA

[Julian Leviston]

Isn't the cola basically irrelevant now? aren't they using maru instead? (or 
rather isn't maru the renamed version of coke?)

Julian


On 26/02/2012, at 2:52 AM, Martin Baldan wrote:

> Michael,
> 
> Thanks for your reply. I'm looking into it.
> 
> Best,
> 
>  Martin
> ___
> 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] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Julian Leviston]

Hiya,

On 13/02/2012, at 2:47 PM, Kurt Stephens wrote:

> Read Ian Piumarta's "Open, extensible object models" ( 
> http://piumarta.com/software/cola/objmodel2.pdf ).
> At a certain level, send(), lookup() and apply() have bootstrap 
> implementations to break the infinite regress.  TORT was directly inspired by 
> Ian's paper.  MOS (written a while ago) has a very similar object model and 
> short-circuit.  There is an object, well-known by the system, that describes 
> its self -- this is where the short-circuit lives.
> 

Yeah I've read it about 20 times. I found it quite difficult... (mostly because 
of the fact that I didn't understand some of the C idioms, but also because the 
architecture was difficult to comprehend for me in general). Ian's object model 
didn't actually reify message though, did it? I should go read it more. I wish 
that it was more accessible to me, and/or that I could somehow increase my 
ability to comprehend it. Any further recommendations for things to read along 
this lines? I'm QUITE interested (this was my favourite part of the FoNC 
project to a point).

> A graph of TORT's object model is here: 
> http://kurtstephens.com/pub/tort/tort.svg .  It's turtles all the way down, 
> er... um... to the right.  The last turtle, the "method table", is chewing 
> its tail. :)
> 
>>> I'm not a fan of HTTP/SOAP bloat.  The fundamentals are often bulldozed by 
>>> it.
>> 
>> How about REST?
>> 
> REST is not object messaging or HTTP.
> 

REST works over HTTP. It can be object messaging, can't it? At least, as far as 
my understanding and implementations have gone. Maybe I'm deluded.


> -- Kurt
> 
> ___
> 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] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?

[Julian Leviston]

On 13/02/2012, at 6:01 AM, Kurt Stephens wrote:

> On 2/12/12 11:15 AM, Steve Wart wrote:
> 
>> Can the distributed computation model you describe be formalized as a
>> set of rewrite rules, or is the "black box" model really about a
>> protocol for message dispatch? Attempts to build distributed messaging
>> systems haven't been particularly simple. In fact I consider both CORBA
>> and Web Services to be failures for that reason.
> 
> Perhaps it's because the "Message" in OO systems is often forgotten: message 
> passing is described as "calling a method", instead of "sending a message".
> 
> Many languages do not reify the message itself as an object.
> 
> If send(sel, rcvr, args) can decomposed into apply(lookup(sel, rcvr, args), 
> rcvr, args), then this follows:
> 
>  Message.new(sel, rcvr, args).lookup().apply()
> 
> Tort does this, so does MOS ( 
> http://kurtstephens.com/pub/mos/current/src/mos/ ), however Ruby, for 
> example, does not -- not sure how many others do.
> 
> The Self Language handles apply() by cloning the method object, assigning 
> arguments into its slots, then transferring control to the object's code 
> slot.  Yet, there is still no tangible Message object.
> 

I don't follow why a "message" isn't simply a token. For example, in Ruby, a 
message is simply a symbol, is it not? One has to draw the line in the sand at 
some point. Why bother building an entire object for something which simply 
holds reference to a Method name (or not, as the case may be)? In this case, 
the media *is* the message, is it not? ;-) or are you stipulating that a 
Message would know how to perform lookup and call, and therefore warrants an 
entire class... the only issue here is that  of efficiency, isn't it?

Sorry if I'm asking really obviously answerable questions. Please bear with me. 
I'm eager to learn.

Another question I have, is, how do you solve the obvious recursive quality of 
having Message.new(sel, scr, args) and also then sending messages to the 
message object? Is "new" the bottom-out point?


>> It's very difficult to use OO in this way without imposing excessive
>> knowledge about the internal representation of objects if you need to
>> serialize parameters or response objects.
>> 
> 
> Remembering there is an implicit Message object behind the scenes makes 
> message distribution a bottom-up abstraction, starting with identity 
> transforms:
> 
> http://kurtstephens.com/pub/abstracting_services_in_ruby/asir.slides/index.html
> 
> This doesn't fully remove the serialization issues, but those are readily, 
> and often already, solved.  One generic serialization is suitable for the 
> parameters and the message objects; decomposed into Request and Response 
> objects.  The Transport is then agnostic of encoding/decoding details.
> 
>> HTTP seems to have avoided this by using MIME types, but this is more
>> about agreed upon engineering standards rather than computational
>> abstractions.
>> 
> 
> I'm not a fan of HTTP/SOAP bloat.  The fundamentals are often bulldozed by it.

How about REST?

> 
>> Cheers,
>> Steve
>> 
> 
> -- Kurt

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

Re: [fonc] One more year?!

[Julian Leviston]

How about symbolic sound Kyma? I think that's an amazing platform - hopefully 
I'll get it soon 

http://www.symbolicsound.com

Julian

On 24/01/2012, at 6:20 AM, GrrrWaaa wrote:

> Max/MSP (which I know a couple of people on this list are very familiar with) 
> is one amongst a huge history of other visual, textual and visual+textual 
> programming languages to think about taking apart and putting together 
> structures in time (such as music). In particular, people on this list might 
> be interested in these, which arguably have more fonc than Live/Logic etc:
> 
> http://en.wikipedia.org/wiki/OpenMusic
> http://www2.siba.fi/pwgl/pwglsynth.html
> https://github.com/digego/extempore
> 
> On Jan 22, 2012, at 9:29 PM, Julian Leviston wrote:
> 
>> 
>> On 23/01/2012, at 4:17 PM, BGB wrote:
>> 
>>> as opposed to either manually placing samples on a timeline (like in 
>>> Audacity or similar), or the stream of note-on/note-off pulses and delays 
>>> used by MIDI, an alternate idea comes up:
>>> one has a number of delayed relative "events", which are in-turn piped 
>>> through any number of filters.
>>> 
>>> then one can procedurally issue commands of the form "in N seconds from 
>>> now, do this", with commands being relative to a base-time (and the ability 
>>> to adjust the base-time based either on a constant value or how long it 
>>> would take a certain "expression" to finish playing).
>>> 
>>> likewise, expressions/events can be piped through filters.
>>> filters could either apply a given effect (add echo or reverb, ...), or 
>>> could be structural (such as to repeat or loop a sequence, potentially 
>>> indefinitely), or possibly sounds could be entirely simulated (various 
>>> waveform patterns, such as sine, box, and triangle, ...).
>> 
>> Heya,
>> 
>> Yeah, I've had that idea for a while - although a more comprehensive one (I 
>> write music). Take a look at what Apple did to their own product Final Cut 
>> Pro... to turn it into Final Cut Pro X, and notice that there are rumors 
>> surrounding Logic Pro X, and I'm pretty sure you'll see that this idea is 
>> where Apple will most likely go when they release Logic Pro X.
>> 
>> In Final Cut Pro, they call it their "magic timeline".
>> 
>> By the way, what you're describing CAN be done with Ableton Live without 
>> much trouble... also Ableton Live has the ability to use Max for Live, which 
>> is Cycling 74's excellent Max/MSP product inlined into a Live instrument 
>> (what you're calling various waveform patterns). It's sine, square/pulse and 
>> triangle by the way, not "box"... and we also can use all sorts of other 
>> waveforms... generated or sampled...
>> 
>> Julian
>> ___
>> 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] One more year?!

[Julian Leviston]

On 23/01/2012, at 4:17 PM, BGB wrote:

> as opposed to either manually placing samples on a timeline (like in Audacity 
> or similar), or the stream of note-on/note-off pulses and delays used by 
> MIDI, an alternate idea comes up:
> one has a number of delayed relative "events", which are in-turn piped 
> through any number of filters.
> 
> then one can procedurally issue commands of the form "in N seconds from now, 
> do this", with commands being relative to a base-time (and the ability to 
> adjust the base-time based either on a constant value or how long it would 
> take a certain "expression" to finish playing).
> 
> likewise, expressions/events can be piped through filters.
> filters could either apply a given effect (add echo or reverb, ...), or could 
> be structural (such as to repeat or loop a sequence, potentially 
> indefinitely), or possibly sounds could be entirely simulated (various 
> waveform patterns, such as sine, box, and triangle, ...).

Heya,

Yeah, I've had that idea for a while - although a more comprehensive one (I 
write music). Take a look at what Apple did to their own product Final Cut 
Pro... to turn it into Final Cut Pro X, and notice that there are rumors 
surrounding Logic Pro X, and I'm pretty sure you'll see that this idea is where 
Apple will most likely go when they release Logic Pro X.

In Final Cut Pro, they call it their "magic timeline".

By the way, what you're describing CAN be done with Ableton Live without much 
trouble... also Ableton Live has the ability to use Max for Live, which is 
Cycling 74's excellent Max/MSP product inlined into a Live instrument (what 
you're calling various waveform patterns). It's sine, square/pulse and triangle 
by the way, not "box"... and we also can use all sorts of other waveforms... 
generated or sampled...

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

Re: [fonc] One more year?!

[Julian Leviston]

On 23/01/2012, at 2:30 PM, BGB wrote:

> little if anything in that area that generally makes me think "dubstep" 
> though...
> 
> (taken loosely enough, most "gangsta-rap" could be called "dubstep" if one 
> turns the sub-woofer loud enough, but this is rather missing the point...).

Listen to this song. It's dubstep. Popular dubstep has been raped to mean 
"brostep" or what skrillex plays... but this song is original dubstep.

two cents. mine.

http://www.youtube.com/watch?v=IlEkvbRmfrA___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] One more year?!

[Julian Leviston]

I agree wholeheartedly with you Casey...

There are such parallels with structure here... it's just vibrational structure 
- patterns. There are SO MANY parallels here (and other places) that sometimes 
my heads hurts with the feel of all of it.

It's at once intensely beautiful and painful because there's so little 
understanding around it.

Love,
Julian

On 23/01/2012, at 12:48 PM, Casey Ransberger wrote:

> Below. 
> 
> On Jan 22, 2012, at 1:51 PM, Reuben Thomas  wrote:
> 
>> On 22 January 2012 21:26, Casey Ransberger  wrote:
>>> Below.
>>> 
>>> On Jan 21, 2012, at 6:26 PM, BGB  wrote:
>>> 
 like, for example, if a musician wanted to pursue various musical forms.
 say, for example: a dubstep backbeat combined with rap-style lyrics sung
 using a death-metal voice or similar, without "the man" (producers, ...)
 demanding all the time that they get a new album together
>> 
>> Only art is not science: it doesn't have pieces you can take apart and
>> reuse in the same way (technique does).
>> 
>> So it's not an analogy that works.
>> 
>> (I did a PhD in computer science, and I make my living as a singer.)
>> 
>> -- 
>> http://rrt.sc3d.org
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
> 
> Music has parts you can disassemble and reuse. We do it all the time. I 
> appoigized to my father for stealing and warping his song, when I sent him a 
> song he wrote about me when I was a kid that I never liked, with every 
> lyrical assertion reversed.
> 
> I was afraid it would upset him. His reply was, "You've done nothing wrong. 
> This is the folk process."
> 
> Whatever the hell that means, anyway I spiked my mohawk and went to work. 
> 
> I can take a single measure of your music and produce variations based on it. 
> I can take a single line from a four part harmony you've written, transpose 
> it, change the key signature, even change the mode, and hand it back to you 
> with a string orchestra. 
> 
> We're way the hell off topic here, but I have to admit being stunned to hear 
> that a musician cannot fathom taking a piece of music apart and reusing parts 
> of it. How many guitar songs use G-D-C for the chord progression? Have you 
> ever heard of theme and variations?
> 
> Your argument about art doesn't stand. 
> 
> C 
> ___
> 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] One more year?!

[Julian Leviston]

On 23/01/2012, at 12:34 PM, BGB wrote:

> I was more giving it as an example of basically wanting to do one thing while 
> being obligated (due to prior work) to do something very different.
> 

Yeah, sorry for diverging :) I actually realised that.

> say, if a musician (or scientist/programmer/...) has an established audience, 
> and is expected to produce "more of the same", they may have less personal 
> freedom to explore other alternatives (and doing so may alienate many of 
> their fans). an real-life example being, for example, Metallica incorporating 
> a lot of Country Western elements.
> 
> in the example, the idea is that the producers may know full well that if 
> their promoted boy-band suddenly released an album containing lots of bass 
> and growling (rather than dancing around on stage being pretty-boys) then the 
> audience of teenage girls might be like "what the hell is this?" and become 
> disillusioned with the band (costing the producers a pile of money).
> 
> this does not necessarily mean that an idea is fundamentally new or original 
> though.

True... but in this case (as in the one you're paralleling - the one of VPRI) 
it'd likely attract a new audience that appreciate it.

Julan

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

Re: [fonc] One more year?!

[Julian Leviston]

On 23/01/2012, at 8:26 AM, Casey Ransberger wrote:

> Below. 
> 
> On Jan 21, 2012, at 6:26 PM, BGB  wrote:
> 
>> like, for example, if a musician wanted to pursue various musical forms. 
>> say, for example: a dubstep backbeat combined with rap-style lyrics sung 
>> using a death-metal voice or similar, without "the man" (producers, ...) 
>> demanding all the time that they get a new album together (or that their 
>> fans and "the man" expect them to stay with their existing sound and theme), 
>> and if they just gave them something which was like "and so wub-wub-wub, 
>> goes the sub-sub-sub, as the lights go blim-blim-blim, as shorty goes 
>> rub-run-run, on my hub-hub-hub, as my rims go spin-spin-spin" or 
>> something... (all sung in deep growls and roars), at which point maybe the 
>> producers would be very unhappy (say, if he was hired on to be part of a 
>> tween-pop boy-band, and adolescent females may respond poorly to bass-filled 
>> "wubbing growl-rap", or something...).
>> 
>> 
>> or such...
> 
> This is probably the raddest metaphor that I have ever seen on a mailing list.
> 
> BGB FTW!
> 
> P.S. 
> 
> If you want to get this song out the door, I'm totally in. Dubsteprapmetal 
> might be the next big thing. I can do everything except the drums. We should 
> write an elegant language for expressing musical score in OMeta and use a 
> simulated orchestra!

Oh come on, Dub Step Rap Metal has been done before... Korn is basically what 
that is...  Just because you're not CALLING it dubstep doesn't mean it doesn't 
have the dubstep feel. 

Interesting, also, that you chose dubstep here, because that's a genre that's 
been basically "raped" in a similar way to what has been done to the ideas in 
object-orientism in order to get it into the mainstream :) People think dubstep 
is just a wobble bass... but it's actually more about the feel of the dub 
break... 

Julian


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

Re: [fonc] One more year?!

[Julian Leviston]

On 21/01/2012, at 9:56 PM, Casey Ransberger wrote:

> 
> Thanks for your passionate words. I hope you'll forgive my natural 
> predisposition to supply a counter-argument. It turns out that I can barely 
> help it, it's just my nature:)
> 
> Here's a project where we have some people trying to do something that a lot 
> of people have wanted to try, but haven't gotten around to. This is something 
> which is in a sense completely new; yes, most of us work in several languages 
> on a daily basis. But are these the right set of languages to get our work 
> done most efficiently? Is there a better set?
> 
> And: while artists in other fields were able to stand on the shoulders of 
> giants, programmers, generally speaking (and this is my own feeling,) have to 
> stand on a pile of dogshit. 
> 
> While we could criticize this work as shipping late, we might also note that 
> most software projects ship both late and *over budget.*
> 
> Here's a project, even a *research* project, that's shipping late strictly 
> because in four years, these people were able to come in so far under budget 
> as to buy themselves another year of invention. 
> 
> Tom West called it "pinball," you work your ass off, you do a good job, and 
> if you're lucky, they let you do it again. One of the things he was famous 
> for was "pinching his quarters," because the real game wasn't what he was 
> doing then, it was about what he was doing *next.*
> 
> West was banking everything he had to get a free ball. 
> 
> I'd like to express my unrepentant, unapologetic congratulations to 
> *everyone* who was a part of making this unique, fantastic inquiry last a 
> full year longer than we thought it would, and for involving the unwashed 
> industrial masses (read: me) in the conversation.
> 
> This continues to enrich my life and I'm damned happy to see it go on another 
> year. 
> 
> 
> Thank you.
> 
> Excelsior!
> 
> 
> Casey Ransberger


I'm in agreement, Casey. I didn't see the project is "shipping late", but 
rather "under-budget so able to extend another year". I was actually quite 
happy to see it go on a further year.

Besides, it's not as though the products of the project haven't gone 
unannounced, unreleased or are in any way secret - quite the opposite. Where 
they have been finished as much as to be useful, they've been released as 
experimental prototypes or even working systems.

Sure, Frank isn't "out" yet... but as far as I understand it even Frank isn't 
the final "product", but rather part of a precursor to a more polished set of 
ideas which exist as simples and beautiful integrated pieces of "executable 
art". (Just as Smalltalk and Self were, in my opinion).

This kind of work is not the same as "normal" projects that proceed in a linear 
fashion IMHO. Truly innovative works never proceed in time in the "normal" way, 
as far as I am able to see.

I hope I haven't caused any offence by writing this. I just feel - like you, 
Casey - that something needs to be contributed to this discussion in the 
contrasting position. I'll leave it at that.

Much Love,
Julian

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

Re: [fonc] Inspired 3D Worlds

[Julian Leviston]

On 18/01/2012, at 6:47 PM, David Barbour wrote:

> 
> 
> On Tue, Jan 17, 2012 at 10:02 PM, Julian Leviston  wrote:
> 
> Noted, but not relevant to my point.
> 
> Oh? You say that without any explanation? Perhaps you need some hand holding 
> to follow my logic.
> 
> 1) You make an argument about contexts being `awe inspiring to humanity as a 
> whole`. 
> 2) Given the human potential for psychopathy, autism, aspergers, and other 
> psychological classifications, it is impossible to find anything 
> awe-inspiring to all humans. 
> 3) Therefore, your `humanity as a whole` reduces to a statistical argument 
> about a group of humans. 
> 4) I describe your argument as `an anthropocentric statistical metric`.
> 5) I point out that even such metrics are influenced (subject to) culture. 
> 6) Therefore, my argument is relevant to your point.
> 
> Indeed, I believe it completely undermines your point. `awe-inspiring` is 
> simply not an objective property.

No hand-holding required. Really? Lack of capacity in the beholder is your 
argument against the existence of the objectivity of the impact of certain 
parts of art that I'm here calling "objective art"? Would you also say that the 
inability of certain individuals to understand certain difficult parts of math 
renders those parts false? I think you might be getting caught up on individual 
words I'm using rather than their meaning in sum.

It might simply be that we'll have to agree to disagree. You don't seem 
interested in understanding what I have to say, which is just fine.

>  
> 
> I'd posit that everything is inherently related. I call this inherent 
> relationship context, or "is-ness" if you will.
> 
> How is such a position - which doesn't seem to make any distinctions - useful 
> in this context? Actually, how is it useful for anything whatsoever? 
>  

To those who this matters to, this is possibly the most useful thing there is. 
Hehe... I present one of the most fundamentally interesting and "obvious, yet 
missed" aspects about life (for me, no doubt), and you subtly deride me for it. 
:P


>> 
>> Sure. Over at http://hof.povray.org/
> 
> Sorry I was implying given a technologically-driven only context. (As in... 
> impossible without high technology) All of those works could be theoretically 
> done more or less with an analogue medium, no?
> 
> Speaking of the theoretically possible is always a fun and fantastic 
> exercise. Theoretically, all the oxygen in your room could just happen to 
> miss your lungs for the few minutes it takes to die. Theoretically, cosmic 
> rays could flip bits into jpeg-encoded pornography on your computer. 
> Theoretically, yes, those images could be generated on an analogue medium. 
> 

I've seen similar such works to (almost?) all of the images on that website 
generated in analogue media. My point here is that certain things can't be done 
in analogue media.

I'm feeling a bit like you don't like my word choice of "theoretically". I'm 
sorry that choosing that word has irritated you as much as it did or didn't 
irritate you.

> But if we speak in practical terms - of what is `feasible` rather than what 
> is `possible` - then, no, those images would not be created in an analog 
> medium. They are the result of trial and error and tweaking that would be 
> `infeasible` in human time frames without the technology. The precision of 
> light and shadow would similarly be infeasible. 

I disagree. Given enough time and photoshop or illustrator, people could build 
those images.

>  
> 
> long-lasting impacting meaning "the impact lasts for a long time" not as in 
> the sense that the activity itself is long-lasting.
> 
> Of the things I've found inspiring that had a long-lasting impact, none 
> inspired `awe`.
> 

I'll take your word on that.

> Regards,
> 
> Dave
> 

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

Re: [fonc] Inspired 3D Worlds

[Julian Leviston]

On 18/01/2012, at 4:46 PM, David Barbour wrote:

> I would note my topic line is `inspired 3D worlds`, not `inspiring 3D 
> worlds`. There is a rather vast difference in meaning. ;)

Oh, beautiful wordsmith, treat me one time of thy intellect distilled. :)

> 
> On Tue, Jan 17, 2012 at 8:50 PM, Julian Leviston  wrote:
> you may find on closer inspection that there can be things that are 
> intrinsically beautiful, or intrinsically awe-inspiring to humanity as a 
> whole.
> 
> Even an anthropocentric statistical metric will be subject to cultural 
> influence. I do grant that humans are likely to find `great heights` and `big 
> explosions` and `loud music` and other such things awe-inspiring on a very 
> primitive level, but I imagine that cultural exposure to them would suppress 
> the feeling in a statistically measurable way. 

Noted, but not relevant to my point.

> 
> it nonetheless matters in a general sense to aspire to such a high standard 
> of quality in everything
> 
> Do keep in mind the fallacy of the beard. There is a significant relationship 
> between quantity and quality, even if it isn't an obvious one. There are also 
> relationships between costs and quality - e.g. flat pay-per-text can 
> completely undermine various story or data distribution models. 

I'd posit that everything is inherently related. I call this inherent 
relationship context, or "is-ness" if you will.

> Given limited resources and limited control over our environment, it does not 
> always make sense to aspire to high standards of quality.
> 

Evidently.

> 
> Also, a question that springs to mind is... do you find any of the popularly 
> "impressive" movies or graphics of the current day awe-inspiring?
> 
> Sure. Over at http://hof.povray.org/

Sorry I was implying given a technologically-driven only context. (As in... 
impossible without high technology) All of those works could be theoretically 
done more or less with an analogue medium, no?

I was thinking more of things along the lines of the commodore 64 game 
Archon... which is a boardgame similar to chess with a twist (take a piece and 
you have to fight out for the square's possession in a real time arcade-type 
simulation fight).

Chess is a great example of something where the meaning isn't changed if played 
on a physical board versus an electronic one. I actually find real life chess 
more impressive in terms of the medium than I do the digital variety. The 
digital variety is often times more convenient (I can play it over the internet 
from my phone that is in my pocket for example), but the graphics aren't as 
good on the phone as they are in reality... ;-)

> 
>  
> I find them quite cool... impressive in a technical sense, but not in a 
> long-lasting impacting sense...
> 
> I do not believe awe-inspiring connotes long-lasting. Ever seen an 
> awe-inspiring thermite fire? judo throw? belch? live theatrical play?
> 

long-lasting impacting meaning "the impact lasts for a long time" not as in the 
sense that the activity itself is long-lasting. (ie getting punched in the face 
by an assailant while standing waiting for a train takes a moment, but it would 
impact you quite a lot if it broke your nose - this is what I mean by 
long-lasting impact).


> Regards,
> 
> Dave
> 
>  
> 
> On 18/01/2012, at 3:06 PM, David Barbour wrote:
> 
>> I understand `awe inspiring` to be subjective - hence, subject to changes in 
>> the observer, such as ephemeral mood or loss of a sensory organ. You seem to 
>> treat it as a heuristic or statistical property - i.e. it's awe inspiring 
>> because people have felt awe in the past and you expect people to feel awe 
>> in the future. 
>> 
>> I suppose I can understand either position. 
>> 
>> But it's silly to say that awe inspiring is just a property of the object - 
>> i.e. you say "without something being awe-inspiring, there's no possibility 
>> for awe to be inspired when the conditions are right." That's just too 
>> egocentric. People find all sorts of funny things awe-inspiring. Like 
>> football. Or grocery bags in the wind. 
>> (http://www.youtube.com/watch?v=VKg6OJ6zhhc)
>> 
>> Regards,
>> 
>> Dave
>> 
>> On Tue, Jan 17, 2012 at 6:35 PM, Julian Leviston  wrote:
>> No, I find it IS awe-inspiring all of the time.
>> 
>> I may not necessarily be full of awe or actually be inspired at any 
>> particular one time... however, this doesn't change the fact that certain 
>> things or people themselves are awe-inspiring all of the time to me. In 
>> other words, if I'm in a bad mood, this is in itself not necessarily any 
>> fault,

Re: [fonc] Inspired 3D Worlds

[Julian Leviston]

 a heuristic or statistical property - i.e. it's awe inspiring 
> because people have felt awe in the past and you expect people to feel awe in 
> the future. 
> 
> I suppose I can understand either position. 
> 
> But it's silly to say that awe inspiring is just a property of the object - 
> i.e. you say "without something being awe-inspiring, there's no possibility 
> for awe to be inspired when the conditions are right." That's just too 
> egocentric. People find all sorts of funny things awe-inspiring. Like 
> football. Or grocery bags in the wind. 
> (http://www.youtube.com/watch?v=VKg6OJ6zhhc)
> 
> Regards,
> 
> Dave
> 
> On Tue, Jan 17, 2012 at 6:35 PM, Julian Leviston  wrote:
> No, I find it IS awe-inspiring all of the time.
> 
> I may not necessarily be full of awe or actually be inspired at any 
> particular one time... however, this doesn't change the fact that certain 
> things or people themselves are awe-inspiring all of the time to me. In other 
> words, if I'm in a bad mood, this is in itself not necessarily any fault, 
> consequence or relationship of or to the fact that Alan Kay is still an 
> amazing person. Even in my bad mood, I recognise he is awe-inspiring.
> 
> Guess this depends what you mean by awe-inspiring (as I originally said). If 
> you re-read the original context, he was talking about inherent breathtaking 
> beauty being required or not. I think to make something inherently beautiful 
> or to construct it with detailed thought is actually very worthwhile. Without 
> something being awe-inspiring, there's no possibility for awe to be inspired 
> when the conditions are right. When something is awe inspiring, it doesn't 
> necessarily always follow that awe will be inspired, though ;-)
> 
> :P
> 
> Julian
> 
> On 18/01/2012, at 11:34 AM, David Barbour wrote:
> 
>> You don't find it awe-inspiring "all the time". (If you do, you're certainly 
>> dysfunctional.) But I readily believe you still find it inspiring "some of 
>> the time" - and that is enough to be an enriching experience. 
>> 
> 
> 
> ___
> 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] Inspired 3D Worlds

[Julian Leviston]

No, I find it IS awe-inspiring all of the time.

I may not necessarily be full of awe or actually be inspired at any particular 
one time... however, this doesn't change the fact that certain things or people 
themselves are awe-inspiring all of the time to me. In other words, if I'm in a 
bad mood, this is in itself not necessarily any fault, consequence or 
relationship of or to the fact that Alan Kay is still an amazing person. Even 
in my bad mood, I recognise he is awe-inspiring.

Guess this depends what you mean by awe-inspiring (as I originally said). If 
you re-read the original context, he was talking about inherent breathtaking 
beauty being required or not. I think to make something inherently beautiful or 
to construct it with detailed thought is actually very worthwhile. Without 
something being awe-inspiring, there's no possibility for awe to be inspired 
when the conditions are right. When something is awe inspiring, it doesn't 
necessarily always follow that awe will be inspired, though ;-)

:P

Julian

On 18/01/2012, at 11:34 AM, David Barbour wrote:

> You don't find it awe-inspiring "all the time". (If you do, you're certainly 
> dysfunctional.) But I readily believe you still find it inspiring "some of 
> the time" - and that is enough to be an enriching experience. 
> 

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

Re: [fonc] Inspired 3D Worlds

[Julian Leviston]

I guess this depends what you mean by awe-inspiring.

David this sentence somewhat disturbs me, though. I grew up in Tasmania - a 
little island at the bottom of Australia... with some of the most picturesque 
(and as you say here awe-inspiring) countryside in Australia. I can tell you 
for sure that humans don't become Jaded to it. It changes us, and vivifies us. 
I feel the same way about my balcony that overlooks the valley where I live, 
and also about the beautiful user interfaces that I use daily... these things 
impact me in a wonderful way, reminding me of the things and people I love. It 
doesn't make me jaded! Quite the opposite.

Just my two cents.

On 18/01/2012, at 11:10 AM, David Barbour wrote:

> It can't be awe inspiring all the time, anyway. Humans would quickly become 
> jaded to that sort of stimulation. 
> 

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

Re: [fonc] Inspired 3D Worlds

[Julian Leviston]

The original topic was about getting the computer to create 3d worlds. That was 
what I was referring to when I said I like minecraft's taken on it. They use a 
seed to generate the world.

Julian

On 17/01/2012, at 3:26 PM, BGB wrote:

> On 1/16/2012 8:36 PM, Julian Leviston wrote:
>> 
>> I like minecraft's take on this.
>> 
>> Julian
>> 
> 
> in which particular way?...
> 
> 
> well, Minecraft is a fairly interesting game, and allows a lot of room for 
> people building stuff, ...
> 
> the downside is:
> how well does the technology work for considerably different gameplay styles? 
> (not based on mining and building)
> what about world voxel density?
> ...
> 
> for example, making voxels 1/2 the size would lead (very likely) to an 8x 
> memory-requirement increase, and 1/4 (250cm) could require 64x the memory.
> 
> a similarly sized world-space with a 1.5 inch (~ 3.75cm) voxel size would 
> require around 18963x as much memory.
> 
> 
> some people have tried "fundamentally different" ways of dealing with voxels 
> (namely "Sparse Voxel Octtrees" and ray-casting), but these in turn have 
> different tradeoffs (on current HW there are significant problems regarding 
> resolution and performance). I suspect it "may be a few years" before this 
> strategy really becomes practical.
> 
> a big issue though is that it probably still wont make creating of compelling 
> worlds all that much easier (so, probably a lot more random-generation and 
> similar, with its inherent pros and cons).
> 
> I guess it may ultimately be a bit of a "wait and see" thing.
> 
> 
> 
>> 
>> On 17/01/2012, at 2:31 PM, BGB wrote:
>> 
>>> On 1/16/2012 6:47 PM, Casey Ransberger wrote:
>>>> 
>>>> Top post. Heightmapping can go a really long way. Probably not news 
>>>> though:)
>>>> 
>>> 
>>> I am still not certain, since a lot of this has a lot more to do with my 
>>> own project than with general issues in computing.
>>> 
>>> 
>>> I had messed with a few technologies already.
>>> 
>>> height-maps (long ago, not much used since then, generally randomized).
>>> 
>>> the issue was mostly one of being "not terribly interesting", but it makes 
>>> sense if one wants terrain (and is "fairly cheap" in terms of memory use 
>>> and performance impact).
>>> 
>>> a more advanced variety would be to combine a height-map with a tile-map, 
>>> where the terrain generator would also vary the texture-map to give a 
>>> little more interest. I have considered this as a possibility.
>>> 
>>> also tried randomly generated voxel terrain (similar to Minecraft, using 
>>> perlin noise). issues were of being difficult to integrate well with my 
>>> existing technology, and being very expensive in terms of both rendering 
>>> and memory usage (particularly for storing intermediate meshes). one may 
>>> need to devote about 500MB-1GB of RAM to the problem to have a moderately 
>>> sized world with (with similar specifics to those in Minecraft).
>>> 
>>> I suspect that, apart from making something like Minecraft, the technology 
>>> is a bit too expensive and limited to really be all that "generally useful" 
>>> at this point in time and on current hardware (I suspect, however, it will 
>>> probably be much more relevant on future HW).
>>> 
>>> 
>>> I also tried randomly generated grid-based areas (basically, stuff is built 
>>> from pre-made parts and randomly-chosen parts are put on a grid). I had 
>>> also tried combining this with maze-generation algorithms. the results were 
>>> "functional" but also "nothing to get excited about". the big drawback was 
>>> that I couldn't really think of any way to make the results of such a grid 
>>> based generator "particularly interesting" (this is I think more so with a 
>>> first-person viewpoint: such a structure is far less visually interesting 
>>> from the inside than with a top-down or isometric view).
>>> 
>>> it could work if one were sufficiently desperate, but I doubt it would be 
>>> able to hold interest of players for all that long absent "something else 
>>> of redeeming value".
>>> 
>>> 
>>> the "main maps" in my case mostly use a Quake/Doom3/... style maps, 
>>> composed mostly of entities (defined in terms of collections of key/value 
>>> pairs 

Re: [fonc] Inspired 3D Worlds

[Julian Leviston]

I like minecraft's take on this.

Julian


On 17/01/2012, at 2:31 PM, BGB wrote:

> On 1/16/2012 6:47 PM, Casey Ransberger wrote:
>> 
>> Top post. Heightmapping can go a really long way. Probably not news though:)
>> 
> 
> I am still not certain, since a lot of this has a lot more to do with my own 
> project than with general issues in computing.
> 
> 
> I had messed with a few technologies already.
> 
> height-maps (long ago, not much used since then, generally randomized).
> 
> the issue was mostly one of being "not terribly interesting", but it makes 
> sense if one wants terrain (and is "fairly cheap" in terms of memory use and 
> performance impact).
> 
> a more advanced variety would be to combine a height-map with a tile-map, 
> where the terrain generator would also vary the texture-map to give a little 
> more interest. I have considered this as a possibility.
> 
> also tried randomly generated voxel terrain (similar to Minecraft, using 
> perlin noise). issues were of being difficult to integrate well with my 
> existing technology, and being very expensive in terms of both rendering and 
> memory usage (particularly for storing intermediate meshes). one may need to 
> devote about 500MB-1GB of RAM to the problem to have a moderately sized world 
> with (with similar specifics to those in Minecraft).
> 
> I suspect that, apart from making something like Minecraft, the technology is 
> a bit too expensive and limited to really be all that "generally useful" at 
> this point in time and on current hardware (I suspect, however, it will 
> probably be much more relevant on future HW).
> 
> 
> I also tried randomly generated grid-based areas (basically, stuff is built 
> from pre-made parts and randomly-chosen parts are put on a grid). I had also 
> tried combining this with maze-generation algorithms. the results were 
> "functional" but also "nothing to get excited about". the big drawback was 
> that I couldn't really think of any way to make the results of such a grid 
> based generator "particularly interesting" (this is I think more so with a 
> first-person viewpoint: such a structure is far less visually interesting 
> from the inside than with a top-down or isometric view).
> 
> it could work if one were sufficiently desperate, but I doubt it would be 
> able to hold interest of players for all that long absent "something else of 
> redeeming value".
> 
> 
> the "main maps" in my case mostly use a Quake/Doom3/... style maps, composed 
> mostly of entities (defined in terms of collections of key/value pairs 
> representing a given object), "brushes" (convex polyhedra), "patches" (Bezier 
> Surfaces), and "meshes" (mostly unstructured polygonal meshes).
> 
> these would generally be created manually, by placing every object and piece 
> of geometry visible in the world, but this is fairly effort-intensive, and 
> simply running head first into it tends to quickly drain my motivation 
> (resulting in me producing worlds which look like "big boxes with some random 
> crap in them").
> 
> sadly, random generation not on a grid of some sort is a much more complex 
> problem (nor random generation directly in terms of unstructured or 
> loosely-structured geometry).
> 
> fractals exist and work well on things like rocks or trees or terrain, but I 
> haven't found a good way to apply them to "general" map generation problem 
> (such as generating an interesting place to run around in and battle enemies, 
> and get to the exit).
> 
> the "problem domain" is potentially best suited to some sort of maze 
> algorithm, but in my own tests, this fairly quickly stopped being all that 
> interesting. the "upper end" I think for this sort of thing was likely the 
> .Hack series games (which had a lot of apparently randomly generated 
> dungeons).
> 
> 
> it is sad that I can't seem to pull off maps even half as interesting as 
> those (generally created by hand) in commercial games from well over a decade 
> ago. I can have a 3D engine which is technically much more advanced (or, at 
> least, runs considerably slower on much faster hardware with moderately more 
> features), but apart from reusing maps made by other people for other games, 
> I can't make it even a small amount nearly as "interesting" or "inspiring".
> 
> 
> 
>> On Jan 16, 2012, at 8:45 AM, David Barbour  wrote:
>> 
>>> Consider offloading some of your creativity burden onto your computer. The 
>>> idea is:
>>> 
>>>   It's easier to recognize and refine something interesting than to create 
>>> it.
>>> 
>>> So turn it into a search, recognition, and refinement problem, and automate 
>>> creation. There are various techniques, which certainly can be combined:
>>> 
>>> * constraint programming
>>> * generative grammar programming
>>> * genetic programming
>>> * seeded fractals
>>> 
>>> You might be surprised about how much of a world can be easily written with 
>>> code rather than mapping. A map can be simplified by marking regions up 
>>> wi

Re: [fonc] new document

[Julian Leviston]

Whether I use one or two thousand words to clothe my meaning is relevant?

I put just as much consideration into writing "+1" as I did in writing this 
email.

I could therefore also summarise your emails below as "-1" for the entire 
amount of meaning that it contains.

Allow me to expand on my "+1":

"I too agree that it would be lovely to be able to experience these events and 
presentations via a video."

Julian

On 09/11/2011, at 10:32 AM, David Barbour wrote:

> `+1`? Really? I seriously do not appreciate having my mail spammed in this 
> manner.
> 
> If you're offering an opinion on the article, try to say something specific 
> and relevant to those who might have skimmed it. Which parts interested you?
> 
> If you're referring to Sean's comment for recording the outreach events, 
> please consider moving it to another topic.
> 
> On Tue, Nov 8, 2011 at 3:17 PM, Julian Leviston  wrote:
> +1
> 
> On 09/11/2011, at 6:30 AM, Kevin Driedger wrote:
> 
>> +1 !!
>> 
>> ]{evin ])riedger
>> 
>> On Tue, Nov 8, 2011 at 1:05 PM, Joel Healy  wrote:
>> +1
>> 
>> Joel Healy
>> 
>> 
>> 
>> On Tue, Nov 8, 2011 at 10:49 AM, DeNigris Sean  wrote:
>> On Nov 7, 2011, at 6:08 PM, karl ramberg wrote:
>> > http://www.vpri.org/pdf/tr2011004_steps11.pdf
>> 
>> It's so exciting to watch the project come along. I can't wait to eventually 
>> play with it!
>> 
>> With every annual report, I think what a shame it is that there are so many 
>> talks given about it (~20 this year) and so few (~3) are recorded. Given the 
>> vital importance of this project, and all the work that must go into 
>> preparing the talks, it seems like a great waste to share this knowledge 
>> with only the few academics who happen to be at the various conferences. I 
>> attend about 6 conferences a year and still feel like I'm missing all the 
>> fun. Why doesn't VPRI just take the bull by the horns and record them even 
>> if the conferences don't? Consumer video equipment is so good now, it 
>> probably wouldn't cost anything but a few conversations - even an iPhone 
>> video could work!
>> 
>> Sean
>> ___
>> 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

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

Re: [fonc] new document

[Julian Leviston]

+1

On 09/11/2011, at 6:30 AM, Kevin Driedger wrote:

> +1 !!
> 
> ]{evin ])riedger
> 
> On Tue, Nov 8, 2011 at 1:05 PM, Joel Healy  wrote:
> +1
> 
> Joel Healy
> 
> 
> 
> On Tue, Nov 8, 2011 at 10:49 AM, DeNigris Sean  wrote:
> On Nov 7, 2011, at 6:08 PM, karl ramberg wrote:
> > http://www.vpri.org/pdf/tr2011004_steps11.pdf
> 
> It's so exciting to watch the project come along. I can't wait to eventually 
> play with it!
> 
> With every annual report, I think what a shame it is that there are so many 
> talks given about it (~20 this year) and so few (~3) are recorded. Given the 
> vital importance of this project, and all the work that must go into 
> preparing the talks, it seems like a great waste to share this knowledge with 
> only the few academics who happen to be at the various conferences. I attend 
> about 6 conferences a year and still feel like I'm missing all the fun. Why 
> doesn't VPRI just take the bull by the horns and record them even if the 
> conferences don't? Consumer video equipment is so good now, it probably 
> wouldn't cost anything but a few conversations - even an iPhone video could 
> work!
> 
> Sean
> ___
> 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] Language of Languages @ SPLASH 2011

[Julian Leviston]

Clicking the link

http://www.squeaksource.com/LoLs.html

Yields this:

Internal Server Error

Error: This block accepts 0 arguments, but was called with 1.

Comanche/6.2 (unix) Server at localhost Port 

On 18/10/2011, at 7:15 AM, Douglass, Jamie wrote:

> Thought you would be interested in the open source development we are 
> presenting next week at SPLASH 2011. (see note below)
>  
> ==Nicholas Chen writes
> Jamie Douglass, Ralph Johnson and I are working on an experimental language 
> workbench called Language of Languages (LoLs) that focuses on unifying 
> concepts
> (meta-models) across different notations. This affords the user greater 
> flexibility for editing the model in a variety of different notations while 
> maintaining consistency. We are building this language workbench on top of 
> Pharo Smalltalk[1] and we are using the Glamour engine[2] to build some of 
> the language browsers. We are using Jamie's CAT parser (continuation of the 
> work he did with Alessandro Warth and Todd Millstein [3]). 
> 
> If anyone is attending SPLASH[4] this year, we'd like to invite you to one of 
> our demo sessions. You can find a schedule of our demos 
> athttp://languageoflanguages.org/news. You can find more information about 
> LoLs from our website athttp://www.languageoflanguages.org.
>  
> Hope to see you at SPLASH '11!
>  
> --
> Nick
> University of Illinois at Urbana-Champaign
>  
> [1] http://www.pharo-project.org/home
> [2] http://www.moosetechnology.org/tools/glamour
> [3] Packrat Parsers Can Support Left Recursion 
> http://www.vpri.org/pdf/tr2007002_packrat.pdf
> [4] http://splashcon.org/2011/
>  
> 
>  
>  
>  
>  
> -Jamie
> James R. Douglass, CSDP & Associate Technical Fellow
> Office of ITI Chief Engineer 
> The Boeing Company 
> (360) 392-8782
> mobile: (425) 293-6254 
> jamie.dougl...@boeing.com 
> "If you don't know where you want to go, any road will do."
>  
> ___
> 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] Google "Dash" and Harmony projects

[Julian Leviston]

Amusing, they seem to be saying that the platform is the problem. ;-) Now where 
have we heard that before? :-) God, Alan's only been saying it for the last ten 
years or something...

Julian

On 14/09/2011, at 2:40 AM, Stephen Pair wrote:

> My guess would be that Dart is the newer, official name of Dart.  Very 
> interesting stuff.  Can't wait to hear what they announce publicly in a 
> couple months.
> 
> - Stephen
> 
> On Mon, Sep 12, 2011 at 4:03 PM, Steve Wart  wrote:
> Is "Dash" related to "Dart"?
> 
> http://www.pcmag.com/article2/0,2817,2392791,00.asp
> 
> On Mon, Sep 12, 2011 at 10:22 AM, John Zabroski  
> wrote:
> A leaked Google memo from November 2010 [1] is being circulated around the 
> Internet, outlining Google's supposed technical strategy for Web programming 
> languages.
> 
> Ironically, I saw this leak via a Google Alert keyword search.  It has 
> propagated to at least the Dzone social network since yesterday.
> 
> Given how we've discussed in the past what a browser could/should/would look 
> like if based on "fundamentals", it's interesting to see how groups in Google 
> approach the problem.  At least they can see a disease.
> 
> [1] http://pastebin.com/NUMTTrKj
> 
> 
> 
> ___
> 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] More information about the "text layout engine for paragraphs" in VPRI Tech Report

[Julian Leviston]

vpri.og is working for me.

Are you talking about Gezira/Nile?

http://www.vpri.org/vp_wiki/index.php/Gezira

Julian

On 01/09/2011, at 5:40 AM, nchen@mac.com wrote:

> Hi
> 
> I briefly remember Alan and other members of VPRI doing a presentation of the 
> text layout engine while they were here for a short visit to the University 
> of Illinois at Urbana-Champaign. I'm currently dealing with some layout work 
> in Morphic and would like to take a deeper look at the algorithm that they 
> have used. 
> 
> The VPRI.org website has been down since Monday and the only reference I 
> could find is a cached version of the STEPS Toward The Reinvention of 
> Programming,
> 2009 Progress Report Submitted to the National Science Foundation (NSF) 
> October 2009 through Google 
> 
> 
> Could anyone provide more pointers about the text layout engine? In 
> particular, is there an image with the implementation that I might be able to 
> take a deeper look at? Has there been any future work on it that I can read 
> more about?
> 
> Thanks!
> 
> --
> Nick
> 
> ___
> 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] OT: Quake-derived engines...

[Julian Leviston]

Hi,

On 24/08/2011, at 5:36 PM, BGB wrote:

> ok, yeah, this is a little awkward, as my way of seeing things I think tends 
> to be a little more "here and now", like the "pink plane" in the video linked 
> to with Alan talking about things (started trying to write a response about 
> this video before, but came to the opinion that my response was lame, so 
> didn't bother sending it, but it was still an interesting video).

The pink plane is a plane of understanding as far as I'm aware.  As in, pink 
thoughts are thoughts that are qualitatively different (ie in a different 
dimension) from the every day run of the mill "ordinary" blue plane thoughts. 
Perhaps I've misunderstood this idea. I don't specifically know what you're 
talking about, but pink plane vs blue plane - I'm fairly sure - is the same 
idea that I'm referencing (it is, after all, in the VPRI logo).

If you were talking about gaming engines that managed to allow you to build 
entirely new worlds in a fundamental way (ie platforms or worlds), this would 
indubitably be the domain of this work, IMHO.

The pink plane isn't really about here and now aside from the fact that the 
understanding has to occur here and now in order for the "future" to 
manifest... like a flash of understanding - it never comes out of some 
mechanistic or inevitably mechanical process. It usually comes from a combining 
of things from other domains to allow a flash-understanding that was not 
previously possible given the "meanderings" one had had before.

For example, the idea of simply building a cruft-free "everything in its place" 
base level operating system and object system using the "obvious" choice of 
mathematics as the base language... the idea of - rather than fight the 
programming language "wars" - embracing ALL languages as possible and valid 
(because it's more real), and continuing along that path - and seeing where it 
takes us... of experimenting with very powerful ideas... and finding out just 
what is possible... how far these ideas can take us... THIS is the domain of 
the FONC project, IMHO.

> so, one could instead deal with more conceptual/hypothetical matters like, 
> say, "what if I had a microchip in my hat that allowed be to watch youtube 
> videos while still looking like I was watching the teacher?..." well, maybe, 
> never-mind the ethical question of trying to look like one is paying 
> attention when really they are watching "teh ponies" or reading posts on 
> 4chan or similar, vs the more honest option of just pulling out a laptop and 
> headphones, or trying to pay attention.

Erm, no this is not "right", not as far as I'm aware. FUNDAMENTALS/FOUNDATIONS 
is an important idea here.

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

Re: [fonc] OT: Quake-derived engines...

[Julian Leviston]

Sorry for being potentially rude. It's fairly ironic that I would talk about 
this stuff given that I'm by no means authoritative for what is and isn't 
appropriate here.

It's my understanding, however, that "just anything" isn't an appropriate topic 
for conversation relating to what would be the fundamentals of new computing.

Game engines - unless they somehow exhibit some form of underutilized or 
little-understood abstracted understanding codified in a programming artifact 
that is pervasive in requirement but rare in actual implementation - are most 
likely going to simply be the general run of the mill computing, not something 
that is in some way foundational to what may be a new form of computation. 

This requirement of appropriateness can't readily be codified or rigidified 
unfortunately. Ironically if it could it most likely wouldn't be the precursor 
to the foundations of a new computing... because intelligence - in the form of 
involving not just the mind but incorporating the entire human being - 
multidisciplinary approaches and involving the emotions and bod as well  - is 
indubitably one of the requirements for this new computing. It needs to spring 
from deep understanding and not just a surface level attention. 

J

On 24/08/2011, at 3:37 PM, BGB  wrote:

> On 8/23/2011 9:54 PM, Julian Leviston wrote:
>> I usually just leave off commenting, but I personally don't think this is 
>> appropriate for this list.
> 
> fair enough, mostly just trying to find where the lines of appropriateness 
> are...
> sorry for any inconvenience.
> 
> 
> so, I guess what I have determined so far:
> programming languages are ok;
> hardware is sometimes ok (provided it does not run x86 or ARM, like 
> alternative HW only);
> physics and biology are ok;
> FOSS game engines are not ok (unless the topic is voxels or metaverse or 
> similar? like a few weeks ago);
> internet is maybe ok (browsers/... seem ok);
> ...
> 
> hmm...
> 
> well, maybe the pattern will be understood eventually?...
> 
> 
> maybe some sort of description of what is and is not ok would make sense, 
> like a description of the bounds of appropriateness or what constitutes a 
> valid topic or similar?...
> 
> 
>> Blog: http://random8.zenunit.com/
>> Twitter: http://twitter.com/random8r
>> Learn: http://sensei.zenunit.com/
>> New video up now at http://sensei.zenunit.com/
>> real fastcgi rails deploy process! Check it out now!
> 
> links: errm... these don't make sense, I am not sure I get the intention here.
> 
> the first 2 links seem to just contain assorted comments with little apparent 
> relation between them.
> 
> 
> 
>> 
>> On 24/08/2011, at 2:38 PM, BGB  wrote:
>> 
>>> sorry, I don't know if anyone here will find any of this interesting.
>>> 
>>> 
> 
> removed, as apparently it was not interesting.
> 
> 
> 
> ___
> 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] OT: Quake-derived engines...

[Julian Leviston]

I usually just leave off commenting, but I personally don't think this is 
appropriate for this list. 

Blog: http://random8.zenunit.com/
Twitter: http://twitter.com/random8r
Learn: http://sensei.zenunit.com/
New video up now at http://sensei.zenunit.com/ 
real fastcgi rails deploy process! Check it out now!


On 24/08/2011, at 2:38 PM, BGB  wrote:

> sorry, I don't know if anyone here will find any of this interesting.
> 
> 
> I just recently ran across a project (Xonotic) which shows something 
> interesting:
> Quake1 derived projects are apparently still ongoing, and managing to deliver 
> reasonably good looking games (sort of surprising, really, as I had thought 
> Quake1 had mostly petered out several years ago...).
> 
> 
> this points out something:
> the only "real" drawback of the Quake engine is mostly that it is GPL.
> say, if one uses it, they are either stuck making a GPL'ed game, or having to 
> license an engine such as Source or idTech4 or similar, and possibly remake a 
> lot of their content to fit the engine (since these engines are not really 
> either particularly backwards compatible or cross-implementation compatible).
> 
> I am almost left thinking that maybe something "sort of like the Quake 
> engine, but available under an MIT or BSD license" might be better, as then 
> one can use the same engine for both open-source and proprietary games.
> 
> but, one can argue:
> "but, hey, isn't the Linux kernel GPL, and people can use it for lots of 
> stuff?..."
> but, this is partly because of an oddity of how the GPL is interpreted 
> (mostly by Torvalds and friends), namely that in this case, the GPL only 
> applies to the kernel itself, but not to anything run on top of the kernel 
> (this is a special case mostly for things like VM's and OS's, where the GPL 
> doesn't apply from one to the other).
> 
> (also, a lot of what is done with the kernel in commercial settings involves 
> the use of loopholes, which I guess sort of puts the rage on RMS...).
> 
> the problem though is that it doesn't likely apply to games, since a game can 
> be considered a "single program" (because it is generally all code in the 
> same process and often directly linked), meaning that the GPL would apply 
> itself to the entire work (unless of course, all of ones' content were purely 
> data-files and scripts, where the VM special case could apply).
> 
> 
> well, my own project is sort of "Quake-like", but is not derived from the 
> engines' source.
> I am almost left wondering if I should just release the whole damn thing as 
> MIT as, otherwise, I am not likely to really make any money off this, and my 
> engine is still "less good" than many of the modern Quake-engine variants 
> around.
> 
> also, as has been mentioned before (on here, I think), my creative and 
> artistic skills are notably lame, which is a problem (this being a large 
> portion of a 3D game project).
> 
> 
> BTW: if anyone wonders what my BGBScript language was mostly intended for, 
> the above is part of it (sort of, me and "goals" is a bit uncertain, but 
> game-scripting was a major potential usage domain, as was scripting for 3D 
> tools and similar).
> 
> 
> but, yeah, it could all matter if, say, in the future game engines became 
> more like open platforms which people can build-on, rather than one-off 
> pieces of technology intended for delivering a particular game, and ideally 
> without the same level of vendor lock-in which has traditionally been the 
> case (or the need to license engines or pay royalties to deploy games or 
> stand-alone content for them...).
> 
> 
> or such...
> 
> 
> ___
> 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] Messages

[Julian Leviston]

On 21/08/2011, at 12:22 AM, John McKeon wrote:

> 
> 
> On Saturday, August 20, 2011, Alan Kay  wrote:
> > (For example)
> > Try to imagine a system where the parts only receive messages but never 
> > explicitly send them.
> > This is one example of what I meant when I requested that computer people 
> > pay more attention to what is in between the parts, than to the parts -- 
> > the Japanese have a great short word for it: "ma" -- we don't, and that's a 
> > clue that we have a hard time with "what is in between"
> > Cheers,
> > Alan
> >
> 
> I like: the ether (it has a more Maxwellian flavor for me :)
> Then try to imagine an object not in it 
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc

I find Alan's email slightly obscure - I thought I understood what it meant... 
but then John, yours is so abstracted away from anything I know to be in 
reality, that I find I don't really understand Alan's email either. In concrete 
terms, what are you talking about? Could you explain it simply?

What I thought Alan was talking about was just the reification of message 
sending... but I think I'm totally lost now.

Sorry!

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

Re: [fonc] OOP

[Julian Leviston]

On 20/08/2011, at 4:05 AM, DeNigris Sean wrote:

>> "assignments are a metalevel change from functions, and therefore should not 
>> be dealt with at the same level"
> What makes them so?
> Even though I encapsulate my domain concepts, inside my objects I write (and 
> see everywhere in Smalltalk) code which seems to violate what you're saying. 
> Like if I was modelling a web page, maybe I'd have an instance creation 
> method Webpage class>>at: aUrl; then during initialization:
>   Webpage>>setUrl: aUrl
>   contents := aUrl retrieveContents contents.
>   ...
> So here again is assignment mixed with functions (or do you really mean 
> "functions" and not messages as here?). But what is the alternative? A 
> WebpageContents class? What would the benefit be?
> 


Perhaps he means function (ie method) definition, as averse to function calling.

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

Re: [fonc] growing a language in pattern calculus

[Julian Leviston]

Hey UTS! That's just up the road from me :)

Haha woo :)

J


On 21/07/2011, at 7:34 PM, Barry Jay wrote:

> Hi everyone,
> 
> the paper "Growing a language in pattern calculus" is now available from
> 
> http://www-staff.it.uts.edu.au/~cbj/Publications/glpmf.pdf
> 
> The material of the paper links to many of the concerns of this list.  It 
> shows how to add features to an existing language in a convenient and 
> principled fashion.  Each (new) feature is isolated within its own 
> object-oriented class that describes all phases of its implementation. The 
> unifying principle is that all computation is pattern matching, an idea which 
> is quite familiar to readers of this list, but pushed to the limits within 
> pattern calculus. Comparisons are made with OMeta, Fortress and severl other 
> approaches to language growth.
> 
> As relative newcomers to this world, we will appreciate any feedback.
> 
> Yours,
> Barry Jay
> Jose Vergara
> 
> ___
> 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: Growth, Popularity and Languages - was Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 3:47 PM, Alan Kay wrote:

> But the dilemma is: what happens if this is the route and the children and 
> adults reject it for the much more alluring human universals? Even if almost 
> none of them lead to a stable, thriving, growth inducing and prosperous 
> civilization?
> 
> These are the issues I care about.


You seem to be seeing these two as orthogonal. I see them as mutually 
complementing. (ie we drive people to what they need through what they want... )

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

Re: Growth, Popularity and Languages - was Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 12:20 PM, Igor Stasenko wrote:

>> 
>> Say, for example, like making a telephone that is vastly more easy to use 
>> than all other telephones on the planet. Now, for tech geeks, it's not 
>> really *that* much easier to use... For example, when the iPhone came out, I 
>> got one, and the only really useful and different thing in terms of 
>> technical specification and features that I could do that I previously 
>> couldn't do easily was synchronise my contacts... but everything was quite a 
>> bit EASIER to do. In the process, Apple are pushing next gen technologies 
>> (next gen for the public is not necessarily next gen for us, mind :)). Mind 
>> you, it comes wrapped around their bank account, but it's still coming.
>> 
>> Look at Twitter for an example of what people like... this is a ridiculously 
>> clear example... it simply allows people to write small messages to whoever 
>> is listening. Brilliantly simple, brilliantly clear. Most people want to do 
>> this, and so it is popular.  The thing with twitter is, though, they're not 
>> using this popularity at all. They don't really know what to do with it.
>> 
>> Now, what we want to do is make something compelling enough such that it 
>> "goes off like a rocket". Smalltalk was designed pretty amazingly well, and 
>> it had an amazingly large amount of influence, but if you ask most 
>> programmers what smalltalk is, they usually haven't heard of it... contrast 
>> this to asking people about Java, and they know what that is. :) You even 
>> ask them what Object Oriented programming is, and they know that, but you 
>> say "Heard of Alan Kay?" and they give you a blank look. Ask them about 
>> Steve Jobs and everyone knows all about him. Hell, what other company has 
>> fanboys keeping track of their ADS? 
>> (http://www.macrumors.com/2011/07/24/new-apple-ipad-ad-well-always/ )
>> 
>> What I'm trying to get at here, is that I see no reason why something free 
>> can't be popular (facebook? twitter?), but for that to take place, it has to 
>> provide something that you simply can't get elsewhere. The advantage the web 
>> has had is that it has moved quite quickly and continues to move at whatever 
>> pace we like to go at. Nothing else has come along that has outpaced or out 
>> innovated it FROM THE POINT OF VIEW OF THE AVERAGE PUNTER. So what is needed 
>> is something along the lines of Frank, which when people see what is 
>> possible (BY USING IT ONLY, I'd wager), they'll stop using everything else 
>> because they simply can't go back to "the old way" because it feels like the 
>> past too much. :)
>> 
>> Make something better than all the user or developer experiences out there, 
>> and developers like me will evangelise the shit out of it... and other users 
>> who care about things will jump on the bandwagon, curators of experience 
>> will jump on board, and overnight, a Windows 95 like experience will happen 
>> (in terms of market share effect), or perhaps an iPod effect will happen. 
>> Remember, it has to be "just better" than what is possible now, so if you 
>> make something "infinitely better" but just show off how it's "just better", 
>> and also make it easy to migrate to and easier to use, then you will have 
>> already "won" as the new way of doing things before you've started.
>> 
>> Even Apple, our current purveyors of "fine user experience" and curators of 
>> style and design, haven't managed to build a device or user experience in 
>> software that allows primarily convention, ease of use and unclutteredness, 
>> and yet then the total ability to configure things for people who want 
>> things to do exactly what they want them to do (ie coders, programmers, and 
>> advanced users). They hit the "80/20" rule quite well in terms of giving 80 
>> percent of people everything they need, while leaving 20% of people sort of 
>> out in the cold.
>> 
> 
> I don't think its a good to drive an analogy between end product and tool(s).
> The main difference between them lies in the fact that tools are made
> for professionals, while end products are made for everyone.
> You don't have to graduate college to know how to use microwave, you
> just need to read a short instruction.
> Professionals who basing their choice on popularity are bad
> professionals, the good ones basing their choice on quality of tools.
> Because everyone knows that popularity has a temporary effect.
> Something which is popular today, will be forgotten tomorrow.

That's just silly. Products vs Tools? A toaster is a device that I can use to 
toast bread. A coffee machine is a device i can use to make coffee. 
Professional people who create coffee or create toasted sandwiches for a living 
use different ones, but they're still coffee machines and toasters, and mostly 
they're just based around higher volume, and higher quality in terms of 
controls.

Popularity doesn't always have a temporary effect. Consider the iPod. It's not 
forgotten is it?

Re: Growth, Popularity and Languages - was Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 12:20 PM, Igor Stasenko wrote:

> But for programming its a bit different: you giving to people a tool
> which they will use to craft their own products. And depending on how
> good/bad this tool are, the end product's quality will vary.
> 
> And also, it would be too good to be true: if people would have to
> choose between java and smalltalk based on "easy to use" criteria, i
> doub't they would choose java.
> Marketing takes its toll, the worse one. :)

But they *did* choose Java over smalltalk precisely because it's easier to use.

You make the mistake of assuming easier to use between experts, but that's not 
how people adopt languages.

One of the reasons Rails became an overnight success for the Ruby and web 
development communities is because of a 15 minute blog screencast... and a 
bunch of simple evangelizing the creator of Rails did... he basically showed 
how easy it was to create a Blog in 15 minutes with comments... Mind you it 
wasn't a particularly beautiful Blog, but it functioned, nonetheless, and the 
kicker is...

... it was about twice as easy, twice as fast, and twice as nice to code than 
in any other comparative programming environment at the time.

People adoped Java because it was readily available to learn, and easy to 
"grok" in comparison with what they knew, and because it had "spunk" in the 
same way that Rails did -  it had an attitude, and was perceived as a funky 
thing. This has to do with marketing and the way our society works. SmallTalk, 
is incredibly simple, incredibly powerful, but also INCREDIBLY unapproachable 
for most people not welcoming to abstract thought.

Contrast that it took me weeks to understand SmallTalk when I first saw it - 
even vaguely understand I mean - but it only took me days to understand Java, 
given that I'd programmed in Basic and C before.

This has to do with the sub-cultural context more than anything. 

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

Re: Growth, Popularity and Languages - was Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 12:20 PM, Igor Stasenko wrote:

> You lost me here. My attitude to Ruby is same as to Perl: lets take
> bit from here, bit from there, mix well everything and voila! , we
> having new programming language.
> It may be good for cooking recipe, but definitely not very good for
> programming language.
> I find it strange that many today's mainstream languages evolution is
> driven by taking same approach: mix & blend things together, rather
> than focusing on completeness, conciseness and clarity.

I don't think you understand Ruby very well. PERL and Ruby are quite different.
Sure, Ruby borrowed some stuff from PERL (such as built in RegExps, etc) but at 
its heart, it's pure objects, and behaves very much how you'd expect it to. 
It's also incredibly compact and beautiful looking, easy to read, and nice. I 
fell in love with it similarly to how I fell in love with SmallTalk...

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

Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 5:59 AM, David Barbour wrote:

> Do you remember those battles between behemoths trying to place proprietary 
> technologies in our browsers? I do. 'Embrace and extend' was a strategy 
> discussed and understood even in grade school. I'm a bit curious whether 
> Google will be facing an EOLAS patent suit for NaCl, or whether that 
> privilege will go to whomever uses NaCl and WebSockets to connect browsers 
> together.
> 


Yeah, I think the truly smart man releases something crappy FIRST before anyone 
else gets out of the gate, but has a plan to improve it, so the "crappy" thing 
actually is very smart because it doesn't "hem in" the future. (ie the design 
decisions made in it allow the step by step shifting to wherever the vision is 
directed). So long as there's a vision... And by crappy, really I mean basic as 
in... doesn't do much... or put another way "does just enough" to get the job 
done.

"Release early, release often".

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

Intention & Implementation - was Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 1:43 AM, Igor Stasenko wrote:

> (quotes are broken)
> 
> On 25 July 2011 16:26, Julian Leviston  wrote:
>> 
>> On 26/07/2011, at 12:03 AM, Igor Stasenko wrote:
>> 
>> In contrast, as you mentioned, TCP/IP protocol which is backbone of
>> today's internet having much better design.
>> But i think this is a general problem of software evolution. No matter
>> how hard you try, you cannot foresee all kinds of interactions,
>> features and use cases for your system, when you designing it from the
>> beginning.
>> Because 20 years ago, systems has completely different requirements,
>> comparing to today's ones. So, what was good enough 20 years ago,
>> today is not very good.
>> 
>> That makes no sense to me at all. How were the requirements radically
>> different?
>> I still use my computer to play games, communicate with friends and family,
>> solve problems, author text, make music and write programs. That's what I
>> did with my computer twenty years ago. My requirements are the same. Of
>> course, the sophistication and capacity of the programs has grown
>> considerably... so has the hardware... but the actual requirements haven't
>> changed much at all.
>> 
> 
> If capacity of programs has grown, then there was a reason for it
> (read requirements)?
> Because if you stating that you having same requirements as 20 years
> ago, then why you don't using those old systems,
> but instead using today's ones?
> 

Well, Igor, if something more efficient comes along, I will use it, and it will 
*probably* work just fine on 20 year old hardware... because *my* requirements 
haven't changed much. I will grant you that it's probably going to be quite 
hard to get a commodore 64 connected to a router, because its not very 
compatible, but what I'm trying to say here is that most of the "requirements" 
you're talking about are actually self-imposed by our computing system. Having 
something that can do 2.5 million instructions per second is ludicrous if all I 
want to do is type my document, isn't it? Surely any machine should be able to 
handle typing a document. ;-) (Note here, I'm obviously ignoring the fact that 
nowadays, we have unicode).

What I'm getting at is *MY* requirements haven't changed much. I still want to 
send a communication to my mother every now and then, and I still want to play 
games. In fact, some of my favourite games, I actually use emulators to play... 
emulators that run 20 year old hardware emulation so I can play the games which 
will not run on today's machines ;-)

One of my favourite games is Tetris Attack, which me and my friend play on his 
XBOX (original, not 360) in a Super Nintendo Emulator...

Do you find that amusing? I sure as hell do. :)

But I digress - my intentions are relatively similar that they were 20 years 
ago... I like to write programs, and I like to use programs to draw, and I like 
to listen to music, solve problems, create texts, make music... etc. The 
IMPLEMENTATIONS of how I went about this are vastly different, and so if you 
like you can bend "requirements" to a systems-view of requirements... and then 
I will agree with you... my requirements that I have today of my computer in 
terms of TECHNICAL requirements are vastly different, but in terms of 
interpersonal requirements, they're not at all different - maybe slightly...

Making music satisfies a creative impulse in me, and I can make it using my 
$10,000 computer system that I have today, or I can satisfy it using a 
synthesizer from the 80's. One of them does a vastly better job for me, but 
this is a qualitative issue, not a requirements issue ;-)

> Speaking of requirements,  a tooday's browser (Firefox) running on my
> machine takes more than 500Mb of system memory.
> I have no idea, why it consuming that much.. the fact is that you
> cannot run it on any 20-years old personal computer.
> 
> 

Well this is the point of the STEPS project and the like - get rid of the 
cruft, and we will have an optimized system that will run like lightning on our 
current day processors with all their amazing amount of memory. 

>> And here the problem: is hard to radically change the software,
>> especially core concepts, because everyone using it, get used to it ,
>> because it made standard.
>> So you have to maintain compatibility and invent workarounds , patches
>> and fixes on top of existing things, rather than radically change the
>> landscape.
>> 
>> I disagree with this entirely. Apple manage to change software radically...
>> by tying it with hardware upgrades (speed/capacity in hardware) and other
>> things people want (new features, e

Growth, Popularity and Languages - was Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 1:33 AM, Igor Stasenko wrote:

> On 25 July 2011 16:16, Julian Leviston  wrote:
>> 
>> On 26/07/2011, at 12:03 AM, Igor Stasenko wrote:
>> 
>> Interestingly that many today's trendy and popular things (which we
>> know today as web) were invented as a temporary solution without any
>> systematic approach.
>> I think that i will be right by saying that most of these technologies
>> (like PHP, Javascript, Ruby, Sendmail etc) is a result of random
>> choice instead making planning and a deep study of problem field
>> before doing anything.
>> And that's why no surprise, they are failing to grow.
>> And now, people trying to fill the gaps in those technologies with
>> security, scalability and so on.. Because they are now well
>> established standards.. while originally was not meant to be used in
>> such form from the beginning.
>> 
>> 
>> Wow... really? PHP, JavaScript, Ruby and Sendmail are the result of random
>> choice?
> 
> Random. Because how something , which was done to satisfy minute needs
> (i wanna script some interactions, so lets do it quick),
> could grow into something mature without solid foundation?
> If conceptual flaw is there from the very beginning, how you can "fix" it?
> 
> Here what author says about JS:
> 
> JS had to “look like Java” only less so, be Java’s dumb kid brother or
> boy-hostage sidekick. Plus, I had to be done in ten days or something
> worse than JS would have happened
> Brendan Eich
> 

Except that JavaScript is one of the only common popular prototype based object 
oriented languages, which it turns out is an amazingly flexible system. I don't 
think this is random. Maybe rushed is what you mean here.

Apart from this, Ruby was DEFINITELY not random, or rushed. It's a delicate 
balance between form and pragmatic functionality. I'll grant you that the 
internals of the standard interpreter leave a lot to be desired, but I think 
this is perhaps less to do with randomness and more to do with the fact that 
perhaps Matz was entirely out of his depth when it came to "best of breed" for 
internal language structuring.

I think to say that these languages served as a temporary solution is not 
really very fair on most of them. PHP was basically designed to be an easy way 
to build dynamic web pages, and popularity drove it to where it is today.

I guess where you're coming from is you're attempting to say that none of these 
languages are being used for what they were originally designed for... possibly 
(I'd put my weight on saying hopefully) with the exception of Ruby, because 
Ruby was designed to be beautiful to code in, and to make programmers happy. 
Ruby is a general purpose language. I really don't know why you include 
Sendmail in this bunch.

I think you're kind of missing the point of the web not being structured 
properly, though... I think Alan's point is more the case that the fact that we 
had to use server side languages, as well as languages such as VBScript and 
JavaScript which the interpreter executes, is an illustration of the fact that 
STRUCTURALLY, the web is fairly broken. It has nothing to do with language 
choice (server- or client-side), really, but rather the fact that there is no 
set of conventions and readily usable standard for programming across the web 
in such a way that code is run in a protected way on machines where code needs 
to run.

I think as computer programmers, we get quite hung up on the specifics of 
languages and other potentially somewhat irrelevant details when perhaps 
they're not the most apposite concerns to be interested in.


> Apparently a missing systematical approach then strikes back, once it
> deployed, became popular and used by millions..
> 
> 
>> Javascript, PHP, Ruby and Sendmail failing to grow? Seriously? What do you
>> mean by grow? It can't surely be popularity...
> 
> Grow not in popularity of course.
> Grow in serving our needs.

Perhaps you miss the point of why things become large and popular...? :) 
They're driven by people. And not just some people - by *most* people. 
Everybody wants to share photos and search for things on the web. Everyone 
wants their content, and purchases, and the things they want.

These people do not care about structural perfection in any way. They care 
about doing the things they want to do and naught else.

Look at Apple if you want to understand a group of people who "get" this (or 
maybe only Steve gets this, I don't really know, but I do know someone at Apple 
fully understand this, and possibly Apple *didn't* understand this when Steve 
wasn't there). The only way you can drive the future is if you get everyone to 
come along with you.

The only wa

Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 12:03 AM, Igor Stasenko wrote:

> In contrast, as you mentioned, TCP/IP protocol which is backbone of
> today's internet having much better design.
> But i think this is a general problem of software evolution. No matter
> how hard you try, you cannot foresee all kinds of interactions,
> features and use cases for your system, when you designing it from the
> beginning.
> Because 20 years ago, systems has completely different requirements,
> comparing to today's ones. So, what was good enough 20 years ago,
> today is not very good.

That makes no sense to me at all. How were the requirements radically different?

I still use my computer to play games, communicate with friends and family, 
solve problems, author text, make music and write programs. That's what I did 
with my computer twenty years ago. My requirements are the same. Of course, the 
sophistication and capacity of the programs has grown considerably... so has 
the hardware... but the actual requirements haven't changed much at all.

> And here the problem: is hard to radically change the software,
> especially core concepts, because everyone using it, get used to it ,
> because it made standard.
> So you have to maintain compatibility and invent workarounds , patches
> and fixes on top of existing things, rather than radically change the
> landscape.

I disagree with this entirely. Apple manage to change software radically... by 
tying it with hardware upgrades (speed/capacity in hardware) and other things 
people want (new features, ease of use). Connect something people want  with 
shifts in software architecture, or make the shift painless and give some kind 
of advantage and people will upgrade, so long as the upgrade doesn't somehow 
detract from the original, that is. Of course, if you don't align something 
people want with software, people won't generally upgrade.


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

Re: [fonc] Alan Kay talk at HPI in Potsdam

[Julian Leviston]

On 26/07/2011, at 12:03 AM, Igor Stasenko wrote:

> Interestingly that many today's trendy and popular things (which we
> know today as web) were invented as a temporary solution without any
> systematic approach.
> I think that i will be right by saying that most of these technologies
> (like PHP, Javascript, Ruby, Sendmail etc) is a result of random
> choice instead making planning and a deep study of problem field
> before doing anything.
> And that's why no surprise, they are failing to grow.
> And now, people trying to fill the gaps in those technologies with
> security, scalability and so on.. Because they are now well
> established standards.. while originally was not meant to be used in
> such form from the beginning.


Wow... really? PHP, JavaScript, Ruby and Sendmail are the result of random 
choice?

Javascript, PHP, Ruby and Sendmail failing to grow? Seriously? What do you mean 
by grow? It can't surely be popularity...

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

Re: [fonc] Richard Gabriel & Guy Steele, "50 in 50" talk

[Julian Leviston]

On 24/06/2011, at 11:42 PM, Bert Freudenberg wrote:

> They gave that presentation more than once (I saw it a OOPSLA). Awesome :)
> 
> Here's a version from JAOO'08, streams fine in Germany:
> 
>   http://blog.jaoo.dk/2008/11/21/art-and-code-obscure-or-beautiful-code/
> 
> - Bert -

I actually thought the presentation was terrible, not very accessible and 
incredibly cliquey... it was so referential that you had to almost have lived 
through the things they were talking about to "get" whatever it was they were 
talking about - sort of self-defeating if they were aiming at instruction, 
which their last few words would indicate.___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Richard Gabriel & Guy Steele, "50 in 50" talk

[Julian Leviston]

On 24/06/2011, at 4:14 PM, Hans-Martin Mosner wrote:

> Am 22.06.2011 23:45, schrieb Steve Dekorte:
>> http://www.youtube.com/watch?v=Nii1n8PYLrc
>> 
>> Thoughts?
> Sadly, this can't be watched in Germany (unless you employ TOR or some other 
> mechanism to conceal your IP address).
> The german rights management organisation (GEMA) apparently didn't grant a 
> license for some piece of background music.
> What a bunch of f*ing morons. Looks like I'll have to learn how to use TOR.
> 
> Cheers,
> Hans-Martin
> 

I noticed that when I opened it in safari, and right-clicked the video, the src 
attribute had the following text in it, which I'm fairly sure one could 
download if one popped it straight into one's browser or curl'd the URL or some 
such...

http://v10.lscache3.c.youtube.com/videoplayback?sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Cratebypass%2Coc%3AU0hPTVlNTl9FSkNOOV9RR1JF&fexp=908606%2C906719%2C904102&itag=22&ip=0.0.0.0&signature=388209DC84BA8D8A49C16D20A443D66814F20973.1721282EFB80A8A988AC1057CC9606168505F921&sver=3&ratebypass=yes&expire=1308920400&key=yt1&ipbits=0&id=3628b59fc3d82eb7




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

Re: Age and Language (was Re: [fonc] Alternative Web programming models?)

[Julian Leviston]

On 23/06/2011, at 12:35 PM, Max OrHai wrote:

> People who want a "small" language should be prepared to be somewhat 
> idiosyncratic, if they want to express "big" or complex programs. I mean 
> 'language' here not just in terms of a programming language definition but 
> rather to mean all constructs (or, more fundamentally, concepts and 
> conventions) which are shared, which belong in some sense to a culture rather 
> than an individual. If they don't enlarge the language (usually via some 
> library) they enlarge their personal idiom instead, which may not be as 
> "portable". Progress depends on the ability of individuals to nonetheless 
> communicate these new ideas 'uphill' so to speak, but more immediately on the 
> ability to make them, so as to make them better. Some leverage here may be 
> available through improvements in the notion of expressivity itself. There is 
> a wonderfully large number of experiments being done in dynamic language 
> design these days, from Ruby to REBOL... If more of them would take what I'd 
> say is the major lesson of Smalltalk and become fully integrated personal 
> computing environments, rather than living off the previous generation's 
> operating systems, perhaps they might be able to move some of the 
> uncomfortable fixed points of usability and complexity, as well as gain more 
> user-programmers altogether. I think FONC is, at least, a pointer in the 
> right direction; a reminder that there's plenty of room out there beyond the 
> familiar.
> 

So, by that reasoning, GNU SmallTalk doesn't exhibit what you'd express as 
being the "major lesson from SmallTalk"?

Interestingly, one of the most irritating things for me was the User Interface 
when I first came to Squeak, having programmed in GemStone SmallTalk for a 
number of years (which we were programming via snippets plugged into HTML, and 
sometimes via GemStone/J, on a mac natively, not inside a SmallTalk environment 
at all).

At that point I had experience in AmigaDOS, MacOS (pre X), Windows 95, NT and 
GEOS (commodore 64 based GUI) would you believe...  Squeak was supremely 
irritating for two reasons: Firstly, the UI was completely different without 
having any easy way to say "hey, I'm a n00b, turn on n00b mode so I can learn 
this thing", and second it seemed far too easy to make irreparable damage, or 
even lose what I was doing... (probably due to point 1).

So I'd be very much against your "build the whole world so you can express the 
language" philosophy. Potentially, though, I'd say having the idea of a 
SmallTalk-like image loaded into a fully graphical interface AS AN OPTION is 
awesome... I'd love to have a visual debugger for my Ruby code the likes of the 
SmallTalk ones... (to a degree, MagLev kind of allows this as a possibility).

My issue seems to be that if you change the language at a base level while in 
one of those environments, you kind of break everything... don't you? They 
don't really lead to experimentation very well.

Julian.


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