es-discuss Digest, Vol 131, Issue 16

Ranando King kingmph at gmail.com
Sat Jan 13 23:27:59 UTC 2018


Just throwing in my 2 cents.

I would argue that this represents such a fundamental change to how the
language works, that it would actually represent a new language, even
though they're optional. One problem is in how this would be implemented.
Making types optional introduces a lot of overhead in type checking. Such
checks would have to occur at runtime since ES is a language capable of
self-modification. What's more is that the weight of all these checks
happening at runtime would cause a serious performance penalty to run speed.

On the flip side, ```class``` already provides some of what you want to do.
The proposal for private fields brings class even closer. If decorators are
allowed to be applied to both non-objects and function parameters, then
decorators could be used to close the gap. All that would be needed is to
define a decorator for each desired type. The decorators would take care of
the type checks while performing the documentation purposes you're saying
would be one of the biggest features.

Having used many typed languages before, I cannot deny the usefulness of
types. However, where Javascript is concerned, mixing typed and untyped
variables leads to complexities that could be flatly impossible to
optimize. Have you considered what would happen if someone does something
like this:

```javascript
function doSomething(param: int32) {
   //Do something here
}

var a = 32;
doSomething(a);
a = "foo";
doSomething(a);
```
The engine would not be able to optimize this... ever. Every call would
involve a type check before the call is made since the type of the
parameter cannot be guaranteed to be converted to an int32. The engine
would either need to disallow such a call from an untyped value, or type
check every time.

If you can imagine implementing types as syntactic sugar over what can
already be done in ES6 (maybe with the inclusion of ES7 or proposed
features) you might find a bit less push-back.


On Sat, Jan 13, 2018 at 3:43 PM, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>    1. Re: Proposal: Optional Static Typing (Part 3) (Mark Volkmann)
>
>
> ---------- Forwarded message ----------
> From: Mark Volkmann <r.mark.volkmann at gmail.com>
> To: kai zhu <kaizhu256 at gmail.com>
> Cc: Brandon Andrews <warcraftthreeft at sbcglobal.net>, es-discuss <
> es-discuss at mozilla.org>
> Bcc:
> Date: Sat, 13 Jan 2018 15:43:52 -0600
> Subject: Re: Proposal: Optional Static Typing (Part 3)
> Not sure if this is the place to debate whether optional type support in
> JavaScript would be a good thing, but I'll throw in my perspective. I used
> to be anti-types. Then I decided to give Flow a try. Initially it felt like
> I was spending a lot of time just learning the syntax and trying to make
> Flow happy. But after a few weeks I caught on and noticed that every time
> Flow complained it was actually correct. Then I needed to so some
> refactoring. That's where the big benefit is for me. I no longer have to
> manually determine what would break if I want to do things like change a
> function name, change a property name in an object, and much more. I just
> make the change and Flow tells me where I need to make adjustments. So
> whether JavaScript adds types, I don't think I'll go back to not having
> them. I'd much rather use Flow or TypeScript than not have types at all.
>
> On Sat, Jan 13, 2018 at 2:45 PM, kai zhu <kaizhu256 at gmail.com> wrote:
>
>> I really don't understand the irrational aversion to OST or classes in
>> ES. If you don't want to use them, well don't use them. These features
>> makes sense for a lot of programmers and IMO EcmaScript should not be a
>> bastion of resistance against other languages, specially when it's the only
>> language for building front end applications.
>>
>>
>> then we agree to disagree. perspective-wise, type-related bugs are among
>> the most easy to debug-and-fix things in javascript (or any serious
>> programming language really). OST brings little to the productivity-table
>> in offering to help solve a relatively trivial problem on the javascript
>> bug-spectrum, while distracting us from bigger-picture show-stoppers. like
>> say, integration-level bugs dealing with async-io and timeouts, that can
>> invalidate design-decisions / performance-tradeoffs made at the
>> application-level and require major code rewrites.
>>
>> for example, did you find out during integration / qa, that mongodb’s
>> scalability claim (using its old mmapv1 storage-engine) is a lie, and even
>> with indexing, its real-world query-performance for your use-case drops
>> dramatically when the db grows past 10gb (to maybe 30-60 seconds / query
>> which is similar to mysql at such scale)? great, now you have to retool the
>> application with a new caching-scheme (or maybe a *shudder* message-queue)
>> to compensate, and perhaps search-and-replace the timeout value everywhere
>> a request to mongodb is made in your code.  these are the kinds of bugs
>> that keep javascript-developers awake at night, not some kiddie
>> string-instead-of-number type-error.
>>
>> On Jan 14, 2018, at 12:48 AM, Pier Bover <pierbover11 at gmail.com> wrote:
>>
>> I strongly disagree with kai zhu.
>>
>> where is this demand coming from? newcomers from c# / java
>>> who don't know anything about how javascript is used to ship
>>> end-user-features and web-products?
>>
>>
>> The idea that optional static typings (OST from now on) are some
>> "contamination" from other languages is naive. Programmers are not asking
>> for OST because they lack perspective, quite the contrary, it's simple
>> common sense. Types make code more obvious and deliberate. The importance
>> of obviousness in code cannot be overstated.
>>
>> I'm not a guy coming from C# or Java. In my 20+ years of professional web
>> dev I've spent 80% of my time writing ES languages. I wrote with ES4
>> extensively (AS3) and I experienced OST myself for years. In fact AS3 was
>> 11 years ago a better language than JS is today and one of the biggest
>> reasons for that were OST.
>>
>> static-typing, like classes, makes frontend developers' lives harder;
>>> it introduce non-essential, rigid structures, making it difficult to
>>> cut the necessary corners (and the inevitable ugly-hacks needed)
>>> during integration to ship a web-product.
>>
>>
>> It seems you are missing the word "optional". Current optional ES classes
>> are nothing more than syntactic sugar over prototypal inheritance, and
>> since these classes were introduced no flexibility has been lost. With the
>> introduction of OST no flexibility would be lost either and we could
>> happily ship quick and dirty solutions if we needed/wanted to.
>>
>> maybe its different @ the large companies / orgs tc39 represents who
>>> can hire better-than-average programmers that can magically ship
>>> products with correct javascript code right-off-the-bat. but not so
>>> for most of the web-industry that can only afford mediocre
>>> javascript-programmers whose code-designs and architectures rarely
>>> survive integration / productization intact.
>>
>>
>> You are again ignoring the optional factor. With OST JavaScript could
>> still be used by mediocre programmers, but maybe they could start
>> architecturing their code better and survive integration. That was exactly
>> my experience when I started to write AS3 back in 2007. It made me a better
>> programmer and it was my stepping to stone to C#, C++, Go, Swift, etc.
>>
>> I really don't understand the irrational aversion to OST or classes in
>> ES. If you don't want to use them, well don't use them. These features
>> makes sense for a lot of programmers and IMO EcmaScript should not be a
>> bastion of resistance against other languages, specially when it's the only
>> language for building front end applications.
>>
>> On Sat, Jan 13, 2018 at 1:59 AM, kai zhu <kaizhu256 at gmail.com> wrote:
>>
>>> rant warning
>>>
>>> > The demand for types as a different approach to code has been so
>>> strong in the past few years that separate languages have been created to
>>> deal with the perceived shortcomings.
>>>
>>> where is this demand coming from? newcomers from c# / java
>>> who don't know anything about how javascript is used to ship
>>> end-user-features and web-products? or those who do and accept the
>>> reality that there's always lots of ugly corner-cutting involved with
>>> javascript to push a product out the door?
>>>
>>> static-typing, like classes, makes frontend developers' lives harder;
>>> it introduce non-essential, rigid structures, making it difficult to
>>> cut the necessary corners (and the inevitable ugly-hacks needed)
>>> during integration to ship a web-product.
>>> its usually easier for javascript-programmers to ship products if the
>>> code and async-logic they have to rewrite during integration and qa
>>> were mostly throwaway static-functions (with the assumption they WILL
>>> be rewritten during integration). versus classes with static-typing
>>> (that are more difficult to rewrite at the late-stage in
>>> web-development when it matters the most and have a higher tech-debt
>>> penalty).
>>>
>>> maybe its different @ the large companies / orgs tc39 represents who
>>> can hire better-than-average programmers that can magically ship
>>> products with correct javascript code right-off-the-bat. but not so
>>> for most of the web-industry that can only afford mediocre
>>> javascript-programmers whose code-designs and architectures rarely
>>> survive integration / productization intact.
>>>
>>> On Jan 12, 2018 12:19, "Brandon Andrews" <warcraftthreeft at sbcglobal.net>
>>> wrote:
>>> >
>>> > > I'm still yet to read the entire proposal, but with a quick skim, it
>>> seems to me like this is essentially what Typescript or Flow offers you:
>>> i.e. an opt-in type system?
>>> >
>>> > This is in the core of ECMAScript, so the types would be real. The
>>> implementers would be encouraged to use native hardware types. But yes,
>>> outside of that it is an opt-in type system. Language built on top of it
>>> would then benefit from this. I often wonder if languages built on top of
>>> ES6 haven't limited themselves because types don't exist. That is they'd do
>>> more, but didn't because the complexity of transpiling. Stuff like this:
>>> https://github.com/Microsoft/TypeScript/issues/4639 Imagine if
>>> ECMAScript already had all those types and support function overloading.
>>> TypeScript could move on and implement more experimental ideas.
>>> >
>>> > > I'm wondering if you have any good reasons to want there to be a
>>> standardised static type annotation syntax within ECMAScript instead of a
>>> "Bring Your Own Type Checker" system. If you do have some thoughts on this,
>>> you might also want to include that as a preface on your Github's
>>> README.You have a "Rationale" bit that seems to ignore the existence of
>>> these existing systems.
>>> >
>>> > Did you read the rationale? It specifically says:
>>> >
>>> > > The demand for types as a different approach to code has been so
>>> strong in the past few years that separate languages have been created to
>>> deal with the perceived shortcomings.
>>> >
>>> > More of the rationale was below the types proposed. I've moved it up
>>> into the rationale since it fits better there. If there's more you think
>>> should be added I'll include it. I'm trying to keep things concise since
>>> it's a long proposal. I could go into an explanation that TypeScript and
>>> other languages are generally just a superset of Javascript and benefit
>>> from bringing their features closer to the base language and possibly the
>>> hardware? It seems too obvious to me to write something like that.
>>> >
>>> >
>>> >
>>> >
>>> > > From a quick read, I'm more in favor of something that's a little
>>> more restricted to start, something like what Python has. Python has
>>> optional static type annotations, but the Python interpreter just ignores
>>> them. They are present purely for the purposes of tooling, and are silently
>>> ignored at runtime.
>>> >
>>> > The goal with this proposal is to get essentially native hardware
>>> types where applicable. All the proposed types have special operator rules,
>>> value ranges (overflow behavior), and in the case of SIMD very real
>>> performance impact behind them. While documentation hints are a
>>> side-effect, I'm more focused instead for pushing ECMAScript toward being a
>>> more powerful language. Python is a classic example of where data type
>>> shortcomings lead to unintuitiveness or weird design like:
>>> https://docs.python.org/2/library/array.html I'm trying to avoid such
>>> things.
>>> >
>>> > > One of the reasons why I'd prefer a simpler approach to start is
>>> that TypeScript and Flow, the two main implementations that add syntax,
>>> have a *very* similar syntax, but have several nuances that would make a
>>> heavier proposal much harder to accomplish:
>>> >
>>> > > - Flow has `?Foo` for optional types, TypeScript just uses unions.
>>> >
>>> > I have a section on unions with a small explanation on why I left it
>>> out. I kept it simple by only adding nullable types. Right now someone
>>> would overload or use 'any'.
>>> >
>>> > > - TypeScript has mapped/index types, where Flow uses special named
>>> types.
>>> >
>>> > I didn't include these.
>>> >
>>> > > - Flow allows omitted parameter names in function types, TypeScript
>>> only allows named parameters with implicit `any` types.
>>> >
>>> > I created an issue to be more explicit about optional and default
>>> typed parameters and the behavior.
>>> >
>>> > > - Flow has exact types, TypeScript doesn't.
>>> >
>>> > I hadn't even considered something like this. It sounds interesting
>>> for configuration options. They introduce new tokens. Something I'm very
>>> much avoiding for this initial proposal.
>>> >
>>> > > - Flow has `opaque type`, TypeScript only has `type`.
>>> >
>>> > Something to be decided later. Doesn't create breaking changes to add
>>> later.
>>> >
>>> > > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`.
>>> >
>>> > There's a section on generics and why it isn't included already. I'm
>>> with you that it's far too complex to add in with initial types. There's no
>>> breaking changes introduced by adding it later. (Mostly because it
>>> introduces new tokens which would be a huge deal).
>>> >
>>> > > - Flow has existential types, TypeScript doesn't.
>>> >
>>> > I definitely haven't included this. Flow is a few steps ahead of this
>>> proposal.
>>> >
>>> > It seems like a lot of these features already aren't included in the
>>> proposal. I definitely hold your view that the proposal has to be minimal,
>>> but I think my minimal is functionally minimal. Something that when
>>> implemented allows developers to experiment and then discussion can
>>> progress from there to how more features can be added. I'm trying to be
>>> thourough though as to not harm a future proposal so if any of my decisions
>>> block something I'm open to changes.
>>> >
>>> > Most of my thoughts and focus have been on what I think of as the
>>> basics. How types interact with declarations, functions, classes,
>>> destructuring, allocation, and control structures. The future consideration
>>> sections are mostly a catalogue of ensuring that these basic initial
>>> features and designs will work as the language incorporates other proposals.
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180113/eb0730e8/attachment-0001.html>


More information about the es-discuss mailing list