Is it time for a new Firefox thread yet?



  • Firefox 28 has been released.  And to the surprise of exactly nobody, it contains a text rendering bug, somehow related to a problem with Internet Explorer 10, that was first reported 5 months ago.  Here are some screen shots posted to Bugzilla. No, those are not compresion artifacts, that's what people are seeing.

     

     

    But that's OK.  At least Firefox 28 now has volume controls for HTML5 video and audio.



  •  Hah. Firefox has that text rendering bug for me for the past year.



  •  I used to get the problem shown in the first picture, but it seems to be fixed as of Firefox 30.


  • ♿ (Parody)

    @El_Heffe said:

    Firefox...somehow related to a problem with Internet Explorer 10

    Microsoft sabotaging Firefox, Russia usurping Eastern Europe...it's like history is going in reverse.


  • Garbage Person

    @cheapie said:

     I used to get the problem shown in the first picture, but it seems to be fixed as of Firefox 30.

    [img]http://1-media-cdn.foolz.us/ffuuka/board/tg/image/1356/49/1356491958516.jpg[/img]

     



  • This guy paid real cash-money to work-around a bug in Firefox. Mock him.

    In FF's defense, the lack of a requirement to show a volume slider on HTML5 video and audio is awful, and it's a good thing they're going above the bare-minimum required to add one. Maybe the long-term strategy here is when the HTML5 video and audio is good enough you won't even NEED text on the Internet!


  • Trolleybus Mechanic

     Firefox rendering bugs are pretty much an expectation of each release. Mainly because there's always some wankoff lead dev who says "we need to rewrite the rendering engine to conform with my preferences".  So Firefox going back at least to version 4 does dumb shit like <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=594889">fucking up spacing between characters</a>.

    The dumb-as-shit rendering method gets revealed, eventually, by these basic troubleshooting responses from Mozilla support:

    1) You're blind. I don't see it. Fuck off.

    2) I can't repro it. Fuck off.

    3) Fine, you posted screen shots. But it's probably a compression artifact of your jpg. Fuck off.

    4) Okay, fine, we acknowledge you posted a lossless png. Disable all your plug-ins, delete your profile, and reinstall Firefox.  {hehehe... that's such a data destroying PITA that no one will ever do that ticket closed!}

    5) Umm, fresh install, you say?  OBVIOUSLY the problem is Clear Type. Disable that useless Micro$oft shit. Sure, it'll make everything else on your system look like shit, but it's not OUR fault M$ is such fuckups.

    6) More screenshots showing that nothing changes on Firefox with Clear Type off. Godd-- I mean good.  Yeah. We love helping you. Ummm-- turn off Hardware Acceleration in Firefox. No, we don't know what that feature does, either. Yes, it fucks things up. No, surely that isn't our fault it's, umm, the fault of your graphics card.

    7) Hardware Acceleration didn't do it, huh?  Hmm, okay, this one might be a long shot, but go to about:config, find some.brandnew.rendering.setting (only available in the new version of Firefox you're reporting the bug on), and set it to false.  What is it?  Oh, it's a new basically untested rendering feature our lead dev forced-- I mean promoted-- into the release branch. It probably isn't that, because if it was we'd have to admit we're fuckups and just wasted a week of your time.

    And repeat when the next version of FF with the next rendering crap is released in a month.


  • Trolleybus Mechanic

    OH HEY IT GETS BETTER GUYS!

    @Yes. Read this. Oh mercy me read this said:

    [Mozilla's] advancements in a revolutionary new open source language called Rust... The Rust language will power Mozilla's new browser...

    Mozilla can't write a proper browser anymore. So rather than figuring out how to fix their shit-- they're going to write a brand new browsers-- written in a brand new language-- that they're writing.

    Oh my god this article is April Fools come early. The pie-eyed optimism-- the buzz-word thick marketspeak-- calling "revolutionary"-- recoding EVERYTHING including the language the code is coded in-- thank God I'm not up for critiquing this shit line by line, or I'd die of comedy orgasm overload.

    AND THEY CALLED THEIR LANGUAGE RUST!  Why not "obsolete"?  Or "decayed corpse pile"?  AH! AH! AHHHHHHHHHH *poof*

     



  • What's even more alarming is that I was able to reproduce the bug in Chrome after reproducing it in Firefox!



  • Just be happy you're not running in high contrast:
    Firefox in high contrast



  • @Lorne Kates said:

    AND THEY CALLED THEIR LANGUAGE RUST!  Why not "obsolete"?  Or "decayed corpse pile"?  AH! AH! AHHHHHHHHHH poof

    To be fair, though: Brendan Eich is a really smart guy, Rust looks fairly tidy, C++ really is the most horrendous piece of abuse ever perpetrated against the fundamental character of a programming language, and Rust isn't Go. It will be interesting to see, in years to come, whether moving to Rust does in fact lower Mozilla's defect rate.

    On the other hand, it does all seem more than a little CADT.



  • I think that Firefox simply has trouble with AMD video drivers. Or the other way around.

    This is also in Win8.0 with IE10, though.



  • @blakeyrat said:

    This guy paid real cash-money to work-around a bug in Firefox. Mock him.



    Seriously?! He bought a gf650 to replace his radeon card just so his Firefox browser would be usable? Does he not realize there are dozens of browser alternative that... well... don't suck?

    Even IE11 is better than Firefox at this point, now that they've implemented most of the useful features that Chrome & Firebug brought to the table.



    Maybe he's the focus group guy who wants his kitten videos. Wants them BAD.



  • @flabdablet said:

    @Lorne Kates said:
    AND THEY CALLED THEIR LANGUAGE RUST!  Why not "obsolete"?  Or "decayed corpse pile"?  AH! AH! AHHHHHHHHHH *poof*

    To be fair, though: Brendan Eich is a really smart guy, Rust looks fairly tidy, C++ really is the most horrendous piece of abuse ever perpetrated against the fundamental character of a programming language, and Rust isn't Go. It will be interesting to see, in years to come, whether moving to Rust does in fact lower Mozilla's defect rate.

    On the other hand, it does all seem more than a little CADT.

    I've never looked at Rust... but that's likely because it's by the guy who invented JavaScript, which I generally describe the same way you describe C++.

     


  • Discourse touched me in a no-no place

    @powerlord said:

    @flabdablet said:
    C++ really is the most horrendous piece of abuse ever perpetrated against the fundamental character of a programming language
    JavaScript, which I generally describe the same way you describe C++.
    Maybe that's because you're both right?


  • Considered Harmful

    @powerlord said:

    @flabdablet said:

    @Lorne Kates said:
    AND THEY CALLED THEIR LANGUAGE RUST!  Why not "obsolete"?  Or "decayed corpse pile"?  AH! AH! AHHHHHHHHHH poof

    To be fair, though: Brendan Eich is a really smart guy, Rust looks fairly tidy, C++ really is the most horrendous piece of abuse ever perpetrated against the fundamental character of a programming language, and Rust isn't Go. It will be interesting to see, in years to come, whether moving to Rust does in fact lower Mozilla's defect rate.

    On the other hand, it does all seem more than a little CADT.

    I've never looked at Rust... but that's likely because it's by the guy who invented JavaScript, which I generally describe the same way you describe C++.

     

    I've been using ECMAScript 6 (aka Javascript 2.0) for the past few weeks, and I have to say, I like the language a lot more now.



  • @flabdablet said:

    Brendan Eich is a really smart guy, Rust looks fairly tidy,


    Er... quoting from the Rust link "The let keyword introduces a local variable. Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence.



  •  I don't see any problem at all with having a globally-recognized, open-source project being programmed in a proprietary language.  It will attract the top talent for contributions.



  • @studog said:

    ... Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence.
    in python varibles are immutable by default, you can change what a varible 'points' ant, but the values are pooled and immutable.



  • @boomzilla said:

    @El_Heffe said:
    Firefox...somehow related to a problem with Internet Explorer 10

    Microsoft sabotaging Firefox, Russia usurping Eastern Europe...it's like history is going in reverse.

    I don't think it's deliberate sabotage.  There seems to be a recurring pattern of Firefox doing something that suddenly breaks things.

    For example, over the years I would just copy my Firefox profile over to a new computer or new OS install.  As a result, there was this one setting that referenced a directory that hasn't existed since I was using.Windows XP.  Then one day when I installed a new version of Firefox and got a weird error message, which I eventually tracked back to that setting, which Firefox had been happily ignoring for about 6 or 7 years.



  • @Lorne Kates said:

    OH HEY IT GETS BETTER GUYS!
    "Because C++ crashes when it runs into memory allocation issues, it weakens any browser that uses the language."

     

       It doesn't crash because we're shitty programmers.  It crashes because . . . . . uh . . . because  . . . . uh . . .  .   C Plus Plus!!



  • @El_Heffe said:

    @Lorne Kates said:

    OH HEY IT GETS BETTER GUYS!
    "Because C++ crashes when it runs into memory allocation issues, it weakens any browser that uses the language."

     

       It doesn't crash because we're shitty programmers.  It crashes because . . . . . uh . . . because  . . . . uh . . .  .   C Plus Plus!!

    Apparently catching std::bad_alloc is impossible.



  • @El_Heffe said:

    @Lorne Kates said:

    OH HEY IT GETS BETTER GUYS!
    "Because C++ crashes when it runs into memory allocation issues, it weakens any browser that uses the language."

       It doesn't crash because we're shitty programmers.  It crashes because . . . . . uh . . . because  . . . . uh . . .  .   C Plus Plus!!

    And what is the spiffy memory management scheme they are proposing for their shiny rusty new language that will allow it to continue when it can't get any more memory*?

    * Because the user is trying to load every Grumpy Cat video on Youtube simultaneously.



  •  @HardwareGeek said:

    And what is the spiffy memory management scheme they are proposing for their shiny rusty new language that will allow it to continue when it can't get any more memory*?

    * Because the user is trying to load every Grumpy Cat video on Youtube simultaneously.

    It will have a process known as "memory stealing," which is when memory from an overloaded computer is taken from another one 

     



  • @esoterik said:

    @studog said:

    ... Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence.
    in python varibles are immutable by default, you can change what a varible 'points' ant, but the values are pooled and immutable.

    Except in Rust you have to declare that you can change the assigned value of the variable whereas Python IIRC (and almost EVERY other language) you have to state that you cannot change the assigned value of the variable.

    If we look at the root of the word "variable," we get "vary" which means roughly "not constant", not "constant unless I tell it to not be constant."

    Also, who the hell calls functions macros? Who do they think we are? VBA "developers"?

     



  • @HuskerFan90 said:

    @esoterik said:

    @studog said:

    ... Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence.
    in python varibles are immutable by default, you can change what a varible 'points' ant, but the values are pooled and immutable.

    Except in Rust you have to declare that you can change the assigned value of the variable whereas Python IIRC (and almost EVERY other language) you have to state that you cannot change the assigned value of the variable.

    If we look at the root of the word "variable," we get "vary" which means roughly "not constant", not "constant unless I tell it to not be constant."

    Also, who the hell calls functions macros? Who do they think we are? VBA "developers"?

     


    The reason variables can only ever hold one value in Rust is so the entire program can be run at compile time, removing the need for processors on user-facing machines.



  • @studog said:

    @flabdablet said:

    Brendan Eich is a really smart guy, Rust looks fairly tidy,


    Er... quoting from the Rust link "The let keyword introduces a local variable. Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence.

    "Let" is being used there as a short synonym for "define". I don't understand why that's problematic.

    Or is it the apparent contradiction between "variable" and "immutable" that's bothering you? It shouldn't. "Variable" is long-established programming jargon for a name used as a placeholder for a value; using some other word for that thing would cause more confusion than it avoids. If a variable is immutable, that simply means that the value it identifies can't be modified in-place; but that doesn't stop any given immutable variable's name from identifying different values over the course of the program.

    Putting that another way: let x = 3 means "until further notice, x refers to some chunk of memory that holds the value 3." As far as I can tell (and I've never used Rust, just read the tutorial) there is nothing stopping you from following that at some point inside the same block with let x = 4, which makes any subsequent use of x mean something different. The name x is indeed a variable, in that it means different things at different points in the course of execution. If x is also immutable, though, you have an additional guarantee that the only way to make x mean something different is to do a new let for it: no other thread or function can change what's inside the memory you've made x a name for.

    Immutability is actually a very old pattern. There were FORTRAN compilers for machines such as the CDC Cyber series, whose architecture made loading constant values into registers very inconvenient, that created a presumed-immutable pool of constant values - one for each unique literal value in your FORTRAN program - and used the addresses of those in any machine instruction requiring access to that constant. With at least some of those compilers, immutability was poorly enforced and you could badly screw things up by passing a literal constant to a function as a parameter, then modifying the value of that parameter inside the function. FORTRAN passes parameters by reference, not by value, so if function FUCKUP(X) does X=99 inside and you invoke FUCKUP(2), you'd pollute the "immutable" 2 inside the constants pool, and any subsequent FORTRAN statement including the literal value 2 would behave as if coded using the literal value 99 instead.



  • @Ben L. said:

    @HuskerFan90 said:

    @esoterik said:

    @studog said:

    ... Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence.
    in python varibles are immutable by default, you can change what a varible 'points' ant, but the values are pooled and immutable.

    Except in Rust you have to declare that you can change the assigned value of the variable whereas Python IIRC (and almost EVERY other language) you have to state that you cannot change the assigned value of the variable.

    If we look at the root of the word "variable," we get "vary" which means roughly "not constant", not "constant unless I tell it to not be constant."

    Also, who the hell calls functions macros? Who do they think we are? VBA "developers"?

     


    The reason variables can only ever hold one value in Rust is so the entire program can be run at compile time, removing the need for processors on user-facing machines.

    That may be true, but still, why? If this was the time when Big Iron ruled the land I could understand, but nowadays my fridge has an embedded CPU so I don't see why this feature is necessary. It can be a royal pain in the ass if you have loads of variables that need to be able to be reassigned.



  • @flabdablet said:

    @studog said:
    @flabdablet said:

    Brendan Eich is a really smart guy, Rust looks fairly tidy,


    Er... quoting from the Rust link "The let keyword introduces a local variable. Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence.

    "Let" is being used there as a short synonym for "define". I don't understand why that's problematic.

    Or is it the apparent contradiction between "variable" and "immutable" that's bothering you? It shouldn't. "Variable" is long-established programming jargon for a name used as a placeholder for a value; using some other word for that thing would cause more confusion than it avoids. If a variable is immutable, that simply means that the value it identifies can't be modified in-place; but that doesn't stop any given immutable variable's name from identifying different values over the course of the program.

    Putting that another way: let x = 3 means "until further notice, x refers to some chunk of memory that holds the value 3." As far as I can tell (and I've never used Rust, just read the tutorial) there is nothing stopping you from following that at some point inside the same block with let x = 4, which makes any subsequent use of x mean something different. The name x is indeed a variable, in that it means different things at different points in the course of execution. If x is also immutable, though, you have an additional guarantee that the only way to make x mean something different is to do a new let for it: no other thread or function can change what's inside the memory you've made x a name for.

    Immutability is actually a very old pattern. There were FORTRAN compilers for machines such as the CDC Cyber series, whose architecture made loading constant values into registers very inconvenient, that created a presumed-immutable pool of constant values - one for each unique literal value in your FORTRAN program - and used the addresses of those in any machine instruction requiring access to that constant. With at least some of those compilers, immutability was poorly enforced and you could badly screw things up by passing a literal constant to a function as a parameter, then modifying the value of that parameter inside the function. FORTRAN passes parameters by reference, not by value, so if function FUCKUP(X) does X=99 inside and you invoke FUCKUP(2), you'd pollute the "immutable" 2 inside the constants pool, and any subsequent FORTRAN statement including the literal value 2 would behave as if coded using the literal value 99 instead.

    I think that we're caught up on the fact that it states that by default you cannot reassign the variable to anything else and that you must explicitly allow the variable to be reassignable AFAICT.

    If that is not the case, OK I am wrong. If it is, WTF? Old paradigms don't need to be used anymore for good reason.



  • @HuskerFan90 said:

    [...]nowadays my fridge has an embedded CPU so I don't see why this feature is necessary. It can be a royal pain in the ass if you have loads of vegetables variables that need to be able to be reassigned.

    FTFY



  • @HuskerFan90 said:

    @flabdablet said:
    @studog said:
    @flabdablet said:

    Brendan Eich is a really smart guy, Rust looks fairly tidy,


    Er... quoting from the Rust link "The let keyword introduces a local variable. Variables are immutable by default." The really smart guy doesn't understand the meaning of a basic english word. This does not inspire confidence.

    "Let" is being used there as a short synonym for "define". I don't understand why that's problematic.

    Or is it the apparent contradiction between "variable" and "immutable" that's bothering you? It shouldn't. "Variable" is long-established programming jargon for a name used as a placeholder for a value; using some other word for that thing would cause more confusion than it avoids. If a variable is immutable, that simply means that the value it identifies can't be modified in-place; but that doesn't stop any given immutable variable's name from identifying different values over the course of the program.

    Putting that another way: let x = 3 means "until further notice, x refers to some chunk of memory that holds the value 3." As far as I can tell (and I've never used Rust, just read the tutorial) there is nothing stopping you from following that at some point inside the same block with let x = 4, which makes any subsequent use of x mean something different. The name x is indeed a variable, in that it means different things at different points in the course of execution. If x is also immutable, though, you have an additional guarantee that the only way to make x mean something different is to do a new let for it: no other thread or function can change what's inside the memory you've made x a name for.

    Immutability is actually a very old pattern. There were FORTRAN compilers for machines such as the CDC Cyber series, whose architecture made loading constant values into registers very inconvenient, that created a presumed-immutable pool of constant values - one for each unique literal value in your FORTRAN program - and used the addresses of those in any machine instruction requiring access to that constant. With at least some of those compilers, immutability was poorly enforced and you could badly screw things up by passing a literal constant to a function as a parameter, then modifying the value of that parameter inside the function. FORTRAN passes parameters by reference, not by value, so if function FUCKUP(X) does X=99 inside and you invoke FUCKUP(2), you'd pollute the "immutable" 2 inside the constants pool, and any subsequent FORTRAN statement including the literal value 2 would behave as if coded using the literal value 99 instead.

    I think that we're caught up on the fact that it states that by default you cannot reassign the variable to anything else and that you must explicitly allow the variable to be reassignable AFAICT.

    If that is not the case, OK I am wrong. If it is, WTF? Old paradigms don't need to be used anymore for good reason.

    Variable (computer science), a symbolic name associated with a value and whose associated value may be changed

    It's fine to invent new things. That's called innovation. However, if I were to redefine the set of irrational numbers to {3, 50} to fit some crazy business logic, that would be stupid and I should have chosen a name that actually describes it. Just like calling something that cannot be modified a "variable".



  • @Ben L. said:

    Variable (computer science), a symbolic name associated with a value and whose associated value may be changed
    And Rust variables do allow that. Mutable variables allow it by letting you overwrite the memory associated with the name; immutable variables allow it by letting you alter the association. When using the variable as an rvalue, both implementations have the same end result.



  • @HuskerFan90 said:

    I think that we're caught up on the fact that it states that by default you cannot reassign the variable to anything else and that you must explicitly allow the variable to be reassignable AFAICT.
    You can't alter the value of the memory region that an immutable variable gives a name to, but you can alter the value of the variable by making the same name refer to some other chunk of memory that contains some other value. If I'm reading the tutorial correctly,
    fn main() {
    let mut foo = 2;
    println!("foo is {}", foo);
    foo = 3;
    println!("foo is {}", foo);
    }
    and
    fn main() {
    let foo = 2;
    println!("foo is {}", foo);
    let foo = 3;
    println!("foo is {}", foo);
    }

    will both compile correctly and display
    2
    3
    even though the second version uses an immutable variable. Note particularly that in both cases, variable foo holds the value 2 during the first println! statement and 3 during the second.



  • @Ben L. said:

    What's even more alarming is that I was able to reproduce the bug in Chrome after reproducing it in Firefox!

    Firefox is always copying Chrome.

     


  • ♿ (Parody)

    @HuskerFan90 said:

    Also, who the hell calls functions macros? Who do they think we are? VBA "developers"?

    I don't think you looked very closely. There are functions and there are macros. I'm not a Lisp expert, and I just skimmed the Rust stuff, but Rust's macros aren't functions, and actually seem similar to Lisp's macros. Or even similar to a C/C++ preprocessor.



  • @boomzilla said:

    @HuskerFan90 said:
    Also, who the hell calls functions macros? Who do they think we are? VBA "developers"?

    I don't think you looked very closely. There are functions and there are macros. I'm not a Lisp expert, and I just skimmed the Rust stuff, but Rust's macros aren't functions, and actually seem similar to Lisp's macros. Or even similar to a C/C++ preprocessor.

     

     

    from the documentation it looks like C/C++ preprocessor with limitations; only full expressions, explicit invocation



  • @ratchet freak said:

    from the documentation it looks like C/C++ preprocessor with limitations; only full expressions, explicit invocation

    Their final example involves breaking up a series of statements into individual expressions, so it's most definitely trying to mimic Lisp macros.
    That being said, it's such a horrifying soup of special characters I find it hard to believe someone didn't stop and go "What the fuck are are we doing?" when they came up with the idea.



  • @HardwareGeek said:

    And what is the spiffy memory management scheme they are proposing for their shiny rusty new language that will allow it to continue when it can't get any more memory*?

    [code]
    int allocate_mem(int bytes):
        try:
            return sys.allocate_mem(bytes);
        catch NoMemoryException:
            sys.killAllProcesses("chrome.exe")
            return sys.allocate_mem(bytes)
    [/code]

  • Discourse touched me in a no-no place

    @Ben L. said:

    Apparently catching std::bad_alloc is impossible.
    No, but working out what to actually do about it is generally pretty hard. Well, assuming you want a reasonable chance of continuing to operate. Yes, with large allocations it is reasonable to trap that and instead pass a soft failure back up the stack, as it's quite possible that the failure really is the current process/thread's fault, but with small allocations there's really not much you can do. It's quite possibly someone else's fault and you've not got anything left to allocate to recover with. You could keep an emergency stash of memory around, but then you might as well use it before running out.



  • @dkf said:

    @Ben L. said:
    Apparently catching std::bad_alloc is impossible.
    No, but working out what to actually do about it is generally pretty hard. Well, assuming you want a reasonable chance of continuing to operate. Yes, with large allocations it is reasonable to trap that and instead pass a soft failure back up the stack, as it's quite possible that the failure really is the current process/thread's fault, but with small allocations there's really not much you can do. It's quite possibly someone else's fault and you've not got anything left to allocate to recover with. You could keep an emergency stash of memory around, but then you might as well use it before running out.
    Exactly. Detecting the memory allocation failure is easy. Continuing to run despite the failure is easy; just don't do whatever operation you needed the memory for. Doing something useful when you don't have enough memory to do it is the hard part. I'd still like to know how they think Rust sill solve this.
    @Firefox Developers said:
    Because C++ crashes any application tends to fail when it runs into memory allocation issues, it weakens any browser that uses the any language.
    FTFMozilla


  • ♿ (Parody)

    @HardwareGeek said:

    Doing something useful when you don't have enough memory to do it is the hard part. I'd still like to know how they think Rust sill solve this.

    I suspect you guys are reading too much into some blogger's misunderstanding of what Rust is supposed to do. From the rust home page:

    @rust-lang said:

    Memory safety: no null or dangling pointers, no buffer overflows


    Memory model: optional task-local GC, safe pointer types with region analysis

    I don't see anything there about helping you deal with low memory stuff like everyone is fixated on. These features are meant to be a step up from dealing with memory in C++, and based on the descriptions, I believe it. Seems like most new languages have this sort of thing.



  • @boomzilla said:

    I suspect you guys are reading too much into some blogger's misunderstanding of what Rust is supposed to do.
    A lot of people (including me, at first) missed the fact that the linked article is not directly from Mozilla, but some person writing about the new rusty programming language that will be used to create a new rusty web browser. However, when they say something like:
    Its big selling point is efficiency. Because C++ crashes when it runs into memory allocation issues, it weakens any browser that uses the language. Mozilla designed Rust to be superior to C++ this way, more easily isolating tasks and promote a process known as "work stealing," which is when tasks from an overloaded processor are shifted over to another one.
    You would probably assume that the person isn't just pulling that out of their ass, but repeating something that was told to them by someone from Mozilla.


  • ♿ (Parody)

    @El_Heffe said:

    You would probably assume that the person isn't just pulling that out of their ass, but repeating something that was told to them by someone from Mozilla.

    Heh...that page apparently lets you record a reaction to each paragraph. That one is overwhelmingly "not entirely accurate." The Gell-Man amnesia effect should work in our favor here, calling BS on something a reporter said about a programming language, though I suppose most people here aren't terribly intimate with C++ (and good on them).



  • @boomzilla said:

    Heh...that page apparently lets you record a reaction to each paragraph. That one is overwhelmingly "not entirely accurate."
     

    WTF?




  • @boomzilla said:

    @El_Heffe said:
    You would probably assume that the person isn't just pulling that out of their ass, but repeating something that was told to them by someone from Mozilla.

    Heh...that page apparently lets you record a reaction to each paragraph. That one is overwhelmingly "not entirely accurate." The Gell-Man amnesia effect should work in our favor here, calling BS on something a reporter said about a programming language, though I suppose most people here aren't terribly intimate with C++ (and good on them).

    Correction:

    You would probably assume that the person isn't just pulling that out of
    their ass, but repeating something that was told to them by someone
    from Mozilla - who pulled it out of their ass.



  • @El_Heffe said:

    You would probably assume that the person isn't just pulling that out of
    their ass, but repeating something that was told to them by someone
    from Mozilla - who pulled it out of their ass.
    I would assume there are a lot of asses at Mozilla.



  • @HardwareGeek said:

    @El_Heffe said:
    You would probably assume that the person isn't just pulling that out of their ass, but repeating something that was told to them by someone from Mozilla - who pulled it out of their ass.
    I would assume there are a lot of asses at Mozilla.
    More than 500, according to their LinkedIn page.



  • @flabdablet said:

    "Let" is being used there as a short synonym for "define". I don't understand why that's problematic....

    Putting that another way: let x = 3 means "until further notice, x refers to some chunk of memory that holds the value 3."

    This is why some people should not be allowed to create computer languages. In my industry, "let x = 3" would be interpreted as "3 is an allowable value for x" and wouldn't say anything about the current value of x.

    If you want to set a value, the language should be something like set x = 3 which is astonishingly less ambiguous.

    Put another way: anyone that thinks "let" is a synonym for "define" has serious linguistic issues.



  • @too_many_usernames said:

    @flabdablet said:
    "Let" is being used there as a short synonym for "define". I don't understand why that's problematic....

    Putting that another way: let x = 3 means "until further notice, x refers to some chunk of memory that holds the value 3."

    This is why some people should not be allowed to create computer languages. In my industry, "let x = 3" would be interpreted as "3 is an allowable value for x" and wouldn't say anything about the current value of x.

    If you want to set a value, the language should be something like set x = 3 which is astonishingly less ambiguous.

    Put another way: anyone that thinks "let" is a synonym for "define" has serious linguistic issues.

    I agree that set x = 3 is preferable to let x = 3, however, syntax like let x = 3 has been around for a long time. I seem to remember it being in some languages such as BASIC many years ago and everyone has always understood that let is the same as set.  To me it has always seemed like just another case of "we want to be different so our language will use let instead of set."

     



  • @El_Heffe said:

    ... syntax like let x = 3 has been around for a long time. I seem to remember it being in some languages such as BASIC many years ago...
    It was definitely in BASIC in the 70's. I thought it had died a well-deserved death almost that long ago.


Log in to reply