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]

Hi James,

The Clojure/dev folks who built ClojureScript disagree with all of the key points of your analysis:

Google Closure is too Java. It's not idiomatic JavaScript.

If you target idiomatic JavaScript you will find yourself living in the world of JavaScript semantics. It is evident that many people want that.  We don't.

Then, there's the elephant in the room, and that elephant is Jquery.

JQuery is a powerful library. So is Google Closure. I don't share your certainty that JQuery is the elephant. (I don't use any JQuery apps that have the sophistication of GMail.)

But in any case, we are targeting a future community, not any currently-existing one. 

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.

This is a good argument for modest applications, and a poor argument for substantial ones. We are interested in the latter.

Then there's rhino/jvm. I would much rather an in-browser focus.

Rhino is an implementation detail of the development platform. That implementation detail could and probably should change.

I'm tempted to "fork" clojurescript and redo it in javascript perhaps
so that seamless interop with jquery would be the main priority.

If that is your objective, the ClojureScript codebase won't be a useful starting point. You would be better off to start from scratch.

Cheers,

Stu

Stuart Halloway
Clojure/core
http://clojure.com

[Aaron Bedra]

First:

* 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]

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:

---

Do you have an actual argument from experience here, or are you regurgitating what you've read in articles like [1].  Is CoffeeScript idiomatic javascript?  How about Dojo?  SproutCore?  jQuery?  What exactly is idiomatic javascript?

vs. jQuery:

---

jQuery is awesome for adding dynamicity and ajaxy stuff to page based web apps, I don't think anyone argues that.  And it is extrememly simple, not even requiring the user to know any javascript to use it.  This is why it is so (deservedly) popular.

Large scale, single page applications are a different thing than page based sites, however.  Writing these types of apps with only jQuery quickly turns to spaghetti.  There are some nice libraries/frameworks out there, like Backbone and Underscore, that do a very nice job of making it cleaner and scalable.  These are all still fairly young though, to be fair.

In the realm of proven environments for large scale, client side javascript development, you have Dojo and Google Closure, and to some degree SproutCore and Cappuccino.  If you can point me to larger scale apps than GMail, Google Docs, etc., written using jQuery, I will gladly have a look.

Once you get to that scale, you really needing a way to organize code, to package and load modules, etc.  Dojo and Closure offer a pretty nice, and proven, system for this.  

So, yes, I would have preferred Dojo, because I am more familiar.  But to be fair, Closure is very similar, is a very complete library, and has very good documentation and examples for the most part.

[1] http://www.sitepoint.com/google-closure-how-not-to-write-javascript/

 - Mark

--
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]

Yes, true, I always forget about YUI, and it never gets its fair recognition. 

 - Mark

[David Nolen]

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

On Sun, Jul 24, 2011 at 11:19 AM, James Keats <james....@gmail.com> wrote:

[Frank Gerhardt]

On Sun, Jul 24, 2011 at 7:03 PM, David Nolen <dnolen...@gmail.com> wrote:

I think the Clojure community can do much, much better. In fact a clientside framework could be the first Clojure killer app ...

Yes, absolutely. 

Integration with other libraries is essential, and possible as I understand it. For client side UIs I need a choice of JQuery, YUI, ExtJs, Closure and others. Most of the time there are customer-related constraints for or against a certain UI library. As clojurescript is only alpha we can't expect that story to be completely done. It would be nice to get an idea in what direction you are thinking for a client-side framework, especially idiomatic UIs.

Frank.

[James Keats]

On Jul 24, 5:02 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote:
> 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:
> ---

I'm not "arguing that everything should be more like Java", but
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!"

> [1]http://www.sitepoint.com/google-closure-how-not-to-write-javascript/
>
>  - Mark
>

> On Sun, Jul 24, 2011 at 11:19 AM, James Keats <james.w.ke...@gmail.com>wrote:
>
>

[Wilson MacGyver]

Given that google closure library has a fairly decent size UI elements, and the pitch about how clojurescript makes google closure usable for mortals. I think that's probably where it will start.

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
>

I was hoping that clojure itself would help jquery build sophisticated
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]

On Sun, Jul 24, 2011 at 1:46 PM, James Keats <james....@gmail.com> wrote:

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.

Restricting yourself to a functional subset of JavaScript can't fix JavaScript. The functional subset stinks, Javascript notaries be damned.

David

[James Keats]

On Jul 24, 7:05 pm, David Nolen <dnolen.li...@gmail.com> wrote:

If so where does this leave clojure itself and its advocacy of
functional programming, then; see last paragraph of my reply to Mark.

[Michael Gardner]

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).

[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.

I'm not drawing an inference, but an argument.

> 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. 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, 2011, at 2:08 PM, James Keats wrote:

> 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]

On Sun, Jul 24, 2011 at 11:11 AM, James Keats <james....@gmail.com> wrote:
> 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]

>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

[Base]

"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.

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.
>

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

> It's not idiomatic JavaScript.

There's no such thing as idiomatic JavaScript. There are a lot of
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.
>

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.

> 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.

> 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.

> 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.

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]

On Sun, Jul 24, 2011 at 2:28 PM, Rich Hickey <richh...@gmail.com> wrote:
>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.

I'm certainly not just picking a fight, I'm honestly voicing a
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]

OK, good. Now, say you're sorry if you offended him. -"I'm sorry if I
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]

Oracle announced/talked about Nashorn at the recent JVM Languages summit, this is an Invoke Dynamic based Javascript runtime which is (aiming) for inclusion in JDK8.

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.

[Colin Yates]

Absolutely nothing to add to the argument as such except to say that I am quite surprised at the level of resistance to James' thread.  I can see the argument if this was the 'dev' mailing list.

I have been reading this mailing list for a long while now (even if I haven't contributed much to it) but if this had been the first post I had read I would have a very negative opinion of the *clojure community*.  It comes off as sounding like "if you don't like what we do, go away - it is our way or the highway", which would be a terrible shame as I don't *think* that is the case?  If I wanted that atmosphere there are plenty of other places to go.

Sure, I get that James' email didn't really provide any points of discussion, it was more a moan (sorry James ;)), but so what - I don't see anybody shooting down "ClojureScript - I love it" type posts.  And maybe a better response would be asking "OK, this guy clearly doesn't get it - how can we improve our communication"?

Rich - we are *all* grateful and I expect I am not alone in being amazed at the technical marvel you have pulled out of the hat.  But to be honest I think you need a thicker skin.  Getting your strokes from the mailing list is dangerous at best.  To be disheartened by one negative post in the midst of positive votes is a bit worrying.  

If this mailing list is for the community to discuss Clojure and ask Clojurians for help then these responses were inappropriate.  If this mailing list is to "big up" Clojure then fine - but make that explicit.

Col (surprisingly disappointed and feels strongly enough to send this at the risk of being called a troll himself!)

P.S.  Strongly opinionated communities that shoots down criticisms of "the great leaders' achievements" is unfortunately not breaking new ground - so stop this :) and move onto the next ground breaking tool!

[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]

Clojure newcomer here, but here's the thought that's frontmost in my
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.

On Jul 24, 10:28 pm, Rich Hickey <richhic...@gmail.com> wrote:

> On Jul 24, 11:19 am, James Keats <james.w.ke...@gmail.com> wrote:
>
> > 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.

"clojure's rocks... javascript reaches"

>
> > 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

Rich, the "pseudo class model" with the new keyword is a syntactic
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.
>

The Javascript community - the vast majority of which - after a decade
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.

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/

>
> > 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.

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.
>

The point is "reach", Rich; things like this:

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.

I did read it though. In any case, the suggested "fork" was for lack
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

> helping people kick butt.Describe your new note here.

[Alen Ribic]

> > 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.
> 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/

Who really cares what library is used at this early, *alpha*, stage of
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

> 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.
>
> 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.
>

> http://www.google.com/trends?q=%22google+closure%22(that lone

[Nick Zbinden]

> Oracle announced/talked about Nashorn at the recent JVM Languages summit, this is an Invoke Dynamic based Javascript runtime which is (aiming) for inclusion in JDK8.
>
> 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.

Does it really matter? Nobody would really deploy ClojureScript based
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]

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.

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 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.

 - Mark

On Mon, Jul 25, 2011 at 5:08 AM, Colin Yates <colin...@gmail.com> wrote:

[Lars Rune Nøstdal]

I'd say Google Closure/Libray is "more idiomatic" JavaScript than jQuery; jQuery is more "sugary" and has a different feel to it.

I like jQuery, but I completely see why that is not a the most optimal base to build on when something like Google Closure exists. Rich mentioned, however, that people would probably wrap or include jQuery as a plugin anyway, i.e. not as a base thing, and this is ok and a much better strategy IMHO.

I didn't really understand your post about Yegge either.

[Ken Wesson]

On Mon, Jul 25, 2011 at 8:28 AM, Mark Rathwell <mark.r...@gmail.com> wrote:
> 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.