hparadiz

This thread is going off the rails with taking the realism aspect of what I said too literally. I'm not saying remove FTL from the game. I'm saying having the map change ....very slowly. It would make things more interesting.

I didn't say I hate them. I said I don't find them fun.

Anyway I don't need a spreadsheet to know where a moon is gonna be in N time. A simple visual simulation I can whip up with AI in minutes would do the trick.

I played it for years. Shaking my head at this silliness. You just set the bookmark to a 50 meters off the side of whatever station and then the position of the station is basic orbital algebra that takes almost no CPU to calculate. It's dumb you can't just activate the warp to immediately activate for one second in whatever direction. Another reason I stopped playing. Irl you'd warp away in any direction if you're about to get blasted. You wouldn't be wasting time aligning to some random bookmark. This is why I can't take Eve online seriously. Like you actually think that a 25 year old engine is the best design ever for some reason.

Tactics like being able to have your fleet hiding behind a moon that happens to orbit into the exact right position at the right time is fun to me. Eve Online is already a spreadsheet simulator so I find it about as fun as watching paint dry. Anyway I don't think basic physics is about fun or not fun.

You would not need to update any bookmarks. They should be using a coordinate system based on a relative object. Existing bookmarks are already technically relative the largest gravity well. New bookmarks would simply be based on whatever you want like any object. Absolutely no reason to overcomplicate it. Dunno why you're assuming you'd need to update anything.

That's not very expensive for a lot of tech workers in the United States. That's why I'm asking so casually. Half a percent for currency conversion is quite cheap.

Positioning of things in orbit around a point in space is cheap. The issue was probably how much more complicated it would be to make all the missions if things kept moving around. You could end up with things on opposite sides of a solar system that are currently right next to each other. But to me it takes me out of the game when I see stuff like that in the engine.

Are stations and jump gates still fixed in place?

Yea it's weird what people on HN will say with no actual first hand experience.

They don't even do orbits of basic solar system objects. Lol.

Eve online has always just pretended to be a space sim.

Not a fan of space engines where locations are fixed.

That's nice. You can pay for it. I won't be.

I legit can't tell if this is sarcasm or not.

That sounds good in theory but the first time you get into a dirty one with a weird smell will be the last time you use it.

It's weird how the discourse on X is so much more high brow compared to HN these days.

I have a hard time believing that the public at large is gonna be okay with having to blow into a hose anytime they turn on their cars.

People that have a perfect driving record.

I was more thinking a brokerage account for typical stock / index fund investing.

I thought it was a regular thing for Americans or anyone in the world to be able to make a Swiss account? Is that not the case? Or is it different if you live there?

A "feature" like this can easily kill someone in some of the sketchy mountain roads I've been on in Crete.

I've always thought it was borderline crazy that Xbox charged a monthly fee and I never had an Xbox for that reason. It always made me wonder how many people they failed to bring into their ecosystem for that reason.

Of course I support experimenting on living humans. That's how medical research is done for everything. Eventually no matter how sure you are someone has to be the first.

Before AI I kinda thought more ram and faster ram was kind of useless because I had written off increased speeds as sort of a luxury whose only application is bloated unoptimized software. Boy was I wrong about that. But then why stop there?

This could completely terraform the weather for the entire region. Possibly even increasing the amount of rain in the middle east overall.

It's being released right now because it's massively profitable and in high demand and has actually gone up in price over the past year so obviously AMD wants to cash in on that instead of selling these units to PC manufacturers at a lower price.

Another reason to drop both iOS and Android.

You are outputting generic QueryRow classes in your code for all results. That doesn't make it an ORM.

By your definition PDO would qualify https://www.php.net/manual/en/class.pdorow.php

Here's a full report for you https://gist.github.com/hparadiz/a1fe30e88dbbe070878a7ea4f72...

You can always make the ORM Model based on a view. Sometimes a background job compiling a simple result set table is the appropriate answer.

Almost all ORMs boil down their queries down to a single query handler so it's actually super easy to find the query.

My ORM for example:

  *Read paths*

  - Models/Factory/Getters/GetAllRecords.php:28 - table(...) when indexField is set.
  - Models/Factory/Getters/GetAllRecords.php:31 - allRecords(...).
  - Models/Factory/Getters/GetAllRecordsByWhere.php:95 - table(...) when indexField is set.
  - Models/Factory/Getters/GetAllRecordsByWhere.php:98 - allRecords(...).
  - Models/Factory/Getters/GetRecordByWhere.php:20 - oneRecord(...).
  - Models/Factory/Getters/GetByQuery.php:9 - oneRecord(...).
  - Models/Factory/Getters/GetAllByQuery.php:9 - allRecords(...).
  - Models/Factory/Getters/GetTableByQuery.php:9 - table(...).
  - Models/Versioning.php:122 - revision table(...).
  - Models/Versioning.php:124 - revision allRecords(...).

  *Write paths*

  - Models/Events/Save.php:41 - insert on save() for phantom records.
  - Models/Events/Save.php:53 - update on save() for existing dirty records.
  - Models/Events/Delete.php:18 - delete by primary key.
  - Models/Events/Destroy.php:24 - insert history row before destroy for versioned models.
  - Models/Versioning.php:180 - insert history row after versioned save.

  Error/retry path

  - Models/Events/HandleException.php:35 - direct $connection->exec(...) for auto-creating missing tables.
  - Models/Events/HandleException.php:43 - direct $connection->query(...) to rerun the failed query after table creation.

  All of those eventually bottom out in IO/Database/StorageType.php:119 for non-result queries via PDO exec, or IO/Database/StorageType.php:149 for result queries via PDO query.

I used to profile all my queries in those two methods but with tools like NewRelic there's no need to slow the code down with profiling cruft.

People focus on the query writing aspect of ORMs too much. That's not that primary reason you use an ORM. It's primary purpose is to hydrate objects in the runtime. If I pull a datetime from SQL there's a lot of value in having a single piece of code handle that datetime the same way across the entire stack. I can unit test that handling once across the entire code base. Very few ORMs are aware of how the data is indexed and yes a lot of people will write code that generates a complex WHERE clause against columns that aren't indexed. But that's an understanding problem. I expect someone who uses an ORM to understand SQL well. Including indexes and fixed length tables. Obviously you are encountering code made by people who don't understand this but the problem isn't the ORM. They would have made that mistake with or without an ORM.

My reply was talking in general terms about the original post.

You wrote the exact opposite of my opinion here which is why I replied to your specifically:

> People who love and advocate the merits of ORM insist that everything be executed through ORM because it introduces too much complexity for them to blend handwritten SQL with the ORM generated queries

I believe strongly that good ORMs expose the ability to put your own queries in. But I can't possibly boil down all the reasons for this in one HN comment.

An ORM is not a query writer. It's a way to map SQL primitives to run time primitives in a static deterministic way backed by a suite of unit tests.

If you have a special query you wanna run that has 10 joins, 2 sub queries, and a derived view that's totally fine. No one says you can't. However remember that statistically 99.9% of all queries are not that.