20
$\begingroup$

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.

Improve this question
$\endgroup$
7
  • 2
    $\begingroup$ Are you aware of Workbench? Also related: mathematica.stackexchange.com/q/5184/131 $\endgroup$
    – Yves Klett
    Commented Aug 24, 2013 at 14:13
  • 1
    $\begingroup$ "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.) $\endgroup$
    – cormullion
    Commented Aug 24, 2013 at 15:22
  • $\begingroup$ @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. $\endgroup$
    – Andrew Cheong
    Commented Aug 24, 2013 at 17:30
  • 3
    $\begingroup$ There is also @halirutan's Open-source IntelliJIDEA plugin to support Mathematica development. Still thinking about an answer that will add value ;-) $\endgroup$
    – Yves Klett
    Commented Aug 24, 2013 at 17:54
  • 2
    $\begingroup$ @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 $\endgroup$
    – amr
    Commented Aug 25, 2013 at 1:09

3 Answers 3

Reset to default
16
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ 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. $\endgroup$
    – Andrew Cheong
    Commented Aug 24, 2013 at 17:37
  • 1
    $\begingroup$ Seconded - to get experience with Mathematica, the frontend is the way to go. Most users (all skill levels) stick with that. $\endgroup$
    – Yves Klett
    Commented Aug 24, 2013 at 19:04
7
$\begingroup$

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
Improve this answer
$\endgroup$
6
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.