Hacker News Reader

I am sure you have heard this before, but F# sounds like it would be right up your alley. It has sane defaults (non-nullability, algebraic data types, etc.) while still targeting the CLR, enabling the usage of any normal C#/.NET library to be used within your application. Granted, there's _some_ friction going between C# and F#, but that is a small price to pay (IMO).

Fun thing is the current explaination regards readonly locals: https://github.com/dotnet/csharplang/issues/188#issuecomment...

It is basically: if we introduce it, it gives us a tiny benefit for a gigantic amount of noise during every single code review. It boils down to comparing developer productivity vs. language safety.

I find the argument a bit weak since code review guidelines can end this conversation AND C# has already quite some code analysis code fixes to auto-fix language usage stuff (like file scoped namespaces or nullability checks). And that case of const and readonly can be algorithmically checked.

It does seem like a weak argument when it can be enforced/fixed by linters e.g. this is already solved in JS with eslint prefer-const rule

I suppose you can emulate it today with variable prefixes/suffixes and check the AST with a custom linter yourself

Especially since its not really a language safety feature. As a reader of code I much prefer knowing what I need to pay much attention and what not. As a writer I want to be reminded when I promised myself to not touch a variable.

Some of the comments in that thread must come from people who are lucky enough to have never had to read or refactor any large, convoluted methods. Knowing that this particular bool flag isn’t being flipped thrice, 100 lines down, is a godsend.

That is indeed a problem every once in a while. These people develop a framework and 3 languages. They do not built large systems.

But there are other groups at Microsoft which keep them on track with their real needs.

>Why can’t I make local variables immutable?

How it'd work in such a case:

You declare immutable variable "a" which's an instance of a class

and then you execute "DoSomething" method which mutates under the hood?

Compilation error? runtime error?

Anyway have you tried records?

I’d be fine with semantics similar to readonly fields (and incidentally, “const” in JavaScript): you can’t reassign the variable, but the contained object can do what it wants.

To your last question: Yes, records are really nice syntactic sugar for classes that want to behave like values.

It's usually on a syntactical level, to disable reassigning a value. For objects this means the reference is still mutable, value types are locked.

Js has const, C has const, Java final.

Imho it'd be awesome if mutability were not the default and we would have to mark mutability, but until then any variable that doesn't need it, is final. Which also helps skimming code

>Js has const, C has const, Java final.

C# has readonly and const

>Imho it'd be awesome if mutability were not the default

If they decided one day that - "let's make immutable by default", then it'd be performance hit - wouldn't it?

> If they decided one day that - "let's make immutable by default", then it'd be performance hit - wouldn't it?

Not really. It's just a syntactic default, reassigning local variables should be discouraged from except for iterators etc. It just fosters bad habits.

For example, A list can still be mutated like usual, the reference however may not change. This usually allows compilers to do optimizations in multithreaded situations. But that's not why I code that way, it reduces the cognitive burden of keeping track which variables are actual moving parts as opposed to context/names etc.

> C# has readonly and const

Haven't written C# in a few years, GP was talking about variables as far as I can tell and their lack of immutability.

C# does not (as far as I know) have readonly or const for local variables, only to fields. You can even have consts inside method bodies, but they are only actual compile-time constants.

codeflo means to declare a local variable that cannot be reassigned later.

    void Foo() {
        // this is possible in C# today, but only for compile-time constants
        const int Bar = 42;

        // this is what codeflo wants: variables that cannot be changed after declaration, but can hold runtime values
        readonly string text = $"Blah: {Bar + System.Environment.ProcessorCount}";

        // with such a variable, you wouldn't be able to reassign it later:
        text = "Some other text";
        // the line above would be a compile-time error, just like trying to reassign to a readonly field.
    }

For me, another gripe is: “Why do I have to manage a csproj file?”

That’s one of the things that tangibly improved IMO: they removed the file list, so except still being ugly XML, the csproj is now very comparable to package.json or Cargo.toml.

A lot… A LOT better than package.json…

And can be edited without unloading the project first.

Better in what sense? Syntax aside, I don’t see a substantial difference in terms of file content. I do see a substantial difference in terms of tool capabilities (like .NET/NuGet’s inability to resolve conflicting diamond dependencies).

As much as I'm not a fan of the XML based project files, the csproj format is much more flexible/capable than package.json files. For example, you may want to have different versions of a package reference based on some condition. Would it be better w/JSON than XML? I think it's a toss-up.

That’s a good point. Rust’s cargo files have that feature as well. And I agree that surface syntax isn’t the main issue.

Lack of comment is a serious flaw for package.json syntax.

Csproj is one of the better build config setups, I'd say. In practice, the IDE handles it all if you want. What would you prefer instead?

csproj is fine these days. sln on the other hand...