5 ms·

> Nobody is completely immune to trends and fads, but the SQLite developers work hard to avoid being sucked into the latest programming fashion. So good to see

> Nobody is completely immune to trends and fads, but the SQLite developers work hard to avoid being sucked into the latest programming fashion. So good to see this. I have seen so many developers use the latest C# features heavily, to avoid looking weak.

hangonhn 1y ago
What do you mean by avoid looking weak? Like engineers in that community look down on not using the latest features?
- general1726 1y ago
  There is a FOMO especially around younger developers who wants to use latest, newest and upgrade all frameworks the moment they pop out on Microsoft website. Older developers (like me) have opposite problem and I have been fighting for months to not upgrade .NET4.8 to .NET8 due to compatibility with our current deployment chains etc. In the end I had to admit that using .NET8 for everything is going to work too and is going to give us access to better tools and new tech either through some teething problems.
  - riku_iki 1y ago
    It could be because this is the easier way to build up resume and be competitive on the market.
  - neonsunset 1y ago
    [dead]
- jayd16 1y ago
  I think the parent is mostly sour grapes. There is no such community push but like anywhere else, you'll see folks get excited about new toys and then try to force them in to try them. It's not any worse for C# than anything else.
- breadwinner 1y ago
  > Like engineers in that community look down on not using the latest features? Yes. Engineers use the latest features heavily to demonstrate that their skills are current. One of the worst such features is "var". Some tools even flag your code for not using var when you could. Inappropriate use of "var" makes code harder to read (and even MS documentation says this) and makes code slightly less reliable too.
  - enlightens 1y ago
    Ok but var has been around since C# 3.0 in 2007. Love it or hate it, using that keyword in 2025 signals nothing about how current your skills are. https://en.wikipedia.org/wiki/C_Sharp_3.0#Local_variable_type_inference https://en.wikipedia.org/wiki/C_Sharp_3.0#Local_variable_typ...
    - breadwinner 1y ago
      You are right about this not being a new feature. But if you don't use it, it seems like you haven't updated your skills in a while. Besides making the code harder to read, "var" also makes your code less reliable as seen in this example: https://circles.page/567f44465c28b00bf8ed6cf9/Csharp-Type-Inference-Danger https://circles.page/567f44465c28b00bf8ed6cf9/Csharp-Type-In...
      - recursive 1y ago
        SomeMethod().Fire(); has the same "problem". var e = new Employee(); does not. The problem you see is independent from var.
        breadwinner 1y ago
        You are right, SomeMethod().Fire() has the problem too. But typically you write Employee e = SomeMethod(); e.Fire(); This does NOT have the same problem as var. When you use var you reduce the opportunities for the compiler to catch your bug. So the best practice is to explicitly state the type when possible. It makes the code more readable too. What's more, Microsoft recommends using implicit typing for local variables only when the type of the variable is obvious from the right side of the assignment. See: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals... But that's not what the community is doing, and some tools (JetBrains Rider) recommend using var whenever possible.
8bitbeep 1y ago
Funny. I don’t need to work hard for that at all. It comes naturally to me. It obviously has its pros and cons, but to me, a shiny new tech has to prove itself first in order to deserve my attention. There are, occasionally, the “wow, I got to have that” moments and those are great, but rare.
Narann 1y ago
The second sentence is also very good to see: > Our aim is to produce timeless code that will be readable, understandable, and maintainable by programmers who have not yet been born.
deleted 1y ago
[deleted]
nurettin 1y ago
I stopped using C# 10+ years ago, but I remember wanting to update the framework and use the latest thing (linq to objects) because it made code a lot more concise.
- beagle3 1y ago
  I have an observation about this: everybody wants a small upgrade that makes it easy for them to make their code a little more concise; But somehow, almost no one wants a language that is already super-terse in the first place (like Lisp or APL- family). And yes, that requires a paradigm change to make the most of it - but so does e.g. LINQ. It’s about the journey, not about the destination.
  - nurettin 1y ago
    I can see someone defending Ruby as concise (having the ability to chain different transformations) and simple to write in (low verbosity). Lisp? Define a class and do some map/filter/reduce. Lisp is verbose. Sometimes even worse than Java21 these days. Just put the equivalent code side by side and look. You would be surprised at how much verbosity you choose to ignore.
    - beagle3 1y ago
      Lisp done idiomatically is terse, incredibly so. It's been a while since I've worked in Lisp, but I never used a class, nor did anyone I worked with. I purposely type everything when coding[0], which makes me painfully aware of all the verbosity and boilerplate. I last wrote Java about 12 years ago (first wrote Java 25 years ago), and it was among the worst at every point in time; I have very little desire to see what it evolved into, but if you can link to a terse, modern Java codebase I will take a look. chaining a-la Ruby does not make code terse; good selection of primitives, and good idioms do. APL family including J & K are at the extreme, and nothing else comes remotely close. [0] need to get on the AI assistant bandwagon .. haven't yet

hangonhn 1y ago

What do you mean by avoid looking weak? Like engineers in that community look down on not using the latest features?

general1726 1y ago
There is a FOMO especially around younger developers who wants to use latest, newest and upgrade all frameworks the moment they pop out on Microsoft website. Older developers (like me) have opposite problem and I have been fighting for months to not upgrade .NET4.8 to .NET8 due to compatibility with our current deployment chains etc. In the end I had to admit that using .NET8 for everything is going to work too and is going to give us access to better tools and new tech either through some teething problems.
- riku_iki 1y ago
  It could be because this is the easier way to build up resume and be competitive on the market.
- neonsunset 1y ago
  [dead]
jayd16 1y ago
I think the parent is mostly sour grapes. There is no such community push but like anywhere else, you'll see folks get excited about new toys and then try to force them in to try them. It's not any worse for C# than anything else.
breadwinner 1y ago
> Like engineers in that community look down on not using the latest features? Yes. Engineers use the latest features heavily to demonstrate that their skills are current. One of the worst such features is "var". Some tools even flag your code for not using var when you could. Inappropriate use of "var" makes code harder to read (and even MS documentation says this) and makes code slightly less reliable too.
- enlightens 1y ago
  Ok but var has been around since C# 3.0 in 2007. Love it or hate it, using that keyword in 2025 signals nothing about how current your skills are. https://en.wikipedia.org/wiki/C_Sharp_3.0#Local_variable_type_inference https://en.wikipedia.org/wiki/C_Sharp_3.0#Local_variable_typ...
  - breadwinner 1y ago
    You are right about this not being a new feature. But if you don't use it, it seems like you haven't updated your skills in a while. Besides making the code harder to read, "var" also makes your code less reliable as seen in this example: https://circles.page/567f44465c28b00bf8ed6cf9/Csharp-Type-Inference-Danger https://circles.page/567f44465c28b00bf8ed6cf9/Csharp-Type-In...
    - recursive 1y ago
      SomeMethod().Fire(); has the same "problem". var e = new Employee(); does not. The problem you see is independent from var.
      - breadwinner 1y ago
        You are right, SomeMethod().Fire() has the problem too. But typically you write Employee e = SomeMethod(); e.Fire(); This does NOT have the same problem as var. When you use var you reduce the opportunities for the compiler to catch your bug. So the best practice is to explicitly state the type when possible. It makes the code more readable too. What's more, Microsoft recommends using implicit typing for local variables only when the type of the variable is obvious from the right side of the assignment. See: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals... But that's not what the community is doing, and some tools (JetBrains Rider) recommend using var whenever possible.

8bitbeep 1y ago

Funny. I don’t need to work hard for that at all. It comes naturally to me. It obviously has its pros and cons, but to me, a shiny new tech has to prove itself first in order to deserve my attention. There are, occasionally, the “wow, I got to have that” moments and those are great, but rare.

Narann 1y ago

The second sentence is also very good to see: > Our aim is to produce timeless code that will be readable, understandable, and maintainable by programmers who have not yet been born.

deleted 1y ago

[deleted]

nurettin 1y ago

I stopped using C# 10+ years ago, but I remember wanting to update the framework and use the latest thing (linq to objects) because it made code a lot more concise.

beagle3 1y ago
I have an observation about this: everybody wants a small upgrade that makes it easy for them to make their code a little more concise; But somehow, almost no one wants a language that is already super-terse in the first place (like Lisp or APL- family). And yes, that requires a paradigm change to make the most of it - but so does e.g. LINQ. It’s about the journey, not about the destination.
- nurettin 1y ago
  I can see someone defending Ruby as concise (having the ability to chain different transformations) and simple to write in (low verbosity). Lisp? Define a class and do some map/filter/reduce. Lisp is verbose. Sometimes even worse than Java21 these days. Just put the equivalent code side by side and look. You would be surprised at how much verbosity you choose to ignore.
  - beagle3 1y ago
    Lisp done idiomatically is terse, incredibly so. It's been a while since I've worked in Lisp, but I never used a class, nor did anyone I worked with. I purposely type everything when coding[0], which makes me painfully aware of all the verbosity and boilerplate. I last wrote Java about 12 years ago (first wrote Java 25 years ago), and it was among the worst at every point in time; I have very little desire to see what it evolved into, but if you can link to a terse, modern Java codebase I will take a look. chaining a-la Ruby does not make code terse; good selection of primitives, and good idioms do. APL family including J & K are at the extreme, and nothing else comes remotely close. [0] need to get on the AI assistant bandwagon .. haven't yet