Alright, fess up, who's unhappy with clojurescript?
James Keats
Alright, to be honest, I'm disappointed.
First of all, congrats and good job to all involved in putting it out.
On the plus side, it's a good way to use the Google Closure javascript
platform.
On the minus, imho, that's what's wrong with it.
Google Closure is too Java. It's not idiomatic JavaScript. I find it
disappointing that rather than porting from a functional language like
Clojure straight to another functional language like Javascript, the
google closure with its ugly Java-isms is right there obnoxiously in
the middle.
Then, there's the elephant in the room, and that elephant is Jquery. I
believe any targetting-javascript tool that misses out on jquery-first-
and-foremost is missing out on the realities of javascript in 2011.
Jquery is huge in its community and plugins, and it has tons of books
and tutorials. In much the same way that you can have lots of libs on
the JVM, there are lots of plugins for jquery. So much so that the
latest edition of Javascript: the Definitive Guide includes a chapter
on it; quoted:
"Because the jQuery library has become so widely used, web developers
should be fa-
miliar with it: even if you don’t use it in your own code, you are
likely to encounter it
in code written by others."
Then, the Google Closure compiler is a moot point. Everyone by now
already has a copy of jquery from the Google CDN and linking to it in
your code will not download it any further after your first visit to a
website that does so. In any case, it's already small and fast.
Then there's rhino/jvm. I would much rather an in-browser focus.
I'm tempted to "fork" clojurescript and redo it in javascript perhaps
so that seamless interop with jquery would be the main priority.
Discuss?
Stuart Halloway
Google Closure is too Java. It's not idiomatic JavaScript.
Then, there's the elephant in the room, and that elephant is Jquery.
Then, the Google Closure compiler is a moot point. Everyone by now
already has a copy of jquery from the Google CDN and linking to it in
your code will not download it any further after your first visit to a
website that does so. In any case, it's already small and fast.
Then there's rhino/jvm. I would much rather an in-browser focus.
I'm tempted to "fork" clojurescript and redo it in javascript perhaps
so that seamless interop with jquery would be the main priority.
Aaron Bedra
* I respect your opinions. I am glad that you have taken the time to
start exploring ClojureScript
Second:
* Dude, stop trolling. This is the second time you have started a thread
with a baiting subject line and no clear end goal. Your opinions are
yours, and I have no problems with that, however, this offers no
constructive feedback. If you would like to write your own Clojure on
JavaScript, that would be a great way to learn and get exactly what you
want out of it. I encourage you to look at the ClojureScript source
code for ideas while you are doing your implementation.
* If you want to start discussions like this, please do so elsewhere.
If you have something in particular you want to discuss about Clojure or
ClojureScript, then this is the place.
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com
On 07/24/2011 08:19 AM, James Keats wrote:
> Alright, to be honest, I'm disappointed.
>
> First of all, congrats and good job to all involved in putting it out.
> On the plus side, it's a good way to use the Google Closure javascript
> platform.
>
> On the minus, imho, that's what's wrong with it.
>
> Google Closure is too Java. It's not idiomatic JavaScript. I find it
> disappointing that rather than porting from a functional language like
> Clojure straight to another functional language like Javascript, the
> google closure with its ugly Java-isms is right there obnoxiously in
> the middle.
>
> Then, there's the elephant in the room, and that elephant is Jquery. I
> believe any targetting-javascript tool that misses out on jquery-first-
> and-foremost is missing out on the realities of javascript in 2011.
> Jquery is huge in its community and plugins, and it has tons of books
> and tutorials. In much the same way that you can have lots of libs on
> the JVM, there are lots of plugins for jquery. So much so that the
> latest edition of Javascript: the Definitive Guide includes a chapter
> on it; quoted:
>
> "Because the jQuery library has become so widely used, web developers
> should be fa-
> miliar with it: even if you don�t use it in your own code, you are
> likely to encounter it
> in code written by others."
>
> Then, the Google Closure compiler is a moot point. Everyone by now
> already has a copy of jquery from the Google CDN and linking to it in
> your code will not download it any further after your first visit to a
> website that does so. In any case, it's already small and fast.
>
> Then there's rhino/jvm. I would much rather an in-browser focus.
>
> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> so that seamless interop with jquery would be the main priority.
>
> Discuss?
>
>
--
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com
Mark Rathwell
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Baishampayan Ghose
Sorry for the digression, but what about YUI 3?
Regards,
BG
---
Sent from phone. Please excuse brevity.
Mark Rathwell
David Nolen
Frank Gerhardt
I think the Clojure community can do much, much better. In fact a clientside framework could be the first Clojure killer app ...
James Keats
> Wasn't it just a couple weeks ago that you were arguing that everything
> should be more like Java? Now you're arguing that Google Closure is bad
> because it has some similarities to Java development (mainly verbosity and
> documentation). I'm honestly not sure if you are just trying to be
> controversial, or to appear smart, but I'll bite (time for a break anyways).
>
> Closure is not idomatic javascript:
> ---
rather, if you're targetting the JVM then Java, if you're targetting
javascript then javascript.
I'm aware of the article you pointed out, but no, that article is
mostly about the implementation details within closure, which is a
lesser concern to me. I think a good book about idiomatic javascript
would probably be Douglass Crockford's Javascript: the Good Parts, and
just as good if not even better is JavaScript Patterns by Stoyan
Stefanov; emphasis on a functional programming small subset of
javascript, using closures and prototypes, et cetera. I had been aware
of the Google Closure library through its book, which I read when it
first came out; I invite you to read this book. It's too Java-esque;
java-inspired annotations, java-inspired OOP, too much complexity and
ceremony, and the author pointedly dismisses much of the javascript
community idioms: http://bolinfest.com/javascript/inheritance.php
I think it's a bit absurd, folks, to criticize Java's OOP as
incidental complexity, too much ceremony, and even suggest in the Joy
of Clojure that a Steve Yegge's Universal Design Pattern and prototype
pattern a la Javascript could be married to clojure's in the chapter
that discuss namespaces, multimethods, protocols and datatypes, and
then turn around and implicitly declare to the world with the release
of clojurescript "oh noes! if we're gonna do anything substantial then
this doesn't scale! we need a Java like solution!"
> On Sun, Jul 24, 2011 at 11:19 AM, James Keats <james.w.ke...@gmail.com>wrote:
>
>
Wilson MacGyver
On Jul 24, 2011, at 1:15 PM, Frank Gerhardt <f...@gerhardtinformatics.com> wrote:
...
James Keats
On Jul 24, 6:03 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> As a professional JavaScripter for the past 6 years who has built his own
> frameworks and written considerable amounts of Prototype, MooTools, and
> jQuery.
>
> I don't think jQuery is special or particularly interesting and most of the
> libraries around it are terrible IMO. It certainly doesn't help in building
> sophisticated clientside applications (if it did, why Backbone.js, why
> Cappuccino, why SproutCore?, etc).
>
> For simple stuff it's fine. But then so is Google Closure.
>
> I think the Clojure community can do much, much better. In fact a clientside
> framework could be the first Clojure killer app ...
>
> David
>
applications, by bringing proper functional programming to the
clientside, rather than bringing Java's OOP in the form of gClosure.
The Javascript notaries have advocated using a small functional subset
of javascript, rather than the full gamut of javscript's quirks, and I
was saddened while watching the Rich Hickey talk when he said that
clojurescript would abstract away the complex conventions and
discipline required when writing apps for gClosure by producing code
ready for its optimizing compiler, when it could've simply enforced
that small functional subset of javascript itself (sans gClosure)
that's now considered idiomatic best practice.
David Nolen
The Javascript notaries have advocated using a small functional subset
of javascript, rather than the full gamut of javscript's quirks, and I
was saddened while watching the Rich Hickey talk when he said that
clojurescript would abstract away the complex conventions and
discipline required when writing apps for gClosure by producing code
ready for its optimizing compiler, when it could've simply enforced
that small functional subset of javascript itself (sans gClosure)
that's now considered idiomatic best practice.
James Keats
On Jul 24, 7:05 pm, David Nolen <dnolen.li...@gmail.com> wrote:
functional programming, then; see last paragraph of my reply to Mark.
Michael Gardner
>> Restricting yourself to a functional subset of JavaScript can't fix
>> JavaScript. The functional subset stinks, Javascript notaries be damned.
>
> If so where does this leave clojure itself and its advocacy of
> functional programming, then; see last paragraph of my reply to Mark.
You can't draw any inference along those lines from David's observation. The functional parts of Javascript are far different from those of Clojure (and not in a good way).
James Keats
On Jul 24, 7:24 pm, Michael Gardner <gardne...@gmail.com> wrote:
> On Jul 24, 2011, at 1:11 PM, James Keats wrote:
>
> >> Restricting yourself to a functional subset of JavaScript can't fix
> >> JavaScript. The functional subset stinks, Javascript notaries be damned.
>
> > If so where does this leave clojure itself and its advocacy of
> > functional programming, then; see last paragraph of my reply to Mark.
>
> You can't draw any inference along those lines from David's observation.
> The functional parts of Javascript are far different from those of Clojure (and not in a good way).
functional than java ( first class functions, closures, anonymous
functions etc. A small subset of clojure would mirror and could expand
on a small subset of javascript); it's been called a "Lisp in C's
Clothing", and Brendan Eich famously and repeatedly said "As I’ve
often said, and as others at Netscape can confirm, I was recruited to
Netscape with the promise of “doing Scheme” in the browser" Back at
Netscape "doing a scheme in the browser" was botched a bit by a deal
with Sun and "the diktat from upper engineering management was that
the language must “look like Java”."[1], and whereas clojure/
clojurescript now had an opportunity to correct that, instead it's
piling on the Java-ism with gClosure.
[1] http://brendaneich.com/tag/history/
Michael Gardner
> On Jul 24, 7:24 pm, Michael Gardner <gardne...@gmail.com> wrote:
>> The functional parts of Javascript are far different from those of Clojure (and not in a good way).
>
> How so? javasript, while not as functional as clojure, is far more
> functional than java ( first class functions, closures, anonymous
> functions etc.
Javascript is simply painful to use functionally. The verbosity of anonymous functions, the lack of crucial HOFs like map/filter/reduce, the lack of functional data structures, the lack of macros (not strictly a "functional" feature, but especially useful with functional code)... You can fix these to varying degrees with libraries; but in any case the overall superiority of Clojure syntax and data structures must be obvious to anyone interested in ClojureScript, since those are the sole advantages it provides over Javascript.
> A small subset of clojure would mirror and could expand
> on a small subset of javascript); it's been called a "Lisp in C's
> Clothing", and Brendan Eich famously and repeatedly said "As I’ve
> often said, and as others at Netscape can confirm, I was recruited to
> Netscape with the promise of “doing Scheme” in the browser" Back at
> Netscape "doing a scheme in the browser" was botched a bit by a deal
> with Sun and "the diktat from upper engineering management was that
> the language must “look like Java”."[1], and whereas clojure/
> clojurescript now had an opportunity to correct that, instead it's
> piling on the Java-ism with gClosure.
Why should we care what kind of Javascript ClojureScript generates, as long as it's correct and performant? The whole point of the project is to allow us to write Clojure rather than Javascript!
Sean Corfield
> If so where does this leave clojure itself and its advocacy of
> functional programming, then; see last paragraph of my reply to Mark.
Given that JS is merely the "assembler" that ClojureScript targets -
in exactly the same way that Java bytecode is the "assembler" that
Clojure targets on the JVM (and presumably CLR bytecode for that VM) -
I don't see why you're concerned about the Closure library here.
Clojure developers are used to working with nice, clean functional
wrappers around Java libraries so why should ClojureScript be any
different? Closure is an implementation detail.
(and, yes, you do seem to be trolling... again)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Mark Rathwell
>incidental complexity, too much ceremony, and even suggest in the Joy
>of Clojure that a Steve Yegge's Universal Design Pattern and prototype
>pattern a la Javascript could be married to clojure's in the chapter
>that discuss namespaces, multimethods, protocols and datatypes, and
>then turn around and implicitly declare to the world with the release
>this doesn't scale! we need a Java like solution!"
Base
as long as it's correct and performant? The whole point of the project
is to allow us to write Clojure rather than Javascript!"
program in Java to write JavaScript, and get the 'benefits' of not
having to actually write JS to develop web clients, ClojureScript
allows you to program in Clojure to write JavaScript that CloSure
likes.
If you like programming in Clojure than you *should* appreciate this
point. If you don't, than it seems to me that you are just picking a
fight to pick a fight.
On Jul 24, 3:09 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote:
> >I think it's a bit absurd, folks, to criticize Java's OOP as
> >incidental complexity, too much ceremony, and even suggest in the Joy
> >of Clojure that a Steve Yegge's Universal Design Pattern and prototype
> >pattern a la Javascript could be married to clojure's in the chapter
> >that discuss namespaces, multimethods, protocols and datatypes, and
> >then turn around and implicitly declare to the world with the release
> >of clojurescript "oh noes! if we're gonna do anything substantial then
> >this doesn't scale! we need a Java like solution!"
>
> From this quote (and many others) of yours: " I always advocate that people
> adopt a managerial/business-case approach.", it seemed as though you value
> maturity and a proven track record, both in programmers and in technology
> stacks. Google's library is the result of many years in battle with large
> scale javascript applications, and it is a proven solution. To me it seems
> a bit absurd to champion Java because it is a proven, robust option, then
> belittle Closure because it isn't the flavor of javascript you like.
>
> In any case, from the coding point of view, you will be writing code in
> Clojure (with a "j"), only using the functionality of google's library, in
> the much the same way as you use the functionality of the JDK, so I'm not
> sure exactly what it is you are wanting with ClojureScript and jQuery.
>
> - Mark
>
Rich Hickey
On Jul 24, 11:19 am, James Keats <james.w.ke...@gmail.com> wrote:
> Alright, to be honest, I'm disappointed.
>
Seriously, this is like being disappointed an action movie was an
action movie instead of a comedy. Your expectations are a complete
mismatch for the intentions of ClojureScript.
> First of all, congrats and good job to all involved in putting it out.
> On the plus side, it's a good way to use the Google Closure javascript
> platform.
>
> On the minus, imho, that's what's wrong with it.
>
> Google Closure is too Java.
pseudo class model, but it certainly is part of the design of
JavaScript. And it has some particular advantages over the other
strategies, as outlined here:
http://bolinfest.com/javascript/inheritance.php
> It's not idiomatic JavaScript.
different conventions used by different libraries.
> I find it
> disappointing that rather than porting from a functional language like
> Clojure straight to another functional language like Javascript, the
> google closure with its ugly Java-isms is right there obnoxiously in
> the middle.
>
Clojure to me. Google Closure is under, and it is no more annoying
there than Java is under Clojure - an implementation detail, and a
rich source of production-quality code.
> Then, there's the elephant in the room, and that elephant is Jquery. I
> believe any targetting-javascript tool that misses out on jquery-first-
> and-foremost is missing out on the realities of javascript in 2011.
orient itself around the realities of currently popular JavaScript
libraries? I think not. If you want jQuery as the center of your
universe, JavasScript is your language - good luck with it. I see
jQuery as a tool to be leveraged when appropriate (i.e. rarely in
large programs), not an architectural centerpiece.
> Jquery is huge in its community and plugins, and it has tons of books
> and tutorials.
and I'm fine with that.
> Then, the Google Closure compiler is a moot point.
are not the target audience for ClojureScript. In any case, for those
interested there is an argument for Google's approach in the
rationale, as well as this page on the wiki:
https://github.com/clojure/clojurescript/wiki/Google-Closure
> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> so that seamless interop with jquery would be the main priority.
>
rationale like this one:
https://github.com/clojure/clojurescript/wiki/Rationale
making your intentions and the superiority of your approach clear.
Then prepare yourself for messages from people who don't bother to
read or understand it.
Messages like yours make creating things and releasing them for free a
really exhausting endeavor.
Good luck with your fork - please start a separate mailing list for
discussions about it.
Rich
p.s. note to others - if you have read the docs and have honest
questions about the approach, I and others would be happy to explain.
But we could do without messages about disappointment, threats of
forks etc. ClojureScript is an action movie, and we're interested in
helping people kick butt.
Charlie Griefer
>ClojureScript is an action movie, and we're interested in
> helping people kick butt.
Could you please tweet that, if only so I can retweet it? :)
--
Charlie Griefer
http://charlie.griefer.com/
I have failed as much as I have succeeded. But I love my life. I love
my wife. And I wish you my kind of success.
James Keats
Well I'm very very sorry if the intent of my post was misunderstood or
I articulated it poorly, but I would like to emphasize, Rich, that I'm
a big fan of yours and in no way intended to exhaust you, I was merely
and honestly voicing my concerns, just like in a previous thread I
have quoted you time and again and voiced my agreement with and
admiration of your work and positions with regard to clojure itself. I
have watched all your talks on vimeo several times, and read most of
what I could find online of interviews with you, and with regard to
clojurescript I did read the rationale, I watched your talk twice and
carefully, and I had the google closure book for almost a year now,
which includes a reprint of the article you linked to and that I had
previously linked to this this thread.
"forking" was in no way a threat, but a suggested possibility to see
what everyone here thought, whether there were others like me, who
aren't fond of google closure, who perceive a demand for it, as a non-
gclosure alternative that'd be part of the clojure toolset.
Unfortunately my intent seems to have been misunderstood or I'd
miscommunicated it, whichever, I find regrettable.
James Keats
On Jul 24, 10:23 pm, Base <basselh...@gmail.com> wrote:
> "Why should we care what kind of Javascript ClojureScript generates,
> as long as it's correct and performant? The whole point of the project
> is to allow us to write Clojure rather than Javascript!"
>
> James, you do get this point, right? Just like GWT allows you to
> program in Java to write JavaScript, and get the 'benefits' of not
> having to actually write JS to develop web clients, ClojureScript
> allows you to program in Clojure to write JavaScript that CloSure
> likes.
>
> If you like programming in Clojure than you *should* appreciate this
> point. If you don't, than it seems to me that you are just picking a
> fight to pick a fight.
concern. I believe you still need to learn and know and understand and
be mindful of gclojure to use clojurescript. Furthermore, gClosure is
low level in what it offers, you'd have to roll your own for much of
what you could reuse elsewhere, and google acknowledges this in its
docs:
"What is the relation between the Closure Library and other JavaScript
libraries?
Many JavaScript libraries emphasize the ability to easily add
JavaScript effects and features with minimal development time. Google
engineers use these third-party tools for precisely the reason that
the libraries are powerful for rapid development.
The Closure Library is designed for use in very large JavaScript
applications. It has a rich API and provides tools for working with
the browser at a lower level. It's not well suited for all tasks, but
we think it provides a useful option for web developers."
Outside of google the closure library hasn't had much uptake and it's
not part of the burgeoning javascript scene.
I just feel it's ironic that on the JVM the idea is that the best
practices of java that are conducive to "very large" application
development are considered too painful for everyday development and
therefore the reason d'etre of clojure, but when it comes to
javascript then it's the "very large" apps that we'll gear up for and
put up with the consequent everyday pain. It's also ironic that with
clojure on the JVM we'd think that things like transaction software
memory are worthwhile compromises performance-wise, but towards
javascript then a slavish obiedience to the google closure compiler -
which predates JITed javascript VMs, and predates the closure library
which was modeled with it in mind - is prioritized over the
development experience or a burgeoning platform of libs.
Anyhow, not wishing to be further misunderstood, I regret any
miscommunication and offer everyone my kindest regards.
Ulrik Sandberg
offended you." And you, say you're sorry if you over-reacted. "I'm
sorry if I over-reacted." Very good. Now, shake hands. Good. I love
you both. You should love each other too. You'll need each other
later.
--
Father of three boys
Mark Derricutt
Colin Yates
Ken Wesson
+1 to all of that.
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
cassiel
mind about ClojureScript...
I'm used to Clojure as a language that's solidly spot-welded to the
JVM and the Java libraries. Just as "[1 2 3]" is legal portable
Clojure code, so is "(.start (Thread. #(...)))" despite it being a
blatant set of calls into Java, and so are the various Java-leaning
reflection features.
I think ClojureScript is a great piece of work, but I'm not sure what
this means for language standardisation or portability. Is it still
"real" Clojure? Clearly I can write programs, or distribute libraries,
which run on one but not the other. Similarly, I'm sure there are
common chunks of functionality (although I'm not enough of a JS
programmer to suggest any) which are pretty crucial to some programs
written in either Clojure but implemented differently. ClojureScript
is still missing key parts of Clojure (e.g. agents) making even non-
Java-ish programs non(-yet)-portable.
I guess I'm interested in the road map, if any: are things heading
towards some kind of common "ClojureCore" specification with
ClojureJava and ClojureScript both supersets of this? What are the
ramifications for library distribution? Or are "Clojure Classic" and
ClojureScript different systems for different environments? In which
case, what mileage is there in identifying and specifying the
overlapping and identical areas and transparently developing for both?
Sorry if the questions are stupid... I'm looking forward to having a
good solid session with ClojureScript in a browser near me soon.
James Keats
Right, Rich, please allow me to reply to the points you mentioned; I
declined from doing so last night as I sensed some unintentionally
irritated feelings, which I hope have eased a bit by now. I believe
all my posts in this discussion are purely technical concerns and I
believe them to be valid. I am most definitely not a troll as some
have suggested; I would've had to do a ridiculous amount of homework
over a long, long period of time and been a psychic to predict this
event (I've only found out clojurescript in the past couple of days),
and I do not believe in any way I'm making an attempt at humor in the
technical arguments I'm making.
>
> > Alright, to be honest, I'm disappointed.
>
> I'll make sure you get a refund then.
>
> Seriously, this is like being disappointed an action movie was an
> action movie instead of a comedy. Your expectations are a complete
> mismatch for the intentions of ClojureScript.
>
> > First of all, congrats and good job to all involved in putting it out.
> > On the plus side, it's a good way to use the Google Closure javascript
> > platform.
>
> > On the minus, imho, that's what's wrong with it.
>
> > Google Closure is too Java.
>
> Actually, it's too JavaScript. Some JS proponents want to disavow its
> pseudo class model, but it certainly is part of the design of
> JavaScript. And it has some particular advantages over the other
> strategies, as outlined here:
>
> http://bolinfest.com/javascript/inheritance.php
obfuscation, semantically javascript is prototypical inheritance. It's
class free. In addition to the pseudo class inheritance advocated by
google closure and the prototypical inherent in javascript, others
like Doug Crockford advocated functional inheritance.
Now I have watched and read enough of your output and for example
Stuart Holloways talk about protocols to know that you've railed in
your adovacy of clojure against classes and inheritance, and find it
ironic that now you posit a link by an advocate of it citing it as
advantageous. In any case, as I've mentioned, I have been aware of
this article for nearly a year now, it failed to convince me back then
and it still does; most of the arguments in it concern the closure
compiler, an obeisance to which by the regular developer who doesn't
have the needs and resources of google, I feel in this day and age of
ample memory and bandwidth and fast javascript engines, is premature
optimization gone berserk (seriously, folks, people are streaming HD
video, 1.5 gbps fiber optic broadband is being rolled out in London
and soon other cities worldwide and 4G mobiles are upon and we're
fretting over mere tens of KB that gets cached after first time and
basing our development around minimizing it?!), and the remainder of
the arguments are in support of classes and inheritance.
>
> > It's not idiomatic JavaScript.
>
> There's no such thing as idiomatic JavaScript. There are a lot of
> different conventions used by different libraries.
>
and a half now of experience with the language has come to regard some
aspect of it as good and others as problematic; things like functional
programming and object literals (akin to clojure's maps/structs/
records) vs classical inheritance, which are positions you yourself
have taken and advocated.
> > I find it
> > disappointing that rather than porting from a functional language like
> > Clojure straight to another functional language like Javascript, the
> > google closure with its ugly Java-isms is right there obnoxiously in
> > the middle.
>
> In the middle of what? I look at ClojureScript code and it looks like
> Clojure to me. Google Closure is under, and it is no more annoying
> there than Java is under Clojure - an implementation detail, and a
> rich source of production-quality code.
events, cookies, ui, effects, animations etc - jquery does it far
better and is much more pleasant an api. What jquery itself doesn't do
the huge ecosphere of libs around it do, for example:
http://metajack.im/2009/03/13/jquery-and-strophe-made-for-each-other/
http://strophe.im/
>
> > Then, there's the elephant in the room, and that elephant is Jquery. I
> > believe any targetting-javascript tool that misses out on jquery-first-
> > and-foremost is missing out on the realities of javascript in 2011.
>
> Should it be the purpose of a new language like ClojureScript to
> orient itself around the realities of currently popular JavaScript
> libraries? I think not.
> If you want jQuery as the center of your
> universe, JavasScript is your language - good luck with it. I see
> jQuery as a tool to be leveraged when appropriate (i.e. rarely in
> large programs), not an architectural centerpiece.
unpopular one? This is exactly what clojurescript does! it orients
itself around the realities of google closure and its compiler. It's
not only currently unpopular, it's never been popular, and in all
likelihood never will be.
http://www.google.com/trends?q=%22google+closure%22 (that lone
vertical line you see was its announcement, let's not do a comparative
google trends for "google closure, jquery", or even google's gwt)
>
> > Jquery is huge in its community and plugins, and it has tons of books
> > and tutorials.
>
> So what? Those people are satisfied by, and not leaving, JavaScript,
> and I'm fine with that.
>
http://jquerymobile.com/
> > Then, the Google Closure compiler is a moot point.
>
> If you seriously cannot see the benefits of Google's compiler then you
> are not the target audience for ClojureScript. In any case, for those
> interested there is an argument for Google's approach in the
> rationale, as well as this page on the wiki:
>
> https://github.com/clojure/clojurescript/wiki/Google-Closure
>
> > I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> > so that seamless interop with jquery would be the main priority.
>
> Is that a threat, or a promise? I suggest you start by writing up a
> rationale like this one:
>
> https://github.com/clojure/clojurescript/wiki/Rationale
>
> making your intentions and the superiority of your approach clear.
> Then prepare yourself for messages from people who don't bother to
> read or understand it.
of a better term, as github's "fork me" slogan goes; I won't now so as
not to seem like I'm here to steal your thunder. Clojure on Java, from
what I've read and watched of yours, was not your first attempt at a
lisp targeting java. It took a few attempts to get it right. We're all
human, you're not an emacs whiz and nor am i, though I do absolutely
believe you're a man of brilliance and I fully admire you. I'm merely
voicing my humble and sincere opinion based purely on technical points
that this first attempt at targeting javascript needs reconsidering.
Best regards; love you, man, and sorry again for any misunderstanding
or unintended miscommunication.
>
> Messages like yours make creating things and releasing them for free a
> really exhausting endeavor.
>
> Good luck with your fork - please start a separate mailing list for
> discussions about it.
>
> Rich
>
> p.s. note to others - if you have read the docs and have honest
> questions about the approach, I and others would be happy to explain.
> But we could do without messages about disappointment, threats of
> forks etc. ClojureScript is an action movie, and we're interested in
Alen Ribic
> > Clojure to me. Google Closure is under, and it is no more annoying
> > there than Java is under Clojure - an implementation detail, and a
> > rich source of production-quality code.
> I respectfully dispute that; for what they both do - dom, css, ajax,
> events, cookies, ui, effects, animations etc - jquery does it far
> better and is much more pleasant an api. What jquery itself doesn't do
> the huge ecosphere of libs around it do, for example:http://metajack.im/2009/03/13/jquery-and-strophe-made-for-each-other/http://strophe.im/
the project? If you want to prove to yourself and then to others that
jQuery is better suited than Google Closure Library, go ahead and
write your ClojureScript code [1] that utilizes the jQuery library.
Once you are happy with your findings, I suggest you fork the
"rationale" and write the reasons that justify your beliefs and I'm
sure we all will be eager to listen.
[1] https://gist.github.com/1098417
-Alen
--
Science is what you know, philosophy is what you don't know.
-- Bertrand Russell
>
>
> > > Then, there's the elephant in the room, and that elephant is Jquery. I
> > > believe any targetting-javascript tool that misses out on jquery-first-
> > > and-foremost is missing out on the realities of javascript in 2011.
>
> > Should it be the purpose of a new language like ClojureScript to
> > orient itself around the realities of currently popular JavaScript
> > libraries? I think not.
> > If you want jQuery as the center of your
> > universe, JavasScript is your language - good luck with it. I see
> > jQuery as a tool to be leveraged when appropriate (i.e. rarely in
> > large programs), not an architectural centerpiece.
>
> As opposed to orienting itself around the realities of a currently
> unpopular one? This is exactly what clojurescript does! it orients
> itself around the realities of google closure and its compiler. It's
> not only currently unpopular, it's never been popular, and in all
> likelihood never will be.
>
Nick Zbinden
>
> I do so hope however that someone manages to pull that out for a "lets run this NOW on Java 7" as that would be a great improvement over rhino.
on Rhino, right? As long as Rhino has the correct semantics its fine
as a repl. We allready have a programming language that runs fast on
the JVM, its called clojure.
Mark Rathwell
Lars Rune Nøstdal
Ken Wesson
> Colin,
> I don't think anyone responding was doing so with the mindset of "my way or
> the highway" and "we must defend the great leader's achievements". Speaking
> for myself, I responded to an argument that did not make sense, that
> argument being basically: "Crockford says javascript can be written a
> certain way, jQuery generally follows this pattern and it is popular, Google
> Closure does not follow this pattern in some ways and is not as popular,
> therefore it should not be used for ClojureScript".
>
> Nobody is shooting down "I love it" type posts because they do come off as
> intentionally inflammatory. The titles of these posts seem aimed to incite
> controversy and ruffle feathers (as does the content), rather than seriously
> inquire about the rationale. And the arguments are generally recaps of
> articles that agree with the author, rather than actual pain points hit when
> trying to create something with Clojure or ClojureScript. The responses
> throwing "troll" around are the attempt of the community to point out that
> this list's main purpose is to help people, not for inflammatory content
> that belongs in blog posts.
Be that as it may, it has been my experience that throwing the term
"troll" around itself is inflammatory and generates more heat than
light. It's easily abused to dismiss without consideration (and to try
to get others to do likewise) an argument you disagree with, for
example, as well as frequently misapplied by accident. (It should be
properly reserved for those who quite intentionally are posting solely
to stir up noise -- not just anyone whose posts have that effect even
unintentionally, let alone where the main stirring up of noise is
coming from the use of the word "troll" itself or from other
name-calling directed AT the alleged troll.)
The best thing to do if you suspect some post may be a troll is to
*ignore it*. Flaming it and/or calling its author names will, if
you're wrong, alienate what might be a useful contributor to the
group, and if you're right, feed the troll. I doubt you wish to do
either.
> As for responding with "OK, this guy clearly doesn't get it - how can we
> improve our communication", this goes back to the intent of the author. I
> don't think the intent was to "get" anything, I think the intent was to
> incite.
The evidence is, thus far, equivocal on that score.
> The best response to this is to ignore it, and that is what I
> should have done, but it is easier to say than to do.
Ahh. That's one that is beginning to get it more, anyway.
Steve
>
> Best regards; love you, man, and sorry again for any misunderstanding
> or unintended miscommunication.
>
paragraph of an opinion piece there's a reasonable chance what you're
writing belongs on your blog rather than here.
- Steve
Colin Yates
Brenton
The reason you are experiencing resistance is because you are
proposing changes to things that will never change. Rich came up with
the Rationale before designing ClojureScript and long before writing
any code. All of the design work was informed by this. You are arguing
that there should be a different rationale which would mean starting
over from scratch.
Imagine that I invite you come work on a house that I am building
which has already been framed. Furthermore, imagine that I welcome
your input as to how the construction should progress. If your input
is, "I think we should build the house on top of the mountain over
there" or "There should be two bedrooms downstairs instead of one" you
are going to get shut down. Those decisions were made a long time ago
and it's too late to change now.
If you look at "The Library Problem" section of the Rationale
document, you will see the specific problem that ClojureScript
addresses and why the Closure compiler was chosen as the solution to
that problem. Your argument seems to be, "that isn't a problem". If
you don't think that is a problem then you are looking for something
other than ClojureScript and are welcome to pursue it.
Brenton
>
>
> > > Then, there's the elephant in the room, and that elephant is Jquery. I
> > > believe any targetting-javascript tool that misses out on jquery-first-
> > > and-foremost is missing out on the realities of javascript in 2011.
>
> > Should it be the purpose of a new language like ClojureScript to
> > orient itself around the realities of currently popular JavaScript
> > libraries? I think not.
> > If you want jQuery as the center of your
> > universe, JavasScript is your language - good luck with it. I see
> > jQuery as a tool to be leveraged when appropriate (i.e. rarely in
> > large programs), not an architectural centerpiece.
>
> As opposed to orienting itself around the realities of a currently
> unpopular one? This is exactly what clojurescript does! it orients
> itself around the realities of google closure and its compiler. It's
> not only currently unpopular, it's never been popular, and in all
> likelihood never will be.
>
Chouser
>
> Google Closure is too Java. It's not idiomatic JavaScript. I find it
> disappointing that rather than porting from a functional language like
> Clojure straight to another functional language like Javascript, the
> google closure with its ugly Java-isms is right there obnoxiously in
> the middle.
It is interesting to me that you say this, because it's an argument
I've used against other JavaScript libraries. In particular I think
Zimbra is weak in this way. For a specific example, to register an
event handler using the Zimbra event system, you can't just pass in a
function, you have to pass in an instance of an AjxListener. This
definitely strikes me as a useless Java-ism.
The G. Closure library doesn't have that particular problem -- it's
clearly aware that functions are first-class objects in JavaScript and
takes advantage of that fact. Is there some other specific way in
which the G. Closure library is too Java-like? How does that specific
way actual harm the development process or the final product?
> Then, there's the elephant in the room, and that elephant is Jquery.
I like jQuery. It's a huge win compared to vanilla JavaScript for the
browser. Now, I personally plan to write my ClojureScript code to
target the G. Closure library and then run it through the
advanced-mode G. Closure compiler, but there's no reason *you* have
to. You argue elsewhere that the G. Closure compiler is unnecessary
(citing streaming HD video in comparison to minified JavaScript) -- if
you don't use the compiler (or use it only in simple mode) you should
have no problem using jQuery. Your resulting .js will be quite a bit
larger because you'll have a couple of the G. Closure library files
that ClojureScript itself uses, but nothing compared to streaming HD
video.
So, you could use ClojureScript and jQuery to write a snappy little
demo and prove to everyone the value of that approach. I'm sure I'm
not the only one that would be interested in seeing such a demo.
--Chouser
Timothy Baldridge
> demo and prove to everyone the value of that approach. I'm sure I'm
> not the only one that would be interested in seeing such a demo.
>
I think Rich's point in his talk is good to re-iterate here. Is jQuery
cool? Yes! I would hate to program a webapp in JS without it...but
that's the key, "in JS". Why do I need jQuery 90% of the time, because
simplifies things like finding dom elements, and adding events, etc.
For JS coding, that's a awesome tool to have. But in ClojureScript we
have map, filter, macros, etc. Why would I need jQuery? I think it's
important to distinguish between libraries that are truly needed to do
web programming, and libraries that are needed in JS to do web
programming.
Timothy
nchurch
post a few weeks ago without realizing these sorts of posts belonged
on blogs (it was, oddly enough, another James Keats thread, on the
subject of Steve Yegge. I figured if \Yegge writes long blogs....).
I didn't intend to ruffle any feathers there, but my opinion that some
things were not being given enough priority was taken as disrespecting
people's efforts so far. But there seems to be some more attention to
documentation now and the newbie experience, so I'm happy (and trying
to help) = )
Ken was helpful to me then when he pointed out that my post was simply
too long. I suspect this was much more useful to the forum than
someone partly reading the post and responding out of context.
Similarly, writing (hopefully gentle) admonishments about etiquette
might help steer things in the right direction. If someone simply
responded with a few lines to this particular thread: "This is not the
kind of discussion this forum is for; it is also too late in the
process to be a constructive criticism", there might have been more
light and less heat.
Furthermore, if people want to offer etiquette pointers on the tone
and framing of a particular post, why not simply use the "reply to
author" link? There's a quote from the New Testament that I can't
quite remember....wait.....thank you Google: "If thy brother shall
trespass against thee, go and tell him his fault between thee and him
alone."
(I note, however, that this was presumably written before Facebook,
which makes privacy sound almost as quaint as King James and
Shakespeare.)
As for the subsequent part about "And if he neglect to hear the
cljurch, let him be as an troll to you" ((this is from the New
Internet Version)), I guess that would be equivalent to simply
ignoring him.
(If it said: "then ANN thou out upon him and the list that he be an
troll"----we would have a horse of a different color.)
On Jul 25, 10:21 am, Colin Yates <colin.ya...@gmail.com> wrote:
> +1 - I think an etiquette document needs to be written.
>
Jack Moffitt
> obfuscation, semantically javascript is prototypical inheritance. It's
> class free. In addition to the pseudo class inheritance advocated by
> google closure and the prototypical inherent in javascript, others
> like Doug Crockford advocated functional inheritance.
Almost every big JS library I know of adds in traditional inheritance,
so I don't think the community has decided what the best design
pattern is. There are many vocal people in the community who advocate
for prototypal inheritance, but I think this is a far cry from
consensus.
But the real issue is that this has very little to do with
ClojureScript. Whether the underlying library uses one or the other is
of little concern to the higher level. I don't think there is anything
in ClojureScript preventing you from interop with *any* JS lib, unless
of course you also want to use Closure compiler, in which case there
are some rules to follow.
> I respectfully dispute that; for what they both do - dom, css, ajax,
> events, cookies, ui, effects, animations etc - jquery does it far
> better and is much more pleasant an api. What jquery itself doesn't do
> the huge ecosphere of libs around it do, for example:
> http://metajack.im/2009/03/13/jquery-and-strophe-made-for-each-other/
> http://strophe.im/
I wrote that post and the Strophe.js library. I can tell you there is
nothing at all in Strophe that is jQuery dependent. It turns out that
jQuery's selector engine is quite useful at picking apart XML (and
strangely the other libraries selector engines aren't), which makes
using Strophe.js a lot easier. Plenty of people use Strophe.js
alongside other JS libs without any problems.
Many libraries are like this. Underscore.js is another example, but
there are tons of others.
It's certainly true that jQuery has a lot of plugins that already
exist. I can't say yet whether any of those would be useful in
ClojureScript. There's nothing preventing you using jQuery and
ClojureScript together (aside from a few kB overhead which they claim
to be working on minimizing). I don't see what benefit ClojureScript
would get from being built on jQuery, and it would be giving up a lot
(the Closure compiler!) for any such benefits.
Strophe is actually a great example because it's nearly impossible to
write any javascript library that satisfies some consensus of
javascript design. What dependency management tool should it use? What
type of object structure? No matter what I choose, there are large
swaths of major libraries that will not have made the same choices.
ClojureScript doesn't seemed particularly tied to anything but the
Closure compiler and it's dependency requirements. The benefits are
huge, and don't exist anywhere else to my knowledge. If jQuery or YUI
offered such a system, I think there would be more to argue about, but
even though I'm not a fan of Closure or YUI either (I tend to reach
for jQuery), I am perfectly happy with ClojureScript's choices and
have started down the road to embracing Closure library as well.
jack.
Ken Wesson
> +1 to writing an etiquette document. I have to confess I wrote a long
> post a few weeks ago without realizing these sorts of posts belonged
> on blogs
Not everyone *has* a blog, you know.
> Ken was helpful to me then when he pointed out that my post was simply
> too long.
More in a "condense your thoughts, or post several posts on subtopics"
sense than a "post somewhere else" sense, though.
> Furthermore, if people want to offer etiquette pointers on the tone
> and framing of a particular post, why not simply use the "reply to
> author" link? There's a quote from the New Testament that I can't
> quite remember....wait.....thank you Google: "If thy brother shall
> trespass against thee, go and tell him his fault between thee and him
> alone."
Unfortunately, some people on the internet seem to think that a) the
way to punish misdemeanors is public humiliation of some sort, b) they
are the police and judge and jury who will decide who's guilty and
apply these punishments, and c) what things are *misdemeanors* and
what things *they, personally, dislike* are precisely equal as sets.
Of course, all three things are wrong. :)
Those people cause as much trouble as trolls -- perhaps more, since
they're among the most incorrigible troll *feeders*.
[snippy]
nchurch, I arrest you, try you, and find you guilty of the heinous
charge of top-posting, thou knave, thou scum, thou waster of
bandwidth! ;)
pmbauer
nchurch
> charge of top-posting, thou knave, thou scum, thou waster of
> bandwidth!
sheep....
Ken Wesson
For penance you must make 3 more useful posts here today, and solve 3
Project Euler problems by midnight. ;)
daly
> +1 to writing an etiquette document.
In place of an etiquette document I suggest the book
called "Producing Open Source Software".
In this generally useful book there is some advice,
mostly directed at project leads but this section is relevant:
http://producingoss.com/en/producingoss.html#communications
I don't think the original poster intended to troll but the
post certainly fell under the rubric of "kibitzing" (def:
"A Kibitzer is a non-participant who hangs around offering
(often unwanted) advice or commentary"). The advice was
"unwanted" as the issue was already addressed in the video.
Based on the book, I think Rich is doing an
excellent job, especially in the area of communication.
Tim Daly
James Keats
Perhaps I should've just looked for a blog about knitting or cupcakes
and posted what I did here about clojure/clojurescript in it. That way
you fine folks won't get to read it, eventhough no one here is obliged
in any way to read my posts or any in this thread. Yeah, definitely,
that way I might've made sure that I didn't "incite" any "controversy"
or "ruffle" any "feathers"; god forbid that should ever be done here.
I ask, what is it that I did other than "seriously inquire about the
rationale"?! I don't see me making any jokes and I don't see me doing
anything other than ""seriously inquire about the rationale". I'm
sorry, but if you fine folks choose to blind and deafen yourself to my
"seriuos inquiry about the rationale" and call me a "troll" for it,
then there's a big wide merciless world out there that'll find it
absolutely ridiculous for Rich Hickey to rail against classes and
inheritance on and on and then favor a library and post a link titled
"inheritance" that argues for hoisting a pseudoclassical version of it
upon a language that tries to be functional as proof that it is
advantageous. Perhaps clojure itself should have classes and
inheritance and Rich should instead of apologizing for having once
taught it to people apologize for teaching them clojure.
Fine, I am done with this (-> back to scala); I have better things to
do than being called a "troll". "ignore" me all you want, if that's
how you want it then it the world out there will "ignore" you.
(ps. what's quotes below mischaracterizes what my psots)
Mark Rathwell
Christian Marks
On Jul 25, 6:11 pm, James Keats <james.w.ke...@gmail.com> wrote:
> I ask, what is it that I did other than "seriously inquire about the
> rationale"?!
whose unhappy with clojurescript?"
instead of the more serious "Comments on the clojurescript rationale."
Having done that, you could have addressed the rationale.
> then there's a big wide merciless world out there that'll find it
> absolutely ridiculous for Rich Hickey to rail against classes and
> inheritance on and on and then favor a library and post a link titled
> "inheritance" that argues for hoisting a pseudoclassical version of it
> upon a language that tries to be functional as proof that it is
> advantageous. Perhaps clojure itself should have classes and
> inheritance and Rich should instead of apologizing for having once
> taught it to people apologize for teaching them clojure.
taking
a "managerial attitude." So much for the managerial attitude. What
happened to "love you, man"? One gathers that managers offer
conditional
apologies and then quickly and resentfully withdraw them.
blackdog
James Keats
On Jul 26, 1:53 am, Christian Marks <9fv...@gmail.com> wrote:
> On Jul 25, 6:11 pm, James Keats <james.w.ke...@gmail.com> wrote:> I ask, what is it that I did other than "seriously inquire about the
> > rationale"?!
>
> You started a thread with the non-serious title, "Alright, fess up,
> whose unhappy with clojurescript?"
> instead of the more serious "Comments on the clojurescript rationale."
> Having done that, you could have addressed the rationale.
one here unhappy with it. I suspected some might've shared my
unhappiness but weren't confessing it, perhaps, evidently, for fear of
"inciting controversy" or "ruffling feathers". And the content of my
OP was clear and to the point.
>
> > then there's a big wide merciless world out there that'll find it
> > absolutely ridiculous for Rich Hickey to rail against classes and
> > inheritance on and on and then favor a library and post a link titled
> > "inheritance" that argues for hoisting a pseudoclassical version of it
> > upon a language that tries to be functional as proof that it is
> > advantageous. Perhaps clojure itself should have classes and
> > inheritance and Rich should instead of apologizing for having once
> > taught it to people apologize for teaching them clojure.
>
> Oh dear, this is jumbled prose for someone who "always advocates"
> taking
> a "managerial attitude." So much for the managerial attitude. What
> happened to "love you, man"? One gathers that managers offer
> conditional
> apologies and then quickly and resentfully withdraw them.
these inane replies. I was reacting to Rich' apparently and needlessly
hurt feelings, and he's not someone I'm managing. That "love you, man"
was specifically to address his feelings, and had nothing to do with
my managerial ways - if someone I'm managing had reacted to my
technical feedback with a temper tantrum I would've fired him, which
is effectively what I'll be doing by washing my hands of clojure.
You folks need to sort this out. Rich needs to put a price on clojure,
a monthly or yearly price - none of this appeal/gift nonsense - so he
doesn't revealingly reply to technical feedback with a revealingly
sarcastic "I'll make sure you get a refund". Perhaps this might work
as a reply to idle leechers, but for people who value their own time
and have an ounce of self-respect it is highly offensive. Just by
merely paying attention to Rich and clojure, serious folks are
incurring a cost already. If I pay attention to someone preaching to
me on and on and then he does something that contradicts his preaching
then I will feel that my time had been wasted, even robbed.
Just because clojure is open source doesn't mean he can't get paid for
it, and just because he gets paid for it doesn't mean he has to answer
to anybody. I can priate jetbrain's intellij if i so wish, and were I
to pay for a copy and then demand that jetbrains put a flight
simulator in it or institute a 120hrs workweek they still wouldn't
need to answer to that. I believe clojurescript is a mistake that Rich
should've put more of his "hammock time" into, and he should
unashamedly put a price on his hammock time.
semperos
Laurent PETIT
--
László Török
I wish I had a plug I could pull to stop this thread right n
--
James Keats
On Jul 26, 2:01 pm, semperos <daniel.l.grego...@gmail.com> wrote:
> Based on the majority of posts in this thread, I think you can see you're in
> the minority, both with regards to your opinions of ClojureScript and with
> regards to how this community should behave. Here's one more person who
> doesn't appreciate the attitude your posts embody. Rich, and everyone else
> more to learn from Clojure and its community than there is to criticize, in
> my opinion.
>
> I have never been involved in a more helpful or welcoming open source
> community than Clojure, and I'm involved in many. Wash your hands and be
> gone, if you're not interested in learning from people who have spent their
> hammock time coming up with the cutting edge in language design and
> implementation.
>
> Or just start coding and make things better.
>
> -Daniel
making things better is precisely what I offered in my OP, which was
taken as a "threat" and I was told to start a "separate mailing list"
for it; perhaps this community welcomes folks who don't know any
better than to be invariably effusive for everything in it, but for
those who do it it quite evidently has not been.
Ken Wesson
> I wish I had a plug I could pull to stop this thread right n
LOL
Timothy Baldridge
> making things better is precisely what I offered in my OP, which was
> taken as a "threat" and I was told to start a "separate mailing list"
> for it; perhaps this community welcomes folks who don't know any
> better than to be invariably effusive for everything in it, but for
> those who do it it quite evidently has not been.
But I think you need to understand what exactly it is that you are
asking of Rich and the other ClojureScript devs whith your original
comment. Rich's comment is not abnormal for the type of request you
are making. I have seen his type of reply before.
For a second let's try to cool down and see the logic process used in
Clojure to start with. Standard Clojure was developed on the JVM...for
one reason...it provides a platform to stand on while developing a new
language. We already have a type system, GC, etc. Could Rich have
developed all this from scratch? Sure, but we'd probably still be at
Clojure 0.1, and no one would be using the language in production.
Believe me, I've actually attempted writing Clojure in a lower level
language (both PyPy and C++), and it's not pretty, the level of tools
that exist for the JVM and the level of the JVMs themselves shaved
years of development time off the creation of Clojure.
What does this have to do with ClojureScript? Well I think it shows
the thought process that Rich uses when developing a new language. He
looks at his tools and finds platforms that make is life easier.
So, let's for the sake of argument, enumerate the features of both
sides of this question:
jQuery:
Understood by the JS community
Helps manipulate the DOM
Provides some UI routines
Optimizes code size via minifiers
Closure:
Enforces a strict OOP model
Provides Graphics routines (canvas)
Provides DOM manipulation routines
Provides many UI routines
Provides encryption, networking, spellchecking, math libraries etc.
Has a full optimizing compiler
The cons of Closure is of course that it's not well understood by the
JS community. But this really isn't a language for the JS community,
so is that really a problem?
I think Rich looked at both these options (and many more), and simply
picked the right tool for the job at hand. No! I would never use
Closure for a website I was writing in JS. It would be a major pain in
the neck. But I plan on using Clojure and ClojureScript for my future
web needs.
Just like you can write Clojure code and not care what Java is doing
under the hood. Now you can write Clojure for the browser and not care
about what JS is doing.
______________
So after taking that all into consideration, I'm confident, that if
you took the time to develop a POC that showed that a jQuery based
ClojureScript would be faster, smaller, and better than one developed
with Clojure, Rich would probably switch in a heartbeat. But until you
have hard evidence, it's really hard to convince anyone.
Timothy
James Keats
On Jul 26, 3:08 pm, Timothy Baldridge <tbaldri...@gmail.com> wrote:
Hi Timothy, and thanks for your much-better-than-others' reply.
> > Oh I will be washing my hands and be gone for sure, as coding and
> > making things better is precisely what I offered in my OP, which was
> > taken as a "threat" and I was told to start a "separate mailing list"
> > for it; perhaps this community welcomes folks who don't know any
> > better than to be invariably effusive for everything in it, but for
> > those who do it it quite evidently has not been.
>
> But I think you need to understand what exactly it is that you are
> asking of Rich and the other ClojureScript devs whith your original
> comment. Rich's comment is not abnormal for the type of request you
> are making. I have seen his type of reply before.
>
singlehandedly "fork" and redo it.
> For a second let's try to cool down and see the logic process used in
> Clojure to start with. Standard Clojure was developed on the JVM...for
> one reason...it provides a platform to stand on while developing a new
> language. We already have a type system, GC, etc. Could Rich have
> developed all this from scratch? Sure, but we'd probably still be at
> Clojure 0.1, and no one would be using the language in production.
> Believe me, I've actually attempted writing Clojure in a lower level
> language (both PyPy and C++), and it's not pretty, the level of tools
> that exist for the JVM and the level of the JVMs themselves shaved
> years of development time off the creation of Clojure.
>
expected Rich to "develop from scratch" a "type system, GC, etc." for
javascript, and this has nothing to do with Google's Closure tools.
additional layer of indirection (translated from another language)
that'd make working with it and reasoning about what's actually
happening and debugging even more of a pain. Sorry, this doesn't make
sense either.
I have already addressed other points, such as favoring it for
"enforcing a strict OOP model" as being an serious affront to the
credibility of clojure's rationale and advocacy and that its
optimizing compiler made sense back when most of the browsers out
there were IE6 but is no longer a reasonable priority.
Regards, and thanks again for your better-than-others' reply, I won't
be coding anything though after all this and I'll still be gone. For
sanity's sake, you guys ought to realize - for your own sake - that as
things stand you surely won't be "kicking butt" with clojurescript.
Devin Walters
Sent via Mobile
Base
On Jul 26, 12:31 pm, Devin Walters <dev...@gmail.com> wrote:
> Let's stop feeding this thread and turn our attention toward healthy and productive discussion. This is my first and final post on this matter.
>
> Sent via Mobile
>
Colin Yates
Sent from my iPad
Mark Derricutt
Daniel Werner
> My unhappiness with it is more akin to my unhappiness with ANY language that
> tries to target multiple VM platforms, and that's mostly due to the
> -potential- to break the community.
It may be helpful to approach the issue with the premise that
ClojureScript != Clojure. They share a lot of syntax and semantics,
and a developer experienced in one can easily transfer his/her working
knowledge to the other. But in the end, I perceive them as two
different languages that just happen to have a lot in common.
> Enter ClojureScript, for the most part you will be able to reuse server code on the
> front end, but some of those libraries you've become accustomed to using just
> won't work, and if you're working to a deadline and suddenly hit that - you're
> going to become frustrated beyond all hell ;-)
Personally, I wouldn't assume that anything works on ClojureScript
unless explicitly tested and labeled as such.
This seems like an interesting avenue to follow. This thread is
already past its expiry date, though, so I doubt further discussion
will get much attention here.
Daniel Gagnon
Javascript is simply painful to use functionally. The verbosity of anonymous functions, the lack of crucial HOFs like map/filter/reduce, the lack of functional data structures, the lack of macros (not strictly a "functional" feature, but especially useful with functional code)... You can fix these to varying degrees with libraries; but in any case the overall superiority of Clojure syntax and data structures must be obvious to anyone interested in ClojureScript, since those are the sole advantages it provides over Javascript.
David Nolen
Javascript is simply painful to use functionally. The verbosity of anonymous functions, the lack of crucial HOFs like map/filter/reduce, the lack of functional data structures, the lack of macros (not strictly a "functional" feature, but especially useful with functional code)... You can fix these to varying degrees with libraries; but in any case the overall superiority of Clojure syntax and data structures must be obvious to anyone interested in ClojureScript, since those are the sole advantages it provides over Javascript.The verbosity of anonymous function (and much more) is fixed by CoffeeScript and Coco[1] and the lack of crucial HOFs is fixed by underscore.js
Daniel Gagnon
I like CoffeeScript. But CoffeeScript is largely syntactic sugar. Hardly anything in the way of new semantics. And it encourages traditional stateful OOP and classical inheritance.Underscore.js does what it can, but it's goals are largely trumped by CoffeeScript.David
ronen
for large web application, starting with the JQueryUi immaturity and
the plethora of plugins that sometime work and sometime don't.
Rich and the rest of the core team, don't be discouraged by such
comments, if it wasn't for your work id wouldn't be so much excited
with javascript as I am now!
Iv bought the Closure book and I can't wait to see all the cool stuff
that the Clojure community will bring to this arena!
Ronen
Tal Liron
position *a little*.
Projects like ClojureScript (and CoffeeScript) -- and GWT and Vaadin
for that matter -- come from a certain anti-JavaScript attitude.
Though I sympathize, I would like to encourage all the JavaScript
haters to give JavaScript another chance. The C-syntax isn't great,
but the language itself shares with Lisps a minimalist core and the
ability to be truly multi-paradigm. If you like JS, you may find
yourself not *needing* something like ClojureScript, CoffeeScript,
etc.
(Although, James, the fact that you and I don't need or want it should
not cause us any disappointment with its existence! For die-hard JS
haters, ClojureScript is terrific.)
jQuery is not so much an elephant as it is a mammoth. It was one of
the first clientside-JS frameworks to reach a broad audience, but it
also one of the worst. It incorporates so many terrible JS practices,
performs miserably, and really can make anyone dislike JS. People have
mentioned other clientside frameworks. Let me mention also Ext JS,
which I believe knocks the socks off the rest. It is crafted with a
real appreciation of JS, and that love may rub off you a little as you
work with it.
And I'll also mention Prudence, which was announced on the list this
week:
http://threecrickets.com/prudence/
Prudence lets you mix both Clojure and JS (via Rhino) code on the
server, and also features good integration with Ext JS. It could be a
good platform for Clojure web development warriors to hone their JS
chops. (Disclosure: I'm the founder of Prudence.)
-Tal
On Jul 24, 10:19 am, James Keats <james.w.ke...@gmail.com> wrote:
> Alright, to be honest, I'm disappointed.
>
> First of all, congrats and good job to all involved in putting it out.
> On the plus side, it's a good way to use the Google Closure javascript
> platform.
>
> On the minus, imho, that's what's wrong with it.
>
> Google Closure is too Java. It's not idiomatic JavaScript. I find it
> disappointing that rather than porting from a functional language like
> Clojure straight to another functional language like Javascript, the
> google closure with its ugly Java-isms is right there obnoxiously in
> the middle.
>
> Then, there's the elephant in the room, and that elephant is Jquery. I
> believe any targetting-javascript tool that misses out on jquery-first-
> and-foremost is missing out on the realities of javascript in 2011.
> Jquery is huge in its community and plugins, and it has tons of books
> and tutorials. In much the same way that you can have lots of libs on
> the JVM, there are lots of plugins for jquery. So much so that the
> latest edition of Javascript: the Definitive Guide includes a chapter
> on it; quoted:
>
> "Because the jQuery library has become so widely used, web developers
> should be fa-
> miliar with it: even if you don’t use it in your own code, you are
> likely to encounter it
> in code written by others."
>
> Then, the Google Closure compiler is a moot point. Everyone by now
> already has a copy of jquery from the Google CDN and linking to it in
> your code will not download it any further after your first visit to a
> website that does so. In any case, it's already small and fast.
>
> Then there's rhino/jvm. I would much rather an in-browser focus.
>
> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> so that seamless interop with jquery would be the main priority.
>
> Discuss?
Lars Rune Nøstdal
Praki Prakash
jQuery is not so much an elephant as it is a mammoth. It was one of
the first clientside-JS frameworks to reach a broad audience, but it
also one of the worst. It incorporates so many terrible JS practices,
performs miserably, and really can make anyone dislike JS. People have
mentioned other clientside frameworks. Let me mention also Ext JS,
which I believe knocks the socks off the rest. It is crafted with a
real appreciation of JS, and that love may rub off you a little as you
work with it.
--
(praki)
Tal Liron
Yes, they are different things. :) Ext Core is probably close in scope
to jQuery by itself. But you can really build Ext JS modularly and use
only what you want. Also, jQuery + plugins ends being just as full-
featured as the complete Ext JS (though the quality of jQuery plugins
tends to be very spotty, IMO.)
Praki, the short answer is that:
1) Ext JS uses the flyweight design pattern throughout, which saves a
lot of resources (it means far less instances are created). Everything
in jQuery is heavyweight.
2) Ext JS has a template-based widget rendering pipeline.
3) Both the above have very real-world performance improvements. I
moved one of my applications from jQuery to Ext Core and had a 400%
performance gain.
4) Ext JS has a very nice class system. I'm not a huge fan of object
orientation, but admit that it makes a lot of sense in widget/
component environments.
5) jQuery plugin architecture is very incoherent. Try to design your
plugin and see!
On Jul 28, 9:40 pm, Praki Prakash <praki.prak...@gmail.com> wrote:
Alexander Yakushev
language" push - I realized that Clojure has become mature. When the
people who do not agree with some choices appear not just outside but
in the community itself - it means that the language matters to them
despite the parts they don't like. Matters enough not to just say "Ah,
screw it, I'll just switch to FooLanguage".
So, sit back, get involved in head-punching and just enjoy Clojure
being a grown-up.
daly
Try to see the situation from the lead developer perspective
(e.g. Rich's perspective). I have been through the "head-punching",
as you call it and I don't want to put words in Rich's mouth but
I do see things differently.
To lead a project you need to make design choices.
To make those design choices you have to take a lot of factors
into account.
Those factors are optimized based on a lot of considerations,
most of which are stated in the project goal or justification.
As you say, "people who do not agree with the choices appear".
When they do, they generally advocate a particular position that
is in conflict with the project goals or justification. Or they
advocate for a new direction that gets rejected.
These "advocates" are of two varieties. Either they are casual
contributors (posters to the mailing list) or developers who have
invested a lot of time and effort going against the goals.
The "posters" who disagree tend to choose particular topics that
they find familiar (e.g. autoconf, eclipse, emacs, maven, etc.).
These lead to mini-flame wars (head-punching, bike-shedding).
The developers who disagree tend to choose particular topics that
they have invested time and effort to develop code. These lead to
forks.
In either case, as the lead developer, you constantly have to
justify your choices. The design space has a lot of freedom so
you have to make choices based on your best judgement. Not everyone
will agree, as you can see. This causes a great deal of stress
on the lead developer, which you DON'T see. Defending every choice
from every poster and developer takes a lot of time and effort.
What is particularly frustrating is the people who ignore your
effort to communicate. If you justify using Google Closure (as
Rich has), if you justify leaving out eval (as Rich has), if you
justify changing certain language features (as Rich has), then
it seems reasonable to expect that people pay attention to the
goals and choices. It is very tiring to keep repeating "the choice
has already been made", especially when code is being written to
support that choice.
As you say, "the language matters to them". Of course it does.
It also matters to Rich. The reason it "matters" is that Rich
is doing an excellent job navigating the design space based on
his considerable experience. He is solving deep problems, like
the expression problem, in novel and creative ways. He is making
tradeoffs based on a lot of factors (unlike the posters) which
take into account project goals such as important performance
questions.
Posting emails about "who's unhappy with ..." is not constructive
criticism. And when it ignores already stated goals or justifications
it can only result in anger. As a Common Lisper, I see that Rich is
dancing all over my religious beliefs, but that seems to be my
problem, not his. If it makes me unhappy that's also my problem.
Being unhappy with design choices is NOT Rich's problem. So why
would I use Rich's mailing list to complain?
While it is fine to say "get involved in head-punching" I think
it is important to realize that it is Rich's head being punched.
Tim Daly
Luc Prefontaine
+1
I would add that I want to see Rich maintain is grip on the Clojure wheel for a very long time.
Consensual decisions are most of the time not the best. They are the result
of compromises not based on technical arguments but on people's feelings or political issues.
I would rather rely on someone who has invested a significant time in evaluating
several options after collecting the maximum input than on loose canons coming up with ideas
that do not fit well with Clojure.
Another thing that Rich does very well is to postponed decisions because he feels
he did not find the good solution yet and needs to think again about it.
How many of us in our professional life can demonstrate such independence ?
How many told their boss "I am not ready yet to take a decision on this matter" ?
We have a leader here that has a very good track record decision wise + an astounding achievements.
Stop hammering on him and if you are not happy with Clojure, find another language
that matches your aspirations. They are plenty out there.
Luc P.
daly <da...@axiom-developer.org> wrote:
--
Luc P.
================
The rabid Muppet
Ken Wesson
<lprefo...@softaddicts.ca> wrote:
> I would add that I want to see Rich maintain is grip on the Clojure wheel for a very long time.
>
> Consensual decisions are most of the time not the best. They are the result
> of compromises not based on technical arguments but on people's feelings or political issues.
And the result of them tends most often to be something like Java at
best, and often closer to C++.
> Stop hammering on him and if you are not happy with Clojure, find another language
> that matches your aspirations. They are plenty out there.
There is something of an issue here, though: where, exactly, should
the line be drawn between "thou shalt not question this on the mailing
list!" and "fair game for discussion", presuming as you do that it
isn't "everything is fair game for discussion if it's not entirely
unrelated to Clojure". You seem to feel that major, already-made
design decisions that would require a fork and massive effort to do
differently lie on the "shalt not question" side. What about more
minor choices -- for example, which of the three kinds of primitive
math overflow behaviors, throwing, auto-promoting, or wrap-around,
should be the default? I assume not-yet-made choices and
easily-tweaked, recentish (still in alpha or beta) things that won't
break a lot of existing code fall under "fair game".
Also, what should the policy be for responding if someone questions a
"shalt not question" anyway? Currently, there's an unfortunate
tendency to assume the worst motives and to employ namecalling,
particularly the word "troll", against possibly-well-intentioned
transgressors. I'd suggest that such threads should get a single
response, saying "that decision's already been made; if you want to
make your own fork that does it differently go ahead, and if you want
to discuss it there's the clojure-misc google group, but please don't
clutter *this* group with it", and otherwise the post should be
ignored. Followups by the OP should be ignored. Oh, and there should
probably be a pointer to a FAQ of some sort in that initial response
answering any likely "but why?" type questions the OP might have,
including "what other topics will bring this kind of response?".
Stuart Halloway
There is something of an issue here, though: where, exactly, should
the line be drawn between "thou shalt not question this on the mailing
list!" and "fair game for discussion"
You seem to feel that major, already-made
design decisions that would require a fork and massive effort to do
differently lie on the "shalt not question" side. What about more
minor choices -- for example, which of the three kinds of primitive
math overflow behaviors, throwing, auto-promoting, or wrap-around,
should be the default?
Ken Wesson
<stuart....@gmail.com> wrote:
> In principle the line is clear. Everything is fair game. Novel feedback is
> always welcome. Question small decisions, question big ones. Press hard for
> quality.
> The opposite of providing novel feedback is recovering old ground. This
> takes two (often overlapping) forms:
> (1) Pushing an agenda when you aren't up to speed enough to be in the
> conversation.
> (2) Pushing an agenda when project leadership has said, "I understand your
> feedback and disagree. This is not the direction we plan to pursue."
I'd say there's also
(3) Covering old ground you didn't know had been discussed before.
Though you might lump that into 1; but there's a difference between
"not up to speed and should know it" and "not up to speed with no way
of knowing it". (3) is most likely coming from a newbie. Another
source of (3) would be if the previous discussions all took place
elsewhere, such as IRC or the dev list, that the user hasn't been
monitoring.
>> You seem to feel that major, already-made
>> design decisions that would require a fork and massive effort to do
>> differently lie on the "shalt not question" side. What about more
>> minor choices -- for example, which of the three kinds of primitive
>> math overflow behaviors, throwing, auto-promoting, or wrap-around,
>> should be the default?
>
> Ken, you are beating a dead horse on 1.3 numerics.
No, I was just bringing it up as an example to illustrate something
else. But now that you bring it up ...
> In particular: (1) You think that the overflow defaulting choice is minor,
> and I think it is fundamental.
Actually, what I think is that the default (once you have a BigInt
that is about as fast as a boxed Long when the numbers are small)
should be to use BigInt except when primitives are specified, and to
use checked primitive math then, with unchecked as an option. This
would be most compatible with 1.2's numerics behavior, and still
provide all 3 options for arithmetic handling.
(I also have concerns about the *unchecked-math* flag I heard about
somewhere. We can't have +, etc. testing some flag at runtime -- much
less fetching a dynamic Var, which is a slow, slow ThreadLocal object
at the JVM level -- before each add without losing performance badly.
We really need an (unchecked-math (the-math-goes-here)) macro, or
something, that affects what functions get used at *compile time*
rather than a dynamic Var flag that is set before performing what you
hope to be really fast math.)
> (2) You were unaware of the platform issues
> in Java that drove us to implement our own BigInt.
That arose in connection with a problem with format, not a gripe with
arithmetic.
> That said, Ken's questions on numerics are not unwelcome. It is not
> realistic for every comer to the mailing list to have encyclopedic knowledge
> about what has gone before.
That would be my category (3) above. :)
> So nobody should bite anyone's head off for
> asking a question that has been answered before (particularly if e.g. it is
> hiding in a deep, convoluted thread and isn't search friendly).
Which, unfortunately, is exactly what happened to me with the numerics
thing a while back. :P
David Nolen
(I also have concerns about the *unchecked-math* flag I heard about
somewhere. We can't have +, etc. testing some flag at runtime -- much
less fetching a dynamic Var, which is a slow, slow ThreadLocal object
at the JVM level -- before each add without losing performance badly.
We really need an (unchecked-math (the-math-goes-here)) macro, or
something, that affects what functions get used at *compile time*
rather than a dynamic Var flag that is set before performing what you
hope to be really fast math.)
Alexander Yakushev
> While it is fine to say "get involved in head-punching" I think
> it is important to realize that it is Rich's head being punched.
At any point of a lifetime of a computer language there are people
that do not agree with some of its design choices. What differentiates
young languages from mature ones is the way how these people deal with
their disagreement.
Year ago a person who was unhappy with some Clojure parts would think:
"No, Clojure is just not for me". Now this person understands actually
how awesome Clojure is, but he is still unhappy with some features.
What does he do now? Right, he goes to the mailing list and starts a
thread with the topic: "Alright, fess up, who's unhappy with Clojure
having no goto?" This person is not evil, neither he wants to insult
the language designers - he just sees this nice tool with minor
mistakes (from his perspective) in it and he wonders why such clever
people as the language designers made this mistakes (from his
perspective).
For example, why do people curse C++ and blame Stroustrup so much?
Because, after all, C++ is an ubiquitous language. Once he (Bjarne
Stroustrup) said: "There are only two kinds of programming languages:
those people always bitch about and those nobody uses". Clojure
finally made it into the first group and that is what I am happy with.
Now we have to learn how to live with the side-effects of it.
I don't think that such messages should be considered like Rich's head
being punched. I don't think that Rich should consider them like an
offense to him or to his work. But such situations are inevitable and
all of us and Rich in particular have to learn how not to take it to
heart.
Alexander
James Keats
As an outcome of this thread, I have decided not to invest in clojure,
so I believe the following to be purely feedback, as I have no agenda
to push.
- it seems from some's point of view that I was "trolling". Fine, from
my point of view though it was akin to "drink the kool aid or gtfo".
Sorry, I'm too old and too well-read and too inquisitive to drink the
kool aid, so I'll just gtfo.
- I'm not sure what you mean by "not up to speed". I had the book
about the google closure library for nearly a year now and I'd read it
a few times. I'd gotten copies of all the clojure books published and
downloaded all the videos put out and read/watched them several times.
I'd scoured the web - and this group - for every clojure related
reading material I could find, and watched the clojurescript video a
couple of times very carefully and read its rationale a few times.
- I'm not sure what you mean by "recovering old ground". When I made
the post (24th of July) Clojurescript had only been out for a few
days, most notably it was 2 days after "Video is now available of Rich
Hickey's talk at ClojureNYC yesterday announcing clojurescript" (22nd
of July).
- I'd understand what you might've meant by the above two points if
you guys had no intentions for anyone outside a very small tightknit
group of you to use clojurescript, but if you'd intended others
besides you to use it too then no, I don't.
- I'm also not sure what you mean by "He did not understand the
thereafter and throughout were clear enough that my concern was not
the clojure language itself, but the google closure library as a
dependency.
- the argument - paraphrasing - "it's just clojure, you code in
clojure, the google library is under, and you don't need to look
under" is akin to saying "here's a foundation for you to build a
skyscraper on, now build your skyscraper, don't look under at what's
in the foundation you're building on". Sorry, can't do.
- the notion that the leader decides all unquestioned and that no
disappointment or unhappiness will be tolerated is too stalinist for
my taste.
Regards and best wishes.
James Keats
As an outcome of this thread, I have decided not to invest in clojure,
so I believe the following to be purely feedback, as I have no agenda
to push.
- it seems from some's point of view that I was "trolling". Fine, from
my point of view though it was akin to "drink the kool aid or gtfo".
Sorry, I'm too old and too well-read and too inquisitive to drink the
kool aid, so I'll just gtfo.
- I'm not sure what you mean by "not up to speed". I had the book
about the google closure library for nearly a year now and I'd read it
a few times. I'd gotten copies of all the clojure books published and
downloaded all the videos put out and read/watched them several times.
I'd scoured the web - and this group - for every clojure related
reading material I could find, and watched the clojurescript video a
couple of times very carefully and read its rationale a few times.
- I'm not sure what you mean by "recovering old ground". When I made
the post (24th of July) Clojurescript had only been out for a few
days, most notably it was 2 days after "Video is now available of Rich
Hickey's talk at ClojureNYC yesterday announcing clojurescript" (22nd
of July).
- I'd understand what you might've meant by the above two points if
you guys had no intentions for anyone outside a very small tightknit
group of you to use clojurescript, but if you'd intended others
besides you to use it too then no, I don't.
thereafter and throughout were clear enough that my concern was not
the clojure language itself, but the google closure library as a
dependency.
- the argument - paraphrasing - "it's just clojure, you code in
clojure, the google library is under, and you don't need to look
under" is akin to saying "here's a foundation for you to build a
skyscraper on, now build your skyscraper, don't look under at what's
in the foundation you're building on". Sorry, can't do.
- the notion that the leader decides all unquestioned and that no
taste. It is my belief that the hallmark of good open source software
is its attitude towards intense and thorough scrutiny.
Nicolas
Like GWT, JWT, ZK or other, you do not longer develop in the client language. You develop in a different language and compile/generate down/use internally JS under the wood.
The whole thing is abstracting things away. Like you don't care in java about CPU registers, x86 instruction set or even allocating memory. The JVM and java abstract it for you.
So there no point as of idiomatic javascript, better OOP model, bad part or good parts. Like one don't care how the x86 code generated by JIT look like, one don't care the look of generated javascript. In fact this discussion is not new. Like you on clojurescript, some developers in the sixties were thinking that assembly language was important, that higher level language were not usefull and that the generated code should look like beautiful handcrafted code. Today processors intruction set are made for compilers, not programmers and most of us don't care much about assembly code anymore.
You can think that idiomatic JS is indeed better than clojurescript. Then don't use clojure. Even by using Jquery or Crawford best pratices, clojurescript will always feel clojure, not like JS. That the essence of clojure. And if you don't like it, there isn't much to argue.
You may not like closure library and prefer jquery. That's fine. But we are not in JS. And in fact closure library with it's strong namespace and convention, with it's compiler is a good fit. In particular because Closure is not "idiomatic" javascript and much more java-like that it fit clojure that well.
You don't like closure library, and that was by design... like you don't like closurescript decision, but it is by design too. In fact nobody use closure library except google... But nobody is able to produce advenced browser client UI except google.
Maybe the design of clojurescript is not so bad after all?
We can argue all we want. But it's time to make decision. It time to use your brain. If you fail to understand/embrace/love clojurescript, no one will care. We can't change people. Maybe clojurescript is really useless and serve nobody interrest and you are on the right side. Maybe you totally missed the point and you humor decision to give will make you lose years and limit your comprehension of computer science and software engineering.
In the end what you choose, what we choose just concern ourselve individually, not others. Many will make mystake and will be persuaded to have done the right choice anyway. But that's life. The more likely is we are all wrong anyway, maybe some a little less wrong than other, nothing more.
Me think clojurescript is exactly the type of think I need and want to use. And I'am happy. Me don't want to use jQuery instead. Me prefer that you fork or make your design if you are serious about it. So all the bad things remains in your repository and hopefully nobody will be forced to use it.
Have a nice day.