You’ve copied the CPU view code from a debug view or something from a function you wrote.

This does not correspond at all to maintaining a system written in Assembler.

I actually have programmed large systems in Assembler, namely device drivers for network cards way back then.

When programming in assembler, you can do the following:

1. Modularize functionality into separate files
2. Organize files into a directory structure, which is a form of namespacing
3. Label your routines and call them or jump to them as the occasion demands

If you were to take just those facts, it’s obvious that you can write tools and an IDE that are 100% equivalent to what is available to C# developers today.

It is definitely a lot more work to program in Assembler, because you have to basically write everything you want to use from scratch.

But coding in Assembler is not very hard. All you have to do is to program only in Assembler for about a year, and then you’ve done the learning curve. From then on, coding in assembler is like coding in any other language that you know intimately: easy.

I will grant you that the type of projects where you actually code in Assembler are complicated, low-level stuff, where you have to be extremely detail oriented and fastidious, but that has nothing to do with Assembler. Because those same projects can be, and often are, written in C instead. And C is very definitely maintainable.

Coding in assembler also requires you to write programs in layers:

a) First write the very basic routines, like reading a hardware port, or something like that
b) Write layer on top of that, which makes use of the lower level layer
b) Repeat as necessary

Just coding in layers like that actually has the beneficial side-effect of enforcing a layered architecture (logically level), which is a fundamental property of any well-designed system.

Now, if you were to listen to Assembler programmers who do not structure their code like this, and who do not modularize as in a)-c), then you have discovered an incompetent programmer. You have NOT discovered anything about the maintainability of programs written in Assembler. But you might have discovered something about the maintainability of programs written by the aforementioned programmer:)

Also, if you were to just stare at a block of assembler code, it would look like gibberish, I suppose.

But I promise you that there are large systems written in Assembler, and they’re shining examples of how to code a highly maintainable system in any language.

It’s all about applying basic design principles.

It’s NOT about what language you choose to do the final “typing in” of the previously designed system.

Here’s an OS written in Assembler. I’ve looked at the source code, and it’s extremely good, and I would find it easy to maintain that system, if I had to:
http://www.menuetos.net/64bit.htm 

@CorrieEngelbrecht:disqus First let me say how much I am enjoying this discussion. I’ve learned some new things and have also been able to better think through and clarify some of my opinions. So, thanks!

I’d like to respond to a few of your points, but in re-reading my responses I think I’m trying to make too many points in too small of a format, so I’m going to try to reign it in a bit here :)

I think it’s important to make the distinction that I am not saying that ANY language is NOT maintainable. It’s not a boolean thing. Of course you can maintain anything given enough time and patience. Rather, I’m trying to make the argument that some languages, and by extension the tools that those languages support, lend themselves in varying degrees to application maintainability (same thing goes for tools. JSLint and gcc both do static analysis, but in different ways and to different degrees). 

Take the following example. I admit it’s a bit contrived but I think it still works to illustrates my point. Both sets of code do the exact same thing. Would you agree that the second one will be easier to maintain?

ASSEMBLY:

push        ebp 
mov         ebp,esp 
push        edi 
push        esi 
push        ebx 
sub         esp,38h 
mov         esi,ecx 
lea         edi,[ebp-38h] 
mov         ecx,0Bh 
xor         eax,eax 
rep stos    dword ptr es:[edi] 
mov         ecx,esi 
mov         dword ptr [ebp-3Ch],ecx 
mov         dword ptr [ebp-40h],edx 
cmp         dword ptr ds:[04AE0AF4h],0 
je          0000002D 
call        73114587 
xor         edx,edx 
mov         dword ptr [ebp-44h],edx 
nop 
mov         eax,dword ptr [ebp-3Ch] 
add         eax,dword ptr [ebp-40h] 
mov         dword ptr [ebp-44h],eax 
nop 
jmp         0000003F 
mov         eax,dword ptr [ebp-44h] 
lea         esp,[ebp-0Ch] 
pop         ebx 
pop         esi 
pop         edi 
pop         ebp 
retC#:

public static int Add(int value1, int value2)
{     return value1 + value2;}

To clarify:
1. I explicitely wrote “ (you = general populace) ” so that you would understand that I mean you in the general sense, and not you specifically, unless stated otherwise.

2. No, this does not follow at all. Any developer can think in one or more languages. Just because a developer cannot “think in JavaScript” says nothing at all about a completely different developer, and what languages that developer might be able to think in.

4. A Perl (which is what you probably meant) programmer that applies loose coupling and high cohesion principles will produce a maintainable system.

A Perl programmer that does not, will produce an unmaintainable system.

It’s as simple as that. And this applies to any language you care to insert there.

5. Maintainability is a completely nonsensical differentiator among languages. You cannot judge a future, not yet written, system’s maintainability based on some sort of predictive crystal ball that extrapolates maintainability given the name of a programming language as input.

6. Why do you mention this? I have listed the tools for JavaScript that make the JavaScript ecosystem exactly on par with the C# ecosystem. JavaScript has JSLint for static analysts, and testing frameworks, and refactoring IDEs and mocking suites, and testing suites (non-TDD type testing and TDD type testing), and code completion.

There’s no tool you can mention that exists in Visual Studio or for C# that does not also exist for JavaScript.

7. I don’t think you understand dynamic typing. JavaScript does not have classes. It only has functions. Any OO concept is done on object prototyping. But this does not prevent any static analysis, or any documentation generation, or any refactoring, or any code completion from being performed on JavaScript source code.

8. So this is where I’m starting to think that the “you = general populace” that can’t think in JavaScript should become “you = herbrandson” cannot think in JavaScript.

And I say this without trying to be insulting, even though I’m probably failing at that:)

You do not need to know what data type is expected by a function in its parameters, nor do you need to know what data type will be returned by a function. JavaScript does not work that way.

I want to mention two good sources of information, with the idea that future visitors might be able to use this information as well, so don’t take this personally:

a). The book Object-Oriented JavaScript is one of the best sources of good JavaScript practices, with specific sections on writing maintainable code: http://www.packtpub.com/object-oriented-javascript-applications-libraries/book

b) The book “JavaScript: The GoodParts” is another standard source of excellent information: http://shop.oreilly.com/product/9780596517748.do

I could go into this, but basically it comes down to this: if you find yourself wanting a type system in JavaScript, then you’re not writing JavaScript.

JavaScript is a functional programming language, with objects prototypes as an added structural bonus.

But of course, developers depend heavily on object prototyping because we want to use OOP.

However, this requires the JavaScript developer to understand something fundamental about JavaScript: object prototyping IS NOT the same as a class system.

Object prototyping is a paradigm all on its own, and it results in a polymorphic typing system, which is immensely powerful.

However, if you want to misuse this object prototyping mechanism and pretend it’s a class modelling system like in C#/Java/C++, then you’re not only missing the point, but it’s like you’re trying to use gasoline in a diesel engine. The two things are superficially equivalent, but they require completely different approaches.

Once again, when you mention tools that can make use of parameter types or function return types, then you’re actually mentioning … tools.

Not the language.

It is completely feasible to write large, maintainable JavaScript systems.

The key is just modularisation.

2. Trying to use dynamic languages in the same way you would use a static language is missing the point. Dynamic languages strengths are completely lost if you don’t approach them in a different way.

3. “Programming languages are different from each other”. Each has its own strengths and weaknesses. There is no ”one language to rule them all”.

4. I completely agree that my opinion is only one data point and far from scientific. I don’t pretend to speak the authoritative truth on this subject and readily acknowledge that I have much to learn.

Also, thanks for the list of IDEs and libraries you listed. I’ve used many, but not all of them. I’ll check the rest out. I do love new toys :)

There are also a few points I’d like to clarify…

1. I get the impression from your comments that you believe me to be a c# only developer (forgive me if I’m mistaken). On the contrary, I pointed out in my original comment that I consistently work in multiple languages. I therefor don’t believe that I am unable to “think in JavaScript”.

2. If c# developers were unable to think in JavaScript, it would seem to follow that JavaScript developers would also not be able to think in c#. If that were true then we’d be wasting our time with this discussion. Neither of us would be capable of understanding the others side. I don’t believe that to be the case at all.

3. I enjoy developing in JavaScript. There’s much about it that’s fantastic. JQuery is one of the best libraries I have used in any language. However, my personal experience has been that JavaScript is less maintainable then other languages. Again, just one data point. But not an uninformed or unqualified opinion.

4. Not all languages are equally maintainable. To take an extreme case, try modifying (or even reading) someone else’s assembly code. Pearl is also commonly referred to as a “write only” language.

5. Maintainability is not the only reason to select a language. I find c# to be more maintainable then JavaScript, but c# is a very poor choice if you want to write code that will run in the browser. JavaScript is fun and lends itself to rapid development, but it’s not really an option if you want to write a native iPhone app (yes, i know you code use an embedded browser, but that’s really not a native app IMHO). C++ is fast and pretty portable, but  in general it’s too slow to develop with for your typical web app.

6. Good tools go a long way toward making a project maintainable. They are not the only factor by a long shot, but they can make a significant impact. I have personally found static code analysis tools to make a significant impact on my ability to modify code without introducing bugs. 

7. Many good tools are the result of good metadata about the code, and a good Type system is the best source of code metadata I’ve seen. Most of the points I listed in my original comment are only possible with good metadata.

8. It’s very possible that I’m ignorant on this point, but I have not yet seen a tool that does a great job with the points I listed in my original comment (especially points 2 and 3). In fact, it’s the very strengths of JavaScript (it’s dynamic nature) that would seem to make these impossible.

Once again, I’m not saying that JavaScript is a bad language. But, I do believe there is a case to be made that it is less maintainable over the long run then other languages. Especially as the scale of an application grows (even with best practices such as modular design, unit tests, etc.).

Thoughts?

Rather, your points appear to rely on tool availability and capability.

Here are some JavaScript IDEs that support code completion and refactoring to the same degree or better than Visual Studio does for C#:
1. Aptana Studio (or Eclipse, which is basically the same thing)
2. BBEdit
3. Komodo
4.  NetBeans
5. WebStorm
6. JetBrains

And with all due respect, coding in JavaScript requires a completely different mindset than coding in C#.

Dynamic typing and functional programming are FEATURES of JavaScript, and requires the correct “thinking in JavaScript” approach to utilize. If you  (you = general populace) want static typing in JavaScript, then you’ve immediately missed a vital, foundational precept of JavaScript, and you will just not succeed in writing maintainable code in the language. But this is NOT the fault of the language, but rather of the programmer. 

And I think most of the rest of what you’re saying is just arguing from ignorance.

BDD in JavaScript: Jasmine (http://pivotal.github.com/jasmine/)
TDD in JavaScript:  QUnit, JSMock
Source Documentation: JsDoc
Runtime loading: RequireJS
Libraries: JQuery, JQueryUI, etc.

I could go on.

Furthermore, I don’t know your very talented developer, just as I don’t know you.

But if the same developer wrote C# code that is highly maintainable, and JavaScript code that is not maintainable, according to a 2nd developer, namely you, then your conclusions are mere supposition.

It could be that you yourself cannot “think in JavaScript”, and that is the source of your problems.

It could be that the original developer was not good at JavaScript.

I’m sorry, but I’ve had quite enough of all the C# developers who think they can comment on JavaScript just because they think they can program.

Programming languages are different from each other. JavaScript is a FUNCTIONAL programming language. To try and use it as a structured OO language is like trying to use a rapier to mow the lawn. You might think you’re doing well, but actually you’re completely misunderstanding what a rapier is and is used for, and how to do it.

I have found that to not be true. For example, I worked on a project recently where I had to add some features to an existing codebase that I didn’t write. The features required work on both the server side code (c#) and client side (javascript). Both the existing c# and javascript were written by the same (very talented) developer. I found the c# to be 10x easier to extend than the javascript. I would attribute this to the better tooling available on the c# side due to being a statically typed language. Just a few examples…

1. being able to quickly see what functions are part of a class
2. knowing what data type each parameter of a function expected
3. knowing what data type would be returned by each function
4. being able to change the api (i.e. adding new parameters to a function) and having the compiler quickly tell me what other parts of the system needed to be updated.

On the javascript side, most of these things required a lot of manual poking around through hundreds of lines of code and a lot of manual testing.

I realize I am only one data point here, but I have worked on large scale projects in the last few years using c, c++, c#, objective-c, javascript, java, php, and a few others. Each language has been fun to work with and each has it’s own strengths and weaknesses. But, I have to say that the statically typed languages were significantly easier when it came to extending/maintaining an existing codebase.