

Why Dynamic Languages are a Startup's Secret Weapon - schleyfox
http://www.pixelmachine.org/2009/10/01/Quick-Nimble-Languages.html

======
jrockway
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.

~~~
schleyfox
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.

~~~
jganetsk
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.

------
akeefer
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.

------
heraclitus
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.

And so on.

------
adatta02
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.

~~~
jamesbritt
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.

~~~
jlouis
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).

------
edw519
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.

~~~
jsankey
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!

~~~
nostrademons
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.

~~~
ZitchDog
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.

~~~
jacquesm
> 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.

------
compay
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.

------
amackera
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!?

~~~
schleyfox
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.

------
keefe
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.

~~~
ibsulon
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.

~~~
fauigerzigerk
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 :-)

------
plinkplonk
Why Better Languages than Java are a Startup's Secret Weapon.

There, fixed the title for you. ;-)

------
donaq
When the smug from this post gets hit by George Clooney's speech, it will be a
perfect storm of self-satisfaction.

I'm no Java supporter, but all those bits about "better programmers" and
"average programmers" was a bit much.

------
yesimahuman
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.

------
megamark16
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.)

~~~
fauigerzigerk
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.

