

Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript - gspyrou
http://lostechies.com/derickbailey/2012/06/04/anders-hejlsberg-is-right-you-cannot-maintain-large-programs-in-javascript/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+LosTechies+%28LosTechies%29&utm_content=Google+Reader

======
mickeyp
I've had this discussion with co-workers before about scripting languages, and
in particular Python, as that is what I am working with currently. I feel that
once Python -- or indeed any loosey-goosey language that lack strong types --
programs grow beyond a certain size you easily fall into the "inconsistency
trap", especially if you have many programmers working on the same code base.

You have to be extra diligent with docstrings; unit tests and variable naming,
or invent your own poor, ad hoc type checking with isinstance, or liberal use
of exception handling if you insist on ensuring that Python's duck typing
continues to work in your program.

Invariably you'll end up with two camps: those who feel <dynamic lang> scales
to large codebases, and those who do not; those in the former camp have
(almost never) had to maintain a millions of lines of code before so they do
not know just how helpful having a strict compiler is, and just how hard it is
to refactor or infer the meaning of code due to the dynamic nature of the
language. Linting will only get you so far.

It's perfectly possible to write maintainable, large programs in dynamic
languages, but it is infinitely harder than it should be.

~~~
reycharles
Python is actually strongly typed. For example, 1+"1" will fail in python.
Type errors will (usually) make the program crash. I believe this is a major
plus over javascript when writing and maintaining large programs.

~~~
mickeyp
Yes, crash at runtime. That's no good in a production environment when you can
have hundreds of code paths and no real way of ensuring they are all correct.
Mistakes happen, and code coverage tools are in my experience pretty useless
at ensuring all code paths have been exercised (a theoretically futile task as
well.)

As for strongly typed- yes, that is true, but it is also dynamically typed,
and combined with duck typing you're left with a philosophy that encourages
interchangeable types provided the interface is similar. Strong typing come in
many forms, and you can have strong types and still have a compiler there to
help you out. But of course, no system is perfect.

That's all well and good when you still have a complete, mental overview of
the code and how it interacts at a macroscopic level. That's much harder to do
when you go from 1 to many developers -- especially if you're developing code
to be consumed by other developers.

~~~
illumen
Python has Abstract Base Classes, and also widely used zope.interfaces. These,
along with simplicity, convention(pep8, frameworks), a stable base(stdlib),
packages, a standard unittest framework, and a strong internet community help
python code bases scale.

JavaScript is missing a stable base, packages, ABCs and interfaces, and a
shared testing framework. However many of these are available within separate
communities like for example the jQuery community. jQuery provides a stable
base, plugins, a good community to share code, a standard testing framework, a
way to extend code (plugins) to make it reusable, and now it has a module
system which can be shared with other JavaScript frameworks.

I've been on 10+ JavaScript developer projects with 100+ developers over all.
I've seen JavaScript code reused by one million+ developers. I've seen open
source JavaScript projects with 100+ developers. So I have experienced myself
that it can scale up to a certain point.

As long as the team has the best practice skills to do it that is. JavaScript
is the ultimate spaghetti making machine in the hands of newbies without
direction.

~~~
mickeyp
They can scale, but not every code base is well written. Operating from the
assumption that best practices is always implemented isn't necessarily true.
Sometimes you work with sub-par code or code that was written by someone
skilled but due to time pressure; misunderstanding the requirements; or a
poorly planned architecture means that it does not lend itself to scalability.
That's the problem. You can refactor it, but refactoring code in Python can be
a nightmare compared with tools like Visual Studio that make it a breeze --
plus you get the benefit of having a compiler catch errors for you.

Well-thought-out code will always trump bad code; but that's a truism.

------
willvarfar
"I haven’t listened to the interview so I honestly don’t know if the quote is
taken out of context or not"

WTF? -1 for not trying.

There's a panel discussion with:

    
    
        Erik Meijer (misc, head of Cloud Programmability Team at Microsoft)
        Gilad Bracha (Dart)
        Martin Odersky (most recently Scala)
        Anders Hejlsberg (Turbo Pascal, Delphi, C# etc)
        Peter Alvaro (researcher e.g. datalog)
    

And some ungooglable twerp doesn't actually listen to it?

Argument from authority seems spot-on when you're replying to something they
said.

Make that -2

~~~
roopeshv
in all fairness, that sentence is said more like a passing comment and not a
discussion topic

~~~
willvarfar
I posted the original to reddit/r/javascript so I've got a point to defend ;)

In the video, they do talk about tooling, IDEs, auto-completion, libraries,
dynamic types, and so on. Refactoring tools come up repeatedly.

So you can build up a richer context to the reasoning.

There's even discussion about reasoning about systems made from components
running on different machines, which is not far from what this Derek chap
responds with as his perceived solution.

Its not all tightly packed into a sound-bite.

------
bad_user
Link-bait.

The problem of composability has been debated to death and is in general
recognized to be the biggest problem of our software industry. Even Unix-
derived operating systems come these days with pretty big and monolithic
pieces of software. Even Emacs is technically a big and monolithic piece of
software, at least when compared to Vi.

    
    
         But Derick, You Write Large JavaScript Apps ...
         I write JavaScript applications that appear to be large.
    

Not trying to make an argument about who Derick is, but he's arguing against
Anders Hejlsberg, a very talented software engineer and language designer.
Certainly we should be wary about appeals to authority (just like the one I've
made), however let's not get ahead of ourselves and forget the shoulders of
the giants on which we stand.

------
willvarfar
I struggle to maintain a large system in Python (which, at least, is strongly
typed).

My major banes are:

* performance. You have a hard job retrofitting performance to Python

* typos. Typos that survive my Integration Tests which can never have enough coverage. Stuff that just won't compile in a static language becomes a runtime issue on a dynamic language, and they can hide for months outside the happy path e.g. in some error handing code

* poor libraries. I get nice warm happy feelings about various async server frameworks that last until I have to debug them and stare at their innards and realised they were contributed to and diluted by twits

* pip/virtualenv doing a poor job with native code in modules

At least it has namespaces / modules and such

At least its not common for every 3rd party lib to want to squat on a function
called $

And so on.

Static typing is a major plus when you are beyond the prototyping stage and
heading heading towards the release and maintenance phase.

Which is why I'm on the look out for implicitly strongly statically typed
languages that look like Python :)

~~~
mixmastamyk
Try pyflakes, pylint, etc. They've helped me find a few typos in exception
handlers that are rarely run.

------
dllthomas
Certainly, large programs are harder to maintain than small programs.
Certainly, modularity and encapsulation helps, in any language. The
implication that, therefore, choice of language is irrelevant to
maintainability is spurious.

~~~
vlisivka
Definition of large program is "program, which is hard to maintain". So large
programs are hard to maintain by definition.

~~~
dllthomas
You're referring to a line I never drew. Programs can be larger or smaller in
many dimensions - LoC, complexity, features... Other things being equal, the
smaller program is easier to deal with. We don't need to say "these programs
are large and these are small" to make valid inferences in this area.

------
DanielRibeiro
The original talk: <http://css.dzone.com/articles/you-can-write-large-
programs>

Martin Odersky keeps a sober view on all of this. His insights on
sound/unsound type systems is really good.

Also, Peter Alvaro makes a very good complaint about having a distinction of
library creators and every-day programmers, which the others seem to believe
not only to be true, but also to be inevitable (I obviously side with Peter on
this).

The conversation is much better than this sad remark.

