4 ms·

Even though I never fully got the hang of F#, I must agree on this one. I like C# as a language, but too many magic keywords just starts smelling wrong. Having

by trezor 16y ago

Even though I never fully got the hang of F#, I must agree on this one. I like C# as a language, but too many magic keywords just starts smelling wrong. Having a compiler do work for you and simplify your code is nice and you wont see me complain about this feature in particular. On the other hand, I've made enough monadic extension classes (NullSafety, Object-transactions, etc) and extension methods to cover up for short-comings as I've seen them in my projects, and it always bugs me how this effectively forces me to clutter up my syntax. Consider the following code var x = GetSomeObject() // can be null .SubProperty // can also be null .Indexer[index]; // can also be null This code can cause NullReferenceExceptions all over, so to do it safely, you need to add a bunch of if (object == null) checks. With my NullSafe-extensions, the expression looks like this: var x = GetSomeObject().AsNullSafe() .Do((x) => x.SubProperty) .Do((x) => x.Indexer[index]) .Value; // can be null or default Within the C# type-system, there is no way to get around this clutter and massive use of lambdas. Granted, it looks better than the corresponding code with manual null-checks for every step, but with lambda expression comes the cost of not being able to debug & correct code at runtime.

barrkel 16y ago
Magic keywords, as you put them, on the other hand increase the ability of the language to be tooled. You get better debugging, code completion, diagnostics etc. when what could be a library feature is implemented as a first-class language feature. The other side of the coin is that many larger businesses use coding standards to restrict the idioms in use across the enterprise. When the language is flexible enough to freely create new idioms (like Lisp and Smalltalk in extremis - the notion of DSLs came from these for good reasons), many folks fear that every codebase in the company will become its own silo of idioms, increasing the ramp-up time of new developers coming in. When an idiom comes packaged up from the tool vendor, "in the box" as it were, however, they can (hopefully) rely on new devs coming in to be up to speed already; as well as fairly confident it's been thought through properly. Furthermore, third-party libraries and software component vendors in general benefit by being able to assume that everyone knows and can support the idioms.

by trezor 16y ago

barrkel 16y ago

Magic keywords, as you put them, on the other hand increase the ability of the language to be tooled. You get better debugging, code completion, diagnostics etc. when what could be a library feature is implemented as a first-class language feature. The other side of the coin is that many larger businesses use coding standards to restrict the idioms in use across the enterprise. When the language is flexible enough to freely create new idioms (like Lisp and Smalltalk in extremis - the notion of DSLs came from these for good reasons), many folks fear that every codebase in the company will become its own silo of idioms, increasing the ramp-up time of new developers coming in. When an idiom comes packaged up from the tool vendor, "in the box" as it were, however, they can (hopefully) rely on new devs coming in to be up to speed already; as well as fairly confident it's been thought through properly. Furthermore, third-party libraries and software component vendors in general benefit by being able to assume that everyone knows and can support the idioms.