On Fri, Sep 20, 2013 at 2:57 PM, Matt McLelland <mclelland.m...@gmail.com>wrote:
>
> I would say that in my experience text is a much better construct form for
> most programs than those other forms, so I would expect text to be the 95%
> case. I'm including in that more structured forms of text like tables.
>
If you look at PL, text has been more effective. Graphical
programming is historically very first-order and ineffective at addressing
a variety of problems.
If you look at UI, text input for control has been much less effective, and
even text output is often augmented by icons or images. The common case is
buttons, sliders, pointing, and so on. Some applications also use concepts
of tooled pointers like brushes, or tooled views like layering.
I've tried to explain this before: I see UI as a form of PL, and vice
versa. Thus, to me, the 95% case is certainly not text. Rather, most users
today are using a really bad PL (<- the 95% case), and most programmers
today are using a really unnatural UI (<- and thus need to be really
serious about it), and this gap is not essential.
>
> What I'm still not understanding is how viewing the editing of an image or
> graph as a tacit concatenative program is a big win.
>
Have you ever used a professional image editing tool?
If you haven't, the process actually does involve quite a bit of
automation. The artist implicitly constructs a small pipeline of layers and
filters based on the actions they perform. This pipeline can often then be
separated from the current image and applied to another. Essentially, you
have implicit macros and a limited form of programming-by-example.
But, with the way applications are designed today, this pipeline is trapped
within the image editing application. You cannot, for example, casually
apply a pipeline of filters to a view of a website. Conversely, you cannot
casually incorporate an image search into layers or elements in an image.
Either of these efforts would require a lot of file manipulation by hand,
but that effort would not be reusable.
If you are an artist with a hobby of hacking code, you could:
* don your programmer hat
* fire up your favorite IDE and textual PL
* go through the steps of starting a new project
* review the APIs for HTTP loading
* review the APIs for Filesystem operations
* review the APIs for your image-editing app
* oh bleep! doesn't have one!
* review the APIs for image processing
* export your pipeline
* begin implementing a parser/interpreter for them
* who the bleep designed this pipeline language?!
* abort your effort to implement a general interpreter/parser
* re-implement your pipeline in your language
* ugh... who designed these validation tools?
* 'Image'? type system ain't worth a bleep here...
* unit tests on images? how does that even work?
* it's a wall of text! I can't see what's going on!!
* review your API for image display
* integrate image display into your tests
* edit test edit test edit test edit test
* woohoo! It works!
* but the test-case is hard-coded in :(
* contemplate building a configuration language
* bleep that! I'm a hacker.
* just edit and hard-code in the next use case...
* and the next, and the next
(years of bitrot later)
* why don't these APIs work anymore?!
* (I really don't want to review them again)
* where are those configuration variables scattered?
And that's only if you happen to be in the small intersection of artists
who have a hobby of hacking. If you're a 'serious' programmer you might
have gone the extra steps to import the pipeline and build a configuration
file. But the overall experience wouldn't be that much different.
If you're anyone else, you might contemplate hiring a programmer. But you
think: that's expensive, and I don't off hand know any programmer with
skills in image-processing who is also looking for work, and I don't want
to pay a programmer to self-educate. So you end up addressing the specific
problem by hand. Or you just abandon the effort.
That experience shouldn't need to happen.
But because UIs are bad PLs today, it is very difficult to integrate the
capabilities of different services, toolkits, and APIs. Conversely, because
PLs are bad UIs today, we build these thick layers we call 'applications'
between users and the underlying capabilities. Of course, most programmers
don't think about UI as PL. And even if they do, most are bad PL designers.
And even those who aren't, don't have access to or examples of UI toolkits
designed to support UI as an effective PL. It's a vicious cycle that has
only been broken by a few small niche communities (like REBOL).
> I'm skeptical that non-programmers will ever do serious programming.
>
I don't expect non-programmers to do "serious programming". I expect to
lower barriers so that "serious programming" is very rarely needed, and
such that when it is needed it can be handled as a tiny extension to an
app, or a small composition, rather than a full new app. The goal: Serious
programming is only needed 5% as often. And, when needed, costs only 5% as
much.
Programming should not be a career.
Programming should be the most basic form of computer literacy - such that
people don't even think about it as "programming".
A scientist who knows how to get big-data into one application and process
it in another should be able to build a direct pipeline - one that
optimizes away the intermediate loading - without ever peeking under the
hood, without learning an API.
A musician who knows how to watch YouTube videos, and who has learned of a
cool new machine-learning tool to extract and characterize microsounds,
should be able to apply the latter to the sounds from the former without
learning about HTTP and video transfer and how to scrape sounds from a
video. Further, it's better for both the artist and servers if this
processing can automatically be shifted close to the resources and
eliminates the irrelevant video rendering.
Artists, scientists, musicians, anyone should be able to think in terms of
capabilities:
* I can get an X
* I can get a Y with an X
* therefore, I can get a Y
But today, because UIs are bad PLs, they cannot. Instead, we have this
modal illogic:
* [app1] I can get X
* [app2] I can get Y with X
* ???
* profit
UI (and programming) is much more difficult today than it should be, or can
be.
> isn't the hard difference more the concatenative vs. applicative than
> named vs. tacit?
>
(context: challenge of translating traditional PL to tacit concatenative)
No. The primary challenge is due to named vs. tacit, and the dataflows
implicitly expressed by use of names. If you have an applicative language
that doesn't use names, then there is a much more limited dataflow. It is
really, literally, just Applicative.
class Functor pl where
-- language supports pure functions
fmap :: (a -> b) -> pl a -> pl b
class Applicative pl where
-- language supports pointy values
pure :: a -> pl a
-- language supports procedural sequencing
ap :: pl (a -> b) -> pl a -> pl b
-- (some thought has been given to separating pure and ap).
This much more constrained language is easy to express in a concatenative
language.
* `fmap` is implicit (you can express pure behaviors if you like)
* `pure` is modeled by literals (e.g. `42` puts a number on the stack)
* `ap` is a simple combinator.
But introducing names moves expressiveness from `Applicative` to `Monad`,
which supports ad-hoc deep bindings:
foo >>= \ x -> bar (\y -> x+y)
Concatenative languages are often somewhere in between Applicative and
Monad, since they require explicitly modeling the data-plumbing and hence
can control the expressiveness of bindings.
Regards,
Dave
>
>
>
> On Fri, Sep 20, 2013 at 2:15 PM, David Barbour <dmbarb...@gmail.com>wrote:
>
>>
>> On Sep 20, 2013 10:46 AM, "Matt McLelland" <mclelland.m...@gmail.com>
>> wrote:
>> >>
>> >> The TUNES vision is revived, and better than ever.
>> >
>> >
>> > Do you have a link that would tell me what TUNES is?
>>
>> Try tunes.org
>>
>> >
>> > What is it about continuous automatic visualization that you think
>> requires tacit or concatenative programming?
>>
>> Not "requires". Just orders of magnitude better at it. Some reasons:
>>
>> 1. well defined environment structure at every step
>> 2. well defined, small step movement operators
>> 3. strong, local distinction between move and copy.
>> 4. linear, incremental timeline built right in
>> 5. much weaker coupling to underlying text
>>
>> >
>> > My main question is: what's the problem with text?
>>
>> Manipulating diagrams, graphs, geometries, images via text is analogous
>> to writing text through a line editor. It's usable for a nerd like me, but
>> is still harder than it could be.
>>
>> My goal is to lower the barrier for programming so that normal people do
>> it as part of their every day lives.
>>
>> >
>> > From my point of view an essential aspect of programming is that we are
>> building up an artifact -- a "program" -- that can be reasoned about
>> independently of its edit history / method of construction.
>>
>> I agree!
>>
>> That gets back to the "meta" in "user actions are an act of
>> metaprogramming."
>>
>> Yet there are many advantages to modeling the method of construction, and
>> reasoning about it, too. It enables programming by example, formal macros,
>> staged metaprogramming.
>>
>> Even better, if execution is fully consistent with method of
>> construction, then the intuitions users gain during normal use will
>> effectively inform them for higher order programming.
>>
>> >
>> > Furthermore, I think it's a mistake to couple the ways of constructing
>> / editing that artifact to its semantics as a program.
>>
>> I halfway agree with this.
>>
>> The programmatic 'meaning' of a graph, geometry, diagram, text, or other
>> artifact should be controlled by the user of that artifact. Yet, it is
>> ideal that the ways of manipulating the artifact also move it from one
>> consistent meaning to another.
>>
>> In order to achieve both properties, it is necessary that the tools and
>> macros for operating on a structure also be programmable by the user.
>>
>> >
>> > you made the claim that there isn't a simple way to translate from
>> tacit concatenative programming to named applicative.
>>
>> Other way around!
>>
>> Tacit concatenative to applicative is trivial (albeit, not idiomatic).
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "reactive-demand" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to reactive-demand+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "reactive-demand" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reactive-demand+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
