HN user

ZeroClickOk

126 karma
Posts6
Comments78
View on HN

Two different perspectives:

1. To be alone is FAR better than to be in bad company. And the world is full of bad company. Thousands of people are craving to be alone for this reason.

2. You need to be a nice companion to yourself. If you arrive at this level, when you meet other people, you will be eager to share this amazing companion with others, instead of appearing to be begging not to "be alone".

And one piece of advice:

1. If you are a Christian, it is a great time to learn and enjoy God's company through prayer; you will never be alone again.

I understand what the author says, but in my experience, "Nullable Types" and "Open/Sealed Classes" are two different subjects and...

1) For "Nullable Types", I see that it is VERY good to think about if some type can be null or not, or use a type system that does not allow nulls, so you need some "unit" type, and appropriately handle these scenarios. I think it is ok the language enforces this, it really, really helps you to avoid bugs and errors sooner.

2) For "Open/Sealed Classes", my experience says you never (or very rarely) know that a class will need to be extended later. I work with older systems. See, I don't care if you, the original coder, marked this class as "sealed", and it does not matter if you wrote tons of unit tests (like the author advocates), my customer wants (or needs) that I extend that class, so I will need to do a lot of language hacks to do it because you marked as sealed. So, IMHO, marking a class as "open" or "sealed" works for me as a hint only; it should not limit me.

  Location: Brasilia, DF, Brazil
  Remote: Yes
  Willing to relocate: No
  Technologies: C#, .NET, Asp.NET, Blazor, SQL
  Résumé/CV: https://www.linkedin.com/in/clickok/
  Email: clickok at gmail.com
  Languages: English and Portuguese
  Location: Brasilia, DF, Brazil
  Remote: Yes
  Willing to relocate: No
  Technologies: C#, .NET, Asp.NET, Blazor, SQL
  Résumé/CV: https://www.linkedin.com/in/clickok/
  Email: clickok at gmail.com
  Languages: English and Portuguese
  Location: Brasilia, DF, Brazil
  Remote: Yes
  Willing to relocate: No
  Technologies: C#, .NET, Asp.NET, Blazor, SQL
  Résumé/CV: https://www.linkedin.com/in/clickok/
  Email: clickok at gmail.com
  Languages: English and Portuguese

According to the rules in the first post, I cannot talk about politics in this thread, but the summary is, the political inclinations that he displayed were "uncomfortable".

Fabio Silva

  Location: Brasilia, DF, Brazil
  Remote: Yes
  Willing to relocate: No
  Technologies: C#, .NET, Asp.NET, Blazor, SQL
  Résumé/CV: https://www.linkedin.com/in/clickok/
  Email: clickok at gmail.com
  Languages: English and Portuguese
I'm a Senior Software Engineer with extensive experience (+25 years). I specialize in solving complex bugs and researching solutions for problems others couldn't resolve.

I have a hard time normalizing existing codebases where coders insist on using `catch (Exception e)` instead of the default `catch (Exception ex)` and then there are clashes in event handlers with try/catch due to the same variable name...

The killer feature that everyone is waiting for Firefox is... "chromium tab". If I can open a "chromium tab" inside of Firefox for some sites that work only on chromium browsers I swear I will not look back :)

from the article:

"For the OR clause query, the DBMS sequentially compares each condition's value one by one. In the given example, it performs three comparisons for each row to determine if (price = 1), (price = 2), and then (price = 3). This evaluation approach means that for N predicates, the complexity of the filtering operation per row is O(N).

On the other hand, with the IN clause, PostgreSQL builds a temporary hash table populated with the elements in the query’s IN clause (ExecEvalHashedScalarArrayOp). Then as the DBMS scans each tuple, it probes this hash table to see whether the tuple's attribute matches with any entry. This hash-based evaluation has a more efficient complexity of O(1) since the DBMS only needs to perform one lookup in the hash table per tuple.

Hence, as the number of predicates increases in a query, the OR clause incurs significant overhead because the DBMS evaluates predicates for each row individually, in contrast to the more efficient IN clause."

I know that does not solve the problem, but I find amazing that it is so hard to open a "read-only" connection to a sql database. At least in Sql Server we need to create a User with specific rights in order to do it, and even so it is not perfect.

He started the article with: "When building a new thing, a good first step is to build a thing that does nothing."

and later he adds: "Too often, I see relatively inexperienced developers dive in and start writing a big complex thing"

He is advicing to before start building something, make sure that the context is rightly settled.