Fun exercise! I found that the Ruby in this post resembles modern C# (probably because Ruby is a gold standard in readability, and in the last 5 years or so C# has been making big strides in readability). I've recreated the Ruby code mostly line-for-line in C# and posted it here: https://gist.github.com/waf/5c6a04899e8250cb9a89406b978c9bcc
It mapped from Ruby to C# really well. The only concept I had to add was a `BoardCell` base type for the `Mine` and `Empty` types so we could return either `Mine` or `Empty` in a typesafe way. Everything else matched conceptually 1-1.
It's 118 lines total, with 18 lines of whitespace, so 100 lines exactly. I figure the original Ruby code was also not counting whitespace so it's a fair comparison. I tried to not use any "code golf tricks" that would minimize line count. It's a full program; it could be copy/pasted into a modern .NET 8 project and run without any additional setup.
Note, I posted this same comment on the original blog post, but I've posted it here too as it might be interesting for HN folks.
Thank you for making a C# variant, with K&R braces it's just 102 lines, and 1.5 MB binary (quite a few un-strippable baseline bits like integer formatting) when AOT compiled with 9 preview, we've come a long way...
Agree, many practical insights in the system programming domain -- the domain is important for any discussion. For example, the unchecked exception pattern is a good choice for business applications.
I've been adding C# code completion functionality to my REPL tool, and ended up reverting to the text-davinci model.
The codex (discontinued?) and text-davinci models gave much better results than GPT3.5-turbo, specifically for code completion scenarios. The latest models seem to produce invalid code, mostly having trouble at the boundaries where they start the completion.
My suspicion is that these latter models focus more on conversation semantics than code completion, and completing code "conversationally" vs completing code in a syntactically valid way has differences.
For example, if the last line of code to be completed is a comment, the model will happily continue to write code on the same line as the comment. Not an issue in a conversation model as there is a natural break in a conversation, but when integrating with tooling it's challenging.
Most likely the issue is that I'm not yet effective at prompt engineering, but I had no issues iterating on prompts for the earlier models. I'm loving the DaVinci model and it's working really well -- I just hope it's not discontinued too soon in favor of later models.
I can corroborate that text-davinci gives much better results than for tasks involving summarization or extraction of key sentences among a large corpus. I wonder what empirical metrics OpenAI uses to determine performance benchmarks for practical tasks like these. You can see the model in action for analysis of reviews here: https://show.nnext.ai/
> it's more hacking than crareful and well specified engineering, and that could lead down a path of instability in the product where some features get better while others get worse, without understanding exactly why.
Airfares are hard, we tackle the hardest part, multi-city up to 10 legs long. Think exponential search space, fuzzy constraints, and constantly changing variables. We're looking for Senior .NET / C# developers to work on our flight search and booking platform.
We're located in central Bangkok, though we work from home most days and come into the office one day a week.
We use the latest C# and .NET technologies, GitHub, Continuous Integration, and Amazon Web Services. The majority of our code is .NET 6 and .NET Standard, as well as some older systems in .NET Framework that are being updated over time.
If you're interested, shoot me an email: will at bkk.jetabroad dot com
For what it's worth, modern C# can evaluate top-level statements with no other ceremony. The following is a valid standalone C# program:
Console.WriteLine("Hello");
For REPLs, there are options like (my own) https://github.com/waf/CSharpRepl which stand on top of the Roslyn compiler infrastructure, which is quite extensive and can easily evaluate standalone functions and statements.
It's still nowhere close to the REPLs of lisp and smalltalk, but it's a step in a more flexible direction.
I'd love to see an additional section on unit testing -- if we wanted to write some assertions on our async http handler that queries the database, what would that look like? Would we need to structure the code differently in order to test it?
Agreed, the predictive intellisense is really nice and a makes a huge difference in my productivity at the command line. It's similar to Fish Shell's features.
There are a ton of interesting and non-obvious options in PSReadLine, like setting hotkeys for running arbitrary PowerShell functions.
It mapped from Ruby to C# really well. The only concept I had to add was a `BoardCell` base type for the `Mine` and `Empty` types so we could return either `Mine` or `Empty` in a typesafe way. Everything else matched conceptually 1-1.
It's 118 lines total, with 18 lines of whitespace, so 100 lines exactly. I figure the original Ruby code was also not counting whitespace so it's a fair comparison. I tried to not use any "code golf tricks" that would minimize line count. It's a full program; it could be copy/pasted into a modern .NET 8 project and run without any additional setup.
Note, I posted this same comment on the original blog post, but I've posted it here too as it might be interesting for HN folks.