Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <3233178.01j8BcMW7d@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sun, 02 Dec 2012 21:22:18 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 7Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <2051112.NKQCjSVfUK@PointedEars.de> <8sanb8dav46vpofli4p0inreu8g94gkhem@4ax.com> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 178 NNTP-Posting-Date: 02 Dec 2012 21:22:19 CET NNTP-Posting-Host: 34b8bb6b.newsspool1.arcor-online.net X-Trace: DXC=@;XfI\KCbbeEB;5>eE0T7mic==]BZ:afn4Fo<]lROoRankgeX?EC@@`g^WmZX^PGjcDZm8W4\YJNlR=i2=[N6Y6j8IBF642AOba6h7]UAPH2Fd X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:17420 Wally W. wrote: ^^^^^^^^ Please fix that. > On Sun, 02 Dec 2012 19:06:27 +0100, Thomas 'PointedEars' Lahn wrote: >> Wally W. wrote: >>> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote: >>>> On 02-12-2012 05:22, Jon wrote: >>>>> Where can I find an editor/..../.... for Javascript? >>>> >>>> Notepad.exe, or any other text-editor.... >>>> >>>>> Where can I find an ..../compiler/.... for Javascript? >>>> >>>> There is no compiler for Javascript, >>> >>> That is an oversight in the IT world. >> >> Strictly speaking, what was stated is correct, > > As was my statement. Most certainly not. >> because there is no "Javascript" language to begin with: >> > > Your link highlights in incompatibilities between script engines. I am comparing the language features supported by different ECMAScript implementations there. > A script I develop for my own use in my preferred browser may be > useless in someone else's preferred browser. Correct. This is why it is important to know where implementations differ and where not, so that appropriate measures can be taken by the Web developer. I am currently focusing on ECMAScript implementations; DOM implementations are another matter altogether (and I will probably investigate them more thoroughly later). > With web pages and javascript so prevalent, There are no "web pages" and there is no "javascript". As soon as you can accept that, and stop talking like you want to sell something, understanding can begin. > it is an oversight that there is no generally available program to > "compile" the pages with *some* version of javascript Different ECMAScript implementations are not versions of one imagined universally implemented and uniform "javascript" language; they are separate programming languages in their own right (with a common root, most of which is standardized in ECMAScript). > to a browser-independent EXE file. You have overlooked the existence of such programs. However, such a program would not be overly useful with regard to browsers, because ECMAScript implementations are scripting languages, which "[are] programming language[s] that [are] used to manipulate, customise, and automate the facilities of an existing system." (ECMAScript Language Specification, 5.1 Edition, p. 2). As such, they are primarily interfacing languages, and APIs differ among browsers. You cannot avoid that; browser vendors will not let you. And if you are honest, you would not want to: this competition is *basically* a Good Thing. >> Loosely speaking it is wrong, though, because ECMAScript source code in >> Web browsers and elsewhere is JIT-compiled and _not_ interpreted >> verbatim. >> Most of the script engines of ECMAScript implementations compile source >> code to bytecode, executed by a Virtual Machine (this applies to >> Netscape/Mozilla JavaScript and Microsoft JScript). Google V8 even JIT- >> compiles source code to native machine code, which part of why it is so >> fast by comparison. > > Which is of no help to one who wants to convert their web page, > complete with javascript, to a browser-independent EXE file. Those people should learn to know what they are doing before they are doing it, and then might be interested in pp. But that has nothing to do with "web pages" (read: HTML documents) as such. >>> Spreadsheets are also "interpreted." >> Spreadsheets are not a programming language. > > Missing the point for the semantics. I am not sure yet, are you trolling or are you just completely clueless? > Functions in spreadsheet cells are, in a practical sense which may not > meet a purist's definition, "interpreted." Yes, but that is a different thing. Functions in spreadsheet cells are a part of an API, which is used with programming languages. > Javascript operating on forms in a web page can behave similarly to > simple, or not-so-simple, spreadsheets. While that is partially true, you still have no clue what you are talking about. There are programming languages, and there are APIs that can be used with programming languages. That is no different with ECMAScript implementations and the DOM API. >>> That didn't stop someone from >>> writing a compiler: >>> http://en.wikipedia.org/wiki/As_Easy_As >> >> ISTM you are confusing things. >> >>> How many would like a compliable web page that has: >>> 1. Embedded javascript >> >> Meaning what exactly? > > For example, this web page could be converted to a stand-alone EXE > file with all the functionality of its scripting fully implemented: > http://www.pmel.org/unitconv.htm No, it could not. The functionality of "the scripting" to be cross-browser would be lost to begin with. >>> 2. A 'save as" capability to write all contents, including entered >>> values, to a disk file? >> That capability exists already. > > Where? In all script-capable Web browsers. >>> 3. An "open file" capability to resume work on or print values in a >>> file placed on disk with the "save as" feature mentioned above? >> That too. > > Where? Same. >>> I know I would like such a compiler. >> I do not think you know what a compiler is or where you are posting to, >> though. > > I suppose the software to produce CHM ("compiled HTML") files would > not meet your definition of "compiler." That is correct. Those files need an executable (HTMLHelp.exe & friends) to be displayed, which in turn uses a runtime library, MSHTML.dll. In short, the browser core. That library supports JScript, Microsoft's ECMAScript implementation (through JScript*.dll), and so does Internet Explorer, for example, because it is based on MSHTML.dll (which is why I am talking about JScript and the MSHTML DOM and not "javascript in Internet Explorer"). .CHM files are not executables themselves, and HTML Help certainly is not a programming language. > The "compiler" I would like for web pages with embedded javascript > would be similar, but with more features. Such as? > My mention of "embedded javascript" recognizes that web pages do *not* > necessarily need to contain javascript. The ideas seems to be anathema > to some webmasters, but it is true. ACK, but your argumentation is inconsistent nevertheless. You cannot have "embedded javascript" without having "javascript". PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs,