> so I've noticed that I do want a map that works like a map - something I can explore and annotate.
I don't doubt that there are use cases for a map that works this way. Even if Google Maps covers 80-90% of the use-cases for mapping, mapping is an absolutely massive domain. 10-20% of use-cases still represents a huge volume.
But it doesn't have to be Google Maps. It actually seems worse to be for one "maps" app try to handle all possible use-cases for a map.
Why isn't there a separate different tool that handles the use-case you describe?
I guess, going back to the original thesis, what would the "1983" replication of what Google Maps does, but faster. Or, what would the "1983" version of the mapping behavior you wanted.
In the thread they say:
> in 1998 if you were planning a trip you might have gotten out a paper road map and put marks on it for interesting locations along the way
I'd argue that this use-case still exists. Paper road maps haven't gone away, so this is still an option. People largely don't use this and prefer Google Maps or other digital mapping tools for most of their problems. Why? If you gave me both the 1998 tools and the 2020 tools, for 95% of the options I'm going to use digital tools to solve it because they let me solve my problems faster and easier. I know this because I have easy access to paper maps and I never touch them. Because they're largely worse at the job.
> There's a very subtle point the Twitter thread was making here. This use case may be most popular not because it's what the people want, but because it's all that they can easily do. The tools you use shape how you work, and what you can work on.
Ultimately, my point above is my response to that. None of the old tools are gone. Paper maps are still available. And yet they have been largely abandoned by the large majority of the population. I agree that there are limitations to our current digital tools, and I hope in 2030 we have tools that do what the article describes. But the 1983 version of the tools are worse for solving problems than the current tools, for most people.
pretty much all games in the early 80's had [so called] pixel perfect scrolling. Each frame showed exactly what was required.
Today it is entirely acceptable for a map to be a jerky stuttering pile of crap. The same goes for the infinite scroll implementations. Its preposterous to start loading things after they are needed.
There is a good analogy with making things in the physical world. The professional doesn't start a job before he has everything he needs to do it, the amateur obtains what he needs after he needs them.
Games have huge advantages of constraint of application that mapping applications don't. You can get pixel perfect scrolling when you constrain the max rate the user can pass through the dataset, you deny them random access into the dataset, your dataset isn't trying to represent a space the volume of planet Earth, etc.
There's a huge gulf between the use cases you're comparing here, and I don't believe for one second that loading the Google Maps dataset into Commander Keene's engine would make for a better experience.
(Also, not to be overly pedantic, but "The professional doesn't start a job before he has everything he needs to do it" pretty much classifies all building construction as unprofessional. The professional doesn't magically have everything on-hand, especially bulky or expensive resources; they have a plan for acquiring them at reasonable rates of input and mitigation strategies if that plan can't be followed)
Illl ignore the pedantic part since it was just an analogy, if it doesn't work for you there is little to talk about.
> Games have huge advantages of ....
I have thoughts like that but I consider them "making up excuses". You don't have to see it that way but I can't see someone fix a problem by making up excuses for it to exist. For me it is just like you can always come up with an excuse not to do something.
8 gigabytes of memory / 64 kilobytes of memory = 125 000 times as much memory.
14 gigahertz (4 cores x 3.5 GHz) / 1.023 MHz = 13 685 times as much processor power.
4108 gigahertz (2560 Cuda cores / 1605 MHz) / 2 MHz = 2 054 000 times as much video power.
Can I just call 2 Mhz memory bandwidth 16 Mbit/s?
If so, 500 Mbit / 16 Mbit = 31.25 fold the bandwidth
We are not rendering many layers of colorful animated game content. A map is just a bunch of boring lines. The modern screen however is a lot bigger. I see a glimmer of hope for an excuse!
320x200 px = 64000 px
1920x1080 px = 2073600 px
2073600 / 64000 = 32.4 times the screen size
meh?
We must applaud everyone involved in making all this hardware progress. It truly blows the mind and defies belief. No one could have imagined this.
Then came weee the software people and... and.....
I'm cringing to hard to continue writing this post.
The numbers don't lie, we suck. Lets leave it at that.
I'm still happy with the configuration we have where my map is a little slower than maybe I'd like it to be (though honestly, I just loaded maps.google.com and moused around randomly and... it's fine? Certainly not so slow I'm bothered by it) but the mapping app also can't crash my computer due to the three layers of abstraction it's running on top of. Because that would suck.
If you're curious where the time goes, btw... Most of the visible delay in Google Maps can be seen by popping the browser inspector and watching the network tab. Maps fetches many thin slices of data (over 1,000 in my test), which is a sub-optimal way to do networking that adds a ton of overhead. So if they wanted to improve maps significantly, switching out for one of the other protocols Google has that allows batching over a single long-lived connection and changing the client and server logic to batch more intelligently could do it. I doubt they will because most users are fine with the sub-three-second load times (and engineering time not spent on solving a problem most users don't care about is time spent on solving problems users do care about). You're seeking perfection in a realm where users don't care and claiming the engineers who don't pursue it "suck;" I'd say those engineers are just busy solving the right problem and you're more interested in the wrong problem. By all means, make your mapping application perfect, as long as you understand why the one put out by a company with a thousand irons in the fire didn't.
Also, I think the analogy was great, but you reached the wrong conclusion. ;) That is how large-scale engineering works. Scheduling becomes the dominant phenomenon in end-to-end performance. Games have huge advantages on constraining the scheduling problem. General-purpose apps do not. Hell, to see this in action in a game: Second Life's performance is crap because the whole world is hyper-malleable, so the game engine cannot predict or pre-schedule anything.
Since it is software nothing is set in stone, everything can be changed, we know how to do it really really fast and really really efficiently.
People did incredible things to improve almost everything.
To me this means all of the performance loss is there for no reason. All we need is for people to stop making excuses. I for one know how to get out of the way when better men are trying to get work done.
You are the engineer if not the artist, impress me! Impress the hardware people! Impress the people who know your field. Some attention to consumers wishes is good but Gustave Eiffel didn't build his tower because consumers wanted that from him.
Why would you even have tap water if the well is down the street? A horse and carriage is just fine, it is good enough for what people need. no? What if our doctors measured their effort in "good enough's" and living up to consumer expectation only?
The hardware folk build a warp capable star ship and we are using it to do shopping on the corner store because that was what mum wanted. Of course there is no need to even go to Mars. It's missing the point entirely you see?
> pretty much all games in the early 80's had [so called] pixel perfect scrolling. Each frame showed exactly what was required.
> Today it is entirely acceptable for a map to be a jerky stuttering pile of crap. The same goes for the infinite scroll implementations. Its preposterous to start loading things after they are needed.
This doesn't make any sense to me. In which game from the early 80's could I view accurate map data for any region on the earth, and quickly scroll across the planet without any loading artifacts?
Of course you can manage pixel-perfect scrolling if all of your data is local and fits in memory. That's not anywhere close to the same domain as maps.
I don't doubt that there are use cases for a map that works this way. Even if Google Maps covers 80-90% of the use-cases for mapping, mapping is an absolutely massive domain. 10-20% of use-cases still represents a huge volume.
But it doesn't have to be Google Maps. It actually seems worse to be for one "maps" app try to handle all possible use-cases for a map.
Why isn't there a separate different tool that handles the use-case you describe?
I guess, going back to the original thesis, what would the "1983" replication of what Google Maps does, but faster. Or, what would the "1983" version of the mapping behavior you wanted.
In the thread they say:
> in 1998 if you were planning a trip you might have gotten out a paper road map and put marks on it for interesting locations along the way
I'd argue that this use-case still exists. Paper road maps haven't gone away, so this is still an option. People largely don't use this and prefer Google Maps or other digital mapping tools for most of their problems. Why? If you gave me both the 1998 tools and the 2020 tools, for 95% of the options I'm going to use digital tools to solve it because they let me solve my problems faster and easier. I know this because I have easy access to paper maps and I never touch them. Because they're largely worse at the job.
> There's a very subtle point the Twitter thread was making here. This use case may be most popular not because it's what the people want, but because it's all that they can easily do. The tools you use shape how you work, and what you can work on.
Ultimately, my point above is my response to that. None of the old tools are gone. Paper maps are still available. And yet they have been largely abandoned by the large majority of the population. I agree that there are limitations to our current digital tools, and I hope in 2030 we have tools that do what the article describes. But the 1983 version of the tools are worse for solving problems than the current tools, for most people.