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

Groups > comp.lang.javascript > #22794 > unrolled thread

Re: JavaScript unfairly blamed?

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-26 02:37 -0800
    Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-26 11:52 +0100
      Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-26 12:04 -0800
        Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-26 22:24 +0100
          Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-26 14:49 -0800
            Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-27 02:14 +0100
              Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-27 18:30 -0800
                Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 19:08 +0100
                  Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-28 19:50 +0100
                    Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 21:18 +0100
                      Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-28 22:27 +0100
                        Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 23:23 +0100
                          Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-29 17:12 +0100
                            Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-31 22:30 +0100
                              Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 22:35 +0100
                      Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-28 19:59 -0800
                        Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-31 14:08 +0100
                          Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 22:52 +0100
                            Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-02-02 10:09 -0800
                              Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-04 23:42 +0100
                    Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-28 19:40 -0800
                      Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-29 17:17 +0100
                        Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-29 16:51 -0800
                          Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-31 01:06 +0100
                  Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-28 19:36 -0800
                    Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-31 14:47 +0100
        Re: JavaScript unfairly blamed? John Harris <niam@jghnorth.org.uk.invalid> - 2014-01-27 14:36 +0000
          Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-27 16:05 -0800
            Re: JavaScript unfairly blamed? John Harris <niam@jghnorth.org.uk.invalid> - 2014-01-29 15:26 +0000
              Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-29 16:44 -0800
                "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-30 11:10 +0100
                  Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Tim Streater <timstreater@greenbee.net> - 2014-01-30 10:38 +0000
                    Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-30 13:30 +0100
                      Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-30 12:45 +0000
                        Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-30 14:05 +0100
                          Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-01-31 21:32 +0000
                            OT: "impedance mismatch" (was: "impedance mismatch", was: Re: JavaScript unfairly blamed?) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 01:15 +0100
                            Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-01 02:40 +0000
                              Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-01 10:02 +0100
                            Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-01 09:54 +0100
                  Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-30 11:06 +0000
                    Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-30 14:02 +0100
                      Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "ViLco" <villiber@tin.it> - 2014-01-30 16:24 +0100
                      Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-31 00:35 +0000
                        Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-31 11:16 +0100
                  Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-30 15:14 -0800
                    Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-31 00:56 +0100
                      Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-30 22:13 -0800
                        Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-31 11:51 +0100
                  Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <J.R.Stockton@physics.org> - 2014-01-31 19:58 +0000
                    Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-01 09:30 +0100
                      Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-02 17:44 +0000
                        Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-03 01:15 +0100
                          Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? John Harris <niam@jghnorth.org.uk.invalid> - 2014-02-03 14:58 +0000
                            Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Tim Streater <timstreater@greenbee.net> - 2014-02-03 15:36 +0000
                              Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-03 17:59 +0100
                                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Tim Streater <timstreater@greenbee.net> - 2014-02-03 17:18 +0000
                                  Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-03 19:47 +0100
                                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? John Harris <niam@jghnorth.org.uk.invalid> - 2014-02-04 10:33 +0000
                                  Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-06 13:40 +0100
                            Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-06 10:12 +0000
                              Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-07 10:32 +0100
                                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-08 23:06 +0000
                                  Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-09 10:33 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#22866

On Tuesday, January 28, 2014 12:50:09 PM UTC-6, Christoph Michael Becker wrote:
> 
> I believe at least one of the arguments Michael has made, is that the
> DOM defines interfaces, but not actual objects ("classes"), which can be
> extended.  While a particular DOM implementation might expose an Element
> object, for instance, this is not mandatory.  For that reason alone it
> is not possible to reliably extend DOM objects (let alone the problem
> that they are host objects, and ECMAScript leaves broad room for the
> actual behavior of these), what may be regarded as (impedance) mismatch.
 
Indeed: get a reference to an "object", and you may be in for a surprise when you try to treat it like any other object

> Apparently, many programmers desire the ability to extend the DOM, and
> so use libraries which simulate this feature, such as jQuery.

...or at least cheap wrappers around the elements

[toc] | [prev] | [next] | [standalone]

#22875

Michael Haufe (TNO) wrote:

> On Tuesday, January 28, 2014 12:50:09 PM UTC-6, Christoph Michael Becker wrote:
>>
>> Apparently, many programmers desire the ability to extend the DOM, and
>> so use libraries which simulate this feature, such as jQuery.
> 
> ...or at least cheap wrappers around the elements

I'm not sure if there is something as a *cheap* wrapper for DOM elements
(nodes might be the more appropriate term here).  What about
HTMLCollections, for instance?

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22879

hristoph Michael Becker wrote:
> Michael Haufe (TNO) wrote:
> 
> >  Christoph Michael Becker wrote:
> >>
> >> Apparently, many programmers desire the ability to extend the DOM, and
> >> so use libraries which simulate this feature, such as jQuery.
> > 
> > ...or at least cheap wrappers around the elements
> 
> I'm not sure if there is something as a *cheap* wrapper for DOM elements
> (nodes might be the more appropriate term here).  What about
> HTMLCollections, for instance?

Sorry, I was using the word "cheap" to mean a simplistic decorator object:

function MyObject(){
  //...
  this._domObject = someNode
  //..
}
MyObject.prototype = {
  //...
  myMethod: function(){
     //...
     this._domObject.someMethod()
     //...
  },
  //...
}

[toc] | [prev] | [next] | [standalone]

#22897

Michael Haufe (TNO) wrote:

> Christoph Michael Becker wrote:
>> Michael Haufe (TNO) wrote:
>>
>>>  Christoph Michael Becker wrote:
>>>>
>>>> Apparently, many programmers desire the ability to extend the DOM, and
>>>> so use libraries which simulate this feature, such as jQuery.
>>>
>>> ...or at least cheap wrappers around the elements
>>
>> I'm not sure if there is something as a *cheap* wrapper for DOM elements
>> (nodes might be the more appropriate term here).  What about
>> HTMLCollections, for instance?
> 
> Sorry, I was using the word "cheap" to mean a simplistic decorator object:
> 
> function MyObject(){
>   //...
>   this._domObject = someNode
>   //..
> }
> MyObject.prototype = {
>   //...
>   myMethod: function(){
>      //...
>      this._domObject.someMethod()
>      //...
>   },
>   //...
> }

Thanks for the explanation.  This technique is a reasonable solution, IMHO.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22865

On Tuesday, January 28, 2014 12:08:36 PM UTC-6, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> 
> > [fallacies]
>
> [I reject your reality and substitute my own]

...or so it seems

> > Regardless of what the origin was, the evolution has been divergent
>                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > (though there has been efforts to improve this lately).
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> What are you talking about?
 
Advancements in the DOM and JS occurring separately, and at times in conflict, that require alignment from time to time. I could point to instances on es-discuss and elsewhere, but you seem to think URLs are unsound...


 
> Again, why? 
> 
> 1. DOMs are specified using *interfaces* that are to be *implemented*.
> 
> 2. Interfaces are a concept of, and are intended for use in,
>    *object-oriented programming languages*.
> 
> 3. ECMAScript *implementations* *are* object-oriented programming languages.
> 
> Where is the mismatch?

You need to step up into a different level of abstraction. The very concept of I.M. is still escaping you. First, and not at least, there are no interfaces in jAvAsCrIpT. The *provided* implementations of those interfaces are not even instances of JS "objects", and this has impact on the way these "objects" are treated (differently)

> Throwing a bunch of URIs at people is no substitute for a sound argument.

It seems to be an iron bubble if even references and further reading are anathema... 

> Here we go again.

Who is "we"? Do you have a mouse in your pocket?

[toc] | [prev] | [next] | [standalone]

#22908

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > [fallacies]
>>
>> [I reject your reality and substitute my own]
> 
> ...or so it seems

A misconception, and a fallacy, on your part of course.
 
>> > Regardless of what the origin was, the evolution has been divergent
>>                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > (though there has been efforts to improve this lately).
>>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> What are you talking about?
>  
> Advancements in the DOM and JS occurring separately, and at times in
> conflict, that require alignment from time to time. I could point to
> instances on es-discuss and elsewhere,

No, you should.

> but you seem to think URLs are unsound...

Yes, that only seems to be so.
 
>> Again, why?
>> 
>> 1. DOMs are specified using *interfaces* that are to be *implemented*.
>> 
>> 2. Interfaces are a concept of, and are intended for use in,
>>    *object-oriented programming languages*.
>> 
>> 3. ECMAScript *implementations* *are* object-oriented programming
>> languages.
>> 
>> Where is the mismatch?
> 
> You need to step up into a different level of abstraction. The very
> concept of I.M. is still escaping you.

It would probably help if I knew what you meant by “I.M.”

> First, and not at least, there are no interfaces in jAvAsCrIpT.

So what?

> The *provided* implementations of those interfaces are not even instances
> of JS "objects",

Again, what does it matter?  The ECMAScript Specification defines what a 
host object is, and allows for host objects.  Now some of these host objects 
implement interfaces specified elsewhere.

> and this has impact on the way these "objects" are treated (differently)

Yes, the ES Specification states that host objects do not have to follow all 
of the specified rules (algorithms) to the letter, and which ones they do 
have to follow.  Which makes it risky for *end* developers to attempt to 
augment them.  (Unfortunately, it is done anyway, and many users of 
libraries do not even know that.)
 
>> Throwing a bunch of URIs at people is no substitute for a sound argument.
> 
> It seems to be an iron bubble if even references and further reading are
> anathema...

I have no problem with references; I welcome them, and as you may have 
noticed, I use them in my writing.  I have a problem with references to 
*other* people’s arguments without sound argument of one’s own that they are 
attached to.  As if such a reference alone would be sufficient to provide 
for one’s sound argument.

In a *constructive* discussion, it is the task of the person making the 
argument to support it (with references); it is not the task of the person 
doubting it to find the statements (in the other’s references) that support 
it, or complementing the other’s missing references with their own 
references to refute it.  Otherwise the argument is fallacious (either 
argument at authority or shifting the burden of proof, respectively).
 
>> Here we go again.
> 
> Who is "we"?

The two of us: You, using obscure language; me, therefore not understanding 
it, and you.

> Do you have a mouse in your pocket?

No, I have a mouse lying next to my computer (and maybe, but hopefully not, 
in the cellar, as there is no cat or OWL nearby – short of software and 
ASCII art).  Is it required to have a mouse in one’s pocket while discussing 
with you?  I can do that; it is, after all, a cordless one.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#22824

On Sun, 26 Jan 2014 12:04:50 -0800 (PST), "Michael Haufe (TNO)"
<tno@thenewobjective.com> wrote:

  <snip>
>there are impedance mismatches that
>occur,
  <snip>

Once upon a time an IT person picked up the term 'impedance mismatch'
from an electronics colleague and started using it without realising
the side effects.

When there is an impedance mismatch an incoming wave is both reflected
and transmitted. In certain circumstances the transmitted wave is an
evanescent wave (the basis of quantum tunneling). Also when there is a
mismatch the power transmitted is less than the maximum possible,
which is why you have to use the right kind of cable to connect to
your TV aerial.

Now, which of these effects were you thinking of in your analogy?

Of course, 'impedance mismatch' sounds much more scientific and
imposing than a mere 'mismatch' when two things don't go together very
well.

  John

[toc] | [prev] | [next] | [standalone]

#22831

On Monday, January 27, 2014 8:36:06 AM UTC-6, John Harris wrote:

> Once upon a time an IT person picked up the term 'impedance mismatch'
> from an electronics colleague and started using it without realising
> the side effects.
> 
> When there is an impedance mismatch an incoming wave is both reflected
> and transmitted. In certain circumstances the transmitted wave is an
> evanescent wave (the basis of quantum tunneling). Also when there is a
> mismatch the power transmitted is less than the maximum possible,
> which is why you have to use the right kind of cable to connect to
> your TV aerial.
> 
> Now, which of these effects were you thinking of in your analogy?
> 
> Of course, 'impedance mismatch' sounds much more scientific and
> imposing than a mere 'mismatch' when two things don't go together very
> well.

I'm using the term as understood in CS literature since at least 1997, for example:
<http://osm7.cs.byu.edu/ER97/workshop4/sw.html>
<http://web.archive.org/web/20111110122106/http://homepages.cwi.nl/~ralf/xo-impedance-mismatch/paper.pdf>

Namely, from the latter reference: 

<quote>
“‘Impedance mismatch’ is derived from the usage of impedance as a
measurement of the ability of one system to efficiently accommodate
the output (energy, information, etc.) of another. [...] Although
the term originated in the field of electrical engineering, it has
been generalized and used as a term of art in systems analysis, 
electronics, computer science, informatics, and physics.” 
In particular, the term is also used “to refer to the difficulties
encountered when attempting to connect two systems which have very
different conceptual bases”.
</quote>

[toc] | [prev] | [next] | [standalone]

#22873

On Mon, 27 Jan 2014 16:05:51 -0800 (PST), "Michael Haufe (TNO)"
<tno@thenewobjective.com> wrote:

>On Monday, January 27, 2014 8:36:06 AM UTC-6, John Harris wrote:
>
>> Once upon a time an IT person picked up the term 'impedance mismatch'
>> from an electronics colleague and started using it without realising
>> the side effects.
>> 
>> When there is an impedance mismatch an incoming wave is both reflected
>> and transmitted. In certain circumstances the transmitted wave is an
>> evanescent wave (the basis of quantum tunneling). Also when there is a
>> mismatch the power transmitted is less than the maximum possible,
>> which is why you have to use the right kind of cable to connect to
>> your TV aerial.
>> 
>> Now, which of these effects were you thinking of in your analogy?
>> 
>> Of course, 'impedance mismatch' sounds much more scientific and
>> imposing than a mere 'mismatch' when two things don't go together very
>> well.
>
>I'm using the term as understood in CS literature since at least 1997, for example:
><http://osm7.cs.byu.edu/ER97/workshop4/sw.html>
><http://web.archive.org/web/20111110122106/http://homepages.cwi.nl/~ralf/xo-impedance-mismatch/paper.pdf>
>
>Namely, from the latter reference: 
>
><quote>
>“‘Impedance mismatch’ is derived from the usage of impedance as a
>measurement of the ability of one system to efficiently accommodate
>the output (energy, information, etc.) of another. [...] Although
>the term originated in the field of electrical engineering, it has
>been generalized and used as a term of art in systems analysis, 
>electronics, computer science, informatics, and physics.” 
>In particular, the term is also used “to refer to the difficulties
>encountered when attempting to connect two systems which have very
>different conceptual bases”.
></quote>

That still doesn't make it a good analogy. And the writer hasn't
explained how an impedance mismatch differs from a plain ordinary
mismatch. What does 'impedance' add to the concept?

(Incidentally, the Wikipedia entry no longer has that text.)

  John

[toc] | [prev] | [next] | [standalone]

#22878

John Harris wrote:
> "Michael Haufe (TNO)"

> ><quote>
> >“‘Impedance mismatch’ is derived from the usage of impedance as a
> >measurement of the ability of one system to efficiently accommodate
> >the output (energy, information, etc.) of another. [...] Although
> >the term originated in the field of electrical engineering, it has
> >been generalized and used as a term of art in systems analysis, 
> >electronics, computer science, informatics, and physics.” 
> >In particular, the term is also used “to refer to the difficulties
> >encountered when attempting to connect two systems which have very
> >different conceptual bases”.
> ></quote>
>
> That still doesn't make it a good analogy. And the writer hasn't
> explained how an impedance mismatch differs from a plain ordinary
> mismatch. What does 'impedance' add to the concept?
> 
> (Incidentally, the Wikipedia entry no longer has that text.)

I tried walking back the paper references as far as I could (1984 thus far), but I've yet to see a clear answer to where the cross-over occurred and the initial reasoning for the choice of this term. Thus far I'm assuming it is partly the etymology of the word: "impede" (hindering). It does sound strange though following that reasoning: "mismatch due to being hindered". Hopefully I can find the first usage of this in the CS field to see if it sheds any light.

[toc] | [prev] | [next] | [standalone]

#22881 — "impedance mismatch", was: Re: JavaScript unfairly blamed?

"Michael Haufe (TNO)" <tno@thenewobjective.com> wrote on 30 jan 2014 in
comp.lang.javascript: 

> I tried walking back the paper references as far as I could (1984 thus
> far), but I've yet to see a clear answer to where the cross-over
> occurred and the initial reasoning for the choice of this term. Thus far
> I'm assuming it is partly the etymology of the word: "impede"
> (hindering). It does sound strange though following that reasoning:
> "mismatch due to being hindered". Hopefully I can find the first usage
> of this in the CS field to see if it sheds any light. 

In electric current you have:

resistance, implying a form of linearity in Ohm's law: V = I x R
[all other factors assumed constant, like temperature, etc.]
The loss of power is usually disipated as heat.

Impedance is the same, be it that the value is not linear for alternating 
current, but depends on the frequency, so Ohm's law only appies with a fixed 
frequency. 

Conductance is the inverce of resistance: conductance = 1 / resistance

The inverse of impedance is compliance:  compliance = 1 / impedance 

Now all these terms so rigidly defined when applied to electric current,
are used more or less strict in other fields.

Compliance is used in lung function measurement, resistance in resisting 
occupation by a foreign power, to name a few, and probably some far precede 
the use in electric current.

These concepts are all far, far older than your 1984, when big brother 
started whatching you.

This preceding cannot be the case in computer scripting, since that concept 
is far more recent.

Power

btw, power, domestic or foreigh, when applied a resistance, can be written 
as: P = V x I.

When electric current is used for transmitting power over a cable,
power is lost:

1 The losses by resistance. These follow Ohm's law, when disregarding high 
frequency behavoure like skin-effect, etc.

2 The losses mismatch by impedance. The source [, the cable] and the "load", 
meaning the destination should all have the same impedance for the 
frequencies used. Otherwise part of the energy will be bounced back and the 
efficiency is lowered as partly the energy is finally dissipated in the 
cable and and partly that the source just is "hindered" in outputting the 
power.

I suppose this concept of "impedance mismatch" can also be used in other 
fields, where inherent losses during transmission, be it in teaching, 
sending food aid or indoctrination, can be minimized by sound engineering.

btw, the resistance of water though a tube, when the flow is low and so 
laminal, follows Ohm's law by having a fixed resistance; when the flow 
accelerates, suddenly the flow becomes turbulent and the resistance becomes 
a quadratic function of the current. A good example is the turbulent murmur 
of the blood you hear when there is a heartvalve stenosis and the current 
exeeds this limit. Personally, I would not call this impedance mismatch.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#22882 — Re: "impedance mismatch", was: Re: JavaScript unfairly blamed?

In article <XnsA2C571A54D08Beejj99@194.109.133.133>, Evertjan.
<exxjxw.hannivoort@inter.nl.net> wrote:

> "Michael Haufe (TNO)" <tno@thenewobjective.com> wrote on 30 jan 2014 in
> comp.lang.javascript: 
> 
> > I tried walking back the paper references as far as I could (1984 thus
> > far), but I've yet to see a clear answer to where the cross-over
> > occurred and the initial reasoning for the choice of this term. Thus far
> > I'm assuming it is partly the etymology of the word: "impede"
> > (hindering). It does sound strange though following that reasoning:
> > "mismatch due to being hindered". Hopefully I can find the first usage
> > of this in the CS field to see if it sheds any light. 
> 
> In electric current you have:
> 
> resistance, implying a form of linearity in Ohm's law: V = I x R
> [all other factors assumed constant, like temperature, etc.]
> The loss of power is usually disipated as heat.
> 
> Impedance is the same, be it that the value is not linear for alternating 
> current, but depends on the frequency, so Ohm's law only appies with a fixed 
> frequency.

Only for a non-resistive load (inductor or capacitor). For a pure
resistive load, impedance is independent of frequency.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#22884 — Re: "impedance mismatch", was: Re: JavaScript unfairly blamed?

Tim Streater <timstreater@greenbee.net> wrote on 30 jan 2014 in 
comp.lang.javascript:

> Only for a non-resistive load (inductor or capacitor). For a pure
> resistive load, impedance is independent of frequency.

That depends on the definition.

Impedance can be defined as the non-resistive part of the load.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#22885 — Re: "impedance mismatch", was: Re: JavaScript unfairly blamed?

On Thu, 30 Jan 2014 13:30:12 +0100, Evertjan. wrote:

> Tim Streater <timstreater@greenbee.net> wrote on 30 jan 2014 in
> comp.lang.javascript:
> 
>> Only for a non-resistive load (inductor or capacitor). For a pure
>> resistive load, impedance is independent of frequency.
> 
> That depends on the definition.
> 
> Impedance can be defined as the non-resistive part of the load.

Nope, that's just the reactive component of the impedance. Impedance 
across a two terminal device is a combination (the vector sum) of the 
resistive and reactive components.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#22887 — Re: "impedance mismatch", was: Re: JavaScript unfairly blamed?

Denis McMahon <denismfmcmahon@gmail.com> wrote on 30 jan 2014 in 
comp.lang.javascript:

> On Thu, 30 Jan 2014 13:30:12 +0100, Evertjan. wrote:
> 
>> Tim Streater <timstreater@greenbee.net> wrote on 30 jan 2014 in
>> comp.lang.javascript:
>> 
>>> Only for a non-resistive load (inductor or capacitor). For a pure
>>> resistive load, impedance is independent of frequency.
>> 
>> That depends on the definition.
>> 
>> Impedance can be defined as the non-resistive part of the load.
> 
> Nope, that's just the reactive component of the impedance. Impedance 
> across a two terminal device is a combination (the vector sum) of the 
> resistive and reactive components.

I disagree.

Fighting about a definition won't be very effective.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#22919 — Re: "impedance mismatch", was: Re: JavaScript unfairly blamed?

In comp.lang.javascript message <XnsA2C58F5115D30eejj99@194.109.133.133>
, Thu, 30 Jan 2014 14:05:18, Evertjan. <exxjxw.hannivoort@inter.nl.net>
posted:

>Denis McMahon <denismfmcmahon@gmail.com> wrote on 30 jan 2014 in
>comp.lang.javascript:
>
>> On Thu, 30 Jan 2014 13:30:12 +0100, Evertjan. wrote:
>>
>>> Tim Streater <timstreater@greenbee.net> wrote on 30 jan 2014 in
>>> comp.lang.javascript:
>>>
>>>> Only for a non-resistive load (inductor or capacitor). For a pure
>>>> resistive load, impedance is independent of frequency.

That is not necessarily the case.  Consider a load which is an ordinary
variable resistor whose shaft is turned by the pointer-axle of an
analogue frequency meter (of infinite input impedance) connected across
the load, being driven by a slowly-varying frequency.

A load is purely resistive if its impedance has no reactive components
at any relevant frequency.

And, whatever an electrical engineer might say, a pure resistance does
not necessarily obey Ohm's Law.  Consider the filament of a traditional
domestic electric light bulb, which changes its resistance significantly
from bulb off to bulb on.

I write as one who has visited the Ohm-Bau (and been made welcome
there).

>>> That depends on the definition.
>>>
>>> Impedance can be defined as the non-resistive part of the load.
>>
>> Nope, that's just the reactive component of the impedance. Impedance
>> across a two terminal device is a combination (the vector sum) of the
>> resistive and reactive components.
>
>I disagree.
>
>Fighting about a definition won't be very effective.

Especially when you disagree with thoroughly established convention.
You might as well say that Herman Achille Van Rompuy is King of Holland.


-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[toc] | [prev] | [next] | [standalone]

#22920 — OT: "impedance mismatch" (was: "impedance mismatch", was: Re: JavaScript unfairly blamed?)

Dr J R Stockton wrote:

> In comp.lang.javascript message <XnsA2C58F5115D30eejj99@194.109.133.133>
> , Thu, 30 Jan 2014 14:05:18, Evertjan. <exxjxw.hannivoort@inter.nl.net>
> posted:
> 
>> Denis McMahon <denismfmcmahon@gmail.com> wrote on 30 jan 2014 in
>> comp.lang.javascript:
>>
>>> On Thu, 30 Jan 2014 13:30:12 +0100, Evertjan. wrote:
>>>
>>>> Tim Streater <timstreater@greenbee.net> wrote on 30 jan 2014 in
>>>> comp.lang.javascript:
>>>>
>>>>> Only for a non-resistive load (inductor or capacitor). For a pure
>>>>> resistive load, impedance is independent of frequency.
> 
> That is not necessarily the case.  Consider a load which is an ordinary
> variable resistor whose shaft is turned by the pointer-axle of an
> analogue frequency meter (of infinite input impedance) connected across
> the load, being driven by a slowly-varying frequency.
> 
> A load is purely resistive if its impedance has no reactive components
> at any relevant frequency.
> 
> And, whatever an electrical engineer might say, a pure resistance does
> not necessarily obey Ohm's Law.  Consider the filament of a traditional
> domestic electric light bulb, which changes its resistance significantly
> from bulb off to bulb on.
> 
> I write as one who has visited the Ohm-Bau (and been made welcome
> there).
> 
>>>> That depends on the definition.
>>>>
>>>> Impedance can be defined as the non-resistive part of the load.
>>>
>>> Nope, that's just the reactive component of the impedance. Impedance
>>> across a two terminal device is a combination (the vector sum) of the
>>> resistive and reactive components.
>>
>> I disagree.
>>
>> Fighting about a definition won't be very effective.
> 
> Especially when you disagree with thoroughly established convention.
> You might as well say that Herman Achille Van Rompuy is King of Holland.

Um, I somewhat wonder whether this discussion is OT in
comp.lang.javascript.  Is it about the "impedance mismatch" of what
*should* be discussed here vs. what *is* discussed? ;)

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22921 — Re: "impedance mismatch", was: Re: JavaScript unfairly blamed?

On Fri, 31 Jan 2014 21:32:41 +0000, Dr J R Stockton wrote:

> And, whatever an electrical engineer might say, a pure resistance does
> not necessarily obey Ohm's Law.  Consider the filament of a traditional
> domestic electric light bulb, which changes its resistance significantly
> from bulb off to bulb on.

Don't confuse the words pure and constant. A pure resistance is one with 
no reactive (ie inductive or capacitive) component. A constant resistance 
is one which does not change.

The resistivity (or conductance) of most materials varies with 
temperature, this does not usually affect their purity as a resistor 
(which is invariably less than 100%, because reactive components tend to 
creep in).

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#22924 — Re: "impedance mismatch", was: Re: JavaScript unfairly blamed?

Denis McMahon <denismfmcmahon@gmail.com> wrote on 01 feb 2014 in 
comp.lang.javascript:

> On Fri, 31 Jan 2014 21:32:41 +0000, Dr J R Stockton wrote:
> 
>> And, whatever an electrical engineer might say, a pure resistance does
>> not necessarily obey Ohm's Law.  Consider the filament of a traditional
>> domestic electric light bulb, which changes its resistance significantly
>> from bulb off to bulb on.
> 
> Don't confuse the words pure and constant. A pure resistance is one with 
> no reactive (ie inductive or capacitive) component. A constant resistance 
> is one which does not change.
> 
> The resistivity (or conductance) of most materials varies with 
> temperature, this does not usually affect their purity as a resistor 
> (which is invariably less than 100%, because reactive components tend to 
> creep in).

Indeed Ohm's law invariably is not encountered in practice.

Purety only exists in religion, not in science.

However, since computer scripting is discrete and not analog,
Ohm's law can nicely be used as a numerical approximation of the real world,
disregarding small mismatches in pure exactness.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#22923 — Re: "impedance mismatch", was: Re: JavaScript unfairly blamed?

Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> wrote on 31 jan 2014 
in comp.lang.javascript:

>>>>> Only for a non-resistive load (inductor or capacitor). For a pure
>>>>> resistive load, impedance is independent of frequency.
> 
> That is not necessarily the case.  Consider a load which is an ordinary
> variable resistor whose shaft is turned by the pointer-axle of an
> analogue frequency meter (of infinite input impedance) connected across
> the load, being driven by a slowly-varying frequency.

Seems we have a definition mismatch of the word "pure".

Ordinary variable [or invariable] resistors invariably are not "pure",
absolute purity being a theoretical property.

> A load is purely resistive if its impedance has no reactive components
> at any relevant frequency.

Why call it an impedance then? [sorry, I did above ;-( ]

If a load has reactive components at any relevant frequency,
in other words, if it has impedance at any relevant frequency,
what is the sense of calling it "purely resistive"?

If the relevant frequency is fixed, 
we could call any impedance resistive,
when forgetting about fase differences and dissipation,
but what is the sense in that?

A load is purely resistive only if its impedance is zero.

Guess we might, pedantically or impedantically,
impudently argue about the definition of "impedance" too.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web