C-like punctuation-heavy programming-language syntax isn't any more "old fashioned" than VB's word-based syntax is.
From the very beginning, higher-level programming language design involved choosing among these and other alternatives for syntax. And those choices were made by analogy with other programming languages and with other systems of representation.
Some early programming languages, such as FORTRAN and ALGOL, were influenced by mathematical and formal notations. They also noted the storage limitations of the machines they ran on, the line length imposed by input mechanisms such as punched cards, and other constraints. Those favored punctuation-heavy syntax. The C family falls in this category.
Other languages, such as COBOL and (to some extent) LISP, took their cues from other sources and generally preferred words over punctuation. This family came to include BASIC and Pascal and their descendants.
Then there are languages which aren't consistently one way or the other, such as various scripting languages - the Bourne shell and descendants (e.g. "case ... esac" but also "$((...))"), for example, or Perl - a mishmash of every idea Larry Wall could think of at the time.
These days, the languages I use most often are punctuation-heavy C and OO COBOL, which largely avoids the stuff. I don't think either has a clear advantage in syntax under any obvious metric, such as readability or maintainability. (OO COBOL probably does have a small readability advantage if you're reading code in some environment that doesn't do syntax highlighting and brace matching, but most developers seem to use syntax-parsing editors these days.)
Some languages, such as OCaml, arguably use punctuation constructs that are too obscure - they're hard for infrequent users to remember, and completely opaque to those who don't know the language, because they don't have analogues in, say, English or common mathematical notation. That, I think, is a design failure. But it's also relatively rare. C# has some constructs (the "verbatim string", for example) which are probably a mistake, but for the most part it sticks to things that should be recognizable to practitioners.