As a follow-up to a previous post, where I wrote some Linq code to find the two closest factors of a number, I decided to do the same in Racket.
The code was nice, but the execution time was initially very disappointing, until I learnt something interesting about Lisp.
My experience coding the twoer of Hanoi in Racket, and how the code compared to the equivalent C# code
I have previously blogged about some of the great error messages I’ve seen come out of Microsoft.
Here is another one.
OK, so the title is really misleading, as you can’t really compare two such different languages, but it’s interesting to try to anyway.
Anyway, being a rank beginner, I had to start with everyone’s favourite recursive function, the factorial. This is a good one, as it’s so simple, but quickly generates numbers so big that it’s pretty useless unless you do something more than the basic coding. The results were surprising.
Rambling introduction to why I started learning Lisp, and my experiences getting going.
Spurred on by my son’s amazingly ugly CSS-only background, I decided to go one better and animate it.
Along the way, I rediscovered some of what made the early days of the web the wild, whacky and downright ugly place it was!
Get your sunglasses out before reading this blog post!
I was browsing the latest C# questions on StackOverflow, and came across one that caught my eye. Sadly, it was quickly closed by people who, in my opinion, didn’t read it properly. The question was…
I am trying to write a program to find the factor of a number with minimum difference. For Ex: for 20 it should be 4×5 or vice versa. How can this be achieved for a really BIG number. lets say 989287498274928743928174192847219347123984723498. Please guide
Ignoring the usual SO rules about showing some effort or research, the question is not simply “How do I find the factors of n?”, which is what all the linked answers were about. This question was how to find the two closest factors. Sure you can do that by finding them all, then sorting them by their difference, but for a big number, that’s hugely inefficient. There are ways of solving this specific question much more efficiently, which is what I decided to do.
As I have mentioned a couple of times, I’ve been creating some reusable Blazor components, to save time on future development. This (rather long) blog post details my journey from innocent newbie to GitHub ninja. Well, maybe not quite that far, but I learnt how to use GitHub actions to build and deploy Nuget packages, and deploy an ASP.NET web site via FTP.
Debunking the Internet myth that this year December (or whatever month is chosen) will have 5 Saturdays, 5 Sundays and 5 Mondays, and how this only happens once every 823 years.
It’s junk, and I proved it using Linq. Afterwards, I realised that I could prove it without Linq, had I only thought about the question first. Still, it was an interesting exercise, both in Linq and in thinking.
I previously blogged about creating a busy indicator in Blazor. That works fine, but there is more we can do. As my loyal reader knows, I have been trying to make my code more functional for some time, and have been using the rather fabulous LanguageExt nuget package to help. One of the most basic, but extremely useful parts of this package is the `Option` monad (oh no, the m-word!). This allows you to handle the case where the data you want doesn’t exist, without having to allow those naughty null references creep in your code. I was wondering how we could handle this in Blazor. GitHub user orthoxerox suggested creating a Blazor component with two render fragments, one for the `Some` case and one for the `None` case. This was simple, but very effective. Whilst playing with this, it occurred to me that we could extend it to combine…
Leave a Comment