If you're going to boast about "terseness" as a selling point, you should at least ensure your examples actually demonstrate that to be at all true.
I was thrown off by this at first as well -- the text really doesn't match the visual impression. It might be smart to add a qualifier to the docs: "look how simple the macro is, and then look how concise the gulp definitions are after that."
"Terser" should not be a programming language selling point. "Expressive" yes.
Btw. the definition of terseness in the essay seem specifically chosen to favor Lisp style languages.
2 + 3 * 4
is clearly terser than
(+ 2 (* 3 4))
But by counting "leafs" like he does (rather than say tokens), they get the same terseness-count.
Of course, a lot of people very much resent the idea of a programming language forcing them to do what they see as pandering to the lowest common denominator (That's what comments are for!). It really is up to the community as to how much description they really need.
I'm doing a complete rewrite with 0.4, overhauling the compiler's architecture (the current version is fairly embarrassing) and dropping some dead-end ideas and Ruby influences. Mostly done, but moving slowly. If anyone's interested, you're welcome to PRs. :)
; assignment (name binding)
(= myVar 'myValue')
wisp also generates very nice JS code (and source maps), and my only real problem with it is that it lacks the time and resources ClojureScript clearly commands at this point.
(edited to add: wisp also has a fair amount of activity: https://gitter.im/Gozala/wisp)
Jisp on the other hand looks like it's a straightforward transpiler, with more or less one to one mapping between Jisp and JS constructs, without the need for providing large runtime. It looks like CoffeeScript with a sexps-based syntax. It reminds me of Hy language and Lisp Flavored Erlang, which I feel are similar projects (for Python and Erlang respectively).
There are at least 3 other Lisp dialects with similar philosophy on JS (excluding ClojureScript) out there, but when I last looked on them I wasn't convinced by any one and I stayed with LiveScript for work and I started exploring ClojureScript. I'll definitely take a look at Jisp now as a potential LS replacement.
Sweet.js, which is modeled after Racket parse transforms, allows for importing only those syntactic extensions you're interested in and most of those macros will probably compose nicely. I always supported the idea of Sweet.js, but I didn't use it because its library of available macros was too small (I'd need to reimplement too much of LiveScript) and macros in syntaxes as complicated as JS are a huge pain to properly display in editors. ki would probably solve the latter problem for me - with syntax that regular adding support for it to js-mode in Emacs shouldn't be too hard. This could mean that it's time to try Sweet.js for real!
These are fun projects, and I don't doubt that the authors and a few individuals have or will get great use of of it, but the market is saturated with languages that compile JS right now and very few stick out or are likely to get critical mass. Even Coffeescript, which is probably the most popular one, has a small community.
There's lots of reasons for a hobby or research project to reinvent a particular wheel. Not everything has to be efficient or practical. But it's probably at least worth considering.
Just musing, but just supporting a js target could replace clojure in entirety since the jvm also has a js runtime.
To this day I still can't fathom why someone thought it'd be acceptable to violate conventions by providing is<Type>() methods that do not return boolean results.
That said, I don't see the need for this language. Wisp and Clojurescript seem to have a lot more mindshare and I don't see a big enough benefit here to warrant splitting the community.
Personally I dislike usage of source maps for Coffee. I want to know what code is being generated. It's good for your health to know this. Most serious C programmers know at least the basics of what asm their compiler generates from which C construct. They can read it (compiled asm) too. I see no reason why this shouldn't be true for Coffee and JS, where it's much, much easier to do anyway.
EDIT: also, as noted by my sibling, it's open source and on Github. You can just go and implement source maps support, I think your pull request would be quickly merged...
"A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language, often having a binary form known as object code)"
It's even sourced. There's nothing here saying that "target language" can't be another high level language; and if you look at CoffeeScript (for example) implementation you'll see that it's structured as any other compiler would be. I think "transpilation" would be a bit more precise, but I don't think "compilation" is incorrect term.
I agree and stand corrected.