Re: Re: Proposal: Implicit variables

[Isiah Meadows]

And why would this be broadly useful? Even Prolog doesn't go this far,
and languages like Idris, Haskell (with its numerous GHC extensions),
and C++ with its proposed concepts are the exception, not the norm,
when it comes to having any significant level of built-in formal
verification/proof checking.
-

Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com


On Wed, May 9, 2018 at 9:58 AM, Abdul Shabazz  wrote:
> See my prior thread:
>
> https://esdiscuss.org/topic/proposal-inline-javascript
>
>
> --
> Abdul S.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Implicit variables

[Abdul Shabazz]

Request please of a moderator to help clean up this thread ;)
-- 
Abdul S.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Re: Proposal: Implicit variables

[Abdul Shabazz]

*See my prior thread:

https://esdiscuss.org/topic/proposal-inline-javascript



On Wed, May 9, 2018 at 09:56 Abdul Shabazz  wrote:

> See my prior thread:
>
> https://esdiscuss.org/topic/proposal-inline-javascript
>
> On Wed, May 9, 2018 at 09:55 Michael Luder-Rosefield <
> rosyatran...@gmail.com> wrote:
>
>> Could you suggest an example?
>>
>> On Wed, 9 May 2018 at 14:50 Abdul Shabazz 
>> wrote:
>>
>>> Allow javascript to facilitate implicit variables by way of an advanced
>>> built-in reasoning engine or theorem prover. Thereby, allowing javascript
>>> to become a more powerful semantics driven language whereby the software
>>> developer need not always be bothered with implementation.
>>> --
>>> Abdul S.
>>>
>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> --
> Abdul S.
>
-- 
Abdul S.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Implicit variables

[Abdul Shabazz]

See my prior thread:

https://esdiscuss.org/topic/proposal-inline-javascript


On Wed, May 9, 2018 at 09:55 Michael Luder-Rosefield 
wrote:

> Could you suggest an example?
>
> On Wed, 9 May 2018 at 14:50 Abdul Shabazz  wrote:
>
>> Allow javascript to facilitate implicit variables by way of an advanced
>> built-in reasoning engine or theorem prover. Thereby, allowing javascript
>> to become a more powerful semantics driven language whereby the software
>> developer need not always be bothered with implementation.
>> --
>> Abdul S.
>>
> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> --
Abdul S.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Implicit variables

[Abdul Shabazz]

See my prior thread:

https://esdiscuss.org/topic/proposal-inline-javascript


-- 
Abdul S.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Implicit variables

[Michael Luder-Rosefield]

Could you suggest an example?

On Wed, 9 May 2018 at 14:50 Abdul Shabazz  wrote:

> Allow javascript to facilitate implicit variables by way of an advanced
> built-in reasoning engine or theorem prover. Thereby, allowing javascript
> to become a more powerful semantics driven language whereby the software
> developer need not always be bothered with implementation.
> --
> Abdul S.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: Implicit variables

[Abdul Shabazz]

Allow javascript to facilitate implicit variables by way of an advanced
built-in reasoning engine or theorem prover. Thereby, allowing javascript
to become a more powerful semantics driven language whereby the software
developer need not always be bothered with implementation.
-- 
Abdul S.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Dynamic `import` with options

[Isiah Meadows]

Inline.

On Wed, May 9, 2018, 04:25 kai zhu  wrote:

> or … we could avoid integration-level headaches that shouldn’t even exist,
> by avoiding es6-modules altogether and
>
> 1) sticking with well-understood require(...) in nodejs and not cross-cut
> it with import(…, options), and
>

The issue is with cross-platform (Node + browser) code, which often, you
*want* to share application logic between the front and back end (which is
simpler).

2) sticking with well-understood global-assignment of modules in browsers
> (with long/descriptive names to avoid name-clash).
>

This is exactly what led people to modules - name clashing gets
increasingly difficult and it's harder to maintain. And in my experience,
most namespacing issues are not with my code (where I get to choose the
names), but with others' code, my dependencies. Dependency hell is a bitch,
but npm's structure + file-based (not namespace-based) modules completely
sidestep the problem. And this isn't unique to highly advanced web apps -
even some more traditional web *sites* have to contend with this.

Also, it's far more convenient and readable to do `new Foo()` with a local
import than `new app.page.feature.Foo()` (my job's code base has numerous
classes with namespacing thay deep\*). You don't need to be at Google scale
to still want some level of sanity.

\* Fun fact: we have about half as much front-end code as backend code, and
very little of it includes any real logic. It's mostly presentation and
integration code, with most of the logic (and some presentation) in the
backend. But even in integration code, it's useful to have at least static
imports.


> but … we need es6-modules/import to manage frontend-projects that load
> dozens/hundreds of modules in the browser!  no, that’s a backend-thinking
> design-pattern, that's idiotic on the frontend and often leads to
> web-project failure, due to all the integration-problems it entails in
> practice.
>

The front-end benefits IMHO were way too over-hyped, I agree (bundling and
prototyping excluded). But it's in the back end where you really start
seeing benefits. Node's `require` is *incredibly* slow, enough to be a
performance burden on many applications. If you can parallelize and
optimize module resolution, that would be very helpful for them, and that's
one of the main reasons for making `import()` async.


> most of us honestly should learn to write leaner, frontend glue-code that
> doesn’t require dozens of superfluous modules;
>

Sounds like a great idea in theory. In practice, there is an unavoidable
amount of complexity to everything - not all apps can be kept this simple.

or hire better/trained frontend-engineers who can; rather than place faith
> in “scalable" frontend-solutions that falsely assume most UX-problems can
> be solved by throwing 10x clueless backend-engineers at it (resulting in
> 10x useless and hard-to-integrate “frontend” code).
>
> a normal web-project with about a dozen frontend-modules shouldn’t require
> complicated es6-module infrastructure at all.  and if it successfully
> evolves to the scale of something like facebook or gmail, your
> frontend-engineering-team is more likely to come up with a custom
> module-framework better-suited for your specific use-case than again, rely
> on es6-modules (and entrust your at-scale, product-specific, module-loading
> issues to tc39’s design-by-commitee process).
>

Problem: if we have N different standards, how are companies supposed to
share their own open source code?


> kai zhu
> kaizhu...@gmail.com
>
>
>
> On 9 May 2018, at 8:43 AM, Isiah Meadows  wrote:
>
> Missed the list somehow...
>
> -- Forwarded message --
> From: Isiah Meadows 
> Date: Tue, May 8, 2018 at 8:43 PM
> Subject: Re: Dynamic `import` with options
> To: Peter Jaszkowiak 
>
>
> Here's three scenarios that aren't even possible without it:
>
> - Hot reloading: https://github.com/nodejs/node/issues/8443
>
> - Loading modules uncached:
>- https://www.npmjs.com/package/import-fresh
>- https://github.com/nodejs/node/issues/8443#issuecomment-382316960
>- Automatic re-runs of module-based tests in the browser.
>
> - Loading modules with mocks:
>- https://www.npmjs.com/package/proxyquire
>- https://www.npmjs.com/package/mock-require
>- https://nodejs.org/api/esm.html#esm_dynamic_instantiate_hook
> (requires a synthetic module and a lot of boilerplate to do it,
> though)
>
> There's other use cases, too:
>
> - Integrating `import` with `WebAssembly.instantiate`:
> https://webassembly.org/docs/js/#webassemblyinstantiate
> - Easier importing relative to another directory (important when
> dependencies get involved).
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Tue, May 8, 2018 at 8:04 PM, Peter Jaszkowiak 
> wrote:
>
> What are some use cases, and how are they easier done this 

Re: Dynamic `import` with options

[T.J. Crowder]

On Wed, May 9, 2018 at 9:25 AM, kai zhu
 wrote:
> or … we could avoid integration-level headaches that shouldn’t even exist,
> by avoiding es6-modules altogether and

Yes. I talked to my team of average developers, and many were increasingly
of the opinion that they’d all made a big mistake in coming down from the
trees in the first place. And some said that even the trees had been a bad
move, and that no one should ever have left the oceans.

*(With apologies to Douglas Adams)*

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Dynamic `import` with options

[kai zhu]

or … we could avoid integration-level headaches that shouldn’t even exist, by 
avoiding es6-modules altogether and

1) sticking with well-understood require(...) in nodejs and not cross-cut it 
with import(…, options), and
2) sticking with well-understood global-assignment of modules in browsers (with 
long/descriptive names to avoid name-clash).

but … we need es6-modules/import to manage frontend-projects that load 
dozens/hundreds of modules in the browser!  no, that’s a backend-thinking 
design-pattern, that's idiotic on the frontend and often leads to web-project 
failure, due to all the integration-problems it entails in practice.

most of us honestly should learn to write leaner, frontend glue-code that 
doesn’t require dozens of superfluous modules; or hire better/trained 
frontend-engineers who can; rather than place faith in “scalable" 
frontend-solutions that falsely assume most UX-problems can be solved by 
throwing 10x clueless backend-engineers at it (resulting in 10x useless and 
hard-to-integrate “frontend” code).

a normal web-project with about a dozen frontend-modules shouldn’t require 
complicated es6-module infrastructure at all.  and if it successfully evolves 
to the scale of something like facebook or gmail, your 
frontend-engineering-team is more likely to come up with a custom 
module-framework better-suited for your specific use-case than again, rely on 
es6-modules (and entrust your at-scale, product-specific, module-loading issues 
to tc39’s design-by-commitee process).

kai zhu
kaizhu...@gmail.com



> On 9 May 2018, at 8:43 AM, Isiah Meadows  wrote:
> 
> Missed the list somehow...
> 
> -- Forwarded message --
> From: Isiah Meadows 
> Date: Tue, May 8, 2018 at 8:43 PM
> Subject: Re: Dynamic `import` with options
> To: Peter Jaszkowiak 
> 
> 
> Here's three scenarios that aren't even possible without it:
> 
> - Hot reloading: https://github.com/nodejs/node/issues/8443
> 
> - Loading modules uncached:
>- https://www.npmjs.com/package/import-fresh
>- https://github.com/nodejs/node/issues/8443#issuecomment-382316960
>- Automatic re-runs of module-based tests in the browser.
> 
> - Loading modules with mocks:
>- https://www.npmjs.com/package/proxyquire
>- https://www.npmjs.com/package/mock-require
>- https://nodejs.org/api/esm.html#esm_dynamic_instantiate_hook
> (requires a synthetic module and a lot of boilerplate to do it,
> though)
> 
> There's other use cases, too:
> 
> - Integrating `import` with `WebAssembly.instantiate`:
> https://webassembly.org/docs/js/#webassemblyinstantiate
> - Easier importing relative to another directory (important when
> dependencies get involved).
> -
> 
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
> 
> 
> On Tue, May 8, 2018 at 8:04 PM, Peter Jaszkowiak  wrote:
>> What are some use cases, and how are they easier done this way than through
>> existing alternatives, like returning a factory function.
>> 
>> On May 8, 2018 17:57, "Isiah Meadows"  wrote:
>> 
>> Yeah, it's about that time. I'm proposing adding support for an
>> options object as a second "argument" for the call-like `import()`,
>> something like `import("./foo.mjs", {...options})`. To complement
>> this, I also propose adding a hook to allow embedders to optionally
>> return something different from the call rather than the usual import
>> and/or change the way something is imported.
>> 
>> -
>> 
>> Isiah Meadows
>> m...@isiahmeadows.com
>> www.isiahmeadows.com
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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