lazulicurio

This is a huge shame. Ondsel brought much-needed focus to the freecad development process.

I hope that with them gone the project doesn't revert to the mindset of "everyone gets their own fiefdom (workbench) to manage" that's resulted in instabilities and fractured user experience in the past.

Just to start, I want to acknowledge that the problem space is tremendously complex; the FreeCAD developers have put in a lot of effort and it's amazing that a project like FreeCAD exists at all.

Not trying to disrespect the other FreeCAD developers, but it seems like things have improved remarkably since ondsel started taking a more active role.

The project seemed to exhibit a (common) impulse to prioritize extensibility too much. The "workbench" architecture and python API let you do some really neat stuff if you're willing to dig into the weeds. But, from the perspective of a community outsider (so take it with a grain of salt), the development process seemed to be a good example of Conway's Law in action. The workbenches let everyone have their own sub-projects to manage without stepping on each other's toes. This led to a lot of resulting complexities, inconsistencies, and instabilities, which made the approach a net negative (imo) in terms of tradeoffs.

With ondsel, there's been more focus on holistic improvements and getting the individual modules working together more smoothly, which I greatly appreciate.

Seconding the plug for sh3d. And the source is relatively accessible if you want to make modifications---I patch my personal copy to allow zero-height walls and floors which can make doing more complicated geometry easier.

Are you on linux? For a while I've been running into issues with FF where it will randomly halt repainting after switching tabs. The process is clearly still responding to keystrokes and mouse events, but the ui is mostly frozen.

I've also been running into an annoying issue where hover menus will randomly stop working---it seems like the mouseout event is firing before the click event is handled.

But all in all not annoying enough to switch.

Yeah, having equals and hashCode on the root Object class is Java's biggest mistake, IMO. Although for a slightly different reason: equality is usually context-dependent, but having equals as an instance method ties you to one implementation.

It's a tad more verbose, but I assume the simplest way would just be to use a standard closure.

    void log(Supplier<? extends String> messageSupplier);

    log(() -> log.info"User is \{someExpensiveFunction(user)}");

The pattern of using Supplier to provide a lazy argument is pretty well-established afaict.

To be somewhat glib, let me coin "lazulicurio's law":

The only way to have the option to have your preferences met in a large and mature enough market is to be completely price insensitive.

Irrational investor expectations in a self-reinforcing feedback loop with economic policy decisions driven by core underlying beliefs that speculation can't destroy productive growth (i.e. if you create a bubble that pops, you'll still be net-positive compared to before the bubble) and that speculation is the best way to create growth in a population-constrained market.

> but the Senate may propose or concur with amendments as on other Bills

Of course, this is a loophole big enough to sail a cruise ship through. And the Senate takes full advantage of that loophole in practice.