javascriptlol

You are completely misunderstanding me. I am not saying "let's all move to this new utopian system". I am suggesting that we move away from the idea of making universal systems entirely. Write software that is small enough that complete rewrites can be accomplished without trouble. The current situation is to build ourselves a problem that gets harder and harder to undo as time goes on.

You can't call something that's been around for less than 100 years "tried and true". I'm not saying we can't have "virtual CPUs" for tasks that can handle a performance hit. But it is becoming an unavoidable impediment. "Simple" doesn't mean "easy". It means predictable, small and undoable. The exact opposite to where we are heading.

Thanks for the link. I will check this out later.

>Can you imagine not having Unix-like systems, and not being able to use C and all the languages built around that ecosystem?

Yes! Charles Moore has been essentially living this since the 1970's. No many have his level of courage though.

Why would you be moving data between cores? I'm talking about an arrangement where each core is dedicated to a single program. No sharing of memory, even via the kernel. Each hardware devices talks to a single core only. Multiplexing of hardware would be done in.. hardware. For all intents and purposes the "core" could be out on the network.

All this throughput nonsense is benchmrk lies. Websites are not as a general rule highly responsive. They have huge variability in response times. Who cares if it costs a bit more to run the system if it means having a nice predictable system built for simplcity and safety from the ground up?

Also, this paper suggests that the answer to multi-tasking problems is to move the complexity out into the language. It's funny how PL researchers will always spin the situation so that it demands more PL research. If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching. Of course, you'd need a simple system and not a billion daemons running in the background waiting to be exploited by criminals.

The problem with systems design is that it's all so complex. Multitasking has become an excuse to run everything as some absurd daemon. Badly designed hardware has to be papered over with undocumented binary drivers. Everything is optimised for throughput benchmarks, so we get warm ups and unpredictable pauses visible to the user. And it's all full of security holes.

The plain truth of the matter is that none of these things are due to a lack of special language support. It's that the whole system is too complex, and the complexity isn't even quarantined in such a way as to be harmless. We need to be able to start over (something the author acknowledges). We can't do this if we build yet another complex system in the belief that we'll get it all right this time round.

"Only C"? What about Forth?

Notice how the posts that are downvoted have no replies, because the downvoters cannot argue their case. How sad.

You haven't made any technical points. You just waffled nonsense about scalability. I see you're bowing out of the argument because you have no case. Once you have interrupts on a platform, you have polling. If you're stuck with polling you can't recover interrupts. Which is why we have websockets decades late. The truth is there is not tension between interrupts and polling. Interrupts are plainly superior, since you can opt out of them trivially. But the platform should not opt out ahead of the developer. This turns out to be inadequate, so we get polling implemented inside interrupts and then a separate mechanism for interrupts. And the interrupt driven stuff has stupid reload buttons and so forth on the GUI. It's dumb engineering because increases complexity and leads to bad results for the user. You have no case. Polling is dumb. And if you think software engineers ever needed "good reasons" to add a bunch of pointless complexity to things, then you simply have no clue on the history of software development.

It fits most cases.. except that web applications are _constantly_ polling for information. Which may be fine, but you can implement polling with interrupts. What part of that do you not understand? Are you aware that the OS is using an interrupt-driven system to poll the server? It's just hidden from you, so you have no choice. This is just dumb engineering. And to say that it's good for "most things" is just lazy thinking. "Most things" are that way precisely because of the crappy architecture. Rationalisations.

I might agree with this statement if the web had produced anything like a "conventional UI" that is consistent. Every website is completely different. Just look at Facebook. This is a horribly confusing website and most of the features are the kind of self-justifying nonsense I'm talking about. Nobody wanted Facebook until Facebook came along and convinced people to turn photo/comment sharing into a sterile game.

People should simply design something small that satisfies a niche. If it doesn't have enough features for some person, rewrite it. When software is small you can rewrite as much as you want. Software engineers labour in the delusion that their creations are so fantastic and amazing that it can only accomplished through huge complexity.

So do you have any technical points to make, or just more dumb excuses? If you don't want interrupts, you just use them to implement polling.

So, WebSockets are a mistake then?

It's lazy when your platform still has mandatory polling decades after interrupt driven programming was invented.

Stop making stupid excuses. The fact that some people might get confused by some detail (like your iPhone alarm example) does not change the fact that some some other things are idiotic (like the refresh button). And your take on the refresh problem shows why this whole thing is a complete mess: I'm not suggesting "universal" auto-refresh. This is why the browsers is such a failure technologically: people want to try to solve all the problems in the platform instead of just providing simple, powerful primitives. As you recognise we need to restrict scope. The only software that actually works is simple and small. And I'm not just "admonishing others". I dropped out of academia and industry and moved into a cheaper neighbourhood to be independent so I can write the simplest software possible. To me that's better than empty talk about "UX" and other modernistic double-talk about how hard we've got it. And having an independent perspective, I can see that it's rationalisations all the way down. We will have botnets etc forever until people tackle the problems as a basic level by simple designs that eliminate the problems. But people can't even conceive of putting ethics before their own financial well-being because as an industry we have no ethics. Just pride in spreading our bullshit around as much as possible.

If software engineers built bridges we'd make it drive up and down the river, put in a few houses to be "efficient". And then when the thing breaks down we'd complain that it's "too hard". No shit it's too hard: because we promise more than we can deliver, hiding the risks and problems from the user. Firefox has as a feature in every version the ability for criminals to install rogue programs on your computer. And yet you won't see this in their marketing material. This is a solved problem. We know how to eliminate memory-safety problems, but Mozilla would rather take N years to do their rust rewrite (if it even happens) because it's in their self interest. If we had any ethics as an industry Firefox would come with a warning that it makes it possible to install rogue programs on your computer. But it won't.

<blockquote>Automatically replace the copy I'm reading with the update, simultaneously removing my ability to ever get back to the version I was reading?</blockquote>

This is an asinine example. Why would the author do this except to correct typos or update the kind of information you want updated? Who are these nefarious authors trying to destroy your reading experience? They don't exist, and this kind of lazy thinking is why it took until very recently for browsers to even have the possibility of auto-update without polling (hello 1970).

Software is too complicated. Now that we have a generation growing up with computers software engineers are happily brain-damaging them into expecting hugely complex software that doesn't really work. The browser is the perfect example. Why can the user manually reload a page? Shouldn't it all update automatically? The answer is: it's that way because it was convenient for lazy designers a long time ago and nobody bothered fixing it. And it will be rationalised as a good decision now that people have been damaged into thinking it's a good thing. What's there has blinded people to what is possible. Don't let people fool you into thinking that there are good reasons why we ended up with, say, C instead of Forth. It's all rubbish. We've become a field of charlatans.

Better to be a bit of an unfair bully than to do sit around while parasites send the industry down the toilet. It's like chemotherapy: sometimes you have to hurt the body to kill off the cancerous cells.

I don't know why I'm being downvoted for a simple question, but my point was that I don't see how this it's ever going to be possible to demonstrate that these things are safe. Our ancestors ate game meat, not farm meat. And now people want to grow it in a lab? I'm not saying we can't make a trade-off here, but people focus on the things they can see and ignore the unknown (in this case, the health effects of eating a new kind of processed food).

What a narrow-minded position. RMS is mostly harmless, has brought some good things into this world, and provides a reliable reservoir for a particular set of ideals. Nobody has to agree with him for him to be useful. He's operating within the confines of the law. He is not trampling on anyone's rights. He is worth 100 people who just compromise everything away for short term gain. He's like Ron Paul; kind of a nutter, but a necessary antidote for these times.

How are you going to ensure that "lab-grown meat" is not going to lack something important contained within farm grown meat? We already know that the composition of the meat changes depending on what you feed the animals. What about micronutrients we don't know about? Man has not supplanted nature in cleverness.

Oops. In the above I said the system shouldn't pause ever. This is silly of course. What I meant to say is that it shouldn't pause except when hit with hard resource limits. Loading from the disk or performing an expensive calculation will take some time of course. But there shouldn't be random pauses when interacting with something that ought to be fit into memory. Modern systems are full of pre-emption, GC pauses and other non-determinisms.

>That's not quite true. People do in fact do CPU intensive stuff in browsers, if nothing else because they write algorithmically slow code.

It's CPU intensive because of the way it's done, not because it intrinsically requires much CPU. That was my point. And it's not just algorithms; everything goes through a million layers of abstraction.

>Note that GMail is not an example of an application that really does intensive JS. A photo editing app would be a better example.

Again, I was doing photo-editing years ago with no troubles. You wouldn't even be able to start your JS photo editing app on a 1996 computer. And by focusing on "CPU-intensive" tasks you're missing an essential point, which is that stuff that shouldn't require any CPU does. My system shouldn't pause - ever. We have optimised everything for high throughput on powerful machines. The JVM suffers from exactly this problem. Java is plenty "fast" if you ignore latency.

There's just nothing demanding enough to require that going on. And yet the UI locks up for 1-2 seconds pretty frequently on my $1000 desktop machine with loads of RAM and CPU. It's even worse on my $400 laptop. There's nothing intrinsic in the hardware or the tasks that should cause this to happen - it's the design of the software. It's because the system is too complex and preemptable that this happens.

You and I are starting from different assumptions. I want to throw out the DOM. It is an application-specific component that should be implemented in "user land". Currently we're heading toward C inside JS inside Rust, with plugins written in C++ running outside any sandboxes. This is never going to be secure. You have to design a VM that everything can sit in. There's no reason why a browser can't sit inside a simple VM except that it builds in huge amounts of complexity regardless of how its used.

We don't need a VM to run JS "well". Nothing going on in the browser is even CPU intensive if not for the huge gobs of complexity going on. People are making simple things harder and harder to do, and complex things easier and easier. If you just write everything for a simple typed VM you don't have to bend over backward to make things run fast. There's nothing going on in the client side of say, GMail, that I couldn't do (faster!) on the computer I was using in 1997.

I wasn't clear. I wasn't meaning to suggest that Chrome were going to move away from C++. But they are trying to sandbox using NaCl and other mechanisms. I was aware of the Rust effort, but not that they were going to implement more of the DOM in JavaScript (thanks!). Maybe there will be more security-by-design.

I also think JavaScript is a bad basis for a platform in any case, since it requires loads of complexity to be fast. Why not just a simple typed language or VM? I have read some JS JIT papers and they have found plenty of code generation bugs (more security holes).

Given that Mozilla aren't willing to redesign their browser to eliminate the recurring flaws, I find it implausible that they're going to go for a balls-out JavaScript-all-the-way-down approach. The way it's going now is more C++ code to do specialised tasks with a bit of scripting on the front. Is stuff like Emscripten getting us closer to a half-way decent design? It seems like this is all just enabling more complexity. Now we'll have C code compiled to JavaScript compiled to machine code.

I like Embscripten and so forth for hack value, but this is a terrible way to build systems. I mean, people want sandboxed code in the browser, so why not make the whole browser sandboxed? Because nobody cares enough to put the effort in, I guess. Chrome is the only browser going along these lines and Mozilla is doing its best to hose down that effort because it just might allow people to program for a simple portable VM instead of all this application-parading-as-a-platform web standards stuff.

HTML5 is critically dependent upon hardware acceleration. So anything that can't be hardware accelerated wherever the games are running will be slow. If your drivers are bad it will be slow. The next step will be people creating ridiculously complex JIT setups just to get back somewhere near native throughput. Note that is _throughput_, not latency. Every layer of abstraction adds more unpredictable pauses and non-reproducible glitches. All so people can slap together the next Angry Birds clone with zero technical artistry.

>It was hard for me to write them off as people who just didn't understand how modern computers work.

I'm glad you didn't fall for that trap. Software engineers constantly make excuses for doing things in idiotic ways. Almost nothing I use really works anymore. It just "kind of" works most of the time. Look at your average web applicaton and the ridiculous resources it takes to get the thing up on the screen and interacting with the user. We've become addicted to high powered machines and finding more complex and inefficient ways of doing the same things.

And then we'd have had people writing applications that Lisp isn't suited for complaining at what could have been if only we'd gone with a simple register architecture. Don't get me wrong - I believe in owning the whole stack, and I'd love to see some Lisp machines. I fully believe that something like this may reappear in the future. But let's not kid ourselves: none of these singular visions of simplicity is going to be good enough for everything.

I don't see the connection between Lisp machines and JavaScript. JavaScript (in the browser at least) is a heavy-weight C++ system utilising huge amounts of library and operating system code with some weak scripting capabilities a the bottom. What relation does that have to Lisp machines or Smalltalk type environments where everything is built in a simple an transparent manner?