[-] lysdexic@programming.dev 4 points 2 years ago

Your comment feels half-baked at best. You start to talk about "best editors" but you proceed to present your two best examples and neither has anything remotely related to editors.

CLion is undoubtedly the absolute best IDE for C++ projects, and it's multiplatform on top of it. It's not even a competition, specially if you're using CMake. Using Git integration as your best and single example to refute this is extremely puzzling by how silly it is.

[-] lysdexic@programming.dev 4 points 2 years ago

It looks like many communities are still down following the last update.

Does anyone have any update on this issue? I'd love to continue using Lemmy but I won't be able to do so if it's unusable.

[-] lysdexic@programming.dev 4 points 2 years ago* (last edited 2 years ago)

Why restrict to 54-bit signed integers?

Because number is a double, and IEEE754 specifies the mantissa of double-precision numbers as 53bits+sign.

Meaning, it's the highest integer precision that a double-precision object can express.

I suppose that makes sense for maximum compatibility, but feels gross if we’re already identifying value types.

It's not about compatibility. It's because JSON only has a number type which covers both floating point and integers, and number is implemented as a double-precision value. If you have to express integers with a double-precision type, when you go beyond 53bits you will start to experience loss of precision, which goes completely against the notion of an integer.

[-] lysdexic@programming.dev 4 points 2 years ago

I wouldn’t call bad readability a loaded gun really.

Bad readability is a problem cause by the developer, not the language. Anyone can crank out unreadable symbol soup in any language, if that's what they want/can deliver.

Blaming the programming language for the programmer's incompetence is very telling, so telling there's even a saying: A bad workman always blames his tools.

[-] lysdexic@programming.dev 4 points 2 years ago

git switch and git restore were introduced way back in 2019. I don't think they count as new.

[-] lysdexic@programming.dev 4 points 2 years ago* (last edited 2 years ago)

Honestly, I don't mind the downvotes. What puzzles me is how some people feel strongly enough about a topic to subscribe to a community, but still feel compelled to slap down contributions in a time nothing is being submitted, as if seeing no new posts is better than seeing a post that might not tickle their fancy.

It's the difference between building up and tearing down.

[-] lysdexic@programming.dev 4 points 2 years ago

Most software is built under non-ideal circumstances. Especially in the beginning there’s often tight deadlines involved.

Exactly this.

I think a bunch of people commenting in this thread on the virtues of rewriting things from scratch using the flavour of the month are instead showing the world they have zero professional experience working on commercial software projects. They are clearly oblivious to very basic and pervasive constraints that anyone working on software for a living is very well aware.

Things like prioritizing how a button is laid out over fixing a rarely occurring race condition is the norm in professional settings. You are paid to deliver value to your employer, and small things like paying technical debt are very hard sells for project managers running tight schedules.

Yet, here we are, seeing people advocating complete rewrites and adding piles of complexity while throwing out major features, and doing so with a straight face.

Unbelievable.

30
1
24
JDK 22 released (openjdk.org)
9
1
1
11
Reflection for C++26 (www.open-std.org)
13
1
7
14
1

Here's a reminder that the good people behind Express.js are currently working on Express 5, currently in beta.

[-] lysdexic@programming.dev 4 points 2 years ago

I dare say anything from the GNOME project.

[-] lysdexic@programming.dev 4 points 2 years ago

From the announcement:

The premise of chiseled containers is that container images are the best deployment vehicle for cloud apps, but that typical images contain far too many components. Instead, we need to slice away all but the essential components. Chiseled container images do that. That helps — a lot — with size and security.

I'm glad that Microsoft is being mindful of how they are delivering .NET container images. However, this announcement feels like a large marketing effort to spin a failure into a win. The need to provide lean container images is as old as Docker itself, and Alpine-based images are synonymous with lean images. A very basic security measure in containerized applications is to not ship stuff you don't need. Microsoft's container images are indeed quite big without no good justification.

It's nice that Microsoft is fixing the problems they've been creating, but I'm baffled by the effort they are making to make believe this is something new or even a new concept.

[-] lysdexic@programming.dev 4 points 2 years ago

From the announcement:

Another frequently mentioned feature in this series is Git’s “partial clone” mechanism, which allows interacting with a repository containing a limited subset of its objects.

Has anyone tried partial clones yet? If you did, how was the experience?

[-] lysdexic@programming.dev 4 points 3 years ago* (last edited 3 years ago)

The main problem is that dynamic linking is hard.

That is not a problem. That is a challenge for those who develop implementations, but it is hardly a problem. Doing hard things is the job description of any engineer.

Dynamic linking does not even reliably work with C++, an “old” language with decades of tooling and experience on the matter.

This is not true at all. Basically all major operating systems rely on dynamic linking, and all of them support C++ extensively. If I recall correctly, macOS even supports multiple types of dynamic linking. On Windows, DLLs are use extensively by system and userland applications. There are no problems other than versioning and version conflicts, and even that is a solved problem.

You get into all kind of UB when interacting with a separate DSO, especially since there are minimal verification of the ABI compatibility when loading a dynamic library.

This statement makes no sense at all. Undefined behavior is just behavior that the C++ standard intentionally did not imposed restrictions upon by leaving the behavior without a definition. Implementations can and do fill in the blanks.

ABI compatibility is also a silly thing to bring up in terms of dynamic linking because it also breaks for static linking.

So dynamic linking never really worked,

This statement is patently and blatantly false. There was no major operating system in use, not a single one, where dynamic linking is/was not used extensively. This has been the case for decades.

[-] lysdexic@programming.dev 4 points 3 years ago

I like old reddit. This project is a reminder that it's highly likely those bastards will start to work on making it unusable, if not outright end it.

view more: ‹ prev next ›

lysdexic

0 post score
0 comment score
joined 3 years ago
MODERATOR OF