Live data from Hacker News

Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

jeditoolkit.com

21–30 of 52 posts

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#21

Earlier quoted context omitted.

If you're interested in lisp without the JVM, there's always ClojureScript. Once the JVM compiler is up an running it compiles most of my ClojureScript code in about 1 sec, and there's utilities that auto re-compile code as files change.

"without the JVM" ... "Once the JVM compiler is up" Does not compute! :P

Can't quite tell if you're serious or joking. In case it's the former: the ClojureScript compiler is implemented in Clojure, which runs on the JVM. The compiled code is Javascript, which doesn't require the JVM. There have been some discussions about making the compiler hostable from Javascript as well, but it's not possible just yet.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#22

As somebody who contributes to ClojureScript, I genuinely do not understand the purpose of this project. If you want a JavaScript with Lispy syntax, there are a few things like http://lispyscript.com/ -- Spiritually similar to CoffeeScript. But if you want Clojure semantics, there is ClojureScript: Very different than a simple transpiler like CoffeeScript. ClojureScript includes a standard library of rich data struct…

I see some reasons on the guys site here: http://jeditoolkit.com/2012/09/16/coljurescript-feedback.htm...

Update:

Also, on the projects web site [0], it says that "Homoiconic syntax and macros are the primary motivations!"

[0] https://github.com/Gozala/wisp

I don't know how this project is in practice, but I think those goals are worthwhile. When it comes to Clojure proper, one of the many selling points is that it does Java better than Java. This project may be able to do the same for Javascript.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#23
post #8
post #5

Earlier quoted context omitted.

Those are 3 distinct types in Clojure; unfortunately they have no equivalents in JavaScript, thus they become strings.

To my knowledge, keywords are actually functions in Clojure, which do have an equivalent in JS. "Looks more like Clojure" seems like a good enough reason to me.

They can be used as functions, but I think they're implemented differently for optimization. Could be wrong.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#24
post #8
post #5

Earlier quoted context omitted.

Those are 3 distinct types in Clojure; unfortunately they have no equivalents in JavaScript, thus they become strings.

To my knowledge, keywords are actually functions in Clojure, which do have an equivalent in JS. "Looks more like Clojure" seems like a good enough reason to me.

Keywords implement many interfaces, function (IFn) being one of them. See this line in the clojure source code:

  public class Keyword implements IFn, Comparable, Named, Serializable, IHashEq 
https://github.com/clojure/clojure/blob/master/src/jvm/cloju...

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#25

As somebody who contributes to ClojureScript, I genuinely do not understand the purpose of this project. If you want a JavaScript with Lispy syntax, there are a few things like http://lispyscript.com/ -- Spiritually similar to CoffeeScript. But if you want Clojure semantics, there is ClojureScript: Very different than a simple transpiler like CoffeeScript. ClojureScript includes a standard library of rich data struct…

A primary benefit of things like Wisp is it makes it easier for non-clojure users to dive in and learn a clojurescript like language. I like JS and I like Lisps but the learning curve for clojurescript is too much if you don't know Clojure already. Wisp feels much more JS like; with my decent JS and decent Scheme knowledge I feel I could just dive in and play with it. Clojurescript does not leave me with the same impression, it feels like a lot of work to get up and learning.

Clojurescript's heavy dependence on the Clojure environment (JVM, leinigren etc) make it a real pain to get setup for. I have looked into clojurescript several times but thought "I better master clojure first". I have been getting a hang of Clojure slowly and plan to tackle learning clojurescript eventually but something like Wisp opens up the possibility of diving in without needing to be comfortable with all the Java crap.

I only tend to take up something when it takes me five minutes to start learning. I think most are the same way; it's the reason why Codecademy is so popular and why clojurescript's primary user base is Clojure users. The more users that can start learning a language in five minutes the better it is for that language. Clojure beat out other Lisp implementations primarily because it was easier to dive into for a greater number of humans than any other Lisp.

Wisp and other implementations like it make diving into Lisp->js languages much easier. It removes the large roadblock that is Java, a roadblock that is unnecessary if your target language is JS not Java.

Re: Wisp: a homoiconic JS dialect with Clojure syntax, s-expressions and macros

#30
post #11
post #4

What is the benefit of having three ways to write strings? \a ;; compiles to "a" :a ;; compiles to "a" "a" ;; compiles to "a" This is not meant as destructive criticism; I'm genuinely interested in the motivation for that.

Seems like a disadvantage to me. It's mostly just confusing and the only thing it affords is the ability to use :keywords as functions (:like so) which is just sugar for property access, so["like"]. This is broken, though. The coolest thing about :keywords in Clojure is that they really are functions and you can do things like (map :keywords ontoSomething) to extract the same property out of many things. It don't wor…

What you're not realizing, though, is that each time you use the string "like" as a key for a map/dictionary, you're allocating a new object on the heap. So what if you have many keys, and they're all strings? What if you have many maps that share the same keys? That's a lot of memory to allocate, and strings are an extremely inefficient way to implement what is essentially a unique identifier to address map values. Instead, use an integer as a unique identifier.

That's basically what keywords do -- they are human-readable and compile down (prob. using some hash) into some integer, and the integer is stored globally only once. The biggest savings in memory comes when using maps, and that's how & why keywords get their name.

Post reply on HN