Posted in Share the Love | 2 Comments » RSS 2.0
After surviving the punch-card-oriented era of Fortran and COBOL, I found liberation in languages like ALGOL and C that place no syntactic value on whitespace beyond delimiting tokens. In these newer languages (which now include Perl, Java, JavaScript, Ruby, and many others) you’re free to use whitespace to improve readability, but that’s completely by convention and not a requirement – you can write the whole program on one line if you prefer.
Of course, the relegation of line feeds, tabs, and spaces to near-total insignificance means that other tokens must be recruited to signify syntactic events such as the end of a statement or the grouping of statements together into blocks. Thus, ALGOL’s introduction of the ubiquitous semi-colon, as well as the begin/end pair that C replaced with {} (often affectionately known by the adolescent-sounding term “squiggly braces”).
Having been programming in C since 1984, the semi-colons and braces just fly off my fingers without me even thinking about them. Languages like Python that not only don’t require them, but complain about them and impose completely different rules to which I am unaccustomed require me to think more about the syntax of what I’m typing, instead of being able to focus on what it means.
But perhaps that’s only because of what I’m used to doing. After all, I do generally use indentation within code blocks – and inadvertently omitting it or worse yet indenting to the wrong level often causes human errors upon rereading the code. If I’m going to indent anyway, why require the squiggly braces (which, after all, are not only a keystroke each, but a shifted one at that)? The Haskell language allows both forms, but I found in practice as many others have that the “layout rule” (which employs significant whitespace) works more naturally within that language. For one thing, a single line feed can be used to terminate multiple layers of indentation.
Just because earlier languages like Fortran abused whitespace as a sort of Simon Says for each statement doesn’t mean that all programming languages should make these potentially useful characters completely meaningless. Most good text editors these days provide some form of auto-indentation, so it’s not like you’d have to lean on the space bar at the beginning of each line as we did back in the old days. Significant whitespace can therefore mean fewer keystrokes than the repetitive { ; }, as well as enforcing a degree of readability.
Imagine how much simpler an XML document would be without all the end tags! Think of all the “end” statements you could leave out of Ruby! Say goodbye to all of those hopelessly illegible Perl one-liners! No more counting braces and parens at the end of a function within a function within a call within a function within a function within a call in JavaScript – just line up the left sides! You could eliminate all the nail clippings in Lisp!
Of course, I could feel differently about this tomorrow.
Posted in Geek Meditations | No Comments » RSS 2.0
Or should that be natural <> simple?
Since the introduction of the first programming languages that didn’t map directly to machine instructions, the debate continues over how closely programming languages should mimic other human languages, especially English. COBOL was the first language (AFAIK) that attempted to allow programmers to write code as semi-English statements. For example:
SUBTRACT AR-TOTAL-BALANCE FROM AR-CREDIT-LIMIT GIVING AR-REMAINING-CREDIT.
Very English – or rather American (including the shouting). As opposed to the much more concise, mathematical, yet somewhat less self-documenting Fortran equivalent:
Z = X – Y
Note how the COBOL statement ends with a period, just like an English sentence – while the Fortran statement mimics a mathematical formula (though it isn’t — it’s an implied LET) by having no terminal punctuation. Because COBOL statements tend to be very wordy, the period actually comes in handy. It allows you to continue a statement over more than one line, because the period clearly marks the end of a statement. But it’s also a curse. It’s easy to forget, because the casual reader can usually tell by context where the end of a statement should be. So it becomes a Simon Says rule – one that punishes the programmer more than it helps.
Back when I used COBOL, if you forgot a period on a COBOL statement every statement in the rest of the program would generate a compilation error. At the end of a college semester, after waiting days to get back the printout from a job you submitted to the queue, you’d often find that your 1345 compilation errors were all due to one missing dot. Then you’d resubmit the corrected version, and wait two more days to find where the next one was missing. I once remarked to a female CS student, “Life is like a COBOL program – miss a period and you’ve had it.”
But without the period, the problem remains of how to continue a statement over more than one line. Fortran and other languages (Synergy/DE and VB included) have resorted to the unnatural practice of placing a continuation character in a specific place. In VB, it’s an underscore at the end of the first line. In Synergy/DE (DIBOL), it’s an ampersand as the first non-whitespace character on the second line. Languages in the Algol tradition (including Pascal, C, Java, C#, etc.) require a terminating semi-colon to delimit statements. This not only allows for ease of continuation, but it also enables having more than one statement on a single source line. Lisp requires matching parentheses, which has the same benefits. Unfortunately, all of these punctuation marks are just as easy to omit as the COBOL period.
Scripting languages like Perl, Python, Ruby, and JavaScript have taken to the practice of inferring the end of a statement or its continuation, while allowing punctuation (e.g., semi-colons, matching parentheses, or the explicit \ continuation in Python) in order to be explicit. This seems very natural. “Hey, you forgot to punctuate? Don’t worry about it – I know what you meant,” the interpreter seems to say.
Unfortunately, as in other human languages “I know what you meant” doesn’t guarantee that you actually do know what I meant. Consider the following Ruby example:
1: def big(frack,n,deal)
2: n * ((frack - 1) / deal * 2.2345) + (deal * 12) - (frack / 3) + (frack - deal) + 1
3: end
4:
5: print big(6,2,0.25)
This prints 97.13, given those parameters to the function “big”. Now, being the good command-line-oriented programmer that I am, I’d like to continue line 2 so it doesn’t exceed the 80th column:
1: def big(frack,n,deal)
2: n * ((frack - 1) / deal * 2.2345) + (deal * 12) - (frack / 3) + (frack - deal)
3: + 1
4: end
5:
6: print big(6,2,0.25)
Now the result is 1. What the frack? Both line 2 and line 3 are syntactically valid in Ruby, because any complete expression can function as a statement. Because they can both be interpreted as independent statements, Ruby does. And since Ruby functions return the last expression evaluated, we get “+ 1”. Adding a semi-colon after the “+ 1” doesn’t help, because Ruby infers one at the end of line 2 if it can. You have to break the line at a different point, such as immediately following an operator, to make the end of the line an invalid end of statement. (I tried enclosing the entire statement in parentheses, and I still get 1! Go figure.)
JavaScript, on the other hand, doesn’t suffer this same symptom even though it also will infer a missing semi-colon. Why? Even though “+ 1” as a statement in JavaScript doesn’t cause an error, it also doesn’t do anything. You have to explicitly “return” a value from a function. So JavaScript can be greedy about combining statements until it can’t, while Ruby non-greedily treats end of line as a statement terminator if it can. Both of these seem to follow the Principle of Least Surprise (POLS) for their syntax, except when they don’t.
This wouldn’t be such a big frack’n deal except for the fact that instead of getting an error you just get an unexpected result. That’s a lot more insidious than 1345 COBOL compilation errors, and it underscores the need for near complete code coverage in your tests for applications written in these languages.
Posted in Coding...OK?, Geek Meditations | 4 Comments » RSS 2.0
Posted in Share the Love | 2 Comments » RSS 2.0
Posted in Share the Love | 2 Comments » RSS 2.0
Trying to solve a software problem just now, I had to jump into Delphi for the first time in a long while. Adding an “else” clause to an “if” block, I somehow automatically remembered to remove the semicolon from the “end” of the “if” block before adding the “else”. Scary.
Pascal was never meant to become second nature. You’re supposed to forget to remove that semi-colon, forget to add the semi-colon at the end of function parameter lists, accidentally use equality when you meant assignment, use double-quotes on strings, and test integers for Boolean truth so the compiler can have the pleasure of getting all Catholic School Holy Sister with a ruler across your knuckles.
Posted in Coding...OK? | No Comments » RSS 2.0
The Ring Nebula is Messier Object 57.
Witty, with such subtlety that I doubt most readers would even get it.
Lorelle includes my tag cloud widget in a list of 31 “interesting WordPress widgets”. Thanks, Lorelle!
engtech reprints some Perls of code poetry for Valentine’s Day.
Randy finds one more certainty in life.
When it comes to the expressive power of a programming language, syntax (the form of statements) makes a huge difference. Semantics (the meaning of terms) are relatively inconsequential, so long as they are precisely defined.
I’m going to be off the radar until next Tuesday. Have a great weekend!
Posted in Share the Love | 1 Comment » RSS 2.0
One gains, one relinquishes authority; both portentous: in 26 AD Pontius Pilate was appointed prefect of Judaea, where he would make an enduring name for himself. The same year, Tiberius largely retired from being emperor to permanently vacation in Capri, letting the Roman empire continue to go to hell.
Across Puget Sound from where I sit, TDavid blogs his side of the storm. Looks like the east side was also without power since Thursday night, but it’s getting restored. Back at you, TD. Stay safe.
Tara Hunt: “Stats mean nothing if they dont account for real people who are truly interested.” How many of those do you have? But even that number is irrelevant.
Chris Samuel liked my simple specification. Thanks for the link, Chris!
Shelley distinguishes syntax and semantics. The former is form, the latter is fecal fecundity.
Joel decides to supplement the discussion on simplicity with a “new” term: elegance. Hmm, seems like I’ve heard that one somewhere before, only it didn’t have much to do with avoiding “intrusion into the users actual DNA-replication goals”.
Maybe it’s wishful thinking, Doug. Pax vobiscum, baby!
Posted in Share the Love | 4 Comments » RSS 2.0
Joel has a well-written post (as always) on why functional syntax makes all the difference when it comes to agility.
I’ve been reading up on Lisp again lately, and I’m quickly falling under the spell of this most elegant of languages. Lisp’s consistency in the treatment of functions and lists (code and data) approaches a Grand Unified Theory of programming.
apotheon and I had an IM conversation yesterday about (what else?) programming languages, and apotheon suggested a cross between Ruby and Lisp: Ruby with a truly functional syntax. As Ruby stands today, you can use “code blocks” (read “anonymous functions”) as arguments to methods (functions), but the support is somewhat inconsistent. It either has to be the last argument declared for the function (in which case the code block follows the function invocation) or you have to use the “proc” function to create the anonymous function reference to pass as an argument. It would be nice if a language could have a functional syntax as regular as Lisp’s, but as readable as Ruby’s, and with Ruby’s radical object-orientation. That would really put the “oo!” back in OOP. Working out the BNF for this magical language is left as an exercise for the reader.
Then the only remaining problem would be what to call it. apotheon suggested LISPR (pronounced “Lisper”). I think it should be a word that is the name of another precious gem in the sequence “Perl, Ruby, …” and is also a woman’s name. Extra points if it sounds like “Lisp”.
Opal? Taken. Jade? Taken. Besides, it sounds too much like Java. Garnet? Used for a UI tool for Lisp. Beryl? Used for a Java Swing XML GUI library … okay … we’ll keep working on the name while you guys smooth out the syntax, all right? Let us know when you’re done.
Posted in Coding...OK? | 1 Comment » RSS 2.0
OPML
blogstrappingBlogstrapping is Chad Perrin's development blog, focusing on Lump development, software design, and the philosophy of programming.
All original content on this site Copyright © Sterling W. Camden, and may be reproduced or distributed under the terms of the Open Works License (OWL) (view license)
Subscribe by Email