Is that a right goal to be compatible with clojure?

[eldargab]

That what distracts me in wisp a lot. I bet namespaces is what every js programmer hates :) Plus wisp's semantics is very different. At the same time there is already ClojureScript.

I am not a clojure programmer and also don't have much experience with lisp's so I am not arguing but I think it's obvious that compiler/language could be much simpler and more like js without clojure compatibility in mind. After all wisp's Readme were saying:

Homoiconic syntax and macroses are the primary motivations!

[Gozala]

That what distracts me in wisp a lot.

Compatibility with clojure means broader community of people and ability to leverage on lot's of good tooling that people have created, most basic example would be syntax highlighting editor support, etc...

I bet namespaces is what every js programmer hates :)

I'm afraid I can't stop people from hating things, but I'm trying my best to pick and choose features such that using wisp will feel natural for both communities. Also namespace support added is nothing more than just a module wrapper defining it's dependencies. That being said use of ns form is not ever required and plain require will do just as fine.

Plus wisp's semantics is very different. At the same time there is already ClojureScript.

I don't think wisp semantics are very different, it's just provides limited capabilities in comparison to Clojure(script). As of Clojure(Script) existence, there have being quite a bunch of people frustrated by the complicated dev process (including myself) which really feels like build for people coming from Java background, in way wisp is attempt to show how that could be better and I believe is more JS friendly.

I don't really understand what are your constraints, or why that causes you distractions. Can you please elaborate ?

[eldargab]

why that causes you distractions. Can you please elaborate ?

Namespace construct. Though currently it's optional that doesn't prevent you from knowing what it does and from using it perhaps indirectly. Also I don't very like "export everything by default" convention as well as may be few other details which I don't remember.

As an attempt to be more constructive I'd like suggest the following:

(import-macro a b c "foo") ;; import a, b, c macroses from the foo module
(import foo "foo") ;; var foo = require('foo')
(exports 10) ;; module.exports = 10
(export :foo "foo") ;; exports.foo = "foo"

where lookup procedure for macro importing is completely separate from compiler. Macroses are installed on compiler level with full src file path prefix.

[Gozala]

Namespace construct. Though currently it's optional that doesn't prevent you from knowing what it does and from using it perhaps indirectly.

I'm not sure what your trying to say here, indeed it does not prevents you from learning about namespaces and writing clojure compatible code, but again you have choice not to do that. In other words I don't see any strong arguments that would overweight benefits of clojure compatibility.

Also I don't very like "export everything by default" convention as well as may be few other details which I don't remember.

I'm afraid I prefer clojure's export by default than node's export only one thing... I don't really see why would I not share code that's in my module, and if I have a reason there is a way to do that to.

As an attempt to be more constructive I'd like suggest the following:

(import-macro a b c "foo") ;; import a, b, c macroses from the foo module (import foo "foo") ;; var foo = require('foo') (exports 10) ;; module.exports = 10 (export :foo "foo") ;; exports.foo = "foo"

Macro imports are not supported yet, macros are installed globally, but fixing that is high priority work for me.

where lookup procedure for macro importing is completely separate from compiler. Macroses are installed on compiler level with full src file path prefix.

I don't quite understand your comment here, my guess would be guessing is decoupling of path resolution from compiler. If so I intend to do the same as with module imports, imports will be resolved by ID's, while actual path resolution will be deferred to a backend in case of node it will follow node's module resolution logic.

[eldargab]

but again you have choice not to do that

Unfortunately not because others will do that and you will encounter that construct again and again while reading a third party code or collaborating.

[Gozala]

If you've encounter more and more people using this construct (which BTW I hope will be a case) and you're only one who does not want's to, it maybe a good indication there is something wrong with your choices.

[jkroso]

I'm questioning the idea of built in clojure interop too. Sounds like a nightmare trying to interop with both JS and CLJS. Has anyone managed to do that yet?

[Gozala]

I'm questioning the idea of built in clojure interop too. Sounds like a nightmare trying to interop with both JS and CLJS. Has anyone managed to do that yet?

Are you suggesting anything specific here ? I'm pretty happy the way things are working out, previous comments were advocating against namespaces, which IMO are very useful and powerful, in fact a lot better than plain js modules. For example protocols are only possible because of the namespaces.

To be clear aim isn't to be a fully clojure compliant, there are ton of other things in clojure that aren't present in wisp. But when there's a choice between doing what clojure(script) does and inventing a slightly different thing, I favor to follow clojure.

[jkroso]

Are you suggesting anything specific here ?

Not really I'm just thinking it would make everything harder. I don't really even know how to get started with wisp. Do I use both npm and leiningen to manage deps. I was wondering if there are any projects built with wisp I could use as an example.

protocols are only possible because of the namespaces

Oh I thought namespaces were just a JVM legacy. I'll read up on that.

[jkroso]

OK I've read a bit about namespaces and from what I can tell your comment about them being more powerful than js modules is wrong. Namespaces allow a separation of the modules location in the file system from the name its referred to in code. Thats all (am I wrong?). I guess this was nice if you didn't have the fs == ./node_modules/fs || ../node_moules/fs || ../../node_modules/fs etc.. convention, since it shortened your require calls. But in an environment where you have that its just bad. For example with namespaces if you fork a module you must change its namespace. With nodes module system you don't worry about it because file paths can never collide.

I think I might be misunderstanding something though because I see no reason namespaces are required for protocols as you suggested. Could you explain that?

[thehydroimpulse]

@jkroso I wouldn't even say namespaces might of been a JVM legacy thing, they're a Clojure feature, and a good one at that.

I'll also note that Wisp must adopt some kind of module system for the client-side of things. Namespaces are kinda solving that need.

I'm personally not a fan of ClojureScript because of the non-idiomatic JavaScript and build process. The JVM is too heavy for interactive building, and not very appropriate for JavaScript projects. ClojureScript also requires the use of Google Closure, which produces the ugliest code known to man. While that's kinda the point, so you can shrink the standard lib to a super small size, it makes it dead impossible to interop with existing JavaScript. Thus, for those who already have a large code base, you simply can't use ClojureScript.

[jkroso]

I wasn't saying clojure namespaces are bad absolutely, just relative to nodes. And for client side stuff I'd like to use the same thing the JS community uses.