Re: Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 8:56 PM, Nick Brown nwbr...@gmail.com wrote: But not the lots of developers part. As much as I like Clojure, it has nowhere near the level of developers languages like Java or Python. And to be honest, that constraint is much more convincing for most software managers than the library one. That's an interesting point. Since 2001, I've mostly been working with CFML - despite my C++ / Java background - and that's a community that has around 800k developers (according to Evans Data Corporation's survey in 2008). One of the biggest concerns that is commonly voiced in the CFML is around the availability of CF developers. We hear of companies who are switching away from CFML to technology X because of the difficulty of finding (good) CF developers. It's hard to know for sure whether that's really the reason for their shift - I think it's a convenient excuse. Some companies will pick the best technology, some companies will pick the most popular technology... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
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? -- 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
Re: Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
As for whether Clojure would work in a large corporate environment (or for large software), I think that's more a function of the internal politics of the organization. Many managers, understandably, go with a technology with heavy library support and lots of developers. The common critique that Lisp isn't practical in industry, comes from that position. But Clojure, sitting atop the JVM, doesn't have that problem. Lisp was originally developed to build an AI system. So Clojure (a Lisp) is, in my opinion, a superior way to develop any size of program. I won't enumerate Clojure's many technical features and attributes. Just recall that computers are essentially heavy paper weights without software. And software is essentially functions and the manipulation of data. These companieshttp://clojure02.managed.contegix.com/display/community/Clojure+Success+Stories have all successfully used Clojure in medium to large projects. And Ray Kuzweil finds Lisp to be ideally suited to build a mindhttp://singularityhub.com/2010/12/21/ray-kurzweil-the-mind-and-how-to-build-one-video/ . OO, alternatively, is not at all practical. It was developed in the 60s, as a way to modularize (data abstraction, encapsulation, etc) large programs. The goal was maintainable and re-usable chunks of code. But we've seen the downsides of the OO paradigm, including: i) excessive overhead and ceremony, ii) software systems don't always fit into an Object world view, and iii) Rich Hickey's critique that OO is bad at representing time. Tim On Sat, Jul 2, 2011 at 3:33 PM, Mark Engelberg mark.engelb...@gmail.comwrote: 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? -- 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: Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
Many managers, understandably, go with a technology with heavy library support and lots of developers. The common critique that Lisp isn't practical in industry, comes from that position. But Clojure, sitting atop the JVM, doesn't have that problem. The library part, ok, sure (but if I'm writing in Clojure, generally I'd prefer to work with a Clojure API, not wrestle with one built for Java). But not the lots of developers part. As much as I like Clojure, it has nowhere near the level of developers languages like Java or Python. And to be honest, that constraint is much more convincing for most software managers than the library one. Of course you can also make the argument there are fewer companies out there hiring Clojure programmers than Java programmers, so you have a better chance at nabbing an excellent developer with Clojure in the job description. But you also have a better chance at struggling to find someone at all, and it should be no surprise than in most corporate environments, most managers will go with the safe pick they know they can hire someone to work on. We can debate the wisdom of that choice and I will likely be sympathetic to your arguments, but then I'm not a manager so you would be preaching to the choir. OO may not be the ideal abstraction for many programs out there, but it is a very commonly used one (well, kinda, many Java programs are only superficially OO) so its still going to be the first choice for many managers who would prefer to go for the safe pick than take a risk with something relatively unknown. Think James Taggart in Atlas Shrugged resisting Rearden Metal because no one else uses it. On Jul 2, 7:02 pm, Timothy Washington twash...@gmail.com wrote: As for whether Clojure would work in a large corporate environment (or for large software), I think that's more a function of the internal politics of the organization. Many managers, understandably, go with a technology with heavy library support and lots of developers. The common critique that Lisp isn't practical in industry, comes from that position. But Clojure, sitting atop the JVM, doesn't have that problem. Lisp was originally developed to build an AI system. So Clojure (a Lisp) is, in my opinion, a superior way to develop any size of program. I won't enumerate Clojure's many technical features and attributes. Just recall that computers are essentially heavy paper weights without software. And software is essentially functions and the manipulation of data. These companieshttp://clojure02.managed.contegix.com/display/community/Clojure+Succe... have all successfully used Clojure in medium to large projects. And Ray Kuzweil finds Lisp to be ideally suited to build a mindhttp://singularityhub.com/2010/12/21/ray-kurzweil-the-mind-and-how-to... . OO, alternatively, is not at all practical. It was developed in the 60s, as a way to modularize (data abstraction, encapsulation, etc) large programs. The goal was maintainable and re-usable chunks of code. But we've seen the downsides of the OO paradigm, including: i) excessive overhead and ceremony, ii) software systems don't always fit into an Object world view, and iii) Rich Hickey's critique that OO is bad at representing time. Tim On Sat, Jul 2, 2011 at 3:33 PM, Mark Engelberg mark.engelb...@gmail.comwrote: 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? -- 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
