19 ms·
Anders Hejlsberg: You Can't Maintain Large Programs in JavaScript.
- some1else 14y agoI 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.
- givan 14y agoThis is how people that think in oop and love java think, everything that does not have classes is unmaintable, this is very subjective.
- afsina 14y agoYet Google agrees with him and pushes Dart
- phpnode 14y agoI think they're covered under "think in oop and love java"
- luriel 14y agoI don't think the Go developers "think in oop", and they certainly don't love Java.
- luriel 14y agoNote that Go has no 'classes', and doesn't follow what many people consider mainstream OO principles (eg., inheritance), and many people would say this is one of the things that make it so great, specially in large projects (working out a good type hierarchy, and evolving it over time is extremely difficult and painful). The problem with JavaScript is not lack of 'classes', but a not just dynamic but also very weak type system. Add to that the callback-hell caused by the async model of things like Node.js, and you end up with something very hard to maintain quite fast.
- wcoenen 14y agoWas the argument really about classes? I would have expected this to be about the lack of namespaces. (I can't watch the video, it stops to buffer every second.)
- danmaz74 14y agoBy the way, if all you need is classes, there are many many libraries that give you those in JS (not to talk about CoffeeScript). What I really miss from a maintainability point of view with javascript, on the other hand, is better development tools (ie IDEs and testing tools). I'm pretty sure there is a big opportunity there.
- hamidpalo 14y agoIt'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.
- ocharles 14y agoThis rings very true to me too, as our entire application is written in Perl. As much as I do like the language, the lack of just about any static guarantees mean we regress an awful lot. Yes, we have unit tests, but until we have 100% coverage we have gaps for regressions that a compiler could have picked up.
- gaius 14y agoAnyone 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 14y agoThis 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 14y agoUsing 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 14y ago
- ilaksh 14y agoYou definitely can create classes in JavaScript, its just not especially convenient. But to me its not really a critical issue, because OOP is very easy in CoffeeScript, which is my favorite language and happens to compile to JavaScript.
- masklinn 14y ago> everything that does not have classes is unmaintable Not that javascript doesn't. It doesn't have the sugar around it, and it doesn't statically check them. But javascript's OO is not "prototype-based" (that doesn't even make sense, prototypes are not a unit of reuse in Self) and it's not anything even remotely close to Self's. Javascript's OO is single-inheritance class-based with no `class` sugar but at the end of the day it behaves pretty much the same way (and offers no more features — less if anything) Python's or Ruby's class-based OO work (sans metaclasses).
- pjmlp 14y agoNo, this is what people that have real life experience from large scale applications think. I have quite some experience with most mainstream dynamic languages, and wouldn't do any large scale application with any of them. The company I work for, does large scale enterprise consultancy projects. This means: - Multiple development sites; - Some projects have up to 200 developers; - Usually several megabytes of source code; - Continuous Integration build systems with automatic unit and integration tests - Usually distributed architecture - High performance requirements No way I would advise anyone to do develop such systems in a dynamic language, let alone in JavaScript.
- mercurial 14y agoMaintaining a large PHP project written by idiots, in addition to a much smaller codebase in Javascript has convinced me of the importance of static typing for large-scale projects.
- phren0logy 14y agoPosts like this make me wonder why OCaml isn't much more popular.
- masklinn 14y agoOh surely that's because it has too much static typing to be practical, it's not like there is much thought put in the argument or any desire to pursue the argument to its logical conclusion in these things.
- LeonidasXIV 14y agoI kinda feel strange when people tell me Python is bad because it does not have static typing but when I tell them about OCaml or whatever else I'm fine with, they try to find another excuse why Java is good.
- DrJokepu 14y agoFunctional programming is difficult and the large majority of developers haven't even heard of it.
- gaius 14y agoOCaml is multi-paradigm - the O is for object. Type inference is a huge productivity win.
- sirclueless 14y ago> Type inference is a huge productivity win. When writing code, sure. When reading and/or maintaining code, not so much. Especially when it stretches across function or method boundaries. Languages like C++ and C# have the right happy medium in my opinion: `auto`/`var` keywords for type-inferenced local variables, but explicit parameters and return types for all methods.
- DrJokepu 14y ago
- kevinconroy 14y agoIf you're going to attack Node.js, do it to its face.
- batista 14y agoYes, 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.
- Jacobi 14y agoJavaScript 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.
- yaz 14y agoWhat's wrong with using dojo for a module system, namespaces and OOP?
- Jacobi 14y agoYou can do OOP in any langage and there is nothing wrong with dojo. But from my limited experience, maintaining large programs written in JavaScript is a tedious job (each program reinvent it's own OOP semantics)
- factorialboy 14y agoUmm .. On the server, node_modules / NPM driven modular system (AMD) works quite well. RequireJS can be used on the client as well.
- ajuc 14y agoI 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;
- losethos 14y agoA design should be appropriate. Overengineering costs time, money, performance and is harder to maintain due to complexity and bulk. Don't hurt yourself patting yourself on the back because you always overengineering. The only voice I ever hear is the voice of overengineering. Single-letter global variables are the right choice for 1,000 line programs that are demos for newbies. If it's 100,000, they should be long global variable names. APPLE ][ HGR HCOLOR=12 HPLOT 50,50 TO 200,100 ---- Today, the same thing is insanity, probably managed code.
- watt 14y agoI 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 14y agoNot 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 14y agoI 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.
- hkolek 14y agoYes, if you include autogenerating code from a DSL, of course this is true. See Greenspun's tenth rule. But if you have to implement a custom DSL to achieve your goal obviously the language isn't expressive enough to do it. But I agree that the factor is probably not as high as 100x.
- ozataman 14y ago
- edandersen 14y agoSteer 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.
- lubos 14y agoI 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 14y agoUmm.. in my personal experience using IntelliJ IDEA for Java and JavaScript code, the refactoring experience is the same.
- kristiandupont 14y agoHow could it possibly be? Refactoring a dynamic language will always be more difficult because you never know exactly what an expression refers to.
- ajuc 14y agoIn 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 14y agoThis 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"]
- moron 14y agoMy 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.
- emarcotte 14y agoOr folks to just don't like hidden surprises when trying to do trivially simple things?
- jonpacker 14y agoIf you take an hour to sit down and understand the type coercion, all of these "hidden surprises" magically disappear.
- redbad 14y ago1. Understanding JavaScript type coercion correctly, including (emphasizing!) all of the corner cases that actually matter, is not an hour's task. 2. The fact that pathological-condition-X of a language is in theory understandable with sufficient study is a total red herring in a broad discussion of that language.
- ZenPsycho 14y agoUnderstanding all the corner cases of how C deals with integers is a huge undertaking, as the C Integer Quiz thread showed us. But in practice, it's not actually a problem since you just learn to avoid using features of the language that involve type coercion. Just simply don't mix types. only use === and !==, use a templating library instead of the + operator to construct strings. jslint can catch the rest. If you truly find the way javascript behaves surprising- in the sense that you are trying to do something reasonable, and it surprises you, I have to wonder what on earth you are trying to do that would invoke type coercion to begin with, and why you need to do it that way.
- gsa 14y agoThe 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/Panel-Web-and-Cloud-Programming/player?w=640&h=360 http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Pan...
- factorialboy 14y agoLanguage wars erupt again! Should it be titled: "Anders Hejlsberg: I Can't Maintain Large Programs in JavaScript." ?
- damian2000 14y agoI 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..
- willvarfar 14y agoThere is also several mentions in the excellent video of how types help refactoring etc.
- keeperofdakeys 14y agoBeing 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.
- pjmlp 14y ago> Being an OOP language, the interaction between modules is very explicit. This is true in any language that supports modules, not only OOP languages.
- damian2000 14y agoI 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.
- Tomis02 14y agoIDE won't help you beyond a certain code size. Good explanation here http://steve-yegge.blogspot.fi/2007/12/codes-worst-enemy.html http://steve-yegge.blogspot.fi/2007/12/codes-worst-enemy.htm...
- ZenPsycho 14y agoI 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 14y agoHave you written mainly todo-apps or do you have by any chance experience writing payroll software or stock keeping applications for a retailer?
- deleted 14y ago[deleted]
- route66 14y agoIn the end everything is an API!
- ZenPsycho 14y agoOkay so may I ask what is the point of this question? (edit; I guess asking for clarification is looked down upon here?)
- route66 14y agoAs 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 14y agoIt 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.
- ivank 14y agoGoogle 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.
- stiff 14y agoThe 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.
- AutoCorrect 14y agoI had a lot of respect for Anders in the Borland days. Now he seems more and more to be just a Microsoft shill.
- deleted 14y ago[deleted]
- carsongross 14y agoAnd, 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.
- mratzloff 14y agoOr at least a JavaScript AST standard, like this one proposed in 2010: http://research.microsoft.com/apps/mobile/publication.aspx?id=120832 http://research.microsoft.com/apps/mobile/publication.aspx?i...
- ZenPsycho 14y agoThere are problems with this idea in that- every js engine will have a different AST structure for optimisation reasons, and making the AST a standard rather constrains optimisation efforts- or forces implementors to include two seperate parsers.
- rwallace 14y agoWe 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.
- sausagefeet 14y agoShame the link only talks about the JS part. So much other great stuff in this video.
- debacle 14y agoThe 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 14y agosmarter staff == higher salaries, not welcome in big companies.
- debacle 14y agoIf 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 14y agoI 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.