The Java programming language is powerful, but it has significant limitations for lightweight development. For certain problems, other programming languages such as Ruby may lead to better productivity. This article shows you what’s important for productivity in an application’s language.
I think this kind of “you are more productive in this than in that” are somewhat irritating for people which invested a lot in, well, “that”, but this seem to be quite apprciable, maybe because bruce tate is an estimated java guy.
OTOH in ruby I’ wont write
array.each {|element| puts element}
but just
puts array
😉
In wanting to help expand my IT career possibilities, I’ve been studying and coding in Java/J2EE (among many other things like C, Linux, Perl, C#, etc). The more I’ve learned about Java, and the more I’ve actually used it, and the more I’ve tried to accomplish seemingly simple things (things that should be simple), the more I’ve become irritated with the language/platform/API.
You see, Java is very very very heavy, resource hungry, and endlessly complex. It also forces OOP (a good programming paradigm in certain situations) down your throat.
Not only does the Java programmer have to master all of the subtleties of using encapsulation, polymorphism, inheritance, access modifiers, inner classes, etc, but the Java programmer has to have very solid grasp of the various libraries, both core Java and J2EE, and the endless frameworks that are supposed make implementing those endlessly complex libraries easier, but only end up making it more complex, and then the Java programmer has to master heavy, bloated, complex IDEs like Eclipse or Netbeans or JBuilder, and then the Java programmer has to master proprietary extensions and development environments such as Websphere, Weblogic, or JBoss, and then the Java programmer has to master the juggling of all those libraries frameworks, bloated IDEs, and proprietary extensions, and the subtleties of integrating all of them into making something that scales, is robust, and is managable. Wheeew! (wipes sweat off forehead).
Just like that previous paragraph was one long, painful run-on sentence, Java is one long, painful run-on language/platform/API.
Java devs frequently gripe about the complexity of C++. C++ is a big, powerful, complex language, and takes a fairly long learning curve to master. But, frankly, with all of the aforementioned Java complexity, I find C++ much, much easier.
Therefore, I agree with the article. There are easier, more managable solutions, like Ruby. Perl and PHP and Python, and ASP are also easier. And frankly, C and C++, even with their low level requirement of memory management, are easier.
I’m sure Java devs will disagree. They will vigorously defend the language from which they earn their living. I don’t blame them at all. They have to expend so much effort becoming productive with the endlessly complex language/platform/API, that they have zero time or energy to learn anything else. So naturally they’ll get defensive. I would do the same in their shoes. I actually have a great deal of respect and empathy for Java developers. They have to work their butts off, much more so then programmers who use other languages/platforms/APIs.
The key is to use the right tool for the right job. It doesn’t really make sense to use Java if all you need is a couple dynamic web pages. Something like ASP, PHP, or Perl-CGI makes a lot more sense in those situations. However, if you’re developing a large system, say for a corporate wide intranet, and you need the freedom to switch application servers and/or database servers relatively easily down the road, Java’s heavy-weight approach makes a lot of sense for such a heavy-weight system.
Have you ever attempted to write a large system in C or C++? It’s utter hell to track down memory leaks, pointer arithmetic errors, and several other causes of segmentation faults and the like. Java for the most part takes care of these issues for you. (Yes it is still possible to get memory leaks due to certain subtleties of garbage collection.)
The key is to use the right tool for the job, and to know enough tools so that you can work more efficiently.
“Java devs frequently gripe about the complexity of C++. C++ is a big, powerful, complex language, and takes a fairly long learning curve to master. But, frankly, with all of the aforementioned Java complexity, I find C++ much, much easier.”
You seem to blame Java’s large set of avialable libraries as a measurement of the complexity of the langauge itself. I think this arguement is flawed. It would be like me bashing on C++ because I thought MFC was too complex.
Most Java developers claim that Java is easier then C++ is based on the fact of producing stable code. It is fairly accepted that it takes more expirence with C++ to produce stable code then it does with Java. Only because Java has removed some of the dangers (or features depending on how you look at it) from C++. I learned C++ before learning Java and the learning curve to pick up Java was almost nothing. You sould like a C++ guy that is having problems with Java. If so then you are the first one that I have ever met.
“They will vigorously defend the language from which they earn their living. I don’t blame them at all. They have to expend so much effort becoming productive with the endlessly complex language/platform/API”
I program in many langauges, and I have personally found that if all you need is a scripting langauge, then use a scripting langauge. If you are building a complex system your requirements may be better met by a language like C++, Java, or C#.
“Just like that previous paragraph was one long, painful run-on sentence, Java is one long, painful run-on language/platform/API.”
I hear the underlying meaning of what you are trying to say here. Basically I think what you mean is that Java has many compeating popular libraries and frameworks that do almost the same thing. Choosing between these frameworks can knowing when to use one over the other can be a very daunting task. Servlets, JSP, EJB, and JDBC are really the only frameworks that are introduced as part of the base langauge. There are not many duplications in the base langauge. The rest are 3rd party development, and opensource efforts. It is hard to fault the fact that Java has a very active and competitive community.
Also this issue is not limited to the Java community. Perl is a langauge that has 100’s of duplicate libraries and duplicate functionality. IMO Perl is even worse in this way. Perl has more duplicate libraries then any langauge I have ever seen. Microsoft C++ is no exception. I many cases there are base MFC libraries that are duplicated by CDO, and the later reduplicated by ADO. In C# I can use the managed or unmanaged version of many libraries, and understanding when to use one over the other can be just as daunting.
Overall I think your rant agaist Java is partly true, but not limited to Java. Strangly you seem to only take issue with one langauge????
You have two replies refuting your post, so I thought I would add one in complete and utter support of it.
I used to be a Java developer, but I wouldn’t consider myself that anymore because I don’t really want anything to do with the language.
The two things I dislike about it are that simple things take too many steps to do and Java’s configurations and conventions are burdensome. Anyone who claims otherwise only knows Java.
apples and oranges- use the right tool for the job. java does worlds more than ruby will ever do. for example- i just typed this out on my psp – wrong tool
Why people keep reinventing
the lisp language ever and ever ?
This is a decent article, as it focuses on the useful features available in other languages rather than harping on the static-vs-dynamic typing debate.
While declaring variables and static typing may be annoying to some, I actually find it conveys very useful information when reading other people’s code. That the compiler does type checking also helps when working for a company where the other programmers don’t write automated unit tests.
I’ve seen a lot of these anti-Java articles lately. It seems like a lot of people want to claim that their scripting language of choice (Python, Perl, PHP, Ruby) is better than Java because it lets them write fewer lines of code.
But what’s more important: The amount of time it takes a programmer to write the app, or the performance of the app?
For enterprise apps, I think it’s pretty obvious that the second is more important. And this is where the above languages just don’t measure up to Java. I can’t speak for Ruby, but none of the rest handle threads well (if at all). Do any of them support asychronous I/O, or atomic operations? What about memory managment (I know that Python’s memory management, in particular, is really bad – it looks like it was designed by a CS sophomore for a college project). Do any of them have good JIT compilers? The answer to move of these questions is no.
There is a lot more to choosing a language for enterprise development than whether or not is support continuations and closures.
Ruby + threads. Threading is not so good in Ruby more so on Windows.
Neither Python has good threading. It doesn’t scale well on SMP machines. We built a multithreaded service in Python, and it never uses more than 1 CPU on our 4-way SMP boxes (running Linux). According to our Python guru, the global interpreter lock (GIL) and RC’ng of Python are causing this problem.
The amount of time it takes for a programmer to write the app is more important.
On a side note, I have both Python and Java applications installed on my box. It will shock you to know that all the Python applications on my box appear noticably more responsive than their Java equivalents.
All the Java applications I have ever used have been unresponsive and slow! I am beginning to realize the performance argument pulled out of thin air in favor of Java, against “scripting” languages, are myths.
Well-written Java programs are responsive. Maple 10’s UI is quite responsive, just for example. Others, like certain GTK+ programs, are written in such a manner that hinders responsiveness. There is also more to the performance of a program than its visual latency. Java programs can also be obnoxious because of their memory requirements, startup times, poor integration, and so forth; especially when using a number of them together. They can also suit a wide audience (Azureus is quite popular).
Then I guess well-written Java programs are hard to come accross or develop.
I have used many GTK+ applications, and even the poorly written ones aren’t as sluggish as any of the Java programs I have used.
Well-written Java programs are exceedingly rare in my experience. I certainly don’t consider it the norm.
How on earth do you figure that development time is more important for enterprise apps? For smaller things, I could see that argument, but not for apps which are receiving thousands of requests a second. At that scale, programmer time is a small cost.
For any kind of software development, “enterprise” or
otherwise, the programmer’s time is not a small cost and is
very limited. The less time a programmer spends writing
code, the more time she can spend on testing, collecting
feedback, writing documentation and more pertinent
activities, like redesign iterations or generating revenue.
Once again, the programmer is the most important variable in
software development, not performance, cost or the
“enterprise” application. And her time is money. Almost all
the software houses I know will kill to get programmers that
can get high quality software products out of the door as
quickly as possible. It’s called a high turnover rate,
and businesses love it.
If you are dealing with an application that handles hundreds of thousands of dollars (if not millions) daily, or handles business-critical functions, then the cost of programmer time is comparatively cheap. For most enterprise apps I’m aware of, the primary developers are not the same people testing and writing docs, so those costs should be factored out.
As for producing “high-quality software products out the door as quickly as possible,” that’s just bunk. You can’t quickly turn out quality software – it takes time. You can certainly take shortcuts by using scripting languages, but then performance becomes an issue. At my organization, we would love to use more open-source apps, but often we find that ones written in perl or python just don’t scale to our load, or they were written in languages that have no notion of authentication abstraction, so they’re effectively useless.
The purpose of the application is irrelevant in our
discussion. For all I care, the application could be
counting presidential votes.
I also disagree with the major premise in your comment. The
fact is that with dynamic languages you can produce high
quality software at a shorter time, compared to static and/or
compiled languages.
How well a program scales is not a function of whether or
not it is written in a dynamic or statically compiled
language. How well a program scales is a closely related to
how well it is designed. The same argument is applicable to
a program’s performance.[1]
I don’t understand what you mean by authentication
abstraction, so I have no comments on that.
1 – Read the rant I posted earlier in this thread regarding
the sluggishness of Java applications compared to Python
ones.
IMHO the most important aspect in “enterprise” software development is the reliablity. And because the dynamic typing reduce this reliablity, IMHO this scripting languages never will important for enterprises.
Do you really feel your “enterprise” application is more
reliable because it is statically typed?
Exactly right – use the right tool for the job. Now, in Java’s defense:
I’ve made my living for years off of building software w/ Microsoft technologies. Over the last year I transitioned from using mostly C# & .NET technologies to Java/J2EE, mostly personally and hopefully more often professionally, in the future.
There is no greater innovation and advance in software right now then there is in the Java world. The Java community has taken an already excellent programming language and surged forward w/ concepts such as IoC (Spring Framework) – which is the next logical advance in OOP – a way to prevent writing tons of “glue” pattern code to achieve flexibility. Then there’s O/R Mapping and data-access automation tools like Hibernate, JDO, and iBatis. Naturally, there is much, much more…a tool to solve nearly every single problem imaginable.
Java is an enterprise-class programming platform for building real-world, mission-critical software and systems. It is a true workhorse – a swiss army knife…and will offer programmers a massive array of pre-built (and even open source) software for which to build applications on top of.
You will find no greater maturity + simplicity available to you, as a programmer today. Java has a proven track record and has weathered the storm…and is probably the most popular platform today as well.
My guess is; You would say this about any non-trivial technology because you are quick to dismiss anything that involves more than a very short learning curve.
My advice is; look at the market to see what has become the chosen platform for software development…is it Ruby, PHP or Java (out of those you’ve mentioned.)
C++ easier than Java? I’m going to have to assume you don’t know much about Java…perhaps C++ either.
Using Hibernate, Spring, and Java I can crank out a web application in 1/5 of the time it took me to build an ASP.NET web app. What kind of web apps are you writing w/ C++? How well will your RoR app scale and perform under the pressure of thousands of users? Would you invest thousands as a bet on it if this were your decision to make? How about hundreds of thousands? These are the things enerprise developers must consider when evaluating technologies…as well as what the market will provide them to sustain a solid living.
As for complexity – a programming language is a programming language…and as far as languages Java is no more complex than C# (less-than, in fact) or any other comperable technology. Ruby, PHP, etc. are not comperable…they’re scripting languages which have their place…but don’t belong everywhere. Strong-typing is the biggest difference between Java and Ruby, in my opinion…and after learning a strongly-typed language I personally don’t know why you’d want to go back…why have OOP w/o strong types…OOP is all about types (objects)!!
I found both C# and Java very easy to learn having come from a mixture of scripting, C++, and VB background before that.
BTW – I don’t make a living writing Java code…but now I prefer that I were. The grass is greener, IMO.
The C++ language really more complex then java language (no operator overloading, no multiple inheritance, no templates, no macros, etc in java). The class libraries are another things, there are many complex java libraries, classes, etc in java.
And IMHO the dynamic typing is a way to hell. IMHO most of fanatics of scripting languages and dynamic typing never wrote any big (>50 000 lines of code) application.
You sound like someone who’s bought all the marketing tripe currently surrounding Java.
“There is no greater innovation and advance in software right now then there is in the Java world.”
I’d hate to tell you, but there is nothing innovative or new about Spring, Hibernate, iBATIS, and the other bazillion IoC/AOP and persistence frameworks. Just because it has a cool or fancy name now doesn’t mean it hasn’t existed long before. In fact, this is just adding to the run-off problem. I used to like Java, until 4 years ago – that’s when I realized Java was just marketing fluff, it only sounds good, but it doesn’t actually put out in the real world. It works great for large apps; as long as nothing changes.
Using an framwork stamped ‘AOP’ does not make your code aspect oriented. I’ve seen more abuses of frameworks for doing stupid things than actually be useful with them, such as unnecassarily screwing everything up by trying to beat Spring into something just because they can, they just have to use Spring for everything, no real reason. What should have taken an hour took 3 days instead. Let’s not get started on when we had to move applications to a different servers. Only java.* and javax.* packages used? Check. Migrate servers? Splat. Who has to fix it? I do; not the ones that built the application, that’s for sure, because the only thing they could come up with was “but it’s java, it should just work! Write once run anywhere!”, which unsurprisingly correlates with all the studies on Java where the development team actually has no idea when something doesn’t work. Tip: ANYTHING that is container managed should be assumed as non-portable and implementation specific. This means IoC containers, ORM frameworks, JNDI, EJBs, MVC frameworks, etc. Hell, even servlets. They can be 100% complaint to the spec, but they all still behave stupidly and incompatibly because the spec is always ambiguous, and they never actually thought of how people would use it when coming up with it.
The greatest innovation of Java is that is makes everyone waste time and money by either solving doing stupid things or solving stupid things.
“Using Hibernate, Spring, and Java I can crank out a web application in 1/5 of the time it took me to build an ASP.NET web app.”
Big whoop. And I can turn out a web application complete with error handling, security, documentation and design and reusable components using ASP.NET in 1/4 the time it took our team of 3 to put out the same web app with no error handling, security, documentation or anything else with Spring, Java, JSF and iBATIS. And I make a living out of writing Java code, not .NET. Did I mention the Java version shits itself if you don’t explicitly log out first before logging in again? And it only happened after they shoved Spring onto it (“Hey, let’s use IoC to intialize every object!”)? Is full of security exploits? Writes out ridiculous amounts of data to the client? (And they complain about ViewState. Hah.) Has event queuing problems in JSF (But this is a problem with JSF itself)? It’s very different when you have to think on your own and build your application instead of simply following instructions on a site.
“BTW – I don’t make a living writing Java code…but now I prefer that I were. The grass is greener, IMO.”
Then what are you waiting for? There is great demand for Java consultants waiting to shovel down yet another framework down an unsuspecting dev team. You’ll always be in demand because the application turns into an unmaintainable steaming crap fest (fertilizer for the grass?) in no time. I make a living writing Java code, and I wish I weren’t – but I’m not leaving, at least until I turn at least this boat around.
Oh yes, I’m very cynical when it comes to Java. 100% compliant to the specification but behaves completely differently.
I admit I totally sold on Ruby. This langauge is so well projected, that I could produce something usable in less that one day of play with it. Yes, I’m programmer, but that’s not the point. I did some useful code in C# with same amount of time, yet, I’ve failed at Java.
I don’t know, it’s just me, or Java seems to be not as easy to start with as other languages? I know it’s powerful, I know Java basics (well, it’s C family when it comes to ,,look” of the code) but I’m still getting lost with the framework and classes provided by Java.
Maybe I just haven’t found right tools for the Java.
I just can’t take any language that uses non printable characters to designate code blocks etc. seriously.
Um. You mean Python, right? You’re just clueless or trolling?
That would be Python and if you haven’t tried it I would just keep your mouth shut. I am not a Python fan but the “whitespace” issue just isn’t one when you get going.
I’ve always considered it a feature, myself.
Java’s biggest strengths is that it came about at the right time, has lots of libraries and frameworks (a problem too), and good tools (IDEA, Netbeans, Eclipse).
It’s problems are that it forces a lot of things on you because it attempted to dumb down C++ and then is now playing the “let’s see what we can take from C#” game. There’s just a lot of plumbing, boilerplate code that has to be scaffolded in order to make Java work.
Right tool for the right job, and the job market for Java is still hot, but I would just rather stay away from the language if possible.
Interestingly, except for the server frameworks, Java is pretty much dead in the open source client space – where Mono, Ruby, and Python are pretty strong, along with the traditional non-managed languages like C and C++.
“Interestingly, except for the server frameworks, Java is pretty much dead in the open source client space”
You couldn’t prove it by me! There are several open source Java client packages being used by tens of thousands of developers on a daily basis. Here are just a few of them: Eclipse, Netbeans, jEdit, ArgoUML. Need I say more?
“- where Mono, Ruby, and Python are pretty strong, along with the traditional non-managed languages like C and C++.”
I agree with you on Ruby and Python, but I can’t say I’ve seen very many open source Mono apps out there, especially what you might call “mainstream” ones. While Mono might arguably be technically better than Java, Mono is covered with the taint of Microsoft. I personally would not touch Mono for an open source project if it were the last programming language on earth. For this reason alone, I would use Java over Mono. Yes, Java is controlled by Sun, which could potentially turn around to bite me on the backside, but I know Microsoft is just waiting for enough Mono apps to get out there before dropping the hammer on the open source community.
“You couldn’t prove it by me! There are several open source Java client packages being used by tens of thousands of developers on a daily basis. Here are just a few of them: Eclipse, Netbeans, jEdit, ArgoUML. Need I say more?”
I didn’t know that “desktop space” meant only developer tools. Even if there’re tens of thousands developers using Java desktop applications, they are just a tiny fraction of total desktop users.
Server space and ides….
eclipse sort of slowly is becoming the defacto standard for ides…
also azureus has its fair share of users
The C++ language really more complex then java language (no operator overloading, no multiple inheritance, no templates, no macros, etc in java). The class libraries are another things, there are many complex java libraries, classes, etc in java.
I think people tend to get confused by C++’s multiparadigm nature, and feel if they aren’t using all the language features they are doing something wrong. This is certainly not the case… C++ is a multiparadigm language and if a particular language feature doesn’t fit what you’re trying to implement then you shouldn’t use it.
Java, on the other hand, attempts to force a single paradigm on everything. This doesn’t always work and can be incredibly frustrating, especially when trying to do complex mathematical code with its BigInteger class and no operator overloading.
The key is to use the right tool for the right job. It doesn’t really make sense to use Java if all you need is a couple dynamic web pages. Something like ASP, PHP, or Perl-CGI makes a lot more sense in those situations. However, if you’re developing a large system, say for a corporate wide intranet, and you need the freedom to switch application servers and/or database servers relatively easily down the road, Java’s heavy-weight approach makes a lot of sense for such a heavy-weight system.
Or you could use Ruby on Rails, let ActiveRecord abstract away the underlying database and let the Ruby interpreter abstract away the underlying platform, and you’d be more productive than JSP.
I’ve done som programming to and fro, nothing fancy the biggest being a PHP framwork and a simple app on top of it. From that I learned quite a few trick on how to abuse the dynamic nature of PHP to do my dancing.
Now last semester we did a project in school using Java . Just a swing app with a small testing model underneath.
The interesting part is how I felt comparing the two projects. Doing the PHP thing I felt that I had controll and I did have a great pride in my work. It was a description of what I wanted and it was how I wanted it (ok almost, but I didn’t get more funding, good enough they said 😉
After the Java project I had started to build up a great anger and almost hate aginst the whole thing. Endless hours went into beating java and swing into submission, while following the required coding guidlines we where supposed to learn. After spending about 80hours of coding I finally realized why I hated it so much. Allmost all code I had written was code that didn’t say anything of what I wanted. It was as if I did the compilers job.
Actually I read somwhere that majort parts of the language was designed to be easily generated… That the problem, if the shit can be generated I don’t have to see it. It’s like programming the resulting executable using a hexeditor, just stupid.
Ok I’m ranting but in the end only about 10% av the code actually expressed anything about my vision. The other 90% was just workarounds and idioms to get Java to accept it. I hate stupid people. That goes for languages too.
I’ve written fairly complex web applications using both, and I very much enjoy Ruby’s simple and expressive nature. On the other hand, it’s not nearly as simple to deploy. If you go the Apache/mod_ruby route, you can run into problems if you have similarly-named classes in two deployed apps; the only way to isolate them is to have multiple apache instances and a reverse proxy. Webrick is nice, but it can’t perform as well as Apache for static content, and fast cgi requires learning a different way of writing a web app, and isn’t appropriate in all situations.
It’s just a lot easier to make a .war file you can drop into a servlet container.
Oh gee, this Ruby on Rails thing is becoming a hot topic nowadays often times presented like it is some sort of a step into the future of web development. Well, it is not. If you’re able to see through sugar coating of Ruby and *seemingly* fast development, you will quickly know that RoR is a giant step architectural step backward to the dark days of PHP and Perl applications inextricably tied to the databases they were written for. Fact is RoR is a complete architectural nightmare throwing years of best practices in middleware development out of the window. If you’re new to web development (especially on the large scale), get this through your thick skulls separating data, business loginc and presentation is *extremely* important for the long term viability of the application and RoR seems to be comfortably forgetting about this fact clumping everything into one pile. RoR may be nice for impressing your girlfriend how quickly you can churn out a “Hello World!” database driven app, but in reality it has no real application beyond tiny and short lived proof-of-concept applications.
If speed of development in your thing and you think that Java is some sort of hinderance to that, obviously you’re not using the right tools. Use JSF and a good IDE and you can beat pants off any RoR hack in speed of development. Check out Sun Java Studio Creator as a good example.
> After the Java project I had started to build up a great anger and almost hate aginst the whole thing. Endless hours went into beating java and swing into submission, while following the required coding guidlines we where supposed to learn. After spending about 80hours of coding I finally realized why I hated it so much. Allmost all code I had written was code that didn’t say anything of what I wanted. It was as if I did the compilers job.
It sounds to me like you’re a poor Java programmer, don’t blame the tools for poor craftsmanship.
I am a poor java programmer. No question about it.
Mabey I missuse the tools. I should have trusted the visual editor and the code it generated. I should also probably have used a UML to java compiler. I’m shure the meanigful code to meaningless code ratio would improve.
The problem is that I still would be required to read all the junk the generators would have produced.
If you’re able to see through sugar coating of Ruby and *seemingly* fast development, you will quickly know that RoR is a giant step architectural step backward to the dark days of PHP and Perl applications inextricably tied to the databases they were written for.
Like all other object persistence layers, such as WebObject’s EOF, Java’s JDO, .NET’s ADO, or PHP’s Propel, the goal of ActiveRecord is to abstract away the database and even SQL.
Fact is RoR is a complete architectural nightmare throwing years of best practices in middleware development out of the window. If you’re new to web development (especially on the large scale), get this through your thick skulls separating data, business loginc and presentation is *extremely* important for the long term viability of the application and RoR seems to be comfortably forgetting about this fact clumping everything into one pile.
RoR pretty much forces an MVC design pattern. Have you even used it? Your complaint seems to be that it doesn’t do exactly what it does.
Honestly, it seems from your comments that not only have you never programmed with Ruby on Rails, but you don’t even have a clue how it’s designed or implemented. ActiveRecord is the best object persistence API I’ve ever used, hands down.
Ruby on Rails has come up with some very novel and elegant solutions to the problems you describe web application developers encountering here, and therefore these problems simply do not exist in the Ruby on Rails framework.
I’ve written fairly complex web applications using both, and I very much enjoy Ruby’s simple and expressive nature. On the other hand, it’s not nearly as simple to deploy. If you go the Apache/mod_ruby route, you can run into problems if you have similarly-named classes in two deployed apps; the only way to isolate them is to have multiple apache instances and a reverse proxy. Webrick is nice, but it can’t perform as well as Apache for static content, and fast cgi requires learning a different way of writing a web app, and isn’t appropriate in all situations.
There are many, many alternatives (which provide substantially better performance) than mod_ruby. Try FastCGI, FCGID, or SCGI…
I used SCGI with Python for a OLTP web application. Well, the main performance problem with SCGI is that it creates 1 socket per HTTP request (no matter if Apache is using HTTP/1.1 persistent connections).
We did some experiments, and while we could get more than 1000 requests/second from Apache/mod_jk/Tomcat using <10% of CPU (the bottleneck was the network card), we could hardly get more than ~200 requests/second using Apache/mod_scgi/Python/Quixote on the same machine (at 100% CPU usage!).
We modified mod_scgi to use UNIX sockets, it improved the performance, but it’s still slower than mod_jk/Tomcat.
Whoever made the comment that you should use the right tool for the job is absolutely 100% correct.
It seems to me that everytime this argument is brought up 9 out of 10 programmers who respond are only working on web applications (and really simple ones at that). Lets remember that for enterprise applications the web is just one type of client that the system as a whole is serving. For financial/logistical/scientific enterprise applications the web tier is just a small piece of the pie, and in a well designed system could be developed in a completely different language.
I am a developer that works on a large logistics application and mostly work in Java however none of my work has anything to do with the web. A good J2EE application server such as JBoss for example provides an amazing array of services and reliability and security for developing applications, I could not even imagine writing this our application in c++, python, ruby anything else (except maybe .net) as they just don’t have the application support structure that a J2EE container provides you. Our application handles around 300 million transactions a day, if we need more performance it is as easy as slotting in a few more jboss servers, it pretty much takes care of the rest.
At the same time I do a lot of web development outside of work, usually fairly simple sites not doing much more than simple database transactions with some data manipulation. i would definitely not use something as complex as the fullblown J2EE for this. Possibly I would just use JSP but I choose to do work in PHP or am just now getting into ruby on rails.
You don’t need a humvee to drive to the grocery store, but I sure would prefer one if I was at war.
To all who believe Java is this slow, massive language, consider that cell phone in your pocket. Yep, it probobly runs Java applications. Mine does, and they’re pretty sweet. Did you know you can write a Java interpreter in less than 100k?
In fact, the language itself is very lightweight. That’s why it can be used in embedded devices. The libraries often used to write programs with, especially GUI libraries, are often sluggish.
“Java, on the other hand, attempts to force a single paradigm on everything. This doesn’t always work and can be incredibly frustrating, especially when trying to do complex mathematical code with its BigInteger class and no operator overloading.”
Amen!
This is one of the things that I really really really hate about Java, and find particularily frustrating. Java assumes that OOP is the be-all to end-all of programming, and forces it down your throat. OOP is very useful for certain problem domains (large libraries, GUI toolkits, large projects with interchangable parts), but completely sucks for other things (smaller projects, relational databases, problem domains that are too complex or ever changing to fit neatly into class hierarchies). And applying class hierarchies, as you have to do with Java (in Java, everything is an object, and is derived from some other base class), can have many very hard to detect and subtle problems/bugs. And solving those problems can be as frustrating as hunting down C/C++ memory leaks.
Another poster pointed out the excess, foolish use of the various frameworks – Spring, Struts, Hibernate, etc etc ad naseum. It seems in the Java world, there is a need for consultants to apply the latest fad paradigm or competing framework into every situation, and thus adding to complexity, and making the code much harder to maintain, and much less effective, and super resource hungry, etc. And every framework and API is a big learning curve unto itself. A developer can spend as much learning effort on an individual framework as he/she did with core Java itself. This is evidenced by the fact that over at oreilly.com there is an individual book for every API and framework commonly used in J2EE development. Thus the poor Java dev has to either carry around an encyclopedia of books, or has to have that encyclopedia of knowledge stored in their brains. That’s very very hard.
And yet another poster made a point about never having used a Java app that performed well. That’s been my experience as well. On the desktop, I’ve used stuff like Jedit, Eclipse, Netbeans, JBuilder, Azereus, and a sprinkling of other programs. In each case, the app either looked like crap, performed like crap, or sucked up so much memory that I had to have at least 700+megs of memory, or all of those things. Where as most C/C++ apps, and Perl or Python apps, or even VB apps I’ve used have been quite good, fast, usable, attractive, etc. On the web/server side of things, any web app I’ve used that was J2EE based (Wells Fargo, eBay, mlsnet.com) have been slower than equivelant sized ASP, CGI, or PHP based apps.
Yes, C++ has a great deal of complexity, and yes, you often have to apply some other library (MFC, QT, GTKmm, Boost, etc). But the complexity in C++ comes from it being multi paradigm, and the libraries are less numerous than Java APIs, and you don’t have to worry about a plethora of competing frameworks.
Also, some posters have alluded to Ruby, Perl, Python, etc. as being “just scripting languages” only good for small scale apps. That is incorrect. One only needs to realize that Amazon is largely driven by Perl/CGI to realize that at least Perl can scale to largest environment possible. Also check out the Perl success stories. Python has one as well. Add to that the fact that 70% of the internet is driven by the LAMP stack, which includes Perl, Python and PHP (and Ruby), and the fact that the internet is one massive network, and one has to realize that these mere “scripting” languages do indeed scale, and can be used effectively for the largest projects imaginable.
Finally, due to Sun hype, one might assume that J2EE is the only/best tool for the “network is the computer” concept – that the huge J2EE APIs are what is needed to truly do distributed computing. Well, sorry, this hype is wrong. Take Google, the hottest tech company of the moment. Their technology is built upon huge farms of cheap Intel servers running a customized kernel of Red Hat Linux, and the queries/searches/storage distributed artitecture software driving all of this is software written in house by Google’s excellent engineers, using none other than C/C++. And other end user apps, such as GMail, are written with Python. This is the largest, hottest, most transactions, busiest, most scaled internet business app in the world, and there isn’t a trace of J2EE. Google engineers are smart. They know they need speed, they know they need to keep costs down, they know they need modularity, and they know they need managability, and they know C/C++ gives them these things much better than J2EE. As an extra very significant bonus, the technology they use is free/cheap, and they are not beholden to to some overcharging J2EE vendor (like IBM, BEA, Oracle, Sun, etc).
“Java, on the other hand, attempts to force a single paradigm on everything. This doesn’t always work and can be incredibly frustrating, especially when trying to do complex mathematical code with its BigInteger class and no operator overloading.”
Amen!
This is one of the things that I really really really hate about Java, and find particularily frustrating. Java assumes that OOP is the be-all to end-all of programming, and forces it down your throat. OOP is very useful for certain problem domains (large libraries, GUI toolkits, large projects with interchangable parts), but completely sucks for other things (smaller projects, relational databases, problem domains that are too complex or ever changing to fit neatly into class hierarchies). And applying class hierarchies, as you have to do with Java (in Java, everything is an object, and is derived from some other base class), can have many very hard to detect and subtle problems/bugs. And solving those problems can be as frustrating as hunting down C/C++ memory leaks.
Another poster pointed out the excess, foolish use of the various frameworks – Spring, Struts, Hibernate, etc etc ad naseum. It seems in the Java world, there is a need for consultants to apply the latest fad paradigm or competing framework into every situation, and thus adding to complexity, and making the code much harder to maintain, and much less effective, and super resource hungry, etc. And every framework and API is a big learning curve unto itself. A developer can spend as much learning effort on an individual framework as he/she did with core Java itself. This is evidenced by the fact that over at oreilly.com there is an individual book for every API and framework commonly used in J2EE development. Thus the poor Java dev has to either carry around an encyclopedia of books, or has to have that encyclopedia of knowledge stored in their brains. That’s very very hard.
And yet another poster made a point about never having used a Java app that performed well. That’s been my experience as well. On the desktop, I’ve used stuff like Jedit, Eclipse, Netbeans, JBuilder, Azereus, and a sprinkling of other programs. In each case, the app either looked like crap, performed like crap, or sucked up so much memory that I had to have at least 700+megs of memory, or all of those things. Where as most C/C++ apps, and Perl or Python apps, or even VB apps I’ve used have been quite good, fast, usable, attractive, etc. On the web/server side of things, any web app I’ve used that was J2EE based (Wells Fargo, eBay, mlsnet.com) have been slower than equivelant sized ASP, CGI, or PHP based apps.
Yes, C++ has a great deal of complexity, and yes, you often have to apply some other library (MFC, QT, GTKmm, Boost, etc). But the complexity in C++ comes from it being multi paradigm, and the libraries are less numerous than Java APIs, and you don’t have to worry about a plethora of competing frameworks.
Also, some posters have alluded to Ruby, Perl, Python, etc. as being “just scripting languages” only good for small scale apps. That is incorrect. One only needs to realize that Amazon is largely driven by Perl/CGI to realize that at least Perl can scale to largest environment possible. Also check out the Perl success stories. Python has one as well. Add to that the fact that 70% of the internet is driven by the LAMP stack, which includes Perl, Python and PHP (and Ruby), and the fact that the internet is one massive network, and one has to realize that these mere “scripting” languages do indeed scale, and can be used effectively for the largest projects imaginable.
Finally, due to Sun hype, one might assume that J2EE is the only/best tool for the “network is the computer” concept – that the huge J2EE APIs are what is needed to truly do distributed computing. Well, sorry, this hype is wrong. Take Google, the hottest tech company of the moment. Their technology is built upon huge farms of cheap Intel servers running a customized kernel of Red Hat Linux, and the queries/searches/storage distributed artitecture software driving all of this is software written in house by Google’s excellent engineers, using none other than C/C++. And other end user apps, such as GMail, are written with Python. This is the largest, hottest, most transactions, busiest, most scaled internet business app in the world, and there isn’t a trace of J2EE. Google engineers are smart. They know they need speed, they know they need to keep costs down, they know they need modularity, and they know they need managability, and they know C/C++ gives them these things much better than J2EE. As an extra very significant bonus, the technology they use is free/cheap, and they are not beholden to to some overcharging J2EE vendor (like IBM, BEA, Oracle, Sun, etc).
“Java, on the other hand, attempts to force a single paradigm on everything. This doesn’t always work and can be incredibly frustrating, especially when trying to do complex mathematical code with its BigInteger class and no operator overloading.”
Amen!
This is one of the things that I really really really hate about Java, and find particularily frustrating. Java assumes that OOP is the be-all to end-all of programming, and forces it down your throat. OOP is very useful for certain problem domains (large libraries, GUI toolkits, large projects with interchangable parts), but completely sucks for other things (smaller projects, relational databases, problem domains that are too complex or ever changing to fit neatly into class hierarchies). And applying class hierarchies, as you have to do with Java (in Java, everything is an object, and is derived from some other base class), can have many very hard to detect and subtle problems/bugs. And solving those problems can be as frustrating as hunting down C/C++ memory leaks.
Another poster pointed out the excess, foolish use of the various frameworks – Spring, Struts, Hibernate, etc etc ad naseum. It seems in the Java world, there is a need for consultants to apply the latest fad paradigm or competing framework into every situation, and thus adding to complexity, and making the code much harder to maintain, and much less effective, and super resource hungry, etc. And every framework and API is a big learning curve unto itself. A developer can spend as much learning effort on an individual framework as he/she did with core Java itself. This is evidenced by the fact that over at oreilly.com there is an individual book for every API and framework commonly used in J2EE development. Thus the poor Java dev has to either carry around an encyclopedia of books, or has to have that encyclopedia of knowledge stored in their brains. That’s very very hard.
And yet another poster made a point about never having used a Java app that performed well. That’s been my experience as well. On the desktop, I’ve used stuff like Jedit, Eclipse, Netbeans, JBuilder, Azereus, and a sprinkling of other programs. In each case, the app either looked like crap, performed like crap, or sucked up so much memory that I had to have at least 700+megs of memory, or all of those things. Where as most C/C++ apps, and Perl or Python apps, or even VB apps I’ve used have been quite good, fast, usable, attractive, etc. On the web/server side of things, any web app I’ve used that was J2EE based (Wells Fargo, eBay, mlsnet.com) have been slower than equivelant sized ASP, CGI, or PHP based apps.
Yes, C++ has a great deal of complexity, and yes, you often have to apply some other library (MFC, QT, GTKmm, Boost, etc). But the complexity in C++ comes from it being multi paradigm, and the libraries are less numerous than Java APIs, and you don’t have to worry about a plethora of competing frameworks.
Also, some posters have alluded to Ruby, Perl, Python, etc. as being “just scripting languages” only good for small scale apps. That is incorrect. One only needs to realize that Amazon is largely driven by Perl/CGI to realize that at least Perl can scale to largest environment possible. Also check out the Perl success stories. Python has one as well. Add to that the fact that 70% of the internet is driven by the LAMP stack, which includes Perl, Python and PHP (and Ruby), and the fact that the internet is one massive network, and one has to realize that these mere “scripting” languages do indeed scale, and can be used effectively for the largest projects imaginable.
Finally, due to Sun hype, one might assume that J2EE is the only/best tool for the “network is the computer” concept – that the huge J2EE APIs are what is needed to truly do distributed computing. Well, sorry, this hype is wrong. Take Google, the hottest tech company of the moment. Their technology is built upon huge farms of cheap Intel servers running a customized kernel of Red Hat Linux, and the queries/searches/storage distributed artitecture software driving all of this is software written in house by Google’s excellent engineers, using none other than C/C++. And other end user apps, such as GMail, are written with Python. This is the largest, hottest, most transactions, busiest, most scaled internet business app in the world, and there isn’t a trace of J2EE. Google engineers are smart. They know they need speed, they know they need to keep costs down, they know they need modularity, and they know they need managability, and they know C/C++ gives them these things much better than J2EE. As an extra very significant bonus, the technology they use is free/cheap, and they are not beholden to to some overcharging J2EE vendor (like IBM, BEA, Oracle, Sun, etc).
“Java, on the other hand, attempts to force a single paradigm on everything. This doesn’t always work and can be incredibly frustrating, especially when trying to do complex mathematical code with its BigInteger class and no operator overloading.”
Amen!
This is one of the things that I really really really hate about Java, and find particularily frustrating. Java assumes that OOP is the be-all to end-all of programming, and forces it down your throat. OOP is very useful for certain problem domains (large libraries, GUI toolkits, large projects with interchangable parts), but completely sucks for other things (smaller projects, relational databases, problem domains that are too complex or ever changing to fit neatly into class hierarchies). And applying class hierarchies, as you have to do with Java (in Java, everything is an object, and is derived from some other base class), can have many very hard to detect and subtle problems/bugs. And solving those problems can be as frustrating as hunting down C/C++ memory leaks.
Another poster pointed out the excess, foolish use of the various frameworks – Spring, Struts, Hibernate, etc etc ad naseum. It seems in the Java world, there is a need for consultants to apply the latest fad paradigm or competing framework into every situation, and thus adding to complexity, and making the code much harder to maintain, and much less effective, and super resource hungry, etc. And every framework and API is a big learning curve unto itself. A developer can spend as much learning effort on an individual framework as he/she did with core Java itself. This is evidenced by the fact that over at oreilly.com there is an individual book for every API and framework commonly used in J2EE development. Thus the poor Java dev has to either carry around an encyclopedia of books, or has to have that encyclopedia of knowledge stored in their brains. That’s very very hard.
And yet another poster made a point about never having used a Java app that performed well. That’s been my experience as well. On the desktop, I’ve used stuff like Jedit, Eclipse, Netbeans, JBuilder, Azereus, and a sprinkling of other programs. In each case, the app either looked like crap, performed like crap, or sucked up so much memory that I had to have at least 700+megs of memory, or all of those things. Where as most C/C++ apps, and Perl or Python apps, or even VB apps I’ve used have been quite good, fast, usable, attractive, etc. On the web/server side of things, any web app I’ve used that was J2EE based (Wells Fargo, eBay, mlsnet.com) have been slower than equivelant sized ASP, CGI, or PHP based apps.
Yes, C++ has a great deal of complexity, and yes, you often have to apply some other library (MFC, QT, GTKmm, Boost, etc). But the complexity in C++ comes from it being multi paradigm, and the libraries are less numerous than Java APIs, and you don’t have to worry about a plethora of competing frameworks.
Also, some posters have alluded to Ruby, Perl, Python, etc. as being “just scripting languages” only good for small scale apps. That is incorrect. One only needs to realize that Amazon is largely driven by Perl/CGI to realize that at least Perl can scale to largest environment possible. Also check out the Perl success stories. Python has one as well. Add to that the fact that 70% of the internet is driven by the LAMP stack, which includes Perl, Python and PHP (and Ruby), and the fact that the internet is one massive network, and one has to realize that these mere “scripting” languages do indeed scale, and can be used effectively for the largest projects imaginable.
Finally, due to Sun hype, one might assume that J2EE is the only/best tool for the “network is the computer” concept – that the huge J2EE APIs are what is needed to truly do distributed computing. Well, sorry, this hype is wrong. Take Google, the hottest tech company of the moment. Their technology is built upon huge farms of cheap Intel servers running a customized kernel of Red Hat Linux, and the queries/searches/storage distributed artitecture software driving all of this is software written in house by Google’s excellent engineers, using none other than C/C++. And other end user apps, such as GMail, are written with Python. This is the largest, hottest, most transactions, busiest, most scaled internet business app in the world, and there isn’t a trace of J2EE. Google engineers are smart. They know they need speed, they know they need to keep costs down, they know they need modularity, and they know they need managability, and they know C/C++ gives them these things much better than J2EE. As an extra very significant bonus, the technology they use is free/cheap, and they are not beholden to to some overcharging J2EE vendor (like IBM, BEA, Oracle, Sun, etc).
When I tried to post it, OSNews came back with the forum being too busy. So I naturally re-posted.
Mods, could you please delete the extra copies of my post? Thank you!
I know it’s more popular to either go with what is marketed- Java- or go with something newer and less mature- Ruby- but, I’m going to go out on a limb and suggest that you folks take a look at Smalltalk. Whether it’s open source like Squeak Smalltalk ( http://www.squeak.org )- my preferred GUI environment/OS and programming language – or something for hardcore business like VisualWorks, it is a joy to code in. It is what both Java and Ruby are basing themselves off of, with Java being blended with C++ and Ruby with Perl. Something to check out, one of the few languages that makes programming really fun again!