What, no design notes? #12630
Comments
|
While .NET, TypeScript, and other MS projects have become fully open source projects with major community contributions, my impression is increasingly that the Roslyn project is becoming much more of a source dump than an open source project. After some initial excitement when the code was first open-sourced on CodePlex, there seems to be little interest from the team outside of @gafter (and occasionally @mattwar, @ljw1004, @CyrusNajmabadi) in interacting with the community. Mads pops up literally only to occasionally post design notes and then disappears back into the ether. Compare this to the repos for any of the other MS projects, where the principles regularly engage with each other and the community on Github. This really is a shame, as I think the community can have a lot of valuable insights and contribute meaningfully (not counting myself in this, as there are lots of folks much smarter than myself who hang around here). I'm starting to wonder if C# and Roslyn are being de-prioritized at MS. It's either that or it's being severely mismanaged. It's telling that a full 50% of features of C# 7.0 are championed by one person. Despite the stated goal of releasing more frequently, the pace of progress is still glacial compared to many other modern language being actively developed (C++, Swift, Rust, TypeScript, the list goes on and on). It will have taken two full versions of the language, or at least 5 years, to add binary literals and digit separators, the simplest of simple features, from when they were first proposed. TypeScript has had 5 versions released in the last year. They will have designed, implemented, and shipped non-nullable types all while the C# team has punted this feature into a future version that is probably years away. And that's not even mentioning that when they do meet, the LDM seems to choose at random what features they're going to talk about- the last design notes were on extension members which isn't even being considered for C# 7. This when there are many outstanding design issues for features that are on the table. Talk about putting the cart before the horse. This project is desperately in need of some effective leadership and organizing, and for the sake of C#, I hope it happens. |
|
@MgSam You can't compare C# to TypeScript. One is a transpiler system and toolchain (sure mirroring ES6) and the other is a language used for more (without sounding too offputing) traditional software development. You know what I hate. Tuples and Pattern Matching. I find them totally repulsive. Guess what? C# 7 will move at a pace that also accommodates and caters to a crowd that can be more conservative than you. I love C# because it has a set of designers that are patient, thoughtful and decisive about the features they want. It's not entirely a bad thing. C++17 hasn't added much, C++14 didn't go too crazy either. Sure C++11 was a big jump, and it's been 5 years for that too. I'm terrified at some of the "pro performance" proposals being made, by the same lot of people. Game developers are coming to C# and they want Unsafe APIs, allocating reference types not on the GC heap, MSIL inside methods, etc. Then there is the pro F# gang. I open a .fs file and I go bananas, I don't understand anything. And now it seems there will be more of it in C# and it'll make me less productive. Nobody in the community thinks of that, but I'm so glad people steering C# as a language do think like that. I will one day have to read C# code one of you may have written and I'm concerned I will not be able to understand much of it, because it'll be F# like "->" code all allocated on the non-GC heap with intertwined MSIL doing .tail prefixes and localloc's all over the place. /end rant. There is another side of the story, that is being somewhat conservative to bring everyone along for the ride. I humbly request people who watch issue to see that side too. |
|
What would you like to know about? :)
Language design is hard. It's inappropriate to focus solely on the near future, without also taking a thoughtful eye toward where you want to be heading in the long term. We continuously discuss a wealth of topics to make sure we feel that we're on the right path and we're not making decisions in the short term that we'll regret later on.
One of the reasons to discuss extensions members is because it affects our thinking on how we do things in the tuples/pattern matching/deconstruction space. For example, if we felt that extensions could be used for deconstruction if they were tweaked slightly, then talkign about where we wanted them to go was sensible. Similarly, things like extension constructors or extension conversions becomes very important if as we consider how different types might convert to/from tuples. Language features are not designed in a vacuum. We have to consider how they work with the entirety of the language so far, as well as how they may work with what we think may be coming in later. We want to make informed decisions, and that means thinking and talking about all these concerns continually. |
|
@MgSam I don't think this is being fair. TypeScript is still brand new as a language, they don't have 15 years and untold millions of lines of legacy code to consider. On top of that, typescript is still 80% javascript. They more or less just need to parse, type check and then strip out their syntax additions. Roslyn needs to do sophisticated checking, lowering and compiling into a completely different language target (IL) along with the very ambitious goal of providing a public compiler API that serves major clients with different needs such as aspnet and visual studio while still being accessible to simple analyzers. That being said, i am a bit disappointed by the change in tone from codeplex where the discussions where richer and more two-way. This is probably due to the larger community here that depersonalizes the discussion as well as creates a flood of messages to the same limited number of respondents. As to the design 'monopoly' by @gafter....i don't mind. C# 7.0's feature list looks GREAT right now to me. I want every feature (and non-nullables and records) as soon as i can get them. What concerns me the most is the monotonically increasing open issue count in roslyn that would seem to indicate that the project is either under-resourced or mismanaged. I hope that @MadsTorgersen can comment on this issue, but i think that his email box has 10,000 unread emails from github on it and this will be lost in the noise. |
It should be noted that different people feel very differently about bugs and bug counts. I, for one, have no problem with bug counts going up. What i care about is quality, and that doesn't have a direct correlation to bug count or trending direction. |
Feel free to ask continue asking questions. People will converse, as before, when time permits. :) |
You are of course correct, but I think that an ocean of open issues makes things difficult to track effectively. Edit: |
There was an LDM last week on 7/13. Decisions came out of it which are changing syntax that had already been discussed here. I'd like to see the notes that came out of that meeting, perhaps with some bits of the discussion that led to the change. The team used to be quite good at writing up these notes and offering them here. I think @AlgorithmsAreCool is right, maybe the team needs some kind of emissary who's role is to help coordinate the communication. Even if that were more one-way and resulted in better dissemination of the team communication to the rest of the community I think that would be a huge win over the situation today. |
|
@roterdam You can't compare TypeScript and C# when it comes to technologies because they are doing two different things but you can certainly compare their development process! one is more transparent and open and the other just pretends to be open, the C# team shares the news with us when it's already too late to make any changes. That's how I feel, maybe I'm completely wrong but that's just the feeling I have. |
|
I think a lot of this is caused by looming 2.0 milestone. I'm sure roslyn guys are focusing on bugfixes and design work will pick up once next version ships. |
|
@ghord I was feeling the same way before RTM shipped. The team can't stay heads down forever. |
|
The reason that there is no new design notes or low level of conversation, may be that there is lack of developers who want to read and participate on this site. The fact is that there is small group 10-20 enthusiasts who daily track every news and changes. Others are visiting this site only to post bugs, or simple high-level ideas. |
|
I'd be happy with an update once a quarter. |
|
There are nearly 3,000 open issues here, a great many of which are related to new feature proposals etc. I think you are wrong in claiming that there's a lack of developers who want to participate. However, having posted their ideas, they are normally to be told (by a community member) that that feature has already been proposed in another issue. They read that, see that the comments are normally only from other community members, give up and leave. The only way that Mads' team will see more people getting involved is by them being more involved themselves. MS claim C# is now "developed in the open". This is clearly untrue. We have a public source dump here, but the language is still developed behind closed doors. C# is failing as an open source project, because it's not developed in the open. Until the team start holding language design discussions in the open (or at the very least, publishing minutes of all internal discussions), there is no incentive for the community to get involved. @ghord, |
I agree, this is disappointing. However, I would argue that being less transparent will not likely attract a larger audience. I don't know what the team could do in general to improve this situation. Certainly more exposure through the usual channels like Channel 9, MSDN Magazine, local events, etc. But I also don't know what the level of interest for a project like this really is, or the breakdown between people who view the repo and browse the issues v. people who actively participate to any real degree. I would expect that the real language enthusiasts would probably be a small minority.
This is what I would like to see. I would assume (and hope!) that minutes are taken of the LDMs anyway if only for the team to reference. It would be nice if that content were made available, even if in somewhat rough form. This would fit the bill of the role I had mentioned, an emissary between the team proper and the community. Someone on or close to the team who can sit in on these meetings and take these notes, clean them up somewhat for public consumption and then post them here. |
Yeah, what with: the release of .NET Core with a cross-platform implementation of C# (written in C#) and an open-source editor to go with it; the acquisition of Xamarin with their tools for creating mobile applications using C#; continual talking-up of Unity3D in a way that strongly suggests an acquisition is in the offing there too; and the talk of AoT compilation of C# code to native stand-alone binaries for Windows, Linux and Mac via CoreRT... it really just feels like Microsoft's hearts aren't really in it anymore. What I'm seeing is features that — to me, at least — seemed really quite simple and straightforward when they were first announced, turning out to be much more nuanced and complicated, and a team taking care to do it properly. It's far easier to iterate on newer languages like TypeScript, Swift and Rust because there aren't billions of lines of code out there to worry about breaking. And the infinite monkey cage that specifies C++ can (and do) do whatever they like because C++ developers expect opening a project to be like walking naked into a forest of thorn-trees on a moonless night and diving headfirst down a deep, dark well that may or may not have a hungry honey-badger covered with angry bees at the bottom of it. All that said, though, I'd like more updates too. |
This. Although i would augment it is: it's pretty much always known that any interesting feature will not be simple and straightforward. The initial 80% of the design can happen very quickly, but the rest takes ages. Just tuples alone has garned hundreds (maybe thousands) of pieces of feedback internally and externally on how people want it to work. There are all sorts of ways we can take it and make it do more stuff (for example, should KeyValuePair/Tuple have any relation? If so, what sort?). We try to strike a balance between not taking on too much, but also not making a new language feature so isolated from the rest that it won't be enjoyable to use. Then there's verification that we're not breaking anything (C# has a much higher bar around back compat than, say, TypeScript does). This is a large added tax to the process that does slow us down, but which our community has given long continuous feedback that they absolutely want this. And that's just the language side of it. On top of that, there's the implementation side. Remember that C# actually has to sit on top of an actual runtime with certain capabilities that we expose through the language. These have to actually be in sync and correct. This is not the case with languages like TypeScript. For example, in TypeScript, it's trivial to write 2-3 lines of code which produce no errors, and which contain nothing that subverts the typesystem (like a type assertion) that are considered typesafe by the compiler but which produce a type error at runtime. For example: var x: { a: number, b?: number };
var y: { a: number };
var z: { a: number, b?: string };
// much later
x = { a: 1, b: 1 };
y = x;
z = y;
z.b.charCodeAt(0)The comparison to TypeScript is not appropriate as each language has different goals and different features it promised. TypeScript wants to statically identify constructs that may be errors. But in doing so it might miss out on whole classes of issues (like above), or it may misidentify errors that will not actually happen. Because of this looseness, it's far easier to change the language and introduce new features as they have. That's a great boon to TypeScript, and i think it's the right choice for the domain it is going after. However, the same looseness does not apply to C#. That's one of the reasons that certain features (like non-null) we consider much harder to supply. We strongly seek to make sure the feature descends through the entire language, without corners that leak bad behavior (either through false positives or negatives). TypeScript also doesn't have to deal with things like metadata and how things are actually encoded and stored to be used by the .Net runtime. It is a 100% erased and only TypeScript source code is the source of information that TypeScript needs. The same is not true for .Net language likes C# which do not erase. This has made even seemingly basic features (like Tuples) very richly complex. For example, because tuple names are represented in metadata as attributes, you can run into issues where when tuples are used in signatures that are inside the constraints of generic type parameters, then those names are lost. In TypeScript such an issue does not occur because they erase entirely and do not need to examine metadata to know what's happening. For C#/VB we have to, and this hole is something we need to plug because we know that if our customers hit this they will be both confused and upset. Without work here, the names they've put in their tuples would be lost, and they'd no longer get good tooling information about what these tuples actually represented. This is just a tiny slice of the broad depth and time that has to go into just a single feature :) Now compound that with multiple features, which themselves overlap (i.e. Tuples and Patterns) and you'll find that language design takes a long time and that it's well worth it to spend that time so you don't end up releasing something you regret later but can't change. Note: i do not want to make this into a discussion about TS vs C#/VB. I just wanted to provide insight to help understand why direct comparisons between them aren't seeing the whole picture. C#/VB could operate more like how TypeScript does (and there are times i wish we could!). But we have strong evidence that doing so would likely produce language versions that would deeply upset many of our user base. |
|
@CyrusNajmabadi I fully agree with your posts, however, I think what some people want is not more features but more communication from the team. |
|
Also the discussion tends to be more C# focused, which gives the impression that the VB language isn't being worked on also. |
|
AFAICT, right now, several team members that generally write up and notes are involved in an Ecma summit. :) I fully expect that once that is done that more recent notes will be forthcoming. |
Which is another thing that makes comparisons to other languages not quite on point :) We've also got to work through all this stuff across multiple languages. And we have to consider how we're going to expose this through the Roslyn API as well (with all of its' back compat guarantees). And on top of all of that, we go and make things work in a multitude of editors :) At the end of the day, we're not just creating a language and a black box that takes in code and spits out IL. We're creating a whole API for working with the language and we're working on exposing all the APIs to allow you to work with it in an Editor context. It's a ton to do and we do the best we can at letting you see it by keeping the majority of our discussions and work happening here on Github. My personal preference would be that we consider moving straight to github as the location where we write our minutes as the meeting is in progress. That might help with the delay between the meeting and the release. The downside is that it's very possible for things to be much more raw, unclear, and possibly even incorrect. The current approach allows Mads the time to go through and dump a ton of expository content into teh notes explaining the wealth of positions presented, the thought process we went through, the pros and cons of the different approaches, and where we finally landed (if we did land). This makes the notes much more understandable and helps avoid misunderstandings and immediate off the cuff reactions. |
|
@CyrusNajmabadi I think we understand that you're doing ton of work and are aiming carefully so you won't miss anything in the process and get things wrong, I mean "better safe than sorry" right? However, I doubt that people want you to exchange quality with communication, we're asking for more communication on your side when it's possible and as often as possible! The most frustrating things for us is hidden changes and decisions that are made without any discussions or involvement of the community, you're going through things and decide what's relevant and what's not and by the time it gets to the community it's too late! I know we have no say about actual decisions and that's how it should be but it also feels like our opinions are meaningless! and that is the actual problem, at least for me. There's no transparency in the process, people don't know whether proposed features were even discussed because all the important decisions and discussions are made internally Now, it's pretty unreasonable to discuss every possible feature but features that are under discussions internally can be shared with the community, there are many smart people here, let them in! People that propose features would also improve their future proposals if they could know what are the reasons for their proposals to be declined or approved. It can also be nice if there was a clear roadmap for the language or at least blurry one that tells the community for say C# 7.x we're going to do that and in C# 8.0 we're going to explore this and that. |
I'm sorry it feels that way. It certainly isn't the case, and much of our discussions are precisely because we've heard feedback from the community about what they think. I routinely go and read through the hundreds of back and forth comments we've had on numerous discussion to help inform my own opinion on the feature and what i think is best moving forward.
i don't think there's a single feature that has been that way for C# 7. :) Our designs and impls have already changed a lot based on feedback we've gotten from teh community. It's true at some point there will be final decisions and those may end up being the "that's that" point for those features. That's true of any language being developed. You eventually get to the point that you've heard all the feedback, you've discussed things to death, you understand the tradeoffs between the multiplicity of different options, and you feel like you're making the best choice for the future of the language and ecosystem. Now, it may be that those decisions are not ones you want. Lord knows there are many decisions we make that I personally don't prefer. But that's just part and parcel of the process :) As time goes on the process goes more from open ended questions and design spaces, to a more locked down path where it's a lot less around figuring out the direction, and instead ensuring that everything necessary is done based on that direction.
Could you clarify this a bit? How would you prefer decisions be made? I think, currently, the opinion is that the LDM makes decisions. Decisions can take in feedback from people outside of it, but the decisions are ultimately in the hands of the LDM. As such, the process is inherently internal. In other words, i'd love some clarification on what, precisely, is being asked for. Is it a faster cadence from LDMs to publications of the notes taken? Are there other asks from you guys as to what you'd want? I don't want to guess at things and i'd lke to know specifically so we can see what of those requests makes sense to us and what we can try to do better with. Thanks! |
|
@CyrusNajmabadi First of all, thank you for taking the time to discuss this with us.
Okay, so currently say we have a feature that is discussed internally by the team, now, what I'm asking and I think that many people would agree with me is to post a summary of the internal discussions and this how I'd imagine the process should look like:
It can also be nice if there was a document that summarizes the issues that are created at step 4 or even a tag for it like "Internal Discussion" so the community would know what's hot! and can follow it. Obviously, this is a rough idea of what I think it should look like. Now, like @AlgorithmsAreCool said, maybe having a community manager for the language that will take some of the pressure off for refining the notes and posting them to the community can help tremendously. You can probably ask the TypeScript team about their process and maybe learn something from them even though the technologies are vastly different. So yes, we would like to have LDM notes as early as possible and we would like to know what's going on when changes are made especially when it comes to changes that were never discussed by the community. Currently, it feels like the process is similar to this:
Seems like the waterfall model to me. Hopefully this clarifies few things for you. Everything I wrote is from my own observation of the current state if I generalized and you share a different point of view please share it with us. :) |
|
For me personally, as primarily a lurker of the On a similar note, remember that GitHub tells you when something was last updated, and, for example, Language Feature Status.md hasn't been updated for 2 months. As outsiders we can't tell whether that's because there's nothing new to report or nobody's got around to updating it. And yes, we are developers too, and yes, we, too, suck at documentation and communication, but we hold you guys to a higher standard because you're Microsoft. The idea of minuting meetings directly into a GitHub issue or doc or something sounds good at first blush, but then I remember how some of the communications have gone over the last couple of years of this New Open Microsoft Adventure, and the not-necessarily-best ways certain changes/deprecations were (accidentally) announced, and, well... if I were you, I'd probably be wary of publishing anything that hadn't been carefully constructed and edited and probably proof-read by a couple of people for good measure. Remember: Fear The Rage. |
|
@CyrusNajmabadi
First two points are most important. We need design and implementation notes Design notes should be posted when team decide to design, change or implement feature (on prototype and final code), and are aimed mainly to gather feedback and discussions. Implementations notes should be posted regularly, just to track state of implementation features on booth prototype and final code.. Another problem is lack of any informations about VB. I am pretty fine that all proposals and discussions are made in context of C#, but I want to know what will be implemented in VB. Do you still maintain feature's parity between C# and VB ? Good news is that tuples will land in VB. But what with source generators, replace/original, typeswitch and other features ? None info about it. Recently I have found that team post progress on Twitter. For example here is news that Tuples work in VB There is no official C#/VB site, with news, events, discussions, proposals and anything other related to C#/VB. Other languages have such official sites, and Microsoft should create such site for C#/VB, especially that they are expanding these languages to other tasks, communities and platforms. Twitter, github and MSDN Blogs combined, are poor dispersed and inefficient replacement for such site. |
|
Well some good news is the DotNet Foundation has just brought in @rachelreese as Community Director. This can only be a good change, but I still think we could use someone down in the github issue trenches to bridge the gap in communication. I think Rachel's role is much higher level than that. |
|
@AlgorithmsAreCool That's awesome! :D |
|
GitHub is the site for any kind of engagement with Roslyn! currently we have no other alternatives unless you consider UserVoice that I really despise and dislike with all my heart. I think that GitHub is a great place for discussions, whether you like it or not it's your choice! people can decide for themselves whether GitHub fits their need or not and it doesn't even matter what it was designed for as long as it fits your needs, it's simple.
So they have zero issues and they are going to a completely different site to post these issues where you cannot use |
|
@eyalsk As for possible site, any forum's features may be added to provide great experience, the same or better than github, |
|
@vbcodec What's good about menus? they are hierarchical, you can't filter them and nested menus aren't pleasant, labels are are used for navigation just like menus would, the only difference is menus are sorted (for you) and labels aren't, meaning, you have to use the search, personally I like the search. Bottom line, I guess we will have to agree to disagree. :) |
|
Swift does their language design over an email list. I read some interesting quotes...
.
.
.
I personally manage a mailing list with ~20 posts per day. There's grumbling about email -- it's not archived, not easily searched, hard to keep track of the separate discussions. Some requested that we move over to github issues so it's easier to keep track of threads (with the idea that folks who prefer email can just rely on the github <-> email interface). |
|
The design notes are important as some contributors may not have been part of the project since it inception, or have access to other microsoft resources. |
|
I've been taking a break from commenting after venting a little bit in that post in the top of the thread. Some thoughts on things people have suggested:
|
|
@MgSam |
|
I agree with everything you say.
And type-switch. To be fair there is a lot of ground work being laid for pattern matching between type-switch, deconstruction and wildcards (7.1). I agree that source generators will be big and I think they will open a big sandbox in which potential new features can be explored without changing the language proper.
I whole-heartedly agree. I think that good labels and a good/maintained wiki will solve nearly all of those problems. Plus a landing page for the language that can help users for different audiences explore the language and development process. As for the popularity, I don't think that the language is the big problem there. It's the ecosystem. Until C# can run directly in the browser (or transpile to JavaScript), run natively on embedded devices with blazing-fast speed and run in Linux-based ecosystems I don't think C# can do a lot to compete with the top players. People aren't choosing to use Java, for example, because it has better language features. That's not an excuse for the C# evolution to slow to a crawl. But it's important to solve the problems and not chase the fads. |
|
@vbcodec I doubt anyone would claim C++ is either "fresh" or "simple", yet that language is now evolving faster than C# as well. @HaloFour I agree that platforms are part of the issue, but they're not the sole determinant. Xamarin is certainly a useful thing that people use, but when you're a team starting a new cross-platform project the case for using Xamarin gets harder and harder to make when C# is stagnating compared to the alternatives. I think if no one higher-up at Microsoft admits there's a problem here it's not going to get fixed. The issues are a lot bigger than the frequency of Mads dropping off design notes. Anders doesn't lead C# development anymore. Who has taken his place? From my outsider perspective it appears to be no one. The language design process cannot succeed without effective leadership. |
|
An example of why design notes are important, especially for offline discussions. Example |
The design team leads together on this.
A lot more evidence needs to be presented to indicate there is actually a problem to the level that you are indicating :) So far, i've heard a bunch of good feedback generally related to the difficulty it is to keep track of what's going on in a project as large as roslyn with github as the medium. There has also been requests for different types of organizational structures around how we do things. It's clear to me things could be tweaked slightly to make things far nicer for a certain segment of users we have. However, that's a far cry from the intimation that there's a very large problem going on. |
It's not that "people got waaay too caught up in the comparison". The point in the responses was to show why such comparisons are not suitable as different languages have different goals and issues they have to consider which can dramatically impact things like language velocity. You cannot simply compare one language to another without considering deeply all the issues and concerns they have. There are pros and cons of the different sorts of approaches and release velocity is one factor among many. |
Dropping other features would not have helped. The difficulty with Source Generators is not the compiler - that part was fairly straightforward. The difficulty is getting all of the rest of the tooling working smoothly. There simply are not resources on the affected teams to get it all done in the C# 7 timeframe. |
Expanding on what @gafter said here. We actually invested considerable resources in source generators for this release. The compiler is the easy part and was done rather quickly. This is true even though the compiler work is actually two features: source generation and replace / overrides. The challenge with source generators is not actually the language / compiler, it is instead the overall experience in the IDE. That includes semantic analysis, Intellisense, debugging, etc ... From a compilation perspective source generators function a lot like analyzers. At a specific point in the compilation pipeline hand them a From an IDE perspective though when to generate source is an enormous problem. This is essentially user code that can take an unbounded amount of time to complete. Yet the output of the generation is critical to the success of many IDE features. Take Intellisense for example: Imagine if for example on generator is furiously spitting out extension members based on the code the user is currently typing. The only way Intellisense can be correct is if it considers the output of the generator based on the latest source code. That means functionally the generator must be run + completed on every key stroke before we display Intellisense. That's a real problem. It essentially inserts 3rd party code directly into one of the most performance sensitive areas of the IDE. Doing so in this fashion is a recipe for bad performance and frustrated users. An enormous amount of time in generators went to solving problems of this nature. A lot of progress was made here and we have worked out the basics of changes to the design that would make the feature significantly more palatable for a good development experience. But it does require a significant amount of work and it just doesn't fit into this release.
Voting wouldn't have helped here. The problem isn't that we didn't invest resources. Instead it's that the problem required more time than we had allotted for this release. |
|
@MgSam |
|
@jaredpar |
|
As a language designer, one of the things i steadfastly work to avoid is adding a feature too early. For example, say we added replace/original in this release. Then for the next release we really tackled SourceGenerators. Let's say during that process we realized that replace/original was just not going to cut it and we would have to add something else that worked slightly differently but still shared similar goals and functionality. Now we're in a situation where we've got to maintain this feature from every moment forward. We also have to consider how this feature impacts everything else we do in every successive release. That's a burdensome tax that will hang around us forever and which will definitely slow down our release cycle. I think it is very important that we put features in when we feel that they're not only great, but really make the most sense for the future of the language. |
|
I always welcomed when the team decided not to push a feature into the release were they not 100% happy with it. Sometimes it prevented including things I personally found frightening, sometimes it prevented features I was looking forward to. Either way, it gives me a feeling of quality control in the process and I know that whatever makes it to the release is backed by sound design and firm belief of a team of experienced people that it is the right thing. Unlike @MgSam, I think C# is evolving pretty fast, actually. You can't please everyone, but everyone can now try their own ideas and see how far they get. And if another language fits your task better, use that one instead. I am also not concerned about the language "popularity". At the very least, I am not convinced that the fact that a language is so confusing that people have to ask questions about it is a good sign of anything. |
|
Hey all, @jmarolf suggested that one way we could give you more insight into what we've been working on is by posting a summary of our end-of-sprint review. So I posted the summary here. Check it out. There are some bits of work that aren't yet public but I figured it was better to let you know that there was activity on stuff that you just can't see yet that's taking up some of our time and attention. Let us know if you think this kind of summary is helpful to you. You can find the summary here: #12974 |
Frankly, being more transparent and more engaged with the community has nothing to do with the product, it has nothing to do with complexity, it has a lot to do with the people working on the product and the process itself. When we compared TypeScript and other teams at Microsoft to how things are done here we simply wanted to show that there are some teams that are doing it right and it's working for them, we didn't really compared products but we were speaking about the process of these teams working on different products, and when I speak about process in this discussion I really mean 1) How teams organize information? 2) How teams deliver this information to their communities? 3) How often this information gets to the community? these sorts of questions has nothing to do with how how mature the language is and how complex it is. One of the things that I really think the team should do or at least start at is write a document that explains the current process and moving forward what it's going to be like. Sorry if I've been blunt or harsh here, it isn't my intention to be disrespectful. @AnthonyDGreen, @jmarolf and for the rest of the team thank you very much for posting the sprint summary, this is a great start! |
|
@MgSam wrote: "This means C# 6 and 7 will ultimately be syntax sugar releases." Also, |
Say 'hello' to my proposal #7300 where I've expressed scepticism for source generators and replace / original. Looks like team realized the same issues, mainly low performance and polluting language with unnecesary features. I've muted my scepticism when these features were promoted to 'high interest', but now I have new more complete proposal, that replaces rejected features, while preserving their goals and potential.
|
|
@ljw1004 |
Nothing has been rejected. @CyrusNajmabadi was just explaining that we have held back the replace/original feature until we have complete confidence that they fully solve the generator scenarios - which we will demonstrate by shipping them together when all the tooling is ready. |
|
👍 on what Neal said. We still like this space, and i'm personally a fan of this source-based approach. But if we can't do it well, we should not rush something incomplete out the door. I'd much rather us spend the time necessary to make something amazing. |
|
@CyrusNajmabadi , @gafter Better option is extensible system based on metadata and IL codegen, that will solve these problems created by replace / original. |
|
We should leave the discussion of SourceGenerators to appropriate threads on that topic. It would be inappropriate to get into a long discussion on that topic here. The core point i was making was that we believe it's better to spend the time to get features right, versus delivering potentially wrong features too early. |
|
@jmarolf Is there anything going on with this website we proposed? or it's something that will come in the (shamelessly) far future? I know you guys are probably very busy for RTM but can we expect to have one after it? I guess that's what I'm really asking. 😄 |
|
The thread seems to have settled. I'll close the issue. |
Hello @MadsTorgersen et al.
There have been no design notes from the dev team since May; over two months ago. Aside from Mads appearing on .NET Rocks and disingenuously claiming that in C# 7, pattern matching will be 80% done (the real figure will be nearer 8% than 80), there haven't been any announcements on progress and plans.
Any chance of an update soon?
Thanks.
The text was updated successfully, but these errors were encountered: