The language of choice is but one of many links in the "secret weapon" chain.
Just as important are:
- the proficiency of the programmers, regardless of language
- the repository of reuseable code, whether public or private
- the startup's skill in analysis, design, testing, and deploying
- the domain knowledge in the market space
- the unassailability of the market position
I'll take a java startup good in these things over a rails shop that isn't.
I would say most of these are considerably more important than the choice of programming language. I write a lot of Java, and though it makes life painful at times I spend a lot more time trying to figure out how things should work from the user's perspective than I do figuring out how to translate that into Java. Distilling to the important features, then making them work together elegantly is tough!
There's a qualitative difference between Java and say Django in how easy that is, though. With Django you can write a couple lines of code and immediately see your results on the screen. Instead of having to figure out how things should work from the user's perspective, you can just try them out and see if they do work from a user's perspective. Often the results are pretty surprising, and suggest new ways that you can make things even better. It's hard to do this when your edit-compile-run cycle consists of "Write new class. Change some lines to include it. Rebuild JAR file. Redeploy. Restart servers."
The advantage of dynamic languages isn't that you get your coding done 5x faster, because most projects don't actually spend all that much time coding. It's that you can do 5x as many iterations in the same amount of time, which changes the way you approach your interaction design.
There are ways of avoiding the long compile/deploy cycle in Java development, but most people don't take the time to learn them. Just like there are ways of writing fairly concise, readable Java, but most of the code written day-to-day is garbage.
> There are ways of avoiding the long compile/deploy cycle in Java development, but most people don't take the time to learn them.
Pointers would be very much appreciated.
I've inherited 50K lines of java of the 'cut-and-paste' variety after one of those 'rockstar ninja' types quit just before product launch and I'm busy refactoring and commenting everything. Currently the ect cycle is on the order of a couple of minutes and I'd really like to get that down to something more manageable.
When I was doing JSF development, I found the real problem was that libraries were often developed without an awareness of how to make it reload-safe. So yeah, it's theoretically possible to hit Save and Refresh and have Tomcat automatically pick up your changes, but in practice I found that all sorts of strange things happened in the 3rd party libraries that made up the middle of our technology stack.
I think one of the main strengths of the Python/Ruby communities is that it's expected that you'll be able to edit a file and immediately have the changes reflected. If this doesn't happen, people complain! While in the Java world, a lot of people (including myself, eventually) just accept it as business as usual, because so many libraries and apps don't work like that.
I'm not sure what you're talking about. If you want to try something you have to code it first. That's true in any language. After that it's just hitting Ctrl+S for me, in any language.
This is just a coincidence, however. Static typing is not where Java fails; Java fails because the language lacks key abstractions and is very verbose as a result. There are plenty of statically-typed languages that are as concise as Perl/Python/Ruby; Haskell immediately comes to mind. (Scala is also good, and compatible with your existing Java.)
Java is an advantage for the corporate world because it lets them look for products and services by filtering on a single word. This advantage has made it very popular.
I entirely agree, OCaml is a particularly fun one for me. I suppose my word choice should have been better, but "dynamic language" was a fairly lazy and easy choice to contrast against big, bad Java.
Yes. This is yet another post against static typing, that does not compare against the best languages the static typing world has to offer. Let's compare with a type-inferencing Hindley-Milner-based language.
Part of what's unfortunate about the attitude of a lot of people in the dynamic language community (honestly, Ruby attracts this far more than Python for some reason) seems to be a complete lack of understanding of why anyone would do anything differently. The same is true the other way, where Java programmers reliant on their IDEs can't imagine working without one, and vice-versa.
Used properly, static typing hurts you in some ways (verbosity, certain kinds of inflexibility) but helps you in other ways (static checking, better tools for discoverability and refactoring). As other people have pointed out, Java itself is also hampered by a lack of a few simple things, like closures and type inference, that could easily be added to the language and that other statically-typed languages have. The JVM is also hampered by the lack of hotswap to let you make changes to a running system at the very least in development, but even that limitation is being worked on by someone as part of the OpenJDK project (who knows if it'll ever make it to the official JDK, though).
There are situations where the tradeoffs are worth it, and situations where they're not. Anyone declaring the superiority of language X in all situations would do well to really try to talk to people who use other languages and understand their strengths and weaknesses instead of just dismissing them as relics of the past or slave laborers.
The thing is that this article makes a lot of assertions and then doesn't provide any compelling evidence for me to believe them.
Ex:
"Java makes doing dangerous (or interesting) things painful." Why? "It protects programmers from themselves." How? "If nothing else, it allows bad code to be isolated and encapsulated away from the rest of the system, protecting the other workers." Huh? Isn't this design, not language? "This comes at the cost of velocity." Huh? The tradeoff isn't immediately present to me.
I'm inherently weary of anyone who claims that dynamic languages with loose types are the end all be all.
I can only speak from experience with PHP, but at some point your app+framework is just so big that I've almost wanted to sacrifice some development time for a little type safety. It really sucks not having a guarantee that somefunction() will always return an array of some object.
Or even worse, taking 5-10 mins to wade through library code to figure out what to call obscure_helper_function() with.
Wouldn't unit tests help with this? I realize they are not the same as type checking, but, at least in the case of what arguments something takes, seems some decent tests would explain how to use it.
No, unit tests will not help with parts of this. Take today for me as an example: I need to update some python code which calls the database through SQLAlchemy. I can't remember half of SQLAlchemy in my head, so I begin digging for what I want in the documentation. No Carrot in 5 minutes. Around 10 minutes in, I find it, just to realize that I am poking at the low-level framework of SA. I hack up the code as I think it works. Application explodes somewhere deep inside SA with a missing cursor.
Then I spend about one hour trying to narrow down how I call the thing incorrectly. I also search for the error message, which prompts an upgrade of psycopg2 for a bug. Doesn't help. In the end, I realize that the calling convention I use is wrong and I should have called the thing differently.
This kind of problem is trivially mitigated with any static type system which is just a little stronger than what Java or C buys you (ocaml, Haskell).
As someone who used to program mostly in Java, but now works mostly in Ruby and Lua, I can say that I enjoy programming in Ruby and Lua more than Java. But I think I was still a fairly productive programmer before I made the switch.
I'm not sure how much of this is due to the languages themselves or the sort of overall culture of how software is developed in each one. You can have 500 character class names and factories that make factories that make factories in both Ruby and Java, but you only see people doing that in Java.
Since many projects end up using a lot of preexisting code in the form of open source or commercial libraries, if the language you're using has a culture of convoluted hierarchies like Java developers often seem to create, then you're going to inherit that pain if you use that software, and it will likely slow you down.
When people say "dynamic languages" what is it that they mean? The typing system? If so, how can typing really effect productivity as drastically as this article (and other people I've heard) claim?
It seems to me that what is really at play here is good language design, good libraries, good sample code, good tutorials, a good community. I honestly don't understand how a statically typed language would be at such a humongous disadvantage to a dynamically typed language.
I ask in ignorance. I spend most of my day in Java and I hate it, but I rarely curse the types... What am I missing here!?
Java's problems are far worse than just typing. I consider lack of lambdas to be much more limiting.
Types contribute greatly to the verbosity and line noise of Java. They also are a big part of the reason design patterns and complex hierarchies are abused in the language. The duck typing that is common in dynamic languages can be a tremendous help for the reuse of code. Open classes also enable code to be reused in ways that had not been intended. These are dangerous features, but used effectively they can result in great productivity.
The writer does not make clear what is meant by "dynamic languages". It could mean any of (for argument's sake) Lisp, Ruby, and PHP.
But I can't see anyone putting those languages on equal footing. Merely being "dynamic" in some sense is insufficient.
Further, the author says, 'I never really considered the “why” of Java, as that would interfere with my unbridled hate. ', leading me to think there's been very little investigation into different type systems.
This comes off as simply "I like Rails over Java".
Fair enough (and the last point certainly is true). My use of "dynamic languages" was a lazy way of referring to several less strict, highly expressive languages. I used it in the sense that Yegge used it in his talk that I link to. While writing it, I had Ruby, Python, and Smalltalk in mind.
I should point out that my lack of consideration of Java was more due to my perception of it being C++ (a language that I have written far too much of) without all the fun or peril.
You are entirely correct that it isn't the type system that makes a language, but it does provide a convenient if highly inaccurate way to speak broadly about a set of languages.
I have never found the act of typing code to be the big time sink. The big problem is devising the algorithm for what you are doing, properly selecting libraries and understanding how maintainable the approach you are using is (patterns). Maybe I am in the minority, but the biggest time sink for me is fundamental mistakes I would make regardless of the programming language I am using. I do prefer a dynamically typed language with lambda expressions, though.... certainly faster and more fun.
Certainly. However, look at the typical Spring web application. There's 1000 lines of XML supporting the application, which is three times the size of the equivalent ruby/python application because of all of the mechanics of setting and getting and factories, etc. This is compounded by a culture that values verbosity over GTD.
Java can be written concisely. However, it's fighting against the language, and most of the libraries will prevent you from doing so. That said, it's perfect for consultingware for the same reason: I can't think of a better platform than Spring to develop customized applications based on a common platform. Write a piece of new business logic in a series of classes and maintain an
xml file for each client.
Mind you, the side project I'm working on is in java because it's going to develop into a business for small and medium sized businesses who often are comforted by the idea of hundreds of thousands of people who already work in the domain.
I agree, but what you are talking about is enterprise culture. And in fact, the title of this enitre thread could be: How not having an enterprise culture is the secret weapon of startups. But that would be a useless tautology :-)
Java is just as productive in my opinion, when built and edited in a command line environment. Using Eclipse slows things down quite a bit (but speeds up things like refactoring). I've found myself no more productive with Python since I end up having to find the syntax/type bugs in runtime rather than compile time.
For myself, using C# in the corporate world and Python for my personal projects, I enjoy developing more in Python, and I am therefore more productive (or at least I feel that way.)
C# 4 is very interesting. I also like Python a lot and so far I liked it better than C#, but C# is evolving quickly and in the right direction.
In 4 we get the dynamic invocation, multimethods and the equivalent of Python's getattr/setattr (or ruby's method_missing) functionality.
I have ported a small project back from Python to C# 4 and there are very few places left where the Python code is more concise. In some places the C# is much clearer than Python, so it's a bind I would say.
For most of my projects I cannot use Python anyway because it's simply too slow and uses too much memory, so I'm glad that there is a fast statically typed language that I actually start to like.
Just as important are:
I'll take a java startup good in these things over a rails shop that isn't.