Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)L
Posts
439
Comments
601
Joined
3 yr. ago

  • You are making an extreme assumption, and it also sounds like you’ve misread what I wrote. The “attempts” I’m talking about are studies (formal and informal) to measure the root causes of bugs, not the C or C++ projects themselves.

    I think you're talking past the point I've made.

    The point I've made is that the bulk of these attempts don't even consider onboarding basic static analysis tools for projects. Do you agree?

    If you read the post of other studies you've quoted, you'd be aware that some of them quite literally report results of onboarding a single static analysis tool to C or C++ projects. The very first study in your list is quite literally the results of onboarding projects to Hardware-assisted AddressSanitizer, after acknowledging that they haven't onboarded AddressSanitizer due to performance reasons. The second study in your list reports results of enabling LLVM’s bound sanitizer.

    Yet, your personal claim over "the lack of memory safety" in languages like C or C++ is unexplainably based on failing to follow very basic and simple steps like onboarding any static analysis tool, which is trivial to do. Yet, your assertion doesn't cover that simple step. Why is that?

    Again, I think this comparison is disingenuous. You take zero effort to address whole family of errors and then proceed to claim that whole family of errors are not addressed, even though nowadays there's a myriad of ways to tackle those. That doesn't sound like a honest comparison to me.

  • If we're going to focus on C++, I think that Large-Scale C++ Volume I: Process and Architecture by John Lakos (link) is a must-read.

  • Was this thing generated by a poorly trained LLM?

  • C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and (...)

    ...and the bulk of these attempts don't even consider onboarding basic static analysis tools to projects.

    I think this comparison is disingenuous. Rust has static code analysis checks built into the compiler, while C compilers don't. Yet, you can still add static code analysis checks to projects, and from my experience they do a pretty good job flagging everything ranging from Critical double-frees to newlines showing up where they shouldn't. How come these tools are kept out of the equation?

  • C has always been (...)

    I think you tried too hard to see patterns where there are none.

    It's way simpler than what you tried to make it out to be: C was one of the very first programming languages put together. It's authors rushed to get a working compiler while using it to develop an operating system. In the 70s you did not had the benefit of leveraging half a century of UX, DX, or any X at all. The only X that was a part of the equation was the developers' own personal experience.

    Once C was made a reality, it stuck. Due to the importance of preserving backward compatibility, it stays mostly the same.

    Rust was different. Rust was created after the world piled up science, technology, experience, and craftsmanship for half a century. Their authors had the benefit of a clean slate approach and insight onto what worked and didn't worked before. They had the advantage of having a wealth of knowledge and insight being formed already before they started.

    That's it.

  • It was supposed to be a better C without the bloat and madness of C++, right?

    D was sold as a better C++, way back then when C++ was stuck with C++98. To be more clear, D promised to be C++ under active development. That was it's selling point.

    In the meantime C++ received 2 or 3 major updates, and thus D lost any claim to relevance.

  • Are you going to post links to all Wikipedia articles here?

    What problem do you have with Wikipedia?

  • C++ @programming.dev

    Safer Usage Of C++ (2021)

    docs.google.com /document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub
  • I found that it was worth sharing this list of IP protocols because more often than not developers are only faced with two of them, TCP and UDP, but there are over a hundred of IP protocols, most of which are never discussed or see the light of day. One I find particularly interesting is UDP-lite.

  • "GitUI is amazing, although unusable."

  • Ergonomic keyboards are not a result of “the size of the keyboard”, but the shape.

    I apologize for the mistake. Even though I referred to size, what I had in mind was geometry/layout.

    Without any real studies on it mentioned so far you’re relying on gut feeling and logic here.

    Are there actually any studies suggesting that ergonomic keyboards prevent RSI? As far as I could gather, there's a correlation between higher RSI incidence and keyboard usage, but nothing suggests ergonomic keyboards lead to a lower incidence of RSI.

  • Not to be a spoilsport, but as I predicted the .NET MAUI community in programming.dev is of course dead on arrival.

    The last post was two weeks ago, and the next to last one dates over one month.

    There was far more effort invested in requesting the creation of a community than to actually have a community. The request to create the community received more messages than those the actual community received in over a month.

    What's the point of creating these communities?

  • Wouldn’t wrist position be considered part of your overall posture?

    There are far more factors determining wrist position than the size of the keyboard, and only a very small fraction of all keyboard users end up developing any form of issue.

    Moreover, I'd wager that the number of people enduring bad laptop keyboards greatly outnumber those developing any kind of RSI issue, let alone those who feel strongly enough to buy ergonomic keyboards.

    It would be interesting to see how many ergonomic keyboards end up being snakeoil preying on people with more disposable money than good judgement.

  • From the whole blog post, the thing that caught my eye was the side remark regarding SPAs vs MPAs. It was one of those things that people don't tend to think about it but once someone touches on the subject, the problem become obvious. It seems that modern javascript frameworks focus on SPAs and try to shoehorn the concept everywhere, even when it clearly does not fit. Things reached a point where rewriting browser history to get that SPA to look like a MPA is now a basic feature of multiple pages, and it rarely works well.

    Perhaps it's too extreme to claim that MPAs are the future, but indeed there are a ton of webapps that are SPAs piling on complexity just to masquerade as MPAs.

  • Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks.

    That greatly depends on your project, what dependencies it has, and what's involved in the migration. For example, I recall a previous project I worked on that experienced a considerable amount of non-trivial issues when upgrading to C++14 due to unforeseeable curve balls. One of them was caused by a third-party dependency toggling constexpr versions of its member functions only on C++14, which caused a bunch of obscure linker errors as old symbols were no longer available.

  • Walter Bright has fairly odious political opinions;

    I fail to see the relevance of what personal opinions and beliefs he may or may not have. You're making it sound like the goal is not to improve a language ir fix issues, but to take something away from a person just because you disagree with their political opinions. That's hardly good use of anyone's time, and sounds terribly petty behavior.

    I wish I had that much free time to be able to waste it being so vindictive about such trifling issues.

    Which languages have you invested/migrated to, only to find that “political stunts” had a “negative impact” on your planned development?

    I don't waste my time with meaningless irrelevant stuff. Either a tech stack serves it's purpose, or it doesn't. I don't have enough free time to waste it trying to cancel others.

  • I'm partial for the Royal Kludge RK84 for no particular reason other than it's one of the rare small form factor keyboards that has USB passthrough. It's a godsend if you use a USB security key, and it also helps if you need to plug in additional devices such as a USB headset.

    If keychron had any model that supported USB passthrough, I'd update my recommendation.

  • I’d go with an ergonomic one to avoid pain on the outside of the wrists.

    I might be totally wrong, but I firmly believe these ergonomic risk factors are not the root cause of these health problems, and instead they are indirect factors that are correlated with fundamental problems affecting a person's activity.

    For example, tennis elbow isn't caused by a particular model of a tennis racket, nor is jumper's knee caused by a shoe model. Interestingly, I stumbled upon a post somewhere in the past that pointed out that Emacs users had a higher incidence of repetitive strain injuries than vi users. One of the most basic treatments of RSI is a combination of working on the patient's overall posture and rest, regardless of keyboard format.

    If you're experiencing wrist pain due to keyboard usage, the time you spend typing is a far more important factor than what keyboard model you're using.

  • From the blog post, it sounds like the underlying motivation is not tied to technical aspects but control over the language. If I had invested any of my personal time onboarding onto D and migrated any of my projects to D, I would be concerned about the negative impact these political stunts have on the tech stack.

  • I would rarely hear about Dlang in my circles and bubbles.

    That's hardly a measure of relevance or technical merit. There's a lot of artificial hype being created around some new projects that have a very tenuous correspondence to their technical merits or problems they actually solve, and social network chatter is hardly a factor in assessing technical merits.