Re: [fonc] Personal Programming Environment as Extension of Self
A thought about bytecode: One problem with distributing things in a
compiled version is that it doesnt really afford collaboration. If the
primary means of distribution instead would be the source as such it's much
easier to debug and fix issues discovered in imported modules. If something
like a github fork was the standard way of importing it would be even
better, then you are basically just a pull request away from contributing
tweaks too.
Things like minification as in the javascript world would have to be
discouraged though, so compilation and caching should be designers so
as not to be a performance problem.
But, like git, this should be easy if things are based on immutable content
adressable fragments. See f.ex. Datomic and/or camlistore as an approach to
this. ( and docker for that matter)
BR
John
Den söndagen den 22:e september 2013 skrev David Barbour:
Mark,
You ask some good questions! I've been taking some concrete actions to
realize my vision, but I haven't much considered how easily others might
get involved.
As I've written, I think a tactic concatenative (TC) language is the key
to making it all work great. A TC language can provide a uniformly safe and
simple foundation for understanding and manipulating streaming updates.
User actions must be formally translated to TC commands, though I can start
at a higher level and work my way down. However, the artifacts constructed
and operated upon by this language must be concretely visualizable,
composable, and manipulable - e.g. documents, diagrams, graphs, geometries.
Homoiconic this is not.
My own plan is to implement a streamable, strongly typed,
capability-secure TC bytecode (Awelon Bytecode, ABC) and build up from
there, perhaps targeting Unity and/or developing a web-app IDE for
visualization. (Unity is a tempting target for me due to my interest in AR
and VR environments, and Meta's support for Unity.)
I would very much favor a lightweight toolkit approach, similar to what
the REBOL/Red community has achieved -fitting entire desktops and
webservices as tiny apps built upon portable OS/runtime ( 1MB). BTW, if
you are a big believer in tools, I strongly recommend you look into what
the REBOL http://www.rebol.com/what-rebol.html community has achieved,
and its offshoot Red http://www.red-lang.org/p/about.html. These people
have already achieved and commercialized a fair portion of the FoNC ideals
through their use of dialects. They make emacs look like a bloated,
outdated, arcane behemoth.
(If REBOL/Red used capability-based security, pervasive reactivity, live
programming, strong types, substructural types, external state, and...
well, there are a lot of reasons I don't favor the languages. But what
they've accomplished is very impressive!)
I think the toolkit approach quite feasible. ABC is designed for
continuous reactive behaviors, but it turns out that it can be very
effectively used for one-off functions and imperative code, depending only
on how the capability invocations are interpreted. ABC can also be used for
efficient serialization, i.e. as the protocol to maintain values in a
reactive model. So it should be feasible to target Unity or build my own
visualization/UI toolkit. (ABC will be relatively inefficient until I have
a good compiler for it, but getting started should be easy once ABC is
fully defined and Agda-sanitized.)
Best,
Dave
On Sep 21, 2013 10:52 PM, Mark Haniford
markhanif...@gmail.comjavascript:_e({}, 'cvml', 'markhanif...@gmail.com');
wrote:
David,
Great Writeup. To get down to more practical terms for laymen software
engineers such as myself, what can we do in immediate terms to realize
your vision?
I'm a big believer in tools( even though I'm installing emacs 24 and
live-tool). Is there currently a rich IDE environment core in which we can
start exploring visualization tools?
Here's what I'm getting at. We have rich IDEs (in relative terms),
Intellij, Resharper, VS, Eclipse, whatever.. I think they are still very
archaic in programmer productivity. The problem I see is that we have a
dichotomy with scripting ennviroments (Emacs) as opposed to heavy IDEs.
e.g. we can't easily script these IDEs for expermination.
thought?
I find myself agreeing with most of your intermediate reasoning and
then failing to understand the jump to the conclusion of tactic
concatenative programming and the appeal of viewing user interfaces as
programs.
Tacit concatenative makes it all work smoothly.
TC is very effective for:
* automatic visualization and animation
* streaming programs
* pattern detection (simple matching)
* simple rewrite rules
* search-based code generation
* Markov model predictions (user anticipation)
* genetic programming and tuning
* typesafe dataflow for linear or modal
Individually, each of these may look like an incremental improvement
that could be achieved without TC.
But every little point, every
Re: [fonc] Final STEP progress report abandoned?
In a sense, but on a higher level, it's more focused on the stretegic desgin. http://impactmapping.org/drawing.php Also take a look at for related modelling technique http://www.b-mc2.com/2013/04/26/from-business-strategy-to-solution-a-unified-conceptual-framework/ And for that matter http://en.wikipedia.org/wiki/Thinking_processes_%28theory_of_constraints%29 BR, John On Thu, Sep 5, 2013 at 8:00 PM, John Carlson yottz...@gmail.com wrote: What is an impact map model? Is it something like a use case? On Sep 5, 2013 12:33 PM, John Nilsson j...@milsson.nu wrote: Even if the different domains are different it should still be possible to generalize the basic framework and strategy used. I imagine layers of models each constrained by the upper metamodel and a fitness function feeding a generator to create the next layer down until you reach the bottom executable layer. In a sense this is what humans do no? Begin with the impact map model , derive from that an activity model, derive from that a high level activity support model, derive from that acceptance criteria, derive from that acceptance test examples, derive from that a low level interaction state machine an so on... In the human case I belive the approach modelled by the kanban katas seems appropriate. Nested stacks of hypotheses to try in a disciplined PDCA cycle. 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 ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Final STEP progress report abandoned?
Even if the different domains are different it should still be possible to generalize the basic framework and strategy used. I imagine layers of models each constrained by the upper metamodel and a fitness function feeding a generator to create the next layer down until you reach the bottom executable layer. In a sense this is what humans do no? Begin with the impact map model , derive from that an activity model, derive from that a high level activity support model, derive from that acceptance criteria, derive from that acceptance test examples, derive from that a low level interaction state machine an so on... In the human case I belive the approach modelled by the kanban katas seems appropriate. Nested stacks of hypotheses to try in a disciplined PDCA cycle. BR John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Final STEP progress report abandoned?
Check out http://www.cat-language.com/ BR John Skickat från min iPhone 4 sep 2013 kl. 01:43 skrev Casey Ransberger casey.obrie...@gmail.com: I've heavily abridged your message David; sorry if I've dropped important context. My words below... On Sep 3, 2013, at 3:04 PM, David Barbour dmbarb...@gmail.com wrote: Even better if the languages are good for exploration by genetic programming - i.e. easily sliced, spliced, rearranged, mutated. I've only seen this done with two languages. Certainly it's possible in any language with the right semantic chops but so far it seems like we're looking at Lisp (et al) and FORTH. My observation has been that the main quality that yields (ease of recombination? I don't even know what it is for sure) is syntaxlessness. I'd love to know about other languages and qualities of languages that are conducive to this sort of thing, especially if anyone has seen interesting work done with one of the logic languages. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Why Mind Uploading could be horrible
It's not so much if a copy is the same as the real thing, but rather how do you define the difference between an all-at-once copy with a simultaneous destruction of the original and a piece by piece replacement of the parts? It seems to me they only differ by the size of the part replaced. BR John Den 23 apr 2013 18:13 skrev Tristan Slominski tristan.slomin...@gmail.com: With great trepidation, I will try to keep this to computing :D It may revolve around the meaning of uploading, but my problem with the uploading approach, is that it makes a copy. Whether a copy is the same as the real thing I feel is beyond the scope of a computing discussion in this particular sense. I assert, that I am not interested in a copy of Me (in legal style, I will use capitals for defined terms). The next thing is the definition of Me. For the purpose of this, Me is defined as the pattern of interaction of physical processes that happens within the volume bound by my skin. I will further refine to a concept of Sensory Me, which I will define as the pattern of interaction of physical processes that happens within my nervous system. I will further refine to a concept of the Conscious Me, which I will define as the pattern of interaction from the definition of Sensory Me, and it is separate from the physical processes of the same. With the definition of Conscious Me in place, what I am interested in is preserving the Conscious Me whether in its original form (i.e. implemented on top of original physical processes, that is embodied in a human body), or over a different substrate. Side note: if you disagree with my definitions, then please don't argue the conclusions using your own definitions. I consider it axiomatic that from different definitions we'll likely arrive at something different, so no argument is to be had really. It seems to me to be possible to one by one replace various physical processes with a different type that would result in supporting the same pattern of interaction (Conscious Me). The distinction I am making, is that I am interested in continuing the existing pattern (Conscious Me), hot-swapping, so to speak, the physical processes implementing it. This is the best illustration of why I feel uploading, which to me implies a copy, would be wrong and horrible. Because the existing pattern would then be discontinued as the uploaded pattern would be permitted to endure. More on computation... There is ample evidence, that I will sort of assume and handwave, that our Conscious Me's are capable of great flexibility and plasticity. For example, when I drive a car, my concept of me incorporates the machine I am operating. This effect is even more pronounced when piloting an aircraft. Or our ability to train our brains to see with our toungeshttp://www.scientificamerican.com/article.cfm?id=device-lets-blind-see-with-tongues I am very interested in the Hierarchical Temporal Memoryhttps://www.numenta.com/technology.html#cla-whitepaper(the HTM) model of how the human neocortex computes and a lot of my views about Conscious Me are informed by the HTM model. HTM proposes one algorithm, implemented on a certain physical architecture, that can give a rise to Metaphors We Live Byhttp://www.amazon.com/Metaphors-We-Live-By-ebook/dp/B006KYECYA/ref=tmm_kin_title_0types of thinking that human beings seem to have. The reason I am very interested in dynamic objects all the way down (types of systems VPRI is building) is because I am looking at them through the lens of preserving the Conscious Me. Fully dynamic objects running on hardware seem promising in this regard. The Actor Model also helps to frame some of the things through a slightly different lens, and hence my interest in it. Both seem to allow emergent behavior for processes that may in the future support Conscious Me. Admittedly, the interface between the two physical processes remains as a subject for future research. On Tue, Apr 23, 2013 at 10:11 AM, Loup Vaillant-David l...@loup-vaillant.frwrote: On Tue, Apr 23, 2013 at 04:01:20PM +0200, Eugen Leitl wrote: On Fri, Apr 19, 2013 at 02:05:07PM -0500, Tristan Slominski wrote: That alone seems to me to dismiss the concern that mind uploading would not be possible (despite that I think it's a wrong and a horrible idea personally :D) Personally, I can think of 2 objections: 1. It may turn out that mind uploading doesn't actually transfer your mind in a new environment, but actually makes a *copy* of you, which will behave the same, but isn't actually you. From the outside, it would make virtually no difference, but from the inside, you wouldn't get to live in the Matrix. 2. There's those cool things called privacy, and free will that can get seriously compromised if anyone but a saint ever get root access to the Matrix you live in. And we have plenty of reasons to abuse such a system.
Re: [fonc] Use case for graphical problem oriented widgets (POW, DSW)
I think Excel is interesting in this regard. The common idiom in excel is to employ user triggered code generation by fill formula to adapt the ui to dynamically resized collections. Not exactly automatic, but is it sufficiently trivial to group with or trivial ui operations such as scroll or resize window that might also be needed to not interfere with the display of the dynamic collection? BR John Den 21 apr 2013 07:59 skrev John Carlson yottz...@gmail.com: If you want a more complex use case, create a loop 10 times around the collection add loop to insert a calculator into the collection. On Apr 21, 2013 12:48 AM, John Carlson yottz...@gmail.com wrote: Here's a semipractical use case: add 1 to the display in each of a dynamic collection of calculators (math domain widgets). What can do this as end-user programming? It's fairly obvious that a textual language can do this. Can any graphical ones? Can something like lively kernel do this by demonstration? How about excel? With a dynamic collection? What will work on android jelly bean? I'm away from my desktop right now. On Apr 21, 2013 12:22 AM, John Carlson yottz...@gmail.com wrote: Looking for systems like this I found app-inventor activity starter on my phone. Has anyone tried this? On Apr 21, 2013 12:14 AM, John Carlson yottz...@gmail.com wrote: I believe the key to this is to create domain widgets. I am not sure if this needs to be something like etoys, maybe a combination between forth and etoys. I believe collections can make for interesting domain widgets. I have only programmed systems with collections of text. What systems work on collections of domain widgets? On Apr 21, 2013 12:02 AM, John Carlson yottz...@gmail.com wrote: Yeah, you're right. The theory is coming up with a syntax free language. Can you? On Apr 21, 2013 12:00 AM, David Barbour dmbarb...@gmail.com wrote: How is that a theory? Sounds like a design principle. On Sat, Apr 20, 2013 at 9:42 PM, John Carlson yottz...@gmail.comwrote: Here's my theory: reduce arguing with the compiler to minimum. This means reducing programmers' syntax errors. Only add syntax to reduce errors (the famous FORTRAN do loop error). The syntax that creates errors should be removed. On Apr 20, 2013 11:18 PM, John Carlson yottz...@gmail.com wrote: I think it's better to work from examples, ala JUnit and end-user programming than come up with a theory that solves nothing. One can compare EGGG to GDL in scope and expressiveness. One interesting part of gaming is arguing about rules. What computer systems do that? On Apr 20, 2013 11:09 PM, John Carlson yottz...@gmail.com wrote: Practice or practical? Maybe there's space for practical theory, instead of relying on things that don't exist. Why do we distinguish practice from theory? Seems like a fallacy there. On Apr 20, 2013 10:51 PM, David Barbour dmbarb...@gmail.com wrote: only in practice On Sat, Apr 20, 2013 at 8:23 PM, John Carlson yottz...@gmail.comwrote: Take my word for it, theory comes down to Monday Night Football on ESPN. On Apr 20, 2013 10:13 PM, John Carlson yottz...@gmail.com wrote: I think that concepts in some sense transcend the universe. Are there more digits in pi than there are atoms in the universe? I guess we are asking if there are transcendental volumes which are bigger or more complex than the universe. If the universe contains the transcendental as symbols then how many transcendental symbols are there? I think you still run into Russell's Paradox. On Apr 20, 2013 9:15 PM, Simon Forman forman.si...@gmail.com wrote: On 4/20/13, John Carlson yottz...@gmail.com wrote: Do you need one symbol for the number infinity and another for denoting that a set is inifinite? Or do you just reason about the size of the set? Is there a difference between a set that is countably infinite and one that isn't countable? I barely know Russell's paradox... you're ahead of me. Well, for what it's worth, quoting from Meguire's 2007 Boundary Algebra: A Simple Notation for Boolean Algebra and the Truth Functors: Let U be the universal set, a,b∈U, and ∅ be the null set. Then the columns headed by “Sets” show how the algebra of sets and the pa are equivalent. Table 4-2. The 10 Nontrivial Binary Connectives (Functors). NameLogic Sets BA Alternation a∨b a∪b ab Conditional a→b a⊆b (a)b Converse a←b a⊇b a(b) Conjunction a∧b a∩b ((a)(b)) ___ NOR a↓b a∪b (ab) ___ Sheffer stroke a|b a∩b (a)(b) Biconditionala↔b a⊆b⊆a (((a)b)(a(b))) -or- ((a)(b))(ab) (Apologies if the Unicode characters got mangled!) Check out http://www.markability.net/sets.htm also. I don't know much about set theory but I think the Universal set stands for the set of everything, no? Cheers, ~Simon The history of
Re: [fonc] Use case for graphical problem oriented widgets (POW, DSW)
I know those do, and I would expect any application claiming to be a spreadsheet to have that. Google spreadsheet actually have an interesting hybrid with its continue function that is automatically inserted to expand array results over a range of cells. BR John Den 21 apr 2013 10:00 skrev John Carlson yottz...@gmail.com: Excel is indeed interesting. Can google docs/libreoffice/OpenOffice do something similar? On Apr 21, 2013 2:52 AM, John Nilsson j...@milsson.nu wrote: I think Excel is interesting in this regard. The common idiom in excel is to employ user triggered code generation by fill formula to adapt the ui to dynamically resized collections. Not exactly automatic, but is it sufficiently trivial to group with or trivial ui operations such as scroll or resize window that might also be needed to not interfere with the display of the dynamic collection? BR John Den 21 apr 2013 07:59 skrev John Carlson yottz...@gmail.com: If you want a more complex use case, create a loop 10 times around the collection add loop to insert a calculator into the collection. On Apr 21, 2013 12:48 AM, John Carlson yottz...@gmail.com wrote: Here's a semipractical use case: add 1 to the display in each of a dynamic collection of calculators (math domain widgets). What can do this as end-user programming? It's fairly obvious that a textual language can do this. Can any graphical ones? Can something like lively kernel do this by demonstration? How about excel? With a dynamic collection? What will work on android jelly bean? I'm away from my desktop right now. On Apr 21, 2013 12:22 AM, John Carlson yottz...@gmail.com wrote: Looking for systems like this I found app-inventor activity starter on my phone. Has anyone tried this? On Apr 21, 2013 12:14 AM, John Carlson yottz...@gmail.com wrote: I believe the key to this is to create domain widgets. I am not sure if this needs to be something like etoys, maybe a combination between forth and etoys. I believe collections can make for interesting domain widgets. I have only programmed systems with collections of text. What systems work on collections of domain widgets? On Apr 21, 2013 12:02 AM, John Carlson yottz...@gmail.com wrote: Yeah, you're right. The theory is coming up with a syntax free language. Can you? On Apr 21, 2013 12:00 AM, David Barbour dmbarb...@gmail.com wrote: How is that a theory? Sounds like a design principle. On Sat, Apr 20, 2013 at 9:42 PM, John Carlson yottz...@gmail.comwrote: Here's my theory: reduce arguing with the compiler to minimum. This means reducing programmers' syntax errors. Only add syntax to reduce errors (the famous FORTRAN do loop error). The syntax that creates errors should be removed. On Apr 20, 2013 11:18 PM, John Carlson yottz...@gmail.com wrote: I think it's better to work from examples, ala JUnit and end-user programming than come up with a theory that solves nothing. One can compare EGGG to GDL in scope and expressiveness. One interesting part of gaming is arguing about rules. What computer systems do that? On Apr 20, 2013 11:09 PM, John Carlson yottz...@gmail.com wrote: Practice or practical? Maybe there's space for practical theory, instead of relying on things that don't exist. Why do we distinguish practice from theory? Seems like a fallacy there. On Apr 20, 2013 10:51 PM, David Barbour dmbarb...@gmail.com wrote: only in practice On Sat, Apr 20, 2013 at 8:23 PM, John Carlson yottz...@gmail.com wrote: Take my word for it, theory comes down to Monday Night Football on ESPN. On Apr 20, 2013 10:13 PM, John Carlson yottz...@gmail.com wrote: I think that concepts in some sense transcend the universe. Are there more digits in pi than there are atoms in the universe? I guess we are asking if there are transcendental volumes which are bigger or more complex than the universe. If the universe contains the transcendental as symbols then how many transcendental symbols are there? I think you still run into Russell's Paradox. On Apr 20, 2013 9:15 PM, Simon Forman forman.si...@gmail.com wrote: On 4/20/13, John Carlson yottz...@gmail.com wrote: Do you need one symbol for the number infinity and another for denoting that a set is inifinite? Or do you just reason about the size of the set? Is there a difference between a set that is countably infinite and one that isn't countable? I barely know Russell's paradox... you're ahead of me. Well, for what it's worth, quoting from Meguire's 2007 Boundary Algebra: A Simple Notation for Boolean Algebra and the Truth Functors: Let U be the universal set, a,b∈U, and ∅ be the null set. Then the columns headed by “Sets” show how the algebra of sets and the pa are equivalent. Table 4-2. The 10 Nontrivial Binary Connectives (Functors). NameLogic Sets BA Alternation a∨b a∪b ab Conditional a→b a⊆b (a)b Converse a←b
Re: [fonc] 90% glue code
One approach I've been thinking about is to invert the information hiding principle. The problem with information hiding is that the interface and properties exposed by a module is determined by the module: I am a... And some line is drawn between which properties are implementation details, and which are the contract. So I was thinking, what if the roles were swapped. What if modules could not declare a public contract but instead just had to conform to any type, interface or property that a client depending on it would care to declare as a requirement. In effect changing the module description into a collection of You are a... statements. Kind of similar to how a structural type allow any module conforming to the interface without the module having to implement a particular nominal type. For one, declaring a contract for a dependency is rather easy as it is based on local reasoning: What do I do, what do I need? as compared to What do I do, what do others need? Another benefit would be that there is no arbitrary reduction of the modules full capabilities. For example a Java List only implementing Iterable couldn't be used by clients requiring an ordered and finite sequence. I would expect this to encourage module writers to declare the smallest set of properties possible to depend on so that there would be more focus on information shielding, what information to expose one self to, rather than what information not to expose to others. The problem with this approach is that the proof of conformance can't come from the module, and it's hardly productive to require each client to provide one. I guess in some sense this is partly solved by a mechanism such as type classes as done in Scala or Haskell. One problem with this scheme though is that they do this by means of a static dispatch, making it impossible to specialize implementations by runtime polymorphism. While I haven't played with it, I do believe that Clojure has solved it while preserving runtime polymorphism. BR, John On Thu, Apr 18, 2013 at 3:13 AM, David Barbour dmbarb...@gmail.com wrote: Sounds like you want stone soup programminghttp://awelonblue.wordpress.com/2012/09/12/stone-soup-programming/. :D In retrospect, I've been disappointed with most techniques that involve providing information about module capabilities to some external configurator (e.g. linkers as constraint solvers). Developers are asked to grok at least two very different programming models. Hand annotations or hints become common practice because many properties cannot be inferred. The resulting system isn't elegantly metacircular, i.e. you need that 'configurator' in the loop and the metada with the inputs. An alternative I've been thinking about recently is to shift the link logic to the modules themselves. Instead of being passive bearers of information that some external linker glues together, the modules become active agents in a link environment that collaboratively construct the runtime behavior (which may afterwards be extracted). Developers would have some freedom to abstract and separate problem-specific link logic (including decision-making) rather than having a one-size-fits-all solution. Re: In my mind powerful languages thus means 98% requirements To me, power means something much more graduated: that I can get as much power as I need, that I can do so late in development without rewriting everything, that my language will grow with me and my projects. On Wed, Apr 17, 2013 at 2:04 PM, John Nilsson j...@milsson.nu wrote: Maybe not. If there is enough information about different modules' capabilities, suitability for solving various problems and requirements, such that the required glue can be generated or configured automatically at run time. Then what is left is the input to such a generator or configurator. At some level of abstraction the input should transition from being glue and better be described as design. Design could be seen as kind of a gray area if thought of mainly as picking what to glue together as it still involves a significant amount of gluing ;) But even design should be possible to formalize enough to minimize the amount of actual design decisions required to encode in the source and what decisions to leave to algorithms though. So what's left is to encode the requirements as input to the designer. In my mind powerful languages thus means 98% requirements, 2% design and 0% glue. BR John Den 17 apr 2013 05:04 skrev Miles Fidelman mfidel...@meetinghouse.net : So let's ask the obvious question, if we have powerful languages, and/or powerful libraries, is not an application comprised primarily of glue code that ties all the piece parts together in an application-specific way? David Barbour wrote: On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart st...@wart.ca mailto: st...@wart.ca wrote: On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich In real systems, 90% of code
Re: [fonc] 90% glue code
Maybe not. If there is enough information about different modules' capabilities, suitability for solving various problems and requirements, such that the required glue can be generated or configured automatically at run time. Then what is left is the input to such a generator or configurator. At some level of abstraction the input should transition from being glue and better be described as design. Design could be seen as kind of a gray area if thought of mainly as picking what to glue together as it still involves a significant amount of gluing ;) But even design should be possible to formalize enough to minimize the amount of actual design decisions required to encode in the source and what decisions to leave to algorithms though. So what's left is to encode the requirements as input to the designer. In my mind powerful languages thus means 98% requirements, 2% design and 0% glue. BR John Den 17 apr 2013 05:04 skrev Miles Fidelman mfidel...@meetinghouse.net: So let's ask the obvious question, if we have powerful languages, and/or powerful libraries, is not an application comprised primarily of glue code that ties all the piece parts together in an application-specific way? David Barbour wrote: On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart st...@wart.ca mailto: st...@wart.ca 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 dmbarb...@gmail.com mailto:dmbarb...@gmail.com wrote: On Mon, Apr 15, 2013 at 11:57 AM, David Barbour dmbarb...@gmail.com mailto:dmbarb...@gmail.com wrote: On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David l...@loup-vaillant.fr mailto: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 mailto:fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://vpri.org/mailman/listinfo/fonc __**_ fonc mailing list fonc@vpri.org mailto:fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://vpri.org/mailman/listinfo/fonc __**_ fonc mailing list fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://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/fonchttp://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Layering, Thinking and Computing
This discussion reminds me of http://www.ageofsignificance.org/ It's a philosophical analysis of what computation means and how, or if, it can be separated from the machine implementing it. The author argues that it cannot. If you haven't read it you might find it interesting. Unfortunately only the introduction is published as of today. BR John Den 12 apr 2013 20:08 skrev Tristan Slominski tristan.slomin...@gmail.com : I had this long response drafted criticizing Bloom/CALM and Lightweight Time Warps, when I realized that we are probably again not aligned as to which meta level we're discussing. (my main criticism of Bloom/CALM was assumption of timesteps, which is an indicator of a meta-framework relying on something else to implement it within reality; and my criticism of Lightweight Time Warps had to do with that it is a protocol for message-driven simulation, which also needs an implementor that touches reality; synchronous reactive programming has the word synchronous in it) - hence my assertion that this is more meta level than actors. I think you and I personally care about different things. I want a computational model that is as close to how the Universe works as possible, with a minimalistic set of constructs from which everything else can be built. Hence my references to cellular automata and Wolfram's hobby of searching for the Universe. Anything which starts as synchronous cannot be minimalistic because that's not what we observe in the world, our world is asynchronous, and if we disagree on this axiom, then so much for that :D But actors model fails with regards to extensibility(*) and reasoning Those are concerns of an imperator, are they not? Again, I'm not saying you're wrong, I'm trying to highlight that our goals differ. But, without invasive code changes or some other form of cheating (e.g. global reflection) it can be difficult to obtain the name of an actor that is part of an actor configuration. Again, this is ignorance of the power of Object Capability and the Actor Model itself. The above is forbidden in the actor model unless the configuration explicitly sends you an address in the message. My earlier comment about Akka refers to this same mistake. However, you do bring up interesting meta-level reasoning complaints against the actor model. I'm not trying to dismiss them away or anything. As I mentioned before, that list is a good guide as to what meta-level programmers care about when writing programs. It would be great if actors could make it easier... and I'm probably starting to get lost here between the meta-levels again :/ Which brings me to a question. Am I the only one that loses track of which meta-level I'm reasoning or is this a common occurrence Bringing it back to the topic somewhat, how do people handle reasoning about all the different layers (meta-levels) when thinking about computing? On Wed, Apr 10, 2013 at 12:21 PM, David Barbour dmbarb...@gmail.comwrote: On Wed, Apr 10, 2013 at 5:35 AM, Tristan Slominski tristan.slomin...@gmail.com wrote: I think it's more of a pessimism about other models. [..] My non-pessimism about actors is linked to Wolfram's cellular automata turing machine [..] overwhelming consideration across all those hints is unbounded scalability. I'm confused. Why would you be pessimistic about non-actor models when your argument is essentially that very simple, deterministic, non-actor models can be both Turing complete and address unbounded scalability? Hmm. Perhaps what you're really arguing is pessimistic about procedural - which today is the mainstream paradigm of choice. The imperial nature of procedures makes it difficult to compose or integrate them in any extensional or collaborative manner - imperative works best when there is exactly one imperator (emperor). I can agree with that pessimism. In practice, the limits of scalability are very often limits of reasoning (too hard to reason about the interactions, safety, security, consistency, progress, process control, partial failure) or limits of extensibility (to inject or integrate new behaviors with existing systems requires invasive changes that are inconvenient or unauthorized). If either of those limits exist, scaling will stall. E.g. pure functional programming fails to scale for extensibility reasons, even though it admits a lot of natural parallelism. Of course, scalable performance is sometimes the issue, especially in models that have global 'instantaneous' relationships (e.g. ad-hoc non-modular logic programming) or global maintenance issues (like garbage collection). Unbounded scalability requires a consideration for locality of computation, and that it takes time for information to propagate. Actors model is one (of many) models that provides some of the considerations necessary for unbounded performance scalability. But actors model fails with regards to extensibility(*) and
Re: [fonc] Layering, Thinking and Computing
Layering kind of implies a one dimensional space: lower vs. higher abstraction. Although we try hard to project other dimensions such as the why-how onto this dimension the end result is complex mess of concepts from different domains trying to fit in a way to small space. So besides layering we should probably also spend some effort in untangling those other dimensions and formalize how to map and compose things in all relevant dimensions without complecting them. BR John Den 7 apr 2013 06:00 skrev David Barbour dmbarb...@gmail.com: On Sat, Apr 6, 2013 at 7:10 PM, Julian Leviston jul...@leviston.netwrote: LISP is perfectly precise. It's completely unambiguous. Of course, this makes it incredibly difficult to use or understand sometimes. LISP isn't completely unambiguous. First, anything that is *implementation dependent* is ambiguous or non-deterministic from the pure language perspective. This includes a lot of things, such as evaluation order for modules. Second, anything that is *context dependent* (e.g. deep structure-walking macros, advanced uses of special vars, the common-lisp object system, OS and configuration-dependent structure) is not entirely specified or unambiguous when studied in isolation. Third, any operation that is non-deterministic (e.g. due to threading or heuristic search) is naturally ambiguous; to the extent you model and use such operations, your LISP code will be ambiguous. Ambiguity isn't necessarily a bad thing, mind. One can consider it an opportunity: For live coding or conversational programming, ambiguity enables a rich form of iterative refinement and conversational programming styles, where the compiler/interpreter fills the gaps with something that seems reasonable then the programmer edits if the results aren't quite those desired. For mobile code, or portable code, ambiguity can provide some flexibility for a program to adapt to its environment. One can consider it a form of contextual abstraction. Ambiguity could even make a decent target for machine-learning, e.g. to find optimal results or improve system stability [1]. [1] http://awelonblue.wordpress.com/2012/03/14/stability-without-state/ is it possible to build a series of tiny LISPs on top of each other such that we could arrive at incredibly precise and yet also incredibly concise, but [[easily able to be traversed] meanings]. It depends on what you want to say. Look up Kolmogorov Complexity [2]. There is a limit to how concise you can make a given meaning upon a given language, no matter how you structure things. [2] http://en.wikipedia.org/wiki/Kolmogorov_complexity If you want to say a broad variety of simple things, you can find a language that allows you to say them concisely. We can, of course, create a language for any meaning Foo that allows us to represent Foo concisely, even if Foo is complicated. But the representation of this language becomes the bulk of the program. Indeed, I often think of modular programming as language-design: abstraction is modifying the language from within - adding new words, structures, interpreters, frameworks - ultimately allowing me express my meaning in just one line. Of course, the alleged advantage of little problem-oriented languages is that they're reusable in different contexts. Consider that critically: it isn't often that languages easily work together because they often have different assumptions or models for cross-cutting concerns (such as concurrency, persistence, reactivity, security, dependency injection, modularity, live coding). Consider, for example, the challenge involved with fusing three or more frameworks, each of which have different callback models and concurrency. Your proposal is effectively that we develop a series (or stack) of little languages for specific problem. But even if you can express your meaning concisely on a given stack, you will encounter severe difficulty when comes time to *integrate* different stacks that solve different problems. (Some people are seeking solutions to the general problem of language composition, e.g. with Algebraic Effects or modeling languages as Generalized Arrows.) one could replace any part of the system because one could understand any part of it Sadly, the former does not follow the latter. The ability to understand any part of a system does not imply the ability to understand how replacing that part (in a substantive way) will affect the greater system. E.g. one might look into a Car engine and say: hmm. I understand this tube, and that bolt, and this piston... but not really grok the issues of vibration, friction and wear, pressure, heat, etc.. For such a person, a simple fix is okay, since the replacement part does the same thing as the original. But substantive modifications would be risky without more knowledge. Today, much software is monolithic for exactly that reason: to understand a block of code often
Re: [fonc] [talk] Cool Code - Kevlin Henney
Isn't the pattern language literature exactly that? An effort to typeset and edit interesting design artifacts. BR John Den 2 dec 2012 10:30 skrev Iian Neill iian.d.ne...@gmail.com: Benoit, I would very much like to read source code more often, as I suspect would many others, but I think the problem lies in the fact that few coders or publishers seem to think that code is worth studying. I know that sounds outrageous but the simple fact is that there are many intellectual artefacts as difficult as source code that are published and read avidly - e.g., scientific articles, mathematical proofs, philosophical essays, musicological analysis, poetry, etc. in these fields publication is considered essential to the culture and energy and creativity is found to typeset and edit these artefacts. In programming, the written analysis of programme design only ever seems to happen in computer science textbooks, such as SICP, etc. I am often curious enough to look at the source code of some library, but are usually discouraged by the lack of organisation in the presentation. Object oriented code is particularly hard to get a handle on, compared to structured programme examples in textbooks, as there an awful lot of boilerplate that obscures the architecture. Technical documentation seems to be the only way to get a mental map but it is often a dry overview that fails to capture the thought process that went into the design. Sometimes I'm lead to the melancholy conclusion that programme analysis -- I mean analysis in the sense of a critical analysis of poetry (like William Empson's) or of art (like John Ruskin or Kenneth Clark) -- isn't done because the programmer and the community thinks of the code artefacts as obscolescent -- i.e., it will be out of date soon, so why bother. Why else no serious critical activity devoted to such a serious mental activity? Where are the software critics? Regards, Iian Sent from my iPhone On 02/12/2012, at 11:41 AM, Benoît Fleury benoit.fle...@gmail.com wrote: Although programming is a discipline with a very large canon of existing work to draw from, the only code most programmers read is the code they maintain. This topic came up a few times on this mailing list so I thought I would share this talk I found interesting. https://yow.eventer.com/yow-2012-1012/cool-code-by-kevlin-henney-1181 - Benoit ___ 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] [talk] Cool Code - Kevlin Henney
Yes.
Hence you write a pattern language and spare people the agony of reading
the programs it was discovered in.
Which was precisely my point. Maybe this is is why we dont read programs
and why we instead have pattern literature as our primary means of
communicating interesting design ideas.
BR
John
Den 2 dec 2012 14:18 skrev Pascal J. Bourguignon p...@informatimago.com:
John Nilsson j...@milsson.nu writes:
Isn't the pattern language literature exactly that? An effort to
typeset and edit interesting design artifacts.
Unless you're programming in lisp(*), reading a program written with
patterns is like looking at the wave form of Hello world! said aloud.
(*) See:
http://groups.google.com/group/comp.lang.lisp/msg/ee09f8475bc7b2a0
http://groups.google.com/group/comp.programming/msg/9e7b8aaec1794126
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] [talk] Cool Code - Kevlin Henney
Agreed.
A program is very context dependent in my experience thought. So you'd
probably also want a pretty good record of the people and the environment
in which it was created to make sens of it.
BR
John
Den 2 dec 2012 14:37 skrev Julian Leviston jul...@leviston.net:
Concrete is better than abstract for learning.
Julian
On 03/12/2012, at 12:23 AM, John Nilsson j...@milsson.nu wrote:
Yes.
Hence you write a pattern language and spare people the agony of reading
the programs it was discovered in.
Which was precisely my point. Maybe this is is why we dont read programs
and why we instead have pattern literature as our primary means of
communicating interesting design ideas.
BR
John
Den 2 dec 2012 14:18 skrev Pascal J. Bourguignon p...@informatimago.com
:
John Nilsson j...@milsson.nu writes:
Isn't the pattern language literature exactly that? An effort to
typeset and edit interesting design artifacts.
Unless you're programming in lisp(*), reading a program written with
patterns is like looking at the wave form of Hello world! said aloud.
(*) See:
http://groups.google.com/group/comp.lang.lisp/msg/ee09f8475bc7b2a0
http://groups.google.com/group/comp.programming/msg/9e7b8aaec1794126
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] How it is
I read that post about constraints and kept thinking that it should be the infrastructure for the next generation of systems development, not art assets :) In my mind it should be possible to input really fuzzy constraints like It should have a good looking, blog-like design A search engine would find a set of implications from that statement created by designers and vetted by their peers. Some browsing and light tweaking and there, I have a full front-end design provided for the system. Then I add further constraints. Available via http://blahblah.com/ and be really cheap, again the search engine will find the implied constrains and provide options among the cheaper cloud providers. I pick one of them and there provisioning is taken care of. I guess the problem is to come up with a way to formalize all this knowledge experts are sitting on into a representation usable by that search engine. But could this not be done implicitly from the act of selecting a match after a search? Say some solution S derived from constrains A,B,C is selected in my search. I have constraint A,B and D as input. By implication the system now knows that S is a solution to D. BR, John On Wed, Oct 3, 2012 at 11:09 PM, David Barbour dmbarb...@gmail.com wrote: I discuss a similar vision in: http://awelonblue.wordpress.com/2012/09/12/stone-soup-programming/ My preferred glue is soft stable constraint logics and my reactive paradigm, RDP. I discuss a particular application of this technique with regards to game art development: http://awelonblue.wordpress.com/2012/09/07/stateless-stable-arts-for-game-development/ Regards, Dave On Wed, Oct 3, 2012 at 8:10 AM, Loup Vaillant l...@loup-vaillant.fr wrote: De : Paul Homer paul_ho...@yahoo.ca If instead, programmers just built little pieces, and it was the computer itself that was responsible for assembling it all together into mega-systems, then we could reach scales that are unimaginable today. […] Sounds neat, but I cannot visualize an instantiation of this. Meaning, I have no idea what assembling mechanisms could be used. Could you sketch a trivial example? Loup. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- bringing s-words to a pen fight ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] How it is
On Thu, Oct 4, 2012 at 1:06 AM, Pascal J. Bourguignon p...@informatimago.com wrote: And who has the resources to do this work: it seems to me to be a big endeavour. Collecting the research prototype developed during the last 50 years, and develop a such a product. I'm not sure it has to be that big of an effort. Most of the work is already being performed. From my previous examples we have projects like twitter bootstrap and htm5 boilerplate being created for the infrastructure, and surrounding that people are creating templates for various frameworks. In the middle we have organizations like google to keep it all accessible to the people gluing it together. Provided even a remote possibility of being indexed and somewhat intelligently filtered I'm sure google will solve the search part. So what's needed could be just the right type of glue for automating scaffolding and bootstrap tasks in a more general sense and some software to take advantage of it. Given that this software makes some step easier for people it could be enough to direct efforts toward formalizing the required meta data. And then you iterate :) BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deployment by virus
More work relative to an approach where full specification and controll is feasible. I was thinking that in a not to distant future we'll want to build systems of such complexity that we need to let go of such dreams. It could be enough with one system. How do you evolve a system that has emerged from som initial condition directed by user input. Even with only one instance of it running you might have no way to recreate it so you must patch it, and given sufficient complexity you might have no way to know how a binary diff should be created. BR, John Den 19 jul 2012 13:54 skrev Pascal J. Bourguignon p...@informatimago.com: ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Deployment by virus
I just had a weird though, maybe there is some precedence? If we were to do software development in a more organic manner, accepting the nature of complex systems as being... complex. In such a setting we might have no blue-print (static source code) to usable for instantiating new live systems ex nihilo, or the option to take down existing systems to deploy an upgrade. The code running the nodes can be the result of wild mutation or complex generative algorithms. A mode of development could be to work on prototypes in a lab, a clone or an isolated node from the production system. When the desired properties are created in the prototype they would then spread through the production system by means of a virus which would adapt the new properties to the running instances individually according to their unique configuration. Is it feasible? Would it provide new options? Any research done in this direction? BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Deployment by virus
Random as in where it's applied or random in what's applied? I was thinking that the viral part was a means to counter the seeming randomness in an otherwise chaotic system. Similar in spirit in how gardening creates some amount of order and predictability, a gardener who can apply DNA tweaks as well as pruning. As I understand it CFEngine does something like this wile limited to simple configuration. BR, John On Thu, Jul 19, 2012 at 3:55 AM, Pascal J. Bourguignon p...@informatimago.com wrote: Joke apart, people are still resiting a lot to stochastic software. One problem with random spreading of updates is that its random. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Historical lessons to escape the current sorry state of personal computing?
On Mon, Jul 16, 2012 at 2:20 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: question becomes: is this a separate discipline, or is it something to be incorporated into math and science? This question is examined at length here: http://www.ageofsignificance.org/ (Unfortunately something seems to have derailed the plan to publish the chapters) BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Scala Days 2012 and ACP
I think one of the video links are wrong, should they both be the same? BR, John Den 20 apr 2012 01:57 skrev Andre van Delft andre.vande...@gmail.com: Scala Days 2012 was held this week in London; 400 passionate developers; many presentations on DSLs, parallelism, concurrency, FP, compiler technology and much other stuff. http://days2012.scala-lang.org/ Enthusiastic tweets: https://twitter.com/search/scaladays The keynotes were by Guy Steele, Simon Peyton-Jones, Anthony Rose ( http://zeebox.com/) and Martin Odersky; I warmly recommend these, but right now the videos are not yet online. Twelve year old Shadaj Laddad had an awesome talk; he is a real good programmer, and maybe even better teacher. The video is here: http://skillsmatter.com/podcast/scala/subscript-extending-scala-with-the-algebra-of-communicating-processes I presented my language extension based on the Algebra of Communicating Processes; I have mentioned this theory a couple of times here the Fonc list. ACP may be viewed as extending Boolean Algebra with actions, and from there parallelism and communication. With some syntactic sugar added, it has much of the power of BNF, CCS, Linda, pipes in Unix command shell. Implementation as a language extension turns out to be fairly easy. I think ACP deserves much more attention than it currently gets; it might IMO become as important as the object-oriented and functional paradigms. The video of my talk is here: http://skillsmatter.com/podcast/scala/subscript-extending-scala-with-the-algebra-of-communicating-processes The sheets and accompanying paper are at http://code.google.com/p/subscript/downloads/list André ___ 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] Naive question
Maybe not what you are looking for, but you might find http://awelon.org/ interesting. BR, John 2012/3/19 Benoît Fleury benoit.fle...@gmail.com: Hi, I was wondering if there is any language out there that lets you describe the behavior of an object as a grammar. An object would receive a stream of events. The rules of the grammar describe the sequence of events the object can respond to. The semantic actions inside these rules can change the internal state of the object or emit other events. We don't want the objects to send message to each other. A bus-like structure would collect events and dispatch them to all interested objects. To avoid pushing an event to all objects, the bus would ask first to all objects what kind of event they're waiting for. These events are the possible alternatives in the object's grammar based on the current internal state of the object. It's different from object-oriented programming since objects don't talk directly to each other. A few questions the come up when thinking about this: - do we want backtracking? probably not, if the semantic actions are different, it might be awkward or impossible to undo them. If the semantic actions are the same in the grammar, we might want to do some factoring to remove repeated semantic actions. - how to represent time? Do all objects need to share the same clock? Do we have to send tick events to all objects? - should we allow the parallel execution of multiple scenarios for the same object? What does it make more complex in the design of the object's behavior? What does it make simpler? If we assume an object receive a tick event to represent time, and using a syntax similar to ometa, we could write a simplistic behavior of an ant this way: # the ant find food when there is a food event raised and the ant's position is in the area of the food # food indicates an event of type food, the question mark starts a semantic predicate findFood = food ?(this.position.inRect(food.area)) # similar rule to find the nest findNest = nest ?(this.position.inRect(nest.area)) # at every step, the ant move move = tick (= move 1 unit in current direction (or pick random direction if no direction)) # the gatherFood scenario can then be described as finding food then finding the nest gatherFood = findFood (= pick up food, change direction to nest) findNest (= drop food, change direction to food source) There is probably a lot of thing missing and not thought through. But I was just wondering if you know a language to do this kind of things? Thanks, Benoit. ___ 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] Alan Kay talk at HPI in Potsdam
On Tue, Jul 26, 2011 at 8:16 AM, BGB cr88...@gmail.com 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
Re: [fonc] Alternative Web programming models?
On Mon, Jun 13, 2011 at 9:26 PM, Julian Leviston jul...@leviston.net wrote: ... also, the idea of modelling change ITSELF is an appealing one in this context, and all changes including data entry etc being simply represented as a log of mutations using the command pattern. Thus the data represented in the first world would be mutated and propagated to the new world (actually more like the view of it filtered or some-such) according to the new rules, and the inverse would apply as well... There might be some experience on this in the CQRS-community. They usually model systems with event sourcing as the primary representation of state and have to deal with the versioning issues. Then there's the experience with working with databases, both relational and OO. The practice that seems to work is to model new versions in a backwards-compatible way and then refactor once the old versions has been completely shut down. My own thinking in this area is that you handle merges automatically if you can but fall back on manual intervention if not. Hopefully the system has a user-base that knows what to do with inconsistent data. In any case I guess the default behaviour when branching is to simply diverge, merges in any direction, should only happen if asked to, and when asked to. The Git workflow seems to work very well. If there is anything broken with it it is that it tends to express dependencies that aren't really there, but that isn't a fundamental property of the DAG-model just a consequence of how the tools steers you. The Darcs approach with it's theory of patches be better in this regard, have no experience working with it though. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Mon, Jun 13, 2011 at 10:02 PM, BGB cr88...@gmail.com wrote: but, what would be the gain?... the major issue with most possible graphical representations, is that they are far less compact. hence, the common use of graphical presentations to represent a small amount in information in a compelling way (say, a bar-chart or line-graph which represents only a small number of data-points). I too have been thinking that the textual representation has to go. Not to replace it with fancy icons but mainly to remove the limits imposed by parsing, but also to make graphical representations available, for example tables is a language construct I usually miss, arrays of arrays of objects just doesn't cut it. By parsing limits I mean the fact that the language grammar usually has to be more verbose than is required by a human to resolve ambiguity and other issues. This is mainly a problem if you start thinking of how to mix languages. To integrates say Java, SQL and regular expressions in one grammar. Sure it can be done by careful attention to the grammar, like PL/SQL f.ex. but how do you do it in a generic way such that DSLs can be created as libraries by application programmers? BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
Thanks for the pointer. I'll have a look. BR, John Sent from my phone Den 14 jun 2011 17:17 skrev Tristan Slominski tristan.slomin...@gmail.com : I had some thoughts about how to approach the issue. I was thinking that you could represent the language in a more semanticaly rich form such as a RAG stored in a graph database. Then languages would be composed by declaring lenses between them. As long as there is a lens to a editor dsl you could edit the labguage in that editor. If you had a lens from SQL to Java (for example via jdbc) you could ebed SQL expressions in java code. Give transitive lenses it would also be a system supporting much reuse. A new DSL could then leverage the semantic editing support allredy created for other languages. BR, John Just for completeness, the lenses you describe here remind me of OMeta's foreign rule invocation: from http://www.vpri.org/pdf/tr2008003_experimenting.pdf see 2.3.4 Foreign Rule Invocation p. 27 of paper, p. 46 of pdf So, if you don't like the PEG roots of OMeta, perhaps it's a good reference that already works? Cheers, Tristan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On Tue, Jun 14, 2011 at 5:14 PM, Tristan Slominski
tristan.slomin...@gmail.com wrote:
Just for completeness, the lenses you describe here remind me of OMeta's
foreign rule invocation:
from http://www.vpri.org/pdf/tr2008003_experimenting.pdf
see 2.3.4 Foreign Rule Invocation p. 27 of paper, p. 46 of pdf
So, if you don't like the PEG roots of OMeta, perhaps it's a good reference
that already works?
The foreign rule invocation let you reuse other grammar but you still
have to carefully declare how the merged grammar should behave. What I
as aiming for was a more dynamic approach in that the merged grammar
doesn't exist as such but is just an execution state derived from the
combined program fragments and available lenses. To continue the
Java/SQL example, lets say I had a program like this:
public int totalAmmount(InvoiceNo invoceNo) {
return SELECT SUM(ammount) FROM Invoices WHERE invoiceNo = :InvoiceNo;
}
To make this work I would need three things
1. The java grammar in which the method is declared
2. The SQL grammar in which the expression is declared
3. Something that can translate an SQL expression to a Java
expression, and Java type-errors to SQL type-errors (the lens).
4. A way to annotate the syntax to distinguish Java-syntax from SQL-syntax.
It is step 4 that I think makes it hard to keep a text representation.
A generic syntax to separate any given language would probably be very
convoluted. OTOH extending all languages one want to include to
support grammar switches means that you will end up having to create
those extensions yourself (which could be hard) or live at the mercy
of the syntax-component you depend on. So my fix is to make the
separation a hidden thing, which means the program needs to be
represented in something that allows such hidden things (and I don't
think Unicode control characters is the way to go here).
Btw, if it wasn't clear form the context before, by RAG I meant a
Reference Attributed Grammar.
BR,
John
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On both questions the answer is basically that Java was an example. I was looking for a general solution. Something that would work withoug prior assumptions about the languages involved. The problem I was thinking about was how to provide an infrastructure where in anyone could be a language designer and almost for free get all the tooling support required for the language to gain traction. It seems to me that the effort required to go from an itch to a fully mainstream language is way to high. And partly to blame why we are still introducing inventions from the sixties in current mainstream languages. BR, John Sent from my phone Den 14 jun 2011 22:10 skrev BGB cr88...@gmail.com: ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
Let say I want this then:
public int totalAmmount()
{
return SELECT SUM(ammount) FROM Invoices WHERE invoiceNo =
Invoice.currentId();
}
That is now there is Java nested inside the SQL. When I ask the IDE to
list all references to Invoice.currentId(), this instance should also
be included.
There was some paper on macros that solved this with varios nestings
of ?() or some such construct. But that isn't very readable when you
add lots of back and forth.
Oh well, it isn't a project I'm working actively on, just a wild idea
for the future ;-)
BR,
John
2011/6/15 Ondřej Bílka nel...@seznam.cz:
On Tue, Jun 14, 2011 at 01:04:20PM -0700, BGB wrote:
On 6/14/2011 12:14 PM, Michael FIG wrote:
Hi,
John Nilssonj...@milsson.nu writes:
So my fix is to make the separation a hidden thing, which means the
program needs to be represented in something that allows such hidden
things (and I don't think Unicode control characters is the way to go
here).
Why not crib a hack from JavaDoc and make your nested syntax embedded in
comments in the host language?
or, like in my languages (generally for other things):
use a keyword...
reusing prior example:
public int totalAmmount(InvoiceNo invoceNo)
{
return SQLExpr {
SELECT SUM(ammount) FROM Invoices WHERE invoiceNo = :InvoiceNo;
}
}
Well you can embed languages easily using fact that in any sane language
parenthness match
unless you areb inside string.
You could get pretty strong preprocessor in few lines like my preprocessor
which I attach.
It has one command
register(name,command)
which replaces all subsequent occurences of name(args){properly parenthized
text}
by output of command with args given and text pasted as input.
--
Big to little endian conversion error
___
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] Question about OMeta
, e,g, imagine a SQL injection attack. Likewise, we might wish to re-use validation logic in multiple places, such as in an HTML form, and it is not sufficient to depend on the HTML form's JavaScript validation logic, since JavaScript can be disabled and the browser can be bypassed completely using raw encoding of HTTP PUT/POST form actions and sending that directly to the server. Food for thought. [1] http://www.google.com/search?q=how+to+add+a+column+to+a+large+table [2] http://martinfowler.com/articles/evodb.html [3] http://databaserefactoring.com/ [4] http://guides.rubyonrails.org/migrations.html [5] http://www.mecs-press.org/ijigsp/ijigsp-200901007.pdf [6] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.6252 [7] http://z-bo.tumblr.com/post/454811730/learning-to-map-between-structured-representations-of On 4/10/11, John Nilsson j...@milsson.nu wrote: Hello John, Thanks for the pointers, I will indeed have a look at this. I have a pet project of mine trying to create a platform and prgramming model to handle this kind of problem. Such a simple thing as keeping referential integritey between static Java code, the embedded SQL and over to the dynamic databas is one of those irritating problems I intend to address with this approach. I enviosion a system with a meta-language and some standard transformation to editor views, compilation stages and type-systems, implemented in terms of this meta-language. BR, John On Sun, Apr 10, 2011 at 4:38 AM, John Zabroski johnzabro...@gmail.com wrote: John, It is true you can't know exact intention but that hasn't stopped computer scientists from trying to answer the question. For example, Joe Goguen's work on algebraic semiotics resulted in Joe developing a few basic rules for mapping information from one medium to another. Joe's first rule was Wherever possible, preserve the structure of the content. I could think of... and have thought of... a lot of techniques for automatically porting code (an extremely difficult problem, considering it covers correct live migration from an Intel to an adversarial AMD processor with possibly deliberately incompatible Instruction Set Architecture), including ways to automatically trade-off structure with other goals in a controlled fashion. One that Goguen was interested in was content mixing or predictive modeling - hot buzzwords before the AI Winter came and dried up lots of interesting funding. It is starting to re-emerge because of the multi-core kerfluffle, since it can achieve the sorts of parallel-busyness chipmaker's crave. I'd recommend Mark Turner's paper Forging Connections, which suggests some meaning belong to the mapping itself, rather the source-target approaches. In other words, we tend to construct meaning in a blend between the source and target. We don't just have mappings-as-meanings , but forge meaning *from* mapping. (I hope I explained that well.) On 4/9/11, John Nilsson j...@milsson.nu wrote: I would think that it is generally impossible to automatically extract intentions from code. I run into this wall every day at work, I know _what_ the code is doing. But there is often little information as to _why_ it does what it does. It's not only due to the fact that the program is shaped by the idioms and constraints by the host language it is also the fact that the host language in general is a machine description language not a general problem statment language. I guess you are referring to the first problem when you talk about expressibility. To address the second problem I'm thinking that you have to seperate the problem description, and solution from machine specifications. That is have a programming model where you create languages specifically to encode the problem, and then create an intepreter for the language to create machines solving it. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] visual environments created by present/former VPRI staff
I think Subetextual[1] deserves a mention. [1] http://www.subtextual.org/ BR, John On Wed, Mar 30, 2011 at 4:09 PM, John Zabroski johnzabro...@gmail.com wrote: I am trying to round up all visual programming kit research written by you folks, so that I can then compile a biography that I can read in one sitting. So far I have: CIA Agent Playground Squeak Skeleton Fabrik What else should I include? Thanks, Z-Bo ___ 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] Program representation
Hi, When reading about the TCP/IP implementation in OMeta it strikes me that parsing the ASCII-art is still text. Isn't it kind of silly to spend all that syntax on representing something as fundamental as a table? So I was wondering, have you, at vpri, been contemplating alternative program representations besides text? It seems to me that if you had a richer model of representation it would be easier to make readable code. The stuff that Jonathan Edwards been working on at http://subtextual.org/ has been very inspiring for my own thinking on these matters. Representing conditionals as tables seems like a brilliant approach. For my self I was thinking that maybe one could embed a programming language on top of a more graphical language, like HTML and see what comes out of it. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
On Mon, May 10, 2010 at 6:54 PM, John Zabroski johnzabro...@gmail.comwrote: Schematic tables are a separate issue entirely. First of all. Thanks for the explanation about the thinking wrt the TCP/IP implementation. I'll have to peruse the code with that in mind. My questions was, as you pointed out, about a separate issue entirely. The ASCII-art was just the trigger for my question. My concern/thinking was rather that the if the aim of the project is to make programs simpler, one dimension worth exploring is the media used to convey the program to humans. In the end it all boils down to communication between humans. I'm mainly involved in ERP-development, an area I understand is not addressed by this project, which focuses more on the desktop. I do think most of the thinking is transferable though, and in my experience one of the biggest code smells is when one basically transcribes requirements and specifications perfectly legible for humans into something legible for the computer, a process that unfortunately results in lots of information loss. I can for example imagine that instead of writing some comments about where a piece of code comes from one could ideally just include the entire discussion thread that resulted in the code, complete with presence indicators and all. Maybe even have the system suggest updates when involved parties leaves the organisation. Another thing worth exploring is to add graphical examples executing the code in question. The elusive sine functions would probably be better described by a simple wave plot, or a unit circle diagram with the relationships plotted on it, than a formal description of its algebraic properties. Basically code is not only about computing, it's also about communicating with humans. So if the code can be expressed in a rich media I think lots could be made about it's simplicity. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
On Mon, May 10, 2010 at 8:55 PM, John Zabroski johnzabro...@gmail.comwrote: Can you provide an end-to-end exemplary situation in Enterprise Resource Planning (ERP) software where FONC ideas are relevant? You sort of jumped off that stream of thought and onto modeling sine waves graphically, etc. Depends on what you mean with end-to-end. I can definitely see how a meta language like OMeta or M can come in handy to define up DSL for various tasks like data transfer or GUI definitions. The chain of meaning is really important to separate the meanings that are tied to actual business meaning from the technical approach. I envision a system where you describe high level business goals and flows in a language entirely free of technical junk. I wonder how much of the architecture and implementation that could be derived from such a high level. Another thought is that I think a good business system should be flexible enough to allow users to program it according to their whims. Possibly with the assistance of a department specific developer. To enable this while still maintaining the integrity of the system will be a interesting challenge. I work in various roles of ERP/CRM/BI software, and so I understand the domain very well When I said ERP I was actually thinking the whole suite of applications like CRM and BI too. The system I base my experience on is a rather simple system. A single webserver against a single rdbms handling a few hundred users developed and maintained by a single team of developers, but enough interfacing with other systems and teams to feel the pain. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
On Mon, May 10, 2010 at 11:29 PM, BGB cr88...@hotmail.com wrote: like having documentation in a hypertext form, and having code contain links into the docs, and from the docs back into the code?... For example. I guess it would be a notable improvement on having to edit external files for the documents, and an improvement on javadocs-style comments (which make code less readable by sticking large gobs of text in the middle of it...). Another improvement would be to get rid of the inherent ordering and context of a text file. Instead one could surround a piece of code, i.e. a method, with context relevant that piece such as dependencies, usages, supplements and complements. The code bubbles project is very interesting in that regard. well, I guess some people like flowcharts/..., but personally I don't like them all that much (or, at least on the small-scale). I can more easily imagine them being used to describe things like library dependencies, ... but, when used to describe code, one almost may as well just be using assembler... Have a look at Conal Elliotts Tangible Functional Programming http://conal.net/blog/posts/tangible-functional-programming-a-modern-marriage-of-usability-and-composability/ he has some interesting examples of a style of visual programming that might actually be useful. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
