Oh, I agree with you 100%. I outlined why I wouldn't use Clojure in a project self-described as "enterprise", but at risk of ranting I didn't get into how I consider the word "enterprise" synonymous with "bloated, bureaucracy-bound, over-engineered, unoriginal and above all /expensive/ ball of tar".
Ironically, "enterprise" has nothing to do with actual size or significance of the project. I've seen very small projects that are infected with "enterprise", whereas I don't think there is anything enterprisy about, say, Google. -Luke On Mar 6, 11:07 am, lprefonta...@softaddicts.ca wrote: > I agree about "consultants" (these days it's not anymore an synonym for > expert) and the state of the market but... > > If you write a new software product and > you are concerned with deadlines and speed in general, Java is not > the way to go anymore considering the pile of code you need to do > anything significant these days. More code = more people = inefficiencies. > > I know some business where HR and IT managers come back with this mantra > that they can find Java and .Net coders, anything else is too risky or > too scarce on the market. > It reminds the time when you could not get fired when buying IBM mainframes. > > Many HR departments do not understand anything about > software development in general and the profile of individuals needed. > They go for the "standard" available bodies with a single fit all projects > skill set and their batteries of psychological tests. > That explains a lot why productivity is low on most projects. > > The landscape will change when HR changes (and managers)... > seeking intelligence and initiative instead of a single static fit. > (looks like StarTrek quest...) > > The day they will understand that software development is not > a Taylor assembly line (less the efficiency), the situation will improve. > > You cannot get more from people that what you are asking for... > > I am not generally optimistic about the state of things in the software > industry but we need to bring in tools that are more accessible to the > masses. Clojure is one if you compared it to CL... > > Luc > > > > > > > The biggest barrier to using Clojure in an "enterprise" environment is > > that enterprise projects are typically built and maintained by 100s of > > replaceable code-monkeys and consultants, all of which understand Java > > and almost none of which understand Lisp of any kind, let alone > > Clojure. > > > To be honest, even if I could get away with it, I wouldn't want to > > inflict hell on the next person who has to fix something in my Clojure > > code. Even if they're a good developer, they are very unlikely to care > > about Clojure or functional programming. I heard of one guy in our > > company who wrote some web services in Scala on the grounds that they > > were one-off services that wouldn't need to be modified - until they > > were, and everyone was roundly cursing him for it. They were small > > enough that it turned out to be easier to redo them in Java rather > > than to learn Scala and understand his code. > > > Like it or not, enterprise development = Java or .NET until the > > language landscape has some radical changes. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
