Well, the first 10 or so lines define a macro; I suspect the author was not counting those. This is not entirely unfair, since we're also not counting the code Gulp used to give you that nice builder-style API.
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."
I feel like someone should note the irony of finding this comment on HN, which is implemented in Arc: a language that was explicitly designed to be as terse as possible.
Terseness at different levels. Avoiding boilerplate syntax is good. Obscure abbreviated names of functions and operators just to save a few keystrokes is bad.
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.
I know nothing about programming languages. What makes you predict that, and what makes you feel terseness cannot be a programming language's selling point?
One of the problems with terseness is that it can make code completely unreadable. You can write perfectly readable code with it, but the fact that it's easy to make dense, inscrutable code can make things a nightmare when you're looking at what someone else has made. Especially if that person is a Real Programmer[1].
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.
Terseness itself tends to confusing and difficult to understand code. Support for extreme terseness formed a large part of the complaints against perl. For examples of powerful languages geared toward terseness, see APL or its derivative J.
Language author here. I feel pretty stupid for what I wrote in the documentation. Commenters here are entirely right to bash it for claims of terseness on the syntax level because that's not an advantage, just a questionable tradeoff.
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. :)
Actually never heard of wisp. There's so many lispy dialects, smaller ones tend to get overlooked. I don't think I can get involved with another compiler at this point — got a bunch of other libraries underway, which have even muscled out jisp for the time being. Sorry :)
Personally, I find https://github.com/Gozala/wisp to be a whole lot more coherent and readable (and probably more mature, too, even though it has much less documentation).
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.
I'm yet to dive into Jisp, but from a few seconds of looking at the page I think the difference is quite obvious. ClojureScript implements semantics which are very different from JS on top of it, it comes with it's own runtime library, it relies on Google Closure Compiler to optimize it's JS which would be rather large otherwise. I don't know of any page where you get side by side clojurescript -> generated js code comparison. It's similar to js-of-ocaml and many other LanguageX-in-JS projects.
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.
Too late to edit: I just found ki (http://ki-lang.org/) which is a Lisp implemented as a set of macros on top of Sweet.js, which means you can a) freely mix it with JS; b) compose it easily with other Sweet.js macros. Now this is huge: all those compile-to-JS languages are nice, but they don't compose at all, ie. if you write Coffee and decide that there's a neat Sweet.js macro you'd like to use you're out of luck. You can't import just one operator (for example `|>`) from LiveScript to Coffee, you need to change the whole language. While this is not a big problem for me personally, it's still an unnecessary overhead.
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!
Hi! There are a few of us here, I saw at least 4 or 5 users mention LS on JS/Coffee/other related threads. I'm saying this because some month ago I was worried about LS future: there is nothing happening on the mailing list and commits on github are rather infrequent. But when I found a bug in LS compiler and fixed it the PR was processed in a reasonable time and the people were there to help. So I guess LS is just mature and somewhat complete at this point and not stagnating :) Which is very nice, because LS is the only lang I know of which gathers so many very useful features in a single language. This is even more true now when generators support was added. The only problem with LS is lack of source maps, but as it compiles to a rather readable JS it's not that bad. It probably limits its popularity greatly, though :(
its distinguishing feature is that it starts with idiomatic javascript and carefully adds lisp features to that, rather than porting an existing lisp to javascript. the readme calls it a "javascript-first approach" and notes that it was heavily inspired by coffeescript.
Came in here to post the same thing. As another Lisp to JavaScript transpiler and the popularity and support for ClojureScript already I think there needs to be some pretty compelling differences.
It needs to be different than ClojureScript as well as more than a dozen other lisp-to-js projects. [1]
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.
I personally am all about encouraging people to make all the new languages and tools they want, even if it duplicates existing stuff. But I also agree that the comparison with the similar stuff should probably be mentioned.
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.
I imagine the pain of setting clojurescript or cljx up with repls and such will soon be eclipsed by one of these dead simple compile to js lisps which seem to be coming out with increasing speed.
Just musing, but just supporting a js target could replace clojure in entirety since the jvm also has a js runtime.
Apologize if this is a dumb question but is the point here to make a language that's somewhat analogous to a stenographer typewriter or a Dvorak keyboard or something? In other words, you can write out new code in Jisp, then hit the compile button and it compiles to JS and you paste that into Sublime Text and you have thereby saved time?
Well if we want to get technical that's how every compiler works, except the stenographer is writing 0s and 1s instead of JS. Writing C saves you time over writing machine code, that's what a programming language is supposed to do. They make it easier for a human to give instructions to a computer.
Usually the compilation is automatic, but you've got the gist of how it works. Saving time isn't usually the main point of these compile-to languages. They usually do something better than the underlying language. In this case, it's the goal is probably more uniform syntax.
A word of warning, there is plenty of google brain cancer in GWT, one of my personal favorites that elicited "wtf..."s frequently in a previous occupation:
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.
In my 1 year of using GWT, I've never had to use that class. Also, you're never required to use GWT's implementation of JSON, you're free to write your own.
Unhygenic macros isn't a drawback, just implement a hygenic macro system on top (this isn't difficult).
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.
If you're a competent JS programmer you don't need source maps in this case. It's hard to tell from the examples, but it looks like generated JS is not particularly hard to read. Source maps are a must for things like FunScript, js_of_ocaml, Whalesong; they are not very useful in langs like Coffee.
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.
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.