freenode/#lisp - IRC Chatlog
Search
7:56:06
MichaelRaskin
Browsers are kind of modular, but in your classification most of the complexity is just one part, Web APIs. Then there is CSS. Then there are some small and nice additional modules.
7:56:52
MichaelRaskin
And of course modern browsers try to do Web API implementations kind of modular (however they are eventually brought together), but it is a huge mess just by size
8:01:10
MichaelRaskin
Well, CSS might just be a small number of huge modules that are hard to modularise further, and in Web APIs there are large chunks where Blink breaks the spec, and Gecko implements both the proper and Blink behaviour, and to test the result you need enough APIs to test against the trash-quality websites that actually use this API (and a ton of others)
8:03:56
beach
I shall have to take your word for it. I don't know enough of web technology to understand.
8:07:46
MichaelRaskin
I agree that Web APIs are just a large pile of kind-of-modularisable things with imprecise spec and compatibility concerns, so they can be written part-by-part. But for that level of modularity Object Pascal is enough.
8:08:23
MichaelRaskin
I guess adding just enough JavaScript support that Lobste;rs submission form works is nice and doable and modularisable
8:08:30
beach
I don't understand why you brought up Object Pascal. Is that what things are typically written in?
8:08:56
MichaelRaskin
Just to say that facilities for modularisation have not be a bottleneck in the last 30 years
8:09:36
MichaelRaskin
These things are written in C++, or in Rust nowadays. It looks like Rust has enough memory safety to be a fully sufficient choice for them
8:10:26
beach
I don't know Object Pascal, but anything with manual memory management or that does not use uniform reference semantics is going to be problematic for modularity.
8:13:40
Shinmera
Implementing an HTML renderer is a big task, but doable. Implementing an HTML5 renderer probably already not. Implementing a CSS renderer is a gigantic task not even the big players can keep up with.
8:16:58
MichaelRaskin
I think one can list «pretty damn bad» Web APIs for a long time without much effort…
8:18:51
no-defun-allowed
The part I dislike the most is that whitespace is significant. If I write <span>foo</span><span>bar</span>, it is different to <span>foo</span> <span>bar</span>, which is sometimes what I want, but also sometimes not.
8:20:01
no-defun-allowed
Or maybe that's a CL-WHO problem for not letting me choose in places where it matters, like disabling whitespace between elements which I use to create a bar graph, but keeping it everywhere else to make the source more readable.
10:53:55
edgar-rft
The funny thing is that HTML originally was meant to be a *simple* markup language.
10:56:19
no-defun-allowed
All of cl-who is compile-time, right? So I couldn't set some magic variable or something to change the whitespace mode?
10:57:22
no-defun-allowed
I could probably embed another with-html-output macro inside the body with different settings though.
13:26:33
kmeow
so I guess the optional extension argument to vector-push-extend is for reserving space in advance
13:54:58
_death
if you know the size in advance you can also create a vector with just a fill-pointer and use vector-push
17:51:39
minion
Josh_2: direct your attention towards copying: http://www.nhplace.com/kent/PS/EQUAL.html
17:57:10
Bike
i wonder if there would be some value in exposing the copying that change-class is defined to use, though.
17:58:41
Bike
implementations might have something faster under the hood, like copying a storage vector