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.
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.
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.
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.
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.
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.
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.
I agree that JS code will generally be shorter than Java code because 1) you don't explicitly describe your types, and 2) JS is more expressive and there are things that you can just do more neatly.
However, there are many classes of code and #2 applies more to some than others. If you are writing something algorithmic like Peter Norvig's famous spell checker[1], the primitives of your language make a big difference. On the other hand, if you are writing something that is larger but of lower complexity where your code is more like configuration of a bunch of pages, this makes less of a difference.
Also, it's at least possible that the people who see your code assume a higher standard of maturity than your 6kloc has. We've all tried creating an apparently complete app rapidly, only to work on it for ages afterwards, implementing fault tolerance, graceful degradation etc. etc.
anyone has evidence of similar projects done in java and javascript showing how js is much more expressive?
Sure, the lines end up less wide, but while you gain something by using function() over inner classes, you also end up reinventing package declarations and visibility all the time, so I don't see a clear advantage of one over the other.
(notice: I do understand people will generally do things in Java that they won't in JS, such as adding setters and getters, but I have seen that done in plenty of "big" js libraries, so I doubt that counts.)
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.
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.
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.
Is there any rigorous study more recent than Lutz Prechelt's "An Empirical Comparison of Programming Languages"? That estimates a factor of two difference in lines of code between Java/C/C++ and Python/Perl/Tcl, albeit for a rather small project.
So I've been using "factor of two" as a rough benchmark. Of course, this assumes appropriate library support; if most of the C code implements a priority queue while C++ has that as part of the standard library, then the comparison is invalid.
I don't know if for this Grails comparison if the extra factor of two comes from Groovy or from the effectiveness of Grails over whatever the Java programmers would use for web app development.
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?
> 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.
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...
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).
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.
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.
I had a similar problem - also dismissed Twitter4J etc. as too complicated and wrote a 50 line Java method to send a tweet (signature: tweet(tweet, consumerKey, consumerSecret, accessToken, accessTokenSecret) ).
So presumably it's the culture you don't like, rather than the language.
I don't think you could grow to that size codebase with Javascript.