Syntax vs semantics: what’s the difference?

This is a subject that many programmers get confused about.  The difference isn’t really a difficult concept, it’s just that it’s not explained to programmers very frequently.  Let’s consider a snippet of a poem by Jeff Harrison:

know-bodies, devoted we to under-do for you
every Sunday-day of dressy morning, black pond,
sky’s germs, chairs’ ponds – prove it, stain!
us, rain-free & orphaned, we’re living laboratories
This is from Dart Mummy & The Squashed Sphinx.  If you haven’t figured it out, this text is generated by a computer.  And it uses the same techniques that a lot of spammers use.  What’s most interesting about this is that it’s grammatically correct.  For instance, “prove it, stain!” is a perfectly valid English sentence.  The problem is just that it’s meaningless.  Thus, we can say that the above poem is syntactically correct but has no meaning semantically.
Programming languages are similar in concept.  Consider the following Python snippet:
The above code is obviously incorrect.  It uses variables that haven’t been declared yet.  Therefore, it is semantically incorrect.  But it is a syntactically valid Python program.
In the same manner, we can say that these two snippets of code are identical semantically although they definitely have very different syntax:
python
def f(x):
return x + 1
rawplus1.py hosted with ❤ by GitHub
ocaml
let f x = x + 1
rawplus1.ml hosted with ❤ by GitHub
Therefore, we can define these terms like this:
 * syntax – A set of rules for specifying a program
 * semantics – The meaning behind that program

How programming language webpages should be designed

A while back, I asked a question on Stackoverflow that taught me something (other than what programming languages are fun to work with). A lot of programming language authors just aren’t very good at marketing their languages.

There are a lot of programming languages out there that I wanted to try out, but couldn’t figure out an excuse to spend my time on them. And that’s pretty sad considering how much I like trying new languages out.

Therefore, I’d like to present to the world my ideal website for programming languages: the Ruby webpage. In fact, I have to admit that if I were trying to decide between Python (my favorite programming language) and Ruby today, I’d easily choose Ruby just based on their website. And that would be sad considering how much I love Python.

Let’s take a look at why this is.

Show me the code!

I still don’t understand why this is such a difficult concept for some programming languages. The first thing I want to know is how my code
will look if I write it in your language. With Ruby, it’s right there on the first page.  Now try doing the same thing on the Python webpage.  Not as easy is it?

Even if you don’t want to put it on the first page, it should at least be reachable using one click on the first page.  See the Scala webpage for an example of this.

Feature lists are useless, documentation is priceless

Hey, your language is cross-platform, has object-oriented and/or functional and/or concatenative and/or [insert language buzzword here] features. Good for you! Since you’ve taken a whole lot of time to provide me with great features, show them to me.

Again, I hold up Ruby as a prime example of how to do this. Right on the front page is Ruby in Twenty Minutes. This shows me all of the great features in brief code examples. And if that doesn’t work for me, I can even try Ruby out in my browser.

As an example of how not to do this, I present the Unicon webpage. From the front page, I can gather that Unicon is a “very high level, goal-directed, object-oriented, general purpose applications language”, but that’s about it.

But we just met!

And one other thing, don’t try to sell me a book. Yes, you should make it easy to find books on your programming language. No, you shouldn’t remind me of it every chance you get. I view suggestions to buy a book as being somewhat like asking me to move in with you on the first date. Yeah, I find you interesting. I’m just not ready for the commitment.