Re: [fonc] Unsolved problem in computer science? Fixing shortcuts.
Context below, sorry about the top-post (stupid "smartphone.") I think I remember that in Xanadu, links are two-way streets. When you "move" the link, I can only assume that both of those pointing devices would need to be updated. I'm not sure how it works though. Is there a central authority involved, can it be distributed, etc? It's hard to visualize a two-way link because I have spent my entire life living in flatland. I even mix up which plane is blue and which is pink sometimes:) The gist I got was that the two-way link concept was a powerful idea which could be applied to more problems than just "pages" (the mere use of the term is liable to give Ted a headache. Flat paper metaphors and such.) I wouldn't be shocked if a good implementation couldn't be done using a "vigilant" doubly-linked list (i.e. an object which cares about provenance and has a means of vetting it, like perhaps a touch of public key encryption.) Think of all the talk on this list about publish/subscribe as an object model, pattern directed invocation and such, and then try to imagine all of the ways a two-way link or "shortcut" might outclass the usual (and fragile-as-glass) one-way link. BCC Ted Nelson on the off chance that he might like to help us visualize the two-way link idea. (Ted, let me know if I shouldn't forward messages like this to you. Seems like giving some researchers a view into some of your ideas should help you on your way to realizing them. Then again, the road to hell is paved with... irritating people forwarding messages with good intentions.) Cheers, --Casey Ransberger > On Oct 5, 2014, at 5:52 AM, John Carlson wrote: > > To put the problem in entirely file system terminology, What happens to a > folder with shortcuts into it when you move the folder? How does one > automatically repoint the shortcuts? Has this problem been solved in > computer science? On linux, the shortcuts would be symbolic links. > > I had a dream about smallstar when I was thinking about this. The author was > essentially asking me how to fix it. He was showing me a hierarchy, then he > moved part of the hierarchy into a subfolder and asked me how to automate > it--especially the links to the original hierarchy. > > In language terms, this would be equivalent of refactoring a class which gets > dropped down into an inner class. This might be solved. I'm not sure. > > This would be a great problem to solve on the web as well...does Xanadu do > this? > > I think the solution is to maintain non-persistent nodes which are computed > at access time, but I'm not entirely clear. > > I have no idea why I am posting this to cap-talk. There may be some > capability issues that I haven't thought of yet. Or perhaps the capability > folks have already solved this. > > For your consideration, > > John Carlson > ___ > 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] About the reduce of complexity in educating children to program
Hello Iliya. While you directed your inquiry to the people at VPRI (and I'm not there,) I hope you'll forgive my curiosity. Questions inline, and hopefully not too many of them. > On Sep 19, 2014, at 2:16 AM, Iliya Georgiev wrote: > > Hello, > I am addressing this letter mainly to Mr. Alan Kay and his fellows at VPRI. I > have an idea how to reduce complexity in educating children to program. This > seems to be a part of a goal of the VPRI "to improve "powerful ideas > education" for the world's children". > > But in case my idea turns into success, a moral hazard emerges. If the > children (6-14 years old) understand things better and can even program, can > they become a victim of labor exploitation? All stop. Anyone can be exploited. It just takes a big enough gang of exploitive people. Is this really a question, or is it more of a statement? > Up to know they could be exploited physically. From now on they could be > exploited mentally. OK, in the north in so called developed countries they > may be protected, but in the south... > > On the other side, don't we owe to the tomorrow people the possibility to > understand the world we leave to them? Or they will be savages that use > tools, but do not know how work. I made a half-assed promise at the top to only ask questions, but your phrasing here struck me as stunningly beautiful. "The tomorrow people." If I'd written that, I'd be inclined to capitalize and underline the words. It'd be a great title for a science fiction novel. > So if you want to wear the burden of the moral hazard, I will send the > description of my idea to you and help with what I can. All stop. Why must I decide to bear a burden before I read your words? What risk is there in sharing them without contract? > You will judge, if it is worth to do it. It would be easily if people work > cooperatively. That is a lesson children should learn too. The software could > be made from one person, but there may be more challenges than one think. In > case you agree to do it I will want you to publish online the results of the > experiment. And if possible to make the program to run in a web browser and > to release it freely too, just as you did in some of your recent experiments. Isn't that asking a bit much? Would not asking for permission to publish your results yourself be enough? > It is strange that unlike more scientists, I will be equally happy from the > success and failure of my idea. Ouch. Yeah, I see what you're trying to say. Once again, I've failed to ask a question. What I'll say instead: I've never known a good scientist who would not be happy to know that her hypothesis was incorrect, because in doing so, she's learned something about the universe and our place in it, which is what she set out to do in the first place. > Best regards, > > Iliya Georgiev Hope I haven't created unnecessary noise with this post. I assure you that you will forgive my curiosity! --Casey___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Xanadu has a heartbeat!
Thought I'd let folks know that the Xanadu project has made some very good progress. They now have a mostly-finished implementation in Javascript. http://xanadu.com --Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] SPUTNIK
After reading this as well as I could, I feel like I'd really need to consult with my analyst, Dr. ELIZA, but maybe it's all roses after all? Anyway I was running down the hall and ran into this guy named Markov, are we still there? Next magic trick? > On Dec 7, 2013, at 11:32 PM, "Евгений Филиппов (Eugene Philippov)" > wrote: > > BAZALTCOMPENDIUM грязьэтоземляземлялечит > жужжат чужие, свои приносят оружие > 8 > ___ > 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] Task management in a world without apps.
A fun, but maybe idealistic idea: an "application" of a computer should just be what one decides to do with it at the time. I've been wondering how I might best switch between "tasks" (or really things that aren't tasks too, like toys and documentaries and symphonies) in a world that does away with most of the application level modality that we got with the first Mac. The dominant way of doing this with apps usually looks like either the OS X dock or the Windows 95 taskbar. But if I wanted less shrink wrap and more interoperability between the virtual things I'm interacting with on a computer, without forcing me to "multitask" (read: do more than one thing at once very badly,) what's my best possible interaction language look like? I would love to know if these tools came from some interesting research once upon a time. I'd be grateful for any references that can be shared. I'm also interested in hearing any wild ideas that folks might have, or great ideas that fell by the wayside way back when. Out of curiosity, how does one change one's "mood" when interacting with Frank? Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Software Crisis (was Re: Final STEP progress report abandoned?)
I don't think cut and paste has been the source of the problems with the systems I've worked on (could be a symptom of one or more of the problems.) What I see is long-term systems built around short-term, usually competitive goals, by people who are competing both with one another (for jobs, promotions, raises, social capital, etc,) and also cooperating with one another to compete with other businesses at the same time. Most people's programming habits seem to change dramatically, for example, when they expect to throw something away. Most programmers dump the company every 2-5 years for another (higher-paying) job, so it's *all* disposable code in effect. It's not just the programmers either, it's the decision makers at C-level too, who are quite often "building the company to sell the company." Maybe the kids are getting dumber, but what I see when I look around is smart kids being pushed to ship before the bits are ready, and not being *allowed* to fix "low-value" bugs which gradually accumulate until a system is deep-sixed for being painful to work on. In other words, I don't believe there's a software crisis or any real shortage of programming talent (I know plenty of great programmers who regularly go without work, often because they're unimpressed with the offers they're seeing.) I think it's not a software crisis, I think it's a *management* crisis. I do think new tools to make managers/customers/investors/partners/users/programmers less stressed out could make the overall experience better for all involved, and with that I guess I'm talking about the continuing emergence of an engineering discipline in software. But that's in-house code. OTOH, FreeBSD has usually been pretty stable for me; I don't have to put out its fires very much. Why might this be? Let's try some fun game theory! http://www.nature.com/ncomms/2013/130801/ncomms3193/pdf/ncomms3193.pdf On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer wrote: > Hi Alan, > > Is the gift really that bad? It certainly is an interesting question. > > I'm a frequent blogger on the topic of what could probably be described as > the ongoing 'software crisis'. We definitely build bigger systems these > days, but the quality has likely been declining. There is great software > out there, but the world is littered with lots of partially working code > that causes lots of problems. > > Perhaps one could lay this on the feet of better documentation. That is, > when I started coding it was hard to find out any information so I spent a > lot of time just playing with the underlying pieces to really understand > them and figure out how to use them appropriately. These days, the "kids" > do a quick google, then just copy&paste the results into the code base, > mostly unaware of what the underlying 'magic' instructions actually do. So > example code is possibly a bad thing? > > But even if that's true, we've let the genie out of the bottle and he is't > going back in. To fix the quality of software, for example, we can't just > ban all cut&paste-able web pages. I definitely agree that we're terrible > thinkers, and that for the most part as a species we are self-absorbed and > often lazy, so I don't really expect that most programmers will have the > same desire that I did to get down to really understanding the details. > That type of curiosity is rare. > > The alternate route out of the problem is to exploit these types of human > deficiencies. If some programmers just want to cut&paste, then perhaps all > we can do is too just make sure that what they are using is high enough > quality. If someday they want more depth, then it should be available in > easily digestible forms, even if few will ever travel that route. > > If most people really don't want to think deeply about about their > problems, then I think that the best we can do is ensure that their hasty > decisions are based on as accurate knowledge as possible. It's far better > than them just flipping a coin. In a sense it moves up our decision making > to a higher level of abstraction. Some people lose the 'why' of the > decision, but their underlying choice ultimately is superior, and the 'why' > can still be found by doing digging into the data. In a way, isn't that > what we've already done with micro-code, chips and assembler? Or machinery? > Gradually we move up towards broader problems... > > > Paul. > > Sent from my iPad > > On 2013-09-08, at 10:45 AM, Alan Kay wrote: > > Hi Paul > > When I said "even scientists go against their training" I was also > pointing out really deep problems in humanity's attempts at thinking (we > are quite terrible thinkers!). > > If we still make most decisions without realizing why, and use > conventional "thinking tools" as ways to rationalize them, then > technologists providing vastly more efficient, wide and deep, sources for > rationalizing is the opposite of a great gift. > > Imagine a Google that also retrieves counter-examples. Or one that > actively
Re: [fonc] Final STEP progress report abandoned?
John, you're right. I have seen raw binary used as DNA and I left that out. This could be my own prejudice, but it seems like a messy way to do things. I suppose I want to limit what the animal can do by constraining it to some set of "safe" primitives. Maybe that's a silly thing to worry about, though. If we're going to grow software, I suppose maybe I should expect the process to be as messy as life is:) On Wed, Sep 4, 2013 at 4:06 PM, John Carlson wrote: > I meant to say you could perform and record operations while the program > was running. > > I think people have missed machine language as "syntaxless." > On Sep 4, 2013 4:17 PM, "John Carlson" wrote: > >> >> On Sep 3, 2013 8:25 PM, "Casey Ransberger" >> wrote: >> >> > It yields a kind of "syntaxlessness" that's interesting. >> >> Our TWB/TE language was mostly syntaxless. Instead, you performed >> operations on desktop objects that were recorded (like AppleScript, but >> with an iconic language). You could even record while the program was >> running. We had a tiny bit of syntax in our predicates, stuff like range >> and set notation. >> >> Can anyone describe Minecraft's syntax and semantics? >> > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- CALIFORNIA H U M A N ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Final STEP progress report abandoned?
Sorry, I've missed a beat somewhere. "Arrowized?" What's this bit with arrows? I saw the term arrow earlier and I think I've assumed that it was some slang for the FRP thing (if you think about it, that makes some sense.) But starting with intuitive assumptions is usually a bad plan, so I'd love some clarification if possible. On Sep 3, 2013, at 5:30 PM, David Barbour wrote: > Factor would be another decent example of a concatenative language. > > But I think arrowized programming models would work better. They aren't > limited to a stack, and instead can compute rich types that can be evaluated > as documents or diagrams. Further, they're really easy to model in a > concatenative language. Further, subprograms can interact through the arrow's > model - e.g. sharing data or constraints - thus operating like agents in a > multi-agent system; we could feasibly model 'chromosomes' in terms of > different agents. > > I've recently (mid August) started developing a language that has these > properties: arrowized, strongly typed, concatenative, reactive. I'm already > using Prolog to find functions to help me bootstrap (it seems bootstrap > functions are not always the most intuitive :). I look forward to trying some > genetic programming, once I'm further along. > > Best, > > Dave > > > On Tue, Sep 3, 2013 at 4:45 PM, Brian Rice wrote: > 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 > wrote: > 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 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 > > > ___ > 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 abandoned?
Yes, in the case of FORTH, the concatenative property is what's interesting in this regard. It yields a kind of "syntaxlessness" that's interesting. I have to admit no real familiarity with APL (outside of some stunningly elegant solutions I've read to problems on Project Euler!) Thanks for letting me know that there's a familial relationship with FORTH and APL, Brian:) Also, genetic programming in a Prolog? Anyone? On Sep 3, 2013, at 4:45 PM, Brian Rice wrote: > 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 > wrote: > 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 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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Final STEP progress report abandoned?
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 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
[fonc] Study on the effectiveness of learning software
Maybe relevant. Reading through this now... the findings seem to be broadly depressing. Notably: I get the sense that only commercial products were part of the study. I'm not familiar with any of them; in other words: Logo, Etoys, and Scratch were absent. Full text: http://ies.ed.gov/ncee/pubs/20094041/pdf/20094041.pdf ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Interaction Design for Languages
Below (original post heavily abridged.) On Thu, Aug 29, 2013 at 6:09 PM, David Barbour wrote: > > 2) Ka-Ping Yee's principles for "Secure Interaction Design" are excellent. > These focus on keeping users continuously aware of what authorities they > possess, where they come from, which authorities they have granted, > universal revocability (no 'grandfather law' authorities), and controlling > against accidental grants (i.e. path of least resistance is least > authority). These principles guided my design of RDP: capability security > model addresses most of Yee's principles, while continuous reactive > dataflows help with both revocability and visibility. > http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=16AE36F3FA20A07CEC5FD242CDC26DAA?doi=10.1.1.6.1380&rep=rep1&type=pdf Guessing this is what I should be reading to know what you're talking about? > 3) Stan Lee's principle: power is coupled with responsibility. A language > or UI should be able to enforce that certain responsibilities are > discharged before it proceeds. E.g. if we start a handshake, we must finish > it; if we open a connection, we must process it; if we make a promise, we > must fulfill it. Most programming languages fail badly here. It easy to > drop these things halfway through; i.e. there is rarely an equivalent of > 'form validation' at the behavior layer. Use of substructural (affine, > relevant, linear) types, however, is very useful for expressing and > enforcing responsibilities. > Stan Lee is very principled. If I find a flaw in this work, do I get a no-prize? :D > Best, > > Dave > Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 2D sexpressions for GIS, Frank/Nile
SHRDLU was related to Planner right? There's a Prologue-alike you might start with in the OMetaJS distro... here: http://tinlizzie.org/ometa-js/#Toylog On Fri, Aug 9, 2013 at 12:43 AM, John Carlson wrote: > Has anyone considered GIS sexpressions for Frank/Nile/Open > Croquet/Cobalt? First one would be given a map with capabilities, one > could place sexpressions on a map on points in areas, like (deposit (sell > (bottle (ferment (harvest #grapes #harvest-location-capability)) > #wente-riesling)) #bank-of-america-account-capability). Perhaps I am > thinking of simfarm but with sexpressions for learning programming and > commerce. Perhaps I'll do some googling if no one has anything. Perhaps > this is a kind of 2D SHRDLU. > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deoptimization as fallback
Hi Dirk, yes I am aware of dynamic VMs that deoptimize when their heuristics for what to precompile fail. Most of the JIT/PIC VMs do this. But my gut says what I'm asking about is a bit different than that. Of course, maybe it isn't. Falling back to interpreter logic, now that you mention it, isn't so different from what I'm asking about at all. Good point. You know, if I didn't have you folks around, I might start thinking that my ideas were original:) On Jul 30, 2013, at 5:58 PM, Dirk Pranke wrote: > On Tue, Jul 30, 2013 at 1:22 PM, Casey Ransberger > wrote: > Thought I had: when a program hits an unhandled exception, we crash, often > there's a hook to log the crash somewhere. > > I was thinking: if a system happens to be running an optimized version of > some algorithm, and hit a crash bug, what if it could fall back to the > suboptimal but conceptually simpler "Occam's explanation?" > > All other things being equal, the simple implementation is usually more > stable than the faster/less-RAM solution. > > Is anyone aware of research in this direction? > > This sounds fairly close to "compiler deoptimization", which is fairly common > in just-in-time compiler technology (see v8, the self system, probably jvms > do it also ...). Perhaps you could start there? > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.4338 > http://www.cs.ucsb.edu/~urs/oocsb/self/papers/dynamic-deoptimization.html > > -- Dirk > > ___ > 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] Macros, JSON
Probably a more usable language would be arrived upon via some extensions to JSON. May I recommend OMetaJS? :) The lack of a unique atomic symbolic literal as distinct from a string is one of the things I'm grappling with right now. To get that I'd need to intern the atoms. Jury's out whether it's a good idea to try to used JS typed arrays to implement the symbol interning or to use an under the hood "tag" on the string at the intermediate level to distinguish them (hidden from the programmer who just sees a Lisp alike.) On Jul 21, 2013, at 1:45 PM, John Carlson wrote: > Or numbers for pointers... > > On Jul 21, 2013 3:43 PM, "John Carlson" wrote: > I think what would be more difficult would be identifying what is persistent > and what is runtime values. Also, JSON doesn't contain pointers, so one > would have to use strings for pointers. > > On Jul 21, 2013 3:22 PM, "James McCartney" wrote: > > I thought about this briefly. One issue is how to distinguish literal strings > from identifiers. > > On Sun, Jul 21, 2013 at 10:28 AM, John Carlson wrote: > Hmm. I've been thinking about creating a macro language written in JSON that > operates on JSON structures. Has someone done similar work? Should I just > create a JavaScript AST in JSON? Or should I create an AST specifically for > JSON manipulation? > > Thanks, > > John > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > > > -- > --- james mccartney > ___ > 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] Macros, JSON
Lisp is such a joy to implement. FORTH is fun too.
I'm working on a scheme-alike on and off. The idea is to take the message
passing and delegation from Self, expose it in Lisp, and then map all of that
to JavaScript.
One idea I had when I was messing around with OMetaJS was that it might have
some kind of "escape syntax" like
(let ((x 1))
#{x++; }#
)
Would basically mean
(let ((x 1))
(+ x 1))
...which would make doing "primitives" feel pretty smooth, and also give you
the nice JSON syntax.
The rule is simple too, '#{' followed by anything:a up until '}#' -> eval(a)
Only problem is relating environment context between the two languages, which I
haven't bothered to figure out yet. The JS eval() in this case is insufficient.
(Sorry about the pseudocode, on a phone and don't keep OMeta syntax in my
head...)
On Jul 21, 2013, at 1:15 PM, Alan Moore wrote:
> JSON is all well and good as far as lowest common denominators go. However,
> you might want to consider EDN:
>
> https://github.com/edn-format/edn
>
> On the other hand, if you are doing that then you might as well go *all* the
> way and re-invent half of Common Lisp :-)
>
> http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
>
> Alan Moore
>
>
> On Sun, Jul 21, 2013 at 10:28 AM, John Carlson wrote:
> Hmm. I've been thinking about creating a macro language written in JSON that
> operates on JSON structures. Has someone done similar work? Should I just
> create a JavaScript AST in JSON? Or should I create an AST specifically for
> JSON manipulation?
>
> Thanks,
>
> 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
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] [HISTORY][MYSTERY][THRILLS][OT] Sunrise anyone?
There's a local computer/electronics store that basically resells old unloved gear in the neighborhood called Re-PC. While the band was buying adapters at the counter, your intrepid bassist wandered off to the little computer museum at the back in order to drool over the PDP-8 a little and saw this odd little thing: [image: photo.JPG] The card next to it just said, where there's usually an interesting blurb: "Xerox Sunrise (???) 19?? We used to know all about this. Re-PC Certificate of Antiquity" It looked like some kind of word processor with the long LCD display line, but the micro cassette drive on the right and accompanying speaker (which seemed a bit large just for a beeper) had me curious. There's also an accompanying disk drive thingie so I was sure it wasn't just a word processor. Googling tells me it ran CP/M and didn't live long as a product, but not much else, at least at first glance. The tag seemed to indicate that at one point there was an interesting story associated with the machine. Anyone know anything about it or why it wasn't made for very long? -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Report Card
I wanted to send this message out after the final status report, but since that's indefinitely delayed (keep going!) I'm just going to do it now. Easy question: has keeping this dialogue open been useful to the folks at VPRI, or has it been more of a burden than anything else? I can definitely say that it's been very good for me, in that I learned a hell of a lot reading all of the lovely papers posters cited. It's also been a lot of fun meeting people who were interested in a lot of the same things that I was. I'm not so happy about my own contribution though. Did I do anything at all to advance the state of the art? Well, no. I mostly just flapped my lips. It's asymmetrical, I learned way more than I taught. The best I could do was play sounding board for some of Ian's ideas while dinking around with Maru's guts. BTW if you haven't looked at it, Maru is way cool. VPRI has done something pretty awesome and weird here, in that the dialogue was wide open the whole time. As I gather, it was in the spirit of ARPA. We've had our share of trolls, long-winded posters (raises hand) and just general chaos. I really enjoyed the guy who called us all a bunch of Alan Kay fanboys the other day by the way. That was just priceless. Like we can't think for ourselves! (Alan if I can get an autograph after this I think I'll be set.) So seriously, has this been worthwhile? I'm not just asking VPRI folks, though I'm DEFINITELY asking VPRI folks, I'm also asking everyone else on the list. I learned a lot, huge win for me, and we talked in circles a bunch, some of that was fun. I can also think of a few parts where I felt pretty strongly that it *was* worthwhile. To throw out an example, remember when Dale Schumacher asked pretty poignantly whether or not the original idea behind objects/messages was similar to the actor model? That was like a blockbuster for nerds it was so awesome. That totally rocked. That's me. Okay now talk amongst yourselves go! ? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
It's on the reading list now. Thank you! On Apr 19, 2013, at 5:56 AM, Alan Kay wrote: > Wow, automatic spelling correctors suck, especially early in the morning > > The only really good -- and reasonably accurate -- book about the history of > Lick, ARPA-IPTO (no "D", that is when things went bad), and Xerox PARC is > "Dream Machines" by Mitchell Waldrop. > > Cheers, > > Alan > > From: Alan Kay > To: Fundamentals of New Computing > Sent: Friday, April 19, 2013 5:53 AM > Subject: Re: [fonc] 90% glue code > > The only really good -- and reasonable accurate -- book about the history of > Lick, ARPA-IPTO (no "D", that is went things went bad), and Xerox PARC is > "Dream Machines" by Mitchel Waldrop. > > Cheers, > > Alan > > From: Miles Fidelman > To: Fundamentals of New Computing > Sent: Friday, April 19, 2013 5:45 AM > Subject: Re: [fonc] 90% glue code > > Casey Ransberger wrote: > > This Licklider guy is interesting. CS + psych = cool. > > A lot more than cool. Lick was the guy who: > - MIT Professor > - pioneered timesharing (bought the first production PDP-1 for BBN) and AI > work at BBN > - served as the initial Program Manager at DARPA/IPTO (the folks who funded > the ARPANET) > - Director of Project MAC at MIT for a while > - wrote some really seminal papers - "Man-Computer Symbiosis"is write up > there with Vannevar Bush's "As We May Think" > > /It seems reasonable to envision, for a time 10 or 15 years hence, a > 'thinking center' that will incorporate the functions of present-day > libraries together with anticipated advances in information storage and > retrieval./ > > /The picture readily enlarges itself into a network of such centers, > connected to one another by wide-band communication lines and to individual > users by leased-wire services. In such a system, the speed of the computers > would be balanced, and the cost of the gigantic memories and the > sophisticated programs would be divided by the number of users./ > > - J.C.R. Licklider, Man-Computer Symbiosis > <http://memex.org/licklider.html>, 1960. > > - perhaps the earliest conception of the Internet: > In a 1963 memo to "Members and Affiliates of the Intergalactic Computer > Network," Licklider theorized that a computer network could help researchers > share information and even enable people with common interests to interact > online. > (http://web.archive.org/web/20071224090235/http://www.today.ucla.edu/1999/990928looking.html) > > Outside the community he kept a very low profile. One of the greats. > > 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] 90% glue code
This Licklider guy is interesting. CS + psych = cool. This conversation makes me think of things Hofstadter wrote about with regard to isomorphism in Gödel, Escher, Bach. I only have one or two very small things to contribute here. Esperanto doesn't seem to have caught on, and sometimes a good idea takes a long time to catch on :) Mmm, and maybe McCarthy's search for a universal intermediate representation is on-target here too. I've wondered how Frank would deal with the problem of "language barrier," especially around metalanguage. On Fri, Apr 19, 2013 at 1:45 AM, Casey Ransberger wrote: > WRT the 90% guess, I usually go for 80% on stuff like that when I make a > SWAG where it smells like a Pareto distribution. > > http://en.wikipedia.org/wiki/Pareto_principle > > http://en.wikipedia.org/wiki/Pareto_distribution > > > > On Tue, Apr 16, 2013 at 7:52 PM, David Barbour wrote: > >> >> On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart wrote: >> >>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>> > In real systems, 90% of code (conservatively) is glue code. >>> >>> What is the origin of this claim? >>> >> >> I claimed it from observation and experience. But I'm sure there are >> other people who have claimed it, too. Do you doubt its veracity? >> >> >>> >>> >>> On Mon, Apr 15, 2013 at 12:15 PM, David Barbour wrote: >>> >>>> >>>> On Mon, Apr 15, 2013 at 11:57 AM, David Barbour wrote: >>>> >>>>> >>>>> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David < >>>>> l...@loup-vaillant.fr> wrote: >>>>> >>>>>> On Sun, Apr 14, 2013 at 04:17:48PM -0700, David Barbour wrote: >>>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>>>>> > In real systems, 90% of code (conservatively) is glue code. >>>>>> >>>>>> Does this *have* to be the case? Real systems also use C++ (or >>>>>> Java). Better languages may require less glue, (even if they require >>>>>> just as much core logic). >>>>>> >>>>> >>>>> Yes. >>>>> >>>>> The prevalence of glue code is a natural consequence of combinatorial >>>>> effects. E.g. there are many ways to partition and summarize properties >>>>> into data-structures. Unless we uniformly make the same decisions - and we >>>>> won't (due to context-dependent variations in convenience or performance) >>>>> - >>>>> then we will eventually have many heterogeneous data models. Similarly can >>>>> be said of event models. >>>>> >>>>> We can't avoid this problem. At best, we can delay it a little. >>>>> >>>> >>>> I should clarify: a potential answer to the glue-code issue is to >>>> *infer* much more of it, i.e. auto-wiring, constraint models, searches. We >>>> could automatically build pipelines that convert one type to another, given >>>> smaller steps (though this does risk aggregate lossiness due to >>>> intermediate summaries or subtle incompatibilities). Machine-learning >>>> could be leveraged to find correspondences between structures, perhaps >>>> aiding humans. 90% or more of code will be glue-code, but it doesn't all >>>> need to be hand-written. I am certainly pursuing such techniques in my >>>> current language development. >>>> >>>> >>>> ___ >>>> 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 >> >> > > > -- > Casey Ransberger > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] 90% glue code
WRT the 90% guess, I usually go for 80% on stuff like that when I make a SWAG where it smells like a Pareto distribution. http://en.wikipedia.org/wiki/Pareto_principle http://en.wikipedia.org/wiki/Pareto_distribution On Tue, Apr 16, 2013 at 7:52 PM, David Barbour wrote: > > On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart wrote: > >> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >> > In real systems, 90% of code (conservatively) is glue code. >> >> What is the origin of this claim? >> > > I claimed it from observation and experience. But I'm sure there are other > people who have claimed it, too. Do you doubt its veracity? > > >> >> >> On Mon, Apr 15, 2013 at 12:15 PM, David Barbour wrote: >> >>> >>> On Mon, Apr 15, 2013 at 11:57 AM, David Barbour wrote: >>> >>>> >>>> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David < >>>> l...@loup-vaillant.fr> wrote: >>>> >>>>> On Sun, Apr 14, 2013 at 04:17:48PM -0700, David Barbour wrote: >>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>>>> > In real systems, 90% of code (conservatively) is glue code. >>>>> >>>>> Does this *have* to be the case? Real systems also use C++ (or >>>>> Java). Better languages may require less glue, (even if they require >>>>> just as much core logic). >>>>> >>>> >>>> Yes. >>>> >>>> The prevalence of glue code is a natural consequence of combinatorial >>>> effects. E.g. there are many ways to partition and summarize properties >>>> into data-structures. Unless we uniformly make the same decisions - and we >>>> won't (due to context-dependent variations in convenience or performance) - >>>> then we will eventually have many heterogeneous data models. Similarly can >>>> be said of event models. >>>> >>>> We can't avoid this problem. At best, we can delay it a little. >>>> >>> >>> I should clarify: a potential answer to the glue-code issue is to >>> *infer* much more of it, i.e. auto-wiring, constraint models, searches. We >>> could automatically build pipelines that convert one type to another, given >>> smaller steps (though this does risk aggregate lossiness due to >>> intermediate summaries or subtle incompatibilities). Machine-learning >>> could be leveraged to find correspondences between structures, perhaps >>> aiding humans. 90% or more of code will be glue-code, but it doesn't all >>> need to be hand-written. I am certainly pursuing such techniques in my >>> current language development. >>> >>> >>> ___ >>> 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 > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Scope? [was: The Fanboy Mailing List With No Productivity]
Below. On Apr 13, 2013, at 7:18 AM, Miles Fidelman wrote: > Ondřej Bílka wrote: >> This is just a trash bin for people who don't want to do anything. The real work is probably on noise-free mailing list. This is the fanboy list for Alan Kay. >> Also cannot resist. >> >> Well if you are not satisfied you can establish new list. Then we will >> have: > > Though... it does raise the question: what is the intended and/or evolved > scope of FONC? For the purposes of discussion here, what constitutes "new > computing?" > > Is it: > a. VPRI's work > b. programming paradigms and languages (for which > http://lambda-the-ultimate.org/ is really the best forum I've seen) > c. computational models and paradigms (e.g, massively concurrent systems, AI) > d. leading edge applications > e. computing paradigms in the large (e.g., biological computing, quantum > computing) > e. something else? > f. some combination of the above? > > Kinda hard to tell from the discussions, and > http://vpri.org/mailman/listinfo/fonc is silent on the question. > > Miles Fidelman Oh come on. If you'd read everything here: http://vpri.org/html/writings.php ...or followed the dialogue much, you wouldn't have to ask this question. Your pal, Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] holy grail of FONC?
I think what you might be seeing is a desire in the community to overcome some of the boundaries to advancement that one arrives upon when building an educational system on top of a less educational system. A class example might be the challenge an avid Etoys user might face when exiting the "walled garden" of Etoys and starting to try to program in (in this case) something like Smalltalk. Smalltalk is easier to learn than C++ (thanks!) but a lot harder to learn than Etoys. It's sudden. There isn't a very good gradient to the learning curve. It's kind of like, kid, now you're on your own, and you better learn how to use that sword fast if you wanna survive. You go from safe to true become: false pretty fast. See below for one way to ease the "unsafe programming" problem that's been a product of the FONC work, called "worlds." It would be better, one might argue, if the knowledge of one layer might be able to help explain the knowledge needed to tackle the next lower layer. One way to facilitate this might be to build every layer in terms of the layer beneath it, but also, *linguistically* to describe every layer's language in terms of the same substrate. See also, OMeta. Frank seems to do this -- as far as I can discern without using it -- better than anything we've seen yet. Or anyway that's the hope as I understand it. Of course there are other objectives which are related, like getting the total body of work needed to express a fully working system down to the quanta we really actually need to continue our studies. If we can do that, we may be able to make our studies more precise, more accurate. This could be valuable to both educators and to the "thousands of slaves" in industry (raises hand.) One initiative which is interesting is Worlds which could function as a kind of "exploratory programmer's undo." This has been covered in various papers on the VPRI writings page, and touched upon IIRC in some of the NSF updates. It's actually IMHO one of the unsung heroes of what these people have been up to. My favorite quote from anyone related to this effort comes from a private conversation with Ian Piumarta, (Ian, if it wasn't cool to share this, I'll let you hit me in the face one time) and he said this: "My mission is to discover the Bose-Einstein condensate of computer programming..." Which is (I think) to say: I want to find a way to make quantum effects become apparent at a macroscopic scale. If we can figure out how to do something analogous to that in the context of programming, by re-examining the fundamentals we have taken for granted since the birth of the industry, we may be able to apply that knowledge to build massively simpler large scale systems. Please forgive if I've gone on at length about stuff you already knew. As for the Holy Grail? I don't think it exists. There is no dark side of the moon, really. As a matter of fact, it's all dark. (The redacted part of the original studio recording was: the only thing that makes it look light is the sun.) Hugs and such! Casey On Apr 13, 2013, at 6:34 AM, John Carlson wrote: > Is the holy grail of FONC to create an environment where you can use command > line, text editor, IDE, and end-user programming to program the same program? > Are there any other ways to program? Circuit boards? I believe FONC > includes this. Speech and gestures? Does FONC provide a way to use speech > and gestures to program? Is this a bit like Intentional Software? This > reminds me a bit of Tcl/Tk as well, where programming command line, program > and GUI were integrated. What else out there is trying to encompass all > kinds of programming in a cross media way? > > 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
[fonc] CodeSpells, new thread
So I think the original thread drifted a bit. I'm curious about what folks think of the research involved here. I read the paper. A few things stuck out. The thing I'd mention is that it seemed to work (at least superficially) with getting 12 year olds to (begin to) tackle a programming language which by my own (prejudiced) standards is a rather difficult choice for *adults* who want to program casually. I guess I also identified with the whole set of things they identified as common among kids who learned to code in a quiet hole without any real support. They say that Java wasn't trying to convert the Lisp crowd, so much as the C++ crowd. Lisp, so far, seems a lot more learnable than C++ but that's beside my interest here. Since one of the things I think we ought to be arguing about in this context is "how do we scale things like Scratch or Etoys up to the sky and down to the metal?" I do think the study is relevant. It maybe helps explain how to deal with the trip to the metal end. Or maybe not. OTOH I didn't feel like there were enough numbers in there. It felt very very soft-science, and maybe there's no way around that. And maybe I have a prejudice about soft science. I got the general sense that the smell meant it was working, though, so I'm really interested in seeing what these folks do next. At the end of the day, what works, works, right? Does anyone here know these researchers? Any chance we might be able to pull them into the dialogue? At risk of wasting time on BS troll threads. I get the sense these are the kind of people I'd like to see posting here. Anyway they've got some *very* relevant experience now, and I think it would be cool to hear about what they're planning to do next. Just a thought. -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] When natural language fails!
I had never heard of Elephant. Of course anything John McCarthy is worth a look, and this is relevant to my interests:) Also: thanks for pointing me at all the papers folks! On Tue, Apr 9, 2013 at 1:25 PM, Brendan Baldwin wrote: > Wasn't John McCarthy's Elephant programming language based on the metaphor > of conversation? Perhaps voice based programming interactions are > addressed there? > On Apr 9, 2013 8:46 AM, "David Barbour" wrote: > >> >> On Tue, Apr 9, 2013 at 1:48 AM, Casey Ransberger < >> casey.obrie...@gmail.com> wrote: >> >>> >>> The computer is going to keep getting smaller. How do you program a >>> phone? It would be nice to be able to just talk to it, but it needs to be >>> able -- in a programming context -- to eliminate ambiguity by asking me >>> questions about what I meant. Or *something.* >>> >> >> Well, once computers get small enough that we can easily integrate them >> with our senses and gestures, it will become easier to program again. >> >> Phones are an especially difficult target (big hands and fingers, small >> screens, poor tactile feedback, noisy environments). But something like >> Project Glass or AR glasses could project information onto different >> surfaces - screens the size of walls, effectively - or perhaps the size of >> our moleskin notebooks [1]. Something like myo [2] would support pointer >> and gesture control without much interfering with our use of hands. >> >> That said, I think supporting ambiguity and resolving it will be one of >> the upcoming major revolutions in both HCI and software design. It has a >> rather deep impact on software design [3]. >> >> (Your Siri converstation had me laughing out loud. Appreciated.) >> >> [1] >> http://awelonblue.wordpress.com/2012/10/26/ubiquitous-programming-with-pen-and-paper/ >> [2] https://getmyo.com/ >> [3] >> http://awelonblue.wordpress.com/2012/05/20/abandoning-commitment-in-hci/ >> >> >> _______ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] When natural language fails!
Hah, yes, 42. I wondered if anyone was going to point that out :D "I always thought there was something fundamentally wrong with the universe..." On Fri, Apr 12, 2013 at 1:40 AM, GrrrWaaa wrote: > It doesn't reply forty-two? > > http://answers.yahoo.com/question/index?qid=20081019212355AAHkApl > > On Apr 9, 2013, at 5:48 PM, Casey Ransberger wrote: > > > It's tragic that Siri can't tell me what you get when you multiply six > by nine. > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] When natural language fails!
Here's my example. Siri: Intruders detected on the tenth floor. Me: Okay Siri, seal off decks six through twelve. Open the airlocks. Number one! Arrange a security detatchment, let's light a fire under their asses! Siri: Aye captain. Retracting cooling rods from primary and secondary reactors. Fire should commence within minutes. Me: No no no no! Put the cooling rods back into the reactors, Siri! What the [explitive deleted] were you thinking?? Siri: Got it. I've made an appointment with your dentist for Monday. Approximately three minutes fourteen seconds to meltdown in primary and secondary reactors. Your dentist says hello, by the way. (etcetera) The computer is going to keep getting smaller. How do you program a phone? It would be nice to be able to just talk to it, but it needs to be able -- in a programming context -- to eliminate ambiguity by asking me questions about what I meant. Or *something.* It's tragic that Siri can't tell me what you get when you multiply six by nine. I think it's been crippled, based on stuff Woz has said about what Apple did when they bought it up. So there are some really interesting angles without well understood solutions wrt NLP (and of course the group is welcomed to slap me in the face with my ignorance because I know there's stuff I don't know.) The best thing I've found to a natural language programming system is Inform 7 which leaves things to be desired. At least it is unambiguous, but I think that in natural language, what we need are ways to cope with disambiguation. Anyone want to point me at cool stuff to read? :D -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Please feel free to change the subject line.
What started off (at least ostensibly) as a conversation about NLP ended up being a conversation about the actor model, and the subject did change once, but to something not AFAIK related to actors. If I was less patient about wading though blah blah I might have missed interesting thoughts about actors, which is relevant to my interests. I'm not referring to the off topic origin of the thread so much as the fact that the subject line didn't track the context as it shifted. Trying not to be too much of a complainer, and I kind of have to applaud the community for trying patiently to bring a thread kicking and screaming back into the topical, as well as Kim Rose for putting the official foot down about what's too far off topic for discussion on this list, so thank you and thank you. -- Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Bio computer
I actually misspoke... they're getting actual logic into the cell. So more than one circuit. I had the same thought though! Isn't it funny that it's easier to get a digital circuit into a biological form than it is to grow software like cells? Still though, maybe we can learn something about the latter from the former. Who knows. On Fri, Mar 29, 2013 at 6:46 PM, Iian Neill wrote: > As great an achievement as that is, shouldn't they be aiming to make a > transistor like a cell? :-) > > Regards, > Iian > > Sent from my iPhone > > On 30/03/2013, at 11:16 AM, Casey Ransberger > wrote: > > Someone finally got round to making a cell that acts like a transistor. > You knew they'd do it eventually;) > > > http://news.sciencemag.org/sciencenow/2013/03/a-computer-inside-a-cell.html?ref=hp > > -- > Casey Ransberger > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > _______ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Bio computer
Someone finally got round to making a cell that acts like a transistor. You knew they'd do it eventually;) http://news.sciencemag.org/sciencenow/2013/03/a-computer-inside-a-cell.html?ref=hp -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] About Waiting (Re: About HyperCard ( was Re: [squeak-dev] Getting rid of coloured code))
Let's keep cool and wait. Or, just take the Gezira code that's leaked out so far and then run as fast as we can with it. I have a feeling, though, that waiting might end up working out better than a lot of folks expect. The results of these experiments may confront us with new challenges. Who could ask for anything more? Let's keep our heads and just pay close attention, okay? I think that's our best plan, don't you? Even if what they're doing isn't a "product" or intended that way, because it's really a big complicated science experiment, I think we will get the best output in terms of understanding the work. If we can understand the work well, we can repeat it without much effort, no? Let us be patient, as we may entreat angels unawares. (Bad quote! I got it all wrong!) :) C On Feb 28, 2013, at 2:02 AM, karl ramberg wrote: > To run the latest and greatest FONC system the Gezire plugin is necessary. > I tried to get the Gezira plug in to compile on Windows but I could not get > the tool chain right and got lost in all the quirky stuff. > I would be nice if there where compiled plugins for all platforms for > download somewhere. > > Karl > > > On Thu, Feb 28, 2013 at 5:09 AM, Yoshiki Ohshima > wrote: > It is not that we at Viewpoints are trying to be secretive, but we do > have a newer system (or systems). Hopefully we can put some code out > when our report is done. > > (Sorry for keeping people guessing.) > > -- > -- Yoshiki > > > ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sources for Functional Reactive Programming
Got it. Thanks! On Thu, Feb 21, 2013 at 1:33 PM, Yoshiki Ohshima wrote: > On Thu, Feb 21, 2013 at 1:15 PM, Casey Ransberger > wrote: > > Didn't know this term, and worrying that I was completely > misunderstanding > > the use of the term "behavior," I googled and found these: > > > > http://conal.net/papers/icfp97/ > > > > > http://haskell.cs.yale.edu/wp-content/uploads/2011/02/genuinely-functional-guis.pdf > > > > There's a Wikipedia article, but it's very sparse. Anything else I should > > read? > > Yes, I think it is unfortunate that they picked the term "behavior" to > mean "continuous time-varying entity". A generic term "behavior" does > not have the connotation of "continuous", as far as I can tell. > > To me, the Flapjax paper and their tutorial are more "intuitive" > (whatever that means) > > http://www.flapjax-lang.org/publications/ > > -- > -- Yoshiki > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Sources for Functional Reactive Programming
Didn't know this term, and worrying that I was completely misunderstanding the use of the term "behavior," I googled and found these: http://conal.net/papers/icfp97/ http://haskell.cs.yale.edu/wp-content/uploads/2011/02/genuinely-functional-guis.pdf There's a Wikipedia article, but it's very sparse. Anything else I should read? -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Building blocks and use of text
The next big thing probably won't be some version of Minecraft, even if Minecraft is really awesome. OTOH, you and your kids can prove me wrong today with Minecraft Raspberry Pi Edition, which is free, and comes with _source code_. http://mojang.com/2013/02/minecraft-pi-edition-is-available-for-download/ On Wed, Feb 13, 2013 at 5:55 PM, John Carlson wrote: > Miles wrote: > > There's a pretty good argument to be made that what "works" are powerful > building blocks that can be combined in lots of different ways; > > So the next big thing will be some version of minecraft? Or perhaps the > older toontalk? Agentcubes? What is the right 3D metaphor? Does anyone > have a comfortable metaphor? It would seem like if there was an open, > federated MMO system that supported object lifecycles, we would have > something. Do we have an "object web" yet, or are we stuck with text > forever, with all the nasty security vunerabilities involved? Yes I agree > that we lost something when we moved to the web. Perhaps we need to step > away from the document model purely for security reasons. > > What's the alternative? Scratch and Alice? Storing/transmitting ASTs? > Does our reliance on https/ssl/tls which is based on streams limit us? When > are we going to stop making streams secure and start making secure network > objects? Object-capability security anyone? > > Are we stuck with documents because they are the best thing for debugging? > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Paranoid programming language
That's a good name for a programming language! On Wed, Feb 13, 2013 at 4:20 AM, David Pennell wrote: > Malboge (http://en.wikipedia.org/wiki/Malbolge) was featured on an > episode of Elementary. It's named after the eighth circle of hell in > Dante's Inferno. > > Malbolge was so difficult to understand when it arrived that it took two >> years for the first Malbolge program to appear. The first Malbolge program >> was not written by a human being, it was generated by a beam >> search<http://en.wikipedia.org/wiki/Beam_search>algorithm designed by Andrew >> Cooke and implemented in >> Lisp <http://en.wikipedia.org/wiki/Lisp_programming_language> >> > > -david > > > On Wed, Feb 13, 2013 at 6:06 AM, Miles Fidelman < > mfidel...@meetinghouse.net> wrote: > >> Well, for evocative names, there's always Brainfuck ( >> http://en.wikipedia.org/wiki/**Brainfuck<http://en.wikipedia.org/wiki/Brainfuck>) >> - which is a real language, with derivatives even. And the name is truly >> accurate. :-) >> >> John Carlson wrote: >> >>> >>> Ah first time I came across a language with such an evocative name. >>> Since I am too paranoid to click on a link, perhaps you could summarize. I >>> did a search and it seemed to indicate that the language was a joke. Sigh. >>> >>> On Feb 12, 2013 7:26 PM, "Miles Fidelman" >>> >> mfidelman@**meetinghouse.net >> wrote: >>> >>> John Carlson wrote: >>> >>> >>> Is there a computer language (yes I realize games do this) >>> that work like human languages? With features like >>> misdirection, misinterpretation, volume, persuasion? Can we >>> come up with a social language for computers? No, I'm not >>> talking lojban, I'm talking something something semantically >>> and/or syntactically ambiguous. Maybe lingodroids is close. >>> More work in this area would be interesting. >>> >>> >>> Well PPL (Paranoid Programming Language) might come close. >>> http://zzo38computer.org/**backup/paranoid-programming-** >>> language.html<http://zzo38computer.org/backup/paranoid-programming-language.html>:-) >>> >>> -- 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<http://vpri.org/mailman/listinfo/fonc> >>> >>> >>> >>> >>> __**_ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/**listinfo/fonc<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 >> >> -- >> -david <http://vpri.org/mailman/listinfo/fonc> >> > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Current topics
nions, and part of the impact of this is amplified by the > simpler shorter term liabilities of imperfect structures on human safety > than on imperfect laws (one could argue that the latter are much more of a > disaster in the long run). > Yeah, the short term liabilities, and the yelling executives interfering with the process. Also, being able to retroactively fix DOA systems remotely produces weird effects that are hard to think about naturally, e.g., working in two different branches where one of them fixes a blocking bug (which is only a minor nuisance for "end users") in the bits you shipped last week, and simultaneously working on next week's release, which depends on the changes in the hotfix. When you're perpetually overworked in that scenario and working on several systems at once, the whole business starts to look like a big ball of wobbly-wobbly, timey-wimey... stuff, and our brains like to view things as a strict progression of cause to effect. What day is it again? > And, in trying to tease useful analogies from Biology, one I get is that > the largest gap in complexity of atomic structures is the one from polymers > to the simplest living cells. (One of my two favorite organisms is > *Pelagibacter > unique*, which is the smallest non-parasitic standalone organism. > Discovered just 10 years ago, it is the most numerous known bacterium in > the world, and accounts for 25% of all of the plankton in the oceans. Still > it has about 1300+ genes, etc.) > 25%? That's like finding out that the world has been round the whole time, ten years ago. > What's interesting (to me) about cell biology is just how much stuff is > organized to make "integrity" of life. Craig Ventor thinks that a minimal > hand-crafted genome for a cell would still require about 300 genes (and a > tiniest whole organism still winds up with a lot of components). > The kernel is a big thing for such a small thing, as usual! > Analogies should be suspect -- both the one to the law, and the one here > should be scrutinized -- but this one harmonizes with one of Butler > Lampson's conclusions/prejudices: that you are much better off making -- > with great care -- a few kinds of relatively big modules as basic building > blocks than to have zillions of different modules being constructed by > vanilla programmers. One of my favorite examples of this was the "Beings" > master's thesis by Doug Lenat at Stanford in the 70s. And this influenced > the partial experiment we did in Etoys 15 years ago. > Partial experiment? Can you be more specific? Should I assume that you mean to point at e.g. Morph (and by extension, Object) in Squeak as largish general purpose base objects or "cells" or "genomes?" > There is probably a "nice size" for such modules -- large enough to both > provide and be well tended, and small enough to minimize internal disasters. > I've had lots of fun arguments about this with coworkers. I have a prejudice: I hate having to scroll down, so I tend toward deeply factored systems (like most of Squeak.) The disadvantage there is I probably spend more time mousing about unraveling the timey-wimey ball than I would if I were looking at files with thousands of lines of code. A friend, though, and I wish I could remember the name of the paper, but he put me onto a study where they tried to measure the relationship between defects and function/method size, and the results surprised me. The systems with the shortest methods had more failures than the systems with slightly longer methods, but that fell off a cliff shortly afterward. Longer than a certain size, defect density seemed to hockey stick. Right through the roof, and at least that part I would expect. BCC friend and former coworker, who might be able to find the paper so I can site my source on that:/ > An interesting and important design problem is to try to (a) vet this idea > in or out, and (b) if in, then what kinds of "semi-universal" modules would > be most fruitful? > (a) I think this is going to be hard to actually measure on a number of levels, which is to say, fun! > One could then contemplate trying -- inducing -- to get most programmers > to program in terms of these modules (they would be the components of an > IDE for commerce, etc., instead of the raw programming components of > today). This tack would almost certainly also help the mess the law is in > going forward ... > Note that desires for runable specifications, etc., could be quite > harmonious with a viable module scheme that has great systems integrity. > > Cheers, > > Alan > > > > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Current topics
Hah, wrong button. Sorry all! Meant to hit forward, as I really enjoyed this one and wanted to share it:) On Tue, Jan 1, 2013 at 6:40 PM, Casey Ransberger wrote: > Read this guy! > > On Tue, Jan 1, 2013 at 7:53 AM, Alan Kay wrote: > >> The most recent discussions get at a number of important issues whose >> pernicious snares need to be handled better. >> >> In an analogy to sending messages "most of the time successfully" through >> noisy channels -- where the noise also affects whatever we add to the >> messages to help (and we may have imperfect models of the noise) -- we have >> to ask: what kinds and rates of error would be acceptable? >> >> We humans are a noisy species. And on both ends of the transmissions. So >> a message that can be proved perfectly "received as sent" can still be >> interpreted poorly by a human directly, or by software written by humans. >> >> A wonderful "specification language" that produces runable code good >> enough to make a prototype, is still going to require debugging because it >> is hard to get the spec-specs right (even with a machine version of human >> level AI to help with "larger goals" comprehension). >> >> As humans, we are used to being sloppy about message creation and >> sending, and rely on negotiation and good will after the fact to deal with >> errors. >> >> We've not done a good job of dealing with these tendencies within >> programming -- we are still sloppy, and we tend not to create negotiation >> processes to deal with various kinds of errors. >> >> However, we do see something that is "actual engineering" -- with both >> care in message sending *and* negotiation -- where "eventual failure" is >> not tolerated: mostly in hardware, and in a few vital low-level systems >> which have to scale pretty much "finally-essentially error-free" such as >> the Ethernet and Internet. >> >> My prejudices have always liked dynamic approaches to problems with error >> detection and improvements (if possible). Dan Ingalls was (and is) a master >> at getting a whole system going in such a way that it has enough integrity >> to "exhibit its failures" and allow many of them to be addressed in the >> context of what is actually going on, even with very low level failures. It >> is interesting to note the contributions from what you can say statically >> (the higher the level the language the better) -- what can be done with >> "meta" (the more dynamic and deep the integrity, the more powerful and safe >> "meta" becomes) -- and the tradeoffs of modularization (hard to sum up, but >> as humans we don't give all modules the same care and love when designing >> and building them). >> >> Mix in real human beings and a world-wide system, and what should be >> done? (I don't know, this is a question to the group.) >> >> There are two systems I look at all the time. The first is lawyers >> contrasted with engineers. The second is human systems contrasted with >> biological systems. >> >> There are about 1.2 million lawyers in the US, and about 1.5 million >> engineers (some of them in computing). The current estimates of >> "programmers in the US" are about 1.3 million (US Dept of Labor counting >> "programmers and developers"). Also, the Internet and multinational >> corporations, etc., internationalizes the impact of programming, so we need >> an estimate of the "programmers world-wide", probably another million or >> two? Add in the *ad hoc* programmers, etc? The populations are similar >> in size enough to make the contrasts in methods and results quite striking. >> >> Looking for analogies, to my eye what is happening with programming is >> more similar to what has happened with law than with classical engineering. >> Everyone will have an opinion on this, but I think it is partly because >> nature is a tougher critic on human built structures than humans are on >> each other's opinions, and part of the impact of this is amplified by the >> simpler shorter term liabilities of imperfect structures on human safety >> than on imperfect laws (one could argue that the latter are much more of a >> disaster in the long run). >> >> And, in trying to tease useful analogies from Biology, one I get is that >> the largest gap in complexity of atomic structures is the one from polymers >> to the simplest living cells. (One of my two favorite organisms is >> *Pelagibacter >> unique*, which i
Re: [fonc] Current topics
ut 300 genes (and a > tiniest whole organism still winds up with a lot of components). > > Analogies should be suspect -- both the one to the law, and the one here > should be scrutinized -- but this one harmonizes with one of Butler > Lampson's conclusions/prejudices: that you are much better off making -- > with great care -- a few kinds of relatively big modules as basic building > blocks than to have zillions of different modules being constructed by > vanilla programmers. One of my favorite examples of this was the "Beings" > master's thesis by Doug Lenat at Stanford in the 70s. And this influenced > the partial experiment we did in Etoys 15 years ago. > > There is probably a "nice size" for such modules -- large enough to both > provide and be well tended, and small enough to minimize internal disasters. > > An interesting and important design problem is to try to (a) vet this idea > in or out, and (b) if in, then what kinds of "semi-universal" modules would > be most fruitful? > > One could then contemplate trying -- inducing -- to get most programmers > to program in terms of these modules (they would be the components of an > IDE for commerce, etc., instead of the raw programming components of > today). This tack would almost certainly also help the mess the law is in > going forward ... > > Note that desires for runable specifications, etc., could be quite > harmonious with a viable module scheme that has great systems integrity. > > Cheers, > > Alan > > > > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] photography and programming
We seem to have changed subjects:)
Fine then! If you can make the same camera, or a better one using less lenses,
you win.
I'm a fan of the Hasselblad design. The detachable back end opens up a lot of
possibilities. One possibility is to take test shots with the Polaroid back
end, for e.g. a quick lighting test before moving on to the expensive film that
goes into the standard back, wherein you can't even see what you've shot until
you've developed it, which necessarily can't happen until after the shoot.
Here's why this is on topic: if we can make a camera that's completely
understandable by a single individual, but can't shoot anything but black and
white (bear with me, I'm playing with words and concepts a bit) because
development of color photos takes too long to be practical, with a design
analogous to a Hasselblad, we can just swap out the back and end up with the
FONC idea that optimizations can be kept separate from meaning and the math of
the meaning in a modular way, and...
Now I'm going to do something which is arguably a bit mean: for as many lenses
as your SLR eschews, is it easier for you to explain concretely to a novice
(for example, a small child) what your SLR does than it is for me to explain
how my Hasselblad works?
I have a feeling that explaining the actual optical chip is going to be
something that's very difficult. Probably, if I tried to teach a kid how a
camera works, my victim would have a working camera years before yours would
have a real chip that could recognize a single pixel, and my game is mostly
made out of a small hole in a milk carton.
For all of humankind doing decades of this stuff, I really wish it was the
other way around. You should let me play with your SLR sometime:) but I'd
honestly rather die developing film in a poorly ventilated darkroom than shoot
with a camera that I am neither able, nor allowed to, understand.
Does that make sense?
Casey
P.S.
This is one of the better metaphors that I've seen on the list. Awesome!
On Dec 5, 2012, at 10:21 AM, Randy MacDonald wrote:
> If you can span the same space with fewer tools, that is good. If you need
> >1 lens to cover all subjects, so be it. It sounds like it is a problem of
> fit, not something independent of the problem space. No need to discuss the
> benefits of SLR's, that is just stretching the analogy.
>
>
>
> On 12/4/2012 10:16 PM, John Carlson wrote:
>> Wouldn't it be best to make programming a bit like single lens photography
>> instead of dual (or triple) lens photography? It would seem like the fewer
>> lenses you use, the less likely it would be for one of them to be scratched.
>> Unless somehow there was a compensating factor in the lenses.
>>
>> My 2 bits. Metaphor isn't quite right, but perhaps you see my point.
>>
>> Where's my post-mature optimization?
>>
>> John "Damn the torpedos, we're going full speed ahead and getting nowhere"
>> Carlson
>>
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>>
>
>
> --
> ---
> |\/| Randy A MacDonald | If the string is too tight, it will snap
> |\\| array...@ns.sympatico.ca| If it is too loose, it won't play...
> BSc(Math) UNBF '83 | APL: If you can say it, it's done.
> Natural Born APL'er | I use Real J
> Experimental webserver
> <-NTP>{ gnat }-
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Obviously Kogge-Stone
Oh, I was mostly fishing to see if anyone was doing anything fun with hardware description. The present time sees a bigger trade between performance and power consumption, but that's all in the realm of optimization. A mentor of mine in the software world once said something to me to the effect of "Don't look under the ISA, you don't want to see what's down there." Of course, that only encouraged me to look. After having done so, I'm seeing a lot of the same stuff there that motivated FONC. Cruft built up over generations of deadlines and back compat, etc. I'm pretty sure one could really put the STEPS treatment to hardware design, but there's a catch. If you wanted to run Frank over a machine designed to be understandable (rather than fast and compatible) and Frank hadn't seen anything more in the way of optimization than what the researchers working on it had to overcome with optimizations in order to complete their research, one might end up with a whole system too slow to experiment with. That's conjecture (obviously) given that I don't have Frank to play out over my FPGA rig, but I tend to trust my gut. Hence the post:) So I got to thinking, while I was doing my little armchair exploration of Verilog, what if we could declare/specify behavior with some concrete algebra, and (I know, I know, I added an "and") find a way to do optimization in an automated way. Thought experiment: what if I designed a behavior-specifying language, which could be reduced to S-expressions, and then tried to find a set of fitness functions around performance? Would it be possible to converge on a performance goal by ripping off nature? If it was possible, how much compute would I need to converge on an acceptable solution? Probably crazy expensive compute because I'm doing two things that don't want to sleep in the same room... verifying correctness (think a lot of tests in some test language) and optimization (convergence on some set of perf metrics.) Not just gen algs but gen programming. This popped into my head after thumbing through this thing: http://www.amazon.com/gp/aw/d/0262111888 Of course, I'm skeptical (of both the content of that book and of my own crazy ideas!) While a performance metric (in some continuum of flops and watts) *does* seem like something GP might be able to optimize, correctness *absolutely* does not. Hence the question about language. Has anyone here read that? I'm quite sure I haven't understood all of the content, and with as obscure as it seems to be, it could be full of bunk. Of course, with regard to obscurity, one might say the same thing of other stuff folks around here know, understand well, and love. I could go into specific ideas I've had, but I won't, because I haven't really a framework for vetting them. Instead, I'm going to ship the Wouldn't It Be Cool If and let the good people of the list slaughter my little thought experiment with the raw unrelenting debunking power of a group of people who like science. Bonus points if anyone can name the Dylan song title that I spoofed for the thread, but that's way OT so please reply direct! Casey On Nov 30, 2012, at 3:35 PM, David Barbour wrote: > Could you clarify what you're thinking about? Is your question about > metaprogramming of Verilog (with an implicit assumption that Verilog will > save battery life)? > > I've spent much time thinking about language and protocol design to extend > battery resources. I happen to think the real wins are at higher levels - > avoiding unnecessary work, amortizing work over time, linear logics, graceful > degradation of services based on power access. > > (Questions about power and energy were common in survivable networking > courses.) > > Low level power saving is a common aspect of mobile computer architecture > design. But it's hard to push fundamentally better hardware designs without > an existing body of software that easily fits it. > On Nov 30, 2012 2:06 PM, "Casey Ransberger" wrote: > Since I'm running out of battery, and my adder is starting to go oh so > slowly, I thought I might challenge the lovely people of the list to make it > stop draining my battery so quickly. > > :D > > My first challenge idea was for someone to make it stop raining in Seattle, > but I realized that I was asking a lot with that. > > Verilog would be cool, but better if you're translating whatcha got to > Verilog with OMeta, and you've come up with some randomly pretty language for > wires! > > Come on, someone else has to be thinking about this;) > > -- > Casey Ransberger > > ___ > fonc mailing list > fonc@vpri.o
[fonc] Obviously Kogge-Stone
Since I'm running out of battery, and my adder is starting to go oh so slowly, I thought I might challenge the lovely people of the list to make it stop draining my battery so quickly. :D My first challenge idea was for someone to make it stop raining in Seattle, but I realized that I was asking a lot with that. Verilog would be cool, but better if you're translating whatcha got to Verilog with OMeta, and you've come up with some randomly pretty language for wires! Come on, someone else has to be thinking about this;) -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Not just clear of mind
I like a nice Benedict with a mimosa on a Saturday brunch, but lots of my friends in Seattle think it's gross and/or immoral that I eat chicken eggs and pig meat (actually I've quit the pig part, so I don't get the Bennie anymore.) I think kids do need some guidance, but the things they're really going to glom onto are the things they figure out that they like all on their own. So: why not take the kid to brunch and get it a Benedict, then, instead of being focused on stopping it from having ice cream? If she likes the Benedict, win. If not, try something else. Bonus points for getting something other than a Benedict for yourself and letting her pick off your plate in the event that the Benedict doesn't suit her fancy. In programming: a buffet of language choices is probably a good plan in general. Most programmers have seen C and something comparable to Perl. Everyone on this list knows that there are more than two ideas. Keeping the stuff in the buffet healthy is key, you're right. But young people, more so than anyone else, desire the freedom to choose. I'd suggest that the real dodge is to give them a long list of healthy things to choose from. Okay, it's 7:13am and now I'm gonna eat some ice cream, crack a beer open, listen to 50 Cent, and do some crimes. When I get back though, Bach is ON. ;) On Mon, Oct 1, 2012 at 9:24 AM, John Pratt wrote: > Children will eat ice cream for breakfast if you don't stop them. > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] success building maru in maru - a bunch of bugs I had to fix to make it happen
Inline! On Aug 19, 2012, at 3:47 PM, Ian Piumarta wrote: > Hi Shawn, > >> My starting point was the published sources for Maru 2.1 here: >> http://piumarta.com/software/maru > > Thanks for posting this. > > Your issues with %typecheck, and were due to generating the > evaluator with %define-accessors set to %define-safe-accessors in boot.l. > Setting %define-accessors to %define-unsafe-accessors fixes them. Yes, playing it safe ends up in the middle of the road, which isn't safe at all. > Your other observations arising from bit rot were spot-on and I've updated > the sources and made a maru-2.2 tarball that can generate a working evaluator > from emit.l and eval.l. I took the liberty of writing subr_read from > scratch, to match the one in eval.c, and updated various other things to > better match the current features. Fantastic! Maru is really lovely and new bits are awesomesauce. > Although 'make test' and 'make test2' are working again, the languages > implemented by eval.c and eval.l are slightly different due to development in > the former that has not been carried forward into the latter. That's funny and fascinating. The bootstrap is not evolving alongside the bootstrapped thing. What's funny is that it can still bootstrap, and is still metacircular, while the prototype sits around collecting dust. It's kind of like the smoldering mess that's left after a rocket leaves for the moon. Good work! > Regards, > Ian I'm really pleased to see that Maru still lives. No BCPL clone? Is Maru "it" at this point? Feel free of course to decline to comment on this paragraph until the time is right. P.S. You mentioned something about a generation scavenging GC for it, did you do that? 'Cause if you did we might have a the roots of a fast (enough) Lisp that's purer than Scheme. 'Scuse the French, but holy shit. --Casey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Fundamentals Of New Guitar (was Re: Alan Kay in the news [german])
(top post) Forgive me if I'm keeping us off topic here, but I like music too:) Here's my excuse: working on doing an assembler (using Ian's peg/leg) and emulator for an expanded TinyComputer which I plan to use in a programming game. *cough* My dad had his hands smashed several times while working. Kind of a lousy coincidence. The doctors told him that he'd never play guitar again a couple times, but he kept at it. He learned to retune his guitar to make certain chords (e.g., the A-shaped barre) which were extremely painful for him to play playable again, and in the process, he expanded his ability by leaps and bounds. He rarely plays in standard tuning anymore, because he can make much more interesting music using open and hybrid tunings. I think in at least one sense his misfortune was my great fortune, because I was exposed early on to an instrument which was not assumed to be fixed, but almost infinitely malleable. There's nothing quite like the sound of a Dm played as a twelve string harmonic, something that just can't be done at all in standard without extra arms. The only thing I could bend further than that guitar was the computer. Makes me think maybe the reason I got into programming languages themselves might have had something to do with the way my dad talked about music. Long story short, I was mugged a few weeks ago, and lost a chunk of my right palm in the process; I was out of commission for a little while but it seems that there was no actual skeletal, neural, or muscular damage, just a really deep flesh wound. I'm lucky and still playing with the band. I was maybe a little bit stupid, because I refused to stop practicing, even when the wound was infected. I've been playing bass with the band because I wanted to grow and I tend to do the same stuff over and over on the guitar. I just slapped some gauze on it, wrapped it tight with tape, took an aspirin and played with a pick for a month until it had healed sufficiently. Here's to finding new expressiveness in the face of adversity! --Casey On Thu, Jul 19, 2012 at 6:16 PM, Alan Kay wrote: > Hi John > > Sorry to hear about your nerve problems. > > I got a variety of books to get started -- including Anton Shearer's and > Christopher Parkening's. > > Then I started corresponding with a fabulous and wonderfully expressive > player in the Netherlands I found on YouTube-- Enno Voorhorst > Check out: http://www.youtube.com/watch?v=viVl-G4lFQ4 > > I like his approach very much -- part of it is that he started out as a > violin player, and still does a fair amount of playing in string quartets, > etc. You can hear that his approach to tremolo playing is that of a solo > timbre rather than an effect. > > And some of the violin ideas of little to no support for the left hand do > work well on classical guitar. But many of the barres (especially the > hinged ones) do require some thumb support. What has been interesting about > this process is to find out how much of the basic classical guitar > technique is quite different from steel string jazz chops -- it's taken a > while to unlearn some "spinal reflexes" that were developed a lifetime ago. > > Cheers, > > Alan > > -- > *From:* John Zabroski > > *To:* Alan Kay ; Fundamentals of New Computing < > fonc@vpri.org> > *Sent:* Thursday, July 19, 2012 5:40 PM > > *Subject:* Re: [fonc] Alan Kay in the news [german] > > > > On Wed, Jul 18, 2012 at 2:01 PM, Alan Kay wrote: > > Hi Long, > > I can keep my elbows into my body typing on a laptop. My problem is that I > can't reach out further for more than a few seconds without a fair amount > of pain from all the ligament tendon and rotator cuff damage along that > axis. If I get that close to the keys on an organ I still have trouble > reaching the other keyboards and my feet are too far forward to play the > pedals. Similar geometry with the piano, plus the reaches on the much wider > keyboard are too far on the right side. Also at my age there are some lower > back problems from trying to lean in at a low angle -- this doesn't work. > > But, after a few months I realized I could go back to guitar playing > (which I did a lot 50 years ago) because you can play guitar with your > right elbow in. After a few years of getting some jazz technique back and > playing in some groups in New England in the summers, I missed the > polyphonic classical music and wound up starting to learn classical guitar > a little over a year ago. This has proved to be quite a challenge -- much > more difficult than I imagined it would be -- and there was much less > transfer from jazz/steel string technique that I would have thought. It not > only feels very different physically, but also mentally, and has many extra > dimensions of nuance and color that is both its charm, and also makes it > quite a separate learning experience. > > Cheers, > > Alan > > > > Hey Alan, > > That's awesome that you are learning classical guitar. Are you usin
[fonc] Publish/subscribe vs. send
Here's the real naive question... I'm fuzzy about why objects should receive messages but not send them. I think I can see the mechanics of how it might work, I just don't grok why it's important. What motivates? Are we trying to eliminate the overhead of ST-style message passing? Is publish/subscribe easier to understand? Does it lead to simpler artifacts? Looser coupling? Does it simplify matters of concurrency? I feel like I'm still missing a pretty important concept, but I have a feeling that once I've grabbed at it, several things might suddenly fit and make sense. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [cross-post] X-Prize guy announces interest in education reform at SXSW, wants ideas
And I forgot the link. Naturally :/ http://www.forbes.com/sites/georgeanders/2012/03/11/x-prize-founder-seeks-ideas-to-fix-education/ On Mon, Mar 12, 2012 at 11:53 AM, Casey Ransberger wrote: > Figured this was broadly applicable enough for a cross-post. Also left a > note at the Scratch site. They're talking about bringing someone > experienced on to tackle some of the bigger (read: social) challenges > around education reform, and they also seem to be looking for some kind of > "killer app." > > Has anyone got a killer app lying around for education that mostly just > needs some very large carrot dangled and a whole lot of love to see > implemented in schools? > > -- > Casey Ransberger > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] [cross-post] X-Prize guy announces interest in education reform at SXSW, wants ideas
Figured this was broadly applicable enough for a cross-post. Also left a note at the Scratch site. They're talking about bringing someone experienced on to tackle some of the bigger (read: social) challenges around education reform, and they also seem to be looking for some kind of "killer app." Has anyone got a killer app lying around for education that mostly just needs some very large carrot dangled and a whole lot of love to see implemented in schools? -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] How Books Work (was: something about ebooks)
Here's a book. You read it. Do you know how it works? Of course. Lots of people, most people know how your book works. Can you tell me everything about how a Kindle works? If it stopped working, would you know how to fix it? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] OT: Hypertext and the e-book
Below. On Mar 7, 2012, at 3:13 PM, BGB wrote: > thoughts: > admittedly, I am not really much of a person for reading fiction (I tend > mostly to read technical information, and most fictional material is more > often experienced in the form of movies/TV/games/...). > > I did find the article interesting though. > > I wonder: why really do some people have such a thing for traditional books? > > they are generally inconvenient, can't be readily accessed: > they have to be physically present; > one may have to go physically retrieve them; > it is not possible to readily access their information (searching is a pain); > ... Books? First, the smell. Especially old books. I have a friend who has a Kindle. It smells *nothing* like a library, and I do think something is lost there. It's also, ironically, the weight of them. The sense of holding something *real* that in turn holds information. When you move, it takes work to keep a book, so one tends to keep the most "important" books one has, whereas with digital we just keep whatever we have "rights" to read, because there's no real expense in keeping. We also can't really share, at least not yet. Not in any legal model. Second: when I finish a book, I usually give it away to someone else who'd enjoy it. Unless I've missed a headline, I can't do this with ebooks any more readily than that dubstep-blackmetal-rap album we still need to record when I buy it on iTunes (or whatever.) ;) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
Inline. On Thu, Mar 1, 2012 at 2:56 PM, Loup Vaillant wrote: > Le 01/03/2012 22:58, Casey Ransberger a écrit : > > Below. >> >> On Feb 29, 2012, at 5:43 AM, Loup Vaillant wrote: >> >> Yes, I'm aware of that limitation. I have the feeling however that >>> IDEs and debuggers are overrated. >>> >> >> When I'm Squeaking, sometimes I find myself modeling classes with the >> browser but leaving method bodies to 'self break' and then write all of the >> actual code in the debugger. Doesn't work so well for hacking on the GUI, >> but, well. >> > > Okay I take it back. Your use case sounds positively awesome. It's fun:) > I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' >> Seems odd. Most people I've encountered who don't use the debugger haven't >> learned one yet. >> > > > Spot on. The only debugger I have used up until now was a semi-broken > version of gdb (it tended to miss stack frames). Oh, ouch. Missed frames. I hate it when things are ill-framed. I can't say I blame you. GDB is very *NIXy. Not really very friendly to newcomers. Crack open a Squeak image and break something. It's a whole different experience. "Where is this nil value coming from?" is a question that I can answer more easily in a ST-80 debugger than I can in any other that I've tried (exception of maybe Self.) The button UI on the thing could probably use a bit of modern design love (I'm sure I'm going to be trampled for saying so!) but otherwise I think it's a great study for what the baseline debugging experience ought to be for a HLL (why deal with less awesome when there's more awesome available under the MIT license as a model to work from?) Of course, I'm saying *baseline.* Which is to say that we can probably go a whole lot further with these things in the future. I'm still waiting on that magical OmniDebugger that Alessandro Warth mentioned would be able to deal with multiple OMeta-implemented languages;) Loup. > __**_ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sorting the WWW mess
On Thu, Mar 1, 2012 at 7:04 AM, Alan Kay wrote: > Hi Loup > > > > However, Ted Nelson said a lot in each of the last 5 decades about what > kinds of linking do the most good. (Chase down what he has to say about why > one-way links are not what should be done.) He advocated from the beginning > that the "provenance" of links must be preserved (which also means that you > cannot copy what is being pointed to without also copying its provenance). > This allows a much better way to deal with all manner of usage, embeddings, > etc. -- including both fair use and also various forms of micropayments and > subscriptions. > If only we could find a way to finally deal with all that intertwingularity! > One way to handle this requirement is via protection mechanisms that "real > objects" can supply. > > Cheers, > > Alan > > -- > *From:* Loup Vaillant > *To:* fonc@vpri.org > *Sent:* Thursday, March 1, 2012 6:36 AM > *Subject:* Re: [fonc] Sorting the WWW mess > > Martin Baldan wrote: > > That said, I don't see why you have an issue with search engines and > > search services. Even on your own machine, searching files with complex > > properties is far from trivial. When outside, untrusted sources are > > involved, you need someone to tell you what is relevant, what is not, > > who is lying, and so on. Google got to dominate that niche for the right > > reasons, namely, being much better than the competition. > > I wasn't clear. Actually, I didn't want to state my opinion. I can't > find the message, but I (incorrectly?) remembered Alan saying that > one-way links basically created the need for big search engines. As I > couldn't imagine an architecture that could do away with centralized > search engines, I wanted to ask about it. > > That said, I do have issues with Big Data search engines: they are > centralized. That alone gives them more power than I'd like them to > have. If we could remove the centralization while keeping the good > stuff (namely, finding things), that would be really cool. > > Loup. > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
Below. On Feb 29, 2012, at 5:43 AM, Loup Vaillant wrote: > Yes, I'm aware of that limitation. I have the feeling however that > IDEs and debuggers are overrated. When I'm Squeaking, sometimes I find myself modeling classes with the browser but leaving method bodies to 'self break' and then write all of the actual code in the debugger. Doesn't work so well for hacking on the GUI, but, well. I'm curious about 'debuggers are overrated' and 'you shouldn't need one.' Seems odd. Most people I've encountered who don't use the debugger haven't learned one yet. At one company (I'd love to tell you which but I signed a non-disparagement agreement) when I asked why the standard dev build of the product didn't include the debugger module, I was told "you don't need it." When I went to install it, I was told not to. I don't work there any more... ___ 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?
There's always http://en.wikipedia.org/wiki/Actor_model and http://www.dalnefre.com/wp/humus/ ...which seem to make concurrency less of a PITA. Like most languages that crystalize a particular style, though, there's some learning involved for folks (like me!) who hadn't really thought about the actor model in a deep way. On Sun, Feb 12, 2012 at 9:15 AM, Steve Wart wrote: > Simplicity, like productivity, is an engineering metric that can only be > measured in the context of a particular application. Most successful > programming languages aren't "mathematically pure" but some make it easier > than others to use functional idioms (by which I mean some mechanism to > emulate the types of operations you describe below). However many problems > are simpler to solve without such abstractions. That's why "practical > languages" like Smalltalk-80 and Lisp and their mainstream derivatives have > succeeded over their more pure counterparts. > > I think I responded to this message because I was sick in bed yesterday > reading the intro paragraphs of The Algorithmic Beauty of Plants yesterday ( > http://algorithmicbotany.org/papers/#abop), and shared the introduction > of DOL-systems with my son. We both enjoyed it, but I'm not sure how this > translates into reasoning about distributed systems. > > 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. > > 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. > > HTTP seems to have avoided this by using MIME types, but this is more > about agreed upon engineering standards rather than computational > abstractions. > > Cheers, > Steve > > > On Sun, Feb 12, 2012 at 4:02 AM, Jakob Praher wrote: > >> We would have to define what you mean by the term computation. >> Computation is a way to transform a language "syntactically" by defined >> rules. >> The lambda calculus is a fundamental way of performing such >> transformation via reduction rules (the alpha, beta, gamma rules). >> >> In the end the beta-reduction is term substitution. But abstraction and >> substitution in a generic purpose von Neumann-style computer has to be >> modelled accordingly: A variable in the computer is a memory location/a >> register that can be updated (but it is not a 1:1 correspondence). E.g. A >> function in a computer is jump to a certain code location having to write >> to certain locations in memory/registers to get the arguments passed. >> >> IMHO the computational model of objects and method dispatch is more of a >> black box / communcation-oriented model. One does not know much about the >> destination and dispatchs a message interpreting the result. In functional >> languages the model is more white boxed. One can always decompose a term >> into subterms and interpret it. Therefore functional languages do not grow >> easily to distributed programming, where the knowledge over the terms is >> limited. >> >> Best, >> Jakob >> >> > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Mitsubishi Luggage Tag, third try
Awesome:) On Feb 8, 2012, at 8:51 AM, Alan Kay wrote: > Cheers, > > Alan > > ___ > 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?!
Below and mile off-topic... On Jan 22, 2012, at 4:11 PM, Julian Leviston wrote: > > 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 Julian, Generally good points but I'm pretty sure the Korn I've heard wasn't dubstep. It's also crap. T.M. :D ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] One more year?!
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
Re: [fonc] One more year?!
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! ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] One more year?!
Below. On Jan 20, 2012, at 5:52 PM, Reuben Thomas wrote: > I have just skimmed VPRI's 2011 report; lots of interesting stuff > there. The ironies of a working system that the rest of us can only > view in snapshot form grow ever-stronger: the constant references to > active documents are infuriating. The audience would like to see the > active document, but instead we only get a printout. It's as if, > waiting for a new film, we got only reviews of trailers rather than > the trailers themselves. > > The irony is then compounded by a code listing at the end of the > document (hint: a URL is shorter and actually useful; this is not the > 1980s). > > And then just when we thought it was going to end, the agony > continues: you've pushed the deadline back a year. > > I wish you all a joyful and productive 2012; unlike many projects, > it's clear that with this one the question is not whether what is > finally released will be worth the wait, it's whether it'll ever > actually be released. > > You do shoot yourselves in the foot at one point: "The Web should have > used HyperCard as its model, and the web designers made a terrible > mistake by not doing so." Yes, but the web shipped and revolutionised > the world; meanwhile, you lot have shipped stuff that, at best, like > Smalltalk, has inspired revolutions at one remove. Many of the lessons > of your work are decades old and still not widely learned. Contrast > with Steve Jobs, who spun an ounce of invention into a mile of > innovation, by combining a desire for better computing with the > understanding that without taking people with you, your ideas will die > with you. It's a shame and an embarrassment that to the world at large > he's the gold standard. > > Please, no more deadline extensions. Whatever you have by the end of > this year will unquestionably be worth releasing, for all its > imperfections. It's high time to stop inventing the future and start > investing it. > > -- > http://rrt.sc3d.org > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc 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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Inspired 3D Worlds
Check out Ken Musgrave. He makes whole planets with fractals. It's cool. Twisting knobs is a lot less work than manual 3D modeling and such. http://www.amazon.com/gp/aw/d/1558608486 On Jan 16, 2012, at 7: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
Re: [fonc] Inspired 3D Worlds
Top post. Heightmapping can go a really long way. Probably not news though:) 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 with > code and using libraries of procedures. Code can sometimes be simplified by > having it read a simple map or image. > > Remember, the basic role of programming is to automate that which bores you. > > Regards, > > Dave > > > On Sun, Jan 15, 2012 at 4:18 PM, BGB wrote: > I am generally personally stuck on the issue of how to make "interesting" 3D > worlds for a game-style project while lacking in both personal creativity and > either artistic skill or a team of artists to do it (creating decent-looking > 3D worlds generally requires a fair amount of effort, and is in-fact I > suspect somewhat bigger than the effort required to make a "passable" 3D > model of an object in a 3D modeling app, since at least generally the model > is smaller and well-defined). > > it seems some that creativity (or what little of it exists) is stifled by it > requiring a large amount of effort (all at once) for the activity needed to > express said creativity (vs things which are either easy to do all at once, > or can be easily decomposed into lots of incremental activities spread over a > large period of time). > > trying to build a non-trivial scene (something which would be "passable" in a > modern 3D game) at the level of dragging around and placing/resizing/... > cubes and/or messing with individual polygon-faces in a mapper-tool is sort > of a motivation killer (one can wish for some sort of "higher level" way to > express the scene). > > meanwhile, writing code, despite (in the grand scale) requiring far more time > and effort, seems to be a lot more enjoyable (but, one can't really build a > world in code, as this is more the mapper-tool's domain). > > ___ > 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] Debugging PEGs and Packrats
Inline. Thanks for your reply! On Dec 28, 2011, at 12:20 PM, John Leuner wrote: > Hi Casey > > In my OMeta implementations I have found that simply recording the > position of the deepest error and then printing out the remaining input > text was sufficient to debug my grammars. This is something I hadn't thought of. It would tell one where the grammar choked. That's interesting. > I think the next step I would take (if that wasn't sufficient) is to > create a test suite that tests each grammar rule independently, > successively building up to the complex input that is failing. I'd been doing this for terminals, but it seems like non-terminals get harder to write as unit tests, parser state and all. I suppose integration tests could work, but it seems the more complex the grammatical structure, the more I experience diminishing returns with tests. I just end up with tests that fail mysteriously which is my original problem. Do you have any examples about? I wonder if maybe there's something essential I'm failing to understand. Maybe looking at your tests might send me along to an a-ha moment. Thanks again! > John > > > On Tue, 2011-12-13 at 23:17 -0800, Casey Ransberger wrote: >> I know this has come up before. Hopefully I'm not about to repeat a lot. >> >> Debugging this stuff just seems really hard. And significantly harder than >> what I've experienced working with e.g. Yacc. >> >> Hypothesis: Yacc had a lot of time to bake before I ever found it. PEGs are >> new, so there's been less overall experience with debugging them. >> >> I've experimented in what little time I can devote with OMeta, PetitParser, >> and Treetop. The debugging experience has been roughly consistent across all >> three. >> >> One particular issue which has bugged me: memoization seems to carry a lot >> of instance-state that's really hard to comprehend when the grammar isn't >> working as I expect. It's just really hard to use that ocean of information >> to figure out what I've done wrong. >> >> Given that with these new parsing technologies, we're pretty lucky to see >> "parse error" as an error message, I can't help but think that it's worth >> studying debugging strategies. Heh. :D I'm really not complaining, I'm just >> pointing it out. >> >> Has anyone here found any technique(s) which makes debugging a grammar >> written for a PEG/packrat less of a pain in the butt? >> >> I'd be really interested in hearing about it. >> >> >> >> ___ >> 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] FASTRA II 12TFLOPS desktop
The video is adorable! "With two FASTRAs in the room, additional heating in the winter is not necessary." CUT TO: Researcher at desk wearing a Hawaiian shirt and sunglasses. Desk has monitor, keyboard, mouse, pineapple, tropical plant. Desk is beneath yellow sun umbrella. RESEARCHER (Raises martini glass full of thick, cold-looking green stuff, sips, smiles.) On Thu, Dec 22, 2011 at 11:03 AM, Steve Dekorte wrote: > > "For just 6000 euros, you can have 12TFLOPS of computing power at your > fingertips." > > http://fastra2.ua.ac.be/ > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] History of computing talks at SJSU
That's really funny:) On Dec 16, 2011, at 7:13 PM, John Zabroski wrote: > On Fri, Dec 16, 2011 at 10:10 PM, John Zabroski > wrote: >> On Fri, Dec 16, 2011 at 10:04 PM, Jecel Assumpcao Jr. >> wrote: >>> Steve Dekorte wrote: >>> [NeXTStation memories versus reality] >>> >>> I still have a running Apple II. My slowest working PC is a 33MHz 486, >>> so I can't directly do the comparison I mentioned. But I agree we >>> shouldn't trust what we remember things feeling like. >>> >>> -- Jecel >> >> >> The Apple booting up faster was not simply a feeling, but a fact owing >> to its human-computer interaction demands. They set fast boot speeds >> as a design criteria. Jef Raskin talks about this in the book The >> Humane Interface. Even modern attempts to reduce boot speed have not >> been that good, such as "upstart", an event-driven alternative to >> "init". >> >> Eugen has some very good points about human limits of managing >> performance details, though. Modern approaches to performance are >> already moving away from such crude methods. > > By the way, slight tangent: Modern operating systems, with all their > hot-swapping requirements, do a poor job distinguishing device error > from continuously plugging-in and plugging-out the device. For > example, if you have an optical mouse and damage it, it might slowly > die and your entire system will hang because 99% of your CPU will be > handling plugin and plugout events. > > ___ > 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] History of computing talks at SJSU
Whereas my Squeak environment comes up in a second. No, it isn't an "OS," or not anymore anyway. But it pops right where I left it. The system that supports it is lucky to boot in a minute... and I can't easily prove it, but... I have this *feeling* that my OS is doing a lot durring boot to set up things I never use in a suboptimal way. And it doesn't even come up exactly where I left it. It *tries* by reopening various things and *sometimes* it works well enough that I don't notice that something is broken. Usually, though, I'm sitting there wondering why I have to spend minutes of my day waiting for the tool that I need to do my job to become available. This sucks. Rebooting at all is a PITA. That it takes minutes, I think, is just lack of forethought or designing for the wrong use case. On Dec 16, 2011, at 7:10 PM, John Zabroski wrote: > On Fri, Dec 16, 2011 at 10:04 PM, Jecel Assumpcao Jr. > wrote: >> Steve Dekorte wrote: >> >>> [NeXTStation memories versus reality] >> >> I still have a running Apple II. My slowest working PC is a 33MHz 486, >> so I can't directly do the comparison I mentioned. But I agree we >> shouldn't trust what we remember things feeling like. >> >> -- Jecel > > > The Apple booting up faster was not simply a feeling, but a fact owing > to its human-computer interaction demands. They set fast boot speeds > as a design criteria. Jef Raskin talks about this in the book The > Humane Interface. Even modern attempts to reduce boot speed have not > been that good, such as "upstart", an event-driven alternative to > "init". > > Eugen has some very good points about human limits of managing > performance details, though. Modern approaches to performance are > already moving away from such crude methods. > > ___ > 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] History of computing talks at SJSU
Below. On Dec 16, 2011, at 9:03 PM, Wesley Smith wrote: >> Some things are just expensive. No one has found an acceptable solution. >> These are things we should avoid in the infrastructure underneath a personal >> computing experience:) > > > Or figure out how to amortize them over time. I think recent > raytracing apps are a good example of this. You can preview the image > as it is rendered to see if it's just right and if not, tweak it. > Another example is scraping data to build a database that will inform > autocompletion and other productivity enhancing UI effects. Sometimes > gather and parsing out the data to put in the database can be > expensive, but it can easily be done in a background thread without > any cost to responsiveness. I'm sure there are plenty of other > examples. > > wes Totally. Look for new ways to make expensive things cheap. Look for ways to turn NP-complete linear! And never ever stop trying. Just don't put factorial complexity in my email client if you can avoid it:);):P > ___ > 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] History of computing talks at SJSU
Below. On Dec 16, 2011, at 3:19 PM, Alan Kay wrote: > And what Engelbart was upset about was that the "hands out -- hands together" > style did not survive. The "hands out" had one hand with the 5 finger > keyboard and the other with the mouse and 3 buttons -- this allowed > navigation and all commands and typing to be done really efficiently compared > to today. "Hands together" on the regular keyboard only happened when you had > bulk typing to do. Are you talking about the so-called "chording keyboard?" I had an idea years ago to have a pair of "twiddlers" (the one chording keyboard I'd seen was called a twiddler) which tracked movement of both hands over the desktop, basically giving you two pointing devices and a keyboarding solution at the same time. Now it's all trackpads and touch screens, and my idea seems almost Victorian:) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] History of computing talks at SJSU
Below. Abridged. On Dec 16, 2011, at 1:42 PM, Steve Dekorte wrote: > > FWIW, in my memory, my old NeXTstation felt as snappy as modern desktops but > when I ran across one at the Computer History Museum it felt painfully slow. > I've had similar experiences with seeing old video games and finding the > quality of the graphics to be much lower than I remembered. > > This is just a guess, but I suspect what we remember is strongly influenced > by our emotional reactions which in turn are shaped by our expectations. At > the time, my expectations were lower. This is an excellent point. At work I'm using a 32-bit single core machine that's 0.6ghz slower than my personal 64-bit dual core machine. Once in awhile, I notice that it's slower. I have a feeling, though, that this is a consequence of slower hardware *compounded* by expensive software, because most of the time, I can't tell the difference at all. What I'm saying is in part that the computational power of modern computers typically eclipses my personal need for computing power. When things are suddenly slow, I suspect algorithm/datastructure. Whereas: it used to be that everything seemed to take a long time. Some things are just expensive. No one has found an acceptable solution. These are things we should avoid in the infrastructure underneath a personal computing experience:) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] History of computing talks at SJSU
Inline below. On Dec 15, 2011, at 2:31 AM, Juan Vuletich wrote: > frank wrote: >> On 12/15/2011 08:02 AM, Casey Ransberger wrote: >> >>> Hypothesis: Mainstream software slows down at a rate slightly less than >>> mainstream hardware speeds up. >>> >> >> Hmmm, seems like a more optimistic Version of Wirth's law (yes, Niklaus): >> "Software is getting slower more rapidly than hardware becomes faster." >> >> Frank >> > > There's also Nathan Myhrvold's four Laws of Software: ( > http://www.codinghorror.com/blog/2006/09/software-its-a-gas.html , > http://blogs.msdn.com/b/larryosterman/archive/2005/06/17/430215.aspx ). > 1) Software is a gas: Software always expands to fit whatever container it is > stored in. Good metaphor. Melikes. > 2) Software grows until it becomes limited by Moore's Law: The initial growth > of software is rapid, like gas expanding, but is inevitably limited by the > rate of increase in hardware speed. Too true! > 3) Software growth makes Moore's Law possible: People buy new hardware > because the software requires it. Funny, but I think Moore's Law happens because around every 18 months, a large enough contingent of people want to buy a computer that's orders of magnitude faster / has orders of magnitude more storage/memory and faster network more pixels etc blah, blah, blah than what they've been getting on with for a number of years. > 4) Software is only limited by human ambition and expectation: We'll always > find new algorithms, new applications, and new users. It kind of seems like this one should actually help. I think what's really happening is: every programmer rediscovers the same algorithm and codes it up, not knowing that it's already in the standard library, because the standard library is so big that no one wants to read it. > These are interesting for several reasons. One is that Nathan doesn't only > describe the phenomena, but also a possible explanation for it. Which makes his arguments fun! > Besides, now that it seems Moore's Law doesn't hold anymore, what will happen? I'm not buying it. The economy just sucks. Give it a couple of holiday seasons, ARM and Intel will find a way again to sell me a computer that's twice as fast as the one I bought a year and a half ago;) > Will software bloat end? Will we focus again in efficiency and simplicity? > Will this make projects like FONC and Cuis relevant to mainstream? One thing that's clear: people are really into little portable gadgets right now. So the shift happened: it's not about how many volts you can push through some silicon without melting it right now, it's about how much you can get done with as little electricity as possible. FWIW, I think this shift is why we aren't seeing performance-doubling. I think we're seeing market focus on battery-life-doubling instead. When I really think about it, these are two sides of the same coin. Which is why I still doubt that Moore was wrong... > WRT law 3), we already see the change. Some years ago, computers were > advertised only in terms of speed. Now they make people want new, slower > computers (iPads and such). Regular PCs, even if much faster, are not "fancy" > anymore. Depends on market segment. I want a cheap slow (you know, fast, like my old Mac, not slow like that fast AMD thing and Windows, that's just too slow) computer that has a battery that lasts for days but still lets me program like I could on my desktop (nope, Android, this isn't you. Don't want language hurdles. Just let me compile what I want.) "Devil's Advocate" but I'm mostly with ya:) > 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
Re: [fonc] History of computing talks at SJSU
The article on Wikipedia about Parkinson's law mentions Wirth's law. Bucket of win! I think we're onto something, ladies and gentleman. I'll be in town all week: try the fish. On Dec 15, 2011, at 12:42 AM, frank wrote: > On 12/15/2011 08:02 AM, Casey Ransberger wrote: >> Hypothesis: Mainstream software slows down at a rate slightly less than >> mainstream hardware speeds up. > > Hmmm, seems like a more optimistic Version of Wirth's law (yes, Niklaus): > "Software is getting slower more rapidly than hardware becomes faster." > > Frank > > > ___ > 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] History of computing talks at SJSU
Below. On Dec 14, 2011, at 11:14 PM, David Barbour wrote: > Hypothesis: Mainstream software slows down at a rate slightly less than > mainstream hardware speeds up. It's an almost-but-not-quite-inverse Moore's > Law. > > Unless someone else has called this out directly, I'm calling it Joe's Law, > because I don't want to deal with the backlash! > > It's a variation on Parkinson's Law. Haha! I knew if there was prior art, someone here would set me straight. I'd *never* heard of this but it's s true for so many things. Mass corollaries! Thank you so much for putting me onto such a succinct statement of so broadly applicable a truism! (Seriously this is great. Forwarding link to almost everyone I know...)___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] History of computing talks at SJSU
Inline and greatly abridged. On Dec 14, 2011, at 5:09 PM, "Jecel Assumpcao Jr." wrote: > About Joss, we normally like to plot computer improvement on a log > scale. But if you look at it on a linear scale, you see that many years > go by initially where we don't see any change. So the relative > improvement in five years is more or less the same no matter what five > years you pick, but the absolute improvement is very different. When I > needed a "serious" computer for software development back in 1985 I > built an Apple II clone for myself, even though that machine was already > 8 years old at the time (about five Moore cycles). That's just so cool. Someday I want to make an Apple IIgs clone because that thing rocked and the emulator I have is dog-slow:/ but we've talked about that before! > The state of the art > in personal computers at the time was the IBM PC AT (6MHz iAPX286) which > was indeed a few times faster than the Apple II, but not enough to make > a qualitative difference for me. If I compare a 1992 PC with one from > 2000, the difference is far more important to me. Okay so this is where stuff gets funny to me. My computer, if you look at the clock and the cores, is blazing fast. You can see it once in awhile: when doing something graphically intensive (the GPU is also really fast) or something straightforwardly computationally expensive, like compiling C code with all of the optimizations on. But in general... my computer is only a tiny bit faster than the one I had in the early nineties. In terms of day to day stuff, it's only gotten a tinsy bit faster. Sometimes I sit there looking at an hourglass or a beach ball and think to myself "this only used to happen when I was waiting on a disk to spin about. There isn't even a disk in this thing. What the hell?" Hypothesis: Mainstream software slows down at a rate slightly less than mainstream hardware speeds up. It's an almost-but-not-quite-inverse Moore's Law. Unless someone else has called this out directly, I'm calling it Joe's Law, because I don't want to deal with the backlash! > Cheers, > -- Jecel > > > ___ > 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] Debugging PEGs and Packrats
I overlooked the IDE completely. I'll check it out as soon as I can. Thanks for the pointer:) On Dec 14, 2011, at 12:35 AM, Lukas Renggli wrote: >> I've experimented in what little time I can devote with OMeta, PetitParser, >> and Treetop. The debugging experience has been roughly consistent across all >> three. > > Casey, did you try the PetitParser IDE? If so, what did you miss? > > If not, please check it out > (http://jenkins.lukas-renggli.ch/job/PetitParser/lastSuccessfulBuild/artifact/PetitParser-OneClick.zip). > It comes with dedicated tools for grammars (editor, visualizations, > profiler, debugger, ...). An earlier version of the tool is described > in Section 3.5 of this paper > (http://scg.unibe.ch/archive/papers/Reng10cDynamicGrammars.pdf). We > are currently working on an improved IDE with grammar refactorings. > > Lukas > >> >> One particular issue which has bugged me: memoization seems to carry a lot >> of instance-state that's really hard to comprehend when the grammar isn't >> working as I expect. It's just really hard to use that ocean of information >> to figure out what I've done wrong. >> >> Given that with these new parsing technologies, we're pretty lucky to see >> "parse error" as an error message, I can't help but think that it's worth >> studying debugging strategies. Heh. :D I'm really not complaining, I'm just >> pointing it out. >> >> Has anyone here found any technique(s) which makes debugging a grammar >> written for a PEG/packrat less of a pain in the butt? >> >> I'd be really interested in hearing about it. >> >> >> >> ___ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > ___ > 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] Debugging PEGs and Packrats
I know this has come up before. Hopefully I'm not about to repeat a lot. Debugging this stuff just seems really hard. And significantly harder than what I've experienced working with e.g. Yacc. Hypothesis: Yacc had a lot of time to bake before I ever found it. PEGs are new, so there's been less overall experience with debugging them. I've experimented in what little time I can devote with OMeta, PetitParser, and Treetop. The debugging experience has been roughly consistent across all three. One particular issue which has bugged me: memoization seems to carry a lot of instance-state that's really hard to comprehend when the grammar isn't working as I expect. It's just really hard to use that ocean of information to figure out what I've done wrong. Given that with these new parsing technologies, we're pretty lucky to see "parse error" as an error message, I can't help but think that it's worth studying debugging strategies. Heh. :D I'm really not complaining, I'm just pointing it out. Has anyone here found any technique(s) which makes debugging a grammar written for a PEG/packrat less of a pain in the butt? I'd be really interested in hearing about it. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
"+1" is a lot less noise than this whole etiquette thread.
From previous experience: listen to a song you like. Read a book that cheers
you. Just let it ride. Otherwise you'll burn much more bandwidth complaining
than was burned in the original post.
That's what happened with me anyway. I made so much noise about a post that I
didn't like that I'll spend a long time regretting my griping.
Better to live and let live.
Think about it: how many bytes have I wasted saying this? A *lot* more than
"+1."
:)
Casey
On Nov 8, 2011, at 6:54 PM, David Barbour wrote:
> On Tue, Nov 8, 2011 at 5:14 PM, Joel Healy wrote:
>
> Dave, I did not realize that you owned this topic. I wasn't even aware that
> you started this topic. If I infringed on your intellectual property rights,
> I apologize.
>
> I have offered no pretense of owning the topic, and now I feel insulted by
> your strawman apologies.
>
> I would object to someone littering in my city's streets. That doesn't
> require I own the streets, only that I use them.
>
> If nobody else had followed your example, I would have said nothing. But
> three people saying `+1` indicates a noisy, unproductive pattern that should
> be discouraged, much like spam or chain letters.
>
>
> As far as moving my comment to a new topic, that just doesn't seem reasonable
> to me. Starting a new topic with "I agree with what Sean said in another
> topic" seems to me to be a poor organizational structure.
>
> I'm not asking you to behave foolishly.
>
> Instead start another topic with a dedicated subject-line and something like:
> "Sean, in this other topic, suggests we record all VPRI outreach events.
> . I agree and would like to see what can be done to achieve
> this." If you are fishing for agreement, you could indicate "Please add your
> voice..."
>
>
> If I violated some list etiquette by expressing my opinion as +1, I do
> sincerely apologize. Perhaps my opinion is of no value. I doubt that I will
> offer any in the future, so there is no need to chastise me further.
>
> Your opinion may be valuable. But `+1` is not very valuable, at least not on
> this forum. On a mailing list `+1` is just noise, whereas community-moderated
> fora (like Stack Exchange or Slash Dot) offer some mechanism to express
> exactly this.
>
> Regards,
>
> Dave
>
>
>
> On Tue, Nov 8, 2011 at 5:32 PM, 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
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
_
Re: [fonc] new document
+1 is a low-bandwidth way to express "yes, let's explore what this person is
talking about some more because this is interesting."
If it's a problem, maybe the rule should be to place [+1] before the subject
line. But that's going to split the thread in lots of mail readers...
Especially when there's a strong polar dispute between people on squeak-dev,
this has worked really well in the short time I've been around.
One time I got in trouble for saying "+1000." I guess I'm only allowed one.
:)
Casey
On Nov 8, 2011, at 5:14 PM, Joel Healy wrote:
> I started this +1 thing. It was indeed referring to Sean's comment (that is
> why Sean's comment was quoted).
>
> I thought about this post before I made it. Normally I would not "spam" a
> thread with a "me too" comment, but in this case I thought that it was
> important to let everyone know that there are people who read this list and
> website who may not feel qualified to participate much but none the less rely
> on them as a vital source of information.
>
> Dave, I did not realize that you owned this topic. I wasn't even aware that
> you started this topic. If I infringed on your intellectual property rights,
> I apologize. As far as moving my comment to a new topic, that just doesn't
> seem reasonable to me. Starting a new topic with "I agree with what Sean
> said in another topic" seems to me to be a poor organizational structure.
>
> If I violated some list etiquette by expressing my opinion as +1, I do
> sincerely apologize. Perhaps my opinion is of no value. I doubt that I will
> offer any in the future, so there is no need to chastise me further.
>
> Regards,
>
> Joel
>
>
>
> On Tue, Nov 8, 2011 at 5:32 PM, 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
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] (eval metacircularly forever)
___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Maru: anon symbols
Sweet! Maru is really fun:) On Oct 17, 2011, at 8:26 PM, Kurt Stephens wrote: > I've been toying with maru. Added anonymous symbol (gensym) support here: > > https://github.com/kstephens/maru/tree/anon-symbol > > Rewrote the pop macro form to use gensym. > > Has anyone ported ometa to maru? If not, I might try. > > -- 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] Tension between meta-object protocol and encapsulation
Top-post: thanks for your reply. I'll check this stuff out. Somehow I missed this when you sent it. Casey On Sep 7, 2011, at 1:50 PM, David Barbour wrote: > On Wed, Sep 7, 2011 at 12:48 PM, Casey Ransberger > wrote: > It seems to me that there is tension here, forces pulling in orthogonal > directions. In systems which include a MOP, it seems as though encapsulation > is sort of hosed at will. Certainly I'm not arguing against the MOP, it's one > of the most powerful ideas in programming. For some things, it seems > absolutely necessary, but then... there's the abuse of the MOP. > > Is this tension irreconcilable? > > There are patterns for meta-object protocol that protect encapsulation (and > security). > > Gilad Bracha discusses capability-secure reflection and MOP by use of > 'Mirrors' [1][2]. The basic idea with mirrors is that the authority to > reflect on an object can be kept separate from the authority to otherwise > interact with the object - access to the MOP is not universal. > > Maude's reflective towers [3] - which I feel are better described as 'towers > of interpreters' - are also a secure basis. Any given interpreter is > constrained to the parts of the model it is interpreting. By extending the > interpreter model, developers are able to achieve ad-hoc extensions similar > to a MOP. > > These two classes of mechanisms are actually quite orthogonal, and can be > used together. For example, developers can provide frameworks or interpreters > in a library, and each interpreter 'instance' can easily export a set of > mirror capabilities (which may then be fed to the application as arguments). > > [1] Mirrors: Design Principles for Meta-level Facilities of Object-Oriented > Programming Language. Gilad Bracha and David Ungar. > http://bracha.org/mirrors.pdf > [2] The Newspeak Programming Platform. http://bracha.org/newspeak.pdf > (sections 3,4). > [3] Maude Manual Chapter 11: Reflection, Metalevel Computation, and > Strategies. http://maude.cs.uiuc.edu/maude2-manual/html/maude-manualch11.html > > We can use power responsibly. The trick is to control who holds it, so that > power is isolated to the 'responsible' regions of code. > > 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] Lessons from COLA
Have you looked at Maru? It's likely(?) what you're after. Or was. On Wed, Sep 28, 2011 at 7:43 PM, Erick Lavoie wrote: > I've found the vision of a simple, open and evolutionary adaptable > programming language substrate, as described in Albert [1], tantalizing. I > especially like the idea of dynamically evolving a language 'from within' a > fluid substrate. I am left wondering the extent to which this vision was > realized and its actual benefits. > > The commit log of idst [2] shows that work has been done up until 2009 > (minus the minor commit in 2010). The 2009 and 2010 NSF reports make no > mention of the COLA system, the latter report mentions Nothing as the target > for all the other DSLs. No comment has been made on the language(s) used to > explore the VMs design. The git mirror for idst and ocean are not accessible > on Micheal FIG website anymore. The latest papers citing [1] dates from 2009 > [3]. Based on Alan's comment that "it is not an incremental project [...]. > We actually throw away much of our code and rewrite with new designs pretty > often" [4], I would assume that there is no interest in pursuing the COLA > project anymore. > > However, I would still be interested in lessons learned from developing and > using COLA for implementing VMs: > > Was a fully bootstrapped dynamic implementation ever realized (Coke-based > implementation of the Pepsi compiler and Coke compiler/evaluator)? > > Was the system used to implement major subsystems (Worlds, Continuations, > On Stack Replacement, Multi-Threading, Network-Transparent and > Fault-Tolerant Distributed semantic)? > > What were the major gains in the practice of developing a new VM when using > a dynamic substrate? What was not significant in practice? > > Was the "evolve from within" strategy truly fruitful? If not, was it a > problem in the vision or in its implementation? > > Was there still a need to start from scratch instead of using COLA to > prototype new implementation techniques or bootstrap a new system? Why? > > I understand that the VPRI team is probably racing against the clock to put > the final touches to Frank and producing paperwork for the NSF, so I guess > more detailed answers might come next year (or hopefully in the last report) > but I am still interested in relevant pointers to article/documentation/code > and experience from members of this list which might provide elements of > answer to those questions. > > In the present, I am interested in developing a COLA-like system that could > serve as an exploration vehicle for research on high-performance > meta-circular VMs for dynamic languages. The main objective would be to > drastically reduce the amount of effort needed to test new ideas about > object representations, calling conventions, memory management, compiler > optimizations, etc. and pave the way for more dynamic optimizations. > > I would like the system to: > 1. allow interactive and safe development of multiple natively-running > object representations and dynamic compilers with full tool support > (debugger, profiler, inspector) > 2. easily migrate the system to a different implementation language > > The first property would serve to bring the benefits of a live programming > environment to VM development (as possible in Squeak, through simulation) > and the second would serve a) to facilitate the dissemination of the > implementation techniques (including meta-circular VM construction) in > existing language communities (Python, JavaScript, Scheme, etc.) and b) > obtain expressive and performant notation(s) for VM research without having > to start from scratch each time. > > Answers to the aforementioned questions would guide my own implementation > strategy. I am also interested in pointers to past work that might be > relevant to such a pursuit. > > Erick > > [1] > http://piumarta.com/papers/**albert.pdf<http://piumarta.com/papers/albert.pdf> > [2] http://piumarta.com/svn2/idst/**trunk<http://piumarta.com/svn2/idst/trunk> > [3] http://scholar.google.com/**scholar?cites=** > 8937759201081236471&as_sdt=**2005&sciodt=1,5&hl=en<http://scholar.google.com/scholar?cites=8937759201081236471&as_sdt=2005&sciodt=1,5&hl=en> > [4] > http://vpri.org/mailman/**private/fonc/2010/001352.html<http://vpri.org/mailman/private/fonc/2010/001352.html> > > > __**_ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Tension between meta-object protocol and encapsulation
This has been bugging me for awhile. This seems like the best forum to ask about it. "With great power comes great responsibility." This quotation is hard to pin down. There are several versions of it to be found. This particular phrasing of the statement probably belongs to Stan Lee, but I think the phrase, in another form, is older than that. It seems to me that there is tension here, forces pulling in orthogonal directions. In systems which include a MOP, it seems as though encapsulation is sort of hosed at will. Certainly I'm not arguing against the MOP, it's one of the most powerful ideas in programming. For some things, it seems absolutely necessary, but then... there's the abuse of the MOP. I've done it to spectacular effect :D and when one is under constant pressure to ship, one tends to reach for the longest lever in the room. On one hand, I can avoid writing a lot of code at times this way, but on the other hand, what I've done is liable to confuse the hell out of whatever poor bastard is maintaining my code now. I've also had to wade through some very confusing code that also did it. You know, as long as it's me doing it, it's fine, but there's only one of me, and there's in the neighborhood of 6,775,235,700 of you! Is this tension irreconcilable? -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Re: [lively-kernel] Using Lively Fabrik in Elementary school program
Lovely. Also, Scratch. Then we can finally deploy it on iOS unblocked. Casey On Aug 22, 2011, at 8:59 AM, Alan Kay wrote: > To lively folks, > > Why not do an Etoys in lively as well? (it was originally done in Morphic and > will probably fit the lively architecture pretty well) > > Cheers > > Alan > From: R.D. Latimer > To: lively-ker...@hpi.uni-potsdam.de > Sent: Monday, August 22, 2011 7:02 AM > Subject: [lively-kernel] Using Lively Fabrik in Elementary school program > > We're working on a course introducing elementary school students, k-6, to > programming and critical thinking skills. > > We'd like to use Lively Fabrik as one of the components of the course. > http://www.lively-kernel.org/repository/lively-wiki/Fabrik.xhtml > > Are there other examples of Fabrik in addition to this page? > > Thanks for your help, > Randy Latimer > rdlati...@gmail.com Virginia, US > > ___ > lively-kernel mailing list > lively-ker...@hpi.uni-potsdam.de > http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel > > > ___ > lively-kernel mailing list > lively-ker...@hpi.uni-potsdam.de > http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Language Barrier
Heh, interesting. I honestly hadn't considered the process-boundary, but that's also a problem. I'll check this out, thank you. Let me ask a more direct question: if I wanted to test Frank, what language do you think I'd use? Right now Maru is looking attractive. One line of thinking is to test each DSL in itself, unless there's... maybe... a good language for testing things. Maybe it's just Lisp. Or maybe it's something I haven't thought of. In an environment, I'd like to be able to get a pulse on complexity without necessarily reading all of the code (you can't, there's 70,000,000 lines in there, and generally I'm lucky to read all of the *new* code, which only gives me a glimpse.) Of course in the future I do hope to have a system with many orders of magnitude less code jammed into it:) Most of the bugs seem to hang out around a) complexity, and b) integration points (which is likely a special case of a.) By test, I think what I have is a euphemism for automatically repeatable experimentation, but most of what I do doesn't get to be very scientific, which makes me sad. It's more like throwing dynamite into a lake to find out what's down there. Another term that might describe it well could be "executable specification" but in practice, there's never enough time to specify anything other than the things that we figure out we want to worry about, which is an entirely human/manual process in most cases. Anyway if we're going to have executable specs, I'm not sure we'd want to write two (one to represent, one to verify.) Seems like duplication of effort and I wish one could get both at once. C On Aug 19, 2011, at 8:09 PM, Monty Zukowski wrote: > Have you seen Causeway? Sounds like it might be a start toward what you > desire. > > http://www.erights.org/elang/tools/causeway/ > > Causeway is an open source postmortem distributed debugger for > examining the behavior of distributed programs built as communicating > event loops. Its message-oriented approach follows the flow of > messages across process and machine boundaries. > > http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html > > An increasing number of developers face the difficult task of > debugging distributed asynchronous programs. This trend has outpaced > the development of adequate debugging tools and currently, the best > option for many is an ad hoc patchwork of sequential tools and printf > debugging. This paper presents Causeway, a postmortem distributed > debugger that demonstrates a novel approach to understanding the > behavior of a distributed program. Our message-oriented approach > borrows an effective strategy from sequential debugging: To find the > source of unintended side- effects, start with the chain of expressed > intentions. We show how Causeway's integrated views - describing both > distributed and sequential computation - help users navigate causal > pathways as they pursue suspicions. We highlight Causeway's innovative > features which include adaptive, customizable event abstraction > mechanisms and graphical views that follow message flow across process > and machine boundaries. > > Monty > > On Fri, Aug 19, 2011 at 3:26 PM, Casey Ransberger > wrote: >> At work there are generally a small pile of languages in play: a "backend" >> language (Perl and Java seem common here,) sometimes a separate language for >> the web "front end," this has often been Ruby of late, a relational language >> (thus far always a SQL variant,) and the now ubiquitous Javascript. >> I test big web apps, usually. When I'm doing automation, I'm often >> frustrated by a "language barrier." Sometimes I can get a lot of mileage out >> of a meta-object protocol in languages which have one. But as the >> application under test is regularly written in multiple languages, the >> places where different subcomponents connect are problematic, I lose this >> leverage here, because these languages don't share a MOP. >> In the future, I want to be able to have this cake and eat it too. I'm not >> sure what that looks like or even what to call it. Maybe it's a domain >> specific language for test automation, or perhaps more interestingly, a >> meta-meta-object protocol (TM!) >> I note that when my backend is written in Java, it still makes some sense to >> choose (of the "company approved languages") e.g. Ruby to do the automation. >> More and more I just wish they'd let me use Lisp. This is partly because I'm >> typically outnumbered by line developers by a wide margin and want all of >> the leverage I can get. >> I
Re: [fonc] OOP
e anything e.g. the order the > arguments are processed in, what syntax is legal, etc. > > > yep, this is a nifty feature. > sadly, the Lisp macro system is not something which can be faithfully done > in notably different languages. > > another biggie problem is that a lot of this may conflict with the use of > late binding (and a delegation-based scoping model), since by design macros > have to be early-bound, making them potentially a "sore thumb" in a language > design sense. > > they may also risk exposing some implementation "nastiness", or may be used > in confusing and/or counter-intuitive ways (since there may not be any > obvious way to tell them apart from built-in functions or similar). > > > some of what could be done in using macros can be done in my case using the > "quote" and "unquote" keywords, but these are sort of a "lame joke" vs > macros. > > for example: > unquote foo(quote x+3); > would be (sort of) similar to: > (eval (foo '(+ x 3))) > > although possible could be to do similar with the syntax: > foo; > I don't really like this option (I don't really like the <...> syntax for > sake of it creating ambiguities). > > "foo!(...)" or "foo![...]" could also be possible. > also: > "foo:(...)" but this would create a whitespace sensitive operation. > "foo::(...)", could also work, and is not *too* ugly. > > note that, ideally, this would be a cached operation, rather than naively > rebuilding the code-fragment on every execution (or being a "one off" static > operation), but this leads to another problem: > how to make this semantically-transparent?... (I lack ideas for an obvious > flushing/invalidation mechanism in this case). > > this could lead to several edge cases: > a case where it is preferable to have it be one-off; > a case where it is preferable to dynamically re-build the expression. > > > > >- I'm not sure where, if at all, security comes in > > doesn't really appear to me that Lisp was really designed with security in > mind. > > > > > I can't really comment on a lot of this (too far outside my area). > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] The Language Barrier
At work there are generally a small pile of languages in play: a "backend" language (Perl and Java seem common here,) sometimes a separate language for the web "front end," this has often been Ruby of late, a relational language (thus far always a SQL variant,) and the now ubiquitous Javascript. I test big web apps, usually. When I'm doing automation, I'm often frustrated by a "language barrier." Sometimes I can get a lot of mileage out of a meta-object protocol in languages which have one. But as the application under test is regularly written in multiple languages, the places where different subcomponents connect are problematic, I lose this leverage here, because these languages don't share a MOP. In the future, I want to be able to have this cake and eat it too. I'm not sure what that looks like or even what to call it. Maybe it's a domain specific language for test automation, or perhaps more interestingly, a meta-meta-object protocol (TM!) I note that when my backend is written in Java, it still makes some sense to choose (of the "company approved languages") e.g. Ruby to do the automation. More and more I just wish they'd let me use Lisp. This is partly because I'm typically outnumbered by line developers by a wide margin and want all of the leverage I can get. I wonder what people here would think about these ideas. Alex Warth mentioned an "omnidebugger" and I almost wonder if whatever approach works for that might work for this. Maybe a common intermediate representation is all I need to do it. -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Line endings
Did Squeak pick up Macintosh style line endings when it travelled through Apple, or did Apple pick up Smalltalk style line endings when it travelled through PARC? I've been wondering about this for awhile now. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: VR "for the rest of us" (was Re: [fonc] Re: SecondPlace, QwaqLife or TeleSim? Open ended, comments welcome)
eveloping modular, federated, distributed command > and control systems, augmented reality systems, and 3D worlds. > > >> Croquet always felt awkward to me, partly it was performance, but it was >> also because some of the primitives were too primitive. >> > > I agree that this is a problem. VRML is a problem for the same reason - > i.e. it is not clear what the physics should be, nor how we should > recharacterize for a different artistic style, and so on. > > Regards, > > Dave > > [1] http://inform7.com/ > [2] http://awelonblue.wordpress.com/2011/07/05/transaction-tribulation/ > [3] http://awelonblue.wordpress.com/2011/05/21/comparing-frp-to-rdp/ > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Large places and lots of users (was Re: VR "for the rest of us")
Aha. This explains why various wonderful people warned me that what I wanted to do would end up being expensive to implement. There's been some talk about "federated worlds" and this is I *think* part of what I'm after. So let me ask you this: if I can find a way to cut down the time to load a new room far enough to where users don't have to notice it very much, e.g. by caching a lot of assets on disk, etc, find a way so that one can see into the next room in a matrix of rooms, and then just make the portals invisible and at compass boundaries between spaces, do you still think I'd need to rip out TeaTime and replace it with something of a completely different design in order to build a large, apparently (but not actually) continuous space? I realize that I'm probably pushing my luck:) but crowds are important for large groups like everyone, so this just got twice as interesting! On Tue, Aug 9, 2011 at 5:37 PM, David Barbour wrote: > On Tue, Aug 9, 2011 at 3:40 PM, BGB wrote: > >> ideally, we should probably be working with higher-level "entities" >> instead of lower-level geometry. >> > > I agree with rendering high-level concepts rather than low-level > geometries. > > But I favor a more logical model - i.e. rendering a set of logical > "predicates". > > Either way, we have a set of records to render. But predicates can be > computed dynamically, a result of composing queries and computing views. > Predicates lack identity or state. This greatly affects how we manage the > opposite direction: modeling user input. > > >> possibly, ultimately all levels should be expressed, but what should be >> fundamental, what should be expressed in each map, ... is potentially a >> subject of debate. >> > > I wouldn't want to build in any 'fundamental' features, except maybe > strings and numbers. But we should expect a lot of de-facto standards - > including forms, rooms, avatars, clothing, doors, buildings, landscapes, > materials, some SVG equivalent, common image formats, video, et cetera - as > a natural consequence of the development model. It would pay to make sure we > have a lot of *good* standards from the very start, along with a flexible > model (e.g. supporting declarative mixins might be nice). > > >> >> I am not familiar with the Teatime protocol. apparently Wikipedia doesn't >> really know about it either... >> > > Teatime was developed for Croquet. You can look it up on the VPRI site. But > the short summary is: > * Each computer has a redundant copy of the world. > * New (or recovering) participant gets snapshot + set of recent messages. > * User input is sent to every computer by distributed transaction. > * Messages generated within the world run normally. > * Logical discrete clock with millisecond precision; you can schedule > incremental events for future. > * Smooth interpolation of more cyclic animations without discrete events is > achieved indirectly: renderer provides render-time. > > This works well for medium-sized worlds and medium numbers of participants. > It scales further by connecting a lot of smaller worlds together (via > 'portals'), which will have separate transaction queues. > > It is feasible to make it scale further yet using specialized protocols for > handling 'crowds', e.g. if we were to model 10k participants viewing a > stage, we could model most of the crowd as relatively static NPCs, and use > some content-distribution techniques. But at this point we're already > fighting the technology, and there are still security concerns, disruption > tolerance concerns, and so on. > > Regards, > > Dave > > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: VR "for the rest of us" (was Re: [fonc] Re: SecondPlace, QwaqLife or TeleSim? Open ended, comments welcome)
On Tue, Aug 9, 2011 at 4:17 PM, David Barbour wrote: The best way to have a conversation with someone is in person, >> > > I think it depends on the nature of the conversation. There are significant > advantages to written conversations, such as: the ability to spend more time > thinking about our responses, the ability to operate at different times, and > having a written record you can search and reference. > Well put. This is an excellent point, and I stand *quite* corrected. I wrote this while slightly irked that a message I sent via a popular textual communication medium was "too long." I still prefer a mailing list for most of the stuff I like to talk about: case in point. -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: VR "for the rest of us" (was Re: [fonc] Re: SecondPlace, QwaqLife or TeleSim? Open ended, comments welcome)
Cut it down to what I'm responding too, and inline. On Tue, Aug 9, 2011 at 11:09 AM, Steve Wart wrote: > > > Despite its commercial nature Minecraft seems very open and easy to adapt. > Interestingly this implementation does a lot more to show that Java is "fast > enough" for real-time 3D environments than Croquet was able to with Squeak. > Croquet always felt awkward to me, partly it was performance, but it was > also because some of the primitives were too primitive. > Have you checked out OpenQwaq? Runs on Cog. I have a feeling if I ran the server on a different computer, rather than in VMWare on the same modest hardware, performance would be a non-issue unless I allowed extremely complex meshes or high-rez textures in. It's even totally acceptable and usable even the way I'm currently running it, which is in a relatively resource starved way. It chunks just a wee bit from time to time. I've been really impressed with the performance so far. It would not, in any previous year, have occurred to me to run an application that rendered 3D graphics alongside an application that virtualized a big old enterprise operating system at the same time on the same machine, but here I am doing it:) > Regards, > Steve > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
VR "for the rest of us" (was Re: [fonc] Re: SecondPlace, QwaqLife or TeleSim? Open ended, comments welcome)
Inline and abridged... and rather long anyhow. I *really* like some of the ideas that are getting tossed around. On Tue, Aug 9, 2011 at 2:05 AM, BGB wrote: > On 8/8/2011 6:55 PM, Casey Ransberger wrote: > > I almost missed this thread. I'm also hunting that grail. VR for consumers > that isn't lame. CC'd FONC because I think this is actually relevant to that > conversation. > > My feeling is, and I may be wrong, that the problems with Second Life are > twofold: > > > [sorry in advance, I mostly ended up running off in an unrelated direction, > but maybe it could still be interesting]. > You're fine, I do it all the time:) IMO, probably better (than centralized servers) is to have independent > world-servers which run alongside a traditional web-server (such as Apache > or similar). > This appears more or less to be the way OpenQwaq works. I'm pretty sure that I haven't fully comprehended everything the server does and how that relates to the more familiar (to me) client, though. I note that the models and such seem to live on the server, and then get sent (synced?) to the client. > one can jump to a server using its URL, pull down its local content via > HTTP, and connect to a server which manages the shared VR world, ... > Ah, you're talking about running in a web browser? Yeah, that will probably happen, but the web browser strikes me as a rather poor choice of life support system for a 3D multimedia collaboration and learning environment at least as of today... OTOH I guess it solves the problem of not being able to deploy (e.g.) GPL'd code on platforms like iOS. I should say that I'm a huge fan of things like Clamato and Lively Kernel, but I'm not sure the WebGL thing is ready for prime time, and I'm not sure how something like e.g. Croquet will translate at this point in time. I also don't have a Croquet implemented in Javascript lying around anywhere, and it's not exactly a small amount of work to implement the basis. I don't even understand how all of the parts work or interact yet... > a partial issue though becomes how much client-specific content to allow, > for example, if clients use their own avatars (which are bounced along using > the webserver to distribute them to anyone who sees them), and a persons' > avatar is derived from copyrighted material, there is always a risk that > some jerkface lawyers may try to sue the person running the server, or the > author of the VR software, with copyright infringement (unless of course one > uses the usual sets of legal disclaimers and "terms of use" agreements and > similar). > Heh, yes. Fortunately there are places one can go to purchase assets which can then be used under commercially compatible licenses... to be honest, though, the avatar I've been testing with is *cough* Tron. Found it on the web and couldn't really resist. Got to take him out of there before I can deploy anything, I think, but I Am Not A Lawyer, so I can't say that I actually know, and like most folks, I'm going to play it safe... what I do know is that this is slightly embarrassing :O Working on an original protagonist/avatar for my "game" but she's not quite done yet. It's all dialed in but the clothes aren't right yet. Having to learn to use this pile of expensive 3D animation software as I go... I really wish I could just draw everything using a pencil and then use a lightbox to transfer the keyframes to cell and paint, but I don't know how to make hand drawn animation work in 3D. This is actually why I was curious about the availability of the sources to SketchPad, because that constraints in 3D idea seems to underly the automated inbetweening that goes on nowadays and you could do stuff in 3D using a light pen with SketchPad, which seems better than what I have now in a lot of ways. > allowing user-created worlds on a shared server (sort of like a Wiki) poses > similar problems. > the temptation for people to be lazy and use copyrighted images/music/... > in their worlds is fairly large, and nearly any new technology is a major > bait for opportunistic lawsuit-crazy lawyers... > So it *seems* like the way most businesses deal with this is by taking UGC down without quarter whenever someone complains. I'll probably end up having to do something like this. It's still painful because one then needs to employ people to actually handle that every day. I don't know, maybe there's some way to use community policing to accomplish this. In my view, though, if it happens, it isn't the worst problem in the world to have. It means someone noticed that your product/service or what have you exists! And if it was fatal, I don't think YouTube would still be on the internet. In fact all of that "ba
[fonc] Re: SecondPlace, QwaqLife or TeleSim? Open ended, comments welcome
On Sun, Aug 7, 2011 at 3:48 AM, Giulio Prisco wrote: > SecondPlace, QwaqLife or TeleSim? Open ended, comments welcome. > > > http://giulioprisco.blogspot.com/2011/08/secondplace-qwaqlife-or-telesim.html > I almost missed this thread. I'm also hunting that grail. VR for consumers that isn't lame. CC'd FONC because I think this is actually relevant to that conversation. My feeling is, and I may be wrong, that the problems with Second Life are twofold: 1. There are technical problems with the implementation. It's very crashy and didn't scale well. My suspicion is that the biggest problem they have is getting the user generated texture maps out to all of the clients on the fly. This leads to usability issues, etc. It can take minutes to get to the point where one is actually participating after arriving in a sim, while all those textures and meshes load it just thrashes like crazy. Also there's the server-centric architecture, which is usually harder to scale than peer to peer technology. I have not yet determined what the "weight" of the OpenQwaq server is yet, though, because I don't have enough machines to build out a "production-like" environment currently. It seems a touch crawly running all of the services on my modest laptop under a single CentOS host in VMWare while the client is also running at the same time (heh) and this is not a real measure of server or client performance:) it's currently just a way to warm up my apartment. 2. Their entire business model ended up being a cultural toxin. Free accounts mean spam and griefing/trolling/abuse. A profit motive for users seemed like a good idea at the outset, as it's about the most marketable universal out there, but it seems that DRM+UGC = red light district, real estate, fashion, and a handful of enterprise applications which would probably be served at least as well by Teleplace. I think one ultimately wants user generated content, but I'm not sure what the right way to do it is. One might read a book about Logo:) Minecraft has been running with an honor system for awhile now, and people just don't seem to mess with each other as much there. They're implementing some anti-griefing stuff around treasure chests now, but users build beautiful sculptures, ALUs, delay line memory, etc. Not a red light district to be found. I think it's because you actually have to pay in order to play, and you can't make money in there. My guess is the real difference is in the business model, but it might also be that low resolution volumetrics don't lend themselves as well to amplifying some of the less-awesome universals, instead amplifying much more creative and often non-universal activity. It's almost like Lego geology. These are all just hunches though. I could be wrong. -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] HotDraw's Tool State Machine Editor
After I heard about the Wolfram Alpha integration, I decided to give it a shot.
I didn't like the price tag.
At the time I was interested in chemical simulations, and I didn't know of
anything else that'd let me do them out of the box (without requiring me to
already have a much greater command of chemistry than I do presently.)
I was on an A-Life kick. Was wondering if I might be able to find some kind
simplified "artificial chemistry" that'd let me get an evolutionary process
going at a (pseudo-) chemical level without leaving me starved for computing
resources.
I really dug the way Alpha would in some cases be able to supply me with
m-expression representations of things.
Kind of wish they'd just used Lisp for Mathematica, and gridding it up isn't
cheap, so I ended up doing some weird art with it before abandoning it in favor
of Squeak, which I can parallelize at the process level without trouble, and of
course the green threads work well enough for some things too.
I did really like the touch of HyperCard that was going on with it though. All
in all, I haven't used it enough to justify the expense, and it takes too much
space on the disk:(
On Jul 28, 2011, at 12:14 PM, David Leibs wrote:
> Ah, powerful notations and the Principia. These are some of my favorite
> things. :-)
>
> An excellent example of a difficult subject made easier by a wonderful tool
> is Mathematica. I think the Wolfram folks have done a really great job over
> the last 25 years with Mathematica. You can directly use math notation but
> it is converted into the much more powerful internal representation of
> Mathematica terms. Just think of Mathematica terms as s-expressions and you
> are close. Mathematica's math notation system is built on a general system
> that supports notations so that you could build a notation system that is
> what chemists would want.
>
> The Mathematica Notebook is a wonderful system for exploration. Notebooks
> let you build beautiful publishable documents that typically also contain
> live code for simulations and modeling. Of course a Mathematica notebook is
> just a bunch of Mathematica terms. I wish web browsers were as good as
> Mathematica notebooks. They are like Smalltalk workspaces on steroids. I
> wish there was an open source Mathematica notebook like
> "read-canonicalize-evaluate-present" shell.
>
> At the bottom of Mathematica is the Mathematica language which is a very
> "Lispy" functional language with a gigantic library of primitives. There is
> no Type Religion in Mathematica's functional programming. The documentation
> is extensive and made from Mathematica notebooks so that all examples are
> both beautiful and executable. The learning curve is very very high because
> there is so much there but you can start simply just by evaluating 3+4 and
> grow. It's very open ended.
>
> The Mathematica language is also great for meta programming. Last year my
> son was working for the University of Colorado physics department building a
> model of the interaction of the solar wind with the interstellar medium. His
> code made big use of meta programming to dramatically boost the performance.
> He would partially evaluate his "code/ math" in the context of interesting
> boundary conditions then use Simplify to reduce the code then run it through
> the low level Mathematica compiler. He was able to get a 100x performance
> boost this way. Mathematica was his first programming language and he has
> used it regularly for about 14 years .
>
>
> To give you a taste let's implement the most beautiful Newton's forward
> difference algorithm from the Principia.
>
> see:
> http://mathworld.wolfram.com/FiniteDifference.html
>
> for the background.
> The code below (hopefully not too mangled by blind email systems) repeatedly
> takes differences
> until a zero is found resulting in a list of list of all differences. The
> first elements are then harvested and the last zero dropped.
> Now just make some parallel lists for that will get passed to the difference
> term algorithm. I could have written a loop
> but APL and Mathematica has taught me that Transpose and Apply, and a level
> spec can write my loops for me without error.
> Once you have all the terms in a list just join them with Plus. Finally run
> the whole thing through Simplify.
>
> The differenceTerm and fallingFactorial helper functions should look familiar
> to those who have played with modern functional programming. Note I pass in
> a symbol and the Mathematica rule reducing system naturally does partial
> evaluation. I realize I have left a lot of Mathematica details unexplained
> but I am just trying to give a taste.
>
> Using the data from the mathworld web page you we can evaluate away
>
> praiseNewton[{1, 19, 143, 607, 1789, 4211, 8539}, n]
>
>1+7 n+2 n^2+3 n^3+6 n^4
>
> Without the Simplify we would have gotten:
>
> 1+18 n
[fonc] Physics and Types
Please forgive - not a physicist. Ian mentioned something about a Bose-Einstein Condensate for computer programming once, and this really jumped out at me. I've seen math and I've seen biology applied, at least in metaphor, to our problems. I can't think of a lot of stories about applying physics to these troubles, and I wonder why. I keep hearing about purely mathematical type systems. I will admit that being focused on "type" seems to have been a bit of an intellectual digression for me, perhaps because the Air Force base really wanted me to take classes centered on Ada, and when I eventually found Smalltalk, I felt almost a sense of relief. I don't think I've ever seen a set of types that looked anything like #(strong weak electro slipperyGraviton) asSet. Maybe it's because this is too much like a type system for an assembly language? I probably don't have sufficient command of these fields to even ask smart questions. I'm asking anyway. With the discussion of "particles and fields" it seems at least topical. Any takers? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alan Kay talk at HPI in Potsdam
On Jul 26, 2011, at 3:28 PM, BGB wrote: > On 7/26/2011 9:05 AM, David Barbour wrote: >> >> On Tue, Jul 26, 2011 at 1:50 AM, BGB wrote: >> whether or not compiling to bytecode is itself an actually effective >> security measure, it is the commonly expected security measure. >> >> Is it? I've not heard anyone speak that way in many, many years. I think >> people are getting used to JavaScript. >> > > for web-apps maybe, but it will likely be a long time before it becomes > adopted by commercial application software (where the source-code is commonly > regarded as a trade-secret). Worth pointing out that server side JS dodges this "problem." Now that Node is out there, people are actually starting to do stuff with JS that doesn't run on the client, so it's happening... whether or not it's a real qualitative improvement for anyone.___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alan Kay talk at HPI in Potsdam
I doubt this is what you're thinking -- not sure I read this clearly -- but I caught an interview with John McCarthy on the 'tubes wherein he seemed to indicate that he was interested in a universal intermediate representation. I thought the idea was cool. On Jul 26, 2011, at 6:43 AM, John Nilsson wrote: > On Tue, Jul 26, 2011 at 8:16 AM, BGB wrote: > the main merit of a bytecode format is that it could shorten the path in > getting to native code, potentially allowing it to be faster. > > It seems to me that there is a lot of derivation of information going on when > interpreting source code. First a one dimensional stream of characters is > transformed into some kind of structured representation, possibly in several > steps. From the structural representation a lot of inference about the > program happens to deduce types and other properties of the structure. Once > inside a VM even more information is gathered such as determining if call > sites are typically monomorphic or not, and so on. > > In other words a _lot_ of CPU cycles are spend on deriving the same > information, again and again, each time a program is loaded. Not only is this > a waste of energy it also means that each interpreter of the program needs to > be able to derive all this information on their own, which leads to very > complex programs (expensive to develop). > > Would it not be a big improvement if we could move from representing programs > as text-strings into representing them in some format capable of representing > all this derived information? Does any one know of attempts in this direction? > > BR, > 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: Growth, Popularity and Languages - was Re: [fonc] Alan Kay talk at HPI in Potsdam
I want to try using a fluffy pop song to sell a protest album... it worked for others before me:) If you're really lucky, some people will accidentally listen to your other songs. (metaphorically speaking) "A spoonful of sugar" -- Casey On Jul 25, 2011, at 10:47 PM, Alan Kay wrote: > The trivial take on computing today by both the consumers and most of the > "professionals" would just be another "pop music" to wince at most of the > time, if it weren't so important for how future thinking should be done. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: [squeak-dev] [ANN] Alan Kay to talk about "Next steps for qualitatively improving programming" at HPI in Potsdam
Drat. Tried to convert this, but I just get a dialog that says "convert only works from a local file." I don't see an option to pull the actual video file down, and IIRC .ram files are like trackers that point at a stream rather than being the actual video data? I have a feeling that the reason I'm unable to do this is by design, but I'm not certain. On Fri, Jul 22, 2011 at 7:47 PM, Juan Vuletich wrote: > Casey Ransberger wrote: > >> I did this dance too... Hmm... Seems the Mac installer comes with some >> kind of translation tool that's advertised to be able to output MPEG, maybe >> we can use that to save others the trouble of installing the Real client. >> If I figure out that I can handle the conversion without spending any >> money, would folks have interest in the artifact produced? >> >> This is a fun talk, I'm only about halfway through it, but I must admit >> having cracked up when he said, (and I have to paraphrase, because I don't >> have it in front of me,) "...if we were physicists, and we didn't understand >> what Newton did [slight dramatic pause] we should be shot." >> >> LOL! >> > > I'd really like to have it in my local disk, and in any format that lets me > pause and resume, or go back to listen to some part again! > > Cheers, > Juan Vuletich > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Re: [squeak-dev] [ANN] Alan Kay to talk about "Next steps for qualitatively improving programming" at HPI in Potsdam
I did this dance too... Hmm... Seems the Mac installer comes with some kind of translation tool that's advertised to be able to output MPEG, maybe we can use that to save others the trouble of installing the Real client. If I figure out that I can handle the conversion without spending any money, would folks have interest in the artifact produced? This is a fun talk, I'm only about halfway through it, but I must admit having cracked up when he said, (and I have to paraphrase, because I don't have it in front of me,) "...if we were physicists, and we didn't understand what Newton did [slight dramatic pause] we should be shot." LOL! On Jul 22, 2011, at 2:27 PM, Eliot Miranda wrote: > never mind. had to install the latest version and reinstall... > > On Fri, Jul 22, 2011 at 2:17 PM, Eliot Miranda > wrote: > Hi Robert, > > is it possible to put the media up on other than Real format? The Real > players, both hd and normal quality, both crash for me on mac OS X 10.6. > > > On Fri, Jul 22, 2011 at 2:06 PM, Robert Hirschfeld > wrote: > A recording of Alan's talk is available online at > > http://www.tele-task.de/de/archive/lecture/overview/5819/ > > Best, > Robert > > On Jul 8, 2011, at 1:35 AM, Robert Hirschfeld wrote: > > > It is my great pleasure to announce Alan Kay's talk here at HPI. > > > > Title: "Next steps for qualitatively improving programming" > > > > Venue: Lecture Hall 1, Hasso-Plattner-Institut Potsdam, Germany > > > > Date and time: July 21 (Thu) 2011, 16:00-17:00 > > > > Additional information: > > http://www.vpri.org/html/people/founders.htm > > http://www.hpi.uni-potsdam.de/hpi/anfahrt?L=1 > > http://www.hpi.uni-potsdam.de/news/beitrag/computerpionier-alan-kay-wird-hpi-fellow.html > > > > (Alan's talk will be recorded and made available online.) > > > > Best, > > Robert > > > > -- > > Robert Hirschfeld > > Hasso-Plattner-Institut > > hirschf...@hpi.uni-potsdam.de > > www.hpi.uni-potsdam.de/swa > > > > > > -- > best, > Eliot > > > > > -- > best, > Eliot > > ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Last programming language
Even if it were possible to have a last language, it would be double plus ungood. On Mon, Jul 18, 2011 at 8:58 AM, Paul Homer wrote: > Realistically, I think Godel's Incompleteness Theorem implies that there > can be no 'last' programming language (formal system). > > But I think it is possible for a fundamentally different paradigm make a > huge leap in our ability to build complex systems. My thinking from a couple > of years back: > > > http://theprogrammersparadox.blogspot.com/2009/04/end-of-coding-as-we-know-it.html > > Paul. > > --- On *Mon, 7/18/11, BGB * wrote: > > > From: BGB > Subject: Re: [fonc] Last programming language > > To: "Fundamentals of New Computing" > Received: Monday, July 18, 2011, 6:28 AM > > > On 7/18/2011 2:56 AM, Casey Ransberger wrote: > > Smells like Kool-Aide. I smell bullshit. Dude is selling a book tour or > something. Let's just pick the POS we have now and run with it? Seriously? > How many times has that gone well? > > Dude is on a book-tour or something. Let him have it. > > > for most people and most projects, advice like "just pick C or Java or C# > or similar" generally aligns fairly well with the path to highest likely > productivity (get code written and out the door to customers, ...). if it is > something common, then there is less likely to be slowdowns or similar due > to some of the development team members getting confused, or having "area of > responsibility" confusion or similar. > > the bigger question is what can be done which hasn't already been done? and > more so, why does it necessarily matter? and, if there is something great > waiting, how does one best go about finding and it and making productive use > of it? ... > > > one potentially overlooked issue in the video: > 40 years ago, threads and multiprocessor systems were not exactly common; > now they are pretty much everywhere, but the most common languages tend to > be fairly incompetent of effectively utilizing them. > > though not "fundamentally new", this is at least a relevant change. > > > for example, what is a "not crappy" way to go about writing code, say, for > a GPU?... > > maybe there are better answers than, say, "well, pretend you are running > loops over big arrays" (CUDA) and "well, just run C on the thing" (OpenCL). > > > IMO, I sort of like mailboxes and asynchronous and trans-thread > function/method calls, but these are relative novelties (vs the ever present > "lock a mutex or enter a critical section or similar" model). > > ... > > or such... > > > On Jul 17, 2011, at 11:31 AM, karl ramberg > http://mc/compose?to=karlramb...@gmail.com>> > wrote: > > Hi > Here is a interesting video about programming languages > > http://skillsmatter.com/podcast/agile-testing/bobs-last-language > > Karl > > ___ > fonc mailing list > fonc@vpri.org <http://mc/compose?to=fonc@vpri.org> > http://vpri.org/mailman/listinfo/fonc > > > > ___ > fonc mailing list > fonc@vpri.org <http://mc/compose?to=fonc@vpri.org> > http://vpri.org/mailman/listinfo/fonc > > > > -Inline Attachment Follows- > > > ___ > fonc mailing list > fonc@vpri.org <http://mc/compose?to=fonc@vpri.org> > http://vpri.org/mailman/listinfo/fonc > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Last programming language
Memorizing Pi is a dumb old trick, like ripping a phone book in half. I can memorize Pi, I mean if I wanted to spend my time that way, but it's all a dodge: I'm just ripping a phone book in half, and the whole trick is to twist it just so that the entire heroic thing only ever happens over a few pages at a time, but quickly enough that people think you know how to do something really special. I saw one of this guy's talks once - or at least, I think so, wasn't he at Rails Conf? Anyway: I think dude's talent is a form of stagecraft. Can we please blow this guy off and get back to inventing the future ??? On Jul 17, 2011, at 2:51 PM, BGB wrote: > On 7/17/2011 2:33 PM, Craig Latta wrote: >> That talk would have been a whole lot better if he had grounded it >> with a discussion of how constraints are good for creativity. It's how >> he should have spent the time where he went on about memorizing Pi for >> no good reason... > > if memorizing pie is a measure of programmer status, it likely puts down > those of us who only know 10s of digits of Pi... > > granted, it is probably not that terribly important to know far more digits > of pie than can be reasonably represented in a sanely-sized floating point > constant. > > > funny though is I don't really believe in taking things away from languages, > rather just providing ideally clean and concise constructs to take over the > role of more hairy constructs. > > for example, if/while/for/... don't mean goto shouldn't exist in a language > or should be branded as "evil" as a result, rather they provide better > alternatives such that things like goto are more of a "break glass in case of > emergency" feature (or can be taken as a sign that, when one finds themselves > using it, then likely things have already gone fairly far south as far as > this particular code is concerned...). > > > so, I think it is more about providing better and cleaner alternatives to > common problems than in trying to take things away. > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
