# Programming Mathematica in plaintext, i.e. no formatting, non-notebook

I'm new to Mathematica and I've just begun reading Paul Wellin's Programming in Mathematica.

The book, like many other books and online tutorials, revolves around using the notebook, with all its helpful formatting and other facilities. However, given my background as a C++ developer, mostly using vim and other "traditional" IDEs for development, Doxygen-style commenting for document generation, and Perforce, git, and svn for version control (all of which, as far as I'm aware, operate by diff-ing newline-delimited code), I'm anxious to know: Is it possible (and more importantly, not limiting) to program Mathematica in "plaintext"? (And if so, how would one go about it, i.e. through a mode in Mathematica's front-end, or writing separate files and "running" them via terminal?)

For the record, I'm not at all opposed to learning a new way of doing things. I'd just like either (1) to ascertain that programming in plaintext is indeed an option and not limiting (at least, there are alternative techniques for getting around any limiting factors) or (2) to ascertain that there are clear advantages to using the notebook, in which case, I'm happy to commit to using the notebook. Of course, it'd be nice if I could touchtype Mathematica code in vim, but I'm sure there would be good reasons for preferring the notebook, if indeed it is preferred.

Perhaps I'm searching for answers using the wrong keywords (mainly "plaintext"), but these are some other threads I read here, on the meta, and on SO, before deciding to ask.

If this question is defective, please help me improve my question. I'm very much for asking only relevant questions, and I'm happy to take this elsewhere, or rewrite the entire thing.

The reason I'd like to ascertain one or the other is that in my current state of mind, uncommitted to either style, I'm subconsciously resistant to imagining myself programming in Mathematica as I read the book and online tutorials. That is, not having a clear idea of how I'll be writing code, my mind seems to avoid even thinking about it! I think reading actively (imagining myself applying what I'm learning) is a critical factor to learning, so I'd like to remove this mental barrier as early on as possible.

-
Are you aware of Workbench? Also related: mathematica.stackexchange.com/q/5184/131 –  Yves Klett Aug 24 '13 at 14:13
"one or the other" - I can't see why you can't do both. Explore the language interactively, and write specific packages using Vim (or whatever) or run things from the command line once you've got it. You may find that looking at the same thing from two different directions enhances understanding. (The steepness of the learning curve may be due to the language itself, rather than to the method you employ.) –  cormullion Aug 24 '13 at 15:22
@cormullion - I agree. Perhaps I miscommunicated; my "either-or" wasn't meant to be a "XOR". I wanted to make sure that one of the ways wasn't a mistake, e.g. impossible, discouraged by seasoned users, or considerably difficult. For example, if it had been the case that plaintext-coding was not possible, I would have begun absorbing information differently: less attention to function names (since ?func* will be available in the notebook; and in the notebook I'm less likely to hone touchtyping), more attention to notebook and interface features; looking into how to bundle scripts; etc. –  Andrew Cheong Aug 24 '13 at 17:30
There is also @halirutan's Open-source IntelliJIDEA plugin to support Mathematica development. Still thinking about an answer that will add value ;-) –  Yves Klett Aug 24 '13 at 17:54
@acheong87 you can just right-click in a Notebook and insert a Code cell, which will have standard text/formatting (same cell type as in New -> package). also check out my answer here for an example of the kinds of things you can do with a Mathematica notebook. and do try to play with Manipulate. i don't miss Vim much in Mathematica because Mathematica code is very succinct. i consider around more than 200 lines to be a large Mathematica program. you can accomplish a lot very efficiently once you get into the vibe of the language –  amr Aug 25 '13 at 1:09

Yes, plain-text programming, as you call it, can be done in Mathematica. It is often used for developing packages (.m files). Try searching this site with the phrase "package development" to get more info.

There is even a built-in working environment supporting package development. It has its own style sheet in which code-form cells (plain-text initialization cells) replace input-form cells as the default cell style. It also provides a few of the traditional IDE tools such as a Run button. To try it, or at least look at it, choose Package from the File > New menu. However, when developing a package, I still keep a normal notebook open to act as a test harness.

This brings me to my final point. Mathematica differs from C++ and similar languages in that it is an interpreted rather than a compiled language. This means you can break out of the code-compile-test cycle and adopt a very fine-grained incremental style with lots of interaction and micro-testing. An interpreter has the advantage of being able to serve a highly interactive debugger. If you have no previous experience with interpreted languages, you should definitely try working with Mathematica interactively. It allows you to develop a program in very small increments, each of which is individually tested, so that you have tested, working code at every stage of your program's development. Of course, this requires acquiring a somewhat different mind-set, but I have found it a very satisfying, indeed addictive, way of programming.

-
Thanks; that's the kind of "notebook advantage" I was looking out for, that might sway me from my usual plaintext coding. Despite the alternatives offered by @YvesKlett, I think I'll try what you're suggesting, as I read similar advice in this blog article I'd read earlier today: mathematica-guide.blogspot.com/2013/05/…, regarding programming in small increments. –  Andrew Cheong Aug 24 '13 at 17:37
Seconded - to get experience with Mathematica, the frontend is the way to go. Most users (all skill levels) stick with that. –  Yves Klett Aug 24 '13 at 19:04

I like to save my files in "plaintext" for 3 reasons:

• Can use SVN to have embedded version information, look at diffs from coauthors, etc.
• Don't mix the code itself with the output of the code, which also makes interacting with coauthors difficult and is unclear what has been run and what hasn't.
• Be able to run the files commandline on a cluster if required (though not debug/program on it)

But none of those are really "programming" in plain-text. The Notebook environment is far too powerful to ignore. So here is how I work:

• Store your files as .m package files. This means they are plaintext for the purposes described above and can be run commandline on a cluster as required.
• Load and edit the .m files in the normal FrontEnd. They are not all that different from working with the than Notebook files themselves
• Different sections of your code can be separated by 2 newlines
• In particular, you can Shift-Enter run only 1 section of a time of your code (i.e. those separated by newlines). If you run the whole package, then it will nicely display the output from the different sections like different sections in a notebook file.
• The only caveat is that if you type in certain things into your code, they will display in the FullForm upon opening the package (e.g. subscripts typed as $a_l$ become Subscript[a,l] after reopening the file). However, greek letters seem to display properly when opening the file, and you shouldn't use subscripts in variable names anyways (see Displaying index as subscript on output: e.g. C[i] -> C_i with Notation[...] or Interpretation[..]? for how to look like subscripts in the display )
• When you save the .m, you will only be saving the input - which is what I like. If you have a very long calculation that you don't want to lose, you can save the state and load it using something like: DumpSave["myfile.mx", "Global"];` This way you can separate the calculation of complicated things (which could be run commandline if required) from the analysis, which doesn't have to be.
• Finally, when you are programming, open up a blank notebook file to act as sort of an interpretive window. That way you can test things out and only copy code over to the .m file as required
-

This question is related to What are the advantages of using .nb rather than .m files?
That question details some of the differences you will face in using a plaintext format.

If you are merely seeking manual code formatting rather than having Mathematica reflow your input you can use the Code cell style, or a customized version (e.g. without being Initialization cells) using style sheets. See Automatic Text Adjustment.

-