Mike-EEE

My feedback

  1. 511 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      24 comments  ·  Visual Studio IDE » Project  ·  Flag idea as inappropriate…  ·  Admin →
      Mike-EEE commented  · 

      @john.ludlow.uk I like the way you think. :) I appreciate the properties pane from a utility perspective, but I agree with you that its implementation is pretty arcane (and not very extensible). It would be great to visually design and explore our project files in a extensible and flexible way. This is why I suggest Xaml as this can be done right now in the current IDE without much effort/work but I am definitely open to other options if the same power, tooling-friendliness, and flexibility is retained.

      Mike-EEE commented  · 

      I just got done making a simple app that does what the Developers Win! post mentions below. Please see this file:
      https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

      And (probably more importantly?) this file: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml.cs

      Here is a good example of a Xaml-driven application. In this case, all of the "steps" of the application startup are encapsulated in System.Windows.Input.ICommand's and they are called in succession to execute very discrete and encapsulated commands. These commands are then defined in the Program.xaml file that can be used to define all of the inputs and (what others might consider) configuration for the application.

      The power again is the markup extensions. There are some really cool ones here that are being used, such as creating a DirectoryInfo object that is used by subsequent components via IoC: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml#L22

      This line tells the application to pull all registered IInstaller's found within the current AppDomain and add them to the collection found within the InitializeDatabaseCommand:
      https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml#L44

      Very powerful stuff. This is how I see MSBuild vNext being implemented, and the new build projects looking very much like this.

      Hm... the more I think about this, the more I think that I should write a blog article on this. :)

      Mike-EEE commented  · 

      Hi David, thank you for your reply. At this point, I believe it's the features that ASP.NET vNext doesn't use but should and are already in classical/traditional projects. The entire wheel is being reinvented all over again, and we're having to pay with enduring all of the same (and new) bugs and quirks that go along with it. It is quite frustrating as I am sure you can imagine.

      Here is an issue I submitted that really started this vote and was the "last straw" for this feeling, really:
      https://github.com/aspnet/Tooling/issues/142

      Additionally, nuget packages now are viewed in the References node, but cannot be interacted with in any obvious way. One would expect a full set of features from right-clicking a nuget package listed References, but alas, it is only a mirage at present.

      Those are the two that strike me off the bat, but to be honest, I really didn't go past these observations. I had seen enough and created this vote instead as clearly there is obviously a systemic problem here.

      I understand that this is all supposed to be fixed at some point (by the final release of ASP.NET vNext), but the (really) big issue here is the fragmentation of the project system in the first place, and how we as developers are now having to deal with two project systems: one in traditional MsBuild xml and now another in .json. Neither of these are as tool/designer-friendly as Xaml, so it really adds to the confusion here on why such an effort was made to bifurcate/duplicate concerns into a new technology (that isn't MSFT-invented and based) altogether, rather than rallying/leveraging an existing (MSFT-invented and based) technology that is tried-tested-mature and is used in pretty much every product/group in MSFT except ASP.NET. :P

      The other major concern here is that a lot of noise was made around the new ASP.NET vNext projects that the experience was going to be "lit up" in Visual Studio. As we cannot easily exclude items from our projects, that simply does not appear to be the case at all. Projects have a very basic/dull feeling to them now, and there is a looming, almost-sinister feeling that if you have to get anything done now, you have to go crawling into an obscure .json file, and poke and prod it for any hidden easter eggs that may reveal working functionality that has already existed for over a decade in other, working project types in your solution.

      We were promised a "lit up" experience, but in reality, it is as if Visual Studio is the afterthought, and enabling external, non-MSFT editors is the primary focus. it's almost as if you're working hard to make OTHER companies successful, not yours, and that is no way to run a successful business. I understand the appeal and value in supporting environments outside of Visual Studio, but please don't do it at the expense of its quality, and (more importantly) the mind share that it affords.

      So, in summary, MSFT *First*... others second. :)

      Thank you for engaging your loyal customers! And please let me know if you have any further questions.

      Mike-EEE commented  · 

      Anything is possible with MarkupExtensions. :) This is the primary power of Xaml and why it is so great.

      First off, the notion of the XML used below is very arbitrary. I am not entirely positive it maps to POCO objects, and to this day (after working with Visual Studio for nearly 15 years!) still don't know what it ultimately resolves to. Instead, POCO objects are initialized, and then data from the XML presented below is then converted (ugly omgggg) and mapped to those POCO objects. This is one of the biggest problems with working with XML-based documents.

      In Xaml, you are working directly with a POCO object. This is why tooling works so well with, from intellisense to the beautiful designers used in Blend and UWP. In this paradigm, you would be designing POCO objects that are used to define build tasks. This is a much more coherent/cohesive manner to design, as Xaml developers know and appreciate. :)

      So, in your example below, PropertyGroups would most likely go away (and should). You would then be working with an POCO, we'll call it BuildTask:

      <msbuild:BuildTask Enabled="{x:Eval {x:Reference Item}, 'SomePropertyInt', 1 }">
      </msbuild:BuildTask>

      This is very quick psedo-code that has absolutely no bearing in reality. :) Just giving a VERY quick example of one way of handling this. In the case above, there is an Eval markup extension, that is referencing another item in the document (with the x:Name of "Item") and is evaluating a property on it named "SomePropertyInt" to see if it equals the number 1.

      Another example could be more terse:
      <msbuild:BuildTask Enabled="{x:Eval 'Item.SomePropertyInt == 1' }">
      </msbuild:BuildTask>

      This would do the same thing and be more aligned with what you see below, but using a stronger object identification structure that Xaml provides seamlessly. Additionally, now that Roslyn is around, the expression above should be a piece of cake to resolve. :)

      So, in regards to "good" replacement, it would be a little more verbose, but much more powerful and clear.

      Mike-EEE commented  · 

      Thank you for your support, José Manuel Nieto Sánchez! Please feel free to share this vote. :)

      Mike-EEE shared this idea  · 
    • 35 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        I agree to the terms of service
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        5 comments  ·  Visual Studio IDE » Cloud  ·  Flag idea as inappropriate…  ·  Admin →
      • 113 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          I agree to the terms of service
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          24 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
          Mike-EEE commented  · 

          Another thought here to add to the list above:
          7) Debugging. The experience of debugging an asynchronous call stack is terrible. You have to wade your way through several frames to one that can load, and those frames that do load are loaded with all sorts of compiler symbols and ugliness. This simply is not the case with a synchronous programming scenario.

          Mike-EEE commented  · 

          Thank you John for your feedback on my feedback. :)

          To start, I didn't make it clear, but the issues that i outlined are in descending order of priority. The naming convention is not as bad of an issue as say, zombie code infestation. With that said, I do not hold exceptions for words such as "extern", "enum" and "const." Those are not words either and should be extended to read as full words (IMO). The difference between those words and "async" is that writing "const" or "extern" in your code somewhere does not beget more of those words. Try doing a search for the amount of times "async" shows up in a code base designed around the current asynchronous model and compare it to the amount of times "const' and "extern" are used. I would also like to point out that UI and IO are acronyms, and not non-words.

          Additionally, I do not like typing out "asynchronous," just as much as I do not like to type out "async". I am suggesting that there is a cleaner way all around to introduce asynchronous code into a code base without having to denote it with such keywords altogether.

          Secondly, I would like to reiterate my statement in the original post that the current asynchronous model is pretty cool, and a welcomed improvement over the prior model. I am in agreement with you. However, just as class properties used to involve a required backing field, and were ultimately reduced to a single, powerful line as an automatic property (complete with constructor support) in C#6.0, there is always (ALWAYS!) room for improving a model to make it even better. That is the purpose of this vote.

          I would prefer a design that keeps my synchronous (cleaner) interfaces and classes in tact while still being able to denote a body of code is meant for asynchronous calls without having to couple it to specific classes.

          WCF design comes to mind. I can use a regular interface and still have its implementation dive into the WCF guts if I would like, via the use of OperationContext and other classes. It would be great to expose TaskContext (or AsynchronousContext) to do something similar with the .NET asynchronous model.

          The AOP technology PostSharp also has some wicked asynchronous capabilities used via attributes. That is also another alternative design that can be used, that I would find cleaner.

          That way, all code is kept synchronously-designed (and the integrity of the original design kept intact), but can further be used in an asynchronous context.

          And obviously, the goal here is to keep the current asynchronous model in tact, so that those who prefer the zombie infection can continue their plague-ish code if they so wish. :P When we talk about making a "major change" I am not saying we should forego the current model altogether, but again (just like properties to automatic properties), keep the existing model but also provide an improved way that allows it to be even better.

          Finally, I do not think it is professionals that "let go of" design that could stand to be improved. On the contrary, professionals constantly aim and find better ways to program and design. That is what this board is for, to highlight features that require improvement, and find ways of making them better.

          Mike-EEE shared this idea  · 
        • 3,302 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            I agree to the terms of service
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            40 comments  ·  Visual Studio IDE » Mobile App Development  ·  Flag idea as inappropriate…  ·  Admin →
            Mike-EEE commented  · 

            Congrats on 2,000 votes, Eder! As of the latest vote report yesterday, this along with 6 other votes comprise 22,775 votes towards the notion/idea of a cross-platform, ubiquitous .NET client application development model:
            http://blog.developers.win/2016/01/weekly-vote-report-for-friday-january-29-2016/

            When we get to 25,000 we should throw a party or something. :P

            Also, I've promoted (haha UserVoice does not like "p1mped" out) your 2,000 vote accomplishment on Twitter. Please feel free to like/retweet:
            https://twitter.com/DevelopersWin/status/693489065174392833

          • 8,057 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              I agree to the terms of service
              Signed in as (Sign out)
              You have left! (?) (thinking…)
              under review  ·  374 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
              Mike-EEE supported this idea  · 
              Mike-EEE commented  · 

              Excuse me, I used the wrong page in regards to NetMarketshare below. That was for the year of 2015. Here is the latest from last month. Google is actually @ 57%+:
              http://www.netmarketshare.com/report.aspx?qprid=8&qptimeframe=M&qpsp=203&qpch=350&qpmr=100&qpdt=1&qpct=3&qpcustomd=1&qpcid=fw823129&qpf=1

              Additionally, Apple announced 1B active devices today:
              http://www.theverge.com/2016/1/26/10835748/apple-devices-active-1-billion-iphone-ipad-ios

              They include Macs in this 1B active, which are technically desktops/workstations, another report provided by Netmarketshare. According to a graph found in this article, Macs comprise about 5% of sales:
              http://www.theverge.com/2016/1/26/10828134/apple-earnings-report-first-quarter-q1-2016-record-profit

              So with some extrapolation (I really should make this a blog post, LOL), we can figure the entire device market at present with the given statistics: 1B (total active devices) - 5% (Macs) / 35.43% (share as of Netmarketshare report December 2015 above).

              That brings the device market (based on my calculations) to 2.6B at present. Again, that does not include desktop/workstation which is its own ball of wax.

              I like to talk about this as it really underscores the market we as developers are living in, and gives us more facts/details about the business problem at hand. Hopefully it helps someone out there and provides a little more context around this problem space. Please also feel free to correct my understanding, as always. :)

              Mike-EEE commented  · 

              Hi Johann, thanks for your input. You are correct that Android/iOS has a great deal of marketshare.

              In total, based off Xamarin's 2014 keynote, there are about 3 billion total devices in the marketplace, half of which are devices (phones/tablets). That is about 1.5B iOS/Droid devices. This might be escaping a lot of people, but Google does appear to be winning the device market overall, currently with 51%+ of the total device market:
              http://www.netmarketshare.com/report.aspx?qprid=8&qptimeframe=M&qpsp=192&qpnp=12&qpch=350&qpmr=100&qpdt=1&qpct=3&qpcustomd=1&qpcid=fw8718&qpf=1

              Even if Windows 10 reaches 1B installs by 2018 (and it should, Windows 10 is pretty awesome), that still leaves 2-2.5B devices outstanding that a UWP-based application simply will not be able to reach, meaning a developer/organization will have to create additional code bases to reach the remaining market. Here is a graph that really illustrates what this will conceivably look like in 2018:
              http://i0.wp.com/blog.developers.win/wp-content/uploads/2015/09/20150923021143.png

              Hopefully what stands out in this graphic is that HTML5 reaches everything (all 3-3.5B devices), so its importance is truly critical in this effort. For full market reach that truly, effectively, and efficiently reaches all known, modern devices (or rather, to be truly ubiquitous), an application will need (at least) four code bases for the Big Four platforms: iOS, Droid, Windows, and web.

              Thanks again for your input and support. Please share the news/idea. :)

              Mike-EEE commented  · 

              @Aaron, well, with THAT attitude. Remind me not to put you in charge of any projects or applications that I need built. ;)

              I am not sure if you fully understand the ask/idea here, so I will try to attend your points one by one.
              1) when you say time and money "developing other things" -- this is exactly what is happening now in a very large scale with developers and organizations as a whole. Since technologies are fragmented and there is no consistent model that spans all known platforms that these technologies address, organizations and developers are spending their time between fragmented between these different technologies. Because of this, developers (.NET in particular) are becoming generalists in these different technologies rather than experts in one. More on this here: http://blog.developers.win/2015/12/is-net-in-trouble-belated-thoughts-from-connect-2015/
              2) When you say "new feature" I will need more context. To be sure, a great majority of required language "features" and platform capabilities are already present across the board. That is, from a .NET perspective, you can take any given feature and find its adaptive equivalent in any target platform. Xamarin and JSIL have proven this out and show there is no technical barrier from making this possible. You will need to provide a working example here to discuss further.
              3) A working example would be nice to know here, too. The capabilities are there, and there is no known technical barrier to keep this idea from happening. The existing barriers are political will and time.
              4) Here we are running into a systemic and pervasive misunderstanding of what a "web app" is and how it should be viewed. To be more accurate, a "web app" is simply a client application that is hosted within a web context. There is nothing conceptually different between a client application hosted on a server and one hosted on the local machine. However, we have had some pretty poor conceptions reinforced around this notion of what makes a "web app" compared to any other client application. We as a developer community as a whole have always thought of "web sites" as a different animal, but really they are indeed client applications and should be viewed as such. They are conceptually and semantically the same thing, but simply comprised and traditionally built in a different fashion from how other client applications are built. Web-hosted technologies have finally reached parity with native technologies and we are finally on a different playing field than what we have had in the past.

              As for Java for Gui... I am not sure that there has ever been a cross platform compilation/transpilation for this technology? From what I understand it was based on VM/plugin/installs (to this day even, annoying) so that is not the same idea/approach as this idea.

              Finally, I would like to point out that you suggest developers should continually reinvent themselves and the technologies that they work with, and this idea/suggestion does exactly that. ;)

              .NET is a major MSFT investment (probably the greatest/biggest?), and it should be protected as such. Thank you for your continued feedback, discussion, and support towards this idea.

              Mike-EEE commented  · 

              Thanks for the dialogue, developers... this is awesome. :)

              @Louis, that migration path is unfortunately one of a broken, incompatible system as highlighted by the series. It is transitioning into a sub-optimal and inferior design from a .NET perspective. Again this works great for JS-only solutions, but not so for .NET-backed ones. :(

              @stimpy77: this goes beyond Windows 10 and is for .NET client application developers. The bridges you speak of are going into Windows, not out of, which is backwards and what the series and this vision seeks to address. Even at 1B Windows 10 installs, there will still be ~1.5B installs of Droid/iOS that outweigh Windows 10, and even much more ubiquity found in the web:
              http://i0.wp.com/blog.developers.win/wp-content/uploads/2015/09/20150923021143.png

              @Marc: To be sure, the transpilers/compilers only come into play when you are ready to deploy to a target environment/platform. Until then you should be able to develop as you suggest: freely and quickly with instant feedback. And yes, I am dreaming out loud right with you, LOL!

              Mike-EEE commented  · 

              @Louis These are all good points, and truly showcase the need, desire, and most importantly the value of creating an innovative solution to revolutionize and cooperate with these standards -- to work in harmony with existing technologies, rather than remain incompatible, expensive and risky (of flight from use). You have only put two years into TS/JS. Think of those who have over 15 years of .NET experience. If .NET was truly compatible with all these new standards you speak of, then we wouldn't even be having this conversation. Unfortunately that is not the case, and we are speaking to that now. To be sure: .NET is currently incompatible with these exciting standards, but they do not have to be. New opportunities (and innovations) do lead to new business indeed!

              Mike-EEE commented  · 

              @Louis that is some pretty fantastic insight, thank you for sharing. It's good to see that you are validating a huge concern here with possibly jumping to NodeJS/JS for your backend, and why there is so much value in this vote. TypeScript might seem like a small step, but you are not just reusing existing knowledge, you are duplicating efforts/concerns between client/server code-reuse and breaking DRY/encapsulation, which ends up being very expensive, as I'm sure you know with your decades of rather significant experience. :) Some organizations might be OK with that, but they will not be as efficient/effective/dominant as those who aren't.

              It will be interesting to see if you end up going all-JS and dumping .NET altogether as other organizations/developers are edging/considering to do.

              Mike-EEE commented  · 

              @Louis I had to look up APL. Old skool huh. :) To be sure, technologies do come and go, but .NET is not exactly a one-hit-wonder technology. What will the next language be? This vote maintains that it should be the same as it has been: .NET (C#/VB.NET/F#) innovated for the web (and any platform). Well, that SHOULD happen, and that is the point of this vote. It's the only thing we can do and hope for the best, right?

              Otherwise, we will be going down the road as outlined in the referenced article. You either need a JavaScript backend to work nicely with your JavaScript frontend or you end up breaking DRY/encapsulation. This is an expensive approach and organizations that recognize this (and they are already starting to) will ditch .NET altogether. I am sure you can agree that this is hardly ideal, especially with developers/organizations with over a decade of investment/knowledge in MSFT/.NET.

              Mike-EEE commented  · 

              Well, if you are so convinced who am I to change your mind, Louis?. ;) ECMAScript/HTML5 is indeed a standard, but that doesn't mean it has to be incompatible with .NET. Mind you, the strategy that you are endorsing is incompatible with .NET, and therein lies the problem that we are attempting to solve here. Rather than following standards, the vision is to innovate with them while still preserving (and yes, strengthening) existing technologies.

              Have you read the rest of that series? You will see CSHTML5/JSIL/Duoco.de transpile .NET artifacts into 100% ECMAScript/HTML5-compliant code. That is the innovative approach that vision this is after.

              It can be done, Louis. Embrace your inner .NET addict and believe again. :)

              Mike-EEE commented  · 

              @Louis, using TypeScript (or traditional JavaScript) within a .NET solution introduces the problem discussed at length here:

              http://blog.developers.win/2015/10/the-broken-burned-bridge/

              Conversely, what this solution aims for is a .NET (C#/VB.NET/F#/etc) transpiler to JavaScript artifacts.

              However, we're all about and open to the idea and prospect of XAML-to-HTML5 transpilation as well. :)

            • 5,708 votes
              Vote
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                I agree to the terms of service
                Signed in as (Sign out)
                You have left! (?) (thinking…)
                73 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
                Mike-EEE commented  · 

                Amazing how much I surf this board and I still don't find gems like this one. :P Noble effort/idea, but I think efforts are better placed in asking MSFT to build the next Silverlight. I say this as a developer who invested 5 years in Silverlight. Silverlight was a subset of WPF, and to this day is the best client application development model offering developed by MSFT.

                Please take a moment to vote for the next version of its incarnation here: http://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

              • 36 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  I agree to the terms of service
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                  12 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →
                  Mike-EEE commented  · 

                  Hello Administrators, please close this vote and merge it into this one: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/10020390-enable-roslyn-powered-code-views

                  It does a much better job explaining the issue, and has a blog post with pretty pictures to outline the process. Thank you. :)

                  Mike-EEE commented  · 

                  Again, the issues mentioned would be solved by having the stored format would be just as customizable as the viewed format. The stored format even could be a 100% StyleCop compliant (which dictates how that Start and Stop should be organized/located in your code, btw -- something you may or may not agree with) code file. When you open that stored file, you actually open your own *view* of it, so it would view to YOU exactly how YOU like it... The Start and Stop would be exactly where YOU would like it to be in YOUR version of the file. When you save it, it gets saved and stored as the file format as configured and designed by the team/repo owner (which, again, could be a 100% StyleCop compliant file for the sake of simplicity in demonstrating and communicating this idea). Everyone wins. Which is the point of this feature/vote, as currently only one person "wins", while everyone else ... doesn't.

                  Roslyn really opens a lot of doors here. This would be a great implementation and use of it. :)

                  Mike-EEE commented  · 

                  Yes this is definitely an ingrained problem, and just in teams that use Visual Studio, but pretty much everywhere. It's a bit innovative, I admit, and it will take time for change and integration.

                  However... if Cobol's/Fortran's editors offered something like this back in the day, we would all be using it as well and wouldn't be giving it a second thought. :P

                  Mike-EEE commented  · 

                  Now thinking about this some more, I guess .ast files would be a bit of a misnomer. Going back to the idea of "strongly-structured" source files... Those could be files that are formatted to be 100% StyleCop-compliant (along with any rules that an organization would like to remove/add).

                  The process we really need here is:

                  1) .ast files are really "strongly-structured" 100% StyleCop-compliant and formatted .cs/.vb files. These are what is checked into source control.
                  2) When an .ast file is loaded in Visual Studio, an AST is loaded and created from it.
                  3) The AST from step 2 is then loaded and formatted based off the local developer's preferences. This then creates a local .cs/.vb "view" file that is stored locally (or better yet in the developer's OneDrive).

                  When a developer saves the .cs/.vb file, Visual Studio attempts to build an AST from it. If it does this successfully, it then saves this AST back to the .ast file as a "strongly-structured" 100% StyleCop-compliant and formatted .cs/.vb file. This trick here would to ensure that it is merge/source-control friendly (shouldn't be a problem) during this process.

                  I think I like this better. :)

                  That way, we're always working in C#/VB and we can view the code any time from anywhere using any editor. The only real difference is the internal formatting/translation process that occurs when the file is loaded in Visual Studio.

                  It is very irritating and unfortunate that you cannot edit a suggestion/idea after you create it! Otherwise I would update it with this new material. Bummer.

                  Mike-EEE commented  · 

                  Those are good points. Obviously if I had all the answers, I would be making this instead of suggesting it. :)

                  I have two thoughts around this:

                  1) .ast files are just serialized AST trees in Roslyn. So they could be serialized as Xaml files which would make them designer-friendly. The designer would then be responsible for processing the Xaml and rendering it in a way that makes sense to the developer. In fact, with this new paradigm, we now have the ability to render it as code (as traditional C#/VB -- exactly how you see it now in Visual Studio) or something completely different altogether. Conceivably, teams (and companies) could build their own renderers for the ASTs now in visually cool and interesting ways.

                  2) .ast files could still be saved as .cs/.vb files in source control. The difference here now is that the "source" file is formatted in a particular way that is not known to the developer, and is "strongly-structured" based off this formatting. That is, it's still C#/VB. When the file is loaded into Visual Studio, an intermediate process occurs where an AST is created and then what is displayed to the developer is that strongly-structured .cs/.vb file formatted based on the developer's formatting preferences.

                  Again, I don't have all the answers, and I am just suggesting what comes to mind. The idea here is that what gets checked into source control isn't necessarily unreadable (or binary).

                  Also keep in mind that this isn't meant to be required technology that everyone is expected to port over to immediately. It's just another way of sourcing files, and really a more exact way of describing the "code." Teams/companies/organizations can continue to treat their code the traditional (and contentious) way if they wish.

                  If #1 is used above, then you do have a point with viewing code on GitHub. Instead of seeing C#, users would see an Xml/Xaml/Data file and not code. There would have to be some additional thought around this to make this work nicely.

                  However, much more difficult problems have been solved in the history of computer science. :)

                  Thanks for the feedback! This is a fun problem to think about.

                  Mike-EEE commented  · 

                  It is similar, but not. The difference is that you have the "source" file (the .ast file) and then the "view" of that file (the "new" .cs/.vb file, or maybe .ast.cs/.ast.vb). The view file is the "formatted" file and would be on the developer's machine and what they interact with. Whenever the view file is saved, a new AST is created and saved to the .ast file. The .ast file is what is they used to compile an assembly.

                  The formatting can be configured to occur per keystroke and/or manually. A caching system could be created around each .ast file so that these differences you speak of can be account for, assuming you mean differences on a per-file basis (as opposed to a per-developer basis, which is exactly what this solution solves over-all).

                  Mike-EEE shared this idea  · 
                • 2,807 votes
                  Vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    I agree to the terms of service
                    Signed in as (Sign out)
                    You have left! (?) (thinking…)
                    13 comments  ·  Visual Studio IDE » Languages - F# Tools  ·  Flag idea as inappropriate…  ·  Admin →
                    Mike-EEE commented  · 

                    Geeze... so confusing. ;) Done.

                  Feedback and Knowledge Base