IT is in a worse place now than it was 5 years ago. The "thinkers" in IT are picking up the shiny new tools and shiny new things and yet again continuing to miss the point of what makes enterprise IT better. There are a few key points that need to be remembered.
- Art v Engineering is still the big problem - 90%+ of people in IT aren't brilliant, a large proportion aren't even good
- Contracts really matter - without them everything becomes tightly bound no matter what people claim about "dynamism"
- No technology has ever, or will ever, deliver a magnitude increase in performance
- The hardest part of IT is integrating systems and service not integrating people. People are good at context shifting and vagueness, good interfaces are fantastic optimisers but even average user interfaces can be worked around by users.
The likes of Clojure and REST haven't improved this situation in the enterprise in any marked way. Its been 5+ years since REST started being hyped and in comparison with the benefits that WS-* delivered to the enterprise in 5 years its been zip, zero, nada. The "dynamic" languages piece that kicked off about the same time has delivered similar benefits to large scale enterprise computing (you know the stuff that keeps most people in IT in a job) over the "old school" Java approach.
A few years ago I said that if you wanted a career then learn Web Services, if you want to be cool learn REST. Since then its become clear that some people have made careers in REST... but you know what?
- Its as hard to do a large scale programme with a large integration bent as it was 5 years ago.
- There are less really good enterprise qualified developers as they've got "dynamic" language experience and struggle, or worse bring the dynamic language in and everyone else struggles
- Vendors have been left to their own devices which has meant less innovation, less challenge and higher costs as the Open Source crowd waste time on pet projects that aren't going to dent enterprise budgets
In 5 years from 1998-2003 Java and Web Services went from near-zero to being everywhere, innovation was being done at the edges and then being applied to the enterprise. It was a melting pot and it improved enterprise IT, thanks in part to the smart people working at the edge and the way this pushed the vendors forwards...
Well now SAP, Oracle and IBM are still heavily backing Web Services but there is a big problem....
No one is holding them to account. With all of the cool, and smart, kids off playing with REST and Clojure and the like we've got an intellectual vacuum in enterprise IT that is being "filled" by the vendors in the only way that vendors know how. Namely by increasing the amount of proprietary extensions and software and pushing their own individual agendas.
So we get the bizarre world in which Siebel's Web Service stack has a pre-OASIS specification of WS-Security, last updated in 2006 by the looks of it. We get a world where IBM is still pushing the old MQSI cart horse as an "Advanced ESB" and generally the innovation in this space has just collapsed in the last few years. Working on a programme doing integration which uses Web Services in 2010 feels pretty much like 2005, sure some specifications have come out and there is some improvement but overall its pretty stagnant.
"Oh do REST then" I hear the snake-oil salesmen cry. Really? If you had to do an integration between 20 different programmes and over 300 systems in a heavily regulated area then you'd use REST? High value assured transactions between different vendors and providers over a "dynamic" interface?
Give me a break.
What works in these areas is what has always worked
- Define your interfaces, nail them down, get them right
- Test like a bastard to those interfaces
You can't do complex programmes without having those firm areas, this is why major engineering programmes don't have variable interfaces for screws. Now before someone pipes up with a nice edge case where 200 people did something complex then please do that 20 times in a single organisation and give me a call.
In 2006 I asked why there was no WS-Contract and the real reason was that it wasn't a good vendor specification (WS-TX is that) but its a brilliant enterprise specification. So WS just had Security and Reliability, important things for the enterprise, but didn't make then next step.
And what has REST given us in the last few years? Errr please, folks... Now in my current engagement there was a great area where REST would have been very useful (Reference Data) and some where it would have been quite useful (Federated Data Network Navigation). The problem is two fold
- Most people in IT appear to know bugger all about it. Now I continue to be surprised at how little people who work in IT read about what is going on, but I was really surprised at how little traction REST had.
- EVERYTHING is manual and there is still no standardised way to communicate on WTF you are doing between teams
Now if you had 2 then you can do 1. I did this with WS back in 2000-1 when most people thought I was just making up this WS stuff I could run between the data centres over port 443, I had interfaces, they had tools, we got it working.
Now before RESTafarians jump up and talk about all of the wonderful WEB things they've been doing. That is great and wonderful, but its not my world, my world is having 300 systems that vary from 20+ years old to just being built and I need to get them all working together. Even when REST was the right "architectural" solution it was the wrong "programme" solution as it would have driven us off a cliff. My world does have stratospherically large budgets however... you know what, if you want to make real cash wouldn't it be a good idea to address the richest part of the IT market?
But my real ire I reserve for a company I used to really respect but which, at the same time as REST began to get a load of buzz, drove a huge amount of enterprise IT off a cliff. When Java SE 6 was released I said it wasn't enterprise grade and indeed very rapidly the stupidity of the decision to push JAX-WS into JavaSE became apparent (yes please note I was massively against WS-* in JavaSE, partly because if someone wants to be a RESTafarian why the hell should they have to have WS-* cruft in their environment?). This was also the release that added in scripting to Java SE.
I'm now seeing 4 years later the impact of this stupidity on the enterprise. Java SE 6 is dribbling in under the application servers but the mentality that it represented, namely that Sun was more interested in "Joe Sixpack" and the cool crowd than the enterprise really helped to ensure that it was left to the vendors to undertake the enterprise side and Java began to stop being the innovative platform or language. The bits that the enterprise wanted, things like profiles and dynamic loading, were deferred into Java SE 7, which is now (by my reckoning) 2 years over due.
Sun championed the new "cool" languages and undermined the whole thing which made Java good for the enterprise, consistency. Having lots of different languages is rubbish in the enterprise, having the same basic platform from 4 different vendors is much much better on every level. So now we have people proposing doing programmes with 4 or 5 different languages and its being seen as "reasonable", we are also seeing some great developers doing some interesting things on platforms that will never bring benefits.... I can't help but wonder whether Spring or Hibernate would ever have delivered any benefit if it wasn't for the fact that they operated on the common platform... oh wait I don't have to wonder, they wouldn't have been anywhere near as successful.
So the last 5 years have been poor ones for enterprise IT. WS-* is the only viable system to system integration mechanism for large scale programmes, but its stagnating. REST has some cool stuff at the front end and for people who can invest in only the very highest calibre individuals but is delivering bugger all for the average enterprise environment.
Why is this a problem?
Well most of the modern world is driven by computers, computers are what makes economies tick and its integration that matters in a networked world. The immature and techno-centric way in which IT approaches enterprise solutions is ensuring that far from being an accelerator that works ahead of business demand it is IT that is all to often the dragging anchor to growth. This obsession with purist solutions that solve problems that don't exist are just exercises in intellectual masturbation which are actively harming developed economies.
Far too much shiny, shiny, far too little getting hands dirty with pragmatic realities.
So maybe I'll come out of this funk and people will point to the wonderful things that are massive improvements over the past 5 years and how some of the biggest enterprise IT challenges in the world are being solved by people in application support thanks to these new developments.....
But I won't hold my breath
Technorati Tags: SOA, Service Architecture
37 comments:
Fortunately that enterprise market of yours is not holding back innovation, because when I read this, it’s the biggest load of shit you can end up in.
Unfortunately, the situation will remain as it is now. Some things will be solved, new problems arise. We are progressing, but only too slowly to notice.
The real problem is always people. Those 10%, who are supposedly so brilliant, are not brilliant enough to make it simple for the rest of us. It's just never going to happen. But hey, marketing slogans work on most people, and so the vendors get their piece of the pie.
The only way I see REST hurting enterprise IT is that the people who actually want to develop and deploy working, maintainable, distributed systems have gotten the hell out of enterprise IT and its blind adherence to WS-* for the vendor support.
You absolutely need robust tooling and vendor support for WS-* because it's not possible to build anything non-trivial without it. If you understand the principles behind REST (and no, POST is not a principle), you find it is much much harder to write tightly coupled brittle apps.
I left a very large enterprise shop at an investment bank because it was no longer possible to get any work done with the insistence on WS-*. I went to a smaller shop where we roll out new REST APIs regularly with real contracts & interfaces (WADL, XSD, etc.) at a tiny fraction of the overhead and meta-work of so-called "enterprise class" approaches.
Doing REST with a WS-* mindset will absolutely set you back five years. The RESTafarian mindset is not blind obedience to the new cool shiny thing, but rather the recognition that REST, done properly, eliminates 90% of the commonalities in distributed systems, and causes whole classes of problems to simply disappear.
Its wonderful when two people miss the whole point. Firstly anon, yes enterprise IT which employs the vast vast majority of folks in IT does have a lot of shitty bits in it. That was the point I'm making.
And Joel. My point on REST is that in the five years that people have being saying that its "the right way" to build distributed systems its pretty impressive just how few people are actually using it in comparison with the "old school" approach. Distributed systems means SYSTEM to SYSTEM communication and most of the REST stuff is SYSTEM to HUMAN which isn't distributed systems stuff at all. Building something that aggregates a few sites or transposes the interface into a different human interface isn't distributed systems stuff.
I'm not talking about doing REST in a WS-* way, I'm talking about the fact that the only people who seem to use REST are those in small shops doing more informal PEOPLE centric applications, which is an area where informal approaches have always worked.
REST does not make the biggest problem of distributed systems disappear, namely how to communicate WTF your solution does to other people outside your team and company. And that is just about 90% of the problems of distributed systems on its own.
I don't understand how you can continually point out the importance of a firm, stable contract - with which I completely agree - but yet fail to see how using the Web/REST is doing *exactly* that.
I read once in the REST Yahoo group a distinction made between "street REST" and "Roy's REST". I think this distinction is apropos here. Without being pedantic, it seems to me that the major challenge with employing the REST architectural style in enterprise IT systems integration is that none of the systems that need integrated were constructed with REST in mind. Most of these systems inherited the legacy of Transaction Processing System. At the very least you'd need a lightweight container to interface with the so-called legacy system to provide REST semantics, i.e. unambiguous methods that define the internal state machine via hypertext. This is difficult at best, but I would go as far as to say that most IT "architects" throw up their hands and just create a CRUD interface over HTTP. That's street REST.
REST is a powerful architectural style. Disambiguating the integration interface by defining it both in terms of simple contracts and hypermedia that exposes the internal state machine is absolutely the deus ex machina of the web. I just don't believe that REST can be effectively applied to integration scenarios in most IT shops; either the TPS systems don't have an FSM to expose (i.e. straight OLTP/RDBMS apps) or the IT "talent" is incapable of realizing the benefits of REST.
I understand the pathos on both sides, of course. Folks advocating REST in IT are tired of fighting battles with the people and systems that are supposed to be making their jobs easier. Unfortunately, they seek a technical solution to a problem that is decided non-technical. REST is no silver bullet.
At the end of the day, to my mind the REST vs WS-* debate is a non sequitur. There is absolutely no reason why the REST style cannot be implemented using the WS-* stack. In fact, where it can be effectively employed, REST provides an elegant and powerful model for integration. All integrators should look for the opportunity to apply the REST constraints to the architectures and integrations.
To those that would advocate an HTTP library, some Python, and a toothbrush for all enterprise integrations, I would expect you are operating more from a position of frustration than pragmatism. It should be that easy, yes, but the realities of hundreds of systems and developers and years and years of maintenance complicate matters more than a little. In truth, I think the move the cloud is enterprise IT throwing up there hands and saying, "This was so much simpler when everything was in one database!"
Maybe true distributed systems integration is just too hard. I know a distributed systems architect working on a a major trading platform who has gone with a large distributed database system. Is he ignorant of the power of event driven architectures, of REST, or the WS-* stack? No, but they're coding instead of talking, running instead of debating, and trading instead of integrating.
Mark, we've been through this before. POST, GET, PUT, et al are not a business contract they are just a low level technical contract.
The contract is the functional element, the piece that Google and Yahoo spend pages and pages describing. Its a lot more than the HTTP "contract".
Christopher I agree with most of what you say, and its this that underpins my moan. Basically in the last 5 years I've not seen any marked improvement in the systems integration & enterprise IT estate. This tends to indicate that REST doesn't have value here as previous approaches that demonstrated any value (Agile, WS-*, et al) have all gone mainstream within a 5 year period.
But with the cool kids hawking REST about this means that a lot of smart people have been ignoring the biggest challenges of IT.
"90%+ of people in IT aren't brilliant, a large proportion aren't even good"
That's the problem right there. Doesn't matter what they use be it Clojure, REST, WS-*, Databases, Java, etc, they will produce rubbish.
Ultimately it's lack of talent and IT's minimal efforts to invest in quality staff because they cost more (as defined by the obvious metrics like pay rather than something more meaningful such as overall system cost etc).
Even when an IT shop manages to attract someone good, they'll ultimately fail because those around them can't begin to cope (and that goes for management as well as grunts). Inevitably those good people run away screaming to some other place of work.
Dan Creswell
http://www.dancres.org/blitzblog
Dan,
I think that good enterprise IT is where the 10% enable the 90% to work within their powers. This is how building engineering works, brickies aren't the smartest tools in the box but the engineers break down the problems so everyone does their job well.... this is done via clear definitions and contracts.
So I think that a good enterprise programme is one where the technology supports that separation. WS-* does this in a way that the average developer can understand. This makes it a better practical technology. Clear separations also help train up new people in better ways of working so they can learn.
Too often new technologies have a breath taking arrogance on being "the best" based on someones 20 years of experience which has led them to see the new technology as the most productive for them, and then they extrapolate that to the entire world
"I think that good enterprise IT is where the 10% enable the 90% to work within their powers. This is how building engineering works, brickies aren't the smartest tools in the box but the engineers break down the problems so everyone does their job well.... this is done via clear definitions and contracts."
I think the enablement thing is spot on however:
(a) I don't believe that definitions and contracts is anything like sufficient because the 90% need so much more than that to do a good job. In essence contracts and definitions are the surface of some system not the whole system and there are plenty of ways for the 90% to louse up the internals.
(b) Technologies that enforce the separation you require but as a consequence introduce inadequacies that cost in ways that the 10% see and the 90% don't makes 90% happy but not the 10% ;)
I appreciate the analogy of building engineering (it's one I use myself after all), equally I would observe that all the workers are coached and invested in to a certain standard and if they can't reach that standard they go unemployed. IT in general doesn't have any people-structure that provides a similar environment of acceptable work standards and training/coaching. To some degree it can't because the 10% that would provide such people-structure are turned off by the environment.
Dan, I completely agree that contracts aren't enough, its just that they are the minimum. There are loads of other elements that are required to really make people effective, but without clear contracts you are pretty much always stuffed.
In terms of the 2nd point. I think that in 2% of cases then the inadequacies are a problem and that you see those a lot. In 98% of the occasions the issue is primarily around the people and the technical challenges are more about stopping them doing dumb stuff than having to develop optimal technical solutions.
OK. Few facts:
1. REST is about using in the best way the Web Platform, for large hypermedia transfer apps. It has some interesting constrains, still there is a large body that is trying to get it right and what they are doing is RPC underneath
2. WS is about business. Middleware so far is too much RPC oriented, IT Domain focused. NO space for business contracts.
3. There is no middleware (REST middelware may be an oxymoron), and not so many tools for REST. Actually, the ones out there are missing some important features.
4.REST can be used machine-to-machine, but requires a mind shift, away from RPC.
5. WS should also get away from RPC, since its promises are not honored either.
There is much more that can be discussed, but I have not much time now. Will digest a little bit more.
Cheers
Epiphany !
Steve, where have you been for the last 5 years? Don't you think you could have written this five years ago?
Don't you think we had enough of irresponsible people who just think about their little career and all the money they can put in their pocket, regardless of what they are pushing down the throat of their fellow developers and architects?
Maybe we have a responsibility as an industry to root out these behaviors via careful peer reviews and less politics.
JJ Dubray
Hi,
I just wonder why not using the best of both and do it pragmatic. Doing Restful comunication, but checking the contract via xsd. So is is very easy to post even binaries without base64 them and keep track of the contracts via xsd. We do this in a z/OS world where CICS 3.1 can post truncks bigger than 32k Which is a problem in host-based soap world, where we would have to use mtom .
Why make the world more complicated as it is ?
regards
e.
William,
What you've put aren't really facts, more statements. There is a bit of a difference.
I'm not sure why you are saying that RPC doesn't allow business contracts. Business Contracts aren't about the mechanism they are about the conceptual model and (IMO) the conceptual model makes more sense using an RPC style semantics no matter what your implementation approach. WS-* isn't, strictly speaking, RPC either as its document centric.
REST clearly could be used for machine-to-machine, as could pigeons, but without a formal contractual definition approach its very hard for teams of developers to communicate effectively. This is the point to anon's comment on "use xsd" as well as there is no standardised way of saying what each POST/GET/PUT request does so its all ad-hoc.
JJ, yup really wish I'd raised this 5 years ago ;)
Semi-related question for you Steve. Do you have any book (or other resources) suggestions on introducing the ws-* ecosystem to people that have only used home grown, REST or native interfaces in the past?
I hope Tim Bray reads this by the way...
JJ-
Steve, you should live in another planet. Human beings aren't as smart as you. Referring to what you said, the whole world, the ''industry'' is not getting it. You are the only one who ''gets it''...wow! You should move enterprise IT 20 years forward with your smartness and beat the dumbness of REST and Sun...
What an arrogant way of telling your opinion!!
If 90% of the people aren't brilliant . . . and they can't handle REST . . . then they sure as heck can't handle WS-*
How does Clojure fit in this rant? It's obscure, marginal and not even related to the point at hand about the authors perceived lack of value in REST.
Just needed filler?
Ahhh Anon, loving the vitriol, but I think you may have missed my point. My point on REST, Clojure, et al and the mentality of Sun isn't one of "smart" v "stupid" its about focus and progress. My point is that the "smart" folks have been doing stuff that hasn't improved the lots of the majority.... which sucks.
Frank, there are shops all over the world using WS-*, that is because there are clear interfaces, tools that make the coding easy and hey presto... people can use it. The same can't be said of REST which while powerful is undertooled and conceptually difficult for most people to do right.
Monkeybutt, Clojure comes in as its part of the language proliferation that we've had in the last 5 years which has seen the core enterprise platform (Java) stagnate as the smart folks did stuff that was good for them but rubbish for the majority.
Daniel, I'm struggling to think of a good modern how-to on WS-*... ummmm....
*cough*
CONVERGENCE
*cough*
Sorry, did I say that out loud? Seems to me that this particular argument could do with a little of the magic spread about by the 3 Amigo's when everyone was scratching their collective heads wondering, "what symbols do I use?"
If the WS-* is becoming stagnant, I suspect it's because it's reaching a point of maturity, or at least seniority equivalent to CORBA.
That REST has attracted the cool kids who generate a lot of vocalisation tells the same story from a different angle.
When will the vendors achieve a consolidation of these open standards so that architects can look for the best of REST & WS-* in a single unified approach?
In terms of choosing which approach to take for the next decade, our own program is seriously considering tackling both within it's own architecture.
With a set of requirements for guaranteed delivery, asynchronous messaging over low-latency distributed networks with weather affected satellite connections (i.e. frontline services) there's simply no way we'd embark on a solution that only aimed to tackle REST.
It just won't fit, any more than distributed common RDBMS, direct RPC or RMI integrations.
But I won't design it out at this stage as I trust that convergence in some form will occur. If REST is really emerging as best of breed for HTTP, and SOAP over HTTP is already a best of breed, and HTTP over TCP/IP is so de-facto it's common as muck, then faith placed first and foremost in WS-* won't be misplaced.
I'll take bets on that for the next 10 years.
you seem misguided, and a critique of sun. people like you keep talking while things keep moving.
George, I'm with you. I actually considered REST for parts of my current programme but couldn't due to the inability of the other ends of the pipe to handle it. Its also Metcalf as well as convergence. WS-* is still winning in the real-world as it has a better network effect.
Anon, I could be misguided but evidence of progress would help me get on the "right" track... but oddly there appears to be bugger all evidence of improvement in the last 5 years.
The biggest problem in this discussion is the old IT dilemma, in the end of the day systems made by humans have to be maintained by humans not machines.
New languages, new tools and all new "cool" things are not meant to be easier on the machine side, but on the human side, thats the hole point of it all.
Many people think that hype new stuff its about making the technology better, in general its not, its about results.
Java its not faster than assembler, is just easier and that logic can be transferred to many examples.
WS-* things do need tooling and thats a problem to humans not systems, its no wonder that many people want to break away from this, but even then, they should know the impacts of their choosing, many also dont.
Personal example: I like delphi and i still think its the best solution to desktop enviroments to the day, but in no way i would develop something new in it, not beacause its not good but because my "human" carrer would be jeopardized by it.
In response to REST has put the enterprise back 5 years, I couldn't DISAGREE more. The WS. stack is bloated and overly complex. REST is not a panacea but it can be one tool to reduce complexity. Sometimes companies want to introduce complexity for complexity's sake. It means more consultants and more vendor lock. The SOA/WS* stack has a lot of problems but may be appropriate for some applications.
The open source tool RabbitMQ is going to eventually kick IBM's butt in the queue service business. This is another approach to a protocol pattern.
Don't get stuck with expensive, bloated, "enterprise" solutions. Its a load of bull and so is the premise of this blog post. No offense..just my professional opinion as a Computer Scientist. -Alan Viars
I can suggest one reason that REST has not made huge in-roads into the enterprise market.
The REST proponents do not have massive sales budgets to take CTOs out to the golf course.
The vendors aren't pushing REST because they haven't figured out how to make middleware products for RESTful systems.
Steve,
Big vendors aren't being held accountable because quite frankly, customers rarely seem to do this, or participate in the standards process. Just look at the mess of cloud standards out there and how many customers are actually involved.
More than anything though, the problem has been a lack of investment. There isn't enough money in middleware. The push towards WS led to some reasonable improvements in enterprise integration but didn't make the vendors a ton of money -- not enough to maintain the levels of investment they had from 1999 through 2004.
Similarly, it is a pretty hard sell for a startup to set out to build a new generation of middleware "for the rest of us", ie. take the best bits of REST and WS and make it palatable to the average IT shop through frameworks, tooling, and processes. Not only is there a huge market entry barrier, there is a huge learning curve when resegmenting such a mature market, and there is a huge legacy that leads to slow change. All of this is poison to a wannabe venture.
So, basically you're stuck with stagnation, with the innovation happening in fringe areas - web startups, cloud startups and standards, without concern for the average IT guy or enterprise needs. This is a result of the business dynamics that I see.
As for dynamic languages, can you really blame intelligent people from avoiding the slogfest of older, more static environments? Put incentives in for them and they'll come back. One continued incentive is the breadth of libraries available for Java.
But, as I said above, there are huge barriers to new entrants to try to shake things up. Best to hope for would be a consulting business with a side show of open source frameworks under maintenance.
I think the author of this article falls in the 90% category.
It is really strange how you cite REST and Clojure like they are related somehow. It makes you come across as uninformed. I would stick with criticizing REST if I was you because Clojure is a masterpiece. If you don't understand how Clojure can help with enterprise solutions then you have no idea what Clojure is all about.
Anon: You obviously have NO idea what Enterprise computing is about. If you think that Clojure is the answer to all problems then you are in for a big surprise (that is if you can get a job when you are old enough to apply for one).
M
Oziel,
I really don't get the argument that tools aren't human friendly, one of the things that separates us from animals is the amount that we use tools. Everything in IT barring coding direct to silicon uses tools.
Alan, I'll take 100 to 1 on RabbitMQ not "kicking IBM's butt". MQ Series has the sort of connectivity that very very few others can match, and price wise its actually fairly good value.
Darrell its a rather lame excuse to say that its about marketing budgets, if people were buying it then the vendors would support it. WS-* kicked off mainly from the OSS projects (my first WS-* project was Apache->MS which was free on both sides) before the vendors picked it up in a big way. If enterprises could do it better with REST they would be doing it and vendors would be supporting them in that.
Stu, I agree with most of what you are saying except on the dynamic languages thing. Sun (IMO) gave their official blessing to yet another round of dynamic language work through the Java SE 6 debacle. Had they had more clarity of thought and looked more at making Java better rather than throwing the kitchen sink in I think that the smart folks avoiding Java would have stayed to make it better. Opening up the door was just inviting the fragmentation and a bunch of years before rigour kicks back in again.
Anon, I understand Clojure, I like some of its approaches in the same way as I've been a fan of Lisp and a massive fan of Eiffel (still IMO the best Enterprise "language" I've ever used). That doesn't make it suitable for the much enterprise IT, particularly anything that requires application support folks.
Where did I say Clojure is the answer to ALL enterprise problems? I didn't because it isn't. Clojure is however ideally suited for solving a certain class of problems. I've been doing Enterprise Software for over 10 years and know first hand what is difficult to implement with more traditional enterprise technologies (such as Java and .Net, or probably COBOL as I would imagine the language of choice in your case).
It still is not clear to me why you think Clojure is not suitable for use in the Enterprise? I would gather from your last comment (regarding application support folks) that you don't think the skill set is available to support a solution written in Clojure. I absolutely agree with that and would probably not use Clojure on most projects for that very reason. I thought this was an article discussing the technical strengths and weakness of technologies however. Clojure is very new and the functional programming paradigm is foreign to most enterprise application support people. It is gaining strength however and I believe it (or perhaps Scala which I assume you also wouldn't recommend) will someday have a strong foothold in the enterprise market.
Anon, Clojure is certainly one of the better new breed of languages and sure in some small niche it would be fine. The problem is that as soon as you transition from your expensive Clojure developers into support then you are pretty much screwed and from an enterprise perspective its much, much, much better to support one language than support lots no matter how cheap that made the original development most of the costs in a successful applications are OpEx rather than the original CapEx so language fragmentation is a big issue as it increases OpEx.
Steve, you said in one of your comment replies that "REST does not make the biggest problem of distributed systems disappear, namely how to communicate WTF your solution does to other people outside your team and company.". In that case I invite you to take a look at RESTx, which has been built to do just that. Whichever service or resource you have is self-documenting and can be browsed to (discovered) by following links (which is one of the core principles of REST). Furthermore, once you have reached that service / resource, you find human and machine readable descriptions for your enjoyment.
Steve,
Very interesting article. I love the response it generated, both in agreement and disagreement.
I do wish that people could handle being disagreed with, and not stoop to calling the person they disagree with an idiot. We are all geeks, and care about doing application development the best way possible for a given set of circumstances.
Post a Comment