BiwaScheme is also pretty decent. http://www.biwascheme.org/
LispyScript
11–20 of 43 posts
Re: LispyScript
#12Also 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 LiveScrip…
Why did they name it that?
LiveScript was Netscape's original name for JavaScript, before Sun asked them to throw in some Java branding.
Re: LispyScript
#13Neat! Now look at: https://github.com/clojure/clojurescript And try it: http://himera.herokuapp.com/index.html
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.
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.
Re: LispyScript
#14> 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.
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.
Re: LispyScript
#15Doesn't look like Lisp, more like Clojure.
Basically none of the functions, macros or syntax is from Lisp.
The documentation says:
> 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.
Re: LispyScript
#16Doesn'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."
Re: LispyScript
#17Wisp should also be added to this list: https://github.com/Gozala/wisp
Re: LispyScript
#18Earlier quoted context omitted.
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.
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 on…
> "again this is only relevant for advanced production builds"
So, all real-life builds that anyone would care about.
Re: LispyScript
#19Earlier quoted context omitted.
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 on…
> "again this is only relevant for advanced production builds" So, all real-life builds that anyone would care about.
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.
Re: LispyScript
#20Neat! Now look at: https://github.com/clojure/clojurescript And try it: http://himera.herokuapp.com/index.html
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.
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.