When comparing LiveScript vs Wolfram Mathematica, the Slant community recommends Wolfram Mathematica for most people. In the question“What are the best (productivity-enhancing, well-designed, and concise, rather than just popular or time-tested) programming languages?” Wolfram Mathematica is ranked 60th while LiveScript is ranked 67th.
Ranked in these QuestionsQuestion Ranking
Pros
Pro Designed for High-level functional code
LiveScript has terse syntax for common functional operations like map, and ships with a library, prelude.ls, with many of the functions most commonly used by functional programmers.
Pro Good amount of programmer flexibility
There's a huge range of features that can make common tasks faster.
Pro ECMA 6 Features
It is the declared goal of LiveScript’s creators to track ECMAScript 6. Hence, the language gives you ECMAScript 6 plus type annotations (which are optional).
LiveScript's module syntax is currently a bit behind the ECMAScript 6 specification (something that will be fixed eventually). It supports two module standards: CJS (Node.js) and AMD (RequireJS).
Pro Fixes coffeescript scoping issues
=
is used to declare variables in the current scope, in order to redeclare variables of outer scope :=
is used. This way bugs are reduced.
Pro Supported by WebStorm and Visual Studio
Pro Lots of functionality
Pro Built-in CPU Parallelization
Pro Very mature
Wolfram Mathematica has been around for a long time without any major changes in the basic design.
Pro Coherent API over different domains
Pro Supports units and can do much more than just maths
Other platforms severely lack this useful feature.
Pro Fully integrated symbolic processing
Pro Very powerful and fast, also possible to get for free
Cons
Con Strong functional lean
LiveScript is designed to be a high level functional language. For people who prefer a more imperative approach it can be hard to get used to.
Con Compiles to unreadable javascript
JSON.stringify(
each(upCaseName)(
sortBy(function(it){
return it.id;
})(
(function(){
var i$, ref$, len$, ref1$, j$, len1$, ref2$, results$ = [];
for (i$ = 0, len$ = (ref$ = table1).length; i$ < len$; ++i$) {
ref1$ = ref$[i$], id1 = ref1$.id, name = ref1$.name;
for (j$ = 0, len1$ = (ref1$ = table2).length; j$ < len1$; ++j$) {
ref2$ = ref1$[j$], id2 = ref2$.id, age = ref2$.age;
if (id1 === id2) {
results$.push({
id: id1,
name: name,
age: age
});
}
}
}
return results$;
}()))));
Con Unintuitive data types and strange assignment statements
Representation of data still remains highly fragmented technically and one fumbles between data types and stumbles on strange assignment statements to attempt conversions of meaning.