March 19, 2009 — Werner Schuster, Kernel Developer

Inside and outside of Wolfram Research, teams are working on large Mathematica projects. Working with large code bases requires powerful tools; it is even better if these tools are integrated. With Wolfram Workbench, we brought an integrated development environment (IDE) to our users.

What does “integrated” mean? Well, let’s look at just one example of how Workbench integrates Mathematica‘s central language features, pattern matching, editors, and source management tools.

Let’s start with a specific problem: with our Mathematica 6.0 release, we overhauled many of our libraries and APIs (our recent Version 7.0 release builds on the improvements in Version 6.0). Some groups of functions were deprecated or their APIs changed. We had collected a long list of these changes… but how would users apply them to their source code? Go through them one by one and line by line in their code? Definitely not.

Read More »

November 12, 2007 — Nilay Gandhi, Corporate Communications

Last month, we hosted our annual technology conference here at our headquarters in Champaign, Illinois, where hundreds of Mathematica users from around the world came to show us what they’ve been working on and to see what we’ve been up to.

A lot of the conference presentations are now available on our website, so you can take a look at them even if you didn’t have a chance to attend this year.

Read More »

June 15, 2007 — Kovas Boguta, Special Projects Group

In this blog and elsewhere, you’ll often see the statement that some advanced Mathematica feature is just another application of symbolic programming. It’s the kind of idea that seems too powerful to explain in a single blog post, yet simple enough that I am tempted to try. So, here goes.

Symbolic programming is based on the concept of recasting core features of human language into a computationally active form.

What does it mean to have a human-language-oriented programming language?

Our cognitive model of computation is typically a three-stage process: 1) describing the computation, 2) executing that description, and 3) outputting the results.

The “language” part of most programming languages begins and ends with stage one. Linguistic structures are erected to describe the program. But the execution of the program is typically oriented around an entirely different system of types and objects; and likewise, the program’s output structure tends to resemble nothing particularly language-like.

Symbolic programming uses linguistic structures as the foundation of all aspects of computation. From a computation’s description, to how the computation executes, to how humans interface with the results, the exact same basic tree structure is used throughout.

This is a powerful unification, making possible many useful computations that in other systems range from cumbersome to practically impossible. We’ll see examples along the way, but let me first describe what these linguistic structures actually are.

Read More »

May 17, 2007 — Theodore Gray, Co-founder, Wolfram Research, Inc; Founder, Touch Press; Proprietor,

I’ve been a “professional” user-interface programmer for 20 years. In that time I’ve written a grand total of three little apps just for the fun of it. Two of them I snuck in as hidden buttons in the Mathematica About Box, because it was just too difficult to start a new application from scratch. All of them can be replicated in a few minutes using Version 6.

In my experience, writing GUI (graphical user interface) applications in C or Java or Visual Basic–or whatever–is fine if you plan to spend weeks or months on a program, but prohibitively horrible if you really only have a few minutes to dedicate to the task.

You have to allocate windows, store pointers to them, then allocate controls or read them from some kind of resource file, store pointers to them, blah, blah, blah. It might be two or three pages of code before you can even start thinking about what this program is actually supposed to do.

Cocoa and other such frameworks make it marginally easier. I enjoyed programming in NeXTSTEP (which is what Cocoa was called before Apple took over NeXT). It’s the environment in which I wrote RealTimeAlgebra in 1989, the one just-for-fun app I wrote not as an About Box button. (RealTimeAlgebra was basically what we now call Manipulate.)

But it is still a pain. Instead of starting by writing pages of code to deal with windows, you start by using an annoying graphical tool to lay out controls and define who is connected to whom. Then you get to write pages of code defining the actions of all these controls before you can start working on the actual content.

Read More »

May 13, 2007 — Kovas Boguta, Special Projects Group

Symbolic programming has been a core idea in Mathematica since the very beginning. But it is big idea, and an abstract idea. And people understandably just want to know what the bottom-line benefit is, and could care less about what went into making it happen. Fortunately, Mathematica 6 is making it a lot easier to illustrate ideas about symbolic computation in visual and interactive forms.

High-Level Functions

For starters, illustrating the core programming primitives with visual examples is a piece of cake with the new graphics and typesetting functions. For example, Map will take a function and apply it to each element in a list:

In[1]:= Map[Framed, {a, b, c, d, e}]  |  Out[1]:= {[a], [b], [c], [d], [e]}

NestList will take a function and apply it over and over again to the initial seed, returning a list of all the iterations:

In[2]:= NestList[Magnify, a, 4] | Out[2]:= {a, a, a, a, a}

Programming in Mathematica is based on transforming trees. The built-in function TreeForm allows us to visually represent the tree backbone of Mathematica programs and data structures:

In[3]:= TreeForm[a+b^2+c^3+d] | Out[3]/TreeForm:= Plus a Power Power d b 2 c 3

Read More »