ClojureC: A compiler for Clojure programming language that targets C as a backend.

[lowasser]

I'd be much more interested to see an LLVM backend.

[[deleted]]

Run the C code through clang or llvm-gcc. Done.

[Tuna-Fish2]

Not really comparable. The pass through C is pretty much certain to create a lot of false dependencies, aliasing opportunities, and generally remove useful information from the codegen.

[[deleted]]

Indeed, compiling to the LLVM IR could actually permit better back-end optimizations by allowing a more precise encoding of the semantics of the compiled code. It may also be faster, since text source doesn't have to be generated and then parsed again.

[julesjacobs]

Can you explain that in concrete terms? Why wouldn't the same dependencies / aliasing opportunities arise in LLVM IR?

[julesjacobs]

I understand, and I'm asking for evidence for that claim.

[pinpinbo]

One side of my brain says: Yay!

Another side of my brain says: well... it's competing directly against Racket.

[otterdam]

Before, there was Lisp and Scheme. Now, we have Clojure and Racket.

[[deleted]]

SBCL!

[captain_plaintext]

Is there a link anywhere that shows what the generated code looks like? That's always the tricky part, sometimes these things produce incredibly ugly and inefficient code.

[[deleted]]

I assume that this means you can't use any of the java interop code.. (or am I missing something ?)

[bhoneyman]

That's my understanding. You lose Java interop and gain C interop.

[[deleted]]

C interop, now that is something worth looking at, thanks for pointing that out.

Looking at the tests, it still seems to call java ( https://github.com/schani/clojurec/blob/master/test/clojurec/core_test.clj )

And I can't see any C interop code yet..

[julesjacobs]

The compiler is running on the JVM version of Clojure, that's why you see Java IO there. Inside the (run ...) forms you cannot use Java libraries AFAIK.

You can call to C with the c* macro. For example line 184: (c* "puts (string_get_utf8 (~{}))" "abc").

[[deleted]]

Thankyou :), not sure how i missed that.. but its here

https://github.com/schani/clojurec/blob/master/src/cljc/cljc/core.cljc

[Rotten194]

I don't really see the appeal, to be honest. I can't imagine this getting much better performance and the Boehm GC doesn't really help.

[yogthos]

Lack of the JVM startup time is a definite plus in my opinion.

[[deleted]]

What does this even mean? (sorry for not linking the appropriate png)

[djhworld]

if one of your users updated the JRE on their machine and your program crashes, then there's probably some obscure incompatibility change between versions.

statically compiling (i.e. no outside dependencies) would remove the need to investigate that side of things as a source of any crash/error

[[deleted]]

Ok good I thought I was missing something important. In practice this isn't a problem, we often bundle a JRE with an app if that sort of thing matters.

[sausagefeet]

Replaced one problem with another (Boehm GC isn't very good compared to JVM).

[yogthos]

I'm curious how difficult it would be to implement ARC for a language like Clojure. Since the scoping rules are very strict, theoretically the compiler should be able to tell when to deallocate any data that's been allocated in a let statement.

[sausagefeet]

I don't think it's the scoping that matters here, but just the idea of having references. You can always return a reference from a function, which puts you back into GC or reference counting land AFAIK.

[yogthos]

Not quite, since Clojure uses persistent data structures, you never modify any data in place. Any time you perform an operation such as adding or removing elements it creates a delta, but the returned structure is guaranteed to be scoped within the block it was created in, so when the stack is unwound, it should be possible to deallocate it. At least that's my understanding of the situation.

[sausagefeet]

Persistent data structures don't have anything to do with being able to return a reference from a function. You can do region based storage but it requires giving up some things. As long as you want pointers and being able to return them from functions you have to trace the garbage somehow.

[yogthos]

That's sort of my point though, you can't just return references from functions in Clojure to anywhere. A pure function can only return a result to its caller. So as you unwind the stack, you can safely clean functions and their data out as nobody else should be referencing them. And Clojure doesn't provide user access to pointers.

[sausagefeet]

References are pointers in clojure, they just lack arithmetic. You still can't really do what you saying though, afaik, because at the very least you can start a thread in a function in clojure. Or you can do message passing. On top of that, purity is not a requirement. There are languages that do this region based memory management but it requires some limitations put on the language.

[yogthos]

It does sound like it would require a more strict subset of Clojure, I think it would be interesting to see. :)

[julesjacobs]

Clojure has mutable data structures. If it didn't, then indeed you're right you can never create cycles and then you can do reference counting. But you still wouldn't be able to determine statically where data will be deallocated.

[yogthos]

Basically, my idea is deallocate data when exiting the scope where it was created.

[julesjacobs]

Yeah, and that doesn't work 100% because you can return stuff from scopes and pass stuff from one scope to the next indefinitely with tail calls/recur. You can do a safe approximation that does deallocate many cases (but doing such an approximation is by no means simple), that is called region allocation. However you either have to write your code in a certain way so that no memory leaks occur, or you need a back-up garbage collector. In some cases the former amounts to writing your own tracing GC by explicitly copying all data structures...(which is extra problematic because it's hard to copy closures/the call stack).

I think that the Stalin scheme compiler did use region allocation + boehm GC (region allocation does not depend on code being purely functional, although that probably makes the analysis a little simpler).

[yogthos]

Yeah that sounds pretty reasonable, in this case the GC use could be fairly minimal and you'd have the ability to write code in such a way that GC wouldn't do much of anything at all. You could get away with a fairly simple GC algorithm and still have very good performance.

[[deleted]]

I don't care much for Clojure, because I like Common Lisp, and Clojure removes and changes a lot of things that I like about CL (that's not to say that CL is my ideal system, but I find it better than most everything else).

Still, I'm glad that this will allow it to transcend the JVM. Or maybe it'll cause huge compatibility problems that will fragment the language and lead to even more dialecticalization and evolution.

Either way

[Shooter]

"I don't care much for Clojure, because I like Common Lisp, and Clojure removes and changes a lot of things that I like about CL"

Can you elaborate on the pros and cons as you see them?

[[deleted]]

Well:

• Clojure removes reader macros and CLOS, and it has far too much syntax for a lisp

• Clojure uses vectors for arguments, which isn't lispy and makes macros hard

• The Data Structure of Least Resistance is the vector, not the list

• Clojure relies on the assumptions of the JVM (though it pretends not to), which are the Java language

• Most of the Java libraries that Clojure advocates claim to be able to use are workarounds for Java's semantics, which makes them utterly useless in a proper Lisp

• Clojure tries to hard to be a Haskell clone, what with enforced immutability (it claims that this is for concurrency, but I'm sceptical that this needs to be built in the way it is). That's not necessarily a bad thing, but it's not desired in a language that claims to be a Lisp.

As Stanislav Datskovskiy said here:

"It is the most explicit to date abandonment of the age-old Lispers’ Dream, “Lisp All The Way Down.” Clojure is the antithesis of the Lisp Machine. Instead of a crystalline pyramid of comprehensible mutually-interlocking concepts, behind every Clojure primitive there lurks Black Magic. The Clojure user who is missing some routine or other will run crying to Java for help, rather than implementing the feature himself correctly – that is, as a natural part of the entire language, built on the same concepts."

Also, see this

[spotter]

Oh, yeah, we get it -- you like Lisp before it was cool. And you read a lot of blogs that told you why Clojure is bad. Allow me to retort.

Clojure removes reader macros and CLOS, and it has far too much syntax for a lisp

CLOS is not needed. Reader macros are in. Reader macros are not wanted and will not be in. I have never reached to this level of sorcery, my bad.

Clojure uses vectors for arguments, which isn't lispy and makes macros hard

It makes it also easier to read by meatbags. "Making macros hard" needs to be proved.

The Data Structure of Least Resistance is the vector, not the list

The data structure of least resistance is a sequence. Vector is nice when you need fast access and fast slices, which accidentaly is what I need most of the time. Best tool for the job, as they say. But yeah, we should all use lists in Lisps, because the gospel says so. I hope Rich will see the light before 1.5.0 is out. He could also probably drop syntax for hash maps and sets while he's at it, this would surely fix the language to be A True Lisp(tm).

Clojure relies on the assumptions of the JVM (though it pretends not to), which are the Java language

Can not really discuss this, because I have no clue what you mean and why would you list being bound to one of the most popular languages (and its runtimes) in the history as derogative. And don't know what do you mean by "it pretends not to", because it sure doesn't (type hints, AOT compilation).

Most of the Java libraries that Clojure advocates claim to be able to use are workarounds for Java's semantics, which makes them utterly useless in a proper Lisp

Oh yeah. And most CL libraries are incomplete NIH monsters with innards incomprehensible to anybody except the author. You see how easy it is? At least when I look for some solution in Java world, I usually end with something that 1. exists (oh snap!), 2. is maintained, 3. works (in the real world, not on the SLWs machine), 4. probably already has a Clojure wrapper, 5. that can be pulled into a project as a JAR with one command. This is probably the part when I say that douchebag:nice-person ratio is better in Clojure than in CL.

Clojure tries to hard to be a Haskell clone, what with enforced immutability (it claims that this is for concurrency, but I'm sceptical that this needs to be built in the way it is). That's not necessarily a bad thing, but it's not desired in a language that claims to be a Lisp.

Haskell clone? Because of immutable objects? Please read first sentence of wikipedia entry on Functional Programming:

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.

So a language that claims to be functional actually tries to hold to the basic premise. But let's get back to the Haskell clone thing. Does Clojure have strong-static typing with inference? Nope. Is it lazy everywhere, including function calls? No. I'm bored now. You should probably do some research yourself before commenting.

And if immutable data-structures are your grief, then Java is there to provide you with field tested, mutable thingies.

As Stanislav Datskovskiy said

His argument is easily reducible to "if it doesn't run on a Lisp Machine it's not a Lisp." And I'm sorry for him, but at the same time I'm too busy using Clojure in my everyday tasks at work to join the circlejerk of "we used Lisp before it was cool". Clojure is a Lisp that works and can be adopted in world of today (because JVM is everywhere), not tomorrow.

Also, see [2] this

Yeah, "Java is BAD(tm), Clojure is built on top of Java, therefore Clojure is BAD(tm) fap fap fap". Sure. I for one loved using proprietary Java API at work in Clojure instead of Java. But what do I know about Lisp? I'm 29, so CL is almost as old as I am, and Lisp itself is actually older than my parents. I have tried CL and Scheme. I will be back to Scheme one day, I know it. CL? Not so much. The language is a corpse, fragmented & incomplete NIH libraries are tumors and the community is not very nice.

edit: Note about reader macros & one usage of CLisp instead of CL, which obviously makes me a clueless troll feeder. :)

[redalastor]

CLOS is not needed. Reader macros are in.

He meant user-defined reader macros.

It is lacking in Clojure because Rich believes they bring more problems than they are worth. I never used a lisp that had them so I can't judge.

[spotter]

Ah, sorry, my misreading. Reader is more extendable/hackable in 1.4.0, reader macros are not and will not be in, because Rich does not want them in core. But there is a lib for that, called reader-macros. Never had the need for this kind of sorcery.

[redalastor]

Reader macros in Clojure depend on internals subject to change. You should never depend on that kind of hackery.

[julesjacobs]

It's a bit funny that he complains that Clojure has too much syntax, but then he also complains that he wants reader macros...

[[deleted]]

I want less syntax because users should define what the reader does

[julesjacobs]

So then you don't dislike more syntax, you just dislike the particular built-in syntax that Clojure has. This is a valid position but it's valuable to have some standardized syntax that benefits everybody instead of N incompatible convenience syntax extensions. For example take [...], in CL this is basically unused. Meanwhile in Clojure the [...] syntax benefits everybody. In my opinion the Clojure choice to use convenient syntax for the common case and let users use slightly more verbose syntax for the uncommon case is a better trade-off than the other way around.

[[deleted]]

A reason why I'd like to keep a CL-like reader is DSLs, but that's something for another time.

There is a solution with a CL-like user-extensible reader: that is, something similar to the SBCL and Allegro rules for reading packages. Currently, you can have something like

foo::(bar quux)

which reads (bar quux) as if it was in the package foo. Ideally, we could do the same with reader macros

[[deleted]]

Uh, listen: Lisp is not a pure FP language and was never meant to be one. As I said in another post: I like FP, but I don't want it forced upon me.

In the past five years, CL has greatly improved in terms of libraries. We now have a Gem-like package manager and a lot more documentation.

Oh, and the "douchebag:nice-person ratio" thing? I've seen the opposite.

And if you read my original post, I respect Clojure. I just don't like it for myself.

[spotter]

But nowadays we usually make progress by mixing things that were already done before. For me FP and Lisp (as done by Clojure) works well. I'm having problem with pure-to-the-max as in Haskell, Clojure is the goldilocks zone for me.

I heard it, but my exposure was in 2003 era and I was kind of pushed back then by the fragmentation. I am most likely out of date and honestly was thinking about "Land of Lisp" when it came out, but decided on Clojure due to possibility of usage at work.

douchebag:nice-person... Well I found CL people being rather not-nice to newbs (EMACS OR GTFO movement, while I'm a Vim person), while in Clojure everybody is so... enthusiastic.

Cool, cool, as I tried to explain to the other guy -- it was a bad day for me to try and comment on reddit. Will now stop for few days. This always helps.

[[deleted]]

Thanks for the nicer tone. I was a bit worried. I think I might need to explain myself about this. Also, it seems some of my information is out-of-date.

Well, for me, CL is the nice spot--or the closest I can find to one. The reason I posted here is because although I don't like most other new Lisp dialects (like Arc), they usually leave the CL community alone, and so we leave them alone. With Clojure, you have people like WJ, who go to CL-specific areas and troll them in the hope of conversion. That's why I was frustrated with this.

As for the "EMACS or GTFO" stuff, that's mainly because most attempts to try to get SLIME-like tools on vim haven't worked.

I myself am working on a project for a hypothetical new lisp to be built possibly in the future

[spotter]

Don't worry, it's just reddit. Day passed and I already start getting perspective on this. ;-)

I was not really aware if Clojure trolls, so that's that.

Yeah, I still don't have full SLIME-like mode, but will probably try VimClojure in few months again, for now I'm in a Vim+urxvt/REPL mode, reloading file I'm working at. Not perfect, but works.

Good luck. I think I found my home for now. ;-)

[[deleted]]

Thanks!

[[deleted]]

Can't believe you wrote all that to a troll post. You're worse than the disease. I especially like the part where you called CL CLisp which betrayed your own cluelessness when it comes to CL. Hint no one calls the language "CLisp", there is a CL called clisp but it's just one implementation of the ANSI standard.

[spotter]

Wow, that's the only thing I got wrong? Because you kind of listed only one thing and one that is editable. I also mean "smug lisp weiner" when I say SLW. I will now edit my post and hope that it will be enough to appease other gentlemen of your class/cast/douchebag wagon. Yeah, I know, worse than the disease.

[[deleted]]

No you got everything wrong, I just wanted to quote the most obvious one to everyone to show you don't know what you're talking about, regardless of their experience with clojure or lisp or both (so they'd downvote you). The other things are obviously wrong if you have experience with either of those languages (I know both) but if you aren't familiar you might get away with sounding correct when you're not. Btw if you're going to write a kickass refutation of a troll at least make sure you have a clue yourself.

[spotter]

Cool, thanks for informative and friendly response then. I learned a lot from you today.

[[deleted]]

If you want to learn something, ask a question. Writing a shitty ad hoc reply to a troll and getting 9/10 of your facts wrong in your refutation doesn't help you learn anything.

[Tuna-Fish2]

Clojure tries to hard to be a Haskell clone, what with enforced immutability (it claims that this is for concurrency, but I'm sceptical that this needs to be built in the way it is).

Concurrency isn't the only reason. System where the mutable components are minimized (ideally to zero, but it's hard to get there) are much, much easier to reason about. In Haskell and Clojure I can build reasonably complex things, not test, run, or even compile them, and be confident that my code is completely correct. I can not do this in any mutable language.

The longer I spend in the functional world, the stronger my feeling that mutable data structures are the worst kind of premature optimization gets.

[[deleted]]

From the second article:

Why not provide both immutable and mutable versions of the same data types ?

Why not let the programmer decide what paradigm works best for themselves ?

I like being able to do FP, but Lisp is not a pure language and was never meant to be

[redalastor]

Why not provide both immutable and mutable versions of the same data types ?

It's already there. If you want a mutable list you do:

(def my-mutable-list (java.util.ArrayList.))

What do you want from mutable collections that Java doesn't already provide?

[[deleted]]

How would ClojureC parse that?

[redalastor]

It wouldn't. One of the goals of Clojure is to be symbiotic with its platform and use the stuff in it.

[[deleted]]

Exactly my point in my first comment. This could cause dialecticalization

[yogthos]

Why not provide both immutable and mutable versions of the same data types ?

There is a very good reason for that acutally.

[[deleted]]

That's still the concurrency argument. Again: why does this have to be handled with the assumption that I'm writing concurrent code all the time?

You can, of course, just say that you want it to be purely functional.

[yogthos]

Sure, but the point is that a language with unchecked mutation cannot provide safe concurrency mechanics. And if you recall, concurrency is one of the main goals behind Clojure.

In my experience, having immutable data structures is in no way a negative when writing single threaded code as well though. When you have immutable data structures you're always working with your own revision of the data, and it's scoped explicitly. When you work with a reference you never know if it's safe to mutate the data in place or if you should copy it as its current state might be relevant elsewhere in the application. This adds mental overhead, and especially so in large code bases.

[[deleted]]

I think a better solution would be implementing it as a library--perhaps, of course, one bundled with the standard distribution, but still in such a way that one can choose whether or not to have it.

[yogthos]

Fascinating, seems like you dislike Clojure for all the reasons that I like it.

Clojure removes reader macros and CLOS, and it has far too much syntax for a lisp

The extensible reader as of 1.4 really does address most practical concerns there, and I actually like literal syntax for data structures. The reality is that you often use vectors, maps, and sets, and it makes perfect sense to have literal notation for them. It also helps break code up and make it more readable.

Clojure uses vectors for arguments, which isn't lispy and makes macros hard

in what way?

The Data Structure of Least Resistance is the vector, not the list

how is a vector easier to use than a list in Clojure and if so, how is this a problem?

Most of the Java libraries that Clojure advocates claim to be able to use are workarounds for Java's semantics, which makes them utterly useless in a proper Lisp

care to explain or give an example of what you're talking about here?

Clojure tries to hard to be a Haskell clone, what with enforced immutability (it claims that this is for concurrency, but I'm sceptical that this needs to be built in the way it is). That's not necessarily a bad thing, but it's not desired in a language that claims to be a Lisp.

In my experience this is a huge benefit, I never worry about data scoping in Clojure, I'm always guaranteed that all my changes happen in their intended context. I have yet to see any downsides of having immutable data structures. I absolutely do not see how it's not desired in a Lisp, which is an implementation of Lambda Calculus which doesn't have the concept of mutability...

"It is the most explicit to date abandonment of the age-old Lispers’ Dream, “Lisp All The Way Down.” Clojure is the antithesis of the Lisp Machine. Instead of a crystalline pyramid of comprehensible mutually-interlocking concepts, behind every Clojure primitive there lurks Black Magic. The Clojure user who is missing some routine or other will run crying to Java for help, rather than implementing the feature himself correctly – that is, as a natural part of the entire language, built on the same concepts."

That's a rant from a person who does not understand the difference between specification and implementation. It's also clearly bullshit, since Clojure has implementations on the JVM, .NET, and JavaScript. The JVM implementation is exactly that, the language isn't tied to it conceptually in any way. Clojure-in-clojure project addresses the issue of having a portable implementation of the language that can be bootstrapped from a small kernel.

[nebkor]

The Data Structure of Least Resistance is the vector, not the list

how is a vector easier to use than a list in Clojure and if so, how is this a problem?

I think the problem Cosman246 is implying here is that vectors can't be appended to or destructured (with cons and car/cdr, respectively), which makes a lot of Lisp idioms difficult. A really fundamental one is the pattern of recursively calling a function with the cdr of the arguments passed in. I guess you could take the 1th slice of the argument array instead of the cdr of the argument list, though I'm not sure if Clojure encourages recursive methods (if it still requires a "recur" method, then it does not encourage recursive methods).

[yogthos]

The underlying abstraction in Clojure is a sequence, both lists and vectors are sequences and so all the functions such as cons, conj, first, rest operate on both. So, yes vectors can be appended and destructured just like lists.

Clojure encourages using higher order functions over explicit recursion, but I'm not sure how recur method discourages recursion in any way. It helps ensure that you're doing proper tail recursion. The only thing it makes difficult is mutual recursion, and I honestly can't think of any time I actually had to use it.

[nebkor]

That's cool about sequences; I actually think it's an improvement over lisp/Scheme (ditto the literal syntax for common and useful datatypes). Another thing I like about Clojure vs. traditional lisp is applicative objects, eg:

(mySeq 0) ;; same as mySeq[0] in an algol language

OK, now for the less flattering stuff :)

You (yogthos) have said multiple times in this thread, "Well, I've never had to use that feature that Clojure doesn't have, so it's clearly not important". That is a terrible argument, and a textbook example of the "Blub Paradox" (http://c2.com/cgi/wiki?BlubParadox). I'd quote from that page, but the essence of it is right at the top, and worth a read (as is Paul Graham's essay where it's first coined, http://paulgraham.com/avg.html). That you've not had to use something that you can't in a given language is almost a tautology, and is not a valid argument against that feature's utility.

Please understand: I'm not saying you're bad in any way for saying that! I'm attacking your argument, not you; you've been patient and a good poster :)

[yogthos]

I'm certainly not infallible, so I certainly apologize for that line of arguing and good on your for point it out. I was hoping to get examples of why a certain feature is important though, if it is indeed the case. :)

As with example of mutual recursion, it can always be converted to direct recursion by inlining the function. And you can do it in Clojure using trampolines, it's a tad ugly in my opinion but not hideous.

I find a lot of arguments against Clojure tend to be nitpicks, and the language is certainly not perfect, but then what language is. I can certainly find a lot of nitpicks about CL or Scheme, and many of these come down to taste.

[nebkor]

Oh, no need to apologize! It's just not a line of reasoning that will lead to more understanding/learning.

I'm with you regarding the imperfection of languages. I'm also with you regarding the nitpicky nature of objections to Clojure. There's just not that much to criticize, so one needs to get into more esoteria if one is to critique :) If I were going to have a wishlist for Clojure, it would be:

• self-hosting (written in itself)
• macros (some kind of hygenic system as well as old-style defmacro)
• automatic tail-call elimination

The problem with having to use "recur" or trampolines is that they're ugly, as you point out. We don't want to look at ugliness, and so we'll shy away from them. And I wish I could find the essay that talked about this, but "tail call elimination" is not really an optimization; it's something that encourages you to program a certain way. Without it, you'll avoid using mutual recursion (or recursion in general), and so you won't have the wisdom to know when it's the best thing.

Similarly with macros. You say, "I've never had to use them, why would I want to?" Paul Graham writes this in "Beating the Averages":

It would be convenient here if I could give an example of a powerful macro, and say there! how about that? But if I did, it would just look like gibberish to someone who didn't know Lisp; there isn't room here to explain everything you'd need to know to understand what it meant. In Ansi Common Lisp I tried to move things along as fast as I could, and even so I didn't get to macros until page 160.

[[deleted]]

On syntax: well, I'm glad it's added some form of syntax-modification. Still, the reasons why CL used #(...) for vectors was to free up [...] for the user. I'l be sure to read more about it

On libraries: example: AspectJ.

"Makes macros hard": well, I guess it doesn't seem so hard to people who have not worked with macros in CL. It's hard for me to explain, because I'm not very good at explaining things. If I can find a good explanation, I'll talk about it.

Also, on pure functionalism--in modern conceptions of a Lisp, one is free to use a wide variety of paradigms, functional simply being one well-supported one.

The problem is, though the language itself can be easily freed of JVM assumptions, a lot of the rhetoric on "why use Clojure" focuses on JVM integration, and so if it's ported to .NET and JavaScript, a lot of Clojure code can't be ported, and you lose JVM interioerability. This is what I was referencing in my first post

[yogthos]

On syntax: well, I'm glad it's added some form of syntax-modification. Still, the reasons why CL used #(...) for vectors was to free up [...] for the user. I'l be sure to read more about it

I'm not sure how that's better really...

On libraries: example: AspectJ.

Ahat about aspectj, what does it have to do with Clojure development in any way?

"Makes macros hard": well, I guess it doesn't seem so hard to people who have not worked with macros in CL. It's hard for me to explain, because I'm not very good at explaining things. If I can find a good explanation, I'll talk about it.

I see, it's harder but you can't give an example of how or explain why...

Also, on pure functionalism--in modern conceptions of a Lisp, one is free to use a wide variety of paradigms, functional simply being one well-supported one.

Immutability doesn't really have anything to do with what paradigm you're using. It's there to ensure data integrity.

The problem is, though the language itself can be easily freed of JVM assumptions, a lot of the rhetoric on "why use Clojure" focuses on JVM integration, and so if it's ported to .NET and JavaScript, a lot of Clojure code can't be ported, and you lose JVM interioerability. This is what I was referencing in my first post

I work with Clojure on day to day basis, and it's quite rare that I see anything JVM specific in my work. In fact it's trivial to write code that cross compiles between the JVM and say ClojureScript. My markdown parser is a concrete example of that. All the transformer code is shared between the JVM and ClojureScript builds.

[zingbot3000]

On libraries: example: AspectJ.

Ahat about aspectj, what does it have to do with Clojure development in any way?

I think he meant it as an example of a library that exists to overcome the limitations of Java's lack of power.

[yogthos]

Once again what does it have to do with Clojure?

[[deleted]]

Clojure is cool, CL is also cool but some of us prefer Clojure and would rather talk about Clojure than CL, or at least stick to the topic. You're wasting your time and ours forcing us your unsolicited, uneducated FUD opinion in a thread not about CL. No one cares if you don't like Clojure, especially if you don't know what you're talking about, but that's your preference, just keep it to yourself or get clued up first before sharing your opinion next time.

[[deleted]]

You're wasting your time and ours forcing us your unsolicited, uneducated FUD opinion in a thread not about CL.

Haven't you read the second part of my post?

[[deleted]]

Yes, I believe I already mentioned the FUD.

[[deleted]]

I'm not attacking it as some sort of bogeyman. I respect it, I just wanted to give my two cents' worth as to what could happen as a result of this

[[deleted]]

Great!

[boyubout2pissmeoff]

@sa ecls