Python and Julia have a nice interactive notebook: IPython/IJulia.

There's some customer stories at: http://www.wolfram.com/mathematica/customer-stories/

I do. I use it as an advanced calculator for doing complex mathematics too hard to deal with by hand. To answer what industries, I do everything from semiconductor device physics to databases and machine learning.

Did they ever share any of their algorithms created in-house? (They claim many are.) If they share the method, why can't they share the code?

They do have some notes on internal implementation, that do not seem up-to-date, here [0]. Were they any more detailed than this?

[0] http://reference.wolfram.com/language/tutorial/SomeNotesOnIn...

I don't know if it is launch-day blues, but on new MacBook Pro, the demo notebooks are sluggish, and some of the examples throw errors.

And it uses "CTRL" to mean "Command", throughout. Tantalizing, but not a perfect first-impression, and it reinforces the feeling the I'd be let down if I stray from the path of polished examples and into real work.

...and it seems I corrupted the master copy of the "Things to Try" notebook -- clicking on the link again, from the home page, launches the corrupted notebook I made earlier.

Well, unlike adding and changing definitions for symbols in the symbol table, associations are actually immutable. So you can pass them around as values, mutate them, and the old versions are still available unchanged. That's just not true of using downvalues of symbols.

Also, using definitions on symbols to store key-values is incredibly limiting, because you can't do reverse lookups without getting into very low level (and slow) hackery via DownValues. Or list the keys or values. Or even know how many keys you have.

Associations really will replace basically all uses of symbol downvalues for storing key-value pairs. And Associations have really nice general-purpose functions like GroupBy, Counts, Merge, and so on (mentioned below).

Associations even support function application syntax, so you should be able to drop them in into existing code that expects symbol downvalues as you're using them above.

Associations are the single most significant language-level improvement we've had in many versions. And we've integrated them really nicely across the system -- they're not just some special-purpose data structure.

We were considering making http://matlink.org/ compatible with Octave. The feedback I got on this was part of why this wasn't done. To make MATLink user friendly, it needs to come with compiled binaries, which would be linked against Mathematica's closed source MathLink library.

If it is the case that GPL doesn't forbid this, I'd love to hear about it.

Mathematica is decades ahead of LightTable

Can the RPi version use Wolfram Cloud to speed it up?

Looks like it... I would delete both from disk, redownload 10, and reinstall it. Also check that you didn't run out of disk space.

If all else fails, phone our technical support at 1-800-WOLFRAM, they're pretty good.

To be fair, fast immutable hash tables have only been around as a technology since around 2005. (Yes, Mathematica is mostly based on immutability) .Other than internal R&D, Wolfram never add experimental methods to Mathematica.

Of course, its always had lists of rules as a far more general (though much slower) form of the hash table concept.

    a[x] = 1
    b = a
    a[y] = 2  <---- mutates a
    a[x] = 3  <-- is this legal?
    b[x]    <--- persistent- uh, what is Mathematica's semantics here?

Associations aren't just a data structure, they've been designed to fit in a sensible way into the rest of the language, via a principle I call the "central dogma". This means they work in a predictable way with a huge number of existing functions (though we still have more to do).

For example, Associations interact naturally with the hierarchical part-specification language used by Part (http://reference.wolfram.com/language/ref/Part.html):

   In[1]:= people = { 
      <|"name" -> "bob", "age" -> 20, "sex" -> "M"|>, 
      <|"name" -> "sue", "age" -> 25, "sex" -> "F"|>, 
      <|"name" -> "ann", "age" -> 18, "sex" -> "F"|>
   }; 
   
   In[2]:= people[[ All, "age" ]] (* extract list of ages *)
   Out[2]= {20, 25, 18}

   In[3]:= people[[ All, "sex" ]] (* extract list of sexes *)
   Out[3]= {"M", "F", "F"}

   In[4]:= people[[ 2, "age" ]] (* extract age of 2nd person *)
   Out[4]= 25

   In[5]:= people[[ 2, {"age","sex"} ]] (* extract age and sex *)
   Out[5]= <|"age" -> 25, "sex" -> "F"|>

This naturally generalizes to 'indexed tables', in which the outermost list becomes an association, because associations serve double-duty as "structs" and "hash-maps", just like lists are used for both "vectors" and "tuples":

   In[6]:= people = <|
      236234 -> <|"name" -> "bob", "age" -> 20, "sex" -> "M"|>, 
      253456 -> <|"name" -> "sue", "age" -> 25, "sex" -> "F"|>, 
      323442 -> <|"name" -> "ann", "age" -> 18, "sex" -> "F"|>
   |>; 
   
   In[7]:= people[[ All, "age" ]] (* extract association between ID and age *)
   Out[7]= <| 236234 -> 20, 253456 -> 25, 323442 -> 18|>

   In[8]:= people[[ All, "sex" ]] (* extract association between ID and sex *)
   Out[8]= <| 236234 -> "M", 253456 -> "F", 323442 -> "F"|>

   In[9]:= people[[ Key[323442], "age" ]] (* extract age of person with ID 323442 *)
   Out[9]= 18

   (* extract age and sex of person with ID 323442 *)
   In[10]:= people[[ Key[323442], {"age","sex"} ]] 
   Out[10]= <|"age" -> 18, "sex" -> "F"|>

The uniform addressing scheme behind Part (and Extract, Position, etc) is tremendously useful in day-to-day code, because it makes it much easier to write programs as functions that transform potentially complex, hierarchical data in a series of steps.

This is similar in some ways to the ideas behind Haskell's lens library, Clojure's assoc-in and friends, even the schemes used in JQuery and XPath. But it's core to WL.

The semantics of Part are also extended to become a full-fledged query language, as used by Dataset (http://reference.wolfram.com/language/ref/Dataset.html):

   (* load a dataset of passengers of the Titanic *)
   titanic = ExampleData[{"Dataset", "Titanic"}]

   (* produce a histogram of passenger ages *) 
   titanic[Histogram, "age"] 

   (* produce a histograms for 1st class, 2nd class, etc.. *)
   titanic[GroupBy[Key["class"]], Histogram[#, {0,80,4}]&, "age"]  

There are also some really nice functions to work with associations, like the map-reduce-like GroupBy (http://reference.wolfram.com/language/ref/GroupBy.html):

   (* split sentence into list of words *)
   In[16]:= words = StringSplit["it was the best of times it was the worst of times"] 
   Out[16]= {"it", "was", "the", "best", "of", "times", "it", "was", 
      "the", "worst", "of", "times"}

   (* group words that have the same length *) 
   In[17]:= GroupBy[words, StringLength] 
   Out[17]= <|
      2 -> {"it", "of", "it", "of"}, 
      3 -> {"was", "the", "was", "the"}, 
      4 -> {"best"}, 
      5 -> {"times", "worst", "times"}
   |>
   
   (* reduce each group into an association of counts *)
   In[18]:= GroupBy[words, StringLength, Counts] 
   Out[18]= <|
      2 -> <|"it" -> 2, "of" -> 2|>, 
      3 -> <|"was" -> 2, "the" -> 2|>, 
      4 -> <|"best" -> 1|>, 
      5 -> <|"times" -> 2, "worst" -> 1|>
   |>

And Counts and CountsBy (http://reference.wolfram.com/language/ref/CountsBy.html):

   In[21]:= CountsBy[words, StringLength]
   Out[21]= <|2 -> 4, 3 -> 4, 4 -> 1, 5 -> 3|>

And AssociationMap (http://reference.wolfram.com/language/ref/AssociationMap.htm...):

   In[23]:= AssociationMap[WordData[#, "PartsOfSpeech"]&, words]
   Out[23]= <|
      "it" -> {"Pronoun"}, "was" -> {"Verb"}, 
      "the" -> {"Determiner"}, 
      "best" -> {"Noun", "Adjective", "Verb", "Adverb"}, 
      "of" -> {"Preposition"}, "times" -> {"Noun"}, 
      "worst" -> {"Noun", "Adjective", "Verb", "Adverb"}
   |>

Here's some more info about associations: http://reference.wolfram.com/language/guide/Associations.htm...

I guess it depends on one's field.

I've never cited a software I didn't write myself, simply saying trust this software, here's the reference. I wouldn't trust a result from Sage any better than one from Mathematica, simply based on which system produced it. I'd trust that x is a solution of an equation if substituting it back verifies it. I'll trust that two graphs are isomorphic if the software gives me a vertex permutation that makes the adjacency matrices identical. It doesn't matter how that isomorphism was computed.

When publishing work, I'll aim to make it verifiable this way.

I believe the vast majority of the use of these systems is not of the type when one needs to blindly trust the software and refer back to it in the paper. At least in my field (physics) it isn't. Yet I use programs like this daily, and I clearly depend on them for my work.

Most of the functionality available in Mathematica (or, I'd argue, most similar systems) are not of the type that one needs to cite. They either use standard and well known algorithms that are available in a multitude of systems (do you cite the methods for matrix multiplication or eigenvalue computation, and would it make a difference?), or the results are much easier to verify than to compute.

In those cases when I need to rely on a published method, like you mention, the method is very unlikely to be a built-in part of any system. So I either need to re-implement it, or use the original code of the authors. If the authors implemented their method in Mathematica instead of Python, does that make their program less reliable? No. It's still a published method, anyone can verify it.

My point is that I hear this argument about Sage very often, and the typical generalization is: "if you used Mathematica for your research, that's wrong, because it's not verifiable". This is a fallacy. It completely ignores how these software are used in practice, and implies that results from open source software are somehow magically reliable (they're not) and don't need verification (they do).

I've yet to come across a situation where the argument does apply at all: point me to a paper which goes truly wrong by citing Mathematica/MATLAB/Maple/etc this way.

People are apt to discount Mathematica completely. I don't see any problem using Mathematica to generate some results because the author prefers Mathematica over other offerings. However, it would give the results much more credence if the Mathematica-obtained result was then replicated using open software.

I would expect that the difficulty of the port could vary widely between different use cases.

I am worried that Sage will get stuck in the mud as its Python code base grows, without a powerful expressive functional core like Mathematica's Lisp-ish core language. For example, see the discussion in this page about simple association lists vs what Mathematica 10 just launched

People into traditional programming languages look at Mathematica and see abstractions for which they see no purpose.

People into PL research look at Mathematica and scoff at its low-brow, for-the-masses term rewriting, lacking whatever theoretical property deemed "essential" that week.

Yet somehow the language has formalized and made more computable and consistent more domains of math, science, and increasingly data than any other.

There is no honor or glory in purposeful ignorance.

Do you know when that change was put into place? I have been using Mathematica sense version 5 and my intuition was that `b[x] == 3`. Testing in mathematica 8 which I have on hand confirms this.

Name[Field1, Field2, ...] is not an opaque data type. Maybe you can give me an idiomatic example of how to build a binary tree, for example? Or maybe something more complicated like a doubly linked list?

I do not write Mathematica code, but most code I've seen usually ends up being this mess of functions. I'll give you that maybe the code I've seen has just been bad, so we can ignore my point there.