
LispyScript - amelius
http://lispyscript.com/
======
lighthawk
Neat!

Now look at:
[https://github.com/clojure/clojurescript](https://github.com/clojure/clojurescript)

And try it:
[http://himera.herokuapp.com/index.html](http://himera.herokuapp.com/index.html)

~~~
zupatol
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.

~~~
swannodette
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.

~~~
didyoucheckthe
> "again this is only relevant for advanced production builds"

So, all real-life builds that anyone would care about.

~~~
moonchrome
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.

~~~
minikomi
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
    

If you return to the terminal, you should have a connected REPL now running.
Along with live code reloading on save of your cljs files.

~~~
moonchrome
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

~~~
minikomi
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..

------
evmar
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](https://github.com/martine/pjs/blob/master/lib/macro.pjs)

------
lispm
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/](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.

~~~
gjm11
> 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.

~~~
lispm
Well said! ;-)

------
aidenn0
See also:
[https://github.com/vsedach/Parenscript](https://github.com/vsedach/Parenscript)

TLDR: s-expression syntax for javascript, macros are written in common lisp.

~~~
TeMPOraL
Macros can actually be written in Parenscript as well, AFAIR. But the language
blends itself very naturally with CL code.

~~~
aidenn0
parenscript macros are in straight common-lisp. They expand to parenscript, of
course.

------
1971genocide
Also check out LiveScript.

[http://livescript.net/](http://livescript.net/)

and its awesome FP library inspired by haskell's prelude.hs

[http://www.preludels.com/](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.

~~~
amyjess
Why did they name it that?

LiveScript was Netscape's original name for JavaScript, before Sun asked them
to throw in some Java branding.

~~~
rane

      > Name
      >
      > LiveScript was one of the original names for JavaScript, so
      > it seemed fitting. It's an inside joke for those who know
      > JavaScript well.

------
jestar_jokin
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."

------
grayrest
> An inherent problem with Javascript is that it has no macro support, unlike
> other Lisp like languages.

[http://sweetjs.org/](http://sweetjs.org/)

There are macro systems for Javascript, just not native ones.

~~~
JoelMcCracken
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.

~~~
drunkcatsdgaf
First commit for lispy - march 5, 2012 First commit for sweet.js - August 1,
2012

im actually pretty shocked they are that close together.

~~~
JoelMcCracken
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.

------
breuleux
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/](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.

------
frakturfreund
Also Spock (Chicken Scheme wiki): [http://wiki.call-
cc.org/eggref/4/spock](http://wiki.call-cc.org/eggref/4/spock)

------
elwell
Wisp should also be added to this list:
[https://github.com/Gozala/wisp](https://github.com/Gozala/wisp)

------
woadwarrior01
Nice. This is reminiscent of HyLang[1], which is like this for Python.

[1]: [http://hylang.org/](http://hylang.org/)

------
rndn
There is no shortage of JavaScript-Lisps, that’s for sure!

------
ktg
LispScript |
[https://bitbucket.org/ktg/lispscript](https://bitbucket.org/ktg/lispscript)

Try LispScript |
[http://ktg.bitbucket.org/lispscript/lispscript.html](http://ktg.bitbucket.org/lispscript/lispscript.html)

------
sebastianconcpt
Nice! reminded me of
[http://ympbyc.github.io/LittleSmallscript/](http://ympbyc.github.io/LittleSmallscript/)

------
Turing_Machine
BiwaScheme is also pretty decent.
[http://www.biwascheme.org/](http://www.biwascheme.org/)

------
Touche
also [http://sibilantjs.info/](http://sibilantjs.info/)

