225 karma · joined August 2, 2022
But how much of our math is just a poor approximation of our universe? Like Newton's gravity was.
If our math only _approximates_ the world, if we discovered something that explains things better, it would all be irrelevant.
There are a lot of hints that something big is missing in our maths as a means of explanation. Like the mathematical constants Pi and Euler repeating infinitely, quantum randomness...
E.g. "Why is the speed of light what it is?".
~300,000,000 meters per second. But the definition of a meter is actually defined by the speed of light, so this number is very human-math-specific.
So instead, you want to look at the speed of light in terms of other physical constants to find a "dimensionless" constant.
This leads us to the fine-structure constant[1], which is a single number that pops out when you relate a few of these experimentally measured constants to each other.
0.0072973525693 ≃ 1/137
This is a number that if any different would mean the universe would not exist in the way it does.
Something very human is the notion of "1". Counting things is very important to intelligent life.
I was thinking the other day, about the world from the perspective of a tree. It doesn't care about counting things. So "1" is irrelevant to it. It's an invented concept by humans.
And most of our mathematical thinking is based around this.
There could be an infinitely deeper and more complicated maths to explain things.
It's like looking at a leaf without a microscope to figure out biological processes. Until the 1600s, biologists could only study what their eyes could see.
All this quantum randomness feels like we are still just looking at a leaf with our eyes.
[1]: https://en.wikipedia.org/wiki/Fine-structure_constant
[2]: https://en.wikipedia.org/wiki/Dimensionless_physical_constan...
[3]: https://en.wikipedia.org/wiki/Physical_constant#Number_of_fu...
I had thought XAML was it and was ahead of the game, but it's kind of a different approach.
All the new ones define their declarative UI as inline source code.
I remember a while back there was contraversy that MS wanted people to write Windows apps for store in TypeScript. What happened to that?
I always wondered why it took until Win UI _3_ to decouple...but I guess this is why.
I remember when the Ribbon UI came out. And there were like 10 different vendors making all different ones, each with a different look and feel.
Just like Amazon took internal services and made them exposable in AWS, so should Microsoft with every UI component they build. You shouldn't be able to ship any UI internally, unless you make it publically accessible. I guess WinUI 3 is heading in these direction by decoupling from the OS. But boy it took a lot of time!
WhatsApp Desktop uses WinUI.
WhatsApp is superior.
I don't get React Native. It's such a huge, complicated abstraction with no ability to performance tweak. I don't understand how a company as big as Facebook doesn't have enough resources to build native apps for each platform. These UIs are the simplest app you could build as well.
It feels like they are trying really hard not to annoy developers by telling them their stack is now legacy.
They should take all old technology and put it on an entirely different docs website.
> We've been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform. > >-- Steve Jobs - https://www.engadget.com/2010-04-10-steve-jobs-responds-to-c...
I've heard Steve say this a few times, and it always caused developer backlash. But having seen how things have played out, I think he was definitely right.
Honestly though, Windows should have just gone with HTML. The majority of HTML-based apps are nicer looking and feeling than Windows apps, and the perf is fine. I just don't know how they f'd up XAML/WPF so badly.
This always infuriated me on Windows, and a big reason I moved to macOS.
This is a great read: https://arstechnica.com/features/2012/10/windows-8-and-winrt...
> ...the biggest problem is that USER [API] is essentially inextensible. If a developer wants to create, say, a menu that acts exactly like the standard operating system menu but with some small extra feature (for example, he might want to support the drag and drop, similar to the Favorites menu in Internet Explorer) he generally has no option but to reinvent the entire menu system from scratch.
Seems like the failure of the Longhorn project really messed things up. It was suppose to replace the janky old win32 with .NET managed APIs.
I just remember XAML/WPF/.NET being incredibly slow. And choosing a managed language for OS stuff seemed bad. I can't believe no one was doing a quick POC and saying: this is too slow.
You have to give credit to Apple platform team. They have some real visionaries there. They had the guts to ignore garbage collection even when it was taking over the entire software industry. I guess MS just needed a competitor for Java.
I have never had so much confusion in my life. WinUI 2, WinUI 3, C++/WinRT, C#/WinRT, C++/CX, C++/CLI, WinRT (Windows Runtime - that's not a runtime), COM, C++ Win32, C# .NET, UWP, Fluent, Metro, .NET MAUI, PWA, React Native for Windows, WPF, Windows Forms, Windows API, Windows App SDK (which is WinUI 3), VSIX, XAML, .winmd, WebView2.
When I think about macOS: Swift + SwiftUI, Swift/ObjC + AppKit.
This article was a huge read but helped me get an idea of things: https://arstechnica.com/features/2012/10/windows-8-and-winrt...
I think the issue is that the writers are trying to be too delicate to not make people feel like their apps are using legacy technology that will be deprecated.
> Many apps for Windows are written using WPF or Windows Forms, and they remain viable tools today...looking to the future....
There should be one obvious recommended way to build new apps, and all the other docs should be moved to a separate section.
And when I install Visual Studio 2022, it has a "Workload" called "Universal Windows Platform"...but I just read this is deprecated!!
WhatsApp seems to use UIView, but I couldn't find evidence of SwiftUI, so am assuming its just a UIKit app.
There are some very similar UI components to the mobile app, so I am guessing they want to unify as much as they can between the two codebases.
WhatsApp Windows seems to be a native Windows app.
There is a lot of good wisdom from the 60s, 70s, 80s that people forget and end up re-inventing. I don't think I'm the first person to make this comment.
> OO
It's very subjective I'll admit. But I don't like OO, and it took me along time to realize why. There are many people who feel the same way. The difficulty is in explaining it. Because you have to look at large systems, explore the evolution of these systems, and pluck enough examples where things don't work.
It takes a while to develop a fascination for the internals of programming which comes after you start building things.
The problem is that a normal person would look at the industry, look at what is the most popular, and think: this must be the way it should be done.
But pick any point in programming history and you would then just be learning the latest fad.
And you can only know how bad something is until you understand it completely in both theory and real-world experience. Only then are you adequately able to criticize it. So when the new hyped thing breaks through to adoption, its then at least 10 years until people can adequately point at the holes in it...and see which stick around and which get fixed.
Yet every single new thing, people still convince themselves that this is the way of the future forever.
I think an unbiased History of Programming Languages is probably the best thing people can learn. After learning a few modern languages of course. Then you can see why things are the way they are.
It's funny to hear people criticize frontend for churn - which is true. But at least the language has stayed the same. Backend is actually incurring a lot more churn in not only the libraries and frameworks like in the frontend world, but the whole programming language too.
Look at how much time we lost with OO. I am only recently coming to grips with how bad it is. C++ was the "thing you are interested in today" back then. And it wasn't well thought through.
What were people doing before Rust?
C is great.
> several better options these days
Every other option requires you to buy into some additional paradigm-of-the-day.
You can easily lose decades going down the wrong programming rabbit holes.
Me too! I think its wayyy over-hyped. The biggest challenges in software are architecture. Object boundaries. System composition.
And I'm a big believer that all the software we write today is shit. So GPT is just regurgitating bad practices.
Once you get it, you will realize how much of a game-changer it is. This is the reason Bun is going to win.
People get so intimidated by these huge frameworks and get FOMO, that they never try to build something from scratch.
React seems simple, but if you tried to understand what is going on under the hood it would take you months.
Simple should be: can you trace through all the code yourself. Like Backbone.js for example.
Plus, there is already so much rendering complexity under the hood in browser engines. The DOM and CSS are already incredible abstractions available for you to use.
I really don't get what is so bad about just having some object to manage a dom element's rendering.
Create a single relational source of truth for your data. Then create some view models that listen to this source of truth. Then make your objects listen to these view models.
This vdom diffing stuff is so overated.
If you have a list of items, and a new item is inserted, I can just insert that directly into the dom. If I render a different entity and it uses mostly the same dom elements, it's really not that hard to tell say: here are some new props, compare them with your old ones, and do what you think is best. React promises this for the entire app but its all magic. I want control of my rendering so I can make things fast. Debugging perf issues in React is insane. Good luck debugging anything.
Declarative build systems obfuscate so much without providing the proper debugging and error-handling capabilities.
Build systems should be imperative and type-checked. A simple script that a user can step through and observe what is happening.
Makefiles suck because they are not type-checked.
The only abstraction you need is some kind of dependency graph. But then it should be completely transparent to the user so they can easily understand it.
Graphdb would be ideal.