Chad Perrin: SOB

15 February 2007

syntax vs. semantics: the other way around

Filed under: Cognition,Geek,Metalog — apotheon @ 06:38

I recently (measured in hours) commented on a disagreement over syntax and semantics. I’ve come to a realization:

The people who disagreed with me may not have been completely out in left field in their disagreement with my characterization of each. That’s not to say I was wrong — just that they were possibly looking at it from an alternate viewpoint. Unfortunately, that’s not all there is to it, so we can’t all just go home happy that we’ve agreed to disagree about the angle of our view on the matter.

I referred to semantics as the more “superficial” of the two aspects of language design, because its effect on the way we program is more superficial. By contrast, then, syntax has a “deeper” effect on how we program than semantics. That’s my perspective.

I don’t know if this is their perspective or not, but it occurs to me that it’s a possibility:

Syntax refers to the most visible aspects of language design — in what order you arrange things, what elements are necessary to compose a complete (and correct) statement, and so on. Semantics, meanwhile, refers to the meaning of things — such as whether your return statement returns the value of something or a reference to it.

Both, of course, can have a significant effect on how we program when using a given language. It really may even be arguable which has the greater effect, and (despite its rancorous phrasing) reddit user akkartik‘s comments in a new reddit discussion begin to make some interesting points to the effect that semantics have a more significant effect on how we think about programming than syntax, even though I think he’s achieving some of that via (perhaps accidental) exaggeration. There’s a potential nugget of wisdom buried there, however, and it’s worth considering, even if the guy strikes me as a first impression as a bit of a wanker. update: It’s becoming pretty clear he’s not actually a “wanker”. Don’t judge a book by its cover.

Ultimately, the implication that most interests me is that there are aspects of programming language design that could, from a perspective other than the one with which I started, be assigned to semantics rather than syntax — though I would have assigned them to syntax. After some thought, I think some of these characteristics actually fall into a gray area between the two, where syntax and semantics overlap. These, in fact, may be among the most influential characteristics of a language’s design in determining how the language really shapes effective programming practice using that language. For instance, the Lisp notion that everything is a list is made feasible, even in theory, only by considering specific syntactic and semantic considerations that necessarily blend a bit in the middle. Considering that “everything is a list” is kinda the central defining characteristic of Lisp (popular gushing about macros, and incredible power granted by code == data, aside), that makes a pretty good case to me for the integration of syntax and semantics at the point where the interesting stuff happens.

I’m still not entirely convinced, but it’ll take some thought or, if someone actually manages to pull it together enough to offer one, a cogent argument.

That’s where the new problem arises: Even if the other participants in the earlier discussion were simply looking at things from a different perspective, they were absolutely incapable of expressing a salient point. The (nominal) counterpoints to my statements were nothing but unsupported, mindless naysaying. In the new discussion, pjdelport even ends up falling back on an argument from authority fallacy to show how stupid I must be. (S)he even assigns pejorative meaning to my use of the term “ignorance” in the process, where it wasn’t really intended — after all, everybody’s ignorant about a great many things, even me. (It’s the term “displays” that carried pejorative meaning in that sentence.)

Of course, akkartik made the same mistake when (s)he said:

apotheon’s wrong regardless [. . .] in mistaking humility and politeness for ignorance.

The Ruby Experience

Filed under: Geek — apotheon @ 04:27

I’ve always been a little put off by the Pythonic “There Is One Right Way To Do It” ethic. It’s not just because I like Perl, with its “There Is More Than One Way To Do It”.

I’ve had discussions in the past with Pythonistas about the differences between Ruby and Python. I’ve mentioned the fact that I like the Ruby community’s attitude about how things are done, and that I don’t like the Python community’s attitude so much. I have also mentioned that (unsurprisingly) the languages reflect the communities’ attitudes as an implementation of principle — languages tend to accrete communities whose policies match the languages’ policies, after all.

Well, this first impression of Rails 1.2.1 illustrates something essential to that community and language policy of the Ruby language, something I like about it. Specifically, this bit caught my attention:

I’ve mentioned that this is what coding in Rails continually feels like: sometimes it just feels off even though it works and is nicer than other languages, and soon I realize a beautiful Right Way to do it.

In other words, the language tends to encourage elegant, “Right” ways to do things, but you don’t feel like you have a gun to your head demanding you make it happen that way. It’s like the language teaches the attentive programmer, helping him learn for himself how to program better. Python, meanwhile, (generally) just refuses to let your program run if it’s not written the way the language designers have decreed is the Right Way. At least, that’s how it feels, reading about the language, reading the occasional bit of source code, discussing its “benefits” with Pythonistas, seeing direct translations between languages, and even (horror of horrors) once in a great while editing a little Python code.

I definitely prefer something fairly open, that gently guides me toward doing something beautiful, over something that just limits what I can do to a set of “correct” actions. I guess, the way I see it, if Java is the new COBOL, Python is a bit like the new Pascal — if that helps you understand my perspective at all. (As far as I’m concerned, that’s about a 1000% improvement over being the new COBOL.)

I suppose it’s possible that, once I become truly competent with both Ruby and Python (it’ll probably happen for both eventually, though much sooner for Ruby than Python, given my druthers and my plans for the near future), I’ll discover I’m way out in left field somewhere. I have yet to run across a single bit of credible evidence to the contrary, or even a believable claim that contradicts these impressions.

Some, of course, prefer the Python way of doing things — and they’ll surely describe the comparative characteristics of the two languages differently from how I have. Python is “cleaner”, they might say, and Ruby “too much like Perl” (yeah, keep using that “insult” while proselytizing — it just drives me further from Python and closer to Ruby anyway). Meanwhile, the Rubyist might say that Ruby “encourages” and “guides”, while Python “forces” (though, frankly, in truth Ruby users always seem to be among the most open and friendly of any language’s communities, along with a couple of rare other examples, so I’m not sure your average Rubyist would say anything of the sort).

That’s fine, really. Pythonistas and I don’t have to see eye-to-eye. That’s why they’re Pythonistas and I’m not. At least you know some of the reasoning behind my preference for a language like Ruby over one like Python.

note to self: Check out the above-linked blogger’s website, NearbyGamers. Also, come up with a good, secure, private way to share bookmarks across computers automagically.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License