That used to be the case, but I would argue that C#'s ecosystem is just as competitive now. For our backend tech stack at work, all of our libraries used are open source nugets. Back 15 years ago, paid nugets were definitely more standard.
Language design isn't just about adding every possible feature. For example, someone mentioned operator overloading. As someone who has written a lot of Scala, I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else.
I never understood the obsession some people have with the C# vs Java debate anyway. Generally, both languages are very good at what they do, each having its own set of advantages and disadvantages. Regardless, a developer can pick up the other language with basically no effort.
Java’s planned approach is more like typeclass-style interfaces than unrestricted operator overloading. Types opt into core-defined operator contracts, rather than every library inventing arbitrary meanings for symbols.
Hopefully a type error, because no sane programmer would implement addition like this. Obviously an insane programmer could, but that’s not the fault of operator overloading. The following code is exactly as confusing:
Take a person, add a job, you get an Employee or EmployedPerson. Person.add(job).
I agree overloading can create footguns, but domain concepts should make a lot of sense in context when basic arithmetic operations are performed on them. Party = Meeting + Booze.
Custom operators are a big assistance for DSLs, and overloading can also aide their creation and elegance. Part of the “awesome but don’t be a jerk about it” toolbox.
And the binaries, the default sdk when using java, i.e. oracle jdk, is still not open source, encumbered with a mine field of legalese. For a long time it also included malware as ask toolbar. Stay away.
To the point that after all the drama with J++ that lead to .NET and C# development, Microsoft nowadays is also an OpenJDK contributor with their own distributions, and official developer advocacy channels on YouTube, conferences and devblogs.
Turns out they really want to have plenty of Java development on Azure as well.
My mistake. I see my oversight now. `Either String String` is not equivalent to `String | String`, but to `Left String | Right String`. The same must be done for the C# version.
Yes, you must have individual constructors for the left and right cases in order to distinguish them. In C# you would use two distinct record types for this. Haskell’s syntax is more concise though, since you define the constructors inline in the declaration of the sum type.
No, it's a union of a left value (that happens to be a string) and a right value (that happens to be a string). But the compiler-generated code can't tell them apart.
What you are describing is something different called a disjoint union which will maintain the identities of the left and right values when there is overlap.
The C# unions appear to behave like unions, not disjoint unions.
My mistake. I see my oversight now. `Either String String` is not equivalent to `String | String`, but to `Left String | Right String`. The same must be done for the C# version.
You are correct that this requires support for disjoint unions (aka tagged unions), which Haskell always had and C# will soon have.
Half of his clever quotes are completely bonkers though and have been disproven by history. How many of you are proving your programs correct before entering them into the computer? Because that is the only correct way to program. And remember he disparaged Margaret Hamiltons software methodology. Sure, she helped put a man on the moon, but apparently she did it the wrong way.
I suspect geeks like Dijkstra because he is "edgy" more than because he is correct.
Also, Object-Oriented programming was actually invented in Norway, even though Alan Kay of Smalltalk fame tried to take credit.
He was right about GOTO though, but many developers did not even understand his argument but just read the headline and concluded "GOTO bad".
I like him because he is outspoken rather than because he is edgy.
I don’t know how amenable he was to his arguments possibly being incorrect, but I love working with/knowing people who are that combination of outspoken and not-overly-stubborn. People like that are a firehose of ideas and knowledge, even if not everything they say is correct. They also usually are “passionate” about their work and at least competent enough to have unorthodox opinions that don’t just sound blatantly stupid.
Most people are too timid or low-ability to be outspoken at all.
The GOTO-paper is widely misunderstood though. It is making a case for blocks and scopes and functions as structures which makes it easier to analyze and reason about the execution of complex programs. The case against unconstrained GOTO follows naturally from this since you can't have those structures in combination with unconstrained GOTO.
So in short, bitwise operators have lower precedence than comparisons to allow you to write:
if (a==b & c==d) ...
but of course, this means you can't write bitwise checks like this:
if (addr & mask == 0) ...
The problem could theoretically have been solved when the shortcut operators were introduced, by increasing the precedence of & and | to be higher than comparisons, but have the shortcut operators be lower. So you would be able to write both:
if (a==b && b==c) ...
if (addr & mask == 0) ...
But this was not done due to concerns of backward compatibility with existing code, since now every expression using the old pattern would subtly change semantics. E.g. the first example would now be parsed as:
> you could write [...] but of course, this means you can't write
I found this rather difficult to read. You could write those expressions. They're legal C code. Whether they will have the expected semantics will depend on, well, what you expected.
The more general problem is code that relies too heavily on precedence rules in the first place. Precedence-related bugs and readability issues are easily avoided, just use parentheses. As I mentioned in another comment in this thread, some languages force the programmer to do this.
I said code that relies too heavily on precedence rules. Your example doesn't do so.
In another comment [0] I mentioned that the Ada and Pony languages force the programmer to use parentheses when the expression would otherwise be confusingly reliant on precedence rules. Neither language requires unwieldy overuse of parentheses.
This C programming style advice article similarly recommends a middle-ground approach. [1]
I agree that unnecessary syntactic noise is bad (although this is essentially true by definition, as it's always a derogative). It can harm readability and make bugs more likely.
I always thought using the bitwise operator as if it were a logical operator was simply a mistake, even though it works because false is 0 and true is 1.
Edit: Mea culpa for reading and responding to the comments before the article.
I think it would be adopted exactly as widely as JavaScript is. People choose JavaScript because it is supported by the browser, not because they think it has a beautiful syntax. If some other language has been supported instead (whether VBScript or Scheme or whatever), people would use that.
Semantic markup languages were niche until the web happened. Objective-C was a weird niche language until the iPhone app boom. People learn the languages they need to learn.
Netscape had market dominance at the time so Internet Explorer had to keep bug-for-bug compatibility with Netscape to keep up. Given the amount of bugs and the lack of documentation of JS, this must have been quite frustrating for MS who was used to calling the shots.
reply