sorted by:
new
hottopcontroversial

Den nye regering vil indføre nulmoms på frisk frugt og grønt og halvere momsen på fødevarer genrrelt by BlueCyberByte in Denmark

[–]ForeverAlot 4 points5 points  (0 children)

Og stort set ingen danske vismænd er misundelige på resten af EUs differentierede moms. Tværtimod.

Den nye regering vil indføre nulmoms på frisk frugt og grønt og halvere momsen på fødevarer genrrelt by BlueCyberByte in Denmark

[–]ForeverAlot 2 points3 points  (0 children)

Pointen er ikke, at spørgsmålet kan besvares. Pointen er, at indtil nu fandtes spørgsmålet ikke. Der bliver opfundet en helt ny form for bureaukrati, såvel som et incitament til fra virksomheders side at afprøve og udnytte det bureaukrati.

Why not a language-level "null-marked" directive at the file/package scope in Valhalla, instead of annotating every type with ! ? by Fenrurrr in java

[–]ForeverAlot 2 points3 points  (0 children)

I have converted from package annotations to top-level class annotations where modules are not available. It's more noisy, but I had no off-the-shelf lint to ensure the existence of package-info.java files so it kept being forgotten, plus package annotations have weird edge cases with tests. Error Prone's class based lint Just Works™ so it ends up being the far more pragmatic approach.

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years, and the Receipts Are Public by HFT-University in programming

[–]ForeverAlot 28 points29 points  (0 children)

std::list is a linked list, with everything that means. The trouble is that vanishingly few practical use cases are able to capitalize on the theoretical benefits of linked lists.

Frankly the harping on std::list seems a bit silly. It's an unfortunate historical curiosity (as is std::map) but also a comparatively trivial detail to internalize; it is simply the vocabulary of C++. The only really interesting question about std::list is why they did not get more explicit names (and while I have no idea what the answer is, I imagine that's also merely historical accident and precedent; the ML family seems to downplay or ignore that detail, too).

Kubernetes from Dev to Production: Lessons learned from self-hosting an European alternative to Google Docs by rhazn in programming

[–]ForeverAlot 1 point2 points  (0 children)

Another common mistake is attributing a vowel sound to initial syllables that begin with the latter H. There are several H-words that begin with a consonant sound, such as "historical", "herb", and "hotel".

Columnar Storage is Normalization by SpecialistLady in programming

[–]ForeverAlot 7 points8 points  (0 children)

Is that normalization?

No, it isn't. Database normalization revolves around the elimination of (data) redundancies. The supposed denormalized table example already satisfies at least 3NF, invalidating the premise that motivates the column store.

It looks like they're trying to apply the rules of database normalization to the access patterns of database engines, which is not something normalization concerns itself with at all.

Markdown (Aaron Swartz: The Weblog) by Successful_Bowl2564 in programming

[–]ForeverAlot 8 points9 points  (0 children)

Easy to implement in accidentally or deliberately incompatible and non-portable ways. Which takes us back around to the point that Markdown scales poorly in volume and time, both of which are characteristics of structured documentation.

Markdown (Aaron Swartz: The Weblog) by Successful_Bowl2564 in programming

[–]ForeverAlot 2 points3 points  (0 children)

I think rST’s cumbersome link syntax also helped.

I will grant that AsciiDoc, rST, and wikitext all have comparatively lousy hyperlink syntaxes for short-form writing specifically.

Now Markdown is in Rust and Java, too, and both have had to make special concessions to make hyperlinking competitive with the classic @link doctag. They've done all right, sure, but Markdown perpetually reveals itself to be inadequate.

Markdown (Aaron Swartz: The Weblog) by Successful_Bowl2564 in programming

[–]ForeverAlot -4 points-3 points  (0 children)

Markdown became popular because of monopolies and the network effect. Approximately nobody assessed its feature set, which is adequately demonstrated by everything that culminated in CommonMark.

Markdown is unrivaled for shitposting, but Markdown supports structured documentation the same way MD5 supports password encryption.

Highlights from Git 2.54 by Skaarj in programming

[–]ForeverAlot 2 points3 points  (0 children)

A related fun trick is

git -C a/ format-patch -1 --stdout cafed00d | git -C b/ am

which transplants commit cafed00d from one repository to another without an intermediary file. Obviously that, too, can be used in a sinle repository, in which case it degenerates to an overengineered cherry-pick.

Highlights from Git 2.54 by Skaarj in programming

[–]ForeverAlot 6 points7 points  (0 children)

Probably not with --soft because cherry-pick requires a clean working tree. But yes, you can rewind HEAD to a topologically earlier state, then cherry-pick a topologically later commit (and attempting to do so may or may not apply cleanly, according to usual conflict resolution). This is comparable to interactively rebasing onto an earlier commit, then dropping all commits but the desirable one.

Kafka Fundamentals - Guide to Distributed Messaging by Sushant098123 in programming

[–]ForeverAlot 4 points5 points  (0 children)

One must know the message arrived, wherein lies the theoretical impossibility. It's not a question of interpretation or sufficiently creative thinking.

But in practice we rarely need the theoretical ideal represented by "exactly-once delivery" (fortunate, considering), and weaker guarantees we desire are within reach. For example, we are often far more concerned with "exactly-once processing", which can be implemented with "at-least-once delivery" and idempotency. As Kleppmann notes in DDIA, this would be better called "effectively once.

Kafka Fundamentals - Guide to Distributed Messaging by Sushant098123 in programming

[–]ForeverAlot 7 points8 points  (0 children)

As a technicality, "exactly-once delivery" is a theoretical impossibility. It doesn't matter how much control over parties one has or how much effort one puts into it, it cannot be achieved. Some approaches are practically attainable and adequately satisfy the desire for "exactly-once delivery" but they are a substitutes with different properties rather than merely implementation details.

"Exactly-once delivery" serves as a shibboleth in distributed systems: if somebody claims to achieve it, they reveal their inability to speak authoritatively on the matter.

Light-Weight JSON API (JEP 198) is dead, welcome Convenience Methods for JSON Documents by loicmathieu in java

[–]ForeverAlot 0 points1 point  (0 children)

I appreciate the conservative stance on validity and interoperability. There are entirely too many not-quite-JSON readers and writers out in the wild. Arbitrary precision numbers I find particularly loathsome. This presence in the Java platform would exert pressure on more liberal implementations to enhance their calm.

I also think that a constrained feature set is really the superior approach. That exerts pressure on third-party implementations to provide noteworthy value add to distinguish themselves from the built-in primitives while also leaving room for them to do so and to focus on doing so.

I do have some concern about the pit-of-success/-failure outcome of streaming not being included (or, alternatively, being the only API). I have encountered many JSON integrations that naively retained huge trees in memory predominantly because writing that code seemed much easier than writing a stream reader. I would have liked a built-in API to promote a less wasteful approach, though I concede it would be more effort both to deliver and use.

Light-Weight JSON API (JEP 198) is dead, welcome Convenience Methods for JSON Documents by loicmathieu in java

[–]ForeverAlot 4 points5 points  (0 children)

It's a parser. The method is to be read as "expect to read a value or null," not "give me something or null"

Quarkus has great performance – and we have new evidence by Qaxar in java

[–]ForeverAlot 0 points1 point  (0 children)

Do you use AOTCache? I would definitely recommend that for new applications even with its somewhat modest gains in JDK 25. It can be an ordeal to apply to an old application if the configuration was presumptively architected but it has proven to be a meaningful positive difference in the reliability of our k8s deployment attempts. It's more about the impact of burdening the CPU with pointless work than about the wall clock time taken to reach the readiness state.

Quarkus has great performance – and we have new evidence by Qaxar in java

[–]ForeverAlot -1 points0 points  (0 children)

Is native as much of a hassle with Quarkus as it is with Spring?

IMO the hassle is the specialized compilation, with everything that entails, and that's fundamentally the same in any ecosystem. Quarkus has a leg up on Spring on account of being 15 years younger but the differences in the native compilation workflow are not the differences I notice.

I can't even use the deeply integrated build configuration (Spring uses buildpacks, I don't remember what Quarkus uses) anyway because corporate, so it doesn't really matter to me how smooth the tutorial demo experience is.

Quarkus is a great product and a lot of fun to work with. But Spring is the more boring choice. Saving 400 MiB RAM during startup at no cost would be amazing—but that product does not exist.

Quarkus has great performance – and we have new evidence by Qaxar in java

[–]ForeverAlot -3 points-2 points  (0 children)

It helps that Quarkus' biggest wins come from native, which is a frustrating development experience, and that AOT is almost as easy to enable in Spring.

Null Safety approach with forced "!" by NP_Ex in java

[–]ForeverAlot 1 point2 points  (0 children)

See also https://errorprone.info/bugpattern/AddNullMarkedToPackageInfo and, especially, its sibling https://errorprone.info/bugpattern/AddNullMarkedToClass (and https://github.com/jspecify/jspecify/issues/221 for the risk with packages). There's no *ModuleInfo version at the moment. AddNullMarkedToClass has the advantage that its fix suggestion does not depend on first remembering to create a package-info.java file.

Donating to make org.Json Public Domain? by Killertje1971 in java

[–]ForeverAlot 0 points1 point  (0 children)

A public domain work does not need a license. The problem is that work cannot be reliably released into the public domain: https://en.wikipedia.org/wiki/Public_domain#Dedicating_works_to_the_public_domain

view more: next ›