I moved this as requested by Robin2 already, but is this a common kind of nit-picking? I'm a 10 on the geek scale, and even I can't see the purpose.
You are both right, to an extent, not wholly. VS can communicate with the serial port of choice, in the same way the serial monitor in Arduino IDE does. What is nice is the ability to abstract the physical connection by dragging a serial port object onto the design surface (same with timers, etc.). I wrote an app that way that asks each available serial port if it has an Arduino on it, thus avoiding having to manually select it each time.
And as far as languages, there are "languaged" components all the way down to the USB/DB-9 (physical) level, so you could be arguing about where the "serial port" starts, and the rest ends, right? That answer will become fuzzy really quick... :)
English is not a high level language for serial ports/computers, so that is an apples/oranges example. But if you were picking nits, English can be used as a protocol to create serial port input & output. Does the hardware/middleware do the communicationg? Yes-just as much as the spoken word did.
No one piece/component/system 'communicated' with the serial port... they all did, and in this example they did it in a choreographed/unison way.
So to the last point made about 'tell me the menu option', the ones I cited above work, as do the locals/watch windows, none of which are actually part of the program under debug/testing.
Rather than making this continue like this after I started it, I would hope that I showed you (mostly PaulS) that you can't make black & white statements like the ones in this thread when it comes to what each part/component/system does. The language doesn't have ways to describe it like you say it is, and the systems can't be described as having such rigid logical/physical boundaries because they simply don't exist.
When I was writing UART drivers for the Amiga, the serial port (from the program's perspective) started once it was declared, and was represented by that declaration. That is the whole point of abstraction in programming, right?
To me, the new guy, when I write Serial.begin()... THAT is my serial port. If I want to read from, or write to, the serial port I do it from there. From my wireless module's perspective, the serial port is at the other end of the jumpers, the same way the Arduino sees it. They are both right, and I challenge you in kind to define the boundaries of a serial port that applies from the perspective of all components in the system.
I might even be able to defend the statement that any .NET 'language' (list here) isn't *really a language when you consider the mechanics of the CIL, and subsequent machine language.
So even after demonstrating that this is more of a discussion than an argument, I am left scratching my head wondering why PaulS is making such a big deal of it. I had no problem whatsoever understanding what @ieee48 was talking about.
And as an aside, I have one of those modules in your link! My post is about how to approach talking to it with an nRF on it! Ends up I then made thje topic off-topic as it was not an arduino. :)
P.S. I'm 80% of the mind now that it may end up being a nano on the usb port when implemented-especcially since this question was so hard to answer...
Lots of applications can. Some of them can even be written using Visual Studio. Some of them can even be written in VB.NET.
But a language can't. That would be like saying that English can communicate with the serial port.
And, Visual Studio can't. If you really think it can, tell me what menu option you selected to choose the serial port. The baud rate.