> the third party, unaffiliated, developer experience is better on an EVM than it is is on a traditional centralized database.
This is definitely a take, given how easy it is to write a program with security bugs using Solidity due to specific concerns like reentrancy that only exist due to the unique way smart contracts work. The inability to "undo" a fraudulent or mistaken transaction without requiring all validators to fork the chain also makes this a non-starter for many developers.
> your users pay to update the state of your application
Also a weird thing to call a "feature" for developers when this actively drives away potential users.
> Also a weird thing to call a "feature" for developers when this actively drives away potential users.
while being a funnel of 1 step for the users already in the ecosystem that find your application
the ecosystems turns the entire Web 2.0 marketing funnel industry on its head because the initial call to action is a payment. All of the mystery of converting to a paying customer is obsoleted in favor of unbridled commerce
this just points out another way its optimal for developers with ideas, when aiming for revenue in a web3 architected project for crypto natives. they have frictions, you solve them, they pay you. If you aren’t catering to crypto natives already, don’t launch a web3 application. the space is already big enough to ignore other potential users, and if you want that to be your cause to help the UX to grow the space, you can do that too.
> security bugs using Solidity
To your other point, I don't see 2016's smart contract coding problems as show stopping criticisms, because this is the lowest hanging fruit of experience for anyone learning solidity, all while standardization of open source methods has solved those building blocks just like in other languages. additionally, you can write an insecure application in the web 2.0 space as well.
There are enough and a growing number of developers that aren't afraid of deploying code on a blockchain. a lot has happened in the last ... decade? developer tooling has improved.
yes, the developer experience is better on a platform where you can write code (potentially with bugs) than a platform where you can’t write code or do anything programmatic at all.
Imagine you're on a snowmachine 10 feet south of the North Pole pointing due east. I tell you to ride for 10 miles without turning. You don't need to worry about map projections or anything - just don't turn. When you stop, are you still 10 feet south of the North Pole? Clearly not, you'll be about 10 miles south of the pole.
It's exactly the same if you start in Seattle. If you drive for 10 miles without turning, when you stop you will no longer be at Seattle's latitude - you'll have gone south.
I know, but that's not what TFA demands. Going 10 miles without turning is not "traveling in a straight line"; it's at most "traveling along a great circle line"!
And even that would require an unusually well aligned steering on a snowmobile :)
Impossible to follow if you are thinking Euclidean geometry, but a great circle is a straight line in spherical geometry. The earth isn't a sphere, but it is much closer to one than it is a plane.
The most reasonable interpretation of this is to follow the latitudenal geodesic along its eastern path. You cannot claim that one geodesic is more “straight” than another in 3d Euclidean geometry, that is nonsense. But that is what the author does.
Edit: Ok, the latitudinal geodesic only exists at the equator, so the question is fundamentally impossible, with how the author defines a straight line.
There is no such thing. A curve of constant latitude on Earth, except for the equator, is not a geodesic.
> You cannot claim that one geodesic is more “straight” than another in 3d Euclidean geometry
In terms of 3D Euclidean geometry, neither a curve of constant latitude on Earth's surface nor a great circle on Earth's surface is a straight line/geodesic. Both are curved.
If you restrict to the 2D surface of the Earth, a great circle is a geodesic but a curve of constant latitude, except for the equator, is not.
You're right, so if the puzzle restricts one (arbitrarily) to geodesics as the only valid straight-lined curve (?), it becomes nonsense because the only easterly geodesic is at the equator, and seattle is not at the equator.
Wrong. There is a perfectly good great circle passing through Seattle and pointing due east at the point where it passes through Seattle. The author showed it to you in the article. That geodesic does not always point due east, but nothing in the article said it had to. The article only said you have to face due east at the start, not that you need to continue facing that way.
> the original instruction was "straight line", not "geodesic"
If you're working within a 2-sphere, such as the Earth's surface, or indeed any non-Euclidean geometry, they mean the same thing. More precisely, there are no "straight lines" in the exact sense you mean in a non-Euclidean geometry, but there are geodesics that satisfy all of the geometric properties of "straight lines" within that non-Euclidean geometry.
Yes, I changed the title to the linked page to ‘A path from Seattle’ from ‘Go east from Seattle’ because, from reading the comments here, I agree the original title was too misleading. Just updated the title of the Substack post also.
Thing is, even when web apps are essentially used as desktop app replacement (Electron etc), all the complexity discussed here is still there.
As far as looking OS-native, this is (unfortunately) increasingly less relevant as OSes themselves drop desktop UX consistency even internally. But that aside, Qt is still around and is a very mature framework for "near native" UI, and then there's Avalonia and others. Even Gtk is surprisingly decent on Windows these days. Although I'm not sure what this all has to do with the original subject, since web apps most certainly don't look native anywhere.
type MyUnion = { type: "foo"; foo: string } | { type: "bar"; bar: string };
vs
type MyUnion = Foo of { foo: string } | Bar of { bar: string };
You still need some runtime encoding of which branch of the union your data is; otherwise, your code could not pick a branch at runtime.
There's a slight overhead to the TypeScript version (which uses strings instead of an int to represent the branch) but it allows discriminated unions to work without having to introduce them as a new data type into JavaScript. And if you really wanted to, you could use a literal int as the `type` field instead.
This is definitely a take, given how easy it is to write a program with security bugs using Solidity due to specific concerns like reentrancy that only exist due to the unique way smart contracts work. The inability to "undo" a fraudulent or mistaken transaction without requiring all validators to fork the chain also makes this a non-starter for many developers.
> your users pay to update the state of your application
Also a weird thing to call a "feature" for developers when this actively drives away potential users.