I am simply offended. By Meta's lack of sensibilities (or ability) towards use of images on the Web while touting their new flavour of artificial intelligence as a product.
312 karma · joined September 21, 2024
> But I suspect that only creatures that have hopes and dreams and fears similar to our own would actually have much impact on human loneliness. And finding that sort of creature may be a long shot indeed.
I've been saying this for many years, and have had the same suspicion for longer -- first of all, for most people beyond myopic (with good reason) zoologists or biologists, it's not about "alien" life -- plenty of that, arguably, in the Mariana trench etc, noone's noticing because it's an answer to the wrong question. Extrapolating this, it's not even about _extra-terrestrial_ life necessarily -- not for some of us -- finding living bacteria of non-terrestrial origin on Mars is going to be amazing and an epic discovery, but it's still an answer to the wrong question -- our search is deep down motivated by desire to communicate, to ask as if our own mirror "what is going on?", "why do we exist?", "have you guys figured it out" and last but not least -- "we are excited to meet you, for all our numbers we've been feeling lonely with so much space, thinking we were alone". Many a sci-fi author express the question much better, because that's the one that matters.
But to placate the level-headed empirists -- yes, discovering the bacteria or alien jelly-fish in the interstellar void, is of course scientifically a big thing. But I suspect we are just being cautious not wanting to utter that discovering these we just want to get _more_ excited about the possibilities the former allows -- that we _will_ meet sentient beings of intelligence who will in the very least understand us (with due effort), sort of like the extended family we suspect we have and always wanted to meet, but the meeting is always postponed.
Jobs used to laugh at Microsoft for all manner of inconsistencies in behaviour and user experience with Windows, but now Apple is contending with the same problem, in part due to exposure as macOS has never been so popular and prevalent, and now there are ever growing amount of eyes calling them out for those inconsistencies that have been appearing more and more frequently without Jobs' leadership style.
A bit of a fun fact: there's a quote by Farah where he said that the language and semantics of the tool he was writing, didn't really "click in" until he was well into writing it :-) I myself have been on occasion pulling my hair out trying to wield `yq`'s language, there's some inconsistencies here and there which I think are related to the novel nature of the language (not novel to everyone but it's uncommon even for those well versed with e.g. SQL). `jq` suffers from similar woes, but to a lesser degree.
However, as someone who always loved faster software and being an optimisation nerd, hat's off!
This is in contrast with [Pijul](https://pijul.org) where changes are patches and are commutative -- you can apply an entire set and the result is supposed to be equivalent regardless of the order the patches are applied in. Now _that_ is unit of work" I understand can be applied and undone in "isolation".
Everything else is messy, in my eyes, but perhaps it's orderly to other people. I mean it would be nice if a software system defined with code could be expressed with a set of independent patches where each patch is "atomic" and a feature or a fix etc, to the degree it is possible. With Git, that's a near-impossibility _in the graph_ -- sure you can cherry-pick or rebase a set of commits that belong to a feature (normally on a feature branch), but _why_?
To all of the above I might add that without "custom elements" Web Components is severely crippled as a feature. If I want to sub-class existing functionality, say a `table` or `details`, composition is the only means to do it, which in the best style on the Web, produces a lot of extra code noone wants to read. I suppose minimisation is supposed to eliminate the need to read JavaScript code, and 99% of every website out there features absolutely unreadable slop of spaghetti code that wouldn't pass paid review in hell. With Web Components that don't implement "custom elements" (e.g. in Safari) it's a essentially an OOP science professor's toy or totem. And since professors like their OOP theory, they should indeed take Liskov's principle to heart -- meaning the spec. is botched in part.
`#fff` is device color, it's short for `#ffffff` which is 24-bit RGB that predates sRGB, as does true color device support. I was sending 24-bit RGB to VESA-compliant graphics cards before sRGB became a thing. `#fff` was supported by Photoshop and Macromedia products as straightforward device colour format, before sRGB was adopted by at least the latter, mind you. The use by CSS is co-incidental, not where the format was introduced.
Also, `#fff` is ambigous -- if you mean device colour, then there's no brightness (nits) specified at all, it may be 200 or 2000 or 10,000. If sRGB is implied, as in `#fff in sRGB colour space` then the standard specifies 80 nits, so when you say you don't want brighter than that, then you can't have much of HDR since sRGB precludes HDR by definition (can't go brighter than 80 nits for the "whitepoint" aka white).
I think if you want HDR you need a different colour space entirely, which either has a different peak brightness, or one where the brightness is specified additionally to e.g. R, G and B primaries. But here my HDR knowledge is weak -- perhaps someone else may chime in. I just find colour science fascinating, sorry to go on a tangent here.
So far it's been a lot of conjecture and correlations. Everyone's guessing, because at the bottom of it lie very difficult to prove concepts like nature of consciousness and intelligence.
In between, you have those who let their pet models loose on the world, these I think work best as experiments whose value is in permitting observation of the kind that can help us plug the data _back_ into the research.
We don't need to answer the question "what is consciousness" if we have utility, which we already have. Which is why I also don't join those who seem to take preliminary conclusions like "why even respond, it's an elaborate algorithm that consumes inordinate amounts of energy". It's complex -- what if AI(s) can meaningfully guide us to solve the energy problem, for example?
Unless you mean by that something entirely different than what most people specifically on Hacker News, of all places, understand with "stateless", most and myself included, would disagree with you regarding the "stateless" property. If you do mean something entirely different than implying an LLM doesn't transition from a state to a state, potentially confined to a limited set of states through finite immutable training data set and accessible context and lack of PRNG, then would you care to elaborate?
Also, it can be stateful _and_ without a consciousness. Like a finite automaton? I don't think anyone's claiming (yet) any of the models today have consciousness, but that's mostly because it's going to be practically impossible to prove without some accepted theory of consciousness, I guess.
The problem with your assumption that I see is that we collectively can't tell for sure whether the above isn't also how humans work. The science is still out on whether free will is indeed free or should be called _will_. Dismissing or discounting whatever (or whoever) wrote a text because they're a token machine, is just a tad unscientific. Yes, it's an algorithm, with a locked seed even deterministic, but claiming and proving are different things, and this is as tricky as it gets.
Personally, I would be inclined to dismiss the case too, just because it's written by a "token machine", but this is where my own fault in scientific reasoning would become evident as well -- it's getting harder and harder to find _valid_ reasons to dismiss these out of hand. For now, persistence of their "personality" (stored in `SOUL.md` or however else) is both externally mutable and very crude, obviously. But we're on a _scale_ now. If a chimp comes into a convenience store and pays a coin and points and the chewing gum, is it legal to take the money and boot them out for being a non-person and/or without self-awareness?
I don't want to get all airy-fairy with this, but point being -- this is a new frontier, and this starts to look like the classic sci-fi prediction: the defenders of AI vs the "they're just tools, dead soulless tools" group. If we're to find out of it -- regardless of how expensive engaging with these models is _today_ -- we need to have a very _solid_ level of prosection of our opinion, not just "it's not sentient, it just takes tokens in, prints tokens out". The sentence obstructs through its simplicity of statement the very nature of the problem the world is already facing, which is why the AI cat refuses to go back into the bag -- there's capital put in into essentially just answering the question "what _is_ intelligence?".
I see a lot of URLs being passed around as strings within a system perfectly capable of leveraging typing theory and offering user defined types, if not at least through OOP goodness a lot of people would furiously defend. The URL, in this case, would often have _already_ been parsed once, but effectively "unparsed" and keeps being sent around as text in need of parsing at every "junction" of the system that requires to meaningfully access it, except that parsing is approached like some ungodly litany best avoided and thus foregone or lazily implemented with a regex where a regex isn't nearly sufficient. Perhaps it's because we lack parsers, by and large, or in the very least parser generators that are readily available, understandable (to your average developer), and simple enough to use without requiring to understand formal language theory with Chomsky hierarchy, context sensitivity, grammar ambiguity and parse forests, to say the least.
Same with [file] paths, HTTP header values, and other things that seem alluring to dismiss as only being text.
It wouldn't be a problem, had I not seen time and again how the "text" breaks -- URLs with malformed query parameters because why not just do `+ '?' + entries.map(([ name, value ]) => name + "=" + value).join("&")`, how hard can it be? Paths that assume leading slash or lack there of etc.
I believe the article was born precisely of the same class of frustrations. So I am now bringing the same mantra everywhere with me: "There is no such type as string". Parse at earliest opportunity, lazily if the language allows it (most languages do) -- breadth first so as to not pay upfront, just don't let the text slip through.
I am talking from experience, really, your mileage may vary.
This brings back _memories_! I think I won't even stand out from the crowd here mentioning me and the gang watched the hell out of the VHS back when, in our circle it was a different world than I suppose even for people in the West who loved it. We're so far removed this became a cult classic long before it became cult classic everywhere else. Needless to say, Angelina Jolie's character made quite an impression on this young mind :-) Damn, quotes from this movie live rent-free in my head. I was already quite a fan of Orbital when I saw Hackers for the first time. It was also at the end of "Mortal Kombat", by the way -- but Hackers used it marginally better still IMO.
Hacker had HEART, man. It was cheesy but the feeling it left in an entire sub-culture of a generation, cannot be underestimated. I am reading some of the other stories here, and it brings smile to my face knowing me and my gang weren't the only ones the movie imprinted on.
Woha, this isn't woodshop class?!
And yeah, XML wasn't perfect -- people harping on it are literally flogging a dead horse. Had the horse been given a pasture, it would have recovered. Instead we have very tiny pig-horses like JSON and YAML and three dozen other "weekend project candidates to someone's claim to fame and CS history" which haven't got half of XML's _useful_ features -- like namespaces, being one.
YAML has anchors, which is a useful feature in itself -- so no, we don't just regress or reinvent the wheel, there's room for improving XML. The tragedy is throwing the baby with the bathwater, or so it seems to me that we have.
Giving XML largely the collective boot was the wrong decision. That's my firm opinion. Tools like XSLT haven't got an equal today -- these for better and for worse need XML in some capacity, and are much more extensible (no pun intended) than abominations like Jinja or what have you. XSLT was _designed_ while Jinja for one, appears to have been grown in a petri dish of sorts.
The hipster-like obsession with every new thing on the hill gave us HTML 5, with its weird context-sensitive parser rules where some tags can be closed, some must be closed and some must not be closed and so on. On top of it it mandates some forgiving behaviour on part of the parser, making best-effort assumptions that kind of get it to render the document but not the one you wanted -- add modern scripting and you are sitting there debugging subtly but by-design hidden errors -- instead of what was the case with XML that demanded you had the basic capacity to write the forward slash in the right places. But no, that was apparently too hard.
Also, really love the choice quotes in the article:
> They are the result of path dependence and fashion, not considered engineering judgment.
_Fashion_ is the word that comes to my mind every time I have to hear people half my age try to sell me JSON or YAML. Like, what basis do you have to argue on bare mention of something you haven't even worked on, just essentially repeating the person on your left? That's _cargo-cult programming_ again. The fact that mention of XML often draws use of that very term, "old-fashioned", speaks enough of the level of the conversation here -- we're apparently occupied by _fashion_ in choices of systems that by and large do the same thing their predecessors have done since the 60's.
> We value familiarity over rigor. We value the appearance of simplicity over actual simplicity, which is the simplicity that comes from clear rules and consistent structure.
Just the cherry on the cake, frankly. The entire "The Final Point" section really nails it for my part. I spend considerable amount of time at work trying to hammer into rookies essentially the equivalent of:
> Formality in data representation prevents entire classes of errors.
But it would appear history repeats itself as every generation has to learn too late the same mistakes that someone in the previous generation could have written a large book about, as a _warning_. Just the other day, for example, one of my let's say less rigorous colleagues said outright that "`null` is great in a [programming] language" (the exact wording was something along of "I love null!"), following up with the dubious clarification that this also includes SQL. I am not sure they even comprehend the size of the hole such statement makes.
Add to the above that iPhone "mini" might have been slower or just "worse" and it wasn't just the screen that was reduced in size, so the word of mouth might have been that the phone is simply worse, and that contributed to poor sales.
There's no way of telling how a 5,5" phone would fare until there's consistent prolonged feature-parity based sales of such phones that are otherwise identical to other offerings by the same brand, across multiple brands (if I am a die-hard Fairphone customer, I am not buying an iPhone regardless of screen size) to help gather proper statistics.
It's very similar to smart TVs. Yes, most people do prefer smart TVs, but vendors use it very successfully to sell inferior displays (poor color, poor contrast etc), to compensate and to pull more selling margin, since that's how the consumer functions (being utterly unable to quantify display quality for an uncalibrated TV). Anyway, I am digressing -- the point of my comparison is that it's complicated and not nearly as simple as "consumers want larger phones / TVs with slow menus and shitty picture as long as there's Netflix in there".
I guess electronics has gotten denser, and density for the same volume is what quite literally translates to larger weight. The density thing is because they're able to cram more electronics, as our fabrication technology inches forward (i.e. Intel/TSMC/Nvidia/etc trying to break the 1nm barrier for transistors).
Remember the old Nokia phones, where the plastic shell likely amounted to as much volume that a modern phone instead dedicates to the entire front camera device? The latter will weigh much more than the plastic, for the same volume. Now apply that to _every_ component in the modern phone, and the difference is multiplicative -- there's just more features in every cubic millimeter of the phone today. No wonder it's getting heavier.
I mean I get what you're implying, I am just making sure I understand the meaning of "context" here. But if you have large fingers, smaller buttons obviously make the device harder to use, no two ways about it. However, in Android and iOS both, it's possible (for the user) to scale everything up, to help solve that very problem.
The bigger battery argument is a valid one too, but you have to keep in mind that most of the battery is consumed by the screen on average, and larger screen will eat more battery, so it's a bit like the rocket equation -- bigger rocket needs more fuel, more fuel needs more space and adds weight to the rocket, more rocket more fuel again and so on. In terms of batteries and rockets both, there's a golden middle there somewhere, I think. But it's a moving quantity since both screens and batteries are different -- OLED vs LED-lit LCD screen and LiPo vs LiOn for battery and so on. In short: I don't think a 5,5" phone (my preferred size) will suffer from shorter battery life, perhaps on the contrary (vs. a 6,5"). Especially considering that _large_ phones tend to be made _thinner_, since their ergonomics depends more on thickness (for the large width and height), perhaps becoming a problem with more than 8mm thickness, while a 5,5" phone can in fact be used comfortably even if it was 8-10mm thick, since it's smaller in the other two dimensions. That extra afforded thickness can directly translate to a battery that is as large or larger in terms of capacity as one for a 7mm "slick" 6,5" phone.