Re: [fonc] Really nice presentation of the VPRI project
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 yoshiki.ohsh...@acm.orgwrote: 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
Re: [fonc] Final STEP progress report abandoned?
With Forth, you are probably reaching for the definition of a concatenative language like Joy. APL, J, K, etc. would also qualify. On Tue, Sep 3, 2013 at 4:43 PM, Casey Ransberger casey.obrie...@gmail.comwrote: I've heavily abridged your message David; sorry if I've dropped important context. My words below... On Sep 3, 2013, at 3:04 PM, David Barbour dmbarb...@gmail.com wrote: Even better if the languages are good for exploration by genetic programming - i.e. easily sliced, spliced, rearranged, mutated. I've only seen this done with two languages. Certainly it's possible in any language with the right semantic chops but so far it seems like we're looking at Lisp (et al) and FORTH. My observation has been that the main quality that yields (ease of recombination? I don't even know what it is for sure) is syntaxlessness. I'd love to know about other languages and qualities of languages that are conducive to this sort of thing, especially if anyone has seen interesting work done with one of the logic languages. ___ 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
Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell)
I'm sure that if you took a pretty clean PEG grammar approach to composable
mixfix phrasing and cues from Inform 7 and Ruby's Cucumber DSL,
Smalltalk-71 would feel as real as any bytecode-native language.
On Wed, Mar 14, 2012 at 11:38 AM, shaun gilchrist shaunxc...@gmail.comwrote:
Alan,
I would go way back to the never implemented Smalltalk-71
Is there a formal specification of what 71 should have been? I have only
ever read about it in passing reference in the various histories of
smalltalk as a step on the way to 72, 76, and finally 80.
I am very intrigued as to what sets 71 apart so dramatically. -Shaun
On Wed, Mar 14, 2012 at 12:29 PM, Alan Kay alan.n...@yahoo.com wrote:
Hi Scott --
1. I will see if I can get one of these scanned for you. Moore tended to
publish in journals and there is very little of his stuff available on line.
2.a. if (ab) { ... } is easier to read than if ab then ...? There
is no hint of the former being tweaked for decades to make it easier to
read.
Several experiments from the past cast doubt on the rest of the idea. At
Disney we did a variety of code display generators to see what kinds of
transformations we could do to the underlying Smalltalk (including
syntactic) to make it something that could be subsetted as a growable path
from Etoys.
We got some good results from this (and this is what I'd do with
Javascript in both directions -- Alex Warth's OMeta is in Javascript and is
quite complete and could do this).
However, the showstopper was all the parentheses that had to be rendered
in tiles. Mike Travers at MIT had done one of the first tile based editors
for a version of Lisp that he used, and this was even worse.
More recently, Jens Moenig (who did SNAP) also did a direct renderer and
editor for Squeak Smalltalk (this can be tried out) and it really seemed to
be much too cluttered.
One argument for some of this, is well, teach the kids a subset that
doesn't use so many parens This could be a solution.
However, in the end, I don't think Javascript semantics is particularly
good for kids. For example, one of features of Etoys that turned out to be
very powerful for children and other Etoy programmers is the easy/trivial
parallel methods execution. And there are others in Etoys and yet others in
Scractch that are non-standard in regular programming languages but are
very powerful for children (and some of them are better than standard CS
language ideas).
I'm encouraging you to do something better (that would be ideal). Or at
least as workable. Giving kids less just because that's what an existing
language for adults has is not a good tactic.
2.c. Ditto 2.a. above
2.d. Ditto above above
Cheers,
Alan
--
*From:* C. Scott Ananian csc...@laptop.org
*To:* Alan Kay alan.n...@yahoo.com
*Cc:* IAEP SugarLabs i...@lists.sugarlabs.org; Fundamentals of New
Computing fonc@vpri.org; Viewpoints Research a...@vpri.org
*Sent:* Wednesday, March 14, 2012 10:25 AM
*Subject:* Re: [IAEP] [fonc] Barbarians at the gate! (Project Nell)
On Wed, Mar 14, 2012 at 12:54 PM, Alan Kay alan.n...@yahoo.com wrote:
The many papers from this work greatly influenced the thinking about
personal computing at Xerox PARC in the 70s. Here are a couple:
-- O. K. Moore, Autotelic Responsive Environments and Exceptional
Children, Experience, Structure and Adaptabilty (ed. Harvey), Springer, 1966
-- Anderson and Moore, Autotelic Folk Models, Sociological Quarterly, 1959
Thank you for these references. I will chase them down and learn as much
as I can.
2. Separating out some of the programming ideas here:
a. Simplest one is that the most important users of this system are the
children, so it would be a better idea to make the tile scripting look as
easy for them as possible. I don't agree with the rationalization in the
paper about preserving the code reading skills of existing programmers.
I probably need to clarify the reasoning in the paper for this point.
Traditional text-based programming languages have been tweaked over
decades to be easy to read -- for both small examples and large systems.
It's somewhat of a heresy, but I thought it would be interesting to
explore a tile-based system that *didn't* throw away the traditional text
structure, and tried simply to make the structure of the traditional text
easier to visualize and manipulate.
So it's not really skills of existing programmers I'm interested in --
I should reword that. It's that I feel we have an existence proof that the
traditional textual form of a program is easy to read, even for very
complicated programs. So I'm trying to scale down the thing that works,
instead of trying to invent something new which proves unwieldy at scale.
b. Good idea to go all the way to the bottom with the children's language.
c. Figure 2 introduces another -- at least equally important language --
in my opinion, this one
Re: [fonc] goals
Or multi-methods / multiple dispatch? On Sat, Jul 10, 2010 at 3:22 AM, Steve Dekorte st...@dekorte.com wrote: It seems as if each computing culture fails to establish a measure for it's own goals which leaves it with no means of critically analyzing it's assumptions resulting in the technical equivalent of religious dogma. From this perspective, new technical cultures are more like religious reform movements than new scientific theories which are measured by agreement with experiment. e.g. had the Smalltalk community said if it can reduce the overall code X without a performance cost Y it's better, perhaps prototypes would have been adopted long ago. -- -Brian T. Rice ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] New anti aliasing techniques for 2d rendering
What looks very good? The only description cited on his website is Sampling theory and unsubstantiated claims. This other page lists some claims but it's hard to tell what is meant in the case of images: http://www.jvuletich.org/research.html On Wed, Jun 2, 2010 at 9:31 AM, dphar...@telus.net wrote: This looks very good. IS processing time reasonable for these techniques? David On Jun 2, 2010, *Juan Vuletich* j...@jvuletich.org wrote: Hi Folks, I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org , especially at the samples. I believe this work fits nicely in the FONC project, as a Nile implementation of it would yield better quality results than Gezira. Comments welcome. Cheers, Juan Vuletich ___ 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
Re: [fonc] New anti aliasing techniques for 2d rendering
Great! Thanks for clarifying that. On Wed, Jun 2, 2010 at 9:59 AM, Andreas Raab andreas.r...@gmx.de wrote: On 6/2/2010 9:38 AM, Brian Rice wrote: What looks very good? The only description cited on his website is Sampling theory and unsubstantiated claims. This is the page: http://www.jvuletich.org/Morphic3/Morphic3-201006.html It's pretty neat. Cheers, - Andreas This other page lists some claims but it's hard to tell what is meant in the case of images: http://www.jvuletich.org/research.html On Wed, Jun 2, 2010 at 9:31 AM, dphar...@telus.net mailto:dphar...@telus.net wrote: This looks very good. IS processing time reasonable for these techniques? David On Jun 2, 2010, *Juan Vuletich* j...@jvuletich.org mailto:j...@jvuletich.org wrote: Hi Folks, I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org http://www.jvuletich.org , especially at the samples. I believe this work fits nicely in the FONC project, as a Nile implementation of it would yield better quality results than Gezira. Comments welcome. Cheers, Juan Vuletich ___ 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 -- -Brian T. Rice ___ 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
