Engine Crash Detective Story

[emadsen]

Once again Henk has succeeded in pushing us off topic, lol. I shouldn't have responded to his LINQ comment

As for saying that SQL is a good language: NO... Linq/EF gets better with every release

I assume we agree LINQ is a terrible idea for chess engine move generation. For line-of-business applications, we're unlikely to agree.

I find SQL easy to read and write. I much prefer to keep it front and center via SQL + a micro-ORM like Dapper than hide it via LINQ + EF. Dapper is extremely fast, type-safe, SQL-injection safe, and versatile: single or multiple record sets in one round-trip to DB, IEnumerable of single or multiple types, preserves object references via Multi-Map lambda (for populating HashSets or Dictionaries), insert with identity, etc. Small, simple, fast. I find EF to be bloated and slow and LINQ needlessly reinventing the wheel when you're talking to a relational database.

With SQL + Dapper, if anything goes wrong in your API method, the underlying SQL is right there. No guessing games about what the hell LINQ or EF is doing under the covers (redundant joins, numerous sub-queries, fetching reams of data over the wire only to discard most of it client-side, etc).

Old school? Yes, old school like Stack Overflow. You know, that slow, useless website from the 90s

At the end of the day, you must know SQL if you're building a line-of-business application on top of it. If the app fails to retrieve data quickly the problem is solved by tuning SQL- structure or query. If you hide SQL from the developer you're excusing them from writing performant code. I've found it encourages junior devs to say, "Why is it slow? I don't know. Ask the DBA." If they write the SQL they own its correctness and performance characteristics.

[Dann Corbit]

2. SQL is bloody dangerous: you make a mistake in an update statement, which is waaaaaaaay to easy to do in SQL, then you get told that 500 records have been updated, and there's nothing you can do about it. There should be an option for a warning if multiple records will be updated or deleted

If you start with BEGIN TRAN there is no danger.
You can always roll back.

As far as LINQ, I love it, but like everything else, it is not perfect. When you only know how to use a hammer, everything looks like a nail.

Use LINQ where appropriate, simple as that

[towforce]

I assume we agree LINQ is a terrible idea for chess engine move generation.

Yes: programs in which every bit of performance is of extreme importance are a special situation.

For line-of-business applications, we're unlikely to agree.

Afraid so: IMO, if businesses understood software development better, they'd put more emphasis on maintainability, and linq/EF is quicker and easier to maintain than SQL queries.

[MOBMAT]

I know it sounds weird, but put assert() calls in EVERY function call with tests against every parameter (within reason) that is passed to it.
I say within reason since if you are using pointers, it is difficult to know what a pointer value should be and the code will toss an error if a pointer is NULL anyways.

assert() is only compiled in debug mode so you won't pay a price in performance except in debug mode.

So what do you test for?

say you are passing a value that represents a board square number (0-63). any other values are invalid, so the assert() call could be
assert( (sqr >= 0) && (sqr < 64) );
as long as the sqr value is within the range, nothing happens.
if sqr is out of range, then assert() tosses an error which is caught by the debugger. I use MSVC so it basically breaks on the line of code that threw the error, in this case, the assert().

you can plaster them all over your code in areas where you think the problem is coming from.

They have saved my anal orifice many times.

[Dann Corbit]

I do array bounds check so often, I have header methods to make them easier for the 2d and 3d case.
I helped Don Dailey find a few problems with them.