These are all valid criticisms. There is no type system, although some safeguards can be implemented through pattern matching and conditions (see the answer by @derf_ above). For quick and dirty transforms on symbolic math expressions, these are often good enough, but it is indeed a mess to use as a full fledge programming language.
I do like that the lispy language itself closely mirrors math expressions, and it is consistently accessible throughout the user interface. For example, the mathematica notebook frontend (IDE) is simply some `MakeBoxes[]` of the expressions, which are all valid mathematica code themselves. I tried sympy a while ago, which I believe took an object-oriented approach, and it was very clumsy when compared to mathematica.
Still, I would not recommend using mathematica for general programming, precisely because of the mentioned shortcomings. By default, it is also impure and not lazy (eager eval, although it can be forced to be lazy on a case by case basis using `Hold` or `Unevaluated`).
I do like that the lispy language itself closely mirrors math expressions, and it is consistently accessible throughout the user interface. For example, the mathematica notebook frontend (IDE) is simply some `MakeBoxes[]` of the expressions, which are all valid mathematica code themselves. I tried sympy a while ago, which I believe took an object-oriented approach, and it was very clumsy when compared to mathematica.
Still, I would not recommend using mathematica for general programming, precisely because of the mentioned shortcomings. By default, it is also impure and not lazy (eager eval, although it can be forced to be lazy on a case by case basis using `Hold` or `Unevaluated`).