I am not Microsoft's biggest fan. I disliked their products and strategies in the 1990s, when they had a virtual monopoly on desktop operating systems, office software, and development tools. Yet I must give them credit for two recent products: OneDrive and Visual Studio Code.
OneDrive
OneDrive synchronizes files across multiple devices. I can store a file in OneDrive on computer A and later retrieve it on computer B. OneDrive stores data on Microsoft's servers and associates it with my account. If I log in to a Windows computer with my ID and password, I can see all of my files on OneDrive. The files are not copied to the local computer, they are simply available for me to view, change, or delete.
OneDrive also provides storage for online services such as Office Online. This lets me use any computer, even a public one in a library. (I think. I have yet to try this. But it makes sense for Microsoft to do things this way.)
Visual Studio Code
The other product that deserves credit is Visual Studio Code.
Microsoft advertises Visual Studio Code as an editor, yet it is much more. It edits, color-highlights, checks syntax, refactors, debugs (at least with Python), and integrates with git. It has an impressive array of features in a small package. What is significant is that the features are just the right set -- at least for me, and I suspect a large number of developers. It is not weighed down with all of the features of Microsoft's classic Visual Studio package. Visual Studio Code omits the templates and the auto-generation. It replaces the package manager with a series of lightweight plug-ins. It seems to ignore Team Foundation Server (and services), although I could be mistaken about that. (Perhaps there is an enterprise version of VS Code that connects to TFS.)
Beyond the feature set, Visual Studio Code... works. It's a competent product, one that feels good to use. It has just enough to get the job done, and it gets the job done well. I feel comfortable using it. (And that's a rare thing with me and Microsoft products.)
Visual Studio Code is a departure from the traditional Microsoft approach to software. The old Microsoft built software for Windows -- and Windows only. (A few exceptions were made for Mac OS.) Visual Studio Code breaks from that tradition: it is available for Windows, Mac OS, and Linux. This is indeed a ground-breaking project.
OneDrive and Visual Studio Code make for a pleasant experience when developing code. Microsoft deserves credit for bold choices and good tools. If you have not tried them, I recommend that you do.
What have you got to lose?
Showing posts with label Visual Studio. Show all posts
Showing posts with label Visual Studio. Show all posts
Tuesday, February 12, 2019
Tuesday, March 31, 2015
Our tools shape our languages, and our programs
Our applications are shaped by many forces: budget, available talent, time, languages, and tools.
When designing applications, languages are sometimes overlooked. Yet it should be obvious to anyone who has used multiple languages. Different languages have different capabilities. C and its descendants have the notions of pointers, something absent in COBOL, Fortran, and BASIC. The notion of pointers lets one build dynamic, complex data structures; such structures are not possible in pointerless languages.
Our tools have an effect on our languages, which can have an effect on our applications.
In the Microsoft world, C# is a simple language, yet the .NET framework of classes is complex and wordy. A simple application in C# requires a significant amount of typing, and a moderately complex application requires a large amount of typing.
Languages such as Perl, Python, and Ruby require less typing. How is it that the .NET framework is so complex? The answer, I believe is in Visual Studio.
Microsoft's development environment is the result of competition and years (decades?) of development. Over that time, Microsoft has added features: debugging, test case management, design documents, and editing features. One significant editing feature is the auto-completion of typing with context-sensitive information. When I am typing a C# program and I start typing a name of a variable, Visual Studio gives me a list of existing variable names. (It also knows that the declaration of a variable is different from the use of a variable, and does not prompt me with existing names.) Visual Studio also lists methods for objects and provides templates for parameters.
This assistance from Visual Studio reduces the burden of typing. Thus, applications that use the .NET framework can appear wordy, but the effort to create them is less than it appears. (Some have argued that the assistance from Visual Studio helps reduce errors, as it suggests only valid possibilities.)
Thus, a development tool can affect our languages (and class frameworks), which in turn can affect our applications. When choosing our tools, we should be aware of their properties and how they can affect our projects.
When designing applications, languages are sometimes overlooked. Yet it should be obvious to anyone who has used multiple languages. Different languages have different capabilities. C and its descendants have the notions of pointers, something absent in COBOL, Fortran, and BASIC. The notion of pointers lets one build dynamic, complex data structures; such structures are not possible in pointerless languages.
Our tools have an effect on our languages, which can have an effect on our applications.
In the Microsoft world, C# is a simple language, yet the .NET framework of classes is complex and wordy. A simple application in C# requires a significant amount of typing, and a moderately complex application requires a large amount of typing.
Languages such as Perl, Python, and Ruby require less typing. How is it that the .NET framework is so complex? The answer, I believe is in Visual Studio.
Microsoft's development environment is the result of competition and years (decades?) of development. Over that time, Microsoft has added features: debugging, test case management, design documents, and editing features. One significant editing feature is the auto-completion of typing with context-sensitive information. When I am typing a C# program and I start typing a name of a variable, Visual Studio gives me a list of existing variable names. (It also knows that the declaration of a variable is different from the use of a variable, and does not prompt me with existing names.) Visual Studio also lists methods for objects and provides templates for parameters.
This assistance from Visual Studio reduces the burden of typing. Thus, applications that use the .NET framework can appear wordy, but the effort to create them is less than it appears. (Some have argued that the assistance from Visual Studio helps reduce errors, as it suggests only valid possibilities.)
Thus, a development tool can affect our languages (and class frameworks), which in turn can affect our applications. When choosing our tools, we should be aware of their properties and how they can affect our projects.
Thursday, May 24, 2012
Microsoft Visual Studio Express abandons the desktop
Visual Studio 2011 Express Edition (the free version) does not support desktop applications.
By abandoning the desktop for entry-level users, Microsoft is sending a clear message: the Windows desktop is now a mature market. By "mature", Microsoft is limiting development of desktop applications to professionals -- people who are willing to pay for the tools. The hobbyists are "guided" into the web and Metro environments.
As I see it, Microsoft recognizes different futures for desktop and web/Metro applications. Web apps and Metro apps have a vibrant future with lots of growth and creativity. Desktop apps... don't. Desktop apps are maintained, but not enhanced.
This is not to say that desktop apps will go away. There are too many businesses with too many critical applications that run on the desktop.
But it does confirm a shift in the landscape. New apps will be mobile (iPhone/Android/Metro) apps. Or web apps, for those organizations that do not want to move to mobile.
Just as mainframe applications are still with us (billing systems, payroll, general ledger...) Windows desktop applications will remain with us. But the environment is now sterile. It bears no fruit.
Microsoft's choice with its latest offering of Visual Studio is the right one. Hobbyists and beginners must work in fertile environments.
By abandoning the desktop for entry-level users, Microsoft is sending a clear message: the Windows desktop is now a mature market. By "mature", Microsoft is limiting development of desktop applications to professionals -- people who are willing to pay for the tools. The hobbyists are "guided" into the web and Metro environments.
As I see it, Microsoft recognizes different futures for desktop and web/Metro applications. Web apps and Metro apps have a vibrant future with lots of growth and creativity. Desktop apps... don't. Desktop apps are maintained, but not enhanced.
This is not to say that desktop apps will go away. There are too many businesses with too many critical applications that run on the desktop.
But it does confirm a shift in the landscape. New apps will be mobile (iPhone/Android/Metro) apps. Or web apps, for those organizations that do not want to move to mobile.
Just as mainframe applications are still with us (billing systems, payroll, general ledger...) Windows desktop applications will remain with us. But the environment is now sterile. It bears no fruit.
Microsoft's choice with its latest offering of Visual Studio is the right one. Hobbyists and beginners must work in fertile environments.
Subscribe to:
Posts (Atom)