LispyScript(lispyscript.com)
lispyscript.com
LispyScript
http://lispyscript.com/
42 comments
Clojurescript has to be compiled by the google closure compiler on the server side. The closure compiler doesn't work out of the box with other libraries, you need some kind of bridge.
Lispyscript has the very nice advantage of being able to run directly in the browser. Since it's translated directly to javascript, I expect it won't have problems using other javascript libraries.
Lispyscript has the very nice advantage of being able to run directly in the browser. Since it's translated directly to javascript, I expect it won't have problems using other javascript libraries.
Some inaccuracies here. ClojureScript does not have to be compiled by Google Closure. That pass is an optional one for production builds. There is no "bridging" when using the Closure Compiler with non-Closure compatible code. The issue is that in production mode the Closure Compiler will make aggressive assumptions about what it can rename. So it's not about bridging it's about preventing renaming - again this is only relevant for advanced production builds.
That said for non-Web applications or applications where advanced compilation isn't that useful providing a bootstrapped ClojureScript is desirable. We've been working on that slowly for a long time now. In the coming months you'll see changes such that the ClojureScript compiler can itself be compiled into JavaScript.
That said for non-Web applications or applications where advanced compilation isn't that useful providing a bootstrapped ClojureScript is desirable. We've been working on that slowly for a long time now. In the coming months you'll see changes such that the ClojureScript compiler can itself be compiled into JavaScript.
> "again this is only relevant for advanced production builds"
So, all real-life builds that anyone would care about.
So, all real-life builds that anyone would care about.
Think about where you would use CLJS - my use cases would not have an issue with extra 100kb of code - you don't use CLJS to do jQuery animations on your web page - you would use it to build complex single page apps or write server side code/scripts.
You don't use clojure for performance anyway, it's going to be slower by default (because of immutability/persistent data structures, and yeah I know about react benefits with immutability that's not my point - you're still going trough a lot more memory and stressing GC) - you use it to help you deal with your code because of it's semantics.
But in reality last time I tried CLJS I didn't really feel like it delivers on the productivity part and it's mostly because of implementation issues. IMO the decision to implement CLJS on top of Closure compiler and in Clojure (instead of going for a self hosting compiler) was a mistake - you can't overstate the value of REPL and fast iteration in a language like Clojure - and my last attempt to use CLJS the compiler/REPL environment far from what I would consider fast iteration : compiler took forever to start because of JVM and while it could run as a service it needed to be restarted frequently enough that it mattered, REPL was very unstable it would just die randomly - sometimes you'd need to refresh the page, sometimes you'd need to restart the server process. Oh and don't even get me started on the voodoo needed to get the damn thing running - install piggieback, then install austin and then add this weasel thingy then configure the server process all so you can get a halfworking repl and pray it doesn't break because good luck figuring out what's actually going on. Compare this to JS where I just go in to the devtools panel and test my code.
You don't use clojure for performance anyway, it's going to be slower by default (because of immutability/persistent data structures, and yeah I know about react benefits with immutability that's not my point - you're still going trough a lot more memory and stressing GC) - you use it to help you deal with your code because of it's semantics.
But in reality last time I tried CLJS I didn't really feel like it delivers on the productivity part and it's mostly because of implementation issues. IMO the decision to implement CLJS on top of Closure compiler and in Clojure (instead of going for a self hosting compiler) was a mistake - you can't overstate the value of REPL and fast iteration in a language like Clojure - and my last attempt to use CLJS the compiler/REPL environment far from what I would consider fast iteration : compiler took forever to start because of JVM and while it could run as a service it needed to be restarted frequently enough that it mattered, REPL was very unstable it would just die randomly - sometimes you'd need to refresh the page, sometimes you'd need to restart the server process. Oh and don't even get me started on the voodoo needed to get the damn thing running - install piggieback, then install austin and then add this weasel thingy then configure the server process all so you can get a halfworking repl and pray it doesn't break because good luck figuring out what's actually going on. Compare this to JS where I just go in to the devtools panel and test my code.
Things are progressing and I encourage you to have another look.
$ lein new figwheel myproject
$ cd myproject
$ rlwrap lein figwheel
Browse to http://localhost:3449
Maybe, but things progressed way further outside of CLJS space. If you told me this 2 years ago when I was in to it I would be jumping right on it - back when people were saying coffescript fixed JS problems :D
Right now JS has persistent datastructure libraries and TypeScript is a huge productivity boost - tooling is top notch - it makes JS manageable, once it gets async/await (which it should in the next couple of months) I'll be pretty happy with JS development story.
I'll miss some niceties like collection operations, homoiconicity and macros but on the other hand I have working optional type checking, excellent tooling and I don't have to code in AST serialization format with macros :D
Right now JS has persistent datastructure libraries and TypeScript is a huge productivity boost - tooling is top notch - it makes JS manageable, once it gets async/await (which it should in the next couple of months) I'll be pretty happy with JS development story.
I'll miss some niceties like collection operations, homoiconicity and macros but on the other hand I have working optional type checking, excellent tooling and I don't have to code in AST serialization format with macros :D
Interesting. Do you have a link to a very basic "get-started" in this space? Right now, figwheel / om or figwheel / reframe are very quick to get started with (although familiarity definitely plays a part..). Last time I looked at js there were 5 or 6 or so flux implementations competing for mindshare and I had to stumble my way through setting up a project with webpack / babel..
Oh wow, that's a lot nicer than the last time I played with Clojure/ClojureScript. This plus Om makes me really want to play with it now.
ClojureScript applications start smaller than jQuery so I'm not really sure what you mean. If you're already using jQuery then ClojureScript applications are not large in comparison.
As far as your experiences sounds like a lot of your problems didn't have anything to do with ClojureScript and everything to do with trying to getting overly complicated 3rd party setups going. I've only heard woes from people trying to get piggieback + Cider going. I now recommend that people avoid those entirely for ClojureScript anyway.
I admit ClojureScript did have startup time issues but these were addressed earlier this year. ClojureScript can now compile "Hello, world!" from cold JVM boot in ~1.5 seconds. Of course auto-building has be subsecond for ages. REPL sessions start similarly fast and can go for hours without encountering problems.
ClojureScript may still not be your cup of tea but your complaints are not the sort I hear from users much these days.
As far as your experiences sounds like a lot of your problems didn't have anything to do with ClojureScript and everything to do with trying to getting overly complicated 3rd party setups going. I've only heard woes from people trying to get piggieback + Cider going. I now recommend that people avoid those entirely for ClojureScript anyway.
I admit ClojureScript did have startup time issues but these were addressed earlier this year. ClojureScript can now compile "Hello, world!" from cold JVM boot in ~1.5 seconds. Of course auto-building has be subsecond for ages. REPL sessions start similarly fast and can go for hours without encountering problems.
ClojureScript may still not be your cup of tea but your complaints are not the sort I hear from users much these days.
> compiler took forever to start because of JVM
No, because of Clojure itself. It is time for people to stop spreading this.
http://blog.ndk.io/2014/02/11/jvm-slow-startup.html
No, because of Clojure itself. It is time for people to stop spreading this.
http://blog.ndk.io/2014/02/11/jvm-slow-startup.html
Not really. Advanced optimizations doesn't matter for server-side JS whether Node.js or Nashorn.
This needs to be stressed. Performance in mobile web is already bad enough. If a tool has an optional, manual "improve performance" step, that is bad, it needs to be the default case and it needs to be a good citizen within the environment.
It seems I got many things wrong about ClojureScript. If I don't use the closure compiler, can I use any requirejs javascript library without problem?
Once you have the JavaScript version of the ClojureScript compiler, will it be reasonable to use it for compiling in the browser? That would be great.
Once you have the JavaScript version of the ClojureScript compiler, will it be reasonable to use it for compiling in the browser? That would be great.
There's very little in the JavaScript world that can't be made to work with ClojureScript. That said it could be made easier and official support for CommonJS and RequireJS is underway thanks to Maria Neise's Google Summer of Code work.
Yes there are additional steps involved for working with the Closure compiler, but in return, you get extremely robust dead-code elimination for your own code and third party code alike.
This turns out to be invaluable in production because most projects only realistically use a handful of functions from utility libraries that tend to be 10s of KBs in size.
This turns out to be invaluable in production because most projects only realistically use a handful of functions from utility libraries that tend to be 10s of KBs in size.
Coincidentally, I've been fiddling with a rather similar project, just as a hobbyist thing. It looks like this one is much farther along, kudos! Unfortunately from the contributions graph perhaps interest in it is dying off -- the last 10% (aka the last 90%) is always the hardest part to slog through...
I've been meaning to write up the various approaches to sexpressions+macros in JS. Mine differs from the others (and perhaps is closer to LispyScript) mostly in that it's close to JS in its names and semantics (e.g. "function" defines a function and you're still required to use a "return" statement), but then it lets you write macros to e.g. define "fn" where the return is implicit.
Anyway, here's some sample code from mine (which is itself defining macros used elsewhere in the compiler): https://github.com/martine/pjs/blob/master/lib/macro.pjs
I've been meaning to write up the various approaches to sexpressions+macros in JS. Mine differs from the others (and perhaps is closer to LispyScript) mostly in that it's close to JS in its names and semantics (e.g. "function" defines a function and you're still required to use a "return" statement), but then it lets you write macros to e.g. define "fn" where the return is implicit.
Anyway, here's some sample code from mine (which is itself defining macros used elsewhere in the compiler): https://github.com/martine/pjs/blob/master/lib/macro.pjs
Doesn't look like Lisp, more like Clojure.
Basically none of the functions, macros or syntax is from Lisp.
The documentation says:
http://lispyscript.com/docs/
> LispyScript is not a dialect of Lisp. There is no list processing in LispyScript . LispyScript is Javascript using a Lispy syntax (a tree syntax).
That's about right. It actually uses some kind of s-expressions, but not Lisp syntax.
The documentation says:
http://lispyscript.com/docs/
> LispyScript is not a dialect of Lisp. There is no list processing in LispyScript . LispyScript is Javascript using a Lispy syntax (a tree syntax).
That's about right. It actually uses some kind of s-expressions, but not Lisp syntax.
> Basically none of the functions, macros or syntax is from Lisp.
Sounds like it's extremely well named, then. LispyScript is to Lisp as Javascript is to Java: an entirely different language with different syntax, semantics, standard library and performance characteristics, but with just enough superficial similarity to provide plausible deniability for the name.
Sounds like it's extremely well named, then. LispyScript is to Lisp as Javascript is to Java: an entirely different language with different syntax, semantics, standard library and performance characteristics, but with just enough superficial similarity to provide plausible deniability for the name.
Well said! ;-)
This is why I called my version of this "Loosp", because it required a very loose (so probably incorrect) definition of Lisp to call it a Lisp: https://github.com/capnmidnight/betty-boop/blob/master/pong....
See also: https://github.com/vsedach/Parenscript
TLDR: s-expression syntax for javascript, macros are written in common lisp.
TLDR: s-expression syntax for javascript, macros are written in common lisp.
Also check out LiveScript.
http://livescript.net/
and its awesome FP library inspired by haskell's prelude.hs
http://www.preludels.com/
I have done all forms of projects using LiveScript - robotics, simple websites, blog, cryptography, computer vision.
Its actually becoming silently fairly mature.
It helps when it doesn't generate any hype like most languages.
The community around is also very helpful !
And LiveScript is awesome with React.js or any other virtual DOM based MVC framework.
http://livescript.net/
and its awesome FP library inspired by haskell's prelude.hs
http://www.preludels.com/
I have done all forms of projects using LiveScript - robotics, simple websites, blog, cryptography, computer vision.
Its actually becoming silently fairly mature.
It helps when it doesn't generate any hype like most languages.
The community around is also very helpful !
And LiveScript is awesome with React.js or any other virtual DOM based MVC framework.
Doesn't it say something about JavaScript, dissatisfaction with it, and the overwhelmingly splintered ecosystem, when every comment is suggesting alternatives to the solution in the article?
I guess we chalk this one up to "neat if you're a hobbyist or solo dev with no maintenance handover, but generally commercially unviable."
I guess we chalk this one up to "neat if you're a hobbyist or solo dev with no maintenance handover, but generally commercially unviable."
> An inherent problem with Javascript is that it has no macro support, unlike other Lisp like languages.
http://sweetjs.org/
There are macro systems for Javascript, just not native ones.
http://sweetjs.org/
There are macro systems for Javascript, just not native ones.
Not that you're wrong -- you're correct -- but I want to bring up that this was likely true at the time this was written. LispyScript has been around for a while.
First commit for lispy - march 5, 2012
First commit for sweet.js - August 1, 2012
im actually pretty shocked they are that close together.
im actually pretty shocked they are that close together.
I bet they both started around the time CoffeeScript started to get big -- it showed there was a market for compile-to-js-but-almost-js langs.
The website is down right now. https://github.com/mozilla/sweet.js
I wouldn't say Lisp-like syntax is necessary for a macro system. It helps a bit... but all things considered, I believe pattern matching is a bigger boon to macro writing than syntax per se.
For those it may interest, I have made a language with mostly conventional syntax which supports macros: http://breuleux.github.io/earl-grey/
The macro system is modular, so you can easily write and publish macro libraries. I have written some for testing, gulp, and react. It's not super mature but it's getting there.
For those it may interest, I have made a language with mostly conventional syntax which supports macros: http://breuleux.github.io/earl-grey/
The macro system is modular, so you can easily write and publish macro libraries. I have written some for testing, gulp, and react. It's not super mature but it's getting there.
Also Spock (Chicken Scheme wiki):
http://wiki.call-cc.org/eggref/4/spock
Wisp should also be added to this list: https://github.com/Gozala/wisp
Nice. This is reminiscent of HyLang[1], which is like this for Python.
[1]: http://hylang.org/
[1]: http://hylang.org/
There is no shortage of JavaScript-Lisps, that’s for sure!
LispScript | https://bitbucket.org/ktg/lispscript
Try LispScript | http://ktg.bitbucket.org/lispscript/lispscript.html
Try LispScript | http://ktg.bitbucket.org/lispscript/lispscript.html
Nice! reminded me of http://ympbyc.github.io/LittleSmallscript/
BiwaScheme is also pretty decent. http://www.biwascheme.org/
Now look at: https://github.com/clojure/clojurescript
And try it: http://himera.herokuapp.com/index.html