Hacker Newsnew | past | comments | ask | show | jobs | submit | nogridbag's commentslogin

I had this same question recently. There's mesh networks like meshcore. But you would be limited to just sending text messages to other users. I would imagine the government would be able to easily identify and destroy such a network as well.

Programming a VCR was pretty trivial for me as a kid, but a bit annoying.

But then VideoGuide [1] was released (available from RadioShack). I begged my parents for that and honestly it was the most amazing product and worked flawlessly. I felt like I was living in the future.

[1] https://www.youtube.com/watch?v=aWzJuqkQbEQ


I believe that's always been a thing. A long time ago I read this teardown article [1] of real vs counterfeit Beats headphones. And even the counterfeit versions had metal weight added to make it feel like the real Beats headphones!

[1] https://blog.bolt.io/our-beats-were-counterfeit/


I consider myself above average with UI design, but I still got confused with that dang "i" icon in the Preview app just yesterday.

I had to add my signature and write in the date so it looks like it was handwritten. So the plan was to just draw the date with a pencil tool and if that failed use the text tool to write the date.

First I instinctively clicked the pencil icon which turned out to be a highlighter. That's a great example where if they had added color for the tip and line it would have clearly looked like a highlighter. After that failed, I clicked that "i" icon because it looks like it's for inserting text. Honestly I was in such a rush I didn't even see the info pane popping up and was dang confused when nothing was happening.

I'm very familiar with info icons and have used them in my own apps, yet I had never seen one without the circle around it.


Those mini screenshots do not look like anything like what's in the "Screenshots" section:

https://imgur.com/a/svQaeCa


Wow that looks very different to what’s on the front page! Where did you find that and where can we see how it really looks then?


Are there any plans for supporting other databases? Our company primarily uses and has experience managing MySQL deployments. I evaluated Temporal some time ago as it seemed like a good fit for what we're building so I'm watching this closely. Thanks!


Our primary focus is Postgres. DBOS Python recently added SQLite support, we'll add this to other languages if it proves popular, but no current plans for MySQL.

That said, while DBOS requires Postgres for its own checkpoints, it can (and often is) used alongside other databases like MySQL for application data.


To build on what Peter said, we need to stay focused and make one backend solid before expanding. But architecturally, nothing prevents us from supporting more engines going forward.


The OP is real time ray tracing which is running between 30-60FPS on my macbook air while moving the camera and objects around.

Your link appears to be a basic ray tracer which anyone who has taken an intro to computer graphics course in college is likely required to implement and would only need a javascript canvas. To be honest I have no idea how much OPs real-time ray tracing differs in complexity from traditional ray tracing.


You don't even need a canvas.

You could simulate pixels with divs if that's all you had. Or you could create an image in memory and save to file. You could write the text for it and save as SVG.

For a CPU based ray tracer, you don't need any output capability at all(unless you want it to be interactive, which school assignment raytracers usually don't have to).


I've used several MVC UI frameworks in the past both on the desktop and web, and they all had the same problems. When the view becomes out of sync with the model, it becomes a nightmare to figure out why that's happening.

You have your model (data), and conceptually, you just want to bind that model to the view. But you have to write all this imperative code to do that. It's very simple with an imperative UI to have infinite loops even with very simple UIs. "When this field changes, I want to update this other field". But that other field has it's own event listeners that trigger other effects. The event listeners work fine in their own silo, but the interactions between fields cause unintended effects that are not obvious reading the code.

When the component is mounted, the behavior is very hard to reason about and you spend lots of time in a debugger tracing through all the event listeners just to reach the initial state of the UI. Additionally, in these frameworks the developer is typically responsible for cleaning up all the event listeners. It's very easy to forget to clean these up properly.

Once a UI reaches a certain complexity, you try to rewrite the imperative code so that it almost reads declarative and you wish you could simply use a declarative UI framework. I can't speak for React as I have not used that in a long time, but in Vue.js I never write the UI to use global state. All state is local to the views that it pertains to and with defineModel introduced back in late 2023, you can write small UI components without all the plumbing required in earlier versions. I've never experienced such a simple and reliable UI framework previously.


Author here.

> "When this field changes, I want to update this other field".

That's the problem MVC solves, and that not just a vast majority of so-called MVC frameworks (that are nothing of the sort) get fundamentally wrong, but also a lot of people talking about MVC, in particular those who want to "fix" this non-problem of MVC (see: React).

In MVC, fields never update other fields. The model also doesn't update any fields.

1. UI events update the model, and only the model

2. The model notifies the UI that it has been updated, and the UI is now inconsistent. It does not initiate an actual update, nor does send data to the UI.

3. The UI fixes the inconsistency by updating itself from the model. This can be a full update, or it can do something more clever to only update parts it knows have changed. This may be in response to an update notification or not.

No update loops. No inconsistencies (well except the temporary ones until the UI has updated itself, but those are part of the deal). Solved in the 70s.

I wrote about this here: Model Widget Controller (MWC) aka: Apple "MVC" is not MVC

https://blog.metaobject.com/2015/04/model-widget-controller-...

And here: Blackbird: A reference architecture for local-first connected mobile apps

https://blog.metaobject.com/2022/06/blackbird-simple-referen...


The update loop occurs as a result of step 3 in which the UI updates itself from the model which then, due to a combination of developer inexperience, UI framework design/complexity, or application complexity, the UI then automatically triggers updates to the model. In my experience, this was a common defect in all applications I've seen that used various MVC style frameworks or home grown MVC architectures.

In a declarative framework, while it is still technically possible, it is very rare. The current app I'm working on is one of the largest front-end apps I've worked on (multiple years of dev). We've had a single infinite loop issue reported that was trivial to fix. We have very junior UI devs compared to teams I've worked on in the past, yet our UI defect rate is incredibly low.


> The update loop occurs as a result of step 3 in which the UI updates itself from the model which then, due to a combination of developer inexperience, UI framework design/complexity, or application complexity, the UI then automatically triggers updates to the model.

In an actual MVC framework, that can't happen.

By which I mean: it cannot and does not happen as a side effect of normal processing that you need extra skill and care to avoid.

Because updates to the UI only come from the model (but pulled by the UI when it is ready) and do nothing else. Changes to the model from the UI only come from user input and only from user input.

As an example, I can't recall every having to deal with this problem in NeXTstep/AppKit/Cocoa in the last 35 years.

If this situation is something that can and does happen just as an emergent effect of normal processing and takes extra care, effort and skill to avoid, then I would argue what you have is not a real MVC framework.

You can obviously always add bugs to programs by just putting them in manually, like, abort() or while(true) {}.


Oh…and on the other hand update loops seem to be quite common in “declarative” SwiftUI.

Go figure…


> It's very simple with an imperative UI to have infinite loops even with very simple UIs.

That's something that reactive UIs inherited from the imperative events by design. It's not a differentiator here. You may be able to debug them better, but infinite event streams are pretty much still an issue, and about as easy to get.

Anyway, almost every problem in the article is a react problem, not a FRP problem. Vue may not have them, I don't know it well enough to say (but some do really look like a FRP in javascript problem, so they should apply there too).


I went through the Crafting Interpreters book with modern Java. I posted this on reddit, but I basically used records and sealed interfaces. With modern Java there's no need for visitor pattern.

    private void execute(Stmt statement) {
        switch (statement) {
            case Stmt.Expression expression -> evaluate(expression.expr());
            case Stmt.Block block -> executeBlock(block.statements(),
               new Environment(environment));
            ...

    public sealed interface Expr permits
        Expr.Assign,
        Expr.Binary,
        Expr.Call,
        Expr.Function,
        .... more exprs here


Interesting. Almost all my actual experience writing Java is in Java 8, so I'm not super familiar with the modern stuff (other then a few things like Records). I'll have to take a look.

Most of the people I know who write Java would have an aneurysm at seeing a switch statement.

To be clear, that's a critique of the Java mindset, not your code. Lol


How does Magit handle complex merges? The website shows simple diffs. In my experience, merging is something where a great UI can vastly simplify the process. I personally use SmartGit which I find is fantastic for diffs and resolving conflicts.


> How does Magit handle complex merges

Like most of the things in Emacs - with variability that can suit [almost] every scenario - you can simply accept upstream or downstream changes with a keypress; use plain (line-by-line) diffing or 3way-merge diff UI; you can go through every hunk and precisely control things, while (if needed) rewriting the code; you can delegate the task to the external tooling;

What's great is that all that is happening in your editor - you can always bring another window next to your conflict resolution to compare with context in a different branch, revision or stash; you can jump from a diff pointing to a file to open it in Dired - directory browser and editor, where you can also get the log of changes pertaining that file only (or any marked files and dirs in the filetree). You can even ask LLM to help you at precise point, by just marking a hunk and sending a request - without context switching, without losing your focus.


It shows you conflicting files. I normally resolve each via ediff or my IDE and then go back to magit. It’s not a diff/merge tool.


Ediff and smerge are both fun to use in Emacs.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: