11:47 AM EST Saturday, December 22 2007
As a result of reading Steve Yegge's latest blog rant, I have discovered a few new interesting things. Steve's rant is very anti-Java for all the right reasons, but falls apart when it gets to the "So here's what I'm going to do about it" part. He's switching to another language, one that runs on the JVM, but not Lisp, Jython, JRuby or Groovy, but for apparently no good reason, JavaScript. Not that JavaScript is a bad language, but I see reason why you would choose that over Lisp, Python or Ruby, and he fails to offer one.
The good thing is that through the comments of this post I learned about a few things, either directly or indirectly. Some of these thing have been around for a long time, but hey, I'm just learning about them.
First, there is a ground swell of support for Scala. I checked out the docs on their site and does look like a very powerful, expressive language. It seems to have many of the features of Lisp without being a Lisp dialect. It is syntactically Java-ish, but unlike Groovy, which really for some reason just seems like much-needed syntactic sugar for Java, Scala feels lieke a completely different language. In other words, and not that this is saying Groovy is a bad thing, but Groovy really isn't conceptually different than Java, where as Scala is, with things like case classes, for example. This is a language I'll have to look into some more.
There is also a mention of a new List-dialect for the JVM called Clojure. Clojure creator Rich Hickey (you need a blog Rich) recently gave a presentation on Clojure at LispNYC and the audio and slides are there. Clojure has a bunch of interesting ideas in it which he explains in the presentation. Clojure has a literal syntax for vectors (a.k.a arrays, lists) and maps (a.k.a Hashtables, Dicts) in addition to the traditional lisp lists. It is not quite a purely functional language, but strongly encourages it, making it the default programming paradigm over object-orientation. I've been wanting to check out Haskell and Erlang to get familiar with the functional programming paradigm, but Clojure might be a good way to get some exposure to that as well.
Another thing I found is Lisplets, which was created by Rich Hickey as well a few years ago. It is a Java Servlet that packages up the entire environment of an HTTP request, request parameters, cookies, session, etc, into an S-expression that is then handed off to a Lisp interpreter that listens on a socket. Lisp then reads the s-expression, does whatever it does, and then returns data to the Servlet which gets sent to the client. Mod_lisp is based on a similar concept. I think it's kind of interesting to think of web development in this manner, with a definitive layer of abstraction between the processing of request into a data structure, and then processing the request based on that data structure.
Posted in
Technology |
Tags
Clojure, JVM, lisp, Scala, Java, Lisplets |
0 Comments
5:21 PM EDT Tuesday, September 25 2007
I try to stay out of language wars, because they just aren't productive. One thing I have found interesting is that a year ago or so, it seemed to be the Ruby guys picking fights with the Java guys saying "Ruby is better than Java, Rails is better than J2EE". Lately, it's Java guys saying "Java is better than Ruby, JEE/Seam/Struts 2.0/RIFE/Wicket/Some yet to be invented Java framework is better than Rails". I get the sense that most Rails guys have just moved on from arguing with Java guys about this, although some still have a hard time resisting the temptation. It's a hard temptation to resist, because I hate to see people say things about Ruby that I disagree with, and I'd hate to see more people believing the anti-dynamic languages, anti-Ruby FUD. Maybe FUD is a little harsh, but I'm sure other people consider my support of Ruby to be FUD.
I really liked Dion Almaer's response to another "Java is better than Ruby" post:
Quite frankly, at this stage of the game all I care about is having a small team of developers that I respect and enjoy working with.
That's where I'm at too. It's more important to be on a team with developers that you respect. But it's more than respect really, it's more like sharing a common development philosophy. I can envision a scenario where there is a Java developer that I respect, but that same developer just hates Ruby. In that case, we're not likely to be on the same page in terms of the way we think a certain solution should be architected, and that being the case, it's not likely to be a productive situation for either of us. I think for anyone involved in a position of hiring developers, this is a key factor to try to be able to evaluate. First, what is the philosophy of my development team, and then when interviewing candidates, will this developer fit in with the team well. I'm sure there are a lot of factors that contribute to this, but here's a few I can think of:
- What is your preferred development platform?
- What is your preferred method of unit testing?
- What are some of your favorite features of language x?
- What are some of your favorite features of framework x?
- Which database platforms have you worked with, and which do you prefer?
I think anytime you can put together a team of good developers who are on the same page with most of these answers, that team is going to be productive.
Posted in
Technology |
Tags
Ruby, Java |
0 Comments
11:57 AM EDT Friday, September 21 2007
Hilarious.
Posted in
Technology |
Tags
Rails, Ruby, Java |
0 Comments
1:38 PM EDT Thursday, March 15 2007
I was having a discussion with a co-worker today regarding String concatenation in Java. Somewhere along the line, I was told that the Java + operator, when applied to String, was slow when compared to using the append method of StringBuffer or StringBuilder. Tuns out this is a myth, sort of. I wrote a class to test it. This will first concatenate a String 100 times using the + operator, and then build the same string using StringBuilder's append method:
public class StringTest {
private int iterations;
public static void main(String[] args) {
StringTest test = new StringTest(100);
for(int i = 0; i < 10; i++) {
test.concat();
test.append();
}
}
public StringTest(int iterations) {
this.iterations = iterations;
}
private void concat() {
String foo = "";
long start = System.currentTimeMillis();
for(int i = 0; i < iterations; i++) {
foo += "foo";
}
System.out.println("String concat took "+(System.currentTimeMillis()-start)+" ms");
}
private void append() {
StringBuilder sb = new StringBuilder();
long start = System.currentTimeMillis();
for(int i = 0; i < iterations; i++) {
sb.append("foo");
}
System.out.println("String append took "+(System.currentTimeMillis()-start)+" ms");
}
}
The results of this test are:
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
String concat took 0 ms
String append took 0 ms
So, when concatenating 100 strings, using the + incurs no significant overhead. But, if we run the same test concatenating 10000 String instead, these are the results:
String concat took 1812 ms
String append took 0 ms
String concat took 1766 ms
String append took 0 ms
String concat took 1766 ms
String append took 0 ms
String concat took 1812 ms
String append took 0 ms
String concat took 1750 ms
String append took 0 ms
String concat took 1828 ms
String append took 0 ms
String concat took 1750 ms
String append took 0 ms
String concat took 1750 ms
String append took 0 ms
String concat took 1782 ms
String append took 0 ms
String concat took 1750 ms
String append took 0 ms
So the Java String concatenation myth is rooted in fact, but as stated on this article on Java Practices, you should use the + operator whenever you are manually concatenating a bunch of Strings, like String foo = "foo"+x+"bar"+y+"baz"+z;, because for that few of a number of Strings, the code is cleaner using the + operator and the overhead of the operator is insignificant. But, if you are pulling data from an external source and building a large String by concatenating many smaller Strings, the StringBuilder would be better to use.
Posted in
Technology |
Tags
Java |
3 Comments
11:25 AM EDT Thursday, March 15 2007
I know, I know, here we go again, another blog post about Ruby on Rails vs. J2EE. Get ready for a flame war. Why do I say that? Because that's what Ruby on Rails vs. J2EE discussions usually turn into. But today I ran across a really good short comparison of Rails and J2EE by Bruno Fernandez-Ruiz. Here's a great quote:
If you have been doing pure web frontends in Java using JSP and JDBC, well, sorry, I think you should go back and examine Python (Django), Ruby (Rails) and PHP (Yellow Duck, BlueShoes) and stop wasting your time.
But don't take that quote out of context, because here's another thing he says:
J2EE is a distributed component on steroids - so if you don't need distributed components, you don't need J2EE. But if you rely on JMS, JCA, JTA and distributed components, then Rails is not your medicine.
And to sum it up:
Bottom line, Rails and J2EE cover different needs and developer populations. There will surely always be an overlap - and over time they will both mutate to copy features from each other.
This points out how Rails and J2EE are different tools, and one can be better than the other, depending on the requirements of the application. Rather than spending time defending whichever one you happen to be better at, spend time learning more about the other, and learning about which kinds of applications each is appropriate for.
Another thing to point how is that how each platform has the opposite challenge. J2EE has the problem of dealing with how to scale down in terms of complexity. Simply put, simple applications are more difficult than they need to be with J2EE. Rails on the other hand has the problem of dealing with how to scale up in terms of complexity. Rails is great for straight-forward database-backed web applications, but what about dealing with applications that have complex transaction management issues? Using either framework in the wrong situation will result in your application falling victim to the Bittersweet Motel Syndrome.
Posted in
Technology |
Tags
Rails, Ruby, Java, J2EE |
0 Comments