Marcel Popescu

This is a class I use frequently for running SQL commands / queries: public   class   Database  :  IDatabase {      public   Database ( DatabaseConfiguration   config )     {          this . config   =   config ;     }      public   object [][]  RunQuery ( string   query ,  params   object []  args )     {          using  ( var   con   =   Connect ())          using  ( var   cmd   =   Prepare ( con ,  query ,  args ))              return   cmd . ExecuteReader () . Pipe ( ReadData );     }      public   void   RunNonQuery ( string ...

Here are three reasons to do things later rather than earlier: You will know more. You will usually be richer and thus can buy some help (at least for part of the task). You might be dead and therefore no longer care about the task :)

I just read an article about eliminating dependencies whose basic thesis is that instead of having a class that depends on something that can give you a value, just depend on that value directly. His example (which you can read more fully in the article) is that instead of having public InvoiceGenerator(IConfigurationReader configurationReader) { _configurationReader = configurationReader; } and later on calling var watermarkText = _configurationReader.Get<string>("invoiceWatermarkText"); if (!String.IsNullOrEmpty(watermarkText)) to get the text we need, just request the text directly: public Invoice GenerateInvoice(string watermarkText) { if (!String.IsNullOrEmpty(watermarkText)) There are two obvious problems with this, which you will hit extremely quickly in real code. One of them, pointed out by a comment by LeszekP, is that most of the time you will require more than a single value from an interface. ...

Going from abstract to concrete: Private currency: good. I would love to have lots of them, just as I love both gold and silver. Blockchain: not so good, more of a solution in search of a problem. The only advantage it has compared to an append-only database is decentralization… and I don't see a need for that. I would much rather have many private currencies. Also, in practice most coins are actually centralized, or at least a very small oligarchy. Bitcoin: nah. Really bad. Incredibly slow to initialize, slow transactions, easy to control by a sustained state-level effort, very low cap on number of transactions per second, plenty of bugs, hard-forks which means the code is actually controlled by a small group (which in turn means that I can't trust that the currency itself is decentralized)… nah. In conclusion, I like the initiative, and I'm 100% behind the idea that we need to separate states and money, but we're nowhere near yet.

The problem with null is that it pretends to be an object of a given type, without actually having that type. For example (C# code - ignore the uselessness of the GetName method): string GetName(Customer customer) { // I got a customer object, I can access the Name property return customer.Name; } var x = func(null); // <-- not a real Customer object so we have a run-time error The proper way to solve this is by using the Option (aka Maybe) monad; for an example using the Functional.Maybe NuGet package: string GetName(Maybe<Customer> customer) { // I don't actually have a Customer object, I have a Maybe<Customer> // I need to treat it carefully return customer.Select(it => it.Name).OrElse("Missing"); } var x = func(null); // compiler error, because Maybe<> doesn't allow null as a value var x = func(Maybe<Customer>.Nothing); // the customer is missing but the call will not crash Using the Opt...

FanFiction Phrase from a book I'm reading: I was bitten by a radioactive Jedi as a child. The Havoc side of the Force