...encrypted communications are too bloody hard to debug!
With unencrypted protocols, I can whip out the packet sniffer and find out *exactly* what's going on. With encrypted protocols, I have to write reports like "we have verified our software configuration and believe it to be correct; perhaps the problem is at your end?"
Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode. Maybe even with a "relax the crypto" configuration flag we can throw during debug.
Not that I think it's a good idea, but editors like xemacs which support mixed proportional and fixed fonts on the same page could solve this problem fairly easily -- use a fixed font for all whitespace which touches the left margin, and make everything else proportional.
I have been using -misc-fixed-medium-r-normal--15-140-75-75-C-90-ISO8859-1 since '97 or '98 and still be believe it to be far superior! Condensed is to skinny.:)
I suppose an upgrade to a Unicode font is due at some point, but I don't speak any languages which can't be represented with Latin-1.
As for colours, I like yellow on blue for paren-match, khaki on blue3 for for default face, and while for font-lock-keyword-face. Loosely borrowed from Borland's IDEs of the Turbo Pascal 5 era.
> now it seems that USA considers withholding some important systems, > meaning the version sold will be inferior to the equivalent operated > by US forces. And this is to nato allies.
That's okay. If said allies want those systems, they can fab them themselves, although they may have to purchase the specifications and other engineering documents from the Chinese.
>> "The proof will be whether it revives home entertainment sales by getting >> consumers excited about the new freedoms of the digital world."
> Really? New Freedoms?
Interestingly, I personally lost interest in home entertainment when it started getting hard to buy blank Beta tapes.... it was only recently revived when I discovered I could buy a DVD player that can read Div/X off thumb drives.
European pumps dole out gas based on RON (research octane number), whereas in North American they use "pump octane", or "anti-knock index". AKI is calculated by averaging RON and MON (motor octane number). MON is determined experimentally on a special engine.
RON-MON is usually 6 to 10 in North America. This is called the sensitivity, S.
Given S=10, then,
RON-MON = 10 95 - MON = 10 95 - 10 = MON MON = 85
and
95+85 / 2 = 90
So 95 octane in europe is around 90 octane in North America, maybe a little higher depending on S.
Ah, I see you have the lawyer that sues Bing! He is my favorite. You see, he works on a contingency basis and that way it comes under the monthly current budget and not the capital account.
> How is only FF 3.5 supporting trim useful to designing a web page?
Part of the Mozilla Team's goal is to implement features from draft specifications so that upcoming features can be tried by the community, who can in turn provide feedback to the technical committee. I believe String.trim is ES5 track, and was in the last ES4 draft.
> You still have to wrap it in a function to support other browsers don't you?
Imagine firefox *didn't* provide a native version of String.prototype.trim. Then you'd have to implement it in all browsers. In fact, if you are happy with the cross-browser implementation, you could simply ignore the Firefox's native.trim method and use your own.
This means that it is exactly as much work for the developer to pretend that Mozilla did not add this method as it is for him to not have it all (as is the case with the other browsers). Thus, the only drawback to adding the method is that it gives people something to whine about on slashdot.
The fellow writing the saladwithsteve.com article is on-point with respect to writing JavaScript programs. But the fact that people can write poor JavaScript programs because they didn't bother to learn the language is not the fault of JavaScript.
if (!a)
print("a is falsey");
is perfectly clear, depending on the type of a:
string: "" undefined: (undefined) object: null number: 0 or NaN boolean: false
Which of the situations values do YOU think should be truthy?
No, delete is not the same as assignment to null. It is more like assignment to void 0. The difference is that null has typeof object and value null, whereas void 0 has typeof undefined and no value.
Deep copy is perfectly doable in JavaScript, provided you have pure-JavaScript objects. I suspect that problem you are seeing is traversing DOM objects which are poorly reflected in JavaScript.
The W3C is not helping here, either, with idiotic things like document.all on the table.
Assignment-by-copy is also not unusual; all functional programming languages do this. JavaScript is a bit unusual in that it has object references.
re. String.prototype.trim You are angry because Mozilla implemented an extension to the language before it was ratified by TC39/ECMA. I can see why this would make you angry, although, frankly, I find the extensions convenient myself. This has happened many times in the past. For example, Turbo C 1.0 had a conio library on MS-DOS that was not documented in the ANSI-C standard. This was confusing, but handy once I read about it.
this You do not like how the DOM's event loop virtualized 'this' and you do not like prototypical inheritance. The first is not a language issue. The second is an idiomatic choice. I happen to like prototypical inheritance, I find it flexible and shallow. Other people like making big, complicated, deep hierarchies. These people are usually tempted to re-implement classical inheritance. That is a bad choice.
Observation: deep object hierarchies and templates seem to chew up a lot of needless developer-time in early-debug phase of C++ projects.
Most of the time, I don't care if a baseball player is a human is a mammal is a vertabrate is an animal. I just care if they can catch a ball. That is the difference between classical inheritance + strict types and prototypical inheritance + duck types.
undefined You do not like how the environment provides a variable named undefined which has the value void 0, that (void 0).toString === "undefined" and that typeof(void 0) is "undefined".
Can't say I blame you, this is pretty warty. But if you understand it (and I have just explained it), it is perfectly safe.
null I'm not sure what your problem is with null, unless you are confusing it with undefined. Assigning to null with throw a SyntaxError. null is a keyword and has specific meaning.
truthiness null, undefined, 0, and NaN are falsy. Everything else is truthy. The if keyword coerces its expression argument to a boolean type. The values above coerce to false. Everything else coerces to true. There is no variable mutation, I do not know where you got this idea.
Don't forget that on-page-load semantics and timers are not part of JavaScript. They are DOM semantics.
That said, timers *are* relevant in a systems language. I had to re-implement for server side JS (although I chose "sleep" rather than the setTimeout event loop paradigm because it suited by purposes better)
That was an interesting link. The outlier, regex-dna is kind of funny -- regexes are compiled directly to native assembly code on tracemonkey. I'll bet the benchmarker's regex library compiles to an intermediary representation for processing through a state machine of some kind.
So, if I'm right, the inverted performance ratio is a result of the C code generating interpreted regex and the JS code generating native regex compilation. That's kind of hilarious.
> There is more malware written in Javascript than in any other language in existence.
*ANY* language which can access poorly-written native types can expose bugs. This has nothing, whatsoever, to do with JavaScript.
Even Lord Java, High Falutin Emperor of the No-Mistakes in the Kingdom of Super-Special would have security vulnerabilities if you bundled it with buggy native code accessed via JNI. *DUH*
Incidentally, pretty much everything you said about JS engine implementation details is not really accurate, at least not on JS engine in modern versions of the firefox browser.
The backing storage of Arrays is now a C-style dynamically allocated array of jsvals. jsvals are pointer-sized and can encode either
- bools
- void
- 31-bit signed integers
- pointer to object|string|double
Additionally, variable references are tokenized with references and accesses to values are cached within a property cache. This is particularly import when your engine has a JIT; you can't go re-parsing the source code every time somebody uses a variable!
I've never used canvas (I live on the server-side), but I'd be willing to bet that your 3D code was either bounded by computation or DOM access to the canvas object (which is not a real JavaScript object, it is proxied from the DOM).
It would be interesting to measure performance of 2d/3d code backed by JS arrays and similar Perl data types in modern versions of JS (v8 or tracemonkey) and Perl.
And before you start in with a statement like "Well if the DOM is slow then JS speed doesn't matter", re-read the title of TFA.
Slashdot Mirror
...encrypted communications are too bloody hard to debug!
With unencrypted protocols, I can whip out the packet sniffer and find out *exactly* what's going on. With encrypted protocols, I have to write reports like "we have verified our software configuration and believe it to be correct; perhaps the problem is at your end?"
Maybe we need to come up with a standard way of encrypting things, that our packet sniffers somehow know how to decode. Maybe even with a "relax the crypto" configuration flag we can throw during debug.
Not that I think it's a good idea, but editors like xemacs which support mixed proportional and fixed fonts on the same page could solve this problem fairly easily -- use a fixed font for all whitespace which touches the left margin, and make everything else proportional.
No way! That's a terrible font!
I have been using -misc-fixed-medium-r-normal--15-140-75-75-C-90-ISO8859-1 since '97 or '98 and still be believe it to be far superior! Condensed is to skinny. :)
I suppose an upgrade to a Unicode font is due at some point, but I don't speak any languages which can't be represented with Latin-1.
As for colours, I like yellow on blue for paren-match, khaki on blue3 for for default face, and while for font-lock-keyword-face. Loosely borrowed from Borland's IDEs of the Turbo Pascal 5 era.
> now it seems that USA considers withholding some important systems,
> meaning the version sold will be inferior to the equivalent operated
> by US forces. And this is to nato allies.
That's okay. If said allies want those systems, they can fab them themselves, although they may have to purchase the specifications and other engineering documents from the Chinese.
> So, maybe you should educate yourself a bit more, before questioning
> the education of others.
He said eg., not ie.
Maybe you should read posts more carefully before insulting the authors?
>> "The proof will be whether it revives home entertainment sales by getting
>> consumers excited about the new freedoms of the digital world."
> Really? New Freedoms?
Interestingly, I personally lost interest in home entertainment when it started getting hard to buy blank Beta tapes.... it was only recently revived when I discovered I could buy a DVD player that can read Div/X off thumb drives.
> So what kind of racing involves towing 7000+ pounds on the track?
Dunno, but I think the OP was talking about towing 7000+ pounds *to* the track.
European pumps dole out gas based on RON (research octane number), whereas in North American they use "pump octane", or "anti-knock index". AKI is calculated by averaging RON and MON (motor octane number). MON is determined experimentally on a special engine.
RON-MON is usually 6 to 10 in North America. This is called the sensitivity, S.
Given S=10, then,
RON-MON = 10
95 - MON = 10
95 - 10 = MON
MON = 85
and
95+85 / 2 = 90
So 95 octane in europe is around 90 octane in North America, maybe a little higher depending on S.
1. U-Haul *did* use Diesels at one point. I had to teach my wife about glow plugs a few years back, she couldn't start it!
2. You can put a gasoline nozzle in a diesel tank, but not vice-versa
That's not an inline V-8.
Hint: A round square would also be an innovation.
Ah, I see you have the lawyer that sues Bing! He is my favorite. You see, he works on a contingency basis and that way it comes under the monthly current budget and not the capital account.
And then there are people like me, who use almost nothing BUT web apps.
In fact, the only app I have run today, so far, that doesn't run in my browser is... my browser.
It was probably two separate million-dollar settlements, one from an 8-year-old girl and from a dead grandmother.
These ARE the same people involved in the Napster suits, after all.
> How is only FF 3.5 supporting trim useful to designing a web page?
Part of the Mozilla Team's goal is to implement features from draft specifications so that upcoming features can be tried by the community, who can in turn provide feedback to the technical committee. I believe String.trim is ES5 track, and was in the last ES4 draft.
> You still have to wrap it in a function to support other browsers don't you?
Imagine firefox *didn't* provide a native version of String.prototype.trim. Then you'd have to implement it in all browsers. In fact, if you are happy with the cross-browser implementation, you could simply ignore the Firefox's native .trim method and use your own.
This means that it is exactly as much work for the developer to pretend that Mozilla did not add this method as it is for him to not have it all (as is the case with the other browsers). Thus, the only drawback to adding the method is that it gives people something to whine about on slashdot.
The fellow writing the saladwithsteve.com article is on-point with respect to writing JavaScript programs. But the fact that people can write poor JavaScript programs because they didn't bother to learn the language is not the fault of JavaScript.
if (!a)
print("a is falsey");
is perfectly clear, depending on the type of a:
string: ""
undefined: (undefined)
object: null
number: 0 or NaN
boolean: false
Which of the situations values do YOU think should be truthy?
No, delete is not the same as assignment to null. It is more like assignment to void 0. The difference is that null has typeof object and value null, whereas void 0 has typeof undefined and no value.
Deep copy is perfectly doable in JavaScript, provided you have pure-JavaScript objects. I suspect that problem you are seeing is traversing DOM objects which are poorly reflected in JavaScript.
The W3C is not helping here, either, with idiotic things like document.all on the table.
Assignment-by-copy is also not unusual; all functional programming languages do this. JavaScript is a bit unusual in that it has object references.
So let me summarize your complains:
re. String.prototype.trim
You are angry because Mozilla implemented an extension to the language before it was ratified by TC39/ECMA. I can see why this would make you angry, although, frankly, I find the extensions convenient myself. This has happened many times in the past. For example, Turbo C 1.0 had a conio library on MS-DOS that was not documented in the ANSI-C standard. This was confusing, but handy once I read about it.
this
You do not like how the DOM's event loop virtualized 'this' and you do not like prototypical inheritance. The first is not a language issue. The second is an idiomatic choice. I happen to like prototypical inheritance, I find it flexible and shallow. Other people like making big, complicated, deep hierarchies. These people are usually tempted to re-implement classical inheritance. That is a bad choice.
Observation: deep object hierarchies and templates seem to chew up a lot of needless developer-time in early-debug phase of C++ projects.
Most of the time, I don't care if a baseball player is a human is a mammal is a vertabrate is an animal. I just care if they can catch a ball. That is the difference between classical inheritance + strict types and prototypical inheritance + duck types.
undefined
You do not like how the environment provides a variable named undefined which has the value void 0, that (void 0).toString === "undefined" and that typeof(void 0) is "undefined".
Can't say I blame you, this is pretty warty. But if you understand it (and I have just explained it), it is perfectly safe.
null
I'm not sure what your problem is with null, unless you are confusing it with undefined. Assigning to null with throw a SyntaxError. null is a keyword and has specific meaning.
truthiness
null, undefined, 0, and NaN are falsy. Everything else is truthy. The if keyword coerces its expression argument to a boolean type. The values above coerce to false. Everything else coerces to true. There is no variable mutation, I do not know where you got this idea.
Do you mean JavaScript without packages or any other language support for real modularity?
Or did you forget to RTFA?
Don't forget that on-page-load semantics and timers are not part of JavaScript. They are DOM semantics.
That said, timers *are* relevant in a systems language. I had to re-implement for server side JS (although I chose "sleep" rather than the setTimeout event loop paradigm because it suited by purposes better)
> The problem is not lack of expressive power, it's excess. JavaScript was
> unmaintainable until jQuery came around
Can you provide two small examples of unmaintainable JavaScript code, where the maintability problem is solvable by jQuery?
Please stick with JavaScript. No DOM, CSS, ActiveX, etc.
That was an interesting link. The outlier, regex-dna is kind of funny -- regexes are compiled directly to native assembly code on tracemonkey. I'll bet the benchmarker's regex library compiles to an intermediary representation for processing through a state machine of some kind.
So, if I'm right, the inverted performance ratio is a result of the C code generating interpreted regex and the JS code generating native regex compilation. That's kind of hilarious.
> There is more malware written in Javascript than in any other language in existence.
*ANY* language which can access poorly-written native types can expose bugs. This has nothing, whatsoever, to do with JavaScript.
Even Lord Java, High Falutin Emperor of the No-Mistakes in the Kingdom of Super-Special would have security vulnerabilities if you bundled it with buggy native code accessed via JNI. *DUH*
Incidentally, pretty much everything you said about JS engine implementation details is not really accurate, at least not on JS engine in modern versions of the firefox browser.
The backing storage of Arrays is now a C-style dynamically allocated array of jsvals. jsvals are pointer-sized and can encode either
- bools
- void
- 31-bit signed integers
- pointer to object|string|double
Additionally, variable references are tokenized with references and accesses to values are cached within a property cache. This is particularly import when your engine has a JIT; you can't go re-parsing the source code every time somebody uses a variable!
I've never used canvas (I live on the server-side), but I'd be willing to bet that your 3D code was either bounded by computation or DOM access to the canvas object (which is not a real JavaScript object, it is proxied from the DOM).
It would be interesting to measure performance of 2d/3d code backed by JS arrays and similar Perl data types in modern versions of JS (v8 or tracemonkey) and Perl.
And before you start in with a statement like "Well if the DOM is slow then JS speed doesn't matter", re-read the title of TFA.
Is that that jslibs opengl binding, or something else?
You can't avoid doing that, but strict mode should generate a warning.