lysdexic @ lysdexic @programming.dev

Posts

65

Comments

357

Joined

2 yr. ago

I think that pattern matching and sum types are orthogonal to monads, and aren't really relevant when discussing monads as alternatives to exceptions. C++ didn't required any of those to add std::optional or std::variant, and those are already used as result monads.

Supporting Result and Either monads in the standard would be nice, but again this does not stop anyone from adopting one of the many libraries that already provide those.

It’s a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.

I don't think this is a lack of support in C++. There are already a few C++ libraries that implement Either and Result monads. It would be nice if those were supported in the C++ stand library, but that does not stop anyone from adopting them.

Let me give you a quick life lesson.

You've typed too many words to try to rationalize your toxic behavior.

I repeat: pay attention to what you say and do. All communities have their bad apples, but this does not grant the likes of you the right to spoil the whole barrel.

That said, incels REALLY hate Naomi for whatever reason.

I think you're way out of line with the insults and broad accusations. I am bare new to the 3D printing community and I never heard of Naomi Wu before. The article only mentions she is an influencer, and this discussion makes little to no efforts to add context to why is a particular influencer relevant to 3D printing.

Calls to clarification are faced with comments like yours, accusing those of asking a simple question of being incels.

This behavior reflects poorly upon you in particular and the 3D printing community in general. Please pay attention to what you say and do.

(proceeds to cry and click on "subscribe")

So, you still have to go through all the dependencies, vulnerabilities and incompatibilities.

That's the point. There is no free lunch. Yet, you can live with stable, pinned versions and only upgrade the ones you really need to, and that means exercise your personal criteria instead of mindlessly upgrade everything just because there was a bump in a version number somewhere in an upstream dependency.

Yes, you can now kind of control the timing,

Timing, extent, scope, and impact. That's the point.

but it’s still unacceptable in my opinion, that you have to spend so much time just to not be an active danger to everyone.

You only spend the time you decide to spend. There are already vulnerability scanners that pinpoint exactly which versions need to be updated, and do that automatically for you. Mindlessly opening the floodgate to each and every change is by definition idiocy and a liability.

Then you’ll end up with tons of vulnerabilities within days.

You only end up with vulnerabilities if you refuse to update your dependencies. Updating a dependency is something you need to do yourself, along with running build validation tests after a successful update. Just because npm can download newer packages that does not mean those packages are good.

Something in the dependency tree will yell at you that it is deprecated or discontinued.

Only if you didn't pinned the dependencies you actually consume, and expect that all your dependencies magically comply with semver.

Blindly replacing dependency versions never worked, at least reliably. If you do not put in the work to ensure things work, more often than not you'll be surprised by them not working.

Also, double can and does in fact represent integers exactly.

There is no C++ tool (AFAIK) providing an exhaustive check of ALL the data lifetimes.

Your reply reads like an attempt at moving the goal post.

The initial point was "Sometimes it’s easier to try a new idea in a new language (e.g. the borrow checker in Rust) rather than trying to shoehorn it into an existing language", to which I pointed the fact that yes it's indeed possible to "try a new idea" like borrow checking, and it only takes adding a tool that runs in a post-build/unit test step. It's simpler, easier, and does not force anyone to rewrite projects from scratch.

Claiming "oh but it might not work as well" is not an answer or a refuttal.

If there was a single language, afterwards the same broken logic would be applied to frameworks and libraries, and we all know how many people bitch and whine over Java and it's extensive standard library.

Rust's borrow checker is a bad example. There are already a few projects that target C++ and support both runtime and compile-time checks, not to mention static code analysis tools that can be added to any project.

I would think you would try to perfect what you have instead of making new ones all the time.

Perfecting what you have often leads to a completely different language. See C vs C with classes which ended up being C++.

There is absolutely no problem with creating new languages. These are often designed with specific features in mind, and the success cases often offer features that are in high demand. Take for instance node.js, and how its event loop makes it a near ideal language for network-heavy applications that run on a single thread.

I think there's context missing from that story. Diagrams do not trigger disgust. At best, making superfluous and time-wasting demands in the context of trivial tasks that add nothing of value and achieve nothing but wasting time and adding overhead can often lead managers to frown upon them.

No> Context is whatever makes sense to provide to a consumer to help them debug it or respond to it

So it's both optional and unspecified. This means it can't be parsed or relied upon, specially by consumers. It's useless.

the same basic idea as in the rfc under details.

No, it isn't. Contrary to your ad-hoc format, RFC9457 specifies exactly the data type of detail and what's its purpose. This allows third parties to reliably consume resources that comply with RFC9457 while your ad-hoc format leaves clients no option other than to ignore it.

IMO, it can’t easily be generalized. Some APIs may have context to provide, others may not.

It matters nothing what services can produce. What matters is whether clients can consume it. Your ad-hoc format fails to specify this field, which is optional, and thus leaves no option other than to ignore it. It's unusable.

Success is something that you can sniff for after deserializing, as IIRC Fetch API will not throw except for a network errors, even in the event of a 4XX or 5XX.

What the Fetch API does or does not do is irrelevant. The responsibility of putting together a response and generating the resource shipped with it lies exclusicely in your service. If it outputs a resource that is unable to tell clients what went on, that's a problem cause by both how your service is designed and the ad-hoc format it outputs.

The main take is that RFC9457 is well specified and covers basic usecases, while your ad-hoc format is broken by design. Thus when you describe the RFC as "overwrought", you're actually expressing the half-baked approach you took.

Your format looks half baked and not thought all he way through. Take for instance the success bool. What info does this add that error_code and the request's own status code doesn't already send? And what's the point of context if it is both unspecified and optional?

I'm going to play devil's advocate for a moment.

following best practices we laid out in our internal documentation

Are you absolutely sure those "best practices" are relevant or meaningful?

I once worked with a junior dev who only cared about "best practices" because it was a quickly whipped document they hastily put together that only specified stuff like coding styles and if spaces should appear before or after things. That junior dev proceeded to cite their own "best practices" doc with an almost religious fervor in everyone else's pull requests. That stopped the very moment I made available a linter to the project, but mind you the junior dev refused to run it.

What's the actual purpose of your "best practices" doc? Does it add any value whatsoever? Or is it just fuel for grandstanding and petty office politics?

his code works mind you,

Sounds like the senior dev is doing the job he was paid to do. Are you doing the same?

It’s weird because I literally went through most of the same training in company with him on best practices and TDD, but he just seems to ignore it.

Perhaps his job is to deliver value instead of wasting time with nonsense that serves no purpose. What do you think?

Electron apps created with React can definitely push the boundaries of what ‘acceptable’ memory usage is.

I have a pet theory that webview-based apps are popular only because currently there is absolutely no usable multiplatform desktop GUI framework. Therefore, developers have to resort to the one thing that works: load a webpage in a web browser.

Even React Native feels like a kludge in a way it converts React components to UI components.

These small proof of concept projects just go to show how fundamentally important are projects such as GCC and LLVM, which considerably lowered the barrier to entry of monumental tasks such as developing a programming language that targets basically all platforms under the sun.

Kudos GCC and LLVM.