> * The language syntax isn't as good as a sexp-based lisp. Editing complex expressions is needlessly complex and doesn't even compare to structured editing with paredit in Emacs.
Did you know that the frontend lets you double/triple/etc click to select outward up the AST? You can also press ctrl+period to do this. It's indeed not paredit, but you can do most paredity things using this single primitive and copy/paste, and it's not too painful (and it would only take a weekend to make a package that implements paredit).
Other than the lack of paredit, could you be more specific about the syntax isn't good? You can always use FullForm if you want to write things in an sexp way.
I think the equivalence between prefix form (f /@ x, f @ x, f @@ x), and FullForm (Map[x, y], f[x], Apply[f, x]), and postfix form (x // f) is a nice degree of freedom when beatifying code. Sames goes for composition (f /* g, or g @* f).
Functions tell a story and having to write that story in exactly one austere syntactic way is in my view a disadvantage for making the story clear and satisfying.
> * The interpreter is slow. Really slow. Sure, if you call a matrix math routine, it will be OK, but try rearranging large data structures and you'll end up waiting a lot.
I haven't done benchmarks recently but we're probably in the same ballpark as (C)Python. Maybe a bit slower. But if you'd consider using Python for a task it's also likely to be handled by Mathematica just fine. In many cases there is plenty-optimized C code doing the heavy lifting, like if you use our machine learning functions or anything with matrices (or vectors/lists, or tensors, or ByteArrays, or Images, or Graphs, or ... :) ).
As usual, interpreted languages can even win when they allow you to describe a computation at a high level, and have that be executed by some smart JIT compiler. Julia leads the way, of course, but we're working on similar things ourselves, particularly for Dataset (http://reference.wolfram.com/language/ref/Dataset.html).
> * Debugging support: what debugging support?
There is a built-in debugger in the frontend, under the "Debug" menu, that actually does a fair job of showing where in your expression the evaluator is at. I admit that I don't use it much, partly because I've got a much more ambitious prototype of a thing that produces a browseable execution history. Hopefully that's only a few point versions away, I just have such a crazy number of projects.. sigh.
> * The editor is a disaster. I seriously don't know how people can stand it and how come the company invests so little in it. A single mismatched bracket can mean ten minutes of hunting for the problem. Code jumps around on screen all the time, seemingly with no logic to it.
That's because you're probably using Input cells. Input cells are for one- or two-line inputs. Use Code cells for large bodies of code. They don't do automatic indenting and won't jump around. If you wish to complain that this isn't obvious enough, I entirely agree with you! It takes too long to discover the 'right way of doing things', which is a UX and design failing. And simple stuff like Tab on a selection of multiple lines doesn't work.
I use Eclipse (for which there is a plugin), or Sublime Text.
> Syntax highlighting is nearly non-existent.
Syntax highlighting isn't non-existent, at all. I'm not sure where you get that from. Some examples of things that are highlighted:
* Misspelled functions (functions without definitions are blue)
* Invalid numbers of function args
* Invalid options to functions (options=keyword parameters)
* Scoped variables for Block, Module, With, DynamicModule, Table, Do, etc
* Symbol shadowing (a variable in a Module shadowing another module, etc)
* Invalid graphics and typesetting and GUI elements
And beyond that, various little red arrows appear when you write something that couldn't parse.
> It's a complete trainwreck and I don't understand why this isn't seen by the company as a huge problem.
"Trainwreck" really seems hyperbolic. Whatever our faults, one of the things people tend to agree about is that we've innovated with the frontend, and others are only now catching up with IPython, Light table, etc.
And they have a long way to go. The frontend has reflow, a box language, cascading stylesheets, and something resembling FRP (though a bit less clean, perhaps). It's really not far off from HTML in its flexibility and power.
> Hash-maps: these were only added recently (!!!) and they are not what I'd expect in a modern language. For example, if you want to do a map lookup, and your keys aren't strings, you need to wrap them in Key[]. Come on.
Good thing we waited, though, if we had added associative arrays 15 years ago we wouldn't have had datastructures like HAMTs to achieve both immutability and efficiency.
I'm puzzled. Both the subvalue lookup (assoc[x]) and the Lookup function (Lookup[assoc, key, default]) don't require a Key wrapper, and those are the dominant ways to use associations. Key wrappers are only required when using e.g. Part, to distinguish e.g. the key All from the part spec All. What other behavior would you have wanted?
And design-wise, I actually think we nailed the design. There are all sorts of nice equivalences of the form Values[f[assoc]] === f[Values[assoc]] that give an association a well-defined 'kinematics' -- they are like ordinary numerically-indexed expressions (e.g. Part[f[a,b,c],2] is b), but the indices are now arbitrary expressions. That essentially forces your hand with respect to many existing functions, like Sort, Map, Partition, Take, Drop, and so on.
And that makes them seem cleaner than in many other languages, which mostly treat associative arrays as little more than bags of tuples (e.g. mapping over a hashmap in Clojure is not terribly useful or efficient).
Plus, the order-preserving is just nice, even if there is a performance cost.
> I find that I use Mathematica for a limited range of problems. If I could have Mathematica's library in Clojure with a graphical REPL, I'd pick that any day (Clojuratica is a project aiming for that).
Clojuratica was developed by a friend of mine. Sadly he's moved on to other things. It's pretty easy to build something similar on top of JLink, though, see http://reference.wolfram.com/language/JLink/tutorial/Writing...
If you're a big Clojure user you may be interested in Session -- https://medium.com/@kovasb/session-1a12997a5f70 -- that's a project by another friend of mine who used to work at Wolfram and now is an active member of the Clojure community.