astrobe_

Yes. I'm moving the goal post a bit here, but I was actually thinking about design mistakes and dangerous constructs - the kind of thing you do when you write in a "hacky" way - either deliberately or because you don't know better. Although these are not directly under the scope of type checking, a more restrictive language can have a positive influence.

I'll paraphrase someone who commented on HN once (about dynamic vs static typing, IIRC): permissive languages are enablers for solo programmers, but you need more restrictive languages for team programming.

This matches my experience because you don't chose who you work with. Skill level is uneven among the team. Less skilled co-workers will make mistakes that will have more consequences when the language is more permissive.

That's one of the reasons you want code reviews, but then you convert your skilled programmers to teachers. This is not a good trade, because the time they spend improving the skills of other programmers is partially wasted because programmers are free to come and go. AI could change this picture.

The name of the game is therefore to keep your teams small and skilled, but this is can be difficult because of typical company politics - e.g. "bus factor" considerations, shortening time-to-market is often achieved by adding more programmers.

> is in fact set in a fictional region of Japan, but is created so lovingly that you’ll believe it’s real life.

This is actually a major cheat. Realism is expensive, and exposes your creation to the equivalent of the "uncanny valley" for vehicle simulation - the simulated world is never accurate enough and you can't help but notice the differences with reality. E.g. if you see generic buildings ("autogen") near a location you know IRL, the simulation feels immediately sloppy.

Yet, as long as I'm not interested in visiting real places, I would go for a vehicle simulation in a fictional world any day. I wouldn't mind if the vehicles were also fictional, as long as they require some technique to drive them. What matters in games is challenge and mastery, but not what you master; your RTS, FPS or chess skills have very little value IRL.

> Zoom out far enough—and for some reason it will let you—and you see the tiles, the roads that don’t line up, and the various tricks and techniques that allow it to look so realistic from low down. But don’t do that! That’s silly. This is a train sim, not a plane sim, you’ve no business in the sky.

OpenBVE one-upped BVE train sim with external cameras, and as a result you see all this too. In my eyes, they sort of miss the point of a train simulation: the view point is normally attached to the driver, so one can use all sorts of tricks to avoid having to "paint the entire wall" - which is quite important if you count on a community of fan modders who have limited resources.

Hardcore fans may like the BVE train sim [1]. A lot of Japanese fan-made lines (add-ons) with custom sounds. Generally speaking, the game is far from AAA, but the "hand-made" feel makes up for that.

The downside is that sometimes it is difficult to install addons or to figure out their custom features because the instructions are often poorly translated from Japanese and websites often have no English translations at all. One should also note that some addons include and run "homemade" DLLs to implement custom features.

It seems that the community is on the decline though, because while searching around I have found a lot of dead links. One can try OpenBVE [2] (partially compatible with BVE), which is less Japan-centric but should have some Japanese lines.

[1] https://bvets.net/en/

[2] https://openbve-project.net/

Let's go for "PearTube" then.

> Using a Gregorian Date before the calendar was introduced is almost certainly an error.

It's just an extrapolation; using the calendar being used at the considered time would be meaningless for us, e.g. the short-lived french republican calendar [1].

[1] https://en.wikipedia.org/wiki/French_Republican_calendar

And that's also why we are in the 21st century, not the 20th.

ORMs and variations like Protobuf or things that have to be cross-plateform in the wide sense. The perspective that the same source will behave the same in various environments, and "velocity" trumps performance considerations. If you want to work on things where performance matters, consider embedded/firmware programming ;-)

It seems this -que was already a relic at that time, or maybe sort of literary, because it coexisted with et (as in etc, et cetera, &c), which still exists e.g. in French. Or maybe one is from antic Latin and the other is from "vulgar"/late Latin ?

Still romanian. "The common law—so named because it was common to all the king's courts across England—originated in the practices of the courts of the English kings in the centuries following the Norman Conquest in 1066" [1]

France (and Normandy) was conquered by Rome before it was granted to Rollo, a Viking. A few generations later, his descendant William the Conqueror claimed the English crown. Just like what happened with Gauls and Romans, the conquered people adopted large parts of the language and customs of the conqueror. That's why the English language is ~25% of Roman origin for it's vocabulary. I suppose it is the same for English common law.

[1] https://en.wikipedia.org/wiki/Common_law#History

You can have them in C/C++ at least [1]

[1] https://en.cppreference.com/cpp/language/operator_alternativ...

The title reads "too little, too late" to me.

This only makes a difference in terms of memory size, not in terms of speed, because for decades processors and compilers have been optimized for moving bytes around.

But one would note that in order to gain memory for this particular case of slicing, one introduces 2 extra words (size and pointer) for every other cases. Like perhaps the second most common string operation, concatenation. In those other cases, the benefit is slightly negative.

I've had extensive experience with "counted strings" because I implemented a bunch of Forth interpreters which also uses this scheme. Including the common trick of using counted and zero-terminated strings, which is the worst of both worlds in the end. Forth is the kind of language that quickly show you how bad your choices are.

I eventually dropped all that and adopted ASCIIZ strings because they are generally more efficient (if you pay attention to the strlen() performance pitfalls) and having a dead simple interface with the rest of the world (OS, libraries) is more valuable.

We sill probably see an increase in the use of OS-level memory compression tricks instead - things like zwap on Linux, for instance. Because the trend is usually to cure the symptoms, not the cause, as it is generally easier to set up and good enough. Makers who already have invested on memory-careless tech such as Electron won't rewrite; at best they'll just be replaced by better alternatives.

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.

If you like nitpicking, Poe's short story *The unparalleled Adventure of One Hans Pfall" [1] should keep you busy a couple of days ;-)

[1] https://en.wikipedia.org/wiki/The_Unparalleled_Adventure_of_...

I'd say if it does have methodological deficits, it should be ignored. Measuring a length with a wet spaghetti can only result in nonsense.

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.

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?

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.

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.

Indeed, even I can guess. I see two answers that end with the same word, so the correct answer is probably one of those.

So "modern" is a synonym for "current" here, if one puts aside warnings about its decline due to human activity?

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.

"I have over 4,000 emails, pictures, addresses, SNS. People just submitted it. I don't know why. They 'trust me'. Dumb fucks"

- M. Zuckerberg, ~2000.

Also: Blade Runner, anyone?

This reminds me of a comment I read here a long time ago; it was about XML and how DTDs were supposed to permit one to be strict. However, in reality, the person said, if the the other end who is sending you broken XML is a big corp who refuses to fix it, then you have no choice but accept it.

Bottom line: it's all a matter of balance of powers. If you're the smaller guy in the equation, you'll be "Postel'ed" anyway.

Yet Postel's law is still in the "the road to hell is paved with good intentions" category, for the reason you explain very well (AKA XKCD #1172 "Workflow"). Wikipedia even lists a couple of major critics about it [1].

[1] https://en.wikipedia.org/wiki/Robustness_principle

That's sort of the point TFA. You make implementation choices that feel OK and then the time comes to implement the "trivial" pause function...

In other domains, adding the delta time of your main loop to your timers can cause (logical) clock drifts in the long term because of resolution errors.

It depends on how your timers are implemented. If they are implemented as a "rendez-vous" absolute date (as in UTC for instance - not in local time unless you want to add "eastern eggs" related to daylight saving time...), this will cause bugs. If you implement your own in-game monotonic clock that you can stop, it should be ok.

> The flip side is everything is being degraded by random mutation

"degraded"? Aren't random mutations precisely one of the core mechanism of adaptation?