Out-Processing Processing with Field

November 17, 2010 at 2:24 pm 6 comments

Marc Downie is coming to Georgia Tech to give a talk, and his abstract included a reference to the Field programming language, designed for creation of computing-as-art.  “Always in collaboration, always in real-time their practice has spawned a parallel series of investigations into the tools and representations used to make digital art. This thought has become embodied in a new open source platform for programming art called Field. What kinds of tools do we need to survive the complex forms that we can create? what kinds of interactions can we have with the code that we write? and what kinds of collaborations and communities of artists might arise around these platforms?”  That was intriguing enough that I looked up Field. Wow!  Explicitly, they aim to be better at processing than Processing. They interact with a wide variety of code bases, from pure-Python to Java to Max/MSP. The IDE includes a bunch of unusual ideas, like embedding GUIs into the source code.

Since it’s such an important source of interesting libraries, the Processing tradition has received special attention — the ProcessingPlugin bridges Field’s execution model to the world of Processing. Field replaces the Processing Development Environment and its programming language while allowing you to use all of your favorite Processing libraries and renderers from within Field’s integrated Processing “Applet”. Field has no start or stop button — there’s no compile cycle. You can execute, script, sequence and manipulate code as the “Applet” runs — all while building personal practice-oriented interfaces in the canvas. We think that, for many uses, Field is a better Processing than Processing. We note that most if not all of the items on Processing’s proposed “future features” list are already available in Field, or are not needed in Field because it is a live environment, or can be readily made inside Field today.

via OverviewBanners2 (Field).

Entry filed under: Uncategorized. Tags: , , .

Take the CSed Week Pledge Atari co-founder Nolan Bushnell on the future of software (Q&A)

6 Comments Add your own

  • 1. John "Z-Bo" Zabroski  |  November 17, 2010 at 2:34 pm

    Embedding GUIs into the source code is not an “unusual” idea, at least as I think of it.

    Andrew Eisenberg did his Ph.D. thesis on it a few years ago, and in the HCI community Andrew Ko independently developed a source code visualization API for IDEs under Brad Myers, for his Ph.D. thesis.

    Apart from that, the more broad idea of unparser definitions (the formal subject matter for reifying source code in different forms) has been around since at least Teitelbaum and Reps work, on the Cornell Program Synthesizer and later the Synthesizer Generator.

    Neither Ko nor Eisenberg used the phrase unparser definitions in their theses and papers, though. Nor did they provide comparisons to system’s that use unparser definitions.

    Furthermore, Joseph Goguen worked on this up until his death, on projects like TATAMI, where he argued for the use of algebraic semiotics to provide the most mathematically rigorous and general framework for reifying code as GUI stuff. For Goguen, just reifying code was not enough.

    So it is not that this is unusual, so much as it is an idea that has been independently developed in many places.

    Reply
  • 2. Mark Guzdial  |  November 17, 2010 at 2:44 pm

    Do you use any of these regularly, John? If so, I’d love to hear what your experience is like, e.g., does it impact your productivity to move between modalities, how does it impact how you think about the code, and when do you choose to use GUI elements vs. textual elements?

    As for me, though I’m aware of lots of tools in this space (you might also have mentioned Boxer, which used GUI elements as part of the language elements), I’ve not used any, and I don’t know any that achieved any significant user base.

    Reply
  • 3. John "Z-Bo" Zabroski  |  November 17, 2010 at 3:39 pm

    I am the presently the maintainer of a visual programming language for financial analysts at hospitals. I don’t know how else to answer your question, since there is too much to discuss here. Suffice to say, I have to know my stuff when it comes to (a) programming language design (b) information visualization (c) interaction design (d) access control (e) interaction control (f) abstract query language formalisms

    I don’t like comparing all these tools or discussing their individual contributions, because usually tools are synergistic in nature. I recently read a blog post by the author of a book on Make about “things Make got right and things it needs to do to improve”, and I just shot back that he has been living in a vacuum for 20 years, and that Butler Lampson, Paul McJones and other great programmers built Vesta, which is superior to Make-like systems in every way imaginable.

    And Goguen’s work on semiotics is really its own subfield of information theory.

    As for choosing between GUI elements vs. textual elements, well I am presently writing a report deconstructing modern IDEs and what they do poorly (IMHO). The big problem really is lack of *integration of concerns*. There is one IDE that has recently announced a Beta preview available in December, the Tenacious C IDE. I won’t know how extensible it is until I try it. I’ve also tried getting into the Code Bubbles beta for awhile now, but they have never replied to my requests.

    I think IDEs of the future need to think in terms of supercomputers, since we’re rapidly converging on that direction. Hansen predicted this development in 1984 when he was discussing alternative architectures to text editors. He called it a master-slave scheme, similar to the terminal services popular in the 1970s.

    Today there is really know excuse for poorly designed IDEs like Eclipse and Visual Studio. We have the formal theories to do much better.

    Reply
    • 4. John "Z-Bo" Zabroski  |  November 17, 2010 at 3:45 pm

      One slight oversight: I left this implicit in my reply, but Field is based on Python, and so is inherently limited to Python’s interpretation semantics and global interpreter lock. Field therefore doesn’t seem that forward thinking to me. It is pretty cool, though, compared to what most language people are building these days 🙂

      Reply
    • 5. John "Z-Bo" Zabroski  |  November 17, 2010 at 3:46 pm

      Eek. Today there is really no* excuse. Oops! How did that happen? 🙂

      Reply
  • 6. Aaron Lanterman  |  November 21, 2010 at 4:16 am

    “Processing.” “Field.” Good grief, what are people thinking when they come up with names for these new languages? It makes it quite difficult to find information on them.

    Dear everyone creating or thinking of creating a new programming language: please, please, please, come up with something that won’t pull up 1,000 unrelated google hits.

    There’s a company that makes audio ICs called “THAT Corp.” Sigh.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,026 other followers

Feeds

Recent Posts

Blog Stats

  • 1,986,125 hits
November 2010
M T W T F S S
1234567
891011121314
15161718192021
22232425262728
2930  

CS Teaching Tips


%d bloggers like this: