Re: novel feedback is always welcome
As an outcome of this thread, I have decided not to invest in clojure, so I believe the following to be purely feedback, as I have no agenda to push. - it seems from some's point of view that I was trolling. Fine, from my point of view though it was akin to drink the kool aid or gtfo. Sorry, I'm too old and too well-read and too inquisitive to drink the kool aid, so I'll just gtfo. - I'm not sure what you mean by not up to speed. I had the book about the google closure library for nearly a year now and I'd read it a few times. I'd gotten copies of all the clojure books published and downloaded all the videos put out and read/watched them several times. I'd scoured the web - and this group - for every clojure related reading material I could find, and watched the clojurescript video a couple of times very carefully and read its rationale a few times. - I'm not sure what you mean by recovering old ground. When I made the post (24th of July) Clojurescript had only been out for a few days, most notably it was 2 days after Video is now available of Rich Hickey's talk at ClojureNYC yesterday announcing clojurescript (22nd of July). - I'd understand what you might've meant by the above two points if you guys had no intentions for anyone outside a very small tightknit group of you to use clojurescript, but if you'd intended others besides you to use it too then no, I don't. - I'm also not sure what you mean by He did not understand the difference between language and platform, and from there was at a loss to understand our decision-making. I believe my original post and thereafter and throughout were clear enough that my concern was not the clojure language itself, but the google closure library as a dependency. - the argument - paraphrasing - it's just clojure, you code in clojure, the google library is under, and you don't need to look under is akin to saying here's a foundation for you to build a skyscraper on, now build your skyscraper, don't look under at what's in the foundation you're building on. Sorry, can't do. - the notion that the leader decides all unquestioned and that no disappointment or unhappiness will be tolerated is too stalinist for my taste. Regards and best wishes. On Jul 31, 3:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: (I have take the liberty of changing the subject line, which may be less than ideal for some people's reading style.) -- 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: novel feedback is always welcome
As an outcome of this thread, I have decided not to invest in clojure, so I believe the following to be purely feedback, as I have no agenda to push. - it seems from some's point of view that I was trolling. Fine, from my point of view though it was akin to drink the kool aid or gtfo. Sorry, I'm too old and too well-read and too inquisitive to drink the kool aid, so I'll just gtfo. - I'm not sure what you mean by not up to speed. I had the book about the google closure library for nearly a year now and I'd read it a few times. I'd gotten copies of all the clojure books published and downloaded all the videos put out and read/watched them several times. I'd scoured the web - and this group - for every clojure related reading material I could find, and watched the clojurescript video a couple of times very carefully and read its rationale a few times. - I'm not sure what you mean by recovering old ground. When I made the post (24th of July) Clojurescript had only been out for a few days, most notably it was 2 days after Video is now available of Rich Hickey's talk at ClojureNYC yesterday announcing clojurescript (22nd of July). - I'd understand what you might've meant by the above two points if you guys had no intentions for anyone outside a very small tightknit group of you to use clojurescript, but if you'd intended others besides you to use it too then no, I don't. - I'm also not sure what you mean by He did not understand the difference between language and platform, and from there was at a loss to understand our decision-making. I believe my original post and thereafter and throughout were clear enough that my concern was not the clojure language itself, but the google closure library as a dependency. - the argument - paraphrasing - it's just clojure, you code in clojure, the google library is under, and you don't need to look under is akin to saying here's a foundation for you to build a skyscraper on, now build your skyscraper, don't look under at what's in the foundation you're building on. Sorry, can't do. - the notion that the leader decides all unquestioned and that no diappointment or unhappiness will be tolerated is too stalinist for my taste. It is my belief that the hallmark of good open source software is its attitude towards intense and thorough scrutiny. Regards and best wishes. On Jul 31, 3:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: (I have take the liberty of changing the subject line, which may be less than ideal for some people's reading style.) -- 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?
On Jul 26, 1:53 am, Christian Marks 9fv...@gmail.com wrote: On Jul 25, 6:11 pm, James Keats james.w.ke...@gmail.com wrote: I ask, what is it that I did other than seriously inquire about the rationale?! You started a thread with the non-serious title, Alright, fess up, whose unhappy with clojurescript? instead of the more serious Comments on the clojurescript rationale. Having done that, you could have addressed the rationale. 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?
On Jul 26, 2:01 pm, semperos daniel.l.grego...@gmail.com wrote: Based on the majority of posts in this thread, I think you can see you're in the minority, both with regards to your opinions of ClojureScript and with regards to how this community should behave. Here's one more person who doesn't appreciate the attitude your posts embody. Rich, and everyone else on this list and everyone on this list http://clojure.org/contributing 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?
On Jul 26, 3:08 pm, Timothy Baldridge tbaldri...@gmail.com wrote: Hi Timothy, and thanks for your much-better-than-others' reply. Oh I will be washing my hands and be gone for sure, as coding and making things better is precisely what I offered in my OP, which was taken as a threat and I was told to start a separate mailing list for it; perhaps this community welcomes folks who don't know any better than to be invariably effusive for everything in it, but for those who do it it quite evidently has not been. But I think you need to understand what exactly it is that you are asking of Rich and the other ClojureScript devs whith your original comment. Rich's comment is not abnormal for the type of request you are making. I have seen his type of reply before. 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?
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
Re: Alright, fess up, who's unhappy with clojurescript?
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 mark.rathw...@gmail.com wrote: Colin, I don't think anyone responding was doing so with the mindset of my way or the highway and we must defend the great leader's achievements. Speaking for myself, I responded to an argument that did not make sense, that argument being basically: Crockford says javascript can be written a certain way, jQuery generally follows this pattern and it is popular, Google Closure does not follow this pattern in some ways and is not as popular, therefore it should not be used for ClojureScript. Nobody is shooting down I love it type posts because they do come off as intentionally inflammatory. The titles of these posts seem aimed to incite controversy and ruffle feathers (as does the content), rather than seriously inquire about the rationale. And the arguments are generally recaps of articles that agree with the author, rather than actual pain points hit when trying to create something with Clojure or ClojureScript. The responses throwing troll around are the attempt of the community to point out that this list's main purpose is to help people, not for inflammatory content that belongs in blog posts. As for responding with OK, this guy clearly doesn't get it - how can we improve our communication, this goes back to the intent of the author. I don't think the intent was to get anything, I think the intent was to incite. The best response to this is to ignore it, and that is what I should have done, but it is easier to say than to do. - Mark On Mon, Jul 25, 2011 at 5:08 AM, Colin Yates colin.ya...@gmail.com 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
Alright, fess up, who's unhappy with clojurescript?
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?
On Jul 24, 5:02 pm, Mark Rathwell mark.rathw...@gmail.com wrote: Wasn't it just a couple weeks ago that you were arguing that everything should be more like Java? Now you're arguing that Google Closure is bad because it has some similarities to Java development (mainly verbosity and documentation). I'm honestly not sure if you are just trying to be controversial, or to appear smart, but I'll bite (time for a break anyways). Closure is not idomatic javascript: --- 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 mark.rathw...@gmail.com wrote: Wasn't it just a couple weeks ago that you were arguing that everything should be more like Java? Now you're arguing that Google Closure is bad because it has some similarities to Java development (mainly verbosity and documentation). I'm honestly not sure if you are just trying to be controversial, or to appear smart, but I'll bite (time for a break anyways). Closure is not idomatic javascript: --- I'm not arguing that everything should be more like Java, but rather, if you're targetting the JVM then Java, if you're targetting javascript then javascript. I'm aware of the article you pointed out, but no, that article is mostly about the implementation details within closure, which is a lesser concern to me. I think a good book about idiomatic javascript would probably be Douglass Crockford's Javascript: the Good Parts, and just as good if not even better is JavaScript Patterns by Stoyan Stefanov; emphasis on a functional programming small subset of javascript, using closures and prototypes, et cetera. I had been aware of the Google Closure library through its book, which I read when it first came out; I invite you to read this book. It's too Java-esque; java-inspired annotations, java-inspired OOP, too much complexity and ceremony, and the author pointedly dismisses much of the javascript community idioms: http://bolinfest.com/javascript/inheritance.php I think it's a bit absurd, folks, to criticize Java's OOP as incidental complexity, too much ceremony, and even suggest in the Joy of Clojure that a Steve Yegge's Universal Design Pattern and prototype pattern a la Javascript could be married to clojure's in the chapter that discuss namespaces, multimethods, protocols and datatypes, and then turn around and implicitly declare to the world with the release of clojurescript oh noes! if we're gonna do anything substantial then this doesn't scale! we need a Java like solution! [1]http://www.sitepoint.com/google-closure-how-not-to-write-javascript/ - Mark On Sun, Jul 24, 2011 at 11:19 AM, James Keats james.w.ke...@gmail.comwrote: -- 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?
On Jul 24, 6:03 pm, David Nolen dnolen.li...@gmail.com wrote: As a professional JavaScripter for the past 6 years who has built his own frameworks and written considerable amounts of Prototype, MooTools, and jQuery. I don't think jQuery is special or particularly interesting and most of the libraries around it are terrible IMO. It certainly doesn't help in building sophisticated clientside applications (if it did, why Backbone.js, why Cappuccino, why SproutCore?, etc). For simple stuff it's fine. But then so is Google Closure. I think the Clojure community can do much, much better. In fact a clientside framework could be the first Clojure killer app ... David I was hoping that clojure itself would help jquery build sophisticated applications, by bringing proper functional programming to the clientside, rather than bringing Java's OOP in the form of gClosure. The Javascript notaries have advocated using a small functional subset of javascript, rather than the full gamut of javscript's quirks, and I was saddened while watching the Rich Hickey talk when he said that clojurescript would abstract away the complex conventions and discipline required when writing apps for gClosure by producing code ready for its optimizing compiler, when it could've simply enforced that small functional subset of javascript itself (sans gClosure) that's now considered idiomatic best practice. -- 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?
On Jul 24, 7:05 pm, David Nolen dnolen.li...@gmail.com wrote: On Sun, Jul 24, 2011 at 1:46 PM, James Keats james.w.ke...@gmail.comwrote: 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?
On Jul 24, 7:24 pm, Michael Gardner gardne...@gmail.com wrote: On Jul 24, 2011, at 1:11 PM, James Keats wrote: Restricting yourself to a functional subset of JavaScript can't fix JavaScript. The functional subset stinks, Javascript notaries be damned. If so where does this leave clojure itself and its advocacy of functional programming, then; see last paragraph of my reply to Mark. You can't draw any inference along those lines from David's observation. I'm not drawing an inference, but an argument. The functional parts of Javascript are far different from those of Clojure (and not in a good way). How so? javasript, while not as functional as clojure, is far more functional than java ( first class functions, closures, anonymous functions etc. A small subset of clojure would mirror and could expand on a small subset of javascript); it's been called a Lisp in C's Clothing, and Brendan Eich famously and repeatedly said As I’ve often said, and as others at Netscape can confirm, I was recruited to Netscape with the promise of “doing Scheme” in the browser Back at Netscape doing a scheme in the browser was botched a bit by a deal with Sun and the diktat from upper engineering management was that the language must “look like Java”.[1], and whereas clojure/ clojurescript now had an opportunity to correct that, instead it's piling on the Java-ism with gClosure. [1] http://brendaneich.com/tag/history/ -- 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?
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 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. 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
Re: Alright, fess up, who's unhappy with clojurescript?
On Jul 24, 10:23 pm, Base basselh...@gmail.com wrote: Why should we care what kind of Javascript ClojureScript generates, as long as it's correct and performant? The whole point of the project is to allow us to write Clojure rather than Javascript! James, you do get this point, right? Just like GWT allows you to program in Java to write JavaScript, and get the 'benefits' of not having to actually write JS to develop web clients, ClojureScript allows you to program in Clojure to write JavaScript that CloSure likes. If you like programming in Clojure than you *should* appreciate this point. If you don't, than it seems to me that you are just picking a fight to pick a fight. I'm certainly not just picking a fight, I'm honestly voicing a concern. I believe you still need to learn and know and understand and be mindful of gclojure to use clojurescript. Furthermore, gClosure is low level in what it offers, you'd have to roll your own for much of what you could reuse elsewhere, and google acknowledges this in its docs: What is the relation between the Closure Library and other JavaScript libraries? Many JavaScript libraries emphasize the ability to easily add JavaScript effects and features with minimal development time. Google engineers use these third-party tools for precisely the reason that the libraries are powerful for rapid development. The Closure Library is designed for use in very large JavaScript applications. It has a rich API and provides tools for working with the browser at a lower level. It's not well suited for all tasks, but we think it provides a useful option for web developers. Outside of google the closure library hasn't had much uptake and it's not part of the burgeoning javascript scene. I just feel it's ironic that on the JVM the idea is that the best practices of java that are conducive to very large application development are considered too painful for everyday development and therefore the reason d'etre of clojure, but when it comes to javascript then it's the very large apps that we'll gear up for and put up with the consequent everyday pain. It's also ironic that with clojure on the JVM we'd think that things like transaction software memory are worthwhile compromises performance-wise, but towards javascript then a slavish obiedience to the google closure compiler - which predates JITed javascript VMs, and predates the closure library which was modeled with it in mind - is prioritized over the development experience or a burgeoning platform of libs. Anyhow, not wishing to be further misunderstood, I regret any miscommunication and offer everyone my kindest regards. -- 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
monads macros
I'm mildly concerned about macros being seen as the secret weapon of clojure(/lisp). In their place, i wish monads would get a wider attention and embrace. 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: Modelling complex data structures (graphs and trees for example)
and most elegant solution with new tools. I probably ate something that disagreed with me, but I just want to break free from the shackles of these heavy-weight tools and fly! OK - that's enough. Or, it might all be a catastrophic failure and I will be signing up to Careers 2.0 :) Col P.S Usual disclaimer - still only written three lines of Clojure :) On 8 July 2011 20:57, James Keats james.w.ke...@gmail.com wrote: On Jun 16, 3:08 pm, Colin Yates colin.ya...@gmail.com wrote: (newbie warning) Our current solution is an OO implementation in Groovy and Java. We have a (mutable) Project which has a DAG (directed acyclic graph). This is stored as a set of nodes and edges. There are multiple implementations of nodes (which may themselves be Projects). There are also multiple implementations of edges. My question isn't how to do this in a functional paradigm, my first question is *how do I learn* to do this in a functional paradigm. I want to be able to get the answer myself ;). To that end, are there any domain driven design with functional programming type resources? A more specific question is how do I model a graph? These graphs can be quite extensive, with mutations on the individual nodes as well as the structure (i.e. adding or removing branches). Does this mean that every every node would be a ref? I think the general answer is that the aggregate roots are refs, meaning they are an atomic block, but is there any more guidance? May I humbly suggest that this ought to be a database-ish concern rather than a middleware one? have you looked at neo4j for example? A quick google found this: http://wiki.neo4j.org/content/Roles This is an implementation of an example found in the article A Model to Represent Directed Acyclic Graphs (DAG) on SQL Databases by Kemal Erdogan. ... In Neo4j storing the roles is trivial, as working with graphs is what Neo4j was designed for I would humbly suggest that you use as much of the database functionality as possible for your data needs and avoid replicating it in your middleware. I hope this works. :-) -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 8, 6:19 am, Ken Wesson kwess...@gmail.com wrote: On Fri, Jul 8, 2011 at 1:07 AM, Lee Spector lspec...@hampshire.edu wrote: On Jul 7, 2011, at 7:29 PM, Sean Corfield wrote: And yet the #1 FAQ we see on lists and reflected in blog posts is about getting Clojure up and running... We see Java developers, committed to their favorite IDE, still asking Should I install / learn Emacs? We see old-time Lispers, happy with Emacs, struggle with the Java infrastructure. A lot of n00bs want to be told the One True Way to set up their development environment - they don't want to be confronted with choices. Like you, I don't entirely understand why this is an issue - but I accept that it clearly _is_ an issue... For me at least the issue isn't that there should be a single blessed setup, but rather that there should be at least one setup (and documentation for that setup) that's a little more newbie-friendly than any of them currently are. How about: GETTING STARTED If you're coming from a Lisp background, or at least are familiar with emacs _here is how to set up with emacs and leiningen_. If you're coming from a Java background, _download Eclipse and CCW_ or _download NetBeans and Enclojure_. If your programming experience lies elsewhere, or you're new to programming altogether, _insert something here_. The last one is maybe the trickiest May I also add the following caveat emptors: - If you're new to programming, clojure will overwhelm you. Start with something like python. - If you come from python/ruby and have no java background, do not expect to start hacking clojure in the morning and be productive and accomplishing work in the afternoon of that same day; go learn java for a while first (a few months at least). Also, continue using whatever it is you use now till you're confident you know enough to jump ship. - we can't teach you java, please go learn java for a while if you have no java experience, there are tons and tons of tutorials and books on teaching you java. - if all you need is a hello world program, there are simpler languages for this purpose (python etc). Consider clojure if you have need for java apis or concurrency needs (concurrency is an advanced, low level topic and not something most programmers should concern themselves with). - and so on... I think it's important to have such caveat emptors, it seems many of the complaints relate to expectations mismatched to reality Regards J -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 8, 4:30 pm, Lee Spector lspec...@hampshire.edu wrote: On Jul 8, 2011, at 10:29 AM, James Keats wrote: May I also add the following caveat emptors: - If you're new to programming, clojure will overwhelm you. Start with something like python. I disagree. This is a subject of religious debates that I don't want to get into in detail, but FWIW this educator thinks that Lisp is a perfectly defensible first language and that Clojure can serve the purpose quite well as long as installation and tooling doesn't make it unnecessarily difficult to write and run code. - If you come from python/ruby and have no java background, do not expect to start hacking clojure in the morning and be productive and accomplishing work in the afternoon of that same day; go learn java for a while first (a few months at least). Also, continue using whatever it is you use now till you're confident you know enough to jump ship. - we can't teach you java, please go learn java for a while if you have no java experience, there are tons and tons of tutorials and books on teaching you java. Disagree and disagree. One can do a lot in Clojure with almost no knowledge of the Java language or the Java ecosystem. At least for the kinds of things that I do. Yes, I occasionally need to use an interop form for something for which there's no Clojure version, but for me that's rare and easy to pick up on a case by case basis without being a Java programmer. - if all you need is a hello world program, there are simpler languages for this purpose (python etc). Consider clojure if you have need for java apis or concurrency needs (concurrency is an advanced, low level topic and not something most programmers should concern themselves with). Disagree. Nobody *just* wants to write hello world, of course, but Clojure can be a great language for many people who have zero need for Java APIs or concurrency. I use/teach it because of all of the great features of Lisps more generally, and because Clojure is the best Lisp going (IMHO). - and so on... I think it's important to have such caveat emptors, it seems many of the complaints relate to expectations mismatched to reality Maybe, but since I disagree with every one of your caveats I wouldn't advocate making them :-0. -Lee Teaching is a strictly controlled and supervised environment. I wouldn't mind teaching a lisp curriculum based on clojure that wouldn't veer from the set path, and which test of learning are a set of specific and circumscribed exercises. For people who come to learn clojure though from the internet, they tend to be people who self- teach, and who'll actually want to use it to do actual work. I am skeptical about its ease for those. Either that, or all those experienced programmers who still struggle with it despite their long experience (I included) are just a bunch of pansies. -- 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: Emacs and clojure for newbies
On Jul 8, 7:14 pm, nchubrich nchubr...@gmail.com wrote: I disagree. This is a subject of religious debates that I don't want to get into in detail, but FWIW this educator thinks that Lisp is a perfectly defensible first language and that Clojure can serve the purpose quite well as long as installation and tooling doesn't make it unnecessarily difficult to write and run code. +1 for all your points here, Lee. Scheme has often used as a first language, and it works great. It's better to teach people the right way first, and the right way is Lisp Oh I have no problem with scheme. Scheme was my introduction to programming, and itself is a teaching language. I also have no problem with *teaching* clojure, with a clear supervised curriculum. My concern is if people are going to self-teach and expect to be able to do work soon, they shouldn't be led to believe that learning clojure and java too all at once is easy. I still believe that python would be more suitable (though *not* jython, the java version of python), and I note that MIT, famous for for SICP scheme course, now teaches python instead of scheme. -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 8, 8:02 pm, Lee Spector lspec...@hampshire.edu wrote: I'm with you 95% here, but I do think that this much editor fanciness is needed to have a sane environment for coding lisp for anything more than a few minutes: bracket-matching and language-aware auto-re-indenting. If there's a straightforward way to get this along with the rest of your setup then I agree that this would be an excellent entry path for newcomers. -Lee Sam Aaron's emacs setup with cake's swank is really really nice. It could possibly be combined with a cheatsheet for emacs' most needed keyboard shortcuts. May I also add that I found remapping some keyboard keys quite useful for a sane emacs lisp editing experience. It gives me 3 ctrl keys on the right and 3 ctrl keys on the left so I could basically use any of my fingers, pinky to thumb, for that often needed key (I've also remapped the meta/alt key to one that's tactilely distinguishable - 6 ctrl may seem a bit overboard but i prefer it this way). Remapping the parens too is possibly a good thing so they'd not require a shift and won't be a rather tiresome fourth keyboard row pinky affair, I've done it, but I haven't yet settled on where to put them. I'm not sure this remapping is needed for newbies, perhaps, perhaps not, depending on how annoying emacs finger acrobatics seem to them, but for the heavy duty use I'd probably recommend it. -- 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: Modelling complex data structures (graphs and trees for example)
On Jun 16, 3:08 pm, Colin Yates colin.ya...@gmail.com wrote: (newbie warning) Our current solution is an OO implementation in Groovy and Java. We have a (mutable) Project which has a DAG (directed acyclic graph). This is stored as a set of nodes and edges. There are multiple implementations of nodes (which may themselves be Projects). There are also multiple implementations of edges. My question isn't how to do this in a functional paradigm, my first question is *how do I learn* to do this in a functional paradigm. I want to be able to get the answer myself ;). To that end, are there any domain driven design with functional programming type resources? A more specific question is how do I model a graph? These graphs can be quite extensive, with mutations on the individual nodes as well as the structure (i.e. adding or removing branches). Does this mean that every every node would be a ref? I think the general answer is that the aggregate roots are refs, meaning they are an atomic block, but is there any more guidance? May I humbly suggest that this ought to be a database-ish concern rather than a middleware one? have you looked at neo4j for example? A quick google found this: http://wiki.neo4j.org/content/Roles This is an implementation of an example found in the article A Model to Represent Directed Acyclic Graphs (DAG) on SQL Databases by Kemal Erdogan. ... In Neo4j storing the roles is trivial, as working with graphs is what Neo4j was designed for I would humbly suggest that you use as much of the database functionality as possible for your data needs and avoid replicating it in your middleware. I hope this works. :-) -- 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: Modelling complex data structures (graphs and trees for example)
On Jul 8, 8:57 pm, James Keats james.w.ke...@gmail.com wrote: On Jun 16, 3:08 pm, Colin Yates colin.ya...@gmail.com wrote: (newbie warning) Our current solution is an OO implementation in Groovy and Java. We have a (mutable) Project which has a DAG (directed acyclic graph). This is stored as a set of nodes and edges. There are multiple implementations of nodes (which may themselves be Projects). There are also multiple implementations of edges. My question isn't how to do this in a functional paradigm, my first question is *how do I learn* to do this in a functional paradigm. I want to be able to get the answer myself ;). To that end, are there any domain driven design with functional programming type resources? A more specific question is how do I model a graph? These graphs can be quite extensive, with mutations on the individual nodes as well as the structure (i.e. adding or removing branches). Does this mean that every every node would be a ref? I think the general answer is that the aggregate roots are refs, meaning they are an atomic block, but is there any more guidance? I just noticed that you wanted to *learn to do it yourself. Sorry, I apologize if my reply misread your query. 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: Please stand firm against Steve Yegge's yes language push
On Jul 7, 6:42 am, nchubrich nchubr...@gmail.com wrote: I'll try :) It was really a polemical post for a polemical thread, but my main points can be extracted here. Feel free to read as many or as few of them as you are inclined nchubrich, I've read your original post in its entirely, so forgive me for not having the time to read your points of summary. To be clear, I do *not* reflect in any way on the clojure community. As has been pointed out, I've only been around this group for ~3 weeks. Given though that I've only been around for ~3 weeks, it irked me to no measure that I saw things in those Steve Yegge's posts in that thread (here and on hackernews) that could've only indicated that had he only bothered to read what books had been published and what screencasts had been put out and what interviews and posts Rich Hickey and others had made he would've come to an understanding of the technical reasons why things with the core language are the way they are - I did - and had answers to his complaints and wouldn't have had to rant about them. Yup, it irked me that - evidently - he didn't even bother to learn the language properly and instead ranted vehemently against things right to its core (compiler etc), demanding they change. Those videos that Rich Hickey put out on blip.tv are outstanding. The guy is a natural teacher, technically brilliant and a joy to listen to. I think humility should go both ways. People should be humble enough to realize that no matter how smart they are that they always have to be willing and eager to learn. Yes, sorry, it's a fact of this trade that you should always be willing and eager to learn, and not a particular situation to this language community. You can never get too smart for these shifting sands of industry. Sorry, there's no excuse here. With regard to emacs, I've pointed out that I wasn't a fan and that I regarded it as too tinkerish for my taste, especially so in a thread in which I invited others to convince me to use it instead of netbeans. In any case, if you do want to use emacs and wish for an out of the box good user experience, then you may wish to have a look at this post by Sam Aaron in this group. I found it very useful and I must admit it made me play with emacs a bit. There really is nothing much to emacs, just knowing the shortcut keystrokes and doing them until they become finger/muscle memory: http://groups.google.com/group/clojure/browse_thread/thread/c3c4febb5b0f0208 Again, to be clear, and I believe I pointed this out in my original post, I was *not* against the language growing in terms of users. I've emphasized that what I was against was that being seen as more important a goal than having a technically sound language. I could reply to more of your points, but not wishing this post to get too long, I'll stop 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: Please stand firm against Steve Yegge's yes language push
On Jul 7, 8:09 am, nchubrich nchubr...@gmail.com wrote (As for Steve Yeggeis he reading all this?if he's totally wrong, then of course people should feel free to disagree with him, and forget about the consequences. But if he happens to be \right, and I do think he mostly is, then making basically dismissive firm stands against him is not going to do anybody any good. This isn't a political party, thank God.) I agree it isn't a political party, but it isn't a social club either. It's a technical forum. Technical soundness, rather than social expansion, should, imho, be the utmost concern. :-) I empathize with your point regarding how hard it is to deal with Java. Unfortunately, it is. But I believe it has to be done. Python is no better in that regard; you still need to understand Unix/C otherwise you'd be too limited and lost too soon. The other issues you cited are tangential to the programming language itself, they are issues of IDE, build system, documentation, etc etc. They do not affect my original post argument for the language core to be conservative and technically sound, Python's is. :-) -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 7, 8:03 pm, logan duskli...@gmail.com wrote: This poisonous attitude is perfectly exemplified in this thread by James Keats. I completely disagree with your mis-characterization and invite you to read again what I had maintained: - I had implored that technical arguments alone should decide technical issues, not who's who. - I made clear that I had asked dumb questions, and that I don't consider myself too smart to read what'd been put out already. I made a clear distinction between a newbie who'd ask dumb questions (and explicitly included myself in that category), and a who's who from elsewhere demanding major changes outright. - If this is going to turn into a who's against whom (I made it clear time and again I wasn't against Steve Yegge personally but against his yes language *features* push, had it come from a Mr firstName lastName I would've still voiced the same technical concern and titled it accordingly), I regret that I do not have the time for that. Regards. J -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 7, 8:35 pm, nchubrich nchubr...@gmail.com wrote someone whose name I can't remember right now once said, There are no bad students, only bad teachers. There are three good books already and more on the way (I look forward to Clojure in Action later this month), there are excellent videos on blip.tv (Rich Hickey's are some of the best programming talks I've ever seen), there are tons and tons and tons of books on Java, and there's ample, ample lisp literature. I don't buy the user-friendliness argument or bad teachers. This is a technical trade, not an end user application for grampa. What's more, people are not in the business of education; they're gracious enough to share their code. I also don't understand why people are in such a rush to get hacking clojure code right away; Peter Norvig has argued that it takes a long time to learn to program, and I would suggest to anyone considering a new language to learn to allow themselves an adequate amount of time well ahead to do the homework required. I think for those who come to clojure having had some Java experience, some lisp experience, some functional programming experience o the ML/Haskell family, then the language is actually such a leap in simplification. For people's sense of sanity, it's not wise to try to run before you walk. Am I being a blowhard by saying this?! I don't believe so, this is a reality. I have expressed an opinion that clojure is for the advanced programmer (Java/lisp/ML-Haskell), and there are perhaps some simpler language (eg. python, which is quite capable and I'm actually quite fond of). But fine, people are free to be impatient and get frustrated and depressed if they so insist. -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 5, 11:07 pm, faenvie fanny.aen...@gmx.de wrote: note on the original posting: First, he shouldn't be porting Java code to clojure, Second, Clojure IS fundamentally different from Java, and third, such said users who don't want to touch Java should not touch Clojure. to port java-code to clojure-code is certainly not the right thing to do in most cases ... but the fact that clojure is not determined to use the jvm as its hosting-language could certainly be a driver for the reimplementation of popular components. even memory-management (gc), io-functions and process-management may be candidates for a (re)implementation in clojure some day. I recently read this and I think it's a very sensible position: Fogus: Different target hosts would naturally support different subsets of Clojure’s functionality. How do you plan to unify the ports? Hickey: I don’t. It has not been, and will not be, the objective of Clojure to allow porting of large programs from one host to another. That is simply a waste of time, and needed by almost no one. Currently, you often have to change languages when you change hosts— from Java to C# or Javascript. This is better than that, while short of some full portability layer. The idea is to be able to take one’s knowledge of Clojure and its core libraries, and of the host du jour, and get something done. Certainly, non-IO libraries, like Clojure’s core, can move between hosts. The JVM and CLR have rough capability parity. We’ll have to see how restrictive a Javascript host might be. -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 5, 7:30 pm, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Jul 3, 2011 at 8:04 PM, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Jul 3, 2011 at 3:34 PM, James Keats james.w.ke...@gmail.com wrote: For example I suggest you look at this video/transcript and pay attention in particular to the point of debate between Joe Armstrong of Erlang and Martin Odersky of Scalahttp://www.infoq.com/interviews/functional-langs , in particular around the point where Odersky says I’m not quite sure I buy that (also of additional relevance to those two points arehttp://erlang.org/pipermail/erlang-questions/2011-May/058769.html and alsohttp://www.scala-lang.org/node/1637), and if you're further interested you may wish to read Eric Meyer's essay in the book Beautiful Architecture regarding a previous Simon Peter Jones Haskell- related publication, titled Software Architecture: Object-Oriented Versus Functional. I've read that book (a month or two ago) but I'll go back and re-read that essay in light of this thread. I think you mean Bertrand Meyer's piece, extolling the virtues of OO in general (and Eiffel in particular)? I thought it was a terribly self-serving piece. Meyer has a strong bias and quite a bit of disdain for anything that isn't Eiffel - which shines right thru that essay to the point of making it fairly worthless, IMO. It has no objectivity :) It was an amusing read somewhat - at points hilarious (I'm actually a fan of Meyer!), but it needs to be considered within a long... what to call it... well, debate or dispute that I've long observed between the Haskell and Eiffel communities; both are concerned with correct software, but come at it in different ways. I believe both are relevant, Haskell's statelessness and Meyer's design by contract. I read the interview transcript for Syme, Armstrong and Odersky and I have to be honest that I found Armstrong almost incoherent and half the time couldn't figure out what he was trying to argue at all - so I'm not sure what point you're trying to make by referring to that interview, sorry. Similarly Armstrong's musings on the Erlang list about the entire world being a single flat namespace full of functions that are globally unique seems rather incoherent too. He talks about the problems with using modules to organize functions (and, yes, modularity can be hard) but then proposes something that would be no different (functions made unique by either having nearly random names or a structured set of metadata that would really be indistinguishable from modules in the first place - seehttp://erlang.org/pipermail/erlang-questions/2011-May/058773.html). Armstrong can come across as incoherent but if you read him again and again and again I find more and more and more in what he says. In any case, what he's suggesting there reminds me of something I read years ago by Dr Richard Hipp of Sqlite and Tcl core, where he suggests instead of putting your program in files you put it in a database http://www.tcl.tk/community/tcl2004/Papers/D.RichardHipp/drh.html The Scala forum discussion is more useful and relevant: TL;DR - objects are occasionally the most natural model for solving a problem. And in Clojure, mutable (shared) state is occasionally the most natural model for solving a problem. That doesn't seem newsworthy to me, just that a pure functional approach might not always lead to the cleanest solution. That's kind of a duh! because otherwise why would we need STM... I think the point he was making was not so much that, but that OOP allows you to defer implementation and there's value in that. And then there's the Ruby rant. Yeah, I'd be pretty ticked off that I got shot in the foot by combining two or three libraries that otherwise ought to behave reasonably together. Global method injection is pretty nasty. When I first read about multi-methods and protocols in Clojure I was a bit worried that library code might cause a similar problem by redefining functions out from under me, by virtue of more specific overloading but it hasn't been a problem yet and when I look at how those features are used in various libraries, I'm no longer so worried. I have other reasons for not liking Ruby so it's ability to shoot you in the foot like that doesn't change my opinion of the language (nor does it change its widespread popularity for a certain class of programmers / companies). Overall then, modularity is hard and sometimes a shared / mutable state solution is cleaner... And I agree with both points. Am I missing something in your concerns? No, you're spot on. I wasn't advocating anything in particular, I was merely suggesting that some of the finest minds in the industry do still find this a hard problem and can disagree on to how best to deal with it. :-) I personally don't feel that much of a schism between functional and OO, but perhaps that's because I actually quite like
Re: Clojure for large programs
On Jul 4, 5:45 am, Christian Schuhegger christian.schuheg...@gmail.com wrote: Thanks for your feed-back. I already have RDF/OWL in my tool-kit. I am only not sure if an ERP like system should be modeled along those lines. But I did not put enough thought in that direction yet. Would you base an ERP like system on top of RDF/OWL? My immediate instinct would suggest you already use an existing one, but I note that you said it was a toy project. ERP is a problem that's historically been well-suited for prolog and logic programming. Yes, I believe RDF/OWL(/Sparql and semantic web reasoners) is a major advancement in that field and would recommend you look at it. A good book to get you started would SEMANTIC WEB for the WORKING ONTOLOGIST, of which a second edition has recently come out. :-) -- 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: Clojure for large programs
On Jul 4, 1:26 pm, James Keats james.w.ke...@gmail.com wrote: On Jul 4, 5:45 am, Christian Schuhegger A good book to get you started would SEMANTIC WEB for the WORKING ONTOLOGIST, of which a second edition has recently come out. :-) Sorry about the unintentional to get you started figure of speech; I note you said you already had rdf/owl in your kit. It's not out of underestimating your knowledge (though it might be out of my sense of being mildly overwhelmed by the still remaining reading list I already have of semantic web books, Springer just keeps dropping them like rain. :-) -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 3, 6:15 am, Ken Wesson kwess...@gmail.com wrote: There's one obvious use case for such a wrapper function, though: if you'll want to pass the Java method to HOFs from time to time. You can't directly pass a Java method to a HOF, but you can pass such a wrapper function. Pardon me if I'm wrong, but could you not use an anonymous function in those places where you'd need to pass it to a HOF and continue to use it directly elsewhere? That would probably be how I'd prefer it, as it'd mean less functions to keep track of, and less indirection (decoupling api concerns aside). -- 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: Clojure for large programs
On Jul 3, 2:26 am, Mark Engelberg mark.engelb...@gmail.com wrote: Ideally, I was hoping to start a more in-depth discussion about the pros and cons of programming in the large in Clojure than just waxing poetic about Clojure/Lisp's capabilities in the abstract :) I am yet to do a large program in clojure, I still need to be convinced in the ok, so far so good, but where is this going? but I have this to say: large programs are primarily an architectural and secondarily a managerial/organizational concern, not a language issue, and large programs have been my prime driving consideration over the years. In terms of where is this going?, I would be quite concerned if the clojure community develops an unreasonably negative attitude towards OO (I don't believe Rich Hickey himself has a negative attitude, I believe his attitude is reasonable and balanced) and, on the other hand, believes it would do well to learn from the oral histories of the early days of Ruby. Well, I believe it would do well to learn from Ruby, but as a cautionary tale. All those little niggling issues you mention cause me no worry, either they could be worked around - or perhaps even properly understood - or they're easily fixable as the language implementation/tools mature, with the exception of in large part because failures usually occur within close proximity of the flaw that triggered the failure; I mentioned some concerns I had about datatypes/protocols, I'm yet to make my mind up on that, in particular with regard to failures usually occur within close proximity of the flaw, I still need to study them more. I wish the Clojure community to learn from two sources. 1) Java itself, and in particular what is happening with the service component architecture (SCA). Clojure makes those good engineering practices of services and contracts feasible for a small team or even an individual developer. I'm not saying that clojure would necessarily work with those frameworks, for that I believe Scala is better positioned, but I believe clojure should be mindful of what's happening there, as I believe that to be the biggest threat and hurdle Clojure faces in terms of its enterprise utility and adoption. The Service Component Architecture is incredibly well thought out, and it already has industry titans singed up to it. 2) RDF/OWL, or otherwise called the resource oriented architecture, or the global giant graph. I believe if clojure plays it cards well then that - the semantic web - could be its killer application. This too is a well thought out and compelling architecture, and I believe Clojure is uniquely well positioned for it. -- 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: Clojure for large programs
On Jul 3, 5:21 pm, Christian Schuhegger christian.schuheg...@gmail.com wrote: Nevertheless for large connected data graphs I think something like a data-schema is needed. Clojure would still follow its approach to only deal with maps, but there is a descriptive meta-data level in addition that explains the connection between those maps. I would agree to what was said elsewhere: the Clojure community has to come up with idioms on how to deal with large scale projects. Christian, your thoughts, generally speaking, chime with mine. I would suggest though that the clojure community does not try to reinvent the wheel where a well-engineered one has been made elsewhere (Rich Hickey's reluctance to give clojure a yet-another-distribution/ clustering-story and instead suggest a look at existing ones is one of the many reasons I believe he has admirable and reassuring sensibilities Given the diversity, sophistication, maturity, interoperability, robustness etc of these options, it's unlikely I'm going to fiddle around with some language-specific solution. http://groups.google.com/group/clojure/msg/4a7a866c45dc2101 - btw Rich, if you're reading this, slightly on a tangent, I do agree that I'm yet to be convinced by Erlang's distributed-at-all-time model, which you expressed reservations about based on your com/dcom experience. You may be interested to know that the SCA architecture takes these into account, and this is detailed in Jim Marino's book Understanding SCA, which contains a discussion that echoes your view, from which I'll quote: It may seem odd that a technology designed for building distributed applications specifies local service contracts as the default when defined in Java. This was a conscious decision on the part of the SCA authors. Echoing Jim Waldo’s seminal essay, “The Fallacies of Distributed Computing,” location transparency is a fallacy...) Christian, With regard to large data graphs, meta data, datalog/prolog and logic programming, I would suggest you take a long at RDF/OWL. It is a burgeoning field of research and my view would be that the clojure commmunity embraces it rather than attempt to reduplicate it. Is Clojure's Json-esque data model suitable for large data graphs? No, it isn't. Nor is sql or xml. That's the end of that story. But RDF/OWL is specifically designed for that, and it is very well designed. Clojure though is an ideal complement to that. -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 3, 9:02 pm, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Jul 3, 2011 at 3:14 AM, James Keats james.w.ke...@gmail.com wrote: Perhaps we move in different circles but I've seen as much bad Java in the large as I ever used to see bad FORTRAN and bad C / C++ code over the years. I think large enterprise Java projects have just as many below average developers working on them as any other popular language projects. And by definition, half of all developers are below average and the more popular a language is, the broader that spread is likely to be. I do not dispute that. I think the only way you can avoid the joe developer that you fear is to have a language which requires a very high barrier to entry so only good developers can even write Hello World! in it. I don't think that actually benefits anyone (since such languages don't get sufficient critical mass that people ever get the chance to use them at work to solve real problems). I respectfully but unreservedly disagree with the only way you can avoid the joe developer that you fear is to have a language which requires a very high barrier to entry. I do not worry so much about Hello World! taking too long, this is a business case analysis (if you can't afford to do something right, should you be doing it at all?!), though I do acknowledge that unfortunately Hello World! is the measure many developers use to judge things. I do not worry about that, what I worry about is what happens months or even years down the line, after much had been invested. Business is business; unless your motive is simply to scam someone else by passing it on (much of what startups and VCs nowadays are about - a ponzi scheme of sorts), you do not want to build on shaky foundations. There is much bad Java, no doubt, but no one if forcing you to fall prey to that. Beyond Java, that was, more or less, predicting the demise of java and was unimpressed by python, whilst favouring ruby, yet since, over those past years, they've only - java and python - gone from strength to strength and remain on the ascendency whilst the ruby hype machine has imploded and the feasibility of ruby has come apart at the seams thanks to an ill-disciplined community culture. I find it interesting that you offer up a perceived demise of Ruby when all I see is continued adoption of Ruby/Rails, far and away ahead of Python. Again, possibly we move in different circles. On Java, I was just at JAXconf where the overall theme was Don't worry, Java's not really dead! - it was an almost desperate sense of trying to rally the (enterprise) Java troops and head off the defections to other languages, whilst all the time praising how much innovation was occurring on the (JVM) platform, i.e., in those other languages. Oracle talked about the big focus for Java EE 6 / 7 / 8 being simplification - making Java easier to use and removing a lot of the complexity and configuration that has grown up in that world (exactly the problems that are causing Java developers to move to more expressive languages and to adopt convention-based frameworks). The big inspiration being held up to everyone at the conference was Ruby/JRuby and the convention-based approach of Rails. I came away with the sense that even its most stalwart supporters think Java is very, very sick and needs to clean its act up if it is to avoid becoming irrelevant as a language. The audience were told that Java developers need to get used to the idea of learning new languages frequently. I bumped into a handful of people there using Groovy and one or two using Scala. I ran into a lot of people who really had no idea what was going on in the world outside of Java and they seemed very focused on data-centric enterprise business applications that really didn't do anything particular complex but yet had grown into gigantic codebases with a huge amount of complicated infrastructure... So, overall, I don't share your belief that Java has a foundational design and community cultures [that is] conducive to large, long-term software and healthy ecosystems. Java is vast; there are so many legacy frameworks and legacy ways of doing things I would not adopt or endorse. After all, there is a reason why I'm here at clojure. We need to differentiate between things; how you build your software is up to you, but it is indisputable that Java has a lot of libraries, some may be bad, but others are outstanding, and no one is forcing you to choose the bad ones. I am a big believer that if there's a library that already does what you do, made by experts and vetted by the world, then you shouldn't do it yourself. I also believe that Java's thou shall not do this! and Python's though shall not do this, unless you have to go towards explaining that. Ruby may have a tempting Hello World! proposition that makes it appeal to startup developers, but sooner or later down the road you'll run into this widely
Re: Please stand firm against Steve Yegge's yes language push
On Jul 1, 10:50 pm, Gregg Reynolds d...@mobileink.com wrote: On Fri, Jul 1, 2011 at 2:59 PM, James Keats james.w.ke...@gmail.com wrote: ... Whereas when Steve Yegge writes: Who? Indeed. I'm not wishing this to be a personal attack on Steve Yegge, but a fair and justified re-examination; if people are going to use their heavyweight-sounding name to wield influence upon others, it's fair and justified to ask what's behind that name. I have been aware of Steve Yegge for many years; pseudo-literary and pseudo-humorous rants that might be of interest to a programmer's cabinet of curiosities, but that I've not had the luxury of time to indulge in reading, preferring to devote mine to meatier topics. I have not learned anything of note from Steve Yegge. His name seems to be associated lately with Javascript, but whereas I've learnt a lot from those folks, the likes of Stoyan Stefanov (perhaps my personal favourite of those folks), Doug Crockford and John Resig, the one time I felt compelled to read a Steve Yegge writing was when he was referenced in the Joy of Clojure regarding his so-called universal design pattern. What a poorly written piece of crap that was, there was nothing new in it (Javascript's literal syntax is well documented in much better writings, and in Steve Yegge's article it was burried in a bunch of mind-numbing nonsense). I believe it'd be better for the Clojure core notables, whom I have a deep respect for, to suggest Haskell and RDF/OWL as better resources for understanding Clojures types/protocols. -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 2, 4:16 pm, Aaron Bedra aaron.be...@gmail.com wrote: Although I agree with the ideas here that have already been stated by Rich, I am concerned about this message. There is no reason to stand against somebody. Steve is welcome to his own opinions and is an incredibly smart guy. He should be respected as a peer. His opinions happen to be different from Clojure's core values, and that is ok. Steve will either choose to use Clojure or go another path, and that is alright. The way for Clojure to grow is by embracing it's core values and showing the world that careful choices do lead to the right outcome. Let's not turn this into us against Steve. There's nothing productive there. Focus your energy instead on writing great Clojure code and sharing it with everyone else. Get people excited about Clojure who want something more powerful, and show them what is truly possible. Cheers, Aaron Bedra -- Clojure/corehttp://clojure.com On 07/01/2011 03:59 PM, James Keats wrote: To be absolutely clear, I am not against Steve Yegge as a person. The title of my post was Please stand firm against Steve Yegge's yes language push. I implore you as clojure core and clojure community to stand firm against his yes language push. I did not intend the message of my post to be personal/social issues, despite the unfortunate fact that the thrust of his posts in that thread revolved around his concept of social attitude of a language creator and community and the evident implication that such social considerations should take primacy over technical merits. -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 2, 3:54 pm, David Nolen dnolen.li...@gmail.com wrote: On Sat, Jul 2, 2011 at 4:05 AM, faenvie faen...@googlemail.com wrote: I agree, that clojure will not gain java-like popularity in a forseeable future. IMO clojure is much more a Language for SystemProgrammers (high demands, thinking in concurrency) than a Language for ApplicationProgrammers (midsize demands, thinking singlethread) it does not have to target general purpose use. But Very well could clojure become a mainstream-language for SystemProgrammers. other promising perspectives for clojure: - as a base for true innovation (core.logic) If true innovation means implementing good ideas found in academic papers, sure ;) I think your characterization of Clojure being best suited for systems programming to be inaccurate. Two of the most interesting large open source projects written in Clojure (for me) are Penumbra and Overtone. Both of these are for creative coding. David I agree that it would be unsuitable for systems programming, if systems programming is of the C variety; in fact even Java wouldn't be suitable there. Actually I do believe Clojure to be an applications language, and I would not constrain it to any one application area, I believe it to be widely applicable. Where I would advocate caution that'd restrict its use though, it would not relate to the programming language itself, but to the programmer. Twofold: 1) Clojure requires an advanced programmer; there's no escaping that. Said programmer needs to know Java well, and also functional programming of the haskell/ml sort, as well as lisp 2) Clojure requires discipline and wisdom; those do not come about easily, they require wide and long experience. It allows the programmer much, not too much for the widely-read experienced programmer, but perhaps too much for a large team constituted of programmers of varied abilities. I therefore see it most suited, as I said, for the advanced independent programmer, or at most a small team of advanced enough programmers. -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 2, 6:39 pm, David Nolen dnolen.li...@gmail.com wrote: On Sat, Jul 2, 2011 at 12:23 PM, James Keats james.w.ke...@gmail.comwrote: I therefore see it most suited, as I said, for the advanced independent programmer, or at most a small team of advanced enough programmers. I think Clojure is great for programmers with all kinds of experience - from beginner to advanced. In fact I think people haven't been brain washed by too much experience in object oriented and imperative languages will have a much easier time picking it up. David This above is the classic Sussman/Abelson/Harvey argument in favour of teaching lisp and functional programming as early as possible. I have nothing against it whatsoever other than to note that it is an educational argument, not an industrial one. In fact, it is exactly how I came to programming; lisp through the writings of those folks was my introduction to programming many years ago. Had it not been for their inspiration I wouldn't have bothered. However, once you're past the CS education stage then industrial concerns are an inescapable reality. And once you encounter the reality and frustration infamously characterized by likening the managing of lispers to the herding of cats then you begin to admire languages like python and java and see what they got right in imposing restrictions. A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. Kind regards, J -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 2, 6:41 pm, Stefan Kamphausen ska2...@googlemail.com wrote: FWIW, However, as Aaron pointed out, I'd rather a more tolerant, pleasant community. Kind regards, A month ago I asked a question here that barely a minute after clicking send realized was utterly dumb. It reminds of an anecdote about an (MIT?) professor who'd insist on whomever asks him a question to explain in some detail what they understand and what they don't understand, and oftentimes when people do so come to an Oh! moment of sudden understanding before he'd even answered just out of formulating the problem. That utterly dumb question got many tolerant, pleasant answers. :-) I would draw a thick line between the community's response to someone who'd ask an utterly dumb question - I don't me specifically, but any newcomer - and someone who'd insist upon the creator of a carefully considered and crafted solution and its community to change their culture outright. If I, and people like me who are willing to put their nose to the grindstone, read the books and watch the videos umpteen times over till they get it through and through, to become invested in clojure and its future, then we need a firm reassurance that ludicrous demands like those are firmly resisted, and believe it's imperative to implore clojure core to do so. Kind regards, :-) J -- 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: Please stand firm against Steve Yegge's yes language push
On Jul 2, 8:33 pm, David Nolen dnolen.li...@gmail.com wrote: On Sat, Jul 2, 2011 at 3:21 PM, James Keats james.w.ke...@gmail.com wrote: And once you encounter the reality and frustration infamously characterized by likening the managing of lispers to the herding of cats then you begin to admire languages like python and java and see what they got right in imposing restrictions. I've yet to see any evidence anecdotal or otherwise that managing a team of good Lisp programmers is any more difficult than managing good programmers in any other language. Links? Sure, good lisp programmers, I have no argument against that, the key operative word here being *good*; where do you find those in large enough numbers to fill industry positions? I would also like to be specific about what good would entail: it has to entail some knowledge of what would actually work in the large and be maintainable, and a personal maturity that would prevent them from becoming too excited and overly adventurous. Unfortunately the industry is not made of good lisp programmers. A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. One of the most popular text editors to this day is Emacs. It's near 3 million lines of Lisp. David Versus the countless libraries and apps of Java and python? -- 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: Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
On Jul 2, 8:33 pm, Mark Engelberg mark.engelb...@gmail.com wrote: On Sat, Jul 2, 2011 at 12:21 PM, James Keats james.w.ke...@gmail.com wrote: A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. In your post, you talk about a certain naivete among Lispers about its practicality in industry, explain that python and java benefit from their added restrictions, and then offer up the above quote by Abelson. But you never really tie these observations back to Clojure. So I want to ask explicitly, do you think Clojure is suitable for these sorts of really large programs? Why or why not? If the community sticks to Rich Hickey's original vision, and in *competent and disciplined* hands, I believe clojure is suitable for almost any problems (barring the obvious of course, eg, those where the jvm wouldn't be suitable). Clojure is not just simply a lisp, it improves upon lisp through its immutable/persistent data structures, emphasis on pure functions and separation of pure code from side-effecting one, collections/sequence abstractions, embrace of java, concurrency, and recently datatypes/ protocols; clojure does impose restrictions; all those above are restrictions (use immutable/persistent data, use pure functions, use java directly, use generic data structures and generic sequence functions to manipulate them, use the appropriate concurrency feature.. etc, though it does somewhat enable the programmer to work around those when necessary) and also for example the disabling of user-defined reader macros. I'm actually thrilled about that, and look forward to see how it would actually work out as the community expands. I do though implore clojure core to stick or Rich Hickey's original vision, and not dilute it to appease ill-conceived social/ marketing claims and incalcitrant newcomers. Additionally, programs and teams for clojure don't have to be really large. The language is such that a small and competent team, or even an individual developer, could do a lot with so little. In any case, enterprise needs could be bolted on clojure; programming against services/interfaces/xml schemas/messaging/et cetera. Those could almost even be said to be orthogonal. Additionally, whatever clojure does, clojure is ultimately java. I could take clojure 1.0 and the innumerable java libs and be done with it (I remain to be convinced about datatypes/protocols and believe them to impose a managerial overhead, I believe for large teams they're a double edged-sword, the programming against interfaces is beneficial, but their ad hoc permissiveness could prove problematic). The same can't be said for other lisps, those weren't made with Java in mind as Rich Hickey made clojure. Regards, J -- 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
Please stand firm against Steve Yegge's yes language push
Hi all. I've been looking at Clojure for the past month, having had a previous look at it a couple of years ago and then moved on to other things only to return to it now. Over the past decade I have looked at many languages and many ways of doing things. People may say this language or that language is general purpose, but the fact remains that languages have their niches in which they excel and beyond which it'd be foolish to venture. Clojure should not attempt be a mass success language or worry about its Tiobe index ranking. Clojure, the way I see it, is most suitable for the advanced independent developer. It is a language in the image of its creator, Rich Hickey. It's not a language for the factory hen. It won't become the next Java. Java already fills that niche, and despite what some may say, I don't see it going away anytime soon. I don't feel Clojure needs to grow - in terms of size of language. In fact it would worry me enormously if Clojure's path is to grow in size. It is fundamentally unsuited for that. If anything I wish for it to shrink even further and further. A Rich Hickey's quote comes to mind: • (paraphrased) Most Clojure programmers go through an arc. First they think “eww, Java” and try to hide all the Java. Then they think “ooh, Java” and realize that Clojure is a powerful way to write Java code and As I've said in my talks, most Clojure users go from eww, Java libs to ooh, Java libs, leveraging the fact there there is already a lib for almost anything they need to do. And using the lib is completely transparent, idiomatic and wrapper free. - Google verbatim for sources. Whereas when Steve Yegge writes: which means that everyone (including me!) who is porting Java code to Clojure (which, by golly, is a good way to get a lot of people using Clojure) is stuck having to rework the code semantically rather than just doing the simplest possible straight port. The more they have to do this, the more you're going to shake users off the tree. all I could think on reading this is horror, horror, oh God, horror!!!; he really doesn't get it. First, he shouldn't be porting Java code to clojure, Second, Clojure IS fundamentally different from Java, and third, such said users who don't want to touch Java should not touch Clojure. Clojure shouldn't worry about growing; java already has innumerable libs. Clojure, imho, should continue its - what I would dub - middleware begone! path, in which it'd provide an end-to-end, down- to-the-metal comprehensible system that an individual developer can get his head round and know exactly what's happening with his code and its environment here and everywhere. I could write more, but I have to run. Regards. J. -- 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: hammock driven development...
On Jun 21, 6:54 pm, miner stevemi...@gmail.com wrote: Here's some more support for the hammock: http://www.npr.org/blogs/health/2011/06/20/137300311/why-hammocks-mak... If this is going to be anything like those ambient orbs, then I better hurry up and invest in hammocks. -- 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: Why should I use emacs instead of netbeans?
On Jun 18, 4:08 pm, Stefan Kamphausen ska2...@googlemail.com wrote: Hi, these modern IDEs really do a tremendous job at organizing projects and providing additional information at programming time. It's just, their text-editor components suck. If you are a Java developer, it's probably better to stay away from Emacs. Should you ever get used to it, you're doomed to never be able to use something else, and Emacs is not particularly good at Java programming. See, this is it. Navigating java libs, maven repositories, project directories, xml files, et cetera et cetera is a much more arduous task, imo, than dealing with clojure code, which I find fairly trivial and not really needing much advanced editing features. I'm likely to want to keep my methods short and my files small. Strangely, I must admit that in the past I did find vim a bit more modern than emacs and its keys generally more sensible, especially when using shift-semicolon instead of esc. I just looked it up and vim does have clojure support with paredit and slime. My main problem with emacs is that most things require too many key presses, and I feel that navigating solely through emacs multi-key keybindings, on the advocacy of not taking my hands off the keyboard, is a recipe for RSI. Perhaps there's virtue in using the trackpad after all. I don't know, I'll see how it goes. That being said, I had my best times in front of the computer with Emacs/SLIME and Emacs/AUCTeX. I had this similar situation with latex a few years ago, trying to get myself into the emacs/auctex holy grail of productivity, and I must admit that after a few days or weeks abandoned it for Kile, the KDE's latex IDE, and for latex documents that are mostly composed of text I quite liked lightweight markup languages, especially those in python that output latex as python code is quite pleasant to read and modify. I just simply found myself much productive with those. http://kile.sourceforge.net/screenshots.php http://en.wikipedia.org/wiki/Lightweight_markup_language :-) J ;-) Cheers, Stefan -- 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
Are the docs on clojure.org always kept up to date?
Hi all, Clojure seems to be a language in a bit of flux (eg, defstruct vs defrecord), is there a canonical set of docs that keeps all of this up- to-date? are the docs on clojure.org always kept up to date? is there a place to track succinct notes on language evolution, conventions and community best practices other than wading through all the blogs and newsgroup posts? Thanks. :-) -- 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
Why should I use emacs instead of netbeans?
Hello all. I'm currently using Netbeans' clojure IDE and I quite like it. It has a REPL. It highlights syntax and matches parentheses. It supports maven and mercurial/git. It provides completion and doc for both clojure and java. It has allows evaluation of forms from source code to repl. It also allows me to customize keyboard shortcuts. The other option that I've seen being popular is emacs with cake. I've seen that cake opens two jvms, one for itself and one for project, ok, nevermind that, no big deal, but emacs, i find, is unnecessarily arcane compared to a modern java IDE. It's keyboard shortcuts and combinations are based on ancient keyboards and terminals and historical conventions, and while i can customize that and only use what I need, netbeans already has a comfortable, modern setup out of the box. I see that some would suggest paredit, but honestly, i don't see that, navigating code through keyboard shortcuts, as all that much of an advantage considering that using the mouse or the trackpad is very convenient. What am I missing out on? Thanks. -- 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
(. rnd nextInt) vs (.nextInt rnd)
Hi all. I'm struggling to see the point of this (from Pragmatic's Programming Clojure): Java = rnd.nextInt() Clojure = (. rnd nextInt) sugared = (.nextInt rnd) What's the point of the sugared version? It's not any less to type. It's also incomprehensible to me how it came about. In the middle one it's simple, class and method, but the in sugared one it's just plain simply bizarre looking. What was the intent? Thanks. -- 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: (. rnd nextInt) vs (.nextInt rnd)
What's the point of the sugared version? It's not any less to type. Actually there's one fewer character -- a space. Okay, I'll give you that. It's also incomprehensible to me how it came about. In the middle one it's simple, class and method, but the in sugared one it's just plain simply bizarre looking. What was the intent? It's closer to typical function-call form: (.doSomething someNoun) resembles (do-something some-noun) more than does (. someNoun doSomething). Right. That makes sense. I see the consistency here now. :-) Thanks. Soldiering on now; I'll probably be back. :-D -- 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
(function [args] more args)
Hi again. This is another syntax that I'm struggling with: (function [args] more args) Or for example: (subvec [1 2 3 4 5] 1 3) Please note I'm not referring specifically to the subvec function, but simply using it as an example, as I've seen this syntax with many other functions, but it escapes my mind now to provide more examples. I don't like it, and here's what I don't like about it. It leaves me with a bad taste that where the arguments are generally meant to be passed to the function in a vector of arguments, some are sometimes passed outside the vector. It feels inconsistent and ad hoc. What am I missing out on? are the arguments contained within a vector only when defining functions? such as: (defn name [args] body) Thanks. -- 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: (function [args] more args)
Hi, I admit that subvec is not a good example as it does indeed take a vector as a first argument, perhaps i'll find better example or perhaps I might've just been confused. I learnt lisp and scheme many years ago, abandoned them for languages with better libraries, and I'm perhaps thrown off by the [] of clojure instead of the () throughout of lisp. Thanks. On Jun 15, 4:54 pm, Meikel Brandmeyer m...@kotka.de wrote: Hi, in your example the vector *is* the argument. You could just as well write (let [x [1 2 3 4 5]] (subvec x 1 3)). On function definition the arguments are given in a vector, yes. I'm not sure I understand your concern completely. Sincerely Meikel -- 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
