
Anders Hejlsberg: You Can't Maintain Large Programs in JavaScript. - tszming
http://css.dzone.com/articles/you-can-write-large-programs
======
carsongross
And, once again, this is why _WE NEED A BROWSER BYTECODE STANDARD_. Let us all
go to hell in our own way.

There is no reason to lock the browser in a cage half-designed and half-
implemented by an engineer under a tight deadline over a decade ago.

~~~
rwallace
We need a standard wire format for code to be run on browsers. Fortunately we
have one: it's called JavaScript. If you look at the internals of that format,
it happens to be designed to be written directly by humans, but if you find
that design suboptimal (and it would be surprising if it wasn't, considering
it was put together on a ten day deadline with contradictory requirements) you
can ignore it and just treat it as object code to which your favorite language
can be compiled.

Doesn't Google make some internal use of a tool chain that compiles Java to
JavaScript? And then of course there's Dart and CoffeeScript. I'm sure
there'll be more.

~~~
carsongross
You can compile anything into anything, but for the vast majority of
languages, the easiest thing to target with sane semantics is a virtual
machine, not a crazy half-baked language (that I end up coding in for about
40% of my day.) A bytecode standard would free us from the crazy design
decisions of javascript, give us source-level debugging, etc. And it wouldn't
be that hard, given all the fine examples of VMs sitting around.

My sense is that the people that suggest javascript as a compilation target
really don't want competition for javascript in the browser.

~~~
rwallace
> A bytecode standard would free us from the crazy design decisions of
> javascript

Not really, because most of the complication and mess is in the document
object model, not the language syntax. How do you propose to solve that
problem?

> My sense is that the people that suggest javascript as a compilation target
> really don't want competition for javascript in the browser.

You sense incorrectly. I'm not working in that area, I don't have a dog in
that fight. I just think it's a good idea to point out problems with a
proposed solution before somebody goes off and puts a lot of work into trying
to implement it.

------
stiff
The problem with JavaScript is, somewhat paradoxically, too much flexibility.
There are no standard language features for very basic things like namespaces
and modules, also what it provides for OOP is so confusing that it makes
people want to roll their own OO system from scratch. Objects as dictionaries
and first-class functions make it possible to implement those features in
hundreds of ways and almost every JavaScript program tends at least in some
places to use some own, original solution for one of the very basic problems
of structuring programs, because it is so easy to built one. It is good that
this is possible, it is bad that people _have to_ do this (or choose one of
the countless existing solutions) before they can actually write the program
they want to write.

A lot of the problems would go away if the following was part of the language
and present in every browser:

* namespaces/modules

* a sensible OO system people would actually enjoy using

* the ability to require/import/include a file/module

* the functionality Underscore.js provides

Then, at least the basic structure of the code would be consistent across
programs from various people, and I wouldn't have to work out the details of
yet another OO system, yet another way of just laying out the code across
functions/objects each time I want to read another JavaScript program or yet
another way of doing function () {}.bind that works across the browsers (here
the problem is also the long time it takes for the majority of people to
install a browser new enough to adopt the revised standards). And it's not
only about reading code, how do you write an object-oriented refactoring tool
if every program realizes OO in its own distinct way?

The situation is probably slightly better with server side JS where you are
free to adapt the newest version of the language/runtime and also the server-
side frameworks at least to some extend tend to encourage to use a common
structure for all the modules.

~~~
garindra
Your 4 points are exactly why I always use Require.js, Backbone, and
Underscore in all my large projects.

Require.js solves point #1 and point #3. Backbone solves point #2. Underscore
solves, well, point #4.

In my experience, the other important thing to maintain coherence and sanity
while creating large JS apps is to have a system that makes dependencies
between modules very, very clear. Require.js basically also does that for me;
it requires every module to define their dependency on other modules on top of
its file.

I highly recommend people creating large JS apps to at least check it out :
<http://requirejs.org/>

~~~
pilgrim689
What's your largest project that uses these?

~~~
garindra
Let me explain to you the two large projects that I'm currently working on
that are both using Require.js (it's hard to explain one without the other):

The first is basically a web framework that lets you compose a fully working
website from a whole slew of independent, pre-built, unique components. Each
component is made of Require.js modules (like its own HTML, CSS, JS). This
isn't exactly the largest project, but Require.js really comes in handy with
its ability to conditionally load modules (or components, in this context.)
because you simply won't use all the components in the system, and also its
ability to treat pure text file as regular modules (for HTML and CSS part of
the components).

The second is a visual drag-and-drop web builder that lets you visually build
a working end product of the first project that I mentioned. This is a large
project simply because there's usually quite a lot of that you have to do in
order to make a completely visual system work. I simply can't imagine building
this system without explicit module dependency that require.js enables.

~~~
roel_v
But how large are these? E.g. in LOC?

~~~
cwbrandsma
I think a better starting point is defining how large does something need to
be to be significant. Otherwise we are nothing better than the guy in the back
of the room shouting "Does it scale?", which given the amount of context in
the question renders it impossible to answer.

------
damian2000
I believe an underrated factor is the quality of tools (IDEs) available for
the language. E.g. imagine refactoring a 50mb source code C# or Java
application without the help of tools like Visual Studio/Resharper or Eclipse?
I remember trying to write a java app in java 1.0 with just a text editor and
the command line compiler - it was painful as hell, but things have progressed
massively since then..

~~~
keeperofdakeys
Being an OOP language, the interaction between modules is very explicit. This
helps weed out bugs, since "what you wrote" may look close to "what you
meant", but is ultimatly violating some rule of the system. This is one of the
reasons why I find OOP languages good for large, complex systems, but not for
small, hacky programs, since I can't hack around things to implement "just
what I want". Javascript defintely fits into the latter category, and requires
some good engeering for large projects.

~~~
damian2000
I know what you mean and I agree that when used correctly OOP can achieve
great modularity, but an OOP-capable language by itself can't protect you from
spaghetti code just as horrible as any other non-OOP language could produce.

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

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

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

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

------
ivank
Google and a few other companies manage to do this with Closure Library and
Closure Compiler. Compiler's static analysis detects a large set of errors
that you might introduce after a broken refactoring, or just during normal
development. Among the most useful are the missing properties check, and the
type mismatch check.

------
lubos
I watched the video. Just to clarify, his argument is that it's hard to
refactor large programs in javascript. In other words, it's likely that large
web-applications written in javascript will be having difficulties to
innovate. Only time will tell though...

~~~
factorialboy
Umm.. in my personal experience using IntelliJ IDEA for Java and JavaScript
code, the refactoring experience is the same.

~~~
kristiandupont
How could it possibly be? Refactoring a dynamic language will always be more
difficult because you never know exactly what an expression refers to.

~~~
ajuc
In Java you have dependency injection, which is fancy name for calling
constructors/methods with reflection, depending on some XML file or
annotations.

Which makes Java more dynamic at the cost of making it as hard to refactor
automatically, as any dynamical language.

The part of code that doesn't use reflection is the part of code, that would
be easy to refactor, even if it was written in javascript.

~~~
h_r
This comment packs a lot of confusion into very few words. You're conflating a
factory abstraction like Spring with dependency injection.

void foo(Reader r) { / _do stuff with r_ / } ... foo(new BufferedReader(new
FileReader("/log.txt")));

There, I just did dependency injection without a trace of reflection.
Additionally, since everything is statically typed in Java, refactoring is
still vastly simpler than with a dynamically typed language. The few spots in
the code where you might be trying an invalid type cast are just that - a few
spots. Such problems don't permeate the entire codebase as they do with a
dynamic language. And I'm saying this as a huge fan of Clojure and Groovy,
preferring them over Java on the JVM.

[edit: changed "strongly" to "statically"]

------
Jacobi
JavaScript lacks a real library/module system, namespaces and OOP facilities.
I usually spend more time maintaining a JavaScript program than a program
written in Java/C# with equivalent size. That being said, my skills in
JavaScript are limited.

~~~
factorialboy
Umm .. On the server, node_modules / NPM driven modular system (AMD) works
quite well. RequireJS can be used on the client as well.

~~~
ajuc
I especially like the fact, that "importing" module in node returns imported
module, instead of putting it into namespace like it does in Java. It's much
better design.

    
    
       var myModule = require('./module');
    

instead of

    
    
       import com.company.module.Sth;

------
ZenPsycho
I think it's very good that javascript discourages writing large programs.
Large programs are not a desirable goal, and it's rather a disadvantage of
java that it allows and encourages such awful behaviour.

~~~
route66
Have you written mainly todo-apps or do you have by any chance experience
writing payroll software or stock keeping applications for a retailer?

~~~
ZenPsycho
Okay so may I ask what is the point of this question? (edit; I guess asking
for clarification is looked down upon here?)

~~~
route66
As for my reply to your deleted reply:I thought you were tongue-in-cheek.

As for my reply above: "you should not have that problems" does not make them
go away: some problems solved by software are inherently complicated and
cannot be reduced to some simple API calls or a 5kloc code base. Composition
of 100 multiple 5-kloc code bases still makes them a 500-kloc code base with
all mutual dependencies.

Just saying "you should not write so much code" might display inexperience
with problems which fall outside of the currently common javascript apps ...

~~~
ZenPsycho
It perhaps depends on how those 100 multiple code bases were written. I won't
lie and say I have experience with inventory systems. But I will take the
position of the young upstart dipshit and suggest perhaps the reason you end
up writing such huge tangled messes is you just haven't thought of a better
way to do it. Javascript might not be the best tool for such jobs though, the
way the number type works- on its own, makes it impractical for accounting
tasks.

~~~
route66
I'm completely with you that messiness is best tackled by loose-coupling parts
early on. It's only that I found the combinatorics of many small systems not
so much easier to tackle than their monolithic counterpart.

The worst is even that you (or somebody else) begins with good intentions ...
and then , 4 software generations and law changes later, the complexity starts
to smell.

Heijlsberg argues, that javascript will be harder to refactor in those cases.
I can't really disagree with him.

So it find it's not so much lacking thought. The current thought for some is
"let's use javascript", let's see what comes of that... :-)

~~~
ZenPsycho
I couldn't watch the video. I am starting to think though, that the sweet spot
is to not just simply use javascript for everything and hope for the best- or
to use java or something else and enjoy the sweet refactoring IDE glory, but a
synthesis of making well tested components in a static language that you
orchestrate with a scripting language- (if I have a choice, I actually would
probably choose lua). In my experience so far, a lot of tangle often comes
about by a confusion of library code and application code- the two styles of
programming are very different. A module is very structured and regular, while
application code seems to be ad hoc, specific, and irregular. There's nothing
stopping both from being written in the same language, but if you decide that
libraries go in one language, and application code goes in another, there's
smaller risk of the two accidentally forming interdependencies. Then you set
the goal that the dynamic portion of the program is to never exceed 2000 lines
of code- and you have the basis for --- an experiment at least. Since really
that's kind of what we are all doing. It's pretty well known by now I think
that nobody has discovered a One True Way of doing this software stuff.

We haven't really figured out how to write large complicated applications-
Static analysis is no magic bullet, and neither are dynamic languages. I think
what we are seeing is just a kind of physics of the mind- reactions and re-
reactions to unpleasant experiences we've all had, and are trying to avoid,
which leads us to polarise on the static/dynamic divide.

------
edandersen
Steer clear of "enterprise scale" ExtJS 3.x projects - tens of thousands of
lines of javascript code that just duplicates server logic and absolutely
positions text boxes and buttons on the page.

------
some1else
I downloaded the Flow app JavaScript to see how they handle relations and
composed views etc. I swear I could be commiting fixes and new modules to that
codebase a few hours later. With OO, TDD and established conventions you can
achieve reasonable maintainability.

------
phren0logy
Posts like this make me wonder why OCaml isn't much more popular.

~~~
DrJokepu
Functional programming is difficult and the large majority of developers
haven't even heard of it.

~~~
gaius
OCaml is multi-paradigm - the O is for object. Type inference is a huge
productivity win.

~~~
DrJokepu
I'm not super familiar with OCaml but I have written a fair amount of code in
F# which is supposedly based on / very similar to OCaml. In the end I had to
convert it all to C# because none of the others developer at my company could
grok it. I agree with you that the type inference is really neat but writing
F# (and probably OCaml too) consistently in an imperative style is a bit of a
pain in the back; it feels like the langauge is simply not meant to be used
like that. And, as I said, functional programming is difficult and most
programmers never even heard of it. (I wish I could use FP at work but jobs
like that are really rare here in London.)

~~~
pjmlp
If you are able to use C# 4.0 then you have most of the FP concepts already at
your disposal.

------
gsa
The video link for anyone else unable to access the site (it's down at the
moment) [http://channel9.msdn.com/Events/Lang-NEXT/Lang-
NEXT-2012/Pan...](http://channel9.msdn.com/Events/Lang-NEXT/Lang-
NEXT-2012/Panel-Web-and-Cloud-Programming/player?w=640&h=360)

------
factorialboy
Language wars erupt again!

Should it be titled: "Anders Hejlsberg: I Can't Maintain Large Programs in
JavaScript." ?

------
debacle
The same has been said of almost every language in existence.

Let me maintain my larger program in JavaScript. It will require smarter
staff, but the application will be more flexible and change more quickly than
that same large program written in Java or C#.

~~~
pjmlp
smarter staff == higher salaries, not welcome in big companies.

~~~
debacle
If where you're working has a big company mentality, someone in the decision
making process screwed the pooch when they decided on JavaScript as an
application programming language.

~~~
pjmlp
I already answered on a previous post that I only work in big projects where
we stay away of languages like JavaScript for application development.

For us the proper place for JavaScript is the browser, just to do some DHTML
stuff.

------
sausagefeet
Shame the link only talks about the JS part. So much other great stuff in this
video.

------
moron
My favorite thing about JS now coming into wider use is how it drives a
certain class of older hackers bonkers.

It has 0 and -0! The default namespace is global! It has a === operator, for
crying out loud!

For folks who spent a bunch of time writing
AbstractPatternVisitorHandlerFactory classes, it probably looks like the end
of the world at the hands of a bunch of freakin' degenerates.

~~~
redbad
These things, like default global namespace, aren't just bad to a particular
class of gray-beard enterprise developers who build AbstractFactoryFactories
and are correspondingly easy to ridicule. They're _bad_ bad, net-negative
properties of a language. I'm not sure why you would (appear to) defend them.
Can you please clarify?

~~~
marknutter
I imagine the OP isn't defending them, but just remarking about how sick they
are of hearing people bitch about javascript.

------
AutoCorrect
I had a lot of respect for Anders in the Borland days. Now he seems more and
more to be just a Microsoft shill.

------
givan
This is how people that think in oop and love java think, everything that does
not have classes is unmaintable, this is very subjective.

~~~
hamidpalo
It's about the type system.

Dynamic, weak typing makes writing static analysis/refactoring/etc tools
extremely hard, but more importantly makes nearly any compile-time guarantees
impossible. Having your app crash because of a small typo of a member name is
impossible in C++/C#/Java. It happens to me almost once a day with Node/JS.

~~~
gaius
Anyone doing a large project in an weakly-typed language will eventually spend
more time writing unit tests than features.

No-one should even be thinking about unit tests if they are not already using
a language in which all code paths can be evaluated and type-checked at
compile time. Why get a dog and bark yourself?

~~~
sktrdie
This is not why you write tests. You write tests to be sure nothing breaks
when you make changes.

And you should do this with _any_ language, typed or not.

~~~
nnythm
Using a language with static typing means that there are a lot of tests you
don't have to write. Do you remember the units trick from physics? If you
forgot which equation you're supposed to use, keep on using identities until
you're in the units you're supposed to be. Static typing checks that your
units are correct for free.

~~~
brazzy
Well, not entirely for "free", but I do agree that the price is much lower
than what you end up paying eventually for the convenience of dynamic typing.

------
kevinconroy
If you're going to attack Node.js, do it to its face.

~~~
batista
Yes, he's very afraid of Node.js, that's why he said those things. I mean who
is this Anders Hejlsberg guy, criticizing the BEST work of language designer
giants like Brendan Eich and framework masterminds like Ryan Dahl.

