This is not true at all. I have personally looked into a reactor pool. I remember thinking how easy it would be to literally just jump in. I mean, I'd trip about a thousand alarms and probably end up in prison, but....
I'm not following you at all. Carbon was an API for Mac OS X, not a programming language. It was a C API, not an Objective-C API. (Maybe you are mistaking it for Cocoa, which required Objective-C on 64-bit platforms.) What relationship does this have to the new Carbon programming language?
Google did clobber another programming language with Go.[1] It was a truly a-hole move.
First of all, apologies for my boneheaded mistake, but let me try to see if I can show you the problem. If everything, everything there is, was named "Tom," you can see how it might get confusing determining just what is being talked about. That is hyperbole, but it should illuminate why it is ambiguous to call two things by the same name, but it is even more so when these two things with the same name operate in the same space.
But wait, you say, they are entirely different and unrelated! You think no one will be confused, because one Carbon is a programming language possibly based on C++ and the other is a C programming language API. Totally different, huh?
In fact, they're in the same space, programming. One Carbon is a language, the other a application programming interface for another programming language. They're also more or less dealing with the same programming language. I realize C is not C++, but without C there would be no C++, so they are very strongly related, along with ObjC. Fundamentally, these languages are all C, the newer ones using the same syntax but with advanced features not found in C. Still C, if we're being handwavy, and we definitely are.
So now, whenever someone mentions Carbon somewhere, like, "use Carbon!" That will be ambiguous due to this developer's unfortunate lack of nomenclature creativity.
Does that help at all to reveal why a new programming language based on C++ should probably chose a unique name rather than recycle a name that is still in use to refer to a C API? Since Apple already chose Carbon for their C API, and since it is so well established, even if it is no longer used, and since it is just not that old, and it when it was current, it was everywhere Apple, then it takes priority. So the arbitrary name this developer chose will inherently cause confusion, inevitably, because another Carbon already exists in the programming space.
Why not call it "Centigrade?" Or "lightspeed?" Because calling a C++-based language "Carbon" because it is based on C++ is not remotely as clever as Apple calling their C API Carbon because C is the symbol for Carbon, and not C++, which itself is a great name for a programminglanguage because it will never be confused with anything else, because afaik nothing other than C++ is called C++.
Let me know if you need more explanation why Carbon is an unfortunate name for anything new in the programming world. If it was, idk, the name of a publishing company or something, it wouldn't matter. It only matters because these things are in the same space.
+1 for this. It is a 'cool' name but this choice has problems.
As a practical illustration, it'll cause confusion when searching for 'carbon programming' or 'carbon apis' on $SEARCH_ENGINE. It isn't current but I would wager that there is still a lot of legacy Carbon code in the Macspace. This won't help the poor devs tasked with maintaining it. Unless they rewrite it in Carbon. See?
We in the trade also know how important it is to avoid giving things confusing names, and how frustrating it is when you find some garbled or ambiguous variable name while debugging or enhancing code. The same principle applies to naming your language too.
I don't think it matters. Do you? Abusive people who are enabled by their privilege need to have that privilege restricted. I believe they deserve such restriction as a form of punishment, a moral consequence of their abusive behavior. But even if you reject that moral analysis—and there are reasonable arguments for doing so—putting or keeping abusive people in power harms the community, and keeping community members from being harmed by an abusive person is more than enough justification for restricting the privilege of that person.
Natural languages are highly ambiguous. Using a naive approach like Early's algorithm can lead to thousands of parse trees for a single sentence. Probabilistic grammar parsing algorithms attempt to discover the "most likely" parse tree with respect to a particular statistical model of the language grammar. As with parsing algorithms for formal languages, different algorithms make different trade-offs. "Best" only makes sense with respect to a particular metric: "Best" in what sense?
I personally don't know much about this area beyond what I just said.
I'm not sure what your question is, there's all sorts of uninteresting complications to the trademarks on the name "Firefox" and how Mozilla deals with it.
Hope springs eternal in the hearts of men. Here's the thing: We have a LOT of evidence that those corporate promises mean nothing. There is a vast history inside and out of IBM of exactly this pattern of everyone saying nothing will change and then everything changes.
What you are saying to us is that the only reason you think nothing will change is that you really, really believe the IBM people. (Just like Palmer Luckey:https://thenextweb.com/wp-content/blogs.dir/1/files/2014/03/...) But that's even less than what other companies have been able to offer skeptics. But we know
"Seventy percent of U.S. acquisitions in the United States negatively impact the acquiring company’s results, sometimes immediately, and often continuing many years after purchase. Approximately 40 percent of the acquisitions of the last 10 years brought devastating business results. In about 80 percent of such cases, product or service, market share, and cultural impact are far below the goals anticipated in the beginning."
https://media.terry.uga.edu/socrates/publications/2011/07/bi...
YOU might be convinced, but you haven't given anyone a reason to believe it.
From my experience the only real proof that will convince people comes from the actions that are taken from now forward. I'd ask that if you believe these actions are harmful to developers or open source communities let me know @bradmicklea on Twitter.
