This post originated from an RSS feed registered with .NET Buzz
by Paul Vick.
Original Post: BASIC principles
Feed Title: Panopticon Central
Feed URL: /error.aspx?aspxerrorpath=/rss.aspx
Feed Description: a blog on Visual Basic, .NET and other stuff
John Montgomery’s entry on “Express “Orcas” Principles” got me thinking about the whole “principles” thing. Just like you should always be able to give an elevator pitch for your product, I think you should always have a clear idea of your product’s principles. I particularly liked Bjarne Stroustrup’s description of C++’s principles in “A Brief Look at C++0x”:
C++ is a general-purpose programming language with a bias towards systems programming that:
is a better C
supports data abstraction
supports object-oriented programming
supports generic programming
By "systems programming", I mean programming the kind of tasks traditionally associated with the operating system and fundamental tools. This includes the operating system kernel, device drivers, system utilities, networking, word processing tools, compilers, some kinds of graphics and GUI, database systems, games engines, CAD/CAM, telecommunications systems, etc. This kind of work is strongly represented among current C++ users.
I recently wrote up a paper that tried to distill some new ideas we’ve been kicking around here in VB-land and decided to submit it to Bill’s latest ThinkWeek. Remains to be seen whether he actually reads it (submitting papers is quite in vogue these days, so there are a lot of ‘em), but I started the paper by laying down what I see as VB’s “principles”:
Visual Basic is a general-purpose programming language that prioritizes ease of use. In particular, Visual Basic is designed with the following principles in mind:
Approachability. English-like syntax is used to promote the clarity and readability of code. Wherever possible, meaningful English words or phrases are used instead of abbreviations, acronyms or special characters.
Simplicity. Extraneous or unneeded syntax is generally allowed but not required. Language semantics prioritize understandable behavior over technically "correct" behavior.
Flexibility. Data types can generally be omitted for brevity and speed of development, but can be introduced at any time to improve error checking or environment feedback.
Pragmatism. Working in a natural way is a higher priority than language purity. Supporting more than one way to accomplish a task is acceptable if it supports common development methodologies.
Platform support. The language enables programmers to take advantage of the major features of the .NET Framework and is always consistent with its conventions.
Do we always fully live up to these principles? Probably not. Do we always strive to achieve them anyway? Definitely.