A Strong Mode for JavaScript • Hacker News Board

Re: A Strong Mode for JavaScript

#41

Post by acjohnson55 » Thu, Mar 12, 2015, 11:41 AM UTC

leichtgewicht wrote: post #29

First: this document should be on github. How do I do a PR on a google doc? My biggest problem with this proposal is that it will force a full-blown code-style on you. Many, perhaps most, of the features will be part of the common consent how to write good apps but I am sure lots of people have a problem with feature x or y. I wonder if a "selecting a subset" would be practicable.

My biggest problem with this proposal is that it will force a full-blown code-style on you.

Yes, just like "use strict" did, and thank goodness! The fact of the matter is that Javascript wasn't a carefully designed language from top to bottom and we're still working to fix some of its pitfalls. It's not that some of the ill-posed features don't have valid uses; they do. But we know a lot about the best practices, and with ES6, there are objectively safer alternatives to old patterns.

This isn't just for today's experienced JS dev. Javascript is here to stay, and there's no reason the person learning it today should have to know all the language quirks I had to work around. "use strong" will lead to more performant and more resilient JS coding practices, period. Let's stop fetishizing the missteps of the original language.

Re: A Strong Mode for JavaScript

#42

Post by lmm » Thu, Mar 12, 2015, 11:42 AM UTC

comex wrote: post #19

dustin1114 wrote: post #9

I think I like most of what this document proposes except for the following: In strong code, accessing objects (strong or not) throws on missing properties. New object properties have to be defined explicitly and cannot be removed from strong objects. To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, wi…

That's funny; I think that's the only part of what the document proposes I like. -- Well, okay, that's not really true; there are a lot of bits that just make sense, either because they hurt performance for little benefit (holes in arrays) or they're just dumb (arguments.caller). But I don't like gratuitously locking things down in a way that makes highly dynamically-typed code harder to write, where it doesn't seem…

I've found that even in Python, only statically typed code matters - at least, statically enough that I can be confident that it works. I don't think the ability to have an object also be a map is especially valuable; code where everything is one or the other is clearer. These changes won't affect the ability to monkeypatch methods on individual instances (that's the one "really dynamic" thing that I find actually useful), will they?

Re: A Strong Mode for JavaScript

#43

Post by fapjacks » Thu, Mar 12, 2015, 2:01 PM UTC

tragic wrote: post #32

fapjacks wrote: post #27

Earlier quoted context omitted.

Which are some of the most insidious bugs possible in JS. I shudder every time I see the syntax in your post's parent. It's a red flag. Your solution is good. I also use a lot of typeof(bar.x) !== 'undefined' since it's very explicit.

Every time? I mean, very many times (for example) you're pulling in some JSON from a server app, which will have types properly enforced at the database and/or application level. There are still gotchas around defaulting to true, whether or not an empty string is a valid value and so on, but there are many cases where foo || bar is safe enough.

Well, I'm not responsible for your code, so you do whatever you want. But this, for me, is like being Van Halen and seeing brown M&Ms in the bowl. It's a red flag when I see that syntax in code that I should be much more defensive about what's happening everywhere else. There are no assurances about data, especially about data coming across the network.

Re: A Strong Mode for JavaScript

#44

Post by SigmundA » Thu, Mar 12, 2015, 3:28 PM UTC

realharo wrote: post #35

SigmundA wrote: post #15

Earlier quoted context omitted.

I agree and I come from a strongly typed background (.Net). It is extremely liberating and useful to just add properties to an object at any time, even ones I didn't create. Kind of like slapping a sticker on something for later reference, whereas a strong types object just explodes when apply you the sticker. I understand that there are performances issues to doing things this way, but it seems like you could have t…

I don't think performance is the primary reason behind this. The motivation section in the article states in the very first sentence: Silent property failures and the resulting proliferation of 'undefined' are the most prominent mistake in JavaScript, and can be rather tedious to debug (very much like null pointer exceptions in other languages, but much more common). Having different objects (that were created in the…

It's not just for quick prototypes though, many times for me it's about marking up objects from other libraries with my own data. I'm extending them one off and not changing the base behavior in any way, this should cause no issues to anyone else using that object. Yes that can be done with inheritance in say C# so long as the base object isn't sealed, which many library classes are from MS especially, ugh.

The undefined issue seems no different to the null reference as you mentioned. I run into it constantly in C#, in fact everyone does that why they are adding the null lifting operator (?.), javascript could do the same for both undefined and null.

I may be weird but I actually like the fact that javascript has both undefined and null. It allows an extra state over just null in C# which I constantly wish I had, typically for things like data/domain objects. With undefined and null it's trivial to encoded the fact that a property is not loaded say from a db or sent from a client vs it being loaded but the value is null or sent over the network with a null value.

Re: A Strong Mode for JavaScript

#45

Post by sidekick » Thu, Mar 12, 2015, 3:34 PM UTC

As someone who is saddened to see the relatively low acceptance of Dart, I hope to more efforts like Strong mode take off.

More and more mission critical software is being written in javascript, affecting the livelihood of ordinary people. I think there is a significant audience that can benefit from a less dynamic, more static javascript.