Viewing profile — Albert_Camus

> If you're a software engineer, it won't make a difference, just send two queries to the DB and combine the results before sending them off. This isn't true if you have certain us…

Author here. Between this and your other response, where you expound on the same point, I think you're being far too hand wavy about what causes performance issues. The number of j…

In the past we worked on a system that used MySQL 8. We used UNION (not UNION ALL, but I assume it doesn't matter) in several places, applying it to improve performance as we descr…

Author of the original article here. Temporary tables are different than using WITH (which are common table expressions, or CTEs). In many database engines, can make a temporary ta…

Author here. This doesn't give the correct results. It produces meal_items that have both customer_id and employee_id. Here's an excerpt (the full result set is thousands of rows, …

Author here, you are indeed correct that Query #2's final join can be an INNER join. However, I just tested it against our test data set and it makes no impact on the performance.

Author here. Having written a lot of Haskell, I don't find lazy evaluation to be an issue nearly as often as it is a benefit. Yes, it can be difficult to reason about at times, but…

I don't think it's holding SPAs to a higher standard. It's holding SPAs to a reasonable expectation for SPAs. An SPA is significantly more complicated on the client side in exchang…

In your post you made it sound like most SPA frameworks will take care of this for you. > With a SPA framework, it could add it to the local list of emails and push to the server i…

> With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity. With an S…

>And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code. Not at all. The issue with an application written in jQuery is a lack of s…

> I care only about properly working, easy to develop and maintain and wildly used so I can hire for. Elm is none of these at the moment, but React is. As a CTO and the author of t…

Author here. I agree with your points, and in my article I specifically mention that there are benefits to some of the "hardness" of certain tasks in Elm (type-safety in the case o…

Author here. As I posted in a different reply: JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the correspon…

Author here. JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object. In Elm, de…

Did you read the post at all? That's exactly the conclusion the post comes to.