Albert_Camus

8 ms·

1.
by Albert_Camus 6y ago
> 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 use cases in your application, pagination be
2.
by Albert_Camus 6y ago
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 joins alone doesn't have much to do with the perfor
3.
by Albert_Camus 6y ago
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 described in the article. There were definitely cases in the
4.
by Albert_Camus 6y ago
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 table that will persist for a single session. The syntax is th
5.
by Albert_Camus 6y ago
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, as opposed to the expected 45): id |label
6.
by Albert_Camus 6y ago
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.
7.
Speeding up SQL queries by orders of magnitude using UNION(foxhound.systems)
3 points by Albert_Camus 6y ago|0 comments
8.
by Albert_Camus 6y ago
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 more often it ends up leading to simpler code. I would
9.
Haskell is our first choice for building production software systems(foxhound.systems)
269 points by Albert_Camus 6y ago|291 comments
10.
by Albert_Camus 6y ago
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 exchange for some purported benefits, especially to
11.
by Albert_Camus 6y ago
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 in the background, so it would transition instantly regard
12.
by Albert_Camus 6y ago
> 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 SPA, it could be built to do this. But most SPAs aren&#x
13.
by Albert_Camus 9y ago
>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 sane state management. Forgetting to initialize
14.
by Albert_Camus 9y ago
> 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 the OP, I can say with confidence this statement is false.
15.
by Albert_Camus 9y ago
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 of JSON decoding). But to claim that JSON decoding
16.
by Albert_Camus 9y ago
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 corresponding JavaScript object. In Elm, decoding is not nearly as ea
17.
by Albert_Camus 9y ago
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, decoding is not nearly as easy as it is in JS because every f
18.
Elm in Production: 25K Lines Later(charukiewi.cz)
449 points by Albert_Camus 9y ago|267 comments
19.
by Albert_Camus 11y ago
Did you read the post at all? That's exactly the conclusion the post comes to.