Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LispyScript

lispyscript.com

Post reply on HN
Print view View original

31–40 of 43 posts

Re: LispyScript

#31

Post by moonchrome »

minikomi wrote: post #30
moonchrome wrote: post #28

Earlier quoted context omitted.

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 benefit…

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.

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

Re: LispyScript

#32

Post by girvo »

minikomi wrote: post #30
moonchrome wrote: post #28

Earlier quoted context omitted.

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 benefit…

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.

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.

Re: LispyScript

#34

Post by minikomi »

moonchrome wrote: post #31
minikomi wrote: post #30

Earlier quoted context omitted.

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.

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…

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

Re: LispyScript

#35

Post by aidenn0 »

TeMPOraL wrote: post #21
aidenn0 wrote: post #5

See also: https://github.com/vsedach/Parenscript TLDR: s-expression syntax for javascript, macros are written in common lisp.

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

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

Re: LispyScript

#38

Post by pjmlp »

moonchrome wrote: post #28
didyoucheckthe wrote: post #18

Earlier quoted context omitted.

> "again this is only relevant for advanced production builds" 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 benefit…

> 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

Re: LispyScript

#39

Post by zupatol »

swannodette wrote: post #13
zupatol wrote: post #9

Earlier 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…

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.

Re: LispyScript

#40

Post by lispm »

gjm11 wrote: post #27
lispm wrote: post #15

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.

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

Well said! ;-)
Post reply on HN