6 ms·

Java is just fine for your online service startup development

30 points by ppolsinelli 17y ago

aarongough 17y ago
"We should all be grateful to the dynamic language communities, that with their repeated successes have shown that the "king is naked" and self-referential practices of formal code quality or blind following of methodologies valid for over-ruled corporations are useless advice in many environments, and that a more socially oriented testing and user interface design is what wins for creating online services. But I believe the development language involved is accidental." It's possible that English is not the OP's first language, but even with this in mind nothing in this article makes any sense.
- efsavage 17y ago
  Actually it makes alot of sense. He's saying that the quality and innovation of what you're building is what is important, not the fact that you're using the newest framework. By using a mature language/environment/community you'll be able to spend more time on your real problem and less on reinventing the wheel.
  - MikeMacMan 17y ago
    It's a good point. Frameworks like Rails have had a big influence on the Java ecosystem (Spring MVC, Grails, AppFuse), which goes to show you that it's not Java -the language- that would prevent a startup from considering Java, but rather the enterprisey, overengineered Java frameworks that haven't evolved.
- zaphar 17y ago
  actually his core argument is completely true. There is nothing in java the language that makes it heavy or verbose. The libraries and frameworks associated with java make it seem that way. But there is no reason you can't write fast lean and clean java code. Since doing java regularly I've concluded that java the language doesn't suck. But a lot of java's apis and frameworks do. That's an important distinction to keep in mind.
  - steveklabnik 17y ago
    No, the language itself forces you to be verbose, and the libraries follow. Yegge's "Kingdom of Nouns" makes the point well.
    - bumblebird 17y ago
      Agree to disagree. Nothing in the language forces verboseness for the sake of verboseness.
      - cschep 17y ago
        public static void blah blah blah...
        bumblebird 17y ago
        That is categorically NOT verbosity. "public static void" has zero chance of containing errors. If you make a typo, it won't compile. It's not code, it's just "stuff". It doesn't translate to code. It doesn't "do" anything. If you really can't learn to look past the "stuff" into the code, get your editor to hide it from you if you must. Using "public static void" as an argument is almost as ridiculous as people who cite the lines of code needed to program HelloWorld. Verbosity in a language should be measured in terms of actual code that does stuff. Not characters in source code. For example, would you consider Basic with line numbers to be a verbose language since it has a number at the start of each line? Well no, because those numbers aren't code. Another example: Regexps are extremely terse and compact. Would you rather debug regexps, or java code? Which is easier to work with? Is it easier to make a mistake and introduce a bug in a regexp, or in java code? The argument that less lines/characters = less bugs is not a good one.
        orangecat 17y ago
        "public static void" has zero chance of containing errors. If you make a typo, it won't compile. It's not code, it's just "stuff". It doesn't translate to code. It doesn't "do" anything. It is verbosity. It's less harmful than some other instances because as you note it's extremely unlikely to cause bugs, but it's still noise that detracts from readability by obscuring the code that's actually relevant to the task at hand. Would you rather debug regexps, or java code? Which is easier to work with? If the regexp is expressing a concept that would otherwise take 20 lines of ad-hoc string processing in Java, I'll take the regexp.
ivenkys 17y ago
This is quite a well-argued post with decent examples. A point well worth repeating. Mature language and tools, stable and "fast execution", clean interaction with popular services. Its not sexy but if you are competent enough - it can get the job done and get it done fast.
- ppolsinelli 17y ago
  Thanks.
- samuel 17y ago
  Wasn't it obvious? I mean, this is applicable for almost any language, let it be C++, ASP, TCL or whatever isn't considered trendy anymore but it's proven and stable, and isn't completely unsuited for the task(COBOL, 4GL, RPG...) Takes at the very least a year to became proficient in any language, and spending that time learning about your tools, that's is a luxury a startup doesn't have. Wasn't it pure common sense?
raju 17y ago
Good advice. If you know a technology well, then run with it. Focusing on actually delivering value vs. bragging rights to the latest and greatest dynamic language/framework. On a side-note, I will say this - I am a Java developer (at my day job), and Java-land boasts some of the best tool support there is out there. On the flip side, the refactoring argument does not hold much water. These days almost everything in Java, especially when using any kind of framework means a lot of configuration and wiring using XML, Annotations and other syntaxes (EL - Expression Language comes to mind). Most tools don't see these as live code, so refactoring essentially boils down to a lot of text search and replace. Java-land is learning a lot from the other communities and products out there. I have been told the Play Framework (http://www.playframework.org/ http://www.playframework.org/) has some potential but haven't looked at it yet.
- bad_user 17y ago
  About refactoring ... even if a project is pure-Java, the refactoring-tools are too simple, boiling down to rename class/method/var, extract method/class and things like that which are just too simple for real-world needs (and in practice, kind of useless ... since I've been doing these same ops in dynamic languages with a combination of find / grep / sed / emacs macros... with unit-tests as guard). When you want to radically change the architecture, as it happens when you've got the business/workflow model wrong, these refactoring tools won't help you. My opinion about Java ... the JVM and the available tools kick ass, but the language is a PITA and this shows in the design of many Java-libraries. Things like PlayFramework are a wonder and it takes discipline and perseverance to build things like that (not to mention having the will to break every best practice set out by the community).
- ppolsinelli 17y ago
  That is why we make an effort to keep at a minimum anything that breaks strong typing check. I agree that at times it is impossible, but you can keep it at a minimum.
dasil003 17y ago
And of course the point is that there is nothing in the nature of the language and tools that forces you to use complex solutions. While it is definitely true that there is nothing in the nature of Java that forces you to use the kind of complex solutions often foisted on Java programmers, there definitely is something in the nature of Java that leads to needlessly complex code and heavyweight patterns that are not needed at all in more powerful languages. To me this article just seems like a justification to use Java where none is needed. You can do a startup in any language, and the best one is the one your dev team is most proficient with. Java is the 500-lb gorilla these days and doesn't need any advocacy.
old-gregg 17y ago
If you are a Java expert and know nothing else, roll with it: learning something significantly different from scratch to a degree comparable with your today's Java expertise will take a long time. That part he got right. But if your toolbox is bigger to begin with, I see very little advantages in using Java and his arguments aren't persuading: Java is a memory hog (which matters more than CPU cycles in the era of VPS), Java starts slow - it won't allow fluid workflows like Python/Ruby do. Java doesn't interface well with UNIX or anybody else for that matter. Java-centric libraries and frameworks, while numerous, are tedious to work with: they tend to be over-engineered, overly-relying on XML to an unhealthy degree, hard to navigate and verbose to use. I am coming from Microsoft/.NET and Ruby/Rails background and even after a year of adjusting, everything in JVM-centric world feels overly complex, slow and "rigid". Java people seem to swim in their own definition of object oriented programming and oh my... they stick with it. Even interviewing "Java-minded" people is painful. All in all, I am 100% with the anonymous poster he quoted in the beginning of his post: "Its great for consultants because it means more billable hours" Not in a sense that it takes a lot of typing, but simply because there're lots of excuses to bill more for.
- Tobias42 17y ago
  > Java is a memory hog Tomcat with a simple app installed uses about 60 MB when it's idle and not much more with dozens of parallel requests. With Rails you need about 40 MB per instance for a very simple application. Edit: And Java is lightning fast. An old project of mine running on a tomcat on a crappy VPS with 192 MB RAM serves the home page in about 100 ms, and without any manual caching, although it executes 7 queries to a postgres-db. A simple rails app which I deployed on a VPS with twice as much RAM takes at least ten times as long to deliver the home page. And the only "dynamic" thing that happens on the home page is the formatting of a date. There is no database involved.
  - davidw 17y ago
    Honest question (I've never done Java web stuff): what does that 60MB actually buy you? Rails gives you a whole lot of tools in that space.
rbanffy 17y ago
Isn't this based on the questionable assumption one can be as productive with Java web frameworks as they would be with, say, Rails or Django? Wouldn't the cost of learning a more productive (assuming the initial supposition is incorrect and that there is a difference of productivity between technologies) framework be diluted in the total lifetime of the product? If all you have in your toolbox is a blunt axe, wouldn't it make sense to get a sharper one before you attack the forest? In the end, it all depends on the lifetime of the product. If it's a one iteration release, then go with whatever you already know that solves the problem. If the lifetime of the product tends to infinity, go with the language that expresses the product in the most concise way and manage to learn it well. The vast gray area between these points is where you can place all those fancy languages and frameworks wherever your expertise and product dictate.
hello_moto 17y ago
One common theme I learned when working with Java developers is that there are vast amount of information out there regarding: * Design Patterns (GoF + newer patterns) * OOAD/OOP * Refactoring * TDD, Agile, and XP * "Reusable", "Generalization", "Framework" that Java developers read the topics lightly and apply immediately without taking the time to understand them and when to use them. This doesn't happen much in other programming language communities because I rarely see someone writing design pattern tutorial in Perl. I won't be surprised that we will see these issues again in Ruby...
- minalecs 17y ago
  well, this generalization is a little out of left field, I suggest you go read Zed Shaw's post about rails is a ghetto http://www.zedshaw.com/rants/rails_is_a_ghetto.html http://www.zedshaw.com/rants/rails_is_a_ghetto.html although there are improvements, its still relevant
bham 17y ago
but this is history, boring, and by now not very interesting So it is in the past, boring, and in the past and boring. OK.

30 points by ppolsinelli 17y ago

"We should all be grateful to the dynamic language communities, that with their repeated successes have shown that the "king is naked" and self-referential practices of formal code quality or blind following of methodologies valid for over-ruled corporations are useless advice in many environments, and that a more socially oriented testing and user interface design is what wins for creating online services. But I believe the development language involved is accidental." It's possible that English is not the OP's first language, but even with this in mind nothing in this article makes any sense.

efsavage 17y ago
Actually it makes alot of sense. He's saying that the quality and innovation of what you're building is what is important, not the fact that you're using the newest framework. By using a mature language/environment/community you'll be able to spend more time on your real problem and less on reinventing the wheel.
- MikeMacMan 17y ago
  It's a good point. Frameworks like Rails have had a big influence on the Java ecosystem (Spring MVC, Grails, AppFuse), which goes to show you that it's not Java -the language- that would prevent a startup from considering Java, but rather the enterprisey, overengineered Java frameworks that haven't evolved.
zaphar 17y ago
actually his core argument is completely true. There is nothing in java the language that makes it heavy or verbose. The libraries and frameworks associated with java make it seem that way. But there is no reason you can't write fast lean and clean java code. Since doing java regularly I've concluded that java the language doesn't suck. But a lot of java's apis and frameworks do. That's an important distinction to keep in mind.
- steveklabnik 17y ago
  No, the language itself forces you to be verbose, and the libraries follow. Yegge's "Kingdom of Nouns" makes the point well.
  - bumblebird 17y ago
    Agree to disagree. Nothing in the language forces verboseness for the sake of verboseness.
    - cschep 17y ago
      public static void blah blah blah...
      - bumblebird 17y ago
        That is categorically NOT verbosity. "public static void" has zero chance of containing errors. If you make a typo, it won't compile. It's not code, it's just "stuff". It doesn't translate to code. It doesn't "do" anything. If you really can't learn to look past the "stuff" into the code, get your editor to hide it from you if you must. Using "public static void" as an argument is almost as ridiculous as people who cite the lines of code needed to program HelloWorld. Verbosity in a language should be measured in terms of actual code that does stuff. Not characters in source code. For example, would you consider Basic with line numbers to be a verbose language since it has a number at the start of each line? Well no, because those numbers aren't code. Another example: Regexps are extremely terse and compact. Would you rather debug regexps, or java code? Which is easier to work with? Is it easier to make a mistake and introduce a bug in a regexp, or in java code? The argument that less lines/characters = less bugs is not a good one.
        orangecat 17y ago
        "public static void" has zero chance of containing errors. If you make a typo, it won't compile. It's not code, it's just "stuff". It doesn't translate to code. It doesn't "do" anything. It is verbosity. It's less harmful than some other instances because as you note it's extremely unlikely to cause bugs, but it's still noise that detracts from readability by obscuring the code that's actually relevant to the task at hand. Would you rather debug regexps, or java code? Which is easier to work with? If the regexp is expressing a concept that would otherwise take 20 lines of ad-hoc string processing in Java, I'll take the regexp.

ivenkys 17y ago

This is quite a well-argued post with decent examples. A point well worth repeating. Mature language and tools, stable and "fast execution", clean interaction with popular services. Its not sexy but if you are competent enough - it can get the job done and get it done fast.

ppolsinelli 17y ago
Thanks.
samuel 17y ago
Wasn't it obvious? I mean, this is applicable for almost any language, let it be C++, ASP, TCL or whatever isn't considered trendy anymore but it's proven and stable, and isn't completely unsuited for the task(COBOL, 4GL, RPG...) Takes at the very least a year to became proficient in any language, and spending that time learning about your tools, that's is a luxury a startup doesn't have. Wasn't it pure common sense?

raju 17y ago

Good advice. If you know a technology well, then run with it. Focusing on actually delivering value vs. bragging rights to the latest and greatest dynamic language/framework. On a side-note, I will say this - I am a Java developer (at my day job), and Java-land boasts some of the best tool support there is out there. On the flip side, the refactoring argument does not hold much water. These days almost everything in Java, especially when using any kind of framework means a lot of configuration and wiring using XML, Annotations and other syntaxes (EL - Expression Language comes to mind). Most tools don't see these as live code, so refactoring essentially boils down to a lot of text search and replace. Java-land is learning a lot from the other communities and products out there. I have been told the Play Framework (http://www.playframework.org/ http://www.playframework.org/) has some potential but haven't looked at it yet.

bad_user 17y ago
About refactoring ... even if a project is pure-Java, the refactoring-tools are too simple, boiling down to rename class/method/var, extract method/class and things like that which are just too simple for real-world needs (and in practice, kind of useless ... since I've been doing these same ops in dynamic languages with a combination of find / grep / sed / emacs macros... with unit-tests as guard). When you want to radically change the architecture, as it happens when you've got the business/workflow model wrong, these refactoring tools won't help you. My opinion about Java ... the JVM and the available tools kick ass, but the language is a PITA and this shows in the design of many Java-libraries. Things like PlayFramework are a wonder and it takes discipline and perseverance to build things like that (not to mention having the will to break every best practice set out by the community).
ppolsinelli 17y ago
That is why we make an effort to keep at a minimum anything that breaks strong typing check. I agree that at times it is impossible, but you can keep it at a minimum.

dasil003 17y ago

And of course the point is that there is nothing in the nature of the language and tools that forces you to use complex solutions. While it is definitely true that there is nothing in the nature of Java that forces you to use the kind of complex solutions often foisted on Java programmers, there definitely is something in the nature of Java that leads to needlessly complex code and heavyweight patterns that are not needed at all in more powerful languages. To me this article just seems like a justification to use Java where none is needed. You can do a startup in any language, and the best one is the one your dev team is most proficient with. Java is the 500-lb gorilla these days and doesn't need any advocacy.

old-gregg 17y ago

If you are a Java expert and know nothing else, roll with it: learning something significantly different from scratch to a degree comparable with your today's Java expertise will take a long time. That part he got right. But if your toolbox is bigger to begin with, I see very little advantages in using Java and his arguments aren't persuading: Java is a memory hog (which matters more than CPU cycles in the era of VPS), Java starts slow - it won't allow fluid workflows like Python/Ruby do. Java doesn't interface well with UNIX or anybody else for that matter. Java-centric libraries and frameworks, while numerous, are tedious to work with: they tend to be over-engineered, overly-relying on XML to an unhealthy degree, hard to navigate and verbose to use. I am coming from Microsoft/.NET and Ruby/Rails background and even after a year of adjusting, everything in JVM-centric world feels overly complex, slow and "rigid". Java people seem to swim in their own definition of object oriented programming and oh my... they stick with it. Even interviewing "Java-minded" people is painful. All in all, I am 100% with the anonymous poster he quoted in the beginning of his post: "Its great for consultants because it means more billable hours" Not in a sense that it takes a lot of typing, but simply because there're lots of excuses to bill more for.

Tobias42 17y ago
> Java is a memory hog Tomcat with a simple app installed uses about 60 MB when it's idle and not much more with dozens of parallel requests. With Rails you need about 40 MB per instance for a very simple application. Edit: And Java is lightning fast. An old project of mine running on a tomcat on a crappy VPS with 192 MB RAM serves the home page in about 100 ms, and without any manual caching, although it executes 7 queries to a postgres-db. A simple rails app which I deployed on a VPS with twice as much RAM takes at least ten times as long to deliver the home page. And the only "dynamic" thing that happens on the home page is the formatting of a date. There is no database involved.
- davidw 17y ago
  Honest question (I've never done Java web stuff): what does that 60MB actually buy you? Rails gives you a whole lot of tools in that space.

rbanffy 17y ago

Isn't this based on the questionable assumption one can be as productive with Java web frameworks as they would be with, say, Rails or Django? Wouldn't the cost of learning a more productive (assuming the initial supposition is incorrect and that there is a difference of productivity between technologies) framework be diluted in the total lifetime of the product? If all you have in your toolbox is a blunt axe, wouldn't it make sense to get a sharper one before you attack the forest? In the end, it all depends on the lifetime of the product. If it's a one iteration release, then go with whatever you already know that solves the problem. If the lifetime of the product tends to infinity, go with the language that expresses the product in the most concise way and manage to learn it well. The vast gray area between these points is where you can place all those fancy languages and frameworks wherever your expertise and product dictate.

hello_moto 17y ago

One common theme I learned when working with Java developers is that there are vast amount of information out there regarding: * Design Patterns (GoF + newer patterns) * OOAD/OOP * Refactoring * TDD, Agile, and XP * "Reusable", "Generalization", "Framework" that Java developers read the topics lightly and apply immediately without taking the time to understand them and when to use them. This doesn't happen much in other programming language communities because I rarely see someone writing design pattern tutorial in Perl. I won't be surprised that we will see these issues again in Ruby...

minalecs 17y ago
well, this generalization is a little out of left field, I suggest you go read Zed Shaw's post about rails is a ghetto http://www.zedshaw.com/rants/rails_is_a_ghetto.html http://www.zedshaw.com/rants/rails_is_a_ghetto.html although there are improvements, its still relevant

bham 17y ago

but this is history, boring, and by now not very interesting So it is in the past, boring, and in the past and boring. OK.