"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 > companies<http://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 > "mind"<http://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.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? > > > -- > > 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
