Microsoft Adds Node.js Support To Visual Studio
shutdown -p now writes "Coming from the team that had previously brought you Python Tools for Visual Studio, Microsoft has announced Node.js Tools for Visual Studio, with the release of the first public alpha. NTVS is the official extension for Visual Studio that adds support for Node.js, including editing with Intellisense, debugging, profiling, and the ability to deploy Node.js websites to Windows Azure. An overview video showcases the features, and Scott Hanselman has a detailed walkthrough. The project is open source under Apache License 2.0. While the extension is published by Microsoft, it is a collaborative effort involving Microsoft, Red Gate (which previously had a private beta version of similar product called Visual Node), and individual contributors from the Node.js community."
...does it even Clippy?
Won't purchase without.
CLI paste? paste.pr0.tips!
I'm sure the NodeJs hipsters running the latest flavor of Linux with custom desktops will close out their sublime text and immediately wget that.
Please, for everyone's sanity, stop it with the JavaScript crap; it's a terrible language, a terrible platform for applications, and supporting it is just prolonging it's Reign of Terror. (this is why we still have flash).
-SaNo
If you know of a better client side web scripting language that has wide spread browser support, we are listening.
nothing? Yeah, I thought so....
HA! I just wasted some of your bandwidth with a frivolous sig!
How 'bout C89 support?
For that matter, how about C64 support? And small enough to fit on floppy disks...
(disclosure: I am a developer on PTVS and NTVS team)
I would hope that the track record of our particular team with Python Tools would speak for itself here - it's been out there for two years now, with 2.0 released last month, and it was and remains all about standard Python. While it does support IronPython, for example (but also Jython, PyPy, and other third party implementations), CPython remains the primary target because that's what the community uses, and our goal is to attract developers from said community to VS, Azure, and other Microsoft platforms and products, not to hijack their language/framework of choice.
The story with NTVS is similar: it's all about making VS a compelling choice for Node.js developers without forcing a Microsoft-top-to-bottom stack on them (which no-one would accept, and rightly so). In that sense, it is in line with Azure offering Linux VMs, or the ability to write Node.js-based Azure push notification services for Windows and Windows Phone.
Sure, karma is a bitch. In fact, part of what we're trying to do as a team is to turn it around, both the external perception as well as internal company understanding on openness - not just open source, though that as well, but generally working together on common things, and purging the NIH and the "we must be in charge" syndrome.
It's not just us, too - it has been a growing thing in the developer division, in general, with a lot more stuff being open sourced, and a broad change of attitude from a single monolithic take-it-or-leave-it stack, to going where the people already are and supporting what they already do. You might have noticed some other glimpses of that if you've been following the general news on MS dev story, e.g. with a renewed effort on C++ standard conformance, or a lot more attention to JS and HTML5.
The developers may want to have a word with the legal/patent department if they're looking for goodwill from the developer community at large. What Microsoft is doing with the Android patents is up there with SCO. They also teamed up with Appple as 'Rockstar' for some of the worst patent abuse around, and lobbied against the current patent reforms. It's going to be a big job.
Why can't Microsoft put out a Visual Studio plugin for Powershell with full intellisense, breakpointing, inspections, etc. ?
We don't need to - someone else already did that.
Keep in mind that we're a relatively small group - 6 developers/testers (we all do both) and 1 project manager, covering two projects already (PTVS and NTVS). We can only do so much. Then again, that's precisely why the code for both products is open source - so that people can take it and use it as a foundation for similar products for other languages. Here is one more for PHP, for example.
Note that GP asked about missing C99 feature that "would take a week or so to implement". Having said that:
Do they have stdint.h now?
It has been there since VS 2010.
How about conforming to C89's strict aliasing rules?
A compiler doesn't need to do anything special to conform to those rules, so this has always been the case. Conformant programs have to be written carefully so as not to trip up an optimizer that relies on strict aliasing, though. I have to admit that I don't know whether VC++ optimizer does use the opportunities presented by strict aliasing, like g++.
Restricted pointers? They have that under __restrict, but again, you have to #define if you want to use restrict with MSVC code.
There's no support for "restrict" yet, and __restrict is subtly different in semantics.
My own personal take on software patents (which is obviously my own only, does not represent the opinion of my employer in any way, blah blah etc) is that they can play a useful role, but they should be significantly scaled down in terms of what you can patent. Complicated algorithms, like, say, MP3 or H.264 or other compression stuff - probably yes, since that takes real time and effort to develop. But I'd love to see the "one click" patents die a fiery death. Some laws that would require non-discriminatory licensing for useful patents for interoperability and standards compliance purposes would also be great.
So EFF gets part of my paycheck every year. Ironically enough, it qualifies for MS donation match program, so they match it dollar for dollar. ~
Designated initializers?
They're there in VS 2013 already.
Compound literals?
Also in VS 2013.
_Bool / stdbool.h as well, and most C99 standard headers except for tgmath.h are there as well.
Also, array sizes defined at runtime is theoretically easy
Dynamically stack-allocating arrays is indeed easy, which is why this feature is also being standardized in C++14. The problem with C99 VLAs is that they are far more than that - you also have things like VLA typedefs (which should remember the size at the point of the typedef, even if the expression that defined it changes later), or parameter arrays where their size is specified by another parameter. Also, the abomination that is dynamic sizeof.
but depending on their codebase (ie, if they are crappy compiler writers that depended on things they shouldn't have), I could see it being hard.
The compiler itself is really ancient. Consider this: gcc 1.0 was released in 1987; Microsoft C was released in 1983, and that was built on top of an even older third-party codebase that was purchased back then. It probably changed a lot since then, like gcc did, but all legacy codebases of that size acquire a lot of legacy cruft (hence why Apple decided to stop mucking around with gcc and just do Clang from scratch). I don't know much about current VC code, but one piece of information that the team has shared publicly is that the front-end doesn't actually operate on an AST, but is rather a multipass process-as-you-parse thing, which makes a great many modern C++ features like constexpr very costly to implement.
jQuery is about JavaScript running on the server side - in the browser. Node.js is about JavaScript running on the server - instead of C#/ASP.NET. The "event-driven, non-blocking I/O model" basically means that all APIs that are normally blocking are instead done asynchronously, with you having to provide a completion callback every time you call one - so threads are never blocked waiting for I/O. For a C# developer, this is basically very similar to all the new stuff about System.Threading.Tasks and async/await in .NET 4 and 4.5, and specifically support for the latter in ASP.NET.