Kip DeCastro

@lauriewired The Mels I’ve met in my life have never produced better code. No Mel, I can guarantee your binary sort is not faster than LINQs.

There’s a famous Usenet story about a programmer (Mel) who refused higher level abstractions. It was the late 1950s, and even in that era, Mel was…well today we’d call him a boomer. Mel only wrote in raw hexadecimal. He didn’t approve of compilers, and refused to use optimizing assemblers. "You never know where it's going to put things”, he said. Everyone else in the company was moving on to FORTRAN, and they didn’t understand why Mel was so stubborn about using new tools. He *loved* self-modifying code. “If a program can’t rewrite its own code”, he asked, “what good is it?” Mel eventually left the company, and other engineers were tasked with understanding what was left. Mel’s hand-optimized routines always beat the assemblers; but some of it looked absolutely bizarre. One engineer took ~2 weeks to understand why there were loops with no exit condition…yet the program worked fine. I won’t spoil all the details, you should really read it, it’s short. But it’s a fantastic piece on “what defines a real programmer?”…which is becoming increasingly relevant in this vibe-coded era. I strive to understand computers as deeply as Mel! If we aren’t careful, we’re going to lose the “Mels” of this world to time. That’s part of why I go so deep in my youtube videos. I hope that younger viewers are genuinely fascinated by the inner workings of our machines, instead of handing everything off to higher abstractions.

@SeedVEVO @usgraphics Unfortunately the code behind is often absolute garbage

@usgraphics winforms is peak, and so are direct web app ports of winforms-like apps (includes vb6 stuff)

I wanna hang out with people that designed this stuff 🍻

@oldmedia Jamiroquai, we bestow upon you the rank hatamoto

Sony’s Japanese Minidisc ads with Jamiroquai are straight up iconic

@lauriewired @skooookum I have a Rocket, which is not a hip machine but it’s been incredibly reliable over the past 5 years. E61s are built like tanks and easy to work on if something does go wrong. I feel no need to upgrade.

the decent DE1 is kind of a meme. Get a solid E61 machine and you'll be set for like 50+years. yes, sure, pressure profiling is interesting in a somewhat data-nerd way, but as someone who has tried it out, turns out: - slow ramp-up to 9-bar is basically the universal ideal - e61 group heads do this somewhat naturally by design. better yet, just do ~10 seconds of preinfusion which is a much more repeatable setup than the decent profiles. If you want to play around, for the same $5k I'd actually suggest getting a workhorse E61 (I've had an ECM Synchronika for ~7 years now) and then a "fun" manual lever machine for experimentation (flair is a fine pick, cafelat robot is a fun one too). the decent feels very cheap IRL, you're essentially paying for software. E61s (and levers) are like the manual cars of the coffee world, plus all your money is going towards...good plumbing and boilers and such.

Does anyone have a good reason why I shouldn’t buy the $5k espresso machine with a documented BLE protocol, open-source firmware, Python SDK, Go parser, REST and WebSocket interfaces, a SQLite shot database, and an active developer community building on it

@IgderKoman @dariogriffo I haven’t had a breaking change since core 3.0 to 5.0 🤷 and even that was easy to fix.

@Kipdec @dariogriffo That is certainly not enough

Also Microsoft people who still asks "why c# is not chosen by startups??????? When I finish explaining the support lifecycle of minimal apis they already have an investor because the MVP in node is out and working. Now think about this: choose dotnet, which version you asking? there is one stable supported, and will be the same version for years to come, now go and ship you lazy bastard...

@onehappyfellow @therealchreke Is lean ml related? Looks very similar to F#

quick lean exercise: RPN calculator + proof of correctness of translation from expression trees to RPN: gist.github.com/happyfellow-on… thanks @therealchreke for the fun problem!

@julestestard @TheAhmadOsman It works just fine. It worked before docker and it’ll work after docker as well. It’s very easy to just add a service for whatever you’re running.

@TheAhmadOsman Wrong, docker is great for running anything on a remote server. Try doing without it and tell me how it goes

am i right or am i right

@ThomasKirven1 @TheAhmadOsman You can just run things on the server.

@TheAhmadOsman wrong, docker is great. Give 1 valid reason why it's stupid

@Aaronontheweb The best way to use dotnet is ignore all the oop patterns you can

If you want to understand how deranged the median .NET developer is: have Claude vibe code a complete application end-to-end with minimal stylistic constraints and see what it comes up with. If you have any sort of good taste, you will be horrified

@SIRHAMY @davidfowl F#!

@davidfowl Native unions pls

People waking up in 2025 realizing that C# is modern, runs cross platform, and is fast AF news.ycombinator.com/item?id=459204… #dotnet

@DanielW_Kiwi No - the main reason I use EF Core is to not waste my life away mapping large legacy tables.

Can someone steelman this for me?

@therealchreke I’ve been using F# extensively. It’s a breath of fresh air using it instead of C#. I like C# but I’m able to write significantly less code for the same result.

hot take: choose F# over TypeScript or Go for backend. can’t think of any metric that matters where Go or TS outperforms F#

@schneidenbach @unclebobmartin I don’t disagree with your rant but I think that’s partly why F# users are so adamantly advocating its use in the comments. It really helps solve many of the issues with C# and while the interop isn’t “easy” it’s better than a poke in the eye.

Morning bathrobe rant: “F# is the better language, just use F#!”

@DevLeaderCa Know how to use a dictionary please

When you're hiring a .NET dev, would you rather see: - Deep familiarity with Microsoft stack - Open source contributions - A side project portfolio ... Something else? Maybe a mix?

@SJFriedl @Aaronontheweb I try to do everything in it. It’s great and I have to write much less code for the same result

@Aaronontheweb I have never gotten the appeal of F# even though people I respect are big fans, and it feels like it's more than a chocolate-vs-vanilla preference.

At C#'s current trajectory, F# will be the more intuitive / instantly readable language within 3 years

@kristijan_kralj F# unironically fixes this by making the most painless way to do things to be to just solve the problem.

The hidden cost of enterprise .NET architecture: Debugging hell. I've spent 13+ years in .NET codebases, and I keep seeing the same pattern: Teams build fortress-level abstractions for problems they don't have. IUserService calls IUserRepository. IUserRepository wraps IUserDataAccess. IUserDataAccess calls IUserQueryBuilder. IUserQueryBuilder finally hits the database. To change one validation rule, you step through 5 layers. To fix a bug, you open 7 files. The justification is always the same: "What if we need to swap out Entity Framework?" "What if we switch databases?" "What if we need multiple implementations?" What if this, what if that. The reality: Those "what ifs" don't come to life in 99% of cases. I've seen exactly zero projects swap their ORM. But I've seen dozens of developers waste hours navigating abstraction mazes. New developers are confused about where to put a new piece of functionality. Senior developers are debugging through the code that has more layers than a wedding cake. The end result? You spend more time navigating than building. Look, good abstractions hide complexity. Bad abstractions create it. Most enterprise .NET apps have way too much of the second kind.

@AntonMartyniuk Maybe don’t get emotional about your code? It’s there to solve a problem. If something is going to cause bugs and you don’t let the creator know directly, you’re being a bad reviewer. And I’ve never seen someone fix naming in a follow up. Doesn’t happen.

𝗧𝘄𝗼 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗿𝗲𝘃𝗶𝗲𝘄𝗲𝗱 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗰𝗼𝗱𝗲: One got fired One got promoted The difference? How they gave feedback 👇 "You should have used Strategy Pattern" ❌ "What do you think about using Strategy Pattern here?" ✅ "Where are the tests? Do you even care about quality?" ❌ "Let's make sure we have test coverage for this feature" ✅ "This code is a mess" ❌ "I see some opportunities for simplification here" ✅ "Why didn't you just do X?" ❌ "Have you considered X as an alternative?" ✅ "This code will crash, fix it" ❌ "Let's focus on improving error handling here" ✅ "Only a junior would write this" ❌ "Here's a pattern that might help make this clearer" ✅ "You're doing this completely wrong" ❌ "Here's an approach that might be more maintainable" ✅ "Change this to use async/await" ❌ "Could we refactor this to use async/await?" ✅ "This function is stupid" ❌ "Can we simplify this function to improve clarity?" ✅ "This is obviously inefficient" ❌ "I noticed potential performance implications here" ✅ "Your code is hard to understand" ❌ "This section could use more documentation" ✅ "Never use global variables" ❌ "Consider using dependency injection instead" ✅ "You're not following standards" ❌ "Let's align this with our team standards" ✅ "This will cause bugs" ❌ "We might prevent edge cases by adding validation" ✅ "Why is this so complicated?" ❌ "Could we break this down into smaller functions?" ✅ "Fix this ASAP" ❌ "Could we prioritize addressing this?" ✅ "Your spacing is a disaster. Fix it before I look further" ❌ "Let's focus on the logic first, then polish spacing later" ✅ "What a mess. Nobody can review 2,000 lines at once" ❌ "Can you split this into smaller PRs?" ✅ "Stop using your patterns. Mine are the only right way" ❌ "Which pattern do you think fits best here?" ✅ "Change this name or I'm blocking the PR" ❌ "Approved — fix naming in a follow-up" ✅ "This PR has zero context. Am I supposed to guess?" ❌ "Can you add scope and risks in the PR description?" ✅ "You changed behavior and forgot the docs" ❌ "Can we update the README with usage notes?" ✅ Remember during code reviews: ✅ Focus on the code, not the person ✅ Suggest, don't command ✅ Explain the why ✅ Be constructive ✅ Stay positive Which toxic review comment have you received? Share below 👇 — ♻️ Repost to help others create a better code review culture ➕ Follow me ( @AntonMartyniuk ) to improve your .NET Skills

@Dave_DotNet You can just ignore 99% of it. Use records and static methods. I think people get caught up in engineering rather than *solving the problem*

#dotnet 👀

@dariogriffo Why would you use IQueryable instead of creating a goofy SDL that doesn’t work that well?

You don't need to install a nuget package or do anything fancy, just a static method that receives an IQueryable<T> and returns IQueryable<T> I'm not installing any library or creating random objects when I can just use a static method, Sorry Ardalis.