Hacker News Reader

Comment by pjmlp | Hacker News Reader

You are hitting exactly the main point.

Dynamic languages are very good for prototyping or small scale projects.

But they fail to address the context of programming large scale applications with teams distributed across multiple sites.

View on HN

I'm betting youtube is bigger than all of your sites combined, and they use python.

And good on them. But that doesn't mean it's easy to write large websites in dynamically-typed programming languages, it just means that they are very good at what they do.

No, it doesn't. It doesn't mean anything except that your belief isn't supported by any scientific data (as far as presented in this thread).

And you have no idea how they struggled while developing it. Besides, it's not entirely written in python.

Let's see, each project usually has:

- Multi-site development at least in 3 countries; - Sometimes up to 100+ developers - CI systems - Source code of several MB of source code - Enterprise like infrastructures for Fortune 500 companies - Different skill sets from the "just out of the university" to the "top developer"

Maybe YouTube beats this, but Google only has Phd guys able to crack out crazy algorithms/data structures in minutes. Not typical in most software houses.

YouTube is of a different class of complexity as faced by enterprise developers integrating millions of lines of code across disparate systems.

Enterprise world does not have the Phd developers that YouTube has.

I agree dynamic languages result in smaller codebases, but that's only because they tend to be so much more concise than most statically typed languages.

Also, as for large and complex projects done by distributed teams, I don't have to point much further than Django or Plone to prove dynamic typing works well in that context.

The plural of anecdote is not proof. Heck, it's not even data.

Heck, the examples you give aren't even anecdotes. They're just name-dropping. One would have to be pretty familiar with the codebases in question and the history of their development in order to be able to give a clear assessment of what, if any, impact dynamic typing might have had on them.

Fair enough. They prove large projects built by distributed teams are possible in at least one dynamic language.

There was a time I was familiar with both codebases (I have some catching up to do) and that's why I mentioned them. Both projects carry heavy heritage and are experiencing huge pressures to evolve and both are doing very well (from what I hear on the dev lists).

Sure, but even then one merely has an observation that there are these two large projects that are written in dynamic languages and are being successfully maintained.

That doesn't imply that they are being successfully maintained because they are written in dynamic languages, or despite being written in dynamic languages. And of course there's also the possibility that static vs. dynamic is a wash and doesn't really have an impact at all. Or that the potential impact of going with static or dynamic is heavily influenced by other factors - does the static language have type inference, does the dynamic language support duck typing, stuff like that.

Long story short, correlation does not, in and of itself, imply causation.

In any case, it's mostly an apples to oranges comparison. Observing from my heavily biased toward web applications experience, there aren't as many Python codebases as there are Java ones at least in part because you can do a lot more with a small Python codebase than you can do with a similarly sized Java codebase.

Django and Plone are very tiny code bases compared with the projects I work with.

- Big consultancy company working with lots for Fortune 500 company groups;

- At least 3 development sites active at any time;

- Some projects can have 100+ active developers across sites;

- Several MB of written source code, plus many modules generated via specific DSLs or code generation tools

- The typical enterprise architectures

- Lots of crappy developers in some of the teams

The implications of static typing helps keeping the possible damages under control.

How does static typing help that?

By limiting the damage a single crappy programmer can do.

Everywhere people talk about 'large' teams maintaining a large codebase in this thread, substitute 'mediocre' teams stuck with a poor bloated codebase that is the vehicle for their ambitions. It's just not worth anybody's time to understand its unique needs in detail, especially since any improvement you make today risks being messed up tomorrow.

I can understand using static typing if you already have a large codebase that's statically typed, but is there any reason you'd start a project with a statically typed language?

Yeah the benefits of static typing are front-loaded at the start of a project. I might rewrite in a statically-typed language for performance if it ever needs it, but I wouldn't start statically-typed.

My lisp interpreter above allows me to tear out a lisp function and replace it with a C function, while leaving the unit tests untouched.

Crappy developers for one.

Most enterprise projects with modules developed in offshore, suffer from crappy developers that barely know one single programming language.

Forcing them to write lots of unit tests as required by dynamic languages development leads to nothing.

The only way to minimize broken systems is to use languages that force them to stay on course.

Reply on news.ycombinator.com