Previous years it didn't have any. Where as IE and Mozilla did. Every year. Chrome just happens to have the best one. And it gets tighter every year. It helps that both that event and google itself are giving out a lot of money to try and attract people that can find holes in even the most stable stuff. Google itself has put in 1 million dollars (total) this year to give out to people finding security bugs in Chrome.

Not to say you shouldn't fo that if you're doing it for fun, but the question is: why?

By all means learn the principles, but don't get hung up on the details. Modern CPUs are very different from the old 16-bit 8086.

You said: "Anyone could for example write a program that uses all your GPU power for computing (bitcoin mining for example)".

How is that a problem? since programs are being downloaded, one could download a program which uses all the available CPU power too. So, it is not a security problem. Even now, a Javascript program can have an infinite loop in it. I do not see how it is a security problem, if right now it is not a security problem for the current technology.

Not at all. You will get all your answers, do not worry. Please don't fall into the "axilmar avoids answering certain questions" trap, which has been laid primarily by the owner of allegro.cc because he regularly had his arguments beaten by me.

I am using Firefox on a daily basis, and I see native and non-native controls all the time. I am not avoiding the question, I wanted you to see that the problem is already solved. But since you asked, here is the answer: through the proper abstraction of the underlying GUI system, which will be an API the downloaded programs can call to interact with native controls. Actually, the abstraction layer between the O/S and the downloaded program will cover not only GUI, but anything else necessary for writing interesting applications.

Nope. I said "stored in the browser". The question was "where would the library be stored?", and my reply was "in the browser". Putting the two together, it says "stored in the browser", which is totally irrelevant to being shipped with the browser.

You do understand me correctly. See? It's not that I cannot explain my ideas! :-)

The library would already be cached locally by the browser. A solution for this problem would be to have browsers ship with a standard library, which will be chosen in case the computer is offline and the imported library is not cached locally. The imported library would have priority over the one shipped with the browser, i.e. if the imported library is cached locally, it would be the one to be used.

Furthermore, there would certainly be different implementations, so, unless they all go offline simultaneously, there wouldn't be a problem. URLs can be redirected at DNS level.

A disclaimer about security: I am not implying I have all the security problems solved by what I am saying in these pages. These ideas rely on evolutions, which come from discussions by many people. My opinion is that a security "system" must be "invented" that covers all the possible security breaches, so as that we should be free to develop interesting applications and not worry about security. Perhaps it's not possible to do so, but thinking about it does no harm.

It's not important. What is important is that you have a reason to do what you do, that you've thought about what you're doing and know why you're doing it.

But that's not what I meant: why are you using an emulator to learn about assembly language for an obsolete architecture?

There are good and valid reasons for doing that, but be sure that your reason is one of those. If you want to learn something that you can directly use to program in assembly language on modern hardware on a modern operating system then this is the wrong way to go.

Largely irrelevant. Those languages are all very similar and it doesn't matter much which one you pick up first. Though I wouldn't start with C++ myself, that may just be because I didn't.

So the question is: why are you trying to learn a particular language? I picked up Perl not for the heck of it, but because I wanted to post-process lots of data stored in text files and was getting sick of using a mix of bash shell scripting, sed and awk. Let alone writing custom C (or FORTRAN) programs to do it. Perl is a much better tool for that job.

Python is a more modern language that could do the same thing, and I did try both Perl and Python and found that I prefer Perl (in fact, I tried Python first). I'm sure I could have done it in Ruby if I wanted to, but it doesn't have the userbase and community that Perl and Python do.

Bottom line: it comes down to why are you learning a particular language? It doesn't matter so much which one you pick, but make sure you know why.

Are you sure you understood the questions?

Never heard of him. Doesn't matter who he is either, since the position he holds doesn't say anything about his ability to write a good book about a language (but it looks good in the blurb on the back cover).

You should ask yourself why they do this.

Ultimately you learn a programming language by using it, and you learn more as you go along. You do not learn to use C++ by using about all the different ways in which it can do the same thing in a book.

Why?

The languages I use most are C, FORTRAN and Perl. I own one book on Perl, the introductory one (the "llama"), if I have use of a more advanced feature I use google or perldoc. I own one book on FORTRAN that I only ever open to remind myself of the edit descriptors. I have two books on C, but I hardly ever use either of them. I have them mainly because I like having a hardcopy reference if I ever need it. Again, you do not learn a programming language by reading about it in a book.

So once again, by all means do what you want to do, but make sure you have a sense of why you're doing it.

Work, what else? A significant fraction of academic production software is written in FORTRAN.

FORTRAN 90 isn't that bad. Ofcourse a lot of code you find is written in FORTRAN 77 with coding conventions that date back to the 70s...

Let's call it Coffee!

What?!!??! You can use any register for a data pointer, you can multiply immediates and any register, you can use (simple) multiplication within an offset expression, you can push/pop all the registers at once, I'll stop now.

It's not what you're used to. I'm not used to it either, but "move <this> (to) that" is just as logical as "let (this) equal (that)".

The clobber list is to tell GCC which registers you're "clobbering", it's not strictly assembler at all. MASM simply saves everything (or lets your code crash) instead of trying to be efficient about it.

But you don't know if a particular register needs to be saved or not, so you're possibly wasting cycles etc. The clobber list says "I need this, this and that, do whatever optimizations you can while honoring this".

{"name":"Q5MlQ.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/b\/0bcc3605e17e942320de8f6c0592c726.gif","w":320,"h":233,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/b\/0bcc3605e17e942320de8f6c0592c726"}

Flat memory model.
Protected mode vs. real mode.
Extra registers.
Different number of cycles used for instructions.
Pairing of instructions for concurrent execution.
Not to mention, simd instructions are rather relevant to programming on modern hardware.

Sure, some of those you don't necessarily need to know immediately, but it still means you'll need to watch out for picking up bad habits.

Not that I know of. I don't work on entertainment.

The difference is that the browser will provide a much lower level API to the downloaded program, allowing much more versatility and expandability that the current model.

More flexible? it's not more flexible. Try to make the world accept a new tag, and it would be years before it is adopted.

What we have now is a lot less flexible than what we could have.

A programming language can support those more suitable formats by providing the appropriate literal forms.

I already told you: a) incompatibilities between browsers, and b) the slow development of the standards.

What I propose is a subset of what we currently have, but it's a more powerful one, allowing more and better abstractions to be built. Those abstractions are not possible with the current model.

Not all browsers support those things though. And there it goes: the incompatibilities between browsers mean a lot of extra work to make your web application available to the masses.

Exactly. With my idea, one could do his own font rendering without being masochist.

You can, but with hacks. The javascript import statement imports names, properties, objects and functions of another script, but javascript does not have a module loading system.

I want a proper API for my downloaded application. As it is right now, js programs cannot even write to a file without using custom browsers extensions.

For fucking good reason. When I visit your Web site it better not affect my computer in any fucking way.