Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #31111

Re: filter queryselectorall

Show all headers | View raw

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
 
> > "just for the sake of it"? I think there is something behind this you
> > could expand on.
> 
> Because it’s “cool” to use it, not because there is considerable *tangible* 
> benefit in using it.

I think I see where you're coming from.

CoffeeScript vs. Babel for instance.

The former being a cutesy short syntax and fundamentally broken semantically

The latter for it's downrev compilation.
  
> > I'd rather people kept with "compiler".
> 
> There is a difference.  “Transpiler” is in fact a not-so-new [1] portmanteau 
> standing for “transcoding compiler” which in turn stands in for “translating 
> source-to-source compiler”.  The difference is that a compiler usually does 
> not generate source code, but *machine* code.
>  
> <https://en.wikipedia.org/wiki/Source-to-source_compiler>
> 
> [1] 
> <https://www.google.com/search?q=transpiler&safe=active&source=lnt&tbs=cdr%3A1%2Ccd_min%3A01.01.1960%2Ccd_max%3A31.12.2000&tbm=>
> 
> (The Google Books Ngram Viewer at <https://books.google.com/ngrams> did not 
> have “transpiler”, so I tried a time-based Google Search.)

Right, but it's the vagueness I find somewhat irksome. 100% opinion based.

> > Which of these counts as "transpilation" vs. "compilation"?
> > 
> > ES6 -> ES6 (minified)
> 
> That does not count either as transpilation or compilation in my book 
> because the underlying programming language stays the same.  Therefore the 
> proper term is, obviously, “minification” or “minifying”, which I would 
> categorize as a form of automated refactoring, and define as refactoring in 
> order to generate equivalent source code that is as small as possible.

Right. The semantics are the same.

> > ES6 -> ES5
> > ES6 -> ES3
> 
> It is debatable whether that alone can be called transpilation because one 
> could argue that the underlying programming language stays the same 
> (ECMAScript), only that the resulting source code is executable by an 
> implementation of an earlier specification of it.  However, usually the 
> software that does this conversion does more than just that (I am thinking 
> of the TypeScript compiler as an example).

You see this debate in other languages as well.

Perl 6 vs Perl 5.

Python 2 vs Python 3

While the differening versions still have the same name, 
they're semantically different as well as syntactically.

> > ES6 -> asm.js
> 
> Is there such a thing?  If yes, see above, as asm.js is “an extraordinarily 
> optimizable, low-level subset of JavaScript”, according to its Web site, and 
> “a strict subset of JavaScript” according to its Specification (August 
> 2014[!] Working Draft).

I'm still using the legacy terminology. It's been succeeded by WebAssembly which is on a standards track:

<https://webassembly.github.io/>

> BTW, I recently noticed that the 7th Edition of the ECMAScript Language 
> Specification, ECMAScript 2016, has been published in 2016-06.  The HTML 
> version is available at <http://ecma-international.org/ecma-262/7.0/>.
> It should be noted that
> 
> | [that] ECMAScript specification is the first ECMAScript edition released 
> | under Ecma TC39's new yearly release cadence and open development process. 
> | A plain-text source document was built from the ECMAScript 2015 source 
> | document to serve as the base for further development entirely on GitHub. 
> | Over the year of this standard's development, hundreds of pull requests 
> | and issues were filed representing thousands of bug fixes, editorial fixes 
> | and other improvements. Additionally, numerous software tools were 
> | developed to aid in this effort including Ecmarkup, Ecmarkdown, and 
> | Grammarkdown. This specification also includes support for a new 
> | exponentiation operator and adds a new method to Array.prototype called 
> | includes.

Yes, I'm still subscribed to es-discuss mailing list and contribute once in a blue moon.

> > If you dislike it as being too terse, fair enough. I assume you know that
> > the semantics of "function(){...this...}" differ from "() => {...this...}"
> 
> No, I was unaware that “this” would be the “undefined” value with the arrow 
> function syntax with braces when the defined function is called.  I find it 
> even more disturbing that “arguments” is not defined with either arrow 
> function syntax.  (Tested in the Chrome DevTools console in Chromium 
> “51.0.2704.79 Built on 8.4, running on Debian stretch/sid (64-bit)”.)

regarding "arguments", that's what rest parameters are for now:

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters>

regarding "this", you can some of the semantics:

//ES6
var foo = {
  m1: function(){ this },
  m2: () => this,
  m3(){ return this }  
}

//ES5
var _this = this;
var foo = {
    m1: function () { this; },
    m2: function () { return _this; },
    m3: function () { return this; }
};


This is more useful when used with a class:

//ES6
class Foo {
	method(){
		var self = this;

		var foo = {
			m1: function(){ this },
			m2: () => this,
			m3(){ return this }  
		}
	}
}

//ES5
function Foo() {}
Foo.prototype.method = function(){
	var _this = this;
	var self = this;
	var foo = {
		m1: function () { this; },
		m2: function () { return _this; },
		m3: function () { return this; }
	};
};


> > Assuming the Tracing JIT doesn't do its job... [1]
> 
> That argument is based on wishful thinking.  There does not have to be a 
> Tracing JIT in the first place.

My point here was that this should be a very low priority during development.

I don't want to see too much cleverness in code for the sake of minor perf-gains

The worst example here is manual loop unrolling, which used to be a fad in ES3 days:

<https://en.wikipedia.org/wiki/Loop_unrolling#Static.2Fmanual_loop_unrolling>

> > JavaScript isn't expressive enough (Yet?) to define the constraints and
> > intent  properly anyway. (interfaces and such)
> 
> That depends on what you call “JavaScript”.  But from ECMAScript Edition 3 
> on you can certainly implement interfaces in all ways that matter:
> 
> - You can define an interface as an object (of a user-defined type) that has
>   certain no-op methods;
> 
> - You can define that a user-defined type implements an interface, meaning
>   that its prototype must implement the methods of the interface that
>   the type implements;
> 
> - you can subject an object to an interface test (it must inherit or 
>   implement certain methods) and throw an exception if it does not pass
>   that test.
> 
> It is possible to improve on that by defining an interface as an object that 
> (additionally) has a description of required properties and property types 
> as as properties, and work with that in the same way.  One can define 
> setters and getters so that the initial type of a property is preserved, or 
> one can use language extensions (e.g. for strict typing).

That's implying the constraints and semantics more than declaring them.

I fall on the side of the type debate that says that typed languages
are more expressive than untyped ones (Church Typing over Curry Typing).
We could debate this, but we'll be repeating some very detailed
arguments from Lambda The Ultimate. About once a year I revisit this
very long thread. It's worth wading through if you have the patience 
and any interest in Programming Language Theory:

<http://lambda-the-ultimate.org/node/100>
<http://lambda-the-ultimate.org/node/175>
<http://lambda-the-ultimate.org/node/220>

(warning): VERY long read. A vague summary on the part we're touching one:

<http://www.lispcast.com/church-vs-curry-types>

> That may be so, but you are missing the point: the problem is not with the 
> standards bodies but intrinsic in the relevant, evolutionally grown APIs.  
> It can only be solved satisfactorily by foregoing all attempts at 
> compatibility (backwards *and* forwards), and that would be unwise at best.

Oh I know the point all too well, having been burned by the XHTML2 movement.

I'm moreso expressing frustration with the sort of things we've both seen
over the years, such as your example of jQuery perverting standards, and
ASCII-turd CSS attempts: <https://www.w3.org/TR/css3-layout/>

I'm all for standards and evolution over revolution, but it continues to
be a sad state of affairs IMO that there is such a lack of perspective
and/or experience from so many on these committees...

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

filter queryselectorall Andrew Poulos <ap_prog@hotmail.com> - 2016-08-06 14:25 +1000
  Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-05 22:23 -0700
    Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-06 08:16 +0200
      Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-06 15:49 -0700
        Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 07:08 +0200
          Re: filter queryselectorall Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-08-07 07:17 +0200
            Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 07:58 +0200
          Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-07 10:30 -0700
            Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-07 21:16 +0200
              Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-09 21:18 -0700
                Re: filter queryselectorall Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-15 22:02 +0200
                Re: filter queryselectorall "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-08-15 23:16 -0700
  Re: filter queryselectorall "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-08-06 10:28 +0200

csiph-web