5 ms·

I wonder if we all agree what "large programs" are. Our team, for example, we are developing a "large program" in Java (Spring, JSF). It's 13'200+ .java files a

by watt 14y ago

I wonder if we all agree what "large programs" are. Our team, for example, we are developing a "large program" in Java (Spring, JSF). It's 13'200+ .java files and total 54mb of source code + about 90mb of third party .jar (open source) library dependencies. I don't think you could grow to that size codebase with Javascript.

hkolek 14y ago
Not that I disagree, but in my experience a lot of the code in a Java application is just a workaround for the poor expressiveness of the language. A lot of the stuff one has to do in Java to get halfway decent encapsulation/abstraction is just not necessary if you use a more expressive language and write code in a more functional way. Not that JavaScript makes that particularly easy or that it's even a nice language, but it is more expressive than Java. With first class functions and closures alone a lot of the Java boilerplate just vanishes. Not that I want to defend JavaScript, I personally think it's a horrible language, especially for large programs. But I think Java seriously suffers from lack of expressiveness which results in an explosion of classes to implement convoluted design patterns and such. I hope it gets better with Java 8.
- eliben 14y ago
  I always found this argument lacking. In any language you can build the necessary abstractions for higher expressiveness. Sometimes these reach things like auto-generating code from a DSL, but in the long run if a good team is working on a large project, I can believe the amount of code can be 2-5x vs a more expressive language, but not 100x.
  - hkolek 14y ago
    Yes, if you include autogenerating code from a DSL, of course this is true. See Greenspun's tenth rule. But if you have to implement a custom DSL to achieve your goal obviously the language isn't expressive enough to do it. But I agree that the factor is probably not as high as 100x.
  - ozataman 14y ago
    I agree with the 2-5x comment, but I don't think this is the right way to look at it. Taking it to an extreme to demonstrate the point - a good team working on a large project could also just implement a new, more expressive programming language than Java and use that to implement their application. The whole point of language selection is to begin with a more capable toolset.
- nobleach 14y ago
  I don't HATE Javascript. It is a rather limited language. Especially if you're used to the standard Java/C#/C++ way of doing OO programming. Then again, sometimes I just want to instantiate a new object without having to say: Dog dog = new Dog(); I'm lazy and I find that sometimes expressing myself in JS is just what the doctor ordered. But with the lack of a type system, I can get pretty frustrated.
Tichy 14y ago
You wouldn't need that size of a codebase with JavaScript... Java was created (or adapted to) for the benefit of consultants. Therefore it requires complicated frameworks and you can not manage coding Java without an IDE. All this makes it easy for consultants to get long paying gigs. Edit: thanks, downvoters! You are incredibly naive...
- yummyfajitas 14y ago
  Therefore it requires complicated frameworks and you can not manage coding Java without an IDE. Nonsense. I write a lot of java in emacs and use no frameworks at all. It's a simple systems programming language with an excellent standard library and great concurrency support. While many people do abuse Java by plugging AbstractFactoryFactory objects into their framework for procedural programming, that's an issue of bad programmers rather than the language itself (which Java has lots of).
  - Tichy 14y ago
    Then I guess you use your own frameworks and have a very special use case that shields you from the typical pains. Maybe it is possible to use Java in a sane way. But there are for example best practice guidelines by Sun/Oracle. If you try to follow all that stuff, it will be painful. Also most libraries for Java were written other Java developers. For example the other day I tried to send a simple Twitter update with Twitter4J (I think that was the name, might mistake it with another one). After an eternity trying to figure out how to configure OAuth with the AbstractAuthenticationProviderAuthenticatorCredentialsMessUpperInterfaceImpl (which requires clicking through several levels of the API dopcs to get the hang of), I eventually gave up and just used a 10 lines Ruby script instead.
    - yummyfajitas 14y ago
      A twitter4j update, taken directly from their webpage: Twitter twitter = (new TwitterFactory()).getInstance(); Status status = twitter.updateStatus("hello from Twitter4j"); You also need a 4 line twitter4j.properties file containing your assorted tokens and secrets. It's a bit longer than 10 lines, but still pretty straightforward, even with the use of a (probably unnecessary) TwitterFactory. By the way, I said java is a simple systems programming language. It's not what I would reach for if I wanted to update twitter either.
jsherer 14y ago
> I don't think you could grow to that size codebase with Javascript. I disagree. Any substantial JavaScript application can reach this size and more. It all depends on the level of abstraction you choose and the functionality frameworks and libraries provide out of the box. I have written numerous mobile applications in JavaScript and they quickly sprouted to 10-30kloc. The majority of this being API functions to speak with our robust REST API, custom controls extending those provided by the Ext framework, and controller logic.
- swah 14y ago
  IIUC, its not 13000 lines, its 13000 files...
mgkimsal 14y ago
As a couple others have said, you likely wouldn't need a codebase that size in JavaScript, even for an equivalent functionality, because of the type of programming the language allows. A bit OT, but it might prove the point. I'm a Groovy enthusiast, and have done this exercise a few times. I'll give a presentation of Grails - basics of Grails, basics of Groovy, then demonstrate a Grails app. I'll walk through all the functionality of the app, then ask the Java developers in the audience for a guess as to how many lines of code they expect the app takes. I clarify I'm asking for lines of code that I had to write, not necessarily in supporting libraries and such. I still get estimates from the Java devs of 25-30k LOC most of the time. Sometimes someone will be brave enough to estimate 15k. The real answer is closer to 6k.
- dalke 14y ago
  This may just mean that Java developers are poor at estimating LOC, or that you are a much better Groovy developer than they are Java developers. Have you asked Grails/Groovy developers the same question? Have you written equivalent Java code to compare outright?
  - mgkimsal 14y ago
    Good questions, and no. Anecdotally, talking to other Grails developers - ones who have switched from Java - they all acknowledge that they write fewer - often far fewer - lines of code. I agree on the point that people may just be bad estimators, but I was assuming at least some of them have done approximate LOC counts on their own code from time to time to get estimates. I do.
  - ternaryoperator 14y ago
    Agreed. And given that he's just taught the basics of Groovy to the audience, the likelihood of them being able to accurately project how many LOCs it will save them seems pretty low.
    - mgkimsal 14y ago
      That's part of the point, in a way. Not to prove to people how much they don't know in a negative way (but maybe it comes across that way), but to provide a hopefully fairly shocking number to get them to rethink some of their basic assumptions about development. Using even a moderately different toolset can yield dramatically different (and I'd argue usually better) results.
x1 14y ago
Yeah, I don't want to weigh in the JavaScript side of things but I've worked with a ton of "large" Java applications. All of them have been large because... > Everything must be an interface/impl/dao/controller so you get 4 files + hibernate mapping (if not using annotation) + view files. Eventually you have 10 files for every object. > Mid-stream decisions (we need to go from Struts to Spring) that effectively create two separate in-process branches of the code base. > Java developers building their own castle. Some guys "owning" a side of the application and not communicating therefore creating solutions their own way instead of using common libraries. Specifically to your description I would argue whatever you are doing must be in multiple projects or it has been poorly engineered. If it is in multiple projects why couldn't another language take it on?

by watt 14y ago

hkolek 14y ago

Not that I disagree, but in my experience a lot of the code in a Java application is just a workaround for the poor expressiveness of the language. A lot of the stuff one has to do in Java to get halfway decent encapsulation/abstraction is just not necessary if you use a more expressive language and write code in a more functional way. Not that JavaScript makes that particularly easy or that it's even a nice language, but it is more expressive than Java. With first class functions and closures alone a lot of the Java boilerplate just vanishes. Not that I want to defend JavaScript, I personally think it's a horrible language, especially for large programs. But I think Java seriously suffers from lack of expressiveness which results in an explosion of classes to implement convoluted design patterns and such. I hope it gets better with Java 8.

eliben 14y ago
I always found this argument lacking. In any language you can build the necessary abstractions for higher expressiveness. Sometimes these reach things like auto-generating code from a DSL, but in the long run if a good team is working on a large project, I can believe the amount of code can be 2-5x vs a more expressive language, but not 100x.
- hkolek 14y ago
  Yes, if you include autogenerating code from a DSL, of course this is true. See Greenspun's tenth rule. But if you have to implement a custom DSL to achieve your goal obviously the language isn't expressive enough to do it. But I agree that the factor is probably not as high as 100x.
- ozataman 14y ago
  I agree with the 2-5x comment, but I don't think this is the right way to look at it. Taking it to an extreme to demonstrate the point - a good team working on a large project could also just implement a new, more expressive programming language than Java and use that to implement their application. The whole point of language selection is to begin with a more capable toolset.
nobleach 14y ago
I don't HATE Javascript. It is a rather limited language. Especially if you're used to the standard Java/C#/C++ way of doing OO programming. Then again, sometimes I just want to instantiate a new object without having to say: Dog dog = new Dog(); I'm lazy and I find that sometimes expressing myself in JS is just what the doctor ordered. But with the lack of a type system, I can get pretty frustrated.

Tichy 14y ago

You wouldn't need that size of a codebase with JavaScript... Java was created (or adapted to) for the benefit of consultants. Therefore it requires complicated frameworks and you can not manage coding Java without an IDE. All this makes it easy for consultants to get long paying gigs. Edit: thanks, downvoters! You are incredibly naive...

yummyfajitas 14y ago
Therefore it requires complicated frameworks and you can not manage coding Java without an IDE. Nonsense. I write a lot of java in emacs and use no frameworks at all. It's a simple systems programming language with an excellent standard library and great concurrency support. While many people do abuse Java by plugging AbstractFactoryFactory objects into their framework for procedural programming, that's an issue of bad programmers rather than the language itself (which Java has lots of).
- Tichy 14y ago
  Then I guess you use your own frameworks and have a very special use case that shields you from the typical pains. Maybe it is possible to use Java in a sane way. But there are for example best practice guidelines by Sun/Oracle. If you try to follow all that stuff, it will be painful. Also most libraries for Java were written other Java developers. For example the other day I tried to send a simple Twitter update with Twitter4J (I think that was the name, might mistake it with another one). After an eternity trying to figure out how to configure OAuth with the AbstractAuthenticationProviderAuthenticatorCredentialsMessUpperInterfaceImpl (which requires clicking through several levels of the API dopcs to get the hang of), I eventually gave up and just used a 10 lines Ruby script instead.
  - yummyfajitas 14y ago
    A twitter4j update, taken directly from their webpage: Twitter twitter = (new TwitterFactory()).getInstance(); Status status = twitter.updateStatus("hello from Twitter4j"); You also need a 4 line twitter4j.properties file containing your assorted tokens and secrets. It's a bit longer than 10 lines, but still pretty straightforward, even with the use of a (probably unnecessary) TwitterFactory. By the way, I said java is a simple systems programming language. It's not what I would reach for if I wanted to update twitter either.

jsherer 14y ago

> I don't think you could grow to that size codebase with Javascript. I disagree. Any substantial JavaScript application can reach this size and more. It all depends on the level of abstraction you choose and the functionality frameworks and libraries provide out of the box. I have written numerous mobile applications in JavaScript and they quickly sprouted to 10-30kloc. The majority of this being API functions to speak with our robust REST API, custom controls extending those provided by the Ext framework, and controller logic.

swah 14y ago
IIUC, its not 13000 lines, its 13000 files...

mgkimsal 14y ago

As a couple others have said, you likely wouldn't need a codebase that size in JavaScript, even for an equivalent functionality, because of the type of programming the language allows. A bit OT, but it might prove the point. I'm a Groovy enthusiast, and have done this exercise a few times. I'll give a presentation of Grails - basics of Grails, basics of Groovy, then demonstrate a Grails app. I'll walk through all the functionality of the app, then ask the Java developers in the audience for a guess as to how many lines of code they expect the app takes. I clarify I'm asking for lines of code that I had to write, not necessarily in supporting libraries and such. I still get estimates from the Java devs of 25-30k LOC most of the time. Sometimes someone will be brave enough to estimate 15k. The real answer is closer to 6k.

dalke 14y ago
This may just mean that Java developers are poor at estimating LOC, or that you are a much better Groovy developer than they are Java developers. Have you asked Grails/Groovy developers the same question? Have you written equivalent Java code to compare outright?
- mgkimsal 14y ago
  Good questions, and no. Anecdotally, talking to other Grails developers - ones who have switched from Java - they all acknowledge that they write fewer - often far fewer - lines of code. I agree on the point that people may just be bad estimators, but I was assuming at least some of them have done approximate LOC counts on their own code from time to time to get estimates. I do.
- ternaryoperator 14y ago
  Agreed. And given that he's just taught the basics of Groovy to the audience, the likelihood of them being able to accurately project how many LOCs it will save them seems pretty low.
  - mgkimsal 14y ago
    That's part of the point, in a way. Not to prove to people how much they don't know in a negative way (but maybe it comes across that way), but to provide a hopefully fairly shocking number to get them to rethink some of their basic assumptions about development. Using even a moderately different toolset can yield dramatically different (and I'd argue usually better) results.

x1 14y ago

Yeah, I don't want to weigh in the JavaScript side of things but I've worked with a ton of "large" Java applications. All of them have been large because... > Everything must be an interface/impl/dao/controller so you get 4 files + hibernate mapping (if not using annotation) + view files. Eventually you have 10 files for every object. > Mid-stream decisions (we need to go from Struts to Spring) that effectively create two separate in-process branches of the code base. > Java developers building their own castle. Some guys "owning" a side of the application and not communicating therefore creating solutions their own way instead of using common libraries. Specifically to your description I would argue whatever you are doing must be in multiple projects or it has been poorly engineered. If it is in multiple projects why couldn't another language take it on?