hot take:
documents should never have an embedded turing-complete language that runs automatically or without the informed consent of the user.

Follow

@impiaaa @enkiv2

from the number of security exploits in it, yeah, maybe not a bad idea

8x8 pixels are enough for anyone (except China, Japan and Korea)

@natecull @impiaaa
At the very least, I think "monospace is enough or anyone".

Kerning hinting can make things look pretty, but it trades accessibility, implementation complexity, and a literal vulnerability to do it.

Your webfonts could be mining bitcoins.

@enkiv2 @natecull "look pretty" means better legibility, which means better accessibility. and I didn't think it was just kerning hinting, I thought it was all hinting (in which case monospace would still need it).

@impiaaa @natecull
People make claims about the legibility of dynamically spaced vs monospace typefaces, but I've never been able to see it. Maybe I've just used well-designed monospace typefaces. (I've seen poorly-kerned barely-legible dynamically spaced types, of course. We all have.)

Monospace means words are visually consistent, at least.

@enkiv2 @natecull I'm not talking about the legibility of monospace vs. not. I mean, a poorly hinted typeface, monospace or not, will look bad at small sizes, which means it will be harder to read. I'm sure there are ways to do hinting that don't need to be Turing complete, but you don't need to jump to conclusions and say that we need to ban all typefaces you don't like.

@impiaaa @natecull
I'm having a hard time figuring out what hinting would be used for that could conceivably require a turing-complete language other than kerning.

Scaling is a difficult problem, but it's not typically done fully procedurally for all sizes, is it?

@impiaaa @enkiv2

It seems to me that 'Turing-complete' shouldn't be a HUGE problem if we can ALSO enforce resource usage limits on any jumping-type construct.

So we can know right from the start 'this can't take more than X cycles to run or use more than Y memory cells'.

Are there languages which do that?

@natecull @impiaaa
Yeah. Javascript in the browser.

Hence, when the javascript in our pages is slow and takes too many cycles, we get a slow laggy pop-up window too, asking if we want to try to kill a thread (with a 2% success rate).

Obviously, it could be done not-stupidly. Not aware of anybody who does.

@enkiv2 @impiaaa

Well, I mean at the LANGUAGE level, not the USER INTERFACE level.

Thinking something like Margaret Hamilton's Universal Systems Language, which seems to basically just put resource bounds on all recursion-type constructions. Any function call is a process and has a finite resource pool that its subfunctions inherit, etc.

Her stuff is probably optimised for missiles, not web browsers, and also maybe we did manual RAM allocation in the Mac/Amiga/DOS days and it was terrible.

@enkiv2 @impiaaa

and then we get:

user wants to pump 100 gigabytes through one browser pane because it's a streaming ultra high-def TV series they're binge-watching

ad company wants to pump 100 gigabytes through the same browser pane but user considers this malware

ad company considers the user's ad blocker to be malware...

@natecull @impiaaa
Yeah, I think we could do that too.

(The javascript thing is basically a UI manifestation of an underlying attempt at user time limits.)

Unix also natively supports this kind of quota. Processes are killed when they overstep some bounds.

@enkiv2 @impiaaa

It's like we need quotas at a finer level of granularity than 'process', though.

Erlang in the Browser, maybe?

@natecull @enkiv2 @impiaaa I would make the argument that any running code that you didn't bless should run in its own process. Isolation within a process has proven to be monstrously difficult because hardware is only designed to isolate code at the process level.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!