3 ms·

I share your sentiment. I'd been away from .NET/C# for a few years and came back to find that they dialed the abstraction level to 11. I adore C# as a languag

I share your sentiment. I'd been away from .NET/C# for a few years and came back to find that they dialed the abstraction level to 11. I adore C# as a language but I find myself increasingly alienated by its generally accepted coding style. I find that Microsoft's products have extremely unintuitive naming schemes at both a low level (language, standard libraries) and a high level (.NET product word salad naming schemes, Office 365 referring to a diverse and inconsistent range of products...). The skeptic in me thinks that this may be an attempt at educational lock-in. The lines between marketing and technology have definitely been blurred.

m_mueller 10y ago
Seems to me all big software houses are affected of this in their long standing products. You start a new thing and come up with a good name. 15 years with 17 product cycles down the line and you have a whole forest of names that have some relation to this thing. See also: iTunes (OSX), iTunes (iOS), "Music" (iOS), Apple Music, iTunes Match, Genius and the iCloud Music tab. Podcasts and videos are also all in there somewhere, know what dear user, you figure it out k?
- rdtsc 10y ago
  They brought in very highly paid, smart engineers. Which have periodic performance reviews. If they don't we "we designed and implemnted X, Y, Z awesome new abstractions / features" everyone in the room bosses, employees, higher ups, marking it going to feel let down. So, we have ever more features. "Say, Steve, what have you been doing last year?" - "Welp, just making sure things work, fixed some bugs, documentation, took customer calls. The product essentially works, people love it". "Wait, so we haven't shipped any new features, hmm, ok...". vs the response of "We implemented fizz, bar, quux features. We tore down old zig and added zag instead. It is really the same as old zig, but now look green and re-written with latest framework we saw in HN headlines". "Oh great, you get a promotion and a raise". I am being a bit silly, but it is only half-joking, it is how software industry often works.
bunderbunder 10y ago
It's not just Microsoft, though I agree they are really bad at naming. There are plenty of examples of similarly obtuse naming in open source. Storm, with its spouts and bolts, comes to mind.
edgyswingset 10y ago
Try using F# if you don't like the verbosity and over-OO-abstraction. It's fantastic.
- theprotocol 10y ago
  I'll be sure to give that a shot, thanks for the tip. You've made me realize I've somehow been subconsciously avoiding F# for whatever reason.
  - platz 10y ago
    Agreed. Subconscious reasoning is the worst.
zamalek 10y ago
> abstraction level to 11. Let's break the problem down. You have a language that doesn't natively support actors or message passing. You can solve this by having the developer stub each method (`this.DispatchActorMessage(...)`) or you can implement the interface on behalf of the developer (`Factory.CreateProxy<T>()`). Microsoft doesn't always use the runtime emit approach and, as someone who has used both approaches[1][2], runtime emit is far preferable. This means that something in your code has a responsibility to create actor proxies. That's the first concept: the responsibility to create actor proxies. Not only that, but so far as Reliable Actors go the proxy needs to do quite a bit of work: actors can be rescheduled to another machine and the proxy needs to continue representing that single durable instance. You also have context: "which cluster controls this actor?" Depending on your scenario you might be able to assume that there is no context. Microsoft cannot make these assumptions because federation is quite important in the enterprise. In fact, the ability for Reliable Actors to have context [will] allow our customers to extend our product without us worrying about noisy neighbors (they are in charge of their own actor cluster, we simply federate to it). Additionally, there are scenarios where the consumption of an actor occurs outside of the context. For example: calling an actor from a GUI app. In order to create the actor, you're going to have to use the object with that responsibility (unless you fancy doing the emit yourself): `ActorFactory.Create<IBrainActor>()`. You then need to pass in the context. Orleans uses a `Client` instance (which should make sense to .Net developers), while Reliable Actors pass the context into the `Create` method. So either: `Context.Factory.Create()` or `Factory.Create(Context)`. Nothing more than a stylistic choice necessitated by the requirements that Orleans and Reliable Actors don't share. The goal here is not to replicate Erlang. It is to make a framework where developers can write distributed systems with a low amount of ceremony. Actors so happen to be the best candidate as a primitive but are most certainly not the be-all and end-all of Reliable Actors (which were inspired by Orleans, so I assume the goal is the same for Orleans). In that way, it makes some things far simpler than Erlang[3] but there's always a cost to that. If distributed systems is the primary goal, then you're going to have overhead if you are not creating a distributed system. If you're talking about terrible naming, that outright I can agree with. Orleans, however, is no more and no less abstracted than it needs to be. [1]: https://msdn.microsoft.com/en-us/library/system.diagnostics.tracing.eventsource.aspx https://msdn.microsoft.com/en-us/library/system.diagnostics.... [2]: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-introduction/ https://azure.microsoft.com/en-us/documentation/articles/ser... [3]: http://erlang.org/doc/reference_manual/distributed.html http://erlang.org/doc/reference_manual/distributed.html

m_mueller 10y ago

Seems to me all big software houses are affected of this in their long standing products. You start a new thing and come up with a good name. 15 years with 17 product cycles down the line and you have a whole forest of names that have some relation to this thing. See also: iTunes (OSX), iTunes (iOS), "Music" (iOS), Apple Music, iTunes Match, Genius and the iCloud Music tab. Podcasts and videos are also all in there somewhere, know what dear user, you figure it out k?

rdtsc 10y ago
They brought in very highly paid, smart engineers. Which have periodic performance reviews. If they don't we "we designed and implemnted X, Y, Z awesome new abstractions / features" everyone in the room bosses, employees, higher ups, marking it going to feel let down. So, we have ever more features. "Say, Steve, what have you been doing last year?" - "Welp, just making sure things work, fixed some bugs, documentation, took customer calls. The product essentially works, people love it". "Wait, so we haven't shipped any new features, hmm, ok...". vs the response of "We implemented fizz, bar, quux features. We tore down old zig and added zag instead. It is really the same as old zig, but now look green and re-written with latest framework we saw in HN headlines". "Oh great, you get a promotion and a raise". I am being a bit silly, but it is only half-joking, it is how software industry often works.

bunderbunder 10y ago

It's not just Microsoft, though I agree they are really bad at naming. There are plenty of examples of similarly obtuse naming in open source. Storm, with its spouts and bolts, comes to mind.

edgyswingset 10y ago

Try using F# if you don't like the verbosity and over-OO-abstraction. It's fantastic.

theprotocol 10y ago
I'll be sure to give that a shot, thanks for the tip. You've made me realize I've somehow been subconsciously avoiding F# for whatever reason.
- platz 10y ago
  Agreed. Subconscious reasoning is the worst.

zamalek 10y ago

> abstraction level to 11. Let's break the problem down. You have a language that doesn't natively support actors or message passing. You can solve this by having the developer stub each method (`this.DispatchActorMessage(...)`) or you can implement the interface on behalf of the developer (`Factory.CreateProxy<T>()`). Microsoft doesn't always use the runtime emit approach and, as someone who has used both approaches[1][2], runtime emit is far preferable. This means that something in your code has a responsibility to create actor proxies. That's the first concept: the responsibility to create actor proxies. Not only that, but so far as Reliable Actors go the proxy needs to do quite a bit of work: actors can be rescheduled to another machine and the proxy needs to continue representing that single durable instance. You also have context: "which cluster controls this actor?" Depending on your scenario you might be able to assume that there is no context. Microsoft cannot make these assumptions because federation is quite important in the enterprise. In fact, the ability for Reliable Actors to have context [will] allow our customers to extend our product without us worrying about noisy neighbors (they are in charge of their own actor cluster, we simply federate to it). Additionally, there are scenarios where the consumption of an actor occurs outside of the context. For example: calling an actor from a GUI app. In order to create the actor, you're going to have to use the object with that responsibility (unless you fancy doing the emit yourself): `ActorFactory.Create<IBrainActor>()`. You then need to pass in the context. Orleans uses a `Client` instance (which should make sense to .Net developers), while Reliable Actors pass the context into the `Create` method. So either: `Context.Factory.Create()` or `Factory.Create(Context)`. Nothing more than a stylistic choice necessitated by the requirements that Orleans and Reliable Actors don't share. The goal here is not to replicate Erlang. It is to make a framework where developers can write distributed systems with a low amount of ceremony. Actors so happen to be the best candidate as a primitive but are most certainly not the be-all and end-all of Reliable Actors (which were inspired by Orleans, so I assume the goal is the same for Orleans). In that way, it makes some things far simpler than Erlang[3] but there's always a cost to that. If distributed systems is the primary goal, then you're going to have overhead if you are not creating a distributed system. If you're talking about terrible naming, that outright I can agree with. Orleans, however, is no more and no less abstracted than it needs to be. [1]: https://msdn.microsoft.com/en-us/library/system.diagnostics.tracing.eventsource.aspx https://msdn.microsoft.com/en-us/library/system.diagnostics.... [2]: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-introduction/ https://azure.microsoft.com/en-us/documentation/articles/ser... [3]: http://erlang.org/doc/reference_manual/distributed.html http://erlang.org/doc/reference_manual/distributed.html