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 <james.w.ke...@gmail.com> 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 <richhic...@gmail.com> wrote: > > > On Jul 24, 11:19 am, James Keats <james.w.ke...@gmail.com> wrote: > > > > Alright, to be honest, I'm disappointed. > > > I'll make sure you get a refund then. > > > Seriously, this is like being disappointed an action movie was an > > action movie instead of a comedy. Your expectations are a complete > > mismatch for the intentions of ClojureScript. > > "clojure's rocks... javascript reaches" > > > > > > First of all, congrats and good job to all involved in putting it out. > > > On the plus side, it's a good way to use the Google Closure javascript > > > platform. > > > > On the minus, imho, that's what's wrong with it. > > > > Google Closure is too Java. > > > Actually, it's too JavaScript. Some JS proponents want to disavow its > > pseudo class model, but it certainly is part of the design of > > JavaScript. And it has some particular advantages over the other > > strategies, as outlined here: > > >http://bolinfest.com/javascript/inheritance.php > > Rich, the "pseudo class model" with the new keyword is a syntactic > obfuscation, semantically javascript is prototypical inheritance. It's > class free. In addition to the pseudo class inheritance advocated by > google closure and the prototypical inherent in javascript, others > like Doug Crockford advocated functional inheritance. > > Now I have watched and read enough of your output and for example > Stuart Holloways talk about protocols to know that you've railed in > your adovacy of clojure against classes and inheritance, and find it > ironic that now you posit a link by an advocate of it citing it as > advantageous. In any case, as I've mentioned, I have been aware of > this article for nearly a year now, it failed to convince me back then > and it still does; most of the arguments in it concern the closure > compiler, an obeisance to which by the regular developer who doesn't > have the needs and resources of google, I feel in this day and age of > ample memory and bandwidth and fast javascript engines, is premature > optimization gone berserk (seriously, folks, people are streaming HD > video, 1.5 gbps fiber optic broadband is being rolled out in London > and soon other cities worldwide and 4G mobiles are upon and we're > fretting over mere tens of KB that gets cached after first time and > basing our development around minimizing it?!), and the remainder of > the arguments are in support of classes and inheritance. > > > > > > It's not idiomatic JavaScript. > > > There's no such thing as idiomatic JavaScript. There are a lot of > > different conventions used by different libraries. > > The Javascript community - the vast majority of which - after a decade > and a half now of experience with the language has come to regard some > aspect of it as good and others as problematic; things like functional > programming and object literals (akin to clojure's maps/structs/ > records) vs classical inheritance, which are positions you yourself > have taken and advocated. > > > > I find it > > > disappointing that rather than porting from a functional language like > > > Clojure straight to another functional language like Javascript, the > > > google closure with its ugly Java-isms is right there obnoxiously in > > > the middle. > > > In the middle of what? I look at ClojureScript code and it looks like > > Clojure to me. Google Closure is under, and it is no more annoying > > there than Java is under Clojure - an implementation detail, and a > > rich source of production-quality code. > > I respectfully dispute that; for what they both do - dom, css, ajax, > events, cookies, ui, effects, animations etc - jquery does it far > better and is much more pleasant an api. What jquery itself doesn't do > the huge ecosphere of libs around it do, for > example:http://metajack.im/2009/03/13/jquery-and-strophe-made-for-each-other/http://strophe.im/ > > > > > > Then, there's the elephant in the room, and that elephant is Jquery. I > > > believe any targetting-javascript tool that misses out on jquery-first- > > > and-foremost is missing out on the realities of javascript in 2011. > > > Should it be the purpose of a new language like ClojureScript to > > orient itself around the realities of currently popular JavaScript > > libraries? I think not. > > If you want jQuery as the center of your > > universe, JavasScript is your language - good luck with it. I see > > jQuery as a tool to be leveraged when appropriate (i.e. rarely in > > large programs), not an architectural centerpiece. > > As opposed to orienting itself around the realities of a currently > unpopular one? This is exactly what clojurescript does! it orients > itself around the realities of google closure and its compiler. It's > not only currently unpopular, it's never been popular, and in all > likelihood never will be. > > http://www.google.com/trends?q=%22google+closure%22(that lone > vertical line you see was its announcement, let's not do a comparative > google trends for "google closure, jquery", or even google's gwt) > > > > > > Jquery is huge in its community and plugins, and it has tons of books > > > and tutorials. > > > So what? Those people are satisfied by, and not leaving, JavaScript, > > and I'm fine with that. > > The point is "reach", Rich; things like this: > > http://jquerymobile.com/ > > > > > > > > > > > > Then, the Google Closure compiler is a moot point. > > > If you seriously cannot see the benefits of Google's compiler then you > > are not the target audience for ClojureScript. In any case, for those > > interested there is an argument for Google's approach in the > > rationale, as well as this page on the wiki: > > >https://github.com/clojure/clojurescript/wiki/Google-Closure > > > > I'm tempted to "fork" clojurescript and redo it in javascript perhaps > > > so that seamless interop with jquery would be the main priority. > > > Is that a threat, or a promise? I suggest you start by writing up a > > rationale like this one: > > >https://github.com/clojure/clojurescript/wiki/Rationale > > > making your intentions and the superiority of your approach clear. > > Then prepare yourself for messages from people who don't bother to > > read or understand it. > > I did read it though. In any case, the suggested "fork" was for lack > of a better term, as github's "fork me" slogan goes; I won't now so as > not to seem like I'm here to steal your thunder. Clojure on Java, from > what I've read and watched of yours, was not your first attempt at a > lisp targeting java. It took a few attempts to get it right. We're all > human, you're not an emacs whiz and nor am i, though I do absolutely > believe you're a man of brilliance and I fully admire you. I'm merely > voicing my humble and sincere opinion based purely on technical points > that this first attempt at targeting javascript needs reconsidering. > > Best regards; love you, man, and sorry again for any misunderstanding > or unintended miscommunication. > > > > > > > > > > > Messages like yours make creating things and releasing them for free a > > really exhausting endeavor. > > > Good luck with your fork - please start a separate mailing list for > > discussions about it. > > > Rich > > > p.s. note to others - if you have read the docs and have honest > > questions about the approach, I and others would be happy to explain. > > But we could do without messages about disappointment, threats of > > forks etc. ClojureScript is an action movie, and we're interested in > > helping people kick butt.Describe your new note here. -- 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
