I think more customers are choosing technology out of fear than good is and many developers are doing a shoddy job standing up to those fears. Customers fear that a world of risk and hurt will come unless they choose "a standard", like Java, C#, or PHP, and by silently bowing in agreement, developers are selling the customer short.
In the advent of highly agile and open source frameworks such as Ruby on Rails (and there are many others), it has never been easier or safer to "experiment" with new technology. Unlike the days of old, it no longer requires an engagement with a vendor and a blind bet on his treasury box of magic tricks. Vendor has turned community and the treasure box has turned transparent.
From the feedback I'm getting, most developers have a pretty good grip on how Rails is going to help them within a few hours. After about a day they're usually pretty convinced. And after a week, all I have talked to are turning out working software at high velocity.
With the barrier for examination so incredible low, there's simple no excuse to instinctively reach for the bow as the first response to fear. As much as it delights me to read Matt Raible write about his enthusiasm with Rails:
After watching the video this morning, it's enough to make me want to become a Ruby developer and use Rails to develop my next webapp.
I'm am equally disappointed by his defeat by default when he his mind wanders on to the possibility of actually using this stuff:
Then again, Ruby probably doesn't pay the bills nearly as well.
So maybe that's just Matt, right? Wrong. This depressing pessimism is pervasive. David Crow chimes in with enthusiasm:
Matt Raible points me to the Ruby on Rails quick setup video. Damn, that is impressive! After spending all weekend fighting with data objects and PHP, I need to spend more time with Ruby and Ruby on Rails.
And then follows the "self-evident truth" of Matt with an immediate dismissal for commercial viability:
Matt's got it right it might not pay the bills, but it looks like I can learn something.
As much as I commend both guys for their interest, kind words, and real enthusiasm, I'm frustrated beyond belief by their lack of energy to fight inertia. How can there ever be a better tomorrow if you're not even willing to contemplate fighting for your enthusiasms of today?
If I do anything of significance with Rails, I hope more than else that it's broadening the horizon of customers by inspiring developers to acquire the will to push for their beliefs and enthusiasms.
Customers are sold short when we as developers accept fear-driven technology choices.
Challenge by Oier on October 26, 12:52
In my last job when I asked the project manager about the reason of using Oracle instead of mysql for a symple webapp. He told me:
"Because if something goes wrong and we use mysql it's my fault , but if we use Oracle is oracle's fault. Nobody gets fired for buying Oracle". The fear is a strong force in the IT enterprise world.
I don't think it's us developers that make "fear driven technology choices", but the companies we work by means of our managers.
Something that has always puzzled me in the IT industry is that non-technical people seem to be making the technical choices for us, eg. what programming language/environment to use. If it was up to me I'd be using the best tools for the job; I'd be writing my parsers in a functional programming language (Clean or Haskell), I'd probably be doing my web application development work in Ruby (on Rails), etc. However this will never happen because management is afraid they can't hire a Clean or a Haskell programmer in case I should ever leave. And Ruby, hell they don't even now what Ruby is.
Management should stop trying to solve the problems that form the developer's domain. Either they trust their developers to do the right thing or they don't in which case they hired the wrong developers.
I totally agree, Guido. What I'm railing against here is that developers by and large have accepted this defeat by ignorant managers.
But I have faith still. Not all managers are ignorant, not all customers are silly. But when developers start believing the opposite to be true and don't even try any more, then both enlightened customers and managers are going to get far less than what they would have otherwise gone along with.
That brings me back to one of the core approaches to moving Ruby on Rails into the enterprise. Don't tell, show! Since the barrier to experimentation is so low, it should be more than possible for the caring developer to create a slice of a system at some point to help bring credit to his argument.
It's about time that developers accepted at least part of the blame for mindless flowing in the mainstream. Develop your persuasion techniques, you're the knowledgeable one (about technical excellence).
Keep the faith. The progress that Rails has made already is very profound. I agree with Dave Thomas's observation that you posted yesterday -- Rails could well be the application that launches Ruby into the mainstream.
It is really up to everyone to evangelize and show, show, show! Show your fellow developers what Rails can do. Show your boss how quickly you can develop applications that are easy to maintain and extend. More importantly, show yourself that you can make a difference by promoting something you believe in.
There are managers and people out there who get it. Look at Linux. It had to overcome the same obstacles but look how much progress has been made.
Keep up the good work David and the extended Rails team.
I could not agree with you more David. My exposure to Ruby came a few years ago while working in Japan. I dismissed the technology and it's alleged capability and even tried to persuade my customer to choose a language with vendor support and a larger developer community. Of course being the typical consultant, I had not even truly given Ruby a try. That was then. Today the system we implemented has been replaced, (the vendor for the COTS package we integrated went bankrupt) and we lost a client because we failed to embrace technology outside of our core expertise. From my perspective, I believe that it is suicide for a technology developer (or company for that matter) to not embrace new technology, especially those that dramatically improve productivity. We are placing two large bets on Ruby and Ruby on Rails....if you ask me we cannot afford not to.
I, as a programmer, like neat toys too. But more important to a company than giving their programmers neat toys is to run a company. That requires several things: A willingness to pick tools and stay with what you picked. A company cannot choose new development languages because they hire a programmer who likes said language and then shift again when he leves after a few years and another one, with different preferences, comes along.
It is important for a company to have things like the ability to easily hire people with the necessary skills to pick up development and to be able to interoperate with existing software and new software from other developers.
As someone who is completely ignorent of Ruby I wonder about a lot of stuff that seems absolutely necessary to me for any development platform.
* Does Ruby support SOAP -- both as a client and a service provider?
* How do I call Ruby-programs/APIs from other languages?
* How do you make gui applications in Ruby? Web isn't the best solution for all types of applications.
* How do you handle integration into the OS? In windows it is pretty necesary to have some kind of integration to Active Directory for most enterprise-style applications. It is a bit easier to wrap similar studd in unix-style OS's.
* How about APIs for COM-interoperability? At least APIs for handling Microsoft Office documents?
* How about encryption? If I want to write an application that communicates securly am I then restricted to SSL/HTTP style development or is it possible to use other algorithms and write your own and will they perform?
You might want to address those concerns in another posting. If you can provide good and easily understood answers, then I think you have a better shot at winning people over than what you get form your "Ruby Good; Conventional Languages Bad" rants.
yes, you have client/server soap (and xmlrpc), you use C libs directly from ruby (no need to write c bindings, even if you can), you have ssl and ssh, you have COM and win32 api access (and lots of win32utils).
I'm not sure that simple ActiveDirectory access exist but there is the standard, LDAP.
But (as I read it) the point was "push whatever you think is good enough in your domain". If you want to build a web thing maybe rails can be a good fit, even if it did' nt had good GUI toolkits (wich it has, FLTK,Tk,Gtk, Qt, Wx and Fox are the first I can think of)
Anyway, I partly agree with the spirit of your post's first part (" you should not change everytime a developer wants"). I would keep my cobol app even if the new Java one was much more shining, but this does not mean I won't ever change anything.
I still think your main problem is aversion to perceived risk, not failure to acknowledge increased developer productivity or decreased costs. Have a look at the Loud Thinking archives; back in '03 you'll find David the Java web app proponent while back in '02 PHP was all that. Catch my drift? What will '05 bring? Will Rails end up as yet another dead SourceForge project, when its supporters have moved on to something newer and shinier? I'm not saying I agree with that line of thinking, but those are some of the questions you need to answer.
Thx Gabriele for your answers. What about calling ruby stuff from my C++ implemented windows exe? Just curious.
I don't really think xmlrpc is as interesting as soap, but that is another matter. I'd like to see someone demonstrate that Ruby can do all those things as easily as a .net framework language or java... I'm just a fairly sceptical guy.
"Nobody ever got fired for buying Oracle" this is prevelant in many larger enterprises. While working for many smaller organizations my colleagues and I were focused on delivering value, this typically meant building the thing that customers would pay the most for in the shortest period of time. It was very simple, there were no politics it was all driven by business value and contribution to the bottom line. Tools like Ruby on Rails are great in these environments both technically and politically.
In larger organizations, the decision about which tools to use are often, as David identifies, are made by others, not developers and technologists. Whether that be Enterprise Standards, CIOs, VPs of IT, consultants or others that might not be developers. They want tools that work and are supported and are broadly accepted in the community. They want Java, C#, SQL (insert your list of acronyms this week its SOAP, WSDL, UDDI, etc.) because there is a large talent pool and a larger experience base. They want tools that are broadly supported that they read about in magazines at the airport.
Selecting a technology that has a single developer (or a much smaller developer base) can be very risky. This very similar to the Innovator's Dilemma (re: Clayton Christiansen). You can't stop doing the things that are your bread-and butter. Large companies want to be on the leading edge, not the bleeding edge. We are perceived as successful because of our risk aversion. This is the "management is afraid they can't hire a Clean or a Haskell programmer in case I should ever leave" sentiment. We have a lot of legacy applications that have a single developer left and a single point of failure. This is extremely scary when your business depends on the application as infrastructure.
The Ruby on Rails demonstration was convincing enough for me to decide to bring it back into our decision making because of the productivity. It is a harder sell but not impossible. But my sell will be over coming the fear experienced by upper management. "We don't have any Ruby programmers" why not just use J2EE it works for lots of other people. We decided on J2EE as our integration layer, you figure it out." Part of my responsibility isn't just to find tools to make my developers more productive, it's to make the business more productive, more effective, and more profitable (actually in my case it's to control expenses). I also have to manage the entire technology stack from hardware -> operating system -> database -> application/integration layer -> development tools -> desktop applications. Making changes requires understanding all of the implications for each of the layers in the technology stack. They like large proven companies, technologies with large talent bases with experience solving their problems. It's why we continue to evaluate and purchase tier-1 ERP systems even as other web services (SAP's xApps have allowed others to enter the fray). I have to select technologies and platforms that will last for an entire application generation (or longer, I still have COBOL programs that I must support and evolve).
It is all about finding the right tool for the right job. Ruby on Rails offers me some fast productive tools for web based solutions. It might not offer the flexibility I need for other enterprise applications. Fear (Only the Paranoid Survive) is what can keep an organization on top, it worked for Andy Grove and Intel. The goal is mitigate risk and yet to remain open to revolutionary ideas and technologies. Ruby on Rails looks very promising.
I am not suggesting that companies should use whatever language or tool their developers come up with. There does need to be some consistency, but that doesn't mean it should be Java across the organisation.
It's my experience that the applications and systems developed are much, much more complex than a particular tool or language. As such learning a new language and or tool requires only a fraction of the amount of time it takes to become familiar with an application or system.
I don't think you need a COBOL programmer to maintain your COBOL programs. You need experienced and flexibel developers that can learn and come up to speed with COBOL quickly. It's just another imperative language.
It's indeed about finding the right tool for the right job. Management should not care whether they do or don't have any Ruby, COBOL, Java, C#, developers. They should care about having flexible and experienced developers that are using the right tool for the right job.
Somehow I doubt that when those managers hire construction workers to build them a house that they would go as far as telling those construction workers what tools to use. They trust the construction workers to know what they're doing. I want them to do the same with their software developers.
The concept of programmers being able to switch from one language to another is not as simple as it may sound. Imagine that you are an experienced C#/Java-programmer and in your job interview you are told that you'd also have to maintain a very old COBOL application.
I personally might want to take another job offer :-).
Fafner: Part of the fun of those jobs are the sleepless nights trying to figure out the new language your 'can-do' attitude got you involved with. Oh, and the hair loss...
Challenge by Morten on October 27, 11:02
I've been a J2EE developer/consultant from 1998 an up until early 2004 where I joined the dark side and became a project manager. Before J2EE, I did my web-based apps using Perl CGI. The change from Perl CGI to J2EE was a thrill. The productivity gains were enormous, and the language features resulted in improved applications (types, exceptions, compile time errors..).
If I were to sit down and write a web-application now, I would go with Rails for the same reason I prefer J2EE over Perl: Productivity and language features. I'm certain that it will give me a competitive advantage. I miss a good code-completing Ruby editor/IDE and the equivalent of Jakarta/Codehaus projects, and I'm still a bit sceptic of performance - but that's a risk I'm willing to take.
I still like J2EE, and I think it has brought a lot of good as a technology. It's been misused and abused also, too many J2EE applications have failed because of "architects" who over-architected them to death in search of the one design to rule them all. I hold them personally responsible for the lack of J2EE successes.
Rails IS NOT struts for the Ruby world. Just thought I'd clear that up after I mis-spoke on one of Matt's blog comments. ;)
Admittedly I don't know much about either Ruby or Rails, but the PHB arguments are valid. It's not that we're fearful of influencing them, but rather they just don't listen. I've been shot down on mySQL, Struts?!?! (had to use homebuilt framework), Spring, Tomcat, and Resin. What's one more to add to the list...
"Finding the right tool for the job" this is exactly the reason I continue to explore and evaluate alternate technologies like Ruby and Ruby on Rails. We have a lot of legacy systems and applications written in a variety of languages. The COBOL ones are most difficult for me, but you are right it is a challenge. The hardest part about picking new technologies is understanding where they fit in my tools or application stack. Ruby looks like a great replacement for the ColdFusion and other web-tier apps we have been building. But can it replace my large-scale enterprise integration layer that currently integrates the web-tier, multiple data sources, (Oracle 8, Oracle 9i, old hierarchical mainframe databases), existing workflows/business process automation tool kits, document imaging, my payroll system, etc. I am convinced that it can eventually. So it's all about finding the right tool for your specific problem.
Challenge by rubyfan on October 27, 19:34
Use fear to your advantage. Something like:
Boss: "But who has ever heard of this Ruby on Rails thingy? Where am I going to find Ruby programmers anyway? ....blah...blah...blah"
You: "Using Ruby on Rails will easily boost our productivity over using J2EE by 2 or 3 X. Do you want our competitors to have that kind of advantage?"
Also, Paul Graham said in one of his essays that Lisp was his secret weapon since he could create applications so much faster in Lisp compared to competitors using C/C++/C#/Java. He doesn't care that Lisp isn't the most widely used language out there, in fact he almost didn't want more developers developing in Lisp so that he could maintain the advantage. Now of course, that means that if you want to use some 'out of the mainstream' tools to boost your productivity then you probably won't be working for PHB Inc. You'll probably be working for yourself.
I think that's a great point. I actually like the idea of Ruby on Rails not being available to big corporate companies because it gives the small guys a very nice edge. Just like the one we got and used to build Basecamp.
Anyone that claims that Lisp can give a development speedup is not to be taken seriously. I've taught lisp at first year comp. science at the university of copenhagen at it is a language entirely unsuited for large scale development.
If someone claim otherwise I suggest that that someone should have his head examined.
Lisp *is* used in large scale development.
At least if you consider airplanes big scale and consider the stuff from itasoftware (graham's society).
Oh, and Viaweb/yahoo store was the first known web application.
Most people don't even know that there are CL implementations as fast as C compilers and with support for 'enteprise' stuff like SOAP or CORBA. Maybe you fall in this category so your opinion on Lisp can be uninformated.
Morten, seeing how I was taught LISP (or should I say S-expressions) at the university of Copenhagen, can I assume that your knowledge of LISP is more or less limited to the curricula of this 3 months course?
Cause then you should probably come to the same conclusion with regard to C++ based on the course also taught at DIKU, which touched a similar rather small subset of the actual possibilities with the language.
The beauty of LISP is how code, data, compile-time, and run-time all blends together and allow for a lot of powerful stuff to be expressed with very little code, and while this is certainly not for everybody, it certainly can make the expert extremely productive.
Yeah, Visual Basic and fortran is also used in large scale development. Basically any language is used in any situation. That doesn't make me ignorant nor does it give everyone a competitive advantage,
Lisp is a crazy development language for anything that is not an academic exercise, I'll stand by that.
Okay that time stamp thing here is sorta scary. I posted before I saw your posting Allan...
I'm not an expert in lisp and I don't think I need to be in order to say what I say. I'm a bit disturbed by the fact that someone uncritically could consider the "blending of compile-time, run-time to allow for a lot of powerful stuff" a good thing.
A lot of languages allows one to express extremly complex things in a neat way that is almost impossible to decipher later. I consider both Lisp and Perl to be languages in that category. Sometimes a languages is better if it forces the programmer to state his intent rather than to have it infered from whatever construct that the language supported.
As an example that I am more fluent with is perl. Regular expressions are neat because you can precisely state your condition in a single expression. At the same time that code becomes unreadable to everyone else, because while it is easy to write a regular expression it is fairly hard to read one!
A language is good if it is good at supporting a programmers mental model of the program and if that language can easily be read. Lisp fails on the last condition.
And btw.: A language does not have to be for everyone, but it does have to be for a lot. Lisp is not for a lot, nor are most other functional language that I like.
I think we are a long way from your original claim that LISP could not speed up the development, anyway:
To blend run-time and compile-time allows a) for the programmer to do less repetitive work when he's actually typing the code and b) to actually have the program adapt at run-time in ways otherwise not possible, which is for example what allows something like Rails (which add class methods at run-time AFAIK).
To say that LISP fails the readability-test is really subjective, I'm sure a LISP programmer thinks my C++ is completely unreadable, but have no problem read another LISP programmers source code.
To say that regular expressions are bad because they are not easily readable, well, yes, that's a valid point (although far from all are unreadable, and LISP is really not like regular expressions with 1-2 character codes for actual constructs), but
a) how often do you actually need to change an existing regular expression?
b) how much time do you save when writing a regular expression instead of a custom parser?
c) if there is a comment saying what the regular expression does, isn't that actually better than 20 lines of source code?
d) isn't the chance of doing a buffer-overflow, off-by-one or similar error when writing a custom parser instead of a regular expression a likely outcome? etc. etc.
So while you can point at one bad thing, I really would not like to be without them! I think a LISP programmer would say something similar about LISP, i.e. yes, the parenthesis suck and prefix notation is unnatural, but use it for a while, and you get used to it.
But as said at the top, this is a long way from whether or not LISP can speed up your development.
Challenge by Vincent Foley on October 28, 5:03
Well, if Lisp is unsuited for large systems, I think you oughta call Orbitz and tell them to stop their flight reservation system... Seriously, times change, people want more powerful systems and languages like Lisp, Smalltalk, Ruby and Python gain more and more popularity to create those, because in so-called "traditional" languages such as C, C++ and Java, the task is too hard, the languages are not flexible enough, which is why flexible languages can create software that is more flexible and in less time (cheaper!)
Challenge by nottlv on October 30, 19:37
While I am quite fond of LISP (though I am primarily a Java developer these days), the Orbitz reservation system is a not quite the example of an entire app coded in LISP that some here would like believe:
"Because of ITA's background in computer science and artificial intelligence, the founders weren't afraid to consider languages outside the normal realm of travel technology. For instance, the conventional programming language for building travel software is Assembly—yes, the same Assembly language from the early days of computing that's just one step up from machine code. Because it was building a Web-based system from the start, Orbitz ditched the travel agencies' assembler legacy and went with Java for about 80 percent of its development efforts. Code that touches data is written in C++, which is considered a more compact and efficient language for performing data-handling tasks.
The high-level algorithms are almost entirely in Lisp, one of the oldest programming languages. You're excused for chuckling, or saying "Why Lisp?" Although the language can be inefficient if used without extreme caution, it has a reputation for compactness. One line of Lisp can replace 20 lines of C. ITA's programmers, who learned the language inside and out while at MIT, note that LISP is highly effective if you ditch the prefabricated data structures. "We're something of a poster child for LISP these days," says Wertheimer. "Lisp vendors love us."
The downside of using a sometimes-maligned language is that it's hard to find good Lisp programmers. Today, only half of ITA's coders are Lisp gurus. For its own Web site, ITA relies on server-side Java, partly because of the availability of capable Java programmers."
I don't know which clients you are dealing with, but we're certainly not seeing any migration to Lisp, Smalltalk, etc. in any of the enterprise clients we deal with.
Of course most outfits make technology choices out of fear. That's normal. Geoffrey Moore (see: http://www.amazon.com/exec/obidos/ASIN/0060517123/) explains it as clearly as anyone.
