erikj

Why do you think I mentioned the autocompletion facility? Shell users won't have to type any more characters than they do now. Please give Genera a try in the emulator to see how it would work with your own eyes, it's nothing like COBOL.

My ideal modern terminal would be pretty much a reimplementation of Symbolics' Listener: https://youtu.be/o4-YnLpLgtk?t=1m46s

- A presentation-based UI, where every on-screen element is always linked to the data it represents: https://dspace.mit.edu/handle/1721.1/6946

- A powerful autocomplete that knows about possible keywords and arguments, and can list them in a graphical fashion (e.g. a drop-down menu).

- An ability to use any previously displayed data as input to a new command just by clicking on it, with the UI highlighting only the things than can be used as valid input to the current command.

- Embedding of images and arbitrary UI widgets.

- Sensible names for commands and their arguments, i.e. "Delete File" instead of "rm", and ":Output Destination File /home/erikj/log" instead of "> /home/erikj/log". This makes a lot more sense with the enhanced autocompletion facility than the current 70s style cryptic Unix two-letter commands that were employed because of the hardware limitations. It would be easier to learn and less prone to errors.

Something as simple as tagged memory becoming a standard feature of the dominant CPU architectures would be a huge step forward for computer security.

There was no Airline Industry Winter or Software Winter either.

What's wrong with Tk, exactly?

Can any of them be used without binary blobs?

The same thing is happening in Firefox.

Apple even considered licensing the NT kernel before the acquisition: http://lowendmac.com/2013/the-rise-and-fall-of-apples-gil-am...

There were 1150x900 monitors in 1983: http://www.textfiles.com/bitsavers/pdf/symbolics/3600technic...

You can access Canvas in WebAssembly, no problem here.

Common Lisp is big because it's a bridge between MacLisp and InterLisp communities of the 80s. There are much smaller (and just as powerful) Lisps like Scheme or ISLISP.

Intel's Larrabee actually ran FreeBSD with a proper filesystem and everything. You could telnet into your GPU, install your own API implementation, pretty cool stuff: http://tomforsyth1000.github.io/blog.wiki.html#%5B%5BWhy%20d...

No, it's still using Valve's fork of that old library (Ipion Virtual Physics) that's referred in the documentation to as VPhysics.

"50 million cigarette smokers can't be wrong!"

Source 2 is another matter altogether. Valve doesn't share it with third-party developers at all, whether you pay or not. There were plans back in 2015 to make it free with the condition that any game made with it has to be published to Steam non-exclusively, but that still hasn't happened yet.

$25,000. Valve doesn't distribute Source without it, as far as I know. Replacing Havok would take a lot of effort which is better spent elsewhere.

Source is pretty expensive due to the mandatory Havok fee.

Rigetti Computing has a Github repository with a reference implementation for their quantum virtual machine and other stuff: https://github.com/rigetticomputing

Python lacks the most important feature of Common Lisp - defmacro.

It's you who should take the "No true Scotsman" card back.

I'm not sure if a country as large as the US can faithfully emulate Denmark.

It's a shame they don't have parents who actually lived in the Soviet Union.

You can use embedded Prolog to implement type inference in your compiler. AFAIK that's how it's done in the Rust compiler.

Were there any successful attempts to design a brand new and complete OS API in the last decade?

ARM chips have a much higher production volume so they are going to be much cheaper than RISC-V chips, at least for the foreseeable future.

So WD is switching their hardware to in-house designed processors after purchasing a RISC-V developer, do I understand this press release correctly?

Too often frameworks end up also changing the grammar, but doing it in a clunky unnatural way, shoehorning it into the language with tons of boilerplate code that could have been eliminated with a few simple macros.

I don't know, where?

As long as there is an always-on CPU with non-permanent firmware that has access to the microphone in my device, Fort Meade will find a way to hijack it and subvert this security model. I would rather not give them more attack surface.

Always-on Siri is a very creepy feature, and who even needs it in a "Pro" workstation?