Live data from Hacker News

Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

lostechies.com

11–20 of 31 posts

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#11
post #9

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…

Otoh, the scripting languages generate so much less code that many systems just aren't "large" in them...

If I understand your position, the only thing really needed should be optional typing of parameters (and possibly variables) that are expanded to assert statements on compiling?

And editor support for that typing, of course, to get popups with calling profiles?

There is something in Perl [1], I don't know about Python. Write a PEP. :-)

[1] Method::Signatures@CPAN, et al http://search.cpan.org/~barefoot/Method-Signatures/lib/Metho...

Edit: Basic English grammar, sigh.

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#12

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.

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

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#13
post #9

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…

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.

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.

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#14
post #11
post #9

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…

Otoh, the scripting languages generate so much less code that many systems just aren't "large" in them... If I understand your position, the only thing really needed should be optional typing of parameters (and possibly variables) that are expanded to assert statements on compiling? And editor support for that typing, of course, to get popups with calling profiles? There is something in Perl [1], I don't know about P…

True, but large systems are just, well, large. I'm not thinking startup land here, but entrenched applications in bigger businesses that grow organically to meet the need of the business.

Python 3 does have type annotations for use by linting tools, but it'll be another 5-6 years before we'll see that filter down into the current Python ecosystem. And even then, it's only as good as the weakest (non-annotated) piece of code. Retrofitting libraries and existing code will bring about its own issues: how do you accurately hint to linters, in a language that encourages duck typing, the type a method parameter is likely to take?

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#15
post #13

Earlier quoted context omitted.

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.

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 t…

> Yes, crash at runtime. That's no good in a production environments My point is that it's a lot better than trying to continue in an inconsistent state.

I'm not saying dynamic typed languages are better than static typed languages. Right now I use coq. I write programs and their correctness proofs so I definitely get why you would want some static guarantees.

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#16
post #13

Earlier quoted context omitted.

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 t…

> Yes, crash at runtime. That's no good in a production environments My point is that it's a lot better than trying to continue in an inconsistent state. I'm not saying dynamic typed languages are better than static typed languages. Right now I use coq. I write programs and their correctness proofs so I definitely get why you would want some static guarantees.

Oh, I know you weren't. It wasn't a criticism of your observation at all, but one of those "sigh, why can't I have my cake and eat it" moments :)

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#17
post #14
post #11

Earlier quoted context omitted.

Otoh, the scripting languages generate so much less code that many systems just aren't "large" in them... If I understand your position, the only thing really needed should be optional typing of parameters (and possibly variables) that are expanded to assert statements on compiling? And editor support for that typing, of course, to get popups with calling profiles? There is something in Perl [1], I don't know about P…

True, but large systems are just, well, large. I'm not thinking startup land here, but entrenched applications in bigger businesses that grow organically to meet the need of the business. Python 3 does have type annotations for use by linting tools, but it'll be another 5-6 years before we'll see that filter down into the current Python ecosystem. And even then, it's only as good as the weakest (non-annotated) piece…

>>how do you accurately hint to linters, in a language that encourages duck typing, the type a method parameter is likely to take?

You didn't check the Method::Signatures link or do I misunderstand your position?

Also check Moose@CPAN, which have typing of object attributes. It isn't like a fully typed language, but it should help a lot.

Edit: Link discussing type checking of attributes in Perl. Should be possible to have something similar in other dynamic languages? http://search.cpan.org/~doy/Moose-2.0602/lib/Moose/Util/Type...

Edit: Please check the links and see if Perl solves your problems? I am curious. (-: Writing a PEP to get something similar into Python is optional. :-)

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#18
post #14
post #11

Earlier quoted context omitted.

Otoh, the scripting languages generate so much less code that many systems just aren't "large" in them... If I understand your position, the only thing really needed should be optional typing of parameters (and possibly variables) that are expanded to assert statements on compiling? And editor support for that typing, of course, to get popups with calling profiles? There is something in Perl [1], I don't know about P…

True, but large systems are just, well, large. I'm not thinking startup land here, but entrenched applications in bigger businesses that grow organically to meet the need of the business. Python 3 does have type annotations for use by linting tools, but it'll be another 5-6 years before we'll see that filter down into the current Python ecosystem. And even then, it's only as good as the weakest (non-annotated) piece…

I'd have thought that taking a leaf out of Go's book and having passively-defined interfaces would be a useful concept for linter hints.

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#19
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 :)

Re: Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

#20
post #9

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…

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.

You call that strong typing ? IMHO it is natural that it fails - what did you want as a result?

But 1 + 1.0 works in Python - and I just added float to integer (integer was implicitly converted to float (given sufficiently large integer such behavior will result in erroneous calculation)), which is contrary to what strong typing is about.

Post reply on HN