Slashdot Mirror

But the number of websites which works in Firefox and Chrome but not Edge, is so big....

Strange... because currently the latest version of Edge is actually one point ahead of Firefox in terms of html standards compliance, and the upcoming version only one point behind.

Edge's javascript compliance with ES6 currently trails behind Firefox and Chrome, with almost all of it's inferiority being here. and here. These parts of Javascript are not, in practice, that significant. I won't say they are nothing, but they are still quite far removed from being needed in most cases.

I find it dubious that there are that many significant websites which would not work with Edge while working fine with another browser like Firefox unless they were specifically designed to be hostile to Edge. You may be able to find a few, but I am skeptical that the number is, as you say, "so big".

But the number of websites which works in Firefox and Chrome but not Edge, is so big....

Strange... because currently the latest version of Edge is actually one point ahead of Firefox in terms of html standards compliance, and the upcoming version only one point behind.

Edge's javascript compliance with ES6 currently trails behind Firefox and Chrome, with almost all of it's inferiority being here. and here. These parts of Javascript are not, in practice, that significant. I won't say they are nothing, but they are still quite far removed from being needed in most cases.

I find it dubious that there are that many significant websites which would not work with Edge while working fine with another browser like Firefox unless they were specifically designed to be hostile to Edge. You may be able to find a few, but I am skeptical that the number is, as you say, "so big".

I can't find a language spec for "web technologies"

In the context of browser extensions, the relevant specs are ECMA-262, CSS, HTML Living Standard, and WebExtensions API.

Incorrect.

You are _assuming_ everyone is incompetent.

We ripped jQuery out of our current project because there is _nothing_ in there that we couldn't do smaller, faster, and cleaner with native Javascript, er, ECMAScript, ECMA-262 5th Ed.

Years ago jQuery solved the cross-browser implementation problem when IE6 was popular. These days anyone using jQuery is an idiot Javascript developer.

It isn't a "theory".
It is specifically mentioned in ECMA-35 6.2.1 Character DELETE

Name: DELETE Acronym: DEL Coded representation: 07/15
DEL was originally used to erase or obliterate an erroneous or unwanted character in punched tape. DEL may be
used for media-fill or time-fill. DEL characters may be inserted into, or removed from, a CC-data-element
without affecting its information content, but such action may affect the information layout and/or the control of
equipment.

For those not familiar with ECMA-35 it is the standard document describing how escape sequences are coded.
It shows how (ESC)[ can be used to reference (CSI) in 7-bit byte-streams.
Codes starting with (CSI) are often incorrectly called escape sequences, but they are really control sequences as described in ECMA-48 5.4 Control sequences (Not to be confused with control strings.)

It isn't a "theory".
It is specifically mentioned in ECMA-35 6.2.1 Character DELETE

Name: DELETE Acronym: DEL Coded representation: 07/15
DEL was originally used to erase or obliterate an erroneous or unwanted character in punched tape. DEL may be
used for media-fill or time-fill. DEL characters may be inserted into, or removed from, a CC-data-element
without affecting its information content, but such action may affect the information layout and/or the control of
equipment.

For those not familiar with ECMA-35 it is the standard document describing how escape sequences are coded.
It shows how (ESC)[ can be used to reference (CSI) in 7-bit byte-streams.
Codes starting with (CSI) are often incorrectly called escape sequences, but they are really control sequences as described in ECMA-48 5.4 Control sequences (Not to be confused with control strings.)

> why should that be NaN? 1/0 is Infinity, not NaN.

Incorrect. You need to go back to school and review what divide by zero actually means.

a/b = c
a = b*c

However when a != 0, and b =0,

a/0 = c

There is NO value of c that produces a.

a = 0*c (impossible)

Furthermore, mathematicians define division by zero as undefined because x/0 has TWO simultaneous values: +inf and -inf, depending on which side you approach x from: the negative side of zero, or the positive side of zero. The mathematical set of Reals is NOT closed under division by zero -- it produces a singularity.

0/0 is "indeterminate" which naturally maps into NaN.

console.log( 0/0 );
NaN
console.log( isNaN(0/0) );
true

All is good and fine so far.

However Javascript uses the broken IEEE 754 definition of x/0 = Infinity. This is is retarded because is broken math

Proof:

1/0 = +inf (assume retarded definition of divide by zero is valid)
0*(1/0) = 0*inf
(0/0)*1 = 0
undefined *1 = 0
NaN = 0
WTF

Note: NaN is NOT equal to ANY value, including itself.

console.log( NaN === NaN );
false
console.log( NaN == NaN );
false

> Is there some standard that says that "big" signed integers should be surreptitiously changed into unsigned ones?

Your mistake is assuming Javascript has integers in the first place. Javascript does NOT have signed integers. All values are 64-bit floating point values.

4.3.20 Number value

primitive value corresponding to a double-precision 64-bit binary format IEEE 754-2008 value

and

6.1.6The Number Type

The Number type has exactly 18437736874454810627 (that is, 264-253+3) values, representing the double-precision 64-bit format IEEE 754-2008 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, ...

One of the reasons Javashit is such a crappy language because it has no uint32_t nor uint64_t. This leads to subtle over-flow bugs that are difficult or impossible to work around.

But what do you expect from a language designed in 10 days.

> why should that be NaN? 1/0 is Infinity, not NaN.

Incorrect. You need to go back to school and review what divide by zero actually means.

a/b = c
a = b*c

However when a != 0, and b =0,

a/0 = c

There is NO value of c that produces a.

a = 0*c (impossible)

Furthermore, mathematicians define division by zero as undefined because x/0 has TWO simultaneous values: +inf and -inf, depending on which side you approach x from: the negative side of zero, or the positive side of zero. The mathematical set of Reals is NOT closed under division by zero -- it produces a singularity.

0/0 is "indeterminate" which naturally maps into NaN.

console.log( 0/0 );
NaN
console.log( isNaN(0/0) );
true

All is good and fine so far.

However Javascript uses the broken IEEE 754 definition of x/0 = Infinity. This is is retarded because is broken math

Proof:

1/0 = +inf (assume retarded definition of divide by zero is valid)
0*(1/0) = 0*inf
(0/0)*1 = 0
undefined *1 = 0
NaN = 0
WTF

Note: NaN is NOT equal to ANY value, including itself.

console.log( NaN === NaN );
false
console.log( NaN == NaN );
false

> Is there some standard that says that "big" signed integers should be surreptitiously changed into unsigned ones?

Your mistake is assuming Javascript has integers in the first place. Javascript does NOT have signed integers. All values are 64-bit floating point values.

4.3.20 Number value

primitive value corresponding to a double-precision 64-bit binary format IEEE 754-2008 value

and

6.1.6The Number Type

The Number type has exactly 18437736874454810627 (that is, 264-253+3) values, representing the double-precision 64-bit format IEEE 754-2008 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, ...

One of the reasons Javashit is such a crappy language because it has no uint32_t nor uint64_t. This leads to subtle over-flow bugs that are difficult or impossible to work around.

But what do you expect from a language designed in 10 days.

Linky link to the organization formally known as the European Computer Manufacturers Association

Uh, no. It is standardized. Technically, it says that using an index past the end of the string is to be treated the same as the length of the string. If you check out the official ECMA specification you'll see that they define "finalStart" as: "Let finalStart be min(max(intStart, 0), len)."

I just gave a simpler explanation of what that actually accomplishes: namely, asking for a substring past the end of a string gives an empty string. Which is the standard.

The spec only says "approximately uniform". The code generated approximately uniform numbers, for some value of approximate, so it wasn't broken per se.

Neither do you, apparently. C++ (the language, not the library) is the largest programming language in existence. Nothing is larger.

[citation needed]

A clue: there is no citation because you're making it up.

So let's consider languages where actual formal specifications exist because they have to be written in excricuiating detail because the asusmption there is no reference implementation that people can refer to if in doubt.

Java spec (788 pages, for the language only):

https://docs.oracle.com/javase...

C++ spec (425 pages, for the language only):

http://open-std.org/jtc1/sc22/...

C# circa 2006 language specification (553 pages for the language only)

http://www.ecma-international....

So there you go, definitive proof that there are bigger languages than C++.

Huh, looks like ADA and Fortran 2008 have longer specs too.

So there you go, there are 4 standardised languages I've given you which have longer specifications than C++.

The best C++ devs I've managed were those who openly acknowledged the fact that it is too large and too complicated to be used without sticking to a strict subset of some sort.

Given your propensity to simply make shit up about C++ [citation: see above], your statements lack credibility.

> No more prototype boilerplate

Definitely a nice touch but not mandatory. Using anonymous closures isn't THAT hard to do with inheritance with.

The nice thing about classes in Section 14.5 is this note:

NOTE: A ClassBody is always strict code.

Now if they could only clean up the rest of the crappy language. At least it's a start.

Since actually having a link to the spec in the announcement of the spec would be helpful...

http://www.ecma-international....

Plenty. All of your criteria have little to do with the language and much more to do with the developer. Any properly defined/debugged program is "safe". Any properly optimized program is "performant". "Clear" is just about source code, which means that it's entirely up to the developer.

ISO 9899:2011.
ISO 14882:2014E.
ECMA 334.

Swift is a "lookalike" to all of these in several ways, especially as that list goes on. The list of languages that aren't ancestral to Swift but that have standards could go on for quite a while longer.

This? http://www.ecma-international....

I agree with this sentiment. However, .docx is already a "standard" that is also compressed. In fact, if you rename it to .zip and open it up, you can view the XML formatted documents it contains. Office OpenXML: http://www.ecma-international....

Quite simply, a patent "promise" is not the same thing as a license. You see, even if they're bared by Laches, they can still drag you through the courts and you've got to prove they're barred by making the promise. If you had a license...you could make a single motion at the first hearing or in the pretrial motions to dismiss because of being licensed if they sought to sue you.

Having this crap in there means Mono's toast without a real license to any valid patents, combined with a covenant to license all tech as it becomes apparent, that ends up in this common core of stuff. Otherwise, you're INSANE for using it- because you can and most probably WILL be sued over it.

No - it is actually stronger (look up promissory estoppel). But leave that aside, because the patents have also already been granted.

The *promise* was issued because fanatics cried foul at the patent grant, arguing that Microsoft with it vast army of lawyers could just sue any OS project out of existence, patent grant or not. Hence, Microsoft issued the promise, all but ensuring that such a case would be outright dismissed since you've acted in good faith on a promise. The promise in that case is actually one of the strongest contract forms imaginable, as it is one-sided: you do not have to sign anything to be covered.

docx
doc

Here's the third edition standard for ECMA script. Please point out any way that ActionScript 2.0 doesn't comply with the standard aside from the comparison operator.

http://www.ecma-international....

Dart is already being made an ECMA standard, just like JavaScript: http://www.ecma-international....

Maybe they should re-evaluate their position on the Microsoft Office formats.

But, but... the Microsoft Office formats are open and documented!

Hey, do you still want that bridge in Brooklyn I have for sale?

Maybe they should re-evaluate their position on the Microsoft Office formats.

But, but... the Microsoft Office formats are open and documented!

Believe it or not, CIL (or MSIL in Microsoft-speak), the bytecode for .NET, is an ECMA standard, and implementations of both .NET JIT'ers and standard libraries exist for practically all modern platforms, thanks to Mono. So I'd say: "competition for portable applications". Really! Just take a look at Gtk#. As a result, there are numerous applications for Linux written in .NET languages (e.g., Banshee). Having written huge amounts of code in both JVM languages (Java, Scala, JRuby, and Clojure) and .NET languages (F# and C#), I would take .NET over the JVM for a new project any day.

Also, to pre-emptively swat down this counter-argument: while the Mono people and Microsoft may have had some animosity in the past, it is most definitely not the case any more. Most of the Mono people I have spoken to (yes, in person) say that their relationship with Microsoft is pretty good.

Build systems and dependency management for the JVM are their own mini-nightmare. .NET's approach isn't perfect but compared to [shudder] Ant, Maven, Buildr, SBT, and on and on and on... it largely just works.

http://www.ecma-international.org/publications/standards/Ecma-376.htm

C# isn't standardized? Someone should call ECMA and ISO then and tell them they've been had.

The specification itself has to be invalid. How can 5000+ pages not have errors? Just look at the 43MB PDF blob (link on the page, not a direct download).

What's really sad is that initially Javascript had the following idiotic C keywords reserved but doesn't use them -- even more annoying was that you couldn't use them as property names until recently!

* char
* double
* float
* int
* long
* short
* void // still reserved as it is an operator

Reference / See:
* http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
* http://stackoverflow.com/questions/5306315/browser-support-for-using-a-reserved-word-as-a-property-name-in-javascript
* https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Reserved_Words

Javascript is the new Basic -- it encourages sloppy programming with hard to find bugs.

--
Only cowards use censorship.

C# != Microsoft.

http://www.ecma-international.org/publications/standards/Ecma-334.htm

Unless you like documentation. There's more than six-thousand pages to go through.

I agree, just try to read the ECMA OOXML standard in its entirety before it's obsolete.

That said, C++/CLI actually is a standard. http://www.ecma-international.org/publications/standards/Ecma-372.htm

A quasi-standard - one that is only managed by ECMA and was rejected by ISO telling them to give it a name not containing the term "C++". So, in the end it is really just a Microsoft "Standard".

Only partially true. C++ Metro apps actually aren't C++/CLI .NET apps. In fact, currently C++/CLI isn't supported at all from a Metro app, although that will likely change. There are a couple of extensions to the C++ language in the VS11 compiler to facilitate easier syntax when working with WinRT and other COM components, but it is strictly compiler syntax candy.

That said, C++/CLI actually is a standard. http://www.ecma-international.org/publications/standards/Ecma-372.htm

Since C# never aimed to run on non-windows, it's also not a fair comparison of designs, because the goals were different.

Plain wrong. C# is a platform-agnostic language with a standards-defined specification. The CLR and CIL specifications are also 100% platform independent.

What is tied to Windows is Microsoft's implementation of their CLR and CIL compiler. This is what Mono implements for other platforms.

Or not, since C# is an ECMA standard. Don't let facts interrupt your butthurt though.

well, there's this and this.

C# is an open standard which anyone is free to use. A number of the libraries in Mono are also based on open standards. .NET MVC is MS-PL.

I don't know right now exactly what tech Microsoft has patented, but it's not in their best interest right now to destroy Mono. MVC + Mono + Linux is really the best option for enterprise web right now in my opinion. JSP never really was all it was cracked up to be. MVC ain't perfect, but it's usable.

He should have been sentenced to implementing ECMA-376 in COBOL without bugs. When he's done with the 6000+ pages of docs, he can go.

I have nothing MS in my house, nor do I intend to just give them money, why would I want to use .NET?

The fact that the CLI is standardized is a potentially compelling reason to use .NET. The C# language is also standardized. In fact, these standards are available at no cost. This is an incredible advantage; if, for some reason or another, you find your .NET vendor to be inadequate, you can move to another vendor with minimal overhead. While there is no question in my mind that Microsoft's implementation of .NET the most commonly used .NET implementation out there, the fact that there is already a competing vendor here is a good sign. This, of course, requires that you resist the urge to use implementation-dependent features in your project. A sufficiently abstract design should mitigate this problem when those features are required.

Why should you use .NET? Maybe there's no good reason to do so. If you're a programmer, you have to decide whether or not that is actually the case. You can make that decision however you like, for whatever reasons you like. There are many objective reasons one might pick not to use .NET, including the possible cost of training your development team to use it. With that in mind, programming is an engineering task. At the end of the day, things like .NET are only tools, and a failure to properly perform research is foolish at best. .NET, at least in its standardized capacity, is no more of a "Microsoft thing" than C++ is a "Bell Labs thing". I do not see that you have to give Microsoft any money or endorsement to make use of .NET as a programmer.

I have nothing MS in my house, nor do I intend to just give them money, why would I want to use .NET?

The fact that the CLI is standardized is a potentially compelling reason to use .NET. The C# language is also standardized. In fact, these standards are available at no cost. This is an incredible advantage; if, for some reason or another, you find your .NET vendor to be inadequate, you can move to another vendor with minimal overhead. While there is no question in my mind that Microsoft's implementation of .NET the most commonly used .NET implementation out there, the fact that there is already a competing vendor here is a good sign. This, of course, requires that you resist the urge to use implementation-dependent features in your project. A sufficiently abstract design should mitigate this problem when those features are required.

Why should you use .NET? Maybe there's no good reason to do so. If you're a programmer, you have to decide whether or not that is actually the case. You can make that decision however you like, for whatever reasons you like. There are many objective reasons one might pick not to use .NET, including the possible cost of training your development team to use it. With that in mind, programming is an engineering task. At the end of the day, things like .NET are only tools, and a failure to properly perform research is foolish at best. .NET, at least in its standardized capacity, is no more of a "Microsoft thing" than C++ is a "Bell Labs thing". I do not see that you have to give Microsoft any money or endorsement to make use of .NET as a programmer.

It's even more confusing than that. Ecma-376 has two editions, the first being rejected by ISO and the second being accepted as ISO/IEC 29500. The first was more or less Microsoft's old proprietary format, and the second includes either "transitional" or "strict" versions. I suppose the Aussie standard means ecma-376, 2nd edition (since it's newer), and either the transitional or strict formats contained therein. In that case, TFA seems to be close to correct--MS Office appears to be one of the only software suites that supports it.

Stalling tactic - new law requiring reading of the specification aloud. Have you seen the documentation? War and Peace is a few times smaller.

Isn't the CLI specification open?

Yes it is, and it's standardized. Unlike Java.

It's true that the very first version of the language, Dartmouth BASIC, didn't have any operators for graphics in it. But at that point in time, there was no language standard yet, so what "non-standard extensions" are is unclear. All implementations of BASIC were "non-standard" then.

By the time the language was standardized by ECMA in 1986 and then by ANSI in 1987, it already had graphics, and that was captured in the standard. Granted, the syntax in that document was different from the typical syntax used by DOS BASIC implementations (which is the one I shown earlier), but it was equally incoherent.

If by .NET you mean C#... http://www.ecma-international.org/publications/standards/Ecma-334.htm - see the attached Patent statement and it's embedded Community Promise.

Everyone keeps talking about MS controlling C#, lets not forget that the C# language, just like java, is an ecma specification http://www.ecma-international.org/publications/standards/Ecma-334.htm MS Does have an exclusivity on the .Net Framework however. Though even that they've opened up (the majority at least) to open download. Though I believe you're not allowed to change that source and redistribute it. --Serp

On the other hand... You know that for Windows Mobile 7, apps need Microsoft's approval, don't you?

Yes, and it is bad.

But at least there's no license agreement with WP7 that says "applications must be originally compiled in C#" or other such bullshit - so long as its verifiable CIL code, it's kosher, and all the specs that are needed to write a compiler targeting it are freely available. Which is what TFA is about. It's a whole new level of "bad" - new in all ways, as no-one ventured there before, not even the historically tightly locked down gaming consoles.

Totally marketing garbage. Man is probably a great guy, with a lousy job. But F#, really? even .NET is ripping off Java.

I'm not sure I follow. Are you saying that F# is somehow "ripping off" Java? If you mean it's a "rip off" something else, then, well, it's clearly designated as an OCaml derivative, it's not exactly news... but we wouldn't get far if people wouldn't "rip off" the work of others, and build on that. You know, just like Java ripped off C++ and Smalltalk, and JavaScript ripped off Self, and Smalltalk ripped off Lisp, etc...

If you mean .NET as a whole being a rip-off of Java, then you're late by like 6 years or so - C# 1.0 was for the most part "a better Java" (note the "better" part, however), but since then it has evolved much faster, and Java is struggling to keep pace, "ripping off" C# as it goes. To give a specific example: C# had first-class functions (called anonymous delegates in the language) in version 2.0, released in 2005. Java still doesn't have them, and they will only likely come in Java 7, to be released by the end of this year. To give another example, C# 2.0 and above has generics that Java language designers would call "reified". Java doesn't, and there's no telling when, or even if, it will.

Microsoft talks about building "ecosystems" but the way they do it, everything in the ecosystem has to have a M$ logo on it. Why can't they just inter-operate and integrate with outside software?

Uhh, I don't even know where to begin here.

Here is the C# language specification, if you ever want to write your own C#compiler. Here is the CLI spec - this covers VM semantics, all involved file formats, and the fundamental class library - this is useful for a .NET compiler for any language.

And third-party languages for .NET do exist in large quantities. One good example is Delphi Prism, which provides full Visual Studio experience, not any worse than what is there for C# out of the box. Then there's Eiffel, Smalltalk, Perl, Fortran, COBOL... IronPython and IronRuby were also outside projects, by the way - their authors got hired by MS along the way because the company was interested in developing dynamic languages on the platform, and, naturally, picked the two most popular ones.

Libraries are also part of the "ecosystem", by definition and there are tons of third-party ones. I won't even bother giving links as there are too many - google it if you want.

So, can you explain what you mean by "inter-operate and integrate with outside software" with respect to .NET, if the above is not good enough?

Totally marketing garbage. Man is probably a great guy, with a lousy job. But F#, really? even .NET is ripping off Java.

I'm not sure I follow. Are you saying that F# is somehow "ripping off" Java? If you mean it's a "rip off" something else, then, well, it's clearly designated as an OCaml derivative, it's not exactly news... but we wouldn't get far if people wouldn't "rip off" the work of others, and build on that. You know, just like Java ripped off C++ and Smalltalk, and JavaScript ripped off Self, and Smalltalk ripped off Lisp, etc...

If you mean .NET as a whole being a rip-off of Java, then you're late by like 6 years or so - C# 1.0 was for the most part "a better Java" (note the "better" part, however), but since then it has evolved much faster, and Java is struggling to keep pace, "ripping off" C# as it goes. To give a specific example: C# had first-class functions (called anonymous delegates in the language) in version 2.0, released in 2005. Java still doesn't have them, and they will only likely come in Java 7, to be released by the end of this year. To give another example, C# 2.0 and above has generics that Java language designers would call "reified". Java doesn't, and there's no telling when, or even if, it will.

Microsoft talks about building "ecosystems" but the way they do it, everything in the ecosystem has to have a M$ logo on it. Why can't they just inter-operate and integrate with outside software?

Uhh, I don't even know where to begin here.

Here is the C# language specification, if you ever want to write your own C#compiler. Here is the CLI spec - this covers VM semantics, all involved file formats, and the fundamental class library - this is useful for a .NET compiler for any language.

And third-party languages for .NET do exist in large quantities. One good example is Delphi Prism, which provides full Visual Studio experience, not any worse than what is there for C# out of the box. Then there's Eiffel, Smalltalk, Perl, Fortran, COBOL... IronPython and IronRuby were also outside projects, by the way - their authors got hired by MS along the way because the company was interested in developing dynamic languages on the platform, and, naturally, picked the two most popular ones.

Libraries are also part of the "ecosystem", by definition and there are tons of third-party ones. I won't even bother giving links as there are too many - google it if you want.

So, can you explain what you mean by "inter-operate and integrate with outside software" with respect to .NET, if the above is not good enough?

Patents on OOXML, 1
Patents on OOXML, 2
Patents on the C# language
Patents on the Common Language Infrastructure