****SPAM(5.0)**** Re: Operator overloading revisited

[Alex Russell]

Spam detection software, running on the system "nibbler.dojotoolkit.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
postmaster for details.

Content preview:  On Jul 6, 2009, at 7:23 PM, Mark S. Miller wrote: > On Mon,
   Jul 6, 2009 at 6:10 PM, Alex Russell<alex@...> > wrote: >>>>
  The original "classes as sugar" sketch Mark did to general >>>> agreement
  at >>>> Oslo >>>> included freezing the class object (constructor function)
   *and* >>>> bind the >>>> class name as a const (neither writable nor configurable
   in the >>>> binding >>>> object or frame). >> >> This point disturbs me.
  Making classes frozen solves no existing JS >> programmer problems, introduces
   new restrictions with no mind paid >> to the >> current (useful) patterns
   of WRT the prototype chain, and >> introduces the >> need for a const that
   only seems there to make some weird security >> use-cases >> work. >> [...]
   >> Questions of "integrity" here to my mind should be justified by why >>
   they'll >> be good for ALL code, not just abuse of built-ins, and then weighed
   >> against >> other possible solutions. Freezing classes seems premature
  to me. > > > For low integrity patterns (or "loosey goosey" as Allen sometimes
   > says), JavaScript has always been and will remain a fine language. [...]
   

Content analysis details:   (5.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.1 RDNS_NONE              Delivered to trusted network by a host with no rDNS
 4.4 HELO_DYNAMIC_IPADDR2   Relay HELO'd using suspicious hostname (IP addr
                            2)
 0.6 FH_HELO_EQ_D_D_D_D     Helo is d-d-d-d
 2.3 TVD_RCVD_IP            TVD_RCVD_IP
-2.3 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
                            [score: 0.0000]




On Jul 6, 2009, at 7:23 PM, Mark S. Miller wrote:

> On Mon, Jul 6, 2009 at 6:10 PM, Alex Russell<alex@...>  
> wrote:
>>>> The original "classes as sugar" sketch Mark did to general  
>>>> agreement at
>>>> Oslo
>>>> included freezing the class object (constructor function) *and*  
>>>> bind the
>>>> class name as a const (neither writable nor configurable in the  
>>>> binding
>>>> object or frame).
>>
>> This point disturbs me. Making classes frozen solves no existing JS
>> programmer problems, introduces new restrictions with no mind paid  
>> to the
>> current (useful) patterns of WRT the prototype chain, and  
>> introduces the
>> need for a const that only seems there to make some weird security  
>> use-cases
>> work.
>> [...]
>> Questions of "integrity" here to my mind should be justified by why  
>> they'll
>> be good for ALL code, not just abuse of built-ins, and then weighed  
>> against
>> other possible solutions. Freezing classes seems premature to me.
>
>
> For low integrity patterns (or "loosey goosey" as Allen sometimes
> says), JavaScript has always been and will remain a fine language.

/me scrapes jaw from floor

JS may have many fine "loosey goosey" primities, but it's not a "fine"  
language for dynamic programming (yet). It's only a plausibly OK  
language that allows you to (at great expense) build your own tools up  
from the (ample and useful) raw materials that populate the landscape.

It is not, however, simple to communicate the meaning of many of the  
discovered patterns, use them to construct larger-scale constructs, or  
treat them as a stable baseline from which to work.

Suggestions that JS is just fine for what people are using it for  
today but insufficient to handle some laudible but unapproachable  
class of tasks by dint of its looseness strike me a disingenuous. Why  
should the "high integrity" programs get to annex the new keywords and  
constructs for their own with little or no improvements to the main-
line tasks which have been so painfully executed for years?

Your null hypothesis is broken.

> In
> ES5 for the first time, it is possible to engage in high integrity
> patterns; but it is not easy.

Welcome to the club!

> We don't need syntactic sugar to provide
> yet another way to express what can already be expressed easily.

Yes, yes we do.

In part we need them because "expressed easily" isn't the whole story.  
It says "I, a person of above average means, can see a way through  
this problem which can be communicated to others of above average  
means who have trudged through the same semantic desert and arrived at  
this shore with me". Blarg. What's being proposed is not an  
improvement in the ability of JavaScript programmers to communicate to  
other programmers (who may be in more of a hurry) as to what their  
programs are supposed to mean.

If the point of introducing classes isn't to make the common case  
easier, simpler to read, and more efficient....well, then I'm not sure  
why everyone is spending so much time on this. There are plenty of  
fine little research languages that can use the love.

> It is
> when something valuable becomes possible, but can't be made easy
> without syntactic sugar -- like high integrity programming in ES5 --
> that syntactic sugar may be justified.

Indeed! That does not imply a pre-judgement as to the relative merit,  
programmer cost, or usability price for such sugar vs. other uses of  
the language, though.

High-integrity is not the common case, so it deserves worse huffmann  
codings. The (unadorned) word "class" should be reserved for efforts  
that benefit the common case, while modifiers to it should indiciate  
the special case. How 'bouts:

        class(frozen) Foo {
        }

Or for the syntax loving amongst us:

        frozen class Foo {
        }

New keyword? You bet. But this is something that's turned on by a new  
mode to start with, right?

> So no, it doesn't need to be justified for all code.

It's weighting sure does. You can't just duck the charge on this by  
saying the feature is important. HOW important relative to other (more  
popular) uses of the language matters.

More to the point, why does this problem need to be solved in the  
language, anyway? Isn't it something that is more of a "platform"  
issue...i.e., something we can be asking browsers to help us out with?  
That, or we could bring Workers into the scope of the language and  
expand the standard library in directions that it probably should go  
anyway.

Not everything needs syntax. Not even everything new.

> It just needs to
> be justified by code that isn't well served by ES5 as it is. No one is
> proposing removing JavaScript's support for making low integrity
> programming easy.
>
> As for whether high integrity is only of interest to security weirdos,

I did not call those with an interest in the security of the platform  
weirdos. I suggested that with regards to the big problems that the  
largest bodies of JS code face today, security barely makes the list.  
Now, with regards to the web platform as a whole, I'll buy the  
argument that it's both underserved and pressing. But not at the JS  
language level.

> I'll just remind everyone that the notion of objects [Simula,
> Smalltalk, Actors] -- or similarly abstract data types [Clu] -- was
> conceived from the beginning as: reusable packages of encapsulated
> state together with the code responsible for maintaining that state's
> invariants and presenting an abstract interface. That interface that
> quickly came to be characterized in terms of pre-conditions and
> post-conditions [Liskov].
>
> Virtually none of the systems or literature that brought about this
> revolution was concerned with security per se. These notions were
> created for the sake of modularity, abstraction, and flexible
> composability.

I support most of those goals = )

> None of these concerns have gone away; hence the
> frequent complaint that JavaScript today provides inadequate support
> for serious large scale programming -- a need which classes-as-sugar
> hopes to address.

There's no quarrel with "classes-as-sugar" from me. Only the  
requirement that they be frozen by default.

> Finally, I make no apology for being a security weirdo or for wanting
> to see JavaScript become more securable.

Nor should you. As we discussed in person, I empathize with your  
concerns and appreciate the approach you're taking.

> JavaScript is uniquely
> positioned as the fastest growing portion of many organizations'
> attack surface; and often also their weakest link.

I reject that. I'll accept this, though:

        Web applications are uniquely positioned
        as the fastest growing portion of many
        organizations' attack surface; and often
        also their weakest link. JavaScript plays
        a part in most compromises, but these are
        enabled primarily by a lack of platform
        awareness of ambient authority granted
        to objects originated by naive domains.

Implicating JavaScript as a language in this situation seems unfair to  
me when the original (and permeating) sins were committed elsewhere.  
Further, I distrust language-level fixes for what is a platform  
problem since they're hard to reason about and encourage too much fine-
grained coordination for my comfort.

Regards

> This is a role for
> which it was not designed and for which it has been ill suited. By the
> same token, JavaScript is also uniquely positioned to capitalize on
> prior work on programming language security. It's continued evolution
> should indeed be shaped by the unique niche it occupies.
>
> --
>    Cheers,
>    --MarkM


_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss