Re: Alright, fess up, who's unhappy with clojurescript?

[Alexander Yakushev]

On Jul 30, 6:02 pm, daly  wrote:

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

Seems like I was unclear in my statement. I'll try to do it again.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Ken Wesson]

On Sat, Jul 30, 2011 at 10:22 PM, Luc Prefontaine
 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?".

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Luc Prefontaine]

On Sat, 30 Jul 2011 11:02:13 -0400
+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  wrote:

> 
> 
> 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
> 
> 
> On Sat, 2011-07-30 at 01:26 -0700, Alexander Yakushev wrote:
> > The moment I saw the previous controversial topic - about "yes
> > 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.
> > 
> 
> 



-- 
Luc P.

=

Re: Alright, fess up, who's unhappy with clojurescript?

[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


On Sat, 2011-07-30 at 01:26 -0700, Alexander Yakushev wrote:
> The moment I saw the previous controversial topic - about "yes
> 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.
> 


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Alexander Yakushev]

The moment I saw the previous controversial topic - about "yes
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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Tal Liron]

Lars,

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  wrote:
> On Thu, Jul 28, 2011 at 5:20 PM, Tal Liron  wrote:
> > 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.
>
> I am not a front-end developer but I am currently stuck prototyping using
> JQuery. I am
> also not a JS expert. I am curious: can you list JQuery's issues and how it
> uses JS badly?
> Or, provide some references?
> --
> (praki)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Praki Prakash]

On Thu, Jul 28, 2011 at 5:20 PM, Tal Liron  wrote:

> 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.
>
>
I am not a front-end developer but I am currently stuck prototyping using
JQuery. I am
also not a JS expert. I am curious: can you list JQuery's issues and how it
uses JS badly?
Or, provide some references?
-- 
(praki)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Lars Rune Nøstdal]

.. but isn't jQuery and ExtJS totally different things?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Tal Liron]

James, your tone was unfortunate, but I do want do defend your
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  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?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[ronen]

Im not a javascript guru but from my experience JQuery isn't suitable
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

On Jul 25, 10:38 am, Mark Derricutt  wrote:
> 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.
>
> On 25/07/2011, at 3:54 AM, Stuart Halloway wrote:
>
> > Rhino is an implementation detail of the development platform. That 
> > implementation detail could and probably should change.
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[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
>
> CoffeeScript and Coco are largely Javascript. I'm just saying they are a
fairer comparison than naked Javascript. Especially when we speak about how
awkward it is to write Javascript.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[David Nolen]

On Thu, Jul 28, 2011 at 12:09 PM, Daniel Gagnon wrote:

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

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

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

1: Coco is a CoffeeScript fork that fixes the main issues CoffeeScript have
(example: CoffeeScript's scope is broken).

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Daniel Werner]

On 27 July 2011 01:43, Mark Derricutt  wrote:
> 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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: The Number of Clojure (Was: Alright, fess up, who's unhappy with clojurescript?)

[Marek Kubica]

On Tue, 26 Jul 2011 21:30:25 -0700 (PDT)
pmbauer  wrote:

> These "unhappy" threads need to die a horrible death.

Well, criticism can also be constructive. It does at least show some of
the problems and/or desires that the community has. Fortunately, noone
is forced to read them :)

regards,
Marek

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: The Number of Clojure (Was: Alright, fess up, who's unhappy with clojurescript?)

[OGINO Masanori]

And I should have posted about the spec separately, right?
;; or all I have to do is to forbid myself to post anything...

-- 
Name:  OGINO Masanori (荻野 雅紀)
E-mail: masanori.og...@gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: The Number of Clojure (Was: Alright, fess up, who's unhappy with clojurescript?)

[Luc Prefontaine]

No need to wait in desperation for this, just add a filter rule in your email 
client
to send these to trash directly. I have a couple of these and it saves me a 
significant
# of frustrating hours :)

Luc P.

On Tue, 26 Jul 2011 21:30:25 -0700 (PDT)
pmbauer  wrote:

> These "unhappy" threads need to die a horrible death.
> 



-- 
Luc P.


The rabid Muppet

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: The Number of Clojure (Was: Alright, fess up, who's unhappy with clojurescript?)

[pmbauer]

These "unhappy" threads need to die a horrible death.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: The Number of Clojure (Was: Alright, fess up, who's unhappy with clojurescript?)

[OGINO Masanori]

Oops, I wrote a footnote not to forget giving a supplement but I forgot it.

The number two was the number of Rich's Clojure implementations AFAIK.

-- 
Name:  OGINO Masanori (荻野 雅紀)
E-mail: masanori.og...@gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

The Number of Clojure (Was: Alright, fess up, who's unhappy with clojurescript?)

[OGINO Masanori]

I have no opinion to add to mainline of this thread, but I could
answer one question.

Before the NYC meetup, there are two [1] "Clojure": Clojure on JVM and
Clojure on CLI/CLR.
Is Clojure on JVM "the true Clojure" and that on CLI/CLR is an poor imitation?
(in Ruby: Is MRI the true Ruby and JRuby, Rubinius, MacRuby, ...(snip))

Now we have three "Clojure".
I think we can categorize programming languages into three groups by
the number of implementations.

1. Zero; the language is in the design stage.
2. One; here you are, this is *the* implementation!
3. Many; well, which implementation I should use? where is the spec?

Clojure *was* 3. before the meetup and *is* 3. now, right?
If so, the problem was there and is still there. It doesn't change.

So...may I ask where is the spec? :-P

2011/7/25, 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.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en


-- 
Name:  OGINO Masanori (荻野 雅紀)
E-mail: masanori.og...@gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Mark Derricutt]

I'm "unhappy" with ClojureScript but not in anyway like it seems you are.

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.

One of the main reasons Clojure "made it" over other lisps on the JVM IMHO was 
its pragmatic approach, and it's seamless and beautiful interop with Java and 
Java libraries.  We've now seen A LOT of adoption and libraries wrapping around 
existing java frameworks, and we're also now starting to see native Clojure 
libraries - however, these are native libraries wrapping low level JVM classes, 
so are still tied to the JVM.

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

Of course, the likely hood of this happening is very low, but I can see it 
coming up -sometime-.

All that being said, everything I've seen with ClojureScript is just pure 
awesome.



On 27/07/2011, at 12:32 AM, James Keats wrote:

> It was a serious title. I'm still surprised that I seem to be the only
> 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.



smime.p7s
Description: S/MIME cryptographic signature

Re: Alright, fess up, who's unhappy with clojurescript?

[Colin Yates]

The irony of +1 doesn't escape me, but +1

Sent from my iPad

On 26 Jul 2011, at 20:15, Base  wrote:

> +1
>
> On Jul 26, 12:31 pm, Devin Walters  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
>>
>> On Jul 26, 2011, at 9:56 AM, James Keats  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Jul 26, 3:08 pm, Timothy Baldridge  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.
>>
>>> And what is it exactly I was "asking of" them?! I offered to
>>> 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.
>>
>>> No, sorry, this doesn't make sense. No reasonable person would've
>>> expected Rich to "develop from scratch" a "type system, GC, etc." for
>>> javascript, and this has nothing to do with Google's Closure tools.
>>
 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.
>>
>>> Right, so you wouldn't use it in JS but you'd use it with an
>>> 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.
>>
 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 

Re: Alright, fess up, who's unhappy with clojurescript?

[Base]

+1

On Jul 26, 12:31 pm, Devin Walters  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
>
> On Jul 26, 2011, at 9:56 AM, James Keats  wrote:
>
>
>
>
>
>
>
>
>
> > On Jul 26, 3:08 pm, Timothy Baldridge  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.
>
> > And what is it exactly I was "asking of" them?! I offered to
> > 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.
>
> > No, sorry, this doesn't make sense. No reasonable person would've
> > expected Rich to "develop from scratch" a "type system, GC, etc." for
> > javascript, and this has nothing to do with Google's Closure tools.
>
> >> 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.
>
> > Right, so you wouldn't use it in JS but you'd use it with an
> > 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.
>
> >> 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
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "C

Re: Alright, fess up, who's unhappy with clojurescript?

[Devin Walters]

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

On Jul 26, 2011, at 9:56 AM, James Keats  wrote:

> 
> 
> On Jul 26, 3:08 pm, Timothy Baldridge  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.
>> 
> 
> And what is it exactly I was "asking of" them?! I offered to
> 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.
>> 
> 
> No, sorry, this doesn't make sense. No reasonable person would've
> expected Rich to "develop from scratch" a "type system, GC, etc." for
> javascript, and this has nothing to do with Google's Closure tools.
> 
>> 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.
>> 
> 
> Right, so you wouldn't use it in JS but you'd use it with an
> 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.
> 
>> 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
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To 

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 26, 3:08 pm, Timothy Baldridge  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.
>

And what is it exactly I was "asking of" them?! I offered to
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.
>

No, sorry, this doesn't make sense. No reasonable person would've
expected Rich to "develop from scratch" a "type system, GC, etc." for
javascript, and this has nothing to do with Google's Closure tools.

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

Right, so you wouldn't use it in JS but you'd use it with an
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.

> 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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Timothy Baldridge]

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

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Ken Wesson]

On Tue, Jul 26, 2011 at 9:29 AM, Laurent PETIT  wrote:
> I wish I had a plug I could pull to stop this thread right n

LOL

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 26, 2:01 pm, semperos  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
> on this list and everyone on this list  have
> put serious and brilliant efforts into developing Clojure. There's a lot
> 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

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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[László Török]

2011/7/26 Laurent PETIT 

> I wish I had a plug I could pull to stop this thread right n

+1


>
> 2011/7/26 semperos 
>
>> 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
>> on this list and everyone on this list  have
>> put serious and brilliant efforts into developing Clojure. There's a lot
>> 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
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>



-- 
László Török

Skype: laczoka2000
Twitter: @laczoka

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Laurent PETIT]

I wish I had a plug I could pull to stop this thread right n

2011/7/26 semperos 

> 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
> on this list and everyone on this list  have
> put serious and brilliant efforts into developing Clojure. There's a lot
> 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
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[semperos]

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 
on this list and everyone on this list  have 
put serious and brilliant efforts into developing Clojure. There's a lot 
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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 26, 1:53 am, Christian Marks <9fv...@gmail.com> wrote:
> On Jul 25, 6:11 pm, James Keats  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.

It was a serious title. I'm still surprised that I seem to be the only
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.

It isn't "jumbled prose", it is clear and to the point; enough of
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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[blackdog]

Clojure was my first Lisp, I learned it just after Rich's first vids came 
out, but I hung up my hat as I prefer 1 language on all tiers(ajax on 
client) for web apps. So, Clojurescript now presents me with the ability to 
do that, and really piques my interest again in Clojure. I think this is a 
terrific development for Clojure. 

Right now I use haXe (targetting js) on node.js and the browser with html5 - 
all typed apis, i mention this as it's in the same space, and I've recently 
had similar arguments in a system I've developed, regards tying to a base ui 
library.  We came down on letting our users select their own ui, it seemed a 
mistake to alienate most of the community no matter what selection of tool 
was used. Our team of 5 had 5 different opinions, it's a real can of worms. 

I think it would be better for Clojurescript acceptance in the long run to 
make use of closure compiler and libraries optional. If it's optional you 
can still utilize the closure compiler in your pipeline (like I can for haXe 
output js - works great), and the better optimizing compilers which will no 
doubt appear in the javascript arms race.

Coffeescript compiles to js as cleanly as possible; haXe by comparison is a 
lot more convoluted in that it has other semantics over and above standard 
js which require emulating, e.g. ocaml like enums. Neither however force the 
use of a 3rd party library. 

One other thing for dev, I'd like as speedy compilation as possible, raw 
compiler output with no other tweaks.

Thanks, for a great tool, it's certainly welcome addition.

bd


 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Christian Marks]

On Jul 25, 6:11 pm, James Keats  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.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Mark Rathwell]

James,

If I've misread and/or mischaracterized your intentions, I do apologize for
that.  I was, and still am, unsure as to your desired outcome from this
post.

If the intent was for the core team to rewrite ClojureScript to target
jQuery instead of GClosure, we both know that was not going to happen.

If the intent was to garner support for a fork of ClojureScript that targets
jQuery, the path that generally offers the best chance of success is to get
a working base or a proof of concept written by yourself, then use that to
start recruiting others to help.

If the intent was to be able to use jQuery with ClojureScript, you can
already do that.  This may help get you started:
https://gist.github.com/1096382

If the issue was that you have been trying to write something in
ClojureScript, but have been running into issues, or feel there is a better
way to do it that you may be missing, post the code you have and what your
desired outcome is, and I guarantee someone can offer advice.  There are
truly some geniuses in this list, and many extremely helpful people in
general.

In any case, I again apologize for any misunderstanding on my part, and
sincerely hope you give Clojure and ClojureScript a fair try.

 - Mark


On Mon, Jul 25, 2011 at 6:11 PM, James Keats wrote:

>
> 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)
>
> On Jul 25, 1:28 pm, Mark Rathwell  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.
> >
> > 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 
> wrote:
> > > 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

Re: Alright, fess up, who's unhappy with clojurescript?

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

On Jul 25, 1:28 pm, Mark Rathwell  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.
>
> 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  wrote:
> > 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 shoo

Re: Alright, fess up, who's unhappy with clojurescript?

[daly]

On Mon, 2011-07-25 at 09:59 -0700, nchurch wrote:
> +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


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Ken Wesson]

On Mon, Jul 25, 2011 at 1:23 PM, nchurch  wrote:
>> 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!
>
> I confess that I have erred and strayed from thy ways like a lost
> sheep

For penance you must make 3 more useful posts here today, and solve 3
Project Euler problems by midnight. ;)

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[nchurch]

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

I confess that I have erred and strayed from thy ways like a lost
sheep

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[pmbauer]

Fair point, but Rhino doesn't always have the correct semantics.

For example, one common JS idiom for default params:
eval("undefined || 2 + 2") => returns true instead of 4

But mostly, Rhino is just a JS engine with no DOM, so is less than ideal for 
browser UI development.
 

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Ken Wesson]

On Mon, Jul 25, 2011 at 12:59 PM, nchurch  wrote:
> +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 rememberwait.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! ;)

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Jack Moffitt]

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

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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[nchurch]

+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 (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 rememberwait.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  wrote:
> +1 - I think an etiquette document needs to be written.
>
> On 25 July 2011 15:10, Steve  wrote:
>
>
>
>
>
>
>
> > On Jul 25, 7:54 pm, James Keats  wrote:
>
> > > Best regards; love you, man, and sorry again for any misunderstanding
> > > or unintended miscommunication.
>
> > My humble suggestion is when you find yourself in your 5th or 6th
> > paragraph of an opinion piece there's a reasonable chance what you're
> > writing belongs on your blog rather than here.
>
> > - Steve
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Timothy Baldridge]

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

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Chouser]

On Sun, Jul 24, 2011 at 11:19 AM, James Keats  wrote:
>
> 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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Brenton]

James,

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

On Jul 25, 5:54 am, James Keats  wrote:
> 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  wrote:
>
> > On Jul 24, 11:19 am, James Keats  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 la

Re: Alright, fess up, who's unhappy with clojurescript?

[Colin Yates]

+1 - I think an etiquette document needs to be written.

On 25 July 2011 15:10, Steve  wrote:

> On Jul 25, 7:54 pm, James Keats  wrote:
> >
> > Best regards; love you, man, and sorry again for any misunderstanding
> > or unintended miscommunication.
> >
>
> My humble suggestion is when you find yourself in your 5th or 6th
> paragraph of an opinion piece there's a reasonable chance what you're
> writing belongs on your blog rather than here.
>
> - Steve
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Steve]

On Jul 25, 7:54 pm, James Keats  wrote:
>
> Best regards; love you, man, and sorry again for any misunderstanding
> or unintended miscommunication.
>

My humble suggestion is when you find yourself in your 5th or 6th
paragraph of an opinion piece there's a reasonable chance what you're
writing belongs on your blog rather than here.

- Steve

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Ken Wesson]

On Mon, Jul 25, 2011 at 8:28 AM, Mark Rathwell  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.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[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  wrote:

> 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!
>
> On 25 July 2011 08:38, Mark Derricutt  wrote:
>
>> 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.
>>
>>
>> On 25/07/2011, at 3:54 AM, Stuart Halloway wrote:
>>
>> Rhino is an implementation detail of the development platform. That
>> implementation detail could and probably should change.
>>
>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Cloju

Re: Alright, fess up, who's unhappy with clojurescript?

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[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


On Jul 25, 11:54 am, James Keats  wrote:
> 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  wrote:
>
> > On Jul 24, 11:19 am, James Keats  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
> > 

Re: Alright, fess up, who's unhappy with clojurescript?

[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  wrote:
> On Jul 24, 11:19 am, James Keats  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 arc

Re: Alright, fess up, who's unhappy with clojurescript?

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Ken Wesson]

On Mon, Jul 25, 2011 at 5:08 AM, Colin Yates  wrote:
> 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!

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

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

On 25 July 2011 08:38, Mark Derricutt  wrote:

> 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.
>
>
> On 25/07/2011, at 3:54 AM, Stuart Halloway wrote:
>
> Rhino is an implementation detail of the development platform. That
> implementation detail could and probably should change.
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

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

On 25/07/2011, at 3:54 AM, Stuart Halloway wrote:

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[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

On 25 Juli, 00:34, James Keats  wrote:
> 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.
>
> On Jul 24, 10:28 pm, Rich Hickey  wrote:
>
>
>
>
>
>
>
> > On Jul 24, 11:19 am, James Keats  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
> > r

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 10:23 pm, Base  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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

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


On Jul 24, 10:28 pm, Rich Hickey  wrote:
> On Jul 24, 11:19 am, James Keats  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.

-- 
You received this message because you are subscribed to the G

Re: Alright, fess up, who's unhappy with clojurescript?

[Charlie Griefer]

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Rich Hickey]

On Jul 24, 11:19 am, James Keats  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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[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  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
>
> On Sun, Jul 24, 2011 at 1:25 PM, James Keats wrote:
>
>
>
>
>
>
>
>
>
> > On Jul 24, 5:02 pm, Mark Rathwell  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:
> > > ---
>
> > > 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.
>
> > On Jul 24, 5:02 pm, Mark Rathwell  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 

Re: Alright, fess up, who's unhappy with clojurescript?

[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


On Sun, Jul 24, 2011 at 1:25 PM, James Keats wrote:

>
>
> On Jul 24, 5:02 pm, Mark Rathwell  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:
> > ---
> >
> > 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.
> >
>
> On Jul 24, 5:02 pm, Mark Rathwell  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 

Re: Alright, fess up, who's unhappy with clojurescript?

[Sean Corfield]

On Sun, Jul 24, 2011 at 11:11 AM, James Keats  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)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Michael Gardner]

On Jul 24, 2011, at 2:08 PM, James Keats wrote:

> On Jul 24, 7:24 pm, Michael Gardner  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!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 7:24 pm, Michael Gardner  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/

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 7:05 pm, David Nolen  wrote:
> On Sun, Jul 24, 2011 at 1:46 PM, James Keats 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

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[David Nolen]

On Sun, Jul 24, 2011 at 1:46 PM, James Keats 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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 6:03 pm, David Nolen  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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 5:02 pm, Mark Rathwell  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:
> ---
>
> 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.
>

On Jul 24, 5:02 pm, Mark Rathwell  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 wrote:
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Frank Gerhardt]

On Sun, Jul 24, 2011 at 7:03 PM, David Nolen  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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[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 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?
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[Mark Rathwell]

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

 - Mark

On Sun, Jul 24, 2011 at 12:08 PM, Baishampayan Ghose wrote:

> Sorry for the digression, but what about YUI 3?
>
> Regards,
> BG
>
> ---
> Sent from phone. Please excuse brevity.
> On Jul 24, 2011 9:32 PM, "Mark Rathwell"  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:
> > ---
> >
> > 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
> >
> >
> > On Sun, Jul 24, 2011 at 11: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?
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >
> > --
> > You recei

Re: Alright, fess up, who's unhappy with clojurescript?

[Baishampayan Ghose]

Sorry for the digression, but what about YUI 3?

Regards,
BG

---
Sent from phone. Please excuse brevity.
On Jul 24, 2011 9:32 PM, "Mark Rathwell"  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:
> ---
>
> 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
>
>
> On Sun, Jul 24, 2011 at 11: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?
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/

Re: Alright, fess up, who's unhappy with clojurescript?

[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


On Sun, Jul 24, 2011 at 11: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?
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[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

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Alright, fess up, who's unhappy with clojurescript?

[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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

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?


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en