These comments would be a lot more interesting if people identified what was cool rather than just bitching about ego or syntax or licensing. I'm not going to be using the Wolfram Language, but I'd love to identify the best ideas from it. And it's a different enough language that I am confident there are interesting ideas in it.
Reap/Sow ss a funny language feature that I haven't imagined before, but that's not really the point. The point is that this is a runnable example – that's actually what is output. Typically when you run something like that you get "NameError: a is not defined". And "a" here is really a variable, of sorts – it's not a string or symbol (at least not a symbol in the sense that we know them in programming).
Given this, snippets of code are just as executable as entire programs. Every expression is like a function with the free variables as its parameters, and a sequence of expressions is a bit like function composition.
This is all natural from the perspective of mathematic notation. In a more traditional programming environment I think it's reminiscent of partial evaluation: https://en.wikipedia.org/wiki/Partial_evaluation – where you analyze a program and execute expressions opportunistically. It's really almost the same as partial evaluation, but the Wolfram Language knows a lot more about how you can execute different combinations of expressions than a typical language. A typical language does not really "believe" that (a+b) and (b+a) are equivalent. It doesn't know how to relate different operations. Nor do normal languages have a concept of simplification, so they can't speculatively try other arrangements (where none in isolation is clearly better or simpler than another) to see if simplifications are possible.
I know it's not the point of what you were mentioning, but I wanted to briefly mention that reap/sow are not unlike Haskell's so-called Writer Monad:
newtype Farm a b = Farm (b, [a]) deriving (Eq,Show)
instance Monad (Farm b) where
return x = Farm (x, [])
Farm (b, as) >>= f =
let Farm (b', as') = f b in Farm(b', as ++ as')
reap :: Farm a b -> (b, [a])
reap (Farm x) = x
sow :: a -> Farm a ()
sow a = Farm ((), [a])
-- prints ("e", ["a","c","d"])
main = print (reap (do sow "a"
return "b"
sow "c"
sow "d"
return "e"))
(Reimplemented in a simple way here to show the underlying machinery; usually, instead of lists, a writer is parameterized by an arbitrary monoid.)
What you are getting at here is the fact that Mathematica is a symbolic language through-and-through.
In my webpage here: http://www.oftenpaper.net/sierpinski.htm I try to give passing mentions to how the Mathematica language and its infrastructure make various things easier.
As a programming language geek, I haven't found a language more powerful than Mathematica, and that's before considering the infrastructure it comes with.
I've always found the repeated application of rules to simplify patterns in expressions until the expression stops changing to be pretty powerful when just playing around, especially with small problems. However, in my experience in bioinformatics, that flexible approach is so slow in the face of actual data as to be totally useless for use on real problems in my line of work.
I think an option to use a faster, less powerful, linear pattern matching algorithm more like in ML/Haskell would help a lot in this regard.
My own contribution:
Idly looking about I come upon this page, which is not particularly notable: https://reference.wolfram.com/language/ref/Sow.html
What is notable is this example:
Reap/Sow ss a funny language feature that I haven't imagined before, but that's not really the point. The point is that this is a runnable example – that's actually what is output. Typically when you run something like that you get "NameError: a is not defined". And "a" here is really a variable, of sorts – it's not a string or symbol (at least not a symbol in the sense that we know them in programming).Given this, snippets of code are just as executable as entire programs. Every expression is like a function with the free variables as its parameters, and a sequence of expressions is a bit like function composition.
This is all natural from the perspective of mathematic notation. In a more traditional programming environment I think it's reminiscent of partial evaluation: https://en.wikipedia.org/wiki/Partial_evaluation – where you analyze a program and execute expressions opportunistically. It's really almost the same as partial evaluation, but the Wolfram Language knows a lot more about how you can execute different combinations of expressions than a typical language. A typical language does not really "believe" that (a+b) and (b+a) are equivalent. It doesn't know how to relate different operations. Nor do normal languages have a concept of simplification, so they can't speculatively try other arrangements (where none in isolation is clearly better or simpler than another) to see if simplifications are possible.