The evolution of a programming language over four years
codehereandthere.blogspot.com
codehereandthere.blogspot.com
The language is a complex "artifact" with many surprises waiting within it. Wanting to go as quickly to implementation as possible seems like mistake - better to spend "debugging" one's syntax and semantics and underlying data structures.
"There is no difference between theory and practice. In theory."
But there are plenty of pieces of information about an application that one won't get by running a bit of code.
Running part of a language implementation won't tell you if the language itself has a flaw that will annoy user because it won't run the entire language.
Running a single module won't tell you if there's a flaw in the way information flows in your application because the different modules aren't interacting.
And if you writing an application and find flaws in a user interface or similar large-scale aspects, you may find that you have to rewrite much of the application or jury-rig existing code to make things work. And iteratively jury-rigging code is a practice that guarantees extra effort latter.
It's usually hard to write real programs that do useful things before the programming language has an implementation.
Obviously, producing a full implementation and then using that implementation fully is the ideal way to find flaws. But considering that often everyone is too committed to change a language at that point, the result is simply that we right now have mostly languages that many consider flawed.