4 ms·

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

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/ 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 structures and utility functions. But why would you want Clojure syntax without Clojure semantics? Especially since Clojure syntax implies several data types that JavaScript can't provide natively. It just doesn't make sense...

wirrbel 13y ago
I like ClojureScript and use it a lot lately. Sometimes however it feels a little distant from JavaScript at times. This can be frustrating at times. Wisp is somewhere between ClojureScript and JavaScript. Of course this means that some of Clojure's features (protocols and lazy sequences, atoms, etc.) are not available. On the other hand there are not so many opaque layers between your code and the target code. Granted feature-wise it might be more similar to a scheme, but Clojure Syntax is so much more readable and I do not see a point why it would not be a valid approach.
- gozala 13y ago
  > Of course this means that some of Clojure's features (protocols and lazy sequences, atoms, etc.) are not available. On the other hand there are not so many opaque layers between your code and the target code. As a matter of fact I plan to provide protocols lazy sequences etc.. in form of (optional) libraries that can be included or omitted based on user use cases. I personally thing that most of these features are drawbacks when interacting with JS code, although I'd definitely used them in cases where interaction with JS is not a concern.
i_s 13y ago
I see some reasons on the guys site here: http://jeditoolkit.com/2012/09/16/coljurescript-feedback.html#post 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 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.
k2052 13y ago
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.
- kyllo 13y ago
  Yeah, I think the concept of sticking a JVM in the middle of the process of generating browser scripts is very strange. Clojure has a lot of JVM specific quirks that don't make sense in the context of Javascript at all. And if you're coming from another Lisp/Scheme dialect, Clojure is definitely nontrivial to learn. Wisp looks like Javascript was supposed to look before they bolted C syntax onto it. People say that Javascript is like Scheme with C syntax. So Wisp is like Javascript with Scheme syntax. I think this is something I would actually use. I didn't know about LispyScript either, though. I would have to compare/contrast the two.
elangoc 13y ago
I agree. The comments here make me think that the commenters don't know all of the extra ideas that Clojure brings besides a "different syntax" to Lisp. Even just for the immutable, persistent data structures that support value semantics (& distinguishing state from identity), ClojureScript ought to go a long way to helping write better code.
- prollyignored 13y ago
  Worse is better. Wisp, I guess provides readable js as opposed to compiled js. That's a win.
- gozala 13y ago
  Note that most functions exposed by wisp do not mutate existing data structures and match clojure in behavior, it's just they use array's instead of vectors and dictionaries instead of maps. My hope is that it will imply same immutable style even if underlying data types remain mutable.
TheHydroImpulse 13y ago
Also, I find the Google Closure library to be way too heavy for a transpiled language. It adds it's own library tools and separates itself from traditional JavaScript paradigms. Letting the transpiled language to do just that and doesn't impose it's own run-time restrictions would be perfect. After looking over Wisp real quick, it seems like it does just that. I was pretty dissapointed with ClojureScript because it generates almost unreadable JavaScript; It includes an extremely heavy library that most people don't use and would never use; It depends on a lot of JVM specific things. For it to be a lot more successful as a compile-to-javascript platform it would need to move closer to native JavaScript than anything else.
gozala 13y ago
I've tried to elaborate my reasoning in the readme actually: > Unlike clojurescript, wisp does not depends on JVM and is completely self-hosted. It compromises clojure's awesome data structures and embraces native JS data structures to be a better at cooperation with JS. Goal of wisp is to present a subset of clojure(script) language such that packages written in wisp can be consumed natively by wisp, clojure(script) and JS when compiled, without data marshalling or any code changes. While I do like clojure(script) a lot I don't think it makes too hard to consume data structures from JS land and makes consuming data produced by clojure(script) awkward for consumption on the JS side. That is a the reasonable compromise for a great power, it's just I think I'd rather leverage JS data structures in immutable manner directly and provide more clojure like data structures in form of libraries. This would allow users to make best (or maybe worst) choices based on their constraints. As of lispyscript it's nice project and as a matter of fact wisp is just a fork that never got merged in to upstream. I was convinced that clojure (or any other known lisp) syntax was better option than yet another new lisp. In addition I wanted full macros that unlike wisp lispyscript does not has. Also lispyscript has no lists, instead it uses arrays and I can continue this list over and over... > But why would you want Clojure syntax without Clojure semantics? Especially since Clojure syntax implies several data types that JavaScript can't provide natively. It just doesn't make sense... JS can do it otherwise clojurescript won't be possible, I just think these data types can be exposed via optional libraries as they have associated cost in terms of performance overhead and learning curve. And to be quite honest I do hope that a lot of wisp parts will find it's way to clojurescript, it's just contributing to clojurescript turned out to be harder than bootstraping own version, since even pull requests for travis-ci integration tests require lot's of justification.

wirrbel 13y ago

I like ClojureScript and use it a lot lately. Sometimes however it feels a little distant from JavaScript at times. This can be frustrating at times. Wisp is somewhere between ClojureScript and JavaScript. Of course this means that some of Clojure's features (protocols and lazy sequences, atoms, etc.) are not available. On the other hand there are not so many opaque layers between your code and the target code. Granted feature-wise it might be more similar to a scheme, but Clojure Syntax is so much more readable and I do not see a point why it would not be a valid approach.

gozala 13y ago
> Of course this means that some of Clojure's features (protocols and lazy sequences, atoms, etc.) are not available. On the other hand there are not so many opaque layers between your code and the target code. As a matter of fact I plan to provide protocols lazy sequences etc.. in form of (optional) libraries that can be included or omitted based on user use cases. I personally thing that most of these features are drawbacks when interacting with JS code, although I'd definitely used them in cases where interaction with JS is not a concern.

i_s 13y ago

I see some reasons on the guys site here: http://jeditoolkit.com/2012/09/16/coljurescript-feedback.html#post 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 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.

k2052 13y ago

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.

kyllo 13y ago
Yeah, I think the concept of sticking a JVM in the middle of the process of generating browser scripts is very strange. Clojure has a lot of JVM specific quirks that don't make sense in the context of Javascript at all. And if you're coming from another Lisp/Scheme dialect, Clojure is definitely nontrivial to learn. Wisp looks like Javascript was supposed to look before they bolted C syntax onto it. People say that Javascript is like Scheme with C syntax. So Wisp is like Javascript with Scheme syntax. I think this is something I would actually use. I didn't know about LispyScript either, though. I would have to compare/contrast the two.

elangoc 13y ago

I agree. The comments here make me think that the commenters don't know all of the extra ideas that Clojure brings besides a "different syntax" to Lisp. Even just for the immutable, persistent data structures that support value semantics (& distinguishing state from identity), ClojureScript ought to go a long way to helping write better code.

prollyignored 13y ago
Worse is better. Wisp, I guess provides readable js as opposed to compiled js. That's a win.
gozala 13y ago
Note that most functions exposed by wisp do not mutate existing data structures and match clojure in behavior, it's just they use array's instead of vectors and dictionaries instead of maps. My hope is that it will imply same immutable style even if underlying data types remain mutable.

TheHydroImpulse 13y ago

Also, I find the Google Closure library to be way too heavy for a transpiled language. It adds it's own library tools and separates itself from traditional JavaScript paradigms. Letting the transpiled language to do just that and doesn't impose it's own run-time restrictions would be perfect. After looking over Wisp real quick, it seems like it does just that. I was pretty dissapointed with ClojureScript because it generates almost unreadable JavaScript; It includes an extremely heavy library that most people don't use and would never use; It depends on a lot of JVM specific things. For it to be a lot more successful as a compile-to-javascript platform it would need to move closer to native JavaScript than anything else.

gozala 13y ago

I've tried to elaborate my reasoning in the readme actually: > Unlike clojurescript, wisp does not depends on JVM and is completely self-hosted. It compromises clojure's awesome data structures and embraces native JS data structures to be a better at cooperation with JS. Goal of wisp is to present a subset of clojure(script) language such that packages written in wisp can be consumed natively by wisp, clojure(script) and JS when compiled, without data marshalling or any code changes. While I do like clojure(script) a lot I don't think it makes too hard to consume data structures from JS land and makes consuming data produced by clojure(script) awkward for consumption on the JS side. That is a the reasonable compromise for a great power, it's just I think I'd rather leverage JS data structures in immutable manner directly and provide more clojure like data structures in form of libraries. This would allow users to make best (or maybe worst) choices based on their constraints. As of lispyscript it's nice project and as a matter of fact wisp is just a fork that never got merged in to upstream. I was convinced that clojure (or any other known lisp) syntax was better option than yet another new lisp. In addition I wanted full macros that unlike wisp lispyscript does not has. Also lispyscript has no lists, instead it uses arrays and I can continue this list over and over... > But why would you want Clojure syntax without Clojure semantics? Especially since Clojure syntax implies several data types that JavaScript can't provide natively. It just doesn't make sense... JS can do it otherwise clojurescript won't be possible, I just think these data types can be exposed via optional libraries as they have associated cost in terms of performance overhead and learning curve. And to be quite honest I do hope that a lot of wisp parts will find it's way to clojurescript, it's just contributing to clojurescript turned out to be harder than bootstraping own version, since even pull requests for travis-ci integration tests require lot's of justification.