The coil whine is present when the display is powered only from MacBook.

Uperfect monitors support power pass through which actually removes the coil whine.

So plug MacBook power source into the monitor and connect monitor to the MacBook. This way the mac gets all the power and the monitor won't whine.

Marks view's property as reactive. Like React's useState() or Vue's ref().
Triggers rendering when changed.

@Binding

Same concept as v-model in Vue. Marks view's property for 2-way binding.
Modifying the property inside view will propagate changes outside.

ObservableObject Protocol and @ObservedObject

class OrderModelController: ObservableObject {
    // @Published notifies watchers when order is modified
    @Published var order: Order
}


class SomeView: View {
    // This may cause issues during re-render when the @ObservedObject is owned by view and is not injected
    @ObservedObject var orderController = OrderModelController.load()
    // ^ Use @StateObject in this case.
}

In general you want something like this:

// SomeView.swift
class SomeView: View {
    @ObservedObject var injectedState: MyState
    init(myState: MyState) {
        self.injectedState = myState
    }
}

// SomeModel.swift
class SomeModel: ObservableObject {
    @Published var stateVariable: MyState

    init() {
        // initialize model
    }
}

// We are sharing the state from top to the bottom.
// This prop drilling can be mitigated by
// Entrypoint
// MyApp.swift
@main
struct MyApp: App {
    @StateObject private var myState: MyState

    init() {
        self._myState = StateObject(wrappedValue: MyState())
    }

    var body: some View {
        // View here
    }
}

Is it even good question when it is closer to english than any other programming language?

My bet (and hope) is that SQL will be more common knowledge as spreadsheet formulas are.

It's expressive and quite powerful and get works done. I would say that it is much more easier to write than it is to read.

Composing queries in your head will make sense to you as you go step by step. Reading others larger SQL statements will be challenging as you try understand how the other person went to solve a problem.

Quite a lot of "Explain SQL AI" solutions popped up lately. And I get it that there is a need to break down the SQL to natural language. But the question is: Can you trust it? Nope.

So, we are not leaving the code anytime soon. And that's good thing! How to present SQL to novices or people new to the field?

If only there was a SQL to Spreadsheet formulas translation. But there isn't and it wouldn't make things easier based on my experience with large nested formulas from complicated spreadsheets.

Currently, my best solution is to break the SQL query into series of simpler steps and display it as a visual graph. Where you start at the left and work towards to the right. It's not perfect but it is deterministic and doesn't hide any details. The vision is to invite users to learn not isolate them. At the end of the day, who would take responsibility for outputs that they can't verify or trust?

A nice side-effect of this approach is the ability to run query partially and understand the temporary results. It's not perfect but it's much better than big SQL snippet.

Each Token will take up 40B + size of enum discriminant - 1B (tag) which will be aligned to 8B because entire structure needs to be aligned by the highest data type size (usize or String (ptr inside is 8B)) which is 8B.

struct Span {
    line: usize,   // 8 bytes
    column: usize, // 8 bytes
}

enum Token {
    Identifier {
        name: String,  // 24 bytes
        location: Span // 16 bytes
    },
    Number {
        value: i32,    // 4 bytes
        raw: String    // 24 bytes
    },
    If(Span),          // 16 bytes
}

It is time to give it a shot and create brand new scripting language that is secure by default.

What security means in this context?

• capbalities for io, networking etc.
• safe to run untrusted code
• memory limits and fuel backed into runtime
• embeddable into server environments allowing user scripting
• allow injecting host functions into the runtime

The main goal is to have runtime and allow user scripting without relying on OS APIs.

Every single general-purpose programming language assume that code is written by trusted programmer.

If it was easy to turn any programming language into safe one, this page wouldn't exist.

Why not WASM?

WASM is promising runtime and combined with WASI, it should be useful for sandboxing other programming languages.

But using WASM prevents to see what would be possible if langauge itself was built with sandboxing in mind from day 1.

They say: "Treat it like a tool".

But how can you instruct the tool without "talking" it to it like a human?!