I think it was sarcasm. I have about as much experience as them in low-level C programming, and I was wondering why this is on front page. I've also discovered again a few things too, so I won't look down on OP. It's certainly better than vibe coding.
I know about XOR-linked lists and a few other tricks for very efficient memory usage in embedded systems, but it's my first time seeing implicit allocation lengths.
But here it's not about a generic lack of realism (there's plenty of details you could point to, but it would be of course silly) but simply the internal contradiction in what the main character says: claims that the station is "as big as the cosmos" and two lines later provides an estimate for its diameter that is grossly inconsistent with that same assessment. Unless they live in a universe that is only 15k years old, which is also possible (but clearly not serving a purpose in the story).
No, the main character isn't confused at all in his last message, he's very confident in saying that the station "is coeval with the cosmos, and constitutes the cosmos." That's why the "estimated diameter: 15k ly" feel like a writer's oversight. Unless it's intentional, but then I'd like to understand why.
The report writer also failed to realize they'd looped back to their starting location until much after they had done so. They're clearly unreliable, an inconsistency like that doesn't need to be explained by anything other than that the author is losing their grip on reality. The other explanation is that their instruments are indicating a diameter of 15,000 light years and that that is all they are recording (as they were recording in previous reports, the numbers came from instruments), and the report writer has failed to recognize the inconsistency between their belief and the facts available to them.
> No, the main character isn't confused at all in his last message, he's very confident in saying that the station "is coeval with the cosmos, and constitutes the cosmos."
The main character is in the midst of a religious fervor. The station does not constitute the cosmos.
> "estimated diameter: 15k ly" feel like a writer's oversight.
Every time the instruments were checked, the instruments jumped in estimated diameter. Are you confused because the speaker got to the conclusion that the station is the universe before the instruments did? No doubt if there were more reports, it would be reported as being larger. Probably it wouldn't stop at the size of the universe, either.
In any event: neither the speaker, nor their instruments, were correct. Both are deeply confused about what the station is.
The size estimates provided are not instrumental readings- there's no information in the text that supports this interpretation. They are- as it makes sense and as clearly stated- estimates based on the best knowledge and understanding of the reporter at that particular moment. They change with the physical exploration of the base. So when the reporter says that the base is the size of the cosmos, his size estimate should match the size of the cosmos. It's pretty clear that here Ballard just chose a number that seemed both immense and a big enough jump from the previous estimate, but at a second look makes his character incoherent because he's contradicting what he just wrote.
> instrumental readings- there's no information in the text that supports this interpretation.
From the story: “A curious feature of the station is its powerful gravitational field, far stronger than would be suggested by its small mass. However, this probably represents a faulty reading by our instruments.”
And then the next paragraph is the estimated size.
> but at a second look makes his character incoherent because he's contradicting what he just wrote.
His character was incoherent from the first look, too.
SW dev costs can be accounted for in the HW price tag, especially when you sell a lot of units, and assuming the SW is much better than "good enough". HW is the best licensing key; if you can do that, go for it.
>SW dev costs can be accounted for in the HW price tag
That would then make you chips more expensive than the competition and less competitive on the BOM side, and BOM costs are a different accounting budget than SW licenses.
People in the industry have already thought of this. HN likes to think they somehow found the magic solution nobody ever has thought before, when the truth is HN doesn't understand sales of the HW industry.
It depends on the HW:SW cost ratio and the volume. In favourable case the extra bit on the price tag can amount to a rounding error. Moreover, the price tag includes a profit margin, which is usually adjusted to match the competition already.
Besides, "ignorant" HN comments on e.g. FOSS software and funding problems have mentioned that the paperwork you have to do to buy software licences can be a PITA, so free software can be perceived as a plus when the R&D selects the parts.
People have already thought of that, sure. But has it been thought about and executed properly? Like the added value of open-sourcing the SW (made a lot easier when you don't need to copy-protect it). Or do they just go for the extra source of profit the SW licence sales provides, anyway?
In my Embedded work experience, the BOM costs matters more than SW licensing costs. Which matches the business model of Xilinx.
The company I worked for was selling million or tens of million of units per year. So in such cases it's easy to see why BOM costs trump the SW costs of a few licences, and why HW companies would like to keep chips costs down and charging you per SW license.
If you haven't shipped million of products in embedded and only worked in SW development, it's easy to get a warped picture of reality.
I haven't shipped millions of units but I do have occasional glimpses of the HW side as a firmware programmer. My impression is that decisions regarding costs are not always entirely rational, hence my questioning. Thanks for the answers.
You can't send a "moral person" to jail, unlike "physical persons". But sometimes I wonder if taking a fraction of their shares from them would make them more... Moral I guess.
Besides Spolsky's law of leaky abstractions, "abstractions" can also result in "lowest common denominator" situations, which are the opposite of performance optimization. Talking negatively about abstractions is not what deals damage; you are shooting the messenger here. It's the abstractions themselves that deal damage when misplaced. "Zero-cost abstractions" is the true hyperbole.
Is this a good faith reply? The particular abstraction we built, and is being discussed, is manifestly and obviously not a lowest common denominator.
Looks like you are deploying a second straw man, that of zero cost. In other comments here I acknowledge a cost to intrinsics.
The thing is, "better" is an ambiguous word. I can change a program in some way and make it smaller. I can change it in some other way and make it faster. Both are "better", but in different ways. More often than not, however, you can't have both smaller and faster - or else your are just fixing a performance bug. Often even improving one property makes some other property less good, as you can see in the numerous "pick two" rules.
So "better" means "more specialized" more often that it means "more optimized". I don't say it is a bad thing per se, but it is best to keep in mind that they are two types of improvement, fixes and specializations, because the latter is a commitment.
reply