jmz92

I'm curious: how would the achievement gap change if all or most post-secondary education was delivered online instead of at physical colleges/universities?

The point isn't that she didn't learn to study. If you had read just a little bit farther, you would have seen the real reason: at the first minor setback she met, she began to question whether she really belonged at a prestigious four-year school. That's a pretty understandable reaction given the culture shock she experienced in going to UT. Rich people with educated parents get to feel like they belong at colleges; poor and working class people don't.

Regarding your comment on an "FPGA backend" for GCC, you have to understand that simulating a VHDL design (what is implemented) is a drastically simpler task than synthesizing an FPGA image. Logic optimization, place and route, timing analysis--these are things entirely out of the scope of the GCC project, and the details differ significantly between FPGA vendors and between an individual vendor's products. It just isn't a realistic goal.

I was two blocks away at Stubb's when this was going on, and I walked through that area many times already during SXSW. I very rarely realize how fragile my life is, but events like this make it real.

In a couple years or so, my bet would be on Rust.

The big difference from my perspective is that Atom isn't currently FOSS. Other than that, the maturity of the emacs ecosystem is both one of its greatest features and a bit of a curse.

LLVM intermediate representation and Mill code are going to be pretty different. The LLVM machine model is a register based machine (with an arbitrary number of registers--the backends do the work of register allocation). Basically, an easier RISC-ish assembly.

So, while LLVM would be helpful for porting things to the Mill, as it's largely a "solve once use everywhere" problem, it's still not trivial. It could take a lot of effort to make it competitive.

"Interesting, the architecture looks greatly simplified compared to even standard RISC"

Depends on how you define simplicity, really. Writing a good back-end for this architecture is likely to be very challenging.

Some of the memory ideas are similar--Itanium had some good ideas about "hoisting" loads [1] which I think are more flexible than the Mill's solution. In general, this is a larger departure from existing architectures than Itanium was. Comparing it with Itanium, I doubt it will be successful in the marketplace for these reasons:

-Nobody could write a competitive compiler for Itanium, in large part because it was just different (VLIW-style scheduling is hard). The Mill is stranger still. -Itanium failed to get a foothold despite a huge marketing effort from the biggest player in the field. -Right now, everybody's needs are being met by the combination of x86 and ARM (with some POWER, MIPS, and SPARC on the fringes). These are doing well enough right now that very few people are going to want to go through the work to port to a wildly new architecture.

[1] http://en.wikipedia.org/wiki/Advanced_load_address_table