| Re: server-side vs.client-side [message #183589 is a reply to message #183584] |
Fri, 01 November 2013 17:53   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/1/2013 12:53 PM, Michael Vilain wrote:
> In article <52721771(dot)6090201(at)arnowelzel(dot)de>,
> Arno Welzel <usenet(at)arnowelzel(dot)de> wrote:
>
>> Christoph Michael Becker, 2013-10-30 20:54:
>>
>>> Jerry Stuckle wrote:
>>>
>>>> One question - since both you and Thomas seem to be from Germany, and
>>>> have the same misunderstanding of the word "normally", what does
>>>> "normally" translate to in German? What does it mean?
>>>
>>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>>> usually. Anyway, a misunderstanding of the term "normally" is not the
>>> problem here for me. In my opinion, it is correct to state: "PHP is
>>> normally (usually, most often etc.) used on a server (for server-side
>>> programming)."
>>>
>>> It is as well correct to state: "No programming language is normally
>>> either server-side or client-side." Otherwise it would mean, that there
>>> are programming languages that couldn't be used outside of a
>>> client-server context.
>>
>> Exactly *this* is the wrong assumption, what "normally" means in this
>> context. It does *NOT* mean that a language can *never* be used in other
>> ways - it only says that is the the most common use of it.
>
> I've never seen javascript run on anything but a browser. Unless
> someone's developed a non-browser version, I personally consider it a
> client-side scripting language. It's meant to control a browser and
> nothing else, which is the client for web pages.
>
> php is not intended to run on the browser. It runs on the server that
> the browser talks to. It can run as part of the web-server or from the
> command line. Same for perl, Java, python, ruby, or C. To me, that
> makes them server-side programming languages.
>
> I don't know if that matches other's definitions of server-side vs.
> client-side, but that's my definition.
>
Michael,
While I agree with your definitions, I should point out there are other
uses for PHP than server-side scripting. I prefer PHP to bash for
complicated CLI projects, for instance. And there is a package (I don't
remember the name) which allows javascript to run on the server,
although I've never seen anyone actually using it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: server-side vs.client-side [message #183590 is a reply to message #183584] |
Fri, 01 November 2013 18:37 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 01/11/13 16:53, Michael Vilain wrote:
> In article <52721771(dot)6090201(at)arnowelzel(dot)de>, Arno Welzel
> <usenet(at)arnowelzel(dot)de> wrote:
>
>> Christoph Michael Becker, 2013-10-30 20:54:
>>
>>> Jerry Stuckle wrote:
>>>
>>>> One question - since both you and Thomas seem to be from
>>>> Germany, and have the same misunderstanding of the word
>>>> "normally", what does "normally" translate to in German? What
>>>> does it mean?
>>>
>>> In Germany it is "normalerweise"/"üblicherweise", what means as
>>> much usually. Anyway, a misunderstanding of the term "normally"
>>> is not the problem here for me. In my opinion, it is correct to
>>> state: "PHP is normally (usually, most often etc.) used on a
>>> server (for server-side programming)."
>>>
>>> It is as well correct to state: "No programming language is
>>> normally either server-side or client-side." Otherwise it would
>>> mean, that there are programming languages that couldn't be used
>>> outside of a client-server context.
>>
>> Exactly *this* is the wrong assumption, what "normally" means in
>> this context. It does *NOT* mean that a language can *never* be
>> used in other ways - it only says that is the the most common use
>> of it.
>
> I've never seen javascript run on anything but a browser. Unless
> someone's developed a non-browser version, I personally consider it
> a client-side scripting language. It's meant to control a browser
> and nothing else, which is the client for web pages.
>
> php is not intended to run on the browser. It runs on the server
> that the browser talks to. It can run as part of the web-server or
> from the command line. Same for perl, Java, python, ruby, or C. To
> me, that makes them server-side programming languages.
>
Java is the one I've seen employed both sides almost equally,otherwise
what you say is broadly true. If we are talking browsers.
If we are talking generic custom client server apps, there are no real
restrictions on what you wrote either end in, beyond the ability of the
platform to support the code.
> I don't know if that matches other's definitions of server-side vs.
> client-side, but that's my definition.
>
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
| Re: server-side vs.client-side [message #183592 is a reply to message #183584] |
Fri, 01 November 2013 19:19 |
Stefan+Usenet
Messages: 3
Registered: June 2013
Karma: 0
|
Junior Member |
|
|
On Fri, 01 Nov 2013 17:53:28 Michael Vilain wrote:
> I've never seen javascript run on anything but a browser.
I do run javascript on the server within one of my web applications.
I don't like it, but the reason is that a certain XML-standard
allowes formulas to be specified ("javascript is used as the formula
language; the return value must be boolean"). So I use a wrapper
calling smjs to parse and execute this.
(Nevertheless I think that the term "client-side scripting language"
fits quite well. Other use-cases are rather exotic)
Bye,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Freude mit Stefan, lüstern und traumhaft!
(Sloganizer)
|
|
|
|
| Re: server-side vs.client-side [message #183594 is a reply to message #183589] |
Fri, 01 November 2013 21:10 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <l50ppv$qdo$1(at)dont-email(dot)me>, Jerry Stuckle
<jstucklex(at)attglobal(dot)net> wrote:
> I prefer PHP to bash for complicated CLI projects, for instance.
I prefer PHP to *any* shell for any scripting purpose. Life's
complicated enough without arcane syntax. Look, if I'd wanted to learn
TECO, I'd have learnt it, OK?
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: server-side vs.client-side [message #183596 is a reply to message #183594] |
Fri, 01 November 2013 22:25 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 01/11/13 21:10, Tim Streater wrote:
> In article <l50ppv$qdo$1(at)dont-email(dot)me>, Jerry Stuckle
> <jstucklex(at)attglobal(dot)net> wrote:
>
>> I prefer PHP to bash for complicated CLI projects, for instance.
>
> I prefer PHP to *any* shell for any scripting purpose. Life's
> complicated enough without arcane syntax. Look, if I'd wanted to learn
> TECO, I'd have learnt it, OK?
>
after years if writing C, I simply reach for the compiler if a three
line shell wont do it..
If there was the same library support in C and the ability to dump text
straight, I wouldn't use PHP at all.
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
| Re: server-side vs.client-side [message #183597 is a reply to message #183596] |
Fri, 01 November 2013 22:29 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <l519pl$lpt$1(at)news(dot)albasani(dot)net>, The Natural Philosopher
<tnp(at)invalid(dot)invalid> wrote:
> On 01/11/13 21:10, Tim Streater wrote:
>> In article <l50ppv$qdo$1(at)dont-email(dot)me>, Jerry Stuckle
>> <jstucklex(at)attglobal(dot)net> wrote:
>>
>>> I prefer PHP to bash for complicated CLI projects, for instance.
>>
>> I prefer PHP to *any* shell for any scripting purpose. Life's
>> complicated enough without arcane syntax. Look, if I'd wanted to learn
>> TECO, I'd have learnt it, OK?
>>
> after years if writing C, I simply reach for the compiler if a three
> line shell wont do it..
> If there was the same library support in C and the ability to dump text
> straight, I wouldn't use PHP at all.
Mmm, well its nearly 25 years since I used C in anger, and these days I
can't be arsed to worry about types and the lack of string handling in
C. Let the giant brain do it, is what I say. I just get on and write
code.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: server-side vs.client-side [message #183599 is a reply to message #183584] |
Sat, 02 November 2013 00:24 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Michael Vilain, 2013-11-01 17:53:
> In article <52721771(dot)6090201(at)arnowelzel(dot)de>,
> Arno Welzel <usenet(at)arnowelzel(dot)de> wrote:
>
>> Christoph Michael Becker, 2013-10-30 20:54:
>>
>>> Jerry Stuckle wrote:
>>>
>>>> One question - since both you and Thomas seem to be from Germany, and
>>>> have the same misunderstanding of the word "normally", what does
>>>> "normally" translate to in German? What does it mean?
>>>
>>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>>> usually. Anyway, a misunderstanding of the term "normally" is not the
>>> problem here for me. In my opinion, it is correct to state: "PHP is
>>> normally (usually, most often etc.) used on a server (for server-side
>>> programming)."
>>>
>>> It is as well correct to state: "No programming language is normally
>>> either server-side or client-side." Otherwise it would mean, that there
>>> are programming languages that couldn't be used outside of a
>>> client-server context.
>>
>> Exactly *this* is the wrong assumption, what "normally" means in this
>> context. It does *NOT* mean that a language can *never* be used in other
>> ways - it only says that is the the most common use of it.
>
> I've never seen javascript run on anything but a browser. Unless
> someone's developed a non-browser version, I personally consider it a
> client-side scripting language. It's meant to control a browser and
> nothing else, which is the client for web pages.
JFTR: see Node.js - this is "server side" JavaScript:
<http://nodejs.org/about/>
But generally you're right - the more common use of JavaScript is
"client side" and originally JavaScript has been created just for this
purpose, even though ECMAScript is not limited to this and can virtually
be found anywhere (even as scripting language for Office applications or
for command line tools).
Therefore I would also not call JavaScript a "normally server side
language" - using it on a server is just another option.
> php is not intended to run on the browser. It runs on the server that
> the browser talks to. It can run as part of the web-server or from the
> command line. Same for perl, Java, python, ruby, or C. To me, that
> makes them server-side programming languages.
I even don't know any PHP runtime for browsers.
> I don't know if that matches other's definitions of server-side vs.
> client-side, but that's my definition.
I would define "server side" in the context of PHP as "will usually not
be executed by a user agent". If the "server" is a public web server or
just the box sitting under your desktop does not make a big difference.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: server-side vs.client-side [message #183600 is a reply to message #183594] |
Sat, 02 November 2013 00:26 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Tim Streater, 2013-11-01 22:10:
> In article <l50ppv$qdo$1(at)dont-email(dot)me>, Jerry Stuckle
> <jstucklex(at)attglobal(dot)net> wrote:
>
>> I prefer PHP to bash for complicated CLI projects, for instance.
>
> I prefer PHP to *any* shell for any scripting purpose. Life's
> complicated enough without arcane syntax. Look, if I'd wanted to learn
> TECO, I'd have learnt it, OK?
I prefer bash for shell scripting - the syntax is not far from C or PHP
and you have the big advantage, that you don't need a PHP runtime set up.
And things like "do something with every file named like x in path y" is
really no fun in PHP.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: server-side vs.client-side [message #183601 is a reply to message #183596] |
Sat, 02 November 2013 00:37 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/1/2013 6:25 PM, The Natural Philosopher wrote:
> On 01/11/13 21:10, Tim Streater wrote:
>> In article <l50ppv$qdo$1(at)dont-email(dot)me>, Jerry Stuckle
>> <jstucklex(at)attglobal(dot)net> wrote:
>>
>>> I prefer PHP to bash for complicated CLI projects, for instance.
>>
>> I prefer PHP to *any* shell for any scripting purpose. Life's
>> complicated enough without arcane syntax. Look, if I'd wanted to learn
>> TECO, I'd have learnt it, OK?
>>
> after years if writing C, I simply reach for the compiler if a three
> line shell wont do it..
> If there was the same library support in C and the ability to dump text
> straight, I wouldn't use PHP at all.
>
>
Yeah, when all you've got is a hammer, every problem is a nail.
Intelligent programmers use the most appropriate tool. I do use C and
C++, but not for basic scripts.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: server-side vs.client-side [message #183609 is a reply to message #183584] |
Sat, 02 November 2013 16:46 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Michael Vilain wrote:
> Arno Welzel <usenet(at)arnowelzel(dot)de> wrote:
>> Christoph Michael Becker, 2013-10-30 20:54:
>>> Jerry Stuckle wrote:
>>>> One question - since both you and Thomas seem to be from Germany, and
>>>> have the same misunderstanding of the word "normally", what does
>>>> "normally" translate to in German? What does it mean?
>>>
>>> In Germany it is "normalerweise"/"�blicherweise", what means as much
>>> usually. Anyway, a misunderstanding of the term "normally" is not the
>>> problem here for me. In my opinion, it is correct to state: "PHP is
>>> normally (usually, most often etc.) used on a server (for server-side
>>> programming)."
>>>
>>> It is as well correct to state: "No programming language is normally
>>> either server-side or client-side." Otherwise it would mean, that
>>> there are programming languages that couldn't be used outside of a
>>> client-server context.
>>
>> Exactly *this* is the wrong assumption, what "normally" means in this
>> context. It does *NOT* mean that a language can *never* be used in other
>> ways - it only says that is the the most common use of it.
>
> I've never seen javascript run on anything but a browser.
Which does not mean anything. Not only is that an /argumentum ad
ignorantiam/, a classic fallacy; but also, contrary to common misconception,
there is not even a (single) programming language called “javascript”.
> Unless someone's developed a non-browser version, I personally consider it
> a client-side scripting language.
“javascript” is not even a scripting language, let alone a programming
language. There is no “javascript”.
> It's meant to control a browser and nothing else,
ECMAScript implementations, which you might mistakenly subsume under
“javascript”, are scripting languages. (So is PHP.) “A scripting language
is a programming language that is used to manipulate, customise, and
automate the facilities of an existing system.” (ECMAScript Language
Specification, 5.1 Edition, section 4) Nothing more, nothing less.
While the original purpose for JavaScript (first called Mocha, then
LiveScript) was to provide scripting capabilities in the Netscape browser,
it has surpassed those constraints already in the days of Netscape (see
JavaScript 1.4 on Netscape Enterprise Server and successors). Today (that
is, since 2001 at the latest, 12 years ago), Netscape as a browser vendor
does not exist anymore; there is ECMAScript (first Edition: 1997) and
implementations of it. Implementations like “JavaScript” in Adobe Reader
and Google V8 JavaScript for node.js (an application server), and
“JavaScript” for MongoDb (an object-oriented DBMS).
See also <http://PointedEars.de/es-matrix> pp.
> which is the client for web pages.
There are no “web pages” either. There are HTML/XHTML/XML/SVG/MathML etc.
documents at best. “Web pages” is used by the same wannabes who think the
World Wide Web and the Internet are the same, and say “IP” instead of
“IP(v4) address when in fact “IP” means “Internet _Protocol_”. Blind people
talking about colors.
> php is not intended to run on the browser.
That much is true. The original meaning of PHP by Rasmus Lerdorf in 1994
was *P*ersonal *H*ome *P*age (intended to maintain his); it now means (more
appropriately) *P*HP *H*ypertext *P*reprocessor. However, that does not
preclude the possibility that PHP can run in the browser, client-side, or
that a PHP program does not have anything to do with hypertext at all; it is
just a programming language. But that was not even meant here.
> It runs on the server that the browser talks to.
No, it usually runs on the server that the HTTP client of the browser talks
to, as part of a HTTP server application.
> It can run as part of the web-server or from the command line.
If a program runs from the command line, it does not matter whether the
computer system it runs on is called a “server” for it could be, and
reasonably be called, a “client” at the same time. Therefore, the logic
leading to a programming language in which such a program is written being
called a “server-side (programming) language” is fundamentally flawed.
> Same for perl, Java, python, ruby, or C.
Yes, AISB the same logic is fundamentally flawed with regard to (all?) other
programming languages (certainly the ones mentioned here). There are Perl
scripts that have nothing to do with HTTP, and there are Perl-based
applications like Bugzilla that have. There are client-side Java-based
applications like Eclipse, SweetHome3D, and TV-Browser, and there are
server-side JavaServer Pages (JSP) based on Java which run on, for example,
Apache Tomcat. There are Python client programs like ketchup(1) and
youtube-dl(1), and there are Python-based application servers like Zope, and
Web-based CMSs running on it like Plone. There are C programs that have
never seen a httpd or a network in general, controlling filesystems or local
storage devices, and there is, for example the collection of C programs
named Apache that make up a Web server.
> To me, that makes them server-side programming languages.
Which shows that, due to lack of basic knowledge and experience, you have
not understood the problem. Hopefully it is clearer to you now.
> I don't know if that matches other's definitions of server-side vs.
> client-side, but that's my definition.
Laymen like you can make up any definition they want; that does not mean
that it makes sense, applies in general, or is generally accepted by
professionals (like me).
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
| Re: server-side vs.client-side [message #183610 is a reply to message #183563] |
Sat, 02 November 2013 16:57 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Arno Welzel wrote:
>> Christoph Michael Becker, 2013-10-30 20:54:
>>> Jerry Stuckle wrote:
>>>> One question - since both you and Thomas seem to be from Germany, and
>>>> have the same misunderstanding of the word "normally", what does
>>>> "normally" translate to in German? What does it mean?
>>>
>>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>>> usually. Anyway, a misunderstanding of the term "normally" is not the
>>> problem here for me. In my opinion, it is correct to state: "PHP is
>>> normally (usually, most often etc.) used on a server (for server-side
>>> programming)."
>>>
>>> It is as well correct to state: "No programming language is normally
>>> either server-side or client-side." Otherwise it would mean, that there
>>> are programming languages that couldn't be used outside of a
>>> client-server context.
>>
>> Exactly *this* is the wrong assumption, what "normally" means in this
>> context. It does *NOT* mean that a language can *never* be used in other
>> ways - it only says that is the the most common use of it.
>
> I thought there is the same difference between
>
> "No programming language is normally either server-side or
> client-side."
>
> and
>
> "No programming language is either normally server-side
> or normally client-side."
>
> as it is in German. Apparently, I was mistaken.
You are not. “normally” is (used here as) a “weasel word”, and the argument
is fundamentally flawed. What is “normally” – who defines what that is (not
what it means)? At which percentage does “normally” start? You can see
that this cannot lead to a sound argument. Which is why I intentionally
double-quoted the word.
JFTR: Mr. Welzel, too, is a native speaker of *German* only. For more
professional (and native-speakers-of-English's) interpretation and
translation, for example go to
< http://dict.leo.org/ende/?lp=ende&lang=de&searchLoc=0&cmpType=r elaxed§Hdr=on&spellToler=&search=normally>
In particular, you might find this interesting:
< http://dict.leo.org/forum/viewGeneraldiscussion.php?idThread=1139295&id Forum=4&lang=de&lp=ende>
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
| Re: server-side vs.client-side [message #183612 is a reply to message #183610] |
Sat, 02 November 2013 18:36 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn, 2013-11-02 17:57:
> Christoph Michael Becker wrote:
>
>> Arno Welzel wrote:
>>> Christoph Michael Becker, 2013-10-30 20:54:
>>>> Jerry Stuckle wrote:
>>>> > One question - since both you and Thomas seem to be from Germany, and
>>>> > have the same misunderstanding of the word "normally", what does
>>>> > "normally" translate to in German? What does it mean?
>>>>
>>>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>>>> usually. Anyway, a misunderstanding of the term "normally" is not the
>>>> problem here for me. In my opinion, it is correct to state: "PHP is
>>>> normally (usually, most often etc.) used on a server (for server-side
>>>> programming)."
>>>>
>>>> It is as well correct to state: "No programming language is normally
>>>> either server-side or client-side." Otherwise it would mean, that there
>>>> are programming languages that couldn't be used outside of a
>>>> client-server context.
>>>
>>> Exactly *this* is the wrong assumption, what "normally" means in this
>>> context. It does *NOT* mean that a language can *never* be used in other
>>> ways - it only says that is the the most common use of it.
>>
>> I thought there is the same difference between
>>
>> "No programming language is normally either server-side or
>> client-side."
>>
>> and
>>
>> "No programming language is either normally server-side
>> or normally client-side."
>>
>> as it is in German. Apparently, I was mistaken.
>
> You are not. “normally” is (used here as) a “weasel word”, and the argument
> is fundamentally flawed. What is “normally” – who defines what that is (not
> what it means)? At which percentage does “normally” start? You can see
> that this cannot lead to a sound argument. Which is why I intentionally
> double-quoted the word.
>
> JFTR: Mr. Welzel, too, is a native speaker of *German* only. For more
JFTR: As you are ;-)
I think your problem is, that you (mis-)understand "normally" in this
context as "no other use makes sense" or "no other use is possible" -
which of course is not true.
We all know that PHP can be used in different ways and not just "server
side". But when saying "PHP is normally used server side" this does not
say anything at all about where PHP *can* be used, just what it is
*meant* to be used for and what its strengths are. Just think a moment
about the history of PHP - it all started as a set of tools to create
HTML documents on the server:
<http://www.php.net/manual/en/history.php.php>
"[...] the very first incarnation of PHP was a simple set of Common
Gateway Interface (CGI) binaries written in the C programming language."
> professional (and native-speakers-of-English's) interpretation and
> translation, for example go to
>
> < http://dict.leo.org/ende/?lp=ende&lang=de&searchLoc=0&cmpType=r elaxed§Hdr=on&spellToler=&search=normally>
You call this a "professional interpretation and translation"?
Anyway - I would also suggest
<http://www.oxforddictionaries.com/definition/english/normally?q=normally>.
> In particular, you might find this interesting:
>
> < http://dict.leo.org/forum/viewGeneraldiscussion.php?idThread=1139295&id Forum=4&lang=de&lp=ende>
Some thoughts by other people - yes, interesting - but a "professional
interpretation"?
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: server-side vs.client-side [message #183613 is a reply to message #183612] |
Sat, 02 November 2013 18:44 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 02/11/13 18:36, Arno Welzel wrote:
> I think your problem is, that you (mis-)understand "normally" in this
> context as "no other use makes sense" or "no other use is possible" -
> which of course is not true.
Yes, being instructed in colloquial English by German is...either
unusual, or typical, depending on your prejudices..
Normal means most commonly that's all. i.e. where you might expect.
There is no implication of the exclusion of other possibilities.
Its normal to see squirrels in trees, or on the ground, less so to see
them in freezers or pies..
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
| Re: server-side vs.client-side [message #183614 is a reply to message #183610] |
Sat, 02 November 2013 19:01 |
Doug Miller
Messages: 171
Registered: August 2011
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> wrote in
news:1543268(dot)nVc8Rr6bpH(at)PointedEars(dot)de:
> You are not. “normally” is (used here as) a “weasel word”, and the argument
> is fundamentally flawed. What is “normally” – who defines what that is (not
> what it means)? At which percentage does “normally” start? You can see
> that this cannot lead to a sound argument. Which is why I intentionally
> double-quoted the word.
And this is why I keep saying you don't understand English nearly as well as you think you
do; this is the charitable assumption, the alternative being that you're just an asshole.
"Normally" means "usually", "typically", "commonly" -- native speakers of English
understand it to mean "the majority of the time". That one cannot assign an exact, specific
percentage at which "sometimes" changes to "normally" does not render the concept of
"normally" meaningless, your delusions to the contrary notwithstanding.
The *fact* is that PHP is *normally* (usually, typically, commonly) a language which is
executed server-side -- and this fact is not altered by your inability to grasp it, whether that
inability stems from the deficiencies in your grasp of the English language, or your innate
insufferable pendantry.
|
|
|
|
| Re: server-side vs.client-side [message #183615 is a reply to message #183609] |
Sat, 02 November 2013 19:41 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
> Michael Vilain wrote:
>> I've never seen javascript run on anything but a browser.
>
> Which does not mean anything. Not only is that an /argumentum ad
> ignorantiam/, a classic fallacy; but also, contrary to common misconception,
> there is not even a (single) programming language called “javascript”.
>
Several Fallacies here:
First, this is not "argumentum ad ignorantiam" because that fallacy is
the fallacy of assuming something is true because it has not been proven
false. You might be able to claim a fallicy of lack of evidence does not
imply evidence of the lack, but the problem with citing that is the
claim isn't that NO use of "javascipt" is not client-side, but that the
"norm" for "javascript" is client-side, which means that any possible
server-side use, if it exist, needs to be uncommon, which IS supported
(but maybe not proved) by a lack of observation. Refutation of this
observation could be done by showing a existing usage *of common enough
usage* to negate the "normally" tag.
There is a language called "javascript", even your beloved ECMAScipt.org
site admits this, stating in at least one location:
"ECMAScript" is the name under which the language more commonly known as
"JavaScript" is standardized.
Which admits to the existence of language with the name of "javascript",
it just isn't the name of the language that the standard applies to.
Your instance that "There is no javascript" is a denial of reality.
The rest of your rant is similarly filled with the flaw that something
must be wrong because it doesn't match YOUR particular unusual
definition (or lack there of) even if it matches the commonly use meaning.
|
|
|
|
| Re: server-side vs.client-side [message #183617 is a reply to message #183615] |
Sat, 02 November 2013 21:37 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <pAcdu.115847$sp1(dot)45670(at)en-nntp-15(dot)dc1(dot)easynews(dot)com>,
Richard Damon <Richard(at)Damon-Family(dot)org> wrote:
> Your instance that "There is no javascript" is a denial of reality.
Richard,
What PointyHead is complaining about is the capitalisation (or lack of
it). For some reason he thinks it's important (nay, crucial) that we
all say (or rather, write) "JavaScript".
The net result is unprofessional behaviour on his part: to wit, being
rude to everyone who doesn't follow his norms.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: server-side vs.client-side [message #183620 is a reply to message #183612] |
Sun, 03 November 2013 00:28 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sat, 02 Nov 2013 19:36:07 +0100, Arno Welzel wrote:
> We all know that PHP can be used in different ways and not just "server
> side". But when saying "PHP is normally used server side" this does not
> say anything at all about where PHP *can* be used, just what it is
> *meant* to be used for and what its strengths are. Just think a moment
> about the history of PHP - it all started as a set of tools to create
> HTML documents on the server:
s/*meant* to be/(usually|commonly|normally)/
I don't think php is meant to be used for anything, per se, as in there's
no god given order that "thou shalt use php to do x".
But php was originally designed as a scripting language to sit behind a
web server and dynamically create html content. It has since morphed into
many other things, and it has many other uses, but I imagine that the
majority of php code that is executed on a daily basis is sitting behind
a web server generating (x)html pages and / or other content intended to
be accessed by means of a web browser and / or otherwise processing http
requests.
Let's assume that globally, on all computers that have some form of php
interpreter, a total of 3.5 * 10^13 php code statements are executed.
This is a manufactured figure, a guesstimate, if you have a better figure
for the number of php statements executed daily on a global basis, I'd
love to hear it, and how you arrived at it.[1]
Now, what proportion of that php code do you think is involved in
responding in some way to an http request, and what proportion of that php
code do you think is not involved in responding in some way to an http
request? Because I would guess that upwards of 90% of those 3.5 * 10^13
lines of php is involved in responding to an http request, and I would
happily state that I would consider that if over 90% of the php that
executes globally on a daily basis is executing in response to http
requests, then php is normally executed in a server environment in
response to an http request.
[1] That's the equivalent of 3.5 billion people (50% of the global
population) making 100 requests each, and each request causing 100 php
code statements to be executed.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: server-side vs.client-side [message #183621 is a reply to message #183610] |
Sun, 03 November 2013 01:40 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/2/2013 12:57 PM, Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Arno Welzel wrote:
>>> Christoph Michael Becker, 2013-10-30 20:54:
>>>> Jerry Stuckle wrote:
>>>> > One question - since both you and Thomas seem to be from Germany, and
>>>> > have the same misunderstanding of the word "normally", what does
>>>> > "normally" translate to in German? What does it mean?
>>>>
>>>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>>>> usually. Anyway, a misunderstanding of the term "normally" is not the
>>>> problem here for me. In my opinion, it is correct to state: "PHP is
>>>> normally (usually, most often etc.) used on a server (for server-side
>>>> programming)."
>>>>
>>>> It is as well correct to state: "No programming language is normally
>>>> either server-side or client-side." Otherwise it would mean, that there
>>>> are programming languages that couldn't be used outside of a
>>>> client-server context.
>>>
>>> Exactly *this* is the wrong assumption, what "normally" means in this
>>> context. It does *NOT* mean that a language can *never* be used in other
>>> ways - it only says that is the the most common use of it.
>>
>> I thought there is the same difference between
>>
>> "No programming language is normally either server-side or
>> client-side."
>>
>> and
>>
>> "No programming language is either normally server-side
>> or normally client-side."
>>
>> as it is in German. Apparently, I was mistaken.
>
> You are not. “normally” is (used here as) a “weasel word”, and the argument
> is fundamentally flawe d. What is “normally” – who defines what that is (not
> what it means)? At which percentage does “normally” start? You can see
> that this cannot lead to a sound argument. Which is why I intentionally
> double-quoted the word.
>
There's only one weasel here - and it is NOT "normally".
>
> PointedEars
>
You really shouldn't criticize a language you don't understand, Pointed
Head.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: server-side vs.client-side [message #183625 is a reply to message #183615] |
Sun, 03 November 2013 09:48 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Richard Damon, 2013-11-02 20:41:
> On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
>> Michael Vilain wrote:
>>> I've never seen javascript run on anything but a browser.
>>
>> Which does not mean anything. Not only is that an /argumentum ad
>> ignorantiam/, a classic fallacy; but also, contrary to common misconception,
>> there is not even a (single) programming language called “javascript”.
>>
[...]
> There is a language called "javascript", even your beloved ECMAScipt.org
> site admits this, stating in at least one location:
>
> "ECMAScript" is the name under which the language more commonly known as
> "JavaScript" is standardized.
You may not know PointedEars good enough yet - it was about the proper
spelling of "JavaScript" instead of "javascript" ;-)
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: server-side vs.client-side [message #183626 is a reply to message #183625] |
Sun, 03 November 2013 10:28 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <52761BF2(dot)2020202(at)arnowelzel(dot)de>, Arno Welzel
<usenet(at)arnowelzel(dot)de> wrote:
> Richard Damon, 2013-11-02 20:41:
>
>> On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
>>> Michael Vilain wrote:
>>>> I've never seen javascript run on anything but a browser.
>>>
>>> Which does not mean anything. Not only is that an /argumentum ad
>>> ignorantiam/, a classic fallacy; but also, contrary to common
>>> misconception,
>>> there is not even a (single) programming language called “javascript”.
>>>
> [...]
>> There is a language called "javascript", even your beloved ECMAScipt.org
>> site admits this, stating in at least one location:
>>
>> "ECMAScript" is the name under which the language more commonly known as
>> "JavaScript" is standardized.
>
> You may not know PointedEars good enough yet - it was about the proper
> spelling of "JavaScript" instead of "javascript" ;-)
There is no difference in spelling between "JavaScript" and
"javascript". It's a difference in capitalisation, something which is
not so important in English, as, AIUI, in German.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: server-side vs.client-side [message #183629 is a reply to message #183615] |
Sun, 03 November 2013 13:16 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Richard Damon wrote:
> On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
>> Michael Vilain wrote:
>>> I've never seen javascript run on anything but a browser.
>>
>> Which does not mean anything. Not only is that an /argumentum ad
>> ignorantiam/, a classic fallacy; but also, contrary to common
>> misconception, there is not even a (single) programming language called
>> “javascript”.
>
> Several Fallacies here:
>
> First, this is not "argumentum ad ignorantiam" because that fallacy is
> the fallacy of assuming something is true because it has not been proven
> false.
It is an /argumentum ad ignorantiam/ *exactly* because of that. The premise
set here implicitly is that “javascript” could only run in a browser, and
the argument made to prove that is that anything else has not been observed
by the person setting the premise; therefore the premise is assumed to be
true. And *that* is a fallacy.
> You might be able to claim a fallicy of lack of evidence does not
> imply evidence of the lack, but the problem with citing that is the
> claim isn't that NO use of "javascipt" is not client-side, but that the
> "norm" for "javascript" is client-side, which means that any possible
> server-side use, if it exist, needs to be uncommon, which IS supported
> (but maybe not proved) by a lack of observation. Refutation of this
> observation could be done by showing a existing usage *of common enough
> usage* to negate the "normally" tag.
Your logic is flawed.
> There is a language called "javascript",
There is not.
> even your beloved ECMAScipt.org site admits this, stating in at least one
> location:
>
> "ECMAScript" is the name under which the language more commonly known as
> "JavaScript" is standardized.
First, note the different spelling. Second, that is still an explanation
for laymen. The only normative work, the ECMAScript Language Specification,
5.1 Edition (and previous Editions), clearly say(s):
| This Ecma Standard is based on several originating technologies, the most
| well known being JavaScript (Netscape) and JScript (Microsoft).
> Which admits to the existence of language with the name of "javascript",
No, it does not. It admits the existence of one programming language named
“JavaScript” (of many others); an existence which was _not_ debated (on the
contrary; if you read the ECMAScript Support Matrix carefully, you can find
confirmation of its existence, past and present, numerous times).
> it just isn't the name of the language that the standard applies to.
Utter nonsense.
> Your instance that "There is no javascript" is a denial of reality.
No, your and other's use of ”javascript” is. From the standard *follows*
that there is no single programming language to implement it, and certainly
no language with that name. The ES Matrix also shows that there have not
been and there is not one programming language, but several ones, with
different names, and have been since shortly after the beginning.
I have been dealing with ECMAScript-based programming languages since about
16 years now; they are the basis of my scientific work in computer science.
Therefore, I strongly suggest you get yourself a lot more informed on the
subject before you start discussing it with me. It would also be preferable
if you discussed it where it is on-topic (comp.lang.javascript), otherwise I
will have to adjust my scorefile.
> The rest of your rant is similarly filled with the flaw that something
> must be wrong because it doesn't match YOUR particular unusual
> definition (or lack there of) even if it matches the commonly use meaning.
It is not merely *my* definition. Perhaps what distinguishes the
professional from the layman the most is that the professional knows that
and understands why definitions cannot be arbitrarily made up if they are to
make sense: they must fit into an existing framework of definitions, they
must be ontological plausible.
To say that a programming language ”is server-side” or “is client-side”
assigns to it an *exclusive* property by predicate. It means that this
programming language could *only* be used either client-side or *only*
server-side.
And nothing could be farther from the truth. It is the very property of
programming languages to be usable in whatever architecture (to be “general-
purpose” in that regard) that makes them so powerful. One must keep in mind
that a programming language is a human-readable abstraction of operations
that tell a machine what to do in order to achieve a human-set goal. It is
only *later* that the human ascribes to a machine or program the property of
being a “client” or a “server” *or* *both*, and he can do that *only* in the
client-server architecture.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
|
|
|
|
| Re: cr [message #183630 is a reply to message #183567] |
Sun, 03 November 2013 14:29 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Richard Damon wrote:
> On 10/29/13, 7:18 AM, Thomas 'PointedEars' Lahn wrote:
>> Richard Damon wrote:
>>> On 10/28/13, 9:34 AM, Thomas 'PointedEars' Lahn wrote:
>>>> Richard Damon wrote:
>>>> > On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>>>> >> Richard Damon wrote:
>>>> >>> […] The one thing that is fairly certain is that the
>>>> >>> player will almost certainly NOT be written in PHP,
>>>> >>
>>>> >> That much is true.
>>>> >>
>>>> >>> as PHP is normally a server side language, and few clients will
>>>> >>> understand it.
>>>> >>
>>>> >> A common misconception. *No* programming language is “normally”
>>>> >> either “server-side” or “client-side”.
>>>> >
>>>> > Clearly a falsehood.
>>>>
>>>> [superseded]
>>>>
>>>> > I would expect that at least 95% of PHP executions
>>>> > are done via mod-php or php-cgi in response to a http request, [tl;dr]
>>>>
>>>> So even by your standards there are 5% left for “client-side”
>>>> applications.
>>>
>>> I consider 95% to be a reasonable definition for "normally". I will add
>>> that I normally ignore what you say because normally you are just
>>> spouting gibberish (as it seems here).
>>
>> Why do you reply to the canceled posting?
>>
> I suppose this shows your level of understanding of Usenet and the
> applicability of RFCs.
It rather shows that you are trolling since you are at least vaguely aware
how Cancel messages work, and what they mean, and not only reply regardless
but also deny their significance.
> Cancel messages are purely advisory,
Cancel messages are control messages. A news server may ignore them at own
risk. That does not make them “purely advisory”.
<http://tools.ietf.org/html/rfc5536#section-3.2.3> pp.
> and routinely ignored by the backbone
There is no “backbone”; Usenet is explicitly decentralized. Each news
server administrator can set their own rules regarding to which messages to
accept from which peers, which to keep, and which to distribute to which
peers.
> because they are not authenticated.
Some news servers now require Cancel messages to be authenticated before
executed, that is, to match the lock-signature of the posting to be
canceled; others (like the one I am using since about 10 years) do not.
> It has been decades since one could expect a cancel to work.
Utter nonsense. That a Cancel message works was the general idea. It was
only after some people abused this feature that some servers decided to
ignore cancels or require authentication.
The Internet draft for lock-signing messages, and cancel messages to match
that signature, is a lot younger than that. And it has expired even though
it is implemented.
<http://wiki.killfile.org/projects/usenet/faqs/cancel/>
<https://en.wikipedia.org/wiki/Control_message>
<http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01>
<http://individual.net/faq.php#1.12>
So much for *your* “understanding of Usenet and the applicability of RFCs”.
It is also exemplified by the way you changed the Subject header field
value.
> Note, that your superseded message was injected to your server on
> USENET, it appears, just 2 minutes before I replied. […]
,----
| […]
| Message-ID: <1434655(dot)Yjjdx3QzlV(at)PointedEars(dot)de>
| From: Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de>
| […]
| Date: Mon, 28 Oct 2013 14:34:58 +0100
| […]
| References: <1ia1p6efkuy6j(dot)ew455c20yr22$(dot)dlg(at)40tude(dot)net>
<l4jjv1$16b$2(at)dont-email(dot)me> <a4mqn9voa0zs$(dot)2gqi5acsdw6l$(dot)dlg(at)40tude(dot)net>
<P9dbu.14655$9X3(dot)6324(at)en-nntp-03(dot)dc1(dot)easynews(dot)com>
<4129338(dot)JVDsMHeclA(at)PointedEars(dot)de> <Yvsbu.14426$Lj7.6142@en-
nntp-01.dc1.easynews.com>
| […]
`----
That was 2013-10-28 13:34:58 UTC.
,----
| Message-ID: <9415386(dot)0xDGcqzFey(at)PointedEars(dot)de>
| From: Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de>
| […]
| Date: Mon, 28 Oct 2013 14:37:03 +0100
| […]
| Supersedes: <1434655(dot)Yjjdx3QzlV(at)PointedEars(dot)de>
`----
That was 2013-10-28 13:37:03 UTC (about 2 minutes later). To be sure (not
all servers support “Supersedes” either), I sent the corresponding Cancel
message only seconds later.
,----
| […]
| From: Richard Damon <Richard(at)Damon-Family(dot)org>
| […]
| References: <1ia1p6efkuy6j(dot)ew455c20yr22$(dot)dlg(at)40tude(dot)net>
<l4jjv1$16b$2(at)dont-email(dot)me> <a4mqn9voa0zs$(dot)2gqi5acsdw6l$(dot)dlg(at)40tude(dot)net>
<P9dbu.14655$9X3(dot)6324(at)en-nntp-03(dot)dc1(dot)easynews(dot)com>
<4129338(dot)JVDsMHeclA(at)PointedEars(dot)de> <Yvsbu.14426$Lj7.6142@en-
nntp-01.dc1.easynews.com> <1434655(dot)Yjjdx3QzlV(at)PointedEars(dot)de>
| In-Reply-To: <1434655(dot)Yjjdx3QzlV(at)PointedEars(dot)de>
| […]
| Message-ID: <wcEbu.10265$UA3(dot)1277(at)en-nntp-08(dot)dc1(dot)easynews(dot)com>
| […]
| Date: Mon, 28 Oct 2013 21:29:53 -0400
| […]
`----
That was 2013-10-29 01:29:53 UTC, more than 10 hours later. I would pity
you for your slow 20th century newsfeed if it were so.
I will now leave you to your further “misconceptions”, lest you do not waste
more of my precious time. May you die in ignorance. *PLONK*
F'up2 poster
|
|
|
|
| Re: cr [message #183631 is a reply to message #183630] |
Sun, 03 November 2013 14:34 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/3/2013 9:29 AM, Thomas 'PointedEars' Lahn wrote:
.... an even bigger bunch of bull manure than normal. Then he changes
the FUP so no one can call him on his crap publicly.
Pointed Head, you have once again made a huge fool of yourself. And
you've only limited your chance of gaining any accurate information by
plonking someone who was 100% correct in his statements.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: cr [message #183633 is a reply to message #183630] |
Sun, 03 November 2013 20:18 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
On 11/3/13, 9:29 AM, Thomas 'PointedEars' Lahn wrote:
> Richard Damon wrote:
> It rather shows that you are trolling since you are at least vaguely aware
> how Cancel messages work, and what they mean, and not only reply regardless
> but also deny their significance.
>
>> Cancel messages are purely advisory,
>
> Cancel messages are control messages. A news server may ignore them at own
> risk. That does not make them “purely advisory”.
>
> <http://tools.ietf.org/html/rfc5536#section-3.2.3> pp.
Note that RFC5537 which defines the cancel message, describes it as a
request, and that serving agents may elect to honor them or not. It is
NOT "ignore at your own risk"
>
>> and routinely ignored by the backbone
>
> There is no “backbone”; Usenet is explicitly decentralized. Each news
> server administrator can set their own rules regarding to which messages to
> accept from which peers, which to keep, and which to distribute to which
> peers.
>
Having a backbone and being decentralized are NOT contradictory states.
There is a backbone of "Tier 1" servers that handle most of the "long
haul" connections. These then peer with Tier 2 servers, and down the
line. Better lower tier servers will connect with multiple upstream
peers for redundancy.
>> because they are not authenticated.
>
> Some news servers now require Cancel messages to be authenticated before
> executed, that is, to match the lock-signature of the posting to be
> canceled; others (like the one I am using since about 10 years) do not.
>
>> It has been decades since one could expect a cancel to work.
>
> Utter nonsense. That a Cancel message works was the general idea. It was
> only after some people abused this feature that some servers decided to
> ignore cancels or require authentication.
>
And this abuse happened decades ago, my experience is that cancels did
not work in the mid 90's (which is about 2 decades ago). My experience
is that MOST servers ignore cancels, as they have for decades.
> The Internet draft for lock-signing messages, and cancel messages to match
> that signature, is a lot younger than that. And it has expired even though
> it is implemented.
>
> <http://wiki.killfile.org/projects/usenet/faqs/cancel/>
> <https://en.wikipedia.org/wiki/Control_message>
> <http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01>
> <http://individual.net/faq.php#1.12>
>
An expired draft RFC does not establish rules to run the internet. The
fact that it IS an expired draft indicates that there were likely
problems in implementing it. There may be a few servers which implement
this, but that hardly makes it something to be counted on. Plus, since
your message didn't have the needed headers to begin with, this is
irrevelent.
> So much for *your* “understanding of Usenet and the applicability of RFCs”.
> It is also exemplified by the way you changed the Subject header field
> value.
That was purely accidental. A feline felt they were being ignore and
pushed some keys, as I was getting ready to send.
> F'up2 poster
Follow up ignored.
>
|
|
|
|
|
|
| Re: server-side vs.client-side [message #183635 is a reply to message #183634] |
Mon, 04 November 2013 06:19 |
Chuck Anderson
Messages: 63
Registered: September 2010
Karma: 0
|
Member |
|
|
Chuck Anderson wrote:
> Tim Streater wrote:
>> In article <2819769(dot)4COP93GsJZ(at)PointedEars(dot)de>, Thomas 'PointedEars'
>> Lahn <PointedEars(at)web(dot)de> wrote:
>>
>>>> "ECMAScript" is the name under which the language more commonly
>>> known as
>>>> "JavaScript" is standardized.
>>>
>>> First, note the different spelling.
>>
>> It is *not* a different spelling.
>>
>
> According to convention, shouldn't that be single-humped, javaScript?
>
> And what the hell does this have to do with Php?
>
I should add, Tim, that the second comment is not directed at you. I
just jumped in using your succinct post.
--
*****************************
Chuck Anderson • Boulder, CO
http://cycletourist.com
Turn Off, Tune Out, Drop In
*****************************
|
|
|
|
| Re: server-side vs.client-side [message #183637 is a reply to message #183635] |
Mon, 04 November 2013 18:02 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <l57eb8$i43$1(at)dont-email(dot)me>, Chuck Anderson
<cycletourist(at)invalid(dot)invalid> wrote:
> Chuck Anderson wrote:
>> Tim Streater wrote:
>>> In article <2819769(dot)4COP93GsJZ(at)PointedEars(dot)de>, Thomas 'PointedEars'
>>> Lahn <PointedEars(at)web(dot)de> wrote:
>>>
>>>> > "ECMAScript" is the name under which the language more commonly
>>>> known as
>>>> > "JavaScript" is standardized.
>>>>
>>>> First, note the different spelling.
>>>
>>> It is *not* a different spelling.
>> According to convention, shouldn't that be single-humped, javaScript?
>>
>> And what the hell does this have to do with Php?
> I should add, Tim, that the second comment is not directed at you. I
> just jumped in using your succinct post.
Well that's how I took it :-)
And, woss more, you are quite right, this has nothing to do with PHP.
Not sure how we got here, although with PointyHead involved, anything's
possible.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: server-side vs.client-side [message #183639 is a reply to message #183626] |
Tue, 05 November 2013 10:15 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Am 03.11.2013 11:28, schrieb Tim Streater:
> In article <52761BF2(dot)2020202(at)arnowelzel(dot)de>, Arno Welzel
> <usenet(at)arnowelzel(dot)de> wrote:
>
>> Richard Damon, 2013-11-02 20:41:
>>
>>> On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Michael Vilain wrote:
>>>> > I've never seen javascript run on anything but a browser.
>>>>
>>>> Which does not mean anything. Not only is that an /argumentum ad
>>>> ignorantiam/, a classic fallacy; but also, contrary to common
>>>> misconception,
>>>> there is not even a (single) programming language called “javascript”.
>>>>
>> [...]
>>> There is a language called "javascript", even your beloved ECMAScipt.org
>>> site admits this, stating in at least one location:
>>>
>>> "ECMAScript" is the name under which the language more commonly known as
>>> "JavaScript" is standardized.
>>
>> You may not know PointedEars good enough yet - it was about the proper
>> spelling of "JavaScript" instead of "javascript" ;-)
>
> There is no difference in spelling between "JavaScript" and
> "javascript". It's a difference in capitalisation, something which is
> not so important in English, as, AIUI, in German.
Well - there is a difference: JavaScript is the official name but
"javascript" not. Of course anybody would clearly understand
"javascript" as well but PointedEars insists teaching people the proper
use of names and precise logic as he seems to be a big fan of Vulcan
philosophy and logic.
Cite from <http://pointedears.de/scripts/test/es-matrix/>:
"Learn to think clearly. Learn to distinguish: what is, and what seems
to be."
-- Surak
BTW: "Surak" is a fictional Vulcan philosopher in Star Trek.
I would prefer Kant and his intepretation of "sapere aude" - but maybe
this is not fancy enough for some people ;-)
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: server-side vs.client-side [message #183641 is a reply to message #183639] |
Tue, 05 November 2013 12:47 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <5278C545(dot)1070401(at)arnowelzel(dot)de>, Arno Welzel
<usenet(at)arnowelzel(dot)de> wrote:
> Am 03.11.2013 11:28, schrieb Tim Streater:
>> There is no difference in spelling between "JavaScript" and
>> "javascript". It's a difference in capitalisation, something which is
>> not so important in English, as, AIUI, in German.
>
> Well - there is a difference: JavaScript is the official name but
> "javascript" not. Of course anybody would clearly understand
> "javascript" as well but PointedEars insists teaching people the proper
> use of names and precise logic as he seems to be a big fan of Vulcan
> philosophy and logic.
>
> Cite from <http://pointedears.de/scripts/test/es-matrix/>:
>
> "Learn to think clearly. Learn to distinguish: what is, and what seems
> to be."
> -- Surak
Perhaps PointyHead needs a spell on the Punishment Planet. My PP, BTW,
has a still largely molten surface.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]