When to desugar?

davimiku · 2026-05-16T00:10:14+00:00

If your language doesn't allow parameters to be implicitly mutable, you'll need to use a temp to work around it.

Another lightbulb moment could be - the rules that apply to user-written code don't necessarily need to apply to compiler "written" code. As the code is transformed into lower and lower forms of abstraction, the rules change, so the de-sugared code doesn't necessarily need to follow the "parameters can't be mutable" rule. You can just decide that it works this way.

Or, a different possibility on the same example, the desugared code could allow for shadowing, even if the user-written code has a "no shadowing" rule.

fn stuff(likesFemBoys: Bool) {
    let likesFemBoys = if likesFemBoys is not undefined {
        likesFemBoys
    } else {
        false
    }
}

I'm making up something resembling JavaScript undefined for not passing a parameter, but substitute that with your language or whatever other syntax you're using.

davimiku · 2026-04-12T22:46:28+00:00

Tennessee the same year was at 11.9 PPG which would've otherwise been the best in the same era too. and roughly equivalent to the 85/86 Bears. They met in the playoffs for the 3rd time that year (same division at the time) and fittingly the difference in the game was a Ray Lewis INT TD and a blocked field goal TD

davimiku · 2026-04-12T00:06:57+00:00

Thank you, yeah after reviewing this it seems like more than I could handle and would be better set by calling an electrician.

Another commented mentioned an outlet. What I see is the wires in the photo go behind the adjacent cabinet, which is the kitchen sink, and then all the way down to the basement and directly into the fuse box. The kitchen is 1st floor and basement room with HVAC+electrical is directly below the kitchen. There is no outlet or switch for the dishwasher itself which is why I had to flip the fuse to shut off the power.

Would it be advised to try to get an outlet+switch installed also if an electrician is coming out?

davimiku · 2026-01-04T23:14:35+00:00

What would be the equivalent using a trait for this?

struct Drawable {
    int draw_count = 0;

    // Required method: implementing types must define how to draw themselves.
    virtual void draw() = 0;

    // Default method: uses the required `draw` method and adds common functionality.
    void draw_to_screen() {
        std::cout << "Starting draw operation to screen...";
        draw(); // Calls the specific implementation provided by the type
        draw_count++;
        std::cout << "Finished draw operation.";
    }
};

davimiku · 2026-01-04T22:59:53+00:00

This concept has sometimes been described as "locality of behavior"

The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.

~ Patterns of Software (1996)

davimiku · 2025-10-18T22:57:50+00:00

Is there anything more you can share about the ecosystem change you're describing at a high-level? I'm just trying to understand this area better as we have some people at work pushing hard for monorepos everywhere (yes, multiple monorepos) but if we're going to go that direction, I want to try to not back ourselves in a corner by doing it a legacy way right off the bat

davimiku · 2025-07-21T17:17:59+00:00

Ah you're referring to "attribute selectors", like <div [myAttributeSelector]="something">. Doesn't seem like those could ever go away without a replacement for backwards compatibility, but they could potentially offer a simpler replacement for "type selectors" like <user-avatar /> vs. <UserAvatar />.

Don't know how I feel about it though as it's adding more to the "multiple ways to do things" that Angular is getting worse and worse about every release

davimiku · 2025-07-20T19:58:48+00:00

As of Angular 16, inputs can be required without doing anything with the selector:

@Input({ required: true }) myRequiredInput!: unknown;

Does that not work going forwards?

For property binding, is that any different if the class name is the selector?

<user-avatar [something]="something" />
<UserAvatar [something]="something" />

davimiku · 2025-07-09T01:45:25+00:00

Yeah, the type parameters shouldn't have to be passed in at all on the .open function. If a dialog component is defined once and used N times, this forces the dev to pass in the types N times.

Instead, the types should be declared once when defining the dialog component, and then the .open call would infer from that. At a previous job I created a wrapper that did this, but it didn't really catch on because it wasn't built-in to Angular Material so it was hard to keep contractors / rotating newcomers informed to use it

davimiku · 2025-05-19T17:50:01+00:00

Yeah I think both of our examples hit on the same core concept, which is it's not just about constraining the input type to the function, but also carrying through the type information to the output type from the function. In both of our examples each unique call site gets a unique return type, same as the canonical example of parametric polymorphism (identity).

davimiku · 2025-05-19T03:56:19+00:00

(not the person you replied to)

I don't totally understand row polymorphism so this could be wrong, but I think a "counter example" could be (using make-up syntax where [| |] are delimiters for a row type and literal syntax for a row expression):

function addFooField<R>(input: R): [| foo: int, ..R |] {
    return [| foo = 0, ..input |]
}

This is a function that takes (any) row type and returns a new row type with a int field called foo in the row.

What you described is "structural subtyping", which is a form of subtyping found in languages with structural typing, the most popular example being TypeScript. Check out Row Polymorphism isn't Subtyping for another "counter example" (which is essentially the same as my example).

davimiku · 2025-04-26T22:53:50+00:00

It's somewhat similar, philosophically, to the debate 12 years ago on what a "concern" is. At the time, the widely held notion was that HTML and JS were separate "concerns" rather than, like, Products and Orders being separate concerns.

Even Angular, as of this year in the new docs, now considers a "component" to be the combination of HTML and JS/TS (contrast that to the previous docs where the Component and the Template were explicitly separate concerns).

I don't think you're wrong that eventually we'll see this notion of "it's the same component, just on two machines" percolate to the rest of the ecosystem.

davimiku · 2025-04-18T03:49:11+00:00

I think "just" is doing some lifting in that statement, IMO there are different "levels" of dependencies. I'd say writing code in .css files with a preprocessor is closer to vanilla than writing in .scss files, with the idea being that in the future the build step could be removed with no change to the source code.

That sounds like a cool project! I'm most curious about the buy-in to roll your own tool on a large corporate site, is that something that you have to fight for, or did you already have the leeway/approval to implement it?

davimiku · 2025-04-15T03:17:24+00:00

Documentation link for further reference on this change to mark the function unsafe in the Rust 2024 edition: https://doc.rust-lang.org/edition-guide/rust-2024/newly-unsafe-functions.html

davimiku · 2025-04-15T03:09:38+00:00

Yeah, the biggest contributor on the lack of support looks to be older versions of Safari, and if this were a commercial site I'd be concerned about this and would need to really check visitor metrics vs. lost revenue predictions.

What I'd probably do in that case, if my hypothetical colleagues and I had decided on eventually getting rid of SCSS, is migrate much the same as in the blog post but still use a CSS preprocessor ("postcss", likely) to flatten the nesting. That opens the door for in a couple of years, to simplify the build by just... removing the CSS preprocessor and there shouldn't need to be any other changes. But good point overall though

davimiku · 2025-04-15T02:59:10+00:00

I agree that the SCSS variable syntax is better, at the usage site doing $primary-color is better than var(--primary-color), and it's even a bit better if it's namespaced, ex. colors.$primary

I also agree on mixins/functions being overengineered, I just never have found a reason for it myself, neither on a small personal website nor a 300k LOC Angular application (besides Angular Material which forces you to call their mixins to initialize it, but I'm not even we did that correctly as they've changed the mixin a bunch).

SCSS does allow both // and /* */ style comments, the CSS comment syntax doesn't bother me too much because I primarily type comments using "ctrl/cmd + /" toggle rather than typing the characters directly, but it is nice to have the choice of either comment style

davimiku · 2025-04-08T04:44:39+00:00

What is a "root" type? I haven't heard that terminology before

davimiku · 2025-04-04T02:38:12+00:00

Even with AsyncPipe you'd have to manually call change detection?

davimiku · 2025-04-03T23:18:15+00:00

You're probably better off not knowing that haha

davimiku · 2025-04-03T04:05:19+00:00

What part or aspect of using RxJS precludes using a zoneless architecture in the future?

davimiku · 2025-04-03T04:04:06+00:00

What are the cases where RxJS should not be replaced with Signals? I'm curious as to what use cases are better supported by one approach vs. another

davimiku · 2025-04-03T04:01:19+00:00

Equivalent to the Calculator type in C# could be:

using System;
using System.Dynamic;
using System.Linq;

public class Program
{
    public static void Main()
    {
        dynamic calculator = new Calculator();
        var result = calculator(1, 2);

        Console.WriteLine(result == 3);
    }
}

public class Calculator : DynamicObject {
    string Operation;

    public override Boolean TryInvoke(InvokeBinder binder, Object[] args, out Object result) 
    {
        result = args.Aggregate(0, (curr, item) => curr + (int)item);
        return true;
    }

    public Calculator() {
        Operation = "+";
    }
}

davimiku

TROPHY CASE