nous @ nous @programming.dev

Posts

0

Comments

716

Joined

2 yr. ago

Well, that is how bubbles form. People will stop investing while/after it has burst. That is basically the definition of a bubble bursting.

But it increases investors likelihood to invest... That is all that really matters these days.

What non-profit company did you get the computer you are currently using to type these messages from?

There is a big difference in planning server layouts and similar tasks and writing pseudocode. In comparason the planning is much cheaper and the cost of getting things wrong can be quite high. But with pseudocode, it is not that much cheaper to write than real code is, it gives you a lot less useful information and the cost of a mistake is quite cheap in code (that is while you are still developing things and for the types of problems pseudocode might even be able to catch).

By "forever" they mean you will be paying them forever for the privilege of using the mouse. Unless you break it that is, or they feel like they no longer want to support it at which point it will likely become a forever brick.

I just got a Sovol v8, using it with orca slicer on Linux without any issues. Orca slicer has a GPL license. Sovol v8 is based on the voron v2.4 printer and sovol have released the source and 3d files for the v8: https://github.com/Sovol3d/SV08 and its firmware is based on the open source klipper firmware. So overall is quite an open designed printer. Those are the big reasons I went for it and would highly recommend it if it is within your budget (which gives you quite a lot for its cost).

But quite a lot of printers use and/or are compatible with most popular slicers of which most are open source. I think bamboo labs printers are the major one that is not open by design. Though I admit I have not been that emersed in the available printers in recent years.

Nah, if you have some complex logic you are not sure about then you need to see it run to be able to see how it reacts to changes. You cannot run pseudocode so it is far harder to validate it will do what you want it to do.

I fundamentally disagree with pseudocode and all the arguments made out on this um, paper? It is written by a educator who has seen lots of shitty unreadable student code which is about the only time pseudocode makes sense to write. But even then, if they cannot form what they want in code what makes making them form what they want in words any better?

But spending ten minutes to think out carefully the pros and cons of different approaches to the goal can save you hours of time debugging and refactoring your code later on.

I find the opposite. Spending time writing pseudocode leads to far more time wasting on things that don't work. One of the biggest problems with pseudocode is YOU CANNOT RUN THE CODE. Not until you have fully finished thinking about it and then converted it to actual code. Only then can you tell if the code even does what you want. No, far better to write a small segment of code and then incrementally build and test it little by little. Then I can verify my ideas are taking me in the right direction and not resulting in some weird behavior due to some broken assumption I made early on.

Incremental development is the way to go. Just test things as you write them. Don't write the whole program (and then rewrite it again in an actual language) before you ever even run it. Write a small bit, test it, refactor and continue. You cannot do that with pseudocode and it is vastly harder to debug something that is complete rather than incrementally checking it at every stage as you progress.

Pseudocode makes low-level design reviews easier and reduces the need to review the code itself.

No, no it does not. You NEED to review the source code to see if it does what the person thought it would do. This step cannot be skipped. So what value does pseudocode add then? The code should be readable enough on its own without basically doubling the amount of lines you need to read. Plus NO ONE READS COMMENTS. This comes from 15+ years in the industry. More often then not I see comments that are out of date and no longer describe the code they are talking about. It is a lot of effort to keep comments in sync with code and not worth the effort. There should be no pseudocode comments in your code at the review stage.

Pseudocode supports the idea of iterative refinement

Iterative refinement is vastly better when you get feedback on what you have written. The best place to get that is to run the code and see what it does (either manually or via testing). You cannot do that with pseudocode. Only hope that you can spot a problem, which more often then not you will not. If you write actual code you can run it and see if it fails and how it fails.

Pseudocode makes changes easier. A few lines of pseudocode are easier to change than a page of code

That is a false comparison, why would you only have a few lines of pseudocode and a whole page of code? Surely your psudocode will roughly match the number of lines of actual code? Otherwise what is the point in it and how will it help you spot any problems? You can always write real code as a series of function calls to hide away the implementations if you want a similar approach.

Pseudocode minimizes commenting effort

Not writing comments minimizes commenting effort. Comments should be used sparingly to describe things that cannot be describe in code. IMO the only comments worth while (at least ones that are not doc blocks) are ones that describe external factors. Like "this is to work around this bug

<link to bug report>

With other approaches, design is separated from the code, and when one changes, the two fall out of agreement... As long as the inline comments are maintained, the pseudocode’s documentation of the design will be accurate.

That is a big if there, IF they get maintained. Which they wont. It is far too much effort to edit the code twice. No one wants to do that and so no one does do that. Just read the code if you want to know what the code is doing and reject PRs for code the is unreadable.

The only people I ever see arguing for psudocode are professors that have never worked in the industry and spend far more time reading crappy students code than anything else. I have never seen anyone actually do this in production systems.

You can have backups of physical books. Just copy the text from one to the other. Yeah it is manual work but so is writing the first one in the first place. You can then store the second copy in a fire resistant safe or at a friends or family members house (maybe inside a safe as well).

I just gotta figure out how you subtract material and it increases surface area.

Say you have a smooth shape like: ███ That has a nice and simple area and surface area. But if you take a chunk out of it: █▂█ you now have less area, but surface area is the same plus those two new vertical walls - so it has increased. That is basically what roughing up the surface does. Might also do some deformation and add some peaks as well though far less than the material removed.

This all leads into the coastline paradox and fractal patterns which show that you can have a finite volume surrounded by an infinite surface area. Here are some interesting videos on the topic: https://www.youtube.com/watch?v=AD4vPNBSrKY https://www.youtube.com/watch?v=I_rw-AJqpCM https://www.youtube.com/watch?v=gB9n2gHsHN4 https://www.youtube.com/watch?v=3s7h2MHQtxc

Perhaps the roughing up of the area permits for micro-gaps which allow for the two to better stick?

I think it is more to do with increased surface area - more molecules of the glue are in contact with the part.

That should not break things though. Maybe get a merge conflict that you need to sortout at worst. This is essentially the constant state of working with other people on a project.

I don't see why you need a separate builder when you are trying to build the app, even if the app is a third part thing you can still build it as part of the final method. Assuming there are no other options needed.

The basic idea behind the builder pattern is to ensure the main thing can only ever exist in a valid state, no half valid values letting you call things in weird ways that break.

Here AppSettings is not the thing you care about, the App is. So you can think of AppSettings as a builder for the App. A final call to it should construct a valid App and you should not be able to do that when the settings are invalid.

If there are one or two required fields the having those on the new method of the AppSettings or the final build method that constructs the app is a good approach. If there is a set order things need to be created in then the generic state pattern or multiple structs can be used instead to limit what functions are available at each stage.

I have never had git get into a state I cannot get out of. Even if that is a reset, checkout or clean. And those are very rare. How are people breaking things so often.

Learn the tools you use daily, it saves you a lot of headache in thelong term.

Where did you get that from?

https://small-modular-reactors.org/smr-cost-estimates/ suggests the opposite:

$2,000 to $6,000 per kilowatt for SMR vs $4,000 to $9,000 per kiliwatt for large scale ones.

Plus they don't take 10+ years to build, and each one is not a bespoke construction leading to better scalability as the more you can build the cheaper things become.

Ideally yes. All core files would be handled by nixos. Except I doubt that is how crowedstrike would work on nixos if it existed on nixos.

Crowedstrikes downloads and manages it own definition file that gets updated multiple times per day. It is this file that was malformed causing the driver to break. This needs to be updated regularly, more then other packages and so would very likely not be something managed by nix package manager but more treated as application data and outside the scope of the nix package manager.

This is how updates to steam and discord are handled in nixos. Only the core updater is packaged and the rest of the application is self managed. So there is a precedence for this behaviour on nixos (although these won't break your system if a bad update happens as the files are in your user dir).

That assums the file is not stored on a writable section of the filesystem and treated as application data and thus wouldn't survive a rollback. Which it likey would.

Nixos still let's discord and steam download their core files independently of the configuration. These get stored in the users home dir but are effectively not part of the immutable promise. I believe that the crowdstrike problem was caused by a file updated in a similar manor. So would have been an issue on any distro. That is one big problem with a driver relying on files outside the package managers control. At least with steam and discord they cannot take your whole system down.

You don't share code between monorepos, the whole point of a monorepo is you only have one repo where all code goes. Want to share a library, just start using it as it is just in a different directory.

Submodules are a poor way to share code between lots of small separate repos. IMO they should never be used as I have never seen them work well.

If you don't want a mono repo then have your repos publish code to artifact stores/registries that can be reused by other projects. But IMO that just adds more complexities and problems then having everything in a single repo does.